JP7843767B2 - セルラネットワークを動作させるための方法 - Google Patents

Description

本発明は、無線通信の分野に関し、特に、ＵＴＭＳロングタームエボリューション（ＬＴＥ）若しくはＬＴＥアドバンスト（共に、４Ｇに含まれる）、ニューレイディオ（ＮＲ）（５Ｇ）、又は他のセルタネットワーク若しくはモバイル通信ネットワークのようなセルラネットワークの環境において、アーキテクチャを中継することに関する。

従来型のセルラネットワークにおいて、一次局は、この一次局によって供給されるセルの内部に位置する複数の二次局に供給（サーブ、serve）する。一次局からそれぞれの二次局に向けての無線通信は、ダウンリンクチャネルにおいて行われる。逆に、それぞれの二次局から一次局に向けての無線通信は、アップリンクチャネルにおいて行われる。無線通信は、データトラフィック（時にはユーザデータと称される）と、制御情報（時にはシグナリングとも称される）とを含み得る。この制御情報は、典型的には、一次局及び／又は二次局がデータトラフィック（例えば、ソース配分／リクエスト、物理伝送パラメータ、それぞれの局の状態に関する情報）を交換することを助ける情報を含む。

３ＧＰＰ（登録商標）によって標準化されたセルラネットワークの環境では、一次局は、基地局と称され、５Ｇ（ＮＲ）ではｇＮｏｄｅＢ（若しくはｇＮＢ）と称され、又は４Ｇ（ＬＴＥ）ではｅＮＯｄｅＢ（若しくはｅＮＢ）と称される。ｅＮＢ／ｇＮＢは、無線アクセスネットワークＲＡＮの一部であり、無線アクセスネットワークＲＡＮは、コアネットワーク（ＣＮ）において機能するインターフェースを有する。同じ環境において、二次局は、４Ｇ／５Ｇにおけるモバイル局又はユーザ機器（又はＵＥ）に対応するのであるが、これは、無線クライアントデバイス又はそのデバイスによって演じられる特定の役割である。「ノード」という用語は、ＵＥ又はｅＮＢ／ｇＮＢのいずれかを示すのにも用いられる。

３ＧＰＰ（登録商標）では、図１に示されているような中継ノードの役割が導入されている。この中継ノード１２０は、基地局１００とＵＥ１１０との間で通信を中継するための機能を含む無線通信局１２０である。この中継機能は、例えば、セル１０のカバレッジをカバレッジ外（ＯｏＣ）のモバイル局１１０に拡張することを助ける。この中継ノード１２０は、モバイル局であるか、又は異なるタイプのデバイスでもあり得る。４Ｇの仕様において、近接サービス（ＰｒｏＳｅ）機能は、とりわけＴＳ２３．３０３及びＴＳ２４．３３４において、他の機能と共に、セル１０に供給しているセルラネットワーク基地局（ｅＮＢ）１００のカバレッジの中には一時的に存在していないセルラユーザ機器（ＵＥ）のために接続を可能にするものとして、定義されている。この特定の機能は、ＰｒｏＳｅによるＵＥとネットワークとの間の中継、又は、単に、中継ＵＥと称される。中継ＵＥ１２０は、ＯｏＣのＵＥ１１０とｅＮＢ１００との間で、アプリケーションとネットワークトラフィックとを双方向に中継する。中継ＵＥ１２０とＯｏＣのＵＥ１１０との間でのローカルな通信は、ＴＳ２３．３０３及びＴＳ２４．３３４において、デバイス相互間（Ｄ２Ｄ）通信、又はサイドリンク（ＰＣ５としても知られている）通信と称されている。いったん中継関係が確立されると、ＯｏＣのＵＥ１１０は、中継ＵＥ１２０を介してＩＰ接続され、「リモートＵＥ」１１０の役割として機能する。この状況は、リモートＵＥが、通常の場合であるコアネットワークのすべての機能へのＴＳ２２．２６１の直接的なネットワーク接続とは対照的に、コアネットワークの選択された機能へのＴＳ２２．２６１の間接的なネットワーク接続を有することを意味する。

追加的に、そのようなシステムでは、図２において示されているように、
Ａ）リモートＵＥは、ＵＥとネットワークとの間での中継を介して、基本局／コアネットワークに向けて通話することができる。
Ｂ）ソースＵＥは、ＵＥ相互間の中継を介して、宛先ＵＥに向けて通話することができる。
Ｃ）ＵＥのグループは、グループキャスト通信として、時にはＵＥ相互間の中継を介して、相互に通話することができる。

３ＧＰＰ（登録商標）のＳＡ２では、通信モデル及び手順が論じられており、中継ベースのシステムに関して合意されている。これらの手順は、ＴＲ２３．７５２に含まれている。３ＧＰＰ（登録商標）のＳＡ３では、セキュリティソリューション及び手順が論じられており、中継ベースのシステムに関して合意されている。これらの手順は、ＴＲ３３．８４７に含まれている。

例えば、ＴＲ２３．７５２のソリューション＃２８は、リモートＵＥがレイヤ３のＵＥとネットワークとの間の中継を発見し、ＵＥとネットワークとの間の中継を用いてＰＣ５ユニキャスト接続を確立する機構を記載している。この機構は、動作の間にコアネットワークと対話することを要求しない。

例えば、ＴＲ３３．８４７のソリューション＃３２は、リモートＵＥが、認可された中継器だけがそれらにアクセスできるように、そのＰＤＵパラメータをＵＥとネットワークとの間の中継から保護する機構を記載している。このソリューションは、コアネットワークとの対話を要求する。

ＴＲ２３．７５２のソリューション＃２８で論じられている現在のソリューションは、それがディスカバリの間にＣＮとの対話を要求しないという利点を提示している。しかし、それは、また、例えばＴＲ３３．８４７のＫＩ＃１６に関係するいくつかの問題を提示する。スライシング情報の事前設定をどのようにして回避するかは、解決されていない（問題１）。また、このソリューションは、ＰＤＵセッションパラメータが平文で輸送されることを要求している（問題２）。ＴＲ３３．８４７におけるこれらの課題への可能なソリューションは、ソリューション＃３２である。しかし、このソリューションは、ＰＤＵパラメータのプライバシ保護を達成するために、動作の過程でコアネットワークを介する通信を要求する（問題３）。

本発明の１つの目的は、上述された問題を緩和することである。

本発明のもう１つの目的は、二次局のためにプロトコルデータユニット（ＰＤＵ）セッションを確立するためのセキュアなセットアップを可能にする、ネットワークにおける通信方法を提案することである。

本発明の更にもう１つの目的は、いったん動作する際にはコアネットワークとの間で最小限の対話だけを要求する、ネットワークにおける二次局の通信方法を提案することである。

この目的のために、本発明の第１の態様に従って、請求項１に記載のシステムを動作させる方法と、従属請求項におけるそのバリアントとが提案されている。

こうして、本発明の第１の態様に従い、二次局と中継局とは、早い段階で、例えばセルへの初期の接続の際に、例えば受信側ＵＥに向けられた署名された公開鍵などの要求されるセキュリティ要素を、コアネットワークから取得する。より後のフェーズである例えばネットワークの動作の間には、二次局と中継局とは、ＰＤＵセッションを開始するために、セキュアな交換及び認証を確立することができる。

以下で説明される例示的な実施形態では、第１のメッセージと第２のメッセージとに含まれる設定パラメータは、中継サービスコード（ＲＳＣ）であり得る。しかし、これらの設定パラメータは、また、下記のうちのいずれか１つ又は複数など、異なるパラメータ又はパラメータの組合せでもあり得る。すなわち、
・１組のアクセス役割、
・１組の属性、
・送信モード、いくつかの組のリソースに対する制約などの、通信パラメータ、
・アプリケーションのためのＩＤ、グループＩＤ、ＵＥなどの、特別の識別子、
・アクセス権を定義するポリシ、
・中継されることが可能な通信のタイプを定義するポリシ。

本発明の第２の態様によると、請求項１８に記載の、中継局を動作させるための方法が提案される。

本発明の第３の態様によると、請求項１９に記載の、二次局を動作させるための方法が提案される。

本発明の第２の態様にリンクされた本発明の第４の態様によると、請求項２０に記載の中継局が提案される。

本発明の第３の態様にリンクされた本発明の第５の態様によると、請求項２１に記載の二次局が提案される。

本発明の第６の態様によると、コンピュータデバイス上で実行されると、本発明の第１、第２又は第３の態様の方法のステップを生じさせるコード手段を含むコンピュータプログラム製品が提案される。

よって、本発明の第１の態様によると、コアネットワークにリンクされ、セルに供給する一次局と、一次局によって供給される中継局と、一次局によって供給される二次局とを含む通信システムを動作させるための方法が提案される。この方法は、
一次局からの少なくとも１つの第１のセキュアなメッセージにおいてサービスコードを含む第１の組の設定パラメータを受信するステップを含む、中継局が一次局との接続を確立するステップと、
少なくとも１つの第２のセキュアなメッセージにおいて今後のデータセッションにリンクされた中継サービスコードを含む第２の組の設定パラメータを一次局から受信するステップを含む、二次局が一次局との接続を確立するステップと、
第１の組の設定パラメータからの少なくとも１つの送信されたサービスコードを中継局が送信するステップと、
送信されたサービスコードが第２の組の設定パラメータに含まれると決定されると、二次局が中継局との直接通信を確立するステップと、
を有する。

本発明の第２の態様によると、ネットワークにおいて通信するように構成された中継局であって、コアネットワークにリンクされておりセルに供給する一次局と、一次局によって供給される二次局とを含み、一次局によって供給される中継局を動作させるための方法が提案される。この方法は、
いくつかの属性又は１組のサービスコードを含む第１の組の設定パラメータを、一次局からの少なくとも１つの第１のセキュアなメッセージにおいて受信するステップを含む、中継局が一次局との接続を確立するステップと、
第２の組の設定パラメータからの少なくとも１つの属性又は第２の組の設定パラメータからの送信されたサービスコードを、中継局が送信するステップと、
送信されたサービスコードに基づく、二次局からのリクエストがあると、中継局が二次局との直接通信を確立するステップと、
を有する。

本発明の第３の態様によると、コアネットワークにリンクされておりセルに供給する一次局と、一次局によって供給される中継局とを含む通信システムにおいて通信するための二次局であって、一次局によって供給される二次局を動作させるための方法が提案される。この方法は、
一次局から、少なくとも１つの第２のセキュアなメッセージにおいて、公開暗号鍵と、第２の組の属性又は少なくとも１つの中継局との今後のデータ交換にリンクされている中継サービスコードとを受信するステップを含む、二次局が一次局との接続を確立するステップと、
二次局が、少なくとも１つの送信された属性又は中継サービスコードを中継局から受信するステップと、
二次局が、送信された属性又は中継サービスコードが第２の組の設定パラメータに含まれているかどうかを決定し、送信された属性若しくは中継サービスコードが第２の組の設定パラメータに含まれているか又はその中のポリシを充足すると決定すると、中継局との直接通信を確立するステップと、
を有する。

本発明の第４の態様によると、コアネットワークにリンクされておりセルに供給する一次局と、一次局によって供給される二次局とを含むネットワークにおいて通信するように構成された中継局であって、一次局によって供給される中継局が提案される。この中継局は、
送信機と、
受信機と、
一次局との接続を確立するように構成され、一次局から少なくとも１つの第１のセキュアなメッセージにおいて属性又はサービスコードを含む第１の組の設定パラメータを受信するように受信機を設定する、コントローラと、
を備え、
送信機は、第１の組の設定パラメータからの少なくとも１つの送信された属性又はサービスコードを送信するように構成され、
コントローラは、二次局からの送信されたサービスコードに基づくリクエストがあると、公開鍵を用いて二次局との直接通信を確立するように構成されている。

本発明の第５の態様によると、コアネットワークにリンクされておりセルに供給する一次局と、一次局によって供給される中継局とを含む通信システムにおいて通信するように構成された二次局であって、一次局によって供給される二次局が提案される。この二次局は、
送信機と、
受信機と、
一次局との接続を確立するように構成されたコントローラであって、一次局から少なくとも１つの第２のセキュアなメッセージにおいて属性又は少なくとも１つの中継局との今後のデータ交換にリンクされた中継サービスコードを含む第２の組の設定パラメータを受信するように受信機を設定する、コントローラと、
を備え、
受信機は、少なくとも１つの送信された属性又は中継サービスコードを中継局から受信するように構成され、
コントローラは、送信された属性若しくは中継サービスコードが第２の組の設定パラメータに含まれる又はその中のポリシを充足するかどうかを決定し、送信された中継サービスコードが第２の組の設定パラメータに含まれると決定されると、送信機に中継局との直接通信を確立させるように構成されている。

本発明の第１から第５の態様のいずれかと組み合わされることが可能な第１のオプションによると、第１のセキュアなメッセージは、中継公開暗号鍵と、対応する中継秘密暗号鍵とを更に含む。

同様に、本発明の第１から第５の態様と又は本発明の第２のオプションと組み合わされることが可能な第２のオプションによると、第２のセキュアなメッセージは、二次局公開暗号鍵と、対応する二次局秘密暗号鍵とを更に含む。

第２及び／又は第３のオプションと組み合わされることが可能な第３のオプションでは、少なくとも１つの第１のセキュアなメッセージは、少なくとも、
中継公開暗号鍵と、
第１の組の設定パラメータの少なくとも１つの属性又は第１の組の設定パラメータのサービスコードのうちの１つと、
において生成された、コアネットワークからの少なくとも１つの第１のコアネットワーク署名を含み、
少なくとも１つの第２のセキュアなメッセージは、少なくとも、
二次局公開暗号鍵と、
第２の組の設定パラメータの少なくとも１つの属性又は第２の組の設定パラメータのサービスコードのうちの１つと、
において生成された、コアネットワークからの少なくとも１つの第２のコアネットワーク署名を含む。

その代わりに、第２及び／又は第３のオプションと組み合わされることが可能な第４のオプションでは、少なくとも１つの第１のセキュアなメッセージは、少なくとも、
中継公開暗号鍵と、
第１の組の設定パラメータの少なくとも１つの属性又は第１の組の設定パラメータのサービスコードのうちの１つと、
において生成された、コアネットワークからの少なくとも１つの第１のコアネットワーク署名を含み、
少なくとも１つの第２のセキュアなメッセージは、少なくとも、
今後のデータセッションに関係しており第２のセキュアなメッセージに含まれるパラメータと、
二次局公開暗号鍵と、
第２の組の設定パラメータの少なくとも１つの属性又は第２の組の設定パラメータのサービスコードのうちの１つと、
において生成された、コアネットワークからの少なくとも１つの第２のコアネットワーク署名を含む。

第３又は第４のオプションと組み合わされることが可能な第５のオプションでは、直接通信を確立するステップは、
ａ．二次局が、直接通信リクエストを中継局に送るステップと、
ｂ．中継局が、中継公開暗号鍵と第１のコアネットワーク署名と応答メッセージ署名とを含む応答メッセージによって、直接通信リクエストに応答するステップと、
ｃ．二次局が、応答メッセージに含まれる第１のコアネットワーク署名と応答メッセージ署名とをチェックするステップと、
を含む。

更に、第４のオプションと組み合わされることが可能な第５のオプションでは、直接通信リクエストは二次局ナンスを含み、応答メッセージ署名は中継秘密暗号鍵を少なくとも二次局ナンスに適用することによって生成される。

追加すると、第５のオプションと組み合わされることが可能な第６のオプションでは、応答メッセージ署名は、中継秘密暗号鍵を、少なくとも二次局ナンスと、コアネットワーク第１署名と中継公開暗号鍵との少なくとも一方と、に適用することによって生成される。

第４、第５、又は第６のオプションと組み合わされることが可能な第７のオプションでは、応答メッセージは中継ナンスを更に含み、二次局は設定メッセージにおいて通信パラメータを送信し、設定メッセージは設定メッセージ署名を含み、設定メッセージ署名は二次局秘密暗号鍵を少なくとも中継ナンスに適用することによって生成される。

第７のオプションと組み合わされることが可能な第８のオプションでは、設定メッセージ署名は、二次局秘密暗号鍵を、少なくとも中継ナンスと、コアネットワーク第２署名と二次局公開暗号鍵との少なくとも一方と、に適用することによって生成される。

