JP6838789B2

JP6838789B2 - Ｕｅ及びその通信方法

Info

Publication number: JP6838789B2
Application number: JP2015561773A
Authority: JP
Inventors: シャオウェイジャン; アナンドラガワプラサド
Original assignee: NEC Corp
Current assignee: NEC Corp
Priority date: 2013-06-28
Filing date: 2014-06-13
Publication date: 2021-03-03
Anticipated expiration: 2034-06-13
Also published as: US20240314112A1; JP7205598B2; US20160149876A1; US20220029975A1; JP2022008873A; CN105340307A; EP3014913B1; JP7056875B2; EP3014913A1; JP7571780B2; CN108923918A; US20200053066A1; JP2019208218A; CN108923918B; US20200153806A1; EP3576447A1; JP2023040071A; JP6958595B2; US10979408B2; US10574635B2

Description

本発明は、セキュアシステム（secure system）、及び、認証及び承認を行う方法に関し、プロキシミティベースサービス（Proximity based Service (ProSe)）通信における認証及び承認を行う方法に関する。

３ＧＰＰ(3rd Generation Partnership Project)は、商業的及びパブリックセーフティ（public safety）の両方の利用に関するプロキシミティベースサービス（Proximity based Services (ProSe)）の研究を開始した。３ＧＰＰＳＡ１（サービスワーキンググループ）は、セキュア通信、ＵＥ（User Equipment）識別、及び、プライバシー保護に関するいくつかのセキュリティ要件を開始した。

ProSeは、近年の巨大な社会技術動向を象徴する。これらのアプリケーションの原理は、お互いの近接範囲内にある端末で実行するアプリケーションのインスタンスを発見すること、及び、アプリケーション関連データも最終的に交換することである。これと並行して、パブリックセーフティの共同体におけるプロキシミティベースのディスカバリ及び通信に関心がある。

ProSe 通信は、eNB (Evolved Node B)経由又はeNBなしの近接におけるUEに対してサービスを提供できる。ＳＡ１は、ProSeサービスがネットワークカバレッジ内／外のＵＥに提供されることを要求する。ＵＥは、他の近所のＵＥを発見し、又は、他のＵＥにより発見され得る。そして、ＵＥは、お互いに通信できる。いくつかのユースケースは、非特許文献１に記載される。

3GPP TR 22.803 Feasibility study for Proximity Services (ProSe), (Release 12)

しかしながら、プライバシ上の問題だけでなく、直接通信についての認証及び承認に関わるセキュリティ上の問題にもかかわらず、3GPP SA3は、セキュリティ上のソリューションを提供していない。

本発明は、上述したセキュリティ上の問題に関する全体的なセキュリティ上のソリューションを提供した。

一態様において、通信の要求を送信する要求デバイス及び前記要求デバイスから前記要求を受信する受信デバイスによるプロキシミティベースサービス（Proximity based Service (ProSe)）通信における認証及び承認を行う方法が提供され、前記方法は、前記要求及び受信デバイスにおいて一意な鍵Ｋｐからセッション鍵Ｋｐｃ及びＫｐｉを導出し、ProSe通信設定及び前記要求及び受信デバイスの間の直接通信のために前記セッション鍵Ｋｐｃ及びＫｐｉを使用し、前記要求及び受信デバイスとの前記直接通信を開始することを備える。前記鍵Ｋｐｃは、機密性鍵であり、前記鍵Ｋｐｉは整合性保護鍵である。

別の態様において、通信の要求を送信する要求デバイスと、前記要求デバイスから前記要求を受信する受信デバイスと、を備え、複数のユーザ装置（User Equipments (UEs)）及びプロキシミティベースサービス（Proximity based Service (ProSe)）サーバを備えるセキュアシステムが提供される。前記要求及び受信デバイスは、一意な鍵Ｋｐからセッション鍵Ｋｐｃ及びＫｐｉを導出する。前記要求及び受信デバイスは、ProSe通信設定及び前記要求及び受信デバイスの間の直接通信のために前記セッション鍵Ｋｐｃ及びＫｐｉを使用する。前記要求及び受信デバイスは、前記要求及び受信デバイスとの前記直接通信を開始する。前記鍵Ｋｐｃは、機密性鍵であり、前記鍵Ｋｐｉは整合性保護鍵である。

セキュアシステム、及び、セキュア通信を行う方法は、セキュリティ上の問題に関する全体的なセキュリティ上のソリューションを提供できる。

本発明の上記及び他の目的、効果及び特徴は、添付の図面と併せて特定の好ましい実施形態の以下の説明からより明らかになるであろう。
図１Ａは、非特許文献１におけるProSe通信シナリオを示す模式図である。図１Ｂは、非特許文献１におけるProSe通信シナリオを示す模式図である。図２は、本発明の実施形態にかかるセキュア通信を行う方法を提供するシステムの例を示す模式図である。図３は、本発明の実施形態にかかるセキュアシステムを示す模式図である。図４は、本発明の実施形態のセキュア通信を行う方法を説明するシーケンス図である。図５Ａは、一対一セッション（One-to-one session）を示す模式図である。図５Ｂは、一対多セッション（One-to-many session）を示す模式図である。図５Ｃは、多対多セッション（Many-to-many session）を示す模式図である。図６は、本発明の実施形態にかかる一対一通信を示すシーケンス図である。図７は、本発明の実施形態にかかるオプション１の一対多通信を示すシーケンス図である。図８は、本発明の実施形態にかかるオプション２の一対多通信を示すシーケンス図である。図９は、本発明の実施形態にかかる多対多通信を示すシーケンス図である。

ここで、以下の説明の目的のために、用語「上」、「下」、「右」、「左」、「垂直」、「水平」、「上部」、「底」、「側面」、「縦」及びそれらの派生語は、図面に示されるような本発明に関連するものとする。しかしながら、本発明は、明確に反対に指定された場合を除き、様々な代替の変形形態および工程順序をとり得ることが理解される。添付の図面に示され、かつ、以下の明細書に記述された特定の装置及び処理は、単に、本発明の例示的な実施形態であることも理解される。従って、本明細書に開示された実施形態に関連する特定の寸法及び他の物理的特性は、限定的なものと考えられるべきではない。

例示的実施形態において、特に、直接通信、ディスカバリ及び通信を中心としたセキュリティ上のソリューションが説明されることを通じて、そのソリューションは、同様に他の通信に適用され得る。

まず、3GPP TR 21.905“Vocabulary for 3GPP Specifications”に与えられた定義が説明される。

ProSe 直接通信（Direct Communication）:
任意のネットワークノード行き来しない経路を介したE-UTRAN技術を用いるユーザプレーン送信によって、ProSe可能な（ProSe-enabled）近接内の２以上のＵＥの間での通信。

ProSe可能なＵＥ：
ProSe要件及び関連付けられた処理をサポートするＵＥ。特に記載がない限り、ProSe可能なＵＥは、非パブリックセーフティＵＥ（non-public safety UE）及びパブリックセーフティＵＥ（public safety UE）の両方を言及する。

ProSe可能なパブリックセーフティＵＥ（ProSe-enabled Public Safety UE）：
ProSe処理及びパブリックセーフティに特有の機能もサポートするProSe可能なＵＥ。

ProSe可能な非パブリックセーフティＵＥ（ProSe-enabled non-public safety UE）：
ProSe処理をサポートするがパブリックセーフティに特有の機能をサポートしないＵＥ。

ProSe 直接ディスカバリ（ProSe Direct Discovery）：
リリース１２のE-UTRA技術を用いた２つのＵＥの機能のみを使用することにより、その周辺の他のProSe可能なＵＥを発見するために、ProSe可能なＵＥにより採用される処理。

ＥＰＣレベルのProSe ディスカバリ（EPC-level ProSe Discovery）：
ＥＰＣが２つのProSe可能なＵＥの近接性を判定し、それらの近接性を通知することによる処理。

