JP2014514860A

JP2014514860A - セキュリティアソシエーションの発見法

Info

Publication number: JP2014514860A
Application number: JP2014506431A
Authority: JP
Inventors: サンダラム，ガナパテイー・エス; ミジコフスキー，セミヨン・ビー
Original assignee: アルカテル−ルーセント
Priority date: 2011-04-22
Filing date: 2012-04-03
Publication date: 2014-06-19
Anticipated expiration: 2032-04-03
Also published as: EP2700187B1; WO2012145161A1; KR20130136551A; US20120272064A1; CN103493427B; JP5775210B2; KR101517713B1; EP2700187A1; US8769288B2; CN103493427A

Abstract

通信環境において形成されたセキュリティアソシエーションを発見する技術を開示する。たとえば、第１のコンピューティングデバイス（たとえば、第１のクライアント）と第２のコンピューティングデバイス（たとえば、第２のクライアント）の間に発見可能なセキュリティアソシエーションを形成する方法は、以下のステップを含む。第１のコンピューティングデバイスは、第２のコンピューティングデバイスとの通信を安全にする際に使用される鍵を計算するために、第１のコンピューティングデバイスによって使用される秘密値を生成するために、第１のコンピューティングデバイスによって使用されるシードを提供される。秘密値は、シードの知識に基づいて再計算可能であり、鍵は、第３のコンピューティングデバイス（たとえば、傍受サーバ）が、第１のコンピューティングデバイスおよび第２のコンピューティングデバイスには気づかれずに、第１のコンピューティングデバイスと第２のコンピューティングデバイスの間の通信を傍受するために再計算された鍵を使用できるように、秘密値の知識に基づいて再計算可能である。一例として、鍵は、識別情報ベースの認証された鍵の交換の結果であってもよい。

Description

本出願は、「Ｏｕｔ−ｏｆ−ＢａｎｄＬａｗｆｕｌＤｉｓｃｏｖｅｒｙｏｆＳｅｃｕｒｉｔｙＡｓｓｏｃｉａｔｉｏｎｓ」と題された、２０１１年４月２２日に出願され、通し番号６１／４７８，１５３で識別され、開示内容全体が引用により本明細書に組み込まれる米国仮特許出願の優先権主張するものである。

本発明は一般に通信セキュリティに関し、より詳細には、通信環境内のセキュリティアソシエーションを発見する技術に関する。

インターネットプロトコル（ＩＰ）通信および電話通信システムが広く普及している。２つのクライアント間のエンドツーエンドＩＰ通信の初期の一例にはインスタントメッセージングがあったが、そのすぐ後にボイスオーバー（Ｖｏｉｃｅ−ｏｖｅｒ）ＩＰが登場し、現在では多くのプロバイダ（たとえば、ネットワーク事業者およびアプリケーションプロバイダ）が、エンドツーエンドのビデオオーバー（Ｖｉｄｅｏ−ｏｖｅｒ）ＩＰを提供している。しかしながら、無線移動体ネットワークのアクセスが狭帯域の回線交換アクセスネットワークによって占められている状況があって、こういった傾向は主として有線の固定ネットワークに制限されていた。しかしながら、広帯域の４Ｇ（第４世代）無線ネットワークが最近配備されたことで、アクセスのタイプに依らず、あらゆる形態のマルチメディアオーバー（ｍｕｌｔｉｍｅｄｉａｏｖｅｒ）ＩＰによるエンドツーエンドの通信のためのステージが設定されている。

エンドツーエンドのＩＰセッションに移行して、市場では、これらのオープンなＩＰネットワーク上でのセキュリティおよびプライバシーに対する関心ならびに意識が再起している。最初のステップとして、エンドツーエンドの暗号化および認証が注目を集めているパラダイムである。商取引および企業イントラネットのアクセスを含む現代のインターネットトランザクションは、これまで１０年間エンドツーエンドで安全にされてきたが、ＩＰでの会話アプリケーションの安全保護は主として、たとえばＳＫＹＰＥ（ＴＭ）（ＬｕｘｅｍｂｏｕｒｇのＳｋｙｐｅＴｅｃｈｎｏｌｏｇｉｅｓＳ．Ａ．の商標）などのアプリケーションプロバイダに任せられていた。

あらゆるＩＰネットワークの出現で、ネットワーク事業者またはその他の、オーディオ、ビデオ、およびメッセージングサービスを提供する事業者が、法的な通信傍受およびセキュリティアソシエーションの発見をサポートするための要件に準拠しつつ、エンドツーエンドのセキュリティを確保することがますます必要になりつつある。そのような法的な通信傍受およびセキュリティアソシエーションの発見は、法の執行の目的で、または単に法の執行以外の何らかの目的で必要なことがあり、それによって、当事者および／またはデバイス間で送信される暗号化メッセージを復号できることが必要であるかまたは望ましい。

ＩＥＴＦＲＦＣ４５６８、「ＳｅｃｕｒｉｔｙＤｅｓｃｒｉｐｔｉｏｎｓｆｏｒＭｅｄｉａＳｔｒｅａｍｓ」、Ｊｕｌｙ２００６ＩＥＴＦＲＦＣ４１２０、「ＫｅｒｂｅｒｏｓＮｅｔｗｏｒｋＡｕｔｈｅｎｔｉｃａｔｉｏｎＳｅｒｖｉｃｅ」、Ｊｕｌｙ２００５ＩＥＴＦＲＦＣ６０４３、「Ｔｉｃｋｅｔ−ｂａｓｅｄＭｏｄｅｓｏｆＫｅｙＤｉｓｔｒｉｂｕｔｉｏｎｉｎＭｕｌｔｉｍｅｄｉａＩｎｔｅｒｎｅｔＫｅｙｉｎｇ」、Ｍａｒｃｈ２０１１Ｍ．ＢｅｌｌａｒｅおよびＰ．Ｒｏｇａｗａｙ、「ＥｎｔｉｔｙＡｕｔｈｅｎｔｉｃａｔｉｏｎａｎｄＫｅｙＤｉｓｔｒｉｂｕｔｉｏｎ」、ＡｄｖａｎｃｅｓｉｎＣｒｙｐｔｏｌｏｇｙ、Ｃｒｙｐｔｏ ’９３、ＬＮＣＳ７７３、Ｅｄ．Ｄ．Ｓｔｉｎｓｏｎ、Ｓｐｒｉｎｇｅｒ−Ｖｅｒｌａｇ、１９９４ＩＥＴＦＲＦＣ２６３１、「Ｄｉｆｆｉｅ−ＨｅｌｌｍａｎＫｅｙＡｇｒｅｅｍｅｎｔＭｅｔｈｏｄ」、Ｊｕｎｅ１９９９Ｗ．Ｄｉｆｆｉｅ、Ｍ．Ｈｅｌｌｍａｎ、「ＮｅｗＤｉｒｅｃｔｉｏｎｓｉｎＣｒｙｐｔｏｇｒａｐｈｙ」、ＩＥＥＥＴｒａｎｓａｃｔｉｏｎｓｏｎＩｎｆｏｒｍａｔｉｏｎＴｈｅｏｒｙ、ｖｏｌ．ＩＴ−２２、Ｎｏｖ．１９７６、ｐｐ：６４４−６５４ＤａｎＢｏｎｅｈ、ＭａｔｔｈｅｗＫ．Ｆｒａｎｋｌｉｎ、「Ｉｄｅｎｔｉｔｙ−ＢａｓｅｄＥｎｃｒｙｐｔｉｏｎｆｒｏｍｔｈｅＷｅｉｌＰａｉｒｉｎｇ」ＡｄｖａｎｃｅｓｉｎＣｒｙｐｔｏｌｏｇｙ−ＰｒｏｃｅｅｄｉｎｇｓｏｆＣＲＹＰＴＯ２００１（２００１）ＩＥＴＦＲＦＣ５４０８ＩＥＴＦＲＦＣ５４０９ＦＩＰＳ１８０−１、「ＳｅｃｕｒｅＨａｓｈＳｔａｎｄａｒｄ」、Ａｐｒｉｌ１９９５３ＧＰＰＴＳ３３．２２０ＢｕｒｍｅｓｔｅｒおよびＤｅｓｍｅｄｔ、「Ａｓｅｃｕｒｅａｎｄｅｆｆｉｃｉｅｎｔｃｏｎｆｅｒｅｎｃｅｋｅｙｄｉｓｔｒｉｂｕｔｉｏｎｓｙｓｔｅｍ」、ＰｒｏｃｅｅｄｉｎｇｓｏｆＥｕｒｏｃｒｙｐｔ ’９４、ＬＮＣＳｖｏｌ．９５０、２７５−２８６ページ、Ｓｐｒｉｎｇｅｒ１９９５

