特許 6837609 デバイスツーデバイス通信ネットワークにおけるエンドツーエンドのセキュア通信のためのシステム及び方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B1)

(11)【特許番号】6837609

(24)【登録日】2021年2月12日

(45)【発行日】2021年3月3日

(54)【発明の名称】デバイスツーデバイス通信ネットワークにおけるエンドツーエンドのセキュア通信のためのシステム及び方法

(51)【国際特許分類】

   H04W 12/03 20210101AFI20210222BHJP

   H04W 92/18 20090101ALI20210222BHJP

【ＦＩ】

   H04W12/02

   H04W92/18

【請求項の数】15

【全頁数】27

(21)【出願番号】特願2020-537016(P2020-537016)

(86)(22)【出願日】2018年12月21日

(86)【国際出願番号】EP2018086690

(87)【国際公開番号】WO2019134868

(87)【国際公開日】20190711

【審査請求日】2020年9月11日

(31)【優先権主張番号】62/613,439

(32)【優先日】2018年1月4日

(33)【優先権主張国】US

(31)【優先権主張番号】18154579.9

(32)【優先日】2018年2月1日

(33)【優先権主張国】EP

【早期審査対象出願】

(73)【特許権者】

【識別番号】516043960

【氏名又は名称】シグニファイ ホールディング ビー ヴィ

【氏名又は名称原語表記】ＳＩＧＮＩＦＹ ＨＯＬＤＩＮＧ Ｂ．Ｖ．

(74)【代理人】

【識別番号】100163821

【弁理士】

【氏名又は名称】柴田 沙希子

(72)【発明者】

【氏名】ツァン ユ―ティン

(72)【発明者】

【氏名】ユー ジン

(72)【発明者】

【氏名】ジャン ダン

(72)【発明者】

【氏名】ハン ドン

【審査官】 石田 信行

(56)【参考文献】

【文献】 特表２０１８−５１４０９２（ＪＰ，Ａ）

【文献】 特開２０１８−８５７７０（ＪＰ，Ａ）

【文献】 特表２０１７−５１９４４２（ＪＰ，Ａ）

【文献】 米国特許出願公開第２０１６／０３７３２５７（ＵＳ，Ａ１）

【文献】 米国特許出願公開第２０１５／０３８２１８９（ＵＳ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｗ ４／００ − ９９／００

Ｈ０４Ｂ ７／２４ − ７／２６

３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１−４

ＳＡ ＷＧ１−４

ＣＴ ＷＧ１，４

(57)【特許請求の範囲】

【請求項1】

送信者ユーザデバイス、受信者ユーザデバイス、及び複数の中継ユーザデバイスを含む複数のユーザデバイス間のエンドツーエンドのセキュアデバイスツーデバイス（Ｄ２Ｄ）通信を実行する方法であって、
前記ユーザデバイスの各々の公開鍵及び秘密鍵を設けるステップであって、各ユーザデバイスの秘密鍵は、当該秘密鍵に対応する公開鍵によって暗号化されたデータを解読するように構成される、ステップと、
前記送信者ユーザデバイスによって、自身の秘密鍵を使用してデジタル署名を作成するステップと、
前記送信者ユーザデバイスによって、前記受信者ユーザデバイスの公開鍵及び前記中継ユーザデバイスのうちの第１の中継ユーザデバイスの公開鍵を使用してデータ送信を二重暗号化するステップであって、前記データ送信は前記デジタル署名を含む、ステップと、
前記送信者ユーザデバイスから、前記第１の中継ユーザデバイスで始まる前記複数の中継ユーザデバイスを介した、前記受信者ユーザデバイスへのチェーンで前記データ送信を送信するステップであって、前記中継ユーザデバイスの各々について、前記送信するステップは、
前記データ送信を受信するステップと、
自身の秘密鍵を使用して前記データ送信の第１の暗号化層を解読するステップと、
前記チェーン内の前記ユーザデバイスのうちの後続するユーザデバイスの公開鍵を使用して前記データ送信を暗号化するステップと、
前記データ送信を前記後続するユーザデバイスに転送するステップと、
を含む、ステップと、
前記受信者ユーザデバイスによって、前記送信者ユーザデバイスの公開鍵を使用して前記送信者ユーザデバイスの前記デジタル署名を認証するステップと、
前記デジタル署名が認証される場合、前記送信者ユーザデバイス及び前記受信者ユーザデバイス間のＤ２Ｄ通信を実行するステップと、
を含む、方法。

【請求項2】

当該方法は、
無線通信ネットワークに基地局を設けるステップと、
ユーザデバイスが無線ネットワークを介して近接サービスアプリケーションサーバと通信する場合前記ユーザデバイスを前記近接サービスアプリケーションサーバに登録するステップと、
前記近接サービスアプリケーションサーバと通信する鍵サーバモジュールを使用して公開鍵、秘密鍵、又は両方を管理するステップと、
を含む、請求項１に記載の方法。

【請求項3】

前記管理するステップは、公開鍵を生成すること、秘密鍵を生成すること、又は両方を含む、請求項２に記載の方法。

【請求項4】

前記管理するステップは、公開鍵をメモリに格納すること、及び要求に応じて前記近接サービスアプリケーションサーバ又は前記ユーザデバイスに公開鍵を提供すること、並びに、秘密鍵を格納しないこと、又は秘密鍵が鍵サーバモジュールによって格納される場合秘密鍵を共有しないことを含む、請求項２に記載の方法。

【請求項5】

前記ユーザデバイスの少なくとも１つは、前記送信するステップの間前記無線ネットワークに接続されない、請求項２に記載の方法。

【請求項6】

前記ユーザデバイスのいずれも、前記送信するステップの間前記無線ネットワークに接続されない、請求項５に記載の方法。

【請求項7】

前記ユーザデバイスの少なくとも１つは、公開鍵及び秘密鍵の複数の対に関連付けられ、各対は、異なる所望のセキュリティレベルに関連付けられる、請求項１に記載の方法。

【請求項8】

前記異なる所望のセキュリティレベルは、送信されるデータの異なる意図された受信者を有する、前記ユーザデバイスにインストールされた異なるアプリケーション、又はこれらの少なくとも１つを含む組み合わせに関連付けられる、請求項７に記載の方法。

【請求項9】

前記実行するステップは、前記送信者ユーザデバイス及び前記受信者ユーザデバイスと、Ｄ２Ｄ通信を解読するために必要な計算能力を低減するために前記送信者ユーザデバイス及び前記受信者ユーザデバイスの公開鍵よりも複雑でない対称シークレット鍵をネゴシエートすることを含む、請求項１に記載の方法。

【請求項10】

送信者ユーザデバイス、受信者ユーザデバイス、及び複数の中継ユーザデバイスを含む複数のユーザデバイスを含む、エンドツーエンドのセキュアデバイスツーデバイス（Ｄ２Ｄ）通信を可能にするためのシステムであって、
各ユーザデバイスは、
前記ユーザデバイスのうちの他のユーザデバイスを検出する、及びユーザデバイス間のＤ２Ｄ通信を可能にするように構成される近接サービスアプリケーションと、
前記近接サービスアプリケーションと通信する鍵アプリケーションモジュールであって、各ユーザデバイスの公開鍵及び秘密鍵を管理するように構成され、各ユーザデバイスの秘密鍵は、当該秘密鍵に対応する公開鍵によって暗号化されたデータを解読するように構成される、鍵アプリケーションモジュールと、
を有する、システムであり、
前記ユーザデバイスは、前記複数の中継ユーザデバイスを含むチェーンを介した前記送信者ユーザデバイス及び前記受信者ユーザデバイス間のＤ２Ｄ通信を可能にするように構成され、
前記送信者ユーザデバイスは、前記受信者ユーザデバイスの公開鍵及び前記中継ユーザデバイスのうちの第１の中継ユーザデバイスの公開鍵を使用してデータ送信を二重暗号化するように構成され、前記データ送信は、前記送信者ユーザデバイスのデジタル署名を含み、
各中継ユーザデバイスは、前記データ送信が受信される場合自身の秘密鍵を使用して前記データ送信から第１の暗号化層を解読する、前記チェーン内の前記ユーザデバイスのうちの後続するユーザデバイスの公開鍵を使用して前記データ送信を暗号化する、及び前記データ送信を前記チェーン内の前記後続するユーザデバイスに転送するように構成され、
前記受信者ユーザデバイスは、自身の秘密鍵を使用して前記データ送信を解読する、及び前記送信者ユーザデバイスの公開鍵を使用して前記デジタル署名の正当性を検証するように構成される、システム。

【請求項11】

前記ユーザデバイスは、セルラー通信ネットワークを介して通信するモバイル通信デバイスである、請求項１０に記載のシステム。

【請求項12】

前記鍵アプリケーションモジュールは、公開鍵及び秘密鍵を生成するように構成される、請求項１０に記載のシステム。

【請求項13】

各ユーザデバイスは、公開鍵及び秘密鍵の複数の対に関連付けられ、各対は、異なる所望のセキュリティレベルに関連付けられる、請求項１０に記載のシステム。

【請求項14】

当該システムは、
前記複数のユーザデバイスのための無線ネットワークを生成するように構成される基地局と、
前記無線ネットワークに接続されるユーザデバイスを登録するように構成される近接サービスアプリケーションサーバと、
前記近接サービスアプリケーションサーバと通信する鍵サーバモジュールであって、公開鍵、秘密鍵又は両方を管理するように構成される、鍵サーバモジュールと、
を含む、請求項１０に記載のシステム。

【請求項15】

前記ユーザデバイスの少なくとも１つは、前記基地局と通信しない、請求項１４に記載のシステム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、一般に、デバイスツーデバイス（Ｄ２Ｄ：device-to-device）通信ネットワークにおけるエンドツーエンドのセキュア通信(end-to-end secure communication)を提供するためのシステム及び方法に関する。

【背景技術】

【0002】

消費者は、速度、信頼性、機能性、カバレッジ等の面でセルラー通信テクノロジの絶え間ない進歩から恩恵を受けてきた。しかしながら、新しい技術は新しいリスクをもたらし、とりわけＩＤ及びデータの盗難は現実の増加する脅威を与えるため、これらのテクノロジが実装される場合対処されなければならない。セルラーネットワークを介したデバイスツーデバイス（Ｄ２Ｄ）通信は、そのようなテクノロジの進歩の１つであるが、Ｄ２Ｄ通信対応のユーザデバイス（代替的には、「ユーザ機器(user equipment)」又は「ＵＥ」）を新しいセキュリティの脅威にさらす。

【0003】

より具体的には、セルラーＤ２Ｄ通信は、アクセスポイント又は基地局等の固定又は集中型ネットワークインフラストラクチャなしでデバイスが直接通信することを可能にする新興タイプのワイヤレステクノロジである。免許不要帯域(unlicensed spectrum)で動作する、Ｂｌｕｅｔｏｏｔｈ、ＷｉＦｉ−Ｄｉｒｅｃｔ、ＮＦＣ(Near Field Communication)等の、他のＤ２Ｄテクノロジとは異なり、セルラーＤ２Ｄ通信は、とりわけ、ＬＴＥ−Ａｄｖａｎｃｅｄ（ＬＴＥ−Ａ）等の既存の通信標準を利用するセルラーネットワークと同じ帯域(spectrum)で動作する制御又は制約されたアンダーレイネットワークとして開発されている。

