Bluetooth Mesh 仕様 – Mesh networking(その5)

仕様

はじめに

Bluetooth Meshの仕様について、Bluetooth SIGで公開されている「Mesh Profile Specification 1.0.1」に基づき、学習を兼ねて記載して行こうと思っています。本文章では、3章の「メッシュ ネットワーキング」の次の節について記載いたします。

  • 3.8 メッシュ セキュリティ

記載内容に誤り等がありましたら、ご連絡いただければ幸いです。

3.8 メッシュ セキュリティ

このセクションでは、メッシュセキュリティの実装方法について説明します。

3.8.1 エンディアン

セクション 3.1.1.1 で説明されているように、このレイヤーのすべてのマルチオクテット数値は「ビッグエンディアン」でマーシャリングされるものとします。

3.8.2 セキュリティ ツールボックス

このセクションでは、メッシュネットワーキング用のセキュリティツールボックスを一緒に提供する 8 つの機能について説明します。

3.8.2.1 暗号化機能

コア仕様 [1] のボリューム 3、パート H、セクション 2.2.1 で定義されているものと同じ暗号化機能 e を使用する必要があります。これは次のように要約できます。

暗号文 = e(キー、平文)

3.8.2.2 CMAC 機能

RFC4493 [9] は、AES-CMAC としても知られるブロック暗号機能として AES-128 を使用する暗号ベースのメッセージ認証コード(CMAC)を定義しています。 AES-CMAC への入力は次のとおりです。

k は 128 ビットキーです。

m は認証される可変長データです。

128 ビットのメッセージ認証コード(MAC)は、次のように生成されます1

MAC = AES-CMACk(m)

ノードは、ホストで AES 関数を実装するか、コントローラーで AES 関数を使用するために HCI_LE_Encrypt コマンド(コア仕様 [1] のボリューム 2、パート E、セクション 7.8.22 を参照)を使用できます。

1 これは、他の Bluetooth 仕様で使用されているのと同じ表記法を使用しています。 これは、RFC 4493の表記法と機能的に同じです。ここで、MAC = AES-CMAC(k、m)です。

3.8.2.3 CCM 機能

RFC3610 [10] は、CBC-MAC(CCM)を使用した AES カウンターを定義しています(コア仕様 [1] のボリューム 6、パート E、セクション 1 を参照)。 この仕様では、AES-CCM を、4 つの入力を受け取り、2つの出力をもたらす関数として定義しています。
AES-CCM への入力は次のとおりです。

k は 128 ビットキーです。

n は 104 ビットのナンスです。

m は、暗号化および認証される可変長データであり、「プレーンテキスト」とも呼ばれます。

a は、認証される可変長データです。「追加データ」とも呼ばれます。

暗号文と mic は次のように生成されます。

暗号文、mic = AES-CCMk(n、m、a)

ここで:

暗号文は、暗号化された後の可変長データです。

mic は、m と a のメッセージ整合性チェック値です。RFC3610 [10] では「メッセージ認証コード」または暗号化された認証値 U とも呼ばれます。

k、n、および m パラメータのみが AES-CCM に提供される場合、追加データは長さがゼロでなければなりません。

3.8.2.4 s1 SALT生成関数

関数 s1 への入力は次のとおりです。

M は、長さがゼロ以外のオクテット配列または ASCII エンコード文字列です。

M が ASCII でエンコードされた文字列の場合、各文字列の文字順序を維持した ASCII コードに置き換えることにより、オクテット配列に変換されます。 たとえば、M が文字列「MESH」の場合、これはオクテット配列 0x4d、0x45、0x53、0x48 に変換されます。

ZERO は 128 ビット値です。

0x0000 0000 0000 0000 0000 0000 0000 0000

salt 生成関数 s1 の出力は次のとおりです。

s1(M)= AES-CMACZERO(M)

3.8.2.5 k1 導出関数

ネットワークキーのマテリアル導出関数 k1は、IdentityKey と BeaconKey のインスタンスを生成するために使用されます。

この鍵生成関数の定義では、128 ビット鍵 T を使用した MAC 関数 AES-CMACT を使用します。

関数 k1 への入力は次のとおりです。

N は 0 オクテット以上

SALT は 128 ビットです。

P は 0 オクテット以上

