藍牙低功耗 (BLE) 裝置

藍牙低功耗裝置的 Google 快速配對服務 (GFPS) 實作項目與 Bluetooth Core Specification v4.2 以上版本相容。

Fast Pair 規格的下列附錄將允許 GFPS 支援僅限低功耗 (LE) 和低功耗音訊 (LEA) 的裝置。

一致性等級

規格中提及的「應」、「必須」、「將」、「應該」、「可」和「可以」等關鍵字說明如下：

字詞 說明
應 為必要 - 用於定義需求。
必須 用於表示：
先前所述強制性規定的自然結果
或
無可爭議的事實陳述 (無論情況如何，一律為真)。
會 這是事實 - 僅用於事實陳述。
應 建議 - 用於指出在多種可能性中，建議使用特別合適的選項，但並非必要。
5 月 可以：用於允許選項。
涵蓋範圍 能夠 - 用於以因果方式連結陳述式。

以金鑰為準的配對特徵

求助者傳送給服務供應商的訊息

「Raw Request」type 0x00 的「Key-based Pairing characteristic」會使用位元 4 指出 Seeker 是否支援 BLE 裝置規格，並使用位元 5 指出 Seeker 是否支援 LE Audio。

八位元 資料類型 說明 值 是否為必要欄位？
0 uint8 訊息類型 0x00 = 以金鑰為準的配對要求 必填
1 uint8 旗標
  • 位元 0 (MSB)：已淘汰，Seeker 會忽略。
  • 位元 1：如果 Seeker 要求 Provider 啟動繫結，且這項要求包含 Seeker 的 BR/EDR 位址，則為 1。否則為 0。
  • 位元 2：如果 Seeker 要求 Provider 通知現有名稱，則為 1。否則為 0。
  • 位元 3：如果是追溯寫入帳戶金鑰，則為 1。否則為 0。
  • 位元 4：如果 Seeker 支援 BLE 裝置規格，則為 1。否則為 0。
  • 位元 5：如果 Seeker 支援 LE Audio，則為 1。否則為 0。
  • 位元 6 至 7 保留供日後使用，應予以忽略。
 因人而異 必填
2 - 7 uint48 以下任一項：
  • 供應商目前的 BLE 位址
  • 供應商的身份位址
 因人而異 必填
8 - 13 uint48 搜尋者的 BR/EDR 地址 因人而異 只有在設定 Flags Bit 1 或 3 時才會顯示
n - 15 隨機值 (鹽) 因人而異 必填

服務提供者傳送給服務需求者的訊息

要求的位元 4 設為 1 時，即可使用「以金鑰為準的配對」特徵的新回應訊息 type 0x02，為 Seeker 提供其他繫結選項。

八位元 資料類型 說明 值
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 裝置規格的供應商應讀取位元 4 和位元 5，瞭解搜尋者的功能

  • 當位元 4 為 0 時，供應商應忽略位元 5，並以 type 0x01 格式回應
  • 當位元 4 為 1 時，
    • 如果是僅支援 LE 的供應商，則應回覆 type 0x02，指出 LE 連結偏好設定。
    • 如果是雙模式供應器，可以透過 type 0x02 回應，指出 BR/EDR 或 LE 連結偏好設定。
  • 如為 LE Audio (LEA) 雙模式供應商案例，請參閱「範例：與 LEA 雙模式供應商配對」

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

為支援 BLE 裝置的訊息串流，快速配對會建立並維護 BLE L2CAP 管道，用於收發訊息。快速配對 L2CAP 伺服器應實作以 LE 信用為基礎的流量控制。

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

快速配對服務特徵 已加密 權限 UUID
Message Stream PSM 是 讀取 FE2C1239-8366-4814-8EB0-01DE32100BEA
八位元 資料類型 說明 值
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 訊息串流連線。

其他密碼金鑰特徵

這項特徵可為額外元件提供中間人攻擊防護。

CSIS Fake Member MITM Protection

快速配對程序需要 MITM 保護機制。由於 CSIS 不提供 MITM 防護，因此目前多個元件的 FP 設計需要擴充，才能為額外元件提供 MITM 防護。

特徵定義

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

訊息

訊息格式適用於讀取、寫入和通知作業。

加密資料格式

加密資料會透過「快速配對」GATT 連線傳送。

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

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

八位元 資料類型 說明 值
0 uint8 訊息類型 下列其中一項：
  • 0x00 = Seeker 的密碼金鑰
  • 0x01 = 供應商的密碼金鑰
1-3 uint24 6 位數密碼金鑰 視情況而定
4-9 uint48 目標連結元件地址 視情況而定
10 uint8 狀態碼，僅供讀取作業使用 下列其中一項：
  • 0x00 = 成功
  • 0x01 = 待處理。FP Seeker 會重試，直到逾時為止
  • 0x02 = 失敗。FP Seeker stop retry
