JP5727093B2

JP5727093B2 - 公開鍵を利用した鍵管理のためのセキュリティアソシエーションの発見

Info

Publication number: JP5727093B2
Application number: JP2014510351A
Authority: JP
Inventors: ケークレフ，ビオレータ; ミジコフスキー，セミヨン・ビー
Original assignee: アルカテル−ルーセント
Priority date: 2011-05-11
Filing date: 2012-04-27
Publication date: 2015-06-03
Anticipated expiration: 2032-04-27
Also published as: KR101516909B1; JP2014514889A; EP2707988B1; US20120288092A1; KR20130140873A; US8644510B2; CN103534975B; WO2012154422A1; EP2707988A1; CN103534975A

Description

本出願は、出願番号６１／４８４８６８として識別される、２０１１年５月１１日に出願した、「ＬａｗｆｕｌＩｎｔｅｒｃｅｐｔｉｏｎＭｅｔｈｏｄｆｏｒＫｅｙＭａｎａｇｅｍｅｎｔＳｃｈｅｍｅｓＲｅｌｙｉｎｇｏｎＰｕｂｌｉｃＫｅｙｓ」という名称の米国仮特許出願の優先権を主張するものであり、その開示は、引用によりその全体が本明細書に組み込まれている。

実施形態は一般に通信セキュリティに関し、より詳細には、通信環境における、情報の合法傍受に使用するためのセキュリティアソシエーションを発見するための技法に関する。

インターネットプロトコル（ＩＰ）通信および電話技術システムは、幅広く採用されている。２つのクライアント間のエンドツーエンドＩＰ通信の第１の例の１つは、インスタントメッセージングを含んでいたが、これには、すぐにボイスオーバーＩＰが続き、現在は多くのプロバイダ（例えばネットワークオペレータおよびアプリケーションプロバイダ）がエンドツーエンドのビデオオーバーＩＰを提供している。しかしながら、これらの傾向は、無線移動ネットワークアクセスが狭帯域回路交換アクセスネットワークによって多数を占められていたので、有線固定ネットワークに大きく限定されていた。しかしながら、広帯域４Ｇ（第４世代）無線ネットワークの最近の開発は、アクセスのタイプに無関係に、ＩＰ通信エンドツーエンドを介したあらゆる形態のマルチメディアのためのステージを設定している。

エンドツーエンドＩＰセッションに向かう変化に伴い、市場は、これらのオープンＩＰネットワークを介したセキュリティおよびプライバシに対する関心ならびに意識の復活を目の当たりにしている。第１のステップとして、エンドツーエンド暗号化および認証は、広範囲にわたる注意を引き付けているパラダイムである。商業および企業インターネットアクセスを含む現代のインターネットトランザクションは、現在、１０年以上にわたってエンドツーエンドを保証しているが、ＩＰを介した会話形アプリケーションの保証は、アプリケーションプロバイダ、例えばＳＫＹＰＥ（ＴＭ）（ルクセンブルクのＳｋｙｐｅＴｅｃｈｎｏｌｏｇｉｅｓＳ．Ａ．の商標）に大きく任されている。

全ＩＰネットワークの出現につれて、ネットワークオペレータまたは音声、ビデオおよびメッセージングサービスを提供している他者にとって、セキュリティアソシエーションの合法傍受および発見を支援する要求事項を遵守しつつ、エンドツーエンドでセキュリティを提供する必要性が増加している。セキュリティアソシエーションのこのような合法傍受および発見は、法的強制目的のため、あるいは単純に何らかの非法的強制目的のためには場合によっては必要であり、したがって当事者および／またはデバイス間で送信される暗号化された情報を解読することができる必要があり、あるいは解読することができることが望ましい。

ＳｅｓｓｉｏｎＤｅｓｃｒｉｐｔｉｏｎＰｒｏｔｏｃｏｌ（ＳＤＰ）ＩｎｔｅｒｎｅｔＥｎｇｉｎｅｅｒｉｎｇＴａｓｋＦｏｒｃｅ（ＩＥＴＦ）ＲｅｑｕｅｓｔｆｏｒＣｏｍｍｅｎｔ（ＲＦＣ）４５６８、「ＳｅｃｕｒｉｔｙＤｅｓｃｒｉｐｔｉｏｎｓｆｏｒＭｅｄｉａＳｔｒｅａｍｓ」、２００６年７月ＩＥＴＦＲＦＣ４１２０、「ＫｅｒｂｅｒｏｓＮｅｔｗｏｒｋＡｕｔｈｅｎｔｉｃａｔｉｏｎＳｅｒｖｉｃｅ」、２００５年７月ＩＥＴＦＲＦＣ６０４３、「Ｔｉｃｋｅｔ−ｂａｓｅｄＭｏｄｅｓｏｆＫｅｙＤｉｓｔｒｉｂｕｔｉｏｎｉｎＭｕｌｔｉｍｅｄｉａＩｎｔｅｒｎｅｔＫｅｙｉｎｇ」、２０１１年３月ＩＥＴＦＲＦＣ２６３１、「Ｄｉｆｆｉｅ−ＨｅｌｌｍａｎＫｅｙＡｇｒｅｅｍｅｎｔＭｅｔｈｏｄ」、１９９９年６月Ｗ．Ｄｉｆｆｉｅ，Ｍ．Ｈｅｌｌｍａｎ、「ＮｅｗＤｉｒｅｃｔｉｏｎｓｉｎＣｒｙｐｔｏｇｒａｐｈｙ」、ＩＥＥＥＴｒａｎｓａｃｔｉｏｎｓｏｎＩｎｆｏｒｍａｔｉｏｎＴｈｅｏｒｙ、ｖｏｌ．ＩＴ−２２、１９７６年１１月、６４４−６５４頁ＤａｎＢｏｎｅｈ、ＭａｔｔｈｅｗＫ．Ｆｒａｎｋｌｉｎ、「Ｉｄｅｎｔｉｔｙ−ＢａｓｅｄＥｎｃｒｙｐｔｉｏｎｆｒｏｍｔｈｅＷｅｉｌＰａｉｒｉｎｇ」ＡｄｖａｎｃｅｓｉｎＣｒｙｐｔｏｌｏｇｙ−ＰｒｏｃｅｅｄｉｎｇｓｏｆＣＲＹＰＴＯ２００１（２００１）ＩＥＴＦＲＦＣｓ５４０８ａｎｄ５４０９ＮａｔｉｏｎａｌＩｎｓｔｉｔｕｔｅｏｆＳｔａｎｄａｒｄｓａｎｄＴｅｃｈｎｏｌｏｇｙ（ＮＩＳＴ）ｉｎＵ．Ｓ．ＦＩＰＳＰＵＢ１９７ＩＥＴＦＲＦＣ３２６１ＢｕｒｍｅｓｔｅｒａｎｄＤｅｓｍｅｄｔ、「ＡｓｅｃｕｒｅａｎｄｅｆｆｉｃｉｅｎｔｃｏｎｆｅｒｅｎｃｅＫｅｙｄｉｓｔｒｉｂｕｔｉｏｎＳｙｓｔｅｍ」、ＰｒｏｃｅｅｄｉｎｇｓｏｆＥｕｒｏｃｒｙｐｔ ’９４、ｖｏｌ．９５０ｏｆＬＮＣＳ、２７５−２８６頁、Ｓｐｒｉｎｇｅｒ１９９５

実施形態例によれば、通信環境における発見可能セキュリティアソシエーションを形成するための技法、および通信環境で形成されるセキュリティアソシエーションを合法的に発見するための技法が提供される。

例えば、一実施形態例では、第１の計算デバイスと第２の計算デバイスの間の発見可能セキュリティアソシエーションを形成するための方法は、以下のステップを含む。第１の計算デバイスが、鍵管理エンティティから以下を入手する：（ｉ）第１の計算デバイスに結合された第１の公開鍵と計算的に連携する、第１の計算デバイスに割り当てられた第１の秘密鍵、および（ｉｉ）第１の計算デバイスに割り当てられた第１のルート鍵。第１の計算デバイスが第１の無作為値を選択し、かつ、第１のルート鍵を使用した第１の無作為値の暗号化の結果である第１のナンスを生成する。第１の計算デバイスが、第１の無作為値に基づいて第１の鍵成分を生成する。第１の計算デバイスが、識別情報ベース暗号化処理を使用して、第１のナンスおよび第１の鍵成分を、第２の計算デバイスに結合された第２の公開鍵で暗号化し、かつ、暗号化された第１のナンスおよび暗号化された第１の鍵成分を第２の計算デバイスに送り、それにより第２の計算デバイスとのセキュリティアソシエーションを確立し、そのセキュリティアソシエーションは、第１の計算デバイスおよび第２の計算デバイスに知られていない第３の計算デバイスによる発見が可能である。