キー(T)は次のように計算されます。

T = AES-CMACSALT(N)

鍵生成関数 k1 の出力は次のとおりです。

k1(N、SALT、P)= AES-CMACT(P)

3.8.2.6 k2 ネットワークキーマテリアル導出関数

ネットワークキーマテリアル導出関数 k2 は、マスターおよびプライベート低電力ノード通信として使用するための EncryptionKey、PrivacyKey、および NID のインスタンスを生成するために使用されます。

この鍵生成関数の定義では、128ビット 鍵 T を使用した MAC 関数 AES-CMACT を使用します。

関数 k2 への入力は次のとおりです。

N は 128 ビットです

P は 1 オクテット以上

キー(T)は次のように計算されます。

T = AES-CMACSALT(N)

SALTは、次のように計算された 128ビット 値です。

SALT = s1(“smk2”)

鍵生成関数 k2 の出力は次のとおりです。
T0 = 空の文字列(長さゼロ)
T1 = AES-CMACT(T0 || P || 0x01)
T2 = AES-CMACT(T1 || P || 0x02)
T3 = AES-CMACT(T2 || P || 0x03)
k2(N、P)=(T1 || T2 || T3)mod 2263

3.8.2.7 k3 導出関数

導出関数 k3 は、秘密鍵から導出された 64 ビットの公開値を生成するために使用されます。

この導出関数の定義では、128 ビットキー T を使用した MAC 関数 AES-CMACT を使用します。

関数 k3 への入力は次のとおりです。

N は 128 ビットです。

キー(T)は次のように計算されます。

T = AES-CMACSALT(N)

SALT は、次のように計算される 128 ビット値です。

SALT = s1(“ smk3”)

導出関数 k3 の出力は次のとおりです。

k3(N)= AES-CMACT(“ id64” || 0x01)mod 264

3.8.2.8 k4 導出関数

導出関数 k4 は、秘密鍵から導出された 6 ビットの公開値を生成するために使用されます。
この導出関数の定義では、128 ビットキー T を使用した MAC 関数 AES-CMACT を使用します。

関数 k4 への入力は次のとおりです。

N は 128 ビットです

キー(T)は次のように計算されます。

T = AES-CMACSALT(N)

SALT は、次のように計算される 128 ビット値です。

SALT = s1(“ smk4”)

導出関数 k4 の出力は次のとおりです。

K4(N)= AES-CMACT(“ id6” || 0x01)mod 26

3.8.3 シーケンス番号

ネットワーク PDU の SEQ フィールドに含まれる 24 ビット値であるシーケンス番号は、主にリプレイ攻撃から保護するために設計されています。同じノード内の要素は、シーケンス番号空間を互いに共有する場合と共有しない場合があります。メッシュネットワークのセキュリティにとって、メッセージソースごとに新しいネットワーク PDU ごとに異なるシーケンス番号( SRC フィールドに含まれるユニキャストアドレスで識別される)を持つことが重要です。

24 ビットのシーケンス番号を使用すると、要素はナンスを繰り返す前に 16,777,216 メッセージを送信できます。要素が平均して 5 秒に 1 回メッセージを送信する場合(既知のユースケースではかなり高い頻度のメッセージを表します)、要素は、ナンスが繰り返される前に 2.6 年間送信できます。

各要素は、生成するネットワーク PDU に対して厳密に増加するシーケンス番号を使用する必要があります。シーケンス番号が最大値(0xFFFFFF)に近づく前に、要素は IV 更新手順を使用して IV インデックスを更新する必要があります(セクション 3.10.5 を参照)。これは、シーケンス番号がラップアラウンドしないようにするために行われます。

3.8.4 IV インデックス

IV インデックスは、共有ネットワークリソースである 32 ビット値です(つまり、メッシュネットワーク内のすべてのノードが IV インデックスの同じ値を共有し、それらが属するすべてのサブネットに使用します)。

IV インデックスは 0x00000000 から始まり、セクション 3.10.5 で説明されているように IV 更新手順中に増分されます。最下位ビットはすべてのネットワーク PDU 内で通信されるため、値がインクリメントされるタイミングは正確である必要はありません。 IV インデックス値は 32 ビット値であるため、メッシュネットワークは IV インデックスがラップする約 5 兆年前に機能することができます。

