3H - arakomiuma/bt GitHub Wiki

1 序論

1.1 範囲

セキュリティ・マネージャは、ペアリングと鍵配布の方法、それらの方法のためのプロトコル、およびそれらの方法と LE 専用または BR/EDR/LE デバイスの他の部分で使用されるセキュリティ・ツールボックスを定義する。

-- 図 1.1.1. 図 1.1：セキュリティ・マネージャとその他の LE Bluetooth アーキテクチャとの関係

これらは同じ意味を持ち、「Vol.1」パート A 1.2 節に記載されている LE デバイスの役割または BR/EDR デバイスの役割（「Vol.1」パート A 1.1 節参照）にマッピングされている。

1.2 コンベンション

1.2.1 ビットとバイトの順序の規則

1オクテットに複数のビットフィールドが含まれている場合、本編では、最下位（低次）のビットを左に、最上位（高次）のビットを右に向けて描画する。

複数オクテットフィールドは、最下位オクテットを左に、最上位オクテットを右に向けて描画する。 複数オクテットフィールドは、最下位オクテットを先に送信しなければならない。

16進数表記で書かれた複数オクテットの値は、左に最も有意なオクテット、右に最も有意なオクテットを持つ。 例えば、'12'が最も有意なオクテットで'34'が最も有意なオクテットの場合、'0x1234'と書かれる。

2 セキュリティ管理者

2.1 はじめに

セキュリティ・マネージャ(SM)は、無線通信におけるアイデンティティ機能と暗号化機能を実行するために、鍵分配アプローチを使用します。 これは、各デバイスが配布する鍵を生成して制御し、他のデバイスがこれらの鍵の生成に影響を与えないことを意味します。 鍵の強度は、配布するデバイスの内部に実装されているアルゴリズムと同じくらい強力です。

セキュリティ・アーキテクチャは、応答するデバイスのメモリと処理要件が、開始するデバイスのメモリと 処理要件よりも低くなるように設計されている。

ペアリングは、リンクを暗号化するために使用できる鍵を確立するために実行される。 その後、トランスポート固有の鍵分配が実行され、将来の再接続でリンクを暗号化するために使用できる鍵を共有し、署名されたデータを検証し、ランダム・アドレス解決するために使用される。

ペアリングは3段階のプロセスである。 最初の2つのフェーズは常に使用され、その後にオプションでトランスポート固有の鍵分配 フェーズが続く場合がある(図2.1参照)。

  • フェーズ1: ペアリング フィーチャー交換
  • フェーズ 2（LE レガシーペアリング）。 短期鍵（STK）生成
  • フェーズ 2（LE セキュア接続）。 長期鍵（LTK）生成
  • フェーズ3：輸送に特化した主要な流通

-- 図 2.1. LE ペアリングのフェーズ

デバイスは、まず、ペアリング機能交換において、認証要件とIO機能を交換し、フェーズ2で以下の方法のいずれを使用するかを決定するものとする。

  • ジャスト・ワークス
  • 数値比較（LEセキュア接続のみ
  • パスキー入力
  • アウトオブバンド (OB) ペアリング機能交換から取得した認証要件は、LEセキュア接続またはLEレガシーペアリングが使用 されるかどうかも決定する。

オプションとして、フェーズ3を実行して、トランスポート固有の鍵、例えば、Identity Resolving Key (IRK)値およびIdentity Address情報を配布してもよい。 フェーズ1およびフェーズ3は、フェーズ2で使用された方法にかかわらず同一である。

フェーズ3は、以下を使用して暗号化されたリンクに対してのみ実行されるものとする。

• LEレガシーペアリングを使用している場合、またはフェーズ2で生成されたSTK • LE Secure Connections または LE Secure Connections を使用している場合、フェーズ 2 で生成される LTK • BR/EDR ペアリングを使用して生成された共有リンク鍵（2.3.5.7 節参照）。

フェーズ 1 およびフェーズ 2 は、暗号化されているリンクまたは暗号化されていないリンクに対して実行することができる。

2.2 暗号化ツールボックス

省略

2.3 ペアリング方法

ペアリングが開始された場合は、ペアリング機能の交換を開始する装置で開始する。 応答するデバイスがペアリングをサポートしていないか、ペアリングを実行できない場合、応答するデバイスは、エラーコード「Pairing Not Supported」を含む「Pairing Failed」メッセージを使用して応答しなければならず、そうでなければ「Pairing Response」メッセージで応答する。

Pairing Feature Exchange は、IO 機能、OB 認証データの可用性、認証要件、鍵サイズ要件、および配布するトランスポート固有の鍵を交換するために使用される。 IO 機能、OB 認証データの可用性、認証要件は、フェーズ 2 で使用される鍵生成方法を決定するために使用される。

すべてのLEレガシーペアリング方式は、2つの鍵を使用し、生成する。

  1. 一時鍵（TK）：ペアリング・プロセスで使用される 128 ビットの一時鍵で、STK の生成に使用される（セクション 2.3.5.5 を参照）。
  2. Short Term Key (STK)：ペアリング後の接続の暗号化に使用される 128 ビットの一時鍵。

LE Secure Connections のペアリング方法は、1 つのキーを使用し、生成します。

  1. Long Term Key (LTK)：ペアリング後の接続およびそれ以降の接続を暗号化するために使用される 128 ビットの鍵。

認証要件は、GAP によって設定される（[Vol 3]パート C、セクション 10.3 参照）。 認証要件には、ボンディングの種類やMITM（man-in-the-middle protection）要件が含まれる。

開始デバイスは、応答デバイスに送信したい特定のトランスポート鍵と、応答デバイスに開始デバイスに送信したい鍵を、応答デバイスに示す。 応答デバイスは、開始デバイスが送信すべき鍵と、応答デバイスが送信すべき鍵を返信する。 配布可能な鍵については、2.4.3 節で定義する。 パラメータが無効なコマンドを受信した場合は、エラーコード "Invalid Parameters "を付して Pairing Failed コマンドで応答する。

2.3.1 セキュリティプロパティ

SMが提供するセキュリティプロパティは、以下のカテゴリに分類されます。

  • LEセキュア接続のペアリング
  • 認証されたMITM保護
  • 認証されていないMITM保護
  • セキュリティ要件はありません LEセキュアコネクションのペアリングは、P-256楕円曲線を利用しています（[Vol.2]パートH 7.6参照）。

LE レガシー・ペアリングでは、Authenticated man-in-the-middle (MITM) の保護は、パスキー・エントリ・ペアリング法を使用して取得されるか、 アウト・オブ・バンド・ペアリング法を使用して取得される場合がある。 LE Secure Connections ペアリングでは、Authenticated man-in-the-middle (MITM) の保護は、パスキー・エントリ・ペアリング法または数値比較法を使用して取得されるか、またはアウト・オブ・バンド・ペアリング法を使用して取得される場合があります。 認証されたMITM保護が生成されるようにするには、選択された認証要件オプションにMITM保護が指定されている必要があります。

認証されていないノーMITMプロテクションは、MITM攻撃に対するプロテクションを持たない。

LE レガシー・ペアリングでは、TK の予測可能な値または容易に確立された値が使用されるため、ペアリング・プロセス中に受動的な盗聴者からの保護を提供するペアリング・メソッドはありません。 ペアリング情報が盗聴者が存在しない状態で配布される場合、すべてのペアリング方法は機密性を提供する。

開始デバイスは、配布された鍵のセキュリティ・プロパティの記録をセキュリティ・データベースに保持しなければならない。

応答装置は、セキュリティデータベース内の分散鍵のサイズとセキュリティプロパティの記録を保持してもよい。 鍵の生成方法とネゴシエートされた鍵サイズによっては、応答デバイスは、イニシエータと レスポンダが同一の鍵を使用するように鍵長を短くしなければならない場合がある(2.3.4 節参照)。

フェーズ 2 で生成された鍵のセキュリティ特性は、鍵が配布されるセキュリティデータベースに格納され るものとする。

2.3.2 IO 機能

デバイスの入力能力と出力能力は、そのIO能力を生成するために結合されます。 入力能力を表2.3に示す。 出力能力は表2.4に記載されています。

-- 表2.3：ユーザ入力能力 注：「はい」は、一定時間内にボタンを押すことで示され、そうでない場合は「いいえ」と見なされる。

-- 表2.4：ユーザー出力機能 個々の入力および出力能力は、ペアリング機能交換で使用されるそのデバイスの単一 IO 能力にマッピングされます。 マッピングを表2.5に示します。

-- 表 2.5：I/O 能力のマッピング

2.3.3 OOB認証データ

ペアリング処理中に使用する情報を通信するために、帯域外機構を使用してもよい。 情報は、AD 構造体のシーケンスとする（[Vol.3]パート C、セクション 11 参照）。

基地局は、基地局との間で、基地局との間の通信に使用する情報を通信することができる。 デバイスは，相手デバイスの帯域外認証データを使用して，相手デバイスの認証を行う。 LE レガシー・ペアリングでは、両方のデバイスが相手デバイスの帯域外認証データを利用できる場合は、帯域外方式が使用されます。 LE Secure Connections ペアリングでは、少なくとも一方のデバイスに相手デバイスの帯域外認証データが利用可能な場合には、帯域外方式が使用されます。

2.3.4 暗号化キーサイズ

各デバイスは、許可される暗号化キーの最大サイズと最小サイズをオクテット単位で定義する暗号化キー長の最大値と最小値のパラメータを持たなければならない。 暗号化キー長の最大値と最小値のパラメータは、1 オクテット（8 ビット）単位で 7 オクテット（56 ビット）から 16 オクテット（128 ビット）の間でなければならない。 これは、プロファイルまたはデバイスアプリケーションによって定義される。

開始デバイスと応答デバイスの最大暗号化キー長パラメータの小さい方の値を暗号化キーサイズとして使用する。

発信デバイスと応答デバイスの両方とも、結果として得られる暗号化キーサイズが、そのデバイスの最小暗号化キーサイズパラメー タより小さくないことを確認しなければならず、小さくない場合は、エラーコード「Encryption Key Size」を含む Pairing Failed コマンドを送信しなければならない。

暗号化キーサイズは、最小暗号化キー長の要件を持つサービスがチェックできるように保存してもよい。