他の実施形態例では、第１の計算デバイスと第２の計算デバイスの間に形成されるセキュリティアソシエーションを発見するための方法は、以下のステップを含む。第３の計算デバイスが、第１の計算デバイスと第２の計算デバイスの間で送信される１つまたは複数のメッセージを入手する。第３の計算デバイスが、第２の計算デバイスに結合された秘密鍵の知識を使用して、第１の計算デバイスから入手した１つまたは複数のメッセージのうちの少なくとも１つを解読し、かつ、以下を得る：（ｉ）第１の計算デバイスによって生成される第１の鍵成分、および（ｉｉ）第２の計算デバイスによって生成されるナンスであって、第２の計算デバイスに一意的に割り当てられるルート鍵を使用した、第２の計算デバイスによって選択される無作為値の暗号化の結果であるナンス。第３の計算デバイスが、第２の計算デバイスのルート鍵の知識を使用して、第２の計算デバイスによって選択された無作為値を入手するためにナンスを解読する。第３の計算デバイスが、第２の計算デバイスによって選択された無作為値の知識および第１の計算デバイスによって生成された第１の鍵成分の知識を使用して、第１の計算デバイスと第２の計算デバイスの間に確立される、第１の計算デバイスおよび第２の計算デバイスに知られていないセキュリティアソシエーションを発見する。

さらに、実施形態例によれば、鍵管理のための公開鍵方法を利用しているシステムにとりわけ適用することができるが、それには限定されない技法を使用した方法であって、エンドツーエンド暗号化セッションのための鍵および他の暗号化データを含むがこれには限定されないセキュリティアソシエーションを合法的に発見する方法が提供される。例えば実施形態は、非対称相互認証鍵交換および／または任意のＤｉｆｆｉｅ−Ｈｅｌｌｍａｎベース鍵交換を実施するシステムおよびプロトコルに従って使用することができる。詳細には、提案されるオーバーレイ手順は、検出不可能であるが、様々なコンプライアンス要求事項を満足する。実施形態は、とりわけインターネットプロトコルマルチメディアサブシステム（ＩＭＳ）環境に適しているが、このような実施形態は、それに限定されることは意図されていないことを理解されたい。つまり、実施形態は、一般に、合法セキュリティアソシエーション発見特徴を提供することが望ましい任意の適切な通信システムに適用することができる。単なる一例にすぎないが、このような技法を適用することができる他の通信システムは、ＩＭＳシグナリングフレームワークまたは任意の他のシグナリングフレームワークに基づく電話会議システムである。

これらおよび他の目的、特徴ならびに利点は、添付の図面に関連して読むべきそれらの例示的な実施形態についての以下の詳細な説明から明らかになるであろう。

クライアントベース鍵転送方法を示す図である。ネットワーク補助鍵転送方法を示す図である。識別情報ベース認証鍵交換方法を示す図である。一実施形態によるナンス交換を含むセッション鍵の合法的発見のための方法を示す図である。一実施形態によるナンス交換を含むセッション鍵の合法的発見のための呼フローを示す図である。一実施形態による電話会議環境におけるナンス交換を含むセッション鍵の合法的発見のための方法を示す図である。実施形態による方法およびプロトコルのうちの１つまたは複数を実施するために適したデータネットワークおよび通信（計算）デバイスの一般化されたハードウェアアーキテクチャを示す図である。

本明細書において使用されている「マルチメディア通信システム」という語句は、一般に、メディア平面を介して、テキストベースデータ、図形ベースデータ、音声ベースデータおよびビデオベースデータを含むが、これらに限定されない、１つまたは複数のタイプのメディアを輸送することができる任意の通信システムとして定義される。

本明細書において使用されている「メディア平面」という語句は、一般に、マルチメディア通信システムの機能部分であって、これに従って１つまたは複数のタイプのメディアが呼セッションにおける複数の当事者間で交換される機能部分として定義される。これは、マルチメディア通信システムの機能部分であって、呼セッションを確立するためにこれに従って呼のネゴシエーション／スケジューリングが実施される機能部分として定義される「制御平面」とは対照的である。本発明による技法を使用することができるメディア平面アプリケーションの例には、それらに限定されないが、ボイスオーバーＩＰ（ＶｏＩＰ）、インスタントメッセージング（ＩＭ）、ビデオ／オーディオＩＭ、ビデオシェアおよびビデオオーバーＩＰがある。メディア平面は、アプリケーション層トラフィックを含むことを理解されたい。しかしながら、本明細書において説明される合法セキュリティアソシエーション発見技法は、通信システムの任意の平面または層に適用することができる。

本明細書において使用されている「鍵」という用語は、一般に、それらに限定されないが、エンティティ認証、プライバシ、メッセージ完全性などの目的のための暗号化プロトコルへの入力として定義される。

本明細書において使用されている「セキュリティアソシエーション」という語句は、一般に、複数の当事者および／またはデバイスがその全体にわたって通信している通信環境におけるセキュリティ定義を意味している。一例では、セキュリティ定義は、それには限定されないがセッション鍵を含むことができる。

本明細書において使用されている「クライアント」は、一般に、１つまたは複数のユーザ、当事者またはエンティティが、通信環境内で他のクライアントなどの１つまたは複数の他の通信デバイスまたは他の計算システムと通信することができる通信デバイスまたは何らかの他の計算システムあるいはデバイスを意味することができる。また、本明細書において使用されている「クライアント」は、一般に、計算デバイス上のアプリケーションまたは他のコンピュータプログラムを意味することも可能である。したがってクライアントという用語は、以下ではデバイスを指すことができるが、クライアントという用語はハードウェアに限定されず、ソフトウェアまたはハードウェアとソフトウェアの組合せであってもよいことを理解されたい。

本明細書において使用されている「通信セッション」は、一般に、２つのデバイス間で通信するための、少なくとも２つの通信デバイスまたは他の計算システム（例えばクライアント）間の接続を意味している。したがって本明細書において使用されている「エンドツーエンド」通信セッションは、一般に、１つのデバイス（例えばクライアント）から他のデバイス（例えばクライアント）までの接続経路全体を意味している。また、通信セッションに関係している複数のクライアントは、「エンドポイントデバイス」または単純に「エンドポイント」と呼ばれる。しかしながら、本明細書において説明される合法セキュリティアソシエーション発見技法は、クライアントだけでなく、任意の計算デバイスまたは通信デバイスに適用することができる。

本明細書において使用されている「アプリケーション」（または「アプリケーションプログラム」）は、一般に、実行されると１つまたは複数の所与の機能を実施する１つまたは複数のコンピュータプログラムを意味している。

本明細書において使用されている「合法」という用語は、一般に、政府または私的な権威ある団体に関連する１つまたは複数のコンプライアンス要求事項またはガイドラインを満足していること、として定義される。このような権威ある団体は、法的強制機能または非法的強制機能の役割を果たすことができる。つまり、合法という用語は、法的強制に限定することは意図されておらず、それどころか非法的強制の意味におけるコンプライアンスを含むことも可能である。

参照を容易にするために、詳細な説明は、以下のように分割されている。節Ｉでは、実施形態例を適用することができる例示的な使用事例およびプロバイダが記述されている。節ＩＩでは、既存のエンドツーエンド鍵管理方法が記述されている。節ＩＩＩでは、既存の鍵解決方法が記述されている。節ＩＶでは、インターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）環境の文脈における、実施形態例による合法セキュリティアソシエーション発見解決法が記述されている。節Ｖでは、実施形態例による１つまたは複数の合法セキュリティアソシエーション発見方法を実施するための例示的な計算システムが記述されている。

Ｉ．例示的な使用事例およびプロバイダ
本明細書において説明される、実施形態例を適用することができる例示的な使用事例は、エンドツーエンド暗号化クライアントツークライアント通信セッションを備えている。単なる一例にすぎず、また、本発明を限定することは一切意図されていないが、このような使用事例は、以下を含む：
１．テキストベースのＩＭまたはインスタントメッセージングアプリケーション
２．インターネットプロトコルエンドツーエンドに基づくマルチメディアメッセージングアプリケーション（オーディオおよび／またはビデオを含む）
３．様々なパケット交換アクセスネットワークを介したボイスオーバーＩＰ
４．様々なパケット交換アクセスネットワークを介したビデオオーバーＩＰ
５．参加者のグループを含むテキストおよびマルチメディアアプリケーションの会議
これらの例示的な使用事例は、様々なプロバイダにも同じように良好に適用される。一例として、プロバイダは３つのカテゴリに分類することができる：
１．サービスのプロバイダは企業であってもよい（最高情報責任者すなわちＣＩＯがアプリケーションのロールアウト、管理および操作を制御する）。企業は法人組織または政府の団体であってもよいことに注意されたい。

２．サービスのプロバイダはアプリケーションプロバイダ（例えばＳｋｙｐｅ、Ｇｏｏｇｌｅｔａｌｋなど）であってもよく、このようなサービスは、ネットワークおよびタイプ全体にわたって「オーバザトップ」で提供される。