【0004】

Ｄ２Ｄ通信を実装するためのいくつかの規格が確立されている。例えば、図１は、３ＧＰＰ(3rd Generation Partnership Project)によって提案されたＤ２Ｄ通信システムアーキテクチャのＬＴＥ標準を示しており、これは、一般に携帯電話業界の人々によって理解されており、ここでは詳細に述べられない。しかしながら、特に注目すべきは、Ｄ２Ｄ通信がインターフェースＰＣ５を介して行われることを理解されたい。

【0005】

既存のシステムは、パーシャルカバレッジ(partial-coverage)又はアウトオブカバレッジ(out-of-coverage)シナリオ（すなわち、少なくとも一部又はすべてのデバイスが基地局又は他のネットワークインフラストラクチャの通信範囲内にない）等、さまざまな状況で十分なレベルのセキュリティを提供しない。なぜなら、偽のＩＤの作成(creating fake identities)、盗聴(eavesdropping)、なりすまし(impersonation)、データ傍受(data interception)、ユーザ改ざん(user manipulation)、プライバシー侵害(privacy invasion)等により、他のＵＥへの直接通信で攻撃を試みる可能性のある悪意のあるユーザから正当なユーザを認証する(authenticate)ことはより困難であるからである。また、既存のシステムは、データが複数の中間ユーザデバイスを介して中継されなければならない「マルチホップ」シナリオでのセキュリティに対処していない。このようなマルチホップシナリオでは、中間の中継ユーザデバイスが、データを妨害されずに目的の受信者に渡すのではなく、傍受して取得しようとする可能性があるため、セキュリティが保証されることができない。

【発明の概要】

【発明が解決しようとする課題】

【0006】

したがって、新興テクノロジ、とりわけ、複数のユーザデバイスを含むＤ２Ｄ通信ネットワークにおける通信のセキュリティを向上させる方法及びシステムが、当技術分野において引き続き必要とされている。

【課題を解決するための手段】

【0007】

本開示は、デバイスツーデバイス通信ネットワークにおけるエンドツーエンドのセキュア通信を確実にするための発明方法及びシステムに関する。本明細書における様々な実施形態及び実装形態は、Ｄ２Ｄ通信に従事することを望む複数のユーザデバイスを含む通信システムに関する。ユーザデバイスは、各ユーザデバイスの近接サービスアプリケーション(proximity service application)に関連付けられる鍵アプリケーションモジュール(key application module)を含む。各ユーザデバイスの鍵アプリケーションモジュールは、当該ユーザデバイスの公開及び秘密暗号鍵（「鍵」）の非対称対を管理し、近接サービスアプリケーションは、ユーザデバイスが他のユーザデバイスを検出し、Ｄ２Ｄ通信に従事することを可能にする。２つのユーザデバイスは、第１の（送信者(sender)）ユーザデバイスが自身の秘密鍵を使用してデジタル署名を作成し、第２の（受信者(recipient)）ユーザデバイスの公開鍵を使用して送信（又は「データ」）を暗号化する認証プロセスでそれら自身を認証することにより通信を開始してもよい。第２の（受信者）ユーザデバイスは、自身独自の秘密鍵を使用して送信を解読し、第１の（送信者）ユーザデバイスの公開鍵を使用してデジタル署名を検証することができる。

【0008】

指定されたネットワークコンポーネントは、特定のネットワークにユーザデバイスを登録する、及び１つ以上のユーザデバイスがこれらのコンポーネントとネットワークカバレッジ内にある場合にユーザデバイス間のＤ２Ｄ通信を促進する(facilitating)ことを支援する近接サービス機能(proximity service function)及び近接サービスアプリケーションサーバ(proximity service application server)を含んでもよい。鍵サーバモジュール(key server module)がまた、公開鍵及び秘密鍵を生成する、格納する、割り当てる、及び／又は管理することを支援するために含まれてもよい。

【0009】

１つ以上のユーザデバイスは、送信者ユーザデバイス及び受信者ユーザデバイスが互いに直接検出することができないが、１つ以上の他のユーザデバイスが検出できる場合中継器(relay)として機能してもよい。複数の中継が必要な場合、前述の認証に加えて、送信者ユーザデバイスは、受信側(receiving)、すなわち、受信者デバイスの公開鍵及び第１の中継ユーザデバイスの公開鍵の両方を使用して送信を二重暗号化してもよい。この場合、第１の中継デバイスは、第１の暗号化層(first layer of encryption)を解読し、後続する中継ユーザデバイス(subsequent relay user device)の公開鍵を使用して送信を再暗号化することができる。二重暗号化の１つの層を解読し、再度二重暗号化するこのプロセスは、送信が所望の受信者、すなわち、受信者ユーザデバイスに到達するまでチェーン内の隣接する中継ユーザデバイスの各対で継続することができ、受信者ユーザデバイスは、自身の秘密鍵を使用して元の暗号化層(original layer of encryption)を解読することができる。

【0010】

現在開示されている実施形態は、悪意のある盗聴(malicious eavesdropping)、ＩＤ偽造(identity fabrication)及びユーザ改ざん(user manipulation)を防止するために、エンドツーエンド通信を認証する及びエンドツーエンド送信を暗号化するために各ユーザデバイスの公開鍵及び秘密鍵の対を使用して非対称セキュリティを管理する鍵アプリケーションモジュール及び鍵サーバモジュールを使用することによってセキュリティの脅威に対処している。鍵サーバモジュール及び鍵アプリケーションモジュールは、Ｄ２Ｄ通信におけるプライバシーを保護するために、データ送信におけるさまざまなレベルの個人情報に提供される保護の範囲を制限する個別化されたセキュリティ及びセンシティビティレベル(differential security and sensitivity level)を割り当てることができる。

【0011】

一般に、一態様では、複数のユーザデバイス間のエンドツーエンドのセキュアデバイスツーデバイス（Ｄ２Ｄ）通信を実行する方法が含まれる。複数のユーザデバイスは、送信者ユーザデバイス、受信者ユーザデバイス、及び複数の中継ユーザデバイスを含む。当該方法は、ユーザデバイスの各々の公開鍵及び秘密鍵を設けるステップであって、各ユーザデバイスの秘密鍵は、当該秘密鍵に対応する公開鍵によって暗号化されたデータを解読するように構成される、ステップと、送信者ユーザデバイスによって、自身の秘密鍵を使用してデジタル署名を作成するステップと、送信者ユーザデバイスによって、受信者ユーザデバイスの公開鍵及び中継ユーザデバイスのうちの第１の中継ユーザデバイスの公開鍵を使用してデータ送信を二重暗号化するステップであって、データ送信はデジタル署名を含む、ステップと、送信者ユーザデバイスから、第１の中継ユーザデバイスで始まる複数の中継ユーザデバイスを介した、受信者ユーザデバイスへのチェーンでデータ送信を送信するステップであって、中継ユーザデバイスの各々について、送信するステップは、データ送信を受信するステップと、自身の秘密鍵を使用してデータ送信の第１の暗号化層を解読するステップと、チェーン内のユーザデバイスのうちの後続するユーザデバイスの公開鍵を使用してデータ送信を暗号化するステップと、データ送信を後続するユーザデバイスに転送するステップとを含む、ステップと、受信者ユーザデバイスによって、送信者ユーザデバイスの公開鍵を使用して送信者ユーザデバイスのデジタル署名を認証するステップと、デジタル署名が認証される場合、送信者ユーザデバイス及び受信者ユーザデバイス間のＤ２Ｄ通信を実行するステップとを含む。

【0012】

一実施形態によれば、当該方法はさらに、無線通信ネットワークに基地局を設けるステップと、ユーザデバイスが無線ネットワークを介して近接サービスアプリケーションサーバ(proximity service application server)と通信する場合ユーザデバイスを近接サービスアプリケーションサーバに登録するステップと、近接サービスアプリケーションサーバと通信する鍵サーバモジュール(key server module)を使用して公開鍵、秘密鍵、又は両方を管理するステップとを含む。

【0013】

一実施形態によれば、管理するステップは、公開鍵を生成すること、秘密鍵を生成すること、又は両方を含む。一実施形態によれば、管理するステップは、公開鍵をメモリに格納すること、及び要求に応じて近接サービスアプリケーションサーバ又はユーザデバイスに公開鍵を提供すること、並びに、秘密鍵を格納しないこと、又は秘密鍵が鍵サーバモジュールによって格納される場合秘密鍵を共有しないことを含む。

【0014】

一実施形態によれば、ユーザデバイスの少なくとも１つは、送信するステップの間無線ネットワークに接続されない。さらなる実施形態によれば、ユーザデバイスのいずれも、送信するステップの間無線ネットワークに接続されない。一実施形態によれば、ユーザデバイスの少なくとも１つは、公開鍵及び秘密鍵の複数の対に関連付けられ、各対は、異なる所望のセキュリティレベルに関連付けられる。さらなる実施形態によれば、異なる所望のセキュリティレベルは、送信されるデータの異なる意図された受信者を有する、ユーザデバイスにインストールされた異なるアプリケーション、又はこれらの少なくとも１つを含む組み合わせに関連付けられる。

【0015】

一実施形態によれば、実行するステップはさらに、送信者ユーザデバイス及び受信者ユーザデバイスと、Ｄ２Ｄ通信を解読するために必要な計算能力を低減するために送信者ユーザデバイス及び受信者ユーザデバイスの公開鍵よりも複雑でない対称シークレット鍵(symmetric secret key)をネゴシエートすることを含む。

【0016】

一態様によれば、エンドツーエンドのセキュアデバイスツーデバイス（Ｄ２Ｄ）通信を可能にするためのシステムも提供される。当該システムは、送信者ユーザデバイス、受信者ユーザデバイス、及び複数の中継ユーザデバイスを含む複数のユーザデバイスを含み、各ユーザデバイスは、ユーザデバイスのうちの他のユーザデバイスを検出する、及びユーザデバイス間のＤ２Ｄ通信を可能にするように構成される近接サービスアプリケーション(proximity service application)（１４）と、近接サービスアプリケーションと通信する鍵アプリケーションモジュール(key application module)（１８）であって、各ユーザデバイスの公開鍵及び秘密鍵を管理するように構成され、各ユーザデバイスの秘密鍵は、当該秘密鍵に対応する公開鍵によって暗号化されたデータを解読するように構成される、鍵アプリケーションモジュールとを有する、システムであり、ユーザデバイスは、複数の中継ユーザデバイスを含むチェーンを介した送信者ユーザデバイス及び受信者ユーザデバイス間のＤ２Ｄ通信を可能にするように構成され、送信者ユーザデバイスは、受信者ユーザデバイスの公開鍵及び中継ユーザデバイスのうちの第１の中継ユーザデバイスの公開鍵を使用してデータ送信を二重暗号化するように構成され、データ送信は、送信者ユーザデバイスのデジタル署名を含み、各中継ユーザデバイスは、データ送信が受信される場合自身の秘密鍵を使用してデータ送信から第１の暗号化層を解読する、チェーン内のユーザデバイスのうちの後続するユーザデバイスの公開鍵を使用してデータ送信を暗号化する、及びデータ送信をチェーン内の後続するユーザデバイスに転送するように構成され、受信者ユーザデバイスは、自身の秘密鍵を使用してデータ送信を解読する、及び送信者ユーザデバイスの公開鍵を使用してデジタル署名の正当性(authenticity)を検証するように構成される。

