図面 (/)

技術 証明書におけるデジタル署名を確証するためのシステムおよび方法

出願人 ブラックベリーリミテッド
発明者 ブラウン,マイケルケー.ブラウン,マイケルエス.
出願日 2005年10月27日 (15年1ヶ月経過) 出願番号 2005-313157
公開日 2006年5月18日 (14年7ヶ月経過) 公開番号 2006-129490
状態 特許登録済
技術分野 暗号化・復号化装置及び秘密通信
主要キーワード はめ込みの 記憶装置要素 分離ワイヤ トランシーバー装置 試行結果 ウィール 基本装置 回路変換
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2006年5月18日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (11)

課題

暗号化されたメッセージの処理において使用され得る、証明書上のディジタル署名を好適に確証するための方法。

解決手段

1つの実施形態において、ディジタル署名確証処理中でディジタル署名が首尾よく確証された場合(ステップ450)、そのディジタル署名を確証するために用いられた公開鍵キャッシュに格納される(ステップ470)。そのディジタル署名を確証する試行が次に為された際には、ディジタル署名を確証するために用いられる公開鍵は、キャッシュに格納されている公開鍵と比較される(ステップ440)。鍵が一致する場合、公開鍵を用いていくつかのデータを復号するような署名確証処理を実行する必要はなく、ディジタル署名を首尾よく確証すること(ステップ480)が可能である。

概要

背景

電子メール(「eメール」)メッセージは、多くの既知プロトコルの一つを利用してエンコードされ得る。Secure Multiple Internet Mail Extensions(「S/MIME」)のように、これらのプロトコルの一部は、守秘性確保と防護とを提供するために、プライベート暗号化鍵に、および、認証と認可とを提供する情報を通信するための公開鍵基盤PKI)に、依存している。秘密鍵公開鍵の対のうちの秘密鍵を利用して暗号化されたデータは、その対になって対応する公開鍵を利用することだけによって解読され得、その逆もまた然りであり得る。メッセージをエンコードすることにおいて利用される公開鍵の真正性は、証明書を使うことで確証される。特に、コンピュータ装置利用者は、メッセージが特定の人に送られる前に、そのメッセージを暗号化したい場合、その利用者は、その人の証明書を要求する。その証明書は、通常、他の身分証明に関する情報だけでなく、その人の公開鍵をも含む。

証明書は、通常、認証局によって発行されるデジタル文書である。特定の公開鍵を信用するためには、通常公開鍵は、信用されている認証局、または、信用される認証局に関連した存在によって発行される必要がある。信用された認証局と発行された公開鍵との間の関係は、証明書チェーンとも呼ばれる、一連の関連された証明書によって示され得る。証明書チェーンは、証明書の妥当性を決定するために、追跡され得る。

通常、認証局はそれぞれの証明書において示されるように、特定の公開鍵が、目的とされる所有者に属することを確証するために、発行するそれぞれの証明書にデジタル署名する。証明書チェーンを作り上げることにおいて、そのチェーンの証明書におけるデジタル署名が確証される必要がある。証明書のデジタル署名の確証は、証明書を発行する認証局の公開鍵を要求するプロセスである。

概要

暗号化されたメッセージの処理において使用され得る、証明書上のディジタル署名を好適に確証するための方法。1つの実施形態において、ディジタル署名確証処理中でディジタル署名が首尾よく確証された場合(ステップ450)、そのディジタル署名を確証するために用いられた公開鍵はキャッシュに格納される(ステップ470)。そのディジタル署名を確証する試行が次に為された際には、ディジタル署名を確証するために用いられる公開鍵は、キャッシュに格納されている公開鍵と比較される(ステップ440)。鍵が一致する場合、公開鍵を用いていくつかのデータを復号するような署名確証処理を実行する必要はなく、ディジタル署名を首尾よく確証すること(ステップ480)が可能である。A

目的

Secure Multiple Internet Mail Extensions(「S/MIME」)のように、これらのプロトコルの一部は、守秘性確保と防護とを提供する

効果

実績

技術文献被引用数
1件
牽制数
2件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

コンピューティング装置上において証明書上のディジタル署名確証する方法であって、該証明書の発行者に関連する第1の公開鍵を用いて、該ディジタル署名に対し、第1の署名確証処理を実行するステップと、該第1の署名確証処理において該ディジタル署名が首尾よく確証されたかどうかを決定するステップと、該第1の公開鍵を記憶装置内に格納するステップと、該証明書の発行者に関連する第2の公開鍵を用いて、該ディジタル署名に対し、第2の署名確証処理を実行するための要求を受けとるステップと、該第2の公開鍵を、該記憶装置内に格納された該第1の公開鍵と比較し、該第1および第2の公開鍵が一致するかを決定するステップと、該第1の署名確証処理において該ディジタル署名が首尾よく確証された場合、および該比較のステップにおいて一致が決定された場合、該要求への応答の際に、該ディジタル署名の確証の成功を指示するステップであって、そのため該第2の署名確証処理が実行される必要のない、ステップとを包含する、方法。

請求項2

前記第1の署名確証処理において前記ディジタル署名が首尾よく確証された場合にのみ、前記格するステップにおいて前記記憶装置内に前記第1の公開鍵が格納される、請求項1に記載の方法。

請求項3

前記格納するステップが、さらに、前記第1の署名確証処理において前記ディジタル署名が首尾よく確証されたか否かを示す結果の格納することを包含し、該結果が、前記指示のステップにおいて、該第1の署名確証処理において該ディジタル署名が首尾よく確証されたか否かを決定するために用いられる、請求項2に記載の方法。

請求項4

前記要求への応答の際、前記指示するステップにおいて、前記第1の署名確証処理において前記ディジタル署名が首尾よく確証されなかったことが示された場合、および、前記比較のステップにおいて一致が決定された場合に、該ディジタル署名の確証の失敗を指示するステップをさらに包含する、請求項3に記載の方法。

請求項5

前記コンピューティング装置がモバイル装置である、請求項1から4に記載の方法。

請求項6

コンピューティング装置上で実行するためのソフトウェアアプリケーションであって、コンピュータ可読媒体上に格納され、請求項1から5のいずれかに一項に記載された方法のステップを実行するための複数の命令を備える、ソフトウェアアプリケーション。

請求項7

証明書上のディジタル署名を確証するためのシステムであって、少なくとも1つのコンピューティング装置を備え、証明書確証アプリケーションが、該少なくとも1つのコンピューティング装置のコンピューティング装置上で実行し、かつ常駐し、該証明書確証アプリケーションが、請求項1から5のいずれかに一項に記載の方法のステップを実行するようにプログラムされた、システム。

技術分野

0001

本発明は、一般的にeメールメッセージのようなメッセージを処理すること、より詳細にはエンコードされたメッセージを処理することにおいて使用される証明書確証するためのシステムおよび方法に関する。

背景技術

0002

電子メール(「eメール」)メッセージは、多くの既知プロトコルの一つを利用してエンコードされ得る。Secure Multiple Internet Mail Extensions(「S/MIME」)のように、これらのプロトコルの一部は、守秘性確保と防護とを提供するために、プライベート暗号化鍵に、および、認証と認可とを提供する情報を通信するための公開鍵基盤PKI)に、依存している。秘密鍵公開鍵の対のうちの秘密鍵を利用して暗号化されたデータは、その対になって対応する公開鍵を利用することだけによって解読され得、その逆もまた然りであり得る。メッセージをエンコードすることにおいて利用される公開鍵の真正性は、証明書を使うことで確証される。特に、コンピュータ装置利用者は、メッセージが特定の人に送られる前に、そのメッセージを暗号化したい場合、その利用者は、その人の証明書を要求する。その証明書は、通常、他の身分証明に関する情報だけでなく、その人の公開鍵をも含む。

0003

証明書は、通常、認証局によって発行されるデジタル文書である。特定の公開鍵を信用するためには、通常公開鍵は、信用されている認証局、または、信用される認証局に関連した存在によって発行される必要がある。信用された認証局と発行された公開鍵との間の関係は、証明書チェーンとも呼ばれる、一連の関連された証明書によって示され得る。証明書チェーンは、証明書の妥当性を決定するために、追跡され得る。

0004

通常、認証局はそれぞれの証明書において示されるように、特定の公開鍵が、目的とされる所有者に属することを確証するために、発行するそれぞれの証明書にデジタル署名する。証明書チェーンを作り上げることにおいて、そのチェーンの証明書におけるデジタル署名が確証される必要がある。証明書のデジタル署名の確証は、証明書を発行する認証局の公開鍵を要求するプロセスである。

課題を解決するための手段

0005

確証のプロセスは、特に、たとえばモバイル装置等、小型のデバイス上で確証が実行される場合には、時間を要し、コストのかかるものとなる可能性がある(コンピューティングリソースの使用の点において)。複数の証明書がユーザのコンピューティング装置上で処理される場合、同一の署名が1回以上確証され得る。本発明の実施形態は、概して署名確証処理に用いられたある種の情報を、再使用のために格納することによって、署名の確証をより効率的にするシステムおよび方法に向けられている。

0006

本発明の広い視野において、コンピューティング装置上において証明書上のディジタル署名を確証する方法であって、第1の証明書の発行者に関連する第1の公開鍵を用いて、ディジタル署名に対し、第1の署名確証処理を実行するステップと、第1の署名確証処理においてディジタル署名が首尾よく確証されたかどうかを決定するステップと、第1の公開鍵を記憶装置内に格納するステップと、証明書の発行者に関連する第2の公開鍵を用いて、ディジタル署名に対し、第2の署名確証処理を実行するための要求を受けるステップと、第2の公開鍵を、記憶装置内に格納された第1の公開鍵と比較し、第1および第2の公開鍵が一致するかを決定するステップと、第1の署名確証処理においてディジタル署名が首尾よく確証された場合、および比較のステップにおいて一致が決定された場合、要求への応答の際に、ディジタル署名の確証の成功を指示するステップであって、そのため署名確証処理が実行される必要のない、ステップとを包含する、署名確証方法。