鍵の暗号化鍵サイズが 16 オクテット(128 ビット)未満の場合は、生成された鍵の適切な MSB をマスキングして、合意された暗号化鍵サイズを持つ鍵を生成しなければならない。 マスキングは、生成後、配布、使用、保存される前に行わなければならない。

注：BR/EDRリンク鍵がLTKから導出される場合、導出はLTKがマスクされる前に行われる。

例えば、128ビット暗号化キーが0x123456789ABCDEF0123456789ABCDEF0の場合 これを 7 オクテット（56 ビット）に削減すると、結果として得られる鍵は 0x0000000000000000003456789ABCDEF0 となります。

2.3.5 ペアリング・アルゴリズム

フェーズ 1 で交換された情報は、フェーズ 2 でどの鍵生成方式を使用するかを選択するために使用されます。

LE レガシー・ペアリングを使用する場合は、各デバイスが一時鍵（TK）を生成してペアリングを行います。 TK を生成する方法は、2.3.5.1 節に記載されたアルゴリズムを用いて選択されたペアリング方法に依存する。 Just Works を使用する場合は、2.3.5.2 節で定義された通りに TK を生成する。 Passkey Entry を使用する場合は、2.3.5.5.3 節に規定される通りとする。 Out Of Band を使用する場合は、セクション 2.3.5.5.4 の規定に従い、TK を生成する。 2.3.5.5.5 節に規定する認証機構では、STK を生成し、リンクを暗号化するために TK 値を使用する。

2.3.5.1 鍵生成方式の選択

両方のデバイスが認証要件フラグで MITM オプションを設定していない場合、IO 機能は無視され、Just Works アソシエーションモデルが使用されるものとする。

LE レガシーペアリングにおいて、両方のデバイスが Out of Band 認証データを持っている場合、ペアリング方法を選択する際に Authentication Requirements Flags は無視され、Out of Band ペアリング方法が使用されるものとする。 そうでない場合は、表 2.8 に定義されているように、デバイスの IO 能力を使用してペアリング方法を決定するものとする。

LE Secure Connections のペアリングでは、一方または両方のデバイスに帯域外認証データがある場合、ペアリング 方法を選択する際に認証要件フラグは無視され、帯域外ペアリング方法が使用されるものとする。 それ以外の場合は、表2.8に定義されているように、デバイスのIO能力を使用してペアリング方法を決定しなければならない。

表 2.6 は、少なくとも 1 つのデバイスが LE セキュア接続をサポートしていない場合の STK 生成方法を定義する。

-- 表 2.6：LE レガシー・ペアリングのための帯域外フラグ及び MITM フラグの使用規則

表 2.7 は、両方のデバイスが LE Secure Connections をサポートしている場合の LTK 生成方法を定義しています。

-- 表 2.7. 表 2.7：LE セキュア・コネクションのペアリングにおける帯域外フラグおよび MITM フラグの使用ルール

-- 表2.8：IO能力とキー生成方式のマッピング

生成される鍵は、Authenticated または Unauthenticated のいずれかである。 アウトオブバンド認証方式が使用され、アウトオブバンドメカニズムが盗聴から安全であることがわかっている場合、キーは認証されたものとみなされますが、正確な強度はアウトオブバンド情報の転送に使用された方式に依存します。 Out of Band 方式が使用され、Out of Band メカニズムが盗み聞きから安全でない場合、または盗み聞き保護のレベルが不明な場合、キーは認証されていないものとする。 IO 機能の認証済みまたは認証されていない鍵へのマッピングは、表 2.8 に記載されている。

LE レガシー・ペアリングでは、開始デバイスが Out of Band データを持ち、応答デバイスが Out of Band データを持っていない場合、応答デバイスは Pairing Response コマンドの代わりにエラー・コード「OOB Not Available」を含む Pairing Failed コマンドを送信することができる。

鍵生成方法が十分なセキュリティ・プロパティ（セクション 2.3.1 を参照）を提供する鍵を生成しない場合、デバイスはエラー・コード「Authentication Requirements」を伴う Pairing Failed コマンドを送信しなければならない。

2.3.5.2 LE レガシー・ペアリング - Just Works

Just WorksのSTK生成方法は、ペアリングプロセス中に盗聴者や中間者攻撃に対する保護を提供しません。 ペアリングプロセス中に攻撃者が存在しない場合は、将来の接続で暗号化を使用することで機密性を確立することができます。

どちらのデバイスも、セクション 2.3.5.5 で定義された認証メカニズムで使用される TK 値をゼロに設定します。

2.3.5.3 LE レガシーペアリング - パスキー入力

パスキーエントリーSTK生成方式では、ユーザが機器間で帯域外に渡した6桁の数字を使用します。 ランダムに生成された6桁の数字のパスキーは、約20ビットのエントロピーを達成します。

デバイスの IO 機能が DisplayOnly である場合、または表 2.8 にデバイスがパスキーを表示すると定義されている場合、そのデバイスは 000,000～999,999 の間でランダムに生成されたパスキー値を表示しなければならない。 表示は、ゼロを含む 6 桁すべてが表示されることを保証しなければならない。 もう一方のデバイスは、ユーザーが 000,000,000 から 999,999 の間の値を入力できるようにしなければならない。

UI でのパスキーの入力に失敗した場合、またはキャンセルされた場合、デバイスは理由コード「Passkey Entry Failed」を含む Pairing Failed コマンドを送信しなければならない。

例えば、ユーザが入力したパスキーが「019655」の場合、TK は 0x0000000000000000000000000000000000004CC7 となる。

Passkey Entry メソッドは、MITM (man-in-the-middle) 攻撃からの保護を提供します。

パスキーエントリーの STK 生成方法は、STK が依存する TK 値の範囲が限られているため、ペアリングプロセス中の盗聴者に対する保護が非常に限られています。 ペアリングプロセス中に攻撃者が存在しない場合は、将来の接続で暗号化を使用して機密性と認証を確立することができます。

このとき、TK 値は、セクション 2.3.5.5.5 で定義された認証メカニズムで使用される。

2.3.5.4 帯域外

帯域外メカニズムは、デバイスの発見に役立つ情報、例えばデバイスアドレス、およびペアリングプロセスで使用される128ビットのTK値を通信するために使用されてもよい。 ＴＫ値は、[Vol.2]Part H, Section 2 で定義されているランダム生成の要件を用いた128ビットの乱数とする。

なお、ＯＯＢ通信がＭＩＴＭ攻撃に対して耐性がある場合には、本アソシエーション方式もＭＩＴＭ攻撃に対して耐性がある。 また、Out of Band方式では、認証パラメータ（TK）のサイズは、ユーザが快適に読み書きできるものに制限される必要はない。 そのため、Out of Band方式は、Passkey Entry方式やJust Works方式を使用するよりも安全性が高くなります。 ただし、両方のデバイスが一致する OOB インターフェイスを持つ必要があります。

MITM 保護は、攻撃が成功する確率が 0.000001 以下である場合にのみ提供される。

2.3.5.5 LE レガシー・ペアリング・フェーズ 2

起動装置は 128 ビットの乱数（Mrand）を生成します。

入力パラメータ k を TK、入力パラメータ r を Mrand、入力パラメータ preq を相手装置とのペアリング要求コマンドに設定(変更なし)、入力パラメータ pres を相手装置とのペアリング応答コマンドに設定(変更なし)、確認値生成機能 c1(2.2.3 節参照)を用いて 128 ビットの確認値(Mconfirm)を算出し、確認値生成機能 c1(2.2.3 節参照)を用いて 128 ビットの確認値(Mconfirm)を算出します。 入力パラメータ preq には相手機器との間でやりとりされるペアリング要求コマンドを、入力パラメータ pres には相手機器との間でやりとりされるペアリング応答コマンドを、入力パラメータ iat には相手機器のアドレスタイプを、ia には相手機器のアドレスを、 rat には応答機器のアドレスタイプを、ra には応答機器のアドレスをそれぞれ設定します。

Mconfirm = c1(TK, Mrand.

ペアリング要求コマンド、ペアリング応答コマンド、イニシエートデバイスアドレスタイプ、イニシエートデバイスアドレス、レスポンシブデバイスアドレスタイプ、レスポンシブデバイスアドレス)

確認生成に使用するイニシエート及びレスポンシングデバイスのアドレスは、「Vol.3」パート C 9.3 節を参照のこと。

応答装置は 128bit の乱数（Srand）を生成する。

応答装置は、確認値生成機能 c1（2.2.3 節参照）を用いて、入力パラメータ k を TK、入力パラメータ r を Srand、入力パラメータ preq をペアリング要求コマンド、入力パラメータ pres をペアリング応答コマンド、入力パラメータ iat を発信装置アドレスの種類、ia を発信装置アドレス、 rat を応答装置アドレスとし、128 ビットの確認値（Sconfirm）を算出する。

デバイスアドレスの種類を指定し、応答するデバイスアドレスに ra を設定します。

Sconfirm = c1(TK, Srand.

ペアリング要求コマンド、ペアリング応答コマンド、イニシエートデバイスアドレスタイプ、イニシエートデバイスアドレス、レスポンシブデバイスアドレスタイプ、レスポンシブデバイスアドレス)

発信側は応答側に Mconfirm を送信します。 応答側は Mconfirm を受信すると Sconfirm を発信側に送信します。 発信側が Sconfirm を受信すると、応答側に Mrand を送信します。

応答装置は、受信した Mrand の値を用いて、開始装置が行った計算を繰り返すことで、Mconfirm 値を確認します。

応答側の計算した Mconfirm 値が発信側から受信した Mconfirm 値と一致しない場合は、ペアリング処理を中止し、 応答側は理由コード「Confirm Value Failed」で Pairing Failed コマンドを送信します。

応答装置の計算したMconfirm値が発信装置から受信したMconfirm値と一致した場合、応答装置は発信装置にSlandを送信する。

発信側装置は、受信した Srand の値を用いて、応答側装置が行った計算を繰り返すことで、受信した Sconfirm 値を確認します。

発信側デバイスの計算したSconfirm値が応答側デバイスから受信したSconfirm値と一致しない場合は、ペアリングプロセスを中止し、発 信側デバイスは理由コード「Confirm Value Failed」を付けてPairing Failedコマンドを送信しなければならない。

