(57)【要約】  ピアツーピア環境内でネットワーク支援型セキュア通信を確立する技法を開示する。たとえば、セキュア通信の方法は、次のステップを含む。第１コンピューティングデバイスは、それに関連する接続性情報をネットワークサーバに提供する。第１コンピューティングデバイスは、１つまたは複数の他のコンピューティングデバイスにそれぞれ関連する接続性情報をネットワークサーバから受信する。第１コンピューティングデバイスは、ネットワークサーバとは独立に、１つまたは複数の他のコンピューティングデバイスのうちの少なくとも１つとのセキュリティアソシエーションを確立する。第１コンピューティングデバイスは、ネットワークサーバとは独立に、少なくとも１つの他のコンピューティングデバイスとのセキュアピアツーピアセッションに参加する。
2015503261.tif 000002
【特許請求の範囲】
【請求項１】
第１コンピューティングデバイスによって、それに関連する接続性情報をネットワークサーバに提供することと、
第１コンピューティングデバイスで、１つまたは複数の他のコンピューティングデバイスにそれぞれ関連する接続性情報をネットワークサーバから受信することと、
第１コンピューティングデバイスによって、ネットワークサーバとは独立に、１つまたは複数の他のコンピューティングデバイスのうちの少なくとも１つとのセキュリティアソシエーションを確立することと、
第１コンピューティングデバイスによって、ネットワークサーバとは独立に、少なくとも１つの他のコンピューティングデバイスとのセキュアピアツーピアセッションに参加することと
を含む、セキュア通信の方法。
【請求項２】
第１コンピューティングデバイスによって、ネットワークサーバからの１つまたは複数の他のコンピューティングデバイスにそれぞれ関連する接続性情報を要求することをさらに含む、請求項１に記載の方法。
【請求項３】
第１コンピューティングデバイスで、１つまたは複数の他のコンピューティングデバイスにそれぞれ関連する接続性情報をネットワークサーバから周期的に受信することをさらに含む、請求項１に記載の方法。
【請求項４】
ネットワークサーバでの１つまたは複数の他のコンピューティングデバイスのうちの少なくとも１つからの更新された接続性情報の受信の後に、第１コンピューティングデバイスで、１つまたは複数の他のコンピューティングデバイスにそれぞれ関連する接続性情報をネットワークサーバから受信することをさらに含む、請求項１に記載の方法。
【請求項５】
第１コンピューティングデバイスで、１つまたは複数の他のコンピューティングデバイスにそれぞれ関連する接続性情報をネットワークサーバから受信するステップは、第１コンピューティングデバイスによって、ネットワークサーバに常駐する１つまたは複数のリソースコンテナを読み取ることをさらに含む、請求項１に記載の方法。
【請求項６】
第１コンピューティングデバイスがその接続性情報をネットワークサーバに提供する前に、第１コンピューティングデバイスによって、ネットワークサーバに登録することをさらに含む、請求項１に記載の方法。
【請求項７】
第１コンピューティングデバイスをネットワークサーバから登録解除することをさらに含む、請求項６に記載の方法。
【請求項８】
第１コンピューティングデバイスによって、少なくとも１つの他のコンピューティングデバイスとのセキュリティアソシエーションを確立するステップは、アイデンティティベースの認証された鍵交換プロトコルに従って実行される、請求項１に記載の方法。
【請求項９】
コンピューティングデバイスであって、
メモリと、
メモリに動作可能に結合され、コンピューティングデバイスに、
コンピューティングデバイスに関連する接続性情報をネットワークサーバに提供させ、
１つまたは複数の他のコンピューティングデバイスにそれぞれ関連する接続性情報をネットワークサーバから受信させ、
ネットワークサーバとは独立に、１つまたは複数の他のコンピューティングデバイスのうちの少なくとも１つとのセキュリティアソシエーションを確立させ、
ネットワークサーバとは独立に、少なくとも１つの他のコンピューティングデバイスとのセキュアピアツーピアセッションに参加させる
ように構成されたプロセッサデバイスと
を含むコンピューティングデバイス。
【請求項１０】
通信モジュールと、
通信モジュールに動作可能に結合された暗号モジュールと
を含むシステムであって、通信モジュールおよび暗号モジュールは、
接続性情報をネットワークサーバに提供するステップと、
１つまたは複数のコンピューティングデバイスにそれぞれ関連する接続性情報をネットワークサーバから受信するステップと、
ネットワークサーバとは独立に、１つまたは複数のコンピューティングデバイスのうちの少なくとも１つとのセキュリティアソシエーションを確立するステップと、
ネットワークサーバとは独立に、少なくとも１つのコンピューティングデバイスとのセキュアピアツーピアセッションに参加するステップと
を実行するために協力する
システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に通信セキュリティに関し、より詳細には、ピアツーピア環境でセキュア通信を確立する技法に関する。
【背景技術】
【０００２】
ピアツーピア（ｐ２ｐ）コンピューティングまたはｐ２ｐネットワーキングは、ピアと称するコンピューティングデバイスの間でタスクまたはワークロードを分割する分散アプリケーションアーキテクチャである。用語「ピア」は、通常、そのように指定されるコンピューティングデバイスが、所与のアプリケーションに関して機能性において実質的に同等であることを表す。
【０００３】
しかし、分散アーキテクチャ内で動作するすべてのコンピューティングデバイスと同様に、ピアの間でのエンドツーエンド通信交換をセキュア化することが重要であると理解されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】米国特許第７９０４７１５号明細書
【非特許文献】
【０００５】
【非特許文献１】Ｔ．ＤｉｅｒｋｓおよびＥ．Ｒｅｓｃｏｒｌａ、「Ｔｈｅ  Ｔｒａｎｓｐｏｒｔ  Ｌａｙｅｒ  Ｓｅｃｕｒｉｔｙ（ＴＬＳ）Ｐｒｏｔｏｃｏｌ  Ｖｅｒｓｉｏｎ  １．２」、ＩＥＴＦ  ＲＦＣ  ５２４６
【非特許文献２】Ｊ．Ａｒｋｋｏ他、「Ｅｘｔｅｎｓｉｂｌｅ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ  ｆｏｒ  ３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  ａｎｄ  Ｋｅｙ  Ａｇｒｅｅｍｅｎｔ（ＥＡＰ−ＡＫＡ））」、ＩＥＴＦ  ＲＦＣ  ４１８７
【非特許文献３】Ａ．Ｂｒｕｓｉｌｏｖｓｋｙ他、「Ｐａｓｓｗｏｒｄ−Ａｕｔｈｅｎｔｉｃａｔｅｄ  Ｋｅｙ（ＰＡＫ）Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ  Ｅｘｃｈａｎｇｅ」、ＩＥＴＦ  ＲＦＣ  ５６８３
【非特許文献４】Ｖ．ＣａｋｕｌｅｖおよびＧ．Ｓｕｎｄａｒａｍ、「ＩＢＡＫＥ：  Ｉｄｅｎｔｉｔｙ−Ｂａｓｅｄ  Ａｕｔｈｅｎｔｉｃａｔｅｄ  Ｋｅｙ  Ａｇｒｅｅｍｅｎｔ」、ＩＥＴＦ  Ｉｎｔｅｒｎｅｔ−Ｄｒａｆｔ、２０１１年４月２０日
【非特許文献５】Ｊ．Ｆｒａｎｋｓ他「ＨＴＴＰ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ：Ｂａｓｉｃ  ａｎｄ  Ｄｉｇｅｓｔ  Ａｃｃｅｓｓ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ」、ＩＥＴＦ  ＲＦＣ  ２６１９
【非特許文献６】Ｒ．Ｆｉｅｌｄｉｎｇ他、「Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ  −  ＨＴＴＰ／１．１」、ＩＥＴＦ  ＲＦＣ  ２６１６
【非特許文献７】Ｊ．Ｃ．Ｓｎａｄｅｒ、「Ｅｆｆｅｃｔｉｖｅ  ＴＣＰ／ＩＰ  Ｐｒｏｇｒａｍｍｉｎｇ：  ４４  Ｔｉｐｓ  ｔｏ  Ｉｍｐｒｏｖｅ  Ｙｏｕｒ  Ｎｅｔｗｏｒｋ  Ｐｒｏｇｒａｍｓ」、Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ  Ｐｒｏｆｅｓｓｉｏｎａｌ、ＩＳＢＮ−１０：９７８０２０１６１５８９０、２０００年５月
【非特許文献８】Ｚ．Ｓｈｅｌｂｙ他、Ｃｏｎｓｔｒａｉｎｅｄ  Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ（ＣｏＡＰ）、Ｄｒａｆｔ−ＩＥＴＦ−Ｃｏｒｅ−ＣｏＡｐ−０２
【非特許文献９】Ｈ．Ｓｃｈｕｌｚｒｉｎｎｅ他、「ＲＴＰ  Ｐｒｏｆｉｌｅ  ｆｏｒ  Ａｕｄｉｏ  ａｎｄ  Ｖｉｄｅｏ  Ｃｏｎｆｅｒｅｎｃｅｓ  ｗｉｔｈ  Ｍｉｎｉｍａｌ  Ｃｏｎｔｒｏｌ」、ＩＥＴＦ  ＲＦＣ  ３５５１
【非特許文献１０】Ｐ．Ｈｅｔｈｍｏｎ、「Ｅｘｔｅｎｓｉｏｎｓ  ｔｏ  ＦＴＰ」、ＩＥＴＦ  ＲＦＣ  ３６５９
【非特許文献１１】ＩＥＴＦ  ＲＦＣ  ６２６７
【非特許文献１２】Ｊ．Ｇａｌｂｒａｉｔｈ、「ＳＳＨ  Ｆｉｌｅ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ」、ＩＥＴＦ  Ｄｒａｆｔ  ２００６
【非特許文献１３】Ｍ．Ｂａｕｇｈｅｒ他、「Ｔｈｅ  Ｓｅｃｕｒｅ  Ｒｅａｌ−ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ（ＳＲＴＰ）」、ＩＥＴＦ  ＲＦＣ  ３７１１
【非特許文献１４】Ｘ．Ｂｏｙｅｎ他、「Ｉｄｅｎｔｉｔｙ−Ｂａｓｅｄ  Ｃｒｙｐｔｏｇｒａｐｈｙ  Ｓｔａｎｄａｒｄ（ＩＢＣＳ）＃１：Ｓｕｐｅｒｓｉｎｇｕｌａｒ  Ｃｕｒｖｅ  Ｉｍｐｌｅｍｅｎｔａｔｉｏｎｓ  ｏｆ  ｔｈｅ  ＢＦ  ａｎｄ  ＢＢ１  Ｃｒｙｐｔｏｓｙｓｔｅｍｓ」、ＩＥＴＦ  ＲＦＣ  ５０９１、２００７年１２月
【非特許文献１５】３ＧＰＰ  Ｔｅｃｈｎｉｃａｌ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ  Ｇｒｏｕｐ  Ｓｅｒｖｉｃｅｓ  ａｎｄ  Ｓｙｓｔｅｍ  Ａｓｐｅｃｔｓ；ＩＰ  Ｍｕｌｔｉｍｅｄｉａ  Ｓｕｂｓｙｓｔｅｍ（ＩＭＳ）；Ｓｔａｇｅ  ２（Ｒｅｌｅａｓｅ  １０）、２０１１年１月
【非特許文献１６】Ｍ．Ｊ．Ｄｏｎａｈｏｏ他、「ＴＣＰ／ＩＰ  Ｓｏｃｋｅｔｓ  ｉｎ  Ｃ：Ｐｒａｃｔｉｃａｌ  Ｇｕｉｄｅ  ｆｏｒ  Ｐｒｏｇｒａｍｍｅｒｓ」、Ｓｅｃｏｎｄ  Ｅｄｉｔｉｏｎ、ＩＳＢＮ−１０：０−１２−３７４５４０−３、２００９年
【非特許文献１７】Ｄ．Ｂｏｎｅｈ他、「Ｉｄｅｎｔｉｔｙ−Ｂａｓｅｄ  Ｅｎｃｒｙｐｔｉｏｎ  ｆｒｏｍ  ｔｈｅ  Ｗｅｉｌ  Ｐａｉｒｉｎｇ」、Ａｄｖａｎｃｅｓ  ｉｎ  Ｃｒｙｐｔｏｌｏｇｙ−Ｐｒｏｃｅｅｄｉｎｇｓ  ｏｆ  ＣＲＹＰＴＯ  ２００１（２００１年）
【発明の概要】
【課題を解決するための手段】
【０００６】
本発明の実施形態は、ピアツーピア環境内でネットワーク支援型セキュア通信を確立する技法を提供する。
【０００７】
たとえば、本発明の一実施形態では、セキュア通信の方法は、次のステップを含む。第１コンピューティングデバイスは、それに関連する接続性情報をネットワークサーバに提供する。第１コンピューティングデバイスは、１つまたは複数の他のコンピューティングデバイスにそれぞれ関連する接続性情報をネットワークサーバから受信する。第１コンピューティングデバイスは、ネットワークサーバとは独立に、１つまたは複数の他のコンピューティングデバイスのうちの少なくとも１つとのセキュリティアソシエーションを確立する。第１コンピューティングデバイスは、ネットワークサーバとは独立に、少なくとも１つの他のコンピューティングデバイスとのセキュアピアツーピアセッションに参加する。
【０００８】
もう１つの実施形態では、コンピューティングデバイスは、メモリと、メモリに動作可能に結合されたプロセッサデバイスとを含む。メモリおよびプロセッサデバイスは、コンピューティングデバイスに：コンピューティングデバイスに関連する接続性情報をネットワークサーバに提供させ、１つまたは複数の他のコンピューティングデバイスにそれぞれ関連する接続性情報をネットワークサーバから受信させ、ネットワークサーバとは独立に、１つまたは複数の他のコンピューティングデバイスのうちの少なくとも１つとのセキュリティアソシエーションを確立させ、ネットワークサーバとは独立に、少なくとも１つの他のコンピューティングデバイスとのセキュアピアツーピアセッションに参加させるように構成される。
【０００９】
さらなる実施形態では、システムは、通信モジュールと、通信モジュールに動作可能に結合された暗号モジュールとを含む。通信モジュールおよび暗号モジュールは：接続性情報をネットワークサーバに提供するステップと、１つまたは複数のコンピューティングデバイスにそれぞれ関連する接続性情報をネットワークサーバから受信するステップと、ネットワークサーバとは独立に、１つまたは複数のコンピューティングデバイスのうちの少なくとも１つとのセキュリティアソシエーションを確立するステップと、ネットワークサーバとは独立に、少なくとも１つのコンピューティングデバイスとのセキュアピアツーピアセッションに参加するステップとを実行するために協力する。
【００１０】
有利なことに、本発明の技法は、ネットワーク支援型ピアツーピアセキュア通信を提供する。
【００１１】
本発明の上記および他の目的、特徴、および利点は、添付図面と共に読まれるべき、本発明の例示的実施形態の次の詳細な説明から明らかになる。
【図面の簡単な説明】
【００１２】
【図１Ａ】本発明の実施形態による、ネットワーク支援型ピアツーピアセキュア通信を示す図である。
【図１Ｂ】本発明の実施形態による、ピアのコンポーネントモジュールを示す図である。
【図２】本発明の実施形態による、ピアとネットワークサーバとの間の通信プロトコルを示す図である。
【図３】本発明の実施形態による、セキュア鍵交換を示す図である。
【図４】本発明の実施形態による、ピアの間の通信用の通信モジュールの動作を示す図である。
【図５】本発明の実施形態による、第１の認証された鍵交換メッセージ（ｆｉｒｓｔ  ａｕｔｈｅｎｔｉｃａｔｅｄ  ｋｅｙ  ｅｘｃｈａｎｇｅ  ｍｅｓｓａｇｅ）を準備する暗号モジュールの動作を示す図である。
【図６】本発明の実施形態による、暗号モジュールの代替実施態様を示す図である。
【図７】本発明の実施形態による、第２の識別子ベースの認証された鍵交換メッセージを受信する際の起動側の暗号モジュールの動作を示す図である。
【図８】本発明の実施形態による、第２の識別子ベースの認証された鍵交換メッセージを受信する際の応答側の暗号モジュールの動作を示す図である。
【図９】本発明の実施形態による、第３の認証された鍵交換メッセージ受信する際の応答側の暗号モジュールの動作を示す図である。
【図１０】本発明の１つまたは複数の実施形態による方法論およびプロトコルのうちの１つまたは複数を実施するのに適する通信システムおよびコンピューティングデバイスの一部のハードウェアアーキテクチャを示す図である。
【発明を実施するための形態】
【００１３】
本発明の実施形態は、下で、例示的な相互認証プロトコルおよび鍵交換プロトコルの状況で説明される。しかし、本発明の実施形態が、特定の相互認証プロトコルおよび鍵交換プロトコルに限定されないことを理解されたい。そうではなく、本発明の実施形態は、ネットワーク支援型ピアツーピアセキュア通信を提供することが望ましい任意の適切な通信環境に適用可能である。
【００１４】
本明細書で使用される用語「ピア」は、全般的に、別のコンピューティングデバイス（すなわち、ピア）と機能性において実質的に同等であるコンピューティングデバイスと定義される。本明細書に記載の各ピアは、下でさらに詳細に説明されるように、そのピアがデータセッションの「起動側」（したがって、クライアント）または応答側（したがって、サーバ）のどちらであるのかに応じて、「クライアント」または「サーバ」として動作することもできることを理解されたい。したがって、所与のピアは、クライアントとサーバとの両方として動作する能力を有する。さらに、本明細書で使用される「ピアツーピア関係」は、全般的に、複数のピアの間のデータセッションまたは通信セッション（セキュアピアツーピアセッション）の存在と定義される。
【００１５】
本明細書で使用される句「ネットワークサーバ」は、全般的に、実質的に通信ネットワークのオペレータ（すなわち、ネットワークオペレータ）またはアプリケーションもしくはサービスのオペレータもしくはプロバイダ（すなわち、アプリケーションプロバイダ／オペレータまたはサービスプロバイダ／オペレータ）の制御下にある１つまたは複数のコンピューティングデバイス（サーバデバイス）と定義される。そのようなネットワークオペレータの例は、ＡＴ＆Ｔ（商標）、Ｖｅｒｉｚｏｎ（商標）、ＮＴＴ（商標）、Ｃｈｉｎａ  Ｍｏｂｉｌｅ（商標）、およびＦｒａｎｃｅ  Ｔｅｌｅｃｏｍ／Ｏｒａｎｇｅ（商標）を含むことができるが、これに限定はされない。そのようなアプリケーションプロバイダの例は、Ｓｋｙｐｅ（商標）、Ｇｏｏｇｌｅ（商標）、Ｙａｈｏｏ（商標）、およびＭＳＮ（商標）を含むことができるが、これに限定はされない。通信ネットワークのオペレータまたはサービスのオペレータの「実質的に制御下」という句によって、ネットワークオペレータが、ネットワークサーバの機能性および動作を維持し、かつ／または管理し、アプリケーションプロバイダ／オペレータまたはサービスプロバイダ／オペレータの場合には、プロバイダ／オペレータが、ネットワークサーバの機能性および動作を維持し、かつ／または管理することを意味する。
【００１６】
さらに、本明細書でネットワークサーバに言及する時には、ネットワークサーバが、単一のサーバデバイスまたは複数のサーバデバイスを含むことができることを理解されたい。複数のサーバデバイスは、同一位置に配置され、またはお互いからリモートとすることができる。ネットワークサーバが、複数のサーバデバイスを含む時に、複数のサーバデバイスのうちの異なるサーバデバイスは、ピアに関して異なる動作を実行することができる。
【００１７】
本明細書で使用される用語「鍵」は、全般的に、エンティティ認証、プライバシ、メッセージ完全性、その他などであるがこれに限定されない目的のための、暗号プロトコルへの入力と定義される。
【００１８】
本明細書で使用される用語「セキュリティアソシエーション」は、全般的に、複数の当事者および／またはデバイスがそれを介して通信する通信環境でのセキュリティ定義を指す。一例では、セキュリティ定義は、セッション鍵を含むことができるが、これに限定はされない。
【００１９】
下で詳細に説明されるように、本発明の例示的な実施形態は、ピアとして動作するコンピューティングデバイスの間の通信の確立を支援する方法論を提供し、ここで、ピアは、接続性情報の欠如に起因して、先験的にそのフェローピア（１つまたは複数）に達することはできない。そのような設定では、下でさらに詳細に説明されるように、各ピアは、ネットワーク内のネットワークサーバにセキュアに連絡し、登録し、それ自体の接続性情報（たとえば、そのインターネットプロトコル（ＩＰ）アドレス）をネットワークサーバに与える。また、ピアは、好ましくはばら（ｂｕｌｋ）で、関心を持たれているすべての他の登録されたピアの接続性情報（たとえば、ＩＰアドレス）を要求する。入手された接続性情報は、ピアによって、フェローピア（１つまたは複数）に直接に、すなわち、ネットワークによるさらなる支援なしで、より具体的にはネットワークサーバと独立に、セキュアに連絡することに向けて使用される。ＩＰアドレス以外の他の形の接続性情報が、使用され得、たとえば、リンク層属性は、１つの代替の例である。一般に、接続性情報は、別のコンピューティングデバイスが所与のコンピューティングデバイスに接続する（たとえば、データセッション内で通信する）ことができるようにするための、所与のコンピューティングデバイスに関するロケーション情報を提供する任意の形の情報とすることができる。コンピューティングデバイスは、モバイル（たとえば、セルラ電話機など）または固定（たとえば、ゲートウェイなど）とすることができる。
【００２０】
コンピューティングデバイスは、登録されたピアがＩＰアドレス情報またはある他の形の接続性情報を使用して相互に到達可能である、ＩＰ対応環境で動作しつつあると仮定される。ピアとネットワークサーバとの間ならびにピアの間の通信は、セキュアな形で実行される。セキュアピアツーピアセッション確立は、ピアの間の相互認証および鍵共有（ｋｅｙ  ａｇｒｅｅｍｅｎｔ）を含み、共有されるセッション鍵をもたらす。そのような鍵は、その後、対応するユーザの間の通信をセキュア化するために、サードパーティアプリケーションに配送され得る。そのようなサードパーティアプリケーションの例は、音声アプリケーション、ビデオアプリケーション、メッセージングアプリケーション、ならびに写真共有およびセキュアファイル共有などのアプリケーションを含むことができるが、これに限定はされない。
【００２１】
図１Ａは、本発明の実施形態による、ネットワーク支援型ピアツーピアセキュア通信システムを示す。図示されているように、通信システム１００は、第１ピア１０２−１、第２ピア１０２−２、第１基地局１０４−１、第２基地局１０４−２、およびネットワークサーバ１０６を含む。「通信システム」が、ピアと、ネットワークサーバが属する「通信ネットワーク」とを含むシステム全体を指すことに留意されたい（通信ネットワークおよびネットワークサーバは、対応するネットワークオペレータによって管理され、維持される）。
【００２２】
また、基地局１０４−１および１０４−２が、ネットワークサーバ１０６およびお互いと通信するのにピア１０２−１および１０２−２によって使用される通常のアクセスポイントであり、さらには説明されないことに留意されたい。
【００２３】
さらに、説明の単純さのために、図１Ａには２つのピアだけが示されているが、システム１００が、通常は３つ以上のピアを有すると理解されることに留意されたい。また、システム１００は、複数のネットワークサーバを含むことができる、すなわち、ピアの異なるグループは、異なるネットワークサーバと通信することができ、さまざまなネットワークサーバは、それらの間で接続性情報を渡すことができる。また、上で言及したように、「ネットワークサーバ」は、複数のサーバデバイスを含むことができる。
【００２４】
システム１００は、ＩＰパケットルーティング能力（または、リンク層もしくはネットワーク層でのある形のパケット転送能力）を有し、パケットを渡すために無線リンクおよび／または有線リンクを含むことができると仮定される。
【００２５】
ネットワークサーバ１０６は、接続性情報を維持し、登録されたピアに広める。ピア登録の際に、サーバは、ピアから接続性情報（たとえば、そのＩＰアドレス）を入手し、関心を持たれている登録されたフェローピアの接続性情報をピアに提供する。ネットワークサーバは、ピア登録の一部として、ネットワークサーバと各ピアとの間の相互認証の機構および鍵共有の機構を提供する。
【００２６】
ピア１０２−１および１０２−２は、エンドツーエンドデータ接続を確立することを望み、これを行うために、お互いのＩＰアドレスなどの接続性情報を必要とすると仮定される。有利なことに、各ピアは、関心を持たれている他のピアのそのような情報を入手するために、ネットワークサーバ１０６に登録する。
【００２７】
ピアは、その接続性情報が必要とされる他のピアの特定のセット（たとえば、「フレンド」）を選択することができる。ネットワークサーバまたは異なるサーバのいずれかが、ピア登録の際に、各ピアのグループ−フレンドの形成を処理することができる。そのような登録は、接続性情報が認証されたサーバから来ることをピアが検証するために、ネットワークサーバ１０６との相互認証および鍵共有の手順を含む。接続性情報を入手した後に、ピアは、データセッションを介して直接に、すなわち、ネットワークサーバからのさらなる支援なしに、別のピアに連絡することができる。
【００２８】
１．ネットワークサーバへのピア登録
ネットワークサーバ１０６は、関心を持たれているピアに到達するための接続性情報を提供する。これを行うために、各ピアは、まず、ネットワークサーバに登録する必要がある（アカウントが、特定のピアについてネットワークサーバ上に既に存在すると仮定する、すなわち、本発明者らは、ピアが前もってネットワークサーバにブートストラップしたと仮定する）。ネットワークサーバへの登録は、ピアおよびネットワークサーバがお互いのアイデンティティを検証するため、ならびに、潜在的に本質的に非セキュアなネットワークを介してセキュアセッションを確立するために、相互認証および鍵共有の手順を含むことができる。
【００２９】
相互認証および鍵共有を実行できる複数の異なる形がある。例は、その開示は引用によりその全体が本明細書に組み込まれている：ＴＬＳ（Ｔ．ＤｉｅｒｋｓおよびＥ．Ｒｅｓｃｏｒｌａ、「Ｔｈｅ  Ｔｒａｎｓｐｏｒｔ  Ｌａｙｅｒ  Ｓｅｃｕｒｉｔｙ（ＴＬＳ）Ｐｒｏｔｏｃｏｌ  Ｖｅｒｓｉｏｎ  １．２」、ＩＥＴＦ  ＲＦＣ  ５２４６参照）、ＡＫＡ（Ｊ．Ａｒｋｋｏ他、「Ｅｘｔｅｎｓｉｂｌｅ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ  ｆｏｒ  ３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  ａｎｄ  Ｋｅｙ  Ａｇｒｅｅｍｅｎｔ（ＥＡＰ−ＡＫＡ））」、ＩＥＴＦ  ＲＦＣ  ４１８７参照）、ＰＡＫ（Ａ．Ｂｒｕｓｉｌｏｖｓｋｙ他、「Ｐａｓｓｗｏｒｄ−Ａｕｔｈｅｎｔｉｃａｔｅｄ  Ｋｅｙ（ＰＡＫ）Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ  Ｅｘｃｈａｎｇｅ」参照、ＩＥＴＦ  ＲＦＣ  ５６８３参照）、ＩＢＡＫＥ（Ｖ．ＣａｋｕｌｅｖおよびＧ．Ｓｕｎｄａｒａｍ、「ＩＢＡＫＥ：  Ｉｄｅｎｔｉｔｙ−Ｂａｓｅｄ  Ａｕｔｈｅｎｔｉｃａｔｅｄ  Ｋｅｙ  Ａｇｒｅｅｍｅｎｔ」、ＩＥＴＦ  Ｉｎｔｅｒｎｅｔ−Ｄｒａｆｔ、２０１１年４月２０日、および２００９年２月１７日に出願された米国特許出願第１２／３７２２４２号、名称「Ｉｄｅｎｔｉｔｙ  Ｂａｓｅｄ  Ａｕｔｈｅｎｔｉｃａｔｅｄ  Ｋｅｙ  Ａｇｒｅｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ」参照）、ＨＴＴＰ−Ｄｉｇｅｓｔ（Ｊ．Ｆｒａｎｋｓ他「ＨＴＴＰ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ：Ｂａｓｉｃ  ａｎｄ  Ｄｉｇｅｓｔ  Ａｃｃｅｓｓ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ」参照、ＩＥＴＦ  ＲＦＣ  ２６１９参照）を含むが、これに限定はされない。そのような方法は、ピアおよびネットワークサーバが、同一の共有される秘密を事前にプロビジョニング（またはブートストラップ）されること、ならびに／またはピアおよびネットワークサーバが、それらのために信用証明書を発行できると同時にお互いのアイデンティティを検証する際にそれらを潜在的に支援することができるサードパーティ（認証機関またはキーマネジメントサーバなど）を信頼することのいずれかを仮定する。
【００３０】
２．接続性情報の交換
登録に成功したとき、ピア（たとえば、１０２−１）およびネットワークサーバ１０６は、接続性情報、たとえば、この実施形態ではＩＰアドレス情報の交換に進む。接続情報の他の形は、Ｖｉｓｉｔｅｄ  ＩＰアドレス（Ｍｏｂｉｌｅ  ＩＰを使用する場合）、リンク層アイデンティティ（たとえば、それらがＨＳＰＡ（Ｈｉｇｈ  Ｓｐｅｅｄ  Ｐａｃｋｅｔ  Ａｃｃｅｓｓ）またはＨＲＰＤ（Ｈｉｇｈ  Ｒａｔｅ  Ｐａｃｋｅｔ  Ｄａｔａ）でどのＲＮＣ（無線ネットワーク制御装置）にアタッチされているのか、それらがＷｉＦｉ（Ｗｉｒｅｌｅｓｓ  Ｆｉｄｅｌｉｔｙ）でどのＷＬＡＮ（無線ローカルエリアネットワーク）スイッチにアタッチされているのか、または、より一般的にレイヤ２アイデンティティ）を含むことができるが、これに限定はされない。
【００３１】
より具体的には、ピアは、その接続性情報をネットワークサーバに提供する。この接続性情報は、ネットワークサーバで格納され、他の登録され認可されたピアから使用可能である。
【００３２】
各ピアは、通常、フェローピアの特定のグループ（フレンド、バディリスト）に関連し、この情報は、ネットワークサーバから使用可能である。すべての提携されたオンラインフレンドの接続性情報を有するリストが、登録に成功したとき、好ましくはピア登録中に確立されたセキュア化されたセッションを介して（上で議論したように）、ばらで各登録されたピアにプロビジョニングされる。ピアは、ＩＰアドレス（たとえば）のリストを入手するや否や、入手されたリスト内の対応するＩＰアドレス（１つまたは複数）を使用して、そのオンラインフレンドのいずれかとのエンドツーエンドセッション確立を独立に開始する（または、複数のフレンドピアを含むグループ通信を開始する）ことができる。
【００３３】
ａ．接続性情報分配
オンライン／オフライン情報ならびに接続性情報更新（一例では、オンラインは、ピアが、ページングされ、応答できることを意味し、そうでない場合には、ピアはオフラインである）を考慮に入れて、接続性情報が、ネットワークサーバを介してピアの間で共有され得る複数の異なる形がある。本発明者らは、下でいくつかの例示的な実施形態を提供する。ＩＰアドレスが、ピアによって提供される接続性情報を説明するための例として使用されるが、本発明の実施形態が、これに限定されないことに留意されたい。上で言及したように、他の形の接続性情報を使用することができる。
【００３４】
（ｉ）プル法（ピアによって開始される）：この方法を用いると、ピアは、更新された情報についてネットワークサーバを周期的にポーリングすると同時に、それ自体の情報をネットワークサーバに提供する。ポーリングメッセージ（プル）の受信の際に、ネットワークサーバは、ピアのすべてのオンラインフレンドのリストを、それに対応するＩＰアドレスと一緒に配送する（このリストは、ユニキャストされると同時にマルチキャストされ得る）。そのようなピアによって開始されたポーリングは、通常、周期的な間隔で、ならびに、潜在的にピアのＩＰアドレスが変化する（したがって、ネットワークサーバが通知されることを必要とする）時に必ず、行われる。ピア配備動力学に応じて、そのような方法は、ピアが、かなりの長さの時間にわたって静的でオンラインのままになるシナリオでは、オーバーヘッド集中的になる可能性がある。その一方で、そのようなオーバーヘッドは、ピアが、絶えず移動し（潜在的に、異なるネットワークにまたがってローミングし）、頻繁にオンライン／オフラインになる時には、無視してよい可能性がある。プル法（だけ）が採用される場合に、ピアは、ネットワークサーバへの次にスケジューリングされたプルメッセージまで、最近に登録されたフレンドのオンライン状況について知らされないことにも留意されたい。
【００３５】
（ｉｉ）プッシュ（ネットワークサーバによって開始される）：プッシュ法は、各登録されたピアへのネットワークサーバによる周期的メッセージを用いる。より具体的には、ピア登録の際に、ネットワークサーバは、ピアのＩＰアドレスを格納し、特定のピアの各フレンドに送信される必要があるＩＰアドレスリストを更新する。更新されたリストは、各登録されたフレンドピアへの来るべき周期的プッシュメッセージ内で送信される。そのような周期的プッシュは、ネットワークサーバポリシに基づいて、異なるピアについて異なる頻度を使用して行われ得ることに留意されたい。この方法は、更新が周期的に送信されるのみであり、接続性情報が変更されるや否やではないので、より少なくネットワークオーバヘッド集中的である。したがって、ピアがオンラインまたはオフラインになる場合（または、そのＩＰアドレスもしくは接続性情報が変化する場合）には、そのような情報は、ネットワークサーバによって、次にスケジューリングされたプッシュメッセージ内で叙述されるのみである。その一方で、ピアのＩＰアドレスが、次にスケジューリングされたプッシュメッセージの前に変更される場合には、次のプッシュメッセージの受信の前のそのピアに到達するためのフレンドによるすべての試みが、失敗する。
【００３６】
（ｉｉｉ）ハイブリッド：ハイブリッド法を用いると、ネットワークサーバは、オンラインフレンドおよびそのＩＰアドレスに関する情報が更新されるや否や、その情報を各フレンドピアにプッシュする。より具体的には、ネットワークサーバは、各登録されたピアに送信された最後のオンラインフレンドリストを格納する。ピアが、更新された情報を送信する時には必ず、ネットワークサーバは、ピアの情報を、最後のプッシュメッセージ中にそのフレンドに送信された情報と比較する（上で説明されたプッシュ法に似て）。ネットワークサーバが、不一致を識別する場合には、更新されたプッシュメッセージが、すべての関係するフレンドに送信される。不一致チェックの利点は、ピアに関する情報が変更されない限り、ネットワークサーバが、ピアのフレンドに繰り返してプッシュメッセージを送信する必要がないことである。これは、ピアがその状態を一時的に失うかリセットするシナリオに特にあてはまる可能性がある。そのようなプッシュメッセージが、ピアがネットワークサーバに連絡するたびに、すなわち、後者による不一致チェックなしで、送信され得ることに留意されたい。しかし、その場合には、ピアのフレンドは、それが既に有する（古い）情報を受信する可能性がある。そのようなポリシベースの判断に加えて、ネットワークサーバは、更新されたプッシュメッセージを用いてピアのフレンドに知らせる前に、ピアが少なくとも指定された（ポリシに基づいて）時間期間の間に特定のＩＰアドレスを有してオンラインのままになると期待されるかどうかを判定するために、予測アルゴリズムを実行することもできる。
【００３７】
ｂ．接続性情報のトランスポート
ピアとネットワークサーバとの間の相互認証および鍵共有に成功したとき、接続性情報が、ピアとネットワークサーバとの間で交換される。そのような情報は、その開示は引用によりその全体が本明細書に組み込まれている、ＨＴＴＰ（Ｒ．Ｆｉｅｌｄｉｎｇ他、「Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ  −  ＨＴＴＰ／１．１」、ＩＥＴＦ  ＲＦＣ  ２６１６参照）、生のＴＣＰ（Ｊ．Ｃ．Ｓｎａｄｅｒ、「Ｅｆｆｅｃｔｉｖｅ  ＴＣＰ／ＩＰ  Ｐｒｏｇｒａｍｍｉｎｇ：  ４４  Ｔｉｐｓ  ｔｏ  Ｉｍｐｒｏｖｅ  Ｙｏｕｒ  Ｎｅｔｗｏｒｋ  Ｐｒｏｇｒａｍｓ」、Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ  Ｐｒｏｆｅｓｓｉｏｎａｌ、ＩＳＢＮ−１０：９７８０２０１６１５８９０、２０００年５月）ＣｏＡＰ（Ｚ．Ｓｈｅｌｂｙ他、Ｃｏｎｓｔｒａｉｎｅｄ  Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ（ＣｏＡＰ）、Ｄｒａｆｔ−ＩＥＴＦ−Ｃｏｒｅ−ＣｏＡｐ−０２参照）などであるがこれに限定されない複数の異なる形でトランスポートされ得る。本発明者らは、下で、ＴＣＰソケットがそのようなトランスポートを容易にするのに使用される実施形態を説明する。
【００３８】
ＨＴＴＰは、ネットワークサーバが、たとえばＡＰＡＣＨＥサーバ（たとえば、Ａｐａｃｈｅ  ＨＴＴＰ  Ｓｅｒｖｅｒ  Ｐｒｏｊｅｃｔ参照）などのＨＴＴＰサーバである、古典的なクライアント−サーバ方式で使用され得る。そのような設定は、プル法が使用される時に特に適用可能である。この方法を用いると、ＨＴＴＰクライアント（ピア１０２）は、サーバ（ネットワークサーバ１０６）にＨＴＴＰ要求を周期的に送信する。後者は、ＨＴＴＰクライアントのピアフレンドのＩＰアドレスリストを用いて応答する。
【００３９】
ピアは、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ  Ｓｔａｔｅ  Ｔｒａｎｓｆｅｒ（ＲＥＳＴ）ベースの手法（たとえば、その開示は引用によりその全体が本明細書に組み込まれている、Ｍ．Ｈａｒｔｌ、「Ｒｕｂｙ  ｏｎ  Ｒａｉｌｓ  Ｔｕｔｏｒｉａｌ」および「Ｌｅａｒｎ  ＲＥＳＴ：  Ａ  Ｔｕｔｏｒｉａｌ」参照）で実施されるネットワークサーバを介して接続性情報を交換することもできる。その場合に、ネットワークサーバは、ＲＥＳＴの性質を有する形で設計され、リソースをピアに提供する。リソースは、ピア認証および認可に成功したとき、ＲＥＳＴコマンド（ＲＥＡＤ、ＰＯＳＴ、ＣＲＥＡＴＥ、ＤＥＬＥＴＥ、その他など）を使用して、ピアによってアクセスされ、変更され得る。
【００４０】
ＲＥＳＴに基づく実施形態は、次のように実施され得る。ネットワークサーバへの登録に成功したとき、ピアは、ＨＴＴＰ−ＣＲＥＡＴＥコマンドを使用して、ネットワークサーバのＲＥＳＴの性質を有する領域でリソースを作成することを認可され、さらに、ＨＴＴＰ−ＰＯＳＴコマンドを介して、そのＩＰアドレスを対応するリソースコンテナに書き込む（ポストする）。ネットワークサーバは、ＲＥＳＴアナウンスメントＨＴＴＰメッセージを介して、すべての登録されたフレンドピアに、ピアによるそのようなリソースの作成をアナウンスする。各認可されたフレンドピアは、さらに、そのフレンドのすべてに対応するすべてのリソースにアクセスし、読み取ることができる。
【００４１】
さまざまな最適化が、そのような実施形態に適用され得る。一例として、各ピアに、そのフレンドのすべてのリソースコンテナにアクセスさせ／読み取らせるのではなく、ネットワークサーバのリソースマッピングユーティリティが、特定のピアにとって関心のあるすべてのリソースを、そのピアの新しい単一のリソースにマッピングすることができる。マッピングの際には、ピアが、ネットワークサーバのリソースインフラストラクチャにアクセスする時に、必ず、ピアは、そのフレンドのＩＰアドレスのすべてを有するリストを含む、単一のリソースコンテナを読み取ることだけを必要とする（各フレンドの対応するリソースコンテナを別々に読み取る必要があるのではなく）。
【００４２】
３．ピア登録解除
一実施形態では、ピア（１０２）は、ネットワークサーバ（１０６）から明示的にまたは暗黙のうちに登録解除することができる。
【００４３】
明示的な登録解除を用いると、ピアは、登録解除メッセージをネットワークサーバに送信し、これを用いて、現在の登録およびこれによってセキュリティアソシエーションが、終了し、この登録中のすべての合意された鍵材料は、無効化される。そのような登録解除は、ネットワークサーバがピアを登録解除することを望む場合に、ネットワークサーバによって開始され得る。
【００４４】
暗黙の登録解除を用いると、ピアが、事前に指定された個数のメッセージ再送信の後に、ネットワークサーバによって送信された最後のプッシュ更新メッセージに応答しない場合に、ネットワークサーバは、ピアの現在の登録を無効化する。暗黙の登録解除は、他のネットワークサーバオペレータポリシに基づいても行われ得る。たとえば、登録アクティブ化以降に特定の時間内部が経過した場合、またはピアが、やはりポリシ依存である特定の固定された時間期間の間にネットワークサーバに連絡しなかった場合に、アクティブ登録は、自動的に満了するものとすることができる。
【００４５】
ピアの登録解除の際に、ピアは、オフラインピアとして扱われる。ピアのフレンドは、上で議論された３つの方法（プッシュ、プル、またはハイブリッド）のいずれかを介して通知される。ネットワークサーバからの登録解除が、必ずしもピアがさらに到達不能であることを暗示するものではないことに留意されたい。ピアは、他のピアがそのピアに到達するために接続情報を入手する形がある限り、それでも他のピアによって到達可能である可能性がある。一例として、ピアが登録解除した後に、フレンドは、そのピアに到達するのに、最後の知られているＩＰアドレスを使用することができる。そのようなＩＰアドレスが、まだ有効であり、ピアが、エンドツーエンドセッション要求をリスンする場合には、セッションは、それでもピアの間で確立されるが、ネットワークは、そのような確立の支援を停止している。これは、ネットワークサーバが、登録されたピアにのみ、どのようにしてお互いに到達すべきかに関する情報を提供するからである。ネットワークサーバは、登録解除の前または後に、ピアの間のエンドツーエンドデータセッション確立に関与しない。
【００４６】
４．ｐ２ｐセッションの確立
ネットワークサーバ１０６からの接続性情報の受信の後に、ピア１０２−１は、フレンドピア１０２−２とのエンドツーエンドデータセッションセットアップ手順を開始することができる。さまざまな異なるデータプロトコルが、ピアの間で交換されるトラフィックのタイプに応じてそのようなセッションに使用され得る。たとえば、ＲＴＰ（その開示は引用によりその全体が本明細書に組み込まれている、Ｈ．Ｓｃｈｕｌｚｒｉｎｎｅ他、「ＲＴＰ  Ｐｒｏｆｉｌｅ  ｆｏｒ  Ａｕｄｉｏ  ａｎｄ  Ｖｉｄｅｏ  Ｃｏｎｆｅｒｅｎｃｅｓ  ｗｉｔｈ  Ｍｉｎｉｍａｌ  Ｃｏｎｔｒｏｌ」、ＩＥＴＦ  ＲＦＣ  ３５５１参照）は、オーディオトラフィックおよび／またはビデオトラフィックを含むエンドツーエンドマルチメディアアプリケーションに関して通常好まれるプロトコルである。その一方で、ＦＴＰ（その開示は引用によりその全体が本明細書に組み込まれている、Ｐ．Ｈｅｔｈｍｏｎ、「Ｅｘｔｅｎｓｉｏｎｓ  ｔｏ  ＦＴＰ」、ＩＥＴＦ  ＲＦＣ  ３６５９参照）は、ファイル転送に広く採用されてきたプロトコルであり、使用され得る。上で言及したように、ネットワークサーバ１０６は、ピアの間のデータセッション確立に関与しない。
【００４７】
複数のピアの間でのデータセッションの確立は、エンドツーエンドトラフィックの交換を保護する形としてセキュリティアソシエーション確立を用いることができる。具体的には、ピアは、お互いを相互に認証し、交換されるデータトラフィックの保護にその後に使用されるセッション鍵材料に合意することができる。そのようなセキュアセッションは、対称暗号演算または非対称暗号演算を活用できる異なる方法に従って確立され得る。
【００４８】
対称法は、相互認証およびセッション鍵共有に使用される、各ピアに事前にプロビジョニングされる共有される秘密に頼る。ＴＬＳ−ＰＳＫ（上で引用されたＩＥＴＦ  ＲＦＣ  ５２４６を参照されたい）およびＰＡＫ（上で引用されたＩＥＴＦ  ＲＦＣ  ５６８３を参照されたい）などのプロトコルが、この目的に使用され得る。
【００４９】
そのようなセキュリティアソシエーションは、その代わりに、ＩＢＡＫＥ（その開示は引用によりその全体が本明細書に組み込まれている、Ｖ．ＣａｋｕｌｅｖおよびＧ．Ｓｕｎｄａｒａｍ、「ＩＢＡＫＥ：  Ｉｄｅｎｔｉｔｙ−Ｂａｓｅｄ  Ａｕｔｈｅｎｔｉｃａｔｅｄ  Ｋｅｙ  Ａｇｒｅｅｍｅｎｔ」、ＩＥＴＦ  Ｉｎｔｅｒｎｅｔ−Ｄｒａｆｔ、２０１１年４月２０日、および２００９年２月１７日に出願された米国特許出願第１２／３７２２４２号参照）およびＭＩＫＥＹ−ＩＢＡＫＥ（その開示は引用によりその全体が本明細書に組み込まれている、ＩＥＴＦ  ＲＦＣ  ６２６７参照）などの非対称暗号法を使用して確立され得る。そのような方法によって合意されるセッション鍵は、さらに、その開示は引用によりその全体が本明細書に組み込まれている、ＳＦＴＰ（Ｊ．Ｇａｌｂｒａｉｔｈ、「ＳＳＨ  Ｆｉｌｅ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ」、ＩＥＴＦ  Ｄｒａｆｔ  ２００６参照）およびＳＲＴＰ（Ｍ．Ｂａｕｇｈｅｒ他、「Ｔｈｅ  Ｓｅｃｕｒｅ  Ｒｅａｌ−ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ（ＳＲＴＰ）」、ＩＥＴＦ  ＲＦＣ  ３７１１参照）などのセキュアデータ転送プロトコルによって利用され得る。参加者のグループがある時に、ＩＢＡＫＥの変形形態が、本明細書で説明されるピアツーピアの状況で利用され得ることにも留意されたい。その場合に、セキュリティアソシエーションは、その開示は引用によりその全体が本明細書に組み込まれている、２０１０年８月２３日に出願された、米国特許出願第１２／５４９９０７号、名称「Ｓｅｃｕｒｅ  Ｋｅｙ  Ｍａｎａｇｅｍｅｎｔ  ｉｎ  Ｃｏｎｆｅｒｅｎｃｉｎｇ  Ｓｙｓｔｅｍ」で説明されるｃｏｎｆｅｒｅｎｃｅ  ＩＢＡＫＥプロトコルに従って確立され得る。
【００５０】
ピアが、スマートフォン、ラップトップ、またはタブレットなどのモバイルユーザデバイスであるものとして本明細書で例示的に説明される場合があるが、他のデバイス（モバイルまたは非モバイル）が、本明細書で説明される例示的実施形態のうちの１つまたは複数の状況でピアとして働くことができることに留意されたい。例としてのみ、システム（たとえば、ＰＳＴＮ（公衆交換電話網）システムを伴うＬＴＥ（ロングタームエボリューション）システム）の間のインターオペラビリティをサポートするために、トランスコーディングなどのタスクを実行する、メディアゲートウェイと呼ばれる特殊化された機能の必要がある。その場合に、メディアゲートウェイは、ピアとして働くことができる。したがって、本発明の１つまたは複数の例示的実施形態は、そのようなメディアゲートウェイに適用可能である。
【００５１】
５．ＩＢＡＫＥを用いるｐ２ｐアーキテクチャ
このセクションでは、本発明者らは、発明的なネットワーク支援型ｐ２ｐ通信確立フレームワークの例示的実施形態を説明する。本発明者らが考慮する例の設定は、セキュアマルチメディアセッションを確立することを望む、図１Ａの１０２−１および１０２−２などの２つのピアを含む。これが発生するために、各ピアは、接続性情報を入手するためにネットワークサーバ１０６と通信すると同時に、エンドツーエンドセキュリティアソシエーションの確立に使用されるセキュリティ信用証明書を入手するためにＫＭＳ（キーマネジメントサーバ）と通信する。本発明者らは、各ピアにＩＢＥ秘密鍵をプロビジョニングする際に、ピアの間のそのようなセキュリティアソシエーションを確立するために、上で引用されたＩＢＡＫＥプロトコルを使用する。
【００５２】
より具体的には、ＩＢＡＫＥは、複数のエンドポイントの間での相互認証および鍵共有のプロトコルである。ＩＢＡＫＥは、公開鍵ベースの認証機構に基づき、各メッセージは、アイデンティティベースの暗号化（ＩＢＥ）原理（その開示は引用によりその全体が本明細書に組み込まれている、Ｘ．Ｂｏｙｅｎ他、「Ｉｄｅｎｔｉｔｙ−Ｂａｓｅｄ  Ｃｒｙｐｔｏｇｒａｐｈｙ  Ｓｔａｎｄａｒｄ（ＩＢＣＳ）＃１：Ｓｕｐｅｒｓｉｎｇｕｌａｒ  Ｃｕｒｖｅ  Ｉｍｐｌｅｍｅｎｔａｔｉｏｎｓ  ｏｆ  ｔｈｅ  ＢＦ  ａｎｄ  ＢＢ１  Ｃｒｙｐｔｏｓｙｓｔｅｍｓ」、ＩＥＴＦ  ＲＦＣ  ５０９１、２００７年１２月）により、対応するエンドポイントの公開鍵を用いて暗号化される。
【００５３】
ＩＢＡＫＥプロトコルの結果として、共有される対称鍵が、各エンドポイントによって生成され、この対称鍵は、さらに、エンドポイントの間の通信をセキュア化するのに使用され得る。ＩＢＡＫＥは、共通の対称鍵の生成を必要とする複数の配備シナリオで適用され得る。したがって、ＩＢＡＫＥは、たとえば、ピアの間でエンドツーエンドセキュアマルチメディアセッションを確立するのに、または、さらなる例として、サーバと共にピアを相互に認証し、共通の鍵を導出するのに使用され得る。ＩＢＡＫＥは、公開鍵インフラストラクチャの存在およびそれがこうむる複雑さに依存しない、相互認証および鍵共有手順に基づいて単純化された公開鍵を容易にすることに関して複数の利益を提供する。ＩＢＡＫＥは、当事者の間の相互認証、エスクローフリーの鍵共有、ならびに完全な前方および後方の秘密（ｆｏｒｗａｒｄ  ａｎｄ  ｂａｃｋｗａｒｄｓ  ｓｅｃｒｅｃｙ）を達成する。
【００５４】
ＩＢＡＫＥは、ＩＰ  Ｍｕｌｔｉｍｅｄｉａ  Ｓｕｂｓｙｓｔｅｍ（ＩＭＳ）インフラストラクチャでのメディアプレーンセキュリティ（ｍｅｄｉａ  ｐｌａｎｅ  ｓｅｃｕｒｉｔｙ、ＭＥＤＩＡＳＥＣ）のソリューションとして提案された（その開示は引用によりその全体が本明細書に組み込まれている、３ＧＰＰ  Ｔｅｃｈｎｉｃａｌ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ  Ｇｒｏｕｐ  Ｓｅｒｖｉｃｅｓ  ａｎｄ  Ｓｙｓｔｅｍ  Ａｓｐｅｃｔｓ；ＩＰ  Ｍｕｌｔｉｍｅｄｉａ  Ｓｕｂｓｙｓｔｅｍ（ＩＭＳ）；Ｓｔａｇｅ  ２（Ｒｅｌｅａｓｅ  １０）、２０１１年１月参照）。その範囲で、ＩＢＡＫＥは、ＭＩＫＥＹベースのトランスポートソリューションに関連して提案され、ここで、ＳＩＰ（セッション開始プロトコル）が、通常はセルラアクセスネットワークインフラストラクチャを介して接続される２つのＩＭＳクライアントの間のＩＢＡＫＥ  ３ウェイハンドシェークプロトコルを容易にするために、ＩＭＳ内で活用される。
【００５５】
本発明者らは、ここで、本発明の一実施形態による、ネットワークによって支援されたｐ２ｐセッションセットアップフレームワークの設計および実施態様を説明する。例示的な設計は、各ピア内に常駐する２つのメインモジュール：通信モジュールおよび暗号モジュールを含む。
【００５６】
通信モジュールは、ピアネットワークサーバ通信およびＩＢＡＫＥ  ３ウェイハンドシェークを実現するために、クライアント−サーバＴＣＰ／ＩＰソケットを活用する。さらに、通信モジュールは、ＩＢＥ秘密鍵のセキュアプロビジョニングのための各ピアとキーマネジメントサーバ（ＫＭＳ）との間の通信に、ＨＴＴＰ／ＴＬＳを使用する。暗号モジュールは、ＩＢＡＫＥのすべての楕円曲線暗号（ＥＣＣ）を実行する。
【００５７】
下で説明されるように、これらのモジュールのそれぞれは、さらに、それぞれが１つまたは複数の特定のタスクを実施する複数の他のサブモジュールの組合せとして構造化され得る。本発明者らは、エンドツーエンドセキュアマルチメディアセッション確立を容易にするためのＩＢＡＫＥの使用を仮定する。この状況では、本発明者らは、任意のアクセスネットワーク技術で実行され得、複数のＩＰ対応モバイルユーザすなわちピアの間でエンドツーエンドセキュアマルチメディアセッションを確立することができる、アプリケーション層ユーティリティとしてＩＢＡＫＥをどのように実施すべきかをも説明する。
【００５８】
この設計を例示するために、図１Ｂは、ピアのメインコンポーネントモジュールを示す。図示されているように、各ピア１０２は、通信モジュール１１０および暗号モジュール１１２を含む。下で説明されるように、通信モジュール１１２は、ピアがｐ２ｐデータセッションの「起動側」（たとえば、図１Ａのピア１０２−１）である時にはＴＣＰクライアントとして、ピアがｐ２ｐデータセッションの「応答側」（たとえば、図１Ａのピア１０２−２）である時にはＴＣＰサーバとして働く。本発明者らは、ここで、通信モジュールおよび暗号モジュールの機能を説明する。用語「起動側」および「応答側」が、データセッション内で特定の役割を与えられた特定のピアを参照するのに、下で周期的に使用されることに留意されたい。
【００５９】
ａ．通信モジュール１１０
この例示的実施形態では、インターネットＴＣＰソケットが、それを介して接続性情報が交換される、各ピアとネットワークサーバとの間の通信に使用されると仮定される。
【００６０】
ＩＢＡＫＥピアへのＩＢＥ秘密鍵の配送のためにＩＢＡＫＥピアとキーマネジメントサーバ（ＫＭＳ）との間でセキュアセッションを確立するために、ＨＴＴＰ／ＴＬＳが使用されることも仮定される。この設定では、ＫＭＳは、サーバ側証明書を介してピアに認証され、ピアは、ログインおよびパスワードを使用することによって、ＨＴＴＰ−Ｄｉｇｅｓｔを介して認証される。他の認証技法およびセキュリティアソシエーション技法も適切であることを理解されたい。
【００６１】
さらに、インターネットＴＣＰソケットが、ピアの間でＩＢＡＫＥメッセージを搬送するのに、すなわち、ＩＢＡＫＥ起動側（たとえば、ピア１０２−１）とＩＢＡＫＥ応答側（たとえば、ピア１０２−２）との間での通信を実現するのに使用されると仮定される。ＴＣＰソケットは、その開示は引用によりその全体が本明細書に組み込まれている、Ｍ．Ｊ．Ｄｏｎａｈｏｏ他、「ＴＣＰ／ＩＰ  Ｓｏｃｋｅｔｓ  ｉｎ  Ｃ：Ｐｒａｃｔｉｃａｌ  Ｇｕｉｄｅ  ｆｏｒ  Ｐｒｏｇｒａｍｍｅｒｓ」、Ｓｅｃｏｎｄ  Ｅｄｉｔｉｏｎ、ＩＳＢＮ−１０：０−１２−３７４５４０−３、２００９年、およびＪ．Ｃ．Ｓｎａｄｅｒ、「Ｅｆｆｅｃｔｉｖｅ  ＴＣＰ／ＩＰ  Ｐｒｏｇｒａｍｍｉｎｇ：４４  Ｔｉｐｓ  ｔｏ  Ｉｍｐｒｏｖｅ  Ｙｏｕｒ  Ｎｅｔｗｏｒｋ  Ｐｒｏｇｒａｍｓ」、Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ  Ｐｒｏｆｅｓｓｉｏｎａｌ、ＩＳＢＮ−１０：９７８０２０１６１５８９０、２０００年５月で詳細に説明されている。
【００６２】
ＩＢＡＫＥプロトコルの状況では、起動側は、当初にピアツーピアの形で応答側に連絡すると想定される。これが発生するためには、応答側は、ＩＢＡＫＥセッションを確立する要求を受け入れ、これにサービスすることが可能な状態でなければならない。したがって、応答側は、（アイドルモードで）起動側がＩＢＡＫＥプロトコルを開始するのを待つＴＣＰソケットサーバと考えられ得る。同様に、起動側は、応答側のＴＣＰソケットサーバとのＴＣＰセッションを確立し、さらに、応答側に第１  ＩＢＡＫＥメッセージを送信する、ＴＣＰソケットクライアントとして実現され得る。しかし、起動側がＴＣＰソケットを使用して応答側と通信するためには、応答側のＩＰアドレスが、起動側に知られていなければならないことに留意されたい。これが発生するために、アプリケーション層ユーティリティが使用され、ネットワークサーバは、上で説明されるように、ＩＢＡＫＥ参加者にお互いのＩＰアドレスについて知らせることができる。
【００６３】
これを考慮すると、通信モジュール１１０は、次の４つのメインタスク：（ｉ）ＩＢＡＫＥピアとネットワークサーバとの間の通信、（ｉｉ）ＫＭＳとのセキュアセッション確立、（ｉｉｉ）起動側と応答側との間のＴＣＰセッション確立、および（ｉｖ）ＩＢＡＫＥ  ３ウェイハンドシェークプロトコルを実行する。
【００６４】
（ｉ）ＩＢＡＫＥピア（１つまたは複数）とネットワークサーバとの間の通信
図２は、ＩＢＡＫＥピアとネットワークサーバとの間の通信を示す。図２は、本発明の実施形態による、ピアとネットワークサーバとの間の通信プロトコルを示す。各ＩＢＡＫＥピア１０２（このシナリオでは、起動側および応答側）は、他のピアのＩＰアドレスに関する最も最新の情報を受信するために、ネットワークサーバ１０６を周期的にポーリングする。これは、上のセクション２ａで説明されたプル法である。代替の方法として、やはり上のセクション２ａで説明されたように、プッシュ法またはハイブリッド法のいずれかに従うことができる。
【００６５】
ピア１０２とネットワークサーバ１０６との間の通信は、図２に示された交換２０２で確立されるインターネットＴＣＰソケット手法を介して実現される。より具体的には、ピア（ＩＢＡＫＥ起動側およびＩＢＡＫＥ応答側）は、ネットワークサーバの公に知られているＩＰアドレスを使用して、ネットワークサーバへのＴＣＰソケット接続の確立を独立に開始する。ネットワークサーバは、個々のソケット確立要求を受け入れる。
【００６６】
交換２０４では、各ピアが、ネットワークサーバと相互に認証する。一実施形態では、これは、その開示は引用によりその全体が本明細書に組み込まれている、Ｓ．Ｍｉｚｉｋｏｖｓｋｙ名義で２０１１年３月８日に発行された米国特許第７９０４７１５号で説明されるチャレンジハンドシェーク認証プロトコル（ＣＨＡＰ）を使用して行われ得る。しかし、ＴＬＳ−ＰＳＫなどのさまざまな他の認証プロトコルが、その代わりに使用され得ることが理解される。本発明の状況ではＣＨＡＰを使用して、事前にプロビジョニングされた鍵が、ネットワークサーバとピアとの両方で使用される。ＣＨＡＰペイロードは、以前に確立されたＴＣＰソケットセッションを介して搬送される。ＣＨＡＰを使用する認証に成功した後に、共有されるセッション鍵の合意が続き、このセッション鍵は、ピアとネットワークサーバとの間のセッションをセキュア化することが望まれる場合に、その保護に使用され得る。
【００６７】
相互認証および鍵共有に成功したとき、ステップ２０６で、ＩＢＡＫＥ起動側が、プル要求をネットワークサーバに送信する。ネットワークサーバは、ステップ２０８で、ＩＢＡＫＥ起動側の現在オンラインのフレンドをそのＩＰアドレスと共に有するフルリストを送信するのにＴＣＰソケットを使用する。これを用いて、ＩＢＡＫＥ起動側は、その応答側のＩＰアドレスを知るようになり、ＴＣＰセッション確立を要求するためにこのＩＰアドレスをさらに使用することができる。
【００６８】
（ｉｉ）ＫＭＳとのセキュアセッション確立
ＩＢＡＫＥメッセージを復号するために、起動側および応答側は、キーマネジメントサーバ（ＫＭＳ）からＩＢＥ秘密鍵を入手しなければならない。秘密鍵は、対応する公開アイデンティティを有するピアだけがそれらを入手できるようにするために、セキュアにトランスポートされる。そのようなセキュアＴＬＳセッションは、証明書もしくは事前に共有される秘密またはその組合せを使用して確立され得る。
【００６９】
図３は、ＩＢＡＫＥ起動側およびＩＢＡＫＥ応答側が２つのモバイルセルラユーザ（すなわち、ピア１０２−１および１０２−２）である場合の発明的フレームワークのこの部分を示す。ネットワークサーバ１０６およびＫＭＳ  ３０２は、両方とも、無線アクセスネットワークを介して連絡される。代替案では、これらのサーバへのアクセスは、ＷｉＦｉ／ＷＬＡＮ、ＷｉＭａｘ、ＺｉｇＢｅｅ、Ｂｌｕｅｔｏｏｔｈ（登録商標）、その他などのデバイス上の他の無線インターフェースならびにそのようなデバイスが有線インターフェース（たとえば、イーサネット（登録商標）、ＦｉｒｅＷｉｒｅ、その他）を備えるシナリオで潜在的に有線インターフェースの使用を介して容易にされ得る。
【００７０】
（ｉｉｉ）起動側と応答側との間でのＴＣＰセッション確立
応答側は、クライアントからのＴＣＰ確立要求を待つ（「リスンする」）特定のポート上でＴＣＰサーバプロセス（すなわち、図１Ｂの通信モジュール１１０の一部）を絶えず実行しつつある。起動側は、ＴＣＰクライアントプロセス（すなわち、図１Ｂの通信モジュール１１０の一部）を実行する。開始時に、このプロセスは、ＴＣＰサーバのＩＰアドレスおよびポートを入力としてとり（実際には、ポートは、固定される場合があり、したがって、クライアントに先験的に知られている場合がある）、さらに、応答側とのＴＣＰソケット確立を要求する。応答側（ＴＣＰサーバ）は、その要求を受け入れる。受入時に、ＴＣＰサーバは、新しいソケット記述子を初期化し、このソケット記述子は、起動側と応答側との間の後続のデータ交換にさらに使用される。この点で、起動側と応答側との間のＴＣＰセッションは、確立済みであり、したがって、起動側は、ＴＣＰを介する第１  ＩＢＡＫＥメッセージの送信に進むことができる。
【００７１】
（ｉｖ）ＩＢＡＫＥ  ３ウェイハンドシェーク
上で参照された米国特許出願第１２／３７２２４２号で説明されるように、ＩＢＡＫＥメッセージは、相互認証およびセッション鍵共有を可能にする、楕円曲線上の「ランダム鍵コンポーネント」を交換することを意図されたものである。第１のメッセージ（ＩＢＡＫＥメッセージ１または第１  ＩＢＡＫＥメッセージ）では、起動側は、応答側の公開鍵を使用して暗号化されたランダム鍵コンポーネントを応答側に送信する。応答側は、秘密鍵を使用してこのメッセージを復号し（そして、秘密鍵を有する応答側だけが復号できることに気づかれたい）、新しいランダム鍵コンポーネントを選択し、受信された鍵コンポーネントおよび新しい鍵コンポーネントを起動側に送り返す。この第２のメッセージ（ＩＢＡＫＥメッセージ２または第２  ＩＢＡＫＥメッセージ）は、起動側の公開鍵を使用して、応答側によって暗号化される。起動側は、このメッセージを復号し、応答側を認証し、セッション鍵を計算することができる。第３のメッセージＩＢＡＫＥメッセージ３または第３  ＩＢＡＫＥメッセージ）は、第２のメッセージで送信された応答側の鍵コンポーネントの暗号化であり、応答側が起動側を認証するためのものであることを意図されたものである。この形で、起動側と応答側との両方が、お互いを相互に認証し、セッション鍵を計算する。
【００７２】
たとえば、Ａ、Ｂが、認証し、鍵に合意することを試みつつある２つのエンティティ（または、Ａが第１当事者のコンピューティングデバイスを表し、Ｂが第２当事者のコンピューティングデバイスを表す場合に、当事者）であると想定する。より具体的には、ＡおよびＢは、定義により彼らの公開鍵をも表す、通信を望む２つのコンピューティングデバイスの対応するアイデンティティを表すと仮定する。
【００７３】
Ｈ１（Ａ）＝ＱＡおよびＨ１（Ｂ）＝ＱＢが、公開鍵に対応する楕円曲線上のそれぞれの点であるものとする。実際に、アイデンティティとＨ１を適用することによって入手される曲線上の点との間に１対１対応があるので、ＱＡおよびＱＢを公開鍵と呼ぶこともできる。
【００７４】
ｘが、Ａによって選択された乱数であるものとし、ｙが、Ｂによって選択された乱数であるものとする。
【００７５】
Ａは、ｘＰ（すなわち、Ｅ上の加算法を使用して、Ｅ上の点としてＰ自体にｘ回加算されたＰ）を計算し、Ｂの公開鍵を使用してこれを暗号化し、これをＢに送信する。このステップでは、暗号化は、その開示は引用によりその全体が本明細書に組み込まれている、Ｄ．Ｂｏｎｅｈ他、「Ｉｄｅｎｔｉｔｙ−Ｂａｓｅｄ  Ｅｎｃｒｙｐｔｉｏｎ  ｆｒｏｍ  ｔｈｅ  Ｗｅｉｌ  Ｐａｉｒｉｎｇ」、Ａｄｖａｎｃｅｓ  ｉｎ  Ｃｒｙｐｔｏｌｏｇｙ−Ｐｒｏｃｅｅｄｉｎｇｓ  ｏｆ  ＣＲＹＰＴＯ  ２００１（２００１年）で説明されるアイデンティティベースの暗号化ＩＢＥを指す。Ｐが、大きい素数位数の点であることに留意されたい。
【００７６】
暗号化されたメッセージの受信時に、Ｂは、メッセージを復号し、ｘＰを入手する。その後、Ｂは、ｙＰを計算し、Ａの公開鍵を使用して対｛ｘＰ，ｙＰ｝を暗号化し、その後、これをＡに送信する。
【００７７】
このメッセージの受信時に、Ａは、メッセージを復号し、ｙＰを入手する。その後、Ａは、Ｂの公開鍵を使用してｙＰを暗号化し、これをＢに送り返す。
【００７８】
これに続いて、ＡとＢとの両方が、セッション鍵としてｘｙＰを計算する。
【００７９】
Ａがｘをランダムに選択し、プロトコル交換の第２ステップでｙＰを受信したことに気づかれたい。これは、Ａが、ｙＰをそれ自体にｘ回加算することによってｘｙＰを計算することを可能にする。逆に、Ｂは、ｙをランダムに選択し、プロトコル交換の第１ステップでｘＰを受信した。これは、Ｂが、ｘＰをそれ自体にｙ回加算することによってｘｙＰを計算することを可能にする。ｘはランダムであるが、ｘＰが、ｘに関する情報を提供しないことにも留意されたい。したがって、ｘＰは、Ａによって選択されたランダムな秘密に基づく鍵のコンポーネントである。同様に、ｙはランダムであるが、ｙＰは、ｙに関する情報を提供しない。したがって、ｙＰは、Ｂのみに知られているランダムな秘密に基づく鍵のコンポーネントである。有利なことに、ｘｙＰは、セッション鍵として働くことができる。
【００８０】
ＩＢＡＫＥプロトコルのこの全般的な理解と共に、図４は、起動側（たとえば、図１Ａの１０２−１）と応答側（たとえば、図１Ａの１０２−２）との間のＩＢＡＫＥ交換を示す。ＴＣＰソケットが、交換４０２で起動側と応答側との間で確立されていると仮定される。したがって、ピア１０２−１（起動側）の通信モジュール１１０−１は、ＴＣＰクライアントとして動作し、ピア１０２−２（応答側）の通信モジュール１１０−２は、ＴＣＰサーバとして動作する。また、図示されているように、ピア１０２−１は、暗号モジュール１１２−１を有し、ピア１０２−２は、暗号モジュール１１２−２を有する。
【００８１】
ステップ４０４では、通信モジュール１１０−１が、第１  ＩＢＡＫＥメッセージ（メッセージ１）の内容を要求する。
【００８２】
ステップ４０６では、暗号モジュール１１２−１が、第１  ＩＢＡＫＥメッセージの内容を導出し、ＩＢＥ暗号化を使用して内容を暗号化する。
【００８３】
ステップ４０８では、暗号モジュール１１２−１が、暗号化された内容を通信モジュール１１０−１に送信する。一実施形態では、通信モジュール１１０−１は、暗号モジュール１１２−１からファイル（またはファイルのセット）の形で第１  ＩＢＡＫＥメッセージの内容を入手する。ファイル内容は、通信モジュール１１０−１によって読み取られ、ステップ４１０で、ＴＣＰソケットに書き込まれ、このＴＣＰソケットが、ＩＢＡＫＥメッセージ１を構成する。このステップについて、ＴＣＰセッション確立フェーズ（４０２）中にインスタンス化された対応するソケット記述子が、参照として使用される。内容の全体的なサイズならびにコードのモジュール性およびスケーラビリティに関する設計プリファレンスに依存して、複数のＴＣＰソケット書込動作は、ＴＣＰサーバ（応答側）がしかるべく実施される限り（すなわち、各ＩＢＡＫＥメッセージの内容を受信するために、何個の対応する読取動作が実行される必要があるのかを知っている限り）、シーケンシャルな形で実行され得る。
【００８４】
第１  ＩＢＡＫＥメッセージの受信時に、応答側１０２−２の通信モジュール１１０−２（ＴＣＰサーバ）は、ステップ４１２で、さらなる処理のためにメッセージ内容をその暗号モジュール１１２−２に配送する。
【００８５】
ステップ４１４では、暗号モジュール１１２−２が、第１  ＩＢＡＫＥメッセージを復号し、第２  ＩＢＲＡＫＥメッセージの内容を生成し、ＩＢＥ暗号化する（やはり、１つまたは複数のファイルの形で）。この内容は、ステップ４１６で通信モジュール１１０−２に供給される。
【００８６】
通信モジュール１１０−２（ＴＣＰサーバ）は、クライアントによるＴＣＰセッション確立要求の受入時に開始されたソケット記述子を使用して、ステップ４１８（ＩＢＡＫＥメッセージ２として図示）で、ＴＣＰソケットにファイル内容を書き込む。
【００８７】
同様に、起動側（クライアント側）では、メッセージ２の内容が、通信モジュール１１０−１（ＴＣＰクライアント）によって受信され、ステップ４２２でのＩＢＥ復号およびさらなる処理のために、ステップ４２０で起動側の暗号モジュール１１２−１に配送される。すなわち、ステップ４２２では、暗号モジュール１１２−１が、第２  ＩＢＡＫＥメッセージを復号し、第３  ＩＢＡＫＥメッセージの内容を導出し、ＩＢＥ暗号化する。暗号モジュール１１２−１は、ＩＢＡＫＥセッション鍵をも計算する。
【００８８】
ステップ４２４では、暗号モジュール１１２−１が、通信モジュール１１０−１に第３  ＩＢＡＫＥメッセージ内容を提供し、通信モジュール１１０−１は、ステップ４２６で第３  ＩＢＡＫＥメッセージを応答側の通信モジュール１１０−２に送信する。
【００８９】
ステップ４２８では、通信モジュール１１０−２が、メッセージをその暗号モジュール１１２−２に配送する。暗号モジュール１１２−２は、メッセージを復号し、ステップ４３０で、起動側が生成した（ステップ４２２で）ものと同一のＩＢＡＫＥセッション鍵を生成する。
【００９０】
したがって、このメッセージ交換の終りに、起動側および応答側は、同一のＩＢＡＫＥセッション鍵を計算済みであり、このＩＢＡＫＥセッション鍵を、後続通信（たとえば、音声呼またはビデオ呼など）をセキュア化するために１つまたは複数のサードパーティアプリケーションにさらに配送する。
【００９１】
図４のプロトコルでは、ピアの通信モジュールからその暗号モジュールに送られる内容の要求は、システムコールの形で実現され得る。たとえば、第１  ＩＢＡＫＥメッセージの内容を入手するために、ＴＣＰクライアントは、システムコールを実行し、これによって暗号モジュールスクリプトを呼び出すことができ、この暗号モジュールスクリプトは、ＲＡＮＤ値を生成し、ＲＡＮＤ＊Ｐ値を計算し、最後に、応答側の公開鍵を用いて、起動側の識別子および応答側の識別子と一緒にこの値をＩＢＥ暗号化する。
【００９２】
ＲＡＮＤが、ｘ（上の一般的なＩＢＡＫＥの例では当事者Ａに関する）またはｙ（上の一般的なＩＢＡＫＥの例では当事者Ｂに関する）と同一の目的のために働くランダム値であることに留意されたい。すなわち、起動側は、ＲＡＮＤｉｎｉｔｉａｔｏｒをランダムに選択し、応答側は、ＲＡＮＤｒｅｓｐｏｎｄｅｒをランダムに選択する。
【００９３】
図４では、ローカル暗号モジュールとのＴＣＰクライアント／サーバの通信が、好ましくは内部的であり、さまざまな形で、たとえば、内部ソケットを介するプロセス間通信を介して、またはそれぞれＴＣＰクライアントおよびＴＣＰサーバ内から対応するローカル暗号モジュールを呼び出すことによって（システムコールを介してまたはローカル暗号モジュールをクライアント／サーバコードにリンクし、適当なライブラリを参照することによって）実現され得ることにも留意されたい。
【００９４】
好ましい実施形態では、本発明者らは、システムコール手法を選択し、この手法では、ＩＢＡＫＥメッセージの受信時に、メッセージの内容が、抽出され、１つまたは複数のファイルに書き込まれ、その後、暗号モジュールが、システムコールを介して呼び出される。これは、ＴＣＰクライアントコードおよびＴＣＰサーバコードが、完全に独立であり、ＩＢＡＫＥの暗号動作にリンクされないという点で、有利である。これを用いると、ＩＢＡＫＥコードは、他のネットワーキングソリューションと共に直接に再利用され得る、すなわち、ＩＢＡＫＥコードは、特定のクライアント−サーバソケット実施態様に束縛されない。
【００９５】
しかし、ＴＣＰソケットコード（または、起動側と応答側との間の通信を実現する任意のコード）を暗号コードと相関させることの選択は、そのような設計が任意の開発スタイルに対処することができるので、図４に示された包括的な実施態様に直接には関係しないことを理解されたい。
【００９６】
ｂ．暗号モジュール１１２
暗号モジュール１１２は、ＩＢＡＫＥに関する暗号動作すなわち：（ａ）ＩＢＥ暗号化およびＩＢＥ復号、（ｂ）ＲＡＮＤ＊Ｐの計算（ＲＡＮＤは、起動側および応答側によって独立に選択される乱数であり、Ｐは、選択された楕円曲線上の知られている点である）、（ｃ）起動側および応答側が、お互いの真正性を検査する、相互認証、ならびに（ｄ）ＩＢＡＫＥセッション鍵（すなわち、点ＲＡＮＤＩｎｉｔｉａｔｏｒ＊ＲＡＮＤＲｅｓｐｏｎｄｅｒ＊Ｐおよび対応する対称鍵）の計算を実行する責任を負う。
【００９７】
相互認証は、ＲＡＮＤ＊Ｐの送信された値と受信された値とを単純に比較することによって行われるが、上記動作の残りは、楕円曲線暗号（ＥＣＣ）動作である。ＲＡＮＤ＊Ｐ値を計算するために、ＮＩＳＴ（米国国立標準技術研究所）は、あるタイプの楕円曲線（コブリッツ曲線など）を承認した。通常、１６３ビットコブリッツ曲線（ＮＩＳＴによって承認された）が、そのような目的に好ましい。今まで、ＮＩＳＴは、ＩＢＥ動作についてどのタイプの曲線も提案していないが、通常、７６８ビットまたは１０２４ビットの非超特異曲線が好ましい。さまざまな異なるＥＣＣライブラリが、過去に開発され、公に入手可能である（たとえば、ペアリング暗号（Ｐａｉｒｉｎｇ  Ｂａｓｅｄ  Ｃｒｙｐｔｏｇｒａｐｈｙ、ＰＢＣ）ライブラリ、およびＭｕｌｔｉｐｒｅｃｉｓｉｏｎ  Ｉｎｔｅｇｅｒ  ａｎｄ  Ｒａｔｉｏｎａｌ  Ａｒｉｔｈｍｅｔｉｃ  Ｃ／Ｃ＋＋  Ｌｉｂｒａｒｙ）。
【００９８】
次では、本発明者らは、起動側および応答側の暗号モジュールの実施形態を説明する。本発明者らは、まず、起動側の暗号モジュール動作を説明し、その後、応答側の暗号モジュール動作を説明する。
【００９９】
（ｉ）起動側の暗号モジュール動作
暗号モジュール１１２−１は、起動側のモバイルデバイス（たとえば、ピア１０２−１）内に常駐する。図５は、第１  ＩＢＡＫＥメッセージを準備する際に暗号モジュールによって実行されるタスクを示す。
【０１００】
暗号モジュール１１２−１は、使用中のＩＢＥ公開鍵と一致するＩＢＥ秘密鍵を入手する。起動側が、ＫＭＳから鍵のリストを入手する場合に、暗号モジュールは、このリストを解析し、適当な秘密鍵を抽出する。さらに、暗号モジュールは、起動側と応答側との両方の完全なパブリックアイデンティティを識別する。
【０１０１】
暗号モジュール１１２−１は、選択されたコブリッツ楕円曲線の座標に関して、サブモジュール５０２内で乱数ＲＡＮＤＩｎｉｔｉａｔｏｒを計算することと、サブモジュール５０４内でＲＡＮＤＩｎｉｔｉａｔｏｒ＊Ｐの値をさらに計算することとによって、ＩＢＡＫＥ内容をも生成する。サブモジュールは、システムコールを介して通信することができる。
【０１０２】
また、暗号モジュール１１２−１は、サブモジュール５０６内で、起動側および応答側の公開鍵と一緒にＲＡＮＤＩｎｉｔｉａｔｏｒ＊ＰをＩＢＥ暗号化し、暗号化された内容をファイルに書き込む。同様に、ここで、ＩＢＥ暗号化サブモジュール５０６は、システムコールを介して到達（通信）される。暗号化される内容は、ファイルの形で提供される。暗号化されたデータは、ファイルに格納され、このファイルが、ＴＣＰクライアント（通信モジュール１１０−１）に供給される。
【０１０３】
代替の実施手法は、図６に示されているように、ＴＣＰクライアントから暗号モジュールの各サブモジュールへの直接のシステムコールの適用を用いることができる。そのような手法の利点は、ＴＣＰクライアントが、各サブモジュールの入力および出力を制御していることである。または、両方の方法（図５および６の）を用いるハイブリッド実施手法も実現可能である。
【０１０４】
ＴＣＰクライアントが、ＴＣＰサーバから第２  ＩＢＡＫＥメッセージを受信するや否や、ＴＣＰクライアントは、そのメッセージ内容を起動側の暗号モジュール１１２−１に配送する。第２  ＩＢＡＫＥメッセージ受信時の暗号化モジュールの動作を、図７に示す。
【０１０５】
図示されているように、暗号モジュール１１２−１は、起動側のＩＢＥ秘密鍵と一緒にメッセージ２の暗号化された内容を供給して、ＩＢＥ復号サブモジュール７０２ヘのシステムコールを実行する。ＩＢＥ復号サブモジュール７０２は、入力データを復号するのに秘密鍵を使用し、さらに、復号された内容をファイルに格納する。したがって、ファイルは、復号されたＲＡＮＤＲｅｓｐｏｎｄｅｒ＊Ｐ値ならびに起動側および応答側の復号されたパブリックアイデンティティを含む。
【０１０６】
第２  ＩＢＡＫＥメッセージに含まれた復号されたデータは、起動側が、ＲＡＮＤＩｎｉｔｉａｔｏｒ＊Ｐの最初に計算された値と第２メッセージ内で返された値とを比較することによって応答側の識別子を検証することを可能にする。この認証は、サブモジュール７０４によって実行される。
【０１０７】
サブモジュール７０６では、ＲＡＮＤＲｅｓｐｏｎｄｅｒ＊Ｐの値が、第２  ＩＢＡＫＥメッセージから抽出され、第３  ＩＢＡＫＥメッセージの内容が、生成される。この内容が、サブモジュール７０８でＩＢＥ暗号化され、サブモジュール７０８は、内容をＴＣＰクライアントに送信する。
【０１０８】
この点で、サブモジュール７１０を介して、暗号化モジュールは、ＩＢＡＫＥセッション鍵すなわち、選択されたコブリッツ曲線上の点ＲＡＮＤＩｎｉｔｉａｔｏｒ＊ＲＡＮＤＲｅｓｐｏｎｄｅｒ＊Ｐに対応する鍵を計算するために、ＲＡＮＤＩｎｉｔｉａｔｏｒ＊ＰおよびＲＡＮＤＲｅｓｐｏｎｄｅｒ＊Ｐの値を使用する。この計算は、上で説明された同様のシステムコールを介して開始される、ＲＡＮＤＩｎｉｔｉａｔｏｒ＊Ｐの計算を実行したものと同一のサブモジュールによって実行され得る。
【０１０９】
ＩＢＡＫＥセッション鍵（またはこれの派生物）は、さらに、マルチメディアアプリケーション７１２に供給され、マルチメディアアプリケーション７１２は、エンドツーエンドの形でマルチメディアコンテンツを暗号化し、かつ／または完全性保護するのにこれを使用することができる。鍵は、ファイルの形で配送される。モバイルデバイス内でのすべての鍵材料の保護は、この説明の範囲を超えるが、認可されないアプリケーションによって入手されることから鍵を保護するために、モバイルオペレーティングシステムの前提の中で注意を払わなければならない。ここで、起動側の識別子検証の結果に関する応答側からの肯定の肯定応答の受信まで、鍵の配送が遅延され得ることに留意されたい。
【０１１０】
（ｉｉ）応答側の暗号モジュール動作
応答側の暗号モジュール１１２−２は、第１  ＩＢＡＫＥメッセージおよび第３  ＩＢＡＫＥメッセージの受信時に、ＥＣＣ演算の同一のセットを実行する。より具体的には、第１  ＩＢＡＫＥメッセージの受信時に、このモジュールは、図８に示された動作を実行する。
【０１１１】
暗号モジュール１１２−２は、その現在有効なＩＢＥ公開鍵と一致する１つのＩＢＥ秘密鍵を入手する。応答側が、ＫＭＳから鍵のリストを入手する場合に、暗号モジュールは、このリストを解析し、適当な秘密鍵を抽出する。さらに、暗号モジュールは、起動側と応答側との両方の完全なパブリックアイデンティティを識別する。
【０１１２】
図８に示されているように、暗号モジュール１１２−２は、応答側のＩＢＥ秘密鍵と一緒にメッセージ１の暗号化された内容を供給して、ＩＢＥ復号サブモジュール８０２へのシステムコールを実行する。ＩＢＥ復号サブモジュール８０２は、入力データを復号するのに秘密鍵を使用し、さらに、復号された内容をファイルに格納する。したがって、ファイルは、復号されたＲＡＮＤＩｎｉｔｉａｔｏｒ＊Ｐ値ならびに起動側および応答側の復号されたパブリック識別子を含む。
【０１１３】
ＩＢＡＫＥメッセージ１に関する起動側に似て、応答側の暗号モジュール１１２−２は、サブモジュール８０４で、乱数（ＲＡＮＤＲｅｓｐｏｎｄｅｒ）を生成し、さらに、選択されたコブリッツ楕円曲線上の座標に関してＲＡＮＤＲｅｓｐｏｎｄｅｒ＊Ｐの値を計算する。サブモジュールは、システムコールを介して通信することができる。
【０１１４】
暗号モジュール１１２−２は、サブモジュール８０６を介して、起動側および応答側の公開鍵と一緒にＲＡＮＤＲｅｓｐｏｎｄｅｒ＊ＰをＩＢＥ暗号化し、暗号化された内容をファイルに書き込む。同様に、ＩＢＥ暗号化サブモジュール８０６は、システムコールを介して到達される。暗号化される内容は、ファイルの形で提供される。暗号化されたデータは、ファイルに格納され、このファイルが、ＴＣＰサーバ（通信モジュール１１０−２）に供給される。ＴＣＰサーバは、さらに、応答としてＩＢＡＫＥメッセージ２をＴＣＰクライアント（通信モジュール１１０−１）に送信する。
【０１１５】
応答側がＩＢＡＫＥメッセージ３を受信するや否や、応答側は、メッセージ内容を復号し、さらに、起動側の識別子を検証する。より具体的には、第３  ＩＢＡＫＥメッセージの受信時に、図９に示されているように、次のタスクが、応答側の暗号モジュール１１２−２によって実行される。
【０１１６】
ＴＣＰサーバは、ＩＢＡＫＥメッセージ３の暗号化された内容を供給して、ＩＢＥ復号サブモジュール９０２へのシステムコールを実行する。ＩＢＥ復号サブモジュール９０２は、入力データを復号するのに応答側のＩＢＥ秘密鍵を使用し、さらに、復号された内容をファイルに格納する。
【０１１７】
第３  ＩＢＡＫＥメッセージ内に含まれた復号されたデータは、応答側が、ＲＡＮＤＲｅｓｐｏｎｄｅｒ＊Ｐの最初に計算された値と第３  ＩＢＡＫＥメッセージ内で返された値とを比較することによって、起動側の識別子を検証することを可能にする。これは、サブモジュール９０４で行われる。
【０１１８】
この点で、サブモジュール９０６は、ＩＢＡＫＥセッション鍵すなわち選択されたコブリッツ曲線上の点ＲＡＮＤＩｎｉｔｉａｔｏｒ＊ＲＡＮＤＲｅｓｐｏｎｄｅｒ＊Ｐに対応する鍵を計算するために、ＲＡＮＤＩｎｉｔｉａｔｏｒ＊ＰおよびＲＡＮＤＲｅｓｐｏｎｄｅｒ＊Ｐの値を使用する。この計算は、上で説明したように同様のシステムコールを介して開始される、ＲＡＮＤＩｎｉｔｉａｔｏｒ＊Ｐの計算を実行したものと同一のサブモジュールによって実行され得る。
【０１１９】
ＩＢＡＫＥセッション鍵（またはこれの派生物）は、マルチメディアアプリケーション９０８に供給され、マルチメディアアプリケーション９０８は、エンドツーエンドの形でマルチメディアコンテンツを暗号化し、かつ／または完全性保護するのにこれを使用することができる。
【０１２０】
最後に、図１０は、本発明の上で説明された原理による、ネットワーク支援型ｐ２ｐセキュア通信を実施するのに適する通信システム１０００の一部の一般化されたハードウェアアーキテクチャを示す。
【０１２１】
図示されているように、コンピューティングデバイス（ピア）１０１０（ピア１０２−１に対応する）、コンピューティングデバイス１０２０（ピア１０２−２に対応する）、およびネットワークサーバ１０３０（ネットワークサーバ１０６に対応する）は、通信媒体１０４０を介して動作可能に結合される。ネットワーク媒体は、ピアおよびネットワークサーバがそれにまたがって通信するように構成される任意のネットワーク媒体とすることができる。たとえば、ネットワーク媒体は、ＩＰパケットを搬送することができ、上で言及された通信媒体のいずれをも含むことができる。しかし、本発明は、特定のタイプのネットワーク媒体に限定されない。
【０１２２】
当業者に直ちに明らかになるように、要素は、コンピュータプログラムコードの制御下で動作するプログラムされたコンピュータとして実施され得る。コンピュータプログラムコードは、コンピュータ（またはプロセッサ）可読記憶媒体（たとえば、メモリ）に格納され、コードは、コンピュータのプロセッサによって実行される。本発明の本開示を与えられれば、当業者は、本明細書で説明されたプロトコルを実施するために、適当なコンピュータプログラムコードを直ちに作ることができるはずである。
【０１２３】
それでも、図１０は、通信媒体を介して通信する各デバイスの例示的なアーキテクチャを全般的に示す。図示されているように、ピア１０１０は、入出力デバイス１０１２、プロセッサ１０１４、およびメモリ１０１６を含む。ピア１０２０は、入出力デバイス１０２２、プロセッサ１０２４、およびメモリ１０２６を含む。ネットワークサーバ１０３０は、入出力デバイス１０３２、プロセッサ１０３４、およびメモリ１０３６を含む。
【０１２４】
本明細書で使用される時に、用語「プロセッサ」は、中央処理装置（ＣＰＵ）を含む１つもしくは複数の処理デバイスまたは１つもしくは複数の信号プロセッサ、１つもしくは複数の集積回路、および類似物を含むがこれに限定されない他の処理回路網を含むことが意図されている。また、本明細書で使用される時に、用語「メモリ」は、ＲＡＭ、ＲＯＭ、固定メモリデバイス（たとえば、ハードドライブ）、またはリムーバブルメモリデバイス（たとえば、ディスケットまたはＣＤＲＯＭ）など、プロセッサまたはＣＰＵに関連するメモリを含むことが意図されている。さらに、本明細書で使用される時に、用語「入出力デバイス」は、処理ユニットにデータを入力する１つまたは複数の入力デバイス（たとえば、キーボード、マウス）ならびに処理ユニットに関連する結果を提供する１つまたは複数の出力デバイス（たとえば、ＣＲＴディスプレイ）を含むことが意図されている。
【０１２５】
したがって、本明細書で説明された、本発明の方法論を実行するソフトウェア命令またはコードは、関連するメモリデバイス、たとえばＲＯＭ、固定メモリ、またはリムーバブルメモリのうちの１つまたは複数に格納され、利用される準備ができた時に、ＲＡＭにロードされ、ＣＰＵによって実行され得る。そのようなメモリデバイスは、それぞれ、コンピュータ可読記憶媒体または固定記憶媒体と考えられ得る。図１０に示された各デバイス（１０１０、１０２０、および１０３０）は、図１から９に示されたプロトコルおよび機能のそれぞれのステップを実行するように個別にプログラムされ得る。また、ブロック１０１０、ブロック１０２０、およびブロック１０３０のそれぞれが、それぞれ複数の別個のノードまたはコンピューティングデバイスを介して実施され得ることを理解されたい。
【０１２６】
本発明の例示的実施形態が、本明細書で添付図面を参照して説明されたが、本発明がこれらの正確な実施形態に限定されないことと、本発明の範囲および趣旨から逸脱せずに、さまざまな他の変更および修正が、当業者によって行われ得ることとを理解されたい。
【図１Ａ】
2015503261.tif 000003
【図１Ｂ】
2015503261.tif 000004
【図２】
2015503261.tif 000005
【図３】
2015503261.tif 000006
【図４】
2015503261.tif 000007
【図５】
2015503261.tif 000008
【図６】
2015503261.tif 000009
【図７】
2015503261.tif 000010
【図８】
2015503261.tif 000011
【図９】
2015503261.tif 000012
【図１０】
2015503261.tif 000013
【国際調査報告】
2015503261.tif 000014
2015503261.tif 000015