IV インデックスは、セキュアネットワークビーコンを介してネットワーク内で共有されます(セクション 3.9.3 を参照)。サブネットで受信した IV 更新は処理され、そのサブネットに伝播されます。伝播は、その特定のサブネットの更新された IV インデックスを使用してセキュアネットワークビーコンを送信するデバイスによって発生します。プライマリサブネット上のデバイスがプライマリサブネットで更新を受信すると、IV 更新を他のすべてのサブネットに伝播する必要があります。プライマリサブネット上のデバイスが他のサブネットでIV更新を受信した場合、その更新は無視されます。

ノードがメッシュネットワークに一定期間存在しない場合、セキュアネットワークビーコンをスキャンするか(セクション 3.10.1 を参照)、IV インデックス回復手順を使用する(セクション 3.10.6 を参照)ため、IV インデックス値を自律的に設定できます。

3.8.5 ナンス

ナンスは、新しいメッセージの暗号化ごとに一意の 13 オクテットの値です。 表3.44 に示すように、使用される 4 つの異なるナンスがあります。 ナンスのタイプは、ナンスタイプと呼ばれるナンスの最初のオクテットによって決定されます。

ナンスタイプナンス説明
0x00ネットワークナンスネットワーク認証および暗号化用の暗号化キー
とともに使用されます
0x01アプリケーションナンス上位トランスポート認証および暗号化用の
アプリケーションキーとともに使用されます
0x02デバイスナンス上位トランスポートの認証と暗号化のために
デバイスキーとともに使用されます
0x03プロキシナンスプロキシ認証および暗号化用の暗号化キー
とともに使用されます
0x04 – 0xFFRFU将来の使用のために予約済み
表3.44:ナンスタイプ

注:TTL は、ネットワークナンス内で使用されますが、アプリケーションナンス、デバイスナンス、またはプロキシナンス内では使用されません。 これは、メッセージが中継され、TTL がデクリメントされても、アプリケーションナンスまたはデバイスナンスは変更されないことを意味します。 ただし、ネットワークナンスは変更されるため、TTL 値の認証が可能になります。

注:DST は、アプリケーションナンスおよびデバイスナンス内で使用されますが、ネットワークナンスでは使用されません。 これは、アプリケーションまたはデバイスメッセージの宛先が認証される可能性があるが、ネットワーク層で宛先アドレスが暗号化されることを意味します。

3.8.5.1 ネットワークナンス

ネットワークナンスは表3.45 で定義され、図3.31 に示されています。

フィールドサイズ
(オクテット)
説明
ナンスタイプ10x00
CTL and TTL1表3.46 を参照してください。
SEQ3シーケンス番号
SRC2送信元アドレス
Pad20x0000
IV インデックス4IV インデックス
表3.45:ネットワークナンスのフォーマット
フィールドサイズ
(オクテット)
説明
CTL1セクション 3.4.4.3 を参照してください。
TTL7セクション 3.4.4.4 を参照してください。
表3.46:CTL および TTL フィールドのフォーマット
図3.31:ネットワークナンスのフォーマット

ネットワークナンスは、ネットワークデータの認証と暗号化のための暗号化キーとともに使用されます(セクション 3.8.7.2 を参照)。

3.8.5.2 アプリケーションナンス

アプリケーションナンスは表 3.47 で定義され、図 3.32 に示されています。

フィールドサイズ
(オクテット)
説明
ナンスタイプ10x01
ASZMIC and Pad1表3.48 を参照してください。
SEQ3アクセスメッセージのシーケンス番号
(セグメント化されたメッセージの
コンテキストの SeqAuth の下位 24 ビット)
SRC2送信元アドレス
DST2宛先アドレス
IV インデックス4IV インデックス
表3.47:アプリケーションナンスのフォーマット
フィールドサイズ
(オクテット)
説明
ASZMIC1セグメント化されたアクセスメッセージの場合は
SZMIC、その他すべてのメッセージ形式の場合は 0
Pad70b0000000
表3.48:ASZMIC および Pad フィールドのフォーマット
図3.32:アプリケーションナンスのフォーマット

アプリケーションナンスは、アプリケーションデータの認証と暗号化のためのアプリケーションキーとともに使用されます(セクション 3.8.6 を参照)。