このとき、通信開始側の計算した Sconfirm 値が応答側から受信した Sconfirm 値と一致した場合、通信開始側は STK を計算し、コントローラに暗号化を有効にするように指示する。

STK は 2.2.4 節で定義した鍵生成関数 s1 を用いて、入力パラメータ k を TK、入力パラメータ r1 を Srand、入力パラメータ r2 を Mrand に設定して生成する。

STK = s1(TK, Srand, Mrand)

暗号化キーサイズが 128 ビット未満の場合は，STK は セクション2.3.4に記載されているように、正しいキーサイズのSTKを生成しなければならない。

イニシエータは、生成された STK を使用してリンク上の暗号化を有効にするか、暗号化が既に有効になっている場合には、暗号化の一時停止手順を実行するものとする（セクション 2.4.4.4.1 を参照）。

2.3.5.6 LE 安全な接続のペアリングフェーズ 2

長期鍵は、LE セキュア・コネクションのペアリング・フェーズ 2 において生成される。

2.3.5.6.1 公開鍵交換

最初に、各デバイスは、独自の楕円曲線ディフィー・ヘルマン（ECDH）公開-秘密鍵ペアを生成します（フェーズ１）。 公開-秘密鍵ペアには、秘密鍵と公開鍵が含まれる。 デバイスA、Bの秘密鍵をそれぞれSKa、SKbと表記する。 デバイス A、B の公開鍵をそれぞれ PKa、PKb と表記する。 この鍵ペアの変更頻度に関する推奨事項については、セクション 2.3.6 を参照のこと。

ペアリングは、開始デバイスが受信デバイスに自分の公開鍵を送信することで開始される(フェーズ1a)。 応答するデバイスは、それ自身の公開鍵で応答する(フェーズ1b)。 これらの公開鍵は、デバイスを識別する可能性はあるが、秘密とはみなされない。

デバイスは、BD_ADDR から受信した公開鍵が正しい曲線上にあることを検証しなければならない(P-256)。

有効な公開鍵 Q = (XQ, YQ)とは、XQ と YQ が共に 0 から p - 1 の範囲内にあり、かつ、当該曲線の有限場において (YQ)2 = (XQ)3 + aXQ + b (mod p) の式を満たすものである。 a,b,pの値については[Vol.2]パートHの7.6節を参照のこと。

デバイスは、曲線の式を直接確認したり、正しい曲線上でのみ有効な式を用いて楕円曲線の点の加算や倍加を実装したり、その他の方法で公開鍵を検証することができます。

LE Secure Connections のペアリング・プロセス中のいずれかの時点でピアから無効な公開鍵を検出したデバイスは、 結果として得られる LTK がある場合には、その LTK を使用しないものとする。

公開鍵が交換された後、デバイスは、Diffie-Hellman 鍵の計算を開始することができる。

セキュリティ・マネージャがデバッグ・モードに置かれている場合、以下の Diffie-Hellman 秘密鍵／公開鍵ペアを使用するものとする。

注: デバッグ機器が LTK を決定し、暗号化された接続を監視できるようにするためには、一方の側 (イニシエータまたはレスポンダ) のみが Secure Connections デバッグ・モードを設定する必要があります。

2.3.5.6.2 認証ステージ 1 - 単機能または数値比較

数値比較アソシエーションモデルは、ペアリング要求PDUおよび/またはペアリング応答PDUの認証要件でMITMビットが1に設定され、両方のデバイスがDisplayYesNoまたはKeyboardDisplayのいずれかに設定されたIO機能を持っている場合、ペアリング中に使用されます。

暗号化の観点から見たJust Worksまたは数値比較プロトコルの認証ステージ1のシーケンス図を図2.3に示す。

公開鍵が交換された後、各デバイスは疑似ランダム 128 ビットの nonce を選択する（ステップ 2）。 この値は、リプレイ攻撃を防ぐために使用され、ペアリングプロトコルの各インスタンス化で新たに生成されなければならない。 この値は、物理的なランダム性のソースから直接生成するか、または物理的なソースからのランダムな値でシードされた優れた擬似ランダム発生器を使用して生成する必要があります。

これに続いて、応答するデバイスは、交換された2つの公開鍵とそれ自身のnonce値に対するコミットメ ントを計算する(ステップ3c)。 このコミットは、これらの値の一方向関数として計算され、開始デバイスに送信される(ステップ4)。 コミットメントは、攻撃者が後からこれらの値を変更することを防ぐ。

その後、開始デバイスと応答デバイスはそれぞれの nonce 値を交換し(ステップ 5 と 6)、開始デバイスはコミットメントを確認する(ステップ 6a)。 この時点での失敗は、攻撃者または他の送信エラーの存在を示し、プロトコルをアボートさせる。 プロトコルは、新しい公開-秘密鍵ペアの生成の有無にかかわらず、繰り返してもよいが、プロトコルが繰り返される場合には、新しい非暗号を生成しなければならない。

Just Worksを使用する場合、コミットメントチェック(ステップ7aと7b)は実行されず、ユーザには6桁の値が表示されない。

数値比較が使用される場合、コミットメントチェックが成功したと仮定して、2つのデバイスはそれぞれ6桁の確認値を計算し、それがそれぞれのデバイス上でユーザに表示される(ステップ7a、7b、および8)。 ユーザは、これらの6桁の値が一致することを確認し、一致するかどうかを確認することが期待される。 一致しない場合、プロトコルは中断され、プロトコルが繰り返される場合は、これまでと同様に、新しい nonce が生成されなければならない。

アクティブなMITMは、サービス拒否以外の効果を得るためには、このプロセスに自身のキーマテリアルを注入しなければならない。 単純なMITM攻撃では、2つの6桁の表示値が0.9999999の確率で異なることになります。 より洗練された攻撃では、表示値を一致させようとする場合がありますが、これはコミットメント・シーケンスによって阻止されます。 攻撃者が最初に応答デバイスとノンスを交換した場合、攻撃者は開始デバイスからのノンスを見る前に、開始デバイスとの間で使用するノンスにコミットしなければならない。 攻撃者が最初に開始デバイスとノンシーを交換する場合、攻撃者は応答デバイスからのノンシーを 見る前に、応答デバイスにノンシーを送信しなければならない。 いずれの場合も、攻撃者は、正当なデバイスからの２番目のノンエースを知る前に、そのノンエースのうち少なくとも２番目のノンエースにコミットしなければならない。 したがって、表示値が一致するような方法で、攻撃者自身のノンスを選択することはできない。

2.3.5.6.3 認証ステージ1-パスキー入力

SMP IO 能力交換シーケンスが Passkey Entry を使用することを示す場合には、Passkey Entry プロトコルを使用する。

暗号化の観点から見たパスキーエントリの認証ステージ 1 のシーケンス図を図 2.4 に示す。

-- 図 2.4：認証ステージ 1：Passkey Entry、LE セキュアコネクション

ユーザーは、両方のデバイスに同一のパスキーを入力する。 あるいは、一方のデバイスでパスキーを生成して表示し、ユーザがもう一方のデバイスに入力することもできます（ステップ2）。 この短い共有鍵が、デバイス間の相互認証の基礎となる。 このパスキーは、各ペアリング手順の間にランダムに生成されるべきであり、前の手順から再利用されてはならない。 静的なパスキーはリンクのセキュリティを損なう可能性があるため、使用しないでください。

6 桁のパスキーは 20 ビット（999999=0xF423F）であるため、ステップ 3 ～ 8 を 20 回繰り返します。 デバイスが短いパスキーを入力することを許可している場合は、そのパスキーの前にゼロを付けなければならない（例：「1234」は「001234」と同等）。

ステップ 3-8 で、各当事者は長い nonce(128 ビット)を使用して Passkey の各ビットにコミットし、nonce のハッシュ、Passkey のビット、および両方の公開鍵を相手に送信する。 その後、パスキー全体が相互に公開されるまで、各当事者は交代で公約を公開する。 最初の当事者がパスキーのあるビットに対するコミットメントを公開した場合は、そのプロセスで事実上そのビットが公開されますが、相手はその後、対応するコミットメントを公開してパスキーのそのビットと同じビット値を示さなければなりません。

この「段階的な開示」は、MITM攻撃の場合、1ビット以上の未推測のパスキー情報の漏洩を防ぐ。 パスキーを部分的にしか知らないMITM攻撃者は、プロトコルが失敗する前に、誤って推測されたパスキーの1ビットだけを受け取ることになる。 したがって、最初に一方の側を攻撃し、次にもう一方の側を攻撃するMITM攻撃者は、確率0.000001で成功する単純なブルートフォース推測者よりも、せいぜい2ビットのアドバンテージしか得られない。

長い nonce は、プロトコルが失敗した後でも、ブルートフォースによる攻撃を困難にするために、 コミットメントハッシュに含まれている。 公開Diffie-Hellman値は、Passkeyプロトコルを元のECDH鍵交換に結びつけるために含まれており、MITMが標準的なMITMファッションでECDH交換の両側で攻撃者の公開鍵を代入することを防ぐために含まれています。

この段階の最後に、Na は Na20 に設定され、Nb は認証段階 2 で使用するために Nb20 に設定される。

2.3.5.6.4 認証ステージ 1 - アウトオブバンド

アウトオブバンドプロトコルは、認証情報を少なくとも１つのデバイスが受信し、ＳＭＰペアリング要求およびＳＭＰペアリング応答ＰＤＵに含まれるＯＯＢデータフラグパラメータに示されている場合に使用される。 なお、ピアデバイスの検出が最初にインバンドで行われ、その後にＯＯＢインタフェースを介して認証パラメータの送信が行われるモードはサポートされていない。 図 2.5 に暗号の観点から見た Out of Band の認証ステージ 1 のシーケンス図を示す。

-- 図 2.5：認証ステージ 1。 図 2.5：認証ステージ 1：アウト・オブ・バンド、LE セキュア接続 動作原理。 両装置が帯域外チャネルを介してデータの送受信が可能であれば、認証ステージ１においてＯＯＢ通信で交換された公開鍵（Ｃａ、Ｃｂ）のコミットに基づいて相互認証を行う。 ＯＯＢ通信が一方向のみで可能な場合、ＯＯＢ通信を受信した装置の認証は、ＯＯＢを介して送信された乱数ｒをその装置が知っていることに基づいて行われる。 この場合、ｒは秘密でなければならない：ｒは毎回新たに作成することができるか、ｒを送信したデバイスへのアクセスを制限しなければならない。 デバイスによってｒが送信されない場合、ステップ４ａまたは４ｂでＯＯＢ情報を受信したデバイスによって０であると仮定される。

