特性

快速配對服務

快速配對供應商應具備下列 GATT 服務。

服務 UUID
快速配對服務 0xFE2C

這項服務具有下列特性。

快速配對服務特性 已加密 權限 UUID
模型 ID 否 讀取 FE2C1233-8366-4814-8EB0-01DE32100BEA
金鑰式配對 否 撰寫與通知 FE2C1234-8366-4814-8EB0-01DE32100BEA
密碼金鑰 否 撰寫與通知 FE2C1235-8366-4814-8EB0-01DE32100BEA
帳戶金鑰 否 寫入 FE2C1236-8366-4814-8EB0-01DE32100BEA

裝置資訊服務

快速配對供應商亦應支援裝置資訊服務。

服務 UUID
裝置資訊服務 0x180A

支援快速配對功能的廣告主需要下列特性，

名稱 已加密 權限 UUID
韌體修訂版本 否 讀取 0x2A26

特性：模型 ID

這項特性允許尋找者視需要讀取模型 ID，但 裝置在可探索模式中啟用廣告時。此值應一律傳回 下列資料：

八位元 資料類型 說明 值
0 - 2 uint24 模型 ID 變動

特性：鍵式配對

這項特性控制金鑰式配對程序。在這個程序中 培養特定信任程度的方法是驗證求職者和 提供者皆擁有預先共用金鑰。與 這兩種情況：

  • 案例 1：預先共用金鑰是以防假冒公開/私密金鑰為基礎 以及觀察器自己的公開/私密金鑰組， 配對嘗試。

    • 供應商已進入配對模式。
    • 尋求確認者是否持有 以及防偽私密金鑰

    請注意，進入配對模式時，供應商也可能會在 例如與不支援 Fast 的裝置配對 組合鍵式配對。

  • 案例 2：預先共用金鑰是其中一個帳戶金鑰。

    • 供應商通常未處於配對模式。(但這並不是 要求 — 供應商應支援使用帳戶金鑰，即使在 配對模式)。
    • 調查對象和提供者各自驗證對方是否持有 帳戶金鑰。

這兩種情況極為相似，除了使用預先共用金鑰之外， 並以採購程序合併計算。

資料格式

如要瞭解每種格式的使用方式，請參閱程序。

八位元 資料類型 說明 值 必要？
0 - 15 uint128 加密要求 變動 必填
16 - 79 公開金鑰 變動 選用

表 1.1：由求職者寫入的加密要求。

八位元 資料類型 說明 值 必要？
0 uint8 訊息類型 0x00 = 以金鑰為基礎的配對要求 必填
1 uint8 標記
  • 位元 0 (MSB)：已淘汰並由 Seeker 忽略。
  • 位元 1：1 (如果尋求者要求提供者應啟動繫結)，且此要求包含搜尋者的 BR/EDR 地址。否則為 0。
  • 位元 2：1 (如果尋求者要求供應商應通知現有名稱)。否則為 0。
  • 位元 3：1 代表用於「回溯寫入帳戶金鑰」。否則為 0。
  • 位元 4 - 7 會保留供日後使用，並應予以忽略。
 各不相同 必填
2 - 7 uint48 符合以下任一條件：
  • 供應商目前的 BLE 位址
  • 提供者的公開位址
 各不相同 必填
8 - 13 uint48 調查員的巴西/EDR 地址 各不相同 僅在已設定 Flags Bit 1 或 3 時才會顯示
n - 15 歲 隨機值 (鹽) 各不相同 必填

表 1.2.1：原始要求 (類型 0x00)。已透過加密的方式解密 表 1.1 中的要求。

八位元 資料類型 說明 值 必要？
0 uint8 訊息類型 0x10 = 動作要求 必填
1 uint8 標記
  • 位元 0 (MSB)：如果是「裝置動作」，值為 1，否則為 0。
  • 位元 1：1 後面會接著「其他資料特性」，否則為 1，否則為 0。
  • 位元 2 - 7 將保留供日後使用，並應予以忽略。
 各不相同 必填
