知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-10-16
(54)【発明の名称】セルラーネットワークの動作方法
(51)【国際特許分類】
H04L 9/08 20060101AFI20241008BHJP
H04L 9/14 20060101ALI20241008BHJP
H04W 12/03 20210101ALI20241008BHJP
H04W 12/041 20210101ALI20241008BHJP
【ＦＩ】
H04L9/08 C
H04L9/14
H04W12/03
H04W12/041
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2024518795
(86)(22)【出願日】2022-09-26
(85)【翻訳文提出日】2024-04-11
(86)【国際出願番号】 EP2022076630
(87)【国際公開番号】W WO2023046944
(87)【国際公開日】2023-03-30
(31)【優先権主張番号】21199194.8
(32)【優先日】2021-09-27
(33)【優先権主張国・地域又は機関】EP
(31)【優先権主張番号】21201483.1
(32)【優先日】2021-10-07
(33)【優先権主張国・地域又は機関】EP
(31)【優先権主張番号】21205309.4
(32)【優先日】2021-10-28
(33)【優先権主張国・地域又は機関】EP
(31)【優先権主張番号】21208847.0
(32)【優先日】2021-11-17
(33)【優先権主張国・地域又は機関】EP
(31)【優先権主張番号】21209081.5
(32)【優先日】2021-11-18
(33)【優先権主張国・地域又は機関】EP
(31)【優先権主張番号】21209743.0
(32)【優先日】2021-11-23
(33)【優先権主張国・地域又は機関】EP
(31)【優先権主張番号】22154888.6
(32)【優先日】2022-02-03
(33)【優先権主張国・地域又は機関】EP
(31)【優先権主張番号】22156421.4
(32)【優先日】2022-02-11
(33)【優先権主張国・地域又は機関】EP
(31)【優先権主張番号】22157640.8
(32)【優先日】2022-02-20
(33)【優先権主張国・地域又は機関】EP
(31)【優先権主張番号】22158360.2
(32)【優先日】2022-02-23
(33)【優先権主張国・地域又は機関】EP
(31)【優先権主張番号】22191357.7
(32)【優先日】2022-08-22
(33)【優先権主張国・地域又は機関】EP
(81)【指定国・地域】
(71)【出願人】
【識別番号】590000248
【氏名又は名称】コーニンクレッカ フィリップス エヌ ヴェ
【氏名又は名称原語表記】Ｋｏｎｉｎｋｌｉｊｋｅ Ｐｈｉｌｉｐｓ Ｎ．Ｖ．
【住所又は居所原語表記】Ｈｉｇｈ Ｔｅｃｈ Ｃａｍｐｕｓ ５２， ５６５６ ＡＧ Ｅｉｎｄｈｏｖｅｎ，Ｎｅｔｈｅｒｌａｎｄｓ
(74)【代理人】
【識別番号】110001690
【氏名又は名称】弁理士法人Ｍ＆Ｓパートナーズ
(72)【発明者】
【氏名】ガルシア モーション オスカー
【テーマコード（参考）】
5K067
【Ｆターム（参考）】
5K067AA21
5K067DD11
5K067EE02
5K067EE25
5K067HH22
5K067HH36
(57)【要約】
本発明は、通信システムを動作させる方法に関し、方法は、ａ．ユーザが中継に必要とするサービスのタイプを示す中継サービスコードと、中継局との通信に使用されるべき通信鍵または通信鍵の指標との組み合わせを含むメッセージを第１の局が準備するステップと、ｂ．少なくとも機密性鍵およびフレッシュネス値に鍵導出関数を適用することによって、第１の局が鍵ストリームを生成するステップと、ｃ．第１の局が鍵ストリームを使用してメッセージを暗号化するステップとを含む。
【特許請求の範囲】
【請求項1】
第１の局および第２の局を含む通信システム内の前記第１の局を動作させる方法であって、前記方法は、ａ．サービスのタイプを示すパラメータと、前記第２の局との通信に使用されるべき通信鍵または通信鍵の指標との組み合わせを少なくとも含むメッセージを前記第１の局が準備するステップと、
ｂ．少なくとも機密性鍵およびフレッシュネス値に鍵導出関数を適用することによって鍵ストリームを生成するためのアルゴリズムを前記第１の局が実行するステップと、
ｃ．前記第１の局が前記鍵ストリームを使用して前記メッセージを暗号化するステップとを含む、方法。
【請求項2】
ステップｂ．は、少なくとも機密性鍵、フレッシュネス値、および前記メッセージに、鍵導出関数を適用することによって、前記鍵ストリームを生成するステップを含む、請求項１に記載の方法。
【請求項3】
ステップｃ．は、前記メッセージおよび前記鍵ストリームに排他的論理和（ＸＯＲ）演算を適用するステップを含む、請求項１または２に記載の方法。
【請求項4】
前記フレッシュネス値は、ＵＴＣに基づく時間値である、請求項１から３のいずれか一項に記載の方法。
【請求項5】
前記第１の局が、前記メッセージのためのメッセージ完全性チェックを計算するステップをさらに含む、請求項１から４のいずれか一項に記載の方法。
【請求項6】
前記メッセージ完全性チェックは、ステップｃ．の前に前記メッセージに含められる、請求項５に記載の方法。
【請求項7】
ステップｂ．は、少なくとも機密性鍵、フレッシュネス値、前記メッセージ、および前記メッセージのＭＩＣに、鍵導出関数を適用することによって、前記鍵ストリームを生成するステップを含む、請求項５または６に記載の方法。
【請求項8】
ステップｂ．は、所定のポリシーに従って、複数の利用可能な鍵から機密性鍵を選択するステップを含む、請求項１から７のいずれか一項に記載の方法。
【請求項9】
ＤＵＣＫが設定される場合、前記機密鍵はＤＵＣＫであり、さもなければ、ＤＵＳＫが設定されている場合、前記機密鍵はＤＵＳＫである、請求項８に記載の方法。
【請求項10】
前記ＤＵＣＫが設定される場合、前記鍵ストリームは暗号化アルゴリズムを適用することによって取得され、前記ＤＵＣＫが設定されていないが、前記ＤＵＳＫが設定されている場合、前記鍵ストリームはスクランブルアルゴリズムを適用することによって取得される、請求項９に記載の方法。
【請求項11】
前記機密性鍵が設定されていない場合、ステップａ．の前記メッセージはステップｃ．において暗号化されない、請求項９または１０に記載の方法。
【請求項12】
前記鍵ストリームは、設定されている前記機密鍵に関係なく、単一のアルゴリズムを適用することによって取得される、請求項１から９のいずれか一項に記載の方法。
【請求項13】
前記第１の局が、完全性鍵を使用して前記メッセージのためのメッセージ完全性チェックを計算するステップをさらに含み、前記完全性鍵は、前記選択された機密性鍵と同じである、請求項８、９、または１０に記載の方法。
【請求項14】
ステップｂ．は、鍵導出関数を適用して第２の機密性鍵を取得するステップを含み、前記鍵ストリームは、対称暗号化アルゴリズムに前記第２の機密性鍵を適用することによって取得される、請求項１から１３のいずれか一項に記載の方法。
【請求項15】
前記対称暗号化アルゴリズムは、前記コアネットワークによって選択されるか、以前の動作フェーズ中にネゴシエーションされたか、または前記メッセージ内で通知されるＮＥＡアルゴリズムである、請求項１４に記載の方法。
【請求項16】
前記サービスのタイプを示す前記パラメータは、リレーサービスコードである、請求項１から１５のいずれか一項に記載の方法。
【請求項17】
第２の局をさらに含む通信システム内で動作する第１の局であって、前記第１の局は、送信機と、
受信機と、
命令を含むメモリに結合されたプロセッサとを備え、前記命令は、
前記サービスのタイプを示すパラメータと、前記第２の局との通信に使用されるべき通信鍵または通信鍵の指標との組み合わせを含むメッセージを準備するステップと、
少なくとも機密性鍵およびフレッシュネス値に鍵導出関数を適用することによって鍵ストリームを生成するためのアルゴリズムを実行するステップと、
前記鍵ストリームを用いて前記メッセージを暗号化するステップとを実行するための命令である、第１の局。
【請求項18】
第１の局をさらに含む通信システム内で動作する第２の局であって、前記第２の局は、送信機と、
受信機と、
命令を含むメモリに結合されたプロセッサとを備え、前記命令は、
暗号化されたメッセージを受信するステップと、
少なくとも機密性鍵およびフレッシュネス値に鍵導出関数を適用することによって鍵ストリームを生成するためのアルゴリズムを実行するステップと、
前記鍵ストリームを用いて前記メッセージを復号するステップとを実行するための命令である、第２の局。
【請求項19】
請求項１７に記載の第１の局と、請求項１８に記載の第２の局とを含む、システム。
【請求項20】
通信システムにおいて、第１の局が第２の局にメッセージを送信するための方法であって、前記方法は、ａ．前記第１の局が、メッセージに基づいてＭＩＣ（メッセージ完全性チェック）を計算するステップと、
ｂ．前記第１の局が、前記ＭＩＣを前記メッセージと組み合わせるステップと、
ｃ．少なくとも前記ＭＩＣに基づいて鍵ストリームを計算するステップと、
ｄ．前記第１の局が、前記鍵ストリームに基づくキーワードを使用して前記メッセージを暗号化し、暗号を取得するステップとを含む、方法。
【請求項21】
ステップｄ．から得られた前記暗号の一部をスクランブルするステップｅをさらに含む、請求項２０に記載の方法。
【請求項22】
前記ＭＩＣは、前記鍵ストリームの前記計算において前記メッセージのフィンガープリントとして使用される、請求項２０に記載の方法。
【請求項23】
前記キーワードは、前記鍵ストリームと暗号化鍵マスクとの組み合わせである、請求項２０、２１、または２２に記載の方法。
【請求項24】
前記組み合わせはＡＮＤ演算である、請求項２３に記載の方法。
【請求項25】
通信システムにおいて第１の局を動作させる方法であって、前記方法は、ａ．前記第１の局が、長さＬバイトのディスカバリメッセージを準備するステップと、
ｂ．前記第１の局が、サイズＢバイトの鍵導出関数をＣｅｉｌｉｎｇ（Ｌ／Ｂ）回適用するか、またはＮＥＡアルゴリズムを適用することによって、出力サイズがＬバイトの疑似乱数列を生成するステップであって、前記疑似乱数列は、少なくとも機密性鍵、フレッシュネス値、およびカウンタ値に依存する、ステップと、
ｃ．前記第１の局が前記疑似乱数列を使用して前記メッセージを暗号化するステップとを含む、方法。
【請求項26】
前記鍵導出関数への入力は、マスクと、前記メッセージおよびＭＩＣの連結とにビットごとの「ＡＮＤ」関数を適用した結果を含む、請求項２５に記載の方法。
【請求項27】
前記鍵導出関数または前記ＮＥＡアルゴリズムへの入力は、マスクの関数、メッセージの関数、またはＭＩＣの関数を少なくとも含む、請求項２５または２６に記載の方法。
【請求項28】
前記メッセージは、メッセージ長を示すか、または、暗号化動作を調整するための任意選択のフィールドの存在を示すマスクを示す、請求項２５、２６、または２７に記載の方法。
【請求項29】
請求項２６から２８のいずれか一項に記載の方法に従って動作する第１の局と、第２の局とを含むシステムを動作させるための方法であって、前記第２の局は、ａ．ディスカバリメッセージを受信するステップと、
ｂ．生成された前記疑似乱数列の最初の部分を使用することによって、前記ディスカバリメッセージの最初の部分をスクランブル解除および／または復号するステップと、
ｃ．前記ディスカバリメッセージの前記最初の部分のＭＩＣを用いて前記ディスカバリメッセージの前記最初の部分の完全性を検証するステップと、
ｄ．前記ディスカバリメッセージの前記最初の部分の完全性チェックが成功した場合、および／または前記ディスカバリメッセージの前記最初の部分のフィールドが前記ディスカバリメッセージの２番目の部分の存在を示す場合、生成された前記疑似乱数列の第２の部分を使用して、前記ディスカバリメッセージの前記２番目の部分をスクランブル解除および／または復号するステップとを実行する、方法。
【請求項30】
受信した前記メッセージのスクランブル／暗号化された前記２番目の部分のハッシュが、前記ディスカバリメッセージの前記最初の部分内に含まれ、かつ前記最初の部分内で検証されるハッシュ値と一致する場合、受信した前記ディスカバリメッセージの前記第２の部分がスクランブル解除および／または復号される、請求項２９に記載の方法。
【請求項31】
ステップａは、前記メッセージ、および利用可能な場合はＤＵＩＫ（完全性鍵）に基づいてＭＩＣを計算するステップを含み、ステップａは、前記ＤＵＩＫが設定されていない場合、前記ＭＩＣをランダムな値に設定するステップを含む、請求項２０または２７に記載の方法。
【請求項32】
前記鍵ストリームは、ＮＥＡアルゴリズムを用いて計算される、請求項２０、２３、２４、２６、２７、２９、３１に記載の方法。
【請求項33】
前記ＮＥＡアルゴリズムにおける３２ビットカウントが、前記ＵＴＣベースのカウンタ値に設定され、ＢＥＡＲＥＲフィールド値がＢＥＡＲＥＲ＝００００に設定され、ＤＩＲＥＣＴＩＯＮフィールド値が０に設定される、請求項３２に記載の方法。
【請求項34】
前記ディスカバリメッセージの保護は、まず前記メッセージの最初の部分に適用され、その後、前記メッセージの前記２番目の部分に適用され、前記メッセージの前記最初の部分および前記メッセージの前記２番目の部分の保護は互いに異なる、請求項２０、２３、２４、２５、２６、２８、３１、３２、および３３に記載の方法。
【請求項35】
通信システム内で動作する第１の局であって、前記第１の局は、送信機と、
受信機と、
命令を含むメモリに結合されたプロセッサとを備え、前記命令は、
ａ．前記第１の局が、メッセージに基づいてＭＩＣ（メッセージ完全性チェック）を計算するステップと、
ｂ．前記第１の局が、前記ＭＩＣを前記メッセージと組み合わせるステップと、
ｃ．少なくとも前記ＭＩＣに基づいて鍵ストリームを計算するステップと、
ｄ．前記第１の局が、前記鍵ストリームに基づくキーワードを使用して前記メッセージを暗号化し、暗号を取得するステップとを実行するための命令である、第１の局。
【請求項36】
通信システム内で動作する第１の局であって、前記第１の局は、送信機と、
受信機と、
命令を含むメモリに結合されたプロセッサとを備え、前記命令は、
長さＬバイトのディスカバリメッセージを準備するステップと、
サイズＢバイトの鍵導出関数をＣｅｉｌｉｎｇ（Ｌ／Ｂ）回適用するか、またはＮＥＡアルゴリズムを適用することによって、出力サイズがＬバイトの疑似乱数列を生成するステップであって、前記疑似乱数列は、少なくとも機密性鍵、フレッシュネス値、およびカウンタ値に依存する、ステップと、
前記疑似乱数列を用いて前記メッセージを暗号化するステップとを実行するための命令である、第１の局。
【請求項37】
通信システム内で動作する第２の局であって、前記第２の局は、送信機と、
受信機と、
命令を含むメモリに結合されたプロセッサとを備え、前記命令は、
第２の局が、暗号化されたメッセージ、ＭＩＣ（メッセージ完全性チェック）を受信するステップと、
前記第２の局が、前記ＭＩＣに基づくキーワードを取得するステップと、
前記第２の局が、取得した前記キーワードを使用して、前記暗号化されたメッセージを復号するステップと、
前記第２の局が、受信した前記ＭＩＣが有効であるか否かをチェックすることで、前記メッセージの完全性をチェックするステップとを実行するための命令である、第２の局。
【請求項38】
請求項３５に記載の第１の局と、請求項３７に記載の第２の局とを備えた、システム。
【請求項39】
無線デバイス上にロードされたとき、前記無線デバイスに請求項１から１６、または２０から３４に記載の方法のステップを実行させるコードを備えた、コンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は無線通信の分野に関し、特に、ＵＭＴＳ ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）もしくはＬＴＥ Ａｄｖａｎｃｅｄ（両方とも４Ｇに含まれる）、ＮＲ（Ｎｅｗ Ｒａｄｉｏ）（５Ｇ）、または他のセルラーネットワークもしくは移動通信ネットワークのようなセルラーネットワークの環境におけるセキュリティ側面に関する。
【背景技術】
【0002】
従来のセルラーネットワークでは、一次局は、自身がサービスを提供するセル内に位置する複数の二次局にサービスを提供する。一次局から各二次局への無線通信はダウンリンクチャネル上で行われる。逆に、各二次局から一次局への無線通信はアップリンクチャネル上で行われる。無線通信は、データトラフィック（ユーザデータとも呼ばれる）および制御情報（シグナリングとも呼ばれる）を含むことができる。この制御情報は通常、一次局および／または二次局がデータトラフィックを交換するのを補助する情報（例えば、リソース割り当て／リクエスト、物理的伝送パラメータ、各局の状態に関する情報）を含む。
【0003】
３ＧＰＰ（登録商標）によって標準化されたセルラーネットワークの環境では、一次局は基地局と呼ばれるか、または５Ｇ（ＮＲ）ではｇＮｏｄｅＢ（またはｇＮＢ）もしくは４Ｇ（ＬＴＥ）ではｅＮｏｄｅＢ（またはｅＮＢ）と呼ばれる。ｅＮＢ／ｇＮＢは、コアネットワーク（ＣＮ）の機能とのインターフェースである無線アクセスネットワークＲＡＮの一部である。同じ環境において、二次局は移動局、または４Ｇ／５Ｇのユーザ機器（またはＵＥ）に対応する。ＵＥは、無線クライアントデバイスまたはそのようなデバイスが果たす特定のロール（役割）である。ＵＥまたはｇＮＢ／ｅＮＢを表すのに「ノード」という用語も使用される。
【0004】
さらに、例えば、ＰＣ５インターフェースまたはサイドリンク通信の場合、二次局、ここではＵＥ間で直接通信を行うことができる。また、その場合、ＵＥがリレーとして動作して、例えばカバレッジ外のＵＥがｅＮＢまたはｇＮＢへの中間 （または間接的）接続を得ることができるようにすることも可能である。リレーとして機能できるようにするために、ＵＥは発見（ｄｉｓｃｏｖｅｒｙ）メッセージを使用して他のＵＥとの新しい接続を確立する可能性がある。
【0005】
したがって、図１に示すような中継ノードの役割が３ＧＰＰ（登録商標）に導入された。この中継ノード１２０は、一次局１００、例えばｇＮＢと二次局１１０、例えばＵＥとの間の通信を中継する機能を含む無線通信局１２０である。この中継機能により、例えば、セル１０のカバレッジをカバレッジ外（ＯｏＣ）二次局１１０まで拡張することが可能になる。この中継ノード１２０は、移動局であってもよいし、または異なるタイプのデバイスであってもよい。４Ｇ用の仕様では、ＰｒｏＳｅ（Ｐｒｏｘｉｍｉｔｙ Ｓｅｒｖｉｃｅｓ）機能が、とりわけ、ＴＳ２３．３０３およびＴＳ２４．３３４で定義されている。これらの機能は、とりわけ、セル１０にサービスを提供するセルラーネットワーク基地局（ｅＮＢ）１００のカバレッジ外に一時的にあるセルラーユーザ機器（ＵＥ）１１０の接続を有効にする。この特定の機能は、ＰｒｏＳｅ ＵＥ－ｔｏ－ｎｅｔｗｏｒｋリレー、または略してリレーＵＥと呼ばれる。リレーＵＥ１２０は、ＯｏＣ ＵＥ１１０とｅＮＢ１００との間の双方向でアプリケーションおよびネットワークトラフィックを中継する。リレーＵＥ１２０とＯｏＣ ＵＥ１１０との間のローカル通信は、ＴＳ２３．３０３およびＴＳ２４．３３４では、Ｄ２Ｄ（ｄｅｖｉｃｅ－ｔｏ－ｄｅｖｉｃｅ）通信またはサイドリンク（ＰＣ５とも呼ばれる）通信と呼ばれる。リレー関係が確立されると、ＯｏＣ－ＵＥ１１０は、例えば、リレーＵＥ１２０を介してＩＰ接続され、「リモートＵＥ」１１０の役割を果たす。この状況は、通常のケースである、全てのコアネットワーク機能への直接ネットワーク接続とは異なり、リモートＵＥがコアネットワークの選択された機能への間接ネットワーク接続を有することを意味する。
【0006】
さらに、ＵＥ間中継ノード、すなわち、２つのＵＥデバイス間の通信を中継する中継ノードの役割が導入されている。これは図３に示されている通りであり、中継ノード１０１０がＵＥデバイス１０２０とＵＥデバイス１０３０との間の通信を中継する。ＵＥ１０１０、１０２０、１０３０は、基地局１０００を介してコアネットワークに接続することができる。
【0007】
後で詳しく説明するように、技術仕様ＴＳ３３．３０３およびこれまでに提案されているソリューションでは、ＴＳ３３．３０３の以前のバージョンで既に導入されている方法に変更を加えて、すなわち、スクランブルされるメッセージの部分、メッセージ識別コード（ＭＩＣ）が計算される方法、どのＭＩＣ値が送信されるか、および機密性保護を達成する方法に変更を加えて再利用することにより、ＰＣ５インターフェースを介したディスカバリメッセージを保護することが説明されている。しかし、現在提案されているソリューションは攻撃を受けやすく、ディスカバリに関与する様々なノードの完全性が保証されていない。さらに、ＴＳ３３．３０３の既存のソリューションは、長いディスカバリメッセージ、例えば３２バイトを超えるメッセージを保護することができない。
【0008】
後で詳しく説明するように、技術仕様ＴＳ３３．３０３およびこれまでに提案されたソリューションでは、ＰＣ５インターフェースを介した直接通信リクエストメッセージの保護について記載されている。しかし、現在提案されているソリューションは相互運用性に欠けており、複雑さが高すぎる。
【発明の概要】
【0009】
本発明の１つの目的は、上記問題を軽減することである。
【0010】
本発明の別の目的は、二次局のためにプロトコルデータユニット（ＰＤＵ）セッションを確立するための安全なセットアップを可能にするネットワーク内で通信する方法を提案することである。
【0011】
本発明のさらに別の目的は、ディスカバリメッセージの保護を改善することである。
【0012】
本発明のさらに別の目的は、発見通信リクエスト（ＤＣＲ）メッセージの保護を改善することである。
【0013】
本発明のさらに別の目的は、動作開始後のコアネットワークとのインタラクションを最小限に抑えるネットワーク内で二次局が通信するための方法を提案することである。
【0014】
本発明の様々な態様によれば、セキュリティルーチンを動作可能に機能させるために、並びにセキュリティ／プライバシー保護およびパフォーマンスを向上させるために、セキュリティルーチンにいくつかの変更を加えることが提案される。
【0015】
この目的を達成するために、本発明の第１の態様によれば、請求項１に記載の第１の局を動作させる方法が提案される。より具体的には、第１の局および第２の局を含む通信システム内の第１の局を動作させる方法が提案され、方法は、
ａ．サービスのタイプを示すパラメータと、第２の局との通信に使用されるべき通信鍵または通信鍵の指標との組み合わせを少なくとも含むメッセージを第１の局が準備するステップと、
ｂ．少なくとも機密性鍵およびフレッシュネス値に鍵導出関数を適用することによって鍵ストリームを生成するためのアルゴリズムを第１の局が実行するステップと、
ｃ．第１の局が鍵ストリームを使用してメッセージを暗号化するステップとを含む、方法。
ａ．サービスのタイプを示すパラメータと、第２の局との通信に使用されるべき通信鍵または通信鍵の指標との組み合わせを少なくとも含むメッセージを第１の局が準備するステップと、
ｂ．少なくとも機密性鍵およびフレッシュネス値に鍵導出関数を適用することによって鍵ストリームを生成するためのアルゴリズムを第１の局が実行するステップと、
ｃ．第１の局が鍵ストリームを使用してメッセージを暗号化するステップとを含む、方法。
【0016】
本発明の第１の変形例では、ステップｂ．は、少なくとも機密性鍵、フレッシュネス値、およびメッセージに鍵導出関数を適用することによって、鍵ストリームを生成するステップを含む。
【0017】
第１の変形例と組み合わせることができる第２の変形例では、ステップｃ．は、メッセージおよび鍵ストリームに排他的論理和（ＸＯＲ）演算を適用するステップを含む。
【0018】
上記提案の全てにおいて、フレッシュネス値は、ＵＴＣ（協定世界時）に基づく時間値であってもよい。
【0019】
さらに、第１の態様またはその変形のいずれかと組み合わせることができる第４の変形では、方法は、第１の局がメッセージのためのメッセージ完全性チェックを計算することを含む。
【0020】
この第４の変形例の一例では、メッセージ完全性チェックは、ステップｃ．の前にメッセージに含められ得る。また、ステップｂ．は、少なくとも機密性鍵、フレッシュネス値、メッセージ、およびメッセージのＭＩＣに鍵導出関数を適用することによって、鍵ストリームを生成するステップを含み得る。
【0021】
第１の態様の第５の変形例またはその変形例では、ステップｂ．は、所定のポリシーに従って、複数の利用可能な鍵から機密性鍵を選択するステップを含む。
【0022】
このような変形例では、（暗号化鍵である）ＤＵＣＫが設定されている場合、機密鍵はＤＵＣＫであり、そうでないが、（スクランブル鍵である）ＤＵＳＫが設定されている場合、機密鍵はＤＵＳＫであり得る。したがって、送信機および受信機は、どの鍵が設定され、合意されているかに応じて、どの鍵が使用されるべきかを知る。追加でまたは任意選択で、ＤＵＣＫが設定されている場合、鍵ストリームは暗号化アルゴリズムを適用することによって取得され得、ＤＵＣＫが設定されていないが、ＤＵＳＫが設定されている場合、鍵ストリームはスクランブルアルゴリズムを適用することによって取得される得る。
【0023】
さらなる選択肢では、機密性が設定されていない（ＤＵＣＫもＤＵＳＫも設定されていない）場合、ステップａ．のメッセージはステップｃ．で暗号化されない。
【0024】
上記変形例のうちのいずれかと組み合わせることができる第６の変形例では、鍵ストリームは、設定されている機密鍵に関係なく、単一のアルゴリズムを適用することによって取得され得る。実際、どの鍵が設定されていたとしても、同じアルゴリズムを使用できる。このアルゴリズムは、設定または選択された鍵を区別なく使用する。
【0025】
本発明の第１の態様の第７の変形例では、方法は、第１の局が、完全性鍵を使用してメッセージのためのメッセージ完全性チェックを計算するステップをさらに含み、完全性鍵は、選択された機密性鍵と同じである。
【0026】
本発明の第１の態様の第８の変形例では、ステップｂ．は、鍵導出関数を適用して第２の機密性鍵を取得するステップを含み、鍵ストリームは、対称暗号化アルゴリズムに第２の機密性鍵を適用することによって取得される。
【0027】
第８の変形例のある選択肢では、対称暗号化アルゴリズムは、コアネットワークによって選択されるか、以前の動作フェーズ中にネゴシエーションされたか、またはメッセージ内で通知されるＮＥＡアルゴリズムである。
【0028】
上記変形例のいずれかと組み合わせることができる第１の態様の第９の変形例では、サービスのタイプを示すパラメータは、リレーサービスコードである。
【0029】
本発明の第２の態様によれば、第２の局をさらに含む通信システムにおいて動作するための請求項１７に記載の第１の局が提案され、第１の局は、
送信機と、
受信機と、
命令を含むメモリに結合されたプロセッサとを備え、命令は、
サービスのタイプを示すパラメータと、第２の局との通信に使用されるべき通信鍵または通信鍵の指標との組み合わせを含むメッセージを準備するステップと、
少なくとも機密性鍵およびフレッシュネス値に鍵導出関数を適用することによって鍵ストリームを生成するためのアルゴリズムを実行するステップと、
鍵ストリームを用いてメッセージを暗号化するステップとを実行するための命令である。
送信機と、
受信機と、
命令を含むメモリに結合されたプロセッサとを備え、命令は、
サービスのタイプを示すパラメータと、第２の局との通信に使用されるべき通信鍵または通信鍵の指標との組み合わせを含むメッセージを準備するステップと、
少なくとも機密性鍵およびフレッシュネス値に鍵導出関数を適用することによって鍵ストリームを生成するためのアルゴリズムを実行するステップと、
鍵ストリームを用いてメッセージを暗号化するステップとを実行するための命令である。
【0030】
本発明の第３の態様によれば、第１の局をさらに含む通信システムにおいて動作するための請求項１８に記載の第２の局が提案され、第２の局は、
送信機と、
受信機と、
命令を含むメモリに結合されたプロセッサとを備え、命令は、
暗号化されたメッセージを受信するステップと、
少なくとも機密性鍵およびフレッシュネス値に鍵導出関数を適用することによって鍵ストリームを生成するためのアルゴリズムを実行するステップと、
鍵ストリームを用いてメッセージを復号するステップとを実行するための命令である。
送信機と、
受信機と、
命令を含むメモリに結合されたプロセッサとを備え、命令は、
暗号化されたメッセージを受信するステップと、
少なくとも機密性鍵およびフレッシュネス値に鍵導出関数を適用することによって鍵ストリームを生成するためのアルゴリズムを実行するステップと、
鍵ストリームを用いてメッセージを復号するステップとを実行するための命令である。
【0031】
第１の態様の様々な変形例は、本発明の第２および第３の態様にも等しく適用されることに留意されたい。
【0032】
本発明の第４の態様では、請求項１９に記載のシステムが提案される。
【0033】
本発明の第５の態様では、通信システムにおいて、第１の局が第２の局にメッセージを送信するための請求項２０に記載の方法が提案され、方法は、
ａ．第１の局が、メッセージに基づいてＭＩＣ（メッセージ完全性チェック）を計算するステップと、
ｂ．第１の局が、ＭＩＣをメッセージと組み合わせるステップと、
ｃ．少なくともＭＩＣに基づいて鍵ストリームを計算するステップと、
ｄ．第１の局が、鍵ストリームに基づくキーワードを使用してメッセージを暗号化し、暗号を取得するステップとを含む。
ａ．第１の局が、メッセージに基づいてＭＩＣ（メッセージ完全性チェック）を計算するステップと、
ｂ．第１の局が、ＭＩＣをメッセージと組み合わせるステップと、
ｃ．少なくともＭＩＣに基づいて鍵ストリームを計算するステップと、
ｄ．第１の局が、鍵ストリームに基づくキーワードを使用してメッセージを暗号化し、暗号を取得するステップとを含む。
【0034】
本発明の第５の態様の第１の変形例では、方法は、ステップｄ．から得られた暗号の一部をスクランブルするステップｅをさらに含む。
【0035】
本発明の第５の態様の第２の変形例では、ＭＩＣは、鍵ストリームの計算においてメッセージのフィンガープリントとして使用される。
【0036】
他の変形例から独立して、または他の変形例と組み合わせて使用され得る、本発明の第５の態様の第３の変形では、キーワードは、鍵ストリームと暗号化鍵マスクとの組み合わせである。任意選択で、組み合わせはＡＮＤ演算である。
【0037】
本発明の第６の態様では、通信システムにおいて第１の局を動作させる方法が提案され、方法は、
ａ．第１の局が、長さＬバイトのディスカバリメッセージを準備するステップと、
ｂ．第１の局が、サイズＢバイトの鍵導出関数をＣｅｉｌｉｎｇ（Ｌ／Ｂ）回適用するか、またはＮＥＡアルゴリズムを適用することによって、出力サイズがＬバイトの疑似乱数列を生成するステップであって、疑似乱数列は、少なくとも機密性鍵、フレッシュネス値、およびカウンタ値に依存する、ステップと、
ｃ．第１の局が疑似乱数列を使用してメッセージを暗号化するステップとを含む。
ａ．第１の局が、長さＬバイトのディスカバリメッセージを準備するステップと、
ｂ．第１の局が、サイズＢバイトの鍵導出関数をＣｅｉｌｉｎｇ（Ｌ／Ｂ）回適用するか、またはＮＥＡアルゴリズムを適用することによって、出力サイズがＬバイトの疑似乱数列を生成するステップであって、疑似乱数列は、少なくとも機密性鍵、フレッシュネス値、およびカウンタ値に依存する、ステップと、
ｃ．第１の局が疑似乱数列を使用してメッセージを暗号化するステップとを含む。
【0038】
本発明の第６の態様の第１の変形例では、鍵導出関数への入力は、マスクと、メッセージおよびＭＩＣの連結とにビットごとの「ＡＮＤ」関数を適用した結果を含む。
【0039】
第１の変形例と組み合わせることができる第２の変形例では、鍵導出関数またはＮＥＡアルゴリズムの入力は、マスクの関数、メッセージの関数、またはＭＩＣの関数を少なくとも含む。
【0040】
第１または第２の変形例と組み合わせることができる第３の変形例では、メッセージは、メッセージ長を示すか、または、暗号化動作を調整するための任意選択のフィールドの存在を示すマスクを示す。
【0041】
本発明の第７の態様では、第６の態様の方法に従って動作する第１の局と、第２の局とを含むシステムを動作させる方法が提案され、第２の局は、
ａ．ディスカバリメッセージを受信するステップと、
ｂ．生成された疑似乱数列の最初の部分を使用することによって、ディスカバリメッセージの最初の部分をスクランブル解除および／または復号するステップと、
ｃ．ディスカバリメッセージの最初の部分のＭＩＣを用いてディスカバリメッセージの最初の部分の完全性を検証するステップと、
ｄ．ディスカバリメッセージの最初の部分の完全性チェックが成功した場合、および／またはディスカバリメッセージの最初の部分のフィールドがディスカバリメッセージの２番目の部分の存在を示す場合、生成された疑似乱数列の第２の部分を使用して、ディスカバリメッセージの２番目の部分をスクランブル解除および／または復号するステップとを実行する。
ａ．ディスカバリメッセージを受信するステップと、
ｂ．生成された疑似乱数列の最初の部分を使用することによって、ディスカバリメッセージの最初の部分をスクランブル解除および／または復号するステップと、
ｃ．ディスカバリメッセージの最初の部分のＭＩＣを用いてディスカバリメッセージの最初の部分の完全性を検証するステップと、
ｄ．ディスカバリメッセージの最初の部分の完全性チェックが成功した場合、および／またはディスカバリメッセージの最初の部分のフィールドがディスカバリメッセージの２番目の部分の存在を示す場合、生成された疑似乱数列の第２の部分を使用して、ディスカバリメッセージの２番目の部分をスクランブル解除および／または復号するステップとを実行する。
【0042】
第７の態様の第１の変形例では、受信したメッセージのスクランブル／暗号化された２番目の部分のハッシュが、ディスカバリメッセージの最初の部分内に含まれ、かつ最初の部分内で検証されるハッシュ値と一致する場合、受信したディスカバリメッセージの第２の部分がスクランブル解除および／または復号される。
【0043】
本発明の第５または６の態様の一変形例では、ステップａは、メッセージ、および利用可能な場合はＤＵＩＫ（完全性鍵）に基づいてＭＩＣを計算するステップを含み、ステップａは、ＤＵＩＫが設定されていない場合、ＭＩＣをランダムな値に設定するステップを含む。任意選択で、鍵ストリームはＮＥＡアルゴリズムを使用して計算される。
【0044】
追加で、ＮＥＡアルゴリズムにおける３２ビットカウントが、ＵＴＣベースのカウンタ値に設定され得、ＢＥＡＲＥＲフィールド値がＢＥＡＲＥＲ＝００００に設定され、ＤＩＲＥＣＴＩＯＮフィールド値が０に設定される。
【0045】
第５または第６の態様の一選択肢では、ディスカバリメッセージの保護は、まずメッセージの最初の部分に適用され、その後、メッセージの２番目の部分に適用され、メッセージの最初の部分およびメッセージの２番目の部分の保護は互いに異なる。
【0046】
本発明の第８の態様では、通信システムにおいて動作する第１の局が提案され、第１の局は、
送信機と、
受信機と、
命令を含むメモリに結合されたプロセッサとを備え、命令は、
ａ．第１の局が、メッセージに基づいてＭＩＣ（メッセージ完全性チェック）を計算するステップと、
ｂ．第１の局が、ＭＩＣをメッセージと組み合わせるステップと、
ｃ．少なくともＭＩＣに基づいて鍵ストリームを計算するステップと、
ｄ．第１の局が、鍵ストリームに基づくキーワードを使用してメッセージを暗号化し、暗号を取得するステップとを実行するための命令である。
送信機と、
受信機と、
命令を含むメモリに結合されたプロセッサとを備え、命令は、
ａ．第１の局が、メッセージに基づいてＭＩＣ（メッセージ完全性チェック）を計算するステップと、
ｂ．第１の局が、ＭＩＣをメッセージと組み合わせるステップと、
ｃ．少なくともＭＩＣに基づいて鍵ストリームを計算するステップと、
ｄ．第１の局が、鍵ストリームに基づくキーワードを使用してメッセージを暗号化し、暗号を取得するステップとを実行するための命令である。
【0047】
本発明の第９の態様では、通信システムにおいて動作する第１の局が提案され、第１の局は、
送信機と、
受信機と、
命令を含むメモリに結合されたプロセッサとを備え、命令は、
長さＬバイトのディスカバリメッセージを準備するステップと、
サイズＢバイトの鍵導出関数をＣｅｉｌｉｎｇ（Ｌ／Ｂ）回適用するか、またはＮＥＡアルゴリズムを適用することによって、出力サイズがＬバイトの疑似乱数列を生成するステップであって、疑似乱数列は、少なくとも機密性鍵、フレッシュネス値、およびカウンタ値に依存する、ステップと、
疑似乱数列を用いてメッセージを暗号化するステップとを実行するための命令である。
送信機と、
受信機と、
命令を含むメモリに結合されたプロセッサとを備え、命令は、
長さＬバイトのディスカバリメッセージを準備するステップと、
サイズＢバイトの鍵導出関数をＣｅｉｌｉｎｇ（Ｌ／Ｂ）回適用するか、またはＮＥＡアルゴリズムを適用することによって、出力サイズがＬバイトの疑似乱数列を生成するステップであって、疑似乱数列は、少なくとも機密性鍵、フレッシュネス値、およびカウンタ値に依存する、ステップと、
疑似乱数列を用いてメッセージを暗号化するステップとを実行するための命令である。
【0048】
本発明の第１０の態様では、通信システムにおいて動作する第２の局が提案され、第２の局は、
送信機と、
受信機と、
命令を含むメモリに結合されたプロセッサとを備え、命令は、
第２の局が、暗号化されたメッセージ、ＭＩＣ（メッセージ完全性チェック）を受信するステップと、
第２の局が、ＭＩＣに基づくキーワードを取得するステップと、
第２の局が、取得したキーワードを使用して、暗号化されたメッセージを復号するステップと、
第２の局が、受信したＭＩＣが有効であるか否かをチェックすることで、メッセージの完全性をチェックするステップとを実行するための命令である。
送信機と、
受信機と、
命令を含むメモリに結合されたプロセッサとを備え、命令は、
第２の局が、暗号化されたメッセージ、ＭＩＣ（メッセージ完全性チェック）を受信するステップと、
第２の局が、ＭＩＣに基づくキーワードを取得するステップと、
第２の局が、取得したキーワードを使用して、暗号化されたメッセージを復号するステップと、
第２の局が、受信したＭＩＣが有効であるか否かをチェックすることで、メッセージの完全性をチェックするステップとを実行するための命令である。
【0049】
本発明の第１１の態様では、システムは、本発明の第８の態様の第１の局と、本発明の第１０の態様の第２の局とを備える。
【0050】
本発明の第１２の態様では、無線デバイス上にロードされたとき、無線デバイスに第１に記載の方法のステップを実行させるコードを備えたコンピュータプログラム製品が提案される。
【0051】
本発明の第２の態様によれば、中継局を動作させる方法、および中継局が提案される。
【0052】
本発明の第３の態様によれば、二次局を動作させる方法、および二次局が提案される。
【0053】
本発明の第４の態様によれば、コンピュータデバイス上で実行されたとき、本発明の第１、第４、第５、第６、または第７の態様の方法のステップを生成するためのコード手段を含むコンピュータプログラム製品が提案される。
【0054】
上記の各装置は、個別のハードウェアコンポーネント、集積チップ、またはチップモジュール構成を有する個別のハードウェア回路に基づいて実装されるか、または、メモリに格納されているか、コンピュータ可読媒体上に書き込まれているか、もしくはインターネットなどのネットワークからダウンロードされたソフトウェアルーチンもしくはプログラムによって制御される信号処理デバイスもしくはチップに基づいて実装され得ることに留意されたい。
【0055】
無線デバイス、システム、中継局、基地局（ｃｅｌｌ ｓｔａｔｉｏｎ）、および方法は、特に従属請求項に記載されているような、類似した、対応する、および／または同一の好ましい実施形態を有し得ることを理解されたい。
【0056】
本発明の好ましい実施形態は、従属請求項又は上記実施形態と独立請求項との任意の組み合わせとすることもできることを理解されたい。
【0057】
本発明の上記および他の態様は、以下に記載される実施形態を参照しながら説明され、明らかになるであろう。
【0058】
上記の各装置は、個別のハードウェアコンポーネント、集積チップ、またはチップモジュール構成を有する個別のハードウェア回路に基づいて実装されるか、または、メモリに格納されているか、コンピュータ可読媒体上に書き込まれているか、もしくはインターネットなどのネットワークからダウンロードされたソフトウェアルーチンもしくはプログラムによって制御される信号処理デバイスもしくはチップに基づいて実装され得ることに留意されたい。
【0059】
局、本発明の様々な態様の方法、コンピュータプログラム製品、およびシステムは、特に従属請求項に記載されているような、類似した、および／または同一の好ましい実施形態を有し得ることを理解されたい。
【0060】
本発明の上記および他の態様は、以下に記載される実施形態を参照しながら説明され、明らかになるであろう。
【図面の簡単な説明】
【0061】
【発明を実施するための形態】
【0062】
以下の実施形態において、本発明の様々な態様を詳細に説明する。上記したように、本発明の実施形態は様々なタイプの無線通信に関連する可能性があり、特に無線ネットワークにアクセスしようとするデバイスの接続セットアップに関連する可能性がある。典型的な例は、おそらくはいくつかの中継ノードを含む、５Ｇネットワークなどのセルラーネットワークである。これらの中継ノードは、中継ノードとして動作できるサイドリンク対応ＵＥなどのＵＥによって、または他のタイプのリピータによって実装されてもよい。
【0063】
この種のリレーを介した新しい接続を可能にするには、ディスカバリメッセージがリレーＵＥに送信されるか、またはリレーＵＥによって送信されるディスカバリフェーズが必要となる。この特定の例示的実施形態の１つの一般的な目的は、そのようなディスカバリメッセージの保護を強化することである。技術仕様ＴＳ３３．３０３ ｖ１７．０．０のセクション６．１．３．４．３では、ディスカバリメッセージの保護について説明されている。制限付きディスカバリメッセージを保護するために使用される３つのタイプのセキュリティが列挙されており、詳細は以下の通りである。
【0064】
第一に、Ｏｐｅｎ Ｄｉｓｃｏｖｅｒｙ（小項６．１．３．３．１を参照）と同様に、ＭＩＣ（メッセージ識別コード）を追加することによって完全性保護が提供される。ＭＩＣは、受信されたＤＵＩＫ（Ｄｉｓｃｏｖｅｒｙ Ｕｓｅｒ Ｉｎｔｅｇｒｉｔｙ Ｋｅｙ）を使用して送信側ＵＥで計算される。ＭＩＣは、供給されたＤＵＩＫを使用して受信側ＵＥでチェックされるか、またはＤＵＩＫを使用してＰｒｏＳｅ 機能（中継ノード）でチェックされ得る。
【0065】
２つ目は、特定のＵＥによって送信された複数のディスカバリメッセージ間に関連性がないことを保証する、すなわち、時間をかけてＵＥがトラッキングされるのを防ぐスクランブル保護である。ＤＵＳＫ（Ｄｉｓｃｏｖｅｒｙ Ｕｓｅｒ Ｓｃｒａｍｂｌｉｎｇ Ｋｅｙ）と、ディスカバリスロットに関連付けられたＵＴＣベースのカウンタとから、スクランブル鍵ストリームが計算される（計算の詳細については、６．１．３．４．３．５を参照）。
【0066】
最後に、ディスカバリメッセージの一部の機密性保護を提供するメッセージ固有機密性がある。これは、複数のＵＥが同じＤＵＳＫを使用する場合、またはＵＥ発見が許可されている複数のＵＥのうちの一部からのディスカバリメッセージの一部を難読化することが望まれる場合に使用される。ＤＵＣＫ（Ｄｉｓｃｏｖｅｒｙ Ｕｓｅｒ Ｃｏｎｆｉｄｅｎｔｉｌｉｔｙ Ｋｅｙ）と、メッセージの内容と、ディスカバリスロットに関連付けられたＵＴＣベースのカウンタとから、鍵ストリームが計算される（計算の詳細については、６．１．３．４．３．６を参照）。
【0067】
送信側ＵＥおよび受信側ＵＥに適用されるセキュリティ手順は、ＰｒｏＳｅ機能がコード送信セキュリティパラメータおよび／またはコード受信セキュリティパラメータを適切なＵＥに送信することによって制御される（すなわち、ＵＥは完全性保護、スクランブル、およびメッセージ固有機密性の全てをサポートする必要がある）。ＰｒｏＳｅ制限付きディスカバリメッセージの完全性保護を実現するには、ＤＵＳＫまたはＤＵＩＫのいずれかを提供する必要がある。ＤＵＣＫを使用してメッセージ固有機密性が適用される場合、複数のメッセージが保護されるので、完全性保護のためにＤＵＩＫが必要である。ユースケースのタイプに応じたディスカバリユーザ鍵の組み合わせの例が、付録Ｇに記載されている。
【0068】
受信側では、照合を試みる前にスクランブル保護を解除する必要がある。メッセージ固有機密性を解除する演算は大量の計算を必要とするため、その前に行われる照合演算で偽陽性が発生する可能性は極めて最小限に抑えるべきである。この目的を達成するために、ＰｒｏＳｅ機能は、スクランブル解除後に照合できるディスカバリメッセージ内のビット数が少なくとも１６であることを保証する必要がある（これにより、偽陽性の可能性が６５，５３６分の１以下になる）。
【0069】
項６．１．３．４．３．２、Ｍｅｓｓａｇｅ Ｐｒｏｃｅｓｓｉｎｇ ｉｎ ｔｈｅ ｓｅｎｄｉｎｇ ＵＥでは、ディスカバリメッセージを送信するＵＥは、メッセージを保護する方法を示すために、ＰｒｏＳｅ機能からコード送信セキュリティパラメータを受信する（セキュリティフローで説明されているように）。コード送信セキュリティパラメータはＤＵＳＫを含み得、ＤＵＩＫを含み得る。コード送信セキュリティパラメータは、ＤＵＣＫおよびＥｎｃｒｙｐｔｅｄ＿ｂｉｔｓ＿ｍａｓｋの両方を含み得る。
【0070】
ディスカバリメッセージを送信するＵＥは次のステップを実行する。
１．ディスカバリメッセージを形成する（例えば、プレフィックスのみが割り当てられている場合はサフィックスを追加する）。
２．ＤＵＩＫが提供された場合はＭＩＣを計算し、そうでない場合はＭＩＣを全てゼロに設定する。
３．ＤＵＣＫを受信した場合、メッセージ固有機密性をメッセージに追加する。
４．ステップ３の出力にＭＩＣを添付する。
５．ＤＵＳＫを受信した場合、ステップ４の出力にスクランブルを追加する。
１．ディスカバリメッセージを形成する（例えば、プレフィックスのみが割り当てられている場合はサフィックスを追加する）。
２．ＤＵＩＫが提供された場合はＭＩＣを計算し、そうでない場合はＭＩＣを全てゼロに設定する。
３．ＤＵＣＫを受信した場合、メッセージ固有機密性をメッセージに追加する。
４．ステップ３の出力にＭＩＣを添付する。
５．ＤＵＳＫを受信した場合、ステップ４の出力にスクランブルを追加する。
【0071】
項６．１．３．４．３．３、Ｐｒｏｔｅｃｔｅｄ ｍｅｓｓａｇｅ ｐｒｏｃｅｓｓｉｎｇ ｉｎ ｔｈｅ ｒｅｃｅｉｖｉｎｇ ＵＥでは、（セキュリティフローで説明されているように）ＰｒｏＳｅ機能から受信されるコード受信セキュリティパラメータを使用して、受信したディスカバリメッセージの保護方法がＵＥに示される。コード受信セキュリティパラメータは、ＤＵＳＫを含み得、ＤＵＩＫ、またはＭＩＣチェックに照合レポートを使用すべきか否かの指示のいずれかを含み得る。ＰｒｏＳｅクエリコードでは照合レポートの選択肢は許可されていない。コード受信セキュリティパラメータも、ＤＵＣＫおよび対応するＥｎｃｒｙｐｔｅｄ＿ｂｉｔｓ＿ｍａｓｋの両方を含み得る。
【0072】
ディスカバリメッセージを受信するＵＥは次のステップを実行する。
１．ＤＵＳＫが受信された場合、スクランブルを解除する（送信側ＵＥのステップ５と同様に）。
２．メッセージ固有機密性を使用して暗号化されていないメッセージのビットが一致するか否かをチェックする。一致しない場合は中止する。
ディスカバリフィルタによって一致が示される一部のビットは、この段階でメッセージ固有機密性によって暗号化され得る。ＵＥは、このステップの後に他のビットの一致を検索して、一致を見つける前に実行される処理の量を最小限に抑えてもよい。
３．ＤＵＣＫが受信された場合、メッセージ固有機密性を解除する（送信側ＵＥのステップ３と同様に）。
４．３で暗号化されていないビットの一致のみが見つかった場合、完全照合を行う。一致しない場合は中止する。
５．ＭＩＣチェックが必要な場合、ＭＩＣを直接チェックするか（ディスカバリフィルタセキュリティパラメータ内でＤＵＩＫが与えられた場合）、またはディスカバリフィルタセキュリティパラメータ内に示されている場合は照合レポートを介してチェックする。
１．ＤＵＳＫが受信された場合、スクランブルを解除する（送信側ＵＥのステップ５と同様に）。
２．メッセージ固有機密性を使用して暗号化されていないメッセージのビットが一致するか否かをチェックする。一致しない場合は中止する。
ディスカバリフィルタによって一致が示される一部のビットは、この段階でメッセージ固有機密性によって暗号化され得る。ＵＥは、このステップの後に他のビットの一致を検索して、一致を見つける前に実行される処理の量を最小限に抑えてもよい。
３．ＤＵＣＫが受信された場合、メッセージ固有機密性を解除する（送信側ＵＥのステップ３と同様に）。
４．３で暗号化されていないビットの一致のみが見つかった場合、完全照合を行う。一致しない場合は中止する。
５．ＭＩＣチェックが必要な場合、ＭＩＣを直接チェックするか（ディスカバリフィルタセキュリティパラメータ内でＤＵＩＫが与えられた場合）、またはディスカバリフィルタセキュリティパラメータ内に示されている場合は照合レポートを介してチェックする。
【0073】
受信側ＵＥが関心のあるメッセージのビットの完全性保護をスクランブル保護が提供する場合にのみ、（ＵＥにおける、または照合レポートを介した）ＭＩＣのチェックの要求を省略できる。このような完全性保護は、（１）与えられたＤＵＳＫが、受信機が一致するちょうど１つのＰｒｏＳｅコードを保護する場合か、または（２）メッセージ固有機密性がＰｒｏＳｅコードに適用されているが、メッセージ固有機密性を除去するためにＤＵＳＫが受信側ＵＥに提供されておらず、全ての非暗号化ビットが、受信機が一致する固定値をとる場合にのみ、提供される。最初のケースでは、攻撃者がメッセージの一部を変更すると、照合が失敗する。２つ目のケースでは、攻撃者が非暗号化ビットを変更すると照合が失敗するが、暗号化ビットを変更しても、受信側ＵＥはどのみちこれらのビットを無視するため、何も起こらない。後者の場合、受信側ＵＥはＭＩＣのチェックに失敗した。
【0074】
項６．１．３．４．３．４、Ｉｎｔｅｇｒｉｔｙ ｐｒｏｔｅｃｔｉｏｎ ｄｅｓｃｒｉｐｔｉｏｎでは、送信側ＵＥは以下を行う。
１．付録Ａ．２のＭＩＣ計算関数を通過されるＤＵＩＫ、メッセージ、および、ＵＴＣベースのカウンタから、出力ビットシーケンスを計算する。
２．関数の出力の４バイトを取得し、それをこのメッセージのＭＩＣの値として設定する。
１．付録Ａ．２のＭＩＣ計算関数を通過されるＤＵＩＫ、メッセージ、および、ＵＴＣベースのカウンタから、出力ビットシーケンスを計算する。
２．関数の出力の４バイトを取得し、それをこのメッセージのＭＩＣの値として設定する。
【0075】
受信側ＵＥまたはＰｒｏＳｅ関数は全く同じ手順を実行するが、さらに、計算されたＭＩＣと受信したＭＩＣとの比較も実行する。
【0076】
項６．１．３．４．３．５、ｓｃｒａｍｂｌｉｎｇ ｄｅｓｃｒｉｐｔｉｏｎでは、送信側ＵＥは以下を行う。
１．このスクランブル計算のみを目的として、ＵＴＣベースのカウンタの４つのＬＳＢをゼロに設定する。
２．鍵付きハッシュ関数を通過されるＤＵＳＫおよびＵＴＣベースのカウンタ（ステップ１のように変更されたもの）からタイムハッシュビットシーケンスを計算する。
３．タイムハッシュビットシーケンスを、処理中のディスカバリメッセージ全体（ＭＩＣを含む）とＸＯＲする。
１．このスクランブル計算のみを目的として、ＵＴＣベースのカウンタの４つのＬＳＢをゼロに設定する。
２．鍵付きハッシュ関数を通過されるＤＵＳＫおよびＵＴＣベースのカウンタ（ステップ１のように変更されたもの）からタイムハッシュビットシーケンスを計算する。
３．タイムハッシュビットシーケンスを、処理中のディスカバリメッセージ全体（ＭＩＣを含む）とＸＯＲする。
【0077】
受信側ＵＥは、処理中の受信メッセージに適用されることを除いて、全く同じ手順を実行する。
【0078】
項６．１．３．４．３．６、ｍｅｓｓａｇｅ－ｓｐｅｃｉｆｉｃ ｃｏｎｆｉｄｅｎｔｉａｌｉｔｙ ｄｅｓｃｒｉｐｔｉｏｎでは、送信側ＵＥは以下を行う。
１．Ｋｅｙ＿ｃａｌｃ＿ｍａｓｋ＝（Ｅｎｃｒｙｐｔｅｄ＿ｂｉｔｓ＿ｍａｓｋ ＸＯＲ ０ｘＦＦ・・・ＦＦ）｜｜０ｘＦＦＦＦＦＦＦＦを計算する
２．鍵ストリーム＝ＫＤＦ（ＤＵＣＫ，ＵＴＣベースのカウンタ，（Ｋｅｙ＿ｃａｌｃ＿ｍａｓｋ ＡＮＤ（メッセージ｜｜ＭＩＣ）））を計算する。
３．メッセージ内へＸＯＲ（鍵ストリーム ＡＮＤ Ｅｎｃｒｙｐｔｅｄ＿ｂｉｔｓ＿ｍａｓｋ）する。
１．Ｋｅｙ＿ｃａｌｃ＿ｍａｓｋ＝（Ｅｎｃｒｙｐｔｅｄ＿ｂｉｔｓ＿ｍａｓｋ ＸＯＲ ０ｘＦＦ・・・ＦＦ）｜｜０ｘＦＦＦＦＦＦＦＦを計算する
２．鍵ストリーム＝ＫＤＦ（ＤＵＣＫ，ＵＴＣベースのカウンタ，（Ｋｅｙ＿ｃａｌｃ＿ｍａｓｋ ＡＮＤ（メッセージ｜｜ＭＩＣ）））を計算する。
３．メッセージ内へＸＯＲ（鍵ストリーム ＡＮＤ Ｅｎｃｒｙｐｔｅｄ＿ｂｉｔｓ＿ｍａｓｋ）する。
【0079】
受信側ＵＥは、処理中の受信したディスカバリメッセージに適用されることを除いて、全く同じ手順を実行する。
【0080】
後述するように上記手順におけるＫＤＦは鍵導出関数（Ｋｅｙ Ｄｅｒｉｖａｔｉｏｎ Ｆｕｎｃｔｉｏｎ）を指す。
【0081】
また、ＭＩＣの計算は次のように定義することが提案される。
【表1】
【0082】
この例でのディスカバリ用のスクランブルビットの計算はＡ．５の通りである。
【表2】
【0083】
この例では、メッセージ固有機密性の計算はＴＳ３３．３０３のＡ．６と同様である。
【表3】
【0084】
メッセージの長さ｜｜ＭＩＣは０ｘ１Ｂ＝１６＋１１＝２７バイト。これは、Ｅ．５．２．２．２７で定義されているように、ＭＩＣが４バイトでＫｅｙ＿ｃａｌｃ＿ｍａｓｋの長さが２３バイトであるという事実に適合する。
【0085】
ＴＳ３３．３０３に記載されているように、ディスカバリメッセージの後に交換される直接通信リクエスト（ＤＣＲ）メッセージ内の内容は保護されない。これらの手順を簡略化するために、およびプライバシー保護を強化するために、ＤＵＣＫまたはＤＵＳＫを再利用して、ディスカバリフェーズ後の直接通信リクエスト内で送信されるＰＲＵＫ ＩＤおよびＲＳＣを保護することが提案されている。このような場合、コード受信セキュリティパラメータを使用して、ＤＣＲメッセージ内のＲＳＣおよびＰＲＵＫ ＩＤを保護することができる。したがって、この提案では、リモートＵＥは次のように動作する必要がある。
「－ リモートＵＥにＤＵＣＫが提供されている場合、
１．メッセージ＝ＲＳＣ｜｜ＰＲＵＫ ＩＤを形成する
２．Ｋｅｙ＿ｃａｌｃ＿ｍａｓｋ＝（Ｅｎｃｒｙｐｔｅｄ＿ｂｉｔｓ＿ｍａｓｋ ＸＯＲ ０ｘＦＦ・・・ＦＦ）｜｜０ｘＦＦＦＦＦＦＦＦを計算する
３．鍵ストリーム＝ＫＤＦ（ＤＵＣＫ，ＵＴＣベースのカウンタ，（Ｋｅｙ＿ｃａｌｃ＿ｍａｓｋ ＡＮＤ Ｍｅｓｓａｇｅ））（小項６．Ｙ．２．３を参照）を計算する。
４．メッセージ内へＸＯＲ（Ｋｅｙｓｔｒｅａｍ ＡＮＤ Ｅｎｃｒｙｐｔｅｄ＿ｂｉｔｓ＿ｍａｓｋ）する。
「－ リモートＵＥにＤＵＣＫが提供されている場合、
１．メッセージ＝ＲＳＣ｜｜ＰＲＵＫ ＩＤを形成する
２．Ｋｅｙ＿ｃａｌｃ＿ｍａｓｋ＝（Ｅｎｃｒｙｐｔｅｄ＿ｂｉｔｓ＿ｍａｓｋ ＸＯＲ ０ｘＦＦ・・・ＦＦ）｜｜０ｘＦＦＦＦＦＦＦＦを計算する
３．鍵ストリーム＝ＫＤＦ（ＤＵＣＫ，ＵＴＣベースのカウンタ，（Ｋｅｙ＿ｃａｌｃ＿ｍａｓｋ ＡＮＤ Ｍｅｓｓａｇｅ））（小項６．Ｙ．２．３を参照）を計算する。
４．メッセージ内へＸＯＲ（Ｋｅｙｓｔｒｅａｍ ＡＮＤ Ｅｎｃｒｙｐｔｅｄ＿ｂｉｔｓ＿ｍａｓｋ）する。
【0086】
－ リモートＵＥにＤＵＳＫが提供されている場合、
１．このスクランブル計算のみを目的として、ＵＴＣベースのカウンタの４つのＬＳＢをゼロに設定する。
２．６．Ｙ．２．４に記載されている鍵付きハッシュ関数を通過される、ＤＵＳＫ（Ｄｉｓｃｏｖｅｒｙ Ｕｓｅｒ Ｓｃｒａｍｂｌｉｎｇ Ｋｅｙ）およびＵＴＣベースのカウンタ（ステップ１のように変更されたもの）からタイムハッシュビットシーケンスを計算する。
３．タイムハッシュビットシーケンスを、処理中のＲＳＣおよびＰＲＵＫ ＩＤとＸＯＲする。
１．このスクランブル計算のみを目的として、ＵＴＣベースのカウンタの４つのＬＳＢをゼロに設定する。
２．６．Ｙ．２．４に記載されている鍵付きハッシュ関数を通過される、ＤＵＳＫ（Ｄｉｓｃｏｖｅｒｙ Ｕｓｅｒ Ｓｃｒａｍｂｌｉｎｇ Ｋｅｙ）およびＵＴＣベースのカウンタ（ステップ１のように変更されたもの）からタイムハッシュビットシーケンスを計算する。
３．タイムハッシュビットシーケンスを、処理中のＲＳＣおよびＰＲＵＫ ＩＤとＸＯＲする。
【0087】
ＵＥからネットワークへのリレーは、受信したＤＣＲからＲＳＣおよびＰＲＵＫ ＩＤを回収するために次を行う。
－ Ｕ２ＮリレーＵＥにＤＵＣＫが提供されている場合、
１．メッセージ＝受信したＤＣＲメッセージ内の保護された（ＲＳＣ｜｜ＰＲＵＫ ＩＤ）の一部、を形成する。
２．Ｋｅｙ＿ｃａｌｃ＿ｍａｓｋ＝（Ｅｎｃｒｙｐｔｅｄ＿ｂｉｔｓ＿ｍａｓｋ ＸＯＲ ０ｘＦＦ・・・ＦＦ）を計算する
３．鍵ストリーム＝ＫＤＦ（ＤＵＣＫ，ＵＴＣベースのカウンタ，（Ｋｅｙ＿ｃａｌｃ＿ｍａｓｋ ＡＮＤ （Ｍｅｓｓａｇｅ）））（小項６．Ｙ．２．３を参照）を計算する。
４．メッセージ内へＸＯＲ（Ｋｅｙｓｔｒｅａｍ ＡＮＤ Ｅｎｃｒｙｐｔｅｄ＿ｂｉｔｓ＿ｍａｓｋ）する。
－ Ｕ２ＮリレーＵＥにＤＵＣＫが提供されている場合、
１．メッセージ＝受信したＤＣＲメッセージ内の保護された（ＲＳＣ｜｜ＰＲＵＫ ＩＤ）の一部、を形成する。
２．Ｋｅｙ＿ｃａｌｃ＿ｍａｓｋ＝（Ｅｎｃｒｙｐｔｅｄ＿ｂｉｔｓ＿ｍａｓｋ ＸＯＲ ０ｘＦＦ・・・ＦＦ）を計算する
３．鍵ストリーム＝ＫＤＦ（ＤＵＣＫ，ＵＴＣベースのカウンタ，（Ｋｅｙ＿ｃａｌｃ＿ｍａｓｋ ＡＮＤ （Ｍｅｓｓａｇｅ）））（小項６．Ｙ．２．３を参照）を計算する。
４．メッセージ内へＸＯＲ（Ｋｅｙｓｔｒｅａｍ ＡＮＤ Ｅｎｃｒｙｐｔｅｄ＿ｂｉｔｓ＿ｍａｓｋ）する。
【0088】
－ Ｕ２ＮリレーにＤＵＳＫが提供されている場合、
１．このスクランブル計算のみを目的として、ＵＴＣベースのカウンタの４つのＬＳＢをゼロに設定する。
２．６．Ｙ．２．４に記載されている鍵付きハッシュ関数を通過される、ＤＵＳＫ（Ｄｉｓｃｏｖｅｒｙ Ｕｓｅｒ Ｓｃｒａｍｂｌｉｎｇ Ｋｅｙ）およびＵＴＣベースのカウンタ（ステップ１のように変更されたもの）からタイムハッシュビットシーケンスを計算する。
３．タイムハッシュビットシーケンスを、受信されたＤＣＲ内のＲＳＣおよびＰＲＵＫ ＩＤのスクランブルされた部分とＸＯＲする。
１．このスクランブル計算のみを目的として、ＵＴＣベースのカウンタの４つのＬＳＢをゼロに設定する。
２．６．Ｙ．２．４に記載されている鍵付きハッシュ関数を通過される、ＤＵＳＫ（Ｄｉｓｃｏｖｅｒｙ Ｕｓｅｒ Ｓｃｒａｍｂｌｉｎｇ Ｋｅｙ）およびＵＴＣベースのカウンタ（ステップ１のように変更されたもの）からタイムハッシュビットシーケンスを計算する。
３．タイムハッシュビットシーケンスを、受信されたＤＣＲ内のＲＳＣおよびＰＲＵＫ ＩＤのスクランブルされた部分とＸＯＲする。
【0089】
ディスカバリ鍵は、ＴＳ３３．３０３ ｖ１７．０．０Ａ．８で説明されているようにＰＤＳＫから生成される。
【0090】
『ＰＳＤＫからＤＵＳＫ、ＤＵＣＫ、またはＤＵＩＫを計算するとき、ＴＳ３３．２２０［５］の付録Ｂに記載されているＫＤＦへの入力Ｓを形成するために次のパラメータが使用される。
－ ＦＣ＝０ｘ４Ｆ
－ Ｐ０＝ＤＵＳＫが導出されている場合は０ｘ００、ＤＵＣＫが導出されている場合は０ｘ０１、ＤＵＩＫが導出されている場合は０ｘ０２
－ Ｌ０＝Ｐ０の長さ（すなわち、０ｘ００ ０ｘ０１）
－ Ｐ１＝アルゴリズムＩＤ
－ Ｌ１＝アルゴリズムＩＤの長さ（すなわち、０ｘ００ ０ｘ０１）
－ ＦＣ＝０ｘ４Ｆ
－ Ｐ０＝ＤＵＳＫが導出されている場合は０ｘ００、ＤＵＣＫが導出されている場合は０ｘ０１、ＤＵＩＫが導出されている場合は０ｘ０２
－ Ｌ０＝Ｐ０の長さ（すなわち、０ｘ００ ０ｘ０１）
－ Ｐ１＝アルゴリズムＩＤ
－ Ｌ１＝アルゴリズムＩＤの長さ（すなわち、０ｘ００ ０ｘ０１）
【0091】
アルゴリズムＩＤは０ｘ００に設定される。今後のリリースでは、他の値が定義される可能性がある。
【0092】
入力鍵は２５６ビットＰＳＤＫである。
【0093】
長さｎビットのアルゴリズム鍵（ここで、ｎは２５６以下）の場合、ＫＤＦ出力の２５６ビットの最下位ｎビットがアルゴリズム鍵として使用される。」
【0094】
上記実施形態で説明した鍵導出関数（ＫＤＦ）は、付録Ｂ．２のＴＳ３３．２２０ ｖ１７．０．０で定義されている。鍵Ｋを有する入力ビット列ＳのＫＤＦ、すなわちＫＤＦ（Ｋ，Ｓ）はＨＭＡＣ－ＳＨＡ－２５６（Ｋ，Ｓ）と同等であり、ここで、ＳＨＡ－２５６は、ＨＭＡＣ構築において使用されるハッシュ関数である。ビット列Ｓは、ＴＳ３３．２２０で説明されているように、複数のパラメータｐａｒａｍ１、ｐａｒａｍ２、・・・、ｐａｒａｍＮから構築され、これらのパラメータは割り当てられた長さで連結され、ＫＤＦの具体的用途のための一意の識別子ＦＣが含まれる。ＫＤＦ（Ｋ，Ｓ）と表す代わりに、ＫＤＦ（Ｋ，ｐａｒａｍ１，ｐａｒａｍ２，・・・，ｐａｒａｍＮ）と表される場合もあり、ここで、ビット列Ｓはフィールドｐａｒａｍ１、ｐａｒａｍ２、以下同で構築されることを理解されたい。
【0095】
完全性、機密性、およびスクランブル用の上記の様々な鍵（それぞれ、ＤＵＩＫ、ＤＵＣＫ、およびＤＵＳＫ）は、ＴＳ３３．３０３の付録Ｇで説明されているように組み合わせて定義することができる。より具体的には、様々な組み合わせを以下の表に示す。この表には、制限付きディスカバリおよびパブリックセーフティディスカバリ用に可能な様々なセキュリティ機構の組み合わせについて、提供されるセキュリティと、サンプルユースケースとが詳細に示されている。この表は、制限付きディスカバリまたはパブリックセーフティディスカバリに関してＵＥがサポートするセキュリティ機構の組み合わせを制限するものではない。
【表4】
【0096】
「送信側ＵＥ」の列は、制限付きディスカバリの場合には、送信側ＵＥが知る必要がある鍵を表し、またはパブリックセーフティディスカバリの場合には、ＰＫＭＦによる使用のために知らせる必要がある鍵を表す。「受信側」の列は、（ＰｒｏＳｅ機能ＭＩＣチェックが必要な場合（ＤＵＩＫが受信側ＵＥのＨＰＬＭＮ内のＰｒｏＳｅ機能にて保持されている場合）を除き）制限付きディスカバリのために受信側ＵＥに送信する必要がある鍵、またはＰＫＭＦによる使用のために知らせる必要がある鍵を示す。「提供されるセキュリティ」の列では、このセキュリティ機構の組み合わせによって提供されるセキュリティについて詳述されている。最後の列では、このセキュリティ機構の組み合わせが使用可能なユースケース例が示されている。
【0097】
ＤＣＲ保護に関する問題
ＴＳ３３．３０３の方法を再利用することによってＰＣ５インターフェースを介したＤＣＲメッセージの保護を改善するために提案されたソリューションに関して、これらの提案された方式はいくつかの問題を生み、本発明の以下の実施形態はそれらを解決する。
ＴＳ３３．３０３の方法を再利用することによってＰＣ５インターフェースを介したＤＣＲメッセージの保護を改善するために提案されたソリューションに関して、これらの提案された方式はいくつかの問題を生み、本発明の以下の実施形態はそれらを解決する。
【0098】
まず（問題１．１）、上記したように、暗号化アルゴリズムｋｅｙ＿ｃａｌｃ＿ｍａｓｋは、Ｋｅｙ＿ｃａｌｃ＿ｍａｓｋ＝（Ｅｎｃｒｙｐｔｅｄ＿ｂｉｔｓ＿ｍａｓｋ ＸＯＲ ０ｘＦＦ・・・ＦＦ）｜｜０ｘＦＦＦＦＦＦＦＦとして計算される。
【0099】
しかし、０ｘＦＦＦＦＦＦＦＦの連結は必要ない（ＴＳ３３．３０３とは異なり、ディスカバリメッセージの保護においてＭＩＣが存在しないため）。なお、０ｘＦＦ・・・ＦＦの長さは規定されていない。
【0100】
また、（問題１．２）Ｅｎｃｒｙｐｔｅｄ＿ｂｉｔｓ＿ｍａｓｋが定義されていないため、このマスクを生成する方法を有する必要がある。
【0101】
さらに（問題１．３）、メッセージは完全性が保護されない。実際、リモートＵＥ（すなわち、ディスカバリモードＡのモニタリングＵＥまたはディスカバリモードＢの発見者ＵＥ）は照合レポートを使用する可能性があるため、リモートＵＥは適切なＤＵＩＫを有さない可能性がある。したがって、現在提案されているルーチン、またはＴＳ３３．３０３の現在のバージョンを使用して完全性保護を適用する方法が存在しない。これらの方式にＭＩＣを単純に追加することは非効率的である。
【0102】
さらなる問題は、以前の提案が、異なるアルゴリズムを使用するＤＵＳＫまたはＤＵＣＫのいずれかを使用してＤＣＲメッセージの機密性を保護できることを示していることである。しかし、これは修正を要するいくつかの問題を伴う。
【0103】
まず、ＤＵＳＫを使用したスクランブルアルゴリズムは、１６秒の粒度で、ＤＵＳＫとＵＴＣベースのカウンタとに依存する疑似乱数列を計算し、この疑似乱数列とのＸＯＲ演算を行うことでメッセージを暗号化する。ＤＵＣＫを使用する暗号化アルゴリズムは、１秒の粒度で、ＤＵＣＫ、ＵＴＣベースのカウンタ、およびＲＳＣに依存する疑似乱数列を計算し、この疑似乱数列とのＸＯＲ演算を行うことでメッセージを暗号化する。複数のアルゴリズムを使用できるため、ソリューションの複雑さが増す。
【0104】
第二に、リモートＵＥおよびリレーＵＥがＤＵＳＫおよびＤＵＣＫの両方を有する場合、どの鍵／アルゴリズムが使用されるかが定義されていないため、問題が生じる。
【0105】
さらなる問題は、リモートＵＥまたはリレーＵＥが複数組のディスカバリ鍵のセットを有する可能性があることである。なお、各セットは識別子によって、例えばＰＤＳＫ ＩＤによって識別され得る。なぜなら、ＤＵＳＫ、ＤＵＣＫ、および ＤＵＩＫはＴＳ３３．３０３またはＴＲ３３．８４７のＳｏｌｕｔｉｏｎ＃３７で指定されているように、ＰＤＳＫから導出されるからである。複数組のディスカバリ鍵セットを有する結果として、リレーＵＥは、ＤＣＲメッセージを復号するためにどのディスカバリ鍵セットのどの鍵を使用すべきかを知らない可能性がある。
【0106】
追加の問題は、暗号化に使用される疑似乱数列の生成における入力に関連しており、ＤＵＣＫと組み合わせられるのはＲＳＣである。実際には、ＤＵＣＫが複数のＲＳＣと組み合わせて使用される可能性があるため、リレーＵＥは、受け取ったメッセージの復号に使用される疑似乱数列の生成にどのＲＳＣを使用すべきかを直接知らない。
【0107】
ＴＳ３３．３０３ディスカバリのためのセキュリティルーチンに関連する問題
【0108】
さらに、ＴＳ３３．３０３の現行バージョンではさらなる問題が発生する。このバージョンでは、メッセージ送信時の処理は次のように指定されている。「セクション６．１．３．４．３．２には、ＤＵＩＫが受信された場合、ステップ２でＭＩＣが計算されると記載されている（そうでない場合は全て０に設定される）。次にステップ３で、ＤＵＣＫが受信された場合、メッセージ固有機密性が適用される。次にステップ４でＭＩＣが付加される。次に、ステップ５で、ＤＵＳＫが受信された場合、合計出力がスクランブルされる。」しかし、これにより次のような問題が発生する。
【0109】
ある追加の問題（問題２．１）では、ＭＩＣが暗号化されていないため、パッシブな攻撃者はメッセージの完全性が保護されているか否か、特にスクランブルが使用されていないかを直接監視することができる。
【0110】
ある追加の問題（問題２．２）では、ＴＳ３３．３０３の目標が、ＤＵＳＫおよびスクランブル機能を使用して、情報（例えば、メッセージの完全性が保護されているか否か）の漏洩を回避することであったとしても、スクランブルシーケンスは１６秒ごとにしか変更されない一方、暗号化シーケンスは（ＵＴＣベースのカウンタのため）毎秒変化し、ＭＩＣも（ＵＴＣベースのカウンタのため）毎秒変化するので、ＵＥによってブロードキャストされるメッセージの最後の４バイトが１秒ごとに変化するか、または１６秒ごとに変化するかを監視することによって、メッセージの完全性が保護されているか否かを観察することができる。
【0111】
ある追加の問題（問題２．３）では、フィールドＥｎｃｒｙｐｔｅｄ＿ｂｉｔｓ＿ｍａｓｋがデバイス（またはデバイスのクラス）ごとに異なる可能性がある。これに該当する場合、ｅｎｃｒｙｐｔｅｄ＿ｂｉｔｓ＿ｍａｓｋフィールドに基づいてデバイスを識別（および／または追跡）することができる。これは、（新しいカウンタに起因して）新しい暗号化が適用されると、暗号化されたビットのみが１秒に１回「変化」するからである。なお、スクランブルをかけたとしても攻撃者による追跡は可能である。これが実現可能なのは、暗号化シーケンスは毎秒変化する一方で、スクランブルシーケンスは１６秒間安定しているためである。この時間の間、攻撃者はデバイスに関連付けられているＥｎｃｒｙｐｔｅｄ＿ｂｉｔｓ＿ｍａｓｋフィールドを特定することができる。新しいスクランブルシーケンスが適用されるたびに、攻撃者は１６秒間を使用してｅｎｃｒｙｐｔｅｄ＿ｂｉｔｓ＿ｍａｓｋフィールドを取得し、それを使用してデバイスを識別／追跡する。
【0112】
ある追加の問題（問題２．４）では、問題１．２と同様に、Ｅｎｃｒｙｐｔｅｄ＿ｂｉｔｓ＿ｍａｓｋが何であるかが指定されていない。
【0113】
ある追加の問題（問題２．５）では、スクランブルシーケンスは、ＤＵＳＫと、１６秒ごとにのみ変更されるＵＴＣカウンタとにのみ依存する。ＤＵＳＫは複数のデバイスで共有される可能性がある。したがって、次のようなことが起こる可能性がある。１）２つの異なるディスカバリメッセージをスクランブルするために、あるデバイスによって、同じ疑似乱数列が使用される、または２）２つ以上の異なるディスカバリメッセージをスクランブルするために、２つ以上のデバイスによって、同じ疑似乱数列が使用される。これが発生した場合、スクランブルされたメッセージのＸＯＲ演算を行うことで、平文メッセージのＸＯＲを取得することができる。これが発生するとセキュリティ保護が失われる。
【0114】
ＤＣＲメッセージの保護を改善する実施形態
したがって、本発明の第１の実施形態の目的は、ｅｎｃｒｙｐｔｅｄ＿ｂｉｔｓ＿ｍａｓｋを生成する方法を設計することである。第１の実施例では、ｅｎｃｒｙｐｔｅｄ＿ｂｉｔｓ＿ｍａｓｋは、ビットが暗号化されるべき場合にはビットを１に設定し、ビットが暗号化されるべきではない場合には０に設定されるように定義されてもよい。この定義を使用すると、送信時のメッセージの処理は次のように変更すると機能することができる。
したがって、本発明の第１の実施形態の目的は、ｅｎｃｒｙｐｔｅｄ＿ｂｉｔｓ＿ｍａｓｋを生成する方法を設計することである。第１の実施例では、ｅｎｃｒｙｐｔｅｄ＿ｂｉｔｓ＿ｍａｓｋは、ビットが暗号化されるべき場合にはビットを１に設定し、ビットが暗号化されるべきではない場合には０に設定されるように定義されてもよい。この定義を使用すると、送信時のメッセージの処理は次のように変更すると機能することができる。
【0115】
ＴＳ３３．３０３、セクション６．１．３．４．３．３のステップ１ではスクランブルを解除する必要があり、ステップ２では、暗号化されていないビットが照合され、ステップ３では、ＤＵＣＫが受信された場合は機密性が解除され、ステップ４では完全照合が実行され、ステップ５では、ディスカバリフィルタセキュリティパラメータに基づきＤＵＩＫである場合はＭＩＣがチェックされるか、またはディスカバリフィルタセキュリティパラメータ内に示されている場合は照合レポートを介してＭＩＣがチェックされる。
【0116】
このような機密性アルゴリズムは次のようなものであってもよい。
１．ＫＣＭ＝（ＥＢＭ ＸＯＲ ０ｘＦＦ・・・ＦＦ）｜｜０ｘＦＦＦＦＦＦＦＦを計算する
２．ＫＳ＝ＫＤＦ（ＤＵＣＫ，ＵＴＣベースのカウンタ，（ＫＣＭ ＡＮＤ （メッセージ｜｜ＭＩＣ）））を計算する。
３．Ｃ＝メッセージ ＸＯＲ （ＫＳ ＡＮＤ ＥＢＭ）
１．ＫＣＭ＝（ＥＢＭ ＸＯＲ ０ｘＦＦ・・・ＦＦ）｜｜０ｘＦＦＦＦＦＦＦＦを計算する
２．ＫＳ＝ＫＤＦ（ＤＵＣＫ，ＵＴＣベースのカウンタ，（ＫＣＭ ＡＮＤ （メッセージ｜｜ＭＩＣ）））を計算する。
３．Ｃ＝メッセージ ＸＯＲ （ＫＳ ＡＮＤ ＥＢＭ）
【0117】
例えば、ＫＳが１０１０ １０１０ １０１０ １０１０であり、ＥＢＭ１１１１ １１１１ ００００ ００００であると仮定すると、ＫＳ ＡＮＤ ＥＢＭ＝１０１０ １０１０ ００００ ００００となる。その場合、メッセージ ＸＯＲ １０１０ １０１０ ００００ ００００ ｉｆ：
メッセージ＝１１１１ １１１１ １１１１ １１１１＝：０１０１ ０１０１ １１１１ １１１１
メッセージ＝００００ ００００ ００００ ００００＝：１０１０ １０１０ ００００ ００００
メッセージ＝１１１１ １１１１ １１１１ １１１１＝：０１０１ ０１０１ １１１１ １１１１
メッセージ＝００００ ００００ ００００ ００００＝：１０１０ １０１０ ００００ ００００
【0118】
この定義を明示しないと、メッセージの間違った部分が暗号化される可能性があり（これは、セキュリティ上のリスクを生む）、実装が相互運用できなくなる可能性がある。先に紹介した提案は、次のように定義することによって改善され得る。上記暗号化アルゴリズムにおいて、ｋｅｙ＿ｃａｌｃ＿ｍａｓｋがＫｅｙ＿ｃａｌｃ＿ｍａｓｋ＝（Ｅｎｃｒｙｐｔｅｄ＿ｂｉｔｓ＿ｍａｓｋ ＸＯＲ ０ｘＦＦ・・・ＦＦ）として計算されるべきであり、ここで、０ｘＦＦ・・・ＦＦはＰＲＵＫ＿ＩＤとＲＳＣとの連結と同じ長さを有する。
【0119】
さらなる実施形態では、ＤＣＲをプライバシー保護するための提案されたソリューションはＭＩＣを含まないので、０ｘＦＦＦＦＦＦＦＦの連結は必要ない。実際、０ｘＦＦＦＦＦＦＦＦが連結される場合、提案されたアルゴリズム内の以下のステップ、
鍵ストリーム＝ＫＤＦ（ＤＵＣＫ，ＵＴＣベースのカウンタ，（Ｋｅｙ＿ｃａｌｃ＿ｍａｓｋ ＡＮＤ メッセージ））
は、ｋｅｙ＿ｃａｌｃ＿ｍａｓｋはメッセージより４バイト長いことから、相互運用可能に機能しない可能性がある。
鍵ストリーム＝ＫＤＦ（ＤＵＣＫ，ＵＴＣベースのカウンタ，（Ｋｅｙ＿ｃａｌｃ＿ｍａｓｋ ＡＮＤ メッセージ））
は、ｋｅｙ＿ｃａｌｃ＿ｍａｓｋはメッセージより４バイト長いことから、相互運用可能に機能しない可能性がある。
【0120】
あるいは、ＰＲＵＫ＿ＩＤおよびＲＳＣの両方を暗号化することを目的としている場合、暗号化ルーチンを次のように定義され得る。
１．メッセージ＝ＲＳＣ（ユーザが中継のために必要としているサービスのリレーサービスコードタイプ）｜｜ＰＲＵＫ ＩＤ（ＰＣ５インターフェースに使用される鍵識別子）
２．鍵ストリーム＝ＫＤＦ（ＤＵＣＫ，ＵＴＣベースのカウンタ，メッセージ）を計算する。
３．暗号文＝メッセージ ＸＯＲ 鍵ストリーム。
１．メッセージ＝ＲＳＣ（ユーザが中継のために必要としているサービスのリレーサービスコードタイプ）｜｜ＰＲＵＫ ＩＤ（ＰＣ５インターフェースに使用される鍵識別子）
２．鍵ストリーム＝ＫＤＦ（ＤＵＣＫ，ＵＴＣベースのカウンタ，メッセージ）を計算する。
３．暗号文＝メッセージ ＸＯＲ 鍵ストリーム。
【0121】
より一般的には、この実施形態では、通信システムの動作方法が提案され、この通信方法は、
ａ．ユーザが中継に必要とするサービスのタイプを示す中継サービスコードと、中継局との通信に使用されるべき通信鍵または通信鍵の指標との組み合わせを含むメッセージを第１の局が準備するステップと、
ｂ．少なくとも機密性鍵およびフレッシュネス値に鍵導出関数を適用することによって、第１の局が鍵ストリームを生成するステップと、
ｃ．第１の局が鍵ストリームを使用してメッセージを暗号化するステップと、を含む。
ａ．ユーザが中継に必要とするサービスのタイプを示す中継サービスコードと、中継局との通信に使用されるべき通信鍵または通信鍵の指標との組み合わせを含むメッセージを第１の局が準備するステップと、
ｂ．少なくとも機密性鍵およびフレッシュネス値に鍵導出関数を適用することによって、第１の局が鍵ストリームを生成するステップと、
ｃ．第１の局が鍵ストリームを使用してメッセージを暗号化するステップと、を含む。
【0122】
別の選択肢では、鍵ストリームがＫＤＦ（ＤＵＣＫ、ＵＴＣベースのカウンタ）として計算されるが、ＫＤＦで使用される文字列Ｓが次のパラメータの連結である。
ＦＣ＝０ｘＸＸ
Ｐ０＝ＵＴＣベースのカウンタ
Ｌ０＝上記の長さ（すなわち、０ｘ００ ０ｘ０４）。
Ｐ１＝メッセージ
Ｌ１＝ＰＲＵＫ＿ＩＤおよびＲＳＣの長さ。
ＦＣ＝０ｘＸＸ
Ｐ０＝ＵＴＣベースのカウンタ
Ｌ０＝上記の長さ（すなわち、０ｘ００ ０ｘ０４）。
Ｐ１＝メッセージ
Ｌ１＝ＰＲＵＫ＿ＩＤおよびＲＳＣの長さ。
【0123】
鍵ストリームはＫＤＦの出力のＬ個のＬＳＢであり、ここで、ＬはＬ１に等しい。この定義により、Ｋｅｙ＿ｃａｌｃ＿ｍａｓｋの計算が回避され、暗号化に使用される鍵ストリーム値の計算が簡略化される。
【0124】
ＤＣＲメッセージを送信する際には完全性保護が推奨される。その目的は、（１）攻撃者が暗号化された内容を変更するのを防ぐため、（２）攻撃者が後の時点でＤＣＲメッセージ／ＰＲＵＫ＿ＩＤおよびＲＳＣ値を再生することを防ぐため、または（３）攻撃者がＤＣＲメッセージ／ＰＲＵＫ＿ＩＤおよびＲＳＣの値を別のリレーＵＥにリプレイすることを防ぐためである。
【0125】
完全性保護が必要な場合は、ＭＩＣを計算するために完全性鍵が必要である。しかし、ＤＵＳＫやＤＵＣＫとは異なり、ＤＵＩＫは常に利用できるとは限らない。ＭＩＣを計算するための適切な完全性鍵を取得し、以前に提案されたスキームを強化するには複数の選択肢が存在する。
【0126】
第１の選択肢Ａ）では、リモートＵＥおよびリレーＵＥの両方が利用可能な鍵（例えば、ＤＵＣＫまたはＤＵＳＫ）をマスター鍵として、ＫＤＦと組み合わせてとして使用し、完全性鍵および機密性鍵の２つの鍵が導出される。
【0127】
第２の選択肢Ｂ）では、ＤＣＲメッセージの完全性保護に使用される追加の鍵によって、ディスカバリ鍵が強化される。この追加の鍵はＤＵＩ＿ＤＣＲ＿Ｋと示される。
【0128】
第３の選択肢Ｃ）では、既存のディスカバリ鍵（ＤＵＩＫ、ＤＵＣＫ、ＤＵＳＫ）を生成するために使用されるマスター鍵が、ＫＤＦを用いてＤＵＩ＿ＤＣＲ＿Ｋを生成する際にも使用される。
【0129】
これらの選択肢では、ＫＤＦが適用される場合、ＴＳ３３．２２０で定義されている３ＧＰＰ（登録商標） ＫＤＦを使用できる。
【0130】
この定義によれば、ＫＤＦは、マスター鍵と、一意のビット列Ｓとを入力として受け取る。例えば、ＤＵＣＫがマスター鍵として使用される場合、完全性鍵の生成に使用されるビット列Ｓは、派生鍵の目的（例えば、ＰＲＵＫ ＩＤ｜ＲＳＣの機密性保護またはＰＲＵＫ ＩＤ｜ＲＳＣの完全性保護）に関連付けられた一意の識別子ＦＣ、鍵の使用法を以前に送信されたディスカバリメッセージにリンクする情報（例えば、ＤＵＣＫ、ＵＴＣベースのカウンタとともにディスカバリメッセージを保護するために使用される鍵ストリーム）を含み得る。
【0131】
選択肢Ｃ）では、ＤＵＩ＿ＤＣＲ＿Ｋに関連付けられた新しいＰ０値、例えば０ｘ０３を使用して、ＴＳ３３．３０３のＡ．８のようにＤＵＩ＿ＤＣＲ＿Ｋが生成され得る。
【0132】
ＤＣＲメッセージのＭＩＣが計算される場合、ＰＲＵＫ＿ＩＤおよびＲＳＣ、並びに、メッセージの送信元または宛先を決定するフィールドなどの他のフィールドを保護することは有意義である。ＭＩＣの計算では、リプレイ攻撃を回避するためにＵＴＣベースのカウンタを入力とする可能性がある。ＭＩＣの計算は、時間ベースのカウンタを必要とせずにリプレイ保護を実現するために、ディスカバリフェーズ中にリレーＵＥが先に送信したノンスも含み得る。
【0133】
ＤＣＲメッセージの機密性および完全性が保護されている場合、セキュリティルーチンは次のようになる。
【表5】
【0134】
ステップ２では、ＴＳ３３．３０３のＡ．２と同様のＭＩＣ計算ルーチンを使用できるが、ここでは、ＤＵＩＫの代わりにＤＵＩ＿ＤＣＲ＿Ｋが使用される。Ｐ０およびＰ１の値は、ＰＲＵＫ＿ＩＤおよびＲＳＣを含むＤＣＲメッセージであることを示す必要がある。なお、ＭＩＣは、保護する必要があるＤＣＲメッセージの他の部分も含めて計算されてもよい。例えば、アドレス指定されたリレーＵＥのＩＤ。これにより、攻撃者がリレーの近くにある他のＵＥにメッセージをリプレイすることを防ぐことができる。
【0135】
ステップ３では、メッセージおよびＭＩＣの両方が暗号化されていると仮定されている。メッセージのみが暗号化されており、ＭＩＣは暗号化されていない場合は、マスクまたはビットを連結することでこれが示され得る。
【0136】
ステップ４では、メッセージおよびＭＩＣの両方が暗号化されていると仮定されている。ＭＩＣが暗号化されていない場合、ＸＯＲはメッセージ部分に対してのみ実行されるべきである。
【0137】
なお、ＲＳＣおよびＰＲＵＫ＿ＩＤがＭＩＣを用いて完全性保護されていない場合でも、ある種の完全性保護は実現できる可能性があることに留意されたい。なぜなら、攻撃者が暗号化されたメッセージを変更した場合（例えば、暗号化された ＰＲＵＫ＿ＩＤまたはＲＳＣフィールド内のビットを反転することによって）、結果として、異なるＰＲＵＫ＿ＩＤおよびＲＳＣになるからである。リレーＵＥはそのような変更されたＲＳＣに対応できない可能性がある。したがって、以前の提案のようにＭＩＣが利用できない／計算されない場合には、リレーＵＥが暗号化されたフィールドを復号し、受信したフィールドが期待された通りである（例えば、以前のディスカバリフェーズにおいてもネゴシエーションされたＲＳＣ値が存在する）か、またはサポートされた通りである（例えば、サポートされているＲＳＣ値）かをチェックすることが推奨される。
【0138】
暗号化またはスクランブルアルゴリズムと呼ばれる異なるアルゴリズムの使用に起因したさらなる複雑さの問題に対処するさらなる実施形態では、ＤＵＳＫもしくはＤＵＣＫまたはこれらの組み合わせが、同じアルゴリズムを使用してＤＣＲメッセージの機密性を保護するために使用される。特に、アルゴリズムは、例えば、ＴＲ３３．８４７の暗号化アルゴリズムであってもよい。
【0139】
さらなる実施形態は、デバイスが複数の鍵を用いた複数の設定を有する場合に、どの鍵／アルゴリズムを使用すべきかが不明確である問題に対処する。
【0140】
この問題を対象としたさらなる実施形態は、所定の優先順序に従って使用する鍵を選択することからなり、例えば、ＤＵＣＫが利用可能な場合は最初にＤＵＣＫで試し、その後、ＤＵＳＫが利用可能な場合はＤＵＳＫで試す。これは、例えば、ＴＲ３３．８４７においてのようにそれぞれの暗号化およびスクランブルアルゴリズムを使用するか、または上記実施形態で提案されているように、選択された鍵を単一のアルゴリズムにおいて使用して実行され得る。
【0141】
別のアプローチは、両方の鍵が使用可能な場合、両方の鍵の組み合わせを適用することにある。これは、例えば、（ｉ）最初に両方の鍵に依存する鍵を導出し、次に結果として得られた鍵を暗号化アルゴリズムで使用することによって、または（ｉｉ）両方の鍵をＫＤＦの入力として使用することで、ＤＵＳＫおよびＤＵＣＫの両方を疑似乱数列の生成に使用することによって実行され得る。
【0142】
別のアプローチは、リモートＵＥがＤＵＣＫまたはＤＵＳＫを選択し、例えば０（ＤＵＳＫ）または１（ＤＵＣＫ）に設定されたビットを含めることによって、それを中継ＵＥに伝えることにある。
【0143】
別のアプローチは、リレーＵＥが両方の鍵を使用してＤＣＲメッセージを復号することを試みることにある。
【0144】
複数組のディスカバリ鍵のセットが存在する可能性がある問題に対処する追加の実施形態は次の通りである。
【0145】
第一に、リモートＵＥは、リレーＵＥがディスカバリ鍵の正しいセットを識別することを可能にするフィールドをＤＣＲメッセージ内に追加し得る。このフィールドはＰＤＳＫ ＩＤであってもよい。
【0146】
第二に、上記と同様であるが、ＰＤＳＫ ＩＤ全体を交換するとプライバシーの問題が生じる可能性があるため、リモートＵＥは、ＰＤＳＫ ＩＤのサブセット、例えば、中継ＵＥが正しいセットを取得することを可能にする最下位ビットを送信してもよい。
【0147】
第三に、リレーＵＥは、最後に配信されたディスカバリメッセージと、それらを保護するために使用された鍵のセットとを追跡してもよい。特に、リレーＵＥは鍵のリストをＦＩＦＯモードで保持することができ、すなわち、鍵の最後の使用に従って挿入および使用することができる。ディスカバリフェーズで異なるディスカバリＤＵＳＫ鍵またはＤＵＣＫ鍵が使用されるたびに、その鍵はリストの先頭に配置され、既存の鍵はリスト内で押し下げられる。リレーＵＥがＤＣＲメッセージを受信すると、リレーＵＥは、前のリストの先頭にあるディスカバリ鍵から復号を試みる。
【0148】
ＤＵＣＫが複数のＲＳＣと組み合わせて使用されるという問題は、リモートＵＥが、リレーＵＥが正しいＲＳＣを識別することを可能にするフィールドをＤＣＲメッセージに追加できる実施形態によって解決することができる。このフィールドは、ＲＳＣのサブセット、例えば、最下位ビット、またはどのＲＳＣが使用されるかを示すインデックスであってもよい。例えば、ＤＵＣＫが３つのＲＳＣ、すなわちＲＳＣ１、ＲＳＣ２、およびＲＳＣ３に関連付けられており、ＲＳＣ１＜ＲＳＣ２＜ＲＳＣ３である場合、ＲＳＣｉはインデックスｉにリンクされ得、ｉ＝１、２、３である。
【0149】
ＤＵＣＫが複数のＲＳＣと組み合わせて使用されるという問題は、最後に配信されたディスカバリメッセージおよび関連付けられたＲＳＣをリレーＵＥが追跡できる追加の実施形態によって、解決することができる。特に、リレーＵＥはＲＳＣのリストをＦＩＦＯモードで保持することができ、すなわち、ＲＳＣの最後の使用に従って挿入および使用することができる。ディスカバリフェーズで異なるＲＳＣがアナウンスされるたびに、そのＲＳＣはリストの先頭に配置され、既存のＲＳＣはリスト内で押し下げられる。リレーＵＥがＤＣＲメッセージを受信すると、リレーＵＥは、前のリストの先頭にあるＲＳＣから復号を試みる。
【0150】
ＴＳ３３．３０３と同様、復号アルゴリズムは暗号化で行われる演算の逆を実行し、すなわち、同じ疑似乱数列を計算した後、受信した暗号文を、計算された疑似乱数列とＸＯＲ演算することによって平文を取得する。
【0151】
上記実施形態に基づいて、リモートＵＥとリレーＵＥとの間のＤＣＲメッセージを保護するための手順の具体的な実装は以下の通りであり得る。
【0152】
この例では、リモートＵＥは以下を実行する。
【表6】
【0153】
その後、リモートＵＥは、ＤＣＲメッセージの一部として暗号文をＵＥからネットワークへのリレーに送信することができる。
【0154】
受信側では、ＵＥからネットワークへのリレーは、受信したＤＣＲメッセージの保護されたフィールド（例えば、ＲＳＣおよびＰＲＵＫ ＩＤ）を取得するために以下を実行し得る。
【表7】
【0155】
ＭＩＣを計算するとき、ＴＳ３３．２２０の付録Ｂに記載されているＫＤＦへの入力Ｓを形成するために次のパラメータが使用され得る。
－ ＦＣ＝０ｘＹＹ。
－ Ｐ０＝メッセージタイプ。
－ Ｌ０＝上記の長さ（すなわち、０ｘ００ ０ｘ０１）。
－ Ｐ１＝完全性保護が必要なメッセージフィールド。
－ Ｌ１＝上記の長さ。
－ Ｐ２＝ＵＴＣベースのカウンタ。
－ Ｌ２＝上記の長さ（すなわち、０ｘ００ ０ｘ０４）。
－ ＦＣ＝０ｘＹＹ。
－ Ｐ０＝メッセージタイプ。
－ Ｌ０＝上記の長さ（すなわち、０ｘ００ ０ｘ０１）。
－ Ｐ１＝完全性保護が必要なメッセージフィールド。
－ Ｌ１＝上記の長さ。
－ Ｐ２＝ＵＴＣベースのカウンタ。
－ Ｌ２＝上記の長さ（すなわち、０ｘ００ ０ｘ０４）。
【0156】
ＭＩＣ計算のための入力鍵は、ステップ１で選択された２５６ビットの鍵であってもよいし、先行する実施形態で説明したようにして導出された完全性鍵であってもよい。ＭＩＣは、ＫＤＦの出力の最下位ｘビットに設定され、例えば、ｘは３２ビットであってもよい。ＤＣＲメッセージ保護のための完全性（および機密性）ＫＤＦで使用されるＦＣ値は、ディスカバリメッセージ保護に使用されるＦＣ値とは異なるものでなければならない。メッセージタイプ識別子は、交換されるメッセージを識別する必要がある。例えば、ＴＳ２４．５５４の項１１．３．１にあるメッセージタイプを伝達するＰｒｏＳｅ ＰＣ５に類似したものであってもよい。完全性保護を必要とするメッセージフィールド（Ｐ１）および長さ（Ｌ１）は少なくともＲＳＣおよびＰＲＵＫ ＩＤであるが、他のフィールド（例えば、ＰｒｏＳｅ識別子、ソースユーザ情報、ＵＥセキュリティ機能）も完全性保護を必要とする可能性がある。ＤＣＲメッセージ内で交換されるパラメータは、ＰＲＯＳＥ ＤＩＲＥＣＴ ＬＩＮＫ ＥＳＴＡＢＬＩＳＨＭＥＮＴ ＲＥＱＵＥＳＴメッセージＩＤ、シーケンス番号、ＰｒｏＳｅ識別子、ソースユーザ情報、ＵＥセキュリティ機能、ＵＥ ＰＣ５ユニキャストシグナリングセキュリティポリシー、鍵確立情報コンテナ、Ｎｏｎｃｅ＿１、ＫＮＲＰセッションＩＤのＭＳＢ、ターゲットユーザ情報、ＫＮＲＰ ＩＤ、中継サービスコードを含み得る。
【0157】
メッセージ固有機密性を計算するとき、ＫＤＦへの入力Ｓを形成する次のパラメータが使用され得る。
－ ＦＣ＝０ｘＸＸ
－ Ｐ０＝ＵＴＣベースのカウンタ
－ Ｌ０＝上記の長さ（すなわち、０ｘ００ ０ｘ０４）。
－ Ｐ１＝ＲＳＣ
－ Ｌ１＝上記の長さ。
－ ＦＣ＝０ｘＸＸ
－ Ｐ０＝ＵＴＣベースのカウンタ
－ Ｌ０＝上記の長さ（すなわち、０ｘ００ ０ｘ０４）。
－ Ｐ１＝ＲＳＣ
－ Ｌ１＝上記の長さ。
【0158】
入力鍵は、ステップ１で選択した２５６ビットの鍵であってもよい。メッセージ固有機密性鍵ストリームは、ＫＤＦ出力のＬ個の最下位ビットに設定され、ここでＬは、保護を必要とするフィールド（上記のように、ＲＳＣおよびＰＲＵＫ ＩＤ）およびＭＩＣの長さである。ＴＳ２４．５５４の項１０．３．１．１は、ＰＲＯＳＥ ＤＩＲＥＣＴ ＬＩＮＫ ＥＳＴＡＢＬＩＳＨＭＥＮＴ ＲＥＱＵＥＳＴについて説明しており、ＰＲＵＫ ＩＤおよびＲＳＣに加えて、保護を必要とする可能性のあるいくつかのフィールド（例えば、ユーザ情報）の交換が要求している。フィールドの長さが３２バイトより長い場合、暗号化は、ＫＤＦへの複数の呼び出しを必要とする鍵ストリームに依拠する可能性がある。これは、Ｓビット列の定義内に追加の入力としてカウンタを含め、カウンタを増加させて鍵ストリームの追加バイトを生成することによって実行され得る。
【0159】
なお、場合によっては、ＲＳＣが利用できない可能性がある。例えば、この技術が、ＵＥからネットワークへのリレーではないリレーのユースケースに適用される場合である。このような場合、上記手順内の鍵ストリームの計算において、Ｓの入力パラメータとしてＲＳＣを使用することができない。この場合、このフィールドは省略される可能性があり、すなわち、鍵ストリーム＝ＫＤＦＤＣＲ＿Ｃｏｎｆｉｄｅｎｔｉａｌｉｔｙ（Ｋ，ＵＴＣベースのカウンタ）。あるいは、例えば、発見されたアプリケーションのタイプを識別する他の入力パラメータによって、ＲＳＣが置き換えられてもよい。
【0160】
なお、上記手順１のステップ１は、リモートＵＥとリレーＵＥにＤＵＣＫとＤＵＳＫの両方が設定されている場合にどの鍵／アルゴリズムを使用するかを決定する方法を示している。
【0161】
上記手順は、発見中にどの鍵が設定されたかにかかわらず、同じ機密性アプローチを適用する方法を示している。わずかに異なるフレーバーを有することでコードの複雑さが増す。また、ディスカバリメッセージの保護では、機密性およびスクランブルに異なるルーチンを使用することで様々なアプリケーションのニーズを満たすことができるが、ディスカバリメッセージの保護とは対照的に、ＤＣＲメッセージフィールドの保護の場合はこれが必要ない。
【0162】
上記手順では、交換されるメッセージの完全性をチェックするためにＭＩＣが使用されることに留意されたい。ＭＩＣを用いた完全性のチェックが必要ない場合、ＲＳＣの完全性のみがチェックされる簡略化されたバージョンは次の通りである。
リモートＵＥは以下を実行する。
リモートＵＥは以下を実行する。
【表8】
【0163】
ＵＥからネットワークへのリレーは、受信したＤＣＲメッセージの保護されたフィールド（例えば、ＲＳＣおよびＰＲＵＫ ＩＤ）を取得するために以下を実行する。
【表9】
【0164】
上記アルゴリズムでは、鍵ストリームはＮＥＡアルゴリズムを使用して生成され得、ＭＩＣはＮＩＡアルゴリズムを使用して生成され得ることに留意されたい。
【0165】
特に、ＤＣＲメッセージを保護するために使用されるＮＥＡアルゴリズムおよびＮＩＡアルゴリズムは次の通りであってもよい。
・発見中に合意された、または
・ディスカバリパラメータの設定中、ＵＥの設定中に事前設定された、または
・ＤＣＲメッセージ自体の中に示されている。
・発見中に合意された、または
・ディスカバリパラメータの設定中、ＵＥの設定中に事前設定された、または
・ＤＣＲメッセージ自体の中に示されている。
【0166】
１２８－ＮＥＡアルゴリズムが使用される場合、ＮＥＡアルゴリズムは、ＮＥＡアルゴリズムの入力鍵としてＤＵＣＫ（またはＤＵＳＫ）の１２８ビットを使用することによって設定されてもよい。ＮＥＡアルゴリズムにおける３２ビットカウントがＵＴＣベースのカウンタに設定されてもよく、ＢＥＡＲＥＲは、所定のバイナリ値（例えば、ＢＥＡＲＥＲ＝００００）に設定されてもよく、ＤＩＲＥＣＴＩＯＮは、所定の値（例えば、ＤＩＲＥＣＴＩＯＮ＝０）に設定されてもよい。鍵ストリームが、ディスカバリメッセージの保護、特に、ＮＥＡアルゴリズムにも依拠する可能性があるメタデータを用いたディスカバリメッセージの保護に使用される鍵ストリームと異なることを保証するには、上記パラメータの一部が異なる設定を有する必要がある可能性があり、例えば、鍵がディスカバリメッセージの保護に使用される場合は第１のＢＥＡＲＥＲ値を使用する必要があり、鍵がＤＣＲメッセージの保護に使用される場合は第２の異なるＢＥＡＲＥＲ値を使用する必要がある。
【0167】
あるいは、ＮＥＡアルゴリズムにおける鍵は、上記手順のステップ１で選択された鍵ＫにＫＤＦを適用し、ディスカバリメッセージおよびＤＣＲメッセージの保護に異なるＦＣ値を使用することによって生成され得る。これにより、ＤＣＲメッセージを保護する場合と、ディスカバリメッセージを保護する場合とで２つの異なる鍵が使用されることが保証される。ＫＤＦはまた、追加の入力として、ＵＴＣベースのカウンタまたはＤＣＲメッセージ内の他の保護されていないフィールドを有し得る。
【0168】
ＮＩＡアルゴリズムも同様に設定されてもよい。別の完全性鍵がＫＤＦを使用して導出される場合、別のＦＣ値も必要となる。
【0169】
上記手順は、ＵＥからネットワークへのリレーにおけるＰＣ５リンクセットアップ中のセキュリティを向上させるためだけでなく、他のタイプのＰＣ５セットアップにも適用され得ることに留意されたい。例えば、ＵＥからＵＥへのリレー、またはＵＥからＵＥへのリレーである。
【0170】
例えば、ＵＥからＵＥへのリレーシナリオにおける（安全な）ＰＣ５通信リンクの確立に関して、発見時に、ＵＥ、例えばソースＵＥは、ＲＳＣ、ＰＲＵＫ ＩＤ、または後続の鍵導出に使用される第１のノンスなどの特定のパラメータを含む直接通信リクエスト（ＤＣＲ）メッセージを送信する。この情報は、上記実施形態のうちの１つのようなソリューションが適用されない限り、平文で交換される可能性がある。この手順および必要性は、ＵＥからＵＥへのリレー４１０を介してターゲットＵＥ４３０との安全な通信リンクを確立することを望んでいるソースＵＥ４２０によってさらに示されている。ＣＮ、またはＣＮ４００内の１つ以上のネットワーク機能が設定を実行する。第１のステップでは、各リモートＵＥ（ソースＵＥおよびターゲットＵＥ）およびＵＥからＵＥへのリレーが、５Ｇ ＤＤＮＭＦから発見パラメータおよびＰＫＭＦ（Ｐｒｏｓｅ Ｋｅｙ Ｍａｎａｇｅｍｅｎｔ Ｆｕｎｃｔｉｏｎ）アドレスを、ＰＫＭＦからディスカバリセキュリティマテリアルを取得する。さらに、ＰＫＭＦによるエンドツーエンドセキュリティセットアップのためのセキュリティマテリアルがリモートＵＥに提供されてもよい。例えば、エンドツーエンドセキュリティセットアップ用のセキュリティマテリアルは、ＰＳＣ（Ｐｒｏｓｅ Ｓｅｒｖｉｃｅ Ｃｏｄｅ）および関連付けられた鍵を含む。次のステップでは、リモートＵＥ４２０は、（ｉ）Ｕ２Ｕリレーを発見し、（ｉｉ）ＲＳＣ（Ｒｅｌａｙ Ｓｅｒｖｉｃｅ Ｃｏｄｅ）、ＰＲＵＫ ＩＤ、およびＮｏｎｃｅ１を含む直接通信リクエストを送信し、（ｉｉｉ）リモートＵＥ４２０とＵＥからＵＥへのリレー４１０との間で認証および鍵合意を実行し、認証が成功した結果、鍵ＫＮＲＰが導出されることによって、ＵＥからＵＥへのリレー４１０と、発見手順およびＰＣ５ユニキャストリンクセットアップ手順とを実行する。その後、ＵＥからＵＥへのリレー４１０はＮｏｎｃｅ２を生成し、ＫＮＲＰ、Ｎｏｎｃｅ１、およびＮｏｎｃｅ２を使用してＫＮＲＰ－ＳＥＳＳを導出する。ＵＥからＵＥへのリレー４１０は、ナンス２を含む触接セキュリティモードコマンドをリモートＵＥ４２０に送信する。直接セキュリティモードコマンドは、ＫＮＲＰ－ＳＥＳＳに基づいて完全性が保護される。次に、リモートＵＥ４１０は、ＫＮＲＰ、Ｎｏｎｃｅ１、およびＮｏｎｃｅ２を使用してＫＮＲＰ－ＳＥＳＳを導出し、直接セキュリティモードコマンドの完全性をチェックする。検証が成功した場合、リモートＵＥ４２０は、直接セキュリティモード完了をＵＥからＵＥへのリレー４１０に送信する。プライバシーセンシティブな特定のフィールド、またはＵＥからＵＥへのリレー中のＤＣＲメッセージ交換における全てのフィールドを保護するには、例えば、上記の例示的な手順で詳述したように、発見パラメータ内の鍵のうちの１つは、送信デバイスおよび受信デバイスによって選択される必要があり、例えば、
・ＤＵＣＫが利用可能な場合、プライバシーセンシティブなフィールドを保護するためにＤＵＣＫが使用され、
・ＤＵＣＫが利用可能でなく、かつＤＵＳＫが利用可能な場合、ＤＵＳＫがそれらを保護するために使用され、そうでなく、
・ＤＵＣＫもＤＵＳＫも利用できない場合、プライバシーセンシティブなフィールド、またはＤＣＲメッセージ内の全てのフィールドを保護してはならない。
・ＤＵＣＫが利用可能な場合、プライバシーセンシティブなフィールドを保護するためにＤＵＣＫが使用され、
・ＤＵＣＫが利用可能でなく、かつＤＵＳＫが利用可能な場合、ＤＵＳＫがそれらを保護するために使用され、そうでなく、
・ＤＵＣＫもＤＵＳＫも利用できない場合、プライバシーセンシティブなフィールド、またはＤＣＲメッセージ内の全てのフィールドを保護してはならない。
【0171】
鍵が選択されると（選択された場合）、送信デバイスはＤＣＲメッセージを保護し、保護されたＤＣＲメッセージを送信できる。鍵が選択されると（選択された場合）、受信デバイスは保護されたＤＣＲメッセージを受信し、それを安全に処理（復号／完全性検証）できる。ソースＵＥおよびターゲットＵＥが、リレーに知られていない共通のディスカバリ鍵のセットを有する場合、この鍵のセットの方が好ましい可能性があることに留意されたい。
【0172】
ＴＳ３３．３０３のディスカバリメッセージ用のセキュリティルーチンの改善
ＴＳ３３．３０３のディスカバリメッセージ用のセキュリティルーチンを改善する実施形態のセットでは、アプローチ１では、暗号化に使用される鍵ストリーム（ＫＳ）を取得するロジックが、次の選択肢のうちのいずれかに従って変更される。
ＴＳ３３．３０３のディスカバリメッセージ用のセキュリティルーチンを改善する実施形態のセットでは、アプローチ１では、暗号化に使用される鍵ストリーム（ＫＳ）を取得するロジックが、次の選択肢のうちのいずれかに従って変更される。
【0173】
第１の選択肢１では、ＫＣＭ＝（ＥＢＭ ＸＯＲ ０ｘＦＦ・・・ＦＦ）を計算し、ここで、０ｘＦＦ・・・ＦＦは２７オクテットの長さを有する。ＥＢＭ ＸＯＲ ０ｘＦＦ・・・ＦＦ＝ＢＩＴＷＩＳＥＮＯＴ（ＥＢＭ）＝ＫＣＭであることに留意されたい。次に、ＫＳ＝ＫＤＦ（ＤＵＣＫ，ＵＴＣベースのカウンタ，（ＫＣＭ ＡＮＤ（メッセージ｜｜ＭＩＣ）））を計算する。ここで、ＫＳはＫＤＦ出力の最後の２７オクテットである。ここで、ＥＢＭはｅｎｃｒｙｐｔｉｏｎ＿ｂｉｔ＿ｍａｓｋであり、ＫＣＭはｋｅｙ＿ｃａｌｃ＿ｍａｓｋであり、ＫＳは鍵ストリームである。それでも、この選択肢の問題は、ＭＩＣがＫＣＭとＡＮＤ演算されること、および、ＥＢＭの最後の４バイトが全て１になるので、ＫＣＭの最後の４つのバイトが０に設定されることから、ＫＳの計算においてＭＩＣの内容が無視されることである。
【0174】
選択肢１に基づいて構築される第２の選択肢２では、ＫＣＭが直接与えられ、すなわち、ＥＢＭが必要なくなる。この選択肢は、選択肢１と同じ問題を有する。
【0175】
選択肢１および選択肢２の問題に対処する第３の選択肢３では、ＫＳ＝ＫＤＦ（ＤＵＣＫ，ＵＴＣベースのカウンタ，ＥＢＭ，メッセージ｜｜ＭＩＣ）が計算される。それでも、このアプローチの問題は、ＫＤＦへの合計入力サイズが３２＋４＋２７＋２７バイト、すなわち２＊３２バイトを超えるため、ＫＤＦの計算により多くのＣＰＵリソースが必要になることである。
【0176】
第４の選択肢４では、ＫＳがＫＤＦ（ＤＵＣＫ，ＵＴＣベースのカウンタ，ＥＢＭ，ＭＩＣ）として計算される。このアプローチでは、送信されるメッセージのフィンガープリントとして、ＭＩＣが使用される。ＥＢＭはＫＳの計算に含まれる。これにより、暗号化マスクおよびメッセージの内容自体の両方がＫＳを決定する。合計メッセージ長さは２＊３２バイト未満であるため、ＣＰＵのニーズが現状より悪化することはない。ＥＭＢが既知または固定である場合、ＥＢＭは必要ない可能性があることに留意されたい。
【0177】
その場合、メッセージを送信する手順は次のように変更され得る。
ステップ１：メッセージおよびＤＵＩＫからＭＩＣを計算する。ＭＩＣは、例えばＴＳ３３．３０３に記載されているように計算される。
ステップ２：送信するメッセージにＭＩＣを追加する。Ｍ＝Ｍ｜｜ＭＩＣ
ステップ３：上記のようにＫＳを計算する。
ステップ４：Ｃ＝Ｍ ＸＯＲ （ＫＳ ＡＮＤ ＥＢＭ）として暗号文を作成する。
ステップ５：Ｃにスクランブルをかける
ステップ１：メッセージおよびＤＵＩＫからＭＩＣを計算する。ＭＩＣは、例えばＴＳ３３．３０３に記載されているように計算される。
ステップ２：送信するメッセージにＭＩＣを追加する。Ｍ＝Ｍ｜｜ＭＩＣ
ステップ３：上記のようにＫＳを計算する。
ステップ４：Ｃ＝Ｍ ＸＯＲ （ＫＳ ＡＮＤ ＥＢＭ）として暗号文を作成する。
ステップ５：Ｃにスクランブルをかける
【0178】
上記は、ＥＢＭがＭＩＣもカバーしているので、ＭＩＣを暗号化できることを意味する。これは、ＴＳ３３．３０３では許可されていないことである。
【0179】
ＥＢＭは０ｘＦＦ・・・ＦＦ（２７オクテット）であることが好ましく、すなわち全てのビットが暗号化されることが好ましいことに留意されたい。この場合、ＤＵＳＫは必要ない。これは、また、Ｅｎｃｒｙｐｔｅｄ＿ｂｉｔｓ＿ｍａｓｋを監視することによってデバイスが完全性保護使用の有無（（ＭＩＣ）を推測できず）を追跡できないため、プライバシーを向上する。メッセージの機密性を保護するためにＫＤＦを１回呼び出すだけで済むため、パフォーマンスも向上する。この場合、この疑似乱数列は、例えばＫＳ＝ＫＤＦ（ＤＵＣＫ，ＵＴＣベースのカウンタ，ＥＢＭ，ＭＩＣ）として計算され、暗号文を計算するためのステップ４は、単にＣ＝Ｍ ＸＯＲ ＫＳである。ステップ５は必要ない。
【0180】
ＴＳ３３．３０３におけるディスカバリメッセージ用のセキュリティルーチンを改善する実施形態では、スクランブルシーケンスが、１６秒に１回よりも頻繁に変化するＵＴＣベースのカウンタを使用して計算される。例えば、８秒ごと、４秒ごと、２秒ごと、１秒である。これにより、スクランブルおよび機密性／完全性において使用されるＵＴＣベースのカウンタの異なる周期によって漏れる情報の量が制限される。
【0181】
ＴＳ３３．３０３のディスカバリメッセージのセキュリティルーチンを改善する実施形態では、完全性が適用されない場合（例えば、ＤＵＩＫが存在しない場合）にＭＩＣ＝０ｘ００００００００を付加する代わりに、乱数に見える値を追加すべきである。この乱数に見える値は、初期乱数値から疑似乱数関数を使用して生成できる。これにより、攻撃者が、ブロードキャストされたディスカバリメッセージを観察することによって、ＵＥが完全性保護を使用しているか否かを判断できないことが保証される。
【0182】
ディスカバリメッセージ用のセキュリティルーチンを改善する実施形態のセットがある。
【0183】
ＴＳ３３．３０３では、ＥＢＭの長さは、２３バイトだけではなく、２７バイトである。その場合、ＴＳ３３．３０３のようにＫＳを計算することができるが、ＫＣＭは（ＥＢＭ［０：２３］ ＸＯＲ ０ｘＦＦ・・・ＦＦ）｜｜０ｘＦＦＦＦＦＦＦＦとして計算される。ここで、ＥＢＭ［０：２３］は、同じく２３バイト長の０ｘＦＦ・・・ＦＦとのＸＯＲ演算時に、ＥＢＭの最初の２３バイトのみが使用されることを示す。ＫＳの出力長は、ＴＳ３３．３０３においてよりも４バイト長く、すなわち２７バイト長であるため、ＭＩＣを暗号化することもできる。
【0184】
その場合、メッセージを送信する手順は次のように変更される。
ステップ１：メッセージおよびＤＵＩＫからＭＩＣを計算する。ＭＩＣは、例えばＴＳ３３．３０３に記載されているように計算される。
ステップ２：送信するメッセージにＭＩＣを追加する。Ｍ＝Ｍ｜｜ＭＩＣ
ステップ３：上記のようにＫＳを計算する。
ステップ４：Ｃ＝Ｍ ＸＯＲ （ＫＳ ＡＮＤ（ＥＢＭ｜｜０ｘＦＦＦＦＦＦＦＦ））として暗号文を作成する。
ステップ５：Ｃにスクランブルをかける
ステップ１：メッセージおよびＤＵＩＫからＭＩＣを計算する。ＭＩＣは、例えばＴＳ３３．３０３に記載されているように計算される。
ステップ２：送信するメッセージにＭＩＣを追加する。Ｍ＝Ｍ｜｜ＭＩＣ
ステップ３：上記のようにＫＳを計算する。
ステップ４：Ｃ＝Ｍ ＸＯＲ （ＫＳ ＡＮＤ（ＥＢＭ｜｜０ｘＦＦＦＦＦＦＦＦ））として暗号文を作成する。
ステップ５：Ｃにスクランブルをかける
【0185】
ステップ４では、ＴＳ３３．３０３と同様にＥＢＭの長さが２３バイトであり、ＭＩＣも暗号化するために０ｘＦＦＦＦＦＦＦＦが付加されることに留意されたい。ステップ３は、ステップ２の前に実行してもよいことに留意されたい。
【0186】
以前の提案に基づく例示的実施形態の変形例では、ＤＣＲメッセージ内のＰＲＵＫ ＩＤおよびＲＳＣを保護する際に疑似乱数スクランブルシーケンスを生成するために使用されるＦＣ値は、ディスカバリメッセージを保護する疑似乱数スクランブルシーケンスを生成するために使用されるＦＣ値とは異なる可能性があることが示唆され得る。これにより、同じ疑似乱数スクランブルシーケンスによって２つの異なる平文メッセージが保護され得る（ＸＯＲスクランブルされ得る）ことを防ぐことができる。同じことが暗号化アルゴリズムで使用されるＦＣ値の使用にも当てはまるが、この場合、ＫＤＦの他の入力パラメータ、特にメッセージの長さが異なるため、これはそれほど重要ではない。
【0187】
ＴＳ３３．３０３において長いディスカバリメッセージを保護するためのセキュリティルーチンの改善
上記実施形態では、保護を必要とするフィールドの長さが、使用されるＫＤＦの出力サイズである３２バイトよりも長い場合でも、ＤＣＲメッセージの機密性を保護する方法を説明した。これは、単一のＫＤＦ呼び出しからではなく、ＫＤＦへの複数回の呼び出しから取得された鍵ストリームを使用してメッセージを暗号化（またはスクランブル）することによって行われる。これは、ＫＤＦにおける入力として使用されるＳビット列の定義内に追加の入力として少なくとも１つのカウンタ（ブロックカウンタ）を含め、カウンタを増加させて鍵ストリームの追加バイトを生成することによって実行され得る。カウンタの代わりにナンスが使用される可能性があることに留意されたい。ナンスは、ランダムに生成され、１回だけ使用される数値である。例えば、メッセージの長さがＮ＊Ｂバイトで、ＢがＫＤＦの出力サイズである場合、ＫＤＦへのＮ回の呼び出しが、それぞれ異なるカウンタ値（例えば、０～Ｎ－１の範囲）で要求される。このようなソリューションは、３２バイトを超える長さを有する可能性があるディスカバリメッセージにも適用可能である。特に、Ｒｅｌ－１７ Ｕ２Ｎサイドリンクリレーでは、サイドリンクディスカバリメッセージのためにＲＬＣ ＵＭモードが使用される可能性があり、ディスカバリメッセージの最大サイズは、例えば９０００バイトであり得る。上記したように、ディスカバリメッセージを保護するためのセキュリティルーチンは、小さい固定サイズのディスカバリメッセージに対してのみ機能することに留意されたい。新しいフィールドまたはアプリケーション層メタデータ情報の交換に起因して、より大きなサイズのディスカバリメッセージが生じる可能性がある。ＲＬＣフラグメンテーションは、２９７６ビット＝３７２バイトで既に発生する可能性がある。この場合、ディスカバリメッセージは３２バイトよりも長くなる可能性があり、ＫＤＦへの複数回の呼び出しが必要になり得る。この場合、ディスカバリメッセージのサイズは２９７６ビットよりも長くなる可能性があり、複数のフラグメントが発生する可能性がある。したがって、ＰＤＣＰ層での（ＤＵＣＫを用いた）暗号化および／または（ＤＵＳＫを用いた）スクランブルのためにＫＤＦを使用するには、ＫＤＦおよびＤＵＣＫまたはＤＵＳＫから疑似乱数列を取得するために、追加のカウンタであるブロックカウンタを含める必要がある。保護がＰＤＣＰ層で行われ、ディスカバリメッセージの長さが１２８バイトである場合、ディスカバリメッセージを暗号化するための鍵ストリームを取得するには、以下のカウンタ値で合計４回のＫＤＦ呼び出しが必要になる。
上記実施形態では、保護を必要とするフィールドの長さが、使用されるＫＤＦの出力サイズである３２バイトよりも長い場合でも、ＤＣＲメッセージの機密性を保護する方法を説明した。これは、単一のＫＤＦ呼び出しからではなく、ＫＤＦへの複数回の呼び出しから取得された鍵ストリームを使用してメッセージを暗号化（またはスクランブル）することによって行われる。これは、ＫＤＦにおける入力として使用されるＳビット列の定義内に追加の入力として少なくとも１つのカウンタ（ブロックカウンタ）を含め、カウンタを増加させて鍵ストリームの追加バイトを生成することによって実行され得る。カウンタの代わりにナンスが使用される可能性があることに留意されたい。ナンスは、ランダムに生成され、１回だけ使用される数値である。例えば、メッセージの長さがＮ＊Ｂバイトで、ＢがＫＤＦの出力サイズである場合、ＫＤＦへのＮ回の呼び出しが、それぞれ異なるカウンタ値（例えば、０～Ｎ－１の範囲）で要求される。このようなソリューションは、３２バイトを超える長さを有する可能性があるディスカバリメッセージにも適用可能である。特に、Ｒｅｌ－１７ Ｕ２Ｎサイドリンクリレーでは、サイドリンクディスカバリメッセージのためにＲＬＣ ＵＭモードが使用される可能性があり、ディスカバリメッセージの最大サイズは、例えば９０００バイトであり得る。上記したように、ディスカバリメッセージを保護するためのセキュリティルーチンは、小さい固定サイズのディスカバリメッセージに対してのみ機能することに留意されたい。新しいフィールドまたはアプリケーション層メタデータ情報の交換に起因して、より大きなサイズのディスカバリメッセージが生じる可能性がある。ＲＬＣフラグメンテーションは、２９７６ビット＝３７２バイトで既に発生する可能性がある。この場合、ディスカバリメッセージは３２バイトよりも長くなる可能性があり、ＫＤＦへの複数回の呼び出しが必要になり得る。この場合、ディスカバリメッセージのサイズは２９７６ビットよりも長くなる可能性があり、複数のフラグメントが発生する可能性がある。したがって、ＰＤＣＰ層での（ＤＵＣＫを用いた）暗号化および／または（ＤＵＳＫを用いた）スクランブルのためにＫＤＦを使用するには、ＫＤＦおよびＤＵＣＫまたはＤＵＳＫから疑似乱数列を取得するために、追加のカウンタであるブロックカウンタを含める必要がある。保護がＰＤＣＰ層で行われ、ディスカバリメッセージの長さが１２８バイトである場合、ディスカバリメッセージを暗号化するための鍵ストリームを取得するには、以下のカウンタ値で合計４回のＫＤＦ呼び出しが必要になる。
【表10】
【0188】
保護がＲＬＣ層で行われる場合、ＫＤＦおよびＤＵＣＫまたはＤＵＳＫから疑似乱数列を取得するために、例えば２つの追加の入力カウンタを含める必要がある。第１の入力カウンタはフラグメントカウンタＣ＿Ｆであり、第２の入力カウンタはブロックカウンタＣ＿ｂである。フラグメントカウンタは、ディスカバリメッセージ全体の中のフラグメントを識別する。ブロックカウンタは、フラグメント内のｂ（例えば、ｂ＝３２バイト）のブロックを識別する。例えば、フラグメントの長さが６４バイトで、ディスカバリメッセージの長さが１２８バイトで、ＫＤＦの出力が３２バイトである場合、ディスカバリメッセージの６４バイトのフラグメントが２つ存在する。ディスカバリメッセージのフラグメントはフラグメントカウンタを含む。各フラグメントは、ブロックカウンタに（暗示的に）リンクされ得る３２バイトのブロックを２つ含む。この例では、フラグメントカウンタ値およびブロックカウンタ値は「００００」および「０００１」であり得、１６進数表現および２バイト長のカウンタが仮定される。保護がＲＬＣ層で行われる場合、ディスカバリメッセージを暗号化するための鍵ストリームを取得するには、以下のカウンタ値で合計２×２回のＫＤＦ呼び出しが必要になる。
【表11】
【0189】
この最後のケースでは、次のように両方のカウンタを１つの値に結合できることに留意されたい。
Ｆｒａｇｍｅｎｔ＿ｃｏｕｎｔｅｒ＊Ｍａｘｉｍｕｍ＿ｎｕｍｂｅｒ＿ｂｌｏｃｋｓ＿ｉｎ＿ａ＿ｆｒａｇｍｅｎｔ＋ｂｌｏｃｋ＿ｃｏｕｎｔｅｒ
Ｆｒａｇｍｅｎｔ＿ｃｏｕｎｔｅｒ＊Ｍａｘｉｍｕｍ＿ｎｕｍｂｅｒ＿ｂｌｏｃｋｓ＿ｉｎ＿ａ＿ｆｒａｇｍｅｎｔ＋ｂｌｏｃｋ＿ｃｏｕｎｔｅｒ
【0190】
上記の１つ以上のカウンタを考慮すると、ＴＳ３３．３０３と比較して、ＫＤＦへの入力を変更する必要がある。
【0191】
ＤＵＳＫが使用される場合、ＫＤＦへの呼び出しは少なくとも１つのカウンタからの情報を含む必要があり、例えば次の通りである。
タイムハッシュビットシーケンス＝ＫＤＦ（ＤＵＳＫ，ＵＴＣベースのカウンタ，ブロックカウンタ）
または
タイムハッシュビットシーケンス＝ＫＤＦ（ＤＵＳＫ，ＵＴＣベースのカウンタ，フラグメントカウンタ，ブロックカウンタ）
タイムハッシュビットシーケンス＝ＫＤＦ（ＤＵＳＫ，ＵＴＣベースのカウンタ，ブロックカウンタ）
または
タイムハッシュビットシーケンス＝ＫＤＦ（ＤＵＳＫ，ＵＴＣベースのカウンタ，フラグメントカウンタ，ブロックカウンタ）
【0192】
上記において、ＵＥは、受信したメッセージからフラグメントカウンタを直接取得する可能性があることに留意されたい。すなわち、各フラグメントはフラグメントカウンタを含む必要があり、この値はスクランブルされてはならない。ブロックカウンタは所定の値で開始し、ＫＤＦへの呼び出しが追加されるたびに、例えば１ずつ増加すべきである。
【0193】
フラグメントカウンタおよび／またはブロックカウンタがタイムハッシュビットシーケンスを生成するための入力として使用されない場合、複数のブロックが同じタイムハッシュビットシーケンスでスクランブルされることに留意されたい。したがって、スクランブルされた２つのブロックをＸＯＲ演算すると、平文ブロックのＸＯＲを取得できる。
【0194】
ＤＵＣＫが使用される場合、ＫＤＦへの呼び出しは次のようになり、すなわち、少なくとも１つのカウンタからの情報を含む。
鍵ストリーム＝ＫＤＦ（ＤＵＣＫ，ＵＴＣベースのカウンタ．ブロックカウンタ，（Ｋｅｙ＿ｃａｌｃ＿ｍａｓｋ ＡＮＤ （Ｍｅｓｓａｇｅ｜｜ＭＩＣ）））。
鍵ストリーム＝ＫＤＦ（ＤＵＣＫ，ＵＴＣベースのカウンタ．ブロックカウンタ，（Ｋｅｙ＿ｃａｌｃ＿ｍａｓｋ ＡＮＤ （Ｍｅｓｓａｇｅ｜｜ＭＩＣ）））。
【0195】
上記において、フラグメントカウンタに関する情報がメッセージ自体に含まれていてもよいことに留意されたい。
【0196】
フラグメンテーションはまた、完全性保護の実行方法を示唆する可能性がある。まず、攻撃者が複数の異なるディスカバリメッセージのフラグメントを混合できないようにするために、ディスカバリメッセージごとにＭＩＣが要求される可能性がある。この全体的ＭＩＣは、ディスカバリメッセージのフラグメントのうちの少なくとも１つ、例えば最後のフラグメントに含まれる必要がある。このＭＩＣは、ＴＳ３３．３０３の６．１．３．４．３．４に記載されるように計算されてもよく、その場合、ビット列Ｓは、メッセージ内のフラグメントの数も含み得、Ｐ１フィールドは、メッセージ全体の内容を指すか、またはメッセージの内容全てに依存する値（例えば、そのハッシュ、またはメッセージの複数の部分の複数のハッシュ／ＭＩＣの連結）を指す。このようなＭＩＣは、ディスカバリメッセージがＰＤＣＰ層で保護されている場合に取得され得る。第二に、フラグメントが変更されておらず、フラグメントが到着した状態で処理できることを保証するために、やはりフラグメントごとのＭＩＣが要求される可能性がある。このＭＩＣの計算では、ＭＩＣが属するフラグメントからの入力情報のみを考慮すべきであり、すなわち、ビット列Ｓがフラグメントカウンタも含み、Ｐ１フィールドがそのフラグメントのみの内容を指す、ＴＳ３３．３０３の６．１．３．４．３．４に記載されているように行われるべきである。
【0197】
全体として、５ＧディスカバリメッセージがＬＴＥよりも長いことを考慮して、ＴＳ３３．３０３の項６．１．３．４．３．２のプロセスを更新する必要がある。特に、ステップ３および５では、ＫＤＦを少なくとも１回、おそらくは複数回呼び出し、ＫＤＦへの呼び出しごとに値が異なるブロックカウンタ（例えば、増加するブロックカウンタ）をＫＤＦへの入力の１つとして使用することによって取得される疑似乱数列を使用して、ディスカバリメッセージを暗号化およびスクランブルする必要がある。ディスカバリメッセージを保護するためのＫＤＦ呼び出し回数は、ＣＥＩＬ（ｍｅｓｓａｇｅ＿ｌｅｎｇｔｈ／ＫＤＦ＿ｏｕｔｐｕｔ ｓｉｚｅ）である。このアプローチは、例えばＴＳ３３．５０３で指定されているような５Ｇ運用に適用可能である。ＣＥＩＬは天井関数を指すが、（量子化ステップ＞１を使用できる）量子化関数を指してもよい。
【0198】
ディスカバリメッセージ内の一部のフィールド（例えば、メタデータ）をセキュリティ保護する必要がない場合、または一部のフィールドのセキュリティ保護がアプリケーション次第である場合、ディスカバリメッセージの一部のみを、ＴＳ３３．３０３または上記実施形態に基づいて保護すればよい。ある選択肢では、ソースレイヤ２ ＩＤ、宛先レイヤ２ ＩＤ、リレーサービスコード、アナウンサ情報、またはＮＣＧＩもしくはＴＡＩなどの追加パラメータなどの既存のフィールドだけでなく、メタデータも含む、ディスカバリメッセージの全ての内容が完全に保護される可能性がある。これは、メッセージ全体をＴＳ３３．３０３の項６．１．３．４．３．２のＭＩＣ生成手順に送ることができるため、実現可能となる。しかし、特定のフィールドのみが機密性保護される可能性がある。特に、暗号化が必要なフィールドの長さが３２バイト未満である可能性があり、そのため、１回のＫＤＦ呼び出しが要求される可能性がある。主な違いは、項６．１．３．４．３．２の３行目では、メッセージの一部にのみ機密性が追加され、機密性の保護が必要なフィールドは、連続した３２バイト以内でなければならないことである。
【0199】
３２バイト長よりも長い疑似乱数列を取得するために鍵導出関数を使用することに対する代替実施形態は、ディスカバリメッセージの保護において、ＴＳ３３．４０１に記載されている標準５Ｇ機密性アルゴリズム（例えば、１２８－ＮＥＡ１、１２８－ＮＥＡ２、１２８－ＮＥＡ３）および完全性アルゴリズム（例えば、１２８－ＮＩＡ１、１２８－ＮＩＡ２、１２８－ＮＩＡ３）のうちの１つを適用することである。
【0200】
これを行うための重要な要件は、送信デバイス（例えば、アナウンスを行うＵＥ）が、ディスカバリメッセージの内容の暗号化および／または完全性保護に使用されるセキュリティアルゴリズムを示すフィールドをディスカバリメッセージに含めることである。これにより、受信側ＵＥ（例えば、監視を行うＵＥ）は、受信メッセージの復号／完全性検証に使用される適切なアルゴリズムを選択できるようになる。発見モデルＢでは、送信側ＵＥがサポートするアルゴリズムが最初のメッセージに含まれ得る。メッセージを受信すると、受信側ＵＥは、受信したサポートされているアルゴリズムを使用して、応答を保護するために使用される暗号化アルゴリズムおよび／または完全性アルゴリズムを決定できる。応答には、受信側ＵＥが復号／完全性検証できるように、選択されたアルゴリズムを含めることができる。サポートされているアルゴリズムを含むフィールドは暗号化すべきではない。なぜなら、暗号化されていると、受信側はどのアルゴリズムを使用すべきかが分からないからである。
【0201】
あるいは、送信側ＵＥによって複数の暗号化および／または完全性アルゴリズムがサポートおよび使用される可能性があり、どの特定の暗号化および／または完全性アルゴリズムが使用されるかを識別するためのフィールドがディスカバリメッセージに追加されない場合、送信側ＵＥ（例えば、アナウンスを行うＵＥ）は、適切な暗号化および／または完全性アルゴリズムを選択し、ディスカバリメッセージを暗号化および／または完全性保護し、保護されたディスカバリメッセージを送信する。保護されたディスカバリメッセージを受信すると、受信側ＵＥ（例えば、監視を行うＵＥ）は、メッセージを復号し、サポートされている暗号化および／または完全性アルゴリズムの全ての組み合わせについて、完全性を検証する。受信側ＵＥは、最初に復号アルゴリズムを適用してから、サポートされている全ての完全性アルゴリズムを使用して完全性をチェックすることを試みる。例えば、受信側ＵＥは最初に１２８－ＮＥＡ１を用いて復号し、次に１２８－ＮＩＡ１、１２８－ＮＩＡ２、および１２８－ＮＩＡ３で完全性をチェックする。それが完了すると、ＵＥは１２８－ＮＥＡ２を用いて復号を行い、１２８－ＮＩＡ１、１２８－ＮＩＡ２、１２８－ＮＩＡ３などで完全性をチェックする。ＭＩＣ検証が成功すると、受信側ＵＥは停止する。
【0202】
長いディスカバリメッセージの処理は、ＴＳ３３．３０３の項６．１．３．４．３．２および６．１．３．４．３．３と比較して、送信側ＵＥおよび受信側ＵＥの両方でのメッセージ処理に影響を与える。
【0203】
そのような実装形態では、ディスカバリメッセージを送信するＵＥは、メッセージを保護する方法を示すために、ＰｒｏＳｅ機能からコード送信セキュリティパラメータを受信することができる（セキュリティフローで説明されているように）。コード送信セキュリティパラメータはＤＵＳＫを含み得、ＤＵＩＫを含み得る。コード送信セキュリティパラメータは、ＤＵＣＫおよびＥｎｃｒｙｐｔｅｄ＿ｂｉｔｓ＿ｍａｓｋの両方を含み得る。ディスカバリメッセージを送信するＵＥは次のステップを実行する。
１．ディスカバリメッセージを形成する（例えば、プレフィックスのみが割り当てられている場合はサフィックスを追加する）。
２．ＤＵＩＫが提供された場合はＭＩＣを計算し、そうでない場合はＭＩＣを全てゼロに設定する。
３．ＤＵＣＫを受信した場合、メッセージ固有機密性をメッセージに追加する。
４．ステップ３の出力にＭＩＣを添付する。
５．ＤＵＳＫを受信した場合、ステップ４の出力にスクランブルを追加する。
１．ディスカバリメッセージを形成する（例えば、プレフィックスのみが割り当てられている場合はサフィックスを追加する）。
２．ＤＵＩＫが提供された場合はＭＩＣを計算し、そうでない場合はＭＩＣを全てゼロに設定する。
３．ＤＵＣＫを受信した場合、メッセージ固有機密性をメッセージに追加する。
４．ステップ３の出力にＭＩＣを添付する。
５．ＤＵＳＫを受信した場合、ステップ４の出力にスクランブルを追加する。
【0204】
あるいは、ＭＩＣが暗号化されていることを保証するために以下が実行される。
１．ディスカバリメッセージを形成する（例えば、プレフィックスのみが割り当てられている場合はサフィックスを追加する）。
２．ＤＵＩＫが提供された場合はＭＩＣを計算し、そうでない場合はＭＩＣを全てゼロに設定する。
３．ステップ１の出力にＭＩＣを添付する。
４．ＤＵＣＫを受信した場合、メッセージ固有機密性をメッセージに追加する。
５．ＤＵＳＫを受信した場合、ステップ４の出力にスクランブルを追加する。
１．ディスカバリメッセージを形成する（例えば、プレフィックスのみが割り当てられている場合はサフィックスを追加する）。
２．ＤＵＩＫが提供された場合はＭＩＣを計算し、そうでない場合はＭＩＣを全てゼロに設定する。
３．ステップ１の出力にＭＩＣを添付する。
４．ＤＵＣＫを受信した場合、メッセージ固有機密性をメッセージに追加する。
５．ＤＵＳＫを受信した場合、ステップ４の出力にスクランブルを追加する。
【0205】
ステップ１において、ＴＳ３３．３０３からの主な違いは、メッセージの長さが固定されていないことである。したがって、メッセージ長を示すか、または長さがアプリケーションに依存するアプリケーション固有のフィールドが含まれているか否かを示すフィールドをメッセージに含める必要がある可能性がある。
【0206】
これを実現するための選択肢は、ディスカバリメッセージの固定（常に存在する）フィールドと、任意選択のフィールドとの合計に対応するメッセージ長を全てのディスカバリメッセージに常に含めることである。例えば、メッセージが、それぞれ長さが２４ビット、２４ビット、および４８ビットである固定フィールドＲＳＣ、ＰｒｏＳｅリレーＵＥ ＩＤ、およびアナウンサ情報、並びに長さが２５６ビットであるメタデータを含む場合、４２バイトの全長を示すフィールドが存在する。別の選択肢は、固定（常に存在する）フィールドの後に任意選択のフィールドの存在を示すビットマスクを含めることである。例えば、ｘ個の任意選択のフィールドがある場合、それらの存在を示すためにｘビットのマスクを含めることができる。例えば、値が１０００であるマスクが存在する場合、１である第１のビットは、４の可能な任意選択のフィールドのうちの第１の任意選択のフィールドが存在することを示す。したがって、受信デバイスは、例えばメタデータを有する追加フィールドが存在することを知る。この任意選択のフィールドは、固定フィールドの後に存在し得る。各任意選択のフィールド、例えばメタデータフィールドの最初の方のバイトは、この場合は長さを、例えば上記の例では３２バイトの長さを含める必要がある。メッセージ固有の機密性およびスクランブルに関連するステップにおける別の主な違いは、ディスカバリメッセージの保護に、ＫＤＦへの複数の呼び出しが要求されることである。
【0207】
受信側ＵＥでの処理に関しては、（セキュリティフローで説明されているように）ＰｒｏＳｅ機能から受信されるコード受信セキュリティパラメータを使用して、受信したディスカバリメッセージの保護方法がＵＥに示される。コード受信セキュリティパラメータは、ＤＵＳＫを含み得、ＤＵＩＫ、またはＭＩＣチェックに照合レポートを使用すべきか否かの指示のいずれかを含み得る。一般に、ＰｒｏＳｅクエリコードでは照合レポートの選択肢は許可されていない。コード受信セキュリティパラメータも、ＤＵＣＫおよび対応するＥｎｃｒｙｐｔｅｄ＿ｂｉｔｓ＿ｍａｓｋの両方を含み得る。
【0208】
したがって、ディスカバリメッセージを受信するＵＥは以下のステップを実行し得る。
１．ＤＵＳＫが受信された場合、スクランブルを解除する（送信側ＵＥのステップ５と同様に）。
１．ＤＵＳＫが受信された場合、スクランブルを解除する（送信側ＵＥのステップ５と同様に）。
【0209】
合計メッセージ長が含まれる場合、ＵＥはこの入力値を使用して、例えばＭＩＣの計算や、スクランブル／暗号化疑似乱数列の長さの決定に必要なバッファを割り当てることができることに留意されたい。長さの値は、長さフィールドが存在する場合、メッセージの最初の部分のスクランブルを解除した後に取得され得る。メッセージ長が直接利用できない場合、ＭＩＣの計算用の入力の長さ、またはスクランブルに必要な長さは、様々な任意選択のフィールドにアクセスし、各フィールドから各フィールドの長さを取り出すことによって段階的に計算される。
【0210】
２．メッセージ固有機密性を使用して暗号化されていないメッセージのビットが一致するか否かをチェックする。一致しない場合は中止する。
【0211】
ディスカバリフィルタによって一致が示される一部のビットは、この段階でメッセージ固有機密性によって暗号化され得ることに留意されたい。ＵＥは、このステップの後に他のビットの一致を検索して、一致を見つける前に実行される処理の量を最小限に抑えてもよい。
【0212】
一致は、メッセージの最初の部分（例えば、メッセージの最初の３２バイト）でのみ必要な可能性があるため、ＫＤＦへの１回の呼び出しが要求されることに留意されたい。一致が見つかった場合、受信側ＵＥはディスカバリメッセージの長さを読み取り（長さフィールドが利用可能な場合）、メッセージの残り部分のスクランブルを解除することができる。あるいは、受信側ＵＥは、マスクにおいて、任意選択の追加フィールド、例えばメタデータフィールドの存在をチェックしてもよい。その場合、受信側ＵＥは、任意選択のフィールドの最初のバイトのスクランブルを解除してフィールド長を取り出し、その後、スクランブルの解除を行う。
【0213】
３．ＤＵＣＫが受信された場合、メッセージ固有機密性を解除する（送信側ＵＥのステップ３と同様に）。
【0214】
４．３で暗号化されていないビットの一致のみが見つかった場合、完全照合を行う。一致しない場合は中止する。
【0215】
５．ＭＩＣチェックが必要な場合、ＭＩＣを直接チェックするか（ディスカバリフィルタセキュリティパラメータ内でＤＵＩＫが与えられた場合）、またはディスカバリフィルタセキュリティパラメータ内に示されている場合は照合レポートを介してチェックする。
【0216】
完全性保護は、ＴＳ３３．３０３の項６．１．３．４．３．４と同様である。
【0217】
したがって、送信側ＵＥは以下を実行し得る。
１．ＴＳ３３．３０３の付録Ａ．２のＭＩＣ計算関数を通過されるＤＵＩＫ、メッセージ、および、ＵＴＣベースのカウンタから、出力ビットシーケンスを計算する。
２．関数の出力のｎバイト（例えば、ｎ＝４）を取得し、それをこのメッセージのＭＩＣの値として設定する。
１．ＴＳ３３．３０３の付録Ａ．２のＭＩＣ計算関数を通過されるＤＵＩＫ、メッセージ、および、ＵＴＣベースのカウンタから、出力ビットシーケンスを計算する。
２．関数の出力のｎバイト（例えば、ｎ＝４）を取得し、それをこのメッセージのＭＩＣの値として設定する。
【0218】
受信側ＵＥまたはＰｒｏＳｅ関数は全く同じ手順を実行するが、さらに、計算されたＭＩＣと受信したＭＩＣとの比較も実行する。
【0219】
スクランブル保護はＴＳ３３．３０３の項６．１．３．４．３．５と同様であるが、より長いメッセージを考慮して変更が加えられている。
【0220】
このような例では、送信側ＵＥは以下を実行する。
１．このスクランブル計算のみを目的として、ＵＴＣベースのカウンタの４つのＬＳＢをゼロに設定する。
２．鍵付きハッシュ関数を通過されるＤＵＳＫおよびＵＴＣベースのカウンタ（ステップ１のように変更されたもの）からタイムハッシュビットシーケンスを計算する。
ａ．タイムハッシュビットシーケンス＝“”
ｂ．ｉ＝ａ～（ａ＋ＦＬＯＯＲ（（Ｌ＋４）／３２））について、
タイムハッシュビットシーケンス＝タイムハッシュビットシーケンス｜｜ＫＤＦ（ＤＵＳＫ，ＵＴＣベースのカウンタ，ｉ）
ｃ．タイムハッシュビットシーケンス＝タイムハッシュビットシーケンス｜｜ＬＳＢ（ＫＤＦ（ＤＵＳＫ，ＵＴＣベースのカウンタ，ｉ），８＊（Ｌ＋４－３２＊ＦＬＯＯＲ（（Ｌ＋４）／３２）））
３．タイムハッシュビットシーケンスを、処理中のディスカバリメッセージ全体（ＭＩＣを含む）とＸＯＲする。
１．このスクランブル計算のみを目的として、ＵＴＣベースのカウンタの４つのＬＳＢをゼロに設定する。
２．鍵付きハッシュ関数を通過されるＤＵＳＫおよびＵＴＣベースのカウンタ（ステップ１のように変更されたもの）からタイムハッシュビットシーケンスを計算する。
ａ．タイムハッシュビットシーケンス＝“”
ｂ．ｉ＝ａ～（ａ＋ＦＬＯＯＲ（（Ｌ＋４）／３２））について、
タイムハッシュビットシーケンス＝タイムハッシュビットシーケンス｜｜ＫＤＦ（ＤＵＳＫ，ＵＴＣベースのカウンタ，ｉ）
ｃ．タイムハッシュビットシーケンス＝タイムハッシュビットシーケンス｜｜ＬＳＢ（ＫＤＦ（ＤＵＳＫ，ＵＴＣベースのカウンタ，ｉ），８＊（Ｌ＋４－３２＊ＦＬＯＯＲ（（Ｌ＋４）／３２）））
３．タイムハッシュビットシーケンスを、処理中のディスカバリメッセージ全体（ＭＩＣを含む）とＸＯＲする。
【0221】
受信側ＵＥも、処理中の受信メッセージに適用されることを除いて、全く同じ手順を実行することができる。上記において、値「ａ」は任意の初期インデックス値であり得、ＬＳＢは最下位ビットを意味する。ＦＬＯＯＲ（ｘ）は、ｘ以下の最大の整数を返す。
【0222】
この実施形態では、メッセージ固有機密性の保護はＴＳ３３．３０３の項６．１．３．４．３．６と同様であるが、より長いメッセージを考慮して変更が加えられている。
【0223】
送信側ＵＥは以下を実行する。
１．Ｋｅｙ＿ｃａｌｃ＿ｍａｓｋ＝（Ｅｎｃｒｙｐｔｅｄ＿ｂｉｔｓ＿ｍａｓｋ ＸＯＲ ０ｘＦＦ・・・ＦＦ）｜｜０ｘＦＦＦＦＦＦＦＦを計算する
２．ＫＤＦを使用して次のように鍵ストリームを取得する
ａ．鍵ストリーム＝“”
ｂ，Ｈ＝（Ｋｅｙ＿ｃａｌｃ＿ｍａｓｋ ＡＮＤ （メッセージ｜｜ＭＩＣ））、またはＨａｓｈ（（Ｋｅｙ＿ｃａｌｃ＿ｍａｓｋ ＡＮＤ （メッセージ｜｜ＭＩＣ）））
ｃ．ｉ＝ａ～（ａ＋ＦＬＯＯＲ（Ｌ／３２））について、
ｉ．鍵ストリーム＝鍵ストリーム｜｜ＫＤＦ（ＤＵＣＫ，ＵＴＣベースのカウンタ，ｉ，Ｈ）。
ｄ．鍵ストリーム＝鍵ストリーム｜｜ＬＳＢ（ＫＤＦ（ＤＵＣＫ，ＵＴＣベースのカウンタ，ｉ，Ｈ），８＊（Ｌ－３２＊ＦＬＯＯＲ（Ｌ／３２）））
３．メッセージ内へＸＯＲ（Ｋｅｙｓｔｒｅａｍ ＡＮＤ Ｅｎｃｒｙｐｔｅｄ＿ｂｉｔｓ＿ｍａｓｋ）する。
１．Ｋｅｙ＿ｃａｌｃ＿ｍａｓｋ＝（Ｅｎｃｒｙｐｔｅｄ＿ｂｉｔｓ＿ｍａｓｋ ＸＯＲ ０ｘＦＦ・・・ＦＦ）｜｜０ｘＦＦＦＦＦＦＦＦを計算する
２．ＫＤＦを使用して次のように鍵ストリームを取得する
ａ．鍵ストリーム＝“”
ｂ，Ｈ＝（Ｋｅｙ＿ｃａｌｃ＿ｍａｓｋ ＡＮＤ （メッセージ｜｜ＭＩＣ））、またはＨａｓｈ（（Ｋｅｙ＿ｃａｌｃ＿ｍａｓｋ ＡＮＤ （メッセージ｜｜ＭＩＣ）））
ｃ．ｉ＝ａ～（ａ＋ＦＬＯＯＲ（Ｌ／３２））について、
ｉ．鍵ストリーム＝鍵ストリーム｜｜ＫＤＦ（ＤＵＣＫ，ＵＴＣベースのカウンタ，ｉ，Ｈ）。
ｄ．鍵ストリーム＝鍵ストリーム｜｜ＬＳＢ（ＫＤＦ（ＤＵＣＫ，ＵＴＣベースのカウンタ，ｉ，Ｈ），８＊（Ｌ－３２＊ＦＬＯＯＲ（Ｌ／３２）））
３．メッセージ内へＸＯＲ（Ｋｅｙｓｔｒｅａｍ ＡＮＤ Ｅｎｃｒｙｐｔｅｄ＿ｂｉｔｓ＿ｍａｓｋ）する。
【0224】
受信側ＵＥは、処理中の受信したディスカバリメッセージに適用されるものと同じ対応する手順を実行する。
【0225】
上記において、ステップ２．ｂ．では、Ｈは、（Ｋｅｙ＿ｃａｌｃ＿ｍａｓｋ ＡＮＤ （メッセージ｜｜ＭＩＣ））、またはこの値の関数（例えば、そのハッシュ）、または入力の一部分の関数（例えば、ｈａｓｈ（Ｋｅｙ＿ｃａｌｃ＿ｍａｓｋ｜｜ＭＩＣ）のいずれかを指し得る。主な目的は、長い可能性があるメッセージを、ステップ２．ｃ．ｉの各ＫＤＦ呼び出しで使用できる短いフィンガープリントに圧縮して、効率を高めることである。
【0226】
上記アルゴリズムは、鍵ストリームおよびタイムハッシュビットシーケンスの生成に使用されるＫＤＦへの入力の定義の変更によって補完される。これらの変更は、ＴＳ３３．３０３の付録Ａ．５およびＡ．６に存在する定義において必要となる。
【0227】
（ＴＳ３３．３０３のＡ．５に関連する）ディスカバリ用のスクランブルビットシーケンスを計算するとき、ＴＳ３３．２２０の付録Ｂに記載されている各ＫＤＦ呼び出しへの入力Ｓを形成するために次のパラメータが使用される。
－ ＦＣ＝一意の識別子。
－ Ｐ０＝ディスカバリスロットに関連付けられたスクランブル用のＵＴＣベースのカウンタ（小項６．１．３．４．３．５を参照）。
－ Ｌ０＝上記の長さ（すなわち、０ｘ００ ０ｘ０４）。
－ Ｐ１＝メッセージフラグメントインデックス。
－ Ｌ１＝上記の長さ（すなわち、０ｘ００ ０ｘ０２）。
－ ＦＣ＝一意の識別子。
－ Ｐ０＝ディスカバリスロットに関連付けられたスクランブル用のＵＴＣベースのカウンタ（小項６．１．３．４．３．５を参照）。
－ Ｌ０＝上記の長さ（すなわち、０ｘ００ ０ｘ０４）。
－ Ｐ１＝メッセージフラグメントインデックス。
－ Ｌ１＝上記の長さ（すなわち、０ｘ００ ０ｘ０２）。
【0228】
入力鍵は２５６ビットＤＵＳＫ。
【0229】
Ｌ１のバイト長は、最大９０００バイトを保護するために必要な最小バイト長である２である。Ｐ１は、ディスカバリメッセージ内の３２バイトのフラグメントまたはブロックを指す。ＴＳ３３．２２０の場合と同様に３２ビットＫＤＦ出力が想定されているため、値３２が使用される。別のＫＤＦが使用される場合は長さが調整される。
【0230】
長さＬのディスカバリメッセージの場合、合計ＣＥＩＬ（（Ｌ＋ＬＭＩＣ）／３２）回のＫＤＦ呼び出しが必要となり、それぞれが異なるＰ１値を有する。ここで、Ｌ＋ＬＭＩＣが使用され、Ｌはディスカバリメッセージの長さを指し、ＬＭＩＣはスクランブルされたＭＩＣの長さを指す。ＣＥＩＬ（ｘ）は、ｘ以上の最小の整数を返す。
【0231】
スクランブルビットシーケンスは、最初のＦＬＯＯＲ（（Ｌ＋ＬＭＩＣ）／３２）回のＫＤＦ呼び出しのＫＤＦ出力全体と、最後のＫＤＦ呼び出しの出力のＲ＝８（Ｌ＋ＬＭＩＣ－３２＊ＦＬＯＯＲ（（Ｌ＋ＬＭＩＣ）／３２））個の最下位ビットとの連結に設定される。ＬＳＢの代わりに、Ｒ個のビットの任意のサブセットが選択されてもよい。ＦＬＯＯＲ（ｘ）は、ｘ以下の最大の整数を返す。
【0232】
（ＴＳ３３．３０３のＡ．６に関連する）ディスカバリ用のメッセージ固有機密性鍵ストリームを計算するとき、ＴＳ３３．２２０［５］の付録Ｂに記載されている各ＫＤＦ呼び出しへの入力Ｓを形成するために次のパラメータが使用される。
－ ＦＣ＝０ｘ４Ｄ
－ Ｐ０＝ディスカバリスロットに関連付けられたＵＴＣベースのカウンタ（６．１．３．４．３．６項を参照）。
－ Ｌ０＝上記の長さ（すなわち、０ｘ００ ０ｘ０４）。
－ Ｐ１＝メッセージフラグメントインデックス。
－ Ｌ１＝上記の長さ（すなわち、０ｘ００ ０ｘ０２）。
－ Ｐ２＝（Ｋｅｙ＿ｃａｌｃ＿ｍａｓｋ ＡＮＤ （Ｍｅｓｓａｇｅ｜｜ＭＩＣ））（小項６．１．３．４．３．６を参照）
－ Ｌ２＝上記の長さ（すなわち、０ｘ００ ０ｘ１Ｂ）。
－ ＦＣ＝０ｘ４Ｄ
－ Ｐ０＝ディスカバリスロットに関連付けられたＵＴＣベースのカウンタ（６．１．３．４．３．６項を参照）。
－ Ｌ０＝上記の長さ（すなわち、０ｘ００ ０ｘ０４）。
－ Ｐ１＝メッセージフラグメントインデックス。
－ Ｌ１＝上記の長さ（すなわち、０ｘ００ ０ｘ０２）。
－ Ｐ２＝（Ｋｅｙ＿ｃａｌｃ＿ｍａｓｋ ＡＮＤ （Ｍｅｓｓａｇｅ｜｜ＭＩＣ））（小項６．１．３．４．３．６を参照）
－ Ｌ２＝上記の長さ（すなわち、０ｘ００ ０ｘ１Ｂ）。
【0233】
入力鍵は２５６ビットＤＵＣＫ。
【0234】
長さＬのディスカバリメッセージの場合、合計ＣＥＩＬ（Ｌ／３２）回のＫＤＦ呼び出しが必要となり、それぞれが異なるＰ１値を有する。ＭＩＣを暗号化する必要がある場合は、ＬＭＩＣも含める必要があることに留意されたい。ＣＥＩＬ（ｘ）は、ｘ以上の最小の整数を返す。
【0235】
メッセージ固有機密性鍵ストリームは、最初のＦＬＯＯＲ（Ｌ／３２）回のＫＤＦ呼び出しのＫＤＦ出力と、最後のＫＤＦ呼び出しの出力のＲ＝８（Ｌ－３２＊ＦＬＯＯＲ（Ｌ／３２））個の最下位ビットとの連結に設定される。Ｒ個のＬＳＢの代わりに、Ｒビットの任意のサブセットであってもよい。ＦＬＯＯＲ（ｘ）は、ｘ以下の最大の整数を返す。
【0236】
追加の変更の可能性としては、暗号化および／またはスクランブルの際にＫＤＦではなくＮＥＡアルゴリズムを使用することが挙げられる。
【0237】
これは、（ＵＴＣベースのカウンタの計算方法のために）鍵ストリームシーケンスをより頻繁に生成する必要があるので、暗号化をする際に有用であり得る。
【0238】
これは、暗号化がメッセージのごく一部のみ（例えば、ディスカバリメッセージの最後の方のバイトのみ）に対してのみ行われる場合においてスクランブルを行うときに役立つ。
【0239】
この場合、１２８－ＮＥＡアルゴリズムが使用されている場合、ＮＥＡアルゴリズムの入力鍵は、ＤＵＣＫ（またはＤＵＳＫ）の１２８ＬＳＢであってもよい。ＮＥＡアルゴリズムの３２ビットカウントはＵＴＣベースのカウンタに設定され得、ＢＥＡＲＥＲは所定のバイナリ値（例えば、ＢＥＡＲＥＲ＝００００）に設定され得、ＤＩＲＥＣＴＩＯＮは所定の値（例えば、モデルＡディスカバリメッセージもしくは最初のモデルＢディスカバリメッセージである場合はＤＩＲＥＣＴＩＯＮ＝０、またはモデルＢの２番目のディスカバリメッセージの場合はＤＩＲＥＣＴＩＯＮ＝１）に設定され得る。長さフィールドには、完全性保護を必要とするディスカバリメッセージ（の一部）の長さを含める必要がある。
【表12】
【0240】
追加の変更の可能性としては、ＫＤＦベースのＭＩＣアプローチの代わりにＮＩＡアルゴリズムを使用することが挙げられる。この場合、１２８－ＮＩＡアルゴリズムが使用されている場合、ＮＩＡアルゴリズムの入力鍵はＤＵＩＫの１２８ＬＳＢであってもよい。ＮＩＡアルゴリズムの３２ビットカウントはＵＴＣベースのカウンタに設定され得、ＢＥＡＲＥＲは所定のバイナリ値（例えば、ＢＥＡＲＥＲ＝００００）に設定され得、ＤＩＲＥＣＴＩＯＮは所定の値（例えば、モデルＡディスカバリメッセージもしくは最初のモデルＢディスカバリメッセージである場合はＤＩＲＥＣＴＩＯＮ＝０、またはモデルＢの２番目のディスカバリメッセージの場合はＤＩＲＥＣＴＩＯＮ＝１）に設定され得る。長さフィールドには、完全性保護を必要とするディスカバリメッセージ（の一部）の長さを含める必要がある。
【0241】
追加の変更の可能性としては、暗号化およびスクランブルの並列処理が挙げられる。この場合、ＴＳ３３．３０３のセクション６．１．３．４．３．２に記載されており、かつ上記に含まれる、基礎となるアルゴリズムが次のように実現される。
【0242】
上記アルゴリズムでは、既に説明したように、パフォーマンスの目的で、６行目のＨが（Ｋｅｙ＿ｃａｌｃ＿ｍａｓｋ ＡＮＤ （メッセージ｜｜ＭＩＣ）））のハッシュに送られる。８行目のＣＴは、複数の３２バイトのフラグメントとして計算され、暗号化およびスクランブルが同時に実行される。これは、ＡＶＸ２などのＳＩＭＤ（Ｓｉｎｇｌｅ Ｉｎｓｔｕｒｃｔｉｏｎ ｏｎ Ｍｕｌｔｉｐｌｅ ｐｉｅｃｅｓ ｏｆ Ｄａｔａ）命令を有するコンピュータアーキテクチャで役立つ。上記アルゴリズムではＭＩＣも暗号化される。ＭＩＣも暗号化すると、暗号化およびスクランブルの両方でループ長が同じになるという利点がある。上記アルゴリズムでは、１２行目で、メッセージの最後の方のバイト（＜３２）の暗号化／スクランブルが計算される。
【0243】
別の追加の潜在的な変形例では、ディスカバリメッセージの大部分は暗号化されない。例えば、メタデータなどの任意選択のフィールドの暗号化は、アプリケーション層に任せられるため、実行されない。しかし、追跡を避けるために、ディスカバリメッセージ全体がスクランブルされる。以下のアルゴリズムでは、任意選択のフィールドが固定フィールドの前に配置される。
【表13】
【0244】
上記と類似する別の追加の潜在的な変形例では、ディスカバリメッセージの一部、例えば、固定フィールドのみが完全性／暗号化保護され、ディスカバリメッセージ全体がスクランブルされる。主な理由は、ディスカバリメッセージ内の一部のフィールドのセキュリティはアプリケーションに任せられる可能性があるが（例えば、メタデータ）、セキュリティ機能はそれでも、ディスカバリメッセージを送信するＵＥを追跡できないようにする必要があるからである。
【0245】
別の追加の潜在的な変形例では、ディスカバリメッセージの保護はまずメッセージの最初の部分（例えば、最初の３２バイト）に適用され、その後、メッセージの残りの（または２番目の）部分に適用される。ここでの目標は、ディスカバリセキュリティルーチンによってスクランブル／暗号化／完全性保護される（メッセージの最初の部分に位置する）固定フィールドのサイズをできるだけ短く、例えば３２バイト以下に保つことである。これにより、ソースレイヤ２ ＩＤ、宛先レイヤ２ ＩＤ、リレーサービスコード、アナウンサ情報、または追加パラメータなどのディスカバリメッセージフィールドの処理を、単一のＫＤＦ呼び出しを使用して可能な限り効率的に実行することができる。別の理由は、メッセージ長が長い場合、例えば９０００バイトに近い場合、攻撃者が実際の短いディスカバリメッセージを変更して、長いメッセージ長を示すおそれがあるという事実に関連している。
【0246】
攻撃者は、長さフィールドの特定のビットを反転することで長さを変更できる。攻撃者がこれをできる理由は、スクランブルがＸＯＲ演算によって行われるからである。これにより、受信側ＵＥは、ディスカバリメッセージ全体に関連付けられたＭＩＣのスクランブル解除、復号、および最終的なチェックに多大なエネルギーを費やす可能性がある。これにより、例えばサービス拒否攻撃が容易になる可能性がある。したがって、代替案は、初期ステップでディスカバリメッセージの最初の部分（例えば、最初の３２バイト）のみを処理（スクランブル解除、復号、および完全性チェック）することにある。メッセージの最初の部分に関連付けられたＭＩＣ検証が成功し、メッセージの最初の部分が、２番目の部分（例えば、長さフィールド＞３２バイト）の存在を示している場合、受信側ＵＥはメッセージの残りの部分の処理（スクランブル解除、復号、完全性チェック）に進むことができる。したがって、ディスカバリメッセージは２つのＭＩＣ、すなわち、最初の３２－ＬＭＩＣバイト用のＭＩＣ（例えば、ＭＩＣの長さがＬＭＩＣ＝４バイトの場合は２８バイト）と、メッセージの残りのバイト用の第２のＭＩＣとを含む可能性がある。ディスカバリメッセージはまた、メッセージの最初の部分、例えばメッセージの最初の３２バイトの中に、メッセージの残りの部分から計算された（切り捨てられた）ハッシュＨと、メッセージの最初の部分の完全性を検証する（Ｈの完全性を検証することを含む）ＭＩＣとを含み得る。メッセージの最初の部分の中のＭＩＣの検証が成功した場合、受信側ＵＥはメッセージの残りの部分の処理に進むことができる。メッセージの残りの部分の完全性検証は、メッセージの残りの部分から計算されたハッシュ値が、メッセージの最初の部分に含まれ、かつメッセージの最初の部分に含まれるＭＩＣを用いて検証される値Ｈと等しいかをチェックすることによって行われる。Ｈは、平文形式、暗号化された形式、またはスクランブルされた形式のメッセージの２番目の部分の（切り捨てられた）ハッシュを指す可能性があることに留意されたい。この最後のケース（スクランブルされた形式）では、受信側ＵＥは、メッセージの２番目の部分がまだスクランブルされている状態（すなわち、受信直後）で、２番目の部分の切り捨てられたハッシュを計算し、それをメッセージの最初の部分に含まれていたＨ値と比較することができる。これが成功した場合、受信側ＵＥはメッセージの２番目の部分のスクランブルの解除に進むことができる。ＭＩＣは、ＴＳ３３．３０３の項６．１．３．４．３．４に従って計算され得る。
【0247】
ディスカバリメッセージを送信するときのメッセージの処理は次の通りである。
１．ディスカバリメッセージを形成する（例えば、プレフィックスのみが割り当てられている場合はサフィックスを追加する）。
２．メッセージの最初の部分用にＤＵＩＫが提供された場合はＭＩＣを計算し、そうでない場合はＭＩＣを全てゼロに設定する。
３．ＤＵＣＫを受信した場合、メッセージ固有機密性をメッセージの最初の部分に追加する。
４．ステップ３の出力にＭＩＣを添付する。
５．ＤＵＳＫを受信した場合、ステップ４の出力にスクランブルを追加する。
６．ＤＵＩＫ２が提供された場合、および／またはメッセージの２番目の部分が完全性保護を必要とする場合はＭＩＣを計算し保護、そうでない場合はＭＩＣを全てゼロに設定する。
７．ＤＵＣＫ２が受信された場合、および／またはメッセージの２番目の部分が機密性保護を必要とする場合、メッセージ固有機密性をメッセージの２番目の部分に追加する。
８．ステップ７の出力にＭＩＣを添付する。
９．ＤＵＳＫ２が受信された場合、および／またはメッセージの２番目の部分がスクランブル保護を必要とする場合、ステップ８の出力にスクランブルを追加する。
１．ディスカバリメッセージを形成する（例えば、プレフィックスのみが割り当てられている場合はサフィックスを追加する）。
２．メッセージの最初の部分用にＤＵＩＫが提供された場合はＭＩＣを計算し、そうでない場合はＭＩＣを全てゼロに設定する。
３．ＤＵＣＫを受信した場合、メッセージ固有機密性をメッセージの最初の部分に追加する。
４．ステップ３の出力にＭＩＣを添付する。
５．ＤＵＳＫを受信した場合、ステップ４の出力にスクランブルを追加する。
６．ＤＵＩＫ２が提供された場合、および／またはメッセージの２番目の部分が完全性保護を必要とする場合はＭＩＣを計算し保護、そうでない場合はＭＩＣを全てゼロに設定する。
７．ＤＵＣＫ２が受信された場合、および／またはメッセージの２番目の部分が機密性保護を必要とする場合、メッセージ固有機密性をメッセージの２番目の部分に追加する。
８．ステップ７の出力にＭＩＣを添付する。
９．ＤＵＳＫ２が受信された場合、および／またはメッセージの２番目の部分がスクランブル保護を必要とする場合、ステップ８の出力にスクランブルを追加する。
【0248】
このアルゴリズムでは、ＤＵＩＫ２、ＤＵＳＫ２、ＤＵＣＫ２は、ＤＵＩＫ、ＤＵＳＫ、ＤＵＣＫに対応してもよく、または異なる鍵であってもよい（例えば、アプリケーションに依存するもの）。２番目の部分が保護を必要とするか否かはポリシーに基づいている可能性がある。メッセージを作成するとき、上記ステップのうちの一部が配置変更されてもよく、例えば、ステップ６がステップ２の後に、ステップ７がステップ３の後に、ステップ８がステップ４の後に、ステップ９がステップ５の後に行われてもよい。同様に、ステップ６が、（平文）メッセージの２番目の部分の切り詰められたハッシュＨを計算し、この計算をステップ２の前に実行するように変更されてもよい。その場合、ステップ２で、メッセージの最初の部分に含まれるＭＩＣが、入力としてＨを使用して計算され、Ｈは、メッセージの最初の部分内のフィールドとして含められる。同様に、ステップ９が、メッセージの２番目の部分のスクランブルされたバージョンから切り捨てられたハッシュＨ’を追加で計算し、この計算をステップ２の前に実行するように変更されてもよい。その場合、ステップ２で、入力としてＨ’を使用してＭＩＣが計算され、Ｈ’は、メッセージの最初の部分のフィールドとして含められる。
【0249】
メッセージの受信時、受信側ＵＥはまずメッセージの最初の部分を処理し、次にメッセージの２番目の部分を処理すべきである。
１．ＤＵＳＫが受信された場合は、メッセージの最初の部分のスクランブルを解除する。
２．任意選択で、一致のチェックが行われる。一致が存在しない場合は処理が中止される。
３．ＤＵＣＫが受信された場合は、メッセージの最初の部分を復号する。
４．任意選択で、完全照合を行い、一致しない場合は処理を中止する。
５．ＤＵＩＫが受信された場合は、メッセージの最初の部分のＭＩＣを検証する。ＭＩＣ検証が失敗した場合は、処理を中止する。
６．メッセージの最初の部分に長さフィールド＞３２が存在するか、またはメッセージの最初の部分のマスクがさらなるフィールドを示している場合において、ＤＵＳＫ２が受信された場合、および／またはメッセージの２番目の部分にスクランブル保護が必要な場合は、メッセージの２番目の部分のスクランブルを解除する。
７．メッセージの最初の部分に長さフィールド＞３２が存在するか、またはメッセージの最初の部分のマスクがさらなるフィールドを示している場合において、ＤＵＣＫ２が受信された場合、および／またはメッセージの２番目の部分に暗号化保護が必要な場合は、メッセージの２番目の部分を復号する。
８．メッセージの最初の部分に長さフィールド＞３２が存在するか、またはメッセージの最初の部分のマスクがさらなるフィールドを示している場合において、ＤＵＩＫ２が受信された場合、および／またはメッセージの２番目の部分に完全性保護が必要な場合は、メッセージの２番目の部分の完全性を検証する。
１．ＤＵＳＫが受信された場合は、メッセージの最初の部分のスクランブルを解除する。
２．任意選択で、一致のチェックが行われる。一致が存在しない場合は処理が中止される。
３．ＤＵＣＫが受信された場合は、メッセージの最初の部分を復号する。
４．任意選択で、完全照合を行い、一致しない場合は処理を中止する。
５．ＤＵＩＫが受信された場合は、メッセージの最初の部分のＭＩＣを検証する。ＭＩＣ検証が失敗した場合は、処理を中止する。
６．メッセージの最初の部分に長さフィールド＞３２が存在するか、またはメッセージの最初の部分のマスクがさらなるフィールドを示している場合において、ＤＵＳＫ２が受信された場合、および／またはメッセージの２番目の部分にスクランブル保護が必要な場合は、メッセージの２番目の部分のスクランブルを解除する。
７．メッセージの最初の部分に長さフィールド＞３２が存在するか、またはメッセージの最初の部分のマスクがさらなるフィールドを示している場合において、ＤＵＣＫ２が受信された場合、および／またはメッセージの２番目の部分に暗号化保護が必要な場合は、メッセージの２番目の部分を復号する。
８．メッセージの最初の部分に長さフィールド＞３２が存在するか、またはメッセージの最初の部分のマスクがさらなるフィールドを示している場合において、ＤＵＩＫ２が受信された場合、および／またはメッセージの２番目の部分に完全性保護が必要な場合は、メッセージの２番目の部分の完全性を検証する。
【0250】
上記したように、メッセージの２番目の部分の完全性保護は、メッセージの２番目の部分に含まれるＭＩＣを用いることによって、またはメッセージの２番目の部分のフィンガープリントＨをメッセージの最初の部分に含めることによって達成され得る。フィンガープリントＨは、メッセージの最初の部分に含まれるＭＩＣを用いることによって検証される。メッセージの２番目の部分の暗号化／スクランブルは、ＫＤＦを１回以上呼び出すことによって実行される。メッセージ全体の全体的な暗号化／スクランブルは、ＫＤＦを複数回呼び出すことによって実行される。例えば、メッセージの最初の部分が、メッセージのスクランブルされた２番目の部分の関数（例えば、切り捨てられたハッシュ）に対応するフィンガープリントＨ’を含む場合、ステップ５の後、受信側ＵＥは、受信したメッセージのスクランブルされた２番目の部分から取得されたハッシュ値が、受信および検証されたＨ’値と一致するかをチェックする。一致する場合、受信側ＵＥはスクランブルを解除し（ステップ６）、復号を行う（ステップ７）。完全性検証（ステップ８）は厳密には必須ではない。
【0251】
ディスカバリメッセージは、常に存在し、パフォーマンス上の理由から長さが制限されたフィールドをいくつか有する可能性があるため、最後のアルゴリズムで説明したような処理が適している。さらに、追加の（任意選択の）フィールドは、アプリケーションによって完全性保護／暗号化され得る。しかし、追跡を防ぐために、全てのフィールド、例えばディスカバリメッセージ全体にスクランブルが適用される可能性がある。また、そのような大量のメッセージが変更されていないことを保証することが必要となる可能性がある。例えば、ＴＳ２４．３３４の項１１．２．５は、ディスカバリメッセージの定義、例えば、オープンＰｒｏＳｅ直接ディスカバリ用のＰＣ５ディスカバリメッセージの内容を含む。
【表14】
【0252】
さらに、次のことが提案されている。「ＵＥの実装形態に応じて、アプリケーション層ディスカバリメッセージは、ＰＣ５上のユーザトラフィックとして、または項６．３．２．１項で指定されているＰＣ５直接ディスカバリメッセージ内のメタデータの一部として交換される。後者の場合、ＰＣ５直接ディスカバリメッセージは、アプリケーション層メタデータ情報（例えば、グループディスカバリ用のアプリケーション層ディスカバリメッセージ）を有する追加フィールドを含み得る。この追加フィールドの形式および内容は３ＧＰＰ（登録商標）の範囲外である。結果として得られるＰＣ５直接ディスカバリメッセージのサイズが大きすぎる場合、アプリケーション層情報を含むＰＣ５直接ディスカバリメッセージのパフォーマンスが影響を受け、例えば、遅延が長くなり、信頼性が低下する。」情報がメタデータの一部として交換される場合、メッセージは、ＬＴＥのメッセージサイズ（例えば、２３バイト）よりも長くなる可能性がある。したがって、最初の、例えば２３バイトまたは２８バイト（ディスカバリメッセージの最初の部分）は、上記したように、ＬＴＥで行われるのと同様の方法で完全性／暗号化保護され、メタデータを含むディスカバリメッセージ全体がスクランブルされる可能性がある。メッセージの最初の部分は、メッセージのスクランブルされた２番目の部分の切り捨てられたハッシュを含み得る。メッセージの最初の部分が最初に処理（スクランブル解除、復号、完全性チェック）された後、メッセージの２番目の部分の完全性がＨ値を用いて検証され得、最後にメッセージの２番目の部分のスクランブルが解除され得る。
【0253】
メッセージの最初の部分が最初のステップで処理（スクランブル、暗号化、完全性検証）され、メッセージの２番目の部分が２番目のステップで処理（スクランブル、暗号化、完全性検証）されたとしても、送信側ＵＥによるディスカバリメッセージのスクランブル（または暗号化）、および受信側ＵＥによるディスカバリメッセージのスクランブル解除（または復号）は依然として、複数回のＫＤＦ呼び出しを必要とすることに留意されたい。したがって、以前に示したように、スクランブル／暗号化のための疑似乱数列の生成は依然として実行される可能性がある。
【0254】
ある代替的実施形態では、メタデータなどの一部の（任意選択の）フィールドは、アプリケーションの決定に従って暗号化／完全性保護され得る。しかし、ディスカバリメッセージは、アプリケーションがメタデータの暗号化／完全性保護するために使用する対称鍵（例えば、ＤＵＩＫ２、ＤＵＳＫ２、ＤＵＣＫ２の生成に使用されるマスター鍵）を保持するために使用できる新しいフィールドを含むように拡張されている。新しいフィールドであるメタデータ鍵も含めることができ、同様に保護することができる。このような新しいフィールドが存在する場合（例えば、０ｘ０００・・・０００以外の値）、これはメタデータなどの他のフィールドの復号／完全性検証に使用される。
【0255】
上記実施形態の例示的なインスタンスでは、ＰＣ５インターフェースを介してディスカバリメッセージを保護するために３つのタイプのセキュリティアルゴリズム、すなわち、ＴＳ３３．３０３［４］の項６．１．３．４．３で定義されている完全性保護、スクランブル保護、およびメッセージ固有機密性が使用される。これらのアルゴリズムは、可変長のディスカバリメッセージを保護するようにＴＳ３３．３０３［４］を拡張するスクランブルアルゴリズムおよび機密性アルゴリズムの以下のように変更された処理とともに適用される。
【0256】
スクランブル保護：送信（受信）時の全体的プロセス
ＵＥがメッセージを送信（または受信）するとき、以下のステップに従ってスクランブル（スクランブル解除）が行われる。
ａ）このスクランブル計算のみを目的として、ＵＴＣベースのカウンタの４つのＬＳＢをゼロに設定する。
ｂ）鍵付きハッシュ関数を通過されるＤＵＳＫおよびＵＴＣベースのカウンタ（ステップ１のように変更されたもの）からタイムハッシュビットシーケンスを計算する。
ａ．タイムハッシュビットシーケンス＝“”
ｂ．ｉ＝０～ＦＬＯＯＲ（（Ｌ＋ＬＭＩＣ）／３２））について、
ｉ．タイムハッシュビットシーケンス＝タイムハッシュビットシーケンス｜｜ＫＤＦ（ＤＵＳＫ，ＵＴＣベースのカウンタ，ｉ）
ｃ．タイムハッシュビットシーケンス＝タイムハッシュビットシーケンス｜｜ＬＳＢ（ＫＤＦ（ＤＵＳＫ，ＵＴＣベースのカウンタ，ＦＬＯＯＲ（（Ｌ＋ＬＭＩＣ）／３２））＋１），８＊（Ｌ＋ＬＭＩＣ－３２＊ＦＬＯＯＲ（（Ｌ＋ＬＭＩＣ）／３２）））
ｃ）タイムハッシュビットシーケンスを、処理中のディスカバリメッセージ全体（ＭＩＣを含む）とＸＯＲする。
ＵＥがメッセージを送信（または受信）するとき、以下のステップに従ってスクランブル（スクランブル解除）が行われる。
ａ）このスクランブル計算のみを目的として、ＵＴＣベースのカウンタの４つのＬＳＢをゼロに設定する。
ｂ）鍵付きハッシュ関数を通過されるＤＵＳＫおよびＵＴＣベースのカウンタ（ステップ１のように変更されたもの）からタイムハッシュビットシーケンスを計算する。
ａ．タイムハッシュビットシーケンス＝“”
ｂ．ｉ＝０～ＦＬＯＯＲ（（Ｌ＋ＬＭＩＣ）／３２））について、
ｉ．タイムハッシュビットシーケンス＝タイムハッシュビットシーケンス｜｜ＫＤＦ（ＤＵＳＫ，ＵＴＣベースのカウンタ，ｉ）
ｃ．タイムハッシュビットシーケンス＝タイムハッシュビットシーケンス｜｜ＬＳＢ（ＫＤＦ（ＤＵＳＫ，ＵＴＣベースのカウンタ，ＦＬＯＯＲ（（Ｌ＋ＬＭＩＣ）／３２））＋１），８＊（Ｌ＋ＬＭＩＣ－３２＊ＦＬＯＯＲ（（Ｌ＋ＬＭＩＣ）／３２）））
ｃ）タイムハッシュビットシーケンスを、処理中のディスカバリメッセージ全体（ＭＩＣを含む）とＸＯＲする。
【0257】
ここで、Ｌはディスカバリメッセージの長さであり、ＬＭＩＣはＭＩＣの長さ（例えば、４バイト）であり、｜｜は連結を示し、ＬＳＢ（ｘ，ｂ）は、ｘのｂ個の最下位ビットを返し、ＦＬＯＯＲ（ｘ）は、ｘ以下の最大の整数を返し、ＣＥＩＬ（ｘ）は、ｘ以上の最小の整数を返し、ＫＤＦ（）は、次のような鍵導出関数を指す。
【0258】
ディスカバリ用のタイムハッシュビットシーケンスを計算するとき、ＴＳ３３．２２０［５］の付録Ｂに記載されているＫＤＦへの入力Ｓを形成するために次のパラメータが使用される。
－ ＦＣ＝一意の識別子。
－ Ｐ０＝ディスカバリスロットに関連付けられたスクランブル用のＵＴＣベースのカウンタ（小項６．１．３．４．３．５を参照）。
－ Ｌ０＝上記の長さ（すなわち、０ｘ００ ０ｘ０４）。
－ Ｐ１＝メッセージフラグメントインデックス。
－ Ｌ１＝上記の長さ（すなわち、０ｘ００ ０ｘ０２）。
－ ＦＣ＝一意の識別子。
－ Ｐ０＝ディスカバリスロットに関連付けられたスクランブル用のＵＴＣベースのカウンタ（小項６．１．３．４．３．５を参照）。
－ Ｌ０＝上記の長さ（すなわち、０ｘ００ ０ｘ０４）。
－ Ｐ１＝メッセージフラグメントインデックス。
－ Ｌ１＝上記の長さ（すなわち、０ｘ００ ０ｘ０２）。
【0259】
入力鍵は２５６ビットＤＵＳＫ。
【0260】
Ｌ１のバイト長は、最大９０００バイトを保護するために必要な最小バイト長である２である。Ｐ１は、ディスカバリメッセージ内の３２バイトのフラグメントまたはブロックを指す。
【0261】
長さＬのディスカバリメッセージの場合、合計ＣＥＩＬ（（Ｌ＋ＬＭＩＣ）／３２）回のＫＤＦ呼び出しが必要となり、それぞれが異なるＰ１値を有する。
【0262】
スクランブルビットシーケンスは、最初のＦＬＯＯＲ（（Ｌ＋ＬＭＩＣ）／３２）回のＫＤＦ呼び出しのＫＤＦ出力全体と、最後のＫＤＦ呼び出しの出力のＲ＝８（Ｌ＋ＬＭＩＣ－３２＊ＦＬＯＯＲ（（Ｌ＋ＬＭＩＣ）／３２））個の最下位ビットとの連結に設定される。
【0263】
機密性保持：送信（受信）時の全体的プロセス
ＵＥがメッセージを送信（または受信）するとき、以下のステップに従って暗号化（復号）が行われる。
ａ）Ｋｅｙ＿ｃａｌｃ＿ｍａｓｋ＝（Ｅｎｃｒｙｐｔｅｄ＿ｂｉｔｓ＿ｍａｓｋ ＸＯＲ ０ｘＦＦ・・・ＦＦ）｜｜０ｘＦＦＦＦＦＦＦＦを計算する
ｂ）ＫＤＦを使用して次のように鍵ストリームを取得する
ａ．鍵ストリーム＝“”
ｂ．ＨＨ＝（Ｋｅｙ＿ｃａｌｃ＿ｍａｓｋ ＡＮＤ （メッセージ｜｜ＭＩＣ））あるいは
ＨＨ＝Ｈａｓｈ（（Ｋｅｙ＿ｃａｌｃ＿ｍａｓｋ ＡＮＤ （メッセージ｜｜ＭＩＣ）））
ｃ．ｉ＝０～ＦＬＯＯＲ（Ｌ／３２）について、
ｉ．鍵ストリーム＝鍵ストリーム｜｜ＫＤＦ（ＤＵＣＫ，ＵＴＣベースのカウンタ，ｉ，ＨＨ）。
ｄ．鍵ストリーム＝鍵ストリーム｜｜ＬＳＢ（ＫＤＦ（ＤＵＣＫ，ＵＴＣベースのカウンタ，ＦＬＯＯＲ（Ｌ／３２）＋１，ＨＨ），８＊（Ｌ－３２＊ＦＬＯＯＲ（Ｌ／３２）））
ａ）メッセージ内へＸＯＲ（Ｋｅｙｓｔｒｅａｍ ＡＮＤ Ｅｎｃｒｙｐｔｅｄ＿ｂｉｔｓ＿ｍａｓｋ）する。
ＵＥがメッセージを送信（または受信）するとき、以下のステップに従って暗号化（復号）が行われる。
ａ）Ｋｅｙ＿ｃａｌｃ＿ｍａｓｋ＝（Ｅｎｃｒｙｐｔｅｄ＿ｂｉｔｓ＿ｍａｓｋ ＸＯＲ ０ｘＦＦ・・・ＦＦ）｜｜０ｘＦＦＦＦＦＦＦＦを計算する
ｂ）ＫＤＦを使用して次のように鍵ストリームを取得する
ａ．鍵ストリーム＝“”
ｂ．ＨＨ＝（Ｋｅｙ＿ｃａｌｃ＿ｍａｓｋ ＡＮＤ （メッセージ｜｜ＭＩＣ））あるいは
ＨＨ＝Ｈａｓｈ（（Ｋｅｙ＿ｃａｌｃ＿ｍａｓｋ ＡＮＤ （メッセージ｜｜ＭＩＣ）））
ｃ．ｉ＝０～ＦＬＯＯＲ（Ｌ／３２）について、
ｉ．鍵ストリーム＝鍵ストリーム｜｜ＫＤＦ（ＤＵＣＫ，ＵＴＣベースのカウンタ，ｉ，ＨＨ）。
ｄ．鍵ストリーム＝鍵ストリーム｜｜ＬＳＢ（ＫＤＦ（ＤＵＣＫ，ＵＴＣベースのカウンタ，ＦＬＯＯＲ（Ｌ／３２）＋１，ＨＨ），８＊（Ｌ－３２＊ＦＬＯＯＲ（Ｌ／３２）））
ａ）メッセージ内へＸＯＲ（Ｋｅｙｓｔｒｅａｍ ＡＮＤ Ｅｎｃｒｙｐｔｅｄ＿ｂｉｔｓ＿ｍａｓｋ）する。
【0264】
ここで、Ｌはディスカバリメッセージの長さであり、ＬＭＩＣはＭＩＣの長さ（例えば、４バイト）であり、｜｜は連結を示し、ＬＳＢ（ｘ，ｂ）は、ｘのｂ個の最下位ビットを返し、ＦＬＯＯＲ（ｘ）は、ｘ以下の最大の整数を返し、ＣＥＩＬ（ｘ）は、ｘ以上の最小の整数を返し、ＫＤＦ（）は、次のような鍵導出関数を指す。
【0265】
ディスカバリ用のメッセージ固有機密性を計算するとき、ＴＳ３３．２２０［５］の付録Ｂに記載されているＫＤＦへの入力Ｓを形成するために次のパラメータが使用される。
【0266】
－ ＦＣ＝一意の識別子
－ Ｐ０＝ディスカバリスロットに関連付けられたＵＴＣベースのカウンタ。
－ Ｌ０＝上記の長さ（すなわち、０ｘ００ ０ｘ０４）。
－ Ｐ１＝メッセージフラグメントインデックス。
－ Ｌ１＝上記の長さ（すなわち、０ｘ００ ０ｘ０２）。
－ Ｐ２＝ＨＨ。
－ Ｌ２＝ＨＨの長さ。
－ Ｐ０＝ディスカバリスロットに関連付けられたＵＴＣベースのカウンタ。
－ Ｌ０＝上記の長さ（すなわち、０ｘ００ ０ｘ０４）。
－ Ｐ１＝メッセージフラグメントインデックス。
－ Ｌ１＝上記の長さ（すなわち、０ｘ００ ０ｘ０２）。
－ Ｐ２＝ＨＨ。
－ Ｌ２＝ＨＨの長さ。
【0267】
入力鍵は２５６ビットＤＵＣＫとする。
【0268】
長さＬのディスカバリメッセージの場合、合計ＣＥＩＬ（Ｌ／３２）回のＫＤＦ呼び出しが必要となり、それぞれが異なるＰ１値を有する。ＭＩＣを暗号化する必要がある場合は、ＬＭＩＣも含める必要がある。
【0269】
メッセージ固有機密性鍵ストリームは、最初のＦＬＯＯＲ（Ｌ／３２）回のＫＤＦ呼び出しのＫＤＦ出力と、最後のＫＤＦ呼び出しの出力のＲ＝８（Ｌ－３２＊ＦＬＯＯＲ（Ｌ／３２））個の最下位ビットとの連結に設定される。
【0270】
上記ソリューションではＭＩＣも暗号化され得る。ＭＩＣが暗号化される場合、長さは（Ｌのみではなく）Ｌ＋ＬＭＩＣに設定する必要があり、ここでＬＭＩＣはＭＩＣの長さである。
【0271】
上記実施形態の例示的なインスタンスでは、ＰＣ５インターフェースを介してディスカバリメッセージを保護するために３つのタイプのセキュリティアルゴリズム、すなわち、ＴＳ３３．３０３［４］の項６．１．３．４．３で定義されている完全性保護、スクランブル保護、およびメッセージ固有機密性が使用される。これらのアルゴリズムは、以下を実行することによってディスカバリメッセージを保護するように拡張される。
【0272】
まず、固定フィールドを含むディスカバリメッセージの短い最初の部分を処理（完全性保護、機密性、スクランブル）し、成功した場合、
その後、メタデータなどの可変長の任意選択のフィールドを含むメッセージの長い２番目の部分を処理（完全性保護、機密性、スクランブル）する。
その後、メタデータなどの可変長の任意選択のフィールドを含むメッセージの長い２番目の部分を処理（完全性保護、機密性、スクランブル）する。
【0273】
図２は、ディスカバリメッセージの構造を示す。最初の短い部分には、リレーサービスコードなどの固定フィールドが含まれる。これらのフィールドには以下のものが含まれる。
メッセージの２番目の部分に任意選択のフィールドが存在することを示す１ビット長の任意選択のフィールドＯ、
メッセージの２番目の部分の任意選択のフィールドの長さを示す１４ビット長のフィールドＬ、
メッセージの２番目の部分から取得された２５ビット長の切り捨てられたハッシュフィールドＨ、および
メッセージの最初の部分に含まれるフィールド上で計算された３２ビットのメッセージ完全性コード（ＭＩＣ）。
メッセージの２番目の部分に任意選択のフィールドが存在することを示す１ビット長の任意選択のフィールドＯ、
メッセージの２番目の部分の任意選択のフィールドの長さを示す１４ビット長のフィールドＬ、
メッセージの２番目の部分から取得された２５ビット長の切り捨てられたハッシュフィールドＨ、および
メッセージの最初の部分に含まれるフィールド上で計算された３２ビットのメッセージ完全性コード（ＭＩＣ）。
【0274】
可能なインスタンスとして、フィールドＯ、Ｌ、Ｈの長さがそれぞれ１ビット、１４ビット、および２５ビットであるものが挙げられる。合計４０ビットなので、メッセージの最初の部分の合計長は３２バイトになる。これらのフィールドは暗黙的に送信される可能性もある。例えば、メタデータの最初の３バイトはメタデータＩＥおよび長さを含む。
【0275】
ディスカバリメッセージを送信するときのメッセージの処理は次の通りである。
１．メッセージの２番目の部分用にＤＵＩＫが提供された場合はＭＩＣ２を計算し、そうでない場合はＭＩＣ２を全てゼロに設定する。
２．ＤＵＣＫが受信された場合、および／またはメッセージの２番目の部分が機密性保護を必要とする場合、メッセージ固有機密性をメッセージの２番目の部分に追加する。
３．ステップ３の出力にＭＩＣ２を添付する。
４．ＤＵＳＫを受信した場合、ステップ４の出力にスクランブルを追加する。
５．メッセージの２番目の部分（ステップ４の出力）の切り捨てられたハッシュＨを計算する。
６．ディスカバリメッセージを形成し（例えば、プレフィックスのみが割り当てられている場合はサフィックスを追加し）、フィールドＯ、Ｌ、およびＨを添付する。
７．ＤＵＩＫが提供された場合はメッセージの最初の部分（最大Ｈ）用のＭＩＣ１を計算し、そうでない場合はＭＩＣ１を全て０に設定する。
８．ＤＵＣＫを受信した場合、メッセージ固有機密性をメッセージの最初の部分に追加する。
９．ステップ８の出力にＭＩＣ１を添付する。
１０．ＤＵＳＫを受信した場合、ステップ９の出力にスクランブルを追加する。
１１．ステップ４の出力をステップ１０の出力に添付して、完全なディスカバリメッセージを作成する。
１．メッセージの２番目の部分用にＤＵＩＫが提供された場合はＭＩＣ２を計算し、そうでない場合はＭＩＣ２を全てゼロに設定する。
２．ＤＵＣＫが受信された場合、および／またはメッセージの２番目の部分が機密性保護を必要とする場合、メッセージ固有機密性をメッセージの２番目の部分に追加する。
３．ステップ３の出力にＭＩＣ２を添付する。
４．ＤＵＳＫを受信した場合、ステップ４の出力にスクランブルを追加する。
５．メッセージの２番目の部分（ステップ４の出力）の切り捨てられたハッシュＨを計算する。
６．ディスカバリメッセージを形成し（例えば、プレフィックスのみが割り当てられている場合はサフィックスを追加し）、フィールドＯ、Ｌ、およびＨを添付する。
７．ＤＵＩＫが提供された場合はメッセージの最初の部分（最大Ｈ）用のＭＩＣ１を計算し、そうでない場合はＭＩＣ１を全て０に設定する。
８．ＤＵＣＫを受信した場合、メッセージ固有機密性をメッセージの最初の部分に追加する。
９．ステップ８の出力にＭＩＣ１を添付する。
１０．ＤＵＳＫを受信した場合、ステップ９の出力にスクランブルを追加する。
１１．ステップ４の出力をステップ１０の出力に添付して、完全なディスカバリメッセージを作成する。
【0276】
メッセージの２番目の部分は、独立したメッセージ完全性コードＭＩＣ２を含む。メッセージの２番目の部分の完全性保護は、ディスカバリメッセージの最初の部分に含まれるメッセージ完全性コードＭＩＣ１を用いて検証されるメッセージの２番目の部分の切り捨てられたハッシュによって常に有効になるため、これは必ずしも必要ではない可能性がある。
【0277】
ステップ２、３、４およびステップ７、８、９はＴＳ３３．３０３と同じ順序に従う。ＭＩＣが常に保護されるように、ステップ３～４およびステップ８～９を入れ替えて配置変更することが好ましい。
【0278】
ディスカバリメッセージの受信時の処理は次の通りである。受信側ＵＥはまずメッセージの最初の部分を処理し、次にメッセージの２番目の（任意選択の）部分を処理する。特に、後続するステップは以下の通りである。
１．ＤＵＳＫが受信された場合は、メッセージの最初の部分のスクランブルを解除する。
２．任意選択で、一致のチェックが行われる。一致が存在しない場合は処理が中止される。
３．ＤＵＣＫが受信された場合は、メッセージの最初の部分を復号する。
４．任意選択で、完全照合を行い、一致しない場合は処理を中止する。
５．ＤＵＩＫが受信された場合は、メッセージの最初の部分のＭＩＣ１を検証する。ＭＩＣ１検証が失敗した場合は、処理を中止する。
６．長さフィールド＞３２がメッセージの最初の部分に存在するか、メッセージの最初の部分内のマスクが追加のフィールドまたは任意選択のフィールドを示している場合、
ａ．メッセージのスクランブル／暗号化／完全性保護された２番目の部分の切り捨てられたハッシュが、メッセージの最初の部分内に含まれ、メッセージの最初の部分内で検証される切り捨てられたハッシュフィールドＨに対応する場合。
ｉ．ＤＵＳＫが受信された場合は、メッセージの２番目の部分のスクランブルを解除する。
ｉｉ．ＤＵＣＫが受信された場合は、メッセージの２番目の部分を復号する。
ｉｉｉ．ＤＵＩＫが受信された場合は、メッセージの２番目の部分の完全性を検証する。
１．ＤＵＳＫが受信された場合は、メッセージの最初の部分のスクランブルを解除する。
２．任意選択で、一致のチェックが行われる。一致が存在しない場合は処理が中止される。
３．ＤＵＣＫが受信された場合は、メッセージの最初の部分を復号する。
４．任意選択で、完全照合を行い、一致しない場合は処理を中止する。
５．ＤＵＩＫが受信された場合は、メッセージの最初の部分のＭＩＣ１を検証する。ＭＩＣ１検証が失敗した場合は、処理を中止する。
６．長さフィールド＞３２がメッセージの最初の部分に存在するか、メッセージの最初の部分内のマスクが追加のフィールドまたは任意選択のフィールドを示している場合、
ａ．メッセージのスクランブル／暗号化／完全性保護された２番目の部分の切り捨てられたハッシュが、メッセージの最初の部分内に含まれ、メッセージの最初の部分内で検証される切り捨てられたハッシュフィールドＨに対応する場合。
ｉ．ＤＵＳＫが受信された場合は、メッセージの２番目の部分のスクランブルを解除する。
ｉｉ．ＤＵＣＫが受信された場合は、メッセージの２番目の部分を復号する。
ｉｉｉ．ＤＵＩＫが受信された場合は、メッセージの２番目の部分の完全性を検証する。
【0279】
ステップ６．ａで完全性チェックが既に実行されているため、ステップ６．ａ．ｉｉｉは必ずしも必要ではない可能性がある。
【0280】
ディスカバリメッセージ（の最初の部分および２番目の部分）をスクランブルするために使用されるスクランブルアルゴリズムは、ＴＳ３３．３０３［４］を拡張する以下のステップに従って実行される。
【0281】
１．このスクランブル計算のみを目的として、ＵＴＣベースのカウンタの４つのＬＳＢをゼロに設定する。
【0282】
２．鍵付きハッシュ関数を通過されるＤＵＳＫおよびＵＴＣベースのカウンタ（ステップ１のように変更されたもの）からタイムハッシュビットシーケンスを計算する。
ａ．タイムハッシュビットシーケンス＝“”
ｂ．ｉ＝０～ＦＬＯＯＲ（（Ｌ＋２＊ＬＭＩＣ）／３２）について、
タイムハッシュビットシーケンス＝タイムハッシュビットシーケンス｜｜ＫＤＦ（ＤＵＳＫ，ＵＴＣベースのカウンタ，ｉ）
ｃ．タイムハッシュビットシーケンス＝タイムハッシュビットシーケンス｜｜ＬＳＢ（ＫＤＦ（ＤＵＳＫ，ＵＴＣベースのカウンタ，ＦＬＯＯＲ（（Ｌ＋２＊ＬＭＩＣ）／３２）＋１），８＊（Ｌ＋２＊ＬＭＩＣ－３２＊ＦＬＯＯＲ（（Ｌ＋２＊ＬＭＩＣ）／３２）））
ａ．タイムハッシュビットシーケンス＝“”
ｂ．ｉ＝０～ＦＬＯＯＲ（（Ｌ＋２＊ＬＭＩＣ）／３２）について、
タイムハッシュビットシーケンス＝タイムハッシュビットシーケンス｜｜ＫＤＦ（ＤＵＳＫ，ＵＴＣベースのカウンタ，ｉ）
ｃ．タイムハッシュビットシーケンス＝タイムハッシュビットシーケンス｜｜ＬＳＢ（ＫＤＦ（ＤＵＳＫ，ＵＴＣベースのカウンタ，ＦＬＯＯＲ（（Ｌ＋２＊ＬＭＩＣ）／３２）＋１），８＊（Ｌ＋２＊ＬＭＩＣ－３２＊ＦＬＯＯＲ（（Ｌ＋２＊ＬＭＩＣ）／３２）））
【0283】
３．タイムハッシュビットシーケンスを、処理中のディスカバリメッセージ全体（ＭＩＣを含む）とＸＯＲする。
【0284】
ここで、Ｌはディスカバリメッセージの長さであり、ＬＭＩＣはＭＩＣの長さ（例えば、４バイト）であり、｜｜は連結を示し、ＬＳＢ（ｘ，ｂ）は、ｘのｂ個の最下位ビットを返し、ＦＬＯＯＲ（ｘ）は、ｘ以下の最大の整数を返し、ＣＥＩＬ（ｘ）は、ｘ以上の最小の整数を返し、ＫＤＦ（）は、次のような鍵導出関数を指す。
【0285】
ディスカバリ用のタイムハッシュビットシーケンスを計算するとき、ＴＳ３３．２２０［５］の付録Ｂに記載されているＫＤＦへの入力Ｓを形成するために次のパラメータが使用される。
－ ＦＣ＝一意の識別子。
－ Ｐ０＝ディスカバリスロットに関連付けられたスクランブル用のＵＴＣベースのカウンタ。
－ Ｌ０＝上記の長さ（すなわち、０ｘ００ ０ｘ０４）。
－ Ｐ１＝メッセージフラグメントインデックス。
－ Ｌ１＝上記の長さ（すなわち、０ｘ００ ０ｘ０２）。
－ ＦＣ＝一意の識別子。
－ Ｐ０＝ディスカバリスロットに関連付けられたスクランブル用のＵＴＣベースのカウンタ。
－ Ｌ０＝上記の長さ（すなわち、０ｘ００ ０ｘ０４）。
－ Ｐ１＝メッセージフラグメントインデックス。
－ Ｌ１＝上記の長さ（すなわち、０ｘ００ ０ｘ０２）。
【0286】
入力鍵は２５６ビットＤＵＳＫとする。
【0287】
Ｌ１のバイト長は、最大９０００バイトを保護するために必要な最小バイト長である２である。Ｐ１は、ディスカバリメッセージ内の３２バイトのフラグメントまたはブロックを指す。
【0288】
長さＬのディスカバリメッセージの場合、合計ＣＥＩＬ（（Ｌ＋２＊ＬＭＩＣ）／３２）回のＫＤＦ呼び出しが必要となり、それぞれが異なるＰ１値を有する。
【0289】
スクランブルビットシーケンスは、最初のＦＬＯＯＲ（（Ｌ＋２＊ＬＭＩＣ）／３２）回のＫＤＦ呼び出しのＫＤＦ出力全体と、最後のＫＤＦ呼び出しの出力のＲ＝８（Ｌ＋２＊ＬＭＩＣ－３２＊ＦＬＯＯＲ（（Ｌ＋２＊ＬＭＩＣ）／３２））個の最下位ビットとの連結に設定される。
【0290】
機密性保護は、ＴＳ３３．３０３［４］を拡張する以下のステップに従って実行される。
【0291】
１．Ｋｅｙ＿ｃａｌｃ＿ｍａｓｋ＝（Ｅｎｃｒｙｐｔｅｄ＿ｂｉｔｓ＿ｍａｓｋ１ ＸＯＲ ０ｘＦＦ・・・ＦＦ）｜｜０ｘＦＦＦＦＦＦＦＦ｜｜（Ｅｎｃｒｙｐｔｅｄ＿ｂｉｔｓ＿ｍａｓｋ２ ＸＯＲ ０ｘＦＦ・・・ＦＦ）｜｜０ｘＦＦＦＦＦＦＦＦを計算する
注：Ｅｎｃｒｙｐｔｅｄ＿ｂｉｔｓ＿ｍａｓｋ１およびＥｎｃｒｙｐｔｅｄ＿ｂｉｔｓ＿ｍａｓｋ２は、ＴＳ３３．３０３のＥｎｃｒｙｐｔｅｄ＿ｂｉｔｓ＿ｍａｓｋと同様の役割を果たすが、ディスカバリメッセージの最初の部分および２番目の部分に独立して適用される。
注：Ｅｎｃｒｙｐｔｅｄ＿ｂｉｔｓ＿ｍａｓｋ１およびＥｎｃｒｙｐｔｅｄ＿ｂｉｔｓ＿ｍａｓｋ２は、ＴＳ３３．３０３のＥｎｃｒｙｐｔｅｄ＿ｂｉｔｓ＿ｍａｓｋと同様の役割を果たすが、ディスカバリメッセージの最初の部分および２番目の部分に独立して適用される。
【0292】
２．ＫＤＦを使用して次のように鍵ストリームを取得する
ａ．鍵ストリーム＝“”
ｂ．ＨＨ＝（Ｋｅｙ＿ｃａｌｃ＿ｍａｓｋ ＡＮＤ （Ｍｅｓｓａｇｅ１｜｜ＭＩＣ｜｜Ｍｅｓｓａｇｅ２｜｜ＭＩＣ２））あるいは
ＨＨ＝Ｈａｓｈ（（Ｋｅｙ＿ｃａｌｃ＿ｍａｓｋ ＡＮＤ （Ｍｅｓｓａｇｅ１｜｜ＭＩＣ｜｜Ｍｅｓｓａｇｅ２｜｜ＭＩＣ２）））
ｃ．ｉ＝０～ＦＬＯＯＲ（Ｌ／３２）について、
ｉ．鍵ストリーム＝鍵ストリーム｜｜ＫＤＦ（ＤＵＣＫ，ＵＴＣベースのカウンタ，ｉ，ＨＨ）。
ｄ．鍵ストリーム＝鍵ストリーム｜｜ＬＳＢ（ＫＤＦ（ＤＵＣＫ，ＵＴＣベースのカウンタ，ＦＬＯＯＲ（Ｌ／３２）＋１，ＨＨ），８＊（Ｌ－３２＊ＦＬＯＯＲ（Ｌ／３２）））
ａ．鍵ストリーム＝“”
ｂ．ＨＨ＝（Ｋｅｙ＿ｃａｌｃ＿ｍａｓｋ ＡＮＤ （Ｍｅｓｓａｇｅ１｜｜ＭＩＣ｜｜Ｍｅｓｓａｇｅ２｜｜ＭＩＣ２））あるいは
ＨＨ＝Ｈａｓｈ（（Ｋｅｙ＿ｃａｌｃ＿ｍａｓｋ ＡＮＤ （Ｍｅｓｓａｇｅ１｜｜ＭＩＣ｜｜Ｍｅｓｓａｇｅ２｜｜ＭＩＣ２）））
ｃ．ｉ＝０～ＦＬＯＯＲ（Ｌ／３２）について、
ｉ．鍵ストリーム＝鍵ストリーム｜｜ＫＤＦ（ＤＵＣＫ，ＵＴＣベースのカウンタ，ｉ，ＨＨ）。
ｄ．鍵ストリーム＝鍵ストリーム｜｜ＬＳＢ（ＫＤＦ（ＤＵＣＫ，ＵＴＣベースのカウンタ，ＦＬＯＯＲ（Ｌ／３２）＋１，ＨＨ），８＊（Ｌ－３２＊ＦＬＯＯＲ（Ｌ／３２）））
【0293】
３．メッセージ内へＸＯＲ（Ｋｅｙｓｔｒｅａｍ ＡＮＤ Ｅｎｃｒｙｐｔｅｄ＿ｂｉｔｓ＿ｍａｓｋ）する。
ディスカバリ用のメッセージ固有機密性を計算するとき、ＴＳ３３．２２０［５］の付録Ｂに記載されているＫＤＦへの入力Ｓを形成するために次のパラメータが使用される。
－ ＦＣ＝一意の識別子
－ Ｐ０＝ディスカバリスロットに関連付けられたＵＴＣベースのカウンタ。
－ Ｌ０＝上記の長さ（すなわち、０ｘ００ ０ｘ０４）。
－ Ｐ１＝メッセージフラグメントインデックス。
－ Ｌ１＝上記の長さ（すなわち、０ｘ００ ０ｘ０２）。
－ Ｐ２＝ＨＨ。
－ Ｌ２＝ＨＨの長さ。
ディスカバリ用のメッセージ固有機密性を計算するとき、ＴＳ３３．２２０［５］の付録Ｂに記載されているＫＤＦへの入力Ｓを形成するために次のパラメータが使用される。
－ ＦＣ＝一意の識別子
－ Ｐ０＝ディスカバリスロットに関連付けられたＵＴＣベースのカウンタ。
－ Ｌ０＝上記の長さ（すなわち、０ｘ００ ０ｘ０４）。
－ Ｐ１＝メッセージフラグメントインデックス。
－ Ｌ１＝上記の長さ（すなわち、０ｘ００ ０ｘ０２）。
－ Ｐ２＝ＨＨ。
－ Ｌ２＝ＨＨの長さ。
【0294】
入力鍵は２５６ビットＤＵＣＫとする。
【0295】
長さＬのディスカバリメッセージの場合、合計ＣＥＩＬ（（Ｌ）／３２）回のＫＤＦ呼び出しが必要となり、それぞれが異なるＰ１値を有する。
【0296】
メッセージ固有機密性鍵ストリームは、最初のＦＬＯＯＲ（（Ｌ）／３２）回のＫＤＦ呼び出しのＫＤＦ出力と、最後のＫＤＦ呼び出しの出力のＲ＝８（Ｌ－３２＊ＦＬＯＯＲ（（Ｌ）／３２））個の最下位ビットとの連結に設定される。
【0297】
メッセージの最初の部分および２番目の部分の保護も、異なるアルゴリズムを使用して行われてもよい。例えば、メッセージの最初の部分の完全性および機密性の保護は、ＴＳ３３．３０３でのようにＰＲＦを使用して上記のように実行され得る。メッセージの２番目の部分の完全性および機密性の保護は、標準５Ｇ機密性アルゴリズム（例えば、１２８－ＮＥＡ１、１２８－ＮＥＡ２、１２８－ＮＥＡ３）および完全性アルゴリズム（例えば、１２８－ＮＩＡ１、１２８－ＮＩＡ２、１２８－ＮＩＡ３）のうちの１つを使用して実行され得る。
【0298】
どのＮＩＡまたはＮＥＡアルゴリズムが使用されるかは、ディスカバリメッセージの最初の部分で通知されてもよい。
【0299】
ＴＳ３３．３０３に記載されている保護機構を再利用することで２５６ビットを超える長さのディスカバリメッセージを保護するというＴＳ３３．５０３ ｖ０．２．０の問題に対処する提案されるソリューションは、次の変更を必要とする。（ａ）ＴＳ３３．３０３のＡ．５では、タイムハッシュビットシーケンス鍵ストリームがＫＤＦの出力のＬ個の最下位ビットに設定され、ここで、Ｌは、スクランブルされた後にＭｉｎ（ディスカバリメッセージの長さ－１６，２５６）に設定されるディスカバリメッセージのビット長である。注：スクランブルされるディスカバリメッセージの最大長は２５６ビットに制限され、（ｂ）ＴＳ３３．３０３の項６．１．３．４．３．２では、ＤＵＩＫが提供されなかった場合はＭＩＣが３２ビットのランダム文字列に設定され、（ｃ）メッセージ固有機密性は、ＴＳ３３．５０１［３］の付録Ｄに規定されている１２８－ＮＥＡアルゴリズムによって実現される。ＴＳ３３．５０１の付録Ｄに記載されている１２８－ＮＥＡアルゴリズムへの入力パラメータは次の通りである。ＤＵＣＫの出力の最下位１２８ビットに設定されるＫＥＹ。ＫＤＦ（ＤＵＣＫ，ＵＴＣベースのカウンタ，ＭＩＣ）、ＵＴＣベースのカウンタに設定されるＣＯＵＮＴ、０ｘ００に設定されるＢＥＡＲＥＲ ＡＮＤ ＤＩＲＥＣＴＩＯＮ、ディスカバリメッセージの長さ－メッセージタイプの長さに設定されるＬＥＮＧＴＨ、ＵＴＣベースのカウンタＬＳＢおよびＭＩＣ。次に、暗号化アルゴリズムの出力鍵ストリーム（ｏｕｔｐｕｔ＿ｋｅｙｓｔｒｅａｍ）がＥｎｃｒｙｔｐｅｄ＿ｂｉｔｓ＿ｍａｓｋを用いてマスクされ、メッセージ固有機密性保護用の最終的な鍵ストリーム（ＫＥＹＳＴＲＥＡＭ）が生成される。ここで、ＫＥＹＳＴＲＥＡＭ＝ｏｕｔｐｕｔ＿ｋｅｙｓｔｒｅａｍ ＡＮＤ （Ｅｎｃｒｙｐｔｅｄ＿ｂｉｔｓ＿ｍａｓｋ｜｜０ｘＦＦ・・・ＦＦ）であり、Ｅｎｃｒｙｐｔｅｄ＿ｂｉｔｓ＿ｍａｓｋの長さはＭｉｎ（ディスカバリメッセージの長さ－４８，２２４）に設定される。ＫＥＹＳＴＲＥＡＭは、メッセージ固有機密性保護のためにディスカバリメッセージとＸＯＲ演算され、（ｄ）メッセージ固有機密性のための暗号化アルゴリズムは、ディスカバリリクエスト手順中にＵＥで設定される。
【0300】
しかし、この提案されるソリューションには多くの問題がある。
【0301】
まず、ＫＥＹがＫＤＦ（ＤＵＣＫ，ＵＴＣベースのカウンタ，ＭＩＣ）として計算される。この理由は、ＤＵＣＫからセッション鍵を生成するためである。しかし、（ｉ）ＭＩＣを含めるには、ＭＩＣを平文で交換する必要があり、（ｉｉ）メッセージを暗号化する前にＫＤＦを計算する必要があるため、ＣＰＵ負荷が増加し、（ｉｉｉ）同じディスカバリメッセージが使用される場合、カウンタがラップアラウンドすると同じＫＥＹが生成されるので、この方法でセッション鍵を導出するとＤＵＣＫの寿命が伸びない。この問題を克服するための一実施形態は、ＤＵＣＫもしくはその一部、またはＤＵＣＫから（ＫＤＦによって）直接導出された鍵を使用することにある。一方、このアプローチには、上記実施形態で説明したように、メッセージ全体をＫＤＦに送る必要なく、（ＭＩＣがＫＤＦへの入力として使用されるため）メッセージ依存の鍵ストリームを生成できるという利点がある。ＮＥＡアルゴリズムを用いて生成される後続の鍵ストリームは、この特性を継承する。
【0302】
セッション鍵が生成される場合にこの問題を克服するための一実施形態は、ＫＥＹ＝ＫＤＦ（ＤＵＣＫ，ＵＴＣ－ｔｉｍｅ－ｉｎ－ｓｅｃｏｎｄｓ／ｒｏｔａｔｉｏｎ＿ｒａｔｅ）を生成することにあり、ここで、ｒｏｔａｔｉｏｎ＿ｒａｔｅは、ＫＥＹをローテーションする必要がある頻度を示す。例えば、ｒｏｔａｔｉｏｎ＿ｒａｔｅは８６４００秒（１日）であってもよく、これは、１日に１回新しいＫＥＹが生成されることを意味する。これにより、ＣＰＵ負荷が軽減され、ＤＵＣＫの寿命が長くなる。
【0303】
第二に、メッセージ固有機密性のための暗号化アルゴリズムが、ディスカバリリクエスト手順中にＵＥで設定される。例えば、モデルＡの制限付きディスカバリでは、リモートＵＥ（またはリレーＵＥ）が、そのＵＥがサポートする暗号化アルゴリズムのリストを含む、自身のＰＣ５ ＵＥセキュリティ機能を通知する。応答では、コアネットワーク（例えば、アナウンスを行うＵＥのＨＰＬＭＮ内の５Ｇ ＤＤＮＭＦ）が、選択されたＰＣ５暗号化アルゴリズムをディスカバリ応答メッセージ内に含める必要がある。この問題は、複数のアナウンスするＵＥおよび複数の監視するＵＥが存在する可能性があり、ある選択されたアルゴリズムをサポートする全てのＵＥに対して、セキュリティ機能が対応できない可能性があるために生じる。
【0304】
この問題を克服する一実施形態は、コアネットワークによって選択されたアルゴリズムを含まない、サポートしている暗号アルゴリズムのリストをＵＥが送信した場合、コアネットワークが、サポートされていないアルゴリズムの指標を与えることにある。
【0305】
この問題を克服する一実施形態では、サポートされていないアルゴリズムの表示、または自身がサポートしていないアルゴリズムの選択を受信したＵＥに大して、そのサービスに関連付けられたディスカバリメッセージを送信または処理しないことを要求する。
【0306】
ＤＵＣＫが提供されない可能性があるため、メッセージの一部がスクランブル／暗号化されない可能性があり、これはプライバシーリスクにつながる。この問題を克服する一実施形態は、ＵＥにＤＵＣＫを設定することをコアネットワークに要求し、また、ＵＥによって送信されるディスカバリメッセージの長さが２５６ビットを超える場合、ＤＵＣＫを適用することをＵＥに要求する。あるいは、ＵＥは、２５６ビットより長いメッセージを保護するようにＴＳ３３．３０３のスクランブルアルゴリズムを更新可能な上記実施形態のうちの１つを適用しなければならない。
【0307】
ＴＳ３３．３０３の項６．１．３．４．３．２は、ＭＩＣを計算し、メッセージに機密性を適用し、ＭＩＣを付加し、メッセージ全体をスクランブルする。これらのステップは、ＫＥＹＳＴＲＥＡＭをｏｕｔｐｕｔ＿ｋｅｙｓｔｒｅａｍ ＡＮＤ （Ｅｎｃｒｙｐｔｅｄ＿ｂｉｔｓ＿ｍａｓｋ｜｜０ｘＦＦ・・・ＦＦ）として計算する関連する提案では変更されていない（ここで、Ｅｎｃｒｙｐｔｅｄ＿ｂｉｔｓ＿ｍａｓｋの長さはＭｉｎ（ディスカバリメッセージの長さ－４８，２２４）に設定される）。ＭＩＣはメッセージの最後にあるため、そのような提案によれば、ＭＩＣは常に暗号化される。したがって、そのような提案において提案されているソリューションでは、ＭＩＣを取り出して、ＮＥＡアルゴリズムとともに使用されるＫＥＹを計算することができないため、このような提案で提案されているソリューションは運用上機能することができない。この状況を解決するために、一実施形態では、以下のステップを実行するように、ＴＳ３３．３０３の項６．１．３．４．３．２を変更することが提案される。（１）ＭＩＣまたは別の完全性コンポーネントを計算し、（２）メッセージに機密性を適用し、（３）（機密性が保護された）メッセージをＭＩＣおよびその他の保護されていないフィールド（例えば、メッセージタイプ、ＵＴＣベースのカウンタＬＳＢ）に付加し、（４）メッセージ（の少なくとも最初の部分）をスクランブルする。項６．１．３．４．３．３は、メッセージの復号には、この実施形態に対応する逆の変更を要求する。
【0308】
代替的実施形態は、ＫＥＹＳＴＲＥＡＭの計算を、ｏｕｔｐｕｔ＿ｋｅｙｓｔｒｅａｍ ＡＮＤ （０ｘ００・・・００｜｜Ｅｎｃｒｙｐｔｅｄ＿ｂｉｔｓ＿ｍａｓｋ｜｜０ｘＦＦ・・・ＦＦ）と変更し、ここで、Ｅｎｃｒｙｐｔｅｄ＿ｂｉｔｓ＿ｍａｓｋの長さがＭｉｎ（ディスカバリメッセージの長さ－４８，２２４）に設定され、０ｘ００・・・００の長さは４８ビットであり、メッセージが２７２ビットより長い場合、０ｘＦＦ・・・ＦＦの長さは、ディスカバリメッセージの長さからＥｎｃｒｙｐｔｅｄ＿ｂｉｔｓ＿ｍａｓｋの長さを差し引いたものに等しく、それ以外の場合は０である。これが行われる場合、ＴＳ３３．３０３の項６．１．３．４．３．２は、（１）ＭＩＣまたは別の完全性コンポーネントを計算し、（２）ＭＩＣ（および他の保護されていないフィールド）にメッセージを付加し、（３）メッセージに機密性を適用し、（４）メッセージをスクランブルする。ステップ（３）および（４）は入れ替えることができる。項６．１．３．４．３．３は、この実施形態に対応する逆の変更を要求する。
【0309】
代替的実施形態では、以下のステップを実行するように、ＴＳ３３．３０３の項６．１．３．４．３．２が変更される。（１）ＭＩＣまたは別の完全性コンポーネントを計算し、（２）メタデータまたはグループＩＤなどの任意選択のフィールドの前にＭＩＣを挿入し、（３）メッセージに機密性を適用し、（４）メッセージの（少なくとも最初の部分）をスクランブルする。ステップ（３）および（４）は入れ替えることができる。この場合、ＫＥＹＳＴＲＥＡＭは、ｏｕｔｐｕｔ＿ｋｅｙｓｔｒｅａｍ ＡＮＤ （０ｘ００００｜｜Ｅｎｃｒｙｐｔｅｄ＿ｂｉｔｓ＿ｍａｓｋ｜｜０ｘ００００００００｜｜０ｘＦＦ・・・ＦＦ）として計算され、ここで、０ｘ００００００００はＭＩＣの位置に対応し、０ｘ００００はメッセージタイプ、ＵＴＣベースのカウンタＬＳＢの位置に対応する。項６．１．３．４．３．３は、この実施形態に対応する逆の変更を要求する。
【0310】
代替的実施形態では、以下のステップを実行するように、ＴＳ３３．３０３の項６．１．３．４．３．２が変更される。（１）ＭＩＣまたは別の完全性コンポーネントを計算し、（２）メッセージに機密性を適用し、（３）ＭＩＣを挿入し、（４）メッセージ、特にメッセージの最初の部分およびメッセージの最後の４バイトをスクランブルする。ステップ（３）および（４）は入れ替えることができる。この場合、ＫＥＹＳＴＲＥＡＭはｏｕｔｐｕｔ＿ｋｅｙｓｔｒｅａｍ ＡＮＤ （０ｘ００００｜｜Ｅｎｃｒｙｐｔｅｄ＿ｂｉｔｓ＿ｍａｓｋ｜｜０ｘＦＦ・・・ＦＦ）として計算され、ここで、０ｘ００００は、メッセージタイプ、ＵＴＣベースのカウンタＬＳＢの位置に対応する。項６．１．３．４．３．３は、この実施形態に対応する逆の変更を要求する。
【0311】
先述の実施形態を通じて説明したように、提案される本発明の変形例は、図３に示すように、ネットワーク、例えば５Ｇネットワークとしてのセルラーネットワークに実装することができる。一次局１０００が、ネットワークのあるセルにサービスを提供する。一次局１０００（例えば、ｇＮＢ）のカバレッジ内では、複数の二次局が一次局に接続することができる。一部の二次局は、中継局１０１０として動作するように適合されてもよい。このような中継局は、送信アンテナに結合された送信機１０１１と、受信アンテナに結合された受信機１０１２とを含み得る。通常、受信アンテナと送信アンテナは同じアンテナである。さらに、技術に応じて、アンテナは、ＭＩＭＯ、送信ダイバーシティ、および異なる周波数セットでの動作など、異なる送信／受信モードを可能にするアンテナアレイによって形成されてもよい。
【0312】
コントローラ１０１３、例えば、内部メモリ（例えば、ＲＯＭ、ＥＥＰＲＯＭ、ＳＳＤ）に格納されたソフトウェアとともに動作するＣＰＵまたはマイクロコントローラ（例えば、通信専用のマイクロプロセッサ（ベースバンドプロセッサ）、またはＵＥを含むデバイスのメインマイクロプロセッサ）は、送信機および受信機、並びにアンテナを制御するように適合されている。送信機、受信機、およびコントローラの一部または全てが単一のベースバンドプロセッサの一部であってもよいことに留意されたい。上記実施形態に関して、コントローラは、中継局１０１０と一次局１０００との間の接続を確立するように適合されている。より具体的には、コントローラ１０１３は、一次局１０００からの少なくとも１つの第１の安全なメッセージにおいて、属性またはサービスコードを含む第１の設定パラメータセットを受信するように受信機１０１２を設定することができる。
【0313】
コントローラ１０１３は、送信機１０１１を制御し、送信機１０１１に、第１の設定パラメータセットから少なくとも１つの送信される属性またはサービスコードを送信させることができる。この属性またはサービスコードは、他の局、例えば二次局１０２０または１０３０などによる受信のためにブロードキャストされてもよい。
【0314】
通常、中継局は、サイドリンク対応ＵＥなどのＵＥであり得、したがって、中継局として設定された場合には中継局として動作することができる。あるいは、中継局は、アクセスポイント、ｇＮＢ、フェムトセルｇＮＢなどの別の一次局であってもよい。
【0315】
二次局１０２０（または同様に１０３０）は、典型的にはＵＥであり、送信機１０２１および受信機１０２２を含む。送信機１０２１および受信機１０２２は、典型的には両方、１つ以上のアンテナまたはアンテナアレイに結合される。さらに、二次局１０２０は、受信機１０２１、送信機１０２２、および場合によってはＵＥの他の要素を制御するように適合されたコントローラ１０２３を含む。中継局に関しては、コントローラ１０２３はプロセッサまたはＣＰＵであってもよく、ソフトウェアによって動作してもよい。
【0316】
コントローラ１０２３は、受信部１０２１および送信部１０２２に、一次局１０００との接続を確立させることができる。これは、例えば、これから行われる中継局１０１０とのデータ交換にリンクされた属性または中継サービスコードを含む第２の設定パラメータセットを、少なくとも１つの第２の安全なメッセージにおいて一次局１０００から受信するように受信機１０２１を設定することを含む。
【0317】
受信機１０２１は、中継局１０１０から少なくとも１つの送信された属性またはサービスコードを受信するように構成されてもよく、コントローラは、送信された属性またはサービスコードが第２の設定パラメータセットに含まれるか、またはそれに含まれるポリシーを満たすかを判断し、送信されたサービスコードが第２のセットに含まれると判断された場合、送信機に、中継局１０１０との直接通信を確立させるように設定され得る。
【0318】
二次局１０２０および１０３０は中継局１０１０を介して相互に通信することも可能であってもよい。
【0319】
単一のユニットまたはデバイスが、請求項に記載される複数のアイテムの機能を果たし得る。複数の手段が互いに異なる従属請求項に記載されているからといって、これらの手段の組み合わせを好適に使用することができないとは限らない。
【0320】
図３および図４に示される動作などの説明されている動作は、それぞれ、コンピュータプログラムのプログラムコード手段として、および／または関連する通信デバイスまたはアクセスデバイスの専用ハードウェアとして実装され得る。コンピュータプログラムは、他のハードウェアとともにまたは他のハードウェアの一部として、供給される光学記憶媒体またはソリッドステート媒体等の適切な媒体上で記憶および／または分配されてもよいし、インターネットまたは他の有線もしくは無線テレコミュニケーションシステムを介して等の他の形態で分配されてもよい。
【0321】
図面、開示および添付の特許請求の範囲から、開示の実施形態の他の変形例が、クレームされる発明を実施する当業者によって理解および実現され得る。特許請求の範囲において、「備える／含む」という用語は他の要素またはステップを排除するものではなく、単数形の要素は複数を除外しない。単一のプロセッサまたは他のユニットが請求項に記載される複数のアイテムの機能を果たし得る。複数の手段が互いに異なる従属請求項に記載されているからといって、これらの手段の組み合わせを好適に使用することができないとは限らない。上記説明は、本発明の特定の実施形態を詳述したものである。しかし、上記の内容がどれほど詳細に記載されているかにかかわらず、本発明は多くの方法で実施することができ、したがって開示されている実施形態に限定されないことが理解されるであろう。本発明の特定の特徴または態様を説明する際の特定の用語の使用は、その用語が関連付けられている本発明の特徴または態様の具体的特徴を含むように制限されるように再定義されていることを意味するものと解釈されるべきではないことに留意されたい。
【0322】
さらに、「Ａ、Ｂ、およびＣなどのうちの少なくとも１つ」に類似した慣用表現が使用される場合、一般にそのような構文は、当業者がその慣用表現を理解するであろう意味で意図されており、例えば、「Ａ、Ｂ、およびＣのうちの少なくとも１つを有するシステム」は、限定はされないが、Ａのみ、Ｂのみ、Ｃのみ、ＡおよびＢを一緒に、ＡおよびＣを一緒に、ＢおよびＣを一緒に、並びに／またはＡ、Ｂ、およびＣを一緒に有するシステムなどを含む。「Ａ、Ｂ、またはＣなどのうちの少なくとも１つ」に類似した慣用表現が使用される場合、一般にそのような構文は、当業者がその慣用表現を理解するであろう意味で意図されており、例えば、「Ａ、Ｂ、またはＣのうちの少なくとも１つを有するシステム」は、限定はされないが、Ａのみ、Ｂのみ、Ｃのみ、ＡおよびＢを一緒に、ＡおよびＣを一緒に、ＢおよびＣを一緒に、並びに／またはＡ、Ｂ、およびＣを一緒に有するシステムなどを含む。また、当業者であれば、明細書、特許請求の範囲、または図面のいずれにおいても、２つ以上の択一的な用語を提示する実質的に任意の選言的な単語および／または句は、用語のうちの１つ、いずれかの用語、または両方の用語を含む可能性を企図していると理解するであろう。例えば、「ＡまたはＢ」という表現は「Ａ」または「Ｂ」または「ＡおよびＢ」の可能性を含むと理解されよう。
【図1】
【図2】
【図3】
【国際調査報告】