性情

快速配對服務

快速配對提供者應具備下列 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：預先共用金鑰是以反假冒公開/私密金鑰組為基礎，而 Seeker 的個人公開/私密金鑰組會在每次嘗試配對時變更。

    • 供應商目前處於配對模式。
    • 查詢工具會驗證提供者是否確實擁有防假冒私密金鑰。

    請注意，在配對模式下，供應器也可能會照常配對，例如用於與不支援快速配對金鑰配對的裝置配對。

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

    • 供應商通常未處於配對模式。(但這並非硬性規定 — 即使在配對模式下，提供者仍應支援使用帳戶金鑰)。
    • 查詢者和提供者會分別驗證對方是否擁有帳戶金鑰。

由於這兩種情況極為相似，但除非使用預先共用金鑰，因此這兩種情況都會以「程序」合併使用。

資料格式

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

八位元 資料類型 說明 值 是否必要？
0 - 15 uint128 加密要求 各不相同 必要
16 - 79 則 公開金鑰 各不相同 選用

表 1.1：加密要求，由 Seeker 人員寫入。

八位元 資料類型 說明 值 是否必要？
0 uint8 訊息類型 0x00 = 金鑰型配對要求 必要
1 uint8 標記
  • 位元 0 (MSB)：已淘汰，並由 Seeker 略過。
  • 如果 Seeker 要求供應商啟動綁定，且此要求包含 Seeker 的 BR/EDR 位址，則位元 1：1。0。
  • 如果 Seeker 要求供應商應通知現有名稱，位元 2：1。0。
  • 如果使用的是「回溯寫入帳戶金鑰」，則位元 3：1。0。
  • 我們將保留位元 4 - 7 供日後使用，系統會忽略此位元。
 各有不同 必要
2 - 7 uint48 兩者之一：
  • 供應商目前的 BLE 位址
  • 供應商的公開位址
 各有不同 必要
8 - 13 則 uint48 旅行者巴西/EDR 地址 各有不同 只有在設定了 Bit 1 或 3 旗標時才會顯示
n - 15 隨機值 (鹽) 各有不同 必要

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

八位元 資料類型 說明 值 是否必要？
0 uint8 訊息類型 0x10 = 動作要求 必要
1 uint8 標記
  • 位元 0 (MSB)：如果是裝置動作，則為 1，否則為 0。
  • 如果後面接著「額外資料特性」，則位元 1：1，否則為 0。
  • 我們將保留 Bit 2 - 7 做為日後使用，並會遭到忽略。
 各有不同 必要
2 - 7 uint48 兩者之一：
  • 供應商目前的 BLE 位址
  • 供應商的公開位址
 各有不同 必要
8 uint8 訊息群組 各有不同 如果設定標記 Bit 0，就必須設定這個屬性
9 uint8 訊息代碼 各有不同 如果設定標記 Bit 0，就必須設定這個屬性
10 uint8 視標記而定：
  • 已設定位元 0：額外資料長度 (小於 6)
  • 位元 1 已設定：資料 ID
 各有不同 如果設定了 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. 使用在程序步驟 4 中產生的共用密鑰解密帳戶金鑰。
    • 需要綁定的提供者 (常見)：
      • 解密前，請確認共用密鑰用於解密步驟 12 的密碼金鑰要求。如未使用此密鑰通過這個步驟，請忽略並結束這個寫入作業。
    • 此時，這個配對不會再次使用共用密鑰 (程序中中的 K)。應拒絕所有以此金鑰加密且未重新啟動此程序的要求。
  2. 驗證解密的值開頭為 0x04。如果沒有，請忽略並結束寫入作業。
  3. 檢查保留的帳戶金鑰清單是否包含新值的空間。
  4. 如果不是，請從清單中刪除最近使用的值。
  5. 將新值加入清單中。

清單中的帳戶金鑰會在金鑰式配對期間使用。

特色：韌體修訂版本

這項特性可讓 Seeker 視需要讀取供應器的韌體修訂版本。它應該一律會傳回下列資料：

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

即使供應器上有多個韌體 (例如左耳機、右耳機和個案各有 3 個韌體)，它應可封裝為單一的 utf8 字串。「供應商」也可以傳回特殊案例的特定字串：

  1. 狀態更新：如果供應商目前正在更新至新韌體。或者，供應商也可以傳回階段式韌體的版本。

  2. 狀態-異常：如果提供者處於異常狀態。例如因韌體更新失敗而故障。這個值會讓跳轉器顯示訊息，通知使用者目前需要更新。

供應商應限制韌體修訂版本存取權，以防止裝置追蹤。建議的限制：

  • 綁定的裝置應隨時能存取
  • 只要是可偵測到供應器，應該都能存取任何裝置

特性：其他資料

此服務應具備以下特性。

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

在寫入或通知此特性之前，必須先透過特性 FE2C1234-8366-4814-8EB0-01DE32100BEA 握手才能擁有共用密鑰。AES-CTR 將用於加密透過這個特性傳輸的資料，其演算法定義如下。在延伸至單一 16 位元組區塊以上的資料中，這個模式會更加安全。HMAC-SHA256 將用於確保資料完整性，詳情請參閱下文的定義。

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

表 3.1：資料封包，由提供者透過通知傳送給探索者，或由 Seeker 寫入提供者。

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

表 3.2：原始資料。已從 表 3.1 中加密的資料解密。

要求通知時 (例如在表 1.2.1 中透過 Bit 2 要求個人化名稱)，快速配對提供者應執行以下操作：

  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 個位元組做為 Datapacket 的前置字串。

收到寫入請求時，快速配對提供者應執行以下操作：

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

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

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

    媒介

    1. enabledBlock[i] 是 16 個位元組的區塊，從 encryption_data[i * 16] 開始。 最後一個區塊可能小於 16 個位元組。
    2. AES 金鑰是由握手產生或識別，例如：
      1. 命名流程 1 中，這個值來自 ECDH，之後就不會再用於此配對。系統會拒絕任何以這組金鑰加密且未重新啟動該程序的要求。
      2. 在命名流程 2 中，是帳戶金鑰。

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