2 - 7 uint48 符合以下任一條件：
  • 供應商目前的 BLE 位址
  • 提供者的公開位址
 各不相同 必填
8 uint8 訊息群組 各不相同 若設定 Flags Bit 0 則為必要項目
9 uint8 訊息代碼 各不相同 若設定 Flags Bit 0 則為必要項目
10 uint8 視旗標而定：
  • 已設定位元 0：額外資料長度，小於 6
  • 已設定位元 1：資料 ID
 各不相同 如果設定 Flags Bit 0 或 1 則為必要項目
11 - n 額外資料 各不相同 選用
n - 15 歲 隨機值 (鹽) 各不相同 必填

表 1.2.2：原始要求 (類型 0x10)。已透過加密的方式解密 表 1.1 中的要求。

八位元 資料類型 說明 值
0 uint8 訊息類型 0x01 = 以鍵為基礎的配對回應
1 - 6 uint48 供應商的公開 (BR/EDR) 地址 各不相同
7 - 15 隨機值 (鹽) 各不相同

表 1.3：原始回應。已加密，以產生加密回應 表 1.4.

八位元 資料類型 說明 值
0 至 15 天 uint128 加密回應 各不相同

表 1.4：供應商透過 通知

特性：密碼金鑰

這項特性可用於 鍵式配對 程序。

八位元 資料類型 說明 值
0 - 15 uint128 加密密碼金鑰封鎖 各不相同

表 2.1：加密密碼金鑰區塊。詳情請見 以金鑰為基礎的配對程序使用。

八位元 資料類型 說明 值
0 uint8 訊息類型 下列其中一項：
  • 0x02 = 求職者的密碼金鑰
  • 0x03 = 供應商的密碼金鑰
1 - 3 人 unit32 6 位數密碼金鑰 各不相同
4 - 15 隨機值 (鹽) 各不相同

表 2.2：原始密碼金鑰封鎖。解密版本 表 2.1。

特性：帳戶金鑰

配對完成後，「快速配對」探索工具會撰寫「帳戶金鑰」至快速配對 提供者。

八位元 資料類型 說明 值
0 - 15 uint128 帳戶金鑰 (加密) 各不相同

收到寫入要求後，「快速配對供應商」應執行以下操作：

  1. 使用 。
    • 適用於需要建立繫結的供應商 (常見)：
      • 解密前，請先確認共用密鑰是用於解密 。如果此步驟尚未通過 密鑰，請忽略這個寫入並退出。
    • 此時，系統不會使用共用密鑰 (程序中的 K) 才能進行配對。以這組金鑰加密的所有要求 如果沒有重新啟動程序，則應拒絕
  2. 確認解密值的開頭是 0x04。如果沒有，則忽略 這一切都是寫作並結束
  3. 檢查保存的「帳戶金鑰清單」是否有足夠的空間可以存放新的金鑰 值。
  4. 如果不是，請從清單中刪除近期最少使用的值。
  5. 將新值加入清單。

清單中的帳戶金鑰會用於按鍵配對。

特性：韌體修訂版本

這項特性可讓 Seeker 讀取 提供者 (如有需要)。應該一律傳回下列資料：

八位元 資料類型 說明 值
0 - var utf8s 韌體修訂版本代碼 各不相同

即使包含多個 utf8 字串，仍應封裝為單一 utf8 字串 「供應商」提供的韌體 (例如左耳機、右耳機和充電盒各 3 個韌體)。 提供者也可以傳回特殊情況的特定字串：

  1. status-updating：如果供應商目前正在更新韌體。 或者，「供應商」也可以傳回暫存韌體的版本。

  2. status-abnormal：如果供應商處於異常狀態，例如 韌體更新失敗，因此復原故障。這個值會導致 讓使用者知道訊息必須立即更新。