本発明の原理は、通信環境において形成されたセキュリティアソシエーションを発見する技術を提供する。

たとえば、本発明の一態様において、第１のコンピューティングデバイスと第２のコンピューティングデバイスの間に発見可能なセキュリティアソシエーションを形成する方法が、以下のステップを含む。第１のコンピューティングデバイスは、第２のコンピューティングデバイスとの通信を安全にする際に使用される鍵を計算するために、第１のコンピューティングデバイスによって使用される秘密値を生成するために、第１のコンピューティングデバイスによって使用されるシードを提供される。秘密値は、シードの知識に基づいて再計算可能であり、鍵は、第３のコンピューティングデバイスが、第１のコンピューティングデバイスおよび第２のコンピューティングデバイスには気づかれずに、第１のコンピューティングデバイスと第２のコンピューティングデバイスの間の通信を傍受するために再計算された鍵を使用できるように、秘密値の知識に基づいて再計算可能である。

さらなる例として、本発明の第２の態様において、第１のコンピューティングデバイスと第２のコンピューティングデバイスの間に形成されたセキュリティアソシエーションを発見する方法が、以下のステップを含む。第３のコンピューティングデバイスは秘密値を第４のコンピューティングデバイスから取得する。秘密値は、第１のコンピューティングデバイスによって生成される同じ秘密値であり、第１のコンピューティングデバイスは、第４のコンピューティングデバイスによって提供されたシードに基づいて秘密値を生成しており、第１のコンピューティングデバイスは、シードを使用して秘密値を生成し、秘密値を使用して、第２のコンピューティングデバイスとの通信を安全にする際に使用される鍵を計算している。第３のコンピューティングデバイスは、第１のコンピューティングデバイスおよび第２のコンピューティングデバイスには気づかれずに、第１のコンピューティングデバイスと第２のコンピューティングデバイスの間の通信を傍受するために、秘密値に基づいて鍵を再計算する。

本発明の例示的な原理は、鍵管理のための公開鍵方法に依存するシステムに特に適用可能であるが、それには限られない技術を使用して、限定はしないが、エンドツーエンドの暗号化されたセッション用の鍵および他の暗号データを含む、セキュリティアソシエーションを合法的に発見する方法を提供する。たとえば、本発明の技術は、非対称相互に認証された鍵の交換および／または任意のディフィーヘルマン（Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ）に基づく鍵交換を実施するシステムおよびプロトコルに従って使用されてもよい。特に、本発明のオーバーレイ手順は、種々の遵守要件を満たしつつ、検出不能である。本発明の原理は、インターネットプロトコルマルチメディアサブシステム（ＩＭＳ）環境に特に適しているが、本発明をそのように限定する意図はないことを理解されたい。すなわち、本発明の原理は一般に、合法的なセキュリティアソシエーション発見機能を提供することが望ましい任意の適切な通信システムに適用可能である。一例に過ぎないが、そのような本発明の技術が適用されてもよい別の通信システムは、ＩＭＳ信号送信枠組みまたは任意の他の信号送信枠組みに基づく会議呼び出しシステムである。

本発明のこれらおよびその他の目的、特徴および利点は、添付の図面と併せて読まれるべき、本発明の例示的実施形態の以下に示す詳細な説明から明らかになろう。

クライアントベースの鍵転送方法を示す図である。ネットワーク支援型の鍵転送方法を示す図である。相互に認証された対称鍵の交換方法を示す図である。識別情報ベースの認証された鍵の交換方法を示す図である。第三者介在（ｍａｎ−ｉｎ−ｔｈｅ−ｍｉｄｄｌｅ）鍵発見方法を示す図である。本発明の一実施形態による、擬似乱数生成器を示す図である。本発明の一実施形態による、秘密値再生でセッション鍵を合法的に発見する方法を示す図である。本発明の一実施形態による、秘密値再生でセッション鍵を合法的に発見するための呼のフローを示す図である。本発明の一実施形態による、会議呼び出し環境における秘密値再生でセッション鍵を合法的に発見する方法を示す図である。本発明の諸実施形態による、方法およびプロトコルのうちの１つまたは複数を実施するのに適したデータネットワークおよび通信（コンピューティング）デバイスの汎用ハードウェアアーキテクチャを示す図である。

本明細書において、語句「マルチメディア通信システム」は全般的に、メディアプレーンを介して、限定はしないが、テキストベースのデータ、グラフィックベースのデータ、音声ベースのデータおよびビデオベースのデータを含むより多くのタイプうちの１つのメディアを運搬することが可能な任意の通信システムとして定義する。

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

本明細書において、用語「鍵」は全般的に、限定はしないが、エンティティの認証、プライバシー、メッセージの保全などの目的で、暗号のプロトコルに入るものとして定義する。

本明細書において、語句「セキュリティアソシエーション」は全般的に、２つ以上の当事者および／またはデバイスが通信する通信環境におけるセキュリティ定義を指す。ある例においては、セキュリティ定義は、限定はしないが、セッション鍵を含んでいてもよい。

本明細書において、用語「シード」は全般的に、少なくとも１つの乱数を含む数の組を指す。

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

本明細書において、「通信セッション」は全般的に、２つのデバイス間の通信目的での、少なくとも２つの通信デバイス間または他のコンピューティングシステム（たとえば、クライアント）間の接続を指す。したがって、本明細書において、「エンドツーエンド」の通信セッションは、概して一方のデバイス（たとえば、クライアント）から他方のデバイス（たとえば、クライアント）までの接続経路全体を指す。また、通信セッションに参加中の２つ以上のクライアントは、「エンドポイントデバイス」または単に「エンドポイント」と呼ぶ。しかしながら、本発明の合法的なセキュリティアソシエーション発見技術は、クライアントだけではなく、任意のコンピューティングデバイスまたは通信デバイスに適用することができる。

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

本明細書において、用語「合法的」は全般的に、政府のまたは私的な権威あるエンティティに関する１つまたは複数の遵守要件またはガイドラインを満たすこととして定義する。そのような権威あるエンティティは、法の執行機能または法の執行以外の機能を果たすことができる。すなわち、合法的という用語は、法の執行に限定する意図はなく、むしろ法の執行以外の意味における遵守を含んでいてもよい。

参照しやすくするために、詳細な説明を以下のように分割する。セクションＩでは、本発明の原理が適用できる例示的な使用のケースおよびプロバイダを説明する。セクションＩＩでは、既存のエンドツーエンドの鍵管理方法を説明する。セクションＩＩＩでは、既存の鍵解決方法を説明する。セクションＩＶでは、インターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）環境の場面における、本発明の例示的な原理による合法的なセキュリティアソシエーション発見の解決策を説明する。セクションＶでは、会議呼び出し環境の場面における、本発明の例示的な原理による合法的なセキュリティアソシエーション発見の解決策を説明する。セクションＶＩでは、本発明による１つまたは複数の合法的なセキュリティアソシエーション発見方法を実施するための例示のコンピューティングシステムを説明する。

