藍牙低功耗 (BLE) 裝置

適用於 BLE 裝置的 Google 快速配對服務 (GFPS) 實作項目與藍牙核心規格 4.2 以上版本相容。

以下是快速配對規格的附錄，可支援 GFPS 中的低耗電 (LE) 和低耗電音訊 (LEA) 裝置。

相容性等級

以下說明規格中提到的關鍵字「應」、「必須」、「將」、「應」、「可」和「能」：

字詞 說明
應該 必須：用於定義必要條件。
must 用於表示：
為先前所述必要要求的自然結果
或
具公信力的事實陳述 (無論情況為何)。
將 確實如此 - 僅用於陳述事實。
should 建議：用於指出在多個選項中，其中一個特別適合，但並非必要。
5 月 is permitted to：用於允許選項。
可以 可：用於以因果關係連結陳述式。

以金鑰為基礎的配對特徵

尋求者傳送給供應者的訊息

金鑰式配對特性的原始要求 type 0x00 會使用 Bit 4 來指出尋找工具是否支援 BLE 裝置規格，並使用 Bit 5 指出尋找器支援 LE Audio。

Octet 資料類型 說明 值 是否必要？
0 uint8 訊息類型 0x00 = 以金鑰為基礎的配對要求 必填
1 uint8 標記
  • 位元 0 (MSB)：已淘汰，Seeker 會忽略。
  • 位元 1：如果 Seeker 要求 Provider 啟動配對，且這項要求包含 Seeker 的 BR/EDR 位址，則為 1。否則為 0。
  • 位元 2：如果尋求者要求供應者通知現有名稱，則設為 1。否則為 0。
  • 位元 3：如果這是用於回溯寫入帳戶金鑰，則為 1。否則為 0。
  • 位元 4：如果 Seeker 支援 BLE 裝置規格，則為 1。否則為 0。
  • 位元 5：如果 Seeker 支援 LE Audio，則為 1。否則為 0。
  • 位元 6 到 7 保留供日後使用，應予以忽略。
 視情況而定 必填
2 到 7 uint48 符合以下任一條件：
  • 供應商目前的 BLE 地址
  • 供應商的 ID 地址
 視情況而定 必填
8 - 13 uint48 尋求者的 BR/EDR 地址 視情況而定 只有在設定旗標位元 1 或 3 時才會出現
n - 15 歲 隨機值 (鹽) 視情況而定 必填

供應者傳送給尋求者的訊息

設定要求的位元 4 後，您可以使用鍵值配對功能的新回應訊息 type 0x02，為 Seeker 提供其他配對選項。

Octet 資料類型 說明 值
0 uint8 訊息類型 0x02 = 以鍵為基礎的配對延伸回應
1 uint8 標記
  • 位元 0 (MSB)：如果提供者是僅支援 LE 的裝置，則為 1，否則為 0。如果位元 0 設為 1，Seeker 會假設位元 1 也設為 1。
  • 位元 1：如果供應器偏好 LE 連結，則值為 1，否則為 0。
  • 位元 2：如果第二個位址的位址類型為隨機，則值為 1；如果為公開，則值為 0。
  • 位元 3 到 7 保留供日後使用，應予以忽略。
 各不相同
2 uint8 供應者地址的數量
(在目前版本中，數量為 1 或 2，因為如果數量大於等於 3，我們需要將區塊加密模式修改為 AES-CTR)		 視情況而定
3 至 8 歲或
3 至 14 歲
  • 第一個地址應為主要節點的 ID 位址，如果偏好 BR/EDR 綁定，則可進行綁定
  • 如果第二個地址可以使用次要地址，則第二個地址應為次要地址
 視情況而定
9 到 15 或 15 隨機值 (鹽) 各不相同

支援 BLE 裝置規格的提供者應讀取 Bit 4 和 Bit 5 來瞭解尋找者的功能

  • 當 Bit 4 為 0 時，提供者應忽略 Bit 5，並以 type 0x01 格式回應
  • 當 Bit 4 為 1 時，
    • 對於僅限 LE 的供應器，應回應 type 0x02，以表示 LE 連結偏好設定。
    • 對於雙模式提供者，它可以回應 type 0x02，表示 BR/EDR 或 LE 連結偏好設定。
  • 如需 LE Audio (LEA) 雙模式供應器的案例，請參閱範例：與 LEA 雙模式供應器配對

訊息串流 PSM (通訊協定服務多工器) 特性

為了支援 BLE 裝置的訊息串流，快速配對功能會建立並維護 BLE L2CAP 通道，用於傳送及接收訊息。Fast Pair L2CAP 伺服器應實作 LE 信用額流量控制。