図１Ａ及び１Ｂは、非特許文献１におけるProSe通信シナリオを示す模式図である。ProSe通信に関わるＵＥ１１及びＵＥ１２が同一のｅＮＢ１９により提供され、ネットワークカバレッジが利用可能である場合、システム１００ａは、図１Ａに実線矢印により示されるように、ＵＥ１１、１２、ｅＮＢ１９及びＥＰＣ(Evolved Packet Core)１４（例えば、セッション管理、承認、セキュリティ）の間で交換される制御情報を用いたProSe通信を実行することを決定できる。課金のために、修正が既存のアーキテクチャに関して最小化される。ＵＥ１１及び１２は、図１Ａに破線矢印により示されるように、ProSe通信経路を経由した制御シグナリングを併せて交換できる。

ProSe通信に関わるＵＥ１１及び１２が異なるｅＮＢ１９、２０により提供され、ネットワークカバレッジが利用可能である場合、システム１００ｂは、図１Ｂに実線矢印により示されるように、ＵＥ１１、１２、ｅＮＢ１９及びＥＰＣ１４（例えば、セッション管理、承認、セキュリティ）の間で交換される制御情報を用いたProSe通信を実行することを決定できる。この構成において、ｅＮＢ１９及び２０は、図１ＢにｅＮＢ１９及び２０の間の破線矢印により示されるように、ＥＰＣ１４を介して互いに連携し、又は、無線リソース管理について直接通信できる。課金のために、シグナリングの修正が既存のアーキテクチャに関して最小化される。ＵＥ１１及び１２は、図１ＢにＵＥ１１及び１２の間の破線矢印により示されるように、ProSe通信経路を経由した制御シグナリングを併せて交換できる。

ネットワークカバレッジがＵＥの部分集合について利用可能な場合、１以上のパブリックセーフティＵＥは、ネットワークカバレッジを有さない他のＵＥに関する無線リソース管理制御情報を中継できる。

ネットワークカバレッジが利用可能でない場合、制御経路は、パブリックセーフティＵＥの間で直接的に存在し得る。この構成において、パブリックセーフティＵＥは、ProSe通信を確立及び維持するために、事前に設定された無線リソースを当てにする。あるいは、パブリックセーフティＵＥに属する、パブリックセーフティ無線リソース管理機能（Public Safety Radio Resource Management Function）は、パブリックセーフティProSe通信についての無線リソースの割り当てを管理できる。

図２は、本発明の実施形態にかかるセキュア通信を行う方法を提供するシステムの例を示す模式図である。図２に示すように、システム１０は、ＵＥ１１、ＵＥ１２、E-UTRAN１３、ＥＰＣ１４、ProSe機能１５、ProSeアプリケーションサーバ１６、ProSeアプリケーション１７、及びProSeアプリケーション１８を備える。

ＵＥ１１及びＵＥ１２は、ＰＣ５を介して通信可能であり、ＵＥ１１及びE-UTRAN１３は、LTE-Uu1を介して通信し、ＵＥ１２は、LTE-Uu2及びＰＣ３のそれぞれを介してE-UTRAN１３及びProSe機能１５と通信可能である。ＥＰＣ１４及びProSe機能１５は、ＰＣ４を介して通信可能であり、ProSeアプリケーションサーバ１６は、SG1及びＰＣ１のそれぞれを介してEPC１４及びProSeアプリケーション１８と通信可能であり、ProSe機能１５は、ＰＣ６を介して自身により通信可能である。

上記のように、既存の鍵は、インフラを用いる時に、すなわちeNodeBを介して使用され得る。しかしながら、新たなソリューションがデバイス間の直接ディスカバリに関して必要とされる。例えば、鍵はネットワークから通信相手へ送信され、鍵は通信相手の間で生成され、又は、ネゴシエーションに関する同様のアルゴリズムは直接又はネットワークを経由して使用され得る。さらに、新たなソリューションは、無認可スペクトル上のセキュリティに関しても必要とされる。

ProSe直接通信一対一についての２つの異なるモードが以下にサポートされる。
ネットワーク独立直接通信（Network independent direct communication）：このProSe直接通信に関する動作モードは、ＵＥへの機能及び地域情報のみを用いることにより実行される、接続及び通信を承認するための任意のネットワーク支援を要求しない。このモードは、ＵＥがE-UTRANにより提供されるか否かにかかわらず、事前に承認されたProSe可能なパブリックセーフティＵＥへのみ適用可能である。

ネットワーク承認直接通信（Network authorized direct communication）：このProSe直接通信に関する動作モードは、ネットワーク支援を常に要求し、唯一のＵＥがパブリックセーフティＵＥについて「E-UTRANにより提供され」る場合にも適用可能である。非パブリックセーフティＵＥについて、ＵＥの双方が「E-UTRANにより提供され」なければならない。

ＰＣ１：
ＵＳ１２内のProSeアプリケーション１８とProSeアプリケーションサーバ１６との間の参照地点である。アプリケーションレベルの要求を定義するために用いられる。

ＰＣ２：
ProSeアプリケーションサーバ１６とProSe機能１５との間の参照地点である。ProSeアプリケーションサーバ１６とProSe機能１５を介した３ＧＰＰＥＰＳにより提供されるProSe機能との間の相互関係を定義するために用いられる。その使用の一例は、ProSe機能１５内のProSeデータベースに関するアプリケーションデータの更新のためであってもよい。その使用の別の例は、３ＧＰＰ機能及びアプリケーションデータの間の相互作用、例えば、名前の変換におけるProSeアプリケーションサーバ１６が使用するためのデータであってもよい。

ＰＣ３：
ＵＥ１２とProSe機能１５との間の参照地点である。ＵＥ１２とProSe機能１５との間の相互関係を定義するために用いられる。その使用の一例は、ProSeディスカバリ及び通信に関する構成のためのものである。

ＰＣ４：
ＥＰＣ１４とProSe機能１５との間の参照地点である。ＥＰＣ１４とProSe機能１５との間の相互関係を定義するために用いられる。その可能なユースケースは、UE間の一対一通信経路を設定する場合、又は、リアルタイムにおけるセッション管理又はモビリティ管理のためのProSeサービス（承認）を検証する場合、であるとよい。

ＰＣ５：
（ＵＥ間の直接的な、及び、ＬＴＥ−Ｕｕ上でのＵＥ間の）中継及び一対一通信のために、ディスカバリ及び通信に関する制御及びユーザプレーンのために使用されるＵＥ１１とＵＥ１２との間の参照地点である。

ＰＣ６：
この参照地点は、異なるＰＬＭＮに加入したユーザ間のProSeディスカバリのような機能のために使用される。

ＳＧｉ:
ＳＧｉを経由したTS 29.061 [10]に定義された関連機能に加えて、アプリケーションデータ及びアプリケーションレベル制御情報交換について使用される。

図３は、本発明の実施形態にかかるセキュアシステムを示す模式図である。図３に示されるように、本発明の実施形態にかかるセキュアシステム１は、１以上の要求ＵＥ＿Ｌ０１、オペレータネットワーク＿Ｌ０２、及び受信ＵＥ＿Ｌ０３を備える。セキュア通信を実行する方法は、オペレータネットワーク＿Ｌ０２との相互作用を用いて又は用いないで、ＵＥの間（要求ＵＥ＿Ｌ０１、受信ＵＥ＿Ｌ０３）で実行される、セキュアグループ管理Ｌ１、セキュアディスカバリＬ２、初期承認Ｌ３、認証Ｌ４、承認Ｌ５、セキュリティ接続確立Ｌ６、セキュア通信Ｌ７、及びターミネーション（termination）Ｌ８を含む。

ネットワークカバレッジがＵＥのために利用可能であると仮定すると、ブロードキャスティングは、本実施形態の例として示される。しかし、本実施形態は、マルチキャスティング、及び、図１Ａ, １Ｂ及び２に示されるような一対一通信にも適用する。