0007

本発明は、さらに以下の手段を提供する。

0008

項目1)
コンピューティング装置上において証明書上のディジタル署名を確証する方法であって、
該証明書の発行者に関連する第1の公開鍵を用いて、該ディジタル署名に対し、第1の署名確証処理を実行するステップと、
該第1の署名確証処理において該ディジタル署名が首尾よく確証されたかどうかを決定するステップと、
該第1の公開鍵を記憶装置内に格納するステップと、
該証明書の発行者に関連する第2の公開鍵を用いて、該ディジタル署名に対し、第2の署名確証処理を実行するための要求を受けとるステップと、
該第2の公開鍵を、該記憶装置内に格納された該第1の公開鍵と比較し、該第1および第2の公開鍵が一致するかを決定するステップと、
該第1の署名確証処理において該ディジタル署名が首尾よく確証された場合、および該比較のステップにおいて一致が決定された場合、該要求への応答の際に、該ディジタル署名の確証の成功を指示するステップであって、そのため該第2の署名確証処理が実行される必要のない、ステップと
を包含する、方法。

0009

(項目2)
上記第1の署名確証処理において上記ディジタル署名が首尾よく確証された場合にのみ、上記格するステップにおいて上記記憶装置内に上記第1の公開鍵が格納される、項目1に記載の方法。

0010

(項目3)
上記格納するステップが、さらに、上記第1の署名確証処理において上記ディジタル署名が首尾よく確証されたか否かを示す結果の格納することを包含し、該結果が、上記指示のステップにおいて、該第1の署名確証処理において該ディジタル署名が首尾よく確証されたか否かを決定するために用いられる、項目2に記載の方法。

0011

(項目4)
上記要求への応答の際、上記指示するステップにおいて、上記第1の署名確証処理において上記ディジタル署名が首尾よく確証されなかったことが示された場合、および、上記比較のステップにおいて一致が決定された場合に、該ディジタル署名の確証の失敗を指示するステップをさらに包含する、項目3に記載の方法。

0012

(項目5)
上記コンピューティング装置がモバイル装置である、項目1から4に記載の方法。

0013

(項目6)
コンピューティング装置上で実行するためのソフトウェアアプリケーションであって、コンピュータ可読媒体上に格納され、項目1から5のいずれかに一項に記載された方法のステップを実行するための複数の命令を備える、ソフトウェアアプリケーション。

0014

(項目7)
証明書上のディジタル署名を確証するためのシステムであって、少なくとも1つのコンピューティング装置を備え、証明書確証アプリケーションが、該少なくとも1つのコンピューティング装置のコンピューティング装置上で実行し、かつ常駐し、該証明書確証アプリケーションが、項目1から5のいずれかに一項に記載の方法のステップを実行するようにプログラムされた、システム。

0015

本発明の実施形態をより良く理解するために、また、本発明がどのように実行され得るのか示すために、例示の方法によって、添付の図面を参照する。

発明を実施するための最良の形態

0016

本発明における一部の実施形態は移動局を利用する。移動局は、他のコンピュータ装置と通信する能力を持つ高度なデータ通信能力を有する2ウェイ通信装置である。モバイル装置はまた、音声通信のための能力も含み得る。モバイル装置によって提供された機能に依存して、それはデータメッセージング装置、送受信両用小型通信機、データメッセージング能力を有する携帯電話ワイヤレスインターネット機器、または、データ通信装置電話機能があってもなくても)などと呼ばれ得る。モバイル装置は、受信局ネットワークを介して他の装置と通信する。

0017

モバイル装置の構造および、他の装置と通信する方法を理解することにおいて、読者を助けるために、図1から図3を参照し得る。

0018

最初に図1を参照し、例示的な一実施におけるモバイル装置のブロック図が100に示される。モバイル装置100は、多くの構成要素を含み、制御の構成要素はマイクロプロセッサ102である。マイクロプロセッサ102は、モバイル装置100の全体にわたる動作を制御する。データおよび音声通信を含む通信機能は、通信サブシステム104を介して実行される。通信サブシステム104は、ワイヤレスネットワーク200からメッセージを受信および送信する。この例のモバイル装置の実施において、通信サブシステム104は、Global System for Mobile Communication(GSM)およびGeneral Packet Radio Services(GPRS)標準にしたがって構成されている。GSM/GPRSワイヤレスネットワークは、世界中で利用されており、これらの標準は、Enhanced Data GSM Environment(EDGE)およびUniversal Mobile Telecommunications Service(UMTS)によって、最終的には取って代わられることが期待されている。新しい標準はまだ制限されているが、それらはここで説明されるネットワークの性質類似性を有すると信じられており、本発明は未来において発展される、他の任意のふさわしい標準にも利用することを意図されていることが、当業者によってもまた理解されている。通信サブシステム104とネットワーク200とを接続するワイヤレスリンクは、一つ以上の異なるラジオ周波数(RF)チャンネルを示しており、GSM/GPRS通信のために特定化された限定のプロトコルにしたがって動作する。より新しいネットワークプロトコルを有し、これらのチャンネルは、回路変換音声通信およびパケット交換データ通信の両方をサポートすることができる。

0019