第１から第５の態様と組み合わされることが可能な第９のオプションでは、直接通信を確立するステップは、
ａ．二次局が、二次局暗号公開鍵と二次局暗号秘密鍵と二次局ナンスとを生成する又は選択し、直接通信リクエストを中継局に送るステップと、
ｂ．中継局が、中継公開暗号鍵、第１のコアネットワーク署名及び／又は応答メッセージ署名を含んでおり、ステップａで受信された公開鍵を用いて暗号化される応答メッセージによって、直接通信リクエストに応答するステップと、
ｃ．二次局が、応答メッセージを復号化し、応答メッセージに含まれる第１のコアネットワーク署名と応答メッセージ署名とをチェックするステップと、
を含む。

本発明の態様及びオプションのいずれかと組み合わされることが可能な第１０のオプションでは、中継局は、第１の組の設定パラメータの少なくとも１つの送信された属性又は第１の組の設定パラメータからのサービスコードと、データセッションポリシとデータセッションパラメータと第１のコアネットワーク署名と中継公開暗号鍵との更なる情報のうちの少なくとも１つとを送信し、二次局は、第１の組の設定パラメータの送信された属性又は送信されたサービスコードが第２の組の設定パラメータに含まれ、更なる情報が今後のデータセッションと互換であると決定されると、中継局との直接通信を確立する。

第１０のオプションと組み合わされることが可能な第１１のオプションでは、中継局からの送信されたメッセージは、少なくともタイムスタンプに適用される署名を含む。

本発明の態様及びオプションのいずれかと組み合わされることが可能な本発明の第１２のオプションでは、第１の組の設定パラメータからの少なくとも１つの送信されたサービスコードは、送信ナンスと組み合わされた第１の組の設定パラメータのハッシュされたサービスコードの結果であり、中継局は、送信ナンスを更に送信する。

第５から第１０のオプションと組み合わされることが可能な本発明の第１３のオプションでは、この方法は、二次局がコアネットワークに第１のコアネットワーク署名が失敗するかどうかを告知するステップを更に有する。

本発明の第１から第５の態様と組み合わされる第１４のオプションでは、中継局が一次局との接続を確立するステップは、中継局が中継公開暗号鍵と中継秘密暗号鍵とを生成するステップと、コアネットワークによる署名のために中継公開暗号鍵を一次局に送るステップと、一次局からの少なくとも１つの第１のセキュアなメッセージにおいて、第１の組のサービスコードと、少なくとも中継公開暗号鍵に基づく第１のコアネットワーク署名とを受け取るステップと、を含む。

本発明の第１から第５の態様又は第１４のオプションと組み合わされる本発明の第１５のオプションでは、二次局が一次局との接続を確立するステップは、二次局が二次局公開暗号鍵と二次局秘密暗号鍵とを生成するステップと、コアネットワークによる署名のために二次局公開暗号鍵を一次局に送るステップと、一次局からの少なくとも１つの第２のセキュアなメッセージにおいて、第２の組のサービスコードと、少なくとも二次局公開暗号鍵に基づく第２のコアネットワーク署名とを受け取るステップとを含む。

上記の装置は、離散的ハードウェアコンポーネント、集積回路、若しくはチップモジュールを備えた離散的ハードウェア回路構成に基づいて、又は、メモリに記憶された、コンピュータ可読媒体上に書かれた若しくはインターネットなどのネットワークからダウンロードされたソフトウェアルーチン若しくはプログラムによって制御される信号処理デバイス若しくはチップに基づいて実装される、ということが注意されるべきである。

無線デバイス、システム、中継局、セル局及び方法は、同様の、対応する、及び／又は同一の好適実施形態を、特に従属請求項において定義されているように、有し得る、ということが理解されるべきである。

本発明の好適実施形態は、従属請求項又は上記の実施形態とそれぞれの独立請求項とのいずれかの組合せでもあり得る、ということが理解されなければならない。本発明のこれらの及び他の態様は、本明細書において以下で説明される実施形態から明らかであり、本明細書において以下で説明される実施形態を参照して明瞭になる。

本発明が実装されているセルラシステムを表す既に説明された概略図である。 図１のネットワークにおける異なる可能性のある動作モードを表す既に説明された概略図である。 本発明の第１の実施形態のプロトコルによる通信の時間ダイアグラムである。 本発明の第２の実施形態のプロトコルによる通信の時間ダイアグラムである。 本発明の第３の実施形態のプロトコルによる通信の時間ダイアグラムである。 本発明の第１の実施形態のプロトコルによる通信の時間ダイアグラムである。 本発明のある実施形態によって可能になる一改善形態に関する時間ダイアグラムである。 本発明のある実施形態によって可能になる一改善形態に関する時間ダイアグラムである。 本発明の他の実施形態におけるプロトコルによる通信の時間ダイアグラムである。 本発明のある実施形態による二次局と中継局とを表すブロック図である。

以下の説明では、問題１、２及び３に対処するソリューションが、様々な実施形態において説明される。これらのソリューションは、第１の実施形態においては、ＣＮによって署名された情報を、特に、それぞれのＵＥ（二次局、リモートＵＥ及び中継局とも称され、中継ＵＥとも称される）に結びつけられた公開鍵を、それぞれのＵＥに分散することを含む。この情報分散フェーズは、初期のプロビジョニング及び認可ステップの間に、すなわち、接続の早い段階で、生じる。ＵＥは、リモートＵＥ又は中継ＵＥであり得る。考察されているＵＥは、動作において、中継ＵＥとして及びリモートＵＥとして交互に動作しなければならないこともあり得る。公開鍵を含む署名された情報により、この第１の実施形態において、以下が許容される。
・動作の間にＣＮにアクセスすることなく中継ＵＥが中継器として作用することが許可されているかどうかを、リモートＵＥがチェックすること。
・動作の間にＣＮにアクセスすることなく許可されている場合に、中継ＵＥが、リモートＵＥのＰＤＵパラメータを確認すること。
・動作の間にＣＮにアクセスすることなく、リモートＵＥと中継ＵＥとがセキュアなＰＣ５リンクを確立すること。

既存のセキュリティソリューション（ＴＲ２３．７５２におけるソリューション＃２８及びＴＲ３３．８４７におけるソリューション＃３２）と比較した場合、本発明のこの第１の実施形態の主要な利点は、それがセキュアな様態で動作している動作中にコアネットワークにアクセスすることを要求しない、という点にある。これは、以下を意味する。
・コアネットワーク上のワークロードがより低いこと、
・いったん動作中であればＣＮとの間での更なるチェックが不要であるから、通信リンクの確立のためのレイテンシが短縮されること、
・中継ＵＥが、カバレッジ範囲外であり得ること、
・リモートＵＥが、カバレッジ範囲外であり得ること、
・プライバシ関連のパラメータが開示されないこと。

このようにして、この第１の実施形態は、プライバシの懸念に対処して問題１及び２を回避するようにＴＲ２３．７５２のソリューション＃２８に適用可能なソリューションを提示する。

なお、この第１の実施形態は、ＴＲ３３．８４７のＫＩ＃１６のコンテキストにおけるＰＤＵパラメータの保護というコンテキストで説明されているが、同じ技法とそれらの技法上での他の実施形態の構築とが、例えば後述の表に記載されているように、他の問題に対処するために用いられることも可能である。この詳細な説明は、これらの問題にソリューションを提供する複数の実施形態を含む。特に、この詳細な説明は、ＴＲ３３．８４７におけるソリューション＃８及びソリューション＃３１に対する改善を提供する。これらの２つのソリューションは、ＴＲ３３．８４７において公開鍵暗号を用いる唯一のソリューションである。ソリューション＃８及びソリューション＃３１は、ＫＩ＃６及びＫＩ＃７にそれぞれ対処する。

本発明の第１の実施形態は他のパラメータの秘密性を保護するために適用可能である、ということが注意されるべきである。例えば、アプリケーション機能は、ＴＲ３３．８４７のソリューション＃２１においてのように、対処する。

このソリューションは、ＴＲ３３．８４７のソリューション＃１、＃６、＃１０及び＃１５への代替的なソリューションとして、ＰＣ５におけるセキュリティ確立のためにも独立に用いられることが可能である、ということが注意されるべきである。

次に、第１の実施形態が、図３を参照して説明される。この説明の前文で説明されたものと類似のネットワークでは、ＣＮが、一般的には、情報に署名することができる。これは、ＴＲ３３．８０９のソリューション＃２０で提案されているデジタル署名ネットワーク機能（ＤＳｎＦ）によって、実現されることが可能である。その代わりに、例えば、アプリケーション機能が、要求される情報に署名することを担当することもあり得る。それに加えて、リモートＵＥは、ＣＮによって署名されるときに情報の確認を可能にするトラストアンカと共に構成される。これらのトラストアンカは、ＤＳｎＦソリューションにおけるようなものであり得る。この第１の実施形態のバリアントでは、これらのトラストアンカは、初期のプロビジョニングフェーズ（下記のステップ１．ａ及び１．ｂ）の間に、ＵＥに配送されることもあり得る。

第１の実施形態は、「ディスカバリモデルＡ」によるＰｒｏＳｅ動作に対応する。実際、制約されたＰｒｏＳｅ直接ディスカバリは、発見されつつあるＵＥの明示的な許可によりその無線アクセス直接無線信号を用いて、ＵＥが近接する他のＵＥを検出して識別するプロセスである。ディスカバリモデルＡ（「わたしはここにいる」）によると、ＵＥをアナウンスする及びＵＥをモニタするというＰｒｏＳｅ対応ＵＥの２つの役割が、このモデルに関係する。アナウンスする側のＵＥは、予め定義されたディスカバリ間隔でディスカバリメッセージをブロードキャストし、これらのメッセージに興味を有するモニタする側のＵＥは、それらを読んで処理する。その代わりに、モデルＢ（「誰がそこにいるのか？」／「あなたはそこにいるか？」）では、発見する側のＵＥと発見される側のＵＥというＰｒｏＳｅ対応ＵＥの２つの役割が関係する。発見する側のＵＥはそれらから応答を受け取ることを望む他のＵＥに関する情報を送るので、それは「誰がそこにいるのか／あなたはそこにいるか？」と同等であり、例えば、この情報は、あるグループに対応するＰｒｏＳｅアプリケーションＩＤに関するものであり得るのであって、そのグループのメンバは応答することが可能である。

第１の実施形態によると、図３に示されているように、
－ステップａでは、初期のプロビジョニングの間に、ＣＮが、中継ＵＥに、例えばそれがサポートする中継サービスコード（ＲＳＣ）など、１組の設定パラメータを分配する。設定パラメータは、例えばそれがどのアプリケーションをサポートするかなど、中継ＵＥによって提供される他の能力を含み得る。この分配は、例えばＲＳＣなど、それぞれの組の設定パラメータがリンクされているプライバシの点でセンシティブな特定のパラメータを中継ＵＥに開示することなく、行われることが可能である。ＣＮは、また、中継ＵＥが用いる中継公開鍵の鍵ペアを作成する。ＣＮは、また、例えば、どのタイプのリモートＵＥのためにどのタイプのリモートＵＥ又は接続に供給することを中継器は許容されるのかを記載しているポリシなど、他の情報も分配することが可能である。ＣＮは、サポートされる設定パラメータと中継公開鍵とに署名する（又は、メッセージの暗号化など、他のセキュリティ処理をする）ことができる。ＣＮは、中継ＵＥに、署名された設定パラメータと中継公開鍵とを、対応する中継秘密鍵と共に、提供する。これは、図３に示されているように単一のメッセージの中で、又はこの実施形態のバリアントでは別個の複数のメッセージにおいて、行われることが可能である。ＣＮによる署名の場合には、コアネットワーク公開鍵も、この時点で共有される。例えば暗号鍵が既に交換されている又は中継ＵＥによって知られている場合などには、他の暗号化プロセスとして、例えば第１のメッセージ全体の暗号化などが含まれる。
－ステップｂでは、初期のプロビジョニングの間に、ＣＮが、リモートＵＥに、例えばＲＳＣなど、特定のＰＤＵセッションパラメータにリンクされている１組の設定パラメータを提供する。ＣＮは、また、二次局公開鍵の鍵ペアを作成する。ＣＮは、設定パラメータと、対応するＰＤＵパラメータとに署名する。それは、二次局公開鍵など、署名に他の要素を含ませることが可能である。ＣＮは、署名された二次局公開鍵と、ＲＳＣと、ＰＤＵパラメータと、二次局秘密鍵とを送る。ＣＮによる署名の場合には、コアネットワーク公開鍵も、この時点で共有される。ＣＮは、また、例えばどのタイプの中継ＵＥがその通信の必要事項を供給することが許されるのかを記載しているポリシなど、他の情報も分配することができる。例えば暗号鍵が既に交換されている又は中継ＵＥによって知られている場合などには、他の暗号化プロセスとして、例えば第２のメッセージ全体の暗号化などが含まれる。また、この分配は、図３に示されているように単一のメッセージにおいて、又は複数のメッセージにおいて、実行されることが可能である。
－ステップｃでは、ディスカバリモデルＡの例では、中継ＵＥが、中継ＵＥディスカバリの間に、例えばそのＲＳＣなど、サポートされる設定パラメータのうちのいくつかをブロードキャストする。ディスカバリモデルＢの場合には、リモートＵＥ（二次局）は、その存在を示すためのあるメッセージをブロードキャストすることがある。実際に、ディスカバリモデルＢでは、リモートＵＥが、ディスカバリメッセージを送るものであり、中継ＵＥではない。第１の実施形態をこの代替的なシナリオに適応するため、リモートＵＥは、例えばそのＲＳＣなど、そのサポートされている設定パラメータを含むディスカバリメッセージを送るものである。
－ステップｄでは、リモートＵＥが、上述のデータを受け取ると、例えばＲＳＣを一致させることにより、中継ＵＥがそのＰＤＵ通信要件をサポートするかどうかをチェックする。
－ステップｅでは、ＲＳＣの一致が存在するかどうかが最初に決定されて、次に、リモートＵＥが、例えば以下のようにして、ＰＣ５接続を確立することを決めることができる。
ｉ．リモートＵＥがナンスＮ＿ｒｅｍｏｔｅを生成し、それを中継ＵＥに送る。オプションであるが、リモートＵＥは、また、中継ＵＥがそのことを知るように、興味を有する特定のＲＳＣを含むことがある。
ｉｉ．中継ＵＥは、下記のものを送る。
１．その公開鍵（ＰｕＫ＿ｒｅｌａｙ）及び例えばＲＳＣなどの設定パラメータ、
２．設定パラメータ（例えば、ＲＳＣ）及びＣＮから受信された公開鍵上のＣＮ署名、すなわち、Ｓ（ＰｒＫ＿ＣＮ，ＲＳＣｓ｜ＰｕＫ＿ｒｅｌａｙ）、
３．受信されたリモートＮ＿ｒｅｍｏｔｅ（オプションとして送られたが、署名計算において要求される）
４． 中継ナンス、Ｎ＿ｒｅｌａｙ。
これらのアイテムの一部又は全部は、中継器の秘密鍵（ＰｒＫ＿ｒｅｌａｙ）を用いて署名されることがあり得る。
図３では、Ｓ（ＰｒＫ，Ｍ）は、秘密鍵ＰｒＫを用いたメッセージＭの署名を意味する。
この説明では、「｜」は、連結動作に対応する。
ｉｉｉ．リモートＵＥは、次に、（ｉ）ＣＮ署名を確認し、（ｉｉ）リモートナンス（ｉｉｉ）を含む中継署名を確認する。こうして、リモートＵＥは、動作の間にＣＮにコンタクトすることを必要とせずに、中継ＵＥが最初にコアネットワークによって認証されたことをチェックすることができる。これは、よって、そうでない場合にはデバイス相互間のそれぞれの接続に対して認証動作を行うことを必要とするコアネットワークへの負荷を減少させる。
ｉｖ．ステップｉｉｉ）が成功すると、リモートＵＥは、次に下記のものを送ることができる。
１．特にＲＳＣと公開鍵ＰｕＫ＿ｒｅｍｏｔｅとにリンクされたそのＰＤＵセッションパラメータである、その通信パラメータ、
２．対応する通信パラメータと公開鍵とに対する対応するＣＮ署名、
３．中継ＵＥから受信されたナンス、すなわち、Ｎ＿ｒｅｌａｙ（オプション）、
４．上記の情報要素（通信パラメータ、対応するＣＮ署名、ナンスＮ＿ｒｅｌａｙ（オプション））は、その公開鍵はＣＮによって署名された二次局秘密鍵（ＰｒＫ＿ｒｅｍｏｔｅ）を用いて署名されることが可能である。
次に、メッセージ全体が、中継ノードの公開鍵ＰｕＫ＿ｒｅｌａｙを用いて暗号化されることが可能であり、その結果、これらのパラメータ及び情報は、無線ネットワーク（ＯＴＡ）を介して平文のまま送られることはない。図３で見られるように、Ｅ（ＰｕＫ，Ｍ）は、公開鍵ＰｕＫを用いるメッセージＭの暗号化を表す。
ｖ．中継ＵＥは、受信された情報を復号化し、リモートのＣＮ署名とリモートＵＥの署名とをチェックする。確認が正しく、Ｎ＿ｒｅｌａｙが存在する場合には、中継ＵＥは、開示されているＰＤＵパラメータのためのリモートＵＥの必要事項を供給する。

