JP2016518075A - ピアツーピア通信およびグループ通信のセキュリティ保護 - Google Patents

Abstract

近傍サービスのセキュリティを拡張するセキュリティアソシエーションを活用するシステム、方法および装置の実施形態が開示される。既存のセキュリティアソシエーションは、近傍サービスによって使用されるセキュリティアソシエーションを生成するために活用される。例えば、既存の鍵は、ピアツーピア通信をセキュリティ保護するために使用され得る新しい鍵を導出するために活用されうる。

Description

関連出願の相互参照
本出願は、2013年4月5日に出願された米国特許仮出願第61/809,067号明細書、および2013年11月1日に出願された米国特許仮出願第61/898,763号明細書の優先権を主張するものであり、それらの開示はこれにより、その全体において明記されるかのように参照により本明細書に組み込まれる。

いくつかの事例でピアツーピア（Ｐ２Ｐ）通信ともまた呼ばれ得るデバイスツーデバイス（Ｄ２Ｄ）通信は、直接パスまたはローカルパスを介して実行され得る。２つのデバイス間の直接パスＤ２Ｄ通信において、物理的な通信は、２つのデバイス間で直接であり、その結果、２つのデバイス間に仲介物は存在しない。２つの例示的なデバイス間のローカルパスＤ２Ｄ通信において、通信は、例えば、両方のデバイスが接続されたｅＮｏｄｅＢ（ｅＮＢ）などのノードを通されることがある。Ｄ２Ｄ通信は、例えば、３ＧＰＰの近傍サービス（ＰｒｏＳｅ）を実装するために利用されうる。近傍サービスは、一般に、デバイスが互いの物理的近傍内にあるときに呼び出され得るサービス、アプリケーション、通信などを指す。例示的な近傍サービスは、パブリックセーフティアプリケーション、ソーシャルアプリケーションなどを含む。近傍サービスはまた、互いに物理的に接近していない２つのデバイスによって使用されうる。例えば、互いに物理的近傍にない２つのデバイスが、２つのデバイス間の中継ノードの役割を果たす他のデバイスとのＤ２Ｄ通信を使用することによって、近傍サービスを使用することができる。近傍サービスはまた、限定はせずに、近傍ベースのサービスとも呼ばれてよい。

近傍サービスの異なる実装形態は、通信システムに異なる要件を課す。近傍サービスを実装することへの既存のアプローチは、例えば、近傍サービス通信の完全性および機密性などのセキュリティを欠く。さらに、Ｐ２Ｐ通信およびグループ通信の間の近傍サービスの発見の間に、プライバシーが欠けていることがある。

本明細書で説明される様々な例示的な実施形態において、近傍サービス（ＰｒｏＳｅ）のセキュリティが有効にされる。例示的な実施形態において、ネットワークレイヤでの既存のセキュリティアソシエーションが活用されて、ＰｒｏＳｅネットワークレベルセキュリティアソシエーションを生成する。別の例示的な実施形態に従って、アプリケーションレイヤでの既存のセキュリティアソシエーションが活用されて、ＰｒｏＳｅネットワークレイヤアソシエーションを生成する。同様に、アプリケーションレイヤでの既存のセキュリティアソシエーションが活用されて、ＰｒｏＳｅアプリケーションレイヤアソシエーションを生成することができる。さらに別の例示的な実施形態において、ネットワークレイヤでのセキュリティアソシエーションが活用されて、ＰｒｏＳｅアプリケーションレイヤアソシエーションを生成する。

一実施形態において、１または複数のユーザ機器（ＵＥ）、例えば、第１のＵＥおよび第２のＵＥが、各々、ネットワークエンティティとの予め確立されたセキュリティアソシエーションを有する。例えば、ネットワークエンティティは、ｅＮｏｄｅＢ（ｅＮＢ）またはモバイル管理エンティティ（ＭＭＥ）であってよい。近傍サービスセキュリティ機能（ＰＳＳＦ）が、第１のＵＥとネットワークエンティティとの間で予め確立されたセキュリティアソシエーションに関連付けられた第１の鍵を取得することができ、ＰＳＳＦは、第２のＵＥとネットワークエンティティとの間で予め確立されたセキュリティアソシエーションに関連付けられた第２の鍵を取得することができる。例に従って、ＰＳＳＦは、第１のＵＥおよび第２のＵＥが近傍通信に関与したいと所望することを示す通知を受信する。第１の鍵および第２の鍵に基づいて、ＰＳＳＦは、第１のＵＥおよび第２のＵＥによってそれぞれ使用され得る第１および第２の中間鍵を導出して、第１のＵＥと第２のＵＥとの間の近傍通信をセキュリティ保護するための共通共有鍵を導出することができる。

より詳細な理解は、添付図面と併せて例として与えられる以下の説明から得られうる。
例示的な近傍サービス無線レベルアーキテクチャのシステム図である。 例示的な実施形態による、近傍サービス通信のセキュリティ保護に従事するエンティティのブロック図である。 グループ通信実装形態の図である。 例示的なセキュリティ機能のブロック図である。 例示的なセキュリティタイプのブロック図である。 例示的な実施形態による、例示的な近傍サービスアクセス層（ＡＳ）（ＰｒＡＳ）アーキテクチャのブロック図である。 近傍サービスセキュリティ機能（ＰＳＳＦ）がｅＮＢ上で実装される例示的な実施形態による、鍵生成および配布についての流れ図である。 ＰＳＳＦがモバイル管理エンティティ（ＭＭＥ）上で実装される別の例示的な実施形態による、鍵生成および配布についての流れ図である。 発見の例示的な方法についての流れ図である。 例示的な実施形態による、認証されたアイデンティティベースの暗号化（ＩＢＥ）鍵交換についての流れ図である。 例示的な実施形態による、ネットワークベースのグループ鍵導出についての流れ図である。 メンバーがグループに加わり、別のメンバーがグループを去る例示的な実施形態による、再キーイングについての流れ図である。 例示的な実施形態による、アイデンティティリスト処理についての流れ図である。 例示的な実施形態による、予め共有された鍵に基づいた認証のプロセスについての流れ図である。 例示的な実施形態による、予め共有された鍵および他のパラメータに基づいた認証のプロセスについての流れ図である。 例示的な実施形態による、デジタル署名に基づいた認証のプロセスについての流れ図である。 １または複数の開示された実施形態が実装されてよい例示的な通信システムのシステム図である。 図１２Ａに示された通信システム内で使用されうる例示的な無線送受信ユニット（ＷＴＲＵ）のシステム図である。 図１２Ａに示された通信システム内で使用されうる例示的な無線アクセスネットワークおよび例示的なコアネットワークのシステム図である。

以下の詳細な説明は、例示的な実施形態を示すために提供され、本発明の範囲、適用可能性、または構成を限定するようには意図されていない。本発明の趣旨および範囲から逸脱せずに、要素およびステップの機能および配置において様々な変更がなされてよい。

上述されたように、現在の技法は、通信が機密で信頼に値するように、近傍サービス通信をセキュリティ保護するには不足している。本明細書で説明される様々な実施形態は、セキュアなＤ２Ｄ通信を可能にする。さらに、本明細書で説明される様々な実施形態は、近傍サービスを使用する様々な例示的なシナリオ（使用事例）において実装されてよい。近傍サービスのソーシャルアプリケーションの例において、Ｄ２Ｄユーザは、ユーザグループ（例えば、友達リスト）に属する他のＤ２Ｄユーザを発見し、他のＤ２Ｄユーザによって発見されることが可能である。発見されたユーザは、Ｄ２Ｄリンク上で、ソーシャルネットワークアプリケーションを介して通信することができる。発見は、ユーザ機器（ＵＥ）のロケーション情報なしに実施されうる。近傍サービスの別の例示的なソーシャルアプリケーションにおいて、Ｄ２Ｄユーザは、発見されるための事前の許可を与えることなく、別のＤ２Ｄユーザによってパブリックに発見されうる。あるいは、制限された発見モードにおいて、認可されたＤ２Ｄユーザのみが、対象の他のＤ２Ｄユーザを発見することが可能であってよい。さらに別の例示的なシナリオにおいて、異なるパブリックランドモバイルネットワーク（ＰＬＭＮ）に属するＤ２Ｄユーザは、互いを発見することができる。例えば、デバイスが互いを発見するとき、デバイスはローミングしていることがある。様々な例示的な実施形態において、デバイスは、ユーザにとって知覚可能な性能低下なしに、直接パスモードとローカルパスモードとの間で推移することができる。ローカルパスモードは、２つのデバイス間に仲介物を含む、２つのデバイス間の通信を指す。ローカルパスモードはまた、限定はせずに、本明細書でインフラストラクチャモードとも呼ばれてよい。直接パスは、２つのデバイス間に仲介物を含まない、２つのデバイス間の通信リンクを指すことができる。動作は、近傍サービスを使用して、それらのロケーション情報および存在情報をさらによくすることができる。

本明細書で説明される様々な実施形態はまた、近傍サービスを使用する様々な例示的なパブリックセーフティシナリオ（使用事例）において実装されてもよい。近傍サービスの例示的なパブリックセーフティ（ＰＳ）アプリケーションにおいて、２つの認可されたパブリックセーフティ職員（ユーザ）が、Ｄ２Ｄリンク上で直接通信することができる。近傍サービスを使用する別の例示的なパブリックセーフティアプリケーションにおいて、ＰＳ Ｄ２Ｄユーザは、異なるＰＳユーザとの複数の同時１対１Ｄ２Ｄセッションを維持することができる。

図１を参照すると、ＬＴＥ（登録商標） Ｄ２Ｄ直接パス１０１の例示的なプロトコルスタック図が示されている。図１は、ｅＮＢ１０２と、例えば、第１のＵＥ１０４および第２のＵＥ１０６などの複数のＵＥとを含む、例示的な近傍サービスシステム１００を示す。示された例に従って、ＬＴＥ直接パス送信のために、近傍サービスアクセス層（ＰｒＡＳ）１０８として示される１または複数の別個のデータ無線ベアラ１０８が、直接パス１０１上でのユーザプレーンデータの送信のためにセットアップされる。例えば、物理レイヤ（ＰＨＹ）、媒体アクセス制御（ＭＡＣ）レイヤ、無線リンク制御（ＲＬＣ）レイヤおよびパケットデータコンバージェンスプロトコル（ＰＤＣＰ）レイヤなどの１または複数のレイヤの各々でのベアラは、ＵＥ１０４および１０６においてデータ終端されうる。ＵＥ１０４および１０６の各々は、互いに、およびｅＮＢ１０２に、同時に接続されてよい。示された例に従って、制御プレーン、例えば、無線リソース制御１１０は、ＵＥ１０４とｅＮＢ１０２との間で終端される。近傍サービスシステム１００は、１つのｅＮＢ１０２と、２つのＵＥ１０４および１０６とを示しているが、所望に応じて、任意の数のＵＥおよびｅＮＢが近傍サービスシステムの一部であり得ることが理解されるであろう。

近傍サービス（ＰｒｏＳｅ）のための仕様を作成する標準化団体、第３世代パートナーシッププロジェクト（３ＧＰＰ）は、１または複数のＵＥの間の直接通信のためのセキュリティ要件を定義している。本明細書で説明される実施形態は、システムが、これらのセキュリティ要件のうちの少なくともいくつかを満たすことを可能にする。例えば、本明細書で説明される様々な実施形態に従って構築される、ＬＴＥのために設計される例示的なアーキテクチャを指す進化型パケットシステム（ＥＰＳ）は、近傍サービス通信およびＰｒｏＳｅ支援されるＷＬＡＮ直接通信パス上の、データ（例えば、ユーザデータ、ネットワークシグナリングデータ）の機密性および完全性が、既存の３ＧＰＰシステムによって提供されるものに少なくとも匹敵するレベルまで、セキュアであることを保証することができる。ＥＰＳは、シグナリング（例えば、アクセス層（ＡＳ）および非アクセス層（ＮＡＳ））のための機密性および完全性保護を提供するように、３ＧＰＰによって要求されるのみであることが、本明細書で認識される。すなわち、ユーザプレーンデータは、３ＧＰＰの要件に従って、機密性保護されるのみであってよい。

本明細書で説明される実施形態は、ＰｒｏＳｅ発見および通信が使用されるときに、ＥＰＳが、加入者、ＵＥおよびユーザの永続的なアイデンティティの機密性を保護することを可能にする。例示的なＥＰＳは、ＰｒｏＳｅ支援されるＷＬＡＮ直接通信が使用されるときに、加入者、ＵＥおよびユーザの永続的なアイデンティティが保護されることを可能にする機密性特徴をさらに含むことができる。

本明細書で説明されるように、近傍サービスシステムは、オペレータおよびユーザによって認可されたアプリケーションによって使用される近傍サービス発見情報の信憑性を保証することができる。例えば、発見可能であることの許可は、ユーザによって与えられてよく、アプリケーションベースごとにオペレータ制御を条件として、ＥＰＳによって実行されてよい。別の例として、ＥＰＳは、近傍サービス発見情報を、ＰｒｏＳｅが使用可能なＵＥ、並びにユーザおよびオペレータによって認可されているアプリケーションに、制限することができる。本明細書で説明される例示的なシステムは、地域または国家の規制要件（例えば、合法な傍受）をサポートすることができる。

図２を参照すると、示された実施形態に従って、例示的な近傍サービスシステム２００が、近傍サービスセキュリティ機能（ＰＳＳＦ）２０２を含む。近傍サービスシステム２００は、１または複数のＵＥ、例えば、ＰＳＳＦ２０２と通信する、第１のＵＥ２０４および第２のＵＥ２０６を含むことができる。示された実施形態は、近傍サービスシステム２００において２つのＵＥを図示するが、所望に応じて、任意の数のＵＥが近傍サービスシステムに含まれ得ることが理解されるであろう。ＰＳＳＦ２０２は、例えば、限定はせずに、ｅＮＢに、モバイル管理エンティティ（ＭＭＥ）に、近傍サービス（ＰｒｏＳｅ）サーバの一部として、例えばアクセスネットワーク発見および選択機能（ＡＮＤＳＦ）などの、アプリケーションレイヤでのエンティティの中に、ＵＥに、または、スタンドアロンエンティティとして、設置されてよい。本明細書で使用されるとき、ＰｒｏＳｅサーバは、近傍サービスを提供するサーバを指す。例えば、ＰｒｏＳｅサーバは、ピアツーピア（Ｐ２Ｐ）ユーザのペアに、またはユーザのグループに、近傍サービスを提供することができる。例示的な近傍サービスは、限定はせずに、直接通信または間接通信を可能にするための無線ベアラの生成においてＵＥまたはネットワークエンティティを補助すること、データフローを管理すること、ネットワークＩＤに対する、アプリケーションレイヤでのユーザアイデンティティ（ＩＤ）を管理すること、一般的なクライアント／サーバアプリケーションおよびサービスを、Ｐ２Ｐセッションもしくはグループセッションに適応させること、または、サービス品質（ＱｏＳ）およびセキュリティを提供することを含む。セキュリティは、ＰｒｏＳｅサーバの一部として実装されうるＰＳＳＦを用いて実現されうる。例示的な実施形態において、ＰＳＳＦ２０２に対応するエンティティは、ＵＥ２０４および２０６上に設置される。ＰＳＳＦ２０２に対応するエンティティは、ＰＳＳＦ２０２が実施する機能と同様に動作のサブセットを実施することができる。従って、例えば、ＰＳＳＦ２０２に対応するエンティティは、ＰｒｏＳｅクライアントと呼ばれうる。ＰｒｏＳｅクライアントはまた、機能、例えば、ＰＳＳＦ２０２によって実施される全ての機能を模倣することができる、ＰｒｏＳｅプロキシ機能として機能することができる。以下でさらに説明されるように、ＰＳＳＦ２０２が実施することができる能力は、ＰｒｏＳｅセッション鍵生成および配布を含む。さらに、ＰＳＳＦ２０２は、ＰｒｏＳｅセキュリティポリシー決定ポイントとして機能することができる。別の例として、ＰＳＳＦ２０２は、合法な傍受（例えば、鍵供託（key escrow））を補助することができ、プライバシーおよびアイデンティティ（例えば、一時的なアイデンティティ）を管理することができる。別の例として、以下でさらに説明されるように、ＰＳＳＦ２０２はまた、認証局、私有鍵生成機関（ＰＫＧ）、および／またはアイデンティティプロバイダ（ＩｄＰ）として機能することができる。