３．サービスのプロバイダはネットワークプロバイダ（例えばＶｅｒｉｚｏｎＷｉｒｅｌｅｓｓ、ＡＴ＆Ｔ、Ｓｐｒｉｎｔ、Ｔ−Ｍｏｂｉｌｅ、Ｖｏｄａｆｏｎｅなど）であってもよい。

実施形態例によって説明されている問題および解決法の例示的な範囲は、すべてのプロバイダに等しく十分に適用され、とりわけエンドツーエンド通信タイプまたはアプリケーションに対して断定的ではない。

ＩＩ．エンドツーエンド鍵管理
エンドツーエンドＩＰセッション、また、エンドツーエンドでセキュリティを提供することが望まれることを考えて、複数のエンドツーエンド鍵管理スキームが工夫されている。一例として、ほとんどのこのようなスキームは３つのカテゴリに分類することができる：（１）クライアントベース鍵転送プロトコル、（２）ネットワーク補助鍵転送プロトコル、および（３）非対称相互認証鍵交換プロトコル。

（１）クライアントベース鍵転送プロトコル。図１のプロトコル１００で示されているように、「イニシエータ」（つまり特定の通信セッションを開始するクライアント）と呼ばれるクライアントデバイス１０２−Ｉは、「レスポンダ」（つまりその特定の通信セッションのイニシエータに応答するクライアント）と呼ばれるクライアントデバイス１０２−Ｒに、１つまたは複数のネットワーク要素１０４−１、１０４−２を介して「セキュリティ鍵」を転送するためのセキュアシグナリングに適用することができる既存のホップバイホップセキュアメッセージングスキームを使用する。次に、通信セッションのエンドポイント、すなわちイニシエータおよびレスポンダは、その鍵（またはその派生物）を使用してそのセッションを保証する。図１に示されている例は、セキュアリアルタイムトランスポートプロトコルのための鍵をネゴシエーションするために使用されるプロトコルであるセッション記述プロトコル（ＳＤＰ）に基づいており、例えば、引用によりその開示全体が本明細書に組み込まれている、セッション記述プロトコル（ＳＤＰ）ＩｎｔｅｒｎｅｔＥｎｇｉｎｅｅｒｉｎｇＴａｓｋＦｏｒｃｅ（ＩＥＴＦ）ＲｅｑｕｅｓｔｆｏｒＣｏｍｍｅｎｔ（ＲＦＣ）４５６８、「ＳｅｃｕｒｉｔｙＤｅｓｃｒｉｐｔｉｏｎｓｆｏｒＭｅｄｉａＳｔｒｅａｍｓ」、２００６年７月を参照されたい。このような場合、クライアント１０２−Ｉは、セキュリティ鍵を含むＳＤＰオファーをネットワーク（エンドツーエンド）を介してクライアント１０２−Ｒに送り、また、クライアント１０２−Ｒは、同じくセキュリティ鍵を含むＳＤＰアンサで応答し、それによりその特定のセッションに関連する通信を保証するために使用される一対のセキュリティ鍵が確立される。セッションを設定している間、セキュリティ鍵の転送に関与するすべての当事者がその鍵に対する完全なアクセスを有しており、したがって２つのクライアント間のセッションの機密に気付いていることは容易に分かる。

（２）ネットワーク補助鍵転送プロトコル。図２のプロトコル２００で示されているように、クライアントデバイス２０２−Ｉ（イニシエータ）は、プロバイダネットワーク（すなわちデータセンタ）内のサーバ２０４（鍵管理サーバすなわちＫＭＳ）から所与のセッションのための鍵を要求し、それに引き続いて鍵およびその鍵に対する「ポインタ」（チケットまたはトークンの形態の）がサーバ２０４からイニシエータに引き渡される。イニシエータは、次に、セキュアシグナリングに適用することができる既存のホップバイホップセキュアメッセージングスキームを使用してクライアントデバイス２０２−Ｒ（レスポンダ）と「ポインタ」を共有し、それに引き続いてレスポンダは、「ポインタ」をサーバ２０４に提示することによってサーバ２０４から鍵を入手する。このようなネットワーク補助プロトコルの２つの例には、ＩＥＴＦＲＦＣ４１２０、「ＫｅｒｂｅｒｏｓＮｅｔｗｏｒｋＡｕｔｈｅｎｔｉｃａｔｉｏｎＳｅｒｖｉｃｅ」、２００５年７月に記載されているＫｅｒｂｅｒｏｓシステム、およびＩＥＴＦＲＦＣ６０４３、「Ｔｉｃｋｅｔ−ｂａｓｅｄＭｏｄｅｓｏｆＫｅｙＤｉｓｔｒｉｂｕｔｉｏｎｉｎＭｕｌｔｉｍｅｄｉａＩｎｔｅｒｎｅｔＫｅｙｉｎｇ」、２０１１年３月に記載されているＭＩＫＥＹ−Ｔｉｃｋｅｔシステムがあり、これらの開示は、引用によりその全体が本明細書に組み込まれている。ＫＭＳはセキュリティ鍵のすべての知識を有しており、したがって２つのクライアント間のセッションの機密に気付いていることは理解されよう。

（３）非対称公開鍵プロトコルを使用した認証鍵交換。このタイプのプロトコルでは、イニシエータおよびレスポンダは、それぞれ一対の鍵（秘密および公開）を所有している。典型的な例は、認証のためのそれらの秘密鍵の使用を含むが、互いにアドレス指定するための公開鍵の使用は、鍵交換のための公開鍵方法と共に含まれていない。図３のプロトコル３００は、ＩＢＡＫＥ（識別情報ベース認証鍵交換）プロトコルおよび非対称公開鍵方法の使用を示したものである。ＩＢＡＫＥプロトコルは、引用によりその開示全体が本明細書に組み込まれている、２００９年２月１７日に出願した、出願番号１２／３７２２４２で識別される米国特許出願に記載されている。

図３のプロトコル３００で示されているように、ＩＢＡＫＥプロトコルは、２つのエンドポイント間の相互認証および鍵交換を定義している：イニシエータＡ（クライアント３０２−Ａ）およびレスポンダＢ（クライアント３０２−Ｂ）。イニシエータおよびレスポンダは、いずれもそれぞれ一対の鍵、すなわちそれらの公開鍵および秘密鍵を有している。公開鍵暗号手法の場合と同様、公開鍵は暗号化のために使用され、また、秘密鍵は解読のために使用される。標準公開鍵方法と識別情報ベース公開鍵方法の間の基本的な相違は、識別情報ベース公開鍵方法では、公開鍵は「識別情報」に対応し、また、対応する秘密鍵は、信用されたサーバ（鍵管理サーバすなわちＫＭＳと呼ばれる）によって生成されることである。

図に示されているプロトコルの主な概念は、イニシエータおよびレスポンダが互いに認証し、かつ、鍵管理サーバ（図示せず）によって提供される秘密鍵を使用してセッション鍵を生成し、また、交換した鍵成分を使用してセッション鍵を生成することであるが、まだサーバはセッション鍵を決定することができない。

図３では、イニシエータＡは、無作為機密「ｘ」を選択し、かつ、「ｘＰ」をレスポンダＢに送る前に値「ｘＰ」（Ｐは、有限体上の楕円曲線上の一点である）を計算することが分かる。同様に、レスポンダは、無作為機密「ｙ」を選択し、かつ、「ｙＰ」をイニシエータＡに送る前に値「ｙＰ」を計算する。イニシエータは、「ｘ」および「ｙＰ」を使用して「ｘｙＰ」を計算する。同様に、レスポンダは、「ｙ」および「ｘＰ」を使用して「ｘｙＰ」を計算する。これにより両方の当事者が通信セッションのための鍵に合意することができる。しかしながら、鍵管理サーバ（ＫＭＳ）は「ｘＰ」および「ｙＰ」に対するアクセスは有しているが、「ｘｙＰ」を計算することはできない。

上で列挙したすべての（３つの）鍵転送／交換プロトコルでは、通信タイプまたはプロバイダに無関係に、エンドツーエンドセキュリティ鍵の発見および共有をプロバイダに合法的に要求することができる（「合法発見」と呼ばれる）規定および／またはコンプライアンス要求事項が存在することが認識される。

プロトコルタイプ１および２の場合、この要求事項は比較的容易に満足することができる。プロトコルタイプ１（図１）では、重要なセキュリティ鍵は、ホップバイホップ保護を有するネットワークのノード間で輸送され、したがって輸送に含まれるネットワークノード（例えば図１のネットワーク要素１０４−１、１０４−２）に知られる。プロトコルタイプ２（図２）では、セッション鍵はサーバ（例えば図２のＫＭＳ２０４）によって生成され、したがってプロバイダはそれを利用することができる。

