快速配對程序

操作程序

跳轉器不會立即叫用任何一般的 BR/EDR 或 BLE 連接程序，而是先針對金鑰式配對特性啟用通知，然後將表 1.1 中的資料寫入該組合。

處理快速配對探索工具的寫入要求時，快速配對提供者應執行以下操作：

  1. 如果有選填的「公開金鑰」欄位：
    1. 如果裝置未處於配對模式，請忽略寫入並結束。
    2. 否則：
      1. 使用收到的公開金鑰 (secp256r1 橢圓曲線上的 64 位元組點)、預先安裝的反假冒私密金鑰 (secp256r1) 和 Elliptic-Curve 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. 產生表 1.3 所示的 16 位元組原始回應，方法是串連類型和提供者的 BR/EDR 位址，然後將封包的其餘部分填入隨機位元組區塊 (即鹽)。

  6. 使用 K 加密原始回應，產生如表 1.4 所示的 16 位元組加密回應。透過「金鑰型配對」特性的通知傳送此訊息。

  7. 讀取要求旗標：

    1. 如果要求的旗標位元組將位元 2 設為 1，請通知其他資料特性，並提供個人化名稱。
    2. 如果要求的旗標位元組將位元 1 設為 1：
      1. 這表示探索工具要求供應者啟動與 Seeker 的 BR/EDR 位址繫結 (以位元組 8 到 13 表示)。
      2. 傳送配對要求至探險者的 BR/EDR 位址。配對要求必須依下方說明 (「配對期間」步驟)。
      3. 必要原因：讓供應商啟動部分裝置上的問題。
    3. 如果要求的旗標位元組將位元 1 設為 0：
      1. 等候 10 秒再提出配對要求。如果未收到任何訊息，請結束。
      2. 請注意，這可能是 BR/EDR 要求，可能來自不同的地址 ( Seeker 的公開位址，而非其可解析的私人地址)。 配對期間，我們會在配對期間重新驗證要求的裝置是否擁有 K。

  8. 配對期間：

    1. 從接收器收到配對要求/回應封包時：如果要求中的裝置功能為 NoInput/NoOutput，請避免使用 Just Works 配對方法。
    2. 針對供應商傳送的配對要求/回應封包：將「裝置功能」欄位設為 Display/YesNo，然後將驗證需求設為「MITM Protection Required」。這會觸發數字比較配對方法 (在 Android 上也稱為「密碼金鑰確認」)。我們仰賴此機制來確認提出要求的裝置確實是快速配對者，而且沒有中間人。請參閱範例。
    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. 比較探索工具與自己的預期密碼金鑰「PProvider」。

    1. 如果兩個值相同，請在確認訊息中回覆「是」。
    2. 否則，請回覆「否」，導致配對失敗。

  14. 無論配對是否成功，都會產生另一個原始密碼金鑰區塊，其格式如「Characteristic: Passkey」>「Table 2.2」，包含我們自己的預期密碼金鑰 PProvider。

    1. 確認區塊的類型正確無誤 (供應商的密碼金鑰，請見表格)。 注意：請勿重複使用來自探索工具的密碼金鑰區塊的鹽。產生新的隨機值。

  15. 使用 K 加密原始密碼金鑰區塊，並透過密碼金鑰特性的通知傳送產生的加密密碼金鑰區塊。

  16. 如果尋找工具收到並解密正確的密碼金鑰 P，探索工具也會回覆「是」來確認，配對成功。

    1. 如果配對成功，請將 K 標示為可用於解密這個 LE 連結上的帳戶金鑰寫入作業，但對於後續的任何密碼金鑰寫入或任何其他連結寫入作業都不適用。啟動計時器，在 10 秒後捨棄 K。在嘗試寫入帳戶金鑰後，也捨棄 K；如果 LE 連結中斷，則請按照步驟 4 所述情況捨棄。
    2. 如果配對失敗，請捨棄 K。

  17. 將裝置功能欄位切換回預設的 I/O 功能和驗證要求，讓新配對能夠繼續正常運作。

請注意，針對不需要綁定的提供者，尋找工具不會傳送配對要求給提供者，亦即步驟 8 至步驟 17。此外，帳戶金鑰特性也使用「K」。

示例
示例 1：成功配對連線 (沒有中間人)。
示例 2：中間人嘗試的配對失敗。