Ｉ．例示的な使用のケースおよびプロバイダ
本発明の原理が適用できる、本明細書に記載の例示的な使用のケースは、エンドツーエンドの暗号化されたクライアント間通信セッションを含む。一例に過ぎず、いかなる方法でも限定することは意図していないが、そのような使用のケースは以下を含む：
１．テキストベースのＩＭまたはインスタントメッセージングアプリケーション。
２．エンドツーエンドのインターネットプロトコルに基づくマルチメディアメッセージングアプリケーション（オーディオおよび／またはビデオを含む）。
３．種々のパケット交換式アクセスネットワークを介したボイスオーバーＩＰ。
４．種々のパケット交換式アクセスネットワークを介したビデオオーバーＩＰ。
５．参加者のグループが関与するテキストおよびマルチメディアアプリケーションの会議。

これらの例示的な使用のケースは、種々のプロバイダに等しく十分に適用される。一例として、プロバイダを以下の３つのカテゴリに分類することができる：
１．サービスプロバイダは企業であり得る（ここでは、最高情報責任者、すなわちＣＩＯがアプリケーションの公開、管理、および運用を統制する）。企業は法人または政府エンティティであり得ることに注意されたい。
２．サービスプロバイダはアプリケーションプロバイダ（たとえば、Ｓｋｙｐｅ、Ｇｏｏｇｌｅトークなど）であってもよく、そのようなサービスは、ネットワークおよびタイプを越えて「オーバーザトップ（ｏｖｅｒｔｈｅｔｏｐ）」で提供される。
３．サービスプロバイダはネットワークプロバイダ（たとえば、ＶｅｒｉｚｏｎＷｉｒｅｌｅｓｓ、ＡＴ＆Ｔ、Ｓｐｒｉｎｔ、Ｔ−Ｍｏｂｉｌｅ、Ｖｏｄａｆｏｎｅなど）であり得る。

本発明の原理に従って説明する問題および解決策の例示的な範囲は、すべてのプロバイダに等しく十分に適用され、特に、エンドツーエンドの通信タイプまたはアプリケーションに左右されない。

ＩＩ．エンドツーエンドの鍵管理
エンドツーエンドのＩＰセッション、およびエンドツーエンドのセキュリティを提供する要求を想定して、エンドツーエンドの鍵管理方式が考案された。一例として、そのような方式を以下の４つのカテゴリに分類することができる：（１）クライアントベースの鍵転送プロトコル、（２）ネットワーク支援型の鍵転送プロトコル、（３）相互に認証された対称鍵の交換プロトコル、および（４）相互に認証された非対称鍵の交換プロトコル。

（１）クライアントベースの鍵転送プロトコル。図１のプロトコル１００に示されるように、「開始側」（すなわち、特定の通信セッションを開始するクライアント）と呼ばれるクライアントデバイス１０２−Ｉが、「安全鍵」を、１つまたは複数のネットワーク要素１０４−１、１０４−２を介して「応答側」（すなわち、特定の通信セッションの開始側に応答するクライアント）と呼ばれるクライアントデバイス１０２−Ｒに移送する安全な信号送信に適用可能な、確立されたホップバイホップ（ｈｏｐ−ｂｙ−ｈｏｐ）の安全なメッセージング方式を使用する。次いで、通信セッションにおけるすべての当事者が、その鍵（またはその派生）を使用して、そのセッションを安全にする。図１に示す例は、安全なリアルタイムトランスポートプロトコル（ＳｅｃｕｒｅＲｅａｌ−ｔｉｍｅＴｒａｎｓｐｏｒｔＰｒｏｔｏｃｏｌ）用の鍵を決めるために使用されるプロトコルであるセッション記述プロトコル（ＳｅｓｓｉｏｎＤｅｓｃｒｉｐｔｉｏｎＰｒｏｔｏｃｏｌ）（ＳＤＰ）に基づいており、たとえば、開示内容の全体が引用により本明細書に組み込まれる、セッション記述プロトコル（ＳＤＰ）インターネット技術タスクフォース（ＩｎｔｅｒｎｅｔＥｎｇｉｎｅｅｒｉｎｇＴａｓｋＦｏｒｃｅ）（ＩＥＴＦ）コメント要求（ＲｅｑｕｅｓｔｆｏｒＣｏｍｍｅｎｔ）（ＲＦＣ）４５６８、「ＳｅｃｕｒｉｔｙＤｅｓｃｒｉｐｔｉｏｎｓｆｏｒＭｅｄｉａＳｔｒｅａｍｓ」、Ｊｕｌｙ２００６を参照されたい。そのような場合には、クライアント１０２−Ｉは、ＳＤＰ提供を、（エンドツーエンドの）ネットワークを介してクライアント１０２−Ｒに送信し、クライアント１０２−Ｒは、ＳＤＰ返答で応答し、それによって、その特定のセッションに関する通信を安全にする際に使用される安全鍵を確立する。

（２）ネットワーク支援型の鍵転送プロトコル。図２のプロトコル２００に示されるように、クライアントデバイス２０２−Ｉ（開始側）は、所与のセッション用の鍵を、プロバイダネットワーク（またはデータセンタ）内のサーバ２０４（鍵管理サーバすなわちＫＭＳ）に要求し、次いで、鍵および鍵の「ポインタ」（チケットまたはトークンの形態）がサーバ２０４から開始側に供給される。次いで、開始側が、確立されたホップバイホップのセキュリティアソシエーションを使用して、「ポインタ」をクライアントデバイス２０２−Ｒ（応答側）と安全に共有し、その後、応答側が、「ポインタ」をサーバ２０４に提示することによってそこから鍵を取得する。そのようなネットワーク支援型のプロトコルの２つの例には、ＩＥＴＦＲＦＣ４１２０、「ＫｅｒｂｅｒｏｓＮｅｔｗｏｒｋＡｕｔｈｅｎｔｉｃａｔｉｏｎＳｅｒｖｉｃｅ」、Ｊｕｌｙ２００５に記載されたＫｅｒｂｅｒｏｓシステム、およびＩＥＴＦＲＦＣ６０４３、「Ｔｉｃｋｅｔ−ｂａｓｅｄＭｏｄｅｓｏｆＫｅｙＤｉｓｔｒｉｂｕｔｉｏｎｉｎＭｕｌｔｉｍｅｄｉａＩｎｔｅｒｎｅｔＫｅｙｉｎｇ」、Ｍａｒｃｈ２０１１に記載されたＭＩＫＥＹ−Ｔｉｃｋｅｔシステムがあり、その開示内容は全体が引用により本明細書に組み込まれる。

（３）相互に認証された対称鍵の交換プロトコル。図３のプロトコル３００に示されるように、開始側（３０２−Ａ）と応答側（３０２−Ｂ）が対称鍵を共有し、次いで、これらはこの鍵を使用して、乱数および／または同期させたカウンタを伴う相互に認証された鍵の交換プロトコルを実行する。そのようなプロトコルの１つの例が、Ｍ．ＢｅｌｌａｒｅおよびＰ．Ｒｏｇａｗａｙ、「ＥｎｔｉｔｙＡｕｔｈｅｎｔｉｃａｔｉｏｎａｎｄＫｅｙＤｉｓｔｒｉｂｕｔｉｏｎ」、ＡｄｖａｎｃｅｓｉｎＣｒｙｐｔｏｌｏｇｙ、Ｃｒｙｐｔｏ ’９３、ＬＮＣＳ７７３、Ｅｄ．Ｄ．Ｓｔｉｎｓｏｎ、Ｓｐｒｉｎｇｅｒ−Ｖｅｒｌａｇ、１９９４に記載されており、その開示内容は全体が引用により本明細書に組み込まれる。

（４）非対称公開鍵プロトコルを使用する認証された鍵の交換。このタイプのプロトコルにおいては、開始側および応答側がそれぞれ一対の鍵（秘密鍵と公開鍵）を所有する。典型的な例では、鍵交換のための公開鍵方法に従って、互いに認証するために秘密鍵を使用するが、互いに話しかけるために公開鍵を使用することを必要とする。図４のプロトコル４００は、ＩＢＡＫＥ（識別情報ベースの認証された鍵の交換（ｉｄｅｎｔｉｔｙｂａｓｅｄａｕｔｈｅｎｔｉｃａｔｅｄｋｅｙｅｘｃｈａｎｇｅ））プロトコルおよび非対称公開鍵方法の使用を示す。ＩＢＡＫＥプロトコルは、開示内容の全体が引用により本明細書に組み込まれ、通し番号１２／３７２，２４２で識別される、２００９年２月１７日出願の米国特許出願に記載されている。