よって、先に説明されたように、中継ＵＥへの接続の間は、中継ＵＥもリモートＵＥも、認証／認可の目的でコアネットワークと通信することは必要ない。すべての確認は前もって実装されており、これは、動作の間にＣＮからの助けがなくとも、円滑でセキュアな接続プロトコルに至るのである。よって、カバレッジの範囲外でも、ＵＥは、ＰＤＵセッションにセキュアに接続することができる。

先に説明されたように、ディスカバリモデルＢは、中継ＵＥに接続するために、リモートＵＥにブロードキャストすることを要求する。よって、第１の実施形態の変形例をディスカバリモデルＢの特定の場合に実装するときには、ステップｃにおいて、リモートＵＥは、そのＲＳＣなどのその設定パラメータをブロードキャストする。この代替例の以後のステップで、中継ＵＥは、例えば受信されたＲＳＣなど、受信された設定パラメータをそれ自身のものと一致させる。一致が存在する場合には、中継ＵＥは、その署名されたＲＳＣ、中継ナンス、その中継サービスコードと関係するＣＮ署名、及び／又は第１の実施形態（モデルＡ）における以後のステップと類似するその公開鍵を、送ることができる。

第１の実施形態のバリアントでは、中継ＵＥが追跡されることが不可能な場合があり得る。この目的のため、リモートＵＥは、一過性の公開鍵ペアを生成して、それを、ステップｅのｉにおいて、中継ＵＥに送る。この公開鍵ペアは、一過性であるから、リモートＵＥを追跡するのに用いられるのは不可能である。中継ＵＥは、それを、中継パラメータが外部（受動的）攻撃者から秘密のまま維持されるようにメッセージを暗号化するために、ステップｅのｉｉで用いる。よって、直接通信を確立するステップは、二次局がそれ自身の暗号公開鍵及び秘密鍵を生成するステップを含み得る。二次局ナンスと共に、リモートＵＥは、直接通信リクエストを、中継局に送ることができる。第１の実施形態におけるのと類似するこの第１のメッセージは、オプションであるが、セキュアであり得る。

直接通信リクエストに応答して、中継局は、中継公開暗号鍵、第１のコアネットワーク署名、及び／又は応答メッセージ署名を含む応答メッセージを送り、その場合に、このメッセージは、直接通信リクエストと共に受信された公開鍵を用いて（秘密性が）保護される。

次に、二次局が、受信されたメッセージを復号化して、応答メッセージと応答メッセージ署名とに含まれている第１のコアネットワーク署名をチェックすることができる。

ディスカバリメッセージが小さいために、上述のプロトコルは、ステップｃにおいてＲＳＣを交換することができる、ということが注意されるべきである。往復移動の回数を減少させる第１の実施形態の他のバリアントは、中継ＵＥがその時点（ステップｃ）でその設定パラメータ（又はその一部）、ポリシ、公開鍵、及び署名をブロードキャストすることで構成される。これがなされると、ステップｄにおいて、リモートＵＥは、中継ＵＥのポリシがそのＰＤＵ通信要件をサポートするかどうかを既にチェックすることができる。サポートする場合には、それは、署名を確認することによって、ポリシ及び公開鍵の妥当性をチェックする。このバリアントによる以後のステップｅでは、リモートＵＥは、ソリューション＃２８におけるようにＰＣ５接続を確立することを決定することができるが、追加的に、このＵＥは、中継ＵＥの公開鍵を用いて暗号化されたその署名済みのＰＤＵセッション要件を共有する。最後に、ステップｆで、中継ＵＥは、リモートのＵＥデータを復号化して、その署名を確認することができる。確認が正しく、パラメータがそのポリシによって許容される場合には、中継ＵＥは、リモートＵＥの必要性を供給する。

ここでは、そして本明細書の任意の箇所においても、署名を確認することは、署名自体をチェックすることに加えて、満了日や発行者などの他のフィールドもチェックすることを含む。これは、また、無効にされた公開鍵が含まれている無効リストを検索する又はそれにアクセスすることも含む、ということに注意してほしい。

この先のバリアントに加え、リプレイアタックを（更に）緩和するために、以下が行われ得る。すなわち、ステップ１ｃにおいて、中継ＵＥは、現在のＵＴＣ時間などのタイムスタンプにおいて署名するためのその秘密鍵と、オプションであるがブロードキャストされた情報の残りとを用いることができる。この署名は、また、ステップ１ｃにも含まれ得る。ステップ１ｄでは、リモートＵＥが、受信された署名をＵＴＣ時間において確認して、この時間が最近かどうかをチェックする。こうして、これにより、攻撃者が過去のメッセージを記憶してリプレイするという危険が回避される。

この先のバリアントに加え、ＭｉｔＭ攻撃を（更に）緩和するために、以下が行われ得る。中継ＵＥは、その秘密鍵を、例えばＧＰＳ座標や建物名などであるその現在地に署名するために用いることができる。この情報は、ステップ１ｃに含まれ得る。ステップ１ｄでは、リモートＵＥは、受信された署名を確認し、位置がそれ自体のものと一致するかどうかをチェックする。これにより、攻撃者が特定の位置にある中継デバイスを危険にさらし、そのブロードキャストメッセージを複数の位置で再利用するという危険が回避される。この特徴は、独立に、そしてスタンドアロンで用いられることが可能である。

静的なＲＳＣのブロードキャストはプライバシの危険だと考えられ得るから、第１の実施形態の他のバリアントは、送り手側が、ナンスＮを生成して、疑似ＲＳＣをｐＲＳＣ＝ＨＡＳＨ（ＲＳＣ｜Ｎ）として導くことで構成される。ここで、ＨＡＳＨは、ＲＳＣとＮとの連結を入力として有するハッシュ関数である。送り手側は、次に、（ｐＲＳＣ，Ｎ）をブロードキャストする（ステップｃ）。受け手側は、このハッシュ関数を、それが有するＲＳＣのそれぞれに適用して、一致が存在するかどうかをチェックしなければならない。このアプローチがセキュアであり衝突なく機能するためには、ｐＲＳＣ、ＲＳＣ，及びＮが、十分に長くなければならない。これらの値がディスカバリメッセージ（ステップｃ）において小さいものに過ぎない場合には、以下のメッセージが、より長いパラメータを用いる他のペア（ｐＲＳＣ’，Ｎ’）を含むことがあり得る。

第１の実施形態と既に論じられたすべてのバリアントにおいて、ステップｅのｉｉｉが失敗する場合には、リモートＵＥは、接続を中止する。そして、リモートＵＥは、ＣＮに、確認の失敗について告知し、それが接続される次の機会に、中継ＵＥパラメータを中継することができる。同様に、ステップｅのｖが失敗する場合には、中継ＵＥは、サービスの配送を拒否する。中継ＵＥは、確認の失敗とリモートＵＥのパラメータとについて、ＣＮに告知することができる。よって、セキュリティ上の危険が発見される場合には、コアネットワークは、迅速に告知を受け、懸念される局をチェックすることができる。

第１の実施形態の更なるバリアントでは、リモートＵＥが、ステップｅのｉｉの１の代わりにステップ１のｂにおいて既に許容されている中継ＵＥの公開鍵（又は、フィンガプリント）を、例えばコアネットワークから受信する。

第１の実施形態において説明されたように、ステップ１のｄでは、リモートＵＥが、ＲＳＣが一致するかどうかをチェックすることによって、中継ＵＥがそのＰＤＵ要件をサポートするかどうかをチェックする。これは、一対一の関係であり、特定の行動を実行するために予め定義された役割を用いる「役割ベースのアクセス制御」アプローチと類似する。換言すると、中継ＵＥがＲＳＣ＝ｘを有する場合には、中継ＵＥが認可される。

この署名されたＲＳＣは、「認可トークン」として見られることが可能である。そして、それは、ディスカバリメッセージの帯域幅の必要性に合致する第１のチェックを実行するためにステップ１のｃにおいてＲＳＣ（署名のない「認可トークン」）が分配される、提案される動作であると考えられ得る。完全な「認可トークン」は、先のステップで一致が検出される場合に、ステップｅのｉｉにおいて、分配されることが可能である。スタンドアロンである、この単純な動作は、例えばＴＲ３３．８４７のソリューション＃３１に統合されることが可能である。

「属性ベースのアクセス制御」のコンテキストでは、より複雑な「ポリシ」を定義することが可能であることを注意しておく。ＲＳＣだけを有する代わりに、中継ＵＥのデバイスのタイプ（例えば、それが秘密のデバイスであるか？、それが公開のデバイスであるか？）、実行される行動（例えば、データのアップロードであるか？、データのダウンロードであるか？）、アクセスされているデータ（例えば、秘密のレベル？）、アプリケーション、デバイス若しくはグループのＩＤ、又は現在のコンテキスト（例えば、通常状況であるか、若しくは緊急状況であるか）に関係するより多くの属性を考察することも可能である。受け手（例えば、リモート）側は、例えば送り手（例えば、中継器）側が認可されているかどうかをチェックするのに用いられることが可能なＸＡＣＭＬアクセス制御ポリシを有することがあり得る。このポリシは、ＲＳＣなどいずれかのデバイス属性を含む他の設定パラメータと共に、プロビジョニングの間に分配されることが可能である。

このソリューションが、例えばＴＲ２３．７５２のソリューション＃１１又はソリューション＃８など、（役割若しくは属性と考えることができる）他の組の情報又は設定パラメータをディスカバリの間に要求する場合には、この情報もまた、初期のプロビジョニングの間に、ＣＮによって署名及び分配されることが可能である。ＣＮは、また、プロビジョニングの間に、中継器、リモート又はピアとして作用することが許容されるためにどの要件を他方が満たすべきかを記載しているポリシを分配することも可能である。ステップｅのｉｉ及びｅのｉｖにおいて送られる情報は、ディスカバリの間に送られる情報の全部又は一部を含んでおり、これには、受信の際にデータが確認されプロビジョニングの間にも受信されていたポリシに対して相互チェックされることが可能なように、対応のＣＮ署名が含まれる。

ステップ１のａ及び１のｂでは、ＣＮが、リモートＵＥと中継ＵＥとの両方のための鍵ペアを生成する。或いは、この鍵ペアは、ＵＥによって生成されることも可能であり、公開鍵が、署名されるためにＣＮに送られることも可能である。こうすることの利点は、ＣＮが秘密鍵に関する知識を有しないということである。

ステップ１のａ及び１のｂでは、ＣＮが、リモートＵＥと中継ＵＥとの両方のために、１組の情報に署名する。ＣＮは、また、これらのＵＥがそれらを回転させることが可能なように、すなわちプライバシ上の理由により規則的に変更することが可能なように、複数の組の情報に署名することも可能である。

ステップ１のａ及び１のｂでは、ＣＮが、リモートＵＥと中継ＵＥとの両方のために、公開鍵に署名する。これらの公開鍵は、対応する秘密鍵と関連付けられている。更なるバリアントでは、これらの鍵ペアは、時には公開鍵暗号化のために、時にはデジタル署名のために、用いられることが可能である。一般に、署名と暗号化との両方のために、同じ鍵ペアを（セキュアな様態で）再利用することは、便利である。しかし、例えば暗号化が署名を破るために用いられ得ると情報が漏れるため、これは推奨される慣行ではない。よって、ステップ１のａ及び１のｂは、例えば２個である複数の署名された公開鍵の配送を含むことにより、それら複数の署名のそれぞれが例えば暗号化と署名という異なる目的のために用いられることになる。

リモートＵＥが複数のＰＤＵパラメータのために複数のＲＳＣを有する場合、ＣＮがそのすべての情報にまとめて署名するというのがひとつのオプションである。このアプローチの問題は、リモートＵＥがこの情報を確認のために中継ＵＥに送る（図３のメッセージｅのｉｖ）ときには、リモートＵＥが、すべてのＲＳＣ及びＰＤＵパラメータを送らなければならないということであり、その理由は、そうしなければ、中継ＵＥがメッセージを確認できないからである。これは、再び、プライバシ上の危険となる。これに対するソリューションは、ｎを（リモート）ＵＥが有するＲＳＣの個数として、２ｎ個の葉を有するマークル木を構築することであり得る。このマークル木では、ｋ＝０，・・・，ｎ－１として、葉２ｋ及び２ｋ＋１が、ｋ番目のＲＳＣと、対応するＰＤＵパラメータとを入力としてそれぞれ取る。ＣＮは、マークル木の根に署名する。あるリモートＵＥがそのｋ番目のＲＳＣのためにＰＤＵパラメータを開示しなければならないとき、そのリモートＵＥは、葉２ｋ及び２ｋ＋１と、マークル木の根を計算することを可能にするマークル木における対応する中間ノードと、マークル木の根におけるＣＮ署名とを開示するだけである。

同じことが、中継器におけるＲＳＣに適用される。この場合には、ＲＳＣは、マークル木の葉に対応する。中継器は、図３におけるメッセージｅのｉｉにおける特定のＲＳＣを開示するときには、そのＲＳＣと、根を再計算するためのマークル木における経路と、マークル木の根においてＣＮによって提供された署名とを開示しなければならない。

以上の情報が与えられると、受け手側は、情報がマークル木の根の再計算を許容することをチェックするために、マークル木のその経路と、ＲＳＣ（及びＰＤＵパラメータ）とを用いなければならず、そして、署名をチェックしなければならない。

すべてのバリアントにおいて、適切な署名アルゴリズムは、楕円曲線（ＥＣ）デジタル署名アルゴリズム（ＤＳＡ）であり得る。

初期のプロビジョニングステップにおいて提供される情報は、例えばそれぞれのＲＳＣ、それぞれの公開鍵、それぞれのＰＤＵパラメータなど、それぞれの情報に対して異なる署名を含み得る。これの利点は、異なる情報が、相互に独立に開示されることが可能であるということである。

以上の説明では、公開鍵暗号が用いられた。これは、ＩＤベースの暗号（ＩＢＥ）によって置き換えることが可能である。ＩＢＥでは、ＵＥのＩＤが、その公開鍵に対応する。あるＵＥのＩＤが与えられると、ＣＮは、そのＵＥのための対応する秘密鍵を導くために、マスタ秘密を用いる。ＩＢＥの利点は、公開鍵が交換される必要がない、ということである。他の利点は、公開鍵がそれ自身「証明書」として機能し、「認可された」当事者だけがプライバシの点でセンシティブなコンテンツを受信して復号化することができる、ということである。例えば、「ＲＳＣ＝ｘ、ｅｘｐｉｒａｔｉｏｎ＿ｄａｔｅ＝２０２２／０２／２２」というＩＤを有する中継器を想定する。これは、ある中継器がブロードキャストすることができ、あるリモートＵＥが受信することができる情報である。ＲＳＣ＝ｘ及びｅｘｐｉｒａｔｉｏｎ＿ｄａｔｅが、プロビジョニングの間にリモートＵＥがＣＮから受信したポリシによると、リモートＵＥにとって問題ない場合には、そのリモートＵＥは、中継ＵＥのこのＩＤ「ＲＳＣ＝ｘ、ｅｘｐｉｒａｔｉｏｎ＿ｄａｔｅ＝２０２２／０２／２２」を公開鍵として用いることができる。これは、リモートＵＥが、ＰＤＵパラメータなどプライバシ的にセンシティブなどのようなパラメータも暗号化するためにこの公開鍵を用い、この暗号化された情報を送る、ということを意味する。コアネットワークによって発行された対応する秘密鍵を有する中継器だけが、この情報を復号化することができる。