モバイル装置100に関連するワイヤレスネットワークは、一実施例におけるモバイル装置100の実行におけるGSM/GPRSワイヤレスネットワークであるけれども、他のワイヤレスネットワークはまた、異なる実行におけるモバイル装置100に関連させられ得る。使用され得るワイヤレスネットワークの異なるタイプは、例えば、データ中心ワイヤレスネットワーク、音声中心ワイヤレスネットワーク、および同じ物理的基地局を媒体にして音声およびデータ通信の両方をサポートすることができるデュアルモードネットワークを含む。組み合わされたデュアルモードネットワークは、符号分割多重アクセス(CDMA)、CDMA2000ネットワーク、GSM/GPRSネットワーク(上述したように)、またはEDGEやUMTSのような未来の第三世代(3G)ネットワークを含み得るが、限定されるものではない。データ中心ネットワークの一部のより古い実施例は、Mobitex(登録商標ラジオネットワークおよびDataTAC(登録商標)ラジオネットワークを含む。音声中心データネットワークのより古い実施例は、GSMのようなPersonal Communication Systems(PCS)ネットワークおよびTime Division Multiple Access(TDMA)システムを含む。

0020

マイクロプロセッサ102はまた、ランダムアクセスメモリ106、フラッシュメモリ108、ディスプレイ110、補助入力/出力(I/O)サブシステム112、シリアルポート114、キーボード116、スピーカ118、マイクロフォン120、近距離通信122、および他の装置124のような追加のサブシステムと相互作用する。

0021

モバイル装置100のサブシステムの一部は、通信関連機能を実行するが、他のサブシステムは、「常駐」またはデバイス上の機能を提供し得る。実施例によって、ディスプレイ110およびキーボード116は、ネットワーク200を媒体として送信のためのテキストメッセージを入力するような通信関連機能、および計算機またはタスクリストのようなデバイス−常駐機能の両方のために利用され得る。マイクロプロセッサ102によって利用されるシステムソフトウェアを動作することは、通常、フラッシュメモリ108のような永続性記憶装置において記憶され、それは、代替的には、読み出し専用記憶装置または類似した記憶装置要素(図には示されてない)であり得る。当業者は、オペレーティングシステム、特定の装置アプリケーションまたはその一部が、RAM106のような揮発性記憶装置に一時的にロードされ得る。

0022

モバイル装置100は、要求されたネットワーク登録または始動手続きが完了した後に、ネットワーク200を媒体として通信信号を送受信し得る。ネットワークアクセスは、モバイル装置100の加入者または利用者に関連している。加入者の身元を確証するために、モバイル装置100は、ネットワークと通信するための加入者確証モジュールまたはSIMインターフェース128が挿入された「SIM」カード126を要求する。SIM126は、モバイル装置100の加入者の身元を確証するため、およびモバイル装置100をパーソナライズするために利用される従来の「スマートカード」の中の一タイプである。SIM126なしでは、モバイル装置100は、ネットワーク200との通信において、十分に動作しない。SIM126をSIMインターフェース128に挿入することによって、加入者は、加入者用の全てのサービスアクセスできる。サービスは、ウェッブ閲覧、eメール、ボイスメールショートメッセージサービス(SMS)、およびマルチメディアメッセージングサービス(MMS)などのメッセージングを含むことができる。さらに高度なサービスは、販売時点情報管理(point of sale)、フィールドサービス(field service)、および営業支援システム(sales force automation)を含む。SIM126は、情報を記憶するためにプロセッサメモリを含む。一度SIM126がSIMインターフェース128に挿入されると、それはマイクロプロセッサ102に結合される。加入者の身元を確証するために、SIM126は、International Mobile Subscriber Identity(IMSI)のような一部の利用者パラメータを含む。SIM126を利用することの利点は、加入者が任意の単一の物理的モバイル装置によっても必然的に拘束されないことである。SIM126は、メモ帳(またはカレンダー)情報および最近の通話情報を含み、モバイル装置のための追加的な加入者情報もまた記憶し得る。

0023

モバイル装置100は、バッテリー電力供給装置であり、一つ以上の再充電可能なバッテリー130を収容するためのバッテリーインターフェース132を含む。バッテリーインターフェース132は、調整装置(図には示されていない)に結合され、それは電力V+をモバイル装置100に供給することでバッテリー130を補助する。現在の技術はバッテリーを利用するが、マイクロ燃料電池のような未来の技術は、モバイル装置100に電力を供給し得る。

0024

そのオペレーティングシステム機能に付け加えて、マイクロプロセッサ102は、モバイル装置100のソフトウェアアプリケーションの実行を可能にする。データおよび音声通信アプリケーションを含み、基本装置動作を制御する一式のアプリケーションは、通常その製造過程の間に、モバイル装置100にインストールされている。モバイル装置100にロードされ得る他のアプリケーションは、パーソナルインフォメーションマネージャー(PIM)である。PIMは、eメール、カレンダーイベント、ボイスメール、予約タスクアイテムなど(限定されないが)のような、当該のデータアイテムを、加入者へ、組織および管理する機能を持つ。PIMアプリケーションは、ワイヤレスネットワーク200を介して、データアイテムを送受信する能力を持つ。PIMデータアイテムは、ホストコンピュータシステムに記憶および/または関連されたモバイル装置加入者の対応するデータアイテムを有するワイヤレスネットワーク200を介して、継ぎ目なく統合され、同期化され、またアップデートされ得る。この機能は、そのようなアイテムに関して、モバイル装置100のミラーホストコンピュータを創る。これは、ホストコンピュータシステムがモバイル装置加入者のオフィスコンピュータシステムである場合、特に有益であり得る。

0025

追加的なアプリケーションはまた、ネットワーク200、補助I/Oサブシステム112、シリアルポート114、近距離通信サブシステム122、または任意の他の適切なサブシステム124を介して、モバイル装置100にロードされ得る。アプリケーションのインストールにおけるこの柔軟性は、モバイル装置100の機能を増加させ、強化型のデバイス上の機能、通信関連機能、または両方を提供し得る。例えば、安全な通信アプリケーションは、電子商業機能および他の経済取引に、モバイル装置100の使用を実行させることを可能にし得る。

0026

シリアルポート114は、外部装置またはソフトウェアアプリケーションを介して加入者に好みを設定させることが可能であり、ワイヤレス通信ネットワークを介するのとは異なったモバイル装置100へ、情報またはソフトウェアダウンロードを提供することによって、モバイル装置100の性能を拡張する。代替的なダウンロード経路は、例えば、安全な装置通信を提供するために、直接の、信頼および信用された接続を介して、モバイル装置100へ暗号化鍵をロードするために利用され得る。

0027

近距離通信サブシステム122は、ネットワーク200の利用なしで、モバイル装置100と異なるシステムまたは装置との間に通信を提供する。例えば、サブシステム122は、赤外線装置、関連される回路および近距離通信の構成要素を含み得る。近距離通信の実施例は、Infrared Data Association(IrDA)、Bluetooth(登録商標)、および、IEEEによって開発された802.11標準ファミリーを含む。

0028

使用において、テキストメッセージ、eメールメッセージ、またはウェッブページのダウンロードなどのような受信された信号は、通信サブシステム104によって処理され、マイクロプロセッサ102へ入力される。マイクロプロセッサ102は、ディスプレイ110または代替的に、補助I/Oサブシステム112へ出力するために、受信された信号を処理する。加入者はまた、例えばディスプレイ110および可能ならば、補助I/Oサブシステム112に接続しているキーボード116を使って、eメールメッセージなどのデータアイテムを作成し得る。補助サブシステム112は、タッチスクリーンマウストラックボール赤外線指紋検出器、またはダイナミックタンプレス能力を有するローラーウィールなどの装置を有し得る。キーボード116は、英数字キーボードおよび/または電話キーパッドである。作成されたアイテムは、通信サブシステム104を介して、ネットワーク200を媒体にして送信され得る。

0029

音声通信にとって、モバイル装置100の全ての動作は、受信された信号がスピーカ118に出力され、送信のための信号がマイクロフォン120によって生成されることを除いて、実質的に類似している。音声メッセージ記録サブシステムのような代替の音声または音声I/Oサブシステムはまた、モバイル装置100に提供され得る。音声または音声信号出力は、第1にスピーカ118を介して完了されるが、ディスプレイ110はまた、通話者の身元確証、音声通話継続時間、または音声通話に関連した情報などの追加的情報を提供するために利用され得る。

0030

図2を参照すると、図1の通信サブシステム構成要素104のブロック図が示されている。通信サブシステム104は、受信機150、送信機152、一つ以上のはめ込みの、または内部のアンテナ要素154、156、ローカル発振器(LOs)158、およびデジタル信号プロセッサ(DSP)160のような処理モジュールを含む。

0031

通信サブシステム104の特定のデザインは、モバイル装置100が動作することを意図されているネットワーク200に依存しており、図2で示されたデザインがほんの一実施例であることは理解されるべきである。ネットワーク200を介してアンテナ154によって受信された信号は、受信機150に入力され、それは、信号アンプ周波数低減変換、フィルタリングチャンネル選択、およびアナログからデジタルへの変換(A/D)などとしての通常の受信機機能を実行し得る。受信された信号のA/D変換は、復調およびデコーディングなどのより複雑な通信機能をDSP160において実行させることを許可する。類似した方法において、変調およびエンコーディングを含み、送信される信号はDSP160によって処理される。これらのDSP処理信号は、デジタルからアナログ(D/A)変換、周波数増加変換、フィルタリング、アンプ、およびアンテナ156を介してネットワーク200を媒体にした送信などのために、送信機152へ入力される。DSP160は、通信信号を処理するだけでなく、受信機および送信機の制御も提供する。例えば、受信機150および送信機152における通信信号に適用されたゲインは、DSP160に提供された自動ゲイン制御アルゴリズムを介して適応できるように制御され得る。

0032

モバイル装置100とネットワーク200との間のワイヤレスリンクは、一つ以上の異なるチャンネル、通常異なるRFチャンネル、および、モバイル装置100とネットワーク200との間で利用される関連されたプロトコルを含み得る。RFチャンネルは、通常、全ての帯域幅における制限およびモバイル装置100のバッテリー電力制限のために、節約されなければならない限定された資源である。

0033

モバイル装置100が十分に動作する場合、送信機152は、ネットワーク200に送信している場合にのみ、通常、入力され、またはオンにされる。そうでない場合は、資源を節約するためにオフにされる。同様に、受信機150は、指定された時間の間に、信号または情報(仮にあるならば)を受信するために必要とされるまで、電力を節約するために定期的にオフにされる。

0034

図3を参照すると、ワイヤレスネットワークのノードのブロック図が202として示されている。実際には、ネットワーク200は、一つ以上のノード202を含む。モバイル装置100は、ワイヤレスネットワーク200の中で、ノード202と通信する。図3の実施例の実行において、ノード202は、General Packet Radio Service(GPRS)および、Global Systems for Mobile technologies(GSM)にしたがって構成される。ノード202は、関連した基地局206を有する基地局制御装置BSC)204、GSMにおけるGPRSのサポートを追加されたパケット制御ユニット(PCU)208、移動通信交換局MSC)210、Home Location Register(HLR)212、Visitor Location Registry(VLR)214、Serving GPRS Support Node(SGSN)216、Gateway GPRS Support Node(GGNS)218および、Dynamic Host Configuration Protocol(DHCP)220を含む。構成要素のこのリストは、GSM/GPRSの中の全てのノード202の包括的なリストであることを意味しているのではなく、むしろ、ネットワーク200を介して通信に、通常利用される構成要素のリストである。

0035

GSMネットワークにおいて、MSC210は、BSC204および、回路交換要求を満たすための、Public Switched Telephone Network(PSTN)222のような地上通信線ネットワークに結合される。公共またはプライベートネットワーク(インターネット)224(一般的に、共有されたネットワークインフラストラクチャとも呼ばれる)への、PCU208、SGSN216およびGGSN218を介した接続は、GPRSの可能なモバイル装置のためのデータ経路を表している。GPRSの能力を拡張したGSMネットワークにおいて、BSC204はまた、分割や無線チャンネル割り当てを制御するため、およびパケット交換要求を満たすために、SGSN216へ接続するパケット制御ユニット(PCU)208を含む。モバイル装置の位置ならびに、回路交換およびパケット交換要求両方の利用を追跡するために、HLR212は、MSC210とSGSN216との間でシェアされる。VLR214へのアクセスは、MSC210によって制御される。

0036

基地局206は固定されたトランシーバー基地局である。基地局206およびBSC204はともに、固定されたトランシーバー装置を形成する。固定されたトランシーバー装置は、通常「セル」と呼ばれる特定の範囲エリアのためにワイヤレスネットワーク範囲を提供する。固定されたトランシーバー装置は、基地局206を介してそのセル内のモバイル装置へ通信信号を送信および受信する。固定されたトランシーバー装置は通常、制御装置の制御のもとで、特定の、通常は前もって決定された通信プロトコルおよびパラメータにしたがったモバイル装置へ送信されるための信号の変調および、可能な場合、エンコードおよび/または暗号化としての機能を実行する。固定された受トランシーバー装置は同様に、必要であれば、そのセル内のモバイル装置100から受信された任意の通信信号を復調および、可能な場合、デコードおよび/または暗号解読する。通信プロトコルおよびパラメータは、異なるノードの間で変化し得る。例えば、一つのノードは、異なる変調スキームを利用し得、他のノードとは異なる周波数にて動作し得る。

0037

特定のネットワークに記録された全てのモバイル装置100にとって、利用者のプロフィールのような恒常的な構成データは、HLR212に記憶される。HLR212はまた、それぞれの記録されたモバイル装置の位置情報を含み、モバイル装置の現在の位置を決定するために照会され得る。MSC210は、位置エリア集まり監督下に置き、VLR214における監督エリアにおいて、目下、モバイル装置のデータを記憶する。さらに、VLR214はまた、他のネットワークを訪れているモバイル装置の情報を含む。VLR214における情報は、より速いアクセスのために、HLR212からVLR214へ送信された恒常のモバイル装置データの一部を含む。遠隔HLR212ノードからVLR214への追加的情報を動かすことによって、これらのノード間のデータ流通量は、音声およびデータサービスがより速い応答時間、と同時により少ないコンピュータリソースの使用を要求することを提供され得るために、減少され得る。