這項特性可讓 Seeker 讀取 PSM 值，然後透過 PSM 值建立安全的 L2CAP 連線。

快速配對服務特性 已加密 權限 UUID
訊息串流 PSM 是 讀取 FE2C1239-8366-4814-8EB0-01DE32100BEA
Octet 資料類型 說明 值
0 uint8 狀態
  • 0x00 = 不明。FP Seeker 將重試多次
  • 0x01 = 可連線
  • 0x02 = 無法使用。FP Seeker 這次不會使用這個元件進行連線
 視情況而定
1 - 2 uint16 PSM 值應介於 0x80 和 0xFF 之間 視情況而定

注意：針對 TWS，有兩個元件：主要和次要元件。在某些情況下，這些元件的角色可以互換。假設 A 是主要元件，而 B 是次要元件，因為由於元件 A 的電池耗電，而元件 B 必須獲取主要元件角色，在此情況下為 role switch。

在 role switch 之後，如果供應器無法處理快速配對訊息串流，應主動中斷現有的 L2CAP 連線。快速配對尋找器隨後可透過新的主要元件重新建立 L2CAP 訊息串流連線。

其他密碼金鑰特性

這項屬性可為額外元件提供 MITM 保護。

CSIS 假會員中間人攻擊 (MITM) 防護

快速配對功能需要在配對程序中提供 MITM 保護。由於 CSIS 不提供 MITM 保護，因此需要擴充目前針對多個元件的 FP 設計，以便為其他元件提供 MITM 保護。

特徵定義

快速配對服務特徵 已加密 權限 UUID
其他密碼金鑰 是 讀取、寫入、通知 FE2C123A-8366-4814-8EB0-01DE32100BEA

訊息

訊息格式會套用至讀取、寫入和通知作業。

加密資料格式

加密資料是使用快速配對 GATT 連線傳送。

Octet 資料類型 說明 值
0-15 uint128 已加密的額外密碼金鑰區塊 視情況而定
原始資料格式

使用共用密鑰解密加密資料後，格式如下：

Octet 資料類型 說明 值
0 uint8 訊息類型 下列其中之一：
  • 0x00 = 尋找者的密碼金鑰
  • 0x01 = 供應者的密碼金鑰
1-3 uint24 6 位數密碼金鑰 變動
4-9 uint48 目標綁定元件位址 變動
10 uint8 狀態碼，僅供讀取作業使用 下列其中一個
  • 0x00 = 成功
  • 0x01 = 未放送。FP Seeker 重試，直到逾時為止
  • 0x02 = 失敗。FP Seeker 停止重試
11-15 隨機值 (鹽) 視情況而定

主要 (第一個綁定元件) 是快速配對尋找者與其他綁定元件之間的橋樑。特徵應遵循以下規範：

  • 收到快速配對尋找器的寫入要求時，供應器應
    • 設定要綁定的元件地址
    • 將密碼金鑰傳送至要綁定的元件
    • 將狀態碼設為 Pending (待處理)，0x01
  • 在接收已綁定元件的密碼金鑰之前，如果接收任何讀取要求，供應器應傳回含有
    • 密碼金鑰 (任何值)
    • 要綁定的元件位址
    • 待處理狀態碼 0x01
  • 在供應器傳送通知給快速配對尋找者之前，請使用
    • 要綁定的元件密碼金鑰
    • 要綁定的元件位址
    • 成功狀態碼 0x00
  • 如果供應器端發生任何無法復原的錯誤，請設定結果
    • 密碼金鑰 (任何值)
    • 要綁定的元件位址
    • 失敗狀態碼，0x02

詳情請參閱 MITM 圖表 1 和 MITM 圖表 2。

LE 裝置需求條件

LE Advertising

在可偵測模式或不可偵測模式下，供應商應使用 RPA 宣傳 FastPair 資料。

黏著功能

對於支援 LE 的裝置，Seeker 必須與現有的 LE 連線建立連結。通過快速配對金鑰配對驗證後，供應商應允許與 RPA 建立繫結，並將 IO 功能設為 DisplayYesNo 以進行快速配對密碼金鑰驗證。

LEA 裝置需求

LEA Advertising

如果是雙模式裝置：如果為可偵測模式，供應商應透過身分識別地址通告快速配對資料。如果是無法偵測的模式，供應商應使用 RPA 宣傳快速配對資料。 強烈建議您使用舊版廣告 (BT 4.2)，以便支援舊版裝置，確保回溯相容性。每次裝置恢復原廠設定時，都必須變更 IRK。

非雙模式裝置：在可偵測模式或不可偵測模式下，供應器應使用擴充廣告 (BT 5.0) 搭配 RPA 來宣傳 FastPair 資料。