しかしながらプロトコルタイプ３（図３）の場合、プロバイダが鍵管理トランザクションに対する唯一のイネーブラーであり、かつ、トランザクションの参加者ではない場合、この合法発見問題はとりわけ厄介である。簡潔に言うと、この問題は、とりわけエンドツーエンド鍵管理のために非対称公開鍵プロトコルが使用される場合に、エンドツーエンドセキュリティ鍵を発見することである。さらに、このような発見は、通信セッションの間、控え目で、かつ、検出不可能であることが要求される。

ＩＩＩ．非対称公開鍵プロトコルにおける鍵解決法
この節では、エンドツーエンド鍵管理のための非対称公開鍵プロトコルにおける鍵解決法の既存の方法について説明する。

（１）包括的なプロトコル説明
ここでは、とりわけＤｉｆｆｉｅ−Ｈｅｌｌｍａｎタイプの鍵交換（例えば、引用によりその開示全体が本明細書に組み込まれているＩＥＴＦＲＦＣ２６３１、「Ｄｉｆｆｉｅ−ＨｅｌｌｍａｎＫｅｙＡｇｒｅｅｍｅｎｔＭｅｔｈｏｄ」、１９９９年６月を参照されたい）を利用するプロトコルに的を絞る。素数ｐを法とする有限体の乗法群に関してＤｉｆｆｉｅおよびＨｅｌｌｍａｎによって彼らのランドマークペーパ（引用によりその開示全体が本明細書に組み込まれている、Ｗ．Ｄｉｆｆｉｅ，Ｍ．Ｈｅｌｌｍａｎ、「ＮｅｗＤｉｒｅｃｔｉｏｎｓｉｎＣｒｙｐｔｏｇｒａｐｈｙ」、ＩＥＥＥＴｒａｎｓａｃｔｉｏｎｓｏｎＩｎｆｏｒｍａｔｉｏｎＴｈｅｏｒｙ、ｖｏｌ．ＩＴ−２２、１９７６年１１月、６４４−６５４頁）の中で典型的に説明されているプロトコルについて説明する。しかしながら、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎプロトコルは、任意の群に拡張することができるが、プロトコルのセキュリティは、その群の特性を利用していることはよく知られている。

このプロトコルでは、２つのエンドポイント（ＡおよびＢ）の各々が、Ｇが大素数Ｐを法とする非ゼロ整数の乗法群の生成元であるよう、公に知られているＧ（生成元）およびＰ（大素数）の値を選択する。

プロトコルを実行するために、Ａは無作為機密ｘを選択し、かつ、ａ＝Ｇ＾ｘ（ｍｏｄＰ）を計算する。同様に、Ｂは無作為機密ｙを選択し、かつ、ｂ＝Ｇ＾ｙ（ｍｏｄＰ）を計算する。機密ｘおよびｙは、Ｐより小さい無作為の正の整数であることを理解されたい。

Ａは次に値ａをＢに送り、また、Ｂは値ｂをＡに送る。

Ａは、値ｂを受け取るとｋ＝ｂ^＊ｘ（ｍｏｄＰ）を計算し、同様にＢは、値ａを受け取るとｋ＝ａ^＊ｙ（ｍｏｄＰ）を計算する。ｋ＝（ａ）^＊ｙ（ｍｏｄＰ）＝（ｂ）^＊ｘ（ｍｏｄＰ）であり、また、ｋは相互計算された共通セッション鍵であることは容易に分かる。

（２）ＩＢＡＫＥにおけるＤｉｆｆｉｅ−Ｈｅｌｌｍａｎの特殊な使用
ＩＢＡＫＥプロトコル（図３に示されている）は、有限体上の楕円曲線上の点の群を利用し、したがって有限体上の楕円曲線内の点の群に関する対応するＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ問題を利用する。個々のエンドポイント（例えばＡ）は、Ａ（ＰＵＢ＿Ａ）のための公開鍵を生成するために任意の他のエンドポイント（例えばＢ）が使用することができる知られている公開識別情報を有している。同様に、Ｂの公開識別情報を知ることにより、任意の他のエンドポイントはＰＵＢ＿Ｂを生成することができる。

個々のエンドポイント（例えばＡ）は、時々および周期的に、秘密ネットワークベース機能である鍵管理サーバ（ＫＭＳ）と接触し、対応する公開鍵（ＰＵＢ＿Ａ）と計算的に結合している特別に計算された秘密鍵（例えばＰＲ＿Ａ）を受け取る。同様に、他のエンドポイントも同じことを実施する。その結果、個々のエンドポイントは、公開鍵がそのエンドポイントの識別に基づいている間、公開−秘密鍵対を所有する。

プロトコルを実行するために、個々のエンドポイントは無作為機密番号を選択する。ｘをＡによって選択された乱数とし、かつ、ｙをＢによって選択された乱数とする。

第１のステップで、Ａは、Ｐが楕円曲線Ｅ上の公に知られている点であるｘＰを計算し（つまり加法を使用してＰ自身がｘ回加えられる）、Ｂの公開鍵ＰＵＢ＿Ｂを使用してそれを暗号化し、かつ、それをＢに送信する。このステップでは、暗号化は、ＤａｎＢｏｎｅｈ、ＭａｔｔｈｅｗＫ．Ｆｒａｎｋｌｉｎ、「Ｉｄｅｎｔｉｔｙ−ＢａｓｅｄＥｎｃｒｙｐｔｉｏｎｆｒｏｍｔｈｅＷｅｉｌＰａｉｒｉｎｇ」ＡｄｖａｎｃｅｓｉｎＣｒｙｐｔｏｌｏｇｙ−ＰｒｏｃｅｅｄｉｎｇｓｏｆＣＲＹＰＴＯ２００１（２００１）、およびＩＥＴＦＲＦＣｓ５４０８ａｎｄ５４０９に記載されている識別情報ベース暗号化を意味しており、これらの開示は、引用によりその全体が本明細書に組み込まれている。

Ｂは、暗号化されたメッセージを受け取ると、そのメッセージを解読してｘＰを得る。

引き続いてＢはｙＰを計算し、かつ、Ａの公開鍵ＰＵＢ＿Ａを使用して対｛ｘＰ、ｙＰ｝を暗号化し、次にそれをＡに送信する。

Ａは、このメッセージを受け取ると、そのメッセージを解読してｙＰを得る。引き続いてＡは、Ｂの公開鍵を使用してｙＰを暗号化し、それをＢに送り返す。

これに引き続いて、ＡおよびＢの両方がセッション鍵としてｋ＝ｘｙＰを計算する。明確にすると、Ａは、受け取った解読されたｙＰ自体をｘ回加えることによってｋ＝ｘｙＰを計算する。同様に、Ｂは、受け取った解読されたｘＰ自体をｙ回加えることによってｋ＝ｙｘＰを計算する。

（３）セッション鍵の合法発見のためのＭａｎ−Ｉｎ−Ｔｈｅ−ＭｉｄｄｌｅＫｅｙＲｅｓｏｌｕｔｉｏｎ
Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ鍵交換のための典型的で、かつ、よく知られている鍵発見方法は、いわゆる「ｍａｎ−ｉｎ−ｔｈｅ−ｍｉｄｄｌｅ」（ＭｉｔＭ）方法に基づいている。この方法では、能動中間物Ｃが自身をエンドポイントＡとＢの間の通信リンク中に置く。この中間物Ｃは、自身、Ａに対してはＢとして出現し、また、Ｂに対してはＡとして出現する。

中間物Ｃは、自身の機密ｘ’およびｙ’を生成する。Ｃは、Ａからａを受け取ると、ｂ’＝Ｇ＾ｙ’（ｍｏｄＰ）で応答し、同様にａ’＝Ｇ＾ｘ’（ｍｏｄＰ）をＢに送る。

交換が完了すると、ＡおよびＣは、ｋ１＝（Ｇ＾ｘ（ｍｏｄＰ））^＊ｙ’（ｍｏｄＰ）＝（Ｇ＾ｙ’（ｍｏｄＰ））＊ｘ）（ｍｏｄＰ）を生成し、一方、ＣおよびＢは、ｋ２＝（Ｇ＾ｘ’（ｍｏｄＰ））＊ｙ（ｍｏｄＰ）＝（Ｇ＾ｙ（ｍｏｄＰ））＊ｘ’（ｍｏｄＰ）を生成する。その結果、ＡおよびＢを使用して２つの独立したセキュアセッションを維持することにより、能動中間物Ｃは、ＡとＢの間の通信を解読し、かつ、再暗号化することができる。

しかしながら、いくつかの高性能エンドポイントデバイスの場合、相互に計算された鍵の画像表現またはシグネチャ表現のいずれかを交換し、かつ、実際、それらが計算した２つの異なる鍵を実現することが可能である。これは、セッション鍵の合法発見には望ましくないＭｉｔＭ機能の発見をもたらすことになる。