ある実施形態において、ＰＳＳＦ２０２は、図２に示される例示の実施形態に従って、ネットワーク２０８などのネットワーク上の中央調整エンティティ（central coordinating entity）に常駐する。中央調整エンティティは、例えば、ＰｒｏＳｅサーバ、ＭＭＥまたはｅＮＢなどのネットワークエンティティであってよい。あるいは、中央調整エンティティは、例えば、クラスタヘッド（ＣＨ）としての役割を果たす、ＵＥ２０４および２０６のうちの１つなどのＵＥであってもよい。

図３を参照すると、例示的なクラスタヘッド（ＣＨ）システム３００は、第１のグループ３０２ａおよび第２のグループ３０２ｂなどの１または複数のグループを含むことができる。示されたＣＨシステム３００は２つのグループを含むが、所望に応じて、例えば２つよりも多いまたは少ない任意の数のグループが、ＣＨシステムに含まれ得ることが理解されるであろう。本明細書で使用されるとき、限定はせずに、グループは、クラスタとも呼ばれてよい。グループ３０２ａおよび３０２ｂの各々は、１または複数のＵＥ３０４を含むことができる。さらに、第１および第２のグループ３０２ａ−ｂの各々がＣＨを含むことができる。例えば、示された実施形態に従って、第１のグループ３０２ａは、ＣＨ、例えば第１のＣＨ３０６ａである１つのＵＥ３０４を含み、第２のグループ３０２ｂは、ＣＨ、例えば第２のＣＨ３０６ｂである１つのＵＥ３０４を含む。示された実施形態に従って、第１および第２のクラスタヘッド３０６ａおよび３０６ｂは、同期、スケジューリングおよびセキュリティを提供する。従って、第１および第２のクラスタヘッド３０６ａおよび３０６ｂは、第１および第２のグループ３０２ａおよび３０２ｂの各々内で、それぞれ、信頼できるエンティティと考えられてよい。例示的な実施形態において、別のＣＨ、例えば、第３のＣＨ３０６ｃは、第１のＣＨ３０６ａおよび第２のＣＨ３０６ｂによって信頼されている信頼できるエンティティである。ＵＥ３０４は、それらのそれぞれのＣＨを信頼することができるので、かつ第１および第２のＣＨ３０６ａおよび３０６ｂは、第３のＣＨ３０６ｃを信頼することができるので、ＵＥ３０４は、例えば、推移的信頼に基づいて、第３のＣＨ３０６ｃを信頼することができる。従って、第３のＣＨ３０６ｃは、互いに通信したいと希望する、第１および第２のグループ３０２ａおよび３０２ｂの両方におけるＵＥ３０４に、セキュリティサービスを提供することができる。例えば、クラスタヘッド３０６ａ−ｃのうちの各々は、認証サーバ、ＰＳＳＦ、アイデンティティベースの暗号化（ＩＢＥ）のための私有鍵生成機関（ＰＫＧ）、アイデンティティプロバイダ（ＩｄＰ）、認証局、またはそれらの任意の適切な組合せとしての働きをすることを含む、セキュリティ機能を実施することができる。ＩｄＰとしての働きをするＣＨは、そのグループ内での、またはグループ間での信頼を提供することができる。同様に、認証局としての働きをするＣＨは、そのグループ内（イントラグループＣＡ）での、またはグループ間（インターグループＣＡ）での、証明機関であってよい。アウトオブカバレッジシナリオにおいて、クラスタヘッド３０６ａ−ｂは、それらのそれぞれのグループ３０２ａ−ｂのための調整エンティティであってよいが、ある実施形態において、クラスタヘッド３０６ａ−ｂの１つなどの調整エンティティが、例えば、ネットワークカバレッジを有することができ、一方で、グループ３０２ａ−ｂにおける他のＵＥ３０４は、セルラネットワークまたは別の外部ネットワークへのアクセスを有さない。従って、クラスタヘッド３０６ａ−ｂは、それらがメンバーであるグループ内での通信、それらの独自のグループから分離した外側のグループへの通信、または、例えば、モバイルネットワークオペレータ（ＭＮＯ）によって制御されるネットワークなどの別のネットワークへの通信を促進することができる。

図４を参照すると、示された実施形態に従って、ＰｒｏＳｅセキュリティ機能性の例示的な図示が、機能４００の組合せを含む。機能４００のサブセットは、セキュリティ要件に応じて、任意の時間に実行されうる。さらに、様々な実施形態に従って、機能４００のうちの少なくともいくつかは、より大きな効率のために組み合わされる。機能４００は、プロトコルスタックの異なるレイヤで実行されうる。

なおも図４を参照すると、４０２で、対象のユーザが識別される発見が実施される。ユーザのアイデンティティは、例えば、プライバシーの理由のために保護されて制限されてもよく、または制限されなくてもよい。示された実施形態に従って、４０２での発見の後に、４０４での認証および認可、および４０６でのセキュアなユーザデータ通信チャネルの確立が続く。代替的実装形態においては、４０２での発見の後に４０４での認証および認可が続かない。さらに、ある事例では、４０２での発見が、機能４００から省略されてもよい。例えば、ウォーキートーキーが、発見を実施せずに、認証および認可を実施することができる。４０２で、示された実施形態に従って、発見は、４０２ａでのフィルタリングを含む。発見は、対象であるとみなされるメッセージのみが処理されるように、近傍サービスメッセージまたはビーコン信号メッセージを効率的にフィルタ除去することを含むことができる。例えば、４０３ａで、リプレイされたビーコンメッセージがさらに処理されないように、リプレイされたビーコンメッセージが識別されるように、リプレイメッセージがフィルタリングされる。４０３ｂで、メッセージは、対象のグループによってさらにフィルタリングされる。メッセージが対象の特定のグループ内にない場合、それらはさらには処理されない。例えば、メッセージは、それらが特定のメンバーシップ情報または他の識別データを含むかどうかに応じて、フィルタリングされてよい。ある例において、４０３ｂで実施される、特定のグループに属する対象のメッセージのフィルタリングは、４０３ａでリプレイメッセージのフィルタリングが実施される前に、実施されてよい。この順序でフィルタリングすることは、例えば、リプレイ保護に関係した少なくともなんらかの情報がフレームまたはパケットに深く埋められているときに、有用であることがある。そのような例では、例えば、メッセージパケットのより深い部分が確認される前に、メッセージパケットが、対象の特定のグループに属していないと識別されてよい。従って、メッセージパケットは、リプレイメッセージのフィルタリングが実施される前に破棄されてよく、このことは、リプレイメッセージのためにメッセージの最後の部分が確認されなければならないシナリオと比較して、より効率的である。

引き続き図４を参照すると、メッセージがフィルタリングされた後、示された実施形態に従って、４０２ｂで、個々のユーザおよび／またはＵＥが識別される。ユーザ／ＵＥのアイデンティティは、ＰｒｏＳｅ発見メッセージを送ったユーザ／ＵＥに対応する。４０４で、例えば、メッセージを送ったユーザおよび／またはＵＥが識別された後で、認証および認可が実施されうる。例えば、ユーザまたはＵＥが、彼／彼女／それが主張するものであるということを検証するために、ユーザまたはＵＥは認証されてよい。例えば、制限された発見の間などのいくつかのシナリオにおいて、メッセージを受信するＵＥが、メッセージにおける発見ＰｒｏＳｅ情報またはビーコン情報の復号を可能にする認可コードを取得するように、認可は、発見およびフィルタリングに先立って実施されうる。４０６で、鍵が取得されうる。鍵は、様々な手段を使用して取得されうる（図５も参照）。４０６で、鍵は導出（生成）されてもよく、導出された鍵は、ユーザデータ通信を暗号化し、かつ完全性保護するために使用されてよい。例えば、Ｐ２Ｐ通信が、意図された職員によってのみ受信され、処理されることを保証するために、パブリックセーフティ作業者が、通信が暗号化され、メッセージが認証されるように望むことがある。

図５をまた参照すると、４０６で行われうる鍵生成は、共有された秘密、公開鍵またはそれらの組合せに基づきうる。本明細書でさらに示され、かつ説明されるように、４０６でセキュアなユーザデータ通信を確立することは、予め共有された鍵５０２、鍵導出５０４、公開／私有鍵ペア（例えば、ＩＢＥ）５０６、ブートストラップされたセキュリティアソシエーション５０８、またはそれらの任意の適切な組合せに基づきうる。例えば、例示的な共有された秘密シナリオにおいて、図２に示されたＵＥ２０４および２０６の１つなどのＵＥと、図２に示されたネットワーク２０８などのネットワークとの間で生成された信頼が、認証のための鍵を導出し、機密性を提供するために活用されてよい。また、以下でさらに説明されるように、生成された信頼は、例えば、第１および第２のＵＥ２０４および２０６などの２つのＵＥ間で通信されるデータの完全性を保証するために活用されてよい。例示的な公開鍵シナリオにおいて、動的に生成された、または静的な公開／私有鍵ペアが、ＵＥ認証、メッセージ認証およびセッション鍵導出のために使用されうる。あるいは、ＰＫＩベースのシステムが使用されうる。鍵生成へのハイブリッドなアプローチを使用する例示的な実施形態において、鍵生成は、共有された秘密および公開鍵に基づく。例えば、共有された秘密は、公開／私有鍵ペア、もしくは公開鍵に基づいたアイデンティティ（例えば、アイデンティティベースの暗号化（ＩＢＥ））を導出するために使用されてよく、または、ＰＫＩもしくは公開／私有鍵ペアが、共有された秘密を導出するために、セキュアなトンネルを生成するために使用されてもよい。

以下で説明される様々な例示的な実施形態において、既存のセキュリティアソシエーションがセキュアなＤ２Ｄ通信を確立するために利用される。例えば、ＵＥと基地局（例えば、ｅＮＢ）との間、ＵＥとＭＭＥとの間、ＵＥとアプリケーションエンティティとの間などの既存のセキュリティアソシエーションが、他のセキュリティアソシエーションを導出するために利用されうる。上述された既存のセキュリティアソシエーションは、ネットワークレベル（例えば、無線、ＲＡＮ）での、および／または、より高いレベル（例えば、アプリケーションレベル）での、ＰｒｏＳｅセキュリティアソシエーションを導出するために活用されてよい。

例えば、図６を参照すると、第１のＵＥ６０２および第２のＵＥ６０４は、近傍サービスネットワークレイヤアソシエーションを生成するために、それぞれのアクセスネットワークレイヤセキュリティアソシエーションを活用する。図示の実施形態に従って、ＰｒｏＳｅネットワークレイヤアソシエーション、およびとりわけ、導出され、ＰｒｏＳｅネットワークレイヤアソシエーションに関連付けられたルート鍵６０６（（Ｋ_ｅＮＢ）_ＰｒＡＳ）が、ユーザプレーン通信鍵６０８（Ｋ_{ＵＰｅｎｃ}）_ＰｒＡＳを導出するために使用されてよい。ユーザプレーン通信鍵は、ＵＥ６０２と６０４との間で転送されるユーザデータを暗号化するために使用され得る。代替的実施形態において、ルート鍵６０６（（Ｋ_ｅＮＢ）_ＰｒＡＳ）は、近傍サービス発見および通信のためのルート鍵であり、それは、ネットワーク鍵（Ｋ_ｅＮＢ）から導出される。ルート鍵６０６（（Ｋ_ｅＮＢ）_ＰｒＡＳ）はまた、グループ直接リンクマスター鍵（ＧＤＬＭＫ）とも呼ばれてよい。例えば、鍵（Ｋ_ｅＮＢ）_ＰｒＡＳおよび（Ｋ_{Ｕｐｅｎｃ}）_ＰｒＡＳは、例えば、ｅＮＢを介して、またはピアＵＥから直接、ピアＵＥによって提供された鍵材料を含む入力を使用して鍵導出関数（ＫＤＦ）から導出されてよい。２つのＵＥが近傍サービスを要求し、ＵＥが同じｅＮＢのカバレッジ下にあるシナリオにおいて、ＰＳＳＦは、呼び出されてよく、ｅＮＢに設置されてよい。

引き続き図６を参照すると、図示の実施形態に従って、ＵＥ６０４および６０２は、それぞれ、ＭＭＥとの一意に存在するセキュリティアソシエーションを有する。ＵＥ６０４および６０２は、既存のセキュリティアソシエーションに対応する、図６でＫ_ＡＳＭＥと示された鍵をさらに有する。示されるように、各鍵Ｋ_ＡＳＭＥは、セキュリティアソシエーション、並びに暗号鍵（ＣＫ）およびアイデンティティ鍵（ＩＫ）に基づいて導出される。各ＣＫおよびＩＫは、各ＵＥと、ひとまとめにＨＳＳ／ＡｕＣと呼ばれうる、認証センター（ＡｕＣ）のホーム加入者サーバ（ＨＳＳ）との間で実施される、認証および鍵共有（ＡＫＡ）プロトコルの一部として導出されていてよい。ＡＫＡプロトコルは、３ＧＰＰ ＬＴＥ／ＵＭＴＳ標準により実施されうる。例示的な実施形態において、第１の導出鍵と呼ばれうる鍵が、第１のＵＥ６０２とｅＮＢとの間で関連付けられたネットワーク鍵Ｋ_ｅＮＢから導出される。第２の導出鍵と呼ばれうる別の鍵が、第２のＵＥ６０４とｅＮＢとの間で関連付けられたネットワーク鍵Ｋ_ｅＮＢから導出される。第１および第２の導出鍵に基づいて、ＵＥ６０２および６０４の各々と、それらのそれぞれのｅＮＢとの間の既存のネットワークレイヤアソシエーションのセキュリティに影響することなく、ＰｒｏＳｅレイヤでの２つのネットワークアソシエーションを結合するルート鍵６０６（（Ｋ_ｅＮＢ）_ＰｒＡＳ）が導出される。示されるように、ＰｒｏＳｅセッションのためのベース鍵としてルート鍵６０６（Ｋ_ｅＮＢ）_ＰｒＡＳを使用して、ユーザプレーン通信鍵６０８（（Ｋ_{ＵＰｅｎｃ}）_ＰｒＡＳ）が、セキュアなＰｒｏＳｅ通信を提供するために導出される。ルート鍵６０６はまた、本明細書で、共通鍵またはＰｒｏＳｅセッション鍵とも呼ばれうる。

例示的な実施形態において、ＰｒｏＳｅセッションをセキュリティ保護する一部として、ユーザプレーン通信鍵６０８（（Ｋ_{ＵＰｅｎｃ}）_ＰｒＡＳ）は、ＰｒｏＳｅセッション鍵（Ｋ_ｅＮＢ）_ＰｒＡＳから導出される。ユーザプレーン通信鍵は、一方向（例えば、ＵＥ６０２からＵＥ６０４）での通信を暗号化することによって、ＵＥ／ユーザのＰｒｏＳｅ通信に機密性を提供することができる。一実施形態において、別のユーザプレーン通信鍵（Ｋ_{Ｄｏｗｎｅｎｃ}）_ＰｒＡＳが、もう一方の方向（例えば、ＵＥ６０４からＵＥ６０２）でのＰｒｏＳｅ通信を暗号化するために生成されてよい。あるいは、１つの鍵が、両方向において機密性を提供するために使用されてもよい。例えば、暗号化鍵（Ｋ_ｅｎｃ）_ＰｒＡＳは、第１のＵＥ６０２と第２のＵＥ６０４との間のＰｒｏＳｅ通信を、両方向で暗号化することができる。追加的な鍵が、ルート鍵６０６（Ｋ_ｅＮＢ）_ＰｒＡＳから導出されうる。例えば、１または複数の追加的な鍵が、ユーザのＰｒｏＳｅ通信に完全性保護を提供することができる。１または複数の追加的な鍵は、ＰｒｏＳｅ通信セッションに関連付けられた制御メッセージまたはシグナリングメッセージに、完全性保護をさらに提供することができる。ＰｒｏＳｅ通信の完全性保護のために使用される１または複数の鍵はまた、メッセージ認証のために使用されてもよい。さらに、１または複数の追加的な鍵は、以下でさらに説明されるように、否認防止のために生成されてもよい。ある事例において、暗号化、完全性保護、メッセージ認証、デジタル署名などのために使用される例示的なアルゴリズムは、ＭＭＥ、ｅＮＢ、ＰＳＳＦ、または他のネットワークエンティティなどのネットワークエンティティによって指図されてよい。他の事例において、アルゴリズムは、ネットワークインフラストラクチャを使用して、またはＤ２Ｄリンクセットアッププロセス中に、ＵＥ間でネゴシエートされてもよい。

