ファスト ペアリングの手順

手順

シーカーは、通常の BR/EDR または BLE ボンディング手順のいずれかをすぐに呼び出すのではなく、まずキーベースのペアリング特性に関する通知を有効にしてから、表 1.1 のデータを書き込みます。

ファスト ペアリング シーカーからの書き込みリクエストを処理する際、ファスト ペアリング プロバイダは次の処理を行います。

  1. オプションの公開鍵フィールドが存在する場合:
    1. デバイスがペア設定モードでない場合は、書き込みを無視して終了します。
    2. それ以外の場合は、次の手順を行います。
      1. 受信した公開鍵（secp256r1 楕円曲線上の 64 バイトのポイント）、プリインストールされているなりすまし対策秘密鍵（secp256r1 も）、楕円曲線 Diffie-Hellman アルゴリズムを使用して、256 ビット AES 鍵を生成します。
      2. SHA-256 を使用して 256 ビット AES 鍵をハッシュ化する。
      3. 結果の最初の 128 ビットを取得します。これは、次の手順で使用するなりすまし対策の AES 鍵です。

  2. AES-128 を使用して、値を復号してみます。値は単一の 16 バイト AES ブロックであるため、IV またはマルチブロック暗号モードは必要ありません。

    1. 使用する鍵:
      1. 手順 1 でなりすまし対策 AES 鍵が生成された場合は、その鍵を使用します。
      2. それ以外の場合は、保存されているアカウントキーリストの各キーを試してください。
    2. 鍵が値を正常に復号した場合は、中断して次のステップに進みます。

    3. 出力が表 1.2.1 または表 1.2.2 の形式と一致する場合（つまり、ファスト ペアリング プロバイダの現在の BLE アドレスまたはファスト ペアリング プロバイダのパブリック アドレスが含まれている場合）、値は正常に復号されます。

      注: パケットの最後にソルトが付加されています。可能であれば、これらのソルトを追跡する必要があります。プロバイダがすでに使用されているソルトを含むリクエストを受け取った場合は、リプレイ攻撃を防ぐためにそのリクエストを無視する必要があります。

    4. ソルトをトラッキングする代わりに、書き込みにプロバイダのプライベート アドレスが含まれている場合にリプレイ攻撃を防ぐもう 1 つの方法は、次に解決可能なプライベート アドレスのローテーションの時刻を早送りして、次の鍵ベースのペアリング書き込みが受け入れられる前にローテーションが行われるようにすることです。

  3. 値を復号できる鍵がない場合は、書き込みを無視して終了します。

    1. これらの失敗の数を数えます。失敗回数が 10 回に達すると、すべての新しいリクエストが直ちに失敗します。5 分後、電源投入後、または成功後に失敗カウントをリセットします。

  4. それ以外の場合は、成功した鍵を K として保存します。この K を、この LE リンクで受信したパスキーとパーソナライズした名前の書き込みの復号に使用できるようにマークしますが、他のリンクに対する他の書き込みや書き込みには使用しません。ペア設定が開始されていない場合は、10 秒後に K を破棄するようにタイマーを開始します。この LE リンクが切断された場合は、K も破棄します。

  5. 表 1.3 に示す 16 バイトの未加工レスポンスを生成します。このために、タイプとプロバイダの BR/EDR アドレスを連結し、パケットの残りの部分にランダムなバイトのブロック（ソルト）を入力します。

  6. 未加工のレスポンスを K で暗号化して、表 1.4 に示す 16 バイトの暗号化レスポンスを生成します。キーベースのペアリング特性に関する通知を介してこれを送信します。

  7. リクエスト フラグを読み取ります。

    1. リクエストのフラグバイトのビット 2 が 1 に設定されている場合は、パーソナライズされた名前で追加データ特性を通知します。
    2. リクエストのフラグバイトのビット 1 が 1 に設定されている場合:
      1. これは、シーカーがプロバイダにシーカーの BR/EDR アドレス（8 ～ 13 バイト目）へのボンディングを開始するようリクエストしていることを示します。
      2. シーカーの BR/EDR アドレスにペア設定リクエストを送信します。ペア設定リクエストは、後述（「ペア設定中」の手順）のとおりにする必要があります。
      3. 必要な理由: プロバイダを起動することで、一部のデバイスでの問題の回避が可能になります。
    3. リクエストのフラグバイトのビット 1 が 0 に設定されている場合:
      1. ペアリングのリクエストが表示されるまで、最大 10 秒待ちます。何も受信しない場合は、終了します。
      2. これは、別のアドレス（解決可能なプライベート アドレスではなく、シーカーの公開アドレス）からの BR/EDR リクエストである可能性があります。ペア設定の際に、リクエスト元のデバイスが K を所有していることが再確認します。

  8. ペア設定中:

    1. ペアリング リクエスト/レスポンス パケットをシーカーから受信した場合: リクエストの Device Capabilities が NoInput/NoOutput の場合は、Just Works のペア設定方法を使用しないようにペア設定を終了します。
    2. プロバイダから送信されるペアリング リクエスト/レスポンス パケットの場合: [Device Capabilities] フィールドを Display/YesNo に設定し、認証要件を [MITM Protection Required] に設定します。これにより、数値比較ペアリングメソッド（Android ではパスキー確認とも呼ばれます）がトリガーされます。Google はこれを利用して、リクエスト元のデバイスが実際にファスト ペアリング シーカーであり、中間者が存在しないことを確認します。例をご覧ください。
    3. 必要な理由: 帯域外ペア設定のほうが適していますが、Android の望ましいすべてのバージョンでこの機能が公開されるわけではありません。

  9. パスキーの確認が必要な場合は、パスキーの特性への書き込みを最大 10 秒待ちます。

    1. 通常、このペア設定方法では、ユーザーは各デバイスの画面に表示されるパスキーが同一であることを確認できます。代わりに、このペアリングに対してのみ、信頼できる事前共有キーで暗号化された BLE 経由で転送します。
    2. 画面やキーボードを備えたデバイスでは、MITM 保護が若干損なわれるため、このアプローチは採用しないでください。このため、現時点ではファスト ペアリングはこれらのデバイスタイプをサポートしていません。
    3. パスキーを書き込まずに 10 秒のタイマーが終了した場合は、K を破棄します。

  10. 値がパスキー特性に書き込まれる場合、これは暗号化されたパスキー ブロックです。これを K で復号し、Characteristic: Passkey > 表 2.2 - (type = Seeker's Passkey) に示す形式で未加工パスキー ブロックを生成します。

  11. 復号に失敗した場合は、書き込みを無視して K を破棄します。

  12. それ以外の場合、未加工パスキー ブロックには 6 桁のパスキー PSeeker が含まれます。これはシーカーが想定するパスキーです。

  13. PSeeker を、想定されているパスキー PProvider と比較します。

    1. 値が等しい場合は、確認に「yes」と返信します。
    2. それ以外の場合は、確認メッセージに「いいえ」と返信すると、ペア設定が失敗します。

  14. ペア設定が失敗したかどうかにかかわらず、特性: パスキー > 表 2.2 に示す形式で、独自のパスキー PProvider を含む未加工パスキー ブロックをもう 1 つ生成します。

    1. ブロックのタイプが正しいことを確認します（プロバイダのパスキー、表を参照）。注: シーカーから受け取ったパスキー ブロックのソルトは再利用しないでください。新しいランダム値を生成します。

  15. 未加工のパスキー ブロックを K で暗号化し、パスキー特性に関する通知を介して暗号化されたパスキー ブロックを送信します。

  16. シーカーが正しいパスキー P を受け取って復号すると、シーカーも確認に対して「yes」と応答し、ペア設定が成功します。

    1. ペアリングが成功したら、この LE リンクでのアカウントキーの書き込みの復号には K を使用可能としてマークしますが、後続のパスキーの書き込みや他のリンクへの書き込みでは使用不可としてマークします。10 秒後に K を破棄するタイマーを開始します。また、アカウントキーの書き込みを試みた後、ステップ 4 で LE リンクが切断された場合は、K を破棄します。
    2. ペア設定に失敗した場合は、K を破棄します。

  17. デバイス機能のフィールドをデフォルトの I/O 機能と認証要件に戻し、新しいペアリングが想定どおりに続行されるようにします。

ボンディングを必要としないプロバイダの場合、シーカーはプロバイダにペアリング リクエストを送信しません。つまり、ステップ 8 からステップ 17 はスキップされます。また、アカウントキー特性では「K」が使用されます。

例
例 1: ペア設定が成功する場合（中間者なし）。
例 2: 中間者によるペア設定の試行が失敗する。