A と B の役割 OOB 認証ステージ 1 プロトコルは、A と B の役割に関しては対称的である。

手順の順序。 公開鍵の交換は、検証ステップ５の前に行わなければならない。 図では、デバイス間のインバンド公開鍵交換（ステップ１）は、ＯＯＢ通信（ステップ４）の前に行われる。 しかし、ＯＯＢインタフェースによってペアリングが開始された場合、公開鍵交換はＯＯＢ通信の後に行われる（ステップ１はステップ４とステップ５の間になる）。

raとrbの値。 OOB通信が行われる前に相手のOOBインタフェースの方向を確認することはできないので、デバイスは常に乱数rを生成し、可能であればそのOOBインタフェースを介して相手に送信する必要があります。 各デバイスは、ローカルに以下のルールを適用して、自分のrの値と相手のrの値を設定します。

  1. 最初に、デバイスの r は乱数に設定され、ピアの r は 0 に設定されます（ステップ 2）。
  2. 機器がOBを受信した場合、相手のrの値を相手が送信したものに設定する（ステップ5）。
  3. SMP ペアリング要求または SMP ペアリング応答で送信された相手機器の OOB データフラグが「OOB 認証データが存在しない」に設定されている場合、自装置の r 値を 0 に設定します(ステップ 5)。
2.3.5.6.5 認証ステージ2と長期鍵計算

認証の第二段階では、両方のデバイスが交換を正常に完了したことを確認します。 この段階は、3 つのプロトコルすべてで同じです。

各デバイスは、以前に交換された値と新たに導出された共有キーを使用して、MacKeyとLTKを計算します（ステップ9）。 次に、各デバイスは、以前に交換された値と新たに導出されたＭａｃＫｅｙを含む新たな確認値を計算する（ステップ１０ａおよび１０ｂ）。 次に、開始デバイスは、その確認値を送信し、応答デバイスによってチェックされる（ステップ１１）。 この確認に失敗した場合は、開始デバイスがペアリングを確認していないことを示し、プロトコルを中止しなければならない。 その後、応答装置は確認値を送信し、この確認値は開始装置によってチェックされる（ステップ１２）。 失敗した場合は、応答装置がペアリングを確認していないことを示し、プロトコルは中止されるべきである。

-- 図 2.6：認証ステージ 2 と長期鍵計算

2.3.5.7 クロストランスポートキーの導出

BR/EDR/LEデバイスのペアがトランスポート上でセキュア接続をサポートしている場合、デバイスは、オプションで他のトランスポート用に同じ強度のキーを生成することができます。 2つのシーケンスがある。

  • LEトランスポートでセキュア接続のペアリングが発生する場合、セクション2.4.2.2.4の手順を使用することができる。
  • セキュアコネクションのペアリングがBR/EDRトランスポートで発生する場合、セクション2.4.2.5の手順 を使用してもよい。

2.3.6 繰り返しの試行

ペアリング手順が失敗した場合、ベリファイアが同じ要求者に対して新しいペアリング要求コマンドまたはセキュリティ要求コマンドを開始する前、または失敗したデバイスと同じIDを主張するデバイスによって開始されたペアリング要求コマンドまたはセキュリティ要求コマンドに応答する前に、待ち時間が経過しなければならない。 後続の各障害については、待ち時間を指数関数的に増加させなければならない。 すなわち、各失敗の後、新たな試みを行うことができるまでの待ち時間は、例えば、前の試みの前の待ち時間の２倍の長さとすることができる1。 待ち時間は最大に制限されるべきである。

最大の待ち時間は，実装に依存する。 待ち時間は、一定時間内に新たな失敗した試行が行われなかった場合、指数関数的に最小に減少しなければならない。 この手順により、侵入者が多数の異なる鍵でペアリング手順を繰り返すことを防ぐことができる。

デバイスの秘密鍵を保護するために、デバイスは、攻撃者がデバイスの秘密鍵に関する有用な情報を取得できないようにする方法を実装すべきである。 この目的のために、デバイスは、ペアリングが成功したか失敗したかに関わらず、ペアリングのたびに秘密鍵を変更しなければならない。 そうでなければ、S + 3F > 8 の場合はいつでも秘密鍵を変更しなければならない(S はペアリングに成功した回数、F は鍵が最後に変更されてからの失敗した試行回数)。

2.4 ブルーートゥース低エネルギーにおけるセキュリティ

セキュリティは、マスターロールのデバイスのセキュリティマネージャによって開始されるものとする。 スレーブロールのデバイスが応答デバイスとなる。 スレーブデバイスは、マスタデバイスにペアリングまたは他のセキュリティ手順の開始を要求してもよい（セクション2.4.6参照）。

鍵配布段階のスレーブは、再接続が暗号化されたり、そのランダムアドレスが解決されたり、マスタデバイスがスレーブからの署名データを検証したりできるように、マスタに鍵を与える。

マスタは、役割が逆の場合に再接続を暗号化できるように、マスタのランダムアドレスを解決できるように、またはスレーブがマスタから署名されたデータを検証できるように、スレーブデバイスに鍵を提供することもできる。

2.4.1 鍵と値の定義

LE セキュリティは、暗号化、署名、ランダム・アドレッシングに以下の鍵と値を使用します。

  1. Identity Resolving Key（IRK）は、ランダム・アドレスの生成と解決に使用される 128 ビット・キーである。
  2. 接続署名解決キー（CSRK）は、データの署名および受信デバイス上の署名を検証するために使用される 128 ビットのキーです。
  3. LTK（Long Term Key）とは、暗号化された接続の貢献セッション鍵を生成するために使用される 128 ビットの鍵です。 リンク層の暗号化については、[Vol.6]パートB「5.1.3節」を参照してください。
  4. Encrypted Diversifier（EDIV）は、LE レガシーペアリング中に配布された LTK を識別するために使用される 16 ビットの格納値である。 固有の LTK が配布されるたびに、新しい EDIV が生成される。
  5. 乱数（Rand）は、LE レガシー・ペアリング中に配布された LTK を識別するために使用される 64 ビットの格納値である。 固有の LTK が配布されるたびに新しい Rand が生成される。

2.4.2 分散鍵の生成

配布されている鍵の生成方法は、生成方法がスレーブ装置の外部には見えないので、結果的に128ビットのエントロピーを持つ鍵となる方法であれば、どのような方法でもよい（付録B参照）。 なお、マスタ装置に配布された情報のみから鍵を生成したり、スレーブ装置の外部から見える情報のみから鍵を生成したりしてはならない。

2.4.2.1 IRK の生成

Identity Resolving Key(IRK)は、解決可能なプライベートアドレス構築に使用される(【Vol 3】パートC、セクション10.8.2参照)。 スレーブからIRKを受信したマスタは、そのスレーブのランダムデバイスアドレスを解決することができます。 マスタからIRKを受信したスレーブは、そのマスタのランダムデバイスアドレスを解決することができます。 プライバシーの概念は、IRKが与えられたセットの一部ではないデバイスに対してのみ保護されます。

IRKは、割り当てられるか、製造時にデバイスによってランダムに生成されるか、または他の方法を使用することができます。 IRK がランダムに生成される場合は、[Vol.2]パート H セクション 2 に定義されたランダム生成の要件を使用するものとする。

IRK には暗号化鍵サイズは適用されないため、配布前に暗号化鍵サイズを小さくする必要はない。

2.4.2.2 CSRK の生成

接続署名解決鍵(Connection Signature Resolving Key: CSRK)は、接続中のデータに署名を行うために使用されます。 CSRKを受け取ったデバイスは、配布先のデバイスが生成した署名を検証することができます。 署名は、CSRKが与えられたセットの一部ではないデバイスに対してのみ保護されます。

CSRKは、製造中にデバイスに割り当てられるか、デバイスによってランダムに生成されるか、または他の方法を使用することができます。 CSRKがランダムに生成される場合は、[Vol.2]パートH第2節に定義されたランダム生成の要件を使用するものとする。

暗号化鍵のサイズは CSRK には適用されないため、配布前にサイズを縮小する必要はない。

2.4.2.3 LE レガシーペアリング - LTK、EDIV、Rand の生成

スレーブロールのリンクレイヤ接続状態で暗号化をサポートするデバイスは、LTK、EDIV及びRandを生成することができるものとする。 EDIV及びRandは、以前にペアリングされたマスター・デバイスとの暗号化接続を開始するために、スレーブ・デバイスが以前に共有したLTKを確立するために使用される。 生成されたLTKサイズは、ネゴシエートされた暗号化キーサイズを超えてはならず、そのサイズを縮小する必要があるかもしれません（セクション2.3.4参照）。 LTK、EDIV、及びRandの新しい値は、それらが分配されるたびに生成されなければならない。 スレーブデバイスは、マスターデバイスが暗号化を要求したときに正しいLTK値が使用されるように、EDIV、Rand、LTK間のマッピングをセキュリティデータベースに保存してもよい。 LTK生成方法に応じて、追加の情報、例えば、配布されたLTKのサイズなどが格納されてもよい。 マスタデバイスはまた、EDIV、Rand、LTKをスレーブデバイスに配布してもよく、将来の接続でデバイスの役割が逆転した場合に再接続を暗号化するために使用することができます。

2.4.2.4 LE LTK からの BR/EDR リンクキーの導出

LE物理トランスポートからのLTKは、中間リンクキー(ILK)を中間値として、以下のようにBR/EDRトランスポート用のBR/EDRリンクキーに変換することができる。 少なくとも1つのデバイスがCT2 = 0をセットする場合、次のようになる。

  1. ILK = h6(LTK, "tmp1")
  2. BR/EDRリンクキー = h6(ILK, "lebr")

両方のデバイスが CT2 = 1 に設定されている場合

  1. ILK = h7(SALT, LTK)
  2. BR/EDRリンクキー = h6(ILK, "lebr")