図７Ａを参照すると、例示的なシステム７００は、ｅＮＢ７０２と、第１のＵＥ７０４と、第２のＵＥ７０６とを含む。第１および第２のＵＥ７０４および７０６は、ｅＮＢ７０２を介してセルラネットワークと通信することができる。図７Ａは、近傍サービスセキュリティ機能（ＰＳＳＦ）２０２がｅＮＢ７０２上で実行される例示的な実施形態による、鍵生成および配布についての流れ図である。例示的なシステム７００は、開示される主題の説明を促進するために簡略化されており、本開示の範囲を限定するように意図されていないことが認識されるであろう。システム７００などのシステムに加えて、またはそれに代えて、他のデバイス、システムおよび構成が、本明細書で開示される実施形態を実装するために使用されてもよく、全てのそのような実施形態は、本開示の範囲内として企図される。図示の実施形態に従って、７０８で、無線レベルセキュリティアソシエーションが、第１のＵＥ７０４とｅＮＢ７０２との間で、初期ネットワーク接続、例えば、初期ＬＴＥ接続の一部として確立される。第１の鍵Ｋ_ｅＮＢ１が、第１のＵＥ７０４によって導出され、第１の鍵Ｋ_ｅＮＢ１は、ネットワークからｅＮＢ７０２に引き渡されうる。あるいは、第１の鍵Ｋ_ｅＮＢ１は、ネットワークによって提供されるキーイング材料に基づいて、ｅＮＢ７０２によって生成されても、または抽出されてもよい。このようにして、ＰＳＳＦ２０２は、第１の鍵を取得することができ、ｅＮＢ７０２は、一般に、ネットワークエンティティと呼ばれうる。従って、ＰＳＳＦ２０２は、第１のＵＥ７０４と、例えば、ｅＮＢ７０２などのネットワークエンティティとの間で予め確立されたセキュリティアソシエーションに関連付けられた第１の鍵を取得することができる。第１の鍵はまた、第１のＵＥ７０４とｅＮＢ７０２との間の共有された秘密とも呼ばれうる。同様に、７１０で、無線レベルセキュリティアソシエーションが、第２のＵＥ７０６と、ｅＮＢ７０２との間で確立される。図示の実施形態に従って、７１０で、第２の鍵Ｋ_ｅＮＢ２が、第２のＵＥ７０６によって導出される。第２の鍵は、ＰＳＳＦ２０２によって取得されうる。このようにして、ＰＳＳＦ２０２は、第２のＵＥ７０６と、例えば、ｅＮＢ７０２などのネットワークエンティティとの間で予め確立されたセキュリティアソシエーションに関連付けられた第２の鍵を取得することができる。第２の鍵はまた、第２のＵＥ７０６とｅＮＢ７０２との間の共有された秘密とも呼ばれうる。

なおも図７Ａを参照すると、図示の実施形態に従って、７１２で、ＰＳＳＦ２０２は、近傍通信に関する通知を受信する。ある事例において、図４に示された機能４００が、７１２で通知が受信される前に、ＵＥ７０４および７０６の１または複数によって実施されうる。本明細書で使用されるとき、近傍通信は、ワイヤレスＰ２Ｐ通信またはＤ２Ｄ通信を指す。通知に基づいて、例えば、ＰＳＳＦ２０２は、近傍サービス鍵生成機能を開始する。受信された通知は、第１のＵＥ７０４および第２のＵＥ７０６が、近傍通信に互いに関与したいと所望することを示すことができる。通知は、例えば、第１および第２のＵＥ７０４および７０６の１つ、アプリケーション、ＰｒｏＳｅサーバなどによって提供されうる。７１４で、ＰＳＳＦ２０２はノンス（nonce）を生成する。さらに、ＰＳＳＦ２０２は、ノンスおよび第１の鍵Ｋ_ｅＮＢ１の関数に等しい第１の中間鍵を導出することができる。第１の中間鍵はまた、ノンスおよび第１の鍵Ｋ_ｅＮＢ１の導出物に基づいて導出されうる。第１の鍵の導出物は第１の導出鍵Ｋ_ｅＮＢ１ ^＋と呼ばれうる。ある事例において、第１の導出鍵Ｋ_ｅＮＢ１ ^＋は、少なくとも最初は、例えば、もっぱらＰｒｏＳｅサービスのために使用されてよい。便宜上、第１の中間鍵を「Ｘ」と呼び、Ｘを生成する関数が、ｆ（Ｎｏｎｃｅ，Ｋ_ｅＮＢ１）またはｆ（Ｎｏｎｃｅ，Ｋ_ｅＮＢ１ ^＋）によって表現されうる。Ｘを生成する関数は、例えば、ＨＭＡＣ−ＳＨＡ−２５６関数であってよい。同様に、７１４で、ＰＳＳＦ２０２は、ノンスおよび第２の鍵Ｋ_ｅＮＢ２の関数に等しい第２の中間鍵を導出することができる。第２の中間鍵はまた、ノンスおよび第２の鍵Ｋ_ｅＮＢ２の導出物に基づいて導出されうる。第２の鍵の導出物は第２の導出鍵Ｋ_ｅＮＢ２ ^＋と呼ばれうる。ある事例において、第２の導出鍵Ｋ_ｅＮＢ２ ^＋は、少なくとも最初は、例えば、もっぱらＰｒｏＳｅサービスのために使用されてよい。便宜上、第２の中間鍵を「Ｙ」と呼び、Ｙを生成する関数が、ｆ（Ｎｏｎｃｅ，Ｋ_ｅＮＢ２）またはｆ（Ｎｏｎｃｅ，Ｋ_ｅＮＢ２ ^＋）によって表現されうる。図示の実施形態に従って、７１６で、ＰＳＳＦ２０２は、ノンスおよび第２の中間鍵Ｙを、第１のＵＥ７０４に送る（送信する）。第２の中間鍵Ｙは、Ｘを使用して暗号化されてよく、Ｙの暗号化値は、「｛Ｙ｝_Ｘ」によって表現されてよい。７１８で、図示の実施形態に従って、ＰＳＳＦ２０２は、ノンスおよび第１の中間鍵Ｘを、第２のＵＥ７０６に送る（送信する）。第２の中間鍵Ｘは、Ｙを使用して暗号化されてよく、従って、Ｘの暗号化値は、｛Ｘ｝_Ｙによって表現されてよい。７２０で、第１のＵＥ７０４は、ノンスおよび第１の鍵の関数からＸを導出し、さらに、Ｘを使用してＹを復号する。第１のＵＥ７０４は、第１の中間鍵Ｘおよび第２の中間鍵Ｙの関数に等しく、ｆ（Ｘ，Ｙ）と呼ばれ得る、第３の鍵（ＫｅＮＢ）_ＰｒＡＳを生成することができる。

引き続き図７Ａを参照すると、７２２で、第２のＵＥ７０６は、ノンスおよび第２の鍵の関数からＹを導出し、さらに、Ｙを使用してＸを復号する。図示の実施形態に従って、第２のＵＥ７０６もまた、第１の中間鍵Ｘおよび第２の中間鍵Ｙの関数に等しい第３の鍵（ＫｅＮＢ）_ＰｒＡＳを生成することができる。第３の鍵（ＫｅＮＢ）_ＰｒＡＳは、ＰｒｏＳｅ通信のためのルート鍵を形成することができ、従って、第３の鍵はまた、第１のＵＥ７０４と第２のＵＥ７０６との間の近傍通信をセキュリティ保護するための共通共有鍵とも呼ばれ得る。このようにして、ＰＳＳＦ２０２は、第１の鍵および第２の鍵に基づいて、第１のＵＥ７０４および第２のＵＥ７０６によってそれぞれ使用され得る第１および第２の中間鍵を導出して、第１のＵＥ７０４と第２のＵＥ７０６との間の近傍通信をセキュリティ保護するための共通共有鍵を導出することができる。７２４で、ＰＳＳＦ２０２は、例えば、合法な傍受（ＬＩ）がネットワークによって要求された場合に、オプションで、第３の鍵（ＫｅＮＢ）_ＰｒＡＳを生成することができる。ある事例において、ＵＥ７０４および７０６は、第３の鍵（ＫｅＮＢ）_ＰｒＡＳから、追加的な鍵を導出することができる。例えば、追加的な鍵は、第１のＵＥ７０４と第２のＵＥ７０６との間で第３の鍵を使用してセキュリティ保護されていてよいセキュアなＤ２Ｄ接続を通して導出されてよく、その結果、ｅＮＢ７０２および他のネットワークエンティティは、追加的な鍵に内々に関知しない。このようにして、例示的な実施形態に従って、１または複数の追加的な鍵は、Ｄ２Ｄ接続におけるデバイスのみが１または複数の追加的な鍵を所有するように、Ｄ２Ｄ接続を介して第３の鍵（ＫｅＮＢ）_ＰｒＡＳから導出されてよい。

代替的実施形態において、７１４で、２つのノンス、例えば、第１のノンス（Ｎｏｎｃｅ１）および第２のノンス（Ｎｏｎｃｅ２）が、ＰＳＳＦ２０２によって生成される。第１および第２のノンスは、第１の中間鍵Ｘ＝ｆ（Ｎｏｎｃｅ１，Ｋ_ｅＮＢ１）、および第２の中間鍵Ｙ＝ｆ（Ｎｏｎｃｅ２，Ｋ_ｅＮＢ２）を、それぞれ計算するために使用されうる。従って、ＰＳＳＦ２０２は、第２のノンス、および第１の中間鍵Ｘで暗号化された第２の中間鍵Ｙを、第１のＵＥ７０４に送ることができ、ＰＳＳＦ２０２は、第１のノンス、および第２の中間鍵Ｙで暗号化された第１の中間鍵Ｘを、第２のＵＥ７０６に送ることができる。あるいは、ＵＥ７０４および７０６は、それら独自のノンスを生成することができ、それは、ＵＥ７０４および７０６に接続された１または複数のＰｒｏＳｅサーバを介してＰＳＳＦ２０２に送られる。さらに、ＵＥ７０４および７０６は、それらのそれぞれの公開鍵でＸおよびＹを暗号化することによって、第１および第２の中間鍵ＸおよびＹを互いに対して送ることができる。

代替的実施形態において、図７Ｂを参照すると、例示的なシステム７０１は、モバイル管理エンティティ（ＭＭＥ）７０３と、第１のＵＥ７０４と、第２のＵＥ７０６とを含む。図７Ｂは、近傍サービスセキュリティ機能（ＰＳＳＦ）２０２がＭＭＥ７０３上で実行される例示的な実施形態による、鍵生成および配布についての流れ図である。図７Ｂに関して示されるステップは、図７ＡにおけるｅＮＢ７０２が、図７ＢではＭＭＥ７０３に置き換えられていることを除いて、図７Ａに関して説明されている。従って、例えば、図７Ａで第１のＵＥ７０４によって導出され、ＭＭＥ７０３によって取得される第１の鍵は、第１の鍵Ｋ_{ＡＳＭＥ１}として表され、第２のＵＥ７０６によって導出され、ＭＭＥ７０３によって取得される第２の鍵は、第２の鍵Ｋ_{ＡＳＭＥ２}として表される。第１の鍵Ｋ_{ＡＳＭＥ１}は、あるいは、ＵＥ７０４とＭＭＥ７０３との間で確立された鍵の導出物であってもよい。同様に、第２の鍵Ｋ_{ＡＳＭＥ２}は、ＵＥ７０６とＭＭＥ７０３との間で確立された鍵の導出物であってもよい。導出鍵は、少なくとも最初は、例えば、もっぱら近傍サービスのために生成されてよい。さらに図７Ｂを参照すると、７２０で、第１のＵＥ７０４は、第１の中間鍵Ｘおよび第２の中間鍵Ｙの関数に等しい第３の鍵（Ｋ_ＡＳＭＥ）_ＰｒＡＳを生成することができる。７２２で、第２のＵＥ７０６は、第１の中間鍵Ｘおよび第２の中間鍵Ｙの関数に等しい第３の鍵（Ｋ_ＡＳＭＥ）_ＰｒＡＳを生成することができる。図７Ａを参照して説明したように、図７Ｂにおける第３の鍵（Ｋ_ＡＳＭＥ）_ＰｒＡＳもまた、ＰｒｏＳｅ通信のためのルート鍵を形成することができ、従って、第３の鍵はまた、第１のＵＥ７０４と第２のＵＥ７０６との間の近傍通信をセキュリティ保護するための共通共有鍵とも呼ばれ得る。

一実施形態において、ＵＥ間で共有される鍵は、静的にプロビジョニングされる。そのような実施形態において、図７Ａおよび７Ｂを全体的に参照すると、ＰｒｏＳｅ通信をセキュリティ保護するための鍵（または鍵を導出するためのキーイング材料）は、ＰＳＳＦ２０２によって、ＵＥ７０４および７０６にプロビジョニングされうる。鍵またはキーイング材料は、ＵＥ７０４および７０６がキーイング材料を提供する、または導出する必要なしに、プロビジョニングされうる。例えば、再び図７Ａおよび７Ｂを参照すると、第３の鍵（ＫｅＮＢ）_ＰｒＡＳおよび（Ｋ_ＡＳＭＥ）_ＰｒＡＳは、キーイング材料または既存のネットワークレイヤセキュリティアソシエーション鍵（Ｋ_ｅＮＢ）を要求することなく、第１および第２のＵＥ７０４および７０６に、直接プロビジョニングされうる。グループアイデンティティおよびグループ鍵、並びにアソシエーションは、ＳＩＭカードまたはセキュアなストレージ上で利用可能であってよい。これらの鍵は、例えば、組織がユーザのためのデバイスを構成するときに、組織によってプロビジョニングされうる。そのような鍵は、セッション鍵を暗号学的かつ周期的に導出するために、ＵＥによって使用されうる。キーイング材料は、ネットワークによってＵＥに送られてよく、その結果、ＵＥのＳＩＭまたはスマートカード内で共有された秘密が、より新しい鍵を導出するために使用される。

様々な例示的な実施形態において、ネットワークレイヤ認証アソシエーションは、ＰｒｏＳｅアプリケーションレイヤセキュリティアソシエーションを生成するために、ブートストラップされる。例えば、ＵＥ７０４と、ｅＮＢ７０２またはＭＭＥ７０３との間のネットワークレベル認証が、ＰｒｏＳｅアプリケーションレイヤセキュリティアソシエーションを生成するために使用されてよく、それが、例えば、第１および第２のＵＥ７０４および７０６などの２つのピアの間、またはグループ内のメンバーの間のアプリケーションレイヤ通信を保護するために使用され得る。このようにして、アプリケーションレイヤ通信は、機密であることが可能であり、完全性保護されることができる。例えば、ネットワークレイヤでのＰｒｏＳｅ通信は、図７Ａおよび７Ｂを参照して説明した例示的な実施形態に従って保護されてよく、ＰｒｏＳｅアプリケーションレイヤ通信は、ネットワークレイヤ通信がセキュリティ保護されるのと実質的に同時に、セキュリティ保護されうる。

さらに別の例示的な実施形態において、アプリケーションレイヤセキュリティアソシエーションは、ネットワークレベルアクセスのために、リバースブートストラップされる。例えば、ＰＳＳＦ２０２は、例えば、汎用ブートストラッピングアーキテクチャ（ＧＢＡ）によって定義されるような、ネットワークアプリケーション機能（ＮＡＦ）などのアプリケーションレイヤセキュリティアサーション機能のサービスを呼び出すことができる。ＮＡＦは、ＰｒｏＳｅ鍵管理を促進するために呼び出されうる。例示的な実施形態に従って、ＧＢＡプロトコルの一部として導出されている鍵が、第１のＵＥ７０４と第２のＵＥ７０６との間などの、２つのＵＥ間のＰｒｏＳｅ鍵を導出するために使用されうる。例えば、（Ｋ_ｅＮＢ）_ＰｒＡＳ、（Ｋ_ＡＳＭＥ）_ＰｒＡＳ、またはＰｒｏＳｅ通信のための他のネットワークレベルの鍵を導出するために使用可能であってよい鍵を生成するために、任意のより高いレイヤアソシエーションが再使用されうる。例えば、ユーザと、Ｇｏｏｇｌｅ（登録商標）またはＦａｃｅｂｏｏｋ（登録商標）との間の同様のアプリケーションレイヤセキュリティアソシエーションが、ＰｒｏＳｅネットワークレイヤまたはアプリケーションレイヤの通信を保護するための鍵を導出するために、ブートストラップされうる。アプリケーションレイヤアソシエーションは、ＨＴＴＰ上で拡張可能な認証プロトコル（ＥＡＰ）プロトコルを使用して、または、例えば、ユーザ名およびパスワードによるＨＴＴＰＳを活用するＴＬＳベースのセキュリティアソシエーションを使用して、遂行されうる。例えば、ＦａｃｅｂｏｏｋサーバまたはＧｏｏｇｌｅサーバなどのアプリケーションサーバに設置されたＰＳＳＦは、ＰｒｏＳｅアプリケーションレイヤセキュリティアソシエーションおよび対応する鍵を導出するために、ユーザと、アプリケーションサーバとの間のセキュリティアソシエーションに関連付けられた、既存のマスターセッション鍵（ＭＳＫ）を使用することができる。