（４）機密の強制生成による鍵解決法
他の方法は、セッション鍵の合法発見に関与する専用ネットワークノードに同じく知られている機密（ｘ）を生成するよう、複数のエンドポイントのうちの少なくとも１つ（例えばＡ）に強制する。このスキームでは、エンドポイントＡは機密ｘを選択しないが、その代わりにネットワークがナンス（Ｎ）などの専用パラメータを送るのを待機し、次に、ネットワークと共有している他の機密（Ｓ）と共にこのナンスをハッシュする。その結果、エンドポイントＡおよび専用ネットワークノードの両方がｘ＝Ｈ（Ｓ、Ｎ）を生成する。引き続いて、この生成されたｘがＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ交換における指数として使用される。

専用ネットワークノードは、ｋ＝（Ｇ＾ｙ（ｍｏｄＰ））^＊ｘ（ｍｏｄＰ）を計算することができ、したがってＡとＢの間の通信リンクの機密鍵に関与することになることは容易に分かる。

しかしながら、ナンスの受取りを期待することにより、エンドポイントデバイスは、その存在およびセッション鍵を合法的に発見するネットワークの意図が完全に気付かれることになり、これは極度に望ましくない。詳細には、この鍵発見解決法は、通信セッションの間、結託するエンドポイントデバイスによる検出が可能であり、さらに、この解決法が機能するのは、結託するエンドポイントデバイスが存在している場合のみである。

（５）エスクローサーバへの鍵転送
さらに他の方法は、ネットワークノードからエンドポイントデバイスに送られる特殊な要求に基づいている。この要求により、エンドポイントデバイスは、ネットワークベース鍵エスクローデータベースへのＡ−Ｂ通信リンクを暗号化するために使用される計算済み鍵ｋまたはその派生物をアップロードするように強制される。このアップロードは、通常、エンドポイントと鍵エスクローデータベースの間で確立されるセキュアトンネルを使用した保護の下で実施される。

しかしながら、このような要求を受け取るエンドポイントデバイスは、鍵エスクローデータベースが存在すること、延いてはセッション鍵の合法発見のためには望ましくないセキュア通信の可能傍受が存在することを明らかに認識している。

（６）「無作為機密」の再生成による鍵解決法
引用によりその開示全体が本明細書に組み込まれている、２０１１年４月２９日に出願した、「ＤｉｓｃｏｖｅｒｙｏｆＳｅｃｕｒｉｔｙＡｓｓｏｃｉａｔｉｏｎｓ」という名称の米国特許出願第１３／０９７１８４号に記載されている方法では、鍵発見問題は、通信セッションにおける少なくとも１つの参加者の「無作為機密」を発見するプロバイダを利用している。詳細には、この方法は以下のように動作する。プロバイダがクライアントアプリケーションに擬似乱数生成元（ＰＲＧ）を埋め込む。オペレータまたはアプリケーション所有者、例えば企業が、クライアント識別情報と結合している機密無作為シード（Ｓ）を有するアプリケーションを事前構成する。この無作為シードは、典型的には乱数であり、あるいはより一般的には少なくとも１つの乱数を含む一組の番号である。この連携、つまりシードと識別は、オペレータまたはアプリケーション所有者、例えば企業によって管理されるサーバに記憶される。Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ、ＩＢＡＫＥなどの鍵交換プロトコルを実行するために、アプリケーションがセッションのための乱数（例えばｘ）の生成を必要とする場合、ＰＲＧが呼び出される。ＰＲＧは、シードを使用して、また、時刻表示または外部管理計数器（Ｃ）などの決定論的に、かつ、単調に増加する量を使用して、要求された擬似無作為値ｘを生成する。合法傍受が許可されると、ネットワーク内の傍受エンティティは、すべての必要な情報を他のネットワークノードに要求するが、エンドポイント自体には要求しない。したがってエンドポイントは、試行されている傍受に気が付かない。このような方法は検出不可能であるが、ネットワーク内に追加エンティティ（すなわち企業サーバ）が必要であり、また、クライアントには、「無作為機密」を生成／再生成するための秘密ソフトウェアが必要である。

ＩＶ．改良型合法セキュリティアソシエーション発見
例示的な一実施形態によれば、鍵発見問題に対する解決法であって、定期的メッセージ交換の間、通信セッション中に２つのクライアントデバイス（エンドポイント）の間で交換されるナンスを利用する解決法が提供される。詳細には、この方法（以下でより詳細に説明する）は以下のように動作する。

図４のＩＢＡＫＥベースプロトコル４００で示されているように、エンドポイント（例えば４０２−Ａ）がＫＭＳ（図４には明確に示されていない）と接触し、対応する公開鍵（ＰＵＢ＿Ａ）と計算的に結合している特別に計算された秘密鍵（例えばＰＲ＿Ａ）を受け取ると、ＫＭＳも同じくユーザ毎のルート鍵（ＲＫ＿Ａ）を含む。このルート鍵は、ＫＭＳおよび秘密鍵を要求しているエンドポイントユーザのみに知られている。図３のＩＢＡＫＥベースプロトコルに関連して上で説明したように、エンドポイントＡ（ここでは４０２−Ａ）がプロトコルの実行を必要とすると、エンドポイントＡは無作為機密ｘを選択する。次に、エンドポイントＡは、ＲＫ＿Ａおよびこの無作為機密ｘを使用してＡ＿Ｎｏｎｃｅを生成する。言い換えると、例示的な実施形態によれば、Ａ＿Ｎｏｎｃｅは、無作為機密ｘの暗号化された値を表している。Ａ−Ｎｏｎｃｅを生成するための例示的な一方法は以下の通りである。

Ａ＿Ｎｏｎｃｅ＝ＡＥＳ_{ＲＫＡ}（ｘ）
上式でＡＥＳは、引用によりその開示全体が本明細書に組み込まれている、２００１年１１月２６日付けのＮａｔｉｏｎａｌＩｎｓｔｉｔｕｔｅｏｆＳｔａｎｄａｒｄｓａｎｄＴｅｃｈｎｏｌｏｇｙ（ＮＩＳＴ）ｉｎＵ．Ｓ．ＦＩＰＳＰＵＢ１９７によって明記されているアドバンストエンクリプションスタンダード（ＡｄｖａｎｃｅｄＥｎｃｒｙｐｔｉｏｎＳｔａｎｄａｒｄ）アルゴリズムである。

エンドポイントＡ（４０２−Ａ）は、次に、エンドポイントＢに送られる第１のメッセージ（図４のメッセージ１）にこのＡ＿Ｎｏｎｃｅを含める。同様にＢ（４０２−Ｂ）はｙを選択し、また、Ｂ＿Ｎｏｎｃｅを生成し（Ｂ＿Ｎｏｎｃｅ＝ＡＥＳ_ＲＫ＿Ｂ（ｙ））、かつ、Ａに送られるメッセージ（図４のメッセージ２）に受け取ったＡ＿Ｎｏｎｃｅおよびこの生成されたＢ＿Ｎｏｎｃｅの両方を含める。

最後に、エンドポイントＡ（４０２−Ａ）は、第３のメッセージ（図４のメッセージ３）に受け取ったＢ＿Ｎｏｎｃｅを含める。メッセージ４を介して検証が実施される。

個々のエンドポイントに対して、対応するエンドポイントから受け取ったナンスの値は、乱数と区別することはできず、したがってこの値は、処理する必要も、認識する必要もないナンスとして処理されることを理解されたい。

合法傍受が許可されると、ネットワーク内の傍受エンティティ（図４には明確に示されていない）は、通信セッションに関与するエンドポイントクライアントに知られていないすべての必要な情報（つまり秘密鍵およびルート鍵）をＫＭＳに要求する。傍受エンティティは、次に、受け取ったルート鍵を使用して無作為機密を入手し、次に、傍受エンティティは、入手した無作為機密およびＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ交換で交換した残りの鍵成分を使用してセッション鍵を生成する。

一般に、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎベースのプロトコルの機密性は、自身の無作為機密についてのクライアントの知識、および対応するエンドポイントによって自身の無作為機密から生成される成分の値を利用している。図４に示されている例では、エンドポイントＡ（４０２−Ａ）は、機密である乱数ｘを生成し、かつ、維持し、一方、エンドポイントＢ（４０２−Ｂ）は、機密である乱数ｙを生成し、かつ、維持する。エンドポイントの各々は、それらの個々の無作為機密を処理し、とりわけ無作為機密にＥｌｌｉｐｔｉｃＣｕｒｖｅ上の点を表す値Ｐを掛け合わせる。得られた値ｘＰおよびｙＰがエンドツーエンドシグナリングを介して交換される。ｘＰおよびｙＰの両方の知識が、ｘｙＰで表される期待セッション鍵の再生成に役立つわけではない。しかしながら、自身の機密（Ａの場合はｘ、また、Ｂの場合はｙ）を知っている個々のエンドポイントは、期待セッション鍵を計算することができる。エンドポイントＡの場合、セッション鍵ｋ＝ｘ^＊ｙＰであり、また、エンドポイントＢの場合は鍵ｋ＝ｙ^＊ｘＰである。