以上の説明では、あるＵＥが、そのＩＤを証明するために用いられることが可能な秘密鍵を有する。しかし、デジタル署名は、いくつかの実装形態のためにはサイズが大きすぎ、その確認には、相当な計算時間を必要とする。これは、例えば数百ビットに制限されているなど、そのサイズに制限があるディスカバリメッセージについて、特に妥当である。これに対する代わりのソリューションは、あるハッシュチェインのシードとアンカとを用いて、そのハッシュチェインリンクがブロードキャストされたいくつかのされたメッセージはアナウンス側ＵＥから来ていることを証明するのに用いられることが可能であるように、アナウンス側ＵＥ（例えば、中継デバイス）とモニタ側ＵＥ（例えば、リモートＵＥ）とをＣＮが設定することで構成される。そのようなソリューションは、例えば、アナウンス側ＵＥによって送られるディスカバリメッセージに関して、妥当である。このディスカバリメッセージは、図３のメッセージｃに対応する。これらのディスカバリメッセージを保護する時のセキュリティ上の必要性は、ＴＲ３３．８４７の鍵の課題＃１において概略されている。

このソリューションは、鍵の課題＃１（ディスカバリメッセージ保護）に注目している。このソリューションは、ＴＲ３３．８４７のソリューション＃３がしているように、５Ｇ ＰｒｏＳｅのオープンディスカバリのためのＴＳ３３．３０３に特定されているオープンディスカバリセキュリティ機構を再利用することを提案しているが、下記の点が強調されている。
・メッセージ修正及びリプレイアタックに対するレジリエンスを改善すること、
・ソースの信頼性を保証すること、
・コアネットワークがアナウンス側のメッセージの完全性を確認しなくてはならない必要性を除去すること。

提案されている強化は、ＴＳ３３．３０３では、ＰＣ５インターフェースにおけるディスカバリメッセージの完全性保護が、ディスカバリユーザ完全性鍵（ＤＵＩＫ）を要求するという事実を動機とする。この鍵は、メッセージ完全性コード（ＭＩＣ）を計算するのに用いられる。ＭＩＣは、受け手側ＵＥにおいて確認されることが可能であるが、これは、そのＵＥにＤＵＩＫが供給されている場合、又はＤＵＩＫを用いてＰｒｏＳｅ機能にある場合である。第１の場合には、ＤＵＩＫがモニタ側ＵＥに供給され、このモニタ側ＵＥは、ＭＩＣ自体を確認することができる。しかし、複数のモニタ側ＵＥが同じＤＵＩＫを受け取る場合には、完全性保護、リプレイ保護、又はソース信頼性を保証することはできず、その理由は、これらのＵＥのいずれかが悪意を有している可能性があるからである。ＰｒｏＳｅ機能がＭＩＣをチェックしなければならない場合には、これが、ＣＮに対する負荷と全体的な通信レイテンシとを増加させる。

このソリューションの基本的アイデアは、ソース信頼性のためのディスカバリユーザ完全性ハッシュチェイン（ＤＵＩＨＣ）を用いて、ＤＵＩＫの使用を補完することである。以下では、
・Ｈ^ｊ（入力）は、ＴＲＵＮＣ_ｂ（Ｈａｓｈ（識別子｜ｊ｜Ｈ^ｊ－１（入力）））を示し、
・Ｈ^１（入力）＝ＴＲＵＮＣ_ｂ（Ｈａｓｈ（識別子｜１｜入力））である。
ここで、
・「｜」は、連結を示し、
・Ｈａｓｈ（入力）は、与えられた入力に対するハッシュ関数の計算を指し、
・「識別子」は、そのＬ２識別子、ＵＥがアナウンスしているＰＬＭＮ、ＵＥが「ＮＧ－ＲＡＮによって供給されていない」ときの無線パラメータなど、アナウンス側ＵＥのＩＤに関係する固定されプロビジョニングされたポリシ／パラメータを含み、
・ＴＲＵＮＣｂ（Ａ）は、例えばＡの最下位のｂビットなど、入力Ａのｂビットを返す関数である。

Ｈ^ｊ（入力）の計算に「ｊ」及び／又は「識別子」のいずれかを含むことは、オプションであるが、計算前の攻撃に対してソリューションをよりレジリアントにする。ＴＲＵＮＣ_ｂ（Ａ）の使用は、通信オーバヘッドを減少させることができることを目的とする。

これを用いると、ＤＵＩＨＣは、下記のように、ランダムに生成されたシードＳから得られる。
Ｓ→Ｈ^１（Ｓ）→Ｈ^２（Ｓ）→Ｈ^３（Ｓ）→・・・→Ｈ^Ｎ－２（Ｓ）→Ｈ^Ｎ－１（Ｓ）→Ｈ^Ｎ（Ｓ）

ここで、矢印「→」は、ハッシュチェインのリンクＨ^１（Ｓ）→Ｈ^２（Ｓ）→・・・を生成するときの向きを示す。最後の要素Ｈ^Ｎ（Ｓ）は、このＤＵＩＨＣのアンカである。

中継ＵＥなどアナウンス側ＵＥには、そのＤＵＩＨＣのシードＳが与えられる。すべてのモニタ側ＵＥには、アナウンス側ＵＥのＤＵＩＨＣのアンカが与えられる。これらのステップは、図３のステップａ及びステップｂに対応するデバイスの認可及び初期プロビジョニングの間に行われ得る。ＵＥにこれらのパラメータが与えられると、これらのＵＥには、また、アナウンス側ＵＥがハッシュチェインリンクを用いると仮定される時間である基準時間ｔ０と、タイムスロット継続時間ｔＤｅｌｔａとが与えられる。

あるアナウンス側ＵＥがＵＴＣ時間ｔにおいてアナウンスメッセージｍを送ることを望むときには、このアナウンス側ＵＥは、最初に、アナウンス側ＵＥがＤＵＩＨＣのリンクＨ^Ｎ－ｊ（Ｓ）を使わなければならないことを意味する（ｔ－ｔ０）／ｔＤｅｌｔａとして、現在のタイムスロットｊを計算する。これは、Ｎ－ｊ＞０であることを要求することに注意してほしい。アナウンス側ＵＥは、メッセージｍのＭＩＣの作成において用いられる最終的な鍵を計算するために、ＤＵＩＫと共にＨ^Ｎ－ｊ（Ｓ）を用いる。この鍵は、ディスカバリユーザ完全性鍵及びハッシュチェインリンク（ＤＵＩＫＨＣＨＬ）として示され、下記のように計算される。
ＤＵＩＫＨＣＬ＝Ｈａｓｈ（ＤＵＩＫ｜Ｈ^Ｎ－ｊ（Ｓ））

ＤＵＩＫＨＣＬの導出にＤＵＩＫを含める理由は、既存のＴＳ３３．３０３ソリューションとの間での相互運用性を提供することである。これは、また、このソリューションが既存のソリューションと同じくらいセキュアであることを保証する。他の選択肢として、Ｈ^Ｎ－ｊ（Ｓ）だけを用いること、又はＭＩＣの計算においてそれに従属する鍵を用いることがある、ということに注意すべきである。

メッセージｍのＭＩＣは、ＭＩＣ_ｍと示され、次のように計算される。
ＭＩＣ_ｍ＝ＭＩＣ（ｍ，ＤＵＫＨＣＬ）

アナウンス側ＵＥは、また、下記のように、前のＤＵＩＨＣリンクを、すなわち、ブロードキャストされたアナウンス側メッセージにおけるＨ^{Ｎ－ｊ＋１}（Ｓ）を含む。
ｍ，Ｈ^{Ｎ－ｊ＋１}（Ｓ）， ＭＩＣ_ｍ

あるモニタ側ＵＥが時間ｔにおいて上記のアナウンス側メッセージを受け取ると、そのモニタ側ＵＥは、基準時間ｔ０とタイムスロット継続時間ｔＤｅｌｔａとを入力として取り入れることにより、タイムスロットｊを最初に計算する。次に、モニタ側デバイスは、後続のアナウンス側メッセージにおいてＨ^Ｎ－ｊ（Ｓ）を受け取るための次のタイムスロットｊ＋１まで、受け取られたメッセージをキャッシュする。Ｈ^Ｎ－ｊ（Ｓ）を用いて、モニタ側ＵＥは、下記のものをチェックすることができる。
ａ）前のメッセージにおいて受け取られたＭＩＣの有効性、したがって、メッセージ自体の完全性。これは、ＤＵＩＫＨＣＬを再計算することによって、受け取られたＭＩＣ_ｍが計算されたＭＩＣと一致することをチェックすることによって、なされる。
ｂ）Ｈ^Ｎ－ｊ（Ｓ）の受信された値が正しいことをチェックすることによる、メッセージの新鮮性及びソース信頼性。この目的のため、モニタ側ＵＥは、入力として、受信されたアンカを用いる。

結果的なメッセージフローは、ＴＲ３３．８４７におけるソリューション＃３及びＴＳ３３．３０３で特定されているオープンディスカバリセキュリティ機構と同様である。図６．３．２－１を参照すると、以下のような鍵の差異が、ＤＵＩＫの次にＤＵＩＨＣを使用することから生じる。
・ ステップ４（ディスカバリ応答）は、また、ＤＵＩＨＣのシードＳと、基準時間ｔ０と、時間スロット継続時間とを含む。
・ ステップ５（アナウンスの開始）は、上述されたようにブロードキャストされたＭＩＣを計算するときに、ＤＵＩＨＣにおけるリンクを用いるように修正される。
・ ステップ９（ディスカバリ応答）は、ＤＵＩＨＣのアンカと、基準時間ｔ０と、時間スロット継続時間とを含む。
・ ステップ１０（アナウンスされたコードの受信）は、上述されたようにブロードキャストされ受信されたメッセージの完全性と新しさとソース信頼性とを確認するために、ステップ９におけるＤＵＩＨＣの受信されたアンカを用いるように修正される。
・ ステップ１１～１５は、要求されない。
追加的に、
・ モニタ側のＵＥが間違ったＭＩＣ又はＤＵＩＨＣリンクを有するディスカバリメッセージを検出する場合には、そのモニタ側のＵＥは、ＨＰＬＭＮ又はＭ－ＵＥのＤＤＮＭＦに、そのイベントについて告知することができる。
・ アナウンス側のＵＥが無効にされる場合には、ＨＰＬＭＮ又はＭ－Ｕ ＤＤＮＭＦが、そのアナウンス側のＵＥを発見することができることへの興味を表現したモニタ側のＵＥに、告知しなければならない。
・ ステップ９でモニタ側のＵＥが受信するＤＵＩＨＣアンカは、アナウンス側のＵＥのＤＵＩＨＣの最新のリンク、又は最近開示されたリンクに対応する。

上述された基本的なアイデアは、制限ディスカバリモードＡにも同様に適用されることが可能である。

上述された基本的なアイデアは、また、制限ディスカバリモードＢにも適用されることが可能である。これにより、被ディスカバリ側のＵＥとディスカバリ側のＵＥとの両方が、ポリシに基づいてそれらのＩＤを証明するためのＤＵＩＨＣの所有者になり得ることが要求される。ＤＵＩＨＣを所有することは、複数のディスカバリ側のＵＥが同じ被ディスカバリ側のＵＥを発見することができて、ディスカバリ側のＵＥからの応答（応答コード）の確認が被ディスカバリ側のＵＥによってローカルに行われる場合には、被ディスカバリ側のＵＥにとって、特に適切である。

上述されたＤＵＩＣＨアプローチと共に又はＤＵＩＣＨアプローチなしで用いられることが可能な、ディスカバリメッセージにおけるセキュリティの保証を改善させる代替的方法は、以下の通りである。モードＢでは、ＴＳ３３．３０３を参照してほしいが、ディスカバリ側のＵＥは、クエリコードを被ディスカバリ側のＵＥに送ることが要求される。被ディスカバリ側のＵＥは、その完全性／新しさ／ソース信頼性をチェックしなければならないが、確認が成功する場合には、被ディスカバリ側のＵＥが、応答コードを用いて、ディスカバリ側のＵＥに返答する。ディスカバリ側のＵＥは、このメッセージの完全性／新しさ／ソース信頼性をチェックできなければならない。ＴＳ３３．３０３では、ＤＵＩＫに基づく被ディスカバリ側のＵＥによる確認は、ローカルにしか生じることができないが、被ディスカバリ側のＵＥによるＤＵＩＫベースの確認は、一致報告に基づくコアネットワークでは、ローカルに又はリモートで、生じることが可能である。これにより、例えば、複数のディスカバリ側のＵＥが同じ被ディスカバリ側のＵＥを発見できる場合には、ディスカバリ側のＵＥのうちの１つが、不正な行動をして被ディスカバリ側のＵＥになりすます、というような状況に至る場合があり得る。この状況は、ディスカバリ側のＵＥから被ディスカバリ側のＵＥへのＤＵＩＫｒｅと、被ディスカバリ側のＵＥからディスカバリ側のＵＥへのＤＵＩＫｅｒという２つのＤＵＩＫを有することによって、改善が可能である。これにより、複数のディスカバリ側のＵＥが同じ被ディスカバリ側のＵＥを発見する場合には、応答コードのＭＩＣが一致報告によって確認されていれば、ディスカバリ側のＵＥは、どれであっても、被ディスカバリ側のＵＥによって生成された応答コードになりすますことは不可能である。この第２の点に関する更なる詳細と明確化は、以下の通りである。
○ ＴＲ３３．８４７における鍵の課題＃１は、制限されたディスカバリが、潜在的なセキュリティ要件として、完全性保護と、新しさと、ソース信頼性とを有することを示している。鍵の課題＃１は、また、潜在的な脅威として、攻撃者が被ディスカバリ側の又は発見されたＵＥになりすます可能性を示している。
○ ソリューション＃４は、ＴＳ３３．３０３におけるＬＴＥのソリューションを再利用している。モードＢでは、ディスカバリユーザ完全性鍵（ＤＵＩＫ）が、クエリコード及び応答コードの保護のために用いられる。ディスカバリ側のＵＥは、クエリコードを被ディスカバリ側のＵＥに送る。被ディスカバリ側のＵＥは、応答コードを用いて、ディスカバリ側のＵＥに返答する。被ディスカバリ側のＵＥは、受信されたクエリコードのＭＩＣを確認するために一致報告を利用することができない。ディスカバリ側のＵＥは、受信された応答コードのＭＩＣを確認するために一致報告を利用することができる。
○ このソリューションは、ディスカバリ側のＵＥのコード送出セキュリティパラメータが被ディスカバリ側のＵＥのコード受信セキュリティパラメータにリンクされていることを記載している。この組のセキュリティパラメータは、クエリコードセキュリティパラメータと称される。
○ このソリューションは、被ディスカバリ側のＵＥのコード送出セキュリティパラメータがディスカバリ側のＵＥのコード受信セキュリティパラメータにリンクされていることを記載している。この組のセキュリティパラメータは、応答コードセキュリティパラメータと称される。
○ このソリューションは、どこにも、クエリコードセキュリティパラメータにおけるセキュリティ鍵が応答コードセキュリティパラメータにおけるセキュリティ鍵と異ならなくてはならないと記載していないから、潜在的なセキュリティの課題が生じ得る。実際に、図６．４．２．２－１におけるステップ４及び１１は、２つの組のセキュリティパラメータが同一であることを示している。
○ これが要件として明示的に記載されていない場合には、単純なエラーが生じる可能性がある。例えば、全く同じＤＵＩＫが、クエリコードセキュリティパラメータと応答コードセキュリティパラメータとにおいて設定されている、と想定してほしい。この状況では、ディスカバリ側のＵＥは、被ディスカバリ側のＵＥになりすますことが可能である。これは、ディスカバリ側のＵＥが、受信された応答コードのＭＩＣを確認するために一致報告を使用しなければならない場合であっても、なされることが可能である。
○ この課題は、ディスカバリ側のＵＥのコード送出セキュリティパラメータにおける例えばＤＵＩＫであるセキュリティ鍵が、被ディスカバリ側のＵＥのコード送出セキュリティパラメータにおけるセキュリティ鍵と同一であってはならない、換言すると、（ディスカバリ側のＵＥから被ディスカバリ側のＵＥへの）ＤＵＩＫｒｅと（被ディスカバリ側のＵＥからディスカバリ側のＵＥへの）ＤＵＩＫｅｒという２つのＤＵＩＫは相互に異ならなければならないと要求することによって、対処されることが可能である。
○ ＴＲ３３．８４７とＴＳ３３．３０３とにおいてこの性質を説明する仕方は、下記の通りである。すなわち、
■ ディスカバリ側のＵＥのコード送出セキュリティパラメータと被ディスカバリ側のコード受信セキュリティパラメータとは、クエリコードセキュリティパラメータと称されるべきである。
■ 被ディスカバリ側のＵＥのコード送出セキュリティパラメータとディスカバリ側のコード受信セキュリティパラメータとは、応答コードセキュリティパラメータと称されるべきである。
■ クエリコードセキュリティパラメータと応答コードセキュリティパラメータとは、異ならなくてはならないと記載されるべきである。