文字列 "lebr "は、以下のように拡張ASCIIを使用してkeyIDにマッピングされます。 keyID[0] = 0111 0010 keyID[1] = 0110 0010 keyID[2] = 0110 0101 keyID[3] = 0110 1100 keyID = 0x6c656272

文字列 "tmp1 "は、以下のように拡張ASCIIを用いてkeyIDにマッピングされます。 keyID[0] = 0011 0001 keyID[1] = 0111 0000 keyID[2] = 0110 1101 keyID[3] = 0111 0100 keyID = 0x746D7031

SALTは以下のように定義されています。 SALT = 0x0000000000000000000000000000000000000000746D7031 注：LTK が 16 オクテット（128 ビット）未満の暗号化キー・サイズを持つ場合、LTK がマスクされる前に BR/EDR リンク・キーが導出される。

2.4.2.5 BR/EDR リンク鍵からの LE LTK の導出

BR/EDR物理トランスポートからのBR/EDRリンクキーは、中間値として中間長期キー(ILTK)を使用して、以下のようにLEトランスポートのLTKに変換することができる。

少なくとも1つのデバイスがCT2 = 0を設定した場合は

  1. ILTK = h6(Link Key, "tmp2")
  2. LTK = h6(ILTK, "brle")

両方のデバイスが CT2 = 1 に設定されている場合

  1. ILTK = h7(SALT, リンクキー)
  2. LTK = h6(ILTK, "brle")

文字列 "brle "は、以下のように拡張ASCIIを使用してkeyIDにマッピングされます。 keyID[0] = 0110 0101 keyID[1] = 0110 1100 keyID[2] = 0111 0010 keyID[3] = 0110 0010 keyID = 0x62726c65

文字列 "tmp2 "は、以下のように拡張ASCIIを用いてkeyIDにマッピングされています。 keyID[0] = 0011 0010 keyID[1] = 0111 0000 keyID[2] = 0110 1101 keyID[3] = 0111 0100 keyID = 0x746D7032

SALTは以下のように定義されています。 SALT = 0x00000000000000000000000000000000746D7032

2.4.3 鍵の分布

LE レガシー・ペアリング及び LE セキュア・コネクションの鍵の分配については、以下のセクションで説明する。

2.4.3.1 LE レガシー・ペアリングの鍵配布

スレーブは、以下の鍵をマスターに配布することができます。

  • LTK、EDIV、Rand
  • アイアールク
  • ＣＳＲＫ

マスタデバイスは、以下のキーをスレーブに配布してもよい。

  • LTK、EDIV、Rand
  • アイアールク
  • ＣＳＲＫ

配布された鍵のセキュリティ・プロパティは、配布に使用された STK のセキュリティ・プロパティに設定されなければならない。 例えば、STK が Unauthenticated no MITM Protection のセキュリティ・プロパティを持つ場合、分散鍵は Unauthenticated no MITM Protection のセキュリティ・プロパティを持つものとする。

リンクは、鍵が配布される前に、フェーズ 2 で生成された STK を使用して暗号化または再暗号化されるものとする(セクション 2.4.4.1 参照)。

注：配布された EDIV 値及び Rand 値は、暗号化セッションのセットアップ中にマスターデバイスからスレーブデバイスにクリアテキストで送信される。

Identity Address Information コマンドで受信した BD_ADDR は、そのペアリング中に配布された BD_ADDR と LTK を使用して再接続が発生した場合にのみ有効とみなされる。 これが成功すると、BD_ADDR と配布された鍵は、セキュリティデータベースのそのデバイスに関連付けられる。

デバイスは、鍵配布フェーズが終了した時点で、スレーブデバイスが配布した LTK、EDIV、Rand の値を使用するように暗号化セッションの設定を要求することができるが、これはセキュリティ上の追加的な利点を提供するものではない。 攻撃者が配布された LTK 値を確立した場合、配布された値を使用するために暗号化セッションセットアップを実行しても、その攻撃者に対する保護は提供されません。

2.4.3.2 LE セキュア・コネクションズの鍵配布

マスタとスレーブは、以下のキーを配布することができます。

  • IRK
  • ＣＳＲＫ 配布された鍵のセキュリティプロパティは、配布に使用された LTK のセキュリティプロパティに設定されるものとする。 例えば、LTK が Unauthenticated no MITM Protection のセキュリティプロパティを持つ場合、分散鍵は Unauthenticated no MITM Protection のセキュリティプロパティを持つものとする。

リンクは、鍵を配布する前にフェーズ 2 で生成された LTK を用いて暗号化または再暗号化されるものとする(セクション 2.4.4.1 参照)。

Identity Address Information コマンドで受信した BD_ADDR は、そのペアリング中に生成された BD_ADDR と LTK を使用して再接続が発生した場合にのみ有効とみなす。 再接続が成功すると、BD_ADDR と分散鍵は、セキュリティデータベースのそのデバイスに関連付けられる。

2.4.4 暗号化セッションの設定

暗号化セッションのセットアップ中、マスタ装置は、１６ビットの暗号化分散器値ＥＤＩＶと、ペアリング中にスレーブ装置から配布された６４ビットの乱数Ｒａｎｄをスレーブ装置に送信します。 マスタのホストは、暗号化セッションを設定する際に使用するLong Term Keyをリンクレイヤに提供します。 スレーブのホストはEDIVとRandの値を受信し、暗号化されたリンクを設定する際に使用するLong Term Keyをスレーブのリンク層に提供します。

両方のデバイスが LE Secure Connections をサポートしている場合、EDIV と Rand はゼロに設定されます。

2.4.4.1 STK を使用した暗号化設定

ペアリングフェーズ 3 で LTK 等の鍵を配布するためには、暗号化セッションを確立する必要がある（2.3.5.5 節参照）。

暗号化セッションの設定は、リンク層に提供する Long Term Key として Phase2 で生成した STK（2.3.5.5 節参照）を使用し、（[Vol.6]パート B、5.1.3.1 節参照）EDIV、Rand の値をゼロとする。

リンクが既に暗号化されている場合には、リンク層に供給される長期鍵としてフェーズ 2 で生成された STK を用いて暗号化一時停止処理を行う（[Vol.6]パート B 5.1.3.2 参照）。 なお、EDIV 及び Rand の値はゼロとする。

2.4.4.2 LTK を用いた暗号化設定

マスタ装置は、暗号化セッションを設定するためには、LE レガシーペアリングでスレーブ装置が配布したセキュリティ情報（LTK、EDIV、Rand）、または LE Secure Connections で生成した LTK を持っている必要があります。

マスタは、セキュリティ情報を使用して暗号化セッションを開始します。 リンクが既に暗号化されている場合は、セキュリティ情報を使用して暗号化の一時停止手順が実行されます。

LE レガシーペアリングでは、EDIV 値と Rand 値を用いて、スレーブ装置の Long Term Key として使用する LTK を確立します。 EDIV 値及び Rand 値から LTK が確立できない場合、スレーブはリンクを暗号化する要求を拒否し、オプションでリンクを切断することができる。

LTK サイズはネゴシエートされた暗号化鍵サイズを超えてはならず、そのサイズを縮小する必要があるかもしれない（セクション 2.3.4 参照）。

セキュリティ情報が保存されている場合、リモートデバイスがセキュリティ情報を削除した場合、それ以降の暗号化セットアップは失敗する可能性がある。 表2.9に、後続の暗号化設定に失敗した場合のセキュリティプロパティの種類とボンディングの有無に応じて、どのような処理を行うべきかを定義します。

-- 表2.9. 表2.9 暗号化設定失敗後の処置

2.4.5 符号化アルゴリズム

LE デバイスは、暗号化されたセッションをピア・デバイスとの間で確立することなく、署名されたデータを送 信することができる。 データは CSRK を用いて署名されるものとする。 署名検証を行うデバイスは、署名デバイスから CSRK を受信しなければならない。 送信デバイスは、その CSRK を使用して送信データに署名する。

署名アルゴリズムへの入力は以下の通りである。

k は 128 ビット SignCounter は 32 ビット 署名は、ブロック暗号として AES-128 を用い、NIST 特開 800-38B[1]に規定されているアルゴリズムで行うこと。 NIST SP 800-38B では、メッセージ認証コード（MAC）生成機能を定義している。

MAC = CMAC(K,M,Tlen)

MAC のビット長（Tlen）は 64 ビットとする。 署名に使用する鍵 生成(k)は CSRK に設定する。

CMAC関数による署名対象メッセージ(M)は、署名対象の可変長メッセージ(M)と、32ビットカウンタ値(SignCounter)の最下位オクテットを最初に表す4オクテットの文字列を連結したものである。

M = m || SignCounter

例えば、署名するデータが 7 オクテット列「3456789ABCDEF1」であり、SignCounter が 67653874 (0x040850F2) に設定されている場合、M はオクテット列「3456789ABCDEF1F2500804」となります。 ブロック暗号としてＡＥＳ-１２８を用いたＣＭＡＣ生成の例は、ＮＩＳＴ特開平８００-３８Ｂ付録Ｄに記載されている。

SignCounterは、CSRKが生成されたときに0に初期化され、与えられたCSRKで署名されたメッセージごとにインクリメントされなければならない。

注：デバイスが1日に100,000個の署名済みイベントを生成する場合、32ビットカウンタは約117年後にラップする。

署名アルゴリズムの結果として、CMAC 関数の 64 ビット結果が使用されます。

署名を検証するために、デバイスは受信したメッセージの MAC と SignCounter を計算し、受信した MAC と比較します。 MAC が一致しない場合は、署名検証は失敗したことになります。 MAC が一致する場合は、署名検証は成功している。

検証を行うデバイスは、リプレイ攻撃を防ぐために、最後に検証された SignCounter をセキュリティデータベースに保存し、受信した SignCounter と比較しなければならない。 受信したSignCounterが保存された値よりも大きければ、そのメッセージはローカルデバイスによって以前に見られたものではなく、セキュリ ティデータベースを更新することができる。

2.4.6 スレーブセキュリティ要求

スレーブデバイスは、セキュリティ要求コマンドをマスタに送信することでセキュリティを要求することができます。 マスタ装置がセキュリティ要求コマンドを受信した場合、リンクの暗号化、ペアリング手順の開始、または要求の拒否を行うことができる。