例えば、図４では、エンドポイントＢ（４０２−Ｂ）が傍受のターゲットであると仮定する。したがって法強制監視局ノード（ＬＥＭＦ）は、ＫＭＳからＲＫ＿ＢおよびＰＲ＿Ｂを入手する。Ｂが通信に加わると、通信ネットワークノード（例えばＰ／Ｓ−ＣＳＣＦ）がＩＭＳメッセージ事象を傍受し、かつＬＥＭＦ（傍受サーバ）に報告する。別法としては、ＬＥＭＦは、Ｐ／Ｓ−ＣＳＣＦを使用することなく、エンドポイント間で送られるＩＭＳメッセージ事象を直接傍受することも可能である。ＳＩＰは、セッション開始プロトコル（引用によりその開示全体が本明細書に組み込まれているＩＥＴＦＲＦＣ３２６１）を表し、また、Ｐ／Ｓ−ＣＳＣＦは、プロキシ呼制御機能またはサービング呼制御機能のいずれかを表わしていることに留意されたい。ＬＥＭＦは、傍受したＩＭＳシグナリングから暗号化に関連する情報（すなわちｘＰおよびＢ＿Ｎｏｎｃｅ）を抽出し、また、ＬＥＭＦは、抽出したこの情報およびＲＫ＿ＢならびにＰＲ＿Ｂを使用してメッセージを解読し、かつ、セッション鍵ｋ＝ｘｙＰを生成する。

とりわけこの例では、ＬＥＭＦは、メッセージ１（図４）の交換を処理することができる。エンドポイントＢ（ＰＲ＿Ｂ）の秘密鍵を知ることにより、ＬＥＭＦは、Ｂ（ＰＵＢ＿Ｂ）の公開鍵を使用してエンドポイントＡによって最初に暗号化されたＩＢＥ暗号化ペイロードを解読することができる。ＬＥＭＦは、このペイロードからｘＰ値を入手することができる。次に、ＬＥＭＦは、メッセージ３（図４）の交換を処理することができる。ＰＲ＿Ｂを知ることにより、ＬＥＭＦは、Ｂ（ＰＵＢ＿Ｂ）公開鍵を使用してエンドポイントＡによって最初に暗号化されたＩＢＥ暗号化ペイロードを解読することができる。ＬＥＭＦは、このペイロードからＢ＿Ｎｏｎｃｅを入手することができる。次に、ＬＥＭＦは、知られているＲＫ＿Ｂを使用してＢ＿Ｎｏｎｃｅ値を解読し、かつ、値ｙを入手することができる。最後に、ｘＰおよびｙを知ることにより、ＬＥＭＦは、ｋ＝ｙ^＊ｘＰとしてセッション鍵を生成することができる。

他の例では、エンドポイントＡ（４０２−Ａ）が傍受のターゲットであると仮定すると、ＬＥＭＦは、ＰＵＢ＿Ａに加えて、ＫＭＳからＲＫ＿ＡおよびＰＲ＿Ａを入手する。ＬＥＭＦは、メッセージ２（図４）の交換を処理することができる。エンドポイントＡ（ＰＲ＿Ａ）の秘密鍵を知ることにより、ＬＥＭＦは、Ａ（ＰＵＢ＿Ａ）の公開鍵を使用してエンドポイントＢによって最初に暗号化されたＩＢＥ暗号化ペイロードを解読することができる。ＬＥＭＦは、このペイロードからｙＰ値を入手することができる。次に、ＬＥＭＦは、このペイロードからＡ＿Ｎｏｎｃｅ値を入手し、かつ、知られているＲＫ＿Ａを使用してＡ＿Ｎｏｎｃｅ値を解読することができ、したがって値ｘを入手することができる。最後に、ｙＰおよびｘを知ることにより、ＬＥＭＦは、ｋ＝ｘ^＊ｙＰとしてセッション鍵を生成することができる。

ＬＥＭＦは、必要なすべての情報を他のネットワークノードに要求するが、エンドポイント自体には要求しないことが分かる。したがってエンドポイントは、試行されている傍受に気が付かない。また、この情報交換（傍受エンティティがＫＭＳから情報を入手する）は、通信セッションが実際に開始される前の任意の時間に実施することができる。これによりネットワーク要素間に必要な調整に関連する複雑性が劇的に緩和される。

次に図５を参照すると、図４のＩＢＡＫＥベース実施形態によるナンス交換を含む、セッション鍵の合法発見のための例示的な呼フローが示されている。理解を容易にし、また、一貫性を維持するために、呼フロー中のエンドポイント要素（４０２−Ａおよび４０２−Ｂ）には、図４に示されている参照数表示と同じ参照数表示を使用して番号が振られていること、また、傍受エンティティは傍受サーバ５０２として描かれており、ＫＭＳはＫＭＳサーバ５０４として描かれていることに留意されたい。また、本明細書において説明されている合法セキュリティアソシエーション発見技法は、何らかの特定のプロトコルとの使用に限定されず、したがってこの実施形態には、例示目的のためにＩΒΑΚΕベースプロトコルが使用されていることに留意されたい。

図５に示されているように、ステップ１、２および３は、図３の文脈で上で説明したように、エンドポイントＡ（４０２−Ａ）とＢ（４０２−Ｂ）の間の典型的なＩＢＡＫＥプロトコル交換を表している。ステップ４は検証メッセージである。ＡまたはＢのどちらかが合法傍受のためのターゲットにされると、傍受サーバ５０２は、これらのシグナリングトランザクションを監視し、かつ、記録する。

図５のステップ５および６では、傍受サーバ５０２（図４の説明の中で上で説明したＬＥＭＦであってもよい）は、傍受のターゲット（例えばＢ）のための１つまたは複数の秘密鍵およびルート鍵をＫＭＳ５０４に要求する。このトランザクションは、実際のＩＢＡＫＥ事象のはるかに前に実施することができる。このような場合、ターゲットの１つまたは複数の秘密鍵およびルート鍵は、ＡおよびＢが通信を開始する際には傍受サーバ５０２側で既に利用可能である。

別法としては、傍受サーバ５０２は、同じ技法を使用してセッション鍵を派生させ、かつ、それをＬＥＭＦに戻すために、エンドポイント間のすべてのメッセージのコピーをＫＭＳに提供し、ターゲットにされたエンドポイントに対する必要なすべての機密パラメータの知識を有することをＫＭＳに期待する。

したがって上で参照した米国特許出願第１３／０９７１８４号に記載されている方法と比較すると、図４および５の文脈で説明した本発明によるナンスベース解決法は、有利には、企業サーバが関与せず、また、「無作為機密」を生成／再生成するための専用ソフトウェアがクライアントにおいて関与していない。

したがって、本明細書において詳細に説明されている内容を要約すると、図３に関連して上で説明したＩＢＡＫＥプロトコルでは、第１のクライアント（エンドポイント）が第２のクライアント（エンドポイント）からｙＰを受け取ると、第１のクライアントはｙを知る必要はない。第１のクライアントに必要であるのは、受け取ったｙＰに、第１のクライアントが機密を知り、かつ、維持しているｘを掛け合わせることだけである。第２のクライアントに対しても同様であり、つまり第２のクライアントがｘＰを受け取ると、第２のクライアントに必要であるのは、ｘＰに、第２のクライアントが機密を知り、かつ、維持しているｙを掛け合わせることだけである。両側におけるこの掛算により、セッション鍵（セキュリティアソシエーションとも呼ばれる）であるｘｙＰが得られる。

つまり、ＩＢＡＫＥプロトコルでは、ｘＰおよびｙＰがＩＢＥ暗号化の下で双方向で交換される。第１のクライアントは、第２のクライアントの公開鍵を使用してｘＰを暗号化する。その公にされた公開鍵に対応する秘密鍵を有しているのは第２のクライアントのみであるため、第２のクライアントのみがそれを解読することができる。同様に、鍵成分ｙＰが、第１のクライアントの公開鍵を有するＩＢＥ暗号化を使用して、第２のクライアントによって第１のクライアントに送られる。第１のクライアントは、その公にされた公開鍵に対応する秘密鍵を有しているため、第１のクライアントのみがそれを解読することができる。受け取った鍵成分を２つのクライアントが互いに送り返すと、それらは、それらのピアを暗に認証する。

有利には、本明細書において説明されている例示的な実施形態によれば、ＩＢＡＫＥプロトコル（図４および５に示されてる）におけるナンスの利用が提供される。つまり、第１のクライアントがその鍵成分ｘＰを第２のクライアントに送る場合、第１のクライアントは、同じく、無作為機密ｘの暗号化された値を送る。この暗号化された値は、上でＡ＿ＮＯＮＣＥで参照されているものである。同様に、第２のクライアントがその鍵成分ｙＰを第１のクライアントに送る場合、第２のクライアントは、その鍵成分ｙＰに自身の無作為機密ｙの暗号化された値、すなわちＢ＿Ｎｏｎｃｅを付随させる。言い換えると、本発明によるプロトコルでは、無作為機密の暗号化された値には、この無作為機密に基づく鍵成分が付随し、対応するピアの公開鍵を使用することによってこの組合せが常にＩＢＥ暗号化される。