供應商應將韌體修訂版本的特性限制在 防止裝置追蹤建議的限制：

  • 綁定裝置應隨時擁有存取權
  • 可找到供應商後，任何裝置應該都能存取該項目

特性：額外資料

這項服務具有以下特性。

快速配對服務特性 已加密 權限 UUID
資料 否 撰寫與通知 FE2C1237-8366-4814-8EB0-01DE32100BEA
舊的快速配對服務特性 (目標將於 2021 年 1 月 1 日淘汰) 已加密 權限 UUID
資料 否 撰寫與通知 0x1237

在撰寫或通知這個特性之前，必須 透過特性 FE2C1234-8366-4814-8EB0-01DE32100BEA 實現 共用密鑰AES-CTR 將用來加密透過此伺服器傳送的資料 特性的演算法，定義如下。這個模式更加 能跨越超過單一 16 位元組區塊的資料安全地予以保護。HMAC-SHA256 負責確保資料完整性，也可以從下方定義。

八位元 說明 值
0 - 7 前 8 個位元組的 HMAC-SHA256。 各不相同
8 - 15 AES-CTR 加密使用的 Nonce。 各不相同
16 - var 加密資料。 各不相同

表 3.1：資料封包，透過 由求職者透過書面通知或傳送給供應商。

八位元 資料類型 說明 值
0 - var byte array 資料 varies 中，請根據表 1.2.2 的資料 ID 解碼：
  • 0x01(個人化名稱)：utf8s

表 3.2：原始資料。從以下加密資料進行解密的 表 3.1.

系統要求傳送通知時 (例如透過 Bit 2 在 表 1.2.1) 中，快速配對供應商應執行以下操作：

  1. 針對 Nonce 隨機產生 8 個位元組的加密編譯位元組。

  2. 使用 AES-CTR 加密資料，每個 16 位元組區塊都會產生

    encryptedBlock[i] = clearBlock[i] ^ AES(key, concat((uint8) i, 0x00000000000000, nonce))

    媒介

    1. AES 金鑰是程序中步驟 4 的共用密鑰。
    2. ClearBlock[i] 從 data[i * 16] 開始的 16 個位元組區塊。最近 區塊小於 16 個位元組

  3. 執行 concat(EncryptBlock[0], encryptionBlock[1],...) 以建立 加密資料。

  4. 產生 HMAC-SHA256，方法如下：

    sha256(concat((K ^ opad), sha256(concat((K ^ ipad), concat(nonce, encrypted_data)))))

    媒介

    1. K 是由 concat(shared_secret, 48-byte ZEROs) 產生 shared_secret 位在程序的步驟 4 中。
    2. opad 是 64 個位元組的外邊框間距，由 0x5C。
    3. ipad 是 64 個位元組的內部邊框間距，由具值的重複位元組組成 0x36。

  5. 以 HMAC-SHA256 中的前 8 個位元組做為資料前置字串 封包。

收到寫入要求後，「快速配對供應商」應執行以下操作：

  1. 檢查前 8 個位元組的資料，確認資料完整性 HMAC-SHA256。

  2. 使用 AES-CTR 解密已加密的資料，且每個區塊都會以

    clearBlock[i] = encryptedBlock[i] ^ AES(key, concat((uint8) i, 0x00000000000000, nonce))

    媒介

    1. encryptionBlock[i] 是從 encryption_data [i * 16] 的 16 位元組區塊開始。 最後一個區塊可小於 16 個位元組。
    2. AES 金鑰會在握手時產生或識別，例如
      1. 「命名流程 1」中，擷取自 ECDH 就會再次用於本次配對由加密程序提出的所有要求 無需重新啟動這項程序，就能順利執行 遭到拒絕。
      2. 在命名流程 2 中，則這是帳戶金鑰。

  3. 執行 concat(clearBlock[0], clearBlock[1],...) 以建立原始資料。