スレーブは、ペアリング手順が進行中の場合、または暗号化手順が進行中の場合には、セキュリティ要求コマンドを送信してはならない。

Security Requestコマンドは，要求されたセキュリティプロパティを含む。 必要なMITM保護のセキュリティプロパティは、スレーブのIO能力がPasskey Entryアソシエーションモデルを使用することを可能にする場合、または帯域外認証データが利用可能な場合にのみ設定されるものとする。

マスタは、マスタがスレーブからペアリング応答を受信せずにペアリング要求を送信した場合、又はマスタが暗号化モード設定を開始した場合には、スレーブのセキュリティ要求を無視するものとする。

スレーブのセキュリティ要求コマンドを受信した時点でペアリングや暗号化モードがサポートされていない、または開始できない場合、マスタは理由を "Pairing Not Supported "に設定してPairing Failedコマンドで応答するものとする。

セキュリティ要求を受信した後、マスタはまず、暗号化を有効にするために必要なセキュリティ情報を持っているかどうかを確認するものとする。 この情報がない場合、またはスレーブが要求したセキュリティプロパティを満たしていない場合は、マスタはペアリング手順を開始するものとする。 ペアリング手順が成功した場合、マスタのセキュリティデータベースは鍵で更新され、セキュリティプロパティはペアリング手順中に配布される。

マスタが暗号化を有効にするために必要なセキュリティ情報を持ち、スレーブからのセキュリティプロパティ要求を満たしている場合は、2.4.4.4.2 節を参照の上、LTK を用いて暗号化設定を実行する。

図 2.7 に、セキュリティ要求を受信した場合のマスタの動作と判断の概要を示す。

スレーブは、セキュリティ要求コマンド送信後にマスタから受信したペアリング要求コマンドに、要求されたセキュリ ティプロパティを満たす認証要求が含まれていることを確認する。

スレーブは、セキュリティ要求コマンド送信後に、Just Works 以外のセキュリティプロパティを要求し、暗号化手順要求を受信した場合、既存のセキュリティ情報が十分なセキュリティプロパティを有していることを確認する。

図2.7 セキュリティ要求コマンド受信後のマスタの動作

3 セキュリティ管理者のプロトコル

3.1 はじめに

セキュリティマネージャプロトコル(SMP)は、ペアリングとトランスポート固有の鍵配布に使用されます。

3.2 L2CAP 上のセキュリティマネージャチャネル

すべての SMP コマンドは、L2CAP 固定チャネルであるセキュリティマネージャチャネルを介して送信される（「Vol 3」パート A 2.1 節参照）。 LEセキュアコネクションがサポートされていない場合のセキュリティマネージャチャネルの設定パラメー タは、表 3.1 に示すとおりとする。

-- 表 3.1：LE セキュアコネクション非対応時のセキュリティマネージャチャネル構成パラメータ

LE Secure Connections をサポートしている場合のセキュリティマネージャチャネルの設定パラメータは、表 3.2 のとおりとする。

-- 表 3.2：LE セキュア・コネクションをサポートする場合のセキュリティ・マネージャ・チャネルの構成パ ラメータ

3.3 コマンドフォーマット

すべての SMP コマンドの一般的なフォーマットを図 3.1 に示します。

-- 図 3.1: SMP コマンドのフォーマット

表示されるフィールドは以下の通りです。

  • コード（1オクテット コードフィールドは1オクテットの長さで、コマンドの種類を識別します。 表 3.3 にこの文書で定義されているコードの一覧を示す。 将来の使用のために予約されたコードでパケットを受信した場合、それは無視されます。

-- 表 3.3: SMP コマンドコード

  • データ（0オクテット以上 Data フィールドの長さは可変です。 Code フィールドは Data フィールドのフォーマットを決定する。

デバイスがペアリングをサポートしていない場合は、コマンドを受信すると、理由を "Pairing Not Supported"（セクション 3.5.5 を参照）に設定した Pairing Failed コマンドで応答する。 ペアリングがサポートされている場合は、すべてのコマンドがサポートされる。

3.4 SMP タイムアウト

セキュリティ・マネージャ・プロトコルをストールから保護するために、セキュリティ・マネージャ・タイマを使用します。 Security Requestコマンドの送信時、またはSecurity Requestコマンドの受信時に、Security Managerタイマをリセットして再起動します。 ペアリング要求コマンドの送信時、またはペアリング要求コマンドの受信時には、セキュ リティマネージャタイマをリセットして起動する。

セキュリティマネージャタイマは、L2CAP SMPコマンドが送信キューに入っている場合にリセットされるものとする。

ペアリング処理が完了した場合は、セキュリティマネージャタイマを停止する。

セキュリティ・マネージャ・タイマが30秒に達した場合、その手順は失敗したとみなされ、ローカル上位レイヤに通知されるものとする。 L2CAP セキュリティマネージャチャネルを介して、それ以上の SMP コマンドは送信されないものとする。 新しいペアリングプロセスは、新しい物理リンクが確立された場合にのみ実行されるものとする。

3.5 ペアリング方法

このセクションで定義されている SMP コマンドは、ペアリング機能交換と鍵生成を実行するために使用されます(セクション 2.1 参照)。

3.5.1 ペアリング要求

イニシエータは、応答するデバイスにペアリング要求コマンドを送信することで、ペアリング機能交換を開始します。 ペアリング・リクエスト・コマンドは図3.2に定義されている。

なお、LE トランスポート上のペアリング手順と BR/EDR トランスポート上のペアリング手順との間のコリジョンの引き渡しルールは、[Vol.3]パート C セクション 14.2 に定義されている。

-- 図3.2：ペアリングリクエストパケット

以下のデータフィールドを使用します。

  • IO能力（1オクテット 表3.4は、IO能力を交換する際に使用する値を定義しています（セクション2.3.2参照）。

-- 表3.4. IO能力値 - OOBデータフラグ（1オクテット

表 3.5 は、OOB 認証データが利用可能かどうかを示す際に使用する値を定義しています（2.3.3 節参照）。

-- 表 3.5: OOB データ提示値 - AuthReq (1 オクテット)

AuthReqフィールドは、STKおよびLTKとGAPボンディング情報（[Vol 3]パートC、9.4節参照）に対して要求されたセキュリティプロパティ（2.3.1節参照）を示すビットフィールドである。

図 3.3 に認証要求ビットフィールドを定義する。

-- 図 3.3.3：認証要求フラグ

Bonding_Flags フィールドは、表 3.6 に定義されているように、イニシエートデバイスが要求する ボンディングのタイプを示す 2 ビットのフィールドである。

-- 表 3.6. 表 3.6: ボンディングフラグ

MITM フィールドは 1 ビットのフラグであり、デバイスが MITM 保護を要求している場合には 1 に設定され、そうでない場合には 0 に設定される。 デバイスは、LE レガシーペアリングを使用する場合には STK に、LE セキュアコネクションを使用する場合には LTK に Authenticated セキュリティプロパティを要求するために MITM フラグを 1 に設定する。

SC フィールドは、1 ビットのフラグである。 両方のデバイスが LE Secure Connections ペアリングをサポートしている場合は、LE Secure Connections ペアリングを使用し、そうでない場合は LE Legacy ペアリングを使用する。

キープレスフィールドは、Passkey Entry プロトコルでのみ使用される 1 ビットのフラグであり、他のプロトコルでは無視される。 双方がそのフィールドを 1 に設定した場合、キープレス通知は、SMP ペアリング・キープレス通知 PDU を使用して生成され、送信されるものとする。

CT2フィールドは、h7機能のサポートを示すために送信時に1に設定される1ビットのフラグである。 2.4.2.2.4 及び 2.4.2.5 節を参照のこと。

  • 最大暗号化キーサイズ（1オクテット この値は、デバイスがサポートできる最大暗号化キーサイズをオクテット単位で定義する。 最大鍵サイズは、7 オクテットから 16 オクテットの範囲内でなければならない。

  • イニシエータ鍵配布/生成(1 オクテット) イニシエータ鍵配布/生成フィールドは、イニシエータがトランスポート固有の鍵配布 フェーズ(セクション2.4.3参照)の間に、どの鍵を配布/生成/使用することを要求しているかを示す。 イニシエータ鍵配布/生成フィールドのフォーマットと使用法は3.6.1節に規定されている。

  • レスポンダ鍵配布/生成(1 オクテット) レスポンダ鍵配布/生成フィールドは、トランスポート固有の鍵配布フェーズ(2.4.3 節参照)において、イニシエータが レスポンダに配布/生成/使用を要求している鍵を示す。 レスポンダ鍵配布/生成フィールドのフォーマットと使用法は 3.6.1 節に規定される。

BR/EDR 上でセキュアコネクションのペアリングが開始された場合、SM ペアリング要求 PDU の以下のフィールドは、将来の使用のために予約されている。

  • IO 能力フィールド。
  • OOBデータフラグフィールドと
  • CT2 ビットを除く Auth Req フィールドのすべてのビットを指定します。

3.5.2 ペアリング応答

このコマンドは、応答装置がペアリングを許可している場合、応答装置が開始装置からペアリング要求コマンドを受信した後、ペアリング機能交換を完了するために応答装置によって使用されます。 ペアリング応答コマンドは図3.4に定義されています。

なお、LE トランスポート上のペアリング手順と BR/EDR トランスポート上のペアリング手順との間のコ リジョンの引き渡しルールについては、[Vol.3]パート C セクション 14.2 に規定されている。

クロストランスポート鍵の導出/生成がサポートされていない場合、またはBR/EDRトランスポートが P256で生成したリンク鍵を使用して暗号化されていない場合にBR/EDRトランスポート上でペアリング要求を受信した場合は、エラーコードCross-Transport Key Derivation/Generation Not Allowed(0x0E)とともにPairing Failedが送信されるものとする。

-- 図 3.4. 図 3.4: ペアリング応答パケット

以下のデータフィールドを使用します。

  • IO能力（1オクテット 表3.4は、IO能力を交換する際に使用する値を定義しています（2.3.2項参照）。

  • OOBデータフラグ（1オクテット 表 3.5 は、OB 認証データが利用可能かどうかを示す際に使用する値を定義しています（2.3.3 節参照）。

  • AuthReq (1オクテット) AuthReqフィールドは、STKまたはLTKとGAPボンディング情報（[Vol.3]パートC、9.4項参照）に対する要求されたセキュリティプロパティ（2.3.1項参照）を示すビットフィールドです。