公開鍵に基づいた例示的な実装形態の初期設定のために、一例示的な実施形態において、各ＵＥは、Ｋ_ｅＮＢから導出された鍵によって保護されたセキュアなチャネルを使用して導出された、公開および私有鍵ペアを使用することができる。各ＵＥはその公開鍵をアドバタイズ（advertise）することができる。例えば、ＵＥは、ビーコンメッセージにおいてその公開鍵をアドバタイズすることができる。例示的な変形実装形態において、公開鍵は、例えば、アイデンティティベースの暗号化（ＩＢＥ）に基づいて、一時的なＵＥアイデンティティから導出され得る。

図７Ａを全体的に参照すると、別の代替的シナリオにおいて、ＰｒｏＳｅ参加ＵＥを発見するためにｅＮＢ７０２が登録される場合、ｅＮＢ７０２は、他のＵＥの公開鍵を用いて各ＵＥを構成することができる。従って、ｅＮＢ７０２は、第２のＵＥ７０６の公開鍵を用いて第１のＵＥ７０４をプロビジョニングすることができ、ｅＮＢ７０２は、第１のＵＥ７０４の公開鍵を用いて第２のＵＥ７０６をプロビジョニングすることができる。さらに、各ＵＥ７０４および７０６は、その私有鍵で、そのそれぞれのビーコンを暗号化することができ、ピアＵＥと呼ばれ得る他のＵＥは、アドバタイズするＵＥを認証するためのアドバタイズするＵＥの公開鍵を使用して、ビーコン情報を復号することができる。このようにして、第１のＵＥ７０４は、私有鍵でそのビーコンを暗号化することができ、第２のＵＥ７０６は、第１のＵＥ７０４の公開鍵を使用して、ビーコンを復号することができる。第２のＵＥ７０６は、第１のＵＥ７０４の私有鍵を使用して、第１のＵＥ７０４を認証することができる。ある事例では、ＵＥが、それが探していたＵＥのうちの１つをそれが見つけたことを検出するとき、ＵＥは、ｅＮＢ７０２に表示を送ることができる。ｅＮＢ７０２は、ネクストホップパラメータ（例えば、ネクストチェーンホップカウンタ（Next Chaining Hop Counter：ＮＣＣ）、ネクストホップ（ＮＨ））を用いてＵＥを構成して、パラメータを使用して共有された秘密を導出することができる。共有された秘密を導出するために使用されるパラメータは、例えば、ピアＵＥの公開鍵、ＵＥ独自の私有鍵、ＮＣＣ、ＮＨなどを含むことができる。従って、ｅＮＢ７０２によるピアＵＥへの鍵配布は、実質的に対称であってよい。

別の例示的な実施形態において、ＵＥは、ピアツーピア通信リンクごとに、１または複数の、例えば、２つの鍵を維持することができる。例えば、１つの鍵は、そのＫ_ｅＮＢおよびピアＵＥの私有鍵から導出された、アウトバウンドデータのためであってよく、デジタル署名を生成するためにメッセージに署名するために使用されてよい。もう１つの鍵は、送り手のデジタル署名を検証するために、ＫｅＮＢおよび送り手ＵＥの公開鍵から導出された、インバウンドリンクのためであってよい。

図２および図７Ａ−Ｂを全体的に参照すると、ＰＳＳＦ２０２は、認証局、または、それを主張するＵＥに属する公開鍵を認証する「公証人」の役割を果たすことができる。従って、ｅＮＢ７０２は、図７Ａに図示されたシナリオなどの上述されたシナリオにおいて、認証局（ＣＡ）または公証人として機能することができる。同様に、ＭＭＥ７０３またはＰｒｏＳｅサーバは、図７Ｂに図示されたシナリオにおいて、ＣＡとして機能することができる。あるいは、鍵導出は、以下で説明されるように、アクセスネットワーク発見および選択（ＡＮＤＳＦ）ポリシーを使用することができる。

発見および鍵管理がＰｒｏＳｅサーバを使用する例示的な実施形態において、所与のＵＥは、特定のアプリケーションのために、および／または特定の関心のために、ＰｒｏＳｅサーバに登録する。ＰｒｏＳｅサーバは、アプリケーションアイデンティティ（ＡｐｐＩｄ）および／またはマスクを、直接、またはｅＮＢおよび／もしくはＭＭＥを通して、ＵＥに提供する。ＵＥは、ＡｐｐＩｄを使用してマスクを生成することができる、または、マスクを直接取得することができる。マスクは、発見ビーコン情報を別のＵＥに送るために使用されうる。あるいは、ビーコンが、意図された受信側の公開鍵で暗号化されてもよく、その私有鍵を使用してビーコンを復号することが可能なエンティティは、送り手を識別することができる。さらに別の代替的実装形態において、ビーコンは、ＰｒｏＳｅサーバから取得された、またはＡｐｐＩｄに基づいて取得されたグループ公開鍵で暗号化されてもよい。そのような実装形態において、グループ公開鍵とペアにされた私有鍵が、全てのグループメンバー（例えば、Ｆａｃｅｂｏｏｋのユーザ）のために構成される。グループ公開鍵および私有鍵ペアは、発見のために使用される。

発見がＡＮＤＳＦポリシーに基づいた例示的な実施形態において、１または複数のＵＥは、ＡＮＤＳＦルールを使用して、他のＵＥを発見することができる。例えば、所与のＵＥが、ＡＮＤＳＦルールを使用して、所与のＵＥと、同じサービス、ユーザグループ、またはピアツーピアセッションに関心のある別のＵＥを発見することができる。例えば、アプリケーションアイデンティティ（ＡｐｐＩＤ）がＡＮＤＳＦルールに準拠していると仮定すると、ＡｐｐＩＤを有するユーザは、ＵＥを介して、ビーコンを検出する。ＵＥは、ＵＥのユーザに対応した１または複数のＡｐｐＩｄ、例えば、ＡｐｐＩｄのリストを使用して、ビーコンを復号することができる。さらに、ビーコン生成機能は、ＡＮＤＳＦロケーションベースのルールに基づいていてよい。例示的なルールにおいて、一定のＡｐｐＩｄは、一定のロケーションで使用され、しかし他のロケーションでは使用されない。例えば、パブリックな場所では、ルールは、Ｆａｃｅｂｏｏｋ ＡｐｐＩｄのみが使用されることを要求することがあるが、ルールは、他のＡｐｐＩＤがホームで使用されるのを可能にすることができる。

図８を参照すると、図示の実施形態に従って、２つのＵＥの２人のユーザ（ユーザ１およびユーザ２）を発見するためにｅＮＢが登録された場合、ｅＮＢは、他のＵＥの公開鍵を用いて各ＵＥを構成することができる。図８は、例示的な発見方法８００を示す流れ図である。例示的な発見方法８００などの様々な発見メカニズムは、図６、７Ａ、７Ｂ、１０Ａおよび１０Ｂを参照して説明される鍵導出に先行しうることが理解されるであろう。

公開鍵方法に基づいた暗号プロトコルは、証明書および公開鍵インフラストラクチャ（ＰＫＩ）に基づいて、証明書管理をサポートすることができる。例示的な実施形態に従って、アイデンティティベースの暗号化（ＩＢＥ）プロトコルの使用は、よりよい柔軟性を提供しながら、私有鍵生成機関（ＰＫＧ）を介したインフラストラクチャ要件の簡略化を可能にすることができる。別の実施形態において、ユーザは、ＰＫＩ／証明書またはＩＢＥメカニズムの要件なしに、公開鍵のみを使用して、ＰＳＳＦに登録されうる。

鍵交換プロトコルのＩＢＥファミリーは、アップストリームネットワークアクセスのための最小可用性要件を有することがある。従来の公開鍵方法では、そのような接続性は、証明書取り消し、並びにオンライン証明書検証のために、必要とされる。Ｄ２Ｄ、ＰｒｏＳｅ、およびグループ通信（例えば、アップストリームネットワークアクセスの限定された可用性）の性質のために、ＩＢＥプロトコルの上記で言及された特質は、Ｄ２Ｄ、ＰｒｏＳｅ、およびグループ通信の鍵交換並びに鍵管理スキームに役立ちうる。

従来のＩＢＥプロトコルは、鍵交換についての事実上の鍵供託であるＰＫＧの特徴を有する一方で、Ｄ２Ｄ、ＰｒｏＳｅ、およびグループ通信がサポートしなければならないことがある合法な傍受（ＬＩ）規制要件により、この特徴が役立つことがある。例えば、図９は、例示的な実施形態による、認証されたアイデンティティベースの暗号化（ＩＢＥ）鍵交換についての流れ図である。図９を参照すると、例示的なシステム９００が、第１のＵＥ９０４と、第２のＵＥ９０６と、第１の私有鍵生成機関（ＰＫＧ）９０８と、第２のＰＫＧ９１０とを含む。例示的なシステム９００は、開示される主題の説明を促進するために簡略化されており、本開示の範囲を限定するように意図されないことが認識されるであろう。システム９００などのシステムに加えて、またはそれに代えて、他のデバイス、システム、および構成が、本明細書で開示される実施形態を実装するために使用されてもよく、全てのそのような実施形態は、本開示の範囲内として企図される。

図９を参照すると、プロビジョニング段階と呼ばれうる９１２で、第１のＵＥ９０４は、ＰｒｏＳｅサービスのために使用されてよいパブリックアイデンティティを、ＰＫＧ９０８に要求する。第１のＵＥ９０４は、第１のＵＥ９０４と第１のＰＫＧ９０８との間で予め確立されたセキュリティアソシエーションに基づいて、第１の鍵と呼ばれうる公開／私有鍵ペア（Ｐｕ／Ｐｒと表される）を第１のＰＫＧ９０８から取得することができる。従って、第１のＵＥ９０４が要求し、受信するパブリックアイデンティティは、第１のＵＥ９０４と第１のＰＫＧ９０８との間で予め確立されたセキュリティアソシエーションに関連付けられた第１の鍵であってよい。同様に、またプロビジョニング段階とも呼ばれうる９１４で、第２のＵＥ９０６は、パブリックアイデンティティを、第２のＰＫＧ９１０に要求する。第２のＵＥ９０６は、第２のＵＥ９０６と第２のＰＫＧ９１０との間で予め確立されたセキュリティアソシエーションに基づいて、第２の鍵と呼ばれうる公開／私有鍵ペア（Ｐｕ／Ｐｒと表される）を第２のＰＫＧ９１０から取得することができる。従って、第２のＵＥ９０６が要求し、受信するパブリックアイデンティティは、第２のＵＥ９０６と第２のＰＫＧ９１０との間で予め確立されたセキュリティアソシエーションに関連付けられた第２の鍵であってよい。第１のＰＫＧ９０８および第２のＰＫＧ９１０は、例えば、ｅＮＢなどのネットワークエンティティ上に常駐することができる。従って、第１のＰＫＧ９０８および第２のＰＫＧ９１０は、それぞれネットワークエンティティと呼ばれうる。さらに、ＵＥ９０４および９０６は、同じ私有鍵生成機関、または異なる私有鍵生成機関からアイデンティティを受信することができる。

請求（requisition）とも呼ばれうる、９１２および９１４でのプロビジョニング段階は、第１のＵＥ９０４と第のＵＥ９０６との間で任意のＰｒｏＳｅ通信が行われる前に実施されてよい。図７Ａおよび図７Ｂ（７１２を参照されたい）に関して説明された通知などのトリガに基づいて、９１６で、第１のＵＥ９０４は、第１のノンス（Ｎｏｎｃｅ_ＵＥ１）および他のキーイング材料を生成することができる。第１のノンスは第１の中間鍵と呼ばれうる。第１のＵＥ９０４は、第２のＵＥ９０６の公開鍵（Ｐｕ_ＵＥ２と表される）または第２のＵＥ９０６のパブリックアイデンティティで、第１のノンスを暗号化することができる。９１８で、暗号化された第１のノンスを含むメッセージが、第１のＵＥ９０４から第２のＵＥ９０６に送られる。９２０で、第１のＵＥ９０４からのメッセージを受信すると、第２のＵＥ９０６は、図示の実施形態に従って、第１のノンスを復号する。第２のＵＥ９０６は、図９でＰｒ_ＵＥ２として表されるその私有鍵を使用して、第１のノンスおよび他のキーイング材料を復号することができる。９２０で、第２のＵＥ９０６は、第２のノンス（Ｎｏｎｃｅ_ＵＥ２）および他のキーイング材料を生成することができる。第２のノンスは第２の中間鍵と呼ばれうる。第２のＵＥ９０６は、第１のＵＥ９０４の公開鍵（Ｐｕ_ＵＥ１と表される）または第１のＵＥ９０４のパブリックアイデンティティで、第２のノンスを暗号化することができる。９２２で、暗号化された第２のノンスを含むメッセージが、第２のＵＥ９０６から第１のＵＥ９０４に送られる。第２のＵＥ９０６は、９２２で送られる暗号化されたメッセージコンテンツ内に、オプションで第１のノンス（Ｎｏｎｃｅ_ＵＥ１）を含むことができる。９２４で、図示の実施形態に従って、第１のＵＥ９０４は、一般的にキーイング材料ともまた呼ばれうるノンスを復号する。第１のＵＥ９０４は、第３の鍵または共通共有鍵とも呼ばれうるＰｒｏＳｅセッション鍵を導出することができる。例えば、共通共有鍵は、第１および第２のＵＥ９０４および９０６のパブリックアイデンティティ、並びに第１および第２のノンスに、ＨＭＡＣ−ＳＨＡ−２５６関数を使用することによって導出されることができる。あるいは、導出された鍵はチャネルに結合されてもよい。例えば、鍵がＴＬＳチャネルに結合される、またはＥＡＰチャネルに結合される場合、鍵は、ＴＬＳマスター秘密であってよい。従って、共通共有鍵（ＰｒｏＳｅセッション鍵）は、第１および第２のＵＥ９０４および９０６のパブリックアイデンティティ、第１および第２のノンス、並びにチャネルＩＤに、ＨＭＡＣ−ＳＨＡ−２５６関数を使用することによって導出されることができる。

引き続き図９を参照すると、９２６で、第１のＵＥ９０４は肯定応答（Ａｃｋ）メッセージを第２のＵＥ９０６に送ることができる。肯定応答メッセージは、セッション鍵の成功した導出および結合を示すことができる。９２８で、チャネルに結合されうるセッション鍵を導出するために、第２のＵＥ９０６は、９２４で第１のＵＥ９０４が実施したのと同じ動作を実施することができる。従って、ＰｒｏＳｅセッション鍵とも呼ばれうる共通共有鍵は、機密性および完全性を提供することによって、第１のＵＥ９０４と第２のＵＥ９０６との間のＰｒｏＳｅ通信をセキュリティ保護するために使用されることができる。

次に図１０Ａを参照すると、例示的なシステム１０００ａが、ｅＮＢ１００２と、１または複数のＵＥ１００４、例えば、第１のＵＥ１００４ａと、第２のＵＥ１００４ｂと、第３のＵＥ１００４ｃと、第４のＵＥ１００４ｄと、第５のＵＥ１００４ｅとを含む。１または複数のＵＥ１００４は、図３に関して説明されたグループのうちの１つなどのグループに属することができる。５つのＵＥが示されているが、システム１０００ａは、所望に応じて、任意の数のＵＥを含むことができることが理解されるであろう。ＵＥ１００４は、ｅＮＢ１００２を介してセルラネットワークと通信する。サブスクリプションに基づいて、ＵＥ１００４は、ネットワークによってグループ鍵をプロビジョニングされてよい。図示の実施形態に従って、ＰＳＳＦ２０２は、ｅＮＢ１００２に常駐しているが、ＰＳＳＦは、あるいは所望に応じて設置されてよいことが理解されるであろう。図１０Ａは、例示的なネットワークベースのグループ鍵導出プロセスを実証する流れ図を示す。