図４のプロトコル４００に示されるように、ＩＢＡＫＥプロトコルは、２つのエンドポイント、すなわち開始側Ａ（クライアント４０２−Ａ）と応答側Ｂ（クライアント４０２−Ｂ）の間での相互認証および鍵交換を定義する。開始側および応答側はともにそれぞれ一対の鍵、すなわち、それらの公開鍵および秘密鍵を有する。公開鍵暗号法と同様に、公開鍵は暗号化に使用され、秘密鍵は復号に使用される。標準的な公開鍵方法と識別情報ベースの公開鍵方法との根本的な違いは、後者では、公開鍵は「識別情報」に対応し、対応する秘密鍵が、信頼できるサーバ（鍵管理サーバすなわちＫＭＳと呼ばれる）によって生成されることである。

図示したプロトコルの主なコンセプトは、開始側と応答側が、互いを認証し、かつ鍵管理サーバ（図示せず）によって提供される秘密鍵を使用してセッション鍵を生成するが、それでもサーバはセッション鍵を特定できないことである。

図４では、開始側Ａが、ランダムな秘密値「ｘ」を選択し、かつ値「ｘＰ」を計算し（ここで、Ｐは有限体での楕円曲線上の点である）、その後、「ｘＰ」を応答側Ｂに送信することに注意されたい。同様に、応答側はランダムな秘密値「ｙ」を選択し、かつ値「ｙＰ」を計算し、その後、「ｙＰ」を開始側Ａに送信する。開始側は「ｘ」および「ｙＰ」を使用して「ｘｙＰ」を計算し、同様に、応答側は「ｙ」および「ｘＰ」を使用して「ｘｙＰ」を計算する。これによって、両当事者は通信セッション用の一致した鍵を得ることができる。しかしながら、鍵管理サーバ（ＫＭＳ）は「ｘＰ」および「ｙＰ」を入手できるが、「ｘｙＰ」を計算することはできない。

上で挙げた（４つの）鍵移送／交換プロトコルのすべてにおいて、通信タイプまたはプロバイダに依らず、規制上の要件および／または遵守要件が存在し、プロバイダはそれに従って、エンドツーエンドの安全鍵の発見および共有（「合法的な発見」と呼ぶ）を行うことが合法的に要求され得ることが理解される。

この要件は、プロトコルタイプ１および２では比較的容易に満たされ得る。プロトコルタイプ１（図１）においては、対象となる安全鍵はホップバイホップの保護でネットワークのノード間を輸送され、そのため、この輸送に関与するネットワークノード（たとえば、図１のネットワーク要素１０４−１、１０４−２）に知られている。プロトコルタイプ２（図２）においては、セッション鍵がサーバ（たとえば、図２のＫＭＳ２０４）によって生成され、そのため、プロバイダにとって利用可能である。

プロトコルタイプ３（図３）においては、通常、プロバイダはこれらのペアの共有秘密値を供給することに関与しており、したがって、これらの秘密値を認識している。そのような場合、プロバイダがセッション鍵を発見し、法的要件および遵守要件を満たすことは実に明瞭である。

しかし、この合法的な発見の問題は、プロバイダが鍵管理トランザクションに対する唯一のイネーブラであるがトランザクションの参加者ではないプロトコルタイプ４（図４）では特に困難なことである。要するに、特に非対称公開鍵プロトコルがエンドツーエンドの鍵管理に使用されるとき、問題はエンドツーエンドの安全鍵を発見することである。さらに、そのような発見は、通信セッションの間、目立たず、かつ検出不能であることが要求される。

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

（１）一般的なプロトコル記述
ここで、ディフィーヘルマンタイプの鍵交換を使用するプロトコル（たとえば、開示内容の全体が引用により本明細書に組み込まれる、ＩＥＴＦＲＦＣ２６３１、「Ｄｉｆｆｉｅ−ＨｅｌｌｍａｎＫｅｙＡｇｒｅｅｍｅｎｔＭｅｔｈｏｄ」、Ｊｕｎｅ１９９９を参照）に具体的に注目する。本発明者らはこのプロトコルを、ＤｉｆｆｉｅおよびＨｅｌｌｍａｎによる、素数ｐを法とした有限体の乗法群についての画期的な論文（開示内容は全体が引用により本明細書に組み込まれる、Ｗ．Ｄｉｆｆｉｅ、Ｍ．Ｈｅｌｌｍａｎ、「ＮｅｗＤｉｒｅｃｔｉｏｎｓｉｎＣｒｙｐｔｏｇｒａｐｈｙ」、ＩＥＥＥＴｒａｎｓａｃｔｉｏｎｓｏｎＩｎｆｏｒｍａｔｉｏｎＴｈｅｏｒｙ、ｖｏｌ．ＩＴ−２２、Ｎｏｖ．１９７６、ｐｐ：６４４−６５４）に古典的に記載されたものと同様に記載する。しかしながら、ディフィーヘルマンプロトコルは、任意の群に拡張させることができるが、プロトコルのセキュリティは、その群の特性に依存することがよく知られている。

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

プロトコルを実行するために、Ａはランダムな秘密値ｘを選択し、ａ＝Ｇ＾ｘ（ｍｏｄＰ）を計算する。同様に、Ｂはランダムな秘密値ｙを選択し、ｂ＝Ｇ＾ｙ（ｍｏｄＰ）を計算する。秘密値ｘおよびｙはＰ未満のランダムな正の整数であることを理解されたい。

Ａは次いで値ａをＢに送信し、Ｂは値ｂをＡに送信する。

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

（２）ＩＢＡＫＥにおけるディフィーヘルマンの特殊な使用
ＩＢＡＫＥプロトコル（図４に示している）は、有限体での楕円曲線上の点の群を使用し、したがって、有限体での楕円曲線における点の群についての対応するディフィーヘルマン問題に依存する。各エンドポイント（たとえば、Ａ）は、Ａへの公開鍵（ＰＵＢ＿Ａ）を作成するために任意の他のエンドポイント（たとえば、Ｂ）によって使用され得る知られている公開識別情報を有する。同様に、任意の他のエンドポイントは、Ｂの公開識別情報が分かるとＰＵＢ＿Ｂを作成することができる。

時折かつ周期的に、各エンドポイント（たとえば、Ａ）は、特別なネットワークベースの機能である鍵管理サーバ（ＫＭＳ）に接触し、対応する公開鍵（ＰＵＢ＿Ａ）に計算上対応付けられている特別に計算された秘密鍵（たとえば、ＰＲ＿Ａ）を受信する。同様に、他のエンドポイントも同じことを行う。その結果、各エンドポイントは公開鍵と秘密鍵のペアを保有するが、公開鍵はエンドポイントの識別情報に基づいている。

プロトコルを実行するために、各エンドポイントは、ランダムな秘密値の数字を選択する。ｘを、Ａが選択する乱数とし、ｙを、Ｂが選択する乱数とする。

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

暗号化されたメッセージを受け取ると、Ｂはメッセージを復号し、ｘＰを取得する。

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

Ａは、このメッセージを受信すると、メッセージを復号し、ｙＰを取得する。続いて、Ａは、Ｂの公開鍵を使用してｙＰを暗号化し、それをＢに送信して戻す。

この後、ＡおよびＢがともにｋ＝ｘｙＰをセッション鍵として計算する。具体的に言うと、Ａは、受信し、復号したｙＰを自らにｘ回加算することによってｋ＝ｘｙＰを計算する。同様に、Ｂは、受信し、復号したｘＰを自らにｙ回加算することによってｋ＝ｘｙＰを計算する。