【0017】

一実施形態によれば、ユーザデバイスは、セルラー通信ネットワークを介して通信するモバイル通信デバイスである。一実施形態によれば、鍵アプリケーションモジュールは、公開鍵及び秘密鍵を生成するように構成される。一実施形態によれば、各ユーザデバイスは、公開鍵及び秘密鍵の複数の対に関連付けられ、各対は、異なる所望のセキュリティレベルに関連付けられる。

【0018】

一実施形態によれば、当該システムはさらに、複数のユーザデバイスのための無線ネットワークを生成するように構成される基地局（１６）と、無線ネットワークに接続されるユーザデバイスを登録するように構成される近接サービスアプリケーションサーバ(proximity service application server)（２０）と、近接サービスアプリケーションサーバと通信する鍵サーバモジュール(key server module)（２４）であって、公開鍵、秘密鍵又は両方を管理するように構成される、鍵サーバモジュールとを含む。一実施形態によれば、ユーザデバイスの少なくとも１つは、基地局と通信しない。

【0019】

様々な実装形態では、プロセッサ又はコントローラは、１つ以上の記憶媒体（本明細書では「メモリ」と総称される、例えば、ＲＡＭ、ＰＲＯＭ、ＥＰＲＯＭ、及びＥＥＰＲＯＭなどの、揮発性及び不揮発性のコンピュータメモリ、フロッピーディスク、コンパクトディスク、光ディスク、磁気テープなど）に関連付けられてもよい。一部の実装形態では、これらの記憶媒体は、１つ以上のプロセッサ及び／又はコントローラ上で実行されると、本明細書で論じられる機能の少なくとも一部を実行する、１つ以上のプログラムでエンコードされてもよい。様々な記憶媒体は、プロセッサ又はコントローラ内に固定されてもよく、あるいは、それらの記憶媒体上に記憶されている１つ以上のプログラムが、本明細書で論じられる本発明の様々な態様を実施するために、プロセッサ又はコントローラ内にロードされることができるように、可搬性であってもよい。用語「プログラム」又は「コンピュータプログラム」は、本明細書では、１つ以上のプロセッサ又はコントローラをプログラムするために採用されることが可能な、任意のタイプのコンピュータコード（例えば、ソフトウェア又はマイクロコード）を指すように、一般的な意味で使用される。

【0020】

本明細書で使用される用語「ネットワーク」は、任意の２つ以上のデバイス間での、及び／又はネットワークに結合された複数のデバイスの間での、（例えば、デバイス制御、データ記憶、データ交換等のための）情報の転送を容易にする、（コントローラ又はプロセッサを含む）２つ以上のデバイスの任意の相互接続を指す。容易に理解されるように、複数のデバイス、例えば、モバイルフォンを相互接続するために好適なネットワーク、例えば、セルラーネットワークの様々な実装は、様々なネットワークトポロジのうちのいずれかを含み、様々な通信プロトコルのうちのいずれかを採用してもよい。さらに、本明細書で論じられるデバイスの様々なネットワークは、そのネットワーク全体にわたる情報転送を容易にするために、適宜、１つ以上の無線リンク、有線／ケーブルリンク、及び／又は光ファイバリンクを採用してもよい点が、容易に理解されよう。

【0021】

上述の概念と、以下でより詳細に論じられる追加的概念との全ての組み合わせは（そのような概念が互いに矛盾しないという条件下で）、本明細書で開示される発明の主題の一部であると想到される点を理解されたい。特に、本開示の最後に記載されている特許請求される主題の全ての組み合わせは、本明細書で開示される発明の主題の一部であると想到される。また、参照により組み込まれるいずれかの開示にもまた現れ得る、本明細書で明示的に採用されている用語は、本明細書で開示される特定の概念と最も一致する意味が与えられるべきである点も理解されたい。

【図面の簡単な説明】

【0022】

図面中、同様の参照文字は、一般に、異なる図の全体にわたって同じ部分を指す。また、これらの図面は、必ずしも正しい縮尺ではなく、その代わりに、全般的に、本発明の原理を例示することに重点が置かれている。

【図1】図１は、Ｄ２Ｄ通信システムの既知のアーキテクチャを示す。

【図2】図２は、本明細書で開示される一実施形態によるＤ２Ｄ通信システムの概略図である。

【図3A】図３Ａは、本明細書で開示されるＤ２Ｄ通信システムのいずれかのための様々なＤ２Ｄ通信構成を概略的に示す。

【図3B】図３Ｂは、本明細書で開示されるＤ２Ｄ通信システムのいずれかのための様々なＤ２Ｄ通信構成を概略的に示す。

【図3C】図３Ｃは、本明細書で開示されるＤ２Ｄ通信システムのいずれかのための様々なＤ２Ｄ通信構成を概略的に示す。

【図4A】図４Ａは、図２のシステムのための公開鍵及び秘密鍵の生成を実施するための方法を概略的に示す。

【図4B】図４Ｂは、図２のシステムのための公開鍵及び秘密鍵の生成を実施するための方法を概略的に示す。

【図4C】図４Ｃは、図２のシステムのための公開鍵及び秘密鍵の生成を実施するための方法を概略的に示す。

【図5】図５は、図３Ａに示される等のインカバレッジシナリオによる図２に示される等のＤ２Ｄ通信システムを動作させる方法を概略的に示す。

【図6】図６は、Ｄ２Ｄ通信における強化されたセキュリティのためのユーザデバイスを認証する方法を概略的に示す。

【図7】図７は、図３Ｂに示される等のパーシャルカバレッジシナリオによる図２に示される等のＤ２Ｄ通信システムを動作させる方法を概略的に示す。

【図8】図８は、図３Ｃに示される等のアウトオブカバレッジシナリオによる図２に示される等のＤ２Ｄ通信におけるセキュアＤ２Ｄ通信を開始する方法を概略的に示す。

【図9】図９は、図２のシステム等の通信システムにおける間接Ｄ２Ｄ通信を促進するために中継ユーザデバイスを使用する方法を概略的に示す。

【図10】図１０は、マルチホップシナリオにおいて、図２のシステム等の通信システムにおける間接Ｄ２Ｄ通信を促進するために複数の中継ユーザデバイスを使用する方法を概略的に示す。

【図11】図１１は、本明細書に開示される構成要素及び／又は実施形態の多くとして、それらと共に、又はそれらのために利用されることができるコンピュータデバイスを概略的に示す。

【発明を実施するための形態】

【0023】

本開示は、本明細書における様々な実施形態及び実装形態が、Ｄ２Ｄ通信に従事することを望む複数のユーザデバイスを含む通信システムに関することを述べる。ユーザデバイスは、各ユーザデバイスの近接サービスアプリケーション(proximity service application)に関連付けられる鍵アプリケーションモジュール(key application module)を含む。各ユーザデバイスの鍵アプリケーションモジュールは、当該ユーザデバイスの公開及び秘密暗号鍵（「鍵」）の非対称対を管理し、近接サービスアプリケーションは、ユーザデバイスが他のユーザデバイスを検出し、Ｄ２Ｄ通信に従事することを可能にする。２つのユーザデバイスは、第１の（送信者(sender)）ユーザデバイスが自身の秘密鍵を使用してデジタル署名を作成し、第２の（受信者(recipient)）ユーザデバイスの公開鍵を使用して送信（又は「データ」）を暗号化する認証プロセスでそれら自身を認証することにより通信を開始してもよい。第２の（受信者）ユーザデバイスは、自身独自の秘密鍵を使用して送信を解読し、第１の（送信者）ユーザデバイスの公開鍵を使用してデジタル署名を検証することができる。

【0024】

指定されたネットワークコンポーネントは、特定のネットワークにユーザデバイスを登録する、及び１つ以上のユーザデバイスがこれらのコンポーネントとネットワークカバレッジ内にある場合にユーザデバイス間のＤ２Ｄ通信を促進する(facilitating)ことを支援する近接サービス機能(proximity service function)及び近接サービスアプリケーションサーバ(proximity service application server)を含んでもよい。鍵サーバモジュール(key server module)がまた、公開鍵及び秘密鍵を生成する、格納する、割り当てる、及び／又は管理することを支援するために含まれてもよい。

【0025】

１つ以上のユーザデバイスは、送信者ユーザデバイス及び受信者ユーザデバイスが互いに直接検出することができないが、１つ以上の他のユーザデバイスが検出できる場合中継器(relay)として機能してもよい。複数の中継が必要な場合、前述の認証に加えて、送信者ユーザデバイスは、受信側(receiving)、すなわち、受信者デバイスの公開鍵及び第１の中継ユーザデバイスの公開鍵の両方を使用して送信を二重暗号化してもよい。この場合、第１の中継デバイスは、第１の暗号化層(first layer of encryption)を解読し、後続する中継ユーザデバイス(subsequent relay user device)の公開鍵を使用して送信を再暗号化することができる。二重暗号化の１つの層を解読し、再度二重暗号化するこのプロセスは、送信が所望の受信者、すなわち、受信者ユーザデバイスに到達するまでチェーン内の隣接する中継ユーザデバイスの各対で継続することができ、受信者ユーザデバイスは、自身の秘密鍵を使用して元の暗号化層(original layer of encryption)を解読することができる。

【0026】

本発明の開示は、非対称セキュリティＰｒｏＳｅ鍵(asymmetric security ProSe Key)の生成、登録及び配布を管理し、インカバレッジ(in-coverage)、パーシャルカバレッジ及びアウトオブカバレッジシナリオのすべて、またネットワーク中継サービスを必要とするシナリオのためのＵＥ間のセキュア通信の確立を実施するシステム及び方法を述べる。さらに、個別化されたプライバシー及びＵＥモビリティのセキュリティが対処される。

【0027】

図２を参照すると、一実施形態において、デバイスツーデバイス（すなわち「Ｄ２Ｄ」）通信システム１０が、複数のユーザデバイス間の直接通信を可能にするために提供され、それらのうちの２つのユーザデバイスが図示され、参照番号１２ａ及び１２ｂで示されている。Ｄ２Ｄ通信は、音声通話、ビデオ通話、テキストメッセージング、ファイル共有等を含む任意のタイプのデータ送信を含んでもよい。任意の数のユーザデバイスが通信してもよく、「各ユーザデバイス１２」又は「ユーザデバイス１２」に対する本明細書における任意の開示は、一般に、ユーザデバイス１２ａ及び１２ｂの両方、並びにそれらと通信する任意の追加のユーザデバイスに当てはまることを理解されたい。同様のアルファベットサフィックス（例えば、「ａ」及び「ｂ」）が、システム１０及び／又はユーザデバイス１２の他のコンポーネントの特定のインスタンスを参照するために使用される場合があることを理解されたい。ユーザデバイス１２は、「ユーザ機器(user equipment)」又は「ＵＥ」として同義的に参照される場合がある。ユーザデバイス１２は、携帯電話、タブレット若しくは他のハンドヘルドコンピューティングデバイス、並びに自動車等の通信可能なデバイス等の任意の民生用、商用、クライアント若しくは個人用機器、又はスマートシティ、コネクテッドライティングシステム及びモノのインターネット等のシステムの形態をとってもよい。当業者は、本明細書に開示される実施形態を考慮して他の実装形態を認識するであろう。