通信終了までのグループの設定から、セキュリティは後述のように各ステップに必要とされる。尚、ステップＬ１‐Ｌ４は、サービス又はアプリケーションに依存して異なる順序で有り得る。

Ｌ１:セキュアグループ管理
メンバーは安全に参加することができ、メンバーは安全に離れることができ、サービス及び各メンバーの承認レベル、任意の他の要求される情報は安全に修正できる。

Ｌ２：セキュアディスカバリが発生するならば
ディスカバリが保証されない場合、マスカレード攻撃が順番に詐欺的な課金に導くことが発生し得るという結果によって、デバイスは誤った相手又は不正なデバイスとの通信を開始するだろう。この目的のために、通信に関連するディスカバリは保証されなければならない。すなわち、ＵＥは、近接する他のＵＥの同一性を認証する。ディスカバリとデバイスの整合性の保護は、メッセージを認証できるべきである。

Ｌ３：初期承認
セキュアディスカバリに基づく初期承認は、ディカバーされたデバイスがグループに属するという決定につながる。従って、次のステップが開始できる。

Ｌ４：認証
一旦、デバイスがグループの一部として発見され、承認されると、相互認証が存在すべきであり、さもなければ、未だに攻撃の範囲が存在する。

Ｌ５：承認
次のレベルの承認は、サービスが同じグループに属するデバイス間で使用され得ることを見出す。例えば、ＵＥは、異なるメッセージの型を送受信することが許可され、ブロードキャスティングメッセージを受信することのみが許可される。

Ｌ６：セキュリティ接続確立（鍵導出及び管理）
同じグループに属するＵＥは、そのグループ又は攻撃者に属していない他のＵＥがメッセージを盗聴、又は、改ざんできないように、それらの通信を保護するための鍵を有すべきである。

Ｌ７：セキュア通信
同じグループ内のＵＥ間の通信は、加入サービス型に応じた整合性及び／又は機密性を用いて、セキュリティ接続（security association）により保護され得る。

Ｌ８：ターミネーション（Termination）
セキュアターミネーションは、ＵＥが通信を停止又は終了する場合、又は、グループ全体の通信が終了した場合に、セキュリティを提供できる。

セキュリティ要件を満たす本発明の実施形態におけるセキュア通信を実行する詳細な方法は、以下のセクションで説明される。図４は、本発明の実施形態にかかるＵＥ１００とネットワーク２００との間のセキュア通信を行う方法を説明するシーケンス図である。

［１］グループ設定及び管理（Ｌ１）
グループとは、
（１）互いに通信する２つのデバイス（一対一）、又は、
（２）１のＵＥが他のデバイスと通信できる２以上のデバイス（一対多）
（３）互いに通信できる２以上のデバイス（多対多）
が可能である。

グループは、異なる通信目的に設定することができ、グループメンバーは変更され得る。グループを形成するために、オペレータネットワーク＿Ｌ０２は、通信をしたい受信ＵＥ＿Ｌ０３を要求する要求ＵＥ＿Ｌ０１を調べ、それらは互いに通信できる場合にデバイスを検証し、要求及び形成の両側（要求ＵＥ＿Ｌ０１及び受信ＵＥ＿Ｌ０３）において、検証されたデバイスを通知できる。

以下に、グループを生成する一例が説明される。図４に示されるように、ＵＥ１００は、ネットワーク２００へProSe加入者を要求し、グループを生成する（ステップ１）。ステップ１において、ＵＥ１００は、条件、すなわち、ポリシー、例えば、興味、特定の位置等が合致する必要がある。また、ネットワーク２００は、ＵＥが条件、すなわち、ポリシー、例えば、近接範囲、加入者、ローミングＵＥの場合のホームネットワーク、ＷｉＦｉか否か、ProSe可能等を満たすか否かを検証する必要がある。グループは厳密に形成され、例えば、グループのメンバーはホワイトリストに登録され、又は、グループは、ＵＥ１００からの要求において、又は、ネットワーク２００が全てのＵＥの条件を認識する場合にはネットワーク２００により、動的に形成される。

セキュアグループを生成するために、ＵＥ１００はグループの一部であることに同意しなければならず、「同意された」ＵＥ１００のみがグループメンバーになる。グループ管理は、グループメンバーの追加、グループメンバーの削除、グループの終了、及び、グループメンバーの一時的な追加を含む。各ＵＥ１００は、例えばソーシャルネットワークアプリケーションから誰が近くにいるかを理解し、ProSeサービスについて要求する。ProSeサーバは承認を実行する必要があるが、ディスカバリを実行する必要はない。

［２］ディスカバリ − 近接内のＵＥのセキュアディテクション（Ｌ２）
［１］のディスカバリ及びグループ生成は、同時に発生し、又は、独立した手順である。ＵＥ（要求ＵＥ＿Ｌ０１）は近接内の他のＵＥ（受信ＵＥ＿Ｌ０３）を発見できるという次の３つの手段が存在する。（１）ブロードキャストベース、（２）ネットワークベース、及び（３）デバイスサービスレベル情報ベース。セキュアディスカバリがどのように行なわれるかが次のように説明される。

［２−１］ブロードキャストベースのソリューション
ブロードキャストベースのソリューション内に６つの方法（ｓ１−ｓ６）が存在する。

（ｓ１）トークン
ブロードキャストメッセージは、所与のＵＥのみが有することができるトークンを含むことができる。トークンは受信側がそれを再利用することを防ぐために一度だけ使用されるべきである。そこに到着するために、ＵＥは、ブロードキャストメッセージを受信する度にトークンを計算でき、又は、ネットワークは、次に使用されるためのトークンのＵＥ全てに通知できる。トークンは受信側により再利用され得るため、このことは、サービスの情報通知の種類としてそのようなユースケースのために使用され得る。

（ｓ２）署名メッセージ（Signing message）
ブロードキャストメッセージは、受信ＵＥ、又は、受信ＵＥへのネットワークのいずれかにより検証される鍵により署名され得る。署名は、異なる鍵管理ソリューションにより生じ、又は、インフラネットワーク−新しい鍵の階層は、ここに必要とされる−との通信（又は現在の鍵からの導出）のために現在の鍵を用いて生じ得る。

（ｓ３）メッセージＩＤ
ブロードキャストメッセージは、認証の間に検証され、承認のためにのみ最初に使用されるＩＤを有することができる。

（ｓ４）ランダム値
ブロードキャストメッセージは、ネットワーク及びＵＥにより生成されるだけのランダム値を含むことができる。ランダム値の検証は、通信するＵＥの代わりにネットワークにより行なわれる。

（ｓ５）鍵
各ＵＥは、他のデバイスに属する特定の鍵を有する。それ故、潜在的に長いブロードキャスト、又は、グループ内の各ＵＥごとに暗号化され／整合性が保護された部品がばらばらに送信される新しいタイプのブロードキャストを送信する。

（ｓ６）スタンプ
ブロードキャストメッセージは、タイムスタンプ及びライフタイムで署名され得る。尚、ライフタイムは、非常に短い期間であるか、次のブロードキャストまで存続させることができる。

［２−２］ネットワークベースのソリューション
この目的のために、ネットワークは、ＵＥ（要求ＵＥ＿Ｌ０１）から受信した位置情報を使用でき、位置情報は、既存のネットワークセキュリティメカニズムにより保護され得る。

［２−３］デバイスサービスレベル情報ベースのソリューション
要求ＵＥ＿Ｌ０１は、ソーシャルネットワーク又は他のサービスにより提供される位置情報を使用できる。セキュリティは、アプリケーション層で保証される。