3.8.5.3 デバイスナンス

デバイスナンスは表3.49 で定義され、図3.33 に示されています。

フィールドサイズ
(オクテット)
説明
ナンスタイプ10x02
ASZMIC and Pad1表3.50 を参照してください。
SEQ3アクセスメッセージのシーケンス番号
(セグメント化されたメッセージの
コンテキストの SeqAuth の下位 24 ビット)
SRC2送信元アドレス
DST2宛先アドレス
IV インデックス4IV インデックス
表3.49:デバイスナンスのフォーマット
フィールドサイズ
(オクテット)
説明
ASZMIC1セグメント化されたアクセスメッセージの場合は SZMIC、
その他すべてのメッセージ形式の場合は 0
Pad70b0000000
表3.50:ASZMIC および Pad フィールドのフォーマット
図3.33:デバイスナンスフォーマット

デバイスナンスは、特定のデバイスに固有のアプリケーションデータ認証および暗号化用のデバイスキーとともに使用されます(セクション 3.8.6 を参照)。

3.8.5.4 プロキシナンス

プロキシナンスは表 3.51 で定義され、図 3.34 に示されています。

フィールドサイズ
(オクテット)
説明
ナンスタイプ10x03
Pad10x00
SEQ3シーケンス番号
SRC2送信元アドレス
Pad20x0000
IV インデックス4IV インデックス
表3.51:プロキシナンスのフォーマット
図3.34:プロキシナンスのフォーマット

プロキシナンスは、プロキシ設定メッセージの認証と暗号化のための暗号化キーとともに使用されます(セクション 6.5 を参照)。

3.8.6 キー

メッシュプロファイル仕様では、アプリケーションキー(AppKey)とネットワークキー(NetKey)の 2 種類のキーが定義されています。 AppKeys は、上位トランスポートレイヤーでの通信を保護するために使用され、NetKeys は、ネットワークレイヤーでの通信を保護するために使用されます。 両方のタイプのキーがノード間で共有されます。 また、各ノードに固有の特別なアプリケーションキーであるデバイスキー(DevKey)もあります。これは、ノードと構成クライアントのみが認識し、ノードと構成クライアント間の通信を保護するために使用されます。

アプリケーションキーはネットワークキーにバインドされています。 つまり、アプリケーションキーは、バインドされているネットワークキーのコンテキストでのみ使用されます。 アプリケーションキーは、単一のネットワークキーにのみバインドされます。 デバイスキーは、すべてのネットワークキーに暗黙的にバインドされます。

アプリケーションキーをネットワークキーとモデルにバインドする例を図3.35 に示します。

図3.35:アプリケーションキーバインディングの例
3.8.6.1 デバイスキー

デバイスキー(DevKey)は、ノードと構成クライアントだけが知っているアクセスレイヤーキーです。 デバイスキーは、ノードが認識しているすべてのネットワークキーにバインドされます。 これらのバインディングは変更できません。 デバイスキーの導出の図を図 3.36 に示します。

図3.36:デバイスキーの導出

DevKey は、以下の式で説明されているように、ECDHSecret および ProvisioningSalt から導出するものとします。

DevKey = k1(ECDHSecret、ProvisioningSalt、“ prdk”)

ProvisioningSalt はセクション 5.4.2.5 で定義され、ECDHSecret はセクション 5.4.2.3 で定義されています。

3.8.6.2 アプリケーションキー

アプリケーションキー(AppKey)は、コア仕様 [1] のボリューム 2、パート H、セクション 2 の要件と互換性のある乱数ジェネレーターを使用して生成されるものとします。
アプリケーションキー識別子(AID)は、アプリケーションキーを識別するために使用されます。 AID の導出の図を図 3.37 に示します。

AID= k4(AppKey)

図3.37:AIDの導出
3.8.6.3 ネットワークキー

ネットワークキー(NetKey)は、コア仕様 [1] のボリューム 2、パート H、セクション 2 の要件と互換性のあるランダム番号ジェネレーターを使用して生成する必要があります。 ネットワークキー階層の図を図3.38 に示します。

図3.38:ネットワークキー階層
3.8.6.3.1 NID、暗号化キー、およびプライバシーキー

各ネットワーク PDU は、NID、暗号化キー、およびプライバシーキーで構成されるセキュリティマテリアルを使用して保護されます。