0038

SGSN216およびGGSN218は、GSM内のGPRSサポート、主にpacket switched data supportのために追加された要素である。SGSN216およびMSC210は、それぞれのモバイル装置100の位置の追跡をすることによって、ワイヤレスネットワーク200内で、類似した責任を有する。SGSN216はまた、ネットワーク200でのデータ流通のためのセキュリティ機能およびアクセス制御を実行する。GGSN218は、外部パケット交換ネットワークインターネット接続し、ネットワーク200内で操作されるインターネットプロトコル(IP)バックボーンネットワークを介して、一つ以上のSGSN216に接続する。通常動作の間、所定のモバイル装置100は、IPアドレスを獲得するため、およびデータサービスにアクセスするために、「GPRSアタッチ」を実行しなければならない。Integrated Services Digital Network(ISDNアドレスが、掛かってきた通話および掛けた通話をルートするために利用される場合、この要求は、回路交換音声チャンネルには存在しない。現在、全てのGPRSの可能なネットワークは、ダイナミックに、プライベートの割り当てられたIPアドレスを利用し、GGSN218へ接続されたDHCPサーバ220を要求する。Remote Authentication Dial−In User Service(RADIUS)サーバおよびDHCPサーバの組み合わせを利用することを含み、ダイナミックIPアドレス割り当てのための多くのメカニズムがある。一度、GPRSアタッチが完了されると、論理接続は、モバイル装置100から、PCU208およびSGSN216を介して、GGSN218内のアクセスポイントノードAPN)へ確立される。APNは、ダイレクトインターネット互換サービスまたはプライベートネットワーク接続のどちらかにアクセスできるIPトンネル論理エンド(end)を示している。APNはまた、それぞれのモバイル装置100が一つ以上のAPNに割り当てられなければならず、および、モバイル装置100が、利用の認可されたAPNへGPRSアタッチを第1に実行せずに、データを交換しえなくなる限りにおいて、ネットワーク200のためのセキュリティメカニズムを示している。APNは、「myconnection.wireless.com」のような、インターネットドメイン名と類似していると考えられ得る。

0039

一度GPRSアタッチが完了すると、トンネルは創られ、IPパケットにおいてサポートされ得る任意のプロトコルを使用した全てのデータ流通は標準IPパケット内で交換される。これはバーチャルプライベートネットワーク(VPN)を用いて利用される一部のIPセキュリティ(IPsec)接続においてはよくあることだが、IP over IPのようなトンネル方法を含む。これらのトンネルはまた、パケットデータプロトコル(PDP)状況と呼ばれ、ネットワーク200においては、限定された利用可能数がある。PDP状況を最大利用するために、ネットワーク200は、活動に欠如があるかどうかを決定するために、それぞれのPDP状況に持ち時間を与える。モバイル装置100がそのPDP状況を利用しない場合、PDP状況は、割り当てを取り消され得、IPアドレスは、DHCPサーバ220によって管理されるIPアドレスプールへ戻る。

0040

図4を参照して、一実施例の構成におけるホストシステムの構成要素が図示されているブロック図が示されている。ホストシステム250は、通常、企業オフィスまたは他のローカルエリアネットワーク(LAN)であるが、例えば、異なる実行においては、ホームオフィスコンピュータまたは一部の他のプライベートシステムでもあり得る。図4において示された実施例において、ホストシステム250は、モバイル装置100のユーザが属する組織のLANとして図示されている。

0041

LAN250は、LAN接続260によってお互いに接続された多くのネットワーク構成要素を含む。例えば、ユーザのモバイル装置100のための付随クレイドル264を有するユーザのデスクトップコンピュータ262aはLAN250に置かれる。モバイル装置100のためのクレイドル264は、例えば、シリアル接続またはUniversal Serial Bus(USB)接続によって、コンピュータ262aに結合され得る。他のユーザコンピュータ262bはまた、LAN250に置かれ、それぞれは、モバイル装置のための付随クレイドル264を備え得、または備え得ない。クレイドル264は、ユーザコンピュータ262aからモバイル装置100への情報(例えば、PIMデータ、モバイル装置100とLAN250との間の安全な通信を容易にするための暗号化対称秘密鍵(private symmetric encryption keys))のロードを容易にし、モバイル装置100の使用を初期設定することにおいて実行される、大量の情報アップデートにとって、特に有益であり得る。モバイル装置100へダウンロードされた情報は、メッセージ交換において利用される証明書を含み得る。ユーザコンピュータ262a、262bはまた、図4にて明示的に示されてはいないが、他の周辺装置に接続されることが、当業者によって理解される。

0042

さらに、LAN250のネットワーク構成要素のサブセットのみが、説明のために図4において示され、LAN250が、図4において明示的に示されてはいないが、この実施例の構成のために、追加の構成要素を含むことが当業者によって理解される。さらに一般的には、LAN250は、この組織の、より大きなネットワーク(図示されていない)のより小さな一部を示し得、異なる構成要素を含み得、および/または、図4の実施例において示されたのとは異なるトポロジーにおいて配置され得る。

0043

本実施例において、モバイル装置100は、ワイヤレスネットワーク200のノード202および、サービスプロバイダーネットワークまたはパブリックインターネットのような、共有されたネットワークインフラストラクチャ224を介してLAN250と通信する。LAN250へのアクセスは、一つ以上の経路(図には示されていない)を介して提供され得、LAN250のコンピュータ装置は、ファイアウォール後ろから、またはプロキシサーバ266から、動作し得る。

0044

異なる実行において、LAN250は、LAN250とモバイル装置100との間のデータ交換を容易にするために、ワイヤレスVPNルータ(図には示されていない)を含む。ワイヤレスVPNルータのコンセプトは、ワイヤレス産業においては新しくVPN接続は、特定のワイヤレスネットワークを介してモバイル装置100へ、直接に確立され得ることを意味する。ワイヤレスVPNルータの使用の見込みは、最近になりようやく利用可能となり、新しいインターネットプロトコル(IP)バージョン6(IPV6)がIPベースのワイヤレスネットワークに届く場合に、利用され得ている。この新しいプロトコルは、IPアドレスを全てのモバイル装置に与えるために、十分なIPアドレスを提供し、いつでもモバイル装置へ情報を送ることを可能にさせる。ワイヤレスVPNルータを使用することの利点は、規格品のVPN構成要素であり得、使用される分離ワイヤレスゲートウェイおよび分離ワイヤレスインフラストラクチャを要求しない。VPN接続は、この異なる実行において、モバイル装置100へ直接にメッセージを運ぶために、好ましくはトランスミッションコントロールプロトコル(TCP)/IP、またはユーザデータグラムプロトコルUDP)/IP接続である。

0045

モバイル装置100のユーザのために意図されたメッセージは、LAN250のメッセージサーバ268によって最初に受信される。そのようなメッセージは、多数のソースの中の任意のソースから始まり得る。例えば、メッセージは、供給されたネットワークインフラストラクチャ224を介して、ワイヤレスネットワーク200または異なるワイヤレスネットワークに接続された異なるモバイル装置から(図には示されていない)、あるいは、異なるコンピュータ装置またはメッセージ送信可能な他の装置から、および可能な場合、例えば、アプリケーションサービスプロバイダ(ASP)またはインターネットサービスプロバイダ(ISP)を介して、LAN250内のコンピュータ262bから送信者によって送信され得る。

0046

メッセージサーバ268は通常、組織内および共有されたネットワークインフラストラクチャ224へ、メッセージ交換、特にeメールメッセージ交換のために、第1インターフェースとしてアクトする。メッセージを送受信するためにセットアップされている組織におけるそれぞれのユーザは、通常、メッセージサーバ268によって管理されるユーザアカウントに関連される。メッセージサーバ268の一実施例は、Microsoft Exchange(登録商標)サーバである。一部の実行において、LANは、マルチプルメッセージサーバ268を含み得る。メッセージサーバ268はまた、例えばカレンダーやタスクリストと関連させられたデータの管理を含み、メッセージ管理の範囲を超えて、追加的機能を提供するために適合され得る。

0047

メッセージがメッセージサーバ268によって受信された場合、それらは通常、メッセージ記憶装置に記憶され得、メッセージはその後、引き出され得、利用者に運ばれ得る。例えば、ユーザのコンピュータ262aにあるeメールクライアントアプリケーションオペレーティングは、メッセージサーバ268に記憶されたそのユーザアカウントに関連されたeメールメッセージを要求し得る。これらのメッセージは、通常、メッセージサーバ268から引き出され、コンピュータ262aに局地的に記憶される。

0048

モバイル装置100を動作する場合、ユーザは、eメールメッセージを持ち運びのために、ハンドヘルドから引き出されることを望み得る。モバイル装置100上で動作するeメールクライアントアプリケーションはまた、メッセージサーバ268からのユーザアカウントに関連されたメッセージを要求し得る。eメールクライアントは、(ユーザによって、または管理者によって、可能な場合、組織の情報技術(IT)ポリシーにしたがい)ユーザの指令で、一部の所定の定義された時間間隔で、または一部の所定の定義され得たイベントの発生にて、この要求をするために設定され得る。一部の実行において、モバイル装置100は、それ自身のeメールアドレスを割り当てられ、特にモバイル装置100へアドレスされたメッセージは、メッセージサーバ268によってそれらが受信されるように、自動的にモバイル装置100にリダイレクトさせる。

0049