ディスカバリの詳細な例が説明される。ＵＥ１００は、Ｄ２Ｄ（デバイス間通信）サーバ内でディスカバリ／ディスカバリ可能な特徴及び／又は機能を設定できる。
ケース１Ａ：
ＵＥ１００は、他のＵＥが近接に存在するか否かを認識しない場合、ProSeサービスについてProSeサーバに要求できる。そして、ProSeサーバは、ProSeサービスについての要求を発信し、それと同時に、他のＵＥの位置情報を取得できる。
ケース２Ａ：
ＵＥ１００は、誰が、例えばソーシャルネットワークアプリケーションから近接に存在し、サービスについて問い合わせるかを把握できる場合、ProSeサーバは、承認を実行する必要があるが、ディスカバリを実行する必要はない。

ProSeサーバが承認を実行する場合、ＵＥ１００は、ProSe及び／又はＵＥ１００が所与のサービス／通信手段を取得するために許可されることを可能にする。

ディスカバリがＵＥ１００の近接性に基づいて行なわれる場合、ＵＥ１００は、ユニキャストセキュリティコンテクストにより周期的に保護される位置情報を送信する。ネットワーク２００は、必要とされる場合又は周期的に、位置情報を要求する。要求（ステップ３）はブロードキャストされ、ブロードキャストされたメッセージはセキュリティを要求する。応答（ステップ４）は、ユニキャストセキュリティコンテクストにより保護され得る。

ネットワークは、要求及び受信ＵＥによっても与えられる、近接性についての状況を保存する。ネットワーク２００は、ディスカバーされることが許可される、近隣の受信ＵＥへブロードキャストできる。そして、ＵＥは保護されたメッセージに応答する。ＵＥ１００は、最初の通信及び／又は登録において、又は、任意の変化が発生する場合に、その状況及び機能をネットワーク２００に通知する。

ネットワーク２００又はＵＥ１００によるブロードキャストベースのソリューションは、１以上の次の要件を必要とする。すなわち、受信側は、ソースを検証できるべきであり、ブロードキャストメッセージは、再利用されるべきでなく、応答を受信するネットワーク２００は、それを検証できるべき、又は、応答は、あまりにも長い場合には破棄されるべきである。ＵＥ１００は、セキュアディスカバリを実行するために１以上のソリューションを使用できる。ソリューションは、トークン、署名、メッセージ、メッセージＩＤ、ランダム値、鍵、及びスタンプを含む。尚、それらのソリューションは、図４に示されるような、ステップ５（相互認証する、認証Ｌ４）、ステップ６（承認する、承認Ｌ５）、及び、ステップ７（鍵の生成及びアルゴリズムのネゴシエート、セキュア通信Ｌ７）において、使用され得る。ステップ５から７は、共に発生してよく、セキュリティをブロードキャストするために関連する可能性もある。

［３］初期承認（Ｌ３）
初期承認は、上記ディスカバリソリューションに応じて変化する。

［３−１］ブロードキャストベース：
要求ＵＥ＿Ｌ０１が受信ＵＥ＿Ｌ０３と通信することが許可されるか否かは、ネットワークにより、又は、ネットワークにより提供される証拠を有する受信ＵＥ＿Ｌ０３により検査され得る。

［３−２］ネットワークベース：
要求ＵＥ＿Ｌ０１及び受信ＵＥ＿Ｌ０３は、直接無線インタフェース上で相互認証を実行できる。

［３−３］デバイスサービスレベル情報ベース：
受信ＵＥ＿Ｌ０３は、ユーザにより、又は、ProSeサービスの目的で、デバイスグループのメンバーの間のＵＥの中で、維持されるリストを検査する。

［４］認証（Ｌ４）
一旦、要求ＵＥ＿Ｌ０１が同じグループに属するとして識別されると、認証が行なわれる。認証は、局所的に、又は、ネットワークとの相互作用により、実行され得る。

［４−１]要求ＵＥ＿Ｌ０１の認証：
このことは、ネットワークにより要求ＵＥ＿Ｌ０１、又は、ネットワークからの証明を有するＵＥの成功識別により実行され得る。

［４−２]受信ＵＥ＿Ｌ０３の認証：
このことは、以下により実行され得る
［４−２−ｉ] 要求ＵＥ＿Ｌ０１及び受信ＵＥ＿Ｌ０３の間で共有される鍵を用いること
［４−２−ｉｉ]現在のネットワークセキュリティ鍵又は新たな鍵を用いること
［４−２−ｉｉｉ]受信ＵＥ＿Ｌ０３からの入力認証要求を要求ＵＥ＿Ｌ０１に通知するネットワーク。

［５］承認−サービスアクセス制御（Ｌ５）
要求ＵＥ＿Ｌ０１及び受信ＵＥ＿Ｌ０３（以下、「ＵＥ」としても参照される）がグループ内で使用できるサービスへのアクセス制御についての異なるレベルが存在する。
［５−１］ＵＥはブロードキャストメッセージを受信及び／又は送信することが許可される。
［５−２］ＵＥは複数メッセージを受信及び／又は送信することが許可される。
［５−３］ＵＥは一対一通信に関するメッセージを受信及び／又は送信することが許可される。
［５−４］加入者情報に応じたＵＥ承認、及び、ProSeサービスに関するポリシーUE集合

ネットワークは、ＵＥ機能及びユーザ契約に応じた要求ＵＥ＿Ｌ０１及び受信ＵＥ＿Ｌ０３を含むグループメンバーへのポリシーを設定及び提供できる。

ネットワーク２００は、グループへの参加を希望するＵＥ１００について承認を行う。ＵＥ１００のグループメンバーは、セッション鍵を用いることにより、他のＵＥがネットワークにより承認されるか否かを検証する。検証された承認を行う別の方法は、（１）各ＵＥ１００へ承認値を送信するネットワークにより行なわれ、各ＵＥ１００がお互いに承認を実行するためにこの値を使用する、又は、（２）まだ、検証された承認を行う別の方法は、要求ＵＥから受信ＵＥへ承認値を送信することにより行なわれ、受信ＵＥはこの承認値及び受信結果を検証するためにネットワークに要求する。

［６］新たな鍵階層及び鍵管理（Ｌ６）
新たな鍵階層が本発明の実施形態に示される。鍵Kp は、グループに関連する鍵であり、ProSeサービスにも関連してもよい。それに関連するインジケータKSI_p を有する。Kp は、使用のためにProSeサーバから送信され得る。

鍵、Kpc及びKpiは、ＵＥにおけるKpから導かれるセッション鍵である。Kpc は機密性鍵であり、Kpiは整合性保護鍵である。セッション鍵は、ＵＥがお互いの承認及びProSe通信設定を実行するために使用され、それらの間の直接通信を有する。

承認及び認証の後、要求ＵＥ＿Ｌ０１及び受信ＵＥ＿Ｌ０３を含む通信デバイスは、お互いに通信するためのセッションを開始できる。要求ＵＥ＿Ｌ０１及び受信ＵＥ＿Ｌ０３がお互いに通信する場合、それらは通信鍵を共有する。鍵は、グループ鍵、及び／又は、各セッションごとのセッション鍵と同様に、通信デバイスごとに一意な鍵であるとよい。

鍵は、ネットワークにより管理され、ネットワークとのセキュア通信チャネルを介して送信され得る。あるいは、鍵は、要求ＵＥ＿Ｌ０１により管理され、認証又は検証の間にネットワークにより保証され得るセキュアユニキャスト通信チャネルを介して、通信内の受信ＵＥ＿Ｌ０３を含む他のデバイスへ送信され得る。鍵は、信頼されたサードパーティによっても発行され得る。

ＵＥ１００は、セッションの開始時にお互いに認証する（Ｓ５）。認証は、承認とリンクされる（Ｓ６）。図５Ａから５Ｃは、それぞれ、一対一、一対多、多対多セッションを示す模式図である。図５Ａから５Ｃに示されるように、ＵＥａ２１及びＵＥａ３１は要求ＵＥ＿Ｌ０１を示し、ＵＥｂ２２、ＵＥｂ３２、ＵＥｂ３３及びＵＥｂ３３ｎは受信ＵＥ＿Ｌ０３を示す。

