(57)【要約】一つ以上のメッセージを交換するために、第１のシステムによって実行される、該第１のシステムと第２のシステムとの間における双方向通信経路を確立する方法が記載される。第１の公開鍵および第１の秘密鍵を有する第１の鍵の対を生成され、第２の公開鍵および第２の秘密鍵を有する第２の鍵の対を生成される。第２の公開鍵は、第１のシステムおよび第２のシステムに対して既知である共有された機密に基づいて生成される。第２の公開鍵および第１の公開鍵は第２のシステムに送信される。第２のシステムによって生成される第３の公開鍵および第４の公開鍵は受信され、第４の公開鍵は共有された機密に基づいて生成される。第１の秘密鍵、該第２の秘密鍵、該第３の公開鍵、および該第４の公開鍵に基づいてマスター鍵は計算され、マスター鍵は一つ以上のメッセージの暗号化において用いられるように構成されている。
2007531422.tif 000002
【特許請求の範囲】
【請求項１】
一つ以上のメッセージを交換するために、第１のシステム（３２）によって実行される、該第１のシステム（３２）と第２のシステム（２２）との間における安全な双方向通信経路（２４、３６）を確立する方法であって、
第１の公開鍵および第１の秘密鍵を有する第１の鍵の対を生成することと、
第２の公開鍵および第２の秘密鍵を有する第２の鍵の対を生成することであって、該第２の公開鍵が、該第１のシステム（３２）および該第２のシステム（２２）に既知である共有された機密に基づいて生成される、ことと、
該第２の公開鍵および該第１の公開鍵を該第２のシステムに送信することと、
該第２のシステム（２２）によって生成される第３の公開鍵および第４の公開鍵を受信することであって、該第４の公開鍵は該共有された機密に基づいて生成される、ことと、
該第１の秘密鍵、該第２の秘密鍵、該第３の公開鍵、および該第４の公開鍵に基づいてマスター鍵を計算することであって、該マスター鍵は一つ以上のメッセージの暗号化において用いられるように構成されている、ことと
を包含する、方法。
【請求項２】
試験文字列を生成することと、
第１の試験文字列を前記第２のシステム（２２）に送信することと、
該第２のシステム（２２）によって生成される第２の試験文字列を受信することと、
該第２の試験文字列および前記マスター鍵を用いて、該第２のシステム（２２）を認証することと
をさらに包含する、請求項１に記載のシステム。
【請求項３】
前記第２のシステム（２２）によって生成される第２の試験文字列を受信するステップに先立ち、ＵＤＤＩ（Ｕｎｉｖｅｒｓａｌ  Ｄｅｓｃｒｉｐｔｉｏｎ，  Ｄｉｓｃｏｖｅｒｙ  ａｎｄ  Ｉｎｔｅｇｒａｔｉｏｎ）サービスエントリを有するデータペイロードを受信するステップをさらに包含する、請求項２に記載の方法。
【請求項４】
前記第１のシステムはワイヤレスモバイル装置（３２）である、請求項１に記載の方法。
【請求項５】
前記第２のシステムはサービスを提供するホストシステム（２２）である、請求項４に記載の方法。
【請求項６】
前記共有された機密は安全な帯域外チャンネル（３４）を介して通信される、請求項４に記載の方法。
【請求項７】
前記共有された機密は前記ホストシステム（２２）によって自動的に生成された個人識別番号（ＰＩＮ）である、請求項５に記載の方法。
【請求項８】
前記共有された機密は前記第１のシステム（３２）による要求に続いて、ウェブインターフェースを介して、前記第２のシステム（２２）から受信される、請求項６に記載の方法。
【請求項９】
前記一つ以上のメッセージの交換は、ｅメールメッセージ、ｈｔｔｐベースのＸＭＬメッセージ、またはｈｔｔｐベースのＷＭＬメッセージの交換を含む、請求項５に記載の方法。
【請求項１０】
前記ワイヤレスモバイル装置（３２）および前記ホストシステム（２２）は、ｅメールアドレスまたはＩＰアドレスを用いてアドレスされる、請求項５に記載の方法。
【請求項１１】
修正されたＳＰＥＫＥ（Ｓｉｍｐｌｅ  Ｐａｓｓｗｏｒｄ−ａｕｔｈｅｎｔｉｃａｔｅｄ  Ｅｘｐｏｎｅｎｔｉａｌ  Ｋｅｙ  Ｅｘｃｈａｎｇｅ）が前記マスター鍵を計算することにおいて用いられる、請求項５に記載の方法。
【請求項１２】
前記第１のシステムはサービスを提供するホストシステム（４６）であり、前記第２のシステムはモバイルワイヤレス装置（４８）である、請求項１に記載の方法。
【請求項１３】
前記マスター鍵を用いる一つ以上のメッセージを暗号化することをさらに包含する、請求項１に記載の方法。
【請求項１４】
請求項１３に記載の方法に従って暗号化されたメッセージを含むデジタル信号。
【請求項１５】
処理ユニットによって請求項１に記載の方法を実行するように適合される処理命令を含むコンピュータ可読キャリア。
【請求項１６】
一つ以上のメッセージを交換するために、第２のシステム（２２）に対して安全な双方向通信経路（２４、３６）を確立する第１のシステム（３２）であって、
第１の公開鍵および第１の秘密鍵を有する第１の鍵の対を生成する手段と、
第２の公開鍵および第２の秘密鍵を有する第２の鍵の対を生成する手段であって、該第２の公開鍵が、該第１のシステム（３２）および該第２のシステム（２２）に既知である共有された機密に基づいて生成される、手段と、
該第２の公開鍵および該第１の公開鍵を該第２のシステム（２２）に送信する手段と、
該第２のシステム（２２）によって生成される第３の公開鍵および第４の公開鍵を受信する手段であって、該第４の公開鍵は該共有された機密に基づいて生成される、手段と、
該第１の秘密鍵、該第２の秘密鍵、該第３の公開鍵、および該第４の公開鍵に基づいてマスター鍵を計算する手段であって、該マスター鍵は一つ以上のメッセージの暗号化において用いられるように構成されている、手段と
を備える、第１のシステム。
【請求項１７】
一つ以上のメッセージを交換するために、第２のシステム（２２）に対して安全な双方向通信経路（２４、３６）を確立する第１のシステム（３２）であって、
メモリと、
該メモリに結合される処理ユニットであって、該処理ユニットは、
第１の公開鍵および第１の秘密鍵を有する第１の鍵の対を生成するステップと、
第２の公開鍵および第２の秘密鍵を有する第２の鍵の対を生成するステップであって、該第２の公開鍵が、該第１のシステム（３２）および該第２のシステム（２２）に既知である共有された機密に基づいて生成される、ステップと、
該第２の公開鍵および該第１の公開鍵を該第２のシステム（２２）に送信するステップと、
該第２のシステム（２２）によって生成される第３の公開鍵および第４の公開鍵を受信するステップであって、該第４の公開鍵は該共有された機密に基づいて生成される、ステップと、
該第１の秘密鍵、該第２の秘密鍵、該第３の公開鍵、および該第４の公開鍵に基づいてマスター鍵を計算することであって、該マスター鍵は一つ以上のメッセージの暗号化において用いられるように構成されている、ステップと
を実行するように構成されている、処理ユニットと
を備える、第１のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、データを交換する二つのメッセージングシステム間の認証がとれ（ａｕｔｈｅｎｔｉｃ）、かつ安全な関係を確立する装置および方法に関する。より詳細には、本出願は、パスワードベースの認証方法を用いて、ワイヤレスハンドヘルド装置（「モバイル装置」）とメッセージセンターまたはホストシステムとの間の認証関係を確立する装置および方法を記載する。本明細書において記載される装置および方法は、陸上通信線環境およびワイヤレス環境に適用可能である。
【背景技術】
【０００２】
現在、コンピュータ産業において知られているいくつかの強力なパスワードベースの暗号化メカニズムが存在する。これらのインプリメンテーションの一部は、ＥＫＥ（Ｅｎｃｒｙｐｔｅｄ  Ｋｅｙ  Ｅｘｃｈａｎｇｅ）、ＰＤＭ（Ｐａｓｓｗｏｒｄ  Ｄｅｒｉｖｅｄ  Ｍｏｄｕｌｉ）、およびＳＰＥＫＥ（Ｓｉｍｐｌｅ  Ｐａｓｓｗｏｒｄ−ａｕｔｈｅｎｔｉｃａｔｅｄ  Ｅｘｐｏｎｅｎｔｉａｌ  Ｋｅｙ  Ｅｘｃｈａｎｇｅ）を含む。これらのメカニズムは、それらのインプリメンテーションに限定され、モバイル装置からの必要性に取り組んではいない。付け加えて、これらのメカニズムは、安全への侵害が生じた場合であっても、それまでに交換された全てのメッセージは安全なままであるような、完全なフォワード秘匿性をインプリメントする要求と取り組んでいない。過去のセッション鍵が漏洩されていない場合で、長期鍵が漏洩された場合であっても、プロトコルは完全なフォワード秘匿性を提供する。（非特許文献１を参照）。また、ブレイクバックワード（ｂｒｅａｋ−ｂａｃｋｗａｒｄ）保護として知られる完全なフォワード秘匿性は、それまでに安全に交換された全てのメッセージは、将来に生じる任意の事態にもかかわらず、安全なままであることを意味する。
【非特許文献１】Ｍｅｎｅｚｅｓら、Ｈａｎｄｂｏｏｋ  ｏｆ  Ａｐｐｌｉｅｄ  Ｃｒｙｐｔｏｇｒａｐｈｙ，１９９６，ｐ．４９６
【発明の開示】
【課題を解決するための手段】
【０００３】
ワイヤレスまたは有線の環境において、パスワードベースの暗号化通信システムが、完全なフォワード秘匿性を有して、記載される。それは、共有された機密を用いて生成される短期認証鍵の対と組み合わされる、生成された長期鍵の対を用いることを含み、完全なフォワード秘匿性のインプリメンテーションを可能にする。長期公開鍵は認証公開鍵と抱き合わせられ（ｐｉｇｇｙ−ｂａｃｋｅｄ）、長期鍵の認証のとれた交換を可能にする。これによって、共有された機密を所有している対応の者が、長期公開鍵を受け取り、それを使用することが可能となる。
【０００４】
一局面に従い、一つ以上のメッセージを交換するために、第１のシステムによって実行される、該第１のシステムと第２のシステムとの間における安全な双方向通信経路を確立する方法が記載される。本方法は、第１の公開鍵および第１の秘密鍵を有する第１の鍵の対を生成することと、第２の公開鍵および第２の秘密鍵を有する第２の鍵の対を生成することを含む。第２の公開鍵が、第１のシステムおよび第２のシステムに既知である共有された機密に基づいて生成される。本方法は、第２の公開鍵および第１の公開鍵を第２のシステムに送信することと、第２のシステムによって生成される第３の公開鍵および第４の公開鍵を受信することであって、第４の公開鍵は共有された機密に基づいて生成される、こととを含む。本方法はまた、第１の秘密鍵、第２の秘密鍵、第３の公開鍵、および第４の公開鍵に基づいてマスター鍵を計算することであって、マスター鍵は一つ以上のメッセージの暗号化において用いられるように構成されている、ことを含む。
【０００５】
別の局面に従い、システムは、メモリと、メモリに結合される処理ユニットであって、上記ステップを実行するように構成されている処理ユニットを備える。
【０００６】
別の局面に従い、コンピュータ可読キャリアは、処理ユニットに上記ステップを実行させるように適合される処理命令を含む。
【発明を実施するための最良の形態】
【０００７】
図１を参照して、固定システムとワイヤレスシステムとの間において、第１の例示的な通信システムのブロック図が示される。この概観図は、本発明が用いられるネットワーク環境を示す。その図は、本発明の例示的な実施形態を示し、ワイヤレスモバイル装置を含むネットワークトポロジに焦点を当てている。この図において、サービス２０および２２を提供するシステム、ならびに、サービス３０および３２を用いたシステムが存在する。サービスの提供（本明細書においては、サービスプロバイダとも呼ばれる）とサービスユーザとの間にて、一つ以上のネットワークおよび一つ以上の接続が存在し、二つのシステム間においてデータのフローを可能にする。
【０００８】
ここで図１を参照し、サービスの提供２０または２２はまた、サービスをユーザに提供する多くの可能なコンピュータであり得る。当業者にとって、一部の周知のサービスプロバイダは、インターネットサービスプロバイダ（ＩＳＰ）またはアプリケーションサービスプロバイダ（ＡＳＰ）オフィス内におけるインターネットに接続されたコンピュータであり得る。サービスの提供２０および２２はまた、銀行、株式仲買人、保険仲買人、または一部の他のサービス志向の企業など、民間企業または株式会社内にて実行されている一つ以上のコンピュータであり得る。サービスの提供２０または２２はまた、ＵＤＤＩ（Ｕｎｉｖｅｒｓａｌ  Ｄｅｓｃｒｉｐｔｉｏｎ，  Ｄｉｓｃｏｖｅｒｙ  ａｎｄ  Ｉｎｔｅｇｒａｔｉｏｎ）クラスタを構築する、ワールドワイドにて稼動するコンピュータのクラスタの一部として実行され得る。これらのサービスの提供２０および２２の全てにおける共通する要素は、これらのサービスの提供２０および２２がユーザとの安全なデータチャンネルを確立する必要があることである。ＵＤＤＩの場合において、安全な関係は、プライベートサービスリストを交換することが必要とされ得るか、または、ＵＤＤＩにサービスの提供を代用させることを可能にすることが必要とされ得る。
【０００９】
モバイル装置およびサービスホストは、様々に異なる方法においてアドレスされ得る。一部の実施形態において、それらは、ＩＰ（インターネットプロトコル）アドレスを用いてアドレスされ得る。他の実施形態において、ホストシステムは、ｅメールアドレスによってアドレスされ得る。さらに別の実施形態において、宛て先アドレスは、ホストシステム内のモバイル装置のユーザのｅメールアドレスであり得る。
【００１０】
当業者は、サービスのユーザ３０および３２が、モバイルハイパーテキスト転送プロトコル（ＨＴＴＰ）ブラウザ、モバイルワイヤレスアプリケーションプロトコル（ＷＡＰ）ブラウザ、メーカー独自（ｐｒｏｐｒｉｅｔａｒｙ）のＴＣＰ／ＩＰ（ｔｒａｎｓｍｉｓｓｉｏｎ  ｃｏｎｔｒｏｌ  ｐｒｏｔｏｃｏｌ／ｉｎｔｅｒｎｅｔ  ｐｒｏｔｏｃｏｌ）ベースのアプリケーションまたは一部のメーカー独自の企業の解決策であり得ることを理解する。この技術分野において、セル式電話および携帯情報端末（ＰＤＡ）などの、小さなワイヤレスモバイル装置への、例えば、新たなＪａｖａ（登録商標）２マイクロエディション（Ｊ２ＭＥ）ソルーションを含む、迅速に開発される新たな方法が存在する。Ｊ２ＭＥを使用する装置にとって、サービスの提供を介して、ソフトウェアを添付およびダウンロードするオプションは一般的になりつつある。同様に、サービスの提供２０および２２は、ＨＴＴＰウェブサーバソルーション、Ｊａｖａ（登録商標）エンタープライズソルーション、ワイヤレスマークアップ言語（ＷＭＬ）ベースのサービスの提供、または、特定目的のために作成された一部のメーカー独自のサービスソルーションであり得る。
【００１１】
本明細書において言及されるモバイルシステムおよびホストシステムはそれぞれ、一つ以上の個々のメモリ（例えば、処理命令を含む）、および一つ以上の個々の処理ユニット（例えば、従来知られている、特定用途向け集積回路（ＡＳＩＣ）およびフィールドプログラマブルゲートアレイ（ＦＰＧＡ）など）を含み得、その処理ユニットは、本明細書において記載されるアプローチを実行するように構成され得る（例えば、適切なソフトウェア／ファームウェアの命令を用いてプログラムされ、および／または、特殊化されたハードウェア回路を用いて製造される）ことは理解される。そのようなシステムのそれぞれはまた、従来から知られているような、任意の適切なインターフェースを含み得、それらは、個々の処理ユニットと関連して動作し得、他のシステムとの通信を容易にする。
【００１２】
通信経路におけるエンドポイントは、一つ以上のデータネットワークを介して結合され、データ、音声、映像、音楽、写真、またはデータ通信チャンネルを介して交換され得る任意の他のデジタルメディアの交換を可能にする。本例示において含まれる二つのメインのネットワークは、広域ネットワーク（ＷＡＮ）２６（最も一般的なものはインターネット）およびワイヤレスネットワーク２８である。ワイヤレスネットワーク２８は、ＧＳＭ／ＧＰＲＳネットワーク、ＣＤＭＡ／１ＸＲＴＴネットワーク、ＣＤＭＡ２０００ネットワーク、ＥＤＧＥまたはＵＭＴＳなどの第三世代ネットワーク、または、いずれ利用可能となる多くの他のパブリックワイヤレスネットワークであり得る。例示的なシステムにおいて、これらのネットワークは、ＩＳＤＮ、Ｔ１、Ｅｔｈｅｒｎｅｔ（登録商標）（陸上通信線および８０２．１１）、Ｆｒａｍｅ  Ｒｅｌａｙ、ＡＴＭ、ＡＤＳＬまたはホストサービス２２への一部の他の高速インターネット接続などの、リンク２４を用いて結合される。より多くのデータが交換されるにつれ、セキュリティは改良される必要があり、ハッカーや盗聴者に対してさらに危険のないようにされる必要があることは明らかである。本発明は、これらの既存のデータ通信経路とともに稼動し、高度なパスワードベースの認証を提供する。セキュリティのこのレベルは、任意の通信されたデータの受け取側が、正確に期待される実体であるというより大きな信頼を提供する。データ通信経路３６の一つの実施形態は、ホストシステムのサービスの提供２２とモバイル装置上のサービスのユーザ３２との間において示される。データ通信経路４０の別の実施形態は、ＵＤＤＩサービスの提供２０とモバイル装置３０上のサービスのユーザとの間において示される。
【００１３】
一実施形態において、ホストシステムサービスの提供２２は、モバイル装置３２のユーザとの帯域外通信３４（すなわち、任意の適切で安全なチャンネルを介した通信）を有する。帯域外通信経路３４は、共有された機密を交換するために使用され、安全になされるべきはずの不確かな経路を避ける。ＵＤＤＩサービスは、セキュリティの一部のレベルを提供し得るゆえ、ＵＤＤＩサービスは、サービスの位置を見出し、最終の宛て先サービスを用いて、帯域外の共有された機密を受け取るために使用され得る。以下は、帯域外通信経路３４および３８の少数の例である。
（ａ）モバイル装置ユーザ３０または３２、およびホストシステム２０または２２におけるオペレータは、互いに通話を確立し、共有された機密を交換する。その機密は、次いで、それぞれのシステムに入力され、暗号化鍵の作成のプロセスにおいて使用される。
（ｂ）モバイル装置ユーザ３０または３２は、ワイヤレスまたは有線のネットワークを介してかのいずれかにて、安全なウェブサイト２０または２２に接続し、鍵を要求する。その鍵は受信され、モバイル装置３０または３２に手動にて入力される。ホストシステム２０または２２は、ウェブサーバから自動的に鍵を受信し得るか、または手動にても入力され得る。一部の実施形態において、記録は、共有された機密が要求された後に、自動で生成される。
（ｃ）モバイル装置３０または３２のユーザは、サービスに対する要求をし、その共有された機密はホストシステム２０または２２によって、安全な領域内であると知られているそれらの企業内のメールボックスへとｅメールを送信される。そのユーザは、それらの電子メールボックスから共有された機密を引き出し、それを手動にて、モバイル装置３０または３２に入力する。
（ｄ）モバイル装置３０または３２のユーザは、サービスの要求をし、サービス２０または２２におけるオペレータは共有された機密を作成し、それは、信頼でき、安全であると知られる特定の人物へ与えられる。この人物は、所定のグループの秘書または管理者であり得る；理想的には、その要求をしたユーザのＩＤを確認することができる人物である。この信頼の置ける人物は次いで、共有された機密をモバイル装置３０または３２の最終のユーザに与え、それは、モバイル装置３０または３２に手動にて入力される。
【００１４】
この短いリストは、共有された機密をモバイル装置のユーザに、認証して与える多くの方法が存在することを示す。これらの例示的な帯域外通信３４および３８の共通の性質は、認証の一部のレベルが内組み込まれているか、または、なされた選択において想定されていることである。この認証された通信経路は、未認証データ通信経路とは異なる。
【００１５】
いったん、共有された機密が交換されると、安全な通信経路を作成する次なるステップが参照番号３６および４０にて生じ得る。安全で認証されたリンクを作成するより良く知られた方法のうちの一つは、ＳＰＥＫＥなどのような強力なパスワードベースの暗号化方法を用いることである。ＳＰＥＫＥは、覚えやすいパスワード、すなわち共有された機密を強め、保護する知識ベースの認証のための暗号方法である。ＳＰＥＫＥは、公知の強力なパスワード方法の最も単純なものである。それは、パスワード認証のＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ交換であり、パスワードはベースまたはその交換の「生成者（ｇｅｎｅｒａｔｏｒ）」を形成する（標準のＤｉｆｆｉｅ−Ｈｅｌｌｍａｎにおいては、そのベースは通常、固定された公開番号である）。いったんＷＡＮ２６およびワイヤレスネットワーク２８を介した通信経路が安全にされると、再鍵（ｒｅ−ｋｅｙ）シーケンスが開始され得る。その再鍵シーケンスによって、所定の数週間または数ヶ月の後、新しい鍵のセットの生成が可能となる。この再鍵シーケンスの間、長期の暗号化鍵の高度な使用が、完全なフォワード秘匿性のインプリメンテーションを可能にする。いったん認証機密（共有された機密）が安全な経路を作成するために使用されると、後に新しい鍵を作成するために再利用され得る。本発明を使用することによって、再鍵動作は、以前の鍵に侵害を生じさせず、全ての以前の会話は将来に亘って機密のままである。
【００１６】
図２を参照すると、本発明の一実施形態に従った、二つのワイヤレスシステム間における例示的な通信システムのブロック図が示される。この実施形態において、安全な経路５２は、二つのモバイル装置間において作成され得る。この実施形態において、モバイル装置１  ４６およびモバイル装置２  ４８は、機密を交換し、その共有された機密を用いて、共通鍵を確立することが可能である。帯域外会話５０は、二人の当事者間の通話、または面と向かった会議を介して生じ得、あるいは、既に概略的に述べられた他の方法または任意の他の適切な方法のうちの一つを用いて生じ得る。いったん機密が共有されると、それはモバイル装置４６および４８に手動にて打ち込まれ得、一つの局は、メッセージの交換を開始し得、共通のマスターセキュリティ鍵を作成する。このタイプの実施形態は、プライベートの２地点間のｅメール会話のために通常使用され得る。これはまた、２地点間の安全なインスタントメッセージングデータ交換のために用いられ得る。モバイル装置１  ４６の高度な使用において、サービスを提供している者は、モバイル装置４６上のウェブサーバを実行し得、これもまたモバイルである安全なサービスの提供の一部の形式を提供し得る。
【００１７】
図３を参照し、本発明の一実施形態に従った、二つの固定システム間における例示的な通信システムのブロック図が示される。この実施形態において、通信は、二つのホストシステム６０と６２との間において生じる。この例示において、サービスの提供６０およびサービスの消費者６２は、帯域外会話６６を有し、機密鍵を交換する。既に述べたように、この帯域外通信は、通話、鍵を作成し引き出すために安全なＳＳＬ接続を用いたブラウザを介した通信、または、以前に提供されたような一部の他の適切な通信であり得る。いったん機密が交換されると、暗号化鍵は、ＳＰＥＫＥなどの、強力なパスワードベースの鍵生成を用いて生成され得る。この例示において、鍵を交換するための通信経路は、インターネット２６などのＷＡＮネットワークを介するものであり、または、内部イントラネット６４を介するものであり、あるいは８０２．１１またはＢｌｕｅｔｏｏｔｈ（登録商標）リンクなど、またはそれらに類似する他の適切な通信経路であり得る。これらの後者の例において、サービスの消費者６２は、ラップトップまたはパームトップを実行し得、既にイントラネットへの限定されたアクセスを有し得るが、さらなるセキュリティが必要とされる。当該技術分野において周知であるが、８０２．１１ｂは、企業内における最も大きな部門によって必要とされる強いセキュリティの必要条件を欠く。この実施形態は、パスワードベースの認証メカニズムを用いる場合、本発明が完全なフォワード秘匿性のオプションを提供するために使用され得ることを示す。いったん適切なメッセージがマスター鍵を作成するために交換されると、データ通信経路６８は、高いセキュリティで、あらゆる形式のデータを秘密裡に交換するために使用され得る。
【００１８】
図４を参照すると、マスター鍵を生成し検証するためのデータ交換の例示的なセットを示すメッセージ交換図が示され、そこでユーザはデータ交換の開始者である。この例は、例示的なステップ、および、サービス消費者１００（ユーザ）とサービスプロバイダ１０２との間のメッセージ交換を示す。この例示において、接続の一端はサービスの消費者またはユーザ１００を想定され、システムＡというラベルを与えられている。接続のもう一方の端は、サービスプロバイダ（サービスの提供としても言及される）またはホストシステム１０２を想定され、システムＢというラベルを与えられている。この例において、ユーザ１００は、データの交換を開始し、安全な接続を作成する。システムＡとシステムＢとの間において、図１において示されるように、一つ以上のデータ通信ネットワークを介したメッセージ交換が存在する。同様に、図１、図２、および図３に示されるように、ユーザは、モバイル装置３０、３２または４８、あるいは、ホストシステム６２であり得る。同様に、サービスプロバイダはモバイル装置４６またはホストシステム２０、２２、または６０であり得る。
【００１９】
ステップ１０４において示されるように、ユーザ１００は、帯域外通信について既に述べられた方法の一つを介して、または別の適切な方法を介して、既知のサービスプロバイダ１０２に接触し、共有された機密を交換する。このサービスプロバイダ１０２は、この交換を容易にすることを望み、機密のパスワードまたは、単純な覚えやすいパスワードの文字列を発行する（ステップ１０６）。このメカニズムを介して、共有された機密は、二人の当事者間にて作成され、交換される。ユーザ１００は、機密を受信および保管し、暗号化鍵生成を助ける。あるいは、サービスプロバイダ１０２は、ユーザ１００からの機密パスワード（共有された機密）を受け取り得る。いずれかの場合において、サービスプロバイダは、このユーザに関連する共有された機密を保管する。
【００２０】
その共有された機密の交換の後、ユーザ１００は次いで（この例において）、鍵の対を作成するステップを開始し（ステップ１０８）、鍵情報をサービスプロバイダに転送する（ステップ１１０）。特に、ユーザ１００は、ステップ１０８において、長期暗号化鍵の対、すなわち、暗号化鍵の公開鍵および秘密鍵を作成する。短期認証鍵の対はまた、ユーザ１００によってステップ１０８において生成される。この短期鍵の対は、以下でさらに検討されるように、それが共有された機密を用いて生成されるゆえに、この例において認証鍵の対として参照される。
【００２１】
いったんユーザの短期および長期鍵の対が生成されると、その公開鍵は、ステップ１１０においてサービスプロバイダ１０２に転送され、最終のマスター鍵（マスター機密とも呼ばれる）をさらに生成する。共有された機密を発行したホストシステム１０２が短期認証鍵を理解し使用し得、マスター鍵を生成する場合にのみ、この転送は、不確かなリンクを介して生じ得る。いったんユーザの公開鍵がサービスプロバイダによって受け取られると（ステップ１１２）、ユーザは検証され、そのユーザに対する共有された機密がリコールされる（ステップ１１２）。いったんユーザが検証され、そのユーザに対する共有された秘密がリコールされると、サービスプロバイダ１０２は、共有された機密を用いて、それ自体の短期認証鍵の対を生成するように進む（ステップ１１４）。サービスプロバイダ１０２はまた、それ自体の短期暗号化鍵の対を生成する（ステップ１１４）。ユーザ１００によって生成された公開鍵を用い、および共有された機密を用いて、サービスプロバイダ１０２は、ステップ１１６において示されるように、マスター暗号化鍵（またはマスター機密）を生成する。その共有された機密は、その交換された情報を信用するために必要である認証を提供する。サービスプロバイダの短期公開認証鍵、サービスプロバイダの短期公開暗号化鍵、および、新しく生成されたマスター暗号化鍵を用いたサービスプロバイダによって計算されている鍵確認値、および一部の既知の文字列は、ユーザに送信される（ステップ１１６）。
【００２２】
ユーザは、サービスプロバイダの短期および長期公開鍵を含むサービスプロバイダ１０２から送信される情報を受け取り（ステップ１１８）、ユーザ自身のマスター鍵を生成する（ステップ１２０）。このマスター鍵を用いて、ユーザは、鍵確認値を検証する（ステップ１２０）。この例において、鍵確認値は、ユーザおよびサービスプロバイダによって承認された、マスター鍵のハッシュ、およびサービスまたは一部の他の既知の文字列の名前であり得る。鍵確認値が検証されない場合、ユーザ１００によって生成されるマスター鍵は信用されず、それは、何者かが接続に障害を生じさせようと試みていると想定される。ユーザ１００によって生成されたマスター暗号化鍵が有効であると思われる場合、ユーザは次いで、最終の鍵確認値をサービスプロバイダに戻す（ステップ１２２）。サービスプロバイダはメッセージを受け取り、鍵確認値を検証し、および、準備の整ったユーザをマークする（ステップ１２４）。これによって、サービスプロバイダの見地から生じるための、完全なデータ交換を行うことが可能となる（ステップ１２８）。ユーザ側において、いったん検証メッセージが送信されると、送信において僅かな停止があるが、次いで、完全なデータ交換が開始され得る（ステップ１２６）。
【００２３】
送信は、ｅメールメッセージ、ＸＭＬ（拡張可能マークアップ言語）、ＷＭＬ（ワイヤレスマークアップ言語）、その他などのＨＴＴＰ（ハイパーテキスト転送プロトコル）ベースのトラフィック、または他のタイプのトラフィックを含み得る。
【００２４】
一部の実施形態において、ホストシステムは、最終の確認値がモバイル装置からホストシステムに送信される前に、モバイル装置へ送信されるメッセージにおけるデータペイロード（ｐａｙｌｏａｄ）を送信することが可能である。このメッセージにおけるペイロードは、ホストシステムにおいて、ホストサービスを規定するサービスブック入力であり得る。一部の実施形態において、サービスブックエントリは、アクセスされるホストシステムにおいて、ホストサービスの属性を規定するＵＤＤＩサービス入力であり得る。
【００２５】
本発明において記載されるように、第１者（例えばユーザ）によって生成される長期暗号化鍵の対は、より一般的には、第１の鍵の対の一例であり、ここで、公開鍵部分および秘密鍵部分は、第１の公開鍵および第１の秘密鍵として参照され得る。同様に、本明細書に記載されるように、第１者（例えばユーザ）によって生成された短期認証鍵の対（短期暗号化鍵の対とも呼ばれる）は、より一般的には、第２の鍵の対の一例であり、ここで、公開鍵部分および秘密鍵部分は、第２の公開鍵および第２の秘密鍵として参照され得る。また、本明細書に記載されるように、第２者（例えばサービスプロバイダ）によって生成された短期暗号化鍵の対（短期暗号化鍵の対とも呼ばれる）は、より一般的には、第３の鍵の対の一例であり、ここで、公開鍵部分および秘密鍵部分は、第３の公開鍵および第３の秘密鍵として参照され得る。同様に、本明細書に記載されるように、第２者（例えばサービスプロバイダ）によって生成された短期認証鍵の対（短期暗号化鍵の対とも呼ばれる）は、より一般的には、第４の鍵の対の一例であり、ここで、公開鍵部分および秘密鍵部分は、第４の公開鍵および第４の秘密鍵として参照され得る。第１および第２の鍵の対を生成する第１者は、上記の例において記載されたようなユーザであるか、または、以下に記載されるようなサービスプロバイダであり得る。
【００２６】
図５を参照すると、マスター鍵を生成し検証するためのデータ交換の例示的なセットを示すメッセージ交換図が示され、サービスプロバイダはデータ交換の開始者である。図５内のステップは、サービスプロバイダが第１のステップを取ること以外は、実質的に図４内のステップに対応している。この例は、ユーザまたはサービスプロバイダのいずれかがデータ交換の開始者であり得ることを強調する。この例示において、接続の一端はユーザ１００と想定され、システムＡ、すなわちサービス消費者とラベル付けされる。接続のもう一方の端は、サービス１０２を想定され、システムＢ、すなわち、サービスプロバイダとラベル付けされる。システムＡ１００とシステムＢ１０２との間において、図１、図２、および図３に示されるように、一つ以上のデータ通信ネットワーク２６、２８、および６４を介したメッセージ交換が存在する。同様に、図１、図２、および図３において示されるように、ユーザは、モバイル装置３０、３２、または４８であり得るか、またはホストシステム２０、２２、４６、または６０であり得る。
【００２７】
ステップ２００／２０２において示されるように、サービスプロバイダ１０２は、ユーザ１００（この例において）と接触し、共有された機密を交換する。あるいは、ユーザはこの通信を開始し得る。ホストカンパニー１０２内の管理者はユーザ１００と接触し得、ユーザに、そのユーザが提供される共有された機密を用いて一部の動作を実行しなければならないことを通知するということが考えられる。既に提供された帯域外通信の拡張リストから選択された任意の適切な方法、または一部の他の適切な方法を用いて、共有された機密は生成され、交換される（ステップ２００およびステップ２０２）。そのユーザコンポーネントは共有された機密を受け取り、保管し、暗号化鍵生成を補助する。あるいは、サービスプロバイダ１０２は、ユーザ１００から機密パスワード（共有された機密）を受け取ることができる。いずれの場合においても、サービスプロバイダは、このユーザに関連して共有された機密を保管する。
【００２８】
その共有された機密の交換の後、サービスプロバイダ１０２は、（この例において）鍵の対を生成し（ステップ２０４）、鍵情報をユーザ１００に転送する（ステップ２０６）ステップを開始し得る。特に、サービスプロバイダ１０２は、短期認証鍵の対および長期暗号化鍵の対を生成する（ステップ２０４）。これは、図４におけるステップ１０８に対応する。
【００２９】
いったんサービスプロバイダの短期鍵および長期鍵の対が生成されると、その公開鍵はユーザに転送され（ステップ２０６）、最終のマスター鍵（マスター機密とも呼ばれる）をさらに生成する。この転送は、共有された機密の所持者が短期認証鍵を理解し使用し得、マスター鍵を生成する場合にのみ、この転送は、不確かなリンクを介して生じ得る。サービスプロバイダの公開鍵がユーザによって受け取られ、それは、サービスの作成が期待されているか、および、メモリにおいて保管された共有された機密を有するかを検証するためにメモリをチェックする（ステップ２０８）。ユーザはそのサービスプロバイダ１０２に対する共有された機密をリコールし、その共有された機密を用いて、短期認証鍵の対を生成する（ステップ２１０）。ユーザはまた、長期暗号化鍵の対を生成する（ステップ２１０）。サービスプロバイダ１０２によって生成され送信された公開鍵および共有された機密を用いて、ユーザ１００は、ステップ２１２において示されるように、マスター暗号化鍵（またはマスター機密）を生成する。マスター鍵を生成した後、ユーザ１００はまた、既知の文字列（すなわち、それ自体およびサービスの提供に対して既知である）とマスター鍵を組み合わせることによって、鍵確認値を生成する（ステップ２１２）。ユーザの短期公開認証鍵、長期公開暗号化鍵、および鍵確認値は、サービスプロバイダに送信される（ステップ２１２）。
【００３０】
サービスプロバイダは、ユーザの公開鍵および鍵確認値を受け取り、その情報の送信者を検証し（ステップ２１４）、ならびに、また、このユーザに対して、共有された機密をリコールする。そのユーザの受け取られた公開鍵を用いて、サービスプロバイダは、このユーザに対して、それ自身の保管された秘密鍵値をリコールする（ステップ２１４）。そのユーザの受け取られた公開鍵およびサービスプロバイダの保管された秘密鍵を用いて、サービスプロバイダは、ここで、マスター鍵を生成することができる（ステップ２１６）。マスター鍵を生成した後、サービスプロバイダ１０２は、それ自身の鍵確認値を計算し、その既知の文字列および新しく作成されたマスター鍵を用い、それと受け取られた鍵確認値とを比較することによって、鍵確認値を検証する（ステップ２１６）。その鍵確認値が検証されない場合、その作成されたマスター鍵は信用されず、何者かがその接続に障害を生じさせようと試みていると想定される。その鍵確認値が検証された場合、マスター暗号化鍵は有効と想定され、サービスプロバイダ１０２は、最終の鍵確認値をユーザへ戻す（ステップ２１８）。ユーザはメッセージを受け取り（ステップ２２０）、鍵確認値を検証し、および、準備の整ったユーザをマークする（ステップ２２０）。これによって、ユーザの見地から、完全なデータ交換を行うことが可能となる（ステップ２２２）。サービスの提供側において、いったん検証メッセージが送信されると、送信において僅かな停止があるが、次いで、完全なデータ交換が開始され得る（ステップ２２４）。多くの場合、それは第１のデータ交換を開始するユーザであり、従って、ユーザにその確認を送信することは、いくらかの利点を有する。
【００３１】
送信は、ｅメールメッセージ、ＸＭＬ（拡張可能マークアップ言語）、ＷＭＬ（ワイヤレスマークアップ言語）、その他などのＨＴＴＰ（ハイパーテキスト転送プロトコル）ベースのトラフィック、または他のタイプのトラフィックを含み得る。
【００３２】
図６は、図４において示された例示的なアプローチを実行するために、ユーザ（例えば、ユーザのソフトウェア内）によって実行される例示的なステップのデータフロー図であり、そのユーザは鍵交換の開始者である。第１のステップは、ユーザが新たなサービスを発見し、それへのアクセスを望む場合に生じる（ステップ３００）。これは、企業内イントラネットサービスを介して、ワールドワイドウェブを閲覧することを介して、友人との会話を介して、または通話を介して、ＵＤＤＩ様のサービスを経由して生じ得る。いったんサービスとユーザが接続されると、それらは、それらの間のみが知る、共有された機密、’ｓ’を交換する（ステップ３０２）。この交換の例示的な方法は、既に詳細に記載されている。この共有された機密’ｓ’は、後に、ＰＩＮ（個人識別番号）などのように、使用され、そのユーザおよびサービスを互いに認証させる。ユーザがサービスにアクセスする準備が整った場合、そのユーザ（例えばソフトウェア内のユーザ）は、要求されたサービスに対する短期鍵の対を生成する（ステップ３０４）。この短期鍵の対は、あらゆる将来の再鍵動作の間に使用される鍵値のうちの一つである。この応用の残りにおける全ての数学的計算に対して、その取引に含まれる全ての者が、ｑ＝ｏｒｄｅｒ（ｇ）が大きい素数であるように、サイズオーダー（Ｇ）のグループＧ、およびＧの要素ｇを事前に合意していることを想定する。Ｇおよびｇは公知であり、すなわち、それらは機密のままにしておく必要はない。鍵値を作成するための例示的な数学的計算は、（ＳＰＥＫＥ方法を用いて）以下に示され、以下に示される例示的な計算が乗法グループを活用する一方で、適切な計算が、加算グループを用いて実行され得ることはあきらかである。
【００３３】
（長期鍵の対をとる（例えばユーザによって））
１＜ａ＜ｑ−１の条件下で、ランダムａをとる；
Ａ＝ｇａを計算する；
Ａ＝１の場合、Ａ＜＞１まで、異なるａを選び続ける  。
【００３４】
値’Ａ’はユーザの長期公開鍵（すなわち、より一般的には、第１の公開鍵）であり、値’ａ’はユーザの長期秘密鍵（すなわち、より一般的には、第１の秘密鍵）である。
【００３５】
その選択された数’ａ’は１より大きく、素数ｑ−１よりも小さい。いったん秘密鍵が選択（すなわち、’ａ’）され、公開鍵が生成（すなわち’Ａ’）されると、その秘密鍵’ａ’が安全に格納され、その公開鍵’Ａ’は、最終的に、サービスプロバイダに転送される。
【００３６】
短期認証鍵の対はまた、共有された機密’ｓ’に基づいてユーザによって生成される（ステップ３０６）。ＳＰＥＫＥ鍵生成方法に従った同様の計算を用いて、このステップに対する例示的な数学的計算は以下である（例えば、以前のように、ｑおよび’ａ’（ここではｘに適用される）に対する同じ想定である）。
【００３７】
（短期鍵の対をとる（例えばユーザによって））
１＜ｘ＜ｑ−１の条件下で、ランダムｘをとる；
Ｘ＝ｓｘを計算する；
Ｘ＝１の場合、Ｘ＜＞１まで、異なるｘ’を選び続ける  。
【００３８】
値’Ｘ’はユーザの短期公開鍵（すなわち、より一般的には、第２の公開鍵）であり、値’ｘ’はユーザの短期秘密鍵（すなわち、より一般的には、第２の秘密鍵）である。値’ｓ’は、共有された機密である。
【００３９】
’ｘ’の選択は１と素数ｑ−１との間である。ユーザのソフトウェアは次いで、公開鍵値’Ａ’および’Ｘ’を、ステップ３０８において示されるように、サービスの提供（サービスプロバイダ）に送信する。このステップは、（Ａ）に進み、サービスの提供は、図７において示されるように、その値を受け取り、追加の計算を実行する。いったんサービスの提供がそれらの計算を完了すると、図７に関連して以下にさらに記載されるように、検証のためのユーザに対する鍵確認値を用いて、それ自体の公開鍵値’Ｂ’および’Ｙ’の類似した対を戻す（ステップ３１２）。これは、図７からの、図６における入力（Ｂ）として示される。この時点において、ユーザは、’Ｂ’および’Ｙ’を利用することができ、例えば、高度なＳＰＥＫＥ計算を用いて、マスター鍵を作成する。マスター鍵を生成するために、’Ｂ’および’Ｙ’の両方を用いることによって、暗号化方法は、完全なフォワード秘匿性のインプリメンテーションを可能にする。これは、後に示される再鍵シーケンスにおいてさらに明らかになる。例示的なマスター鍵計算は以下である。
【００４０】
（マスター鍵の計算（例えばユーザによって））
ｋ１＝Ｙｘ；
ｋ２＝Ｂａ；
ｋ１，ｋ２！＝０，１またはｏｒｄｅｒ（Ｇ）−１であることをチェックする
ｋ＝ハッシュ（ｋ１｜｜ｋ２）  ここで、｜｜は連結（ｃｏｎｃａｔｅｎｔａｔｉｏｎ）関数である。
【００４１】
ここで、’ｘ’はユーザの短期秘密認証鍵（すなわち、より一般的には、第２の秘密鍵）であり、’Ｙ’は、サービスの提供の受け取られた短期公開認証鍵（すなわち、より一般的には、第４の公開鍵）である。また、’ａ’は、ユーザの長期秘密暗号化鍵（すなわち、より一般的には、第１の秘密鍵）であり、’Ｂ’はサービス提供の受け取られた長期公開暗号化鍵（すなわち、より一般的には、第３の公開鍵）である。
【００４２】
値’ｋ’は、ユーザとサービスとの間における暗号化データに対して使用され得るマスター鍵を表す。値’ｋ’は、中間鍵’ｋ１’（短期認証鍵に基づく）および中間鍵’ｋ２’（長期暗号化鍵に基づく）の組み合わせである。重要なチェックは、ステップ３１４において、ｋ１およびｋ２の中間鍵値に対してなされ得、これらの二つの値が０、１、またはｏｒｄｅｒ（Ｇ）−１でないことを検証する。そうでない場合、セキュリティへの攻撃が企てられていることを意味し得る（ステップ３１４）。その鍵が全体の可能な鍵のうちの少ないサブセットへと強られている場合、この攻撃という結果となる。その攻撃者がＸ＝０またはＹ＝０を送信する場合、通信する者はその結果として、０の鍵値を得ることができる。この迅速なチェックは、攻撃が実施されていないことを保証する。しかしながら、ｋ１またはｋ２がこれらの少ないサブセットグループのうちの一つに該当する場合、鍵に対するネゴシエーションは中止され得る（ステップ３１６）。
【００４３】
サブセットの攻撃が検出されない場合、マスター鍵’ｋ’は、ユーザによって使用され得、サービスの提供によって送信される鍵確認値を試験する（ステップ３１８）。鍵確認値を生成するための一つの方法は、公開鍵”Ａ”におけるバイトなどの、既知の文字列を用いて、その鍵をハッシュすることである。鍵確認値を試験するための例示的な計算は以下である。
【００４４】
（鍵確認値の試験）
”受け取られたｈＡ”＝ｈＡ＝ハッシュ（ｋ｜｜公開鍵”Ａ”のバイト）、ここで、”受け取られたｈＡ”は、サービスの提供から由来し、’ｋ’は局地のマスター鍵である。
【００４５】
’Ａ’に対するソフトウェアの生成された鍵確認値が、その受信された鍵確認値と合致しない場合（ステップ３２０）、それは不正確である（ステップ３２２）。不正確な鍵確認値は、中攻撃（ｍａｎ−ｉｎ−ｔｈｅ−ｍｉｄｄｌｅ−ａｔｔａｃｋ）または一部の他の攻撃が企てられていることを意味し得る。その動作は、この場合、中止される（ステップ３２２）。二つの確認値が合致する場合、次いで、十分に安全なリンクが確立される想定される（ステップ３２４）。そのリンクは、有効としてマークされ、少しの遅延の後、通信のために使用される（ステップ３２４）。新しく生成された検証鍵を用いて、そのユーザは、この値をサービスへ送信する（ステップ３２６）。これは、ラベル（Ｃ）に続く図６に戻る。数秒の停止の後、すなわち、確認がサービスの提供によって受け取られたことを保証するための停止の後、ユーザはデータを交換し始めることが可能である（ステップ３２８）。
【００４６】
任意の適切な暗号化および解読方法は、ＡＥＳ（Ａｄｖａｎｃｅｄ  Ｅｎｃｙｐｔｉｏｎ  Ｓｔａｎｄａｒｄ）（Ｆｅｄｅｒａｌ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｐｒｏｃｅｓｓｉｎｇ  Ｓｔａｎｄａｒｄｓ  Ｐｕｂｌｉｃａｔｉｏｎ  １９７、１１月２６日、２００１年、Ｎａｔｉｏｎａｌ  Ｉｎｓｔｉｔｕｔｅ  ｏｆ  Ｓｔａｎｄａｒｄｓ  ａｎｄ  Ｔｅｃｈｎｏｌｏｇｙ）などのような、対称的な鍵暗号化／解読方法などの、マスター鍵を使用してメッセージを暗号化および解読するために使用され得る。
【００４７】
図７は、ユーザが図４に示されているように、ユーザが鍵交換の開始者である場合に、図４に示される例示的なアプローチを実行するためのサービスの提供（例えば、サービスプロバイダソフトウェア内）によって実行される例示的なステップのデータフロー図である。そのプロセスは、ユーザが共有された機密を交換するために、サービスプロバイダに、「帯域外」にて接触する場合に、開始される（ステップ３９８）。これは、ユーザの装置上での、図６のステップ３０２に対応する。この帯域外交換は、数回検討され、また、そのユーザおよびサービスが、それらが何に対してなのか、何なのかといった認証のレベルを提供する。いったんこの交換が完了すると、そのユーザは適宜に、任意の場所にて自由であり、そのプロセスを開始するためにサービスと接触する。いったんユーザがホストサービスと接触すると、図６におけるユーザのフローチャートから到着するメッセージ（Ａ）を用いて示されるように、新たなユーザが検証される（ステップ４００）。サービスプロバイダは、いつでも、数十数百のユーザを、それらのサービスを用いて開始することを望み得るゆえ、そのサービスプロバイダは、ユーザがサービスを開始したいことを決定するまで、受身である。たとえ共有された機密が交換されたとしても、これは重要ではなくあり得、ユーザが相当期間に亘って接続を失敗する場合でも、数日後には、古い共有された機密は取り除かれ得る。メッセージの到着によって、サービスプロバイダが新たなユーザを見出し、共有された機密が存在することを検証することを可能にする（ステップ４００）。そのメッセージにおいて、ユーザの公開短期認証鍵が存在し、それは、共有された機密に基づく（ステップ４００）。そのメッセージはまた、ユーザの公開長期暗号化鍵を含み（ステップ４００）、それは、インプリメンテーションにおいて使用され得、図７および図８において、再鍵動作が生じる場合に、完全なフォワード秘匿性を作成する。
【００４８】
サービスの提供は、ユーザによって作成された長期暗号化鍵の対と同様な方法において、このユーザに対して、長期暗号化鍵の対を生成する（ステップ４０２）。サービスの提供の長期暗号化鍵の対を作成するための例示的な数学的計算は以下である（例えば、ＳＰＥＫＥ方法を用いて）。
【００４９】
（長期鍵の対をとる（例えばサービスプロバイダによって））
１＜ｂ＜ｑ−１の条件下で、ランダムｂをとる；
Ｂ＝ｇｂを計算する
Ｂ＝１の場合、Ｂ＜＞１まで異なるｂを選択し続ける  。
【００５０】
値’Ｂ’はサービスの提供（サービスプロバイダ）の長期公開鍵（すなわち、より一般的には、第３の公開鍵）であり、値’ｂ’はサービスの提供の長期秘密鍵（すなわち、より一般的には、第３の秘密鍵）である。
【００５１】
その選択された数’ｂ’は１より大きく、素数ｑ−１よりも小さい。いったん秘密鍵’ｂ’が選択され、公開鍵’Ｂ’が生成されると、その秘密鍵’ｂ’が安全に格納され、その公開鍵’Ｂ’は、最終的に、ユーザに転送され、そのユーザは、彼の計算においてそれを使用することができる。
【００５２】
サービスの提供はまた、共有された機密に基づいて短期認証鍵の対を生成する（ステップ４０４）。ＳＰＥＫＥ鍵生成方法に従った同様の計算を用いて、このステップに対する例示的な数学的計算は以下である（例えば、以前のように、ｑおよびｘ（ここではｙに適用される）に対する同じ想定である）。
【００５３】
（短期認証鍵の対（例えばサービスプロバイダによって））
１＜ｙ＜ｑ−１の条件下で、ランダムｙをとる；
Ｙ＝ｇｙを計算する
Ｙ＝１の場合、Ｙ＜＞１まで異なるｙを選択し続ける
値’Ｙ’はサービスの提供（サービスプロバイダ）の公開短期認証鍵（すなわち、より一般的には、第４の公開鍵）であり、値’ｙ’はサービスの提供の秘密短期認証鍵（すなわち、より一般的には、第４の秘密鍵）である。
【００５４】
その選択された数’ｙ’は１と素数ｑ−１との間である。その公開鍵値’Ｂ’および’Ｙ’は、最終的に、ユーザに送信され、そのユーザ自身のマスター鍵を生成する。
【００５５】
サービスの提供は、次いで、ユーザから受信された公開鍵’Ａ’および’Ｘ’、ならびに、計算された秘密鍵を用いて、マスター鍵を生成する（ステップ４６０）。’Ａ’および’Ｘ’を共に用いることによって、マスター鍵を生成するために、その暗号化方法は、完全なフォワード秘匿性を提供する。完全なフォワード秘匿性を提供するために、そのインプリメンテーションはまた、任意の再鍵シーケンスの間、その後の鍵の再生成において、秘密鍵を使用する。例示的なマスター鍵計算は以下である。
【００５６】
（マスター鍵の計算（例えばサービスプロバイダ））
ｋ１＝Ｘｙ；
ｋ２＝Ａｂ；
ｋ１，ｋ２！＝０，１，またはｏｒｄｅｒ（Ｇ）−１であることをチェックする；
ｋ＝ハッシュ（ｋ１｜｜ｋ２）。
【００５７】
ここで、’ｙ’はサービスの提供の短期秘密暗号化鍵（すなわち、より一般的には、第４の秘密鍵）であり、’Ｘ’はユーザの受け取られた短期公開暗号化鍵（すなわち、より一般的には、第２の公開鍵）である。また、’ｂ’はサービスの提供の長期秘密鍵（すなわち、より一般的には、第３の秘密鍵）であり、’Ａ’はユーザの受け取られた長期公開暗号化鍵（すなわち、より一般的には、第１の公開鍵）である。
【００５８】
値’ｋ’はサービスの提供によって生成されたマスター鍵を表し、それはユーザによって生成されたマスター鍵と同じである。このマスター鍵は、サービスとユーザとの間における暗号化データに対して使用され得る。その値’ｋ’は、中間鍵’ｋ１’（短期認証鍵に基づく）および中間鍵’ｋ２’（長期暗号化鍵に基づく）の組み合わせである。重要なチェックは、ステップ４０８において、ｋ１およびｋ２の中間鍵値に対してなされ得、これらの二つの値が０、１、またはｏｒｄｅｒ（Ｇ）−１でないことを検証する；そうでない場合、セキュリティへの攻撃が企てられていることを意味し得る。その鍵が全体の可能な鍵のうちの少ないサブセットへと強られている場合、この攻撃という結果となる。その攻撃者がＸ＝０またはＹ＝０を送信する場合、通信する者はその結果として、０の鍵値を得ることができる。この迅速なチェックは、攻撃が実施されていないことを保証する。しかしながら、ｋ１またはｋ２の値がこれらの少ないサブセットグループのうちの一つに該当する場合、鍵に対するネゴシエーションは中止され得る（ステップ４１０）。
【００５９】
サブセットの攻撃が検出されない場合、マスター鍵’ｋ’は、サービスの提供によって使用され得、ユーザによって送信される鍵確認値を試験する（ステップ４１６）。鍵確認値を生成するための一つの方法は、公開鍵”Ｂ”におけるバイトなどの、既知の文字列を用いて、その鍵をハッシュすることである。サンプルの試験文字列の生成は、ステップ４１２において起こる。その文字列（鍵確認値）を試験するための例示的な計算は以下である。
【００６０】
（鍵確認値の試験）
ｈＢ＝ハッシュ（ｋ｜｜公開鍵’Ｂ’のバイト）  。
【００６１】
サービスの提供は、ユーザによって生成されたマスター鍵がそのサービスの提供によって作成されるマスター鍵と合致することを検証することができるように、テスト文字列をユーザに送信する。そのサービスの提供は次いで、長期公開暗号化鍵’Ｂ’、短期公開認証鍵’Ｙ’（すなわち、第４の公開鍵）、および検証文字列ｈＢを、ユーザへ送信する（ステップ４１４）。
【００６２】
いったんユーザがそれ自体のマスター鍵’ｋ’を生成すると、最終の鍵確認値を送信し、サービスの提供が、全てが正確に作動していると知っていることを保証する（ステップ（Ｃ））。この最終のステップ（Ｃ）は、ステップ４１６における、サービスの提供に対する入力として、図７において示される。その鍵確認値が’Ａ’に基づいて計算され、そのサービスの提供へ送信された場合（ステップ４１６）、これが、その試験が探しているものである（ステップ４１８）。その鍵確認値が期待された値と合致しない場合、その動作は中止される（ステップ４２０）。その鍵確認値が合致する場合、次いで、完全な双方向の暗号化された、かつ安全なデータ通信経路が存在することが想定される（ステップ４２２）。
【００６３】
（再鍵データフローシーケンス）
図８は、図１、図２、および図３において示されるような環境において、別の鍵を再生成する場合、再鍵シーケンスに対しての、ユーザ内（例えばソフトウェア内）における例示的なステップを示すデータフロー図である。この手順は、完全なフォワード秘匿性のインプリメンテーションを可能にする長期暗号化鍵を用いた効用を示す。そのプロセスは、ユーザまたはサービスの提供のいずれかが新たな鍵が必要とされることを決定する場合に開始される。この例において、ホスト（サービスプロバイダ）は暗号化鍵の終了タイマー（ｅｘｐｉｒｙ  ｔｉｍｅｒ）を実行していると想定する。しかしながら、その暗号化鍵が再生成され得る他の多くの方法が存在する。そのユーザは、新たな鍵のための時間を決定し得、ユーザまたはサービスは、何者かが攻撃を企てており、現在の鍵値を決定することを恐れることもある。いずれの場合においても、新たな鍵は所望され、オリジナルの共有された機密に基づかない独自の方法が、新たな鍵を生成するために使用され得る。
【００６４】
図８の例において示されるように、再鍵要求は、ユーザによって受け取られるか、または、ユーザが新たな鍵をカット（ｃｕｔ）することを決定する（ステップ４３０）。もちろん、ステップ４３０はユーザの代わりに、サービスプロバイダによって実行され得る。ユーザソフトウェアは、新たな短期暗号化鍵を生成する（ステップ４３２）。例示的な数学的計算は、ＳＰＥＫＥに基づき、同じシーケンスを使用し、以下に示される。
【００６５】
（新たな短期暗号化鍵の対をとる（例えばユーザによって））
１＜ｘ＜ｑ−１の条件下で、ランダムｘをとる；
Ｘ＝ｇｘを計算する；
Ｘ＝１の場合、Ｘ＜＞１までｘを選択し続ける  。
【００６６】
ここで、’ｘ’は、ユーザの短期秘密暗号化鍵に対して生成された’新しい’値である。その値’ｘ’は、「暗号化」鍵または「認証」鍵（以前になされたように）のいずれかとして言及され得る。なぜならば、その値’ｘ’は、両方の局面に寄与するからである。’ｘ’の選択は、１と素数ｑ−１との間でなければならない。そのユーザのソフトウェアは次いで、新たに生成された公開鍵値’Ｘ’をサービスプロバイダ４３４に送信する。このステップは（Ｄ）に進み、そこで、サービスプロバイダはその値を受け取り、追加的な計算を実行する。ステップ（Ｄ）は、その接続のサービスプロバイダ側上の入力として、図９において考慮される。
【００６７】
いったんサービスプロバイダが、図９において示される（Ｄ）を用いてそれらの計算を完了させると、ユーザによる検証のための鍵確認値を用いて、類似した新たな公開暗号化鍵’Ｙ’（以下でさらに検討される）を戻す（Ｅ）。これは、図８における入力（Ｅ）として示される。この点において、ユーザは、サービスプロバイダのより古い長期公開’Ｂ’鍵とともに、サービスプロバイダの新たな’Ｙ’鍵を使用することができ、例えば、高度なＳＰＥＫＥ計算に続いて、ステップ４４０においてマスター鍵を作成する。現行の’Ｂ’および新たな’Ｙ’の両方を用いることによって、暗号化方法は、完全なフォワード秘匿性のインプリメンテーションを提供することが可能である。現行の’Ｂ’および新たな’Ｙ’がオリジナルの共有された機密に基づかず、現行の’Ｂ’が新たな’Ｙ’と組み合わされ、以前の鍵に直接に基づかずに新たな鍵を作成するゆえに、完全なフォワード秘匿性が達成され得る。付け加えて、現行の’Ｂ’鍵は、オリジナルの共有された機密を用いて生成された認証の一部を実行する。認証されたサービスのユーザ（最初から共有された機密を所有している）のみがディスクに保存された秘密鍵’ｂ’を有することが可能である。これは、新たなマスター鍵’ｋ’を作成するために、例示的な再鍵の数学的計算において、さらに明らかになる。
【００６８】
（マスター鍵の計算（例えばユーザによって））
ｋ１＝Ｙｘ；
ｋ２＝Ｂａ；
ｋ１，ｋ２！＝０，１，またはｏｒｄｅｒ（Ｇ）−１であることをチェック
ｋ＝ハッシュ（ｋ１｜｜ｋ２）  。
【００６９】
ここで、’ｘ’は新たな短期秘密暗号化鍵であり、’Ｙ’は、サービスプロバイダによって生成される、新しく受け取られた短期公開暗号化鍵である。その値’ａ’は、ユーザの現行の長期秘密暗号化鍵であり、’Ｂ’はサービスプロバイダの現行の長期公開暗号化鍵である。
【００７０】
値’ｋ’は、ユーザとサービスプロバイダとの間においてデータを暗号化するために使用され得る新たなマスター鍵を表す。値’ｋ’は、中間鍵’ｋ１’（短期暗号化鍵に基づく）および中間鍵’ｋ２’（長期暗号化鍵に基づく）の組み合わせである。重要なチェックは、ステップ４４２において、ｋ１およびｋ２の中間鍵値に対してなされ得、これらの二つの値が０、１、またはｏｒｄｅｒ（Ｇ）−１でないことを検証する。そうでない場合では、セキュリティへの攻撃が企てられていることを意味し得る（ステップ４４２）。しかしながら、ｋ１またはｋ２の値がこれらの少ないサブセットグループのうちの一つに該当する場合、鍵に対するネゴシエーションは中止され得る（ステップ４４４）。
【００７１】
サブセットの攻撃が検出されない場合、新たなマスター鍵’ｋ’は、ステップ４４６において示されるように、サービスの提供（サービスプロバイダ）によって送信される鍵確認値を試験するために使用され得る。鍵確認値を生成するための一つの方法は、公開鍵”Ａ”におけるバイトなどの、既知の文字列を用いて、その鍵をハッシュすることである。鍵確認値を計算するためのアプローチは以前に記載されたものと同じであり得る。その計算された鍵確認値が、受け取られたものと合致しない場合（ステップ４４８）、その鍵はエラーと想定される（ステップ４５０）。不正確な鍵確認値は、中攻撃（ｍａｎ−ｉｎ−ｔｈｅ−ｍｉｄｄｌｅ−ａｔｔａｃｋ）または一部の他の攻撃が企てられていることを意味する。そうでない場合、ユーザは、マスター鍵’ｋ’を用いて、最終の鍵確認値を生成する（ステップ４５２）。鍵確認値は、図８における（Ｆ）に示されているように、最終確認として、サービスプロバイダへ送信される（ステップ４５４）。僅かな停止の後、新たな暗号化鍵はユーザソフトウェア内にて用いられる（ステップ４５６）。僅かな時間の間に、以前に送信されたメッセージが到達し得るウィンドウがまた存在する。この数秒の間に、解読エラーが生じた場合に、古い鍵は保持され、解読が試される（ステップ４５６）。
【００７２】
ここで図９を参照すると、図１、図２、および図３に示される環境において別の鍵を再生成する場合、再鍵シーケンスに対する、サービスプロバイダ内における例示的なステップのデータフロー図を表す。この手続きは、完全なフォワード秘匿性をインプリメントするための長期暗号化鍵を用いた効用を示す。この実施形態において、図８において示されるように、ユーザはその処理を開始し、新たな短期暗号化（または認証）鍵の対を既に作成していると想定する。短期公開暗号化鍵‘Ｘ’の到達は、入力（Ｄ）として示される。公開鍵は受信され、そのユーザの構成情報はリコールされチェックされる（ステップ４６０）。サービスの提供は次いで、次の時間セグメントに亘る使用のために、新たな短期暗号化鍵の対を生成する（ステップ４６２）。新たな短期暗号化鍵を作成するための例示的な数式は、共有された機密‘Ｓ’が用いられないことを除き、以前に示されたものと類似する。
【００７３】
（新たな短期暗号化鍵の対をとる（例えば、サービスプロバイダによって））
１＜ｙ＜ｑ−１の条件下で、ランダムｙをとる；
Ｙ＝ｇｙを計算する；
Ｙ＝１である場合、Ｙ＜＞１まで、ランダムｙを選択し続ける  。
【００７４】
‘ｙ’の選択は、１と素数ｑ−１との間である。値‘Ｙ’は最終的に、ユーザに送信され、マスター鍵を生成する（ステップ４７２）。
【００７５】
新たな短期暗号化鍵の対を取った後、マスター鍵は、ユーザから受け取った値‘Ｘ’および新たに生成された値‘ｙ’を用いて、サービスプロバイダによって生成される。‘Ａ’および‘Ｘ’の両方を用いてその鍵を生成することによって、暗号化方法は、完全なフォワード秘匿性を提供する。例示的なマスター鍵計算は以下である。
【００７６】
（マスター鍵を計算する（例えばサービスプロバイダによって））
ｋ１＝Ｘｙ；
ｋ２＝Ａｂ；
ｋ１，ｋ２！＝０，１またはｏｒｄｅｒ（Ｇ）−１であることをチェックする；
ｋ＝ハッシュ（ｋ１｜｜ｋ２）
ここで、‘ｙ’はサービスプロバイダの新たな短期秘密暗号化鍵であり、‘Ｘ’は、ユーザによって生成された新たに受信された短期公開暗号化鍵である。値‘ｂ’は、サービスプロバイダの現行の長期秘密暗号化鍵であり、‘Ａ’はユーザの現行の長期公開暗号化鍵である。
【００７７】
値‘ｋ’は、サービスの提供に対するマスター鍵を表す（ステップ４６４）。これは、サービスの提供とユーザとの間における全てのデータを暗号化するために使用され得る。値‘ｋ’は、中間鍵‘ｋ１’（新たな短期暗号化鍵に基づく）および中間鍵‘ｋ２’（長期暗号化鍵に基づく）の組み合わせである。‘ｋ’の計算は、オリジナルの共有された機密‘ｓ’に直接依存してはいないが、値‘Ａ’および‘ｂ’は、‘ｓ’によってオリジナルに提供された認証の一部を伴う。ｋ１およびｋ２の中間鍵値上においてチェックがなされ得（ステップ４６６）、これら二つの値は０，１またはｏｒｄｅｒ（Ｇ）−１でないことを検証する。そうでない場合、それは、セキュリティへの攻撃が企てられていることを意味し得る。ｋ１またはｋ２がこれらの少ないサブセットグループのうちの一つに該当する場合、鍵に対するネゴシエーションは中止され得る（ステップ４６８）。
【００７８】
サブセットの攻撃が検出されない場合、マスター鍵’ｋ’は、サービスの提供によって送信される鍵確認値を試験するために使用され得る（ステップ４７０）。鍵確認値を生成するための一つの方法は、公開鍵”Ｂ”におけるバイトなどの、既知の文字列を用いて、その鍵をハッシュすることである（ステップ４７０）。その計算は既に述べられたものと類似し得る。サービスの提供は、次いで、その新たな短期公開暗号化鍵‘Ｙ’および鍵確認値ｈＢをユーザに送信する（ステップ４７２）。その鍵値および鍵確認値の転送は、図９における転送ボックス（Ｅ）において示される。
【００７９】
いったんユーザがそれ自体のマスター鍵‘ｋ’を生成すると、最終の鍵確認値を送信し、（Ｆ）に示されるように、全てが正確に作動していることをサービスの提供が知ることを保証する（図８のステップ４５４）。（Ｆ）におけるこの最終ステップは、図９において、サービスの提供への入力として示される（ステップ４７４）。鍵確認値が‘Ａ’に対して計算され、サービスの提供へ送信される場合（ステップ４７４）、これは試験が求めているものである（ステップ４７６）。鍵確認値が期待された値と合致しない場合、動作が中止される（ステップ４７８）。鍵確認値が検証される場合、次いで、完全な双方向の暗号化され、安全なデータ通信経路が存在すると想定される（ステップ４８０）。サーバは、パケットが万が一この新たな鍵生成ステージの間の途中である場合のために、数分間は以前の鍵を保持する（ステップ４８０）。
【００８０】
別の局面に従い、コンピュータ可読キャリア（ｃａｒｒｉｅｒ）の任意の形式は、処理ユニットによって本明細書に記載された方法を実行させるように適合される命令を処理することを含み得る。そのコンピュータ可読キャリアは、固体メモリ（例えば、読み出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）など）、磁気メモリ、光学メモリ、他のタイプのメモリ、または、処理ユニットによって本明細書において記載された技術を実行させるコンピュータ命令の適切なセットを含む変調波／信号（例えば、無線周波数、音声周波数、または光周波数変調波／信号など）の、任意の適切なキャリアであり得る。
【００８１】
例示的な動作方法を含め、本発明の例示的な実施形態において記載されているが、本明細書において記載された動作は、異なる要素およびステップを用いて実行され得ることは理解される。例示的な実施形態は例示の目的のためのみであり、本発明の範囲を限定することは意図されていない。本発明の範囲は請求の範囲によって限定される。
【図面の簡単な説明】
【００８２】
【図１】固定システムとワイヤレスシステムとの間における第１の例示的な通信システムのブロック図である。
【図２】二つのワイヤレスシステムの間における第２の例示的な通信システムのブロック図である。
【図３】二つの固定システムの間における第３の例示的な通信システムのブロック図である。
【図４】図１の通信システムをインプリメントするためのデータ交換の例示的なセットのメッセージ交換図であり、ここで、ユーザがデータ交換の開始者である。
【図５】図１の通信システムをインプリメントするためのデータ交換の例示的なセットのメッセージ交換図であり、ここで、サービスプロバイダがデータ交換の開始者である。
【図６】図４におけるステップを実行するためのユーザソフトウェア内のステップのデータフロー図であり、ここでユーザは鍵交換の開始者である。
【図７】図４におけるステップを実行するためのサービスソフトウェア内のステップのデータフロー図であり、ここでユーザは鍵交換の開始者である。
【図８】図１、図２、および図３において示される環境において、別の鍵を再生成する場合、再鍵シーケンスに対しての、サービスユーザ内におけるステップを示すデータフロー図である。
【図９】図１、図２、および図３において示される環境において、別の鍵を再生成する場合、再鍵シーケンスに対しての、サービスプロバイダ内において必要とされるステップを示すデータフロー図である。
【図１】
2007531422.tif 000003
【図２】
2007531422.tif 000004
【図３】
2007531422.tif 000005
【図４】
2007531422.tif 000006
【図５】
2007531422.tif 000007
【図６】
2007531422.tif 000008
【図７】
2007531422.tif 000009
【図８】
2007531422.tif 000010
【図９】
2007531422.tif 000011
【国際調査報告】
2007531422.tif 000012
2007531422.tif 000013