NID は、このネットワーク PDU を保護するために使用されるセキュリティマテリアルを識別する 7 ビット値です。

注:NID ごとに最大 2121 個の可能なキーがあります。 したがって、NID 値は、このネットワーク PDU を保護するために使用されたセキュリティ資料の指標のみを提供できます。

NID、EncryptionKey、および PrivacyKey は、セキュリティ資格情報を入力として使用する k2 関数を使用して導出されます。

フレンドシップセキュリティマテリアルは、以下を使用してマスターセキュリティ資格情報から取得されます。

NID || EncryptionKey || PrivacyKey = k2(NetKey, 0x00)

フレンドシップセキュリティマテリアルは、以下を使用してフレンドシップセキュリティ資格情報から取得されます。

NID || EncryptionKey || PrivacyKey = k2(NetKey、0x01 || LPNAddress || FriendAddress || LPNCounter || FriendCounter)

ここで:

LPNAddress 値は、フレンドシップを設定するフレンドリクエストメッセージで送信元アドレスとして設定されたユニキャストアドレスです。

FriendAddress 値は、フレンドシップを設定するフレンドオファーメッセージで送信元アドレスとして設定されたユニキャストアドレスです。

LPNCounter 値は、フレンドシップを設定したFriendRequestメッセージのLPNCounterフィールドからの値です。

FriendCounter は、フレンドシップを設定する FriendOffer メッセージの FriendCounter フィールドの値です。

フレンドシップ関係にある低電力ノードとフレンドノード間で送信されるネットワーク PDU の場合、フレンドシップセキュリティマテリアルが使用されます。

他のすべてのネットワーク PDU には、マスターセキュリティマテリアルが使用されます。

3.8.6.3.2 ネットワークID

ネットワーク ID は、各ネットワークキーが 1 つのネットワーク ID を生成するようにネットワークキーから取得されます。 この識別子は公開情報になります。

ネットワーク ID = k3(NetKey)

3.8.6.3.3 IdentityKey

IdentityKey は、各ネットワークキーが1つの IdentityKey を生成するように、ネットワークキーから生成されます。

salt = s1(“ nkik”)

P =“ id128” || 0x01

IdentityKey = k1(NetKey、salt、P)

3.8.6.3.4 ビーコンキー

ビーコンキーは、各ネットワークキーが1つのビーコンキーを生成するように、ネットワークキーから生成されます。

salt = s1(“ nkbk”)

P =“ id128” || 0x01

BeaconKey = k1(NetKey、salt、P)

3.8.6.4 グローバルキーインデックス

ネットワークキーとアプリケーションキーは、メッシュネットワーク内で、構成クライアントによって維持される 2 つのリスト(ネットワークキーのリストとアプリケーションキーのリスト)に編成されます。 各リストは共有メッシュネットワークリソースであり、最大 4096 個のキーを収容できます。 キーは、グローバルキーインデックス(NetKey インデックスと AppKey インデックス)を使用して参照されます。 キーインデックスは、0x000 から 0xFFF までの範囲の 12 ビット値です。 インデックス 0x000 のネットワークキーは、プライマリ NetKey と呼ばれます。

3.8.7 メッセージのセキュリティ

メッセージは、2 つの異なるレイヤーで AES-CCM を使用して保護されます。 メッセージは、ネットワークレイヤーと上位トランスポートレイヤーで暗号化および認証されます。 各メッセージは、パケットから可能な識別情報を隠すために難読化されています。 これを図3.39 に示します。

図3.39:ネットワークレイヤーの暗号化、認証、および難読化の例

すべてのメッセージには、最低 64ビットの認証情報が関連付けられています。 この認証情報は、ネットワークレイヤーと上位トランスポートレイヤーの間で分割される場合があります。

制御メッセージと呼ばれる一部のメッセージは、上位トランスポートレイヤーで認証されないため、64 ビットの NetMIC を備えています。 アクセスメッセージは上位トランスポートレイヤーで認証されるため、32ビットの NetMIC があります。 単一のセグメント化されていないメッセージで送信されるアクセスメッセージには、32 ビットの TransMIC があります。 複数のネットワーク PDU でセグメント化されたアクセスメッセージは、32 ビットまたは 64 ビットの TransMIC を持つことができます。 これにより、上位レイヤーがアクセスメッセージを安全に配信するために必要な認証レベルを決定し、 TransMIC に適切なサイズを適用できるようになります。