セッションが開始される場合、最初に、セッション鍵が生成される。本実施形態において、要求ＵＥ＿Ｌ０１（ＵＥａ２１、ＵＥａ３１）及び受信ＵＥ＿Ｌ０３（ＵＥｂ２２、ＵＥｂ３２、ＵＥｃ３３、ＵＥｎ３３ｎ）は、セッション鍵を含む２種類の鍵を使用する。
ケース１Ｂ：
各グループは、各サービスに関する鍵Ｋｐ(Ｋｐはサービス鍵として提供される)を有し、新たなセッション鍵は各セッションに対して生成される。
ケース２Ｂ：
各グループは、鍵Ｋｐ（Ｋｐはグループ鍵として提供される）を有し、新たなセッション鍵は各セッションに対して生成される。

各ケースにおいて、ProSeサーバ又は要求ＵＥ＿Ｌ０１のいずれかは、鍵を送信する。例えば、ProSeサーバは、要求ＵＥ＿Ｌ０１及び受信ＵＥ(群)Ｌ０３へ鍵Ｋｐを送信し、要求ＵＥ＿Ｌ０１は、セッションごとに受信ＵＥ＿Ｌ０３(群)へセッション鍵を送信する。あるいは、 ProSeサーバは、鍵Ｋｐ及びセッション鍵の両方を要求ＵＥ＿Ｌ０１及び受信ＵＥ（群）Ｌ０３へ送信し、又は、要求ＵＥ＿Ｌ０１は、鍵Ｋｐ及びセッション鍵の両方を受信ＵＥ（群）Ｌ０３へ送信する。

さらに、誰かが離れ又は追加されるか否かをグループが変更する場合、セッションが終了し、もしくは、鍵がタイムアウトする場合、又は、ProSeサーバが決定した場合、例えば、鍵Ｋｐ及び／又はセッション鍵が変更されるべきである。

ProSeサーバが鍵ＫｐをＵＥに割り当てる場合、ＵＥは承認及び通信に関する鍵からセッション鍵を導き出す。ＵＥは、鍵導出についてのアルゴリズムを事前に設定される、又は、鍵ＫｐはＫＳＩ（鍵設定識別子（key set identifier））及びサービスに関連する。それらの理由で、ＵＥの認証及び承認中のセキュリティ問題、又は、直接通信に関する鍵のセキュリティ問題は、解決され得る。

尚、鍵設定識別子（ＫＳＩ）は、認証中に導出される暗号及び整合性鍵に関連付けられる番号である。鍵設定識別子は、ネットワークにより割り当てられ、計算された暗号鍵ＣＫ及び整合性鍵ＩＫと共に保存される移動局への認証要求メッセージで送信され得る。鍵設定識別子の目的は、ネットワークが、認証処理を呼び出すことなしに移動局に保存される暗号鍵ＣＫ及び整合性鍵ＩＫを識別することを可能にすることである。このことは、その後の接続（セッション）の間に暗号鍵ＣＫ及び整合性鍵ＩＫの再利用を許可するために使用される。

［７］セキュア通信（Ｌ７）
セキュア通信は、メッセージがグループに属さないＵＥにより盗聴され、又は、改ざんされることから防ぐのと同様に、グループメンバーＵＥの間のメッセージ送信の可用性を提供できる。また、セキュア通信は、ＵＥが承認されないサービスを利用することを防ぐことができる。

グループ内の通信は、整合性及び／又は信頼性保護を有すべきである。通信の全ては、セキュリティ接続が確立される後に、上述したセッション鍵により保護され得る。

セキュリティポリシは、オペレータネットワーク＿Ｌ０２の支援を有し又はなしにグループ内のネゴシエーション及び同意であり得る。グループメンバーの全ては、セキュリティポリシに従うべきである。

次に、ＵＥの位置の変化が発生した場合のセキュリティが説明される。ＵＥのいずれもが位置変更を有さない場合、セキュリティ問題は存在しない。さらに、ＵＥの全てが変更された位置を有さないが、お互いに近接に留まる場合、未だにセキュリティ問題は存在しない。

ＵＥの一部（１以上のＵＥ）が他のＵＥから近接の外に移動しており、ProSeサービスを利用しない場合、グループ及びセキュリティ管理は、グループ内でＵＥを残すために更新される必要がある。あるいは、１以上のＵＥがＵＥから近接の外に移動しており、お互いにProSeサービスを維持したい場合、グループ及びセキュリティ管理は、グループ内でＵＥを残すために更新される必要があり、新しいグループ及びセキュリティは、トラベラー（traveler）のために必要とされる。

尚、ProSeサーバは、全ＵＥの位置の違いを比較及び計算するために、周期的に、ＧＭＬＣ(Gateway Mobile Location Center)からＵＥ位置情報を取得すべきである。

［８］ターミネーション（Ｌ８）
通信が中断される場合、デバイスは、認証及び承認の情報を維持する間にセッション鍵を削除すべきである。

通信が終了（terminate）する場合、デバイスは、履歴情報、又は、再び、認証及び承認についてのシグナリングを防ぐための次の利用時間に関するライフタイムを有する割り当てられたトークンを保持できる。

インフラから直接モードへの滑らかなハンドオーバは、ハンドオーバが発生する前の通信パーティ（要求ＵＥ＿Ｌ０１及び受信ＵＥ＿Ｌ０３）の間の鍵の生成を要求するだろう。例えば、通信パーティがＷｉＦｉを使用している場合、鍵は、ＷｉＦｉＡＰ及びＵＥに割り当てられるべきである。ＷｉＦｉＡＰ及びＵＥは、お互いに承認及び認証するべきである。鍵は、限定されたライフタイムを有するべきである。ネットワークは、ＵＥがどちらのＷｉＦｉＡＰと通信できるかを認識できる。ＵＥは、ＷｉＦｉＡＰが存在し、ネットワークがＷｉＦｉＡＰを検証することを見出すことができる。ＵＥがＷｉＦｉＡＰと接続する場合、ＵＥはProSeサーバを認証する。１つのオプションは、ProSe機能がProSeアプリケーションサーバと通信するためのUEに鍵を割り当てられるということである。

上記説明を要約すると、本実施の形態にかかるセキュア通信を行う方法は以下の特徴を備える：
（１）オペレータネットワーク＿Ｌ０２は、要求ＵＥ＿Ｌ０１が要求ＵＥ＿Ｌ０１により要求された受信ＵＥ＿Ｌ０３と通信できるか否かを判定する。
（２）近接内のＵＥのディスカバリにおけるセキュリティは、ネットワークにより提供されたトークン、鍵、及び署名を使用することにより提供され得る。
（３）近接内のＵＥのディスカバリのセキュリティは、オペレータネットワーク＿Ｌ０２により提供される位置を使用することにより提供され得る。
（４）近接内のＵＥのディスカバリのセキュリティは、アプリケーション層内で提供されるセキュリティを有し、ソーシャルネットワークサービスにより提供される位置情報を使用することにより提供され得る
（５）デバイスの承認は、ネットワークにより、又は、デバイス直接検証により実行され得る。
（６）要求ＵＥ＿Ｌ０１及びグループ内に存在することを同意する受信ＵＥ＿Ｌ０３の間の相互認証は、ネットワークにより実行され、また、両方のＵＥには結果が通知され得る。
（７）要求ＵＥ＿Ｌ０１及び受信ＵＥ＿Ｌ０３の間の相互認証は、それらの間で共有される鍵で両端により実行され得る。
（８）グループ鍵及び一意なセッション鍵であり、ProSe通信を保証するための新たな鍵が使用され得る。
（９）セキュア通信のためのグループ内のセキュリティポリシーはネゴシエートされ、設定される。
（１０）ターミネーション管理は、同一の鍵が、他の通信に関するセキュリティコンテクストに使用され、設定されることを防ぐために実行され得る。