モバイル装置100とLAN250との間のメッセージのワイヤレス通信およびメッセージに関連されたデータを容易にするために、多くのワイヤレス通信のサポート構成要素270は提供され得る。本実施例の実行において、ワイヤレス通信をサポートする構成要素270は、例えば、メッセージ管理サーバ272を含む。メッセージ管理サーバ272は、特に、モバイル装置によって扱われるeメールメッセージのようなメッセージの管理のためのサポートを提供するために利用される。一般には、メッセージはメッセージサーバ268に記憶される一方で、メッセージ管理サーバ272は、メッセージがモバイル装置100へ、いつ、どのように、および、送られるべきかどうかを制御するために利用され得る。メッセージ管理サーバ272はまた、モバイル装置100で作成されたメッセージの扱いを容易にし、次の送達のためにメッセージサーバ268へ送られる。

0050

例えば、メッセージサーバ272は、新しいeメールメッセージのために、ユーザの「メールボックス」(例えば、メッセージサーバ268のユーザアカウントに関連されたメッセージ記憶装置など)を監視し得、メッセージがユーザのモバイル装置100へ、どのように、および、中継されるかどうかを決定するために、ユーザが定義可能なフィルタを新しいメッセージに適用し得、新しいメッセージを圧縮および暗号化(例えば、データ暗号か標準(DES)またはトリプルDES)し得、共有されたネットワークインフラストラクチャ224およびワイヤレスネットワーク200を介して、モバイル装置100へそれらをプッシュし得、モバイル装置100で作成されたメッセージ(例えば、トリプルDESを使って暗号化された)を受信し得、作成されたメッセージが解読および解凍され得、それらのメッセージがユーザコンピュータ262aから来ているように所望される場合に、作成されたメッセージを再フォーマットし得、送達のためにメッセージサーバ268へ作成されたメッセージを再ルートし得る。

0051

モバイル装置100から送信、および/または、受信されるメッセージに関連された属性または規制は、メッセージ管理サーバ272によって定義および強化(ITポリシーにしたがった管理者によって)され得る。これらは、モバイル装置100が、最小の暗号化鍵サイズで暗号化された、および/または署名されたメッセージ、を受信し得るかどうか、送信メッセージが暗号化、および/または署名されなければならないかどうか、および、モバイル装置100から送られた全ての安全なメッセージのコピーが例えば、所定のコピーアドレスへ送られたかどうかを含み得る。

0052

メッセージ管理サーバ272はまた、メッセージ情報、またはメッセージサーバ268に記憶されたメッセージの所定の一部(例えば、ブロックなど)をモバイル装置100にプッシュするなどように、他の制御機能を提供するために適用され得る。例えば、メッセージが、メッセージサーバ268からモバイル装置100によって最初に引き出される場合、メッセージ管理サーバ272は、所定のサイズ(例えば2KB)の一部を有し、メッセージの最初の一部だけをモバイル装置100へプッシュするために適用される。モバイル装置100へ、メッセージ管理サーバ272によって同様なサイズのブロックにて送られるため、ユーザはそれゆえ、可能な場合、最大の所定のメッセージサイズまで、メッセージの多くを要求することができる。

0053

したがって、メッセージ管理サーバ272は、モバイル装置100に通信されるデータのタイプおよびデータ量に対してより良い制御を容易にし、帯域幅の潜在的な無駄または他のリソースを最小限にすることを助けることができる。

0054

メッセージ管理サーバ272は、LAN250または他のネットワークにおける分離した物理サーバにおいて実行される必要がないことは、当業者によって理解される。例えば、メッセージ管理サーバ272に関連された機能の一部または全ては、メッセージサーバ268またはLAN250における一部の他のサーバに統合され得る。そのうえ、LAN250は、特に多数のモバイル装置がサポートされる必要がある場合の異なった実行において、多数のメッセージ管理サーバ272を含み得る。

0055

本発明の実施形態は一般に、暗号化され、および/または署名される例えばeメールメッセージのように、エンコードされたメッセージの処理において使用される証明書に関する。SMTP(Simple Mail Transfer Protocol)、RFC882ヘッダ、およびMIME(Multipurpose Internet Mail Extensions)の本体部分は、エンコードを必要としない一般的なeメールのフォーマットを定義するために利用され得る一方で、MIMEプロトコルの一バージョンであるS/MIME(Secure/MIME)は、(例えば、安全なメッセージングアプリケーションにおいて)、エンコードされたメッセージの通信において利用され得る。S/MIMEは終端間(end−to−end)の認証および守秘性確保を可能とし、メッセージの受信者によってデコードされ読まれるまで、メッセージの作成者がメッセージを送信する時点からデータの防護およびプライバシーを保護する。他の既知の標準およびプロトコルは、Pretty Good Privacy(登録商標)(PGP)、OpenPGP、および技術的に既知の他のものなどのように、安全なメッセージ通信を容易にするために利用され得る。

0056

S/MIMEのような安全なメッセージングプロトコルは、守秘性確保および防護を提供するために、および、公開鍵インフラストラクチャ(PKI)上で、認証および認可を提供する情報を通信するために、公開鍵および秘密暗号鍵に依存している。公開鍵/秘密鍵のペアのうちの秘密鍵を使用して暗号化されたデータは、そのペアのうちの対応する公開鍵を使用することでのみ解読され得、その逆もまた然りである。秘密鍵情報は、決して公開されないが、公開鍵情報は共有される。

0057

例えば、送信者がメッセージを暗号化された形式において受信者に送りたい場合、受信者の公開鍵は、メッセージを暗号化するために利用され、次いで、受信者の秘密鍵を使用することによってのみ解読され得る。代替的に、一部のエンコード技術において、一度限りのセッション鍵は、通常、対称暗号化技術を用いて(例えば、Triple DES)、メッセージの本体を暗号化するために作られ、利用される。セッション鍵は、次いで、受信者の公開鍵を使用することで暗号化され(例えば、RSAのような公開鍵暗号アルゴリズムを用いて)、次いで、受信者の秘密鍵を使用することによってのみ、解読され得る。解読されたセッション鍵は、メッセージの本体を解読するために使用され得る。メッセージのヘッダは、メッセージを解読するために使用されなければならない特定の解読スキームを特定するために利用され得る。公開鍵暗号化に基づいた他の暗号化技術は、異なる実行において利用され得る。しかしながら、これらの各場合において、受信者の秘密鍵のみが、そのメッセージの解読を容易にするために利用され得、この方法において、メッセージの守秘性確保が維持され得る。

0058

さらなる実施例として、送信者が、デジタル署名を利用するメッセージに署名し得る。デジタル署名は、送信者の秘密鍵を使用することで暗号化されるメッセージのダイジェスト(例えば、メッセージのハッシュなど)であり、送信されるメッセージへ添付され得る。受信された場合にメッセージのデジタル署名を確証するために、受信者は、受信されたメッセージのダイジェストを得るための(例えば、同じ標準ハッシュアルゴリズムを使って)、送信者と同じ技術を使用する。受信者もまた、受信されたメッセージのためのダイジェストと一致するものを得るために、デジタル署名を解読するための送信者の公開鍵を使用する。受信されたメッセージのダイジェストが一致しない場合、メッセージのコンテンツが運ばれる間に変化されたか、および/または、メッセージが、公開鍵が確証のために使用された送信者から来たものではなかったかのどちらかであることを示す。デジタル署名アルゴリズムは、送信者の秘密鍵の知識を有する者のみが、受信者が送信者の公開鍵を使用することで正しくデコードする署名をエンコードすることが可能となるべきであるようにデザインされている。それゆえ、この方法において、デジタル署名を確証することによって、送信者の認証およびメッセージ防護が維持され得る。

0059

エンコードされたメッセージは、暗号化され、署名され、または、暗号化および署名の両方をされ得る。これらの動作において使用される公開鍵の真正性は、証明書を使用することで、確証される。証明書は、認証局(CA)によって発行されたデジタル文書である。証明書は、ユーザおよびユーザの公開鍵との間の関連を認証するために利用され、主として、ユーザの公開鍵の真正性における信用の水準を提供する。証明書は、通常、容認された標準(例えば、X.509)にしたがってフォーマットされた証明書のコンテンツを有し、証明書所持者についての情報を含む。

0060

図5において、証明書チェーン300の実施例が示される。「John Smith」へ発行された証明書310は、個々人に発行された証明書の実施例であり、エンドエンティティ証明書と呼ばれ得る。エンドエンティティ証明書310は、通常、証明書保持者312(例えば、本実施例におけるJohn Smith)および証明書314の発行者を識別し、発行者316および証明書保持者の公開鍵318のデジタル署名を含む。証明書310はまた、通常、他の情報および、証明書所持者を識別する属性(例えば、eメールメッセージ、組織名、組織単位名、位置など)を含む。個人が受信者に送られるメッセージを作成する場合、メッセージとともにその個人の証明書300を含むことは習慣的である。

0061

信用される公開鍵にとって、それを発行する組織が信用されなければならない。信用されたCAとユーザの公開鍵との間の関係は、証明書チェーンとも呼ばれる一連の関連された証明書によって示されることができる。

0062

例えば、図5に示された本実施例の証明書チェーン300において、John Smithによって送信を意図されたメッセージの受信者は、受信されるメッセージに添付された証明書310の信用状態を確証することを望み得る。例えば、受信者のコンピュータ装置(例えば、図4のコンピュータ262a)上の証明書310の信用状態を確証するためには、発行者ABCの証明書320が得られ、証明書310が発行者ABCによって署名されたことを確証するために使用され得る。証明書320は既に、コンピュータ装置上の証明書記憶装置において記憶され得、または、証明書ソース(例えば、図4LDAPサーバ284、または、一部の他の公開または秘密LDAPサーバなど)から引き出される必要があり得る。証明書320が既に受信者のコンピュータ装置に記憶され、証明書が受信者によって信用されたと指示があった場合、証明書310は、それが記憶され、信用された証明書へチェーンされるゆえに、信用されたと考えられる。