（３）セッション鍵を合法的に発見するための第三者介在鍵解決
典型的かつよく知られている、ディフィーヘルマン鍵交換での鍵発見の方法は、いわゆる「第三者介在（ｍａｎ−ｉｎ−ｔｈｅ−ｍｉｄｄｌｅ）」（ＭｉｔＭ）方法に基づく。この方法では、アクティブな媒介装置Ｃが、それ自体を通信リンクのエンドポイントＡとＢの間に配置している。媒介装置Ｃはそれ自体を、Ａに対してはＢ、かつ、Ｂに対してはＡとして呈する。

媒介装置Ｃは、それ自体の秘密値ｘ’およびｙ’を作成する。ＣがａをＡから受信したとき、Ｃはｂ’＝Ｇ＾ｙ’（ｍｏｄＰ）で応答し、同様にａ’＝Ｇ＾ｘ’（ｍｏｄＰ）をＢに送信する。

交換が完了したとき、ＡおよびＣは、ｋ１＝（Ｇ＾ｘ（ｍｏｄＰ））＊ｙ’（ｍｏｄＰ）＝（Ｇ＾ｙ’（ｍｏｄＰ））＊ｘ）（ｍｏｄＰ）を生成し、ＣおよびＢは、ｋ２＝（Ｇ＾ｘ’（ｍｏｄＰ））＊ｙ（ｍｏｄＰ）＝（Ｇ＾ｙ（ｍｏｄＰ））＊ｘ’（ｍｏｄＰ）を生成する。その結果、ＡおよびＢとの２つの独立した安全なセッションを維持することによって、アクティブな媒介装置Ｃは、ＡとＢの間の通信を復号し、再度暗号化することができる。

しかしながら、高度なエンドポイントデバイスによっては、相互に計算された鍵の画像または署名表現のいずれかを交換し、実際に２つの異なる鍵を計算したことを認識できるものもある。これによって、ＭｉｔＭ機能が発見されることになり、これはセッション鍵の合法的な発見においては望ましくない。

図５は、ＭｉｔＭ方法がクライアント５０２−Ａとクライアント５０２−Ｂの間で使用されるプロトコル５００を示す。合法的な傍受（ＬＩ）が、２つのエンドポイントデバイス間の信号を傍受する傍受制御要素（ＩＣＥ）５０６と、２つのエンドポイントデバイス間のメディアを傍受する傍受ネットワーク要素（ＩＮＥ）５０８とによって試みられることに留意されたい。ＩＣＥが、必要な秘密鍵（たとえば、ＰＲ＿ＡおよびＰＲ＿Ｂ）をＫＭＳ５０４からどのように取得するかに留意されたい。しかしながら、すでに述べたように、そのようなＬＩ機能は、ある種の高度なエンドポイントデバイスによって検出可能なことがある。

（４）秘密値の強制的な作成による鍵解決
別の方法では、エンドポイントのうちの少なくとも１つ（たとえば、Ａ）に、セッション鍵の合法的な発見に関与する特化したネットワークノードにやはり知られている秘密値（ｘ）を強制的に作成させる。この方式では、エンドポイントＡは秘密値ｘを選択せず、むしろ、ネットワークが臨時値（ｎｏｎｃｅ）（Ｎ）などの特別なパラメータを送信してくるのを待機し、次いでこの臨時値を、ネットワークと共有する別の秘密値（Ｓ）とハッシュ処理する。その結果、エンドポイントＡおよび特化したネットワークノードは、ｘ＝Ｈ（Ｓ，Ｎ）を生成する。続いて、この生成されたｘは、ディフィーヘルマン交換において指数として使用される。

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

しかしながら、臨時値を受信することを予期することによって、エンドポイントデバイスは、ネットワークの存在およびセッション鍵を合法的に発見しようとするその意図を十分に認識し、これは極めて望ましくない。特に、この鍵発見の解決策は、通信セッションの間に結託しているエンドポイントデバイスによって検出可能で、さらに、結託しているエンドポイントデバイスが存在する場合にのみ機能する。

（５）供託サーバへの鍵の転送
さらに別の方法は、ネットワークノードからエンドポイントデバイスに送信される特別な要求に基づく。この要求によって、エンドポイントデバイスは、Ａ−Ｂ通信リンクを暗号化するために使用される計算された鍵ｋまたはその派生鍵を、ネットワークベースの鍵供託データベースに強制的にアップロードさせられる。通常、このアップロードは、エンドポイントと鍵供託データベースの間に確立された安全なトンネルによる保護の下で行われる。

しかしながら、そのような要求を受信するエンドポイントデバイスは、鍵供託データベースの存在、したがって、安全な通信の可能な傍受を明確に認識し、これは、セッション鍵の合法的な発見のためには望ましくない。

ＩＶ．セキュリティアソシエーションの改良された合法的な発見
本発明の例示的な実施形態によれば、通信セッションにおける少なくとも１つの参加者の「ランダムな秘密値」を発見するプロバイダに依存する、鍵発見問題の解決策が提供される。特に、方法（以下により詳細に説明する）は以下のように機能する。

擬似乱数生成器（ＰＲＧ）が、クライアントアプリケーションに含まれる（たとえば、埋め込まれる）。これはプロバイダが行うことができるが、別のエンティティ、たとえば、アプリケーションの開発者または作成者が行うこともできる。後者のシナリオの場合、プロバイダは、クライアントアプリケーションに含まれるＰＲＧを認識させられる。

ネットワーク事業者またはアプリケーション所有者、たとえば企業は、アプリケーションに、クライアント識別情報に関連付けられた秘密のランダムなシード（Ｓ）を供給する。このランダムなシードは通常は乱数であり、またはより一般的には、少なくとも１つの乱数を含む数の組である。さらにシードは、必要に応じてよく更新されることがあり、本発明の解決策は、シードを供給するために使用される方法またはシードが更新される頻度の影響は受けない。

この関連性、すなわちシードと識別情報は、ネットワーク事業者またはアプリケーション所有者、たとえば企業が管理するサーバに格納される。また、本発明者らは、必要とあれば所与の識別情報に対するシードを更新できるようにしているが、クライアントに対する任意の更新もサーバで実施する必要がある。

ディフィーヘルマン、ＩＢＡＫＥなどの鍵交換プロトコルを実行するために、アプリケーションがセッション（たとえば、ｘ）用の乱数（秘密値）の生成を必要とするとき、ＰＲＧが呼び出される。ＰＲＧは、シードおよびタイムスタンプまたは外部で管理されるカウンタ（Ｃ）などの決定論的かつ単調に増加する数量（値）を使用して、必要な擬似乱数値ｘを生成する。この値は、リセットまたは増分などについて独自の規則をもつセッションカウンタ、タイムスタンプ、または単純なカウンタの値などの、任意のタイプの単調に増分する値であり得ることを理解されたい。基準は、シードの存続期間に、同じデバイスでのセッションからセッションの間にこの値が繰り返されないことである。

図６は、本発明の一実施形態による擬似乱数生成器６００を示す。この例示的な実施形態に示されるように、ＰＲＧは、ＦＩＰＳの刊行物である、開示内容の全体が引用により本明細書に組み込まれるＦＩＰＳ１８０−１、「ＳｅｃｕｒｅＨａｓｈＳｔａｎｄａｒｄ」、Ａｐｒｉｌ１９９５に定義されるＳＨＡ１アルゴリズムに基づく。しかしながら、本発明の原理は、この特定のアルゴリズムに限定されないことが理解されるべきである。

擬似乱数のｘを生成するために、事前に構成された１２８ビットのランダムなシード（Ｓ）の、ＳＨＡ１アルゴリズムに規定された従来の初期ベクトル（ＩＶ）とのＸＯＲ（６０２における排他的論理和関数）をとる。