実施形態にかかるセキュアシステムによれば、オペレータネットワーク＿Ｌ０２は、受信ＵＥ＿Ｌ０３と、どの要求ＵＥ＿Ｌ０１が通信できるかを決定でき、セキュリティパラメータを要求ＵＥ＿Ｌ０１又は受信ＵＥ＿Ｌ０３に提供すること、又は、受信ＵＥ＿Ｌ０３の位置情報を要求ＵＥ＿Ｌ０１に提供することのいずれかによりセキュアディスカバリを保証できる。その上、オペレータネットワーク＿Ｌ０２は、要求ＵＥ＿Ｌ０１及び受信ＵＥ＿Ｌ０３についての認証及び承認を実行でき、ProSe通信を保証するためにＵＥの間でセキュリティ接続をサポートできる。

［９］認証及び承認を実行する詳細な方法
次に、認証及び承認を実行し、直接通信のためにお互いにセキュリティ接続を確立するより詳細な方法が説明される。

上述したように、ＵＥ間の直接通信の３つの型、すなわち、図５Ａ、５Ｂ及び５Ｃにそれぞれ示したような１）一対一、２）一対多、３）多対多が存在する。

ＵＥａは、要求ＵＥである。ＵＥｂ、ＵＥｃ及び他のＵＥは、受信ＵＥである。ＵＥは、お互いの直接通信を設定し、それらが共有する鍵を用いて通信を保護する。

新しい鍵階層は、本発明に示される。鍵Ｋｐは、ProSeサービスＩＤに関連する鍵であり、それに関連するインジケータKSI_pを有する。Ｋｐは、ProSeサーバからProSeサービス結果メッセージ内のＵＥへ送信され、又は、ＵＥがProSeサーバに登録された場合にProSeサーバから送信され得る。Ｋｐｃ及びＫｐｉは、ＵＥにおいてＫｐから導出されるセッション鍵である。Ｋｐｃは、機密性鍵であり、Kpiは整合性保護鍵である。セッション鍵は、ProSe通信設定及びそれらの間の直接通信のために使用される。

ＵＥがネットワークに認証され、ProSeサーバに登録されると仮定する。ディスカバリ処理は、上述したように完了される。３つのケースの詳細なメッセージシーケンス及び説明は、以下に与えられる。

［［ケース１Ｃ］]一対一直接通信
お互いに直接通信を有する近接内の２つのみのＵＥが存在する。一対一通信では、ＫｐはProSeサーバへのUE登録において、ＵＥにも割り当てられ得る。一対一型の通信が動的な要求のためでなく、特定の型のサービスに専念されないことを考慮し、通信が要求される場合にProSeサーバが鍵を分配することはより効率的である。

図６は、本発明の実施形態にかかる一対一通信を示すシーケンス図である。図６に示すように、本システムは、UEa３１、UEb３２、ProSeサーバ３４及びオペレータネットワーク３６を備える。本方法は、次の１２ステップを備える。

ＳＰ２０：UEa３１及びUEb３２は、それぞれ、鍵導出アルゴリズムを用いて事前設定される。
ＳＰ２１：［４］ステップ８において検証が成功して完了する場合、ProSeサーバ３４は、（既存の）鍵Ｋｐを割り当て、又は（新しい）鍵Ｋｐを導出できる。
ＳＰ２２：ProSeサーバ３４は、UEa３１へ、ProSeサービス結果内のＫｐ、KSI_p, UEbのＩＤ及びサービスＩＤを送信する。
ＳＰ２３：ProSeサーバ３４は、UEb３２へ、ProSeサービス結果内のＫｐ、KSI_p, UEaのＩＤ及びサービスＩＤを送信する。
ＳＰ２４：UEa３１は、ProSeサーバ３４から受信したＫｐからセッション鍵Ｋｐｃ及びＫｐｉを導出する。
ＳＰ２５：UEa３１は、サービスＩＤ、KSI_p, UEaのＩＤ及びセッション鍵導出に関するアルゴリズムを用いて、ProSe通信設定をUEb３２へ送信する。このメッセージは、Kpiを用いて保護された整合性である。
ＳＰ２６：UEb３２は、ProSeサーバ３４から受信したＫｐから、同一のセッション鍵Ｋｐｃ及びＫｐｉを導出する。UEb３２は、ＳＰ２５で受信したKSI_p及びサービスＩＤに応じてどのＫｐが使用されるものかを判定できる。
ＳＰ２７：UEb３２は、導出されたＫｐｉを用いてＳＰ２５で受信したメッセージの整合性検査を行う。UEb３２は、ＵＥａのＩＤ及びサービスＩＤがＳＰ２３で受信されたものと同じか否かもさらに検査できる。
ＳＰ２８：ＳＰ２７における検証が成功した場合、UEb３２は、UEa３１へ、サービスＩＤ及びＵＥｂのＩＤを用いてProSe通信受理を送信する。本メッセージは、Kpiを用いて保護された整合性である。ＳＰ３０へ進む。
ＳＰ２９：ＳＰ２７における検証が失敗した場合、UEb３２は、UEa３１へ、サービスＩＤ、ＵＥｂのＩＤ及び正確な原因を用いてProSe通信却下を送信する。
ＳＰ３０：UEa３１は、Ｋｐｉを用いてProSe通信受理の整合性検査を実行する。UEa３１は、UEbのＩＤ及びサービスＩＤもさらに検査できる。検証が成功して完了した場合、その後、直接通信は開始できる。
ＳＰ３１：直接通信は、UEa３１及びUEb３２の間で開始する。本メッセージは、セッション鍵Ｋｐｃ及びＫｐｉにより保護される機密性及び／又は整合性であり得る。

［［ケース２Ｃ］]一対多通信
要求ＵＥがブロードキャスティングメッセージをグループ内の他のメンバーＵＥへ送信でき、他のメンバーＵＥが要求ＵＥと通信できるが、同じグループ内の他のＵＥと通信しない、という直接通信を有するＵＥのグループが存在する。

本実施形態では、ＫｐがどのようにＵＥに割り当てられ得るかについて２つのオプションが説明される。以下は、図６に示される一対一通信と同じように、ＫｐがProSeサービス結果内のProSeサーバ３４から送信されるというオプション１である。

図７は、本発明の実施形態にかかるオプション１の一対多通信を示すシーケンス図である。図７に示すように、本方法は、次のステップを備える。