包含 FP 服務資料的 LE 可連結廣告應遵循 藍牙介面卡設定檔 (BAP 1.0.1) 和 通用音訊設定檔規定，並包含 CAS UUID。如果因為加入電池和 SASS 資料而因缺少電池和 SASS 資料而無法在舊版廣告中找到足夠的空間，則無法探索的廣告應在掃描回應中加入 CAS UUID。

LEA 黏合功能

尋覓者必須與現有的 LE 連線建立連結。通過快速配對密鑰配對驗證後，雙模式供應器應允許與 ID 位址和 RPA 建立連結，而非雙模式供應器應允許與 RPA 建立連結，並將 IO 能力設為 DisplayYesNo，以便進行快速配對密鑰驗證。

元件之間的內部通訊管道

現有的 GATT 連線會保留，以便對其他元件執行 MITM 保護機制。主要綁定元件應處理 Fast Pair Seeker 與其餘元件之間的訊息傳遞作業。

內部通訊用於 Initial Pair 和 Subsequent Pair

  • 當以鍵為基礎的配對程序傳遞主要元件時，主要元件應傳送訊息，以變更其餘元件的 IO 能力
  • 快速配對完成後，主要元件應傳送訊息，重設其其餘元件的 IO 功能
  • 執行其他密碼金鑰程序時，主要元件應處理透過快速配對尋找工具及其剩餘元件之間的密碼金鑰傳送作業

變更 I/O 功能的時機

  • 在 Key-based Pairing 程序通過時，將 IO 能力變更為 DisplayYesNo
    • 如果裝置有多個元件，則應將所有元件設為 DisplayYesNo
    • 供應者不得將 IO 能力變更為 DisplayYesNo 的例外狀況是 Retroactive Pair，其 Key-based Pairing Request 的 Bit 3 設為 1，請參閱Seeker 傳送給供應者的訊息
  • 將 I/O 功能變更為預設設定
    • 初始配對
      • 如果 LE 連線中斷，請結束快速配對工作階段
      • 主要裝置配對後，如果 15 秒內沒有其他密碼金鑰寫入要求，則結束快速配對工作階段
      • 收到其他密碼金鑰寫入要求後，如果要綁定的元件未在 15 秒內綁定，就結束快速配對工作階段
      • 所有元件連結後，如果 15 秒內沒有帳戶金鑰寫入要求，請結束快速配對工作階段
      • 收到帳戶金鑰寫入要求後，將逾時時間設為 15 秒，以結束快速配對工作階段
    • 後續配對
      • 如果 LE 連線中斷，請結束快速配對工作階段
      • 主要裝置配對後，如果 15 秒內沒有其他密碼金鑰寫入要求，則結束快速配對工作階段
      • 收到其他密碼金鑰寫入要求後，如果要綁定的元件未在 15 秒內綁定，就結束快速配對工作階段
      • 所有元件都建立繫結後，結束快速配對工作階段

隱藏 UI 指示

當耳機無法配對時，提供者應使用 type 0b0010 為帳戶金鑰資料設定隱藏 UI 指示，指示尋找器不要顯示後續配對 UI (請參閱「廣告酬載：快速配對帳戶資料」)。

LE 音訊裝置需求

藍牙需求

請參閱 Android LE Audio 耳機推薦內容。

CTKD 支援

對於雙模式裝置，從 LE 到 BR/EDR 的 CTKD 是強制規定，且符合 BAP 規定。

指定公告

周邊裝置應使用指定廣播，向已配對的中央裝置索取連線。依據CAP 1.0 表 8.4 (p48/58) 的規定，連線管理的 BAP 和 CAP 中定義了目標公告。

GATT EATT 伺服器支援

EATT 可讓中樞裝置在裝置綁定時，並行傳送多個 GATT 交易。對於支援 CSIP 的裝置，這項功能可提高設定檔連線效能，並且很快開始為其他耳機啟動 CSIP 綁定程序。

如果提供者不是單一裝置，而是與 CSIP 實作相互協調合作，為減少探索服務的次數並加快連線速度，供應商應實作藍牙 5.1 中定義的 GATT 快取。

快速配對需求

LE Advertising

在可偵測模式或不可偵測模式下，如果裝置有多個元件，則主要元件應宣傳快速配對資料。如果裝置尚未準備好進行後續配對，次要元件可以宣傳 Fast Pair 資料，以便使用擴充功能。請參閱「隱藏 UI 指示」。

GATT 服務可見性

所有 LE 傳輸 GATT 連線的 GATT 資料庫都應相同。快速配對連線的 GATT 資料庫中應包含 LE Audio 服務 (0x184E)。

範例：與 LEA 雙模式供應器配對

情境 1 - 尋找者不支援 LEA