３ＧＰＰ（登録商標）のＳＡ３＃１０４ｅに提出されたＴｄｏｃのＳ３－２１２４６４は、グループ構成員及び中継器のディスカバリのためのキーイング手順を説明している。特に、このＴｄｏｃは、例えば公開の安全シナリオに関して、カバレッジの範囲内における及びカバレッジの範囲外においてグループ構成員及び中継器のディスカバリをサポートするために必要なセキュリティパラメータを、ＵＥがどのようにして取得するかを説明している。ＴｄｏｃのＳ３－２１２４６４では、以下のように、すなわち、「グループ構成員のディスカバリは、制限されたタイプのディスカバリであり、カバレッジの範囲内で及びカバレッジの範囲外でサポートされることが期待される。グループ構成員のディスカバリは、ディスカバリメッセージの完全性、機密性及び非追跡可能性をサポートするために、プロビジョニングされた鍵を用いる。他の鍵がそれから導出可能なディスカバリのルート鍵が、ＯＴＡによるディスカバリ及び通信をセキュアにするのに用いられる。このルート鍵は、５ＧのＤＤＮＭＦによって及び／又は５ＧのＰＫＭＦによってプロビジョニングされることが可能である」と説明されている。ＴｄｏｃのＳ３－２１２４６４は、更に、ＴＳ３３．３０３［２］に基づいて、更なるソリューションを、下記のように、すなわち、「グループ構成員ディスカバリと中継器ディスカバリという両方の公開安全ディスカバリシナリオのために、同じソリューションが提供されるのであって、公開安全ディスカバリ鍵（ＰＳＤＫ）が、公開安全ディスカバリメッセージの保護のために用いられるルート鍵としてプロビジョニングされ、１つ又は複数のディスカバリグループＩＤ又はそれぞれの中継サービスコード（ＲＳＣ）と関連付けされる。これらの識別子の両方が、ＴＳ２３．３０３［５］で、定義されている」と提案している。グループ構成員ディスカバリのためのステップは、「ステップ０：ＵＥがネットワークに接続し、グループ構成員ディスカバリを実行するための認可をＰＣＦから取得する。ＵＥは、また、そのＨＰＬＭＮの５ＧのＤＤＮＭＦ及び／又は５ＧのＰＫＭＦのアドレスも得る。セキュリティポリシに加えて、以下の追加的なパラメータ、すなわち１組の１つ又は複数のアプリケーションレイヤグループのＩＤ、（ＰｒｏＳｅ）レイヤ２グループのＩＤ、ユーザ情報、ディスカバリグループのＩＤ、及びそれらの有効時間などが、ＵＥに送られる。ステップ１：ＵＥが、５ＧのＤＤＮＭＦとの、又はそのＨＰＬＭＮの５ＧのＰＫＭＦとのセキュアな接続を確立する。ＵＥのＩＤが、５ＧのＤＤＮＭＦ又は５ＧのＰＫＭＦによって認証され認可される。ステップ２：ＵＥが、ディスカバリ鍵リクエストを、５ＧのＤＤＮＭＦに、又はそのＨＰＬＭＮの５ＧのＰＫＭＦに送る。この鍵リクエストは、少なくとも以下の情報を、すなわち、ＵＥのＩＤ、１組の１つ又は複数のディスカバリグループのＩＤ、及びそれらの有効時間を含む。ステップ３：５ＧのＤＤＮＭＦ又は５ＧのＰＫＭＦが、ＵＥがグループ構成員ディスカバリのために認可されているかどうかをチェックする。ステップ４：ステップ３でのチェックが成功する場合には、５ＧのＤＤＮＭＦ又は５ＧのＰＫＭＦが、ディスカバリグループのＩＤとそのＰＬＭＮのＩＤとに対応する公開安全ディスカバリ鍵（ＰＳＤＫ）を生成する。複数のＰＳＤＫが生成されることがあるが、全体の有効時間は、ステップ２の対応する１組のディスカバリグループのＩＤの有効時間に一致するはずである。ステップ５：５ＧのＤＤＮＭＦ又は５ＧのＰＫＭＦが、鍵応答をＵＥに送る。この鍵応答メッセージは、少なくとも以下の情報を、すなわち、ＵＥのＩＤ、ＰＤＳＫの識別子、ＰＤＳＫ、有効時間を含む。中継器のディスカバリに関しては、中継器のディスカバリのための手順／ステップは、上述されたグループディスカバリのためのものと同一であるが、以下の点が例外である。すなわち、（ｉ）ＵＥは、今度は、リモートＵＥ又はＵＥとネットワークとの間の中継器であり、（ｉｉ）パラメータディスカバリグループのＩＤの代わりに、中継サービスコードが用いられ、（ｉｉｉ）レイヤ２のグループＩＤの代わりに、宛先レイヤ２のＩＤが用いられ、（ｉｖ）アプリケーションレイヤグループのＩＤは、用いられない」を含む。提案されているソリューションＴｄｏｃのＳ３－２１２４６４は、先の実施形態で説明されたディスカバリフェーズの間に用いられるクエリコードセキュリティパラメータと応答コードセキュリティパラメータとのために異なる鍵を有する必要性を識別しない。単一のＰＳＤＫが、ＴｄｏｃのＳ３－２１２４６４で提案されているように、公開安全ディスカバリメッセージの保護のために用いられるルート鍵としてプロビジョニングされる場合には、そして、クエリコードセキュリティパラメータと応答コードセキュリティパラメータとが異なるＤＵＩＫを有するように、鍵導出機能が適用される場合でも、関与するデバイスは、すべてのこれらの鍵を生成することが可能であり、よって、ディスカバリ側のＵＥは、上述されたように、被ディスカバリ側のＵＥのなりすましが可能であり得る。このセキュリティに関する課題に対処するためには、ディスカバリのためのキーイング手順が、クエリコードセキュリティパラメータと応答コードセキュリティパラメータとの導出のために用いられる異なるマスタ鍵を、すなわち異なるＰＳＤＫを、分配しなければならない。例えば、２つの異なるマスタ鍵は、ＰＳＤＫ＿ＱＣＳＰとＰＳＤＫ＿ＲＣＳＰとであり得るが、ＰＳＤＫ＿ＱＣＳＰは、（ＤＵＩＫ、ＤＵＳＫ及び／又はＤＵＣＫを含む）クエリコードセキュリティパラメータを生成するのに用いられ、ＰＳＤＫ＿ＲＣＳＰは、（ＤＵＩＫ、ＤＵＳＫ及び／又はＤＵＣＫを含む）応答コードセキュリティパラメータを生成するのに用いられる。このようにして、なりすまし攻撃が、実行可能ではなくなる。ＰＳＤＫ＿ＱＣＳＰとＰＳＤＫ＿ＲＣＳＰとは、独立かつランダムに生成されるか、又は、鍵導出機能を適用することによって、マスタ鍵から生成される。この最後の場合には、Ｋは、特にリモートＵＥ及び中継ＵＥであるＵＥには開示されないのであるが、その理由は、そうでないと、なりすまし攻撃が実行可能になるからである。これらの鍵の生成又は検索は、対応するネットワークがコアネットワークで機能するときに、例えばＤＤＮＭＦ又はＰＫＭＦなどのコアネットワークにおける対応するネットワーク機能がＵＥを認可し、例えばＵＥがリモートＵＥであるか、中継ＵＥであるか又はその両方であるかというその役割を識別するときに、ステップ４において、行われることが可能である。これらの鍵の分配は、上述したステップ５において、行われる。

ＴＲ３３．８４７ ｖ０．７．０（０８／２０２１）においては、Ｔｄｏｃ Ｓ３－２１２４６４の改訂版におけるＳＡ３＃１０４ｅの構築の後に、ソリューション＃３７が含まれる。ソリューション＃３７は、ディスカバリのためのキーイング手順が異なるマスタ鍵を分配しなければならないことを示す。この更新されたプロトコルは、上述された攻撃を回避するために、プロトコルを幾分改善しているが、その理由は、ＵＥは、今では、例えば、クエリコードセキュリティパラメータのためのＰＤＳＫと応答コードセキュリティパラメータのためのＰＤＳＫという２つのＰＤＳＫなど、いくつかのＰＤＳＫを受け取ることができるからである。これは、（単一の）ＰＤＳＫがＵＥに分配され、鍵導出機能（ＫＤＦ）によりＰＤＳＫからディスカバリ鍵（ＤＵＳＫ、ＤＵＣＫ、ＤＵＩＫ）を生成することを可能にするという事実を含め、複数のＵＥの間のディスカバリメッセージの保護が説明されているＴＳ３３．３０３のセクション６．６．７と比較すると、状況を改善している。しかし、ＴＲ３３．８４７ ｖ０．７．０（０８／２０２１）のソリューション＃３７における説明は、依然として十分ではない。その理由は、一致報告を用いるディスカバリ側のＵＥが、ＤＵＩＫを導出するのに用いられることが可能なＭＩＣ又はどの他の鍵であっても確認するのに用いられるＤＵＩＫを受信してはならないからである。ＤＵＩＫを導出するのに用いられるＰＤＳＫが、それがＤＵＳＫ及びＤＵＣＫを生成することを可能にするという理由により、ＵＥに分配される場合には、ＵＥはＰＤＳＫを有しており、したがってＤＵＩＫを生成できるのであるから、問題は解決されない。よって、ＴＲ３３．８４７ ｖ０．７．０（０８／２０２１）に適用可能な改善されたキーイング手順は、ＵＥに、特にディスカバリ側のＵＥに、下記のものを分配することで構成される。
○ クエリコードセキュリティパラメータを確保するために用いられる第１の組のＤＵＩＫ，ＤＵＳＫ及びＤＵＣＫを生成することを可能にする第１のＰＤＳＫ、並びに
○ 応答コードセキュリティパラメータを復号化／スクランブル解除するのに用いられるが第２のＤＵＩＫを含まない第２のＤＵＣＫ及び／又は第２のＤＵＳＫ。
これらの第２のＤＵＣＫ、ＤＵＳＫ、及びＤＵＩＫキーは、ＫＤＦにより例えば第２のＰＳＤＫから生成され得る。

ＴＲ３３．８４７ ｖ０．７．０（０８／２０２１）では、結論に、鍵の課題（ＫＩ）＃１及び＃２に関するＳＡ３＃１０４ｅの後で、到達する。制限されたＰｒｏＳｅ直接ディスカバリシナリオのためのＫＩ＃１では、ソリューション＃４が規範的作業のための基礎として用いられるが、これには、「ディスカバリ側のＵＥのコード送出セキュリティパラメータにおけるセキュリティ鍵と、被ディスカバリ側のＵＥのコード送出セキュリティパラメータにおけるセキュリティ鍵とは、独立でランダムに生成されることが必要である。これにより、ディスカバリ側のＵＥが一致報告を利用するときには、被ディスカバリ側のＵＥのなりすましが実行可能ではないことが保証される。」という注記が含まれる。鍵が独立でランダムに生成されるという記載は、なりすまし攻撃を回避するためにこれらの鍵が異なることを要求する上述の実施形態と整合している。ＫＩ＃２には、「直接ディスカバリに対する結論は、以下の通りである。（１）ディスカバリ鍵は、暗号鍵、完全性鍵及びスクランブル鍵を含む。（２）オープンディスカバリのためには、完全性鍵だけが、５ＧのＤＤＮＭＦによって割り当てられ、アナウンスメッセージの完全性保護を提供するために用いられる。（３）制限されたディスカバリのためには、５ＧのＤＤＮＭＦが、プローズサービスの要件に基づき、ディスカバリ鍵を割り当てる」と、記載されている。ＫＩ＃２における結論は、上述されたなりすまし攻撃に勝利するためには不十分であり、ソリューション＃４と整合がとれていないのであるが、その理由は、ＫＩ＃２における結論はＤＵＩＫの個数を１に限定しているからである。よって、ＫＩ＃２に対する結論は、「ディスカバリ鍵は少なくとも暗号鍵と、少なくとも完全性鍵と、少なくともスクランブル鍵とを含む」と記載するように、更新されるべきである。

ＴＳ３３．５０３における条項６．３は、５ＧのＰｒｏＳｅにおけるＵＥとネットワークとの間を中継する通信のためのセキュリティを説明している。５ＧのＰｒｏＳｅレイヤ３を介するＵＥとネットワークとの間の中継での５ＧのＰｒｏＳｅ通信とコントロールプレーンとのためのセキュリティに関して（ＴＳ３３．５０３における条項６．３．３．３）、「ＰＣＦは、ＴＳ２３．３０４［２］における５．１．４に特定されているように、５ＧでのＵＥとネットワークとの間の中継のディスカバリと通信とのために、認可ポリシとパラメータとをプロビジョニングしなければならない」と記載されている。ＴＳ２３．３０４における条項５．１．４では、「セキュリティパラメータがＰＣＦによって提供されることが可能かどうかと、セキュリティパラメータの詳細とは、ＳＡ３のＷＧによって決定される」と、記載されている。ＴＳ３３．５０３の図６．３．３．３．２－１におけるメッセージフローの最初の２つのステップには、「リモートＵＥと中継ＵＥとは、ネットワークに登録されなければならない」と記載されている。ＵＥとネットワークとの間の中継は、中継ＵＥとしてサポートするためには、ネットワークによって認証され認可されなければならない。リモートＵＥは、リモートＵＥとして機能するためには、ネットワークによって認証され認可されなければならない」と記載されている。この目的のためには、リモートＵＥと中継ＵＥとは、それらのそれぞれのＡＭＦにコンタクトしなければならない。ＡＭＦは、ネットワークにおいて登録する際のエントリポイントとして機能する。ＴＳ２３．３０４の条項４．３．４によると、ＡＭＦは、「登録リクエストにおける「５ＧＭＭ能力」の一部としての５ＧのＰｒｏＳｅ能力の指示に基づく５ＧのＰｒｏＳｅポリシ／パラメータのプロビジョニングをサポートするＰＣＦ」を選択する。その後では、「リモートＵＥは、ＴＳ２３．３０４［２］の条項６．３．１．２又は６．３．１．３のそれぞれに特定されているように、モデルＡ又はモデルＢの方法のいずれかを用いて、ディスカバリ手順を開始しなければならない」と記載されている。プロセスにおける後の段階（ＴＳ３３．５０３における図６．３．３．３．２－１におけるステップ４）では、中継ＵＥのＡＭＦが、中継ＵＥが（リモートＵＥのための）中継器として機能することを認可する。ＡＭＦは、ＴＳ２３．３０４の条項４．３．４に従って、５ＧのＰｒｏＳｅに関係する加入情報をＵＤＭから取得してそれをＵＥコンテキストデータの一部として記憶するためにＵＤＭにコンタクトすることによって、それを行う、ということを注意してほしい。

２つの異なるエンティティが、ディスカバリ手順が機能するために中継ＵＥとリモートＵＥとの両方に分配されることが必要なパラメータとディスカバリ鍵との管理を担当するのは、不可能である。よって、ＴＳ３３．５０３における現在の仕様は、どちらのエンティティがディスカバリパラメータ及び鍵を管理し、どちらのエンティティが、ＵＥがディスカバリパラメータ及び鍵を取得することを認可するのかを解決してない。特に、単一のネットワークにおける単一のネットワーク機能が、ディスカバリ鍵の管理を担当することは可能であり、これは、ネットワークの中の１つにおけるＰＣＦ、ＰＫＭＦ、ＤＤＮＭＦ又は他のＮＦであり得る。