0063

しかしながら、図5における本実施例において、証明書330はまた、証明書310の信用状態を確証することが要求される。証明書330は、自署名であり、および、ルート証明書と呼ばれる。したがって、証明書320は、証明書チェーン300における「中間証明書」と呼ばれ得る。ルート証明書へのチェーンが特定およびエンティティ証明書のために決定され得ることを想定し、ルート証明書への任意の所定の証明書チェーンは、ゼロ、一つ、または複数の中間証明書を含み得る。証明書330は、信用されたソース(例えば、VerisignまたはEntrustのようなより大きな認証局から)によって発行されたルート証明書であり、証明書310は、それが信用された証明書へチェーンするゆえに、信用されると考えられる。その意味は、メッセージの送信者および受信者の両方が、ルート証明書330のソースを信用するということである。証明書が信用された証明書へチェーンされ得ない場合、その証明書は、「信用されない」と考えられ得る。

0064

証明書サーバは、証明書および、無効にされた証明書を識別するリストについての情報を記憶する。これらの証明書サーバは、証明書を得るために、ならびに、証明書の真正性および無効状態を確証するために、アクセスされ得る。例えば、Lightweight Directory Access Protocol(LDAP)サーバは、証明書を得るために使用され得るし、Online Certificate Status Protocol(OCSP)サーバは、証明書の無効状態を確証するために使用され得る。

0065

標準のeメールセキュリティプロトコルは、通常、モバイル型ではないコンピュータ装置(例えば、図4のコンピュータ262a、262b、遠隔のデスクトップ装置など)との間の安全なメッセージ伝送を容易にする。図4を再び参照し、送信者から受信された署名されたメッセージがモバイル装置100から読まれ得、暗号化されたメッセージがそれらの送信者に送信され得るために、モバイル装置100は、証明書および他の個人の関連された公開鍵を記憶するために適応される。ユーザのコンピュータ262a上に記憶された証明書は、例えば、通常、コンピュータ262aからモバイル装置100へ、クレイドル264を介して、ダウンロードされる。

0066

コンピュータ262a上に記憶され、および、モバイル装置100へダウンロードされた証明書は、個人に関連された証明書に限定されないが、例えば、CAで発行された証明書もまた含み得る。コンピュータ262aおよび/またはモバイル装置100において記憶された証明書はまた、ユーザによって、「信用された」と明示的に示され得る。したがって、証明書が、ユーザまたはモバイル装置100によって受信された場合、証明書と、モバイル装置100上に記憶され、信用されたと示されるもの、または、そうでなければ、信用された証明書へチェーンされることが決定されたものとを一致させることによって、モバイル装置100上で確証され得る。

0067

モバイル装置100はまた、モバイル装置100のユーザが、モバイル装置100にて作成された送信されるメッセージに署名し、および、ユーザの公開鍵を用いて暗号化され、ユーザに送信されたメッセージを解読するように、ユーザに関連された公開鍵/秘密鍵のペアのうちの秘密鍵を記憶するために適応され得る。秘密鍵は、例えば、ユーザのコンピュータ262aから、クレイドル264を介して、モバイル装置100へダウンロードされ得る。秘密鍵は、ユーザがメッセージにアクセスするための一つの識別および一つの方法を共有し得るように、コンピュータ262aとモバイル装置100との間において、好ましく交換される。

0068

ユーザコンピュータ262a、262bは、262a、262bおよび/またはモバイル装置(例えば、モバイル装置100)上でのストレージのために、多くのソースから証明書を得ることが出来る。これらの証明書ソースは、秘密(例えば、組織内で使用のために専念される)または公開であり得、局地的または遠隔的に存在し得、例えば、組織のプライベートネットワーク内から、またはインターネットを介して、アクセスすることが可能であり得る。図4において示された本実施例において、組織に関連された複数のPKIサーバ280は、LAN250に存在する。PKIサーバ280は、発行する証明書のためのCAサーバ282、証明書を検索し、ダウンロードするために使用されるLDAPサーバ284、証明書の無効状態を確証するために使用されるOCSPサーバ286を含む。

0069

証明書は、例えば、クレイドル264を介してモバイル装置100へダウンロードされるために、ユーザのコンピュータ262aによってLDAPサーバ284から引き出され得る。しかしながら、異なる実施形態において、LDAPサーバ284は、モバイル装置100によって直接に(例えば、この文脈においては、「放送で(over air)」)アクセスされ得、モバイル装置100は、モバイルデータサーバ288を介して、個々の証明書を検索し得、および引き出し得る。同様に、モバイルデータサーバ288は、OCSPサーバ286を直接クエリすることをモバイル装置100に許可するために、適応され得、証明書の無効状態を確証し得る。

0070

異なる実施形態において、選択されたPKIサーバ280のみが、モバイル装置にアクセス可能(例えば、証明書の無効状態をモバイル装置100から照合されることを許可する一方で、証明書に、ユーザのコンピュータ262a、262bからのみダウンロードさせることを許可する)とされ得る。

0071

異なる実施形態において、PKIサーバ280は、特定のユーザ(IT管理者によって特定されるように、可能な場合、例えば、ITポリシーにしたがって)に登録されたモバイル装置のみにアクセス可能にされ得る。

0072

証明書の他のソース(図には示されていない)は、例えば、Windows(登録商標)、LAN250上または外の他の安全な証明書、および、スマートカード(smart card)などを含み得る。

0073

ここで図6を参照すると、メッセージサーバ(たとえば図4のメッセージサーバ268)によって受信され得る、暗号化されたメッセージの一例の構成要素を図示するブロック図が、全体で350として示されている。暗号化されたメッセージ350は一般的に、以下のうち1つ以上を含む。ヘッダ部分352、暗号化された本文部分354、随意的に1つ以上の暗号化された添付物、1つ以上の暗号化されたセッション鍵358、そして署名および署名に関連する情報360である。たとえば、ヘッダ部分352は一般的に、”To”、”From”、および”CC”等のアドレス情報を含み、また、たとえばメッセージ長指示子および送信者の暗号、署名スキーム識別子などを含んでもよい。実際のメッセージの内容は、通常メッセージ本文またはデータ部分354と、場合によっては1つ以上の添付物356とを含み、これは送信者の使用するセッション鍵によって暗号化され得る。セッション鍵が用いられた場合、一般的には、セッション鍵は意図された受取人に対して、各自のための公開鍵を用いて暗号化されており、メッセージ中の358に含まれる。メッセージが署名されたものであれば、署名および署名に関連する情報も含まれる。これには、たとえば送信者の証明書が含まれる。

0074

図6中に示したような、暗号化されたメッセージのフォーマットは、例示のみによって与えられるものとする。また、他のフォーマットにおいても暗号化されたメッセージが存在し得ることは、当業者であれば理解できよう。たとえば、用いられた特定のメッセージスキームに従って、暗号化されたメッセージの構成要素は図6に示されるものとは異なる順序で現れることもあり、暗号化されたメッセージは、構成要素がより少ないか、さらなる構成要素を含むか、または異なる構成要素を含むことが可能であり、これは暗号化されたメッセージが暗号化されているか、署名されているか、またはその両方かどうかによる。

0075

本発明の実施形態は、概して、署名の認証作業に利用したある種の情報を再使用のために格納することによって、証明書上のディジタル署名をさらに効率的に認証できるようにするシステムおよび方法に向けられたものである。証明書のチェーン(図5の例において論じる)を構築する際、証明書上のディジタル署名が認証されていることが必要であることが多い。多数の証明書がユーザのコンピューティング装置上で処理される場合、同一のディジタル署名は2つ以上の認証を受けなければならない。このことは、特に、クロス証明書を含む証明書チェーンが形成されている場合に有効となり得る。クロス証明書については、図7Bを参照して以下でさらに詳細に論じる。

0076

まず図7Aを参照すると、2例の証明書チェーンのブロック図が示されている。2例の証明書チェーンは、全体で400aおよび400bとして図示されている。証明書チェーン400aおよび400bが例として挙げられているということは、当業者であれば理解できよう。詳細には、証明書チェーンは図示した例の中に描かれているものよりも少数あるいは多数の証明書を含み得る。

0077

多数の組織が、独自の組織内の個人に対して厳密に証明書を発行するCAを設けている。個々の組織内の個人に対して発行されるエンドエンティティ証明書は、その組織と提携している1つのCAによって発行される必要はない。エンドエンティティ証明書は、ルートCAを頭とする、組織用のCA階層内の、従属する、または中間の複数のCAのうちの1つによって発行されることが多い。このルートCAは自署されたルート証明書を発行することができ、これは「トラストアンカー」、つまり組織内で発行された証明書を確証するための開始点として用いられる。

0078

証明書チェーン400aは、組織「ABC」内の1個人「ユーザ1」に対して発行された証明書402aを確証するために形成された1例の証明書チェーンを説明する。証明書402aは、組織のルートCAによって中間CAへ発行された中間証明書406aを介し、自署ルート証明書404aと連結する。自署ルート証明書404aは組織のルートCAによって発行され、なおかつユーザ1によって信用されている。組織ABC内で発行された証明書は、たとえば、組織が管理するLDAPサーバ(たとえば図4のLDAPサーバ284)から検索したり引き出したりすることができる。

0079

同様に、証明書チェーン400bは、別の組織「XYZ」内の1個人「ユーザ2」に対して発行された証明書402bを確証するために形成された1例の証明書のチェーンを説明する。証明書402bは、中間証明書406bを介し、自署ルート証明書404bと連結する。自署ルート証明書404bは組織XYZのルートCAによって発行され、なおかつユーザ2によって信用されている。組織XYZ内で発行された証明書は、たとえば、組織XYZが管理するLDAPサーバから検索したり引き出したりすることができる。