【0028】

各ユーザデバイス１２は、ユーザデバイス１２が互いに検出し、通信リンク１５を介して直接通信することを可能にする、（ユーザデバイス１２ａ及び１２ｂに対してそれぞれ、参照番号１４ａ及び１４ｂで個別に示される）近接サービスアプリケーション(proximity service application)１４を含む。ユーザデバイス１２はまた、基地局１６等の指定されたネットワークインフラストラクチャと通信し、したがって、基地局１６によって提供されるネットワーク上で通信してもよい。基地局１６の通信範囲内にある場合（すなわち、基地局１６により提供されるネットワークに参加した場合）、ユーザデバイス１２は、接続リンク１７（例えば、図１の３ＧＰＰアーキテクチャに従って実装される場合、インターフェースＵｕ）を介して基地局１６と通信してもよい。

【0029】

通信システム１０は、限定されるものではないが、３ＧＰＰによって指定され、図１に示されるアーキテクチャ等、任意の通信規格、プロトコル、及び／又はアーキテクチャに従って実装されてもよいことを認識されたい。例えば、基地局１６は、Ｅ−ＵＴＲＡＮ(evolved universal mobile telecommunications system terrestrial radio access network)に対応してもよく、又は任意の他の既知の又は発見されたモバイル通信テクノロジを使用してもよい。システム１０が、３ＧＰＰアーキテクチャの一般的なレイアウト及びターミノロジを基本的な出発点として利用して実装される場合、システム１０の機能的及び／又は構造的態様は、図１のものに類似し得ることを理解されたい。例えば、近接サービスアプリケーション１４及び通信リンク１５は、ある点で、一般に、図１のＰｒｏＳｅ Ａｐｐ及びインターフェースＰＣ５にそれぞれ類似又は相当してもよく、斯くして、そのような態様の詳細な説明は、本明細書には含まれないが、それにもかかわらず、当業者には理解されることを理解されたい。

【0030】

各ユーザデバイス１２は、（ユーザデバイス１２ａ及び１２ｂに対してそれぞれ、参照番号１８ａ及び１８ｂで個別に示される）鍵アプリケーションモジュール(key application module)１８を含む。鍵アプリケーションモジュール１８は、非対称暗号学(asymmetric cryptology)に従って送信暗号化及び認証を実施するために各ユーザデバイス１２の秘密鍵及び公開鍵を管理する。「非対称暗号学」とは、１つ以上の選択デバイスにだけ、特に、暗号化されたデータの受信者にプライベートに知られる、対応する秘密鍵なしでは解読されることができない形式でデータを暗号化するために、任意のデバイスに知られ得る公開鍵を使用する暗号化システムを意味する。鍵アプリケーションモジュール１８は、ソフトウェア又はプログラミングコード（及びソフトウェアを実行するための関連ハードウェア）として実装され、近接サービスアプリケーション１４に埋め込まれることができる、又はアプリケーションプログラミングインターフェイス（ＡＰＩ）若しくは他のソフトウェアインターフェイスを介して近接サービスアプリケーション１４にアクセス可能である。公開鍵によって暗号化されたデータは、対応する秘密鍵によってのみ解読されることができる。一実施形態では、秘密鍵によって暗号化されたデータは、公開鍵によってのみ解読されることができる。

【0031】

通信システム１０は、（例えば、ＰｒｏＳｅ Ａｐｐ Ｓｅｒｖｅｒに類似した）近接サービスアプリケーションサーバ(proximity service application server)２０を含む。近接アプリケーションサーバ２０は、（例えば、図１の３ＧＰＰアーキテクチャのＰＣ１に類似した）通信インターフェース又はリンク２２を介した通信を介してユーザデバイス１２の登録を支援するように構成されてもよい。例えば、ユーザデバイス１２の登録は、近接サービスアプリケーション１４が上述のように動作する、すなわち、ユーザデバイス１２が互いに検出及び通信することを可能にすることをトリガし、可能にし、又は認証してもよい。

【0032】

鍵サーバモジュール(key server module)２４が、通信システム１０に登録されるユーザデバイス１２の各々の秘密鍵及び公開鍵の登録及び配布を管理及び維持するために含まれる。近接サービスアプリケーションサーバ２０及び／又は鍵サーバモジュール２４は、特定のネットワークのために指定されたインフラストラクチャ（例えば、基地局等）にローカルに実装されてもよく、又はリモートでアクセスされてもよい（例えば、クラウドに存在してもよい）。一実施形態では、鍵サーバモジュール２４は、近接アプリケーションサーバ２０の一部として形成されるが、いずれにしても、近接アプリケーションサーバ２０とデータ通信する。

【0033】

鍵サーバモジュール２４は、ユーザデバイス１２が近接サービスアプリケーションサーバ２０に登録する場合その秘密鍵及び公開鍵が生成される、割り当てられる、及び／又は共有されることができるように近接サービスアプリケーションサーバ２０と通信する。例えば、一実施形態による通信システム１０へのユーザデバイス１２のうちの１つの登録中、ユーザデバイス１２上の近接サービスアプリケーション１４は、登録要求を近接サービスアプリケーションサーバ２０に送信する。近接サービスアプリケーションサーバ２０は、登録要求に応え、要求を行うユーザデバイス１２に関連する公開鍵及び秘密鍵を生成する及び／又は割り当てるプロセスを開始するように鍵サーバモジュール２４に信号を出す。

【0034】

システム１０は、例えば、図１に示される３ＧＰＰアーキテクチャ等の現在使用されている通信ネットワークシステムとの互換性を可能にするために、オプションで追加のフィーチャ及びコンポーネントを含んでもよいことを理解されたい。例えば、システム１０は、３ＧＰＰアーキテクチャのＵＰＣと同様の機能を可能にするパケットコア２５を含んでもよい。例えば、パケットコア２５は、ホーム加入者サーバ、モビリティ管理エンティティ(mobility management entity)、サービングゲートウェイ及び／又はパケットデータネットワークゲートウェイ等のゲートウェイ等を含んでもよい。当業者は、実装され得るこれら及び他のコンポーネント又はフィーチャを認識するであろう。

【0035】

通信システム１０はまた、近接サービス機能(proximity service function)２６を含んでもよい。近接サービス機能２６は、ある点で、一般に、３ＧＰＰアーキテクチャのＰｒｏＳｅ Ｆｕｎｃｔｉｏｎに類似してもよい。例えば、近接サービス機能２６は、（例えば、図１の３ＧＰＰアーキテクチャに従う場合、インターフェースＰＣ３に相当する）通信リンク２８を利用してユーザデバイス１２と通信してもよい。ユーザデバイス１２の異なるユーザデバイスが異なるネットワークに登録されている場合、近接機能２６、近接サービスアプリケーションサーバ２０、及び／又は鍵サーバモジュール２４は、異なるネットワークの各々に関連付けられているが、互いに通信する、複数のそのようなコンポーネントによって実装されてもよい。

【0036】

例えば、一実施形態では、ユーザデバイス１２ａは、異なるネットワークオペレータに登録されており、ユーザデバイス１２ｂが登録されているネットワークにローミングしている。この実施形態のユーザデバイス１２ａは、最初に、ユーザデバイス１２ｂによって使用される近接サービス機能と比べて固有の近接サービス機能を介して自身の鍵登録プロセスを実行していてもよい。例えば、ユーザデバイス１２ａ及び１２ｂの各々は、それ自身の「ホーム」近接サービス機能に対応してもよい。ユーザデバイスが異なるネットワークにおいてローミングしている場合でも、該デバイスは、上記のように自身がローミングしているネットワークの「ローカル」近接サービス機能にコンタクトすることができる。このユーザデバイスはローミングしているため、例えばゲストとしてこのネットワークに登録する必要があり、「ローカル」近接サービス機能は、ローミングしているユーザデバイスがすでに登録されているローミングしているユーザデバイスの「ホーム」近接サービス機能にコンタクトしてもよい。

【0037】

追加的又は代替的に、近接サービス機能２６は、（例えば、インターフェースＰＣ４に相当する通信リンクを介して）パケットコア２５と、及び（例えば、図１の３ＧＰＰアーキテクチャに従う場合、インターフェースＰＣ２に相当する）通信リンク２９を介して近接サービスアプリケーションサーバ２０と通信してもよい。しかしながら、近接サービス機能２６はさらに、本明細書の開示を考慮して理解されるように、通信システム１０の他のコンポーネントの動作及びそれらの間の通信を支援するように構成されてもよい。例えば、近接サービスアプリケーションサーバ２０は、通信リンク２２を介してユーザデバイス１２の近接サービスアプリケーション１４と直接通信してもよく、又は近接サービス機能２６を通じて通信リンク２８及び２９を介してユーザデバイス１２に間接的に通信してもよい。

【0038】

図３Ａ〜３Ｃは、通信システム、例えば、システム１０が、ユーザデバイス（例えば、ユーザデバイス１２ａ及び１２ｂ）間のＤ２Ｄ通信を可能にするために実装され得る３つの異なるシナリオを提供する。したがって、図３Ａ〜３Ｃの構成は、それぞれ、参照番号１０ａ、１０ｂ、及び１０ｃで示されている。これらの３つの構成は、インカバレッジ(in-coverage)（図３Ａの構成１０ａ）、パーシャルカバレッジ(partial coverage)（図３Ｂの構成１０ｂ）、及びアウトオブカバレッジ(out of coverage)（図３Ｃの構成１０ｃ）を含む。図３Ａ〜３Ｃのユーザデバイス（すなわち、ＵＥ１〜ＵＥ４）は、ユーザデバイス１２（逆の場合も同じ）について開示された、及び本明細書で開示された任意の他のユーザデバイスに関する様々な実施形態のいずれかに従って実装されてもよいことを理解されたい。図３Ａ〜３Ｃの矢印は、通信リンク１５又はインターフェースＰＣ５等のＤ２Ｄ通信リンク又はインターフェースを表す。

【0039】

図３Ａは、複数のユーザデバイス（例えば、ユーザデバイス１２）が、ＵＥ１、ＵＥ２、ＵＥ３、及びＵＥ４として識別され、すべてのユーザデバイスが、（他のネットワークテクノロジが利用されてもよいことを理解されたいが）この実施形態ではＥｖｏｌｖｅｄ Ｎｏｄｅ Ｂ、すなわち、ｅＮＢとして識別される基地局又は他のネットワークインフラストラクチャ（例えば、基地局１６）の（円で囲まれた領域によって示される）通信範囲内にある、インカバレッジＤ２Ｄ通信構成１０ａを示す。ユーザデバイスＵＥ１〜ＵＥ４のすべてがネットワークカバレッジ内にあるので、Ｄ２Ｄ通信は、すべてのデバイス間で、また各デバイスと基地局との間で可能な状態にある。

