(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-10-15
(45)【発行日】2024-10-23
(54)【発明の名称】UE及びその通信方法
(51)【国際特許分類】
H04L 9/08 20060101AFI20241016BHJP
H04W 92/18 20090101ALI20241016BHJP
H04W 12/041 20210101ALI20241016BHJP
H04W 12/76 20210101ALI20241016BHJP
【FI】
H04L9/08 C
H04W92/18
H04W12/041
H04W12/76
(21)【出願番号】P 2022206667
(22)【出願日】2022-12-23
(62)【分割の表示】P 2021164409の分割
【原出願日】2014-06-13
【審査請求日】2022-12-23
(31)【優先権主張番号】P 2013137293
(32)【優先日】2013-06-28
(33)【優先権主張国・地域又は機関】JP
(73)【特許権者】
【識別番号】000004237
【氏名又は名称】日本電気株式会社
(74)【代理人】
【識別番号】100103894
【氏名又は名称】家入 健
(72)【発明者】
【氏名】ジャン シャオウェイ
(72)【発明者】
【氏名】プラサド アナンド ラガワ
【審査官】金沢 史明
(56)【参考文献】
【文献】特開2006-238343(JP,A)
【文献】特開2005-244534(JP,A)
【文献】米国特許出願公開第2011/0307694(US,A1)
【文献】特開2012-231352(JP,A)
【文献】特開2007-150888(JP,A)
【文献】3GPP TR 23.703, 3rd Generation Partnership Project; Technical Specification Group Services and Syste,V0.4.1,2013年06月12日,pp.1-85,[2018年7月30日検索],インターネット<URL:http://www.3gpp.org/ftp/spec/archive/23_series/23.703/23703-041.zip>
(58)【調査した分野】(Int.Cl.,DB名)
H04L 9/08
H04W 12/04-12/0471
H04W 92/18
(57)【特許請求の範囲】
【請求項1】
UE(User Equipment)であって、
グループ鍵と前記グループ鍵を特定するグループ鍵ID(Identifier)を含む第1のメッセージを
ネットワークノードから受信する受信手段と、
前記グループ鍵に基づいて機密性鍵を生成する鍵生成手段と、
前記グループ鍵を有し
前記グループ鍵IDに応じて判定される前記グループ鍵に基づき前記機密性鍵を生成する他のUEに対して、前記グループ鍵IDを含む第2のメッセージを送信する送信手段と、
前記他のUEと、前記機密性鍵を用いて保護された直接通信を行う制御手段と、
を備えるUE。
【請求項2】
前記UEは、PC5インターフェースを介して前記他のUEと直接通信する請求項1記載のUE。
【請求項3】
前記UEは、前記他のUEとグループを形成する請求項1記載のUE。
【請求項4】
UE(User Equipment)の通信方法であって、
グループ鍵と前記グループ鍵を特定するグループ鍵ID(Identifier)を含む第1のメッセージを
ネットワークノードから受信し、
前記グループ鍵に基づいて機密性鍵を生成し、
前記グループ鍵を有し
前記グループ鍵IDに応じて判定される前記グループ鍵に基づき前記機密性鍵を生成する他のUEに対して、前記グループ鍵IDを含む第2のメッセージを送信し、
前記他のUEと、前記機密性鍵を用いて保護された直接通信を行う、
通信方法。
【請求項5】
前記UEは、PC5インターフェースを介して前記他のUEと直接通信する請求項4記載の通信方法。
【請求項6】
前記UEは、前記他のUEとグループを形成する請求項4記載の通信方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、UE(User Equipment)及びその通信方法に関する。
【背景技術】
【0002】
3GPP(登録商標)(3rd Generation Partnership Project)は、商業的及びパブリックセーフティ(public safety)の両方の利用に関するプロキシミティベースサービス(Proximity based Services (ProSe))の研究を開始した。3GPP SA1(サービスワーキンググループ)は、セキュア通信、UE(User Equipment)識別、及び、プライバシー保護に関するいくつかのセキュリティ要件を開始した。
【0003】
ProSeは、近年の巨大な社会技術動向を象徴する。これらのアプリケーションの原理は、お互いの近接範囲内にある端末で実行するアプリケーションのインスタンスを発見すること、及び、アプリケーション関連データも最終的に交換することである。これと並行して、パブリックセーフティの共同体におけるプロキシミティベースのディスカバリ及び通信に関心がある。
【0004】
ProSe 通信は、eNB (Evolved Node B)経由又はeNBなしの近接におけるUEに対してサービスを提供できる。SA1は、ProSeサービスがネットワークカバレッジ内/外のUEに提供されることを要求する。UEは、他の近所のUEを発見し、又は、他のUEにより発見され得る。そして、UEは、お互いに通信できる。いくつかのユースケースは、非特許文献1に記載される。
【先行技術文献】
【非特許文献】
【0005】
【文献】3GPP TR 22.803 Feasibility study for Proximity Services (ProSe), (Release 12)
【発明の概要】
【発明が解決しようとする課題】
【0006】
しかしながら、プライバシ上の問題だけでなく、直接通信についての認証及び承認に関わるセキュリティ上の問題にもかかわらず、3GPP SA3は、セキュリティ上のソリューションを提供していない。
【課題を解決するための手段】
【0007】
本発明は、上述したセキュリティ上の問題に関する全体的なセキュリティ上のソリューションを提供した。
【0008】
一態様において、UE(User Equipment)であって、グループ鍵と前記グループ鍵を特定するグループ鍵ID(Identifier)を含む第1のメッセージを受信する受信手段と、前記グループ鍵に基づいて機密性鍵を生成する鍵生成手段と、前記グループ鍵を有し前記グループ鍵に基づき前記機密性鍵を生成する他のUEに対して、前記グループ鍵IDを含む第2のメッセージを送信する送信手段と、前記他のUEと、前記機密性鍵を用いて保護された直接通信を行う制御手段と、を備えるUEである。
【0009】
別の態様において、UE(User Equipment)の通信方法であって、グループ鍵と前記グループ鍵を特定するグループ鍵ID(Identifier)を含む第1のメッセージを受信し、前記グループ鍵に基づいて機密性鍵を生成し、前記グループ鍵を有し前記グループ鍵に基づき前記機密性鍵を生成する他のUEに対して、前記グループ鍵IDを含む第2のメッセージを送信し、前記他のUEと、前記機密性鍵を用いて保護された直接通信を行う、通信方法である。
【発明の効果】
【0010】
セキュアシステム、及び、セキュア通信を行う方法は、セキュリティ上の問題に関する全体的なセキュリティ上のソリューションを提供できる。
【図面の簡単な説明】
【0011】
本発明の上記及び他の目的、効果及び特徴は、添付の図面と併せて特定の好ましい実施形態の以下の説明からより明らかになるであろう。
【
図1A】
図1Aは、非特許文献1におけるProSe通信シナリオを示す模式図である。
【
図1B】
図1Bは、非特許文献1におけるProSe通信シナリオを示す模式図である。
【
図2】
図2は、本発明の実施形態にかかるセキュア通信を行う方法を提供するシステムの例を示す模式図である。
【
図3】
図3は、本発明の実施形態にかかるセキュアシステムを示す模式図である。
【
図4】
図4は、本発明の実施形態のセキュア通信を行う方法を説明するシーケンス図である。
【
図5A】
図5Aは、一対一セッション(One-to-one session)を示す模式図である。
【
図5B】
図5Bは、一対多セッション(One-to-many session)を示す模式図である。
【
図5C】
図5Cは、多対多セッション(Many-to-many session)を示す模式図である。
【
図6】
図6は、本発明の実施形態にかかる一対一通信を示すシーケンス図である。
【
図7】
図7は、本発明の実施形態にかかるオプション1の一対多通信を示すシーケンス図である。
【
図8】
図8は、本発明の実施形態にかかるオプション2の一対多通信を示すシーケンス図である。
【
図9】
図9は、本発明の実施形態にかかる多対多通信を示すシーケンス図である。
【発明を実施するための形態】
【0012】
ここで、以下の説明の目的のために、用語「上」、「下」、「右」、「左」、「垂直」、「水平」、「上部」、「底」、「側面」、「縦」及びそれらの派生語は、図面に示されるような本発明に関連するものとする。しかしながら、本発明は、明確に反対に指定された場合を除き、様々な代替の変形形態および工程順序をとり得ることが理解される。添付の図面に示され、かつ、以下の明細書に記述された特定の装置及び処理は、単に、本発明の例示的な実施形態であることも理解される。従って、本明細書に開示された実施形態に関連する特定の寸法及び他の物理的特性は、限定的なものと考えられるべきではない。
【0013】
例示的実施形態において、特に、直接通信、ディスカバリ及び通信を中心としたセキュリティ上のソリューションが説明されることを通じて、そのソリューションは、同様に他の通信に適用され得る。
【0014】
まず、3GPP TR 21.905“Vocabulary for 3GPP Specifications”に与えられた定義が説明される。
【0015】
ProSe 直接通信(Direct Communication):
任意のネットワークノード行き来しない経路を介したE-UTRAN技術を用いるユーザプレーン送信によって、ProSe可能な(ProSe-enabled)近接内の2以上のUEの間での通信。
【0016】
ProSe可能なUE:
ProSe要件及び関連付けられた処理をサポートするUE。特に記載がない限り、ProSe可能なUEは、非パブリックセーフティUE(non-public safety UE)及びパブリックセーフティUE(public safety UE)の両方を言及する。
【0017】
ProSe可能なパブリックセーフティUE(ProSe-enabled Public Safety UE):
ProSe処理及びパブリックセーフティに特有の機能もサポートするProSe可能なUE。
【0018】
ProSe可能な非パブリックセーフティUE(ProSe-enabled non-public safety UE):
ProSe処理をサポートするがパブリックセーフティに特有の機能をサポートしないUE。
【0019】
ProSe 直接ディスカバリ(ProSe Direct Discovery):
リリース12のE-UTRAN技術を用いた2つのUEの機能のみを使用することにより、その周辺の他のProSe可能なUEを発見するために、ProSe可能なUEにより採用される処理。
【0020】
EPCレベルのProSe ディスカバリ(EPC-level ProSe Discovery):
EPCが2つのProSe可能なUEの近接性を判定し、それらの近接性を通知することによる処理。
【0021】
図1A及び1Bは、非特許文献1におけるProSe通信シナリオを示す模式図である。ProSe通信に関わるUE11及びUE12が同一のeNB19により提供され、ネットワークカバレッジが利用可能である場合、システム100aは、
図1Aに実線矢印により示されるように、UE11、12、eNB19及びEPC(Evolved Packet Core)14(例えば、セッション管理、承認、セキュリティ)の間で交換される制御情報を用いたProSe通信を実行することを決定できる。課金のために、修正が既存のアーキテクチャに関して最小化される。UE11及び12は、
図1Aに破線矢印により示されるように、ProSe通信経路を経由した制御シグナリングを併せて交換できる。
【0022】
ProSe通信に関わるUE11及び12が異なるeNB19、20により提供され、ネットワークカバレッジが利用可能である場合、システム100bは、
図1Bに実線矢印により示されるように、UE11、12、eNB19及びEPC14(例えば、セッション管理、承認、セキュリティ)の間で交換される制御情報を用いたProSe通信を実行することを決定できる。この構成において、eNB19及び20は、
図1BにeNB19及び20の間の破線矢印により示されるように、EPC14を介して互いに連携し、又は、無線リソース管理について直接通信できる。課金のために、シグナリングの修正が既存のアーキテクチャに関して最小化される。UE11及び12は、
図1BにUE11及び12の間の破線矢印により示されるように、ProSe通信経路を経由した制御シグナリングを併せて交換できる。
【0023】
ネットワークカバレッジがUEの部分集合について利用可能な場合、1以上のパブリックセーフティUEは、ネットワークカバレッジを有さない他のUEに関する無線リソース管理制御情報を中継できる。
【0024】
ネットワークカバレッジが利用可能でない場合、制御経路は、パブリックセーフティUEの間で直接的に存在し得る。この構成において、パブリックセーフティUEは、ProSe通信を確立及び維持するために、事前に設定された無線リソースを当てにする。あるいは、パブリックセーフティUEに属する、パブリックセーフティ無線リソース管理機能(Public Safety Radio Resource Management Function)は、パブリックセーフティProSe通信についての無線リソースの割り当てを管理できる。
【0025】
図2は、本発明の実施形態にかかるセキュア通信を行う方法を提供するシステムの例を示す模式図である。
図2に示すように、システム10は、UE11、UE12、E-UTRAN13、EPC14、ProSe機能15、ProSeアプリケーションサーバ16、ProSeアプリケーション17、及びProSeアプリケーション18を備える。
【0026】
UE11及びUE12は、PC5を介して通信可能であり、UE11及びE-UTRAN13は、LTE-Uu1を介して通信し、UE12は、LTE-Uu2及びPC3のそれぞれを介してE-UTRAN13及びProSe機能15と通信可能である。EPC14及びProSe機能15は、PC4を介して通信可能であり、ProSeアプリケーションサーバ16は、SG1及びPC1のそれぞれを介してEPC14及びProSeアプリケーション18と通信可能であり、ProSe機能15は、PC6を介して自身により通信可能である。
【0027】
上記のように、既存の鍵は、インフラを用いる時に、すなわちeNodeBを介して使用され得る。しかしながら、新たなソリューションがデバイス間の直接ディスカバリに関して必要とされる。例えば、鍵はネットワークから通信相手へ送信され、鍵は通信相手の間で生成され、又は、ネゴシエーションに関する同様のアルゴリズムは直接又はネットワークを経由して使用され得る。さらに、新たなソリューションは、無認可スペクトル上のセキュリティに関しても必要とされる。
【0028】
ProSe直接通信一対一についての2つの異なるモードが以下にサポートされる。
ネットワーク独立直接通信(Network independent direct communication):このProSe直接通信に関する動作モードは、UEへの機能及び地域情報のみを用いることにより実行される、接続及び通信を承認するための任意のネットワーク支援を要求しない。このモードは、UEがE-UTRANにより提供されるか否かにかかわらず、事前に承認されたProSe可能なパブリックセーフティUEへのみ適用可能である。
【0029】
ネットワーク承認直接通信(Network authorized direct communication):このProSe直接通信に関する動作モードは、ネットワーク支援を常に要求し、唯一のUEがパブリックセーフティUEについて「E-UTRANにより提供され」る場合にも適用可能である。非パブリックセーフティUEについて、UEの双方が「E-UTRANにより提供され」なければならない。
【0030】
PC1:
US12内のProSeアプリケーション18とProSeアプリケーションサーバ16との間の参照地点である。アプリケーションレベルの要求を定義するために用いられる。
【0031】
PC2:
ProSeアプリケーションサーバ16とProSe機能15との間の参照地点である。ProSeアプリケーションサーバ16とProSe機能15を介した3GPP EPSにより提供されるProSe機能との間の相互関係を定義するために用いられる。その使用の一例は、ProSe機能15内のProSeデータベースに関するアプリケーションデータの更新のためであってもよい。その使用の別の例は、3GPP機能及びアプリケーションデータの間の相互作用、例えば、名前の変換におけるProSeアプリケーションサーバ16が使用するためのデータであってもよい。
【0032】
PC3:
UE12とProSe機能15との間の参照地点である。UE12とProSe機能15との間の相互関係を定義するために用いられる。その使用の一例は、ProSeディスカバリ及び通信に関する構成のためのものである。
【0033】
PC4:
EPC14とProSe機能15との間の参照地点である。EPC14とProSe機能15との間の相互関係を定義するために用いられる。その可能なユースケースは、UE間の一対一通信経路を設定する場合、又は、リアルタイムにおけるセッション管理又はモビリティ管理のためのProSeサービス(承認)を検証する場合、であるとよい。
【0034】
PC5:
(UE間の直接的な、及び、LTE-Uu上でのUE間の)中継及び一対一通信のために、ディスカバリ及び通信に関する制御及びユーザプレーンのために使用されるUE11とUE12との間の参照地点である。
【0035】
PC6:
この参照地点は、異なるPLMNに加入したユーザ間のProSeディスカバリのような機能のために使用される。
【0036】
SGi:
SGiを経由したTS 29.061 [10]に定義された関連機能に加えて、アプリケーションデータ及びアプリケーションレベル制御情報交換について使用される。
【0037】
図3は、本発明の実施形態にかかるセキュアシステムを示す模式図である。
図3に示されるように、本発明の実施形態にかかるセキュアシステム1は、1以上の要求UE_L01、オペレータネットワーク_L02、及び受信UE_L03を備える。セキュア通信を実行する方法は、オペレータネットワーク_L02との相互作用を用いて又は用いないで、UEの間(要求UE_L01、受信UE_L03)で実行される、セキュアグループ管理L1、セキュアディスカバリL2、初期承認L3、認証L4、承認L5、セキュリティ接続確立L6、セキュア通信L7、及びターミネーション(termination)L8を含む。
【0038】
ネットワークカバレッジがUEのために利用可能であると仮定すると、ブロードキャスティングは、本実施形態の例として示される。しかし、本実施形態は、マルチキャスティング、及び、
図1A, 1B及び2に示されるような一対一通信にも適用する。
【0039】
通信終了までのグループの設定から、セキュリティは後述のように各ステップに必要とされる。尚、ステップL1‐L4は、サービス又はアプリケーションに依存して異なる順序で有り得る。
【0040】
L1:セキュアグループ管理
メンバーは安全に参加することができ、メンバーは安全に離れることができ、サービス及び各メンバーの承認レベル、任意の他の要求される情報は安全に修正できる。
【0041】
L2:セキュアディスカバリが発生するならば
ディスカバリが保証されない場合、マスカレード攻撃が順番に詐欺的な課金に導くことが発生し得るという結果によって、デバイスは誤った相手又は不正なデバイスとの通信を開始するだろう。この目的のために、通信に関連するディスカバリは保証されなければならない。すなわち、UEは、近接する他のUEの同一性を認証する。ディスカバリとデバイスの整合性の保護は、メッセージを認証できるべきである。
【0042】
L3:初期承認
セキュアディスカバリに基づく初期承認は、ディカバーされたデバイスがグループに属するという決定につながる。従って、次のステップが開始できる。
【0043】
L4:認証
一旦、デバイスがグループの一部として発見され、承認されると、相互認証が存在すべきであり、さもなければ、未だに攻撃の範囲が存在する。
【0044】
L5:承認
次のレベルの承認は、サービスが同じグループに属するデバイス間で使用され得ることを見出す。例えば、UEは、異なるメッセージの型を送受信することが許可され、ブロードキャスティングメッセージを受信することのみが許可される。
【0045】
L6:セキュリティ接続確立(鍵導出及び管理)
同じグループに属するUEは、そのグループ又は攻撃者に属していない他のUEがメッセージを盗聴、又は、改ざんできないように、それらの通信を保護するための鍵を有すべきである。
【0046】
L7:セキュア通信
同じグループ内のUE間の通信は、加入サービス型に応じた整合性及び/又は機密性を用いて、セキュリティ接続(security association)により保護され得る。
【0047】
L8:ターミネーション(Termination)
セキュアターミネーションは、UEが通信を停止又は終了する場合、又は、グループ全体の通信が終了した場合に、セキュリティを提供できる。
【0048】
セキュリティ要件を満たす本発明の実施形態におけるセキュア通信を実行する詳細な方法は、以下のセクションで説明される。
図4は、本発明の実施形態にかかるUE100とネットワーク200との間のセキュア通信を行う方法を説明するシーケンス図である。
【0049】
[1]グループ設定及び管理(L1)
グループとは、
(1)互いに通信する2つのデバイス(一対一)、又は、
(2)1のUEが他のデバイスと通信できる2以上のデバイス(一対多)
(3)互いに通信できる2以上のデバイス(多対多)
が可能である。
【0050】
グループは、異なる通信目的に設定することができ、グループメンバーは変更され得る。グループを形成するために、オペレータネットワーク_L02は、通信をしたい受信UE_L03を要求する要求UE_L01を調べ、それらは互いに通信できる場合にデバイスを検証し、要求及び形成の両側(要求UE_L01及び受信UE_L03)において、検証されたデバイスを通知できる。
【0051】
以下に、グループを生成する一例が説明される。
図4に示されるように、UE100は、ネットワーク200へProSe加入者を要求し、グループを生成する(ステップ1)。ステップ1において、UE100は、条件、すなわち、ポリシー、例えば、興味、特定の位置等が合致する必要がある。また、ネットワーク200は、UEが条件、すなわち、ポリシー、例えば、近接範囲、加入者、ローミングUEの場合のホームネットワーク、WiFiか否か、ProSe可能等を満たすか否かを検証する必要がある。グループは厳密に形成され、例えば、グループのメンバーはホワイトリストに登録され、又は、グループは、UE100からの要求において、又は、ネットワーク200が全てのUEの条件を認識する場合にはネットワーク200により、動的に形成される。
【0052】
セキュアグループを生成するために、UE100はグループの一部であることに同意しなければならず、「同意された」UE100のみがグループメンバーになる。グループ管理は、グループメンバーの追加、グループメンバーの削除、グループの終了、及び、グループメンバーの一時的な追加を含む。各UE100は、例えばソーシャルネットワークアプリケーションから誰が近くにいるかを理解し、ProSeサービスについて要求する。ProSeサーバは承認を実行する必要があるが、ディスカバリを実行する必要はない。
【0053】
[2]ディスカバリ - 近接内のUEのセキュアディテクション(L2)
[1]のディスカバリ及びグループ生成は、同時に発生し、又は、独立した手順である。UE(要求UE_L01)は近接内の他のUE(受信UE_L03)を発見できるという次の3つの手段が存在する。(1)ブロードキャストベース、(2)ネットワークベース、及び(3)デバイスサービスレベル情報ベース。セキュアディスカバリがどのように行なわれるかが次のように説明される。
【0054】
[2-1]ブロードキャストベースのソリューション
ブロードキャストベースのソリューション内に6つの方法(s1-s6)が存在する。
【0055】
(s1)トークン
ブロードキャストメッセージは、所与のUEのみが有することができるトークンを含むことができる。トークンは受信側がそれを再利用することを防ぐために一度だけ使用されるべきである。そこに到着するために、UEは、ブロードキャストメッセージを受信する度にトークンを計算でき、又は、ネットワークは、次に使用されるためのトークンのUE全てに通知できる。トークンは受信側により再利用され得るため、このことは、サービスの情報通知の種類としてそのようなユースケースのために使用され得る。
【0056】
(s2)署名メッセージ(Signing message)
ブロードキャストメッセージは、受信UE、又は、受信UEへのネットワークのいずれかにより検証される鍵により署名され得る。署名は、異なる鍵管理ソリューションにより生じ、又は、インフラネットワーク-新しい鍵の階層は、ここに必要とされる-との通信(又は現在の鍵からの導出)のために現在の鍵を用いて生じ得る。
【0057】
(s3)メッセージID
ブロードキャストメッセージは、認証の間に検証され、承認のためにのみ最初に使用されるIDを有することができる。
【0058】
(s4)ランダム値
ブロードキャストメッセージは、ネットワーク及びUEにより生成されるだけのランダム値を含むことができる。ランダム値の検証は、通信するUEの代わりにネットワークにより行なわれる。
【0059】
(s5)鍵
各UEは、他のデバイスに属する特定の鍵を有する。それ故、潜在的に長いブロードキャスト、又は、グループ内の各UEごとに暗号化され/整合性が保護された部品がばらばらに送信される新しいタイプのブロードキャストを送信する。
【0060】
(s6)スタンプ
ブロードキャストメッセージは、タイムスタンプ及びライフタイムで署名され得る。尚、ライフタイムは、非常に短い期間であるか、次のブロードキャストまで存続させることができる。
【0061】
[2-2]ネットワークベースのソリューション
この目的のために、ネットワークは、UE(要求UE_L01)から受信した位置情報を使用でき、位置情報は、既存のネットワークセキュリティメカニズムにより保護され得る。
【0062】
[2-3]デバイスサービスレベル情報ベースのソリューション
要求UE_L01は、ソーシャルネットワーク又は他のサービスにより提供される位置情報を使用できる。セキュリティは、アプリケーション層で保証される。
【0063】
ディスカバリの詳細な例が説明される。UE100は、D2D(デバイス間通信)サーバ内でディスカバリ/ディスカバリ可能な特徴及び/又は機能を設定できる。
ケース1A:
UE100は、他のUEが近接に存在するか否かを認識しない場合、ProSeサービスについてProSeサーバに要求できる。そして、ProSeサーバは、ProSeサービスについての要求を発信し、それと同時に、他のUEの位置情報を取得できる。
ケース2A:
UE100は、誰が、例えばソーシャルネットワークアプリケーションから近接に存在し、サービスについて問い合わせるかを把握できる場合、ProSeサーバは、承認を実行する必要があるが、ディスカバリを実行する必要はない。
【0064】
ProSeサーバが承認を実行する場合、UE100は、ProSe及び/又はUE100が所与のサービス/通信手段を取得するために許可されることを可能にする。
【0065】
ディスカバリがUE100の近接性に基づいて行なわれる場合、UE100は、ユニキャストセキュリティコンテクストにより周期的に保護される位置情報を送信する。ネットワーク200は、必要とされる場合又は周期的に、位置情報を要求する。要求(ステップ3)はブロードキャストされ、ブロードキャストされたメッセージはセキュリティを要求する。応答(ステップ4)は、ユニキャストセキュリティコンテクストにより保護され得る。
【0066】
ネットワークは、要求及び受信UEによっても与えられる、近接性についての状況を保存する。ネットワーク200は、ディスカバーされることが許可される、近隣の受信UEへブロードキャストできる。そして、UEは保護されたメッセージに応答する。UE100は、最初の通信及び/又は登録において、又は、任意の変化が発生する場合に、その状況及び機能をネットワーク200に通知する。
【0067】
ネットワーク200又はUE100によるブロードキャストベースのソリューションは、1以上の次の要件を必要とする。すなわち、受信側は、ソースを検証できるべきであり、ブロードキャストメッセージは、再利用されるべきでなく、応答を受信するネットワーク200は、それを検証できるべき、又は、応答は、あまりにも長い場合には破棄されるべきである。UE100は、セキュアディスカバリを実行するために1以上のソリューションを使用できる。ソリューションは、トークン、署名、メッセージ、メッセージID、ランダム値、鍵、及びスタンプを含む。尚、それらのソリューションは、
図4に示されるような、ステップ5(相互認証する、認証L4)、ステップ6(承認する、承認L5)、及び、ステップ7(鍵の生成及びアルゴリズムのネゴシエート、セキュア通信L7)において、使用され得る。ステップ5から7は、共に発生してよく、セキュリティをブロードキャストするために関連する可能性もある。
【0068】
[3]初期承認(L3)
初期承認は、上記ディスカバリソリューションに応じて変化する。
【0069】
[3-1]ブロードキャストベース:
要求UE_L01が受信UE_L03と通信することが許可されるか否かは、ネットワークにより、又は、ネットワークにより提供される証拠を有する受信UE_L03により検査され得る。
【0070】
[3-2]ネットワークベース:
要求UE_L01及び受信UE_L03は、直接無線インタフェース上で相互認証を実行できる。
【0071】
[3-3]デバイスサービスレベル情報ベース:
受信UE_L03は、ユーザにより、又は、ProSeサービスの目的で、デバイスグループのメンバーの間のUEの中で、維持されるリストを検査する。
【0072】
[4]認証(L4)
一旦、要求UE_L01が同じグループに属するとして識別されると、認証が行なわれる。認証は、局所的に、又は、ネットワークとの相互作用により、実行され得る。
【0073】
[4-1]要求UE_L01の認証:
このことは、ネットワークにより要求UE_L01、又は、ネットワークからの証明を有するUEの成功識別により実行され得る。
【0074】
[4-2]受信UE_L03の認証:
このことは、以下により実行され得る
[4-2-i] 要求UE_L01及び受信UE_L03の間で共有される鍵を用いること
[4-2-ii]現在のネットワークセキュリティ鍵又は新たな鍵を用いること
[4-2-iii]受信UE_L03からの入力認証要求を要求UE_L01に通知するネットワーク。
【0075】
[5]承認-サービスアクセス制御(L5)
要求UE_L01及び受信UE_L03(以下、「UE」としても参照される)がグループ内で使用できるサービスへのアクセス制御についての異なるレベルが存在する。
[5-1]UEはブロードキャストメッセージを受信及び/又は送信することが許可される。
[5-2]UEは複数メッセージを受信及び/又は送信することが許可される。
[5-3]UEは一対一通信に関するメッセージを受信及び/又は送信することが許可される。
[5-4]加入者情報に応じたUE承認、及び、ProSeサービスに関するポリシーUE集合
【0076】
ネットワークは、UE機能及びユーザ契約に応じた要求UE_L01及び受信UE_L03を含むグループメンバーへのポリシーを設定及び提供できる。
【0077】
ネットワーク200は、グループへの参加を希望するUE100について承認を行う。UE100のグループメンバーは、セッション鍵を用いることにより、他のUEがネットワークにより承認されるか否かを検証する。検証された承認を行う別の方法は、(1)各UE100へ承認値を送信するネットワークにより行なわれ、各UE100がお互いに承認を実行するためにこの値を使用する、又は、(2)まだ、検証された承認を行う別の方法は、要求UEから受信UEへ承認値を送信することにより行なわれ、受信UEはこの承認値及び受信結果を検証するためにネットワークに要求する。
【0078】
[6]新たな鍵階層及び鍵管理(L6)
新たな鍵階層が本発明の実施形態に示される。鍵Kp は、グループに関連する鍵であり、ProSeサービスにも関連してもよい。それに関連するインジケータKSI_p を有する。Kp は、使用のためにProSeサーバから送信され得る。
【0079】
鍵、Kpc及びKpiは、UEにおけるKpから導かれるセッション鍵である。Kpc は機密性鍵であり、Kpiは整合性保護鍵である。セッション鍵は、UEがお互いの承認及びProSe通信設定を実行するために使用され、それらの間の直接通信を有する。
【0080】
承認及び認証の後、要求UE_L01及び受信UE_L03を含む通信デバイスは、お互いに通信するためのセッションを開始できる。要求UE_L01及び受信UE_L03がお互いに通信する場合、それらは通信鍵を共有する。鍵は、グループ鍵、及び/又は、各セッションごとのセッション鍵と同様に、通信デバイスごとに一意な鍵であるとよい。
【0081】
鍵は、ネットワークにより管理され、ネットワークとのセキュア通信チャネルを介して送信され得る。あるいは、鍵は、要求UE_L01により管理され、認証又は検証の間にネットワークにより保証され得るセキュアユニキャスト通信チャネルを介して、通信内の受信UE_L03を含む他のデバイスへ送信され得る。鍵は、信頼されたサードパーティによっても発行され得る。
【0082】
UE100は、セッションの開始時にお互いに認証する(S5)。認証は、承認とリンクされる(S6)。
図5Aから5Cは、それぞれ、一対一、一対多、多対多セッションを示す模式図である。
図5Aから5Cに示されるように、UEa21及びUEa31は要求UE_L01を示し、UEb22、UEb32、UEb33及びUEb33nは受信UE_L03を示す。
【0083】
セッションが開始される場合、最初に、セッション鍵が生成される。本実施形態において、要求UE_L01(UEa21、UEa31)及び受信UE_L03(UEb22、UEb32、UEc33、UEn33n)は、セッション鍵を含む2種類の鍵を使用する。
ケース1B:
各グループは、各サービスに関する鍵Kp(Kpはサービス鍵として提供される)を有し、新たなセッション鍵は各セッションに対して生成される。
ケース2B:
各グループは、鍵Kp(Kpはグループ鍵として提供される)を有し、新たなセッション鍵は各セッションに対して生成される。
【0084】
各ケースにおいて、ProSeサーバ又は要求UE_L01のいずれかは、鍵を送信する。例えば、ProSeサーバは、要求UE_L01及び受信UE(群)L03へ鍵Kpを送信し、要求UE_L01は、セッションごとに受信UE_L03(群)へセッション鍵を送信する。あるいは、 ProSeサーバは、鍵Kp及びセッション鍵の両方を要求UE_L01及び受信UE(群)L03へ送信し、又は、要求UE_L01は、鍵Kp及びセッション鍵の両方を受信UE(群)L03へ送信する。
【0085】
さらに、誰かが離れ又は追加されるか否かをグループが変更する場合、セッションが終了し、もしくは、鍵がタイムアウトする場合、又は、ProSeサーバが決定した場合、例えば、鍵Kp及び/又はセッション鍵が変更されるべきである。
【0086】
ProSeサーバが鍵KpをUEに割り当てる場合、UEは承認及び通信に関する鍵からセッション鍵を導き出す。UEは、鍵導出についてのアルゴリズムを事前に設定される、又は、鍵KpはKSI(鍵設定識別子(key set identifier))及びサービスに関連する。それらの理由で、UEの認証及び承認中のセキュリティ問題、又は、直接通信に関する鍵のセキュリティ問題は、解決され得る。
【0087】
尚、鍵設定識別子(KSI)は、認証中に導出される暗号及び整合性鍵に関連付けられる番号である。鍵設定識別子は、ネットワークにより割り当てられ、計算された暗号鍵CK及び整合性鍵IKと共に保存される移動局への認証要求メッセージで送信され得る。鍵設定識別子の目的は、ネットワークが、認証処理を呼び出すことなしに移動局に保存される暗号鍵CK及び整合性鍵IKを識別することを可能にすることである。このことは、その後の接続(セッション)の間に暗号鍵CK及び整合性鍵IKの再利用を許可するために使用される。
【0088】
[7]セキュア通信(L7)
セキュア通信は、メッセージがグループに属さないUEにより盗聴され、又は、改ざんされることから防ぐのと同様に、グループメンバーUEの間のメッセージ送信の可用性を提供できる。また、セキュア通信は、UEが承認されないサービスを利用することを防ぐことができる。
【0089】
グループ内の通信は、整合性及び/又は信頼性保護を有すべきである。通信の全ては、セキュリティ接続が確立される後に、上述したセッション鍵により保護され得る。
【0090】
セキュリティポリシは、オペレータネットワーク_L02の支援を有し又はなしにグループ内のネゴシエーション及び同意であり得る。グループメンバーの全ては、セキュリティポリシに従うべきである。
【0091】
次に、UEの位置の変化が発生した場合のセキュリティが説明される。UEのいずれもが位置変更を有さない場合、セキュリティ問題は存在しない。さらに、UEの全てが変更された位置を有さないが、お互いに近接に留まる場合、未だにセキュリティ問題は存在しない。
【0092】
UEの一部(1以上のUE)が他のUEから近接の外に移動しており、ProSeサービスを利用しない場合、グループ及びセキュリティ管理は、グループ内でUEを残すために更新される必要がある。あるいは、1以上のUEがUEから近接の外に移動しており、お互いにProSeサービスを維持したい場合、グループ及びセキュリティ管理は、グループ内でUEを残すために更新される必要があり、新しいグループ及びセキュリティは、トラベラー(traveler)のために必要とされる。
【0093】
尚、ProSeサーバは、全UEの位置の違いを比較及び計算するために、周期的に、GMLC(Gateway Mobile Location Center)からUE位置情報を取得すべきである。
【0094】
[8]ターミネーション(L8)
通信が中断される場合、デバイスは、認証及び承認の情報を維持する間にセッション鍵を削除すべきである。
【0095】
通信が終了(terminate)する場合、デバイスは、履歴情報、又は、再び、認証及び承認についてのシグナリングを防ぐための次の利用時間に関するライフタイムを有する割り当てられたトークンを保持できる。
【0096】
インフラから直接モードへの滑らかなハンドオーバは、ハンドオーバが発生する前の通信パーティ(要求UE_L01及び受信UE_L03)の間の鍵の生成を要求するだろう。例えば、通信パーティがWiFiを使用している場合、鍵は、WiFi AP及びUEに割り当てられるべきである。WiFi AP及びUEは、お互いに承認及び認証するべきである。鍵は、限定されたライフタイムを有するべきである。ネットワークは、UEがどちらのWiFi APと通信できるかを認識できる。UEは、WiFi APが存在し、ネットワークがWiFi APを検証することを見出すことができる。UEがWiFi APと接続する場合、UEはProSeサーバを認証する。1つのオプションは、ProSe機能がProSeアプリケーションサーバと通信するためのUEに鍵を割り当てられるということである。
【0097】
上記説明を要約すると、本実施の形態にかかるセキュア通信を行う方法は以下の特徴を備える:
(1)オペレータネットワーク_L02は、要求UE_L01が要求UE_L01により要求された受信UE_L03と通信できるか否かを判定する。
(2)近接内のUEのディスカバリにおけるセキュリティは、ネットワークにより提供されたトークン、鍵、及び署名を使用することにより提供され得る。
(3)近接内のUEのディスカバリのセキュリティは、オペレータネットワーク_L02により提供される位置を使用することにより提供され得る。
(4)近接内のUEのディスカバリのセキュリティは、アプリケーション層内で提供されるセキュリティを有し、ソーシャルネットワークサービスにより提供される位置情報を使用することにより提供され得る
(5)デバイスの承認は、ネットワークにより、又は、デバイス直接検証により実行され得る。
(6)要求UE_L01及びグループ内に存在することを同意する受信UE_L03の間の相互認証は、ネットワークにより実行され、また、両方のUEには結果が通知され得る。
(7)要求UE_L01及び受信UE_L03の間の相互認証は、それらの間で共有される鍵で両端により実行され得る。
(8)グループ鍵及び一意なセッション鍵であり、ProSe通信を保証するための新たな鍵が使用され得る。
(9)セキュア通信のためのグループ内のセキュリティポリシーはネゴシエートされ、設定される。
(10)ターミネーション管理は、同一の鍵が、他の通信に関するセキュリティコンテクストに使用され、設定されることを防ぐために実行され得る。
【0098】
実施形態にかかるセキュアシステムによれば、オペレータネットワーク_L02は、受信UE_L03と、どの要求UE_L01が通信できるかを決定でき、セキュリティパラメータを要求UE_L01又は受信UE_L03に提供すること、又は、受信UE_L03の位置情報を要求UE_L01に提供することのいずれかによりセキュアディスカバリを保証できる。その上、オペレータネットワーク_L02は、要求UE_L01及び受信UE_L03についての認証及び承認を実行でき、ProSe通信を保証するためにUEの間でセキュリティ接続をサポートできる。
【0099】
[9]認証及び承認を実行する詳細な方法
次に、認証及び承認を実行し、直接通信のためにお互いにセキュリティ接続を確立するより詳細な方法が説明される。
【0100】
上述したように、UE間の直接通信の3つの型、すなわち、
図5A、5B及び5Cにそれぞれ示したような1)一対一、2)一対多、3)多対多が存在する。
【0101】
UEaは、要求UEである。UEb、UEc及び他のUEは、受信UEである。UEは、お互いの直接通信を設定し、それらが共有する鍵を用いて通信を保護する。
【0102】
新しい鍵階層は、本発明に示される。鍵Kpは、ProSeサービスIDに関連する鍵であり、それに関連するインジケータKSI_pを有する。Kpは、ProSeサーバからProSeサービス結果メッセージ内のUEへ送信され、又は、UEがProSeサーバに登録された場合にProSeサーバから送信され得る。Kpc及びKpiは、UEにおいてKpから導出されるセッション鍵である。Kpcは、機密性鍵であり、Kpiは整合性保護鍵である。セッション鍵は、ProSe通信設定及びそれらの間の直接通信のために使用される。
【0103】
UEがネットワークに認証され、ProSeサーバに登録されると仮定する。ディスカバリ処理は、上述したように完了される。3つのケースの詳細なメッセージシーケンス及び説明は、以下に与えられる。
【0104】
[[ケース1C]]一対一直接通信
お互いに直接通信を有する近接内の2つのみのUEが存在する。一対一通信では、KpはProSeサーバへのUE登録において、UEにも割り当てられ得る。一対一型の通信が動的な要求のためでなく、特定の型のサービスに専念されないことを考慮し、通信が要求される場合にProSeサーバが鍵を分配することはより効率的である。
【0105】
図6は、本発明の実施形態にかかる一対一通信を示すシーケンス図である。
図6に示すように、本システムは、UEa31、UEb32、ProSeサーバ34及びオペレータネットワーク36を備える。本方法は、次の12ステップを備える。
【0106】
SP20:UEa31及びUEb32は、それぞれ、鍵導出アルゴリズムを用いて事前設定される。
SP21:[4]ステップ8において検証が成功して完了する場合、ProSeサーバ34は、(既存の)鍵Kpを割り当て、又は(新しい)鍵Kpを導出できる。
SP22:ProSeサーバ34は、UEa31へ、ProSeサービス結果内のKp、KSI_p, UEbのID及びサービスIDを送信する。
SP23:ProSeサーバ34は、UEb32へ、ProSeサービス結果内のKp、KSI_p, UEaのID及びサービスIDを送信する。
SP24:UEa31は、ProSeサーバ34から受信したKpからセッション鍵Kpc及びKpiを導出する。
SP25:UEa31は、サービスID、KSI_p, UEaのID及びセッション鍵導出に関するアルゴリズムを用いて、ProSe通信設定をUEb32へ送信する。このメッセージは、Kpiを用いて保護された整合性である。
SP26:UEb32は、ProSeサーバ34から受信したKpから、同一のセッション鍵Kpc及びKpiを導出する。UEb32は、SP25で受信したKSI_p及びサービスIDに応じてどのKpが使用されるものかを判定できる。
SP27:UEb32は、導出されたKpiを用いてSP25で受信したメッセージの整合性検査を行う。UEb32は、UEaのID及びサービスIDがSP23で受信されたものと同じか否かもさらに検査できる。
SP28:SP27における検証が成功した場合、UEb32は、UEa31へ、サービスID及びUEbのIDを用いてProSe通信受理を送信する。本メッセージは、Kpiを用いて保護された整合性である。SP30へ進む。
SP29:SP27における検証が失敗した場合、UEb32は、UEa31へ、サービスID、UEbのID及び正確な原因を用いてProSe通信却下を送信する。
SP30:UEa31は、Kpiを用いてProSe通信受理の整合性検査を実行する。UEa31は、UEbのID及びサービスIDもさらに検査できる。検証が成功して完了した場合、その後、直接通信は開始できる。
SP31:直接通信は、UEa31及びUEb32の間で開始する。本メッセージは、セッション鍵Kpc及びKpiにより保護される機密性及び/又は整合性であり得る。
【0107】
[[ケース2C]]一対多通信
要求UEがブロードキャスティングメッセージをグループ内の他のメンバーUEへ送信でき、他のメンバーUEが要求UEと通信できるが、同じグループ内の他のUEと通信しない、という直接通信を有するUEのグループが存在する。
【0108】
本実施形態では、KpがどのようにUEに割り当てられ得るかについて2つのオプションが説明される。以下は、
図6に示される一対一通信と同じように、KpがProSeサービス結果内のProSeサーバ34から送信されるというオプション1である。
【0109】
図7は、本発明の実施形態にかかるオプション1の一対多通信を示すシーケンス図である。
図7に示すように、本方法は、次のステップを備える。
【0110】
SP40:UEa31、UEb32及びUEc33は、それぞれ、鍵導出アルゴリズムを用いて事前設定される。
SP41:[4]ステップ8において検証が成功して完了する場合、ProSeサーバ34は、(既存の)鍵Kpを割り当て、又は(新しい)鍵Kpを導出できる。
SP42:ProSeサーバ34は、UEa31へ、ProSeサービス結果内のKp、KSI_p、許可UEのUEIDリスト及びサービスIDを送信する。
SP43a及びSP43b:ProSeサーバ34は、UEb32及びUEc33のそれぞれへ、ProSeサービス結果内のKp、KSI_p, UEaのID、許可UEのUEIDリスト及びサービスIDを送信する。
SP44:UEa31は、ProSeサーバ34から受信したKpからセッション鍵Kpc及びKpiを導出する。
SP45a及びSP45b:UEa31は、サービスID、KSI_p, UEaのID及びセッション鍵導出に関するアルゴリズムを用いて、ProSe通信設定をUEb32及びUEc33のそれぞれへ送信する。このメッセージは、Kpiを用いて保護された整合性である。
SP46:UEb32及びUEc33は、それぞれ、ProSeサーバ34から受信したKpから、同一のセッション鍵Kpc及びKpiを導出する。UEb32及びUEc33は、SP45a及びSP45bでそれぞれ受信したKSI_p及びサービスIDに応じて、どのKpが使用されるものかを判定できる。
SP47:UEb32及びUEc33は、導出されたKpiを用いてSP45a及びSP45bでそれぞれ受信したメッセージの整合性検査を行う。UEb32及びUEc33は、UEaのID及びサービスIDがSP43a及びSP43bで受信されたものと同じか否かもさらに検査できる。
SP48a及びSP48b:SP47における検証が成功した場合、UEb32及びUEc33は、それぞれ、UEa31へ、サービスID及びUEb/UEcのIDを用いてProSe通信受理を送信する。本メッセージは、Kpiを用いて保護された整合性である。SP50へ進む。
SP49a及びSP49b:SP47における検証が失敗した場合、UEb32及びUEc33は、それぞれ、UEa31へ、サービスID、UEb/UEcのID及び正確な原因を用いてProSe通信却下を送信する。
SP50:UEa31は、Kpiを用いてProSe通信受理の整合性検査を実行する。UEa31は、UEb/UEcのID及びサービスIDもさらに検査できる。検証が成功して完了した場合、その後、直接通信は開始できる。
SP51:直接通信は、UEa31及びUEb32、又は、UEa31及びUEc33の間で開始する。本メッセージは、セッション鍵Kpc及びKpiにより保護される機密性及び/又は整合性であり得る。
【0111】
以下は、受信UE(UEb32、UEc33)がProSeサーバ34への登録時にKpを受信するというオプション2である。このオプションでは、ProSeサーバ34は、受信UE(UEb32、UEc33)のそれぞれへProSeサービス結果を送信する必要がない。このことは、直接通信のためにグループ内の多くのUEが存在する場合に、ネットワークリソースを確保する。
【0112】
図8は、本発明の実施形態にかかるオプション2の一対多通信を示すシーケンス図である。
図8に示すように、本方法は、次の10ステップを備える。
【0113】
SP60:UEがProSeサーバ34に登録される時にKpはUEに割り当てられる。UEa31、UEb32及びUEc33cは、それぞれ、鍵導出アルゴリズムを用いて事前設定される。
SP61:ProSeサーバ34は、UEa31へ、ProSeサービス結果内のKSI_p、許可UEのUEIDリスト及びサービスIDを送信する。
SP62:UEa31は、Kpからセッション鍵Kpc及びKpiを導出する。
SP63:UEa31は、サービスID、UEaのID、UEIDリスト及びKSI_pを用いて、ProSe通信設定をUEIDリスト内のUEへブロードキャストする。このメッセージは、Kpiを用いて保護された整合性である。
SP64:ブロードキャストメッセージを受信したUEは、それがリスト上にあるか否かを確認し、Kpから、同一のセッション鍵Kpc及びKpiを導出する。UEは、SP63で受信したKSI_p及びサービスIDに応じて、どのKpが使用されるものかを判定できる。
SP65:UEb32及びUEc33は、導出されたKpiを用いてブロードキャストメッセージの整合性検査を行う。UEb32及びUEc33は、それぞれ、事前設定された基準が存在する場合に、UEaのID及びサービスIDもさらに検査できる。
SP66a及びSP66b:検証が成功した場合、UEb32及びUEc33は、それぞれ、UEa31へ、サービスID及びUEb/UEcのIDを用いてProSe通信受理を送信する。本メッセージは、Kpiを用いて保護された整合性である。SP68へ進む。
SP67a及びSP67b:検証が失敗した場合、UEb32及びUEc33は、それぞれ、UEa31へ、サービスID、UEb/UEcのID及び正確な原因を用いてProSe通信却下を送信する。
SP68:UEa31は、Kpiを用いてProSe通信受理の整合性検査を実行する。UEa31は、UEb/UEcのID及びサービスIDもさらに検査できる。検証が成功して完了した場合、その後、直接通信は開始できる。
SP69:直接通信は、UEa31及びUEb32、又は、UEa31及びUEc33の間で開始する。本メッセージは、セッション鍵Kpc及びKpiにより保護される機密性及び/又は整合性であり得る。
【0114】
[[ケース3C]]多対多通信
多対多通信では、各UEは、グループ内の任意の他のUEと通信できる。
図9は、本発明の実施形態にかかる多対多通信を示すシーケンス図である。
図9に示すように、本方法は、次の10ステップを備える。
【0115】
SP70:UEがProSeサーバ34に登録される時にKpはUEに割り当てられる。UEa31、UEb32及びUEn33nは、それぞれ、鍵導出アルゴリズムを用いて事前設定される。
SP71:ProSeサーバ34は、UEa31へ、ProSeサービス結果内のKSI_p、許可UEのUEIDリスト及びサービスIDを送信する。
SP72:UEa31は、Kpからセッション鍵Kpc及びKpiを導出する。
SP73:UEa31は、サービスID、UEaのID、UEIDリスト及びKSI_pを用いて、ProSe通信設定をUEIDリスト内のUEへブロードキャストする。このメッセージは、Kpiを用いて保護された整合性である。
SP74:ブロードキャストメッセージを受信したUEは、それぞれ、それがリスト上にあるか否かを確認し、Kpから、同一のセッション鍵Kpc及びKpiを導出する。UEは、SP73でそれぞれ受信したKSI_p及びサービスIDに応じて、どのKpが使用されるものかを判定できる。
SP75:UEb32及びUEn33nは、それぞれ、導出されたKpiを用いてブロードキャストメッセージの整合性検査を行う。UEb32及びUEn33nは、それぞれ、事前設定された基準が存在する場合に、UEaのID及びサービスIDもさらに検査できる。
SP76a及びSP76b:検証が成功した場合、UEb32及びUEn33nは、それぞれ、UEa31へ、サービスID及びUEb/UEnのIDを用いてProSe通信受理を送信する。本メッセージは、Kpiを用いて保護された整合性である。SP78へ進む。
SP77a及びSP77b:検証が失敗した場合、UEb32及びUEn33nは、それぞれ、UEa31へ、サービスID、UEb/UEnのID及び正確な原因を用いてProSe通信却下を送信する。
SP78:UEa31は、Kpiを用いてProSe通信受理の整合性検査を実行する。UEa31は、UEb/UEnのID及びサービスIDもさらに検査できる。検証が成功して完了した場合、その後、直接通信は開始できる。
SP79:直接通信は、UEの間で開始する。本メッセージは、セッション鍵Kpc及びKpiにより保護される機密性及び/又は整合性であり得る。
【0116】
上記説明を要約すると、本実施の形態にかかる認証及び承認を行う方法は以下の特徴を備える:
(1)UE直接通信に関する新しい鍵階層:Kp並びにセッション鍵Kpc及びKpi。Kpcは、暗号化のためであり、Kpiは整合性保護のためである。Kpc及びKpiは、Kpから導出される。
(2)UEが同期を保持し、鍵が要求されたサービスについて正確であるか否かを検証するように、Kpは鍵識別子KSI_p及びサービスIDにも関連する。
(3)UEがProSeサーバ又はProSeサービス結果メッセージ内に登録される場合、ProSeサーバは、KpをUEへ分配する。
(4)UEは、セッション鍵導出のためのアルゴリズムを用いて事前設定される。KSI_p、サービスID及び示されたアルゴリズムにより、受信UEは、同じセッション鍵を導出できる。
(5)受信UEが整合性検査を実行し、メッセージが承認されたソースからであるか否かを検証できるように、整合性鍵Kpiは、要求UEからの通信要求を保護するために使用される。
(6)受信UEは、サービスID、要求ID及び鍵の全てが一致するか否かも検証できる。
(7)ProSe通信受理は、要求UEがその整合性を検証できるような受信UEにより保護された整合性である。
(8)UE間の直接通信は、セッション鍵Kpc及びKpiを用いて保護された機密性及び/又は整合性であり得る。
【0117】
本発明の実施形態にかかるセキュアシステムによれば、ネットワーク要素ProSeサーバから分配される鍵は、直接通信を確立することを望むUEに、他のUEがサービスを有するために承認されるか否かを検証させることができる。それらがあるUEが別のものへ送信される場合、UEは、鍵が盗まれ又は改ざんされることを防ぐことができる側において、セッション鍵を導出する。Kpは、それらが有することを承認されない他のサービスのための鍵をUEに使用されることを防ぐ、あるサービスに関連する。UE間の直接通信は、UE間でのみ共有されるセッション鍵を用いて保護され得る。
【0118】
本プログラムは、様々なタイプの非一時的なコンピュータ可読媒体(non-transitory computer readable media)を用いて格納され、コンピュータに供給することができる。
非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体(tangible storage media)を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体(例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ)、光磁気記録媒体(例えば光磁気ディスク)、CD-ROM(Read Only Memory)、CD-R(compact disc recordable)、CD-R/W(compact disc rewritable)、半導体メモリ(例えば、マスクROM、PROM(Programmable ROM)、EPROM(Erasable PROM)、フラッシュROM、RAM(Random Access Memory))を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体(transitory computer readable media)によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、(電線及び光ファイバ等の)有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給するために使用され得る。
【0119】
本出願は、2013年6月28日に出願された日本国特許出願第2013-137293号からの優先権の利益を主張し、該特許出願の開示は参照によりその全体が本明細書に援用される。
【符号の説明】
【0120】
1 セキュアシステム
10 システム
11 UE
12 UE
13 E-UTRAN
14 EPC
15 ProSe機能
16 ProSe APPサーバ
17 ProSe APP
18 ProSe APP
19 eNB
20 eNB
21 UEa
22 UEb
31 UEa
32 UEb
33 UEc
33n UEn
34 ProSeサーバ
36 オペレータネットワーク
100 UE
100a システム
100b システム
200 ネットワーク
L01 要求UE
L02 オペレータネットワーク
L03 受信UE
L1 セキュアグループ管理
L2 セキュアディスカバリ
L3 初期承認
L4 認証
L5 承認
L6 セキュリティ接続確立
L7 セキュア通信
L8 ターミネーション