タイムスタンプまたは外部で管理される単調増加カウンタ（Ｃ）は、任意選択で、事前に構成された別の定数（たとえば、５１２ビットの定数）とのＸＯＲをとり（６０４）、ＳＨＡ１の入力への「メッセージ」として適用される（６０６）。ＳＨＡ１の実行から生じる１６０ビットの値ｓがさらに、ｓの各ビットの硬度を確実に等しくするために、Ｒｓ＋ＱｍｏｄＧ関数で「白色化」され（６０８）、得られる１６０ビットの値ｘ（６１０）がディフィーヘルマンタイプのプロトコルに出力される。ここで、ＲおよびＱは、２進数体内の係数をもつ、公に知られている事前に選択された大きい多項式であり、Ｇは多項式（Ｔ^１６０＋Ｔ^５＋Ｔ^２＋１）である。別法として、任意の有限体を使用することができ（２進数体だけではない）、この有限体での任意の既約多項式を使用することができる（上記の特定のＧだけではない）。より一般的には、硬いビットを抽出するために、任意の白色化関数を使用することができる（線形合同ハッシュ関数Ｒｓ＋ＱｍｏｄＧだけではない）。

安全通信クライアントアプリケーションの各インスタンスが、シリアル番号またはクライアント識別情報を使用して追跡される。たとえば、Ａｌｉｃｅ＠ａｂｃｅｎｔｅｒｐｒｉｓｅ．ｃｏｍが、シリアル番号（またはＡｌｉｃｅの識別情報）を有する「ａｂｃｅｎｔｅｒｐｒｉｓｅｓ」から、安全通信クライアントソフトウェアのインスタンスを受け取る。プロバイダは、関連する事前に構成されたランダムなシードＳおよびシステム時間などの単調に増加するカウンタ値Ｃの履歴を記録管理する。これによって、プロバイダは、他の誰かとの鍵交換セッションの間にＡｌｉｃｅが生成する同じ乱数を再生成できるようになる。

鍵を発見し、会話を傍受するための法律上の要件が存在するとき、プロバイダは次いで、先行の鍵交換セッションとともに、暗号化された通信セッションの記録に移行する。オフラインのサーバが次いで、やり取りされた群要素を計算するために、鍵交換プロトコルにおいて開始側（または応答側（複数可））によって使用されたランダムな秘密値を計算する。有利には、これによって、オフラインのサーバは、開始側（および応答側（複数可））が計算した同じセッション鍵を計算できるようになる。

図６に示したＰＲＧは、使用されてもよいＰＲＧの一例でしかないことを理解されたい。別の例として、開示内容の全体が引用により本明細書に組み込まれる３ＧＰＰＴＳ３３．２２０において規定された鍵導出関数ＫＤＦと呼ばれるＰＲＧが使用されてもよい。さらに別のＰＲＧも使用され得る。

図７は、本発明の一実施形態による、秘密値再生でセッション鍵を合法的に発見する方法７００を示す。特に、この実施形態は、クライアントデバイス７０２−Ａとクライアントデバイス７０２−Ｂの間の、傍受および鍵を含むセキュリティアソシエーションの発見を示す。

図示のように、企業サーバ７０８が、移動体ごとの秘密シードＳを、全クライアントデバイス（移動体）に供給し、またこれと平行させて、前記クライアントデバイスに関連する企業サーバ加入に供給することに留意されたい。シードの値は、クライアント加入の存続期間において存在することができ、企業ポリシーに基づいて修正することもできる。クライアントおよび企業サーバにシードＳを供給する方法は、たとえば、工場でのプログラム書き込みから、標準的または事業者固有の供給手順の実行に対する既存の他のセキュリティ資格証明書のブートストラッピングに至るまでの知られている技術のうちの多数を使用することができる。

さらに、図示のように、（本明細書では、信号およびメディアの両方にアクセスできると想定される「傍受ネットワーク要素」と同様に示される）傍受エンティティ７０４が、すべての必要な情報を他のネットワークノードに要求するが、エンドポイントデバイス（７０２−Ａ、７０２−Ｂ）自体には要求しない。したがって、エンドポイントデバイスは、試みられる傍受を認識しない。また、この情報交換は、傍受要件に応じて、通信セッションを実際に開始するかなり前の時間に、またはセッションが終わった後の時間に実施され得る。したがって、この情報交換は、通信セッション中でないことを意味する「オフライン」と呼んでもよい。これによって、ネットワーク要素間で必要とされる調整に関する複雑さが、（図５に示すＭｉｔＭ解決策と比較して）劇的に減少する。しかしながら、代替として、そのような交換または交換の各部分は、通信セッションの間に実施されてもよい。

したがって、図示のように、傍受エンティティ７０４は、クライアントデバイス７０２−Ａに関連付けられた複製されたランダムな「秘密値」ｘを、企業サーバ７０８に要求し、取得する（秘密値という用語は、ここではあえて括弧付きにしており、すなわち、ｘは他者にとって秘密の値であり、したがって厳密に秘密値であるが、ｘは、ｘを再生成できる企業サーバおよび傍受エンティティの両方にとっては秘密の値ではないことに留意されたい）。すなわち、安全鍵を生成するためにクライアント７０２−Ａが使用するアプリケーションは、企業サーバ７０８によってクライアントに提供されたときにクライアント７０２−Ａの識別情報に関連付けられる秘密のランダムなシード（Ｓ）とともに、（クライアント７０２−Ａには気づかれずに）事前に構成されるので、企業サーバ７０８は、同じランダムな「秘密値」ｘを傍受要素７０４に提供する。企業サーバは、アプリケーションプロバイダ／所有者および／またはネットワーク事業者によって管理されてもよいことを想起されたい。傍受サーバは、Ｃ（図６のセッションカウンタ値Ｃを想起されたいが、代替としてＣはセッションのタイムスタンプであってもよい）およびクライアントが監視を望む自らの識別子（この例では、ＩＤ＿Ａ）を送信することによって、企業サーバ７０８に「秘密値」ｘを要求することにも留意されたい。識別情報は、第１のコンピューティングデバイスに関連付けられた加入またはユーザ識別情報でもあり得る。

さらに、傍受エンティティ７０４はＫＭＳ７０６と安全な信頼関係をもつと仮定されており、ＫＭＳは、監視下でエンドポイント（この場合、クライアント７０２−Ａ）に関連付けられた秘密鍵を提供する義務を負った状態である。企業環境では、これは規制上の要件の義務というよりは、遵守要件の問題が大きい。これらのパラメータ（エンドポイントの秘密鍵およびランダムな「秘密値」ｘ）が受信されると、傍受エンティティ７０４は、トラフィックを暗号化する際にＡおよびＢによって使用される秘密のセッション鍵を再生成するためのすべての必要な情報を有し、セッション鍵の合法的な発見は、エンドポイントのそれについての知識なしで適用され得る。

ＫＭＳもネットワーク事業者／企業も、エンドポイント間の通信ストリームを自らが個別に復号することは不可能であり、データの秘密状態はエンドツーエンドで保存されることに注意することは重要である。ＫＭＳ７０６は、エンドポイント７０２−Ａおよび７０２−Ｂの秘密鍵にアクセスできるので、ＩＢＡＫＥプロトコルメッセージの、ＩＢＥで暗号化されたペイロードを復号することが可能であり、これによって、ＩＢＡＫＥメッセージに含めてエンドポイント間で交換されるｘＰおよびｙＰパラメータを取得できるようになる。しかし、ＫＭＳ７０６は、ｘまたはｙのいずれかが分からないので、所望のｘｙＰセッション鍵を再生成する能力はない。同様に、事業者／企業サーバ７０８はｘまたはｙのいずれかを再生成することができるが、エンドポイント７０２−Ａおよび７０２−Ｂの秘密鍵がない状態で、ＩＢＡＫＥメッセージの、ＩＢＥで暗号化されたペイロードを復号する能力はない。したがって、事業者／企業サーバ７０８は、所望のセッション鍵ｘｙＰの再生成にも成功することはできない。セッション鍵を合法的に発見する機能を実施し、ＫＭＳ７０６および企業サーバ７０８の両方からパラメータを受信するエンティティのみ（すなわち、傍受エンティティ７０４）が、トラフィックを復号することができる。しかしながら、両方のエンドポイントが同じ事業者／企業の加入者である場合、企業サーバは、ＫＭＳと協働することなく、セッション鍵を発見するためにセッションで使用されるｘおよびｙの値を簡単に発見することができる。ＫＭＳからの情報は、エンドポイントが、企業サーバが計算したｘおよびｙの値を実際に使用したことを確認することのみに有用である。かかる状況において、そのような確認が必要でない場合、セッション鍵は、さらにセキュリティアソシエーションを合法的に発見する処理を単純化する信号トランザクションの記録さえもなしで発見できることに留意されたい。