【0040】

図３ＢのＤ２Ｄ通信構成１０ｂでは、ユーザデバイスＵＥ１及びＵＥ３は基地局ｅＮＢの通信範囲内にあるが、ユーザデバイスＵＥ２及びＵＥ４は通信範囲外にあるため、デバイスＵＥ１は、任意の他方のデバイスと直接通信することができるが、他方のデバイスの各々は、ユーザデバイスＵＥ１とのみ通信することができる。ＵＥ１及びＵＥ３はどちらも基地局ｅＮＢと通信することができる。一部のユーザデバイスはネットワークカバレッジ内にあり、他方はそうではないため、これは、パーシャルカバレッジと呼ばれる。

【0041】

図３ＣのＤ２Ｄ通信構成１０ｃでは、どのユーザデバイスも基地局と通信しないため、この構成は、アウトオブカバレッジと呼ばれる。しかしながら、デバイスＵＥ１〜ＵＥ４のすべては、本明細書で開示されるＤ２Ｄ通信の実施形態のいずれかを利用して互いに直接通信する。

【0042】

図４Ａ〜４Ｃは、鍵生成プロセスが実施され得る３つの異なるアプローチを示す。方法３０が図４Ａに示され、ここでは、鍵アプリケーションモジュール１８及び鍵サーバモジュール２４の両方が、同じ鍵生成／割り当てメカニズム、例えば、同じソフトウェア実装アルゴリズムを認識するようにプログラムされている。方法３０によれば、近接サービスアプリケーション１４が、まずステップ３２で近接サービスアプリケーションサーバ２０に登録を要求する。ステップ３４で、近接サービスアプリケーションサーバ２０は、固有のパラメータのセットで登録要求に応答する。同じ鍵生成メカニズム（例えば、アルゴリズム）及び（ステップ３４で提供される）同じパラメータを使用して、ユーザデバイス１２のうちの対応するユーザデバイスにおける鍵アプリケーションモジュール１８（例えば、ユーザデバイス１２ａのための鍵アプリケーションモジュール１８ａ）は、ステップ３８で当該ユーザデバイス１２に固有の秘密鍵及び公開鍵を生成する。鍵生成メカニズム及びパラメータは、鍵サーバモジュール２４によって知られているので、鍵サーバモジュール２４は、ステップ３６で当該ユーザデバイスのために秘密鍵及び公開鍵の同じセットを生成することができる。

【0043】

方法３０によれば、公開鍵及び秘密鍵の対は、Ｄ２Ｄ通信における認証及び暗号化のためにユーザ側（例えば、鍵アプリケーションモジュール１８）及びサーバ側（例えば、鍵サーバモジュール２４）の両方に別個に管理される。近接サービスアプリケーションサーバ２０及び／又は鍵サーバモジュール２４は、（例えば、他のデバイスが、各公開鍵に対応するユーザデバイスによって受信されることが意図されたデータを暗号化するために公開鍵を使用することができるように）各ユーザデバイス１２に対応する公開鍵をパブリックに共有するように構成されてもよいが、秘密鍵を共有又は通信しないであろう。

【0044】

方法４０が図４Ｂに示され、ここでは、鍵生成メカニズムはサーバ側にのみ存在する（すなわち、鍵アプリケーションモジュール１８は、鍵を生成するためのアルゴリズム又は他の手段で構成されていない）。方法４０では、近接サービスアプリケーション１４が、まず（一般にステップ３２に類似する）ステップ４２で近接サービスアプリケーションサーバ２０に登録を要求する。ステップ４４で、近接サービスアプリケーションサーバ２０は、例えば、当該ユーザデバイスの登録に関連する確認又は他のデータ若しくは情報で、登録要求に応答する。しかしながら、ステップ３４とは異なり、ユーザ側３２のコンポーネント（例えば、鍵アプリケーションモジュール１８）は、パラメータを用いて鍵を生成するように構成されていないので、固有のパラメータは、ステップ４４で伝達される必要はない。

【0045】

ステップ４４で近接サービスアプリケーションサーバ２０で登録プロセスが完了すると、近接サービスアプリケーションサーバ２０は、（一般にステップ３６に類似する）ステップ４６で秘密鍵及び公開鍵の対を生成するように鍵サーバモジュール２４に通知する。しかしながら、方法４０は、方法３０のステップ３８に類似するステップを含まない。なぜなら、鍵アプリケーションモジュール１８は、方法４０においてそれら自身の鍵を生成するように構成されていないからである。したがって、ステップ４８において、鍵サーバモジュール２４は、通信リンク２２を介して近接サービスアプリケーション１４及び／若しくは鍵アプリケーションモジュール１８に、又は通信リンク２８及び２９を介した近接サービス機能２６の支援によりユーザデバイス１２に秘密鍵及び公開鍵を割り当てることができる。

【0046】

第３のアプローチが、図４Ｃに方法５０として例示され、ここでは、鍵生成プロセスはユーザ側にのみ存在する（すなわち、鍵サーバモジュール２４は、鍵を生成するためのアルゴリズム又は他の手段で構成されていない）。本方法は、一般に方法３０及び４０のステップ３２及び４２に類似するステップ５２で始まり、近接サービスアプリケーション１４が、対応するユーザデバイス１２の登録を要求する。近接サービスアプリケーションサーバ２０は、ステップ４４と同様のステップ５４で要求に応答する。近接サービスアプリケーション１４は、ステップ５４で近接サービスアプリケーションサーバ２０から登録応答を受信した場合、ステップ５６で当該ユーザデバイスに対応する秘密鍵及び公開鍵を生成するように鍵アプリケーションモジュール１８に信号を出す。その後、ステップ５８において、鍵アプリケーションモジュール１８は、公開鍵を鍵サーバモジュール２４に送信する。このアプローチによっては、鍵サーバモジュール２４は、ユーザデバイス１２の秘密鍵を知らない。しかしながら、一実施形態では、例えば、ユーザデバイスが紛失、損傷、再フォーマットされた場合等、秘密鍵の回復を容易にするために、秘密鍵も鍵サーバモジュール２４に伝達される。

【0047】

図５は、図３Ａのシナリオ１０ａに示される等、インカバレッジシナリオでエンドツーエンドのＤ２Ｄ通信を実行するための方法６０を示している。方法６０では、第１のユーザデバイスのユーザデバイス１２ａが、第２のユーザデバイス１２ｂとのセキュアＤ２Ｄ通信を確立することを要求する。ここでも、この例で使用されるユーザデバイス１２ａ及び１２ｂは、代替的には、図３ＡのＵＥ１及びＵＥ２、又は図３ＡのＵＥ３及びＵＥ４、又は図３ＢのＵＥ１及びＵＥ３等、インカバレッジにあり、直接通信を欲する任意のユーザデバイスの対であってもよく、又はそう称されてもよい。

【0048】

通信を開始するために、第１のユーザデバイス１２ａは、ステップ６２で、自身の近接サービスアプリケーション１４ａを使用して、通信リンク２８を介してデバイス発見要求を近接サービス機能２６に送信する。ユーザデバイス１２ａ及び１２ｂの両方が（例えば、方法３０、４０、又は５０のいずれかに従って）登録されている場合、近接サービス機能２６は、登録プロセスからの情報（例えば、ユーザデバイス１２ａ及び１２ｂに関連するシリアル番号等）を使用して、（要求を行っている）ユーザデバイス１２ａ及び（通信を要求されている）ユーザデバイス１２ｂの両方を識別することができる。近接サービス機能２６は、ユーザデバイス１２ｂの近接性をチェックし、ステップ６４で鍵サーバモジュール２４にユーザデバイス１２ｂの公開鍵を要求する。

【0049】

鍵サーバモジュール２４は、ステップ６６においてユーザデバイス１２ｂの公開鍵で近接サービス機能２６に応答し、次いで、公開鍵は、ステップ６８でユーザデバイス１２ａに配布される。上述のように、ユーザデバイス１２ａへの公開鍵の配布は、近接サービス機能２６を通じて通信リンク２８及び２９を介して間接的にではなく、通信リンク２２を介して近接サービスアプリケーションサーバ２０から近接サービスアプリケーション１４ａに直接行われてもよい。近接サービス機能２６はまた、この段階で、ユーザデバイス１２ａと１２ｂとの間のＤ２Ｄ通信を可能にするためのスペクトル及び時間リソースを割り当ててもよい。その後、ステップ７０で、ユーザデバイス１２ａの鍵アプリケーションモジュール１８ａは、ステップ６８でユーザデバイス１２ａが受信したユーザデバイス１２ｂの公開鍵を使用して自身の送信を暗号化することができる。次いで、暗号化されたデータは、ステップ７２でユーザデバイス１２ｂに送信される。ユーザデバイス１２ｂは、ステップ７４で自身の秘密鍵を使用して暗号化された送信を解読することができる。

【0050】

ユーザデバイス１２ｂは、ステップ７６で応答してもよい。ユーザデバイス１２ｂが応答する場合、ユーザデバイス１２ｂは、ユーザデバイス１２ａにすでに知られている、自身の公開鍵による解読のために自身の秘密鍵で自身の送信を暗号化することができる。代替的に、方法６０は、ユーザデバイス１２ｂがユーザデバイス１２ａの公開鍵でユーザデバイス１２ａへの送信を暗号化するために（これは、ユーザデバイス１２ａによって自身の秘密鍵を使用して解読されなければならない）、ユーザデバイス１２ｂがユーザデバイス１２ａに取って代わるように、本質的にステップ６２から繰り返すことができる。別の実施形態では、ユーザデバイス１２ａは、自身の公開鍵を自身の送信においてユーザデバイス１２ｂに送信することができる。

【0051】

図６は、Ｄ２Ｄ通信におけるセキュリティを強化するための認証プロセスを実施する方法８０を示す。このようにして、方法８０は、ステップ７０〜７６を実行する、又は補足するために使用されてもよい。方法８０では、ユーザデバイス１２ａ及び１２ｂは、（例えば、互いによって直接提供された、ステップ６２〜６８に関して述べられた近接サービス機能２６を介して提供された、又はこれらのデバイス間の過去の通信の後でメモリから取り出された）互いの公開鍵を有すると想定される。このようにして、各ユーザデバイス１２は、自身の秘密鍵及び相手デバイスの公開鍵を有する（すなわち、ユーザデバイス１２ａは、自身の秘密鍵及びユーザデバイス１２ｂの公開鍵を有し、一方、ユーザデバイス１２ｂは、自身の秘密鍵及びユーザデバイス１２ａの公開鍵を有する）。

【0052】

ステップ８２において、ユーザデバイス１２ａは、それ自身の秘密鍵を使用してデータを暗号化して、ユーザデバイス１２ａに固有であり、その送信を伴うデジタル署名を作成する。ステップ８４において、ユーザデバイス１２ａは、ユーザデバイス１２ｂの公開鍵を使用してデータを暗号化する。ステップ８２及び８４において暗号化されたデータは、（二重に暗号化される等の）同じデータ又は異なるデータ（例えば、ユーザデバイス１２ｂの公開鍵で暗号化されるデバイス１２ｂ向けのメッセージ及びデジタル署名を作成するためにユーザデバイス１２ａの秘密鍵によって暗号化される比較的小さいサイズのデータ）であってもよい。言い換えると、データのさまざまな部分が、異なるレベルに、すなわち、ユーザデバイス１２ｂの公開鍵によってだけ、ユーザデバイス１２ａの秘密鍵によってだけ、又はこれらの鍵の両方によって暗号化されてもよい。ステップ８４で暗号化された後、データは、ステップ８５で（例えば、通信リンク１５及び／又はインターフェースＰＣ５を介して）ユーザデバイス１２ｂに送信される。