0080

組織ABCのユーザ1が組織XYZのユーザ2から暗号化されたメッセージを受け取った場合という状況例を考慮されたい。ユーザ2が自分の証明書402bをメッセージに添付していても、ユーザ1にはその証明書のみを用いてユーザ2の証明書402bの信用状態を確証することは不可能であろう。(まだ、ユーザ1はユーザ2の証明書402bを格納し信用されるものとしてマークしていないものと仮定する。)ユーザ1が組織XYZからの証明書を信用しない場合、この証明書は信用されている証明書と連結しないため、ユーザ2の証明書402bは確証され得ない。

0081

異なる組織のユーザ間での安全なコミュニケーションを可能にするためには、証明書が組織間で使用でき、信用できることが望ましい。クロス証明書として知られる認証方法は、一方の組織のCAが他方の組織のCAを証明いしている場合に、2つの組織間で実行できる。

0082

クロス証明書という用語は、広く2つの処理について言うときに使用され得る。第1の処理は、一般には実行頻度が比較的低く、クロス証明書と呼ばれる証明書の中に一方のCAが他方のCAの公開鍵を署名することを通じて2つのCA間(たとえば組織間または同一組織内)に信頼関係を確立することに関連する。第2の処理は、一般には実行頻度が比較的高く、このようなクロス証明書を少なくとも1つ含む証明書チェーンを構築することを通じてユーザ証明書を確証することを含む。

0083

ここで図7Bを参照すると、2例の証明書チェーンを連結するクロス証明書を図示したブロック図が示されている。組織XYZのルートCAが組織ABCのルートCAに対して発行したクロス証明書410を本例において示す。同様に、組織ABCのルートCAが組織XYZのルートCAに対して発行したクロス証明書412を示す。

0084

図7Bの例は、2つのCA間における相互のクロス証明を説明する。ただし、様々な実行において他のクロス証明の方法が可能である。たとえば、クロス証明書は1つの組織内の従属するCAによって別の組織のルートCAに対して発行されてもよい。さらなる例として、第1の組織に対して第2の組織によってクロス証明書を発行し返さなくても、第1の組織のCAが第2の組織のCAに対してクロス証明書を発行してよい。

0085

さらに、たとえば組織のIT方針規定によって、組織間の証明書の使用が制限されることがある。たとえば、他の組織からの証明書は暗号化されたeメールメッセージを処理する目的でのみ信用される、というふうにある組織のIT方針が規定していることがある。また、一方の発行CAがクロス証明書を取消し、他の組織との信頼関係を終結させることもできる。このことによって、異なる組織の個人間における安全なeメールコミュニケーションをさらに効率的に管理することが可能になる。

0086

クロス証明書によって信頼関係を確立した組織の個人間における安全なコミュニケーションが可能である。組織ABCのユーザ1が、暗号化されたメッセージを組織XYZのユーザ2から受け取った場合の状況を再度考慮されたい。ユーザ1は、ユーザ2の証明書402bのチェーン内にある証明書を引出し、ユーザ1の組織のルートCAによって発行され、なおかつユーザ1の信用する証明書404aを探し出すことによって、ユーザ2の証明書402bの信用状態を確証することができるであろう。厳密に言えば、図7Bの例に示すように、チェーンにはABCのルート証明書404aと、クロス証明書412と、XYZのルート証明書404bと、中間証明書406bと、ユーザ2の証明書402bとが含まれる。

0087

ユーザ1がユーザ2の証明書402bの信用状態を確証するには、ユーザ1は証明書402bを入手しなければならない。この証明書は、ユーザ2からユーザ1へのメッセージに関連するのが慣習である。ただし、証明書402bが与えられておらず、また、ユーザ1のコンピューティングディバイスにも特に格納されていない場合には、たとえば組織XYZの管理するLDAPまたは他の証明書サーバからそれを引出さなければならない。さらに、証明書402bの信用状態を確証するために、チェーン内に残っている各証明書も引出さなければならない。チェーン内にあるそれ以外の証明書、本例においてはルート証明書およびクロス証明書を含むが、それらをABCのLDAPサーバ、XYZのLDAPサーバ、またはユーザ1にアクセス可能なその他のLDAPサーバから引出す必要があろう。

0088

図5図7A、および図7Bを参照して論じたように、証明書チェーンを構築する際には、証明書上に発行CAのディジタル署名が必要であることが多い。証明書を確証する際には、たとえば証明書の日付が有効であることの確証、または、組織がIT方針に従って設け得るその他の基準が有効であることの確証等、他のタスクが実行されることもある。

0089

証明書上のディジタル署名の確証は、発行CAの公開鍵を必要とするプロセスである。CAが証明書にディジタル署名をする場合、たとえば証明書の所持者の氏名や公開鍵を含む証明書情報、またはハッシュアルゴリズムの実行を介して得たこのような情報のハッシュは、一般的にそのCAの秘密鍵を用いて暗号化される。発行CAが証明書に署名するために用いるアルゴリズムは、一般的に証明書中で識別される。したがって、公開鍵を用いて暗号化された情報またはハッシュを復号し、結果を予測される証明書情報またはそのハッシュとそれぞれ比較することによって、ユーザが署名した、メッセージのディジタル署名を確証する際に用いたのと類似の方法で証明書上のCAのディジタル署名を確証することができる。それらの一致に成功すれば、証明書の所持者の公開鍵を証明書の所持者と正当に結びつけてよいということをCAが証明したということであり、CAが信用されていれば証明書の所持者の公開鍵は信用できるという意味である。

0090

証明書の署名の確証は、特に、モバイル装置等の小型のデバイス上で実行される場合には、時間を要し、コストもかかるプロセスとなる可能性がある(コンピューティングリソースの使用の点において)。本発明の実施形態は、概して、署名の確証処理に用いられたある種の情報を再使用のために格納することによって、証明書上のディジタル署名をより効率的に確証することができるようなシステムおよび方法に向けられている。

0091

少なくとも1つの実施形態において、独自の証明書を発行したCAの公開鍵が1つ以上、証明書と結び付けられ、キャッシュまたは格納される。上記したように、CAによって署名された証明書上のディジタル署名を確証しようと試みる際には、そのCAの公開鍵が必要である。ただし、同一のCAに属すると思われる複数の証明書(それぞれ、添付の公開鍵をもつ)が存在し得る。この状況は、たとえば、何通かの証明書が同一または類似のサブジェクトデータ(すなわち、証明書の所持者を識別する証明書データである)を有する場合、またはCAが複数の公開鍵(そのうちのいくつかはもはや有効でない)を発行している場合に起こり得る。したがって、個々の公開鍵のいずれが個々の証明書を確証するのに有効に使用されたか、追跡することは有益となり得る。

0092

図8を参照すると、本発明の一実施形態中の、証明書上のディジタル署名を確証する方法におけるステップを図示するフローチャートが示されている。

0093

本発明の1つの実施形態において、方法のステップのうち少なくともいくつかは、モバイル装置上で実行し常駐する証明書確証アプリケーションによって実行される。様々な実施形態において、証明書確証アプリケーションはモバイル装置以外のコンピューティング装置上で実行し常駐することができる。さらに、証明書確証アプリケーションは、独立型のアプリケーションである必要はなく、証明書確証アプリケーションの機能性は、モバイルまたは他のコンピューティング装置上で実行し常駐する1つ以上のアプリケーション内でも実行される。

0094

一般的に、方法420において、与えられた公開鍵が証明書上のディジタル署名の確証に有効に使用される場合、その公開鍵の複製がキャッシュに格納されるか、そうでなければ記憶装置内に格納される。たとえば公開鍵は、証明書に関連する証明書データと共に、または、有効な証明書確証に使用された公開鍵を格納するのに適した独立型の記憶装置(たとえばlookup table)に格納できる。次に同一の証明書上のディジタル署名を確証する試行が為された場合には、少なくとも公開鍵を用いていくつかのデータを復号する必要のある高価な署名確証処理を即座に実行するよりも、代わりに再度ディジタル署名を確証するのに使用されるであろう公開鍵を、格納されている公開鍵と初めに比較するのがよい。これらの公開鍵が一致した場合、用いられる公開鍵が署名確証処理において以前に有効に使用された鍵と一致するため、確証は成功だと考えられる。
同一のディジタル署名に対しては、実際の署名確証処理を再度実行する必要はないと考えられる。したがって、その後の署名確証処理の少なくともいくつかを、より効率的な同等の処理に置き換えることができる(たとえばバイアレイ)。以下に、方法420のステップをさらに詳細に説明する。

0095

ステップ430において、証明書上のディジタル署名の確証が開始される(たとえば証明書確証アプリケーションによって)。たとえばユーザが受け取った特定の証明書を確証するために証明書チェーンを構築する際に、証明書上のディジタル署名の確証を実行することができる(図5を参照して論じたように、たとえば受信したメッセージに添付された証明書の信用状態を確証するため)。本実施形態において、確証される証明書上のディジタル署名は、それぞれの証明書を発行した認証局のものである。前述したように、署名確証処理において、証明書を発行した認証局の公開鍵が必要である。モバイルまたは他のコンピューティング装置上の証明書格納領域に、認証局の証明書および公開鍵が既に格納されていなければ、このステップにおいてそれらを引出すことが必要となり得る。

0096

