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

手順

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

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

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

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

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

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

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

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

  8. ペア設定時:

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

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

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

  10. 値がパスキー特性に書き込まれる場合、これは暗号化されたパスキー ブロックです。特性: パスキー > 表 2.2 -（タイプ = シーカーのパスキー）に示す形式で、K で復号して未加工パスキー ブロックを生成します。

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

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

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

    1. 値が同じ場合は、確認に「yes」と返信します。
    2. それ以外の場合は、確認に「no」と返信すると、ペア設定が失敗します。

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

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

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

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

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

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

例
例 1: ペア設定に成功した場合（中間者なし）。
例 2: 中間者とのペア設定が失敗した場合。