ＳＰ４０：UEa３１、UEb３２及びUEc３３は、それぞれ、鍵導出アルゴリズムを用いて事前設定される。
ＳＰ４１：［４］ステップ８において検証が成功して完了する場合、ProSeサーバ３４は、（既存の）鍵Ｋｐを割り当て、又は（新しい）鍵Ｋｐを導出できる。
ＳＰ４２：ProSeサーバ３４は、UEa３１へ、ProSeサービス結果内のＫｐ、KSI_p、許可ＵＥのＵＥＩＤリスト及びサービスＩＤを送信する。
ＳＰ４３ａ及びＳＰ４３ｂ：ProSeサーバ３４は、UEb３２及びUEc３３のそれぞれへ、ProSeサービス結果内のＫｐ、KSI_p, UEaのＩＤ、許可ＵＥのＵＥＩＤリスト及びサービスＩＤを送信する。
ＳＰ４４：UEa３１は、ProSeサーバ３４から受信したＫｐからセッション鍵Ｋｐｃ及びＫｐｉを導出する。
ＳＰ４５ａ及びＳＰ４５ｂ：UEa３１は、サービスＩＤ、KSI_p, UEaのＩＤ及びセッション鍵導出に関するアルゴリズムを用いて、ProSe通信設定をUEb３２及びUEc３３のそれぞれへ送信する。このメッセージは、Kpiを用いて保護された整合性である。
ＳＰ４６：UEb３２及びUEc３３は、それぞれ、ProSeサーバ３４から受信したＫｐから、同一のセッション鍵Ｋｐｃ及びＫｐｉを導出する。UEb３２及びUEc３３は、ＳＰ４５ａ及びＳＰ４５ｂでそれぞれ受信したKSI_p及びサービスＩＤに応じて、どのＫｐが使用されるものかを判定できる。
ＳＰ４７：UEb３２及びUEc３３は、導出されたＫｐｉを用いてＳＰ４５ａ及びＳＰ４５ｂでそれぞれ受信したメッセージの整合性検査を行う。UEb３２及びUEc３３は、ＵＥａのＩＤ及びサービスＩＤがＳＰ４３ａ及びＳＰ４３ｂで受信されたものと同じか否かもさらに検査できる。
ＳＰ４８ａ及びＳＰ４８ｂ：ＳＰ４７における検証が成功した場合、UEb３２及びUEc３３は、それぞれ、UEa３１へ、サービスＩＤ及びＵＥｂ／ＵＥｃのＩＤを用いてProSe通信受理を送信する。本メッセージは、Kpiを用いて保護された整合性である。ＳＰ５０へ進む。
ＳＰ４９ａ及びＳＰ４９ｂ：ＳＰ４７における検証が失敗した場合、UEb３２及びUEc３３は、それぞれ、UEa３１へ、サービスＩＤ、ＵＥｂ／ＵＥｃのＩＤ及び正確な原因を用いてProSe通信却下を送信する。
ＳＰ５０：UEa３１は、Ｋｐｉを用いてProSe通信受理の整合性検査を実行する。UEa３１は、UEb/UEcのＩＤ及びサービスＩＤもさらに検査できる。検証が成功して完了した場合、その後、直接通信は開始できる。
ＳＰ５１：直接通信は、UEa３１及びUEb３２、又は、UEa３１及びUEc３３の間で開始する。本メッセージは、セッション鍵Ｋｐｃ及びＫｐｉにより保護される機密性及び／又は整合性であり得る。

以下は、受信ＵＥ（ＵＥｂ３２、ＵＥｃ３３）がProSeサーバ３４への登録時にＫｐを受信するというオプション２である。このオプションでは、ProSeサーバ３４は、受信ＵＥ（ＵＥｂ３２、ＵＥｃ３３）のそれぞれへProSeサービス結果を送信する必要がない。このことは、直接通信のためにグループ内の多くのＵＥが存在する場合に、ネットワークリソースを確保する。

図８は、本発明の実施形態にかかるオプション２の一対多通信を示すシーケンス図である。図８に示すように、本方法は、次の１０ステップを備える。

ＳＰ６０：ＵＥがProSeサーバ３４に登録される時にＫｐはＵＥに割り当てられる。UEa３１、UEb３２及びUEc３３ｃは、それぞれ、鍵導出アルゴリズムを用いて事前設定される。
ＳＰ６１：ProSeサーバ３４は、UEa３１へ、ProSeサービス結果内のKSI_p、許可ＵＥのＵＥＩＤリスト及びサービスＩＤを送信する。
ＳＰ６２：UEa３１は、Ｋｐからセッション鍵Ｋｐｃ及びＫｐｉを導出する。
ＳＰ６３：UEa３１は、サービスＩＤ、UEaのＩＤ、ＵＥＩＤリスト及びKSI_pを用いて、ProSe通信設定をＵＥＩＤリスト内のＵＥへブロードキャストする。このメッセージは、Kpiを用いて保護された整合性である。
ＳＰ６４：ブロードキャストメッセージを受信したＵＥは、それがリスト上にあるか否かを確認し、Ｋｐから、同一のセッション鍵Ｋｐｃ及びＫｐｉを導出する。ＵＥは、ＳＰ６３で受信したKSI_p及びサービスＩＤに応じて、どのＫｐが使用されるものかを判定できる。
ＳＰ６５：UEb３２及びUEc３３は、導出されたＫｐｉを用いてブロードキャストメッセージの整合性検査を行う。UEb３２及びUEc３３は、それぞれ、事前設定された基準が存在する場合に、ＵＥａのＩＤ及びサービスＩＤもさらに検査できる。
ＳＰ６６ａ及びＳＰ６６ｂ：検証が成功した場合、UEb３２及びUEc３３は、それぞれ、UEa３１へ、サービスＩＤ及びＵＥｂ／ＵＥｃのＩＤを用いてProSe通信受理を送信する。本メッセージは、Kpiを用いて保護された整合性である。ＳＰ６８へ進む。
ＳＰ６７ａ及びＳＰ６７ｂ：検証が失敗した場合、UEb３２及びUEc３３は、それぞれ、UEa３１へ、サービスＩＤ、ＵＥｂ／ＵＥｃのＩＤ及び正確な原因を用いてProSe通信却下を送信する。
ＳＰ６８：UEa３１は、Ｋｐｉを用いてProSe通信受理の整合性検査を実行する。UEa３１は、UEb/UEcのＩＤ及びサービスＩＤもさらに検査できる。検証が成功して完了した場合、その後、直接通信は開始できる。
ＳＰ６９：直接通信は、UEa３１及びUEb３２、又は、UEa３１及びUEc３３の間で開始する。本メッセージは、セッション鍵Ｋｐｃ及びＫｐｉにより保護される機密性及び／又は整合性であり得る。

［［ケース３Ｃ］]多対多通信
多対多通信では、各ＵＥは、グループ内の任意の他のＵＥと通信できる。図９は、本発明の実施形態にかかる多対多通信を示すシーケンス図である。図９に示すように、本方法は、次の１０ステップを備える。

ＳＰ７０：ＵＥがProSeサーバ３４に登録される時にＫｐはＵＥに割り当てられる。UEa３１、UEb３２及びUEn３３ｎは、それぞれ、鍵導出アルゴリズムを用いて事前設定される。
ＳＰ７１：ProSeサーバ３４は、UEa３１へ、ProSeサービス結果内のKSI_p、許可ＵＥのＵＥＩＤリスト及びサービスＩＤを送信する。
ＳＰ７２：UEa３１は、Ｋｐからセッション鍵Ｋｐｃ及びＫｐｉを導出する。
ＳＰ７３：UEa３１は、サービスＩＤ、UEaのＩＤ、ＵＥＩＤリスト及びKSI_pを用いて、ProSe通信設定をＵＥＩＤリスト内のＵＥへブロードキャストする。このメッセージは、Kpiを用いて保護された整合性である。
ＳＰ７４：ブロードキャストメッセージを受信したＵＥは、それぞれ、それがリスト上にあるか否かを確認し、Ｋｐから、同一のセッション鍵Ｋｐｃ及びＫｐｉを導出する。ＵＥは、ＳＰ７３でそれぞれ受信したKSI_p及びサービスＩＤに応じて、どのＫｐが使用されるものかを判定できる。
ＳＰ７５：UEb３２及びUEn３３ｎは、それぞれ、導出されたＫｐｉを用いてブロードキャストメッセージの整合性検査を行う。UEb３２及びUEn３３ｎは、それぞれ、事前設定された基準が存在する場合に、ＵＥａのＩＤ及びサービスＩＤもさらに検査できる。
ＳＰ７６ａ及びＳＰ７６ｂ：検証が成功した場合、UEb３２及びUEn３３ｎは、それぞれ、UEa３１へ、サービスＩＤ及びＵＥｂ／ＵＥｎのＩＤを用いてProSe通信受理を送信する。本メッセージは、Kpiを用いて保護された整合性である。ＳＰ７８へ進む。
ＳＰ７７ａ及びＳＰ７７ｂ：検証が失敗した場合、UEb３２及びUEn３３ｎは、それぞれ、UEa３１へ、サービスＩＤ、ＵＥｂ／ＵＥｎのＩＤ及び正確な原因を用いてProSe通信却下を送信する。
ＳＰ７８：UEa３１は、Ｋｐｉを用いてProSe通信受理の整合性検査を実行する。UEa３１は、UEb/UEnのＩＤ及びサービスＩＤもさらに検査できる。検証が成功して完了した場合、その後、直接通信は開始できる。
ＳＰ７９：直接通信は、UEの間で開始する。本メッセージは、セッション鍵Ｋｐｃ及びＫｐｉにより保護される機密性及び／又は整合性であり得る。