図 3.3.3 に認証要求ビットフィールドを定義する。

Bonding_Flags フィールドは、ボンディングの種類を示す 2 ビットのフィールドである。

表 3.6 で定義されているように、応答するデバイスが要求していることを示す。

MITM フィールドは 1 ビットのフラグであり、デバイスが MITM 保護を要求している場合には 1 に設定され、そうでない場合には 0 に設定される。 デバイスは、LE レガシーペアリングを使用する場合には STK に、LE セキュアコネクションを使用する場合には LTK に Authenticated セキュリティプロパティを要求するために MITM フラグを 1 に設定する。

SC フィールドは、1 ビットのフラグである。 両方のデバイスが LE Secure Connections ペアリングをサポートしている場合は、LE Secure Connections ペアリングを使用し、そうでない場合は LE Legacy ペアリングを使用する。

キープレスフィールドは、Passkey Entry プロトコルでのみ使用される 1 ビットのフラグであり、他のプロトコルでは無視される。 双方がそのフィールドを 1 に設定した場合、キープレス通知は、SMP ペアリング・キープレス通知 PDU を使用して生成され、送信されるものとする。

CT2フィールドは、h7機能のサポートを示すために送信時に1に設定される1ビットのフラグである。 2.4.2.2.4 節及び 2.4.2.5 節を参照のこと。

  • 最大暗号化鍵サイズ（1 オクテット この値は、デバイスがサポートできる最大暗号化キーサイズをオクテット単位で定義する。 最大鍵サイズは、7 オクテットから 16 オクテットの範囲内でなければならない。

  • イニシエータ鍵配布(1オクテット) イニシエータ鍵配布フィールドは、トランスポート固有の鍵配布フェーズ(セクション2.4.3参照)の間にイニシエータが配布し、 使用する鍵を定義する。 イニシエータ鍵配布フィールドのフォーマットと使用法は、セクション3.6.1で定義される。

  • レスポンダ鍵配布(1 オクテット) レスポンダの鍵配布は、トランスポート固有の鍵配布フェーズ(2.4.3 節参照)において、 レスポンダが配布して使用する鍵を定義する。 レスポンダ鍵配布フィールドのフォーマットと使用法は、3.6.1 節で定義する。

BR/EDR 上でセキュアコネクションのペアリングが開始された場合、SM ペアリング応答 PDU の以下のフィールドは、将来の使用のために予約されている。

  • IO Capability」フィールド。
  • OOBデータフラグフィールドと
  • CT2 ビットを除く Auth Req フィールドのすべてのビットを指定します。

3.5.3 ペアリングの確認

これは、ペアリング機能交換が成功した後に使用され、LE レガシー・ペアリングの STK 生成と LE セキュア・コネクション・ペアリングの LTK 生成を開始します。 Pairing Confirm」コマンドは、図 3.5 に定義されています。

このコマンドは、LE レガシー・ペアリングの場合はセクション 2.3.5.5.5 を、LE セキュア・コネクション・ペアリングの場合はセクション 2.3.5.6 を参照してください。

開始デバイスは、応答デバイスに Pairing Confirm コマンドを送信することにより、鍵の生成を開始します。 発信デバイスがペアリングの中止を希望する場合は、代わりに Pairing Failed コマンドを送信することができます。

応答装置は、開始装置から Pairing Confirm コマンドを受信した後、Pairing Confirm コマンドを送信します。

-- 図 3.5: Pairing Confirm パケット

以下のデータフィールドを使用します。

  • 確認値（16 オクテット LE レガシー・ペアリングでは、セクション 2.3.5.5 に定義されているように、開始デバイスは Mconfirm を送信し、応答デバイスは Sconfirm を送信する。

LE セキュア・コネクションでは、Ca および Cb はセクション 2.2.6 で定義される。

3.5.4 ペアリングのランダム

このコマンドは、ペアリング確認コマンドで送信された確認値を計算するために使用される乱数を送信するために、開始側および応答側のデバイスが使用します。 Pairing Random コマンドは図 3.6 に定義されています。

開始デバイスは、応答デバイスから Pairing Confirm コマンドを受信した後、Pairing Random コマンドを送信します。

LE レガシーペアリングでは、応答側装置は、応答側装置で計算した確認値が応答側装置から受信した確認値と一致する場合には、応答側装置から Pairing Random コマンドを受信した後に Pairing Random コマンドを送信するものとする。 計算された確認値が一致しない場合、応答デバイスは、ペアリング失敗コマンドで応答するものとする。

LE セキュア・コネクションでは、応答デバイスは、開始デバイスからペアリング・ランダム・コマンドを受信した後、ペ アリング・ランダム・コマンドを送信するものとする。 計算された確認値が一致しない場合、応答デバイスは「Pairing Failed」コマンドで応答するものとする。

開始デバイスで計算された確認値が応答デバイスから受信した確認値と一致する場合、開始デバイスは、生成されたキー（LE レガシー・ペアリングでは STK、LE セキュア・コネクションでは LTK）を使用してリンクを暗号化しなければならない。 リンクの暗号化または再暗号化が成功したことは、鍵生成が正常に完了したことを応答デバイスに伝える信号です。 計算されたConfirm値が一致しない場合は、応答デバイスはPairing Failedコマンドで応答する。

-- 図3.6. 図 3.6: ペアリング・ランダム・パケット

データフィールドは以下の通りです。

  • ランダム値（16オクテット LE レガシー・ペアリングでは、セクション 2.3.5.5.5 で定義されているように、開始デバイスは Mrand を送信し、応答デバイスは Srand を送信する。

LE セキュア・コネクションでは、開始デバイスは Na を送信し、応答デバイスは Nb を送信する。

3.5.5 ペアリングの失敗

これは、ペアリング中に失敗があった場合に使用され、ペアリング手順が停止され、現在のペアリング手順のためにそれ以上の通信が発生しないことを報告します。 Pairing Failed コマンドは図 3.7 に定義されています。

後続のペアリング手順は、ペアリング機能交換フェーズから再開する。

このコマンドは、いずれかのデバイスがリモート・デバイスからのメッセージに応答して、ペアリング・プロセス中にいつでも送 信することができる。

LE Secure Connections のペアリング中、このコマンドは、リモート・デバイスの公開鍵が無効な場合に送信され るものとする（セクション 2.3.5.6.1 を参照）。 Reason」フィールドは「DHKey Check Failed」に設定する必要がある。

-- 図 3.7: Pairing Failed パケット

以下のデータフィールドを使用します。

  • 理由 (1 オクテット) Reason」フィールドは、ペアリングが失敗した理由を示します。 理由コードは表 3.7 に定義されています。

-- 表 3.7: ペアリング失敗の理由コード

3.5.6 公開鍵のペアリング

このメッセージは、デバイスのローカル公開鍵(X と Y の共同座標)をリモートデバイスに転送するために使用されます。 このメッセージは、イニシエータとレスポンダの両方で使用されます。 この PDU は、セキュア接続でのみ使用されます。

-- 図 3.8. 図 3.8: ペアリング公開鍵 PDU

3.5.7 ペアリング DHKey チェック

このメッセージは、f6 で生成された 128 ビットの DHKey チェック値（Ea/Eb）を送信するために使用されます。 このメッセージは、イニシエータとレスポンダの両方で使用されます。 この PDU は LE セキュア・コネクションでのみ使用される。

-- 図 3.9：ペアリング DHKey チェック PDU

3.5.8 キープレス通知

このメッセージは、KeyboardOnly IO 機能を持つデバイスが Passkey Entry プロトコルの間に使用し、キーが入力または消去されたことをリモートデバイスに通知するために使用されます。

-- 図 3.10：ペアリングキープレス通知 PDU

通知タイプは以下のいずれかの値を取ることができます。

-- 表 3.8. 通知タイプ

3.6 ブルーートゥース低エネルギーでのセキュリティ

3.6.1 主な流通・発電

Bluetooth Low Energy デバイスは、スレーブからマスターへ、およびマスターからスレーブデバイスへキーを配布することができます。 LEレガシーペアリングを使用する場合、以下のキーをスレーブからマスターに配布することができます。

  • 暗号化情報コマンドを使用したLTK
  • マスター識別コマンドを使用したEDIVとランド
  • アイデンティティ情報コマンドを使用したIRK
  • アイデンティティアドレス情報コマンドを使用したパブリックデバイスまたは静的ランダムアドレス
  • 署名情報コマンドを使用したCSRK

LE Secure Connections を使用する場合、以下のキーをスレーブからマスタに配布することができます。

  • Identity Information コマンドを使用した IRK
  • アイデンティティアドレス情報コマンドを使用したパブリックデバイスまたは静的ランダムアドレス
  • 署名情報コマンドを使用したCSRK

LEレガシーペアリングを使用する場合、マスタは以下の鍵をスレーブに配布することができます。

  • 暗号化情報コマンドを使用したLTK
  • マスター識別コマンドを使用したEDIVとランド
  • アイデンティティ情報コマンドを使用したIRK
  • アイデンティティアドレス情報コマンドを使用したパブリックデバイスまたは静的ランダムアドレス
  • 署名情報コマンドを使用したCSRK

LEセキュアコネクションを使用する場合、マスタは以下のキーをスレーブに配布することができます。

  • アイデンティティ情報コマンドを使用した IRK
  • アイデンティティアドレス情報コマンドを使用したパブリックデバイスまたは静的ランダムアドレス
  • 署名情報コマンドを使用したCSRK トランスポート固有の鍵配布フェーズで配布される鍵は、3.5.1 節及び 3.5.2 節を参照のこと。

LE のペアリング要求及びペアリング応答コマンドの Initiator Key Distribution / Generation フィールド及び Responder Key Distribution / Generation フィールドのフォーマットは、図 3.11 に定義される。

-- 図 3.11：LE 鍵配布フォーマット

鍵配布／生成フィールドには、以下のフラグがある。

  • LE レガシー・ペアリングでは、EncKey は 1 ビットのフィールドであり、デバイスが暗号化情報コマンドを使用して LTK を配布し、EDIV とランドはマスター識別コマンドを使用して配布することを示すために 1 に設定される。