11-15 隨機值 (鹽) 視情況而定

主要元件 (第一個繫結的元件) 是快速配對搜尋器與其他繫結元件之間的橋樑。特徵應遵循下列規範：

  • 收到快速配對 Seeker 的寫入要求時，Provider 應
    • 設定要繫結的元件位址
    • 將密碼金鑰傳送至要繫結的元件
    • 將狀態碼設為「待處理」，0x01
  • 在收到來自繫結元件的密碼金鑰之前，如果收到任何讀取要求，Provider 應傳回含有
    • 密碼金鑰，任何值
    • 要繫結的元件地址
    • 待處理狀態碼 0x01
  • 在供應器將通知傳送至「快速配對」搜尋器之前，請使用
      設定讀取要求的結果。
    • 要繫結的元件密碼金鑰
    • 要繫結的元件地址
    • 成功狀態碼，0x00
  • 如果供應商端發生任何無法復原的錯誤，請將結果設為
    • 密碼金鑰，任何值
    • 要繫結的元件地址
    • 失敗狀態碼 0x02

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

LE 裝置需求

LE Advertising

無論是可探索模式或不可探索模式，供應商都應使用 RPA 宣傳 FastPair 資料。

黏著修復功能

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

學區裝置需求

LEA Advertising

雙模式裝置： 在可探索模式中，供應商應使用身分位址宣傳快速配對資料。 如果是無法探索的模式，供應商應使用 RPA 宣傳「快速配對」資料。強烈建議使用舊版廣告 (BT 4.2)，支援舊版裝置以確保回溯相容性。裝置恢復原廠設定時，必須變更 IRK。

非雙模式裝置： 無論是可探索模式或不可探索模式，供應商都應使用擴展廣告 (BT 5.0) 和 RPA，放送 FastPair 資料。

包含 FP 服務資料的 LE 可連線廣告應包含 CAS UUID，並遵守 Bluetooth Adapter Profile (BAP 1.0.1) 和Common Audio Profile 規定。

無論可探索模式為何，供應商都可以在服務資料 (AD Type 0x16) 或 16 位元服務類別 UUID (AD Type 0x02 或 0x03) 中加入 CAS UUID (0x1853)，藉此指出 LEA 功能。

如果因納入電池和 SASS 資料，導致舊版廣告空間不足，無法顯示廣告，則必須在掃描回應中加入 CAS UUID。

LEA 黏著修復功能

Seeker 必須與現有的 LE 連線建立繫結。通過快速配對金鑰驗證後，雙模式供應商應允許與身分位址和 RPA 繫結，非雙模式供應商則應允許與 RPA 繫結，並將快速配對密碼金鑰驗證的 IO 能力設為 DisplayYesNo。

元件之間的內部通訊管道

系統會保留現有的 GATT 連線，對其他元件執行 MITM 保護。主要連結元件應處理快速配對搜尋器及其餘元件之間的訊息傳遞作業。

內部通訊用於 Initial Pair 和 Subsequent Pair

  • 當以金鑰為準的配對程序通過主要元件時，主要元件應傳送訊息，變更其餘元件的 IO 功能
  • 快速配對完成後，主要元件應傳送訊息，重設其餘元件的 IO 功能
  • 執行額外密碼金鑰程序時，主要元件應處理快速配對搜尋器及其餘元件之間的密碼金鑰傳送作業

變更 IO 功能的時間

  • 當通過以金鑰為準的配對程序時，將 IO 功能變更為 DisplayYesNo
    • 如果裝置有多個元件，所有元件都應設為 DisplayYesNo
    • 如果「供應商」不得將 IO 功能變更為 DisplayYesNo，則「供應商」應將 Bit 3 設為 1，請參閱「從搜尋者傳送至供應商的訊息」。Retroactive Pair
  • 將 IO 功能變更為預設設定
    • 初始配對
      • 如果 LE 連線中斷，請結束快速配對工作階段
      • 主要裝置完成配對後，如果 15 秒內沒有其他密碼金鑰寫入要求，則結束快速配對工作階段
      • 收到額外的密碼金鑰寫入要求後，如果要在 15 秒內綁定元件，請結束快速配對工作階段
      • 所有元件完成繫結後，如果 15 秒內沒有帳戶金鑰寫入要求，則結束快速配對工作階段
      • 收到帳戶金鑰寫入要求後，將逾時時間設為 15 秒，以結束快速配對工作階段
    • 後續配對
      • 如果 LE 連線中斷，請結束快速配對工作階段
      • 主要裝置完成配對後，如果 15 秒內沒有其他密碼金鑰寫入要求，則結束快速配對工作階段
      • 收到額外的密碼金鑰寫入要求後，如果要在 15 秒內綁定元件，請結束快速配對工作階段
      • 所有元件黏合後，結束快速配對工作階段

隱藏 UI 指示