供應者必須具備回溯相容性，可支援不支援 LEA 的 Seeker。

元件
  • 提供者：A2DP/HFP/LEA
  • 搜尋者：A2DP/HFP
初始配對 / 後續配對的預期行為
  • 供應商使用身分地址 (初始) 或 RPA (之後) 宣傳快速配對服務資料 (0xFE2C)。
    • 使用舊版廣告
  • 尋找者會收到提供者的廣告，其中包含初始 ID 位址或後續配對的 RPA
  • 尋找者傳送以金鑰為基礎的配對要求
    • 金鑰式配對要求的位元-5 設為 0
  • 供應者會傳送金鑰式配對回應，並在下列其中一種情況中提供公開地址：
    • 如果使用訊息類型 0x01，地址應為公開地址
    • 如果使用訊息類型 0x02
      • 位元-0 應為 0
      • Bit-1 應為 0
      • 地址必須是公開地址
  • 尋人使用 BR/EDR 傳輸功能建立鍵結
    • BR/EDR 的 IO 功能已設為 DisplayYesNo
  • 尋找者和供應者執行 Fast Pair 密碼金鑰驗證程序

情境 2：Seeker 支援 LEA

元件
  • 供應商
    • 支援 A2DP/HFP/LEA
    • 單一元件
  • 探索者
    • 支援 A2DP/HFP/LEA
初始配對 / 後續配對的預期行為
  • 供應商使用身分地址 (初始) 或 RPA (之後) 宣傳快速配對服務資料 (0xFE2C)。
    • 使用舊版廣告
  • 尋找者傳送以金鑰為基礎的配對要求
    • 以金鑰為基礎的配對要求的旗標位元 5 設為 1
  • 提供者傳送以金鑰為基礎的配對回應，訊息類型為 0x02
    • 位元 0 應為 0
    • Bit-1 應為 1
    • 地址為身分證件地址
  • Seeker 會在 LE 傳輸上與現有的 LE 連線建立連結
    • CTKD 的方向從 LE 到 BR/EDR
    • LE 的 IO 功能已設為 DisplayYesNo
  • 尋找者和供應者執行 Fast Pair 密碼金鑰驗證程序

情境 3：當 Seeker 支援 LEA 和 CSIP 時

元件
  • 供應商
    • 支援 A2DP/HFP/LEA
    • 多個元件
      • 主要組件為 BR/EDR/LE
      • 次要元件僅限 LE
  • 探索者
    • 支援 A2DP/HFP/LEA
初始配對 / 後續配對的預期行為
  • 主要元件會使用 ID 位址 (初始) 或 RPA (後續) 宣傳 Fast Pair 服務資料 (0xFE2C)。
    • 使用舊版廣告
  • 尋找工具會將金鑰式配對要求傳送至主要元件
    • 金鑰式配對要求的位元-5 設為 1
  • 主要元件會傳送含有 0x02 訊息類型以金鑰為基礎的配對回應
    • 位元 0 應為 0
    • Bit-1 應為 1
    • 地址如下：
      • 第一個地址是主要元件的 ID 位址
      • 第二個位址是次要元件的可綁定位址，第二個元件也會使用這個位址進行 CSIP 廣告
  • Seeker 會在現有 LE 連線上與主要元件建立連結
    • CTKD 方向是從 LE 到 BR/EDR
    • 將 IO 能力設為 LE 的 DisplayYesNo
  • Seeker 會與次要元件建立連結，該元件的位址來自 Key-based Pairing Extended Response
    • IO 功能應為 DisplayYesNo，否則拒絕配對要求
  • 尋求者和供應者會執行 MITM 保護程序，以便配對次要元件，供應者應在兩種情況下實作
  • Seeker 會等到與次要元件連結後才執行

MITM 的流程圖

這場講座會說明 MITM 保護程序的順序。

透過通知取得已綁定的元件密碼金鑰

透過讀取方式，從已綁定的元件取得密碼金鑰

已知問題

已針對 LEA 的 FP 進行最佳化，以便與 Android V(Android 15) 搭配運作。

相反地，我們也遇到許多問題，這些問題與支援 LEA 但缺少正確的 LEA 快速配對實作方式 (也就是僅支援經典版快速配對) 的耳機有關。舉例來說，如果提供者的 RPA 並非由正確的 ID 解析鍵 (IRK) 產生，就無法解析地址。雖然我們無法測試完整的耳機設定清單，但有限的測試結果顯示了各種問題，包括無法顯示耳機電池通知、缺少音訊切換 (SASS) 功能、初始和後續配對失敗的情況普遍存在等等。

因此，我們強烈建議合作夥伴為新裝置和現有裝置 (透過無線更新) 實作快速配對-LEA 規格，以便支援雙模式。