【0053】

ステップ８５でユーザデバイス１２ｂがデータを受信した後、解読がステップ８６において始まり、ここで、ユーザデバイス１２ｂは、自身の秘密鍵を使用して、ステップ８４で暗号化されたデータ（又はデータの関連する部分）を解読する。データの出所(origin)を認証するために、第２のユーザデバイス１２ｂは、公開鍵１２ａを使用して、データがステップ８２において第１のユーザデバイス１２ａによって実際に署名されたことを検証する。このようにして、データは、その意図された受信者（ユーザデバイス１２ｂ）にセキュアに送信され、送信者（ユーザデバイス１２ａ）のＩＤは、盗聴、ＩＤ偽造、又は改ざんの試みを挫くように認証される。同様に、ユーザデバイス１２ｂは、ユーザデバイス１２ａに取って代わり、ユーザデバイス１２ａにセキュアに応答するために方法８０に従ってセキュリティ認証を適用することができる。

【0054】

処理及び／又は計算能力を削減又は制限することが望ましい又は必要な場合、方法８０に従うセキュアで認証された通信の確立後、ユーザデバイスは、代替的に、それらの通信に固有の対称シークレット鍵に同意し、ステップ８２及び８４の二重暗号化を実行し続ける代わりに、この対称シークレット鍵を使用して暗号化及び解読することができる。すなわち、このような対称シークレット鍵は、非対称公開鍵及び秘密鍵よりも短くすることができ、斯くして、計算要件が削減されるため暗号化及び解読の複雑さが軽減される。この実施形態では、ユーザデバイス１２のうちの一方は、自身のデジタル署名及び他方のユーザデバイスの公開鍵による暗号化を適用することによって秘密鍵を送信してもよい。他方のユーザデバイスのみがそれ自身の秘密鍵を使用してメッセージを解読することができるため、他のユーザは、ユーザデバイス１２ａ及び１２ｂの両方の公開鍵を持っていたとしても、メッセージを傍受し、解読することはできない。

【0055】

図３Ｂに示されている等のパーシャルカバレッジシナリオにおいてセキュアなエンドツーエンドのＤ２Ｄ通信を可能にする方法も、本明細書で開示される。パーシャルカバレッジの場合、デバイスのうちの少なくとも１つは、アウトオブカバレッジ又はリモートユーザデバイス（例えば、図３ＢのＵＥ２）であり、少なくとも１つの他のデバイスは、インカバレッジデバイス（例えば、図３ＢのＵＥ１）である。このようにして、インカバレッジデバイスは、リモートユーザデバイスのための中継ユーザデバイスとして機能してもよい（及びそのように称されてもよい）。例えば、リモートデバイス（例えば、図３ＢのＵＥ２）は、ｅＮＢ又は他の基地局によって提供されるセルラー又は他のネットワークカバレッジに直接アクセスできない。しかしながら、Ｄ２Ｄ通信が、基地局とリモートデバイスとの間の仲介者(intermediary)として機能することによりネットワークカバレッジをリモートデバイスに効果的に拡張するように中継ユーザデバイス（例えば、図３ＢのＵＥ１）とリモートユーザデバイス（例えば、図３ＢのＵＥ２）との間で使用されることができる。中継ユーザデバイス（例えば、図３ＢのＵＥ１）はまた、リモートユーザデバイス（例えば、図３ＢのＵＥ２）と他のリモートユーザデバイス（例えば、図３ＢのＵＥ４）との間の通信、又は他のインカバレッジユーザデバイス（例えば、図３ＢのＵＥ３）を可能にする。

【0056】

エンドツーエンドのセキュアＤ２Ｄ通信は、リモートユーザデバイスと中継ユーザデバイスの間でさまざまなやり方で確立されることができる。第１の実施形態では、Ｄ２Ｄ通信は、方法６０と同様のプロセスにおいて中継ユーザデバイスによって先ず要求され、ここで、中継ユーザデバイスは、第１のユーザデバイス１２ａの役割にあり、リモートユーザデバイスは、第２のユーザデバイス１２ｂの役割にある。この例では、リモートユーザデバイスが以前にネットワークに登録しており、鍵サーバ２４がリモートユーザデバイスの公開鍵をすでに持っていると想定される。通信リンクが確立されると、中継ユーザデバイスは、自身の公開鍵をリモートユーザデバイスに送信することができる。上述したように、中継及びリモートユーザデバイスはさらに、セキュリティを強化するために方法８０に従ってセキュリティ認証を実施することができる。同様に、中継及びリモートユーザデバイスは、上記のようにリソース消費を削減してセキュアな通信を維持するために共通の対称シークレット鍵をネゴシエートすることができる。

【0057】

一実施形態では、Ｄ２Ｄ通信は、近接サービスアプリケーションサーバ２０、鍵サーバモジュール２４、又は近接サービス機能２６へのアクセスを持たない、リモートユーザデバイスによって要求される。図７は、このシナリオにおいてセキュアＤ２Ｄ通信を可能にするための方法９０を提供する。図７において参照番号１２ｘで示される、リモートユーザデバイス(UE Remote)は、ステップ９２における初期発見要求で、参照番号１２ｙで示される、中継ユーザデバイス(UE Relay)を探索することができる。その後、中継ユーザデバイス１２ｙは、ステップ９４で近接サービス機能２６を介してＤ２Ｄリソースを要求する。

【0058】

近接サービス機能２６は、ステップ９６で鍵サーバモジュール２４にリモートユーザデバイス１２ｘの公開鍵を要求し、この要求は、ステップ９８で許可される。その後、近接サービス機能２６は、ステップ１００でリソースを割り当て、中継ユーザデバイス１２ｙにリモートユーザデバイス１２ｘの公開鍵を提供する。中継ユーザデバイス１２ｙによるリモートユーザデバイス１２ｘへの応答は、ステップ１０２でリモートユーザデバイス１２ｘの公開鍵を使用して暗号化され、リモートユーザデバイス１２ｘに送信されることができる。リモートユーザデバイス１２ｘは、それ自身の秘密鍵を使用して送信を解読することができる。通信が確立されると、リモートユーザデバイス１２ｘ及び中継ユーザデバイス１２ｙは、上述のように、セキュリティを強化するために方法８０に従って認証プロセスを実施することによって、及び／又はリソース消費を削減するために共通の対称シークレット鍵をネゴシエートすることによって、ステップ１０４で通信することができる。

【0059】

パーシャルカバレッジ状況における中継支援によるセキュアＤ２Ｄ通信(relay assisted secure D2D communication)のさまざまな実施形態は、図３Bを考慮して理解されることができる。例えば、一実施形態では、第１のユーザデバイスは、第２のユーザデバイスと通信することを望むが、これらユーザデバイスは、基地局のネットワーク範囲内にも、互いに直接通信するための範囲内にもない。例えば、図３BのＵＥ２及びＵＥ４を考える。これらは、中継者としてＵＥ１に依存する必要がある。別の実施形態では、第１のユーザデバイスは、基地局のネットワークカバレッジ内にあるが、リモートの該第１のユーザデバイスとの直接Ｄ２Ｄ通信の範囲内ではない、第２のユーザデバイスと通信することを望むリモートデバイスである。例えば、図３BのＵＥ２及びＵＥ３を考える。これらも、中継者としてＵＥ１に依存する必要がある。

【0060】

これらの中継可能な実施形態では、方法９０は、ステップ９２と同様のステップでリモートユーザデバイス１２ｘが、中継ユーザデバイス１２ｙが（例えば、通信リンク１５、インターフェースＰＣ５等を介して）第２のユーザデバイス１２ｂを検出できるかどうかを問い合わせるように中継ユーザデバイス１２ｙに発見要求を送信することも有することにより修正されてもよい。そうである場合、方法はステップ９４及び９６と同様に継続するが、中継ユーザデバイス１２ｙは、近接サービス機能２６、近接サービスアプリケーションサーバ２０、及び／又は鍵サーバモジュール２４を介してリモートユーザデバイス１２ｘ及び第２のユーザデバイス１２ｂの両方の公開鍵を要求する。中継ユーザデバイス１２ｙへの応答は、ステップ９８及び／又は１００と同様に生成されるが、第２のユーザデバイス１２ｂ及びリモートユーザデバイス１２ｘの両方の公開鍵が、ステップ１０２でリモートユーザデバイス１２ｘに転送される。方法９０はまた、これらの公開鍵を第２のユーザデバイス１２ｂに、例えば、第２のユーザデバイス１２ｂがアウトオブカバレッジである場合中継ユーザデバイス１２ｙを介して、又は第２のユーザデバイス１２ｂがインカバレッジである場合近接サービス機能２６を介して転送するように適合させることもできる。その後、中継ユーザデバイス１２ｙは、方法８０に従ってリモートユーザデバイス１２ｘ及び第２のユーザデバイス１２ｂの両方を認証し、これらのユーザデバイス間の通信を中継するための仲介者として機能することができる。当業者は、アウトオブカバレッジシナリオに関連する、図９及び１０の実施形態が、それにもかかわらずここで、及び１つ以上の中継ユーザデバイスが必要とされる任意のＤ２Ｄ通信に一般に適用可能であることを理解するであろう。

【0061】

図３Ｃに示されている等のアウトオブカバレッジシナリオにおいてエンドツーエンドのセキュアＤ２Ｄ通信を確立するための方法も、本明細書に開示される。アウトオブカバレッジシナリオでは、基地局（例えば、基地局１６及び／又はｅＮＢ）はどのユーザデバイスにも到達できないため、近接サービスアプリケーションサーバ２０、鍵サーバ２４、及び近接サービス機能２６もアクセス不能である。アウトオブカバレッジシナリオでセキュアな接続を確立するプロセスは、以下で述べられるように、通信に参加するユーザデバイスの数によって異なり得る。

【0062】

図８に示される一実施形態では方法１０５が提供され、ここでは、Ｄ２Ｄリンクが、２つのユーザデバイス間で直接確立されることができる（すなわち、これらユーザデバイスは、それぞれの無線範囲内で互いに検出し、到達することができる）。方法１０５に示されるように、この例ではＵＥ Ａ及びＵＥ Ｂとして示される第１及び第２のユーザデバイスは、ステップ１０６で通信リンク１５を介してそれぞれの近接サービスアプリケーション１４ａ及び１４ｂによって互いに発見する。ＵＥ Ａ及びＵＥ Ｂは、それぞれの鍵アプリケーションモジュール１８ａ及び１８ｂによって管理されるように、ステップ１０８でそれら自身の公開鍵を交換することができる。次に、ＵＥ Ａ及びＵＥ Ｂは、方法８０に従って認証を適用して、セキュアＤ２Ｄ通信リンクを確立することができる。その後、ＵＥ Ａ及びＵＥ Ｂは、上述のように、必要に応じて、計算リソースを削減するために共通の対称シークレット鍵をネゴシエートすることができる。