如果耳機尚未準備好配對，供應商應使用 type 0b0010 設定帳戶金鑰資料的隱藏 UI 指示，告知搜尋器不要顯示後續配對 UI (請參閱「廣告酬載：快速配對帳戶資料」)。

LE Audio 裝置需求

藍牙需求

請參閱 Android LE Audio 耳機建議。

CTKD 支援

如果是雙模裝置，必須從 LE 到 BR/EDR 取得 CTKD，並符合BAP 規定。

目標公告

周邊裝置應使用目標式公告，向已配對的中央裝置要求連線。目標式公告定義於 BAP 和 CAP，用於根據 CAP 1.0 表 8.4 (第 48/58 頁) 管理連線。

GATT EATT 伺服器支援

EATT 可讓中央裝置在裝置繫結時，並行傳送多個 GATT 交易。如果裝置支援 CSIP，就能提升設定檔連線效能，並隨即為其他耳機啟動 CSIP 連結程序。

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

快速配對功能需求條件

LE Advertising

無論是可探索模式或不可探索模式，如果裝置有多個元件，主要元件應會放送「快速配對」資料。如果裝置尚未準備好進行後續配對，次要元件可以宣傳「快速配對」資料，以提供擴充功能。請參閱「隱藏 UI 指示」。

GATT 服務瀏覽權限

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

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

情境 1 - Seeker 不支援 LEA

供應商應回溯相容於不支援 LEA 的搜尋者。

元件
  • 提供者：A2DP/HFP/LEA
  • 搜尋器：A2DP/HFP
初始配對 / 後續配對的預期行為
  • 供應商會使用身分位址 (初始) 或 RPA (後續) 宣傳快速配對服務資料 (0xFE2C)。
    • 使用舊版廣告
  • Seeker 接收 Provider 的廣告，其中包含初始配對的 Identity 位址，或後續配對的 RPA
  • 搜尋者傳送以金鑰為準的配對要求
    • 將「以金鑰為準的配對要求」的旗標位元 5 設為 0
  • 供應商會透過下列其中一種方式傳送以金鑰為準的配對回應，並附上公開地址：
    • 如果使用訊息類型 0x01，位址應為公開位址
    • 如果使用訊息類型 0x02
      • 位元 0 應為 0
      • Bit-1 應為 0
      • 位址應為公開位址
  • Seeker 會透過 BR/EDR 傳輸建立連結
    • IO 功能設為 BR/EDR 的「顯示是/否」
  • Seeker 和 Provider 執行「快速配對」密碼金鑰驗證程序

情境 2 - 搜尋者支援 LEA 時

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

情境 3 - Seeker 支援 LEA 和 CSIP

元件
  • 提供者
    • 支援 A2DP/HFP/LEA
    • 多個元件
      • 主要元件為 BR/EDR/LE
      • 次要元件僅適用於 LE
  • Seeker
    • 支援 A2DP/HFP/LEA
初始配對 / 後續配對的預期行為
  • 主要元件會使用身分位址 (初始) 或 RPA (後續)，宣傳快速配對服務資料 (0xFE2C)。
    • 使用舊版廣告
  • Seeker 會將以金鑰為準的配對要求傳送至主要元件
    • 將以金鑰為基礎的配對要求旗標位元 5 設為 1
  • 主要元件會傳送以金鑰為準的配對回應，訊息類型為 0x02
    • 位元 0 應為 0
    • 位元 1 應為 1
    • 地址如下：
      • 第一個地址是主要元件的身分地址
      • 第二個位址是次要元件的可繫結位址，第二個元件也會使用這個位址進行 CSIP 廣告
  • Seeker 會在現有的 LE 連線中，與主要元件建立繫結。
    • CTKD 方向是從 LE 到 BR/EDR
    • IO 功能設為 LE 的 DisplayYesNo
  • Seeker 會與次要元件建立連線，該元件的地址來自「以金鑰為準的配對擴充回應」
    • IO 功能應為 DisplayYesNo，否則拒絕配對要求
  • Seeker 和 Provider 會執行 MITM 保護程序，配對次要元件，Provider 應在兩種情境中實作此程序
  • Seeker 會等待，直到與次要元件繫結為止

中間人攻擊的流程圖

本課程將說明 MITM 保護程序的順序。

透過通知從繫結的元件取得密碼金鑰

從讀取作業繫結的元件取得密碼金鑰

已知問題

FP for LEA 已最佳化，可與 Android V(Android 15) 搭配運作。

反之，我們發現許多支援 LEA 的耳機，卻沒有正確實作 LEA 快速配對 (即僅支援傳統快速配對)。舉例來說，如果供應商的 RPA 不是由正確的「身分識別解析金鑰」(IRK) 產生，就無法解析地址。我們無法測試完整的耳機設定清單，但有限的測試顯示，這類耳機有各種問題，包括無法顯示耳機電池通知、缺少音訊切換 (SASS) 功能、普遍的初始和後續配對失敗等。

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