上記説明を要約すると、本実施の形態にかかる認証及び承認を行う方法は以下の特徴を備える：
（１）ＵＥ直接通信に関する新しい鍵階層：Ｋｐ並びにセッション鍵Ｋｐｃ及びＫｐｉ。Ｋｐｃは、暗号化のためであり、Ｋｐｉは整合性保護のためである。Ｋｐｃ及びＫｐｉは、Ｋｐから導出される。
（２）ＵＥが同期を保持し、鍵が要求されたサービスについて正確であるか否かを検証するように、Ｋｐは鍵識別子KSI_p及びサービスＩＤにも関連する。
（３）ＵＥがProSeサーバ又はProSeサービス結果メッセージ内に登録される場合、ProSeサーバは、ＫｐをＵＥへ分配する。
（４）ＵＥは、セッション鍵導出のためのアルゴリズムを用いて事前設定される。KSI_p、サービスＩＤ及び示されたアルゴリズムにより、受信ＵＥは、同じセッション鍵を導出できる。
（５）受信ＵＥが整合性検査を実行し、メッセージが承認されたソースからであるか否かを検証できるように、整合性鍵Ｋｐｉは、要求ＵＥからの通信要求を保護するために使用される。
（６）受信ＵＥは、サービスＩＤ、要求ＩＤ及び鍵の全てが一致するか否かも検証できる。
（７）ProSe通信受理は、要求ＵＥがその整合性を検証できるような受信ＵＥにより保護された整合性である。
（８）ＵＥ間の直接通信は、セッション鍵Ｋｐｃ及びＫｐｉを用いて保護された機密性及び／又は整合性であり得る。

本発明の実施形態にかかるセキュアシステムによれば、ネットワーク要素ProSeサーバから分配される鍵は、直接通信を確立することを望むＵＥに、他のＵＥがサービスを有するために承認されるか否かを検証させることができる。それらがあるＵＥが別のものへ送信される場合、ＵＥは、鍵が盗まれ又は改ざんされることを防ぐことができる側において、セッション鍵を導出する。Ｋｐは、それらが有することを承認されない他のサービスのための鍵をＵＥに使用されることを防ぐ、あるサービスに関連する。ＵＥ間の直接通信は、ＵＥ間でのみ共有されるセッション鍵を用いて保護され得る。

本プログラムは、様々なタイプの非一時的なコンピュータ可読媒体（non-transitory computer readable media）を用いて格納され、コンピュータに供給することができる。
非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（tangible storage media）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば光磁気ディスク）、ＣＤ−ＲＯＭ(Read Only Memory)、ＣＤ−Ｒ（compact disc recordable）、ＣＤ−Ｒ／Ｗ（compact disc rewritable）、半導体メモリ（例えば、マスクＲＯＭ、ＰＲＯＭ（Programmable ROM）、ＥＰＲＯＭ（Erasable PROM）、フラッシュＲＯＭ、ＲＡＭ（Random Access Memory））を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（transitory computer readable media）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、（電線及び光ファイバ等の）有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給するために使用され得る。

本出願は、２０１３年６月２８日に出願された日本国特許出願第２０１３−１３７２９３号からの優先権の利益を主張し、該特許出願の開示は参照によりその全体が本明細書に援用される。

１セキュアシステム
１０システム
１１ＵＥ
１２ＵＥ
１３ E-UTRAN
１４ EPC
１５ ProSe機能
１６ ProSe APPサーバ
１７ ProSe APP
１８ ProSe APP
１９ eNB
２０ eNB
２１ UEa
２２ UEb
３１ UEa
３２ UEb
３３ UEc
３３ｎ UEn
３４ ProSeサーバ
３６オペレータネットワーク
１００ UE
１００ａシステム
１００ｂシステム
２００ネットワーク
Ｌ０１要求ＵＥ
Ｌ０２オペレータネットワーク
Ｌ０３受信ＵＥ
Ｌ１セキュアグループ管理
Ｌ２セキュアディスカバリ
Ｌ３初期承認
Ｌ４認証
Ｌ５承認
Ｌ６セキュリティ接続確立
Ｌ７セキュア通信
Ｌ８ターミネーション

Claims

一対一直接通信のためのＵＥ（User Equipment）であって、
他のＵＥから、セッション鍵に関連するインジケータと、検証のための情報と、を含む第一のメッセージを受信する受信部と、
前記インジケータから判定された鍵に基づき機密性鍵と完全性鍵を生成する鍵生成部と、
前記ＵＥが保有する前記他のＵＥに関する情報と前記受信した前記情報との一致を検証する第一の検証と、前記完全性鍵による前記第一のメッセージの完全性保護を検証する第二の検証とを行い、前記第一の検証及び前記第二の検証が共に通った場合に、前記他のＵＥと、前記機密性鍵と前記完全性鍵とで保護された前記一対一直接通信を行う制御部と、
を備えるＵＥ。
前記他のＵＥは、前記ＵＥから第二のメッセージを受信し、前記第二のメッセージに関する前記完全性保護を検証する、請求項１記載のＵＥ。
前記ＵＥ及び前記他のＵＥは、プロキシミティサービス（ＰｒｏｘｉｍｉｔｙＳｅｒｖｉｃｅｓ（ＰｒｏＳｅ）をサポートする、請求項１記載のＵＥ。
前記ＵＥ及び前記他のＵＥは、プロキシミティサービス（ＰｒｏｘｉｍｉｔｙＳｅｒｖｉｃｅｓ（ＰｒｏＳｅ）ファンクション及びＰｒｏＳｅアプリケーションサーバを少なくとも含むネットワークからの承認を得る、請求項１記載のＵＥ。
前記ＵＥ及び前記他のＵＥは、相互認証を行う、請求項１記載のＵＥ。
一対一直接通信のためのＵＥ（User Equipment）の通信方法であって、
他のＵＥから、セッション鍵に関連するインジケータと、検証のための情報と、を含む第一のメッセージを受信し、
前記インジケータから判定された鍵に基づき機密性鍵と完全性鍵を生成し、
前記ＵＥが保有する前記他のＵＥに関する情報と前記受信した前記情報との一致を検証する第一の検証と、前記完全性鍵による前記第一のメッセージの完全性保護を検証する第二の検証とを行い、
前記第一の検証及び前記第二の検証が共に通った場合に、前記他のＵＥと、前記機密性鍵と前記完全性鍵とで保護された前記一対一直接通信を行う
通信方法。
前記他のＵＥは、前記ＵＥから第二のメッセージを受信し、前記第二のメッセージに関する前記完全性保護を検証する、請求項６記載の通信方法。
前記ＵＥ及び前記他のＵＥは、プロキシミティサービス（ＰｒｏｘｉｍｉｔｙＳｅｒｖｉｃｅｓ（ＰｒｏＳｅ）をサポートする、請求項６記載の通信方法。
前記ＵＥ及び前記他のＵＥは、プロキシミティサービス（ＰｒｏｘｉｍｉｔｙＳｅｒｖｉｃｅｓ（ＰｒｏＳｅ）ファンクション及びＰｒｏＳｅアプリケーションサーバを少なくとも含むネットワークからの承認を得る、請求項６記載の通信方法。
前記ＵＥ及び前記他のＵＥは、相互認証を行う、請求項６記載の通信方法。