上述された問題を克服する第１の実施形態では、リモートＵＥ（又は中継ＵＥ）は、そのネットワークに登録しており、例えば中継ＵＥ（又はリモートＵＥ）のネットワークである異なるネットワークによって提供される所与のネットワーク中継サービスのための認可を求める。この場合に、リモートＵＥ（又は中継ＵＥ）の（例えばＡＭＦ又はＰＣＦを通過する）ネットワークは、中継ＵＥ（又はリモートＵＥ）のネットワークに、特に、ＰＣＦ又は中継ＵＥ（若しくはリモートＵＥ）のディスカバリ鍵（例えばＰＫＭＦ、ＤＤＮＭＦ）を担当する鍵管理機能に、リモートＵＥ（又は中継ＵＥ）（のＩＤ若しくはそれによるリクエストされた中継サービス）について、告知する。そうするときに、中継ＵＥ（又はリモートＵＥ）の（例えばＰＣＦなどの）ネットワークは、リモートＵＥ（又は中継ＵＥ）のネットワークに、リモートＵＥ（又は中継ＵＥ）のための対応するディスカバリパラメータ及び鍵を提供する。リモートＵＥのネットワークと中継ＵＥのネットワークとは、両方のネットワークからの入力（例えば、部分鍵、ＵＥのＩＤ若しくはネットワークＩＤ）に基づいてディスカバリ資格証明書又は鍵を作成するために、協働することができる。これがいったん終了すると、リモートＵＥ（又は中継ＵＥ）は、ＴＳ３３．５０３の図６．３．３．３．２－１におけるメッセージフローにおけるステップ０ａ及び０ｂに説明されているように、リモートＵＥ（中継ＵＥ）のネットワークによって、登録され、認証され、認可される。特に、それは、この段階において、ディスカバリパラメータ及び鍵を受信する。リモートＵＥ（又は中継ＵＥ）の（例えばＰＣＦなどの）ネットワークは、ディスカバリパラメータ及び鍵を更新するたびに、次に中継ＵＥ（又はリモートＵＥ）へのパラメータの更新を担当することになる中継ＵＥ（又はリモートＵＥ）の（例えばＰＣＦなどの）ネットワークにコンタクトしなければならない。

上述された問題を克服する第２の実施形態では、リモートＵＥ（又は中継ＵＥ）は、そのホームネットワークに登録しており、例えば中継ＵＥ（又はリモートＵＥ）のネットワークである異なるネットワークによって提供される所与のネットワーク中継サービスのための認可を求める。この場合に、リモートＵＥ（又は中継ＵＥ）の（例えばＡＭＦ又はＰＣＦを通過する）ネットワークは、中継ＵＥ（又はリモートＵＥ）のネットワークに、特に、中継ＵＥ（又はリモートＵＥ）のＰＣＦに、リモートＵＥ（又は中継ＵＥ）（のＩＤ）と中継サービスの必要性とについて、告知する。更に、リモートＵＥ（若しくは中継ＵＥ）の（例えばＡＭＦ又はＰＣＦを通過する）ネットワークは、リモートＵＥ（若しくは中継ＵＥ）に、中継ＵＥ（若しくはリモートＵＥ）のネットワークについて、特に中継ＵＥ（リモートＵＥ）のＡＭＦ若しくはＰＣＦ、並びに／又はディスカバリ鍵を担当しておりＴＳ３３．５０３における図６．３．３．３．２－１におけるメッセージフローのステップ０ａ及び０ｂでの登録、認証及び認可及び／若しくはディスカバリ鍵の検索のためにコンタクトしなければならない鍵管理機能について、告知する。これは、この第２の実施形態が用いられる場合には、リモートＵＥと中継ＵＥとの両方が、同じネットワークすなわちサービスを提供しているネットワークから、ディスカバリパラメータ及び鍵を検索することを意味する。特に、リモートＵＥと中継ＵＥとの両方が、対応する例えばＰＣＦから、ディスカバリパラメータ及び鍵を検索することになる。

上記の実施形態と組み合わされることが可能な第３の実施形態では、中継ＵＥのネットワークとリモートＵＥのネットワークとが、中継サービスコードを一致させる又は整合させるために対話をする。例えば、上述した第１の実施形態では、リモートＵＥ（又は中継ＵＥ）のネットワークが、中継ＵＥ（又はリモートＵＥ）のネットワークに、中継ＵＥ（又はリモートＵＥ）によってリクエストされた（与えられた）中継サービスについて告知すると、中継ＵＥ（リモートＵＥ）のネットワークは、他方のネットワークの中継サービスコードとそれ自体のネットワークにおいて用いられる中継サービスコードとを一致させる／整合させる。

ＴＳ３３．５０３の条項６．３は、５ＧのＰｒｏＳｅでのＵＥとネットワークとの間での中継通信のためのセキュリティを説明している。５ＧのＰｒｏＳｅでのレイヤ３のＵＥとネットワークとの間での中継を介する５ＧのＰｒｏＳｅ通信のためのセキュリティでは、ユーザプレーン（ＵＰ）アプローチ（ＴＳ３３．５０３の条項６．３．３．２）とコントロールプレーン（ＣＰ）（ＴＳ３３．５０３の条項６．３．３．３）が、５ＧのＰｒｏＳｅのレイヤ３でのＵＥとネットワークとの間の中継認可とセキュリティ確立とのために説明されている。図７は、ＴＳ３３．５０３の図６．３．３．２．２－１（ＵＰにおけるＵＥとネットワークとの中継のための認可及びセキュアなＰＣ５リンク確立手順）を参照し、図８は、ＴＳ３３．５０３の図６．３．３．３．２－１（ＣＰにおけるＵＥとネットワークとの中継のための認可及びセキュアなＰＣ５リンク確立手順）を参照している。ＵＰベースとＣＰベースとの両方の手順において、（図７及び図８に示されているように）以下の３つのフェーズが存在する。すなわち、
－ ディスカバリ鍵を含むディスカバリパラメータのプロビジョニングに関与する第１のフェーズ、
－ プロビジョニングがなされたディスカバリパラメータに依拠するディスカバリ手順に関与する第２のフェーズ、並びに
－ ＰＣ５認可及びセキュリティ確立のための第３のフェーズである。

第２のフェーズは、同じディスカバリプロトコルに依拠しているが、第１及び第３のフェーズは、異なるプロトコル又はエンティティ（ネットワーク機能）に関与し得る。これは、例えばＵＥがＵＰの第１のフェーズに基づくディスカバリパラメータ／鍵を用いて設定されている場合であっても、第３のフェーズはＰＣ５の認可及びセキュリティ確立に関してはＣＰベースであるというような、相互運用性の問題に至ることがあり得る。この相互運用性という問題は、あるネットワーク機能の初期化の欠如に起因し得る。例えば、ＵＰベースのアプローチ（ＣＰベースのアプローチ）の第１のフェーズとＣＰベースのアプローチ（ＵＰベースのアプローチ）の第３のフェーズとの間での相互運用性の問題である。

図９は、ＵＰ及びＣＰ手順の両方に関与するエンティティが含まれている場合の、より完全な説明を示している。図９は、ＵＰ／ＣＰベースのアプローチの第１のフェーズと第３のフェーズとの間での相互運用性を保証するいくつかの対話及び通信の概要である。

図９では、参照符号（ａ）との関係では、中継器のＰＫＭＦが、例えばＡＭＦ又はＵＤＭである中継ネットワークにおけるネットワーク機能と、通信インターフェースによって対話することにより、ＵＥが第１のフェーズにおいてＵＰアプローチを介して設定されている場合には、ＵＥがＣＰベースの第３のフェーズを開始すると、中継認可（図８のステップ４）が生じ得る。この通信インターフェースは、Ｔｄｏｃ Ｓ２－２２００２１４によって、Ｎｐｃ１０として示される（ＵＤＭと５ＧのＰＫＭＦとの間の基準点であり、ＵＥが５ＧのＰｒｏＳｅリモートＵＥ又は５ＧのＰｒｏＳｅによるＵＥとネットワークとの中継器として機能できるかどうかを認可するために、加入情報を提供するのに用いられる）。この通信は、例えばＵＥが、ＵＰアプローチ（すなわち、ＰＫＭＦが設定をＡＭＦにプッシュする）を介して設定された後、又はそのＵＥがＣＰベースの第３のフェーズを開始する（すなわち、ＡＭＦがリクエストをＰＫＭＦに送る）ときにオンデマンド型で、生じ得る。

図９では、参照符号（ｂ）との関係では、リモートのＰＫＭＦとリモートのＡＵＳＦ／ＵＤＭとが、それらがＣＰベースの第３のフェーズ手順の準備ができてリモートＵＥのネットワークがそのリモートを認可できるように、通信インターフェースによって、相互にリモートの設定に関して告知するために相互に対話する。この通信は、例えば図８のステップ４～１０におけるように、例えばＵＥがＵＰアプローチを介して（すなわち、ＰＫＭＦが設定をＡＵＳＦ／ＵＤＭにプッシュする）を介して設定された後、又はそのＵＥがＣＰベースの第３のフェーズを開始する（すなわち、ＡＵＳＦ／ＵＤＭがリクエストをＰＫＭＦに送る）ときにオンデマンド型で、生じ得る。

図９では、参照符号（ｃ）との関係では、ＣＰベースの手順における初期の第１のフェーズ（ディスカバリパラメータ／鍵の設定）のために、ＰＫＭＦ（中継器）によって管理されている鍵を検索するための対話である、ＡＭＦ－ＰＣＦ（リモート）、ＰＣＦ（リモート）－ＰＣＦ（中継器）、ＰＣＦ－ＤＤＮＭＦ、ＤＤＮＭＦ－ＰＫＭＦ（中継器）が示されている。ここでは、ＰＫＭＦ（中継器）などのネットワーク機能が、ＵＰ及びＣＰの両方のための鍵を管理している。

図９では、参照符号（ｄ）との関係では、ＣＰベースの手順における初期の第１のフェーズ（ディスカバリパラメータ／鍵の設定）のためにＰＫＭＦ（中継器）から鍵を検索するための対話である、ＡＭＦ－ＰＣＦ、ＰＣＦ－ＤＤＮＭＦ、ＤＤＮＭＦ－ＰＫＭＦ（中継器）及び最終的にＰＫＭＦ（リモート）－ＰＫＭＦ（中継器）が示されている。ここでは、ＰＫＭＦ（中継）などのネットワーク機能が、ＵＰ及びＣＰの両方のための鍵を管理している。

以下では、異なる実施形態が説明される。ＴＲ３３．８４７のＫＩ＃１６の次に、第１の実施形態とその上述のバリアントとは、少なくとも下記を含むＵＥとネットワークとの中継に関係する他の鍵の課題に対処する／適用可能である。
○ 鍵の課題＃４（ＫＩ＃４）は、ＵＥとネットワークとの中継シナリオにおける認可に、すなわち、中継器として機能させるためには中継ＵＥをどのようにして認可すべきかに関する。これは、ステップ１のｅ．ｉｉｉにおいてなされ得るのであるが、そこでは、リモートＵＥが中継器のＲＳＣをチェックして、その署名が有効であれば、対応するサービスを提供することがＣＮによって認可されたことを確認することが可能である。
○ 鍵の課題＃３（ＫＩ＃３）であるＵＥとネットワークとの中継のセキュリティと、鍵の課題＃９（ＫＩ＃９）であるＵＥとネットワークとの中継通信のための５Ｇでの近接サービスにおける鍵管理とは、鍵がどのように取り扱われるべきか、そしてＰＣ５のリンクがどのように保護されるのかに関する。

第１の実施形態において説明されたセットアップは、これらの鍵の課題に対処するように拡張されることが可能である。リモートＵＥと中継ＵＥとの間のＰＣ５通信リンクをセキュアにするために、共有秘密鍵Ｋ’を交換することが可能である。１つのオプションとして、リモートＵＥが、ステップｅ．ｉｖの前に、共有秘密鍵Ｋ’をランダムに生成するということがある。ステップｅ．ｉｖでは、それが、Ｋを、それを暗号化することによってセキュアな様態で、中継ＵＥに送る。ステップｅ．ｉｖに含まれている署名は、また、中継器がＫの完全性をチェックすることができるように、（暗号化された）Ｋを入力として有することが可能である。例えばステップｅ．ｖｉでＫ、Ｎ＿ｒｅｍｏｔｅ及びＮ＿ｒｅｌａｙの連結に対してＫＤＦを適用することによって、共有秘密鍵Ｋ’が計算される。これは、図４に示されている。拡張１が利用可能な場合には、他のオプションが生じる。この場合には、ステップｅ．ｉｉにおいて、Ｋが中継ＵＥによって生成され、リモートＵＥに送られることが可能である。

鍵交換のための適切なアプローチは、楕円曲線（ＥＣ）ディフィー・ヘルマン法である。公開鍵暗号のための適切なアプローチは、ＥＣ統合暗号化方式である。

上記パラグラフでは、ＫＩ＃９に対処するためのＴＲ３３．８４７のソリューション＃１、＃６、＃１０及び＃１５に対する分配型の代替方式を説明している。これらのソリューションでは、コアネットワークが、リモートＵＥと中継ＵＥとの間での共有対称鍵の生成及び分配に関与している。特に、リモートＵＥが、リモートＵＥと中継ＵＥとの間でのＰＣ５をセキュアにするために用いられることが可能な共有秘密鍵を分配／生成するためにＣＮへの更なるリクエストをトリガする「直接通信リクエスト」を、中継ＵＥに送る。

○ 鍵の課題＃１１（ＫＩ＃１１）は、ＰｒｏＳｅディスカバリの間のＵＥのＩＤ保護に、すなわち、どのようにしてディスカバリの間のＵＥのＩＤは保護されるべきかに関する。これは、ステップ１のｅ．ｉにおけるようになされるのであるが、そこでは、リモートＵＥは中継器によってブロードキャストされたＲＳＣの受信の際にだけ、ナンスを用いて返答する。このナンスは、ここでは、２つの目的を有し得る。第１の目的は、既にメインプロトコルにおいて説明されたように新しさに関する。第２の目的は、中継ＵＥが中継器として機能することを認可されることをリモートＵＥが確認するまではその真のＩＤが開示されないように、ＵＥの一時的な識別子として機能することである。リモートＵＥの真のＩＤは、ＰＤＵパラメータと共に、ステップ１のｅ．ｉｖにおいて開示される。

第１の実施形態と上述したそのバリアントとは、ＵＥ相互間の中継に関係する他の鍵の課題に対処する／適用され得る。ＵＥ相互間での中継シナリオでは、２つのリモートＵＥは、直接に、中継ＵＥを介して、相互に通信する必要がある。

ＴＲ２３．７５２では、ソリューション＃１１がモデルＡのディスカバリのための最低線として選択され、ソリューション＃８がモデルＢのディスカバリのための最低線として選択される、ということに注意してほしい。ソリューション＃１１の場合には、ディスカバリ情報は、（ｉ）タイプ＝アナウンスと、（ｉｉ）ディスカバリのタイプ＝ＵＥ相互間での中継のディスカバリと、（ｉｉｉ）アナウンサ情報（すなわち、ＵＥ－Ｒユーザのための上位レイヤ識別子）と、（ｉｖ）ＵＥ－ＲのＰｒｏＳｅでのＵＥのＩＤ（すなわち、ＵＥ－Ｒのレイヤ２識別子）と、（ｖ）ステップ２におけるグループメンバディスカバリの間に収集された「ターゲットユーザ情報」パラメータ（又は属性）のリスト（ＵＥ－１及びＵＥ－２のユーザを含む）と、を含む。「ターゲットユーザ情報」とは、ターゲットユーザを識別する上位レイヤのパラメータである。ステートフルなＵＥ相互間での中継を介するレイヤ２の通信をサポートするために、「ターゲットユーザ情報」は、また、ターゲットユーザのＵＥのレイヤ２識別子も含む。ソリューション＃８では、ディスカバリ情報は、個別的なディスカバリメッセージではなく、「ブロードキャストされた」直接通信リクエストを送ることによって、行われる。この直接通信リクエストは、ソースＵＥ情報と、ターゲットＵＥ情報と、アプリケーションＩＤとを含み、同様に中継サービスコードも含む。

○ 鍵の課題＃６（ＫＩ＃６）は、ＵＥ相互間の中継における情報の完全性及び秘密性に、すなわち中継ＵＥを介して通信する２つのリモートＵＥの間の通信をどのようにして保護するかに関する。特に、上記のソリューションに続いて、いったん２つのＵＥが適切な中継器を識別してそれに接続すると、これら２つのＵＥは、両方のＵＥの間での通信をセキュアにするために用いられることが可能な対称鍵を（拡張２におけるように）交換するためにＣＮによって設定された同じ情報を用いることができる。

関係する作業及び差異：ＴＲ３３．８４７のソリューション＃８は、同じシナリオに対処するために公開鍵も用いる、ということが注意されるべきである。しかし、現在のソリューションは、このソリューションにおいて対処されるいくつかのＦＦＳを有する。ソリューション＃１６は、また、公開鍵暗号について直接には言及していないが、ＫＩ＃６にも対処する。