図８は、本発明のＩＢＡＫＥの実施形態による、秘密値の再生でセッション鍵を合法的に発見するための呼のフローを示す。理解のしやすさと一貫性のために、呼のフローにおける各要素は、図７に示したものと同じ参照符号を付してあることに留意されたい。また、本発明の合法的なセキュリティアソシエーション発見技術は、任意の特定のプロトコルでの使用に限定されず、したがって、本実施形態におけるＩＢＡＫＥプロトコル（および、下記の図９の場面の中で説明する会議呼び出しの実施形態）は例示目的で使用されていることに留意されたい。

図８に示すように、ステップ１、２、および３は、エンドポイントＡとＢの間での典型的なＩＢＡＫＥプロトコルによる交換を表すことに留意されたい。これらのステップは前述している。ＡまたはＢのいずれかが合法的な傍受の対象である場合、傍受サーバ（傍受エンティティ）７０４は、本発明のセキュリティアソシエーション発見技術を使用することによって、これらの信号トランザクションを監視および記録する。

すなわち、図８のステップ４および５において、傍受サーバ７０４は、ＡおよびＢ用の秘密鍵をＫＭＳ７０６に要求する。このトランザクションは、ＡおよびＢが傍受の対象になるときである実際のＩＢＡＫＥイベントの前に多くが行われ得る。そのような場合、ＡおよびＢが通信を開始するとき、ＡおよびＢの公開鍵および秘密鍵は傍受サーバにおいてすでに利用可能である。

ステップ６および７は、実際のＡ−Ｂ間の通信セッションの前、間、および後の任意の時間に実行されることもある。たとえば、通信セッションが、暗号化された形で傍受サーバによって記録された場合、傍受サーバは、企業サーバ７０８に対する特定のセッションに関連付けられたＣの値（タイムスタンプまたはカウンタ）を提供し、そのセッションに関連付けられたｘを受信する。次いで、傍受サーバは、図示のようにｋを計算し、ＡとＢの間の通信を復号することができる。

エンドポイントＡおよびＢが、異なる事業者／企業の加入者であるだけでなく、秘密鍵を提供するための異なるＫＭＳを使用する場合、傍受がどのように実現されるのかをここでさらに説明する。すなわち、対象のクライアントＡを含むセッションを傍受するために、図８のステップ４および５において、傍受サーバ７０４は、Ａ用の秘密鍵を、クライアントＡに関連するＫＭＳ７０６に要求する。このトランザクションは、Ａが傍受の対象となるときである実際のＩＢＡＫＥイベントの前に多くが行われ得る。

ステップ６および７が、傍受サーバ７０４とクライアントＡに関連する企業サーバ７０８との間で実行され、傍受サーバが、そのセッションに関連付けられたｘを受信する。

クライアントＢが傍受の対象である場合、図８のステップ４および５において、傍受サーバ７０４は、Ｂ用の秘密鍵を、クライアントＢに関連するＫＭＳ７０６に要求する。図８のステップ６および７において、傍受サーバ７０４は、クライアントＢに関連する企業サーバ７０８からｙを取得する。

次いで、傍受サーバは、図８のステップ３で送信される情報を復号し、クライアントＡが送信するｘＰパラメータを取得することができる。ｙおよびｘＰの値を知ると、次いで、傍受サーバは、図示のようにｋを計算し、ＡとＢの間の通信を復号することができる。

Ｖ．グループセッティングにおける改良された合法的なセキュリティアソシエーション発見
次に、会議呼び出し環境などのグループセッティングについて説明する。会議呼び出しにおいて、参加者のグループは鍵要素（ｍａｔｅｒｉａｌ）を交換し、グループ鍵を一致させる。具体的には、ディフィーヘルマンの鍵交換が、グループセッティングに拡張され（たとえば、開示内容の全体が引用により本明細書に組み込まれる、ＢｕｒｍｅｓｔｅｒおよびＤｅｓｍｅｄｔ、「Ａｓｅｃｕｒｅａｎｄｅｆｆｉｃｉｅｎｔｃｏｎｆｅｒｅｎｃｅｋｅｙｄｉｓｔｒｉｂｕｔｉｏｎｓｙｓｔｅｍ」、ＰｒｏｃｅｅｄｉｎｇｓｏｆＥｕｒｏｃｒｙｐｔ ’９４、ＬＮＣＳｖｏｌ．９５０、２７５−２８６ページ、Ｓｐｒｉｎｇｅｒ１９９５参照）、さらにＩＢＡＫＥが、グループセッティング内での認証された鍵の交換に対処するように拡張されている（たとえば、通し番号１２／５４９，９０７で識別され、開示内容全体が引用により本明細書に組み込まれる、２００９年８月２８日に出願の米国特許出願を参照）。この例では、語句「グループセッティング」は、２を超えるユーザのグループを指し、プロトコルによって、すべてのユーザが、安全でない環境で情報を交換できるようになり、限定はしないが会議システムに適用可能なものとして「グループ鍵」を交換できるようになることに注意されたい。

図９は、本発明の一実施形態による、会議呼び出し環境における秘密値の再生でセッション鍵を合法的に発見する方法９００を示す。特に、図９は、ＩＢＡＫＥを使用するグループ鍵の交換を示す。このセッティングにおいて、中央調整サーバ９０４（会議セキュリティサーバと呼ぶ）は、グループ鍵の交換に参加するために、各ユーザ（デバイス９０２−１から９０２−Ｎ）を確認し、認証する。しかしながら、ＩＢＡＫＥ計算から得られるグループ鍵は、中央調整サーバ９０４には知られていない。それでも、遵守要件および他の規制上の要件によって、会議プロバイダはしばしばグループ鍵を発見することが要求される。

図に示すように、個々のユーザが、会議サーバとの間でＩＢＡＫＥを実行する。これによって、サーバは、確認され、許可された参加者のみが呼に入れることを確実にできる。この後、サーバは、ディフィーヘルマン鍵コンポーネントを呼にいる全員と共有し、それによって、各参加者は、追加の鍵コンポーネントを計算し、参加者の残りと（サーバを介して）共有できるようになる。初歩的な群論を用いて、すべての参加者が同じグループ鍵を計算することができるが、会議サーバは鍵を特定することはできないことが容易に観察できる。プロトコルは、図９に９０６として記載してある。

上記のセクションＩＶに記載したように、本発明の合法的な鍵発見技術は、簡単な方法でこのセッティングにも拡張させることができる。ネットワーク事業者または企業または「オーバーザトップ（ｏｖｅｒｔｈｅｔｏｐ）」アプリケーションのプロバイダは、以上説明したように、エンドポイントクライアント（９０２−１から９０２−Ｎ）上で動作するアプリケーションに含まれる同じ擬似乱数生成器のコピーを使用して、ランダムな秘密値を生成し、したがって、計算されたグループ鍵も発見することができる。これは、同じ擬似乱数生成器を使用し、生成器を呼び出すために使用されるパラメータを発見することにより、傍受サーバ（この場合、会議サーバ９０４または何らかの他の傍受エンティティ）が、グループ鍵を計算するためにプロトコルで使用される１つまたは複数の乱数を再生成できるようになるということから導き出される。計算の詳細は、初歩的な群論における簡単なものである。