なおも図１０Ａを参照すると、図示の実施形態に従って、１００８で、無線レベルセキュリティアソシエーションが、第１のＵＥ１００４ａとｅＮＢ１００２との間で、初期ネットワーク接続、例えば、初期ＬＴＥ接続の一部として確立される。第１の鍵Ｋ_ｅＮＢ１が、第１のＵＥ１００４ａによって導出され、第１の鍵Ｋ_ｅＮＢ１は、ネットワークからｅＮＢ１００２に引き渡されうる。従って、ＰＳＳＦ２０２は第１の鍵を取得することができる。従って、ＰＳＳＦ２０２は、第１のＵＥ１００４ａと、例えば、ｅＮＢ１００２などのネットワークエンティティとの間で予め確立されたセキュリティアソシエーションに関連付けられた第１の鍵を取得することができる。第１の鍵はまた、第１のＵＥ１００４ａとｅＮＢ１００２との間の共有された秘密とも呼ばれうる。同様に、１０１０で、無線レベルセキュリティアソシエーションが、第２のＵＥ１００４ｂとｅＮＢ１００２との間で確立される。図示の実施形態に従って、１０１０で、第２の鍵Ｋ_ｅＮＢ２が第２のＵＥ１００４ｂによって導出される。第２の鍵はＰＳＳＦ２０２によって取得されうる。１０１２で、無線レベルセキュリティアソシエーションが、第３のＵＥ１００４ｃとｅＮＢ１００２との間で確立される。図示の実施形態に従って、１０１２で、第３の鍵Ｋ_ｅＮＢ３が第３のＵＥ１００４ｃによって導出される。第３の鍵はＰＳＳＦ２０２によって取得されうる。１０１４で、無線レベルセキュリティアソシエーションが、第４のＵＥ１００４ｄとｅＮＢ１００２との間で確立される。図示の実施形態に従って、１０１４で、第４の鍵Ｋ_ｅＮＢ４が第４のＵＥ１００４ｄによって導出される。第４の鍵はＰＳＳＦ２０２によって取得されうる。

なおも図１０Ａを参照すると、図示の実施形態に従って、１０１６で、ＰＳＳＦ２０２は、近傍通信に関する通知を受信する。通知は、例えば、ＵＥ１００４のうちの１つから、または、近傍サービスサーバから受信されうる。通知に基づいて、例えば、ＰＳＳＦ２０２は近傍サービス鍵生成機能を開始する。受信された通知は、ＵＥ１００４が、近傍通信に互いに関与したいと所望することを示すことができる。１０１８で、ＰＳＳＦ２０２はノンスを生成する。さらに、ＰＳＳＦ２０２は、例えば、第１の中間鍵Ｗ、第２の中間鍵Ｘ、第３の中間鍵Ｙ、および第４の中間鍵Ｚなどの１または複数の中間鍵を導出することができる。さらに、ＰＳＳＦ２０２は、鍵ミキシング順序（ＫＭＯ）と呼ばれうる、中間鍵がミックスされることになる順序を生成することができる。示されるように、第１の中間鍵Ｗは、ノンスおよび第１の鍵の関数を使用して生成され、第２の中間鍵Ｘは、ノンスおよび第２の鍵の関数を使用して生成され、第３の中間鍵Ｙは、ノンスおよび第３の鍵の関数を使用して生成され、第４の中間鍵Ｚは、ノンスおよび第４の鍵の関数を使用して生成される。中間鍵を生成する関数は、例えば、ＨＭＡＣ−ＳＨＡ−２５６関数であってよい。

引き続き図１０Ａを参照すると、図示の実施形態に従って、１０２０で、ＰＳＳＦ２０２は、ノンス、ＫＭＯ、並びに第２、第３および第４の中間鍵を、第１のＵＥ１００４ａに送る。第２、第３および第４の中間鍵は、第１の中間鍵Ｗで暗号化されうる。１０２２で、ＰＳＳＦ２０２は、ノンス、ＫＭＯ、並びに第１、第３および第４の中間鍵を、第２のＵＥ１００４ｂに送る。第１、第３および第４の中間鍵は、第２の中間鍵Ｘで暗号化されうる。１０２４で、ＰＳＳＦ２０２は、ノンス、ＫＭＯ、並びに第１、第２および第４の中間鍵を、第３のＵＥ１００４ｃに送る。第１、第２および第４の中間鍵は、第３の中間鍵Ｙで暗号化されうる。１０２６で、ＰＳＳＦ２０２は、ノンス、ＫＭＯ、並びに第１、第２および第３の中間鍵を、第４のＵＥ１００４ｄに送る。第１、第２および第３の中間鍵は、第４の中間鍵Ｚで暗号化されうる。

１０２８で、第１のＵＥ１００４ａは、第１の中間鍵Ｗを、ノンスおよび第１の鍵の関数から導出し、Ｗを使用してＸ、ＹおよびＺをさらに復号する。第１のＵＥ１００４ａは、第１の中間鍵Ｗ、第２の中間鍵Ｘ、第３の中間鍵Ｙおよび第４の中間鍵Ｚの関数に等しい共通鍵（ＫｅＮＢ）_ＰｒＡＳを生成することができ、関数はｆ（Ｗ，Ｘ，Ｙ，Ｚ）と呼ばれ得る。１０３０で、第２のＵＥ１００４ｂは、第２の中間鍵Ｘを、ノンスおよび第２の鍵の関数から導出し、Ｘを使用してＷ、ＹおよびＺをさらに復号する。第２のＵＥ１００４ｂは、ｆ（Ｗ，Ｘ，Ｙ，Ｚ）に等しい共通鍵（ＫｅＮＢ）_ＰｒＡＳを生成することができる。１０３２で、第３のＵＥ１００４ｃは、第３の中間鍵Ｙを、ノンスおよび第３の鍵の関数から導出し、Ｙを使用してＷ、ＸおよびＺをさらに復号する。第３のＵＥ１００４ｃは、ｆ（Ｗ，Ｘ，Ｙ，Ｚ）に等しい共通鍵（ＫｅＮＢ）_ＰｒＡＳを生成することができる。１０３４で、第４のＵＥ１００４ｄは、第４の中間鍵Ｚを、ノンスおよび第４の鍵の関数から導出し、Ｚを使用してＷ、ＸおよびＹをさらに復号する。第４のＵＥ１００４ｄは、ｆ（Ｗ，Ｘ，Ｙ，Ｚ）に等しい共通鍵（ＫｅＮＢ）_ＰｒＡＳを生成することができる。共通鍵（ＫｅＮＢ）_ＰｒＡＳは、ＰｒｏＳｅ通信のためのルート鍵を形成することができ、共通鍵はまた、ＵＥ１００４同士の間の近傍通信をセキュリティ保護するための共通共有鍵とも呼ばれ得る。１０３６で、ｅＮＢ１００２、およびとりわけ、ＰＳＳＦ２０２はまた、例えば、合法な傍受（ＬＩ）がネットワークによって要求された場合に、共通鍵（ＫｅＮＢ）_ＰｒＡＳを生成することができる。システム１０００ａは、ＵＥ１００４のグループを表すことができるので、図１０Ａで示された共通鍵（ＫｅＮＢ）_ＰｒＡＳは、グループ内で通信するためのグループ鍵（ＫｅＮＢ）_ＰｒＡＳであってよい。例えば、第１のＵＥ１００４ａおよび第２のＵＥ１００４ｂは、第１のＵＥ１００４ａおよび第２のＵＥ１００４ｂに加えた１または複数のＵＥ１００４を含むグループに属することができる。さらに、グループ鍵（ＫｅＮＢ）_ＰｒＡＳは、メッセージのデジタル署名が検証された後で、グループに属するＵＥ１００４の１つによって、メッセージを復号するために使用されうる。

鍵は、様々な手段を使用してミックスされうる。ＫＭＯは鍵をミックスする方法を説明する。例えば、ＫＭＯは、（Ｋ_ｅＮＢ）_ＰｒＡＳが、Ｗ、Ｘ、Ｙ、Ｚの順でミックスされることになることを説明する。そのような順序では、ＵＥ１００４は、鍵：（Ｋ_ｅＮＢ）_ＰｒＡＳ＝ｆ（Ｗ，Ｘ，Ｙ，Ｚ）を導出する。別の例として、ＫＭＯは、（Ｋ_ｅＮＢ）_ＰｒＡＳが、Ｙ、Ｚ、Ｘ、Ｗの順でミックスされることになることを説明することができる。そのような順序では、ＵＥ１００４は、鍵：（Ｋ_ｅＮＢ）_ＰｒＡＳ＝ｆ（Ｙ，Ｚ，Ｘ，Ｗ）を導出する。

再び図１０Ａを参照すると、新しいＵＥ、例えば、第５のＵＥ１００４ｅが、システム１０００ａにおいてＵＥ１００４のグループに加わる場合、かつ、新しい鍵、例えば、第５の鍵Ｋ_ｅＮＢ５が、第５のＵＥ１００４ｅとｅＮＢ１００２との間で予め確立された（１０３７で）セキュリティアソシエーションに関連付けられた場合、ＰＳＳＦ２０２は、新しい中間鍵、例えば、第５の中間鍵Ｑを導出することができる。従って、新しい鍵に基づいて、新しい中間鍵Ｑが導出されうる。以下で説明されるように、新しい中間鍵Ｑは、グループにおけるＵＥ１００４の間の近傍通信をセキュリティ保護するための新しい共通共有鍵を導出するために、ＵＥ１００４のグループによって使用されうる。ｅＮＢ１００２は、新しい鍵Ｋ_ｅＮＢ５を取得することができる。図示の実施形態に従って、１０３８で、第５のＵＥ１００４ｅは、ｅＮＢ１００２、およびとりわけ、ＰＳＳＦ２０２にグループＩＤを要求する。１０４０で、ｅＮＢ１００２は、第５のＵＥ１００４ｅが、グループの加入者であることを検証する。１０４２で、第５の中間鍵Ｑが、ノンスおよび第５の鍵Ｋ_ｅＮＢ５の関数に等しいように導出されうる。ノンスは、１０１８で生成されたノンスであってよい。あるいは、ノンスは、新しいノンス、例えば、１０４２で生成される第５のノンスであってもよい。１０４４で、ＰＳＳＦ２０２は、第５の中間鍵Ｑを第１のＵＥ１００４ａに送ることができ、Ｑは、Ｗを使用して暗号化されうる。（Ｋ_ｅＮＢ）_ＰｒＡＳを構築するための順序を示す新しいＫＭＯがまた、第１のＵＥ１００４ａに送られうる。同様に、１０４６で、ＰＳＳＦ２０２は、Ｑを第２のＵＥ１００４ｂに送ることができ、Ｑは、Ｘを使用して暗号化されうる。また、（Ｋ_ｅＮＢ）_ＰｒＡＳを構築するための順序を示す新しいＫＭＯが、第２のＵＥ１００４ｂに送られうる。１０５０および１０５２で、ＰＳＳＦ２０２は、第５の中間鍵Ｑを、第３のＵＥ１００４ｃおよび第４のＵＥ１００４ｄに送ることができ、Ｑは、ＹおよびＺでそれぞれ暗号化されうる。１０４８で、ＰＳＳＦ２０２は、ＵＥ１００４のグループに新規である第５のＵＥ１００４ｅに、中間鍵：Ｑによって暗号化されたＷ、Ｘ、Ｙ、Ｚを送る。１０１８からのノンス、およびＫＭＯもまた、１０４８で送られうる。あるいは、１０４２で生成されたノンスが、１０４８で送られてもよい。１０６０、１０６２、１０５８および１０５６で、ＵＥ１００４ａ−ｄはそれぞれ、それらのそれぞれの中間鍵を使用して第５の中間鍵Ｑを復号する。ＵＥ１００４ａ−ｄは、新しい共通共有鍵（Ｋ_ｅＮＢ）_ＰｒＡＳを生成する。１０５４で、第５のＵＥ１００４ｅは、ＰＳＳＦ２０２によって送られた第５の鍵Ｋ_ｅＮＢ５およびノンスを使用して導出されたその中間鍵Ｑを使用して、中間鍵Ｗ、Ｘ、Ｙ、Ｚを復号する。第５のＵＥ１００４ｅは、ＰｒｏＳｅセッション鍵とも呼ばれうる新しい共通鍵（Ｋ_ｅＮＢ）_ＰｒＡＳを生成する。このようにして、新しい中間鍵Ｑは、グループにおけるＵＥ１００４の間の近傍通信をセキュリティ保護するための新しい共通共有鍵（Ｋ_ｅＮＢ）_ＰｒＡＳを導出するために、ＵＥ１００４のグループによって使用され得る。例示的な実施形態において、ＵＥ１００４のうちの１つがグループを去るとき、新しい中間鍵のサブセットが生成され、グループのメンバーとして残るＵＥ１００４の各々に、暗号化されたやり方で送られる。例示的な実施形態において、グループを去ったＵＥ１００４には、新しいキーイング材料は送られない。

図１０Ａを全体的に参照すると、別の実施形態に従って、動的鍵導出が、ＵＥ１００４の各々で実施されうる。そのような実施形態において、ＵＥ１００４は、それらがネットワークカバレッジを有する時の間に互いに同期することができ、その結果、アウトオブカバレッジのときは、鍵が、後で導出される、または生成されることが可能である。ＵＥ１００４のうちの１つは、選出されたマスターであってよく、シーディング材料を提供することができる。シーディング材料のベクトル（ワンタイムパッド（ＯＴＰ）および関連付けられた存続期間）は、ＵＥが互いに同期される間に提供される。例えば、シーディング材料のベクトルは、ノンスのリストまたはランダムな値であってよい。ある事例において、例えば、ＵＥ１００４がセットアップ中のみインカバレッジであり、他の時間はアウトオブカバレッジであるシナリオにおいて、ＵＥ１００４のＵＳＩＭ上で共有された秘密（Ｋｉ）が活用されうる。例えば、グループを開始して共有された秘密でサインインする第１のＵＥが、マスターまたはＣＨになる。共有鍵を受信する他のメンバーは、共有された秘密から鍵を生成する。従って、各グループに関連付けられた鍵階層が存在しうる。

別の実施形態において、アウトオブカバレッジグループは、中央調整エンティティを使用して機能することができる。中央調整エンティティは、クラスタヘッド（ＣＨ）としての役割を果たすＵＥであってよい。ある事例において、中央調整エンティティは、同期のみを提供するＣＨであってよい。他の事例において、中央調整エンティティは、同期およびスケジューリングの両方、並びに、ＰＳＳＦなどのセキュリティ機能、認証局またはＰＫＧ、認証サーバ、アイデンティティプロバイダ（ＩｄＰ）、およびインターグループ信頼プロバイダを提供するためだけに使用される。

複数のユーザが同じグループ鍵を共有している例示的なグループ通信シナリオにおいては、否認防止が問題になることがある。否認防止に対処するために、各ＵＥまたはユーザは、ＵＥに関連付けられた公開／私有鍵を有することができ、その結果、全てのメッセージはまた個々の私有鍵によってデジタル署名される。従って、機密性は、例えば、共通鍵（Ｋ_ｅＮＢ）_ＰｒＡＳから導出された、共有された秘密を用いて提供されうる。完全性およびメッセージ認証は、ＵＥの私有鍵を送ることによりメッセージのハッシュに署名することによって生み出されるデジタル署名を用いて提供されうる。例示的な実施形態に従って、各受信するＵＥ／ユーザは、送信ＵＥのデジタル署名を検証し、（Ｋ_ｅＮＢ）_ＰｒＡＳから導出されたグループ鍵を使用して、メッセージを復号する。従って、例えば、共通鍵（ＫｅＮＢ）_ＰｒＡＳなどのグループ鍵は、メッセージのデジタル署名が検証された後に、グループに属するＵＥのうちの１つによってメッセージを復号するために使用されてよく、デジタル署名は、メッセージの発信者に固有であってよい。従って、メッセージの発信者または送り手は、メッセージが暗号化される前に、識別され、認証されてよく、それにより、送信ＵＥが適切なグループのメンバーであることを保証する。

グループ鍵は、複数のステージにおいて生成されうる。第１のステージは、対象のグループのためのシードと呼ばれ得る初期共有鍵を取得することからなることができる。第２のステージは、鍵リフレッシュ入力に基づいた、リフレッシュまたは再キーイングを含むことができる。鍵リフレッシュアルゴリズムは、調整エンティティによって提供された同期コードを使用して、暗黙的に生成されてよい。鍵リフレッシュ情報は、ＳＦＮ番号、ノンス、時間、グループチャネルｉｄ、インデックスまたは同様の入力を含むことができる。各グループメンバーは、ハッシュまたは指定されたアルゴリズムを実行して、初期共有鍵から現在の鍵を取得することができる。

非同期展開のために使用されうる別の実施形態において、鍵リフレッシュ情報は、ＰＬＭＮまたは異なるＰＬＭＮにおけるセル内に属することができる２つのセルの間の時間オフセットを含むことができる。