与えられた公開鍵に対しては、ステップ440において、この公開鍵を用いて署名確証処理を実行するのに先行して、承認されるべき証明書上のディジタル署名が以前にこの公開鍵を用いて首尾よく確証されたことがあるかどうかに関する決定がなされる。上述したように、これは、以前に用いられ、承認されるべき証明書上の署名を有効に確証し、格納されている証明書発行者の公開鍵(ステップ470においてキャッシュまたは他の記憶装置内に格納された公開鍵として、1つの鍵が存在する場合)を、ディジタル署名を確証するのに用いようとしている公開鍵と比較することによって実行することができ、一致があるかどうかを決定する。本実施形態においては、成功した確証の試行に用いられた公開鍵のみがキャッシュまたは他の記憶装置内に格納されるため、一致が決定された場合、承認されるべき証明書上のディジタル署名は以前に首尾よく確証されたことのある鍵だということになるであろう。

0097

承認されるべき証明書上のディジタル署名が、与えられた公開鍵を用いて首尾よく確証されたことが以前にない場合、ステップ450において、ディジタル署名は、この公開鍵を用いて既知の方法で確証される。ステップ460において決定されるように、この公開鍵を用いて首尾よく署名が確証された場合、この成功した確証において用いられた公開鍵は、本実施形態に従って、将来ステップ470で使用されるためにキャッシュまたは他の記憶装置内に格納される。たとえば、ステップ470において格納された公開鍵は、承認されるべき証明書に関連したデータと共に格納されるか、公開鍵用の中枢記憶装置内(たとえばlookup table内)に証明書によって索引をつけて(たとえば公開鍵と共に、発行者の名前および証明書のシリアルナンバーを格納することによって)格納されてもよい。

0098

他方で、ステップ440において決定されるように、承認されるべき証明書上のディジタル署名が与えられた公開鍵を用いて以前に首尾よく確証されたことがあれば、ステップ480において、確証は成功するという指示が与えられる。これは、少なくともいくつかのデータを公開鍵を用いて復号する必要のある現在の署名確証処理を実行する代わりに行われ、それによって署名確証のプロセスをより効率的にする。これは、バッテリの電力を節約し、また、たとえば特にモバイル装置等の小型のデバイスに対するユーザの能力を高めるのに役立つ。

0099

方法420のステップは、追加の公開鍵に対して繰り返されてもよい。

0100

図8Bを参照すると、本発明の別の実施形態における、ディジタル署名の確証方法のステップを図示するフローチャートが、全体で420bとして示されている。

0101

成功した署名確証に用いられた公開鍵のみがキャッシュまたは他の記憶装置に格納される方法420とは対照的に、方法420bにおいては、いかなる署名確証の試行(成功したものも成功しなかったものも)に用いられた公開鍵も、確証の試行の結果と共にキャッシュまたは他の記憶装置内に格納されるが、そのことを除いて方法420bは方法420と類似している。

0102

概して、方法420bにおいては、与えられた公開鍵が証明書上のディジタル署名の確証に用いられる際、処理結果と共に、その公開鍵の複製がキャッシュに格納されるか、そうでなければ記憶装置内に格納される。たとえば、公開鍵およびそれに伴う結果は、証明書に関連する証明書情報と共に格納されるか、独立型の記憶装置(たとえばlookup table)内に格納されることができる。与えられた鍵を用いて、次に同一の証明書上のディジタル署名を確証する試行が為される場合、少なくともいくつかのデータをその鍵を用いて復号する必要のある高価な署名確証処理を実行するよりも、代わりに、ディジタル署名を再度確証するために使用されるであろう公開鍵を格納された公開鍵と初めに比較するのがよい。与えられた公開鍵が格納されている公開鍵と一致した場合、格納されている公開鍵と関連して格納されている結果に従って、この確証の試行は成功しているまたは成功していないと考えられる。格納されている結果が、その公開鍵を用いた以前の確証の試行は成功したことを示す場合、この確証の試行は成功すると考えられるであろう。格納されている結果が、その公開鍵を用いた以前の確証の試行は成功しなかったことを示す場合、この確証の試行は失敗すると考えられるであろう。したがって、そうでなければ公開鍵を用いていくつかのデータを復号する必要があるであろう次の署名確証処理を、より効率的な同等の処理に置き換えることができる(たとえばバイトアレイ)。

0103

方法420を参照して説明したように、ステップ430において、証明書上のディジタル署名の確証が開始される(たとえば証明書確証アプリケーションによって)。

0104

与えられた公開鍵に対しては、ステップ440bにおいて、この公開鍵を用いて署名確証処理を実行するのに先行して、承認されるべき証明書上のディジタル署名が以前にこの公開鍵を用いて首尾よく確証されたことがあるかどうかに関する決定がなされる。上述したように、これは、以前に用いられ、承認されるべき証明書上の署名を有効に確証し、格納されている証明書発行者の公開鍵(ステップ470においてキャッシュまたは他の記憶装置内に格納された公開鍵として、1つの鍵が存在する場合)を、ディジタル署名を確証するのに用いようとしている公開鍵と比較することによって実行することができ、一致があるかどうかを決定する。一致が決定された場合、承認されるべき証明書上のディジタル署名の確証は以前に行われたことがあるということになるであろう。

0105

承認されるべき証明書上のディジタル署名を確証する試行が以前になされていない場合、方法420を参照して同様に説明したとおり、署名確証処理はステップ450において既知の方法で実行される。確証に用いられた公開鍵および確証の試行結果(すなわち、ディジタル署名が確証に成功しているか、そうでないかを示すもの)は、本実施形態に従って、キャッシュまたは他の記憶装置内に格納される。たとえば、ステップ470bにおいて格納された公開鍵および結果は、承認されるべき証明書に関連する情報と共に格納されるか、証明書によって索引をつけて(たとえば公開鍵と共に証明書のシリアルナンバーを格納することによって)公開鍵用の中枢記憶装置内(たとえばlookup table内)に格納されてもよい。

0106

ステップ440bにおいて決定されるように、承認されるべき証明書上のディジタル署名が与えられた公開鍵を用いて以前に首尾よく確証されたことがあれば、ステップ472において、以前の確証の試行結果がこの鍵と共にキャッシュまたは他の記憶装置から引出される。そして、格納されている結果が、この鍵を用いた以前の確証の試行は成功したことを示すか、そうでないかについての決定がなされる。成功したことを示した場合、ステップ480において、この確証は成功するという指示が与えられる。また、そうでなければ、ステップ490において、この確証は成功しないという指示が与えられる。

0107

方法420bのステップは、追加の公開鍵に対して繰り返されてもよい。

0108

この公開鍵を用いた確証が失敗するかどうかを決定するために、少なくとも公開鍵を用いていくつかのデータを復号する必要のある署名確証処理を実行する代わりに以前の確証の試行結果が用いられ、それによって署名確証処理をより効率的なものにする。特に、ユーザが、同一の無効な公開鍵を用いて証明書上のディジタル署名の確証処理を何度も要求した場合、少なくとも公開鍵を用いていくつかのデータを復号する必要があり高価な現在の署名確証処理は、一度だけ実行する必要があるが、次の試行は、比較的効率的な同等の処理(たとえばバイトアレイ)を実行した後、即座に失敗するであろう。このことは、バッテリの電力を節約し、また、たとえば特にモバイル装置等の小型のデバイスに対するユーザの能力を高めるのにさらに役立ち得る。

0109

所望であれば、様々な実施形態において、上記した公開鍵および確証の試行結果に加え他の情報もキャッシュまたは他の記憶装置内に格納され得ることは当業者であれば理解できよう。

0110

様々な実施形態において、キャッシュまたは他の記憶装置に格納されている、公開鍵および他の情報(たとえば確証の試行結果)は、限られた有効期間の、公開鍵を比較する際の使用のためにのみ認められている。その後には、それらは古いと考えられ、キャッシュまたは他の記憶装置から削除しなければならない。これはセキュリティの目的で行われるので、少なくとも公開鍵を用いていくつかのデータを復号する必要のある現在の署名確証処理は、何度も再行されなければならない。この有効期間は、たとえばIT方針に従って設定される。同様に、本発明の別の実施形態において、キャッシュまたは他の記憶装置に格納された、いくつかの、または全ての公開鍵および他の情報は、たとえばユーザまたはアドミニストレータによって手動で命令されることもあるが、古いとみなされるか削除され得るため、署名確証処理が再実行されなければならない。さらに高度なセキュリティのために、たとえば、格納した後に公開鍵(たとえば以前に首尾よく証明書の署名を確証した公開鍵)が無効になっていないことを確証するための確証処理も実行してもよい。

0111

本発明の実施形態における、証明書上のディジタル署名を確証する方法のステップは、伝送型媒体を含めたコンピュータ可読媒体に格納された、実行可能なソフトウェア命令として提供されてもよい。

0112

本発明を多数の実施形態に関して説明したが、ここに付属する請求項において定義される本発明の範囲から逸脱することなく、他の変更および修正が行われてもよいことは、当業者であれば理解できよう。

図面の簡単な説明

0113

1つの例の実行におけるモバイル装置のブロック図である。
図1のモバイル装置の、コミュニケーションサブシステムの構成要素のブロック図である。
無線ネットワークのノードのブロック図である。
1つの例の構成における、ホストシステムの構成要素を図示するブロック図である。
証明書チェーンの例を示すブロック図である。
暗号化されたメッセージの例の構成要素を示すブロック図である。
証明書チェーンの2つの例を示すブロック図である。
図7Aの証明書チェーンと連結するクロス証明書を示すブロック図である。
本発明の一実施形態における、証明書上のディジタル署名の確証方法のステップを図示するフローチャートである。
本発明の別の実施形態における、証明書上のディジタル署名の確証方法のステップを図示するフローチャートである。

符号の説明

0114

100モバイル装置
102マイクロプロセッサ
106 RAM
108フラッシュメモリ
104通信サブシステム
150送信機
151受信機
160 デジタル信号プロセッサ

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