以下では、公開鍵暗号を用いることにより、どのようにしてソリューション＃８が改善されることが可能であるかが説明される。これらの改善点のうちのいくつかは、ソリューション＃１６にも適用可能である。

依然として論じられるべき第１の点は、どのようにして公開鍵が特定のＵＥに拘束されるかについて、である。これは、このソリューションが認証手段を提供しないということ、そして、中間攻撃者における人間に対して脆弱であること、を意味する。このソリューションにおいて、これは、ＵＥに割り当てられる公開鍵がＣＮによって署名されるために、解決される。

ソリューション＃８は、また、メッセージ２及び４において公開鍵の交換について説明しており、ステップ６では、「拡張されたリンクは、ルーティング情報は平文のままの状態でありながら、ソースＵＥとターゲットＵＥとの公開鍵を用いて、エンドツーエンドでのセキュリティが保たれる」と書かれている。この説明から、それは、ディフィ－ヘルマン鍵交換方式に依拠しているように思われ、この鍵交換方式では、ｐｒが秘密鍵を意味し、ＰＵが公開鍵を意味する場合に、秘密鍵は、ｐｒ＿Ａ＊ＰＵ＿Ｂ＝ｐｒ＿Ｂ＊ＰＵ＿Ａに等しい。このソリューションは、したがって、例えばＮＩＳＴのポスト量子暗号（ＰＱＣ）によって標準化されているＥＣＩＥＳ又は鍵カプセル化機構（ＫＥＭｓ）は、カバーしていない。ＰＱＣのＫＥＭｓの例は、ＳＡＢＥＲ、Ｒｏｕｎｄ５、Ｋｙｂｅｒ、又はＮＴＲＵを含む。この点での差異は、メッセージ２では、ソースＵＥがその公開鍵を送り、ターゲットＵＥは、受信すると、ソースＵＥの公開鍵を用いてカプセル化されるランダムな鍵Ｋをランダムに生成する、ということである。メッセージ４は、ターゲットＵＥとカプセル化された鍵とから、一過性の公開鍵コンポーネントを含む。

ソリューション＃８における他のＦＦＳは、ＤＣＡメッセージが信頼可能であることをどのようにして確認するかに関する。これは、現在のソリューションではステップ１．ａ及び１．ｂにおいて行われるように、公開鍵がＣＮによって署名される場合に確認可能である。上述されたように、ＩＢＥソリューションも、同様に、用いられることが可能である。

ソリューション＃８は、ステップ０において、ポリシ／パラメータを用いて、中継器を設定し、次にステップ３において、ポリシが一致し、中継器がメッセージを中継することを許容される場合に、メッセージを中継する。このアプローチは、以下のようないくつかの課題を有する。
＊第１に、メッセージ＃２（ソースＵＥからＵＥ相互間中継器への直接通信リクエスト）は、リプレイされることが可能である。これは、メッセージが最初に中継器によって開示されソースＵＥによって署名されたナンスを含む場合に、回避されることが可能である。その代わりとして、ソースＵＥは、また、現在の時間を署名することも可能であり、そうすることで、中継器が、ある所与の時間ウィンドウの中にあるメッセージだけを受け入れる。これは、ステップ１のｅ．ｉｖと同様である。
＊第２に、メッセージ＃２におけるパラメータは平文のままであり、完全性が保護されていない。これは、攻撃者によって修正される可能性があることを意味する。中継器又はターゲットＵＥがメッセージ２とメッセージ３とに反応するかどうかを観察することによって、攻撃者は、また、例えばどのＰｒｏＳｅアプリケーションを中継器又はターゲットＵＥがサポートするかを知ることができる。これは、最初に中継器が公開鍵を開示し（例えば、それをソースＵＥに送り）、ソースＵＥが、どのプライバシに関してセンシティブなパラメータを暗号化するのにも、それを用いる場合に、解決されることが可能である。これは、ステップ１のｅ．ｉｉと同様である。

図５は、どのようにしてソリューション＃８が上記のアイデアに基づいて改善され得るのか、を説明している。
＊ステップａ０、ａ１、ａ２は、ＵＥ及び中継器の初期プロビジョニングに関する。この初期プロビジョニングは、メインソリューションにおけるステップａ及びｂと類似しているが、これらのデバイスはＵＥ相互間の使用の場合において情報を中継するそれらの能力に関係する情報／ポリシを用いてプロビジョニングされている、という点が追加／差異である。
＊ステップｃは、第１の実施形態又はそのバリアントにおけるのと同様である。
＊ステップｅ．ｉは、第１の実施形態又はそのバリアントにおけるのと同様である。
＊ステップｅ．ｉｉは、第１の実施形態又はそのバリアントにおけるのと同様であるが、今回は、中継局が、ＵＥ相互間での使用の場合において情報を中継するその能力に関係する署名された情報を分配する点が追加／差異である。
＊この情報が成功裏のうちにソースＵＥによって確認される場合には、ソースＵＥは、メインソリューションの場合のように、ｅ．ｉｖを用いて、返答する。ソースＵＥは中継器の公開鍵を有しているから、これらのパラメータは、プライバシを保証するために、暗号化されることが可能である、ということに注意すべきである。ソースＵＥの公開鍵はＣＮによって署名されているから、ソースＵＥは、ＭｉｔＭ／リプレイ攻撃を回避するために、どの通信パラメータにも署名することができる、ということに注意すべきである。これらのＰｒｏＳｅパラメータ（例えば、ブロードキャストされたレイヤ２のＩＤ、ＰｒｏＳｅアプリケーションのＩＤ、ＵＥのアプリケーションレイヤのＩＤ、ターゲットＵＥのアプリケーションレイヤのＩＤ、中継適用可能な指示）のうちのいくつかは、やはりＣＮによって直接に署名され、ステップａ０においてソースＵＥに提供されている。
＊ステップｅ．ｖでは、中継器が、情報をこの接続において転送することができるか／許されているかをチェックする。中継器は、また、ソースＵＥが、それ自体が主張する通りかどうかも、チェックする。これらのチェックは、第１の実施形態と非常に類似している。
＊ステップｅ．ｖｉは、情報をターゲットＵＥに転送することから構成される。しかし、ｅ．ｉｖにおける情報は中継器の鍵を用いて暗号化されており、ターゲットＵＥは対応する秘密鍵を有していない、ということが考慮されなければならない。しかし、ターゲットＵＥは、ターゲットＵＥの公開鍵に基づいて、情報を再び復号化及び暗号化することができる。その代わりに、中継器は、ターゲットＵＥとリモートＵＥとの間で共有されている対称鍵であって、より早い段階すなわちターゲットＵＥが中継器との接続の際にステップｃのｅ．ｉ、ｅ．ｉｉ、ｅ．ｉｖ自体を通過したときに確立された対称鍵を、用いることができる。中継器はターゲットＵＥの選好／ポリシについて既に知っており（例えば、それらが前もって中継器に開示されているかどうかなど）、よって、中継器は、メッセージがターゲットＵＥのポリシを充足する場合にのみこのメッセージを転送する。このステップは、また、例えばステップｅ．ｉにおけるナンス、ステップｅ．ｉｉにおけるナンス、若しくはそれらの組合せなど、１つ又は複数のナンスも含む。
＊ステップｅ．ｖｉｉは、入来するメッセージをチェックするターゲットＵＥに関するものである。それは、ソースＵＥがそのポリシ／通信必要性を充足するかどうかをチェックする。ターゲットＵＥは、これをチェックすることができるのであるが、その理由は、ターゲットＵＥがＣＮ及び／又はソースＵＥによって署名されたソースＵＥの通信情報を受信するからである。ステップｅ．ｖｉｉにおける特定のオプションでは、ターゲットＵＥは、ランダムに対称鍵を生成して、ランダムに生成された対称鍵Ｋをカプセル化／暗号化するためにソースＵＥの受信された（量子抵抗性の）公開鍵を用いることができ、また、ソースＵＥは、その一過性の公開鍵をこの目的のために生成する。
＊ステップｅ．ｖｉｉｉは、通信を確認するのに用いられ、ターゲットＵＥの公開鍵を含む。それは、また、例えばソースＵＥがそれを確認できるようにＣＮによって署名されたものなど、ターゲットＵＥからの更なる情報も含み得る。この情報は、カプセル化された鍵（ステップｅ．ｖｉｉ）を用いて、又はソースＵＥの公開鍵を用いて、暗号化されることが可能である。この情報は、ターゲットＵＥによっても署名される。その代わりとして、メッセージ認証コードも、中継器とターゲットＵＥとの間で先に確立された対称鍵を用いて、取得され得る。署名又はＭＡＣの目的は、これは信頼に値するメッセージであり転送可能であるということを中継器に知らせることである。このメッセージは、また、中継器とソースＵＥとがそのメッセージの新しさをチェック可能なように、ステップｅ．ｖｉにおけるナンスを含むこともあり得る。
＊ステップｅ．ｉｘは、ステップｅ．ｖｉｉｉで交換された署名又はＭＡＣを中継器がチェックすることに関する。
＊ステップｅ．ｘは、署名又はＭＡＣを有しないｅ．ｖｉｉｉのメッセージを含む。このメッセージを受信すると、ソースＵＥは、対称鍵をカプセル化解除して、ターゲットＵＥに関係するどの情報も復号化することができる。復号化の後で、ソースＵＥは、署名をチェックすることによって情報を、ナンスをチェックすることによって新しさを、確認することができる。

（上述した）図５のステップと、ＴＲ３３．８４７の図６．８．２．１－１におけるステップは、以下のように、相互に対応する。

○ 鍵の課題＃７は、ＵＥ相互間での中継シナリオにおける認可に関するものであり、すなわち、リモートＵＥは、どのようにして、それらが相互に対話することを認可されるかを確認することができるか、に関するものである。特に、いったん２つのＵＥが上記のソリューションの後で適切な中継器を識別してそれに接続すると、以下が想定できる。
■ まさに最初の設定段階では、当初のプロビジョニングフェーズにあるＣＮネットワークは、それぞれのＵＥに、その通信属性を記述するポリシと、他のＵＥとのデバイス相互間通信リンクを許容するためにはどの属性がＵＥによって要求されるかを決定するポリシとを提供しなければならない。それぞれのＵＥは、また、ＣＮによって署名された公開鍵を受信しなければならない。ＵＥは、対応する秘密鍵を有していなければならないか、又は同様にそれをＣＮから受信しなければならない。

動作の間には、以下のように、２つの選択肢が考慮される。
■ 選択肢１：動作の間に、ＵＥのうちの一方が、その通信ポリシを他方のＵＥに送る。第２のＵＥは、それをチェックして、それが認可される場合には、それ自体の通信ポリシを第１のデバイスに送る。第１のデバイスも第２のデバイスを認可する場合には、それは、確認を第２のデバイスに送る。
■ 選択肢２：動作の間に、あるＵＥがグループに参加するときには、そのＵＥは、最初に、ＣＮによって署名された中継器からパラメータを受信する。これは、図３におけるステップｅ．ｉｉと同様である。そのＵＥは、次に、その中継器がＵＥ相互間での通信に関して認可されておりその通信の必要性（ＲＳＣ）をサポートするかどうかをチェックする。このチェックは、図３におけるステップｅ．ｉｉｉにおけるチェックと類似している。次に、ＵＥは、その通信パラメータを中継ＵＥに送るが、これは、図３のｅ．ｉｖと同様である。中継ＵＥは、それらをチェックする（図３におけるステップｅ．ｖ）。

第１の実施形態と上記のそのバリアントとは、また、グループキャスト通信に関係する他の鍵の課題に対処する／適用可能である。特に、これは、グループキャスト通信のセキュリティ及びプライバシに関しリンク可能性、トレーサビリティ及びプライバシについてＬ２ ＩＤの保護に関与するＴＲ３３．８４７のＫＩ＃１３に部分的に関係し、また、通信の完全性／機密性にも関する。

次に、鍵の課題＃７に関して上述された選択肢２について生じるこれらの問題を取り扱うソリューションを提示する。選択肢２において説明されたステップを実行した後で、中継器は、複数のＵＥからなるグループの既に一部である他のＵＥとの通信にそのＵＥが参加可能（認可される）かどうかをチェックすることができる。ＵＥが相互に対話することが認可される場合には、中継器は、グループの中のＵＥのそれぞれに告知する。特に、新たなＵＥであるＺが参加したと想定してほしい。中継器がリモートＵＥ（Ａ、Ｂ、・・・、Ｙ）にグループに新たに参加するＵＥであるＺについて告知するときには、中継器は、Ｎ－１個のメッセージＭを送るのであるが、既にグループに属していたＵＥ（Ａ、Ｂ、・・・、Ｙ）のそれぞれに１つのメッセージＭを送ることになる。このメッセージＭは、図３のｅ．ｉｖと同様であって、そこでは、（ｉ）ＰｕＫ＿ｒｅｌａｙが、Ａ、Ｂ、・・・の公開鍵で置き換えられ、（ｉｉ）Ｎ＿ｒｅｌａｙが、Ａ、Ｂ、・・・、Ｙによって先に送られたナンスで置き換えられ、（ｉｉｉ）Ｓ（ＰｒＫ＿ＣＮ，ＲＳＣ｜ＰＤＵ＿ｐａｒａｍ｜ＰｕＫ＿ｒｅｍｏｔｅ）が、リモートデバイスの代わりである新たなデバイスＺの能力に関するコアネットワークからの署名であり、（ｉｖ）Ｓ（ＰｒＫ＿ｒｅｍｏｔｅ，・・・）が、送られたパラメータに関する中継デバイスからの署名によって置き換えられる。更に、中継器は、また、新たなデバイスＺに、既存のデバイス（Ａ、Ｂ、・・・、Ｙ）について告知しなければならない。この目的のために、中継器は、メッセージＭ’をＺに送る。Ｍ’はＭのようであるが、単一のデバイスに関する情報を含む代わりに、Ｎ－１個のデバイスに関する情報を含む。

以上に加えて、中継器は、グループ内での通信のために用いられることが可能なマスタグループ鍵を扱うことが可能である。中継器は、上述のメッセージＭ及びＭ’の中で保護された状態で、ＵＥに分配可能なこのマスタグループ鍵Ｋをランダムに生成する。新たなマスタグループ鍵は、新たなデバイスがグループに参加する又はグループを去るたびごとに、生成されることが可能である。導出されるグループ鍵Ｋ’は、Ｋとグループ内のすべてのデバイスのナンスとを入力として用いる鍵導出関数として導出されることが可能である。例えば、Ｋと上昇する値及びカウンタｉでソートされたナンスのそれぞれとの連結に、ハッシュ関数が適用されることが可能である。このカウンタｉは、時間経過に伴いＫ’を回転させるのに用いられることが可能である。

この鍵は、また、例えばＫ’に対して鍵導出関数を適用し最下位ビットを採用することによって、宛先Ｌ２－ＩＤを導くのに用いられることが可能である。

グループの相互認可及び分配をチェックするためのこのアプローチは、中継器が全体でＮ－１個のメッセージを送らなければならないことを意味している、ということに注意すべきである。これは、Ｎ^２個のメッセージというオーバヘッドを必要とし得るそれぞれのＵＥが相互に認証／認可するソリューションと比較して、改善である。そのような利点は、ＫＩ＃８に対処するソリューション＃１２にも、「ＵＥ１は、ＵＥ相互間の中継を介するＰＣ５ユニキャストリンクにおいて、複数のターゲットＵＥと通信することができる。その場合に、すべてのターゲットＵＥは、ＵＥ１の新たなＩＰアドレス／プレフィクスを告知されなければならない。」と記載されている。

このソリューションは、図６に示されており、その主たるステップは、以下の通りである。
＊ステップａ、ｂ、ｃは、初期のプロビジョニングに関するものであって、図３におけるステップａ及びｂと同様である。
＊ステップｄは、ディスカバリと分散型の認証／認可を指す。これは、図３におけるｃ、ｄ、ｅのｉ、ｅのｉｉ、ｅのｉｉｉ、ｅのｉｖ、及びｅのｖと同様なステップを含む。
＊ステップｅは、新たなＵＥであるＺが他のＵＥのポリシに従うグループにおいて認可されるかどうかをチェックすることに関する。
＊ステップｆは、既に定義されたマスタグループ鍵の生成に関する。
＊ステップｇは、グループの既に一部であったそれぞれのＵＥにメッセージＭを送ることに関する。
＊ステップｈは、メッセージＭ’を新たなＵＥに送ることに関する。
＊ステップｉは、現在のグループ鍵の生成に関する。