鍵リニューアルまたは鍵取り消しについての例示的な実施形態において、共通鍵（ＫｅＮＢ）_ＰｒＡＳは関連付けられた存続期間を有しうる。鍵の存続期間は使用されているアプリケーションに依存しうる。例えば、あるタイプのチャットの存続期間は、ゲームをプレイすることを望む２人のユーザのために使用される鍵の存続時間よりも短いことがある。

ある事例において、既存の鍵は、グループを去るグループのメンバーから取り消される必要がある。図１０Ｂは、新しいＵＥがグループに加わる例示的な実施形態に従った信号フローを示す。図１０Ｂを参照すると、例示的なシステム１０００ｂが、ｅＮＢ１００２と、グループに属する１または複数のＵＥ１００４、例えば、第１のＵＥ１００４ａと、第２のＵＥ１００４ｂと、第３のＵＥ１００４ｃと、第５のＵＥ１００４ｅとを含む。図１０Ａもまた参照すると、システム１０００ａにある第４のＵＥ１００４ｄは、システム１０００ｂにはない。例えば、第４のＵＥ１００４ｄの共通鍵は、ＵＥ１００４ｄがＵＥ１００４のグループを去ったために、取り消されていてよい。１０１６ａで、ＰＳＳＦ２０２は通知を受信する。通知は、第４のＵＥ１００４ｄがグループから移動したことを示すことができる。通知は、第５のＵＥ１００４ｅがグループに加わったことをさらに示すことができる。通知に基づいて、１０１８ａで、新しいノンスが生成され、新しい中間鍵が生成される。その後、共通共有鍵が、図７Ａに関して説明されたように導出される。共通共有鍵は、ＵＥ１００４によって共有されて、それらが互いの間の近傍通信をセキュリティ保護することを可能にする。

制限された発見では、受信側が認可される必要がある。従って、送信側によって使用される共有鍵（例えば、共有された秘密）は、周期的にリフレッシュされる必要があることがある。新しい受信側ＵＥが制限されたＵＥを発見するための認可を要求するとき、新しいＵＥは、送信側によって使用される最終鍵（共有鍵）を生成するための鍵材料として使用され得る、初期鍵および認可コードを提供されてよい。受信側ＵＥは、周期的に認可を再要求する必要があることがあり、認可が要求される度に、受信側ＵＥは、フレッシュな認可コードを与えられてよい。

一実施形態において、悪意のある、または悪意のないリプレーアタックが防止されるように（図４の４０３ａ）、対象のパーティ（ユーザまたはＵＥ）からの過去の通信がフィルタリングされることもまた保証しながら、対象のユーザまたはＵＥアイデンティティのスマートフィルタリングを使用することによって（例えば、図４の４０２ａ参照）ＰｒｏＳｅ発見は実施されうる。フィルタリングは、１または複数の関心グループに基づいていてよい。例えば、一定の関心グループに属しており、かつ受信ＵＥに対する対象ではないことがあるメッセージが、フィルタリングされうる（例えば、図４の４０３ｂ参照）。ある実施形態において、そのようなフィルタリングは、無線アクセスレイヤで、またはより上位のレイヤで実施されうる。アプリケーションによって無線レイヤに提供されるグループアイデンティティが使用されうる。これらのグループアイデンティティは、セキュリティ要件に基づいて、完全性保護されている、かつ／または、暗号化されていることがある。グループアイデンティティが完全性保護されている、または暗号化されている場合、例えば、これらのセキュリティ特徴についての確認は、前もって促進されてよい。例示的なグループアイデンティティが、以下で表１に提供される。

フィルタリングプロセスはさらに、または代わりに、意図的にまたは偶発的にリプレイされていることがあるメッセージを識別することを伴うことができる。リプレイされたメッセージをフィルタリングすることは、アイデンティティの予め構成されたセットを使用して採用されてよく、その場合、互いを発見することを希望する２つのＵＥまたはユーザは、予め構成された持続時間の間、互いを発見するために使用されることになる一時的なアイデンティティのセットを用いて予め構成されてよい。以下で表２に示されるようなアイデンティティテーブルが、発見されることを希望するユーザによって、別のユーザまたはＵＥにプロビジョニングされてよい。

発見されることを望むユーザまたはＵＥは、テーブルを、発見プロセスより前に、１または複数のユーザに提供することができる。例えば、時間の各インターバルの間に、関連付けられたアイデンティティが、ユーザの発見メッセージにおいて使用されうる。アイデンティティテーブルを提供されているユーザは、それを使用して、その時間の期間に関連付けられたアイデンティティを搬送する発見メッセージを探す。リプレーアタックは、同じタイムスロット内でもなお可能であることから、説明されたメカニズムは、リプレーアタックを完全に排除することはできない。しかしながら、タイムスロットは、一層小さくされて（例えば、５分またはそれ未満）、従って、可能であり得る攻撃を最小限にすることができる。スロットは、任意の恣意的な値であってよい。

一実施形態において、１または複数のチャネルスロット、コードまたは同期シーケンスが、アイデンティティを生成するために使用されうる。ユーザは、提供されている彼／彼女のアプリケーションから一時的なアイデンティティを生成し、次いで発見メッセージの送信のために使用される現在のチャネルスロット、コードまたは同期シーケンスのフィンガープリントで、アイデンティティを暗号学的にミックスすることができる。同期シーケンスを検証するための能力は、リプレーアタックを保護する、軽減する、または最小限にするためのメカニズムを提供することができる。

一実施形態において、ユーザまたはＵＥを識別するための識別プロセスは、発見メッセージを送ったユーザのアイデンティティ情報を取得することを含むことができる。プロセスは、例示的な実施形態に従って、認証を伴わないことがある。一実施形態において、発見鍵が複数のステージで生成されうる。第１のステージは、アイデンティティのための初期共有鍵（またはシード）を取得することであってよい。第２のステージは、例えば、本明細書に明記されたような実施形態によって提供される鍵リフレッシュ情報に基づいた、リフレッシングまたは再キーイングを含むことができる。鍵リフレッシュ情報は、調整エンティティ（アウトオブカバレッジ状況の場合、これはＣＨであってよく、一方インカバレッジ状況の場合、これは、ｅＮＢ、ＭＭＥもしくはＰｒｏＳｅ機能などのネットワークエンティティであってよい）によって提供された、またはアプリケーションによって提供された同期コードを使用して、暗黙的に生成されうる。鍵リフレッシュ情報は、ＳＦＮ番号、ノンス、調整された時間（インターセル発見が実施されている場合、セル間の時間オフセットを含む）、グループチャネルｉｄ、インデックス、または同様の入力を含むことができる。各送信側および潜在的な受信側は、ハッシュまたはアルゴリズムを実行して、初期共有鍵プラス鍵リフレッシュ材料から現在の鍵を取得することができる。別の実施形態において、非同期展開の場合、鍵リフレッシュ情報は、２つのセル間の時間オフセットを含むことができる。

図１１Ａを参照すると、ある事例において、ユーザの真のアイデンティティは、プライバシーの理由のために隠されていてもよく、従って、一時的なアイデンティティのみが使用されうる。一時的なアイデンティティは、発見メッセージにおいて送られることになるＩＤである。一時的なアイデンティティは、プライバシー保護のために、かつリプレーアタックを軽減するために、それ自体がハッシュされうる。知られているユーザのみによって発見されることを希望する（制限された発見）送信ユーザ（送り手）は、彼または彼女のアイデンティティを、知られているユーザに前もって提供することができる。ユーザ／ＵＥは、発見目的のために通信されているユーザアイデンティティのリスト１１０２を維持し、記憶することができる。例えば、ユーザによって維持されるアイデンティティのリスト１１０２は、そのアイデンティティがリストされているユーザが、リストを維持する特定のユーザに、発見認可を提供していることを暗示することができる。ユーザが発見メッセージを受信するとき、それは、そのアイデンティティのリスト１１０２を使用することができる。ユーザは、ハッシングアルゴリズム１１０４を通して、アイデンティティのリスト１１０２からアイデンティティの各１つを実行して、アイデンティティのハッシュされた値を計算することができる。なおも図１１Ａを参照すると、１１０６で、アイデンティティの計算されたハッシュされた値が、発見メッセージにおいて受信されたハッシュされたアイデンティティと比較されてよい。一致する場合、ユーザ／ＵＥは、発見メッセージを処理することができる。一致しない場合、ＵＥは、取り出すべきアイデンティティがなくなるまで、または一致するまで、アイデンティティのリスト１１０２から別のアイデンティティを取り出すことができる。

ある事例において、アイデンティティのリスト１１０２は、より頻繁に通信されるユーザ、またはより頻繁に発見されるユーザが、リストの上部へと押し上げられるようにソートされてよく、それにより、一致が迅速に得られる確率を増加させることができる。そのようなソーティングは、ＵＥおよび／またはネットワーク上の負荷を減らすことができる。これはまた、ネットワークへの悪意のない、および悪意のある攻撃を減らすことができる。加えて、または代わりに、リストは、ロケーション、時間、日付などに基づいてソートされてもよい。ある実施形態において、「most frequently visited」アルゴリズムが使用されてもよい。

ＰｒｏＳｅ発見およびアイデンティティ管理の例示的な実施形態において、ビーコンにおけるアイデンティティ情報は、マスクで処理される。例えば、マスクは、スクランブリングシーケンス、多項式ベクトル、ブーリアン関数、任意の適切な鍵導出アルゴリズムなどであってよい。マスクは、ＡｐｐＩｄの関数、アプリケーションユーザＩｄの関数、またはそれらの組合せであってよい。ビーコンは、ＡｐｐＩｄを搬送することができる。例示的な実施形態において、所与のＵＥは、特定のアプリケーションおよび／または関心について、ＰｒｏＳｅサーバに登録する。ＰｒｏＳｅサーバは、例えば、直接、またはｅＮＢ／ＭＭＥを通して、ＡｐｐＩｄ／マスクをＵＥに提供する。ＵＥは、発見ビーコン情報を別のＵＥに送るために、ＡｐｐＩｄを使用してマスクを生成する、または直接取得されたマスクを使用する。あるいは、ビーコンは、意図された受信側の公開鍵で、送り手によって暗号化されてもよく、それを復号するエンティティが、ユーザを識別することができる。別の例として、ビーコンは、（例えば、ＰｒｏＳｅサーバから、またはＡｐｐＩｄから取得された）グループ公開鍵で暗号化されうる。グループ公開鍵／私有鍵は、全てのグループメンバー（例えば、Ｆａｃｅｂｏｏｋのユーザ）のために構成されてよく、発見のために使用されてよい。

発見メッセージの送り手に実際に属する発見メッセージ内で受信されたアイデンティティを検証することは、通信の完全性を保証するのに役立ちうる。メッセージの送り手は、彼または彼女の認証を裏付けることができ、従って、発見メッセージ内でのアイデンティティを裏付けることができる。２人のユーザが、他の誰かではなく、互いによってのみ発見されることを望む場合に、認証は予め共有された鍵に基づくことができる。各ユーザは、互いに対してそれらのアイデンティティを提供することに加え、それらの信憑性を証明するために使用されうる共有された秘密もまた提供することができる。図１１Ｂを参照すると、ＵＥは、アイデンティティおよび共有された秘密のリスト１１０２ａを記憶することができる。従って、アイデンティティおよび共有された秘密は、図１１Ａを参照して説明されたように、ハッシングアルゴリズムに提供されうる。

図１１Ｃを参照すると、ある事例において、認証は、予め共有された鍵を使用して実施され、リプレーアタックに対する保護を提供することができる。発見メッセージを送るユーザは、ハッシュされたＩＤを生成するために、様々なパラメータ１１０８を、そのＩＤおよび共有された秘密（図１１Ｂも参照）と共に使用することができる。例示的なパラメータは、限定はせずに、システム時間、時間またはチャネル特性から導出されたパラメータ、同期シーケンスから導出されたパラメータ（例えば、システムフレーム番号（ＳＦＮ）、サブフレーム番号）、または、別のＵＥによって送られた、もしくは中央調整エンティティ（例えば、ｅＮＢもしくはクラスタヘッド）によって送られた同期情報から導出されたパラメータを含む。送り手のＩＤを発見することを認可されたユーザは、そのリストにおけるユーザアイデンティティの各々を、関連付けられた共有された秘密または同期パラメータ（例えば、ＳＦＮ、時間ベースのパラメータ）と共に使用するハッシングアルゴリズム１１０４実行して、（１１０６で）一致を見つけることができる。一致する場合、１１０６で、ユーザは、発見メッセージがリプレイされなかったこと、かつ送り手が彼または彼女が主張した人であることを、より高い度合いの確実性で確信させられてよい。

ネットワークカバレッジシナリオ、またはインカバレッジシナリオと呼ばれうる、ＵＥがセルラネットワーク内にあるシナリオにおいて、ネットワークは、絶対時間とは異なりうる同期時間で使用されることになる、一時的なアイデンティティを発行することができる。一時的なアイデンティティおよび、「ティック（tick）」と呼ばれうる対応する同期時間は、発見のためにグループメンバーによってその時使用されうる。このハイブリッドなアプローチは、リプレイ保護のために、ネットワークからプッシュされた一時的なアイデンティティのランダム性と、同期されたパラメータ（例えば、時間オフセット、カウント）を使用するための端末の能力とを組み合わせる。加えて、一時的なアイデンティティおよび対応する同期時間（ティック）を搬送する、同じネットワーク発信メッセージはまた、送信側と受信側との両方がフレッシュカウンタを使用するのを可能にする情報を搬送することができる。そのような情報は、時間インクリメントからカウンタインクリメントへの並進因子（translation factor）をセットし、従って、送信側および受信側が、順に時間に固定される共通のカウンタ上で同期されるのを可能にすることができる。例えば、そのような情報は、１つのカウンタインクリメントを５秒時間インクリメントにセットして、カウンタが、送信側および受信側で、５秒ごとに、同期してインクリメントされるのを可能にすることができる。情報は、インカバレッジシナリオにおいて、セキュアなネットワーク発信メッセージによって搬送されるので、ネットワークセキュリティを破ることなく盗聴されることはできず、従って、発見リプレイ保護のために特別なセキュリティを提供することができる。同期ティックは、ＵＥが共有するＰｒｏＳｅアプリケーションによって送られうる。あるいは、同期ティックは、ＵＥによって信頼されたＰＳＳＦ、または単一の信頼できるネットワークに属するＰＳＳＦによって送られうる。

別の実施形態において、例えば、インカバレッジシナリオの場合、ハッシングアルゴリズム１１０４への入力は、ｅＮＢによって送られたパラメータ（例えば、システム時間またはＳＦＮ番号）から導出されうる。さらに別の実施形態において、例えば、アウトオブカバレッジシナリオの場合、ハッシングアルゴリズム１１０４への入力は、ＣＨによって送られたパラメータから導出されうる。一例示的な方法において、ＣＨは、グループにタイミングを提供する同期シーケンスを送ることができる。同期シーケンスはまた、送信および受信機会を導出するために、グループメンバーによって使用されうる。

図１１Ｄを参照すると、認証はデジタル署名に基づきうる。例えば、ＵＥは、一時的なアイデンティティおよび公開鍵のリスト１１０１を記憶することができる。ある事例において、他のユーザによって発見されることを望むユーザは、彼らの公開鍵（証明書の要件なしに行われてよい）を、それらの他のユーザに提供することができる。あるいは、ユーザの代わりに生成された一時的な証明書が、ユーザのアイデンティティおよび通信を受信することを認可されたグループに提供されうる。図１１Ｄを参照すると、図示の実施形態に従って、計算されたハッシュされたＩＤが、発見メッセージにおいて受信されたハッシュされたＩＤとマッチした場合、リスト１１０１からの公開鍵の１つを使用してデジタル署名が計算される。１１１２で、計算されたデジタル署名は、発見メッセージにおけるデジタル署名と比較される。発見メッセージは、送り手の私有鍵によって署名されたデジタル署名を含むことができる。デジタル署名が一致する場合、ユーザは認証され、メッセージは１１１４でさらに処理されうる。署名が一致しない場合、受信ＵＥは、リストがなくなるまで、または一致があるまで、リスト１１０１を調べることができる。

別の実施形態において、アイデンティティは、ユーザの私有鍵で暗号化されて、それを復号する別のユーザが、送り手の公開鍵を使用してユーザを識別することを可能にすることができる。信頼できるエンティティ、ネットワークからの、またはユーザ／ＵＥそれ自体のいずれかからの公開鍵を取得しているユーザのみが、アイデンティティを復号することができることになる。