LE セキュア・コネクションのペアリングでは、SMP が LE トランスポート上で動作している場合、EncKey フィールドは無視されるものとする。 EDIVとRandはゼロに設定され、分配されないものとする。

SMPがBR/EDRトランスポートで実行されている場合、EncKeyフィールドは1に設定され、デバイスがBR/EDRリンクキーから LTKを導出したいことを示す。 イニシエータとレスポンダの両方のデバイスがキー分配／生成フィールドで EncKey を 1 に設定した場合、BR/EDR リンクキーから LTK を計算する手順を使用する。

  • IdKey は、1 に設定される 1 ビットのフィールドで、Identity Information コマンドを使用して IRK を配布し、その後に Identity Address Information を使用してパブリックデバイスまたはスタティックランダムアドレスを配布することを示す。

  • SignKey」は、デバイスが「Signing Information」コマンドを使用して CSRK を配布することを示すために 1 に設定される 1 ビットのフィールドである。

  • LinkKey は 1 ビットのフィールドである。 SMP が LE トランスポート上で動作している場合、LinkKey フィールドは 1 に設定され、 デバイスが LTK から LinkKey を導出することを示す。 イニシエータとレスポンダの両方のデバイスで LinkKey が 1 に設定されている場合、LTK から BR/EDR リンク・キーを計算する手順を使用するものとする。 LE セキュア接続をサポートしていないデバイスは、このビットをゼロに設定し、受信時に無視するものとする。 SMP が BR/EDR トランスポート上で動作している場合、LinkKey フィールドは将来の使用のために予約される。

Pairing Request コマンドの Initiator Key Distribution / Generation フィールドは、イニシエータがレスポンダに配布または生成する鍵を要求するために、マスタが使用する。 Pairing Request コマンドの Responder Key Distribution / Generation フィールドは、どの鍵がレスポンダからイニシエータに配布されるか、または生成されるかを要求するためにマスタが使用する。 スレーブからのペアリング応答コマンドの Initiator Key Distribution / Generation フィールドは、イニシエータからレスポンダに配布または生成される鍵を定義する。 スレーブからのペアリング応答コマンドのレスポンダキー配布・生成フィールドは、レスポンダからイニシエータへ配布・生成するキーを定義する。 スレーブは，ペアリング応答コマンドの Initiator Key Distribution / Generation または Responder Key Distribution / Generation フィールドに，マスタがペアリング要求コマンドの Initiator Key Distribution / Generation および Responder Key Distribution / Generation フィールドでゼロに設定したフラグを 1 に設定してはならない。

LE レガシー・ペアリングを使用する場合、鍵は以下の順序で配布されるものとする。

  1. スレーブによる LTK
  2. 奴隷によるEDIVとランド
  3. スレーブによるIRK
  4. スレーブによるBD ADDR
  5. スレーブによるCSRK
  6. 師匠によるLTK
  7. 師匠によるEDIVとランド
  8. 師匠のIRK
  9. マスタによるBD_ADDR
  10. マスタによるCSRK

LEセキュア・コネクションを利用する場合は、以下の順序で鍵を配布するものとする。

  1. スレーブによる IRK
  2. スレーブによるBD ADDR
  3. スレーブによるCSRK
  4. 師匠のIRK
  5. マスタによるBD_ADDR
  6. マスターによるCSRK

鍵が配布されていない場合、その鍵を配布するコマンドは送られてはならない。

注：鍵が配布されていない場合、この鍵を使用する能力は利用できなくなる。 例えば、LTKがスレーブからマスタに配布されない場合、マスタはそのスレーブとの将来のリンクを暗号化できないので、ペアリングを再度実行しなければならない。

注：イニシエータは、上位レイヤの仕様で要求される能力に基づいて必要な鍵を決定する必要があります。 例えば、イニシエータがそのスレーブとの将来のリンクで暗号化が必要であると判断した場合、イニシエータは、ペアリング要求コマンドのレスポンダキー配布/生成フィールドで EncKey ビットを 1 に設定して、そのスレーブの LTK が配布されるように要求する必要があります。

注意：キーが配布されていない場合、このキーを使用する機能は使用できません。 例えば、LTK がスレーブからマスタに配布されていない場合、マスタはそのスレーブとの将来のリンクを暗号化できないため、再度ペアリングを行う必要があります。

注：イニシエータは、上位レイヤの仕様で要求される能力に基づいて必要な鍵を決定する必要があります。 例えば、イニシエータがそのスレーブとの将来のリンクで暗号化が必要であると判断した場合、イニシエータは、ペアリング要求コマンドのレスポンダキー配布/生成フィールドで EncKey ビットを 1 に設定して、スレーブの LTK の配布を要求しなければなりません。

Initiator Key Distribution / Generation および Responder Key Distribution / Generation フィールドで EncKey、IdKey、SignKey が 0 に設定されている場合、キーは配布または生成されず、LE レガシーペアリングを使用する場合は生成された STK を使用してリンクが暗号化され、LE Secure Connections ペアリングを使用する場合は LTK を使用してリンクが暗号化される。

鍵の配布は、最終的な鍵を送信するデバイスがその鍵のベースバンド確認応答を受信した時点で完了し、 受信側のデバイスが配布される最終鍵を受信した時点で完了する。

3.6.2 暗号化情報

暗号化情報は，LE レガシーペアリングの Transport Specific Key Distribution で，将来の接続を暗号化する際に使用する LTK を配布するために使用します。 図 3.12 に暗号化情報コマンドを定義する。

Encryption Information コマンドは、生成した STK を用いてリンクが暗号化または再暗号化された場合にのみ送信される。

-- 図 3.12：暗号化情報パケット

データフィールドは以下のようになっています。

  • ロングタームキー（16オクテット 2.4.2.3 節を参照のこと。

3.6.3 マスター識別

マスター識別は、将来の接続を暗号化する際に使用される EDIV と Rand を配布するために、LE レガシーペアリングのトランスポート特定鍵配布フェーズで使用される。 マスター識別コマンドは、図 3.13 に定義される。 マスター識別コマンドは、生成された STK を使用してリンクが暗号化または再暗号化された場合にのみ送信される。

-- 図3.13: マスター識別パケット

以下のデータフィールドを使用します。

  • EDIV (2 オクテット) 配布されるEDIV値（2.4.2.3項参照）。

  • ランド(8オクテット) 配布される 64 ビットのランド値（セクション 2.4.2.3 を参照）。

3.6.4 アイデンティティ情報

Identity Informationは、IRKを配布するためのTransport Specific Key Distributionフェーズで使用される。 Identity Informationコマンドは、図3.14に定義されている。

Identity Informationコマンドは、生成された鍵を使用してリンクが暗号化または再暗号化された場合にのみ送信される。

-- 図3.14: Identity Informationパケット

データフィールドは以下の通りです。

  • アイデンティティ解決キー(16オクテット) 配布される128ビットIRK値(セクション2.4.2.1参照)。

注記：Identity Resolving Keyデータフィールドがすべて0の場合、デバイスが は、有効な解決可能なプライベート・アドレスを持っていない。

3.6.5 IDアドレス情報

Identity Address Information は、トランスポート特定鍵配布フェーズで、その公開デバイスアドレスまたは静的ランダムアドレスを配布するために使用される。 Identity Address Informationコマンドは、図3.15に定義されている。

Identity Address Informationコマンドは、生成された鍵を使用してリンクが暗号化または再暗号化された場合にのみ送信される。

-- 図3.15: Identity Address Information パケット

データフィールドは

  • AddrType (1 オクテット) BD_ADDR がパブリックデバイスアドレスの場合、AddrType は 0x00 とする。 BD_ADDR がスタティックランダムデバイスアドレスの場合は、AddrType を 0x01 とする。

  • BD_ADDR (6 オクテット) このフィールドには、配信装置のパブリックデバイスアドレスまたはスタティックランダムアドレスが設定されます。

3.6.6 署名情報

Signing Information は、トランスポート特定鍵配布において、デバイスがデータに署名する際に使用する CSRK を配布するために使用する。 Signing Information コマンドは、図 3.16 に示すとおりである。

Signing Information コマンドは、生成した鍵を用いてリンクを暗号化または再暗号化した場合にのみ送信する。

-- 図 3.16：Signing Information パケット

以下のデータフィールドを使用します。

  • 署名キー（16オクテット 配布される128ビットのCSRK；セクション2.4.2.2を参照のこと。

3.6.7 セキュリティ要求

セキュリティ要求コマンドは、マスタが要求されたセキュリティプロパティでセキュリティを開始するように要求するために、スレーブが使用します（セクション2.4.6参照）。 図3.17にSecurity Requestコマンドの定義を示します。

-- 図3.17: セキュリティ要求パケット

以下のデータフィールドを使用します。

  • AuthReq (1オクテット) AuthReqフィールドは、STKまたはLTKとGAPボンディング情報（[Vol.3]パートC、9.4項参照）に対する要求されたセキュリティプロパティ（2.3.1項参照）を示すビットフィールドです。

図 3.3.3 に認証要求ビットフィールドを定義する。

Bonding_Flags フィールドは、ボンディングの種類を示す 2 ビットのフィールドである。

表 3.6 で定義されているように、応答するデバイスが要求していることを示す。

MITM フィールドは 1 ビットのフラグであり、デバイスが MITM 保護を要求している場合には 1 に設定され、そうでない場合には 0 に設定される。 デバイスは、LE レガシーペアリングを使用する場合には STK に、LE セキュアコネクションを使用する場合には LTK に Authenticated セキュリティプロパティを要求するために MITM フラグを 1 に設定する。

SC フィールドは、1 ビットのフラグである。 両方のデバイスが LE Secure Connections ペアリングをサポートしている場合は、LE Secure Connections ペアリングを使用し、そうでない場合は LE Legacy ペアリングを使用する。

キープレスフィールドは、Passkey Entry プロトコルでのみ使用される 1 ビットのフラグであり、他のプロトコルでは無視される。 双方がこのフィールドを1に設定した場合、キープレス通知は、SMPペアリングキープレス通知PDUを使用して 生成され、送信されるものとする。

4 参考文献

[1] NIST Special Publication 800-38B: http://dx.doi.org/10.6028/NIST.SP.800-38B