ＶＩ．例示的なコンピューティングシステム
図１０は、本発明による、ネットワーク環境の汎用ハードウェアアーキテクチャ１０００と、２つのエンティティ間に安全な鍵管理プロトコルを実施し、かつ合法的なセキュリティアソシエーション発見を実施するのに適したコンピューティングデバイスの形態の通信デバイスとを示す。

図１０は、図示のエンティティのうちの２つのみについて詳細な下位構成要素を示すが、他のエンティティも同じ構成を有し得ることを理解されたい。したがって、上記の安全な鍵管理プロトコルおよび合法的なセキュリティアソシエーション発見に関して、詳細に示した２つのエンティティは、開始側クライアントデバイス７０２−Ａ（第１の当事者またはＡ）および応答側クライアントデバイス７０２−Ｂ（第２の当事者またはＢ）であってもよい。しかしながら、ＫＭＳ（７０６）、会議サーバ（９０４）、傍受サーバ（７０４）、機能的要素、追加のクライアントデバイス（当事者）および追加のサーバ（７０８）が、図１０のコンピューティングデバイスに示されるような同じアーキテクチャを備えて実装されてもよい。したがって、一例として、傍受サーバ１０２０、企業サーバ１０２２およびＫＭＳ１０２４を図１０に示してあり、これらはデバイス１００２および１００４に示したものと同じコンピューティングアーキテクチャを有すると理解される。しかしながら、簡単にするために、本発明のプロトコルに参加できるすべてのコンピューティングデバイス（通信デバイス）は図１０に図示していないことを理解されたい。

図示のように、１００２で示すＡのコンピューティングデバイスと、１００４で示すＢのコンピューティングデバイスとが、ネットワーク１００６を介して結合される。ネットワークは、それを介してデバイス同士が通信できる任意のネットワークであってもよく、たとえば、上記の実施形態のように、ネットワーク１００６は、ネットワーク事業者（たとえば、Ｖｅｒｉｚｏｎ、ＡＴ＆Ｔ、Ｓｐｒｉｎｔ）が運用するセルラー通信ネットワークなどの公にアクセス可能な広域通信ネットワークを含み得る。しかしながら、本発明は、特定のタイプのネットワークには限定されない。通常、デバイスはクライアントマシンであり得る。本明細書に記載のプロトコルに参加するために当事者によって使用され得るクライアントデバイスの例としては、セルラー電話、スマートフォン、デスクトップフォン、携帯情報端末、ラップトップコンピュータ、パーソナルコンピュータなどが挙げられるが、これらに限定はされない。すでに説明したように、クライアントは、コンピューティングデバイス（たとえば、スマートフォン）上のアプリケーションでもあり得ることも想起されたい。しかしながら、デバイスの１つまたは複数は、サーバ（たとえば、傍受サーバ、企業サーバ、ＫＭＳサーバなど）であり得る。したがって、本発明のプロトコルおよび方法は、コンピューティングシステムがそれぞれクライアントとサーバである場合に限らず、代わりに、２つのネットワーク要素を含む任意のコンピューティングデバイスに適用可能であることを理解されたい。

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

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

したがって、本明細書に記載している本発明の方法を実施するためのソフトウェア命令またはコードは、関連するメモリデバイス、たとえばＲＯＭ、固定型または取り外し可能なメモリのうちの１つまたは複数に格納されていてもよく、使用できるようになったとき、ＲＡＭにロードされ、ＣＰＵによって実行されてもよい。

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

Claims

第１のコンピューティングデバイスと第２のコンピューティングデバイスの間に発見可能なセキュリティアソシエーションを形成する方法であって、
第２のコンピューティングデバイスとの通信を安全にする際に使用される鍵を計算するために、第１のコンピューティングデバイスによって使用される秘密値を生成するために、第１のコンピューティングデバイスによって使用されるシードが、第１のコンピューティングデバイスに提供されるステップであって、第３のコンピューティングデバイスが、第１のコンピューティングデバイスおよび第２のコンピューティングデバイスには気づかれずに、第１のコンピューティングデバイスと第２のコンピューティングデバイスの間の通信を傍受するために再計算された鍵を使用できるように、秘密値はシードの知識に基づいて再計算可能であり、鍵は秘密値の知識に基づいて再計算可能である、提供されるステップを含む、方法。
第１のコンピューティングデバイスが、擬似乱数生成器を含むアプリケーションプログラムを取得する、請求項１に記載の方法。
第１のコンピューティングデバイスが、アプリケーションプログラムを第４のコンピューティングデバイスから取得する、請求項２に記載の方法。
アプリケーションプログラムがシードを提供され、シードが、第１のコンピューティングデバイスに関連付けられた識別子に関連付けられている、請求項２に記載の方法。
アプリケーションプログラムが、擬似乱数生成器を呼び出して、シードに基づいて秘密値を生成する、請求項１に記載の方法。
シードが、少なくとも１つの乱数を含む数の組を含む、請求項１に記載の方法。
第１のコンピューティングデバイスと第２のコンピューティングデバイスの間に形成されたセキュリティアソシエーションを発見する方法であって、
第３のコンピューティングデバイスが秘密値を第４のコンピューティングデバイスから取得するステップであって、秘密値が、第１のコンピューティングデバイスによって生成される同じ秘密値であり、第１のコンピューティングデバイスが、第４のコンピューティングデバイスによって提供されたシードに基づいて秘密値を生成しており、第１のコンピューティングデバイスが、シードを使用して秘密値を生成し、秘密値を使用して、第２のコンピューティングデバイスとの通信を安全にする際に使用される鍵を計算している、取得するステップと、
第１のコンピューティングデバイスおよび第２のコンピューティングデバイスには気づかれずに、第１のコンピューティングデバイスと第２のコンピューティングデバイスの間の通信を傍受するために、第３のコンピューティングデバイスが、秘密値に基づいて鍵を再計算するステップと
を含む、方法。
第３のコンピューティングデバイスが、第１のコンピューティングデバイスに関連付けられた識別情報に関連付けられた値を、第４のコンピューティングデバイスに提供し、それにより、第４のコンピューティングデバイスが、第１のコンピューティングデバイスと第２のコンピューティングデバイスの間の通信を傍受するために第３のコンピューティングデバイスによって鍵の再計算に必要とされる秘密値を返す、請求項７に記載の方法。
第１のコンピューティングデバイスと第２のコンピューティングデバイスの間に発見可能なセキュリティアソシエーションを形成する装置であって、
メモリと、
メモリに結合され、第２のコンピューティングデバイスとの通信を安全にする際に使用される鍵を計算するために、第１のコンピューティングデバイスによって使用される秘密値を生成するために、第１のコンピューティングデバイスによって使用されるシードが、第１のコンピューティングデバイスに提供されるように構成されたプロセッサとを備え、第３のコンピューティングデバイスが、第１のコンピューティングデバイスおよび第２のコンピューティングデバイスには気づかれずに、第１のコンピューティングデバイスと第２のコンピューティングデバイスの間の通信を傍受するために再計算された鍵を使用できるように、秘密値はシードの知識に基づいて再計算可能であり、鍵は秘密値の知識に基づいて再計算可能である、装置。
第１のコンピューティングデバイスと第２のコンピューティングデバイスの間に形成されたセキュリティアソシエーションを発見する装置であって、
メモリと、
メモリに結合され、第３のコンピューティングデバイスが、秘密値を第４のコンピューティングデバイスから取得するように構成されたプロセッサとを備え、秘密値が、第１のコンピューティングデバイスによって生成される同じ秘密値であり、第１のコンピューティングデバイスが、第４のコンピューティングデバイスによって提供されたシードに基づいて秘密値を生成しており、第１のコンピューティングデバイスが、シードを使用して秘密値を生成し、秘密値を使用して第２のコンピューティングデバイスとの通信を安全にする際に使用される鍵を計算しており、したがって、第３のコンピューティングデバイスが、第１のコンピューティングデバイスおよび第２のコンピューティングデバイスには気づかれずに、第１のコンピューティングデバイスと第２のコンピューティングデバイスの間の通信を傍受するために、秘密値に基づいて鍵を再計算する、装置。