別の代替的実施形態において、送り手のアイデンティティは、意図された受信側の公開鍵で暗号化されうる。受信側は、彼らの私有鍵を使用して、送り手のアイデンティティを復号することができる。送り手が、送り手のアイデンティティを暗号化し、その私有鍵が復号にマッチしたことを検証することができる他の情報を別々に暗号化するのを選ぶことができることが、本明細書において企図される。送り手は次いで、その一時的なアイデンティティを暗号化し、それを、受信側の公開鍵を使用してまた暗号化される現在の時間と連結することができる。例示的なシナリオに従って、まさに１つの意図された受け手が存在してよい。意図された受け手の公開鍵のリストは、送り手のアイデンティティを暗号化するために使用されてよい。そのようなリストにおいて、暗号化された送り手のアイデンティティは、意図された受け手の公開鍵で暗号化されうる。

さらに別の代替的実施形態において、ノンスは、共有された秘密を生成するために使用されうるユーザの私有鍵で暗号化されうる。あるいは、ビーコンは、（例えば、ＰｒｏＳｅサーバから、またはＡｐｐＩｄから取得された）グループ公開鍵で暗号化されうる。そのようなグループ公開鍵／私有鍵は、全てのグループメンバー（例えば、Ｆａｃｅ−ｂｏｏｋのユーザ）のために構成され、発見のためだけに使用されうる。

グループのユーザは、鍵の初期セットおよびハッシュアルゴリズムで予め構成されて、鍵をリフレッシュすることができる。そのようなアルゴリズムは、例えば、時間を使用することができる。以下で表３に示されるような鍵テーブルが、グループのために認可されたユーザに予めプロビジョニングされてよい。

再び図１１Ｃを参照すると、ハッシュアルゴリズム１１０４への入力として使用されるパラメータ１１０８は、時間、または時間もしくはセル間の時間オフセットから導出されたパラメータ、チャネル状態もしくはチャネル状態の導出されたパラメータ、またはフレーム番号（例えば、ＳＦＮ）、または同期シーケンスもしくはそこから導出されたパラメータを含むことができる。鍵リフレッシュ情報は、ＳＦＮ番号、ノンス、時間、グループチャネルＩＤ、インデックス、または同様の入力を含むことができる。各グループメンバーは、ハッシュまたは他のアルゴリズムを実行して、初期共有鍵プラス鍵リフレッシュ材料から現在の鍵を取得することができる。他の実施形態において、例えば、非同期展開の場合、鍵リフレッシュ情報は、２つのセル間の時間オフセットを含むことができる。

リフレッシュまたは再キーイングは、中央エンティティ（例えば、ｅＮＢ）によって提供された鍵リフレッシュ入力に基づいていてよい。ある事例において、鍵リフレッシュアルゴリズムは、調整エンティティによって提供された同期コードを使用して、暗黙的に生成されうる。鍵リフレッシュ情報は、例えば、ノンス、時間、グループチャネルＩＤ、インデックス、または同様の入力を含むことができる。各グループメンバーは、ハッシュまたは特殊化されたアルゴリズムを実行して、初期共有鍵プラス鍵リフレッシュ材料から現在の鍵を取得することができる。

完全性保護のために、グループチャネル上で送信されたデータは、ＵＥ固有の鍵を使用して生成されたメッセージ認証コードを使用して付加されうる。ＵＥ固有の鍵は、本明細書で論じられたように、ＰｒｏＳｅ一時的なＩＤを使用して生成されてよい。

ＵＥがネットワークカバレッジ内にある間は、インカバレッジメカニズムが使用されてよく、ＵＥがもはやインカバレッジでないときは、アウトオブカバレッジメカニズムが使用されてよい。インカバレッジメカニズムは、ネットワークまたは任意の他の信頼できるエンティティと同期するために使用されてよい。

ＷｉＦｉのためのグループ鍵導出がまた本明細書で企図される。上述された共通鍵（ＫｅＮＢ）_ＰｒＡＳ鍵は、ＵＥによって、マスターセッション鍵（ＭＳＫ）として使用されてよく、その結果、セッション鍵は、８０２．１１標準によって説明されるような４ウェイハンドシェイクメカニズムを使用して生成され得る。鍵は、ＭＳＫのサイズおよび性質に満たすように、暗号学的に適合されてよい。本明細書で説明されるメカニズムは、ＷｉＦｉベースの近傍サービスに適用されてよいことが理解されるであろう。

図１２Ａは、１または複数の開示される実施形態が実施されうる例示的な通信システム５０の図である。通信システム５０は、音声、データ、ビデオ、メッセージング、放送などのコンテンツを複数の無線ユーザに提供する多元接続システムを含むことができる。通信システム５０は、複数の無線ユーザが、無線帯域幅を含むシステムリソースの共用を通して、そのようなコンテンツにアクセスすることを可能にする。例えば、通信システム５０は、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、直交ＦＤＭＡ（ＯＦＤＭＡ）およびシングルキャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）など、１または複数のチャネルアクセス方法を利用することができる。

図１２Ａに示されるように、通信システム５０は、無線送受信ユニット（ＷＴＲＵ）５２ａ、５２ｂ、５２ｃ、５２ｄ、無線アクセスネットワーク（ＲＡＮ）５４、コアネットワーク５６、公衆交換電話網（ＰＳＴＮ）５８、インターネット６０および他のネットワーク６２を含むことができるが、開示される実施形態は、任意の数のＷＴＲＵ、基地局、ネットワークおよび／またはネットワーク要素を企図していることが理解されよう。ＷＴＲＵ５２ａ、５２ｂ、５２ｃ、５２ｄの各々は、無線環境において動作および／または通信するように構成された任意のタイプのデバイスとすることができる。例えば、ＷＴＲＵ５２ａ、５２ｂ、５２ｃ、５２ｄは、無線信号を送信および／または受信するように構成されることができ、ユーザ機器（ＵＥ）、移動局、固定若しくは移動加入者ユニット、ページャ、セルラ電話、携帯情報端末（ＰＤＡ）、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、無線センサおよび家電製品などを含むことができる。

通信システム５０は、基地局６４ａおよび基地局６４ｂも含むことができる。基地局６４ａ、６４ｂの各々は、コアネットワーク５６、インターネット６０および／またはネットワーク６２などの１または複数の通信ネットワークへのアクセスを円滑化するために、ＷＴＲＵ５２ａ、５２ｂ、５２ｃ、５２ｄの少なくとも１つとワイヤレスでインターフェースを取るように構成された、任意のタイプのデバイスとすることができる。例えば、基地局６４ａ、６４ｂは、基地トランシーバ局（ＢＴＳ）、ノードＢ、ｅノードＢ、ホームノードＢ、ホームｅノードＢ、サイトコントローラ、アクセスポイント（ＡＰ）および無線ルータなどとすることができる。基地局６４ａ、６４ｂは各々、単一の要素として示されているが、基地局６４ａ、６４ｂは、任意の数の相互接続された基地局および／またはネットワーク要素を含むことができることが理解されよう。

基地局６４ａは、ＲＡＮ５４の部分とすることができ、ＲＡＮ５４は、他の基地局、および／または基地局コントローラ（ＢＳＣ）、無線ネットワークコントローラ（ＲＮＣ）、中継ノードなどのネットワーク要素（図示されず）も含むことができる。基地局６４ａおよび／または基地局６４ｂは、セル（図示されず）と呼ばれうる特定の地理的領域内で、無線信号を送信および／または受信するように構成されうる。セルは、さらにセルセクタに分割することができる。例えば、基地局６４ａに関連付けられたセルは、３つのセクタに分割することができる。従って、一実施形態では、基地局６４ａは、送受信機を３つ、すなわち、セルのセクタ毎に１つずつ含むことができる。一実施形態では、基地局６４ａは、ＭＩＭＯ技術を利用することができ、従って、セルのセクタ毎に複数の送受信機を利用することができる。

基地局６４ａ、６４ｂは、エアインターフェース６６を介して、ＷＴＲＵ５２ａ、５２ｂ、５２ｃ、５２ｄの１または複数と通信することができ、エアインターフェース６６は、任意の適切な無線通信リンク（例えば、無線周波（ＲＦ）、マイクロ波、赤外線（ＩＲ）、紫外線（ＵＶ）、可視光など）とすることができる。エアインターフェース６６は、任意の適切な無線アクセス技術（ＲＡＴ）を使用して確立することができる。

より具体的には、上述したように、通信システム５０は、多元接続システムとすることができ、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡおよびＳＣ−ＦＤＭＡなどの、１または複数のチャネルアクセス方式を利用できる。例えば、ＲＡＮ５４内の基地局６４ａ並びにＷＴＲＵ５２ａ、５２ｂ、５２ｃは、広帯域ＣＤＭＡ（ＷＣＤＭＡ（登録商標））を使用してエアインターフェース６６を確立しうるユニバーサル移動体通信システム（ＵＭＴＳ）地上無線アクセス（ＵＴＲＡ）などの無線技術を実施することができる。ＷＣＤＭＡは、高速パケットアクセス（ＨＳＰＡ）および／または進化型ＨＳＰＡ（ＨＳＰＡ＋）などの通信プロトコルを含むことができる。ＨＳＰＡは、高速ダウンリンクパケットアクセス（ＨＳＤＰＡ）および／または高速アップリンクパケットアクセス（ＨＳＵＰＡ）を含むことができる。

一実施形態では、基地局６４ａ、並びにＷＴＲＵ５２ａ、５２ｂ、５２ｃは、ＬＴＥ（Long Term Evolution）および／またはＬＴＥアドバンスト（ＬＴＥ−Ａ）を使用してエアインターフェース６６を確立しうる進化型ＵＭＴＳ地上無線アクセス（Ｅ−ＵＴＲＡ）などの無線技術を実施することができる。

他の実施形態では、基地局６４ａ、並びにＷＴＲＵ５２ａ、５２ｂ、５２ｃは、ＩＥＥＥ８０２．１６（すなわち、ＷｉＭＡＸ）、ＣＤＭＡ２０００、ＣＤＭＡ２０００ １Ｘ、ＣＤＭＡ２０００ ＥＶ−ＤＯ、暫定標準２０００（ＩＳ−２０００）、暫定標準９５（ＩＳ−９５）、暫定標準８５６（ＩＳ−８５６）、移動体通信用グローバルシステム（ＧＳＭ（登録商標））、ＧＳＭ進化型高速データレート（ＥＤＧＥ）、およびＧＳＭ ＥＤＧＥ（ＧＥＲＡＮ）などの無線技術を実施することができる。

図１２Ａの基地局６４ｂは、例えば、無線ルータ、ホームノードＢ、ホームｅノードＢ、フェムトセル基地局またはアクセスポイントとすることができ、職場、家庭、乗物およびキャンパスなどの局所的エリアにおける無線接続性を円滑化するために、任意の適切なＲＡＴを利用することができる。一実施形態では、基地局６４ｂおよびＷＴＲＵ５２ｃ、５２ｄは、ＩＥＥＥ８０２．１１などの無線技術を実施して、無線ローカルエリアネットワーク（ＷＬＡＮ）を確立することができる。一実施形態では、基地局６４ｂおよびＷＴＲＵ５２ｃ、５２ｄは、ＩＥＥＥ８０２．１５などの無線技術を実施して、無線パーソナルエリアネットワーク（ＷＰＡＮ）を確立することができる。また一実施形態では、基地局６４ｂおよびＷＴＲＵ５２ｃ、５２ｄは、セルラベースのＲＡＴ（例えば、ＷＣＤＭＡ、ＣＤＭＡ２０００、ＧＳＭ、ＬＴＥ、ＬＴＥ−Ａなど）を利用して、ピコセルまたはフェムトセルを確立することができる。図１２Ａに示されるように、基地局６４ｂは、インターネット６０への直接的な接続を有することができる。従って、基地局６４ｂは、コアネットワーク５６を介して、インターネット６０にアクセスする必要がないことがある。

ＲＡＮ５４は、コアネットワーク５６と通信することができ、コアネットワーク５６は、音声、データ、アプリケーションおよび／またはＶｏＩＰ（Voice over IP）サービスをＷＴＲＵ５２ａ、５２ｂ、５２ｃ、５２ｄの１または複数に提供するように構成された、任意のタイプのネットワークとすることができる。例えば、コアネットワーク５６は、呼制御、請求サービス、モバイル位置情報サービス、プリペイド通話、インターネット接続性、ビデオ配信などを提供することができ、および／またはユーザ認証など、高レベルのセキュリティ機能を実行することができる。図１２Ａには示されていないが、ＲＡＮ５４および／またはコアネットワーク５６は、ＲＡＮ５４と同じＲＡＴまたは異なるＲＡＴを利用する他のＲＡＮと直接的または間接的に通信できることが理解されよう。例えば、Ｅ−ＵＴＲＡ無線技術を利用することができるＲＡＮ５４に接続されるのに加えて、コアネットワーク５６は、ＧＳＭ無線技術を利用する別のＲＡＮ（図示されず）とも通信することができる。

コアネットワーク５６は、ＰＳＴＮ５８、インターネット６０および／または他のネットワーク６２にアクセスするための、ＷＴＲＵ５２ａ、５２ｂ、５２ｃ、５２ｄのためのゲートウェイとしてもサービスすることができる。ＰＳＴＮ５８は、ＰＯＴＳ（plain old telephone service）を提供する回線交換電話網を含むことができる。インターネット６０は、ＴＣＰ／ＩＰインターネットプロトコルスイート内のＴＣＰ、ＵＤＰおよびＩＰなど、共通の通信プロトコルを使用する、相互接続されたコンピュータネットワークとデバイスとからなるグローバルシステムを含みうる。ネットワーク６２は、他のサービスプロバイダによって所有および／または運営される有線または無線通信ネットワークを含むことができる。例えば、ネットワーク６２は、ＲＡＮ５４と同じＲＡＴまたは異なるＲＡＴを利用することができる１または複数のＲＡＮに接続された別のコアネットワークを含むことができる。

通信システム５０内のＷＴＲＵ５２ａ、５２ｂ、５２ｃ、５２ｄのいくつかまたは全ては、マルチモード機能を含むことができ、すなわち、ＷＴＲＵ５２ａ、５２ｂ、５２ｃ、５２ｄは、異なる無線リンクを介して異なる無線ネットワークと通信するための複数の送受信機を含むことができる。例えば、図１２Ａに示されたＷＴＲＵ５２ｃは、セルラベースの無線技術を利用可能な基地局６４ａと通信するように、またＩＥＥＥ８０２無線技術を利用可能な基地局６４ｂと通信するように構成されうる。

図１２Ｂは、例示的なＷＴＲＵ５２のシステム図である。図１２Ｂに示されるように、ＷＴＲＵ５２は、プロセッサ６８、送受信機７０、送受信要素７２、スピーカ／マイクロフォン７４、キーパッド７６、ディスプレイ／タッチパッド７８、非リムーバブルメモリ８０、リムーバブルメモリ８２、電源８４、ＧＰＳチップセット８６および他の周辺機器８８を含むことができる。ＷＴＲＵ５２は、一実施形態との整合性を保ちながら、上記の要素の任意のサブコンビネーションを含むことができることが理解されよう。

プロセッサ６８は、汎用プロセッサ、専用プロセッサ、従来型プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと連携する１または複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、ＡＳＩＣ、ＦＰＧＡ回路、他の任意のタイプの集積回路（ＩＣ）および状態機械などとすることができる。プロセッサ６８は、信号符号化、データ処理、電力制御、入力／出力処理、および／またはＷＴＲＵ５２が無線環境で動作することを可能にする他の任意の機能を実行することができる。プロセッサ６８は、送受信機７０に結合することができ、送受信機７０は、送受信要素７２に結合することができる。図１２Ｂは、プロセッサ６８と送受信機７０を別々のコンポーネントとして示しているが、プロセッサ６８と送受信機７０は、電子パッケージまたはチップ内に一緒に統合できることが理解できよう。プロセッサ６８は、アプリケーション層プログラム（例えば、ブラウザ）および／または無線アクセス層（ＲＡＮ）プログラムおよび／または通信を行うことができる。プロセッサ６８は、例えば、アクセス層および／またはアプリケーション層において、認証、セキュリティ鍵共有、および／または暗号化操作などのセキュリティ操作を行うことができる。

送受信要素７２は、エアインターフェース６６を介して、基地局（例えば基地局６４ａ）に信号を送信し、または基地局から信号を受信するように構成されることができる。例えば、一実施形態では、送受信要素７２は、ＲＦ信号を送信および／または受信するように構成されたアンテナとすることができる。一実施形態では、送受信要素７２は、例えば、ＩＲ、ＵＶ、または可視光信号を送信および／または受信するように構成された放射器／検出器とすることができる。また一実施形態では、送受信要素７２は、ＲＦ信号と光信号の両方を送信および受信するように構成されることができる。送受信要素７２は、無線信号の任意の組み合わせを送信および／または受信するように構成されうることが理解されよう。