開示されている実施形態に対する他の変形は、当業者によって、特許請求されている発明を実践する際に、図面、開示及び添付されている特許請求の範囲を検討することから、理解され、もたらされる。特許請求の範囲において、「有する、備える、含む」という用語は、他の要素又はステップを排除せず、単数形の要素は、複数を排除しない。単一のプロセッサ又は他のユニットが、特許請求の範囲に記載されている複数のアイテムの機能を充足することがあり得る。ある手段が相互に異なる従属請求項に記載されているという単なる事実は、利益をもたらすためにこれらの手段の組合せが用いられることは不可能であることを示さない。以上の説明は、本発明のある実施形態の詳細を述べている。しかし、以上の説明が本文においてどれだけ詳細であっても、本発明は、多くの様態で実現され得るのであり、したがって、開示されている実施形態に限定されることはない。本発明のある特徴又は態様を説明するときに特定の用語が用いられているとしても、その用語が関連する本発明の特徴又は態様のいずれかの特定の特性を含むように制限されるようにその用語が本明細書で再定義されていることを含意するとは解釈されるべきでない、ということが注意されるべきである。

先の実施形態の全体を通じて説明されたように、本発明の提案されているバリアントは、例えば図１０に示されている５Ｇネットワークのようなセルラネットワークなど、ネットワークにおいて実装されることが可能である。ネットワークのセルは、一次局１０００によって供給を受ける。一次局１０００（例えば、ｇＮＢ）のカバレッジでは、複数の二次局が、その一次局に接続することができる。ある二次局は、中継局１０１０として動作するように構成され得る。そのような中継局は、送信アンテナと結合された送信機１０１１と、受信アンテナに結合された受信機１０１２と、を備えている。典型的には、これらの受信及び送信アンテナは、同じアンテナである。更に、技術に応じて、これらのアンテナは、ＭＩＭＯ、送信ダイバーシティ、及び異なる組の周波数での動作など、異なる送信／受信モードを許容するアンテナアレイによって形成されることがある。

例えばソフトウェアを用いて動作しているＣＰＵ又はマイクロコントローラであるコントローラ１０１３は、送信機と受信機とを制御し、アンテナを制御するように、構成されている。送信機、受信機及びコントローラのいくつか又は全部は単一のベースバンドプロセッサの一部であり得る、ということが注意されるべきである。上述された実施形態との関係で、コントローラは、中継局１０１０と一次局１０００との間の接続を確立するように構成される。より具体的には、コントローラ１０１３は、受信機１０１２を、一次局１０００からの少なくとも１つのセキュアなメッセージにおいて属性又はサービスコードを含む第１の組の設定パラメータを受け取るように、設定することができる。

コントローラ１０１３は、送信機１０１１を制御し、その送信機に、第１の組の設定パラメータからの少なくとも１つの送信された属性又はサービスコードを送信させることができる。この属性又はサービスコードは、例えば二次局１０２０のような他の局によって受信されるようにブロードキャストされることが、可能である。

更に、コントローラ１０１３は、次に、二次局からリクエストされると公開鍵を用いて二次局１０２０との直接通信を確立するように設定され得るのであるが、ここで、前記リクエストは、送信されたサービスメッセージに基づいている。

典型的には、中継局は、サイドリンク互換のＵＥのようなＵＥであり、よって、これは、設定されると中継局として振る舞うことが可能である。代替的には、中継局は、アクセスポイント、ｇＮＢ又はフェムトセルｇＮＢのような、他の一次局でもあり得る。

二次局１０２０は、典型的にはＵＥであり、送信機１０２１と受信機１０２２とを備えており、これらは共に典型的には１つ又は複数のアンテナ若しくはアンテナアレイに結合されている。更に、二次局１０２０は、受信機１０２１と送信機１０２２とおそらくはＵＥの他の要素とを制御するように構成されているコントローラ１０２３を、含む。中継局に関しては、コントローラ１０２３は、プロセッサ又はＣＰＵであり、ソフトウェアによって動作する。

コントローラ１０２３は、受信機１０２１及び送信機１０２２に、一次局１０００との接続を確立させることができる。これは、例えば、少なくとも１つの第２のセキュアなメッセージにおいて、中継局１０１０との今後のデータ交換にリンクされた属性又は中継サービスコードを含む第２の組の設定パラメータを一次局１０００から受信するように、受信機１０２１を設定することを含む。

受信機１０２１は、少なくとも１つの送信された属性又はサービスコードを中継局１０１０から受信するように構成されており、コントローラは、送信された属性若しくはサービスコードが第２の組の設定パラメータに含まれているか又はその中のポリシを充足しており、送信されたサービスコードが第２の組に含まれていると決定すると、送信機に中継局１０１０との直接通信を確立させるかどうかを決定するように、設定され得る。

図３から図９に示されているような説明された動作は、コンピュータプログラムのプログラムコード手段として、及び／又は関係する通信デバイス若しくはアクセスデバイスの専用ハードウェアとして、それぞれ実装されることが可能である。コンピュータプログラムは、他のハードウェアと共に若しくはその一部として一緒に供給される光ストレージ媒体若しくはソリッドステート媒体など、適切な媒体上に記憶及び／又は分配され得るが、インターネット若しくは他の有線若しくは無線通信システムを介してなど、他の形態で分配されることもあり得る。

Claims (21)

1. コアネットワークにリンクされ、セルに供給する一次局と、前記一次局によって供給される中継局と、前記一次局によって供給される二次局とを含む通信システムを動作させるための方法であって、前記方法は、
   前記一次局からの少なくとも１つの第１のセキュアなメッセージにおいてサービスコードを含む第１の組の設定パラメータを受信するステップを含む、前記中継局が前記一次局との接続を確立するステップと、
   少なくとも１つの第２のセキュアなメッセージにおいて今後のデータセッションにリンクされた中継サービスコードを含む第２の組の設定パラメータを前記一次局から受信するステップを含む、前記二次局が前記一次局との接続を確立するステップと、
   前記第１の組の設定パラメータからの少なくとも１つの送信されたサービスコードを前記中継局が送信するステップと、
   前記少なくとも１つの送信されたサービスコードが前記第２の組の設定パラメータに含まれると決定されると、前記二次局が前記中継局との直接通信を確立するステップと、
   を有する、方法。
2. 前記少なくとも１つの第１のセキュアなメッセージは、中継公開暗号鍵と、対応する中継秘密暗号鍵とを更に含む、請求項１に記載の方法。
3. 前記少なくとも１つの第２のセキュアなメッセージは、二次局公開暗号鍵と、対応する二次局秘密暗号鍵とを更に含む、請求項１又は２に記載の方法。
4. 前記少なくとも１つの第１のセキュアなメッセージは、少なくとも、
   中継公開暗号鍵と、
   前記第１の組の設定パラメータの少なくとも１つの属性又は前記第１の組の設定パラメータの前記サービスコードのうちの１つと、
   において生成された前記コアネットワークからの少なくとも１つの第１のコアネットワーク署名を含み、
   前記少なくとも１つの第２のセキュアなメッセージは、少なくとも、
   二次局公開暗号鍵と、
   前記第２の組の設定パラメータの少なくとも１つの属性又は前記第２の組の設定パラメータの前記サービスコードのうちの１つと、
   において生成された前記コアネットワークからの少なくとも１つの第２のコアネットワーク署名を含む、請求項２又は３に記載の方法。
5. 前記少なくとも１つの第１のセキュアなメッセージは、少なくとも、
   中継公開暗号鍵と、
   前記第１の組の設定パラメータの少なくとも１つの属性又は前記第１の組の設定パラメータの前記サービスコードのうちの１つと、
   において生成された前記コアネットワークからの少なくとも１つの第１のコアネットワーク署名を含み、
   前記少なくとも１つの第２のセキュアなメッセージは、少なくとも、
   前記今後のデータセッションに関係しており前記少なくとも１つの第２のセキュアなメッセージに含まれるパラメータと、
   二次局公開暗号鍵と、
   前記第２の組の設定パラメータの少なくとも１つの属性又は前記第２の組の設定パラメータの前記サービスコードのうちの１つと、
   において生成された前記コアネットワークからの少なくとも１つの第２のコアネットワーク署名を含む、請求項２又は３に記載の方法。
6. 前記直接通信を確立するステップは、
   ａ．前記二次局が、直接通信リクエストを前記中継局に送るステップと、
   ｂ．前記中継局が、前記中継公開暗号鍵と前記第１のコアネットワーク署名と応答メッセージ署名とを含む応答メッセージによって、前記直接通信リクエストに応答するステップと、
   ｃ．前記二次局が、前記応答メッセージに含まれる前記第１のコアネットワーク署名と前記応答メッセージ署名とをチェックするステップと、
   を含む、請求項４又は５に記載の方法。
7. 前記直接通信リクエストは二次局ナンスを含み、前記応答メッセージ署名は中継秘密暗号鍵を少なくとも前記二次局ナンスに適用することによって生成される、請求項６に記載の方法。
8. 前記応答メッセージ署名は、前記中継秘密暗号鍵を、少なくとも前記二次局ナンスと、コアネットワーク第１署名と前記中継公開暗号鍵との少なくとも一方とに適用することによって生成される、請求項７に記載の方法。
9. 前記応答メッセージは中継ナンスを更に含み、前記二次局は設定メッセージにおいて通信パラメータを送信し、前記設定メッセージは設定メッセージ署名を含み、前記設定メッセージ署名は二次局秘密暗号鍵を少なくとも前記中継ナンスに適用することによって生成される、請求項６から８のいずれか一項に記載の方法。
10. 前記設定メッセージ署名は、前記二次局秘密暗号鍵を、少なくとも前記中継ナンスと、コアネットワーク第２署名と前記二次局公開暗号鍵との少なくとも一方とに適用することによって生成される、請求項９に記載の方法。
11. 前記直接通信を確立するステップは、
    ａ．前記二次局が、二次局暗号公開鍵と二次局暗号秘密鍵と二次局ナンスとを生成又は選択し、直接通信リクエストを前記中継局に送るステップと、
    ｂ．前記中継局が、中継公開暗号鍵、第１のコアネットワーク署名及び／又は応答メッセージ署名を含む応答メッセージであって、ステップａで受信された公開鍵を用いて暗号化される応答メッセージによって、前記直接通信リクエストに応答するステップと、
    ｃ．前記二次局が、前記応答メッセージを復号化し、前記応答メッセージに含まれる前記第１のコアネットワーク署名と前記応答メッセージ署名とをチェックするステップと、
    を含む、請求項１に記載の方法。
12. 前記中継局は、前記第１の組の設置パラメータの前記少なくとも１つの送信された属性又は前記第１の組の設定パラメータからのサービスコードと、データセッションポリシとデータセッションパラメータと第１のコアネットワーク署名と中継公開暗号鍵との更なる情報のうちの少なくとも１つとを送信し、前記二次局は、前記第１の組の設定パラメータの前記送信された属性又は前記送信されたサービスコードが前記第２の組の設定パラメータに含まれ、前記更なる情報が前記今後のデータセッションと互換であると決定されると、前記中継局との直接通信を確立する、請求項１から１１のいずれか一項に記載の方法。
13. 前記中継局から送信されたメッセージは、少なくともタイムスタンプに適用される署名を含む、請求項１２に記載の方法。
14. 前記第１の組の設定パラメータからの前記少なくとも１つの送信されたサービスコードは、送信ナンスと組み合わされた前記第１の組の設定パラメータのハッシュされたサービスコードの結果であり、前記中継局は、前記送信ナンスを更に送信する、請求項１から１３のいずれか一項に記載の方法。
15. 前記二次局が前記コアネットワークに前記第１のコアネットワーク署名をチェックするステップが失敗するかどうかを告知するステップを更に有する、請求項６又は１１に記載の方法。
16. 前記中継局が前記一次局との接続を確立するステップは、前記中継局が中継公開暗号鍵と中継秘密暗号鍵とを生成するステップと、前記コアネットワークによる署名のために前記中継公開暗号鍵を前記一次局に送るステップと、前記一次局からの前記少なくとも１つの第１のセキュアなメッセージにおいて、前記第１の組のサービスコードと、少なくとも前記中継公開暗号鍵に基づく第１のコアネットワーク署名とを受け取るステップと、を含む、請求項１に記載の方法。
17. 前記二次局が前記一次局との接続を確立するステップは、前記二次局が二次局公開暗号鍵と二次局秘密暗号鍵とを生成するステップと、前記コアネットワークによる署名のために前記二次局公開暗号鍵を前記一次局に送るステップと、前記一次局からの前記少なくとも１つの第２のセキュアなメッセージにおいて、前記第２の組の設定パラメータの前記サービスコードと、少なくとも前記二次局公開暗号鍵に基づく第２のコアネットワーク署名とを受け取るステップと、を含む、請求項１又は１６に記載の方法。
18. コアネットワークにリンクされ、セルに供給する一次局と、前記一次局によって供給される二次局とを含むネットワークにおいて通信するための中継局であって、前記一次局によって供給される当該中継局を動作させるための方法であって、前記方法は、
    いくつかの属性又は１組のサービスコードを含む第１の組の設定パラメータを、前記一次局からの少なくとも１つの第１のセキュアなメッセージにおいて受信するステップを含む、前記中継局が前記一次局との接続を確立するステップと、
    第２の組の設定パラメータからの少なくとも１つの属性、又は、前記第２の組の設定パラメータからのサービスコードであって、前記一次局から送信されたサービスコードを、前記中継局が送信するステップと、
    前記送信されたサービスコードに基づく、前記二次局からのリクエストがあると、前記中継局が前記二次局との直接通信を確立するステップと、
    を有する、方法。
19. コアネットワークにリンクされておりセルに供給する一次局と、前記一次局によって供給される中継局とを含む通信システムにおいて通信するための二次局であって、前記一次局によって供給される当該二次局を動作させるための方法であって、前記方法は、
    前記一次局から、少なくとも１つの第２のセキュアなメッセージにおいて、公開暗号鍵と、第２の組の属性又は少なくとも１つの中継局との今後のデータ交換にリンクされている中継サービスコードとを受信するステップを含む、前記二次局が前記一次局との接続を確立するステップと、
    前記二次局が、少なくとも１つの送信された属性又は中継サービスコードを前記中継局から受信するステップと、
    前記二次局が、前記送信された属性又は中継サービスコードが前記第２の組の設定パラメータに含まれているかどうかを決定し、前記送信された属性若しくは中継サービスコードが前記第２の組の設定パラメータに含まれているか又はポリシを充足すると決定すると、前記中継局との直接通信を確立するステップと、
    を有する、方法。
20. コアネットワークにリンクされておりセルに供給する一次局と、前記一次局によって供給される二次局とを含むネットワークにおいて通信するための中継局であって、前記中継局は前記一次局によって供給され、前記中継局は、
    送信機と、
    受信機と、
    前記一次局との接続を確立し、前記一次局から少なくとも１つの第１のセキュアなメッセージにおいて属性又はサービスコードを含む第１の組の設定パラメータを受信するように前記受信機を設定する、コントローラと、
    を備え、
    前記送信機は、前記第１の組の設定パラメータからの少なくとも１つの送信された属性又はサービスコードを送信し、
    前記コントローラは、前記二次局からの前記送信されたサービスコードに基づくリクエストがあると、公開鍵を用いて前記二次局との直接通信を確立する、中継局。
21. コアネットワークにリンクされておりセルに供給する一次局と、前記一次局によって供給される中継局とを含む通信システムにおいて通信するための二次局であって、前記二次局は前記一次局によって供給され、前記二次局は、
    送信機と、
    受信機と、
    前記一次局との接続を確立するコントローラであって、前記一次局から少なくとも１つの第２のセキュアなメッセージにおいて属性又は少なくとも１つの中継局との今後のデータ交換にリンクされた中継サービスコードを含む第２の組の設定パラメータを受信するように前記受信機を設定する、コントローラと、
    を備え、
    前記受信機は、少なくとも１つの送信された前記属性又は中継サービスコードを前記中継局から受信し、
    前記コントローラは、送信された前記属性若しくは中継サービスコードが前記第２の組の設定パラメータに含まれる又はポリシを充足するかどうかを決定し、送信された前記中継サービスコードが前記第２の組の設定パラメータに含まれると決定されると、前記送信機に前記中継局との直接通信を確立させる、二次局。