3.8.7.1 上位トランスポートレイヤーの認証と暗号化

アクセスペイロードの認証と暗号化は、上位のトランスポートレイヤーによって実行されます。

アクセスペイロードは、AES-CCM を使用して暗号化および認証されます。 これは、Bluetooth Low Energy の暗号化と認証が機能する方法と同じです。 上位トランスポートレイヤーの暗号化の図を図3.40 に示します。

図3.40:上位トランスポートレイヤーの暗号化

アクセスペイロードがアプリケーションキーを使用して保護されている場合、アクセスペイロードはアプリケーションナンスとアプリケーションキーを使用して暗号化されます。

アクセスペイロードがデバイスキーを使用して保護されている場合、アクセスペイロードはデバイスナンスとデバイスキーを使用して暗号化されます。

ナンスはシーケンス番号と送信元アドレスを使用して、2 つの異なるノードが同じナンスを使用できないようにします。 IV インデックスは、シーケンス番号が特定のノードに提供できるより、より多くのナンス値を提供するために使用されます。 IV インデックスの管理については、セクション 3.10.5 で説明しています。

注:アクセスペイロードの認証と暗号化は TTL 値に依存しません。つまり、アクセスペイロードはメッシュネットワークを介して中継されるため、各ホップでアクセスペイロードを再暗号化する必要はありません。

アプリケーションキーを使用し、宛先アドレスが仮想アドレスである場合:

EncAccessPayload、TransMIC = AES-CCM(AppKey、Application Nonce、AccessPayload、Label UUID)

アプリケーションキーを使用し、宛先アドレスがユニキャストアドレスまたはグループアドレスである場合:

EncAccessPayload、TransMIC = AES-CCM(AppKey、Application Nonce、AccessPayload)

デバイスキーを使用し、宛先アドレスがユニキャストアドレスである場合:

EncAccessPayload、TransMIC = AES-CCM(DevKey、Device Nonce、AccessPayload)

暗号化されたアクセスペイロードとトランスポート MIC の連結は、上位トランスポート PDUと呼ばれます。

上位トランスポート PDU = EncAccessPayload || TransMIC

3.8.7.2 ネットワークレイヤーの認証と暗号化

宛先アドレスと TransportPDU は、AES-CCM を使用して暗号化および認証されます。 これは、Bluetooth Low Energyの暗号化と認証が機能する方法と同じです。

すべてのネットワーク PDU は、ネットワークキーから導出した暗号化キーを使用して暗号化されます(セクション 3.8.6.3.1 を参照)。

ネットワークレイヤーの暗号化の図を図3.41 に示します。

図3.41:ネットワークレイヤーの暗号化

以下は、これがどのように実行されるかを定義します。

EncDST || EncTransportPDU、NetMIC = AES-CCM(EncryptionKey、Network Nonce、DST || TransportPDU)

3.8.7.3 ネットワークレイヤーの難読化

ネットワークヘッダー(CTL、TTL、SEQ、SRC)を難読化するために、これらの値は、パッシブ盗聴者がネットワーク PDU をリッスンすることによってノードの ID を判別するのを防ぐように設計された単一の暗号化関数 e の結果と組み合わせる必要があります。

難読化は、アプリケーションとネットワークメッセージの整合性チェック値が計算された後に発生します。 難読化は、ネットワーク PDU 内から入手可能な情報を使用して計算されます。 この難読化は、単純なパッシブ盗聴者がノードを追跡するのを防ぐためにのみ設計されています。 断固とした攻撃者は、この難読化内のパターンを発見する可能性があり、ノードの送信元アドレスまたはシーケンス番号が明らかになる可能性があります。 重要なことに、難読化は、暗号化機能への入力が一意であることを強制しません。

難読化はプライバシーキーを侵害から保護するものではなく、受動的な盗聴者のみに対する保護に関する上記の設計上の考慮事項を考慮すると、プライバシーキーは十分な時間で侵害される可能性があると考えられます。 難読化の設計には IV インデックスが含まれているため、IV インデックスが変更されると、難読化攻撃を再開する必要があります。