【0063】

２つのユーザデバイス間の中継支援によるＤ２Ｄ通信を提供する方法１１０が図９に示されている。この実施形態では、第１のユーザデバイスＵＥ Ａ（例えば、ユーザデバイス１２ａ）は、第２のユーザデバイスＵＥ Ｂ（例えば、ユーザデバイス１２ｂ）と通信することを望むが、ＵＥ Ｂは、ＵＥ Ａの発見範囲内にない。しかしながら、中継ユーザデバイスＵＥ Ｒｅｌａｙ（例えば、ユーザデバイス１２ｙ）は、ＵＥ Ａ及びＵＥ Ｂの両方の通信範囲内にある。第１のステップ１１２で、ＵＥ Ａは、ＵＥ ＢとのＤ２Ｄ中継者として機能するようにＵＥ Ｒｅｌａｙに要求を送信する。ＵＥ ＡがＵＥ Ｂに関連付けられた公開鍵をまだ持っていない場合、これも、ステップ１１２で要求されることができる。ステップ１１４で、この要求はＵＥ ＲｅｌａｙによってＵＥ Ｂに転送される。ステップ１１６で、ＵＥ Ｂは、自身の公開鍵でＵＥ Ｒｅｌａｙに応答し、ＵＥ Ｂの公開鍵は、ステップ１１８でＵＥ Ｒｅｌａｙを介してＵＥ Ａに転送される。ステップ１２０で、ＵＥ Ａは、自身の公開鍵をＵＥ Ｒｅｌａｙに送信し、ＵＥ Ｒｅｌａｙは、ステップ１２２でＵＥ Ａの公開鍵をＵＥ Ｂに転送する。

【0064】

ＵＥ Ａ及びＵＥ Ｂが互いの公開鍵を有した後、ＵＥ Ａ及びＵＥ Ｂは、エンドツーエンドのセキュアＤ２Ｄ通信を確立するために方法８０に従って認証を適用することができる。ＵＥ Ｒｅｌａｙは、ＵＥ ＡとＵＥ Ｂとの間で送信されるすべてのデータを受信する仲介者であり、ＵＥ Ａ及びＵＥ Ｂの両方に関連付けられた公開鍵を有するが、ＵＥ Ｒｅｌａｙは、これらの公開鍵のいずれかで暗号化されたメッセージを解読することはできず、デジタル署名を偽造することもできない。なぜなら、ＵＥ Ｒｅｌａｙは、ＵＥ Ａ又はＵＥ Ｂに関連付けられた秘密鍵を有していないからである。このエンドツーエンドのセキュアＤ２Ｄ通信の確立後、ＵＥ Ａ及びＵＥ Ｂは、上述のように、共通の対称シークレット鍵に同意できる。これは、ＵＥ Ｒｅｌａｙにはパブリックにならない。このケースは前述の中継支援によるパーシャルカバレッジの実施形態とは異なることに留意されたい。なぜなら、ＵＥ Ｒｅｌａｙは、基地局への無線アクセスがなく、したがって鍵サーバモジュール２４に公開鍵を要求できないからである。しかしながら、この方法１１０は、それにもかかわらず、特にパーシャルカバレッジシナリオにおける公開鍵が鍵サーバモジュール２４から取得されることが望ましくない又はそうできない場合に、パーシャルカバレッジの実施形態に有益であり、一般に適用可能であり得る。

【0065】

いわゆる「マルチホップ」シナリオでは、２つ以上の中継ユーザデバイスのチェーンを介してデータ送信を行う必要があるため、セキュリティリスクが高まる。マルチホップシナリオにおけるセキュアに認証されたＤ２Ｄの方法１３０が図１０に示され、ここでは、第１の（送信者）ユーザデバイスＵＥ Ａ（例えば、ユーザデバイス１２ａ）は、（例えば、各々、中継ユーザデバイス１２ｙとして実装される、及び／又はそれに類似している）ＵＥ Ｂ及びＵＥ Ｃとして示される２つの中継ユーザデバイスによって提供される複数のＤ２Ｄ中継ホップを介して、第２の（受信者）ユーザデバイスＵＥ Ｄ（例えば、ユーザデバイス１２ｂ）と通信することを望む。ＵＥ ＡはＵＥ Ｄに直接到達できないが、方法１３０は、ＵＥ ＡとＵＥ Ｂとの間、ＵＥ ＢとＵＥ Ｃとの間、及びＵＥ ＣとＵＥ Ｄとの間のＤ２Ｄ通信リンクがセキュアにされることを可能にする。

【0066】

最初に、ＵＥ Ａ及びＵＥ Ｄは互いの公開鍵を有している、又は取得する、例えば、互いの鍵は既知であり、ＵＥ ＡとＵＥ Ｄとの間の以前の通信から、又は本明細書で述べられるプロセスのいずれかからメモリに格納されると想定される。第１のステップ１３２で、ＵＥ Ａは、ＵＥ Ｄの公開鍵によってＵＥ Ｄへのデータを暗号化して、（ＵＥ Ｄだけが自身の秘密鍵でこのデータを暗号化解除することができるので）ＵＥ Ｂ及びＵＥ Ｃによって中継される場合にセキュアなままであることを保証することができる。意図された中継ユーザデバイス、すなわち、ＵＥ Ｂが送信を受信し、転送することを保証するために、単一暗号化されたデータ(single-encrypted data)は、次いで、ＵＥ Ｂの公開鍵を使用してステップ１３４で再度暗号化されることができる。その後、二重暗号化されたデータ(double-encrypted data)が、ステップ１３６でＵＥ Ｂに送信される。

【0067】

ＵＥ Ｂは、ステップ１３８で自身の秘密鍵を使用して二重暗号化の第１の層を解読することにより、それ自体を認証する。その後、ＵＥ Ｂは、（ＵＥ Ｃがマルチホッププロセスにおける次の中継であるので）ステップ１４０でＵＥ Ｃの公開鍵を使用して（ここでは再び、ＵＥ Ｄの公開鍵によってのみ暗号化されている）データを暗号化する。その後、二重暗号化されたデータパッケージが、ステップ１４２でＵＥ Ｃに送信され、ＵＥ Ｃは、ステップ１４４で自身の秘密鍵を使用して第１の暗号化層を解読することによりそれ自体の認証及び検証を繰り返す。

【0068】

ステップ１４４後のデータは、依然としてＵＥ Ｄの公開鍵で暗号化されているため、ステップ１４６でＵＥ Ｄの公開鍵で二重暗号化され、ステップ１４８でＵＥ Ｄに送信されるか、又はステップ１４６をスキップすることにより二重暗号化なしで送信されることができる。一部の実施形態では、ステップ１４６が実行されることを必要とすることが有利であり得る。例えば、このようにして、ＵＥ Ｂ及びＵＥ Ｃは、ＵＥ Ｄが意図された受信者であることを「知る」必要がなくなり得る。代わりに、各中継ユーザデバイスは、単純に、チェーン内の次のユーザデバイスの公開鍵でデータを暗号化するように（例えば、当該中継ユーザデバイスの公開鍵によって解読された命令において）指示されるが、中継ユーザデバイスは、次のユーザデバイスが受信者であるか、単に別の中継であるかは分からない。これと同じ理由で、各中継ユーザデバイスは、ＵＥ Ａが元の送信者(original sender)であることを認識しなくてもよい。これは、誰がデータを送信している及び受信することになるのか中継ユーザデバイスには不明確になるため、Ｄ２Ｄ通信に追加の保護レベルを加える。

【0069】

ＵＥ Ｄはパッケージを受信し、ＵＥ Ａによって送信された元のデータを取得するためにステップ１５０で自身の秘密鍵を使用して（ステップ１４６がスキップされたかどうかに応じて）１回又は２回解読する。ＵＥ Ｄは、ＵＥ ＤからＵＥ Ｃ、ＵＥ Ｂ、最後にＵＥ Ａへの逆のマルチホップルートを使用してＵＥ Ａに通信することができる。

【0070】

方法１３０がＵＥ ＡとＵＥ Ｄとの間にエンドツーエンドのセキュアなＤ２Ｄルートを確立すると、方法８０によるが、ＵＥ Ｂ及びＵＥ Ｃを介して中継される認証が、ＵＥ ＡとＵＥ Ｄとの間で実施されることができる。同様に、共通の対称鍵が、各エンティティにおける認証及び検証を簡略化するために方法１３０を使用してＵＥ ＡとＵＥ Ｄとの間でネゴシエートされることができる。対称シークレット鍵が実装される場合でも、中継ユーザデバイスＵＥ Ｂ及びＵＥ Ｃの公開鍵が、所望であれば引き続き使用されることができ、又はＵＥ ＡとＵＥ Ｄとの間のチェーンの中継「ホップ」ごとに異なる対称シークレット鍵が作成されることができる。これらのマルチホップは、方法１３０に関して述べられるタイプの二重暗号化Ｄ２Ｄ通信リンクを使用することにより、より大きな規模に拡張されることができ、斯くして、サイズ又は構成(configuration)に関係なく、多くのネットワーク及び状況に有利に適用可能である。

【0071】

一実施形態では、ジオロケーションが、マルチホップシナリオで中継者として使用されるのに適切なユーザデバイスの識別を支援する際に利用されてもよい。例えば、送信者ユーザデバイスは、（例えば、ＧＰＳ又は他のジオロケーティングテクノロジを利用して）受信ユーザデバイスの「最後に既知の(last-known)」又は「可能性が高い(likely)」物理アドレスを認識している場合、受信ユーザデバイスの最後に既知のアドレスに近いものととして識別する第１の中継デバイスを選択することができる。第１の中継デバイス及び後続の各中継ユーザデバイスは、受信者ユーザデバイスが見つかるまで、このようにして中継を選択し続けることができる。さらに、中継ユーザデバイスが信用のある又は信頼できるネットワーク(reputable or trusted network)上にある場合（例えば、基地局のネットワークカバレッジ内にある場合）、当該中継ユーザデバイスは、送信者ユーザデバイスと受信者ユーザデバイスとの間の識別及び通信を容易にするために基地局を中継者として選択してもよい。例えば、基地局が中継者して使用される場合、所望の受信者ユーザデバイスのためにより広いエリアをより簡単にスキャンすることができ、及び／又は、例えば基地局によって追跡された履歴イベントに基づいて、中継者として使用されるのにより信用でき、信頼できるユーザデバイスを特定することができる。

【0072】