また、図１２Ｂでは送受信要素７２が単一の要素として示されているが、ＷＴＲＵ５２は、任意の数の送受信要素７２を含むことができる。より具体的には、ＷＴＲＵ５２は、ＭＩＭＯ技術を利用することができる。従って、一実施形態では、ＷＴＲＵ５２は、エアインターフェース６６を介して無線信号を送信および受信するための２つ以上の送受信要素７２（例えば複数のアンテナ）を含むことができる。

送受信機７０は、送受信要素７２によって送信される信号を変調し、送受信要素７２によって受信された信号を復調するように構成されうる。上述したように、ＷＴＲＵ５２はマルチモード機能を有することができる。従って、送受信機７０は、ＷＴＲＵ５２が、例えばＵＴＲＡおよびＩＥＥＥ８０２．１１などの複数のＲＡＴを介して通信することを可能にするための、複数の送受信機を含むことができる。

ＷＴＲＵ５２のプロセッサ６８は、スピーカ／マイクロフォン７４、キーパッド７６および／またはディスプレイ／タッチパッド７８（例えば、液晶表示（ＬＣＤ）ディスプレイユニット若しくは有機発光ダイオード（ＯＬＥＤ）ディスプレイユニット）に結合され、それらからユーザ入力データを受け取ることができる。プロセッサ６８は、スピーカ／マイクロフォン７４、キーパッド７６および／またはディスプレイ／タッチパッド７８にユーザデータを出力することもできる。また、プロセッサ６８は、非リムーバブルメモリ８０および／またはリムーバブルメモリ８２など、任意のタイプの適切なメモリから情報を入手することができ、それらにデータを記憶することができる。非リムーバブルメモリ８０は、ＲＡＭ、ＲＯＭ、ハードディスクまたは他の任意のタイプのメモリ記憶デバイスを含むことができる。リムーバブルメモリ８２は、加入者識別モジュール（ＳＩＭ）カード、メモリスティックおよびセキュアデジタル（ＳＤ）メモリカードなどを含むことができる。他の実施形態では、プロセッサ６８は、ＷＴＲＵ５２上に物理的に配置されていない、サーバまたはホームコンピュータ（図示されず）上などのメモリから情報を入手ことができ、それらにデータを記憶することができる。

プロセッサ６８は、電源８４から電力を受け取ることができ、ＷＴＲＵ５２内の他のコンポーネントへの電力の分配および／または制御を行うように構成されうる。電源８４は、ＷＴＲＵ５２に給電するための任意の適切なデバイスとすることができる。例えば、電源８４は、１または複数の乾電池（例えば、ニッケル−カドミウム（ＮｉＣｄ）、ニッケル−亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉｏｎ）など）、太陽電池、および燃料電池などを含むことができる。

プロセッサ６８は、ＧＰＳチップセット８６にも結合することができ、ＧＰＳチップセット８６は、ＷＴＲＵ５２の現在位置に関する位置情報（例えば経度および緯度）を提供するように構成されうる。ＧＰＳチップセット８６からの情報に加えて、またはその代わりに、ＷＴＲＵ５２は、基地局（例えば基地局６４ａ、６４ｂ）からエアインターフェース６６を介して位置情報を受け取ることができ、および／または２つ以上の近くの基地局から受信した信号のタイミングに基づいて自らの位置を判定することができる。ＷＴＲＵ５２は、一実施形態との整合性を保ちながら任意の適切な位置判定方法を用いて、位置情報を獲得できることが理解されよう。

プロセッサ６８は、他の周辺機器８８にさらに結合することができ、他の周辺機器８８は、追加的な特徴、機能、および／または有線若しくは無線接続性を提供する、１または複数のソフトウェアモジュールおよび／またはハードウェアモジュールを含むことができる。例えば、周辺機器８８は、加速度計、ｅコンパス、衛星送受信機、（写真またはビデオ用の）デジタルカメラ、ユニバーサルシリアルバス（ＵＳＢ）ポート、バイブレーションデバイス、テレビ送受信機、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）ラジオユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、およびインターネットブラウザなどを含むことができる。

図１２Ｃは、一実施形態によるＲＡＮ５４およびコアネットワーク５６のシステム図である。上述したように、ＲＡＮ５４は、エアインターフェース６６を介してＷＴＲＵ５２ａ、５２ｂ、５２ｃと通信するためにＥ−ＵＴＲＡ無線技術を利用することができる。ＲＡＮ５４は、コアネットワーク５６とも通信可能である。図１２Ｃに示されるように、ＲＡＮ５４は、ノードＢ９０ａ、９０ｂ、９０ｃを含むことができるが、それぞれは、エアインターフェース６６を介してＷＴＲＵ５２ａ、５２ｂ、５２ｃと通信するための１または複数の送受信機を含むことができる。ノードＢ９０ａ、９０ｂ、９０ｃは、ＲＡＮ５４内の特定のセル（不図示）にそれぞれ関連付けられうる。一実施形態と整合しながら、ＲＡＮ５４は、任意の数のノードＢおよびＲＮＣを含むことができることを理解されたい。

図１２Ｃに示されるように、ノードＢ９０ａ、９０ｂは、ＲＮＣ９２ａと通信することができる。また、ノードＢ９０ｃは、ＲＮＣ９２ｂと通信することができる。ノードＢ９０ａ、９０ｂ、９０ｃは、Ｉｕｂインターフェースを介して各ＲＮＣ９２ａ、ＲＮＣ９２ｂと通信することができる。ＲＮＣ９２ａ、ＲＮＣ９２ｂは、Ｉｕｒインターフェースを介して互いに通信することができる。ＲＮＣ９２ａ、ＲＮＣ９２ｂのそれぞれは、接続されるそれぞれのノードＢ９０ａ、９０ｂ、９０ｃを制御するように構成されることができる。また、ＲＮＣ９２ａ、ＲＮＣ９２ｂのそれぞれは、アウターループ電力制御、負荷制御、アドミッション制御、パケットスケジューリング、ハンドオーバ制御、マクロダイバーシティ、セキュリティ機能、データ暗号化などの他の機能を実行し、および／またはサポートすることができる。

図１２Ｃのコアネットワーク５６は、メディアゲートウェイ（ＭＧＷ）９４、モバイル交換センタ（ＭＳＣ）９６、サービングＧＰＲＳサポートノード（ＳＧＳＮ）９８および／またはゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）９９を含むことができる。上記の要素の各々は、コアネットワーク５６の部分として示されているが、これらの要素の任意の要素は、コアネットワーク運営体とは異なる主体によって所有および／または運営できることが理解されよう。

ＲＡＮ５４内のＲＮＣ９２ａは、ＩｕＣＳインターフェースを介してコアネットワーク５６内のＭＳＣ９６に接続されうる。ＭＳＣ９６はＭＧＷ９４に接続されうる。ＭＳＣ９６とＭＧＷ９４は、ＰＳＴＮ５８などの回線交換ネットワークへのアクセスをＷＴＲＵ５２ａ、５２ｂ、５２ｃに提供して、ＷＴＲＵ５２ａ、５２ｂ、５２ｃと従来の陸線通信デバイスの間の通信を円滑化することができる。

ＲＡＮ５４のＲＮＣ９２ａは、ＩｕＰＳインターフェースを介してコアネットワーク５６内のＳＧＳＮ９８にも接続されうる。ＳＧＳＮ９８はＧＧＳＮ９９に接続されうる。ＳＧＳＮ９８とＧＧＳＮ９９は、インターネット６０などのパケット交換ネットワークへのアクセスをＷＴＲＵ５２ａ、５２ｂ、５２ｃに提供して、ＷＴＲＵ５２ａ、５２ｂ、５２ｃとＩＰ対応デバイスの間の通信を円滑化することができる。

上述したように、コアネットワーク５６は、ネットワーク６２にも接続されることができ、ネットワーク６２は、他のサービスプロバイダによって所有および／または運営される他の有線または無線ネットワークを含むことができる。

上記では特徴および要素を特定の組み合わせで説明したが、各特徴または要素は、単独で使用でき、または他の特徴および要素との任意の組み合わせで使用できる。また、本明細書で説明した方法は、例示の目的のためにのみ提供される。本明細書に記載された実施形態は、コンピュータまたはプロセッサによって実行される、コンピュータ可読媒体内に包含された、コンピュータプログラム、ソフトウェアまたはファームウェアで実施することができる。コンピュータ可読媒体の例は、（有線接続または無線接続を介して送信される）電子信号と、コンピュータ可読記憶媒体とを含む。コンピュータ可読記憶媒体の例は、ＲＯＭ、ＲＡＭ、レジスタ、キャッシュメモリ、半導体メモリデバイス、内蔵ハードディスクおよびリムーバブルディスクなどの磁気媒体、光磁気媒体、並びにＣＤ−ＲＯＭディスクおよびＤＶＤなどの光媒体を含むが、それらに限定されない。ソフトウェアと連携するプロセッサは、ＷＴＲＵ、ＵＥ、端末、基地局、ＲＮＣ、または任意のホストコンピュータにおいて使用する無線周波送受信機を実施するために使用することができる。

Claims (21)

1. 第１のユーザ機器（ＵＥ）および第２のＵＥの間の近傍通信をセキュリティ保護するための方法であって、各ＵＥはネットワークエンティティとの予め確立されたセキュリティアソシエーションを有し、前記方法は、
   前記第１のＵＥおよび前記ネットワークエンティティの間の前記予め確立されたセキュリティアソシエーションに関連付けられた第１の鍵を取得することと、
   前記第２のＵＥおよび前記ネットワークエンティティの間の前記予め確立されたセキュリティアソシエーションに関連付けられた第２の鍵を取得することと、
   前記第１のＵＥおよび前記第２のＵＥが近傍通信に参加することを望むことを示す通知を受信することと、
   前記第１の鍵および前記第２の鍵に基づいて、それぞれ前記第１のＵＥおよび前記第２のＵＥによって使用され得る第１の中間鍵および第２の中間鍵を導出して、前記第１のＵＥおよび前記第２のＵＥの間の近傍通信をセキュリティ保護する共通共有鍵を導出することと
   を備える方法。
2. 前記第１の中間鍵を前記第１のＵＥに送信すること、および前記第２の中間鍵を前記第２のＵＥに送信することをさらに備える、請求項１に記載の方法。
3. 前記方法は、ｅＮｏｄｅＢ（ｅＮＢ）またはモバイル管理エンティティ（ＭＭＥ）にある近傍サービスセキュリティ機能によって実行される、請求項１に記載の方法。
4. 前記第１のＵＥおよび前記ネットワークエンティティの間の前記予め確立されたセキュリティアソシエーションは、前記第１のＵＥおよびｅＮｏｄｅＢまたはモバイル管理エンティティ（ＭＭＥ）の間の無線レベルセキュリティアソシエーションである、請求項１に記載の方法。
5. ノンスを生成することと、
   前記ノンスおよび前記第１の鍵の関数を適用して前記第１の中間鍵を導出することと、
   前記ノンスおよび前記第２の鍵の関数を適用して前記第２の中間鍵を導出することと
   をさらに備える、請求項１に記載の方法。
6. 前記第２の中間鍵を前記第１の中間鍵で暗号化し、暗号化された第２の中間鍵をもたらすことと、
   前記ノンスおよび前記暗号化された第２の中間鍵を前記第１のＵＥに送信することと
   をさらに備える、請求項５に記載の方法。
7. 前記第１の中間鍵を前記第２の中間鍵で暗号化し、暗号化された第１の中間鍵をもたらすことと、
   前記ノンスおよび前記暗号化された第１の中間鍵を前記第２のＵＥに送信することと
   をさらに備える、請求項５に記載の方法。
8. 前記第１の中間鍵および前記第２の中間鍵に基づいて、前記共通共有鍵を導出することをさらに備える、請求項１に記載の方法。
9. 前記ネットワークエンティティは、ｅＮｏｄｅＢまたはモバイル管理エンティティ（ＭＭＥ）の少なくとも一つである、請求項１に記載の方法。
10. 前記第１のＵＥおよび前記第２のＵＥが近傍通信に参加することを望むことを示す前記通知は、前記第１のＵＥおよび前記第２のＵＥの一つから受信される、請求項１に記載の方法。
11. 前記第１のＵＥおよび前記第２のＵＥは、前記第１のＵＥおよび前記第２のＵＥに加えて１または複数のＵＥを含むグループに属し、前記共通共有鍵は、前記グループ内で通信するためのグループ鍵である、請求項１に記載の方法。
12. 前記グループ鍵は、メッセージのデジタル署名が検証された後、前記グループに属する前記ＵＥの一つによってメッセージを復号するために使用され、前記デジタル署名は、前記メッセージの発信者に固有である、請求項１１に記載の方法。
13. 前記グループに属する前記ＵＥの一つは、前記グループ内で前記ＵＥのそれぞれによって信頼されるクラスタヘッドであり、前記方法は、前記クラスタヘッドにある近傍サービスセキュリティ機能によって実行される、請求項１１に記載の方法。
14. 新しいＵＥから前記グループに参加する要求を受信することと、
    前記新しいＵＥおよび前記ネットワークエンティティとの間の前記予め確立されたセキュリティアソシエーションに関連付けられた新しい鍵を取得することと、
    前記第１のＵＥおよび前記第２のＵＥが近傍通信に参加することを望むことを示す通知を受信することと、
    前記新しい鍵に基づいて、前記ＵＥのグループによって使用され得る新しい中間鍵を導出して、前記グループ内の前記ＵＥ間の近傍通信をセキュリティ保護する新しい共通共有鍵を導出することと
    をさらに備える、請求項１１に記載の方法。
15. 前記第１のＵＥおよび前記ネットワークエンティティの間の前記予め確立されたセキュリティアソシエーションは、前記第１のＵＥおよび私有鍵生成機関の間のセキュリティアソシエーションである、請求項１に記載の方法。
16. 前記私有鍵生成機関は、前記第１のＵＥにパブリックアイデンティティを供給し、前記パブリックアイデンティティは前記第１の鍵である、請求項１５に記載の方法。
17. 通信ネットワークにおけるネットワークエンティティであって、前記ネットワークエンティティは、第１のユーザ機器（ＵＥ）および第２のＵＥのそれぞれとの予め確立されたセキュリティアソシエーションを有し、前記ネットワークエンティティは、
    実行可能命令を備えるメモリと、
    前記実行可能命令を実行するとき、
    前記第１のＵＥおよび前記ネットワークエンティティの間の前記予め確立されたセキュリティアソシエーションに関連付けられた第１の鍵を取得することと、
    前記第２のＵＥおよび前記ネットワークエンティティの間の前記予め確立されたセキュリティアソシエーションに関連付けられた第２の鍵を取得することと、
    前記第１のＵＥおよび前記第２のＵＥが近傍通信に参加することを望むことを示す通知を受信することと、
    前記第１の鍵および前記第２の鍵に基づいて、それぞれ前記第１のＵＥおよび前記第２のＵＥによって使用され得る第１の中間鍵および第２の中間鍵を導出して、前記第１のＵＥおよび前記第２のＵＥの間の近傍通信をセキュリティ保護する共通共有鍵を導出すること
    を備える動作を実行するプロセッサと
    を備えたネットワークエンティティ。
18. 前記プロセッサは、前記第１の中間鍵を前記第１のＵＥに送信すること、および前記第２の中間鍵を前記第２のＵＥに送信することを備える動作をさらに実行する、請求項１７に記載のネットワークエンティティ。
19. 前記プロセッサは、
    ノンスを生成することと、
    前記ノンスおよび前記第１の鍵の関数を適用して前記第１の中間鍵を導出することと、
    前記ノンスおよび前記第２の鍵の関数を適用して前記第２の中間鍵を導出することと
    を備える動作をさらに実行する、請求項１７に記載のネットワークエンティティ。
20. 前記プロセッサは、
    前記第２の中間鍵を前記第１の中間鍵で暗号化し、暗号化された第２の中間鍵をもたらすことと、
    前記ノンスおよび前記暗号化された第２の中間鍵を前記第１のＵＥに送信することと
    を備える動作をさらに実行する、請求項１９に記載のネットワークエンティティ。
21. 前記プロセッサは、
    前記第１の中間鍵を前記第２の中間鍵で暗号化し、暗号化された第１の中間鍵をもたらすことと、
    前記ノンスおよび前記暗号化された第１の中間鍵を前記第２のＵＥに送信することと
    を備える動作をさらに実行する、請求項１９に記載のネットワークエンティティ。

Images