ネットワーク PDU を難読化するために、すでに暗号化されているネットワーク PDU の最初の 7 オクテットが、IV インデックスおよびプライバシーキーと組み合わされます。

暗号化されたネットワーク PDU のこれらの最初の7オクテットには、EncDST と、NetMIC と連結された EncTransportPDU または EncTransportPDU のいずれかの 5 オクテットの両方が含まれます。 これらのオクテットは、PrivacyRandom 値として知られています。

プライバシーキーは、ネットワークキーからのキー導出関数(セクション3.8.6.3.1を参照)を使用して導出され、プライバシーキーが侵害された場合でもネットワークキーを保護します。

IVインデックスは、PrivacyRandom 値と連結され、暗号化機能への入力としてプライバシーキーとともに使用されます。 この出力は、PECB 値として知られています。

次に、PECB 値の最初の 6 オクテットは、TTL オクテット、シーケンス番号、および送信元アドレスフィールドと排他ORされ、ObfuscatedData になります。 ネットワーク PDU は、NID / IVI オクテット、ObfuscatedData、EncDST、EncTransportPDU、および NetMIC の連結として送信されます。

ネットワークレイヤーの難読化の図を図3.42 に示します。

図3.42:ネットワークレイヤーの難読化

Privacy Random = (EncDST || EncTransportPDU || NetMIC)[0–6]

Privacy Plaintext = 0x0000000000 || IV Index || Privacy Random

PECB = e (PrivacyKey, Privacy Plaintext)

ObfuscatedData =(CTL || TTL || SEQ || SRC)⊕PECB[0–5]

これを逆にすると、次の操作が実行されます。

プライバシーランダム=(EncDST || EncTransportPDU || NetMIC)[0–6]

プライバシー平文= 0x0000000000 || IVインデックス|| プライバシーランダム

PECB = e(PrivacyKey、Privacy Plaintext)

(CTL || TTL || SEQ || SRC)=ObfuscatedData⊕PECB[0–5]

3.8.8 メッセージリプレイ保護

正当な発信元要素によって送信されたメッセージは、攻撃者によって受動的に受信され、後で変更されることなく再生される可能性があります。 これはリプレイ攻撃と呼ばれます。

発信元の要素が正しいキーを使用してメッセージを暗号化および認証したため、受信者は、メッセージの整合性チェックを実行するだけでは、リプレイ攻撃を受けているかどうかを判断できません(つまり、ネットワーク MIC と、該当する場合はトランスポート MIC で)。

リプレイ攻撃に対する保護を強化するために、各要素は、送信する新しいメッセージごとにシーケンス番号を増やします。特定のシーケンス番号を持つ発信元要素から有効なメッセージを受信した場合、最後の有効なシーケンス番号よりも数値的に小さいか等しいシーケンス番号を含む同じ発信元要素からの今後のメッセージは、再生メッセージである可能性が高く破棄されます。したがって、メッセージはシーケンス番号順にアクセスレイヤーに配信されます。

同じ発信要素からより低い IV インデックスを受信した場合、メッセージは破棄されます。

ノードは、他の要素から受信したすべてのアクセスおよび制御メッセージ、および該当する場合はプロキシ構成メッセージに対してリプレイ保護を実装する必要があります。

ノードに特定の送信元アドレスのリプレイ保護を実行するのに十分なリソースがない場合、ノードは受信後すぐにメッセージを破棄する必要があります。

実装は、メッセージ認証ステップ(ネットワークレイヤーの復号化およびトランスポートレイヤーの復号化)に関して、メッセージ処理フロー、暗号化操作の数、またはメモリ使用量を最適化するため任意のレイヤーで任意の順序でリプレイ保護を実行できます。

ただし、実装は、特定のメッセージが再生されているかどうかを判断できるか、受信後すぐにメッセージを破棄するという基本的な要件に従う必要があります。

図3.43 は、リプレイ攻撃を受けているマルチセグメントメッセージトランザクションを処理するリプレイ保護リストの実装例を示しています。 このメッセージに対して受信された最後のセグメントのシーケンス番号は、そのピアノードのリプレイ保護リストに保存されます。

図3.43:セグメント化されたメッセージのリプレイ保護リストを更新する例

タイトルとURLをコピーしました