一実施形態では、Ｄ２Ｄ通信システム、例えば、通信システム１０は、秘密鍵及び公開鍵について異なるセキュリティレベルを区別するように構成される。例えば、鍵サーバモジュール２４は、一実施形態では、個別化されたセキュリティ(differential security)を、特定のレベル、例えば、公衆緊急安全応答(public safety and emergency response)等、メッセージがパブリックにブロードキャストされることが意図されるローセキュリティの「パブリック−トゥ−オール(public-to-all)」レベル、信頼できるデバイスの選択されたグループと個人情報を共有するためのミディアムセキュリティの「プライベート−トゥ−フレンド(private-to-friends)」レベル、及びあらゆる種類のプライバシー漏洩を厳格に保護するように構成されるハイセキュリティの「プライベート−トゥ−ナン(private-to-none)」レベルに分類するように構成される。各カテゴリは、対応する鍵（又は複数の鍵）に関連付けられたフィールドを有し、鍵（又は複数の鍵）を適用することができるユーザデバイス上のプログラム又はアプリケーションのセットを指定してもよい。ユーザデバイスは、カテゴリ又はセキュリティレベルごとに、公開鍵及び秘密鍵の対を登録することができる。このフィールドを鍵に追加することにより、プライバシーのレベルが、任意の鍵に設定されることができ、斯くして、Ｄ２Ｄ通信におけるプライバシーの段階的な又は個別化された保護(tiered or differential protection of privacy)が実現され得るように前述の実施形態のすべてに適用可能である。

【0073】

本明細書で論じられる様々な機能及び方法のステップは、ハードウェア及び／又はソフトウェアの組み合わせの形態でコンピュータ化されたシステムによって実装されることが意図されていることを理解されたい。ソフトウェアとは、ハードウェアによって実行するための任意のタイプの命令又はプログラミングコードを意味する。例えば、本明細書で論じられる様々な機能を実行するようにソフトウェアを使用してプログラムされたプロセッサ２０２を含み、メモリ２０４と組み合わせて利用されることができる、コンピュータ化されたデバイス２００が図１１に示されている。メモリ２０４は、本明細書に開示される公開鍵及び秘密鍵、本明細書に開示されるＤ２Ｄ通信で送信されるデータ、並びに／又はプロセッサ２０２による実行のためのソフトウェアプログラム、及びコンピュータ化されたデバイス２００の動作を可能にする若しくは支援する様々なタイプの他のデータ若しくは命令を含む、データを格納することができる。コンピュータ化されたデバイス２００はまた、ネットワークインターフェース２０６を含む。ネットワークインターフェース２０６は、トランシーバ、レシーバ、又は同じ通信プロトコル、標準、若しくはテクノロジ、例えば、ＬＴＥ若しくは他のセルラー通信テクノロジを介して動作する他のデバイスとの無線（及び／又は有線）通信を可能にする他の無線デバイスであってもよい。

【0074】

ユーザデバイス（すなわち、ユーザデバイス１２、ＵＥ Ａ、ＵＥ Ｂ、ＵＥ１〜ＵＥ４等）、基地局及びネットワークインフラストラクチャ（例えば、基地局１６、ｅＮＢ等）は、コンピュータ化されたデバイス２００の１つ以上として、コンピュータ化されたデバイス２００の１つ以上に従って、又はコンピュータ化されたデバイス２００の１つ以上を含むように実装されてもよいことを理解されたい。したがって、本明細書で開示される通信リンク及びインターフェース、例えば、通信リンク／インターフェース１５、２２、２８、２９、ＰＣ１、ＰＣ２、ＰＣ３、ＰＣ５等は、ネットワークインターフェース２０６を介して確立又は実装されてもよい。同様に、近接サービスアプリケーション１４及び鍵アプリケーションモジュール１８は、したがって、コンピュータデバイス２００のインスタンスによって実行されるソフトウェアであってもよく、又は該ソフトウェアを含んでもよい。同様に、近接サーバ機能２６、近接サービスアプリケーションサーバ２０、及び鍵サーバモジュール２４は、１つ以上のコンピュータ化されたデバイス２００、並びに本明細書に開示される方法及び実施形態に従ってコンピュータ化されたデバイス２００によって実行される関連するソフトウェアであってもよく、又はそれらを含んでもよい。

【0075】

いくつかの発明実施形態が、本明細書で説明及び図示されてきたが、当業者は、本明細書で説明される機能を実行するための、並びに／あるいは、その結果及び／又は利点のうちの１つ以上を得るための、様々な他の手段及び／又は構造体を、容易に構想することとなり、そのような変形態様及び／又は修正態様は、本明細書で説明される発明実施形態の範囲内にあるものと見なされる。より一般的には、本明細書で説明される全てのパラメータ、寸法、材料、及び構成は、例示であることが意図されており、実際のパラメータ、寸法、材料、及び／又は構成は、本発明の教示が使用される特定の用途に応じて変化することを、当業者は容易に理解するであろう。当業者は、通常の実験のみを使用して、本明細書で説明される特定の発明実施形態に対する、多くの等価物を認識し、又は確認することが可能であろう。それゆえ、上述の実施形態は、例としてのみ提示されており、添付の請求項及びその等価物の範囲内で、具体的に説明及び特許請求されるもの以外の発明実施形態が実践されてもよい点を理解されたい。本開示の発明実施形態は、本明細書で説明される、それぞれの個別の特徴、システム、物品、材料、キット、及び／又は方法を対象とする。更には、２つ以上のそのような特徴、システム、物品、材料、キット、及び／又は方法の任意の組み合わせは、そのような特徴、システム、物品、材料、キット、及び／又は方法が相互に矛盾しない場合であれば、本開示の発明の範囲内に含まれる。

【0076】

本明細書で定義及び使用されるような、全ての定義は、辞書定義、参照により組み込まれる文書中での定義、及び／又は定義される用語の通常の意味を支配するように理解されるべきである。

【0077】

不定冠詞「ａ」及び「ａｎ」は、本明細書及び請求項において使用されるとき、そうではないことが明確に示されない限り、「少なくとも１つ」を意味するように理解されるべきである。

【0078】

語句「及び／又は」は、本明細書及び請求項において使用されるとき、そのように結合されている要素の「いずれか又は双方」、すなわち、一部の場合には接続的に存在し、他の場合には離接的に存在する要素を意味するように理解されるべきである。「及び／又は」で列挙されている複数の要素は、同じ方式で、すなわち、そのように結合されている要素のうちの「１つ以上」として解釈されるべきである。「及び／又は」の節によって具体的に特定されている要素以外の他の要素は、具体的に特定されているそれらの要素に関連するか又は関連しないかにかかわらず、オプションとして存在してもよい。それゆえ、非限定例として、「Ａ及び／又はＢ」への言及は、「含む（comprising）」などのオープンエンドの言語とともに使用される場合、一実施形態では、Ａのみ（オプションとして、Ｂ以外の要素を含む）、別の実施形態では、Ｂのみ（オプションとして、Ａ以外の要素を含む）、更に別の実施形態では、Ａ及びＢの双方（オプションとして、他の要素を含む）などに言及することができる。

【0079】

本明細書及び請求項において使用されるとき、「又は」は、上記で定義されたような「及び／又は」と同じ意味を有するように理解されるべきである。例えば、リスト内の項目を分離する際、「又は」又は「及び／又は」は、包括的であるとして、すなわち、少なくとも１つを含むが、また、いくつかの要素又は要素のリストのうちの２つ以上を、オプションとして、列挙されていない追加項目も含むとして解釈されるものとする。その反対が明確に示される、「〜のうちの１つのみ」若しくは「〜のうちの厳密に１つ」、又は請求項で使用される場合の「〜から成る」などの用語のみが、いくつかの要素又は要素のリストのうちの厳密に１つを含むことに言及する。一般に、用語「又は」は、本明細書で使用されるとき、「〜のいずれか」、「〜のうちの１つ」、「〜のうちの１つのみ」、又は「〜のうちの厳密に１つ」などの、排他性の用語に先行する場合にのみ、排他的選択肢（すなわち、「一方又は他方であるが、双方ではない」）を示すとして解釈されるものとする。「〜から本質的に成る」は、請求項で使用される場合、特許法の分野で使用される際の、その通常の意味を有するものとする。

【0080】

本明細書及び請求項において使用されるとき、１つ以上の要素のリストを参照する語句「少なくとも１つ」は、その要素のリスト内の要素の任意の１つ以上から選択された、少なくとも１つを意味するが、必ずしも、その要素のリスト内で具体的に列挙されているそれぞれの要素のうちの、少なくとも１つを含むものではなく、その要素のリスト内の要素の、任意の組み合わせを排除するものではないことが理解されるべきである。この定義はまた、語句「少なくとも１つ」が言及する、その要素のリスト内で具体的に特定されている要素以外の要素が、具体的に特定されているそれらの要素に関連するか又は関連しないかにかかわらず、オプションとして存在してもよいことも可能にする。それゆえ、非限定例として、「Ａ及びＢのうちの少なくとも１つ」（又は、等価的に「Ａ又はＢのうちの少なくとも１つ」、又は、等価的に「Ａ及び／又はＢのうちの少なくとも１つ」）は、一実施形態では、オプションとして２つ以上を含めた、少なくとも１つのＡであり、Ｂは存在しないこと（及び、オプションとしてＢ以外の要素を含む）、別の実施形態では、オプションとして２つ以上を含めた、少なくとも１つのＢであり、Ａは存在しないこと（及び、オプションとしてＡ以外の要素を含む）、更に別の実施形態では、オプションとして２つ以上を含めた、少なくとも１つのＡ、及び、オプションとして２つ以上を含めた、少なくとも１つのＢ（及び、オプションとして他の要素も含む）などに言及することができる。

【0081】

また、そうではないことが明確に示されない限り、２つ以上のステップ又は行為を含む、本明細書で特許請求されるいずれの方法においても、その方法のステップ又は行為の順序は、必ずしも、その方法のステップ又は行為が列挙されている順序に限定されるものではないことも理解されるべきである。

【0082】

請求項並びに上記の明細書では、「備える（comprising）」、「含む（including）」、「運ぶ（carrying）」、「有する（having）」、「包含する（containing）」、「伴う（involving）」、「保持する（holding）」、「〜で構成される（composed of）」などの全ての移行句は、オープンエンドであり、すなわち、含むが限定されないことを意味する点を理解されたい。米国特許庁の特許審査基準のセクション２１１１．０３に記載されているように、移行句「〜から成る」及び「〜から本質的に成る」のみが、それぞれ、クローズド又は半クローズドの移行句であるものとする。

【要約】

複数のユーザデバイス間のセキュアデバイスツーデバイス（Ｄ２Ｄ）通信を可能にするための方法及びシステム。方法は、ユーザデバイスの各々の公開鍵及び秘密鍵を設けるステップを含み、秘密鍵は、対応する公開鍵によって暗号化されたデータを解読するように構成される。送信者ユーザデバイスは、自身の秘密鍵を使用してデジタル署名を作成する。送信者は、受信者ユーザデバイスの公開鍵及び第１の中継ユーザデバイスの公開鍵の両方を使用して送信を二重暗号化する。送信は、送信者から複数の中継ユーザデバイスを介して受信者に送信される。各中継ユーザデバイスは、送信を受信する、自身の秘密鍵を使用して第１の暗号化層を解読する、後続するユーザデバイスの公開鍵を使用して送信を暗号化する、及びデータ送信を後続するユーザデバイスに転送する。受信者は、送信者の公開鍵を使用して送信者のデジタル署名を認証する。

【図1】

【図2】

【図3A】

【図3B】

【図3C】

【図4A】

【図4B】

【図4C】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】