したがってセッション鍵を回復するために、傍受者は２つのレベルの保護をかいくぐる：（１）鍵成分および関連するナンスを含む「鍵化カプセル」を解読し、かつ、対応するノードから他の鍵成分を受け取るために、ターゲットの秘密鍵を入手し、および（２）ターゲットの無作為機密に関連するナンスを解読する、つまり無作為機密自体を回復する。他の対応するクライアントの無作為機密またはターゲットおよび鍵成分を有することにより、傍受者はセッション鍵を複製することができる。

次に、電話会議環境などのグループ設定を参照する。電話会議では、参加者のグループが鍵マテリアルを交換し、かつ、グループ鍵に合意する。詳細には、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ鍵交換がグループ設定まで拡張されており（例えば、引用によりその開示全体が本明細書に組み込まれている、ＢｕｒｍｅｓｔｅｒａｎｄＤｅｓｍｅｄｔ、「ＡｓｅｃｕｒｅａｎｄｅｆｆｉｃｉｅｎｔｃｏｎｆｅｒｅｎｃｅＫｅｙｄｉｓｔｒｉｂｕｔｉｏｎＳｙｓｔｅｍ」、ＰｒｏｃｅｅｄｉｎｇｓｏｆＥｕｒｏｃｒｙｐｔ ’９４、ｖｏｌ．９５０ｏｆＬＮＣＳ、２７５−２８６頁、Ｓｐｒｉｎｇｅｒ１９９５を参照されたい）、また、さらにＩＢＡＫＥがグループ設定におけるアドレス認証鍵交換まで拡張されている（例えば、引用によりその開示全体が本明細書に組み込まれている、２００９年８月２８日に出願した、出願番号１２／５４９９０７で識別されている米国特許出願を参照されたい）。この例における「グループ設定」という語句は、３つ以上のユーザのグループを意味しており、また、プロトコルは、すべてのユーザによる非セキュア環境における情報の交換および適用可能である場合は「グループ鍵」の交換を許すが、会議システムに限定されないことが分かる。

図６は、一実施形態による電話会議環境におけるナンス交換を含むセッション鍵の合法的発見のための方法６００を示したものである。詳細には、図６は、ＩＢＡＫＥを使用したグループ鍵交換を示している。この設定では、中央調整サーバ６０４（会議セキュリティサーバまたは会議サーバと呼ばれる）は、個々のユーザ（デバイス６０２−１から６０２−Ｎ）を認証し、かつ、グループ鍵交換への参加を許可する。しかしながら、ＩＢＡＫＥ計算によって得られるグループ鍵は、中央調整サーバ６０４に知られていない。しかしながら、コンプライアンス要求事項および他の規定要求事項のため、グループ鍵を発見するためには会議プロバイダは依然としてしばしば必要である。

図に示されているように、個々のユーザは、会議サーバを使用して個々にＩＢＡＫＥを実行する。これによりサーバは、認証され、かつ、許可された参加者のみが呼を許されることを保証することができる。これに引き続いて、サーバは、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ鍵成分を呼におけるすべてと共有し、それにより個々の参加者は、追加鍵成分を計算し、かつ、残りの参加者と共有することができる（サーバを介して）。すべての参加者は、初歩的な群論を使用して同じグループ鍵を計算することができるが、会議サーバは鍵を決定することはできないことが容易に分かる。プロトコルは、図６には６０６で示されている。

上で説明したナンスベース合法鍵発見技法は、簡単な方法でこの設定まで拡張することも可能である。このような実施態様によれば、参加者に関連するナンスは、本明細書において説明されているように生成され、また、生成される鍵成分が付随し、かつ、参加者によって送信されることを理解されたい。

したがって電話会議セットアップの開始時に、個々の参加者は、会議サーバ６０４とＩＢＡＫＥシグナリングを交換する。ＬＥＭＦは、ターゲットと会議サーバの間のこのシグナリングを傍受し、かつ、ターゲットによって送られる無作為機密を解読する。第２のフェーズでは、鍵成分が会議サーバと交換されると、ＬＥＭＦは、ターゲット自身によって実施されたすべての計算を完全に複製することができる。その結果、ＬＥＭＦは、会議セッション鍵の正確なコピーを再生する。同様に、ＬＥＭＦがすべてのシグナリングを単純にＫＭＳに送る場合、ＫＭＳは計算を処理し、セッション鍵をＬＥＭＦに戻す。
Ｖ．例示的な計算システム
図７は、実施形態例による、２つのエンティティと合法セキュリティアソシエーション発見の間のナンスベースセキュア鍵管理プロトコルを実施するために適した計算デバイスの形態のネットワーク環境および通信デバイスの一般化されたハードウェアアーキテクチャ７００を示したものである。

図７は、図に示されている２つのエンティティについてのみ、その詳細なサブコンポーネントを示しているが、他のエンティティも同じ構成を有することができることを理解されたい。したがって上で説明したセキュア鍵管理プロトコルおよび合法セキュリティアソシエーション発見に関して、詳細に示されている２つのエンティティは、イニシエータクライアントデバイス４０２−Ａ（第１の当事者すなわちＡ）およびレスポンダクライアントデバイス４０２−Ｂ（第２の当事者すなわちＢ）であってもよい。しかしながら、傍受サーバ（５０２）、ＫＭＳ（５０４）、機能要素、追加クライアントデバイス（当事者）および追加サーバも、図７の計算デバイスで示されているアーキテクチャと同じアーキテクチャを使用して実施することができる。したがって図７には一例として傍受サーバ７２０およびＫＭＳ７２２が示されており、これらは、デバイス７０２および７０４で示されている計算アーキテクチャと同じ計算アーキテクチャを有していることを理解されたい。しかしながら、簡潔にするために、本明細書において説明されているプロトコルに参加することができるすべての計算デバイス（通信デバイス）は図７には示されていないことを理解されたい。また、電話会議実施態様では、会議参加者（デバイス６０２−１から６０２−Ｎ）および会議サーバ（６０４）は、図７の計算デバイスで示されているアーキテクチャと同じアーキテクチャを使用して実施することができる。

図に示されているように、７０２で示されているＡの計算デバイスおよび７０４で示されているＢの計算デバイスは、ネットワーク７０６を介して結合されている。ネットワークは、これらのデバイスがそのネットワークを介して通信することができる任意のネットワークであってもよく、例えば上で説明した実施形態の場合と同様、ネットワーク７０６は、ネットワークオペレータ（例えばＶｅｒｉｚｏｎ、ＡＴ＆Ｔ、Ｓｐｒｉｎｔ）によって操作されるセルラ通信ネットワークなどの公にアクセスすることができる広域通信ネットワークを含むことができる。しかしながら、実施形態は、特定のタイプのネットワークに限定されない。典型的には、これらのデバイスはクライアントマシンであってもよい。本明細書において説明されているプロトコルに参加するために当事者が使用することができるクライアントデバイスの例は、セルラ電話、スマートフォン、デスクトップ電話、パーソナルディジタルアシスタント、ラップトップコンピュータ、パーソナルコンピュータなどを含むことができるが、これらに限定されない。また、上で説明したように、クライアントは、計算デバイス（例えばスマートフォン）上のアプリケーションであってもよいことを思い起こされたい。しかしながら、これらのデバイスのうちの１つまたは複数は、サーバ（例えば傍受サーバ、ＫＭＳサーバなど）であってもよい。したがって本明細書において説明されているプロトコルおよび方法は、計算システムがそれぞれクライアントおよびサーバである場合に限定されず、２つのネットワーク要素を備えた任意の計算デバイスに適用することができることを理解されたい。

当業者には容易に明らかなように、サーバおよびクライアントは、コンピュータプログラムコードの制御下で動作するプログラム済みコンピュータとして実施することができる。コンピュータプログラムコードは、コンピュータ可読記憶媒体（例えばメモリ）に記憶することができ、また、このコンピュータプログラムコードは、コンピュータのプロセッサによって実行することができる。本開示が与えられると、当業者は、本明細書において説明されているプロトコルを実施するための適切なコンピュータプログラムコードを容易に構築することができる。

しかしながら、図７は、概ね、ネットワークを介して通信する個々のコンピュータシステムのための一例示的アーキテクチャを示したものである。図に示されているように、デバイス７０２は、Ｉ／Ｏデバイス７０８−Ａ、プロセッサ７１０−Ａおよびメモリ７１２−Ａを備えている。デバイス７０４は、Ｉ／Ｏデバイス７０８−Ｂ、プロセッサ７１０−Ｂおよびメモリ７０２−Ｂを備えている。本明細書において使用されている「プロセッサ」という用語には、中央処理装置（ＣＰＵ）または他の処理回路を含む１つまたは複数の処理デバイスを包含することが意図されており、他の処理回路は、１つまたは複数の信号プロセッサ、１つまたは複数の集積回路などを含むが、これらに限定されないことを理解されたい。また、本明細書において使用されている「メモリ」という用語には、プロセッサすなわちＣＰＵと結合した、ＲＡＭ、ＲＯＭ、固定メモリデバイス（例えばハードドライブ）または取外し可能メモリデバイス（例えばディスケットまたはＣＤＲＯＭ）などのメモリを包含することが意図されている。また、メモリは、コンピュータ可読記憶媒体の一例である。さらに、本明細書において使用されている「Ｉ／Ｏデバイス」という用語には、処理装置にデータを入力するための１つまたは複数の入力デバイス（例えばキーボード、マウス）、ならびに処理装置に関連する結果を提供するための１つまたは複数の出力デバイス（例えばＣＲＴディスプレイ）を包含することが意図されている。

したがって本明細書において説明されている方法を実施するためのソフトウェア命令またはコードは、関連する複数のメモリデバイス、例えばＲＯＭ、固定または取外し可能メモリのうちの１つまたは複数に記憶することができ、また、利用する準備が整った時点でＲＡＭにロードし、かつ、ＣＰＵによって実行することができる。

以上、本明細書において、例示的な実施形態について添付の図面を参照して説明したが、本発明はこれらの厳密な実施形態に限定されないこと、また、当業者は、本発明の範囲または趣旨を逸脱することなく、様々な他の変更および修正を加えることができることを理解されたい。

Claims

第１の計算デバイスと第２の計算デバイスの間の発見可能セキュリティアソシエーションを形成するための方法であって、
第１の計算デバイスにより、鍵管理エンティティから、（ｉ）第１の計算デバイスに結合された第１の公開鍵と計算的に連携する、第１の計算デバイスに割り当てられた第１の秘密鍵と、（ｉｉ）第１の計算デバイスに割り当てられた第１のルート鍵とを入手するステップと、
第１の計算デバイスにより、第１の無作為値を選択するステップと、
第１の計算デバイスにより、第１のルート鍵を使用して第１の無作為値を暗号化して第１のナンスを生成するステップと、
第１の計算デバイスにより、第１の無作為値に基づいて第１の鍵成分を生成するステップと、
第１の計算デバイスにより、識別情報ベース暗号化処理を使用して、第１のナンスおよび第１の鍵成分を、第２の計算デバイスに結合された第２の公開鍵で暗号化するステップと、
第１の計算デバイスにより、暗号化された第１のナンスおよび暗号化された第１の鍵成分を第２の計算デバイスに送るステップであって、それにより第２の計算デバイスとのセキュリティアソシエーションを確立し、そのセキュリティアソシエーションが、第１の計算デバイスおよび第２の計算デバイスに気付かれずに第３の計算デバイスによる発見が可能である、送るステップと
を含む、方法。
第１の計算デバイスが、第２の計算デバイスからの戻りで、第１のナンス、第２のナンス、第１の鍵成分および第２の鍵成分を受け取るステップをさらに含み、第１のナンス、第２のナンス、第１の鍵成分および第２の鍵成分が、識別情報ベース暗号化処理を使用して、第１の計算デバイスに結合された第１の公開鍵で暗号化され、第２のナンスおよび第２の鍵成分が第２の計算デバイスで生成される、請求項１に記載の方法。
第２のナンスが、第２の計算デバイスによって選択された第２の無作為値の暗号化の結果であり、暗号化が第２の無作為値を暗号化するために第２のルート鍵を使用し、その第２のルート鍵が、第２のルート鍵を第２の計算デバイスに割り当てた鍵管理エンティティから第２の計算デバイスが入手したものである、請求項２に記載の方法。
第２の鍵成分が、第２の無作為値に基づいて第２の計算デバイスによって生成される、請求項３に記載の方法。
第１の計算デバイスが第２の計算デバイスに第２のナンスおよび第２の鍵成分を送り返すステップをさらに含み、第２のナンスおよび第２の鍵成分が、識別情報ベース暗号化処理を使用して、第２の計算デバイスに結合された第２の公開鍵で暗号化される、請求項２に記載の方法。
第１の計算デバイスおよび第２の計算デバイスが、それらの間の後続する通信に使用するための同じセッション鍵を計算する、請求項５に記載の方法。
セッション鍵が、第３の計算デバイスによる発見が可能なセキュリティアソシエーションの少なくとも一部を表す、請求項６に記載の方法。
第１の計算デバイスと第２の計算デバイスの間に形成されるセキュリティアソシエーションを発見するための方法であって、
第３の計算デバイスにより、第１の計算デバイスと第２の計算デバイスの間で送信される１つまたは複数のメッセージを入手するステップと、
第３の計算デバイスにより、第１の計算デバイスから入手した１つまたは複数のメッセージのうちの少なくとも１つを解読し、かつ、第１の計算デバイスにより、（ｉ）第１の計算デバイスによって生成される第１の鍵成分、および（ｉｉ）第２の計算デバイスによって生成されるナンスを入手するステップを含み、第３の計算デバイスが、第２の計算デバイスに結合された秘密鍵の知識を有し、及び、ナンスが第２の計算デバイスに一意的に割り当てられるルート鍵を使用して第２の計算デバイスによって選択される無作為値の暗号化することにより第２の計算デバイスにより生成され、
前記方法は更に、
第３の計算デバイスにより、第２の計算デバイスによって選択された無作為値を入手するためにナンスを解読するステップを含み、第３の計算デバイスが第２の計算デバイスのルート鍵の知識を有し、
前記方法は更に、
第３の計算デバイスにより、第１の計算デバイスと第２の計算デバイスに気付かれずに、第１の計算デバイスおよび第２の計算デバイスの間に確立されるセキュリティアソシエーションを発見するステップを含み、第３の計算デバイスが、第２の計算デバイスによって選択された無作為値の知識および第１の計算デバイスによって生成された第１の鍵成分の知識を有する、方法。
第２の計算デバイスと発見可能セキュリティアソシエーションを形成するための第１の計算デバイスであって、
メモリと、
メモリに結合され、かつ、第１の計算デバイスに、
鍵管理エンティティから、（ｉ）第１の計算デバイスに結合された第１の公開鍵と計算的に連携する、第１の計算デバイスに割り当てられた第１の秘密鍵と、（ｉｉ）第１の計算デバイスに割り当てられた第１のルート鍵とを入手させ、
第１の無作為値を選択させ、
第１のルート鍵を使用して第１の無作為値を暗号化して第１のナンスを生成させ、
第１の無作為値に基づいて第１の鍵成分を生成させ、
識別情報ベース暗号化処理を使用して、第１のナンスおよび第１の鍵成分を、第２の計算デバイスに結合された第２の公開鍵で暗号化させ、
暗号化された第１のナンスおよび暗号化された第１の鍵成分を第２の計算デバイスに送り、それにより第２の計算デバイスとのセキュリティアソシエーションであって、第１の計算デバイスおよび第２の計算デバイスに気付かれずに第３の計算デバイスによる発見が可能であるセキュリティアソシエーションを確立させる
ように構成されたプロセッサと
を備える、第１の計算デバイス。
第１の計算デバイスと第２の計算デバイスの間に形成されるセキュリティアソシエーションを発見するための第３の計算デバイスであって、
メモリと、
メモリに結合され、かつ、第３の計算デバイスに、
第１の計算デバイスと第２の計算デバイスの間で送信される１つまたは複数のメッセージを入手させ、
第１の計算デバイスから入手した１つまたは複数のメッセージのうちの少なくとも１つを解読させ、かつ、（ｉ）第１の計算デバイスによって生成される第１の鍵成分、および（ｉｉ）第２の計算デバイスによって生成されるナンスを入手させ、第３の計算デバイスが、第２の計算デバイスに結合された秘密鍵の知識を有し、及び、ナンスが第２の計算デバイスに一意的に割り当てられるルート鍵を使用して第２の計算デバイスによって選択される無作為値を暗号化することにより第２の計算デバイスにより生成される、ように構成され、
第２の計算デバイスによって選択された無作為値を入手するためにナンスを解読させ、第３の計算デバイスが第２の計算デバイスのルート鍵の知識を有する、ように構成され、
第１の計算デバイスと第２の計算デバイスに気付かれずに、第１の計算デバイスおよび第２の計算デバイスの間に確立されるセキュリティアソシエーションを発見させ、第３の計算デバイスが、第２の計算デバイスによって選択された無作為値の知識および第１の計算デバイスによって生成された第１の鍵成分の知識を有する、
ように構成されたプロセッサと
を備える、第３の計算デバイス。