藍牙低功耗 (BLE) 裝置

BLE 裝置的 Google 快速配對服務 (GFPS) 實作方式為 與 Bluetooth Core 規格 4.2 以上版本相容。

如要順利支援，歡迎使用下列「快速配對」規格附加條款 僅適用於低功耗 (LE) 和 GFPS 低功耗音訊 (LEA) 裝置。

符合等級

規格中提到的「可以」、「必須」、「應該」、「應該」、「可能」和「可以」使用的關鍵字如下：

字詞 說明
應該 是必要項目 - 用來定義需求。
必須 用於表示：
為先前所述必要要求的自然結果
或
具公信力的事實陳述 (無論情況為何)。
將 是真的 - 只用於事實陳述。
應該 建議： - 指出從多個可能性中建議的適當項目，但並非必要。
5 月 是否允許 - 用於允許選項。
可以 is can to - 用因果語氣陳述陳述內容。

以鍵為基礎的組合特性

Seeker 給供應商的訊息

金鑰型配對特性的原始要求 type 0x00 使用 Bit 4 用於指出尋求者是否支援 BLE 裝置規格，且使用 位元 5 用於表示 Seeker 是否支援 LE Audio。

八位元 資料類型 說明 值 必要？
0 uint8 訊息類型 0x00 = 以金鑰為基礎的配對要求 必填
1 uint8 標記
  • 位元 0 (MSB)：已淘汰並由 Seeker 忽略。
  • 位元 1：1 (如果尋求者要求供應商應發起繫結，而此要求包含搜尋者的 BR/EDR 地址)，否則為 0。
  • 位元 2：1 (如果尋求者要求供應商應通知現有名稱)。否則為 0。
  • 位元 3：1 代表用於「回溯寫入帳戶金鑰」。否則為 0。
  • 如果探索工具支援 BLE 裝置規格，則 Bit 4：1。否則為 0。
  • 位元 5：1 如果尋找程式支援 LE Audio。否則為 0。
  • 位元 6 - 7 將保留供日後使用，並應予以忽略。
 各不相同 必填
2 - 7 uint48 符合以下任一條件：
  • 供應商目前的 BLE 地址
  • 提供者的身分地址
 各不相同 必填
8 - 13 uint48 廣告主的巴西/EDR 地址 各不相同 僅在已設定 Flags Bit 1 或 3 時才會顯示
n - 15 歲 隨機值 (鹽) 各不相同 必填

從提供者給 Seeker 的訊息

已設定要求的 Bit 4 時，新的回應訊息 type 0x02 金鑰式組合特性可用於提供額外鍵結 選項。

八位元 資料類型 說明 值
0 uint8 訊息類型 0x02 = 以鍵為基礎的配對延伸回應
1 uint8 標記
  • 位元 0 (MSB)：如果供應商是 LE 裝置，則值為 1，否則為 0。如果位元 0 設為 1，尋找工具會假設 Bit 1 設定為 1。
  • 位元 1：如果供應商偏好 LE 繫結，位元 1：1，否則為 0。
  • 位元 2：如果第二個位址類型為「隨機」，則值為 1，如果是「公開」，則值為 0。
  • 位元 3 - 7 將保留供日後使用，並應予以忽略。
 各不相同
2 uint8 提供者地址數量
(目前版本中的數字是 1 或 2，因為如果數字 >= 3，就需要修改區塊加密模式)		 各不相同
3 - 8 或
3 - 14
  • 第一個地址應為主要身分地址；如果偏好使用 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 雙模式供應商配對

Message Stream PSM (通訊協定服務多工器) 特性

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

這項特性可讓尋找者讀取 PSM 值，然後建立 依據 PSM 值分類安全 L2CAP 連線。

快速配對服務特性 已加密 權限 UUID
訊息串流 PSM 是 讀取 FE2C1239-8366-4814-8EB0-01DE32100BEA
八位元 資料類型 說明 值
0 uint8 州/省
  • 0x00 = 不明。FP Seeker 將重試多次
  • 0x01 = 已可連線
  • 0x02 = 無法使用。FP Seeker 這次不會使用這個元件進行連線
 各不相同
1 - 2 人 uint16 PSM 值必須介於 0x80 至 0xFF 之間 各不相同

注意：臺灣有以下兩種： 分別是主要和次要元件這些元件的作用 在某些條件下可互換假設 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 連線傳送。

八位元 資料類型 說明 值
0-15 uint128 其他加密密碼金鑰區塊 變動
原始資料格式

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

八位元 資料類型 說明 值
0 uint8 訊息類型 下列其中之一：
  • 0x00 = 求職者的密碼金鑰
  • 0x01 = 提供者的密碼金鑰
1-3 uint24 6 位數密碼金鑰 變動
4-9 uint48 目標繫結元件位址 變動
10 uint8 狀態碼，僅用於讀取作業 下列其中之一：
  • 0x00 = 成功
  • 0x01 = 未放送。FP Seeker 會在逾時前重試
  • 0x02 = 失敗。FP Seeker 停止重試
11-15 隨機值 (鹽) 變動

主要 (第一個鍵結元件) 是快速配對之間的橋樑 定義器和其他繫結元件。特色 遵循指南：

  • 收到快速配對尋求者的寫入要求時，供應商應
    • 設定要建立繫結的元件地址
    • 將密碼金鑰傳送至要建立繫結的元件
    • 將狀態碼設為「待處理」，0x01
  • 收到來自元件的密碼金鑰前的任何讀取要求 建立鍵結後，供應商應傳回
    • 密碼金鑰 (任何值)
    • 要建立繫結的元件地址
    • 待處理狀態碼 (0x01)
  • 供應商將通知傳送給快速配對尋找者前，請先設定結果 讀取要求
    • 要建立繫結的元件的密碼金鑰
    • 要建立繫結的元件地址
    • 成功狀態碼，0x00
  • 如果在供應商端發生任何無法復原錯誤，請設定結果
    • 密碼金鑰 (任何值)
    • 要建立繫結的元件地址
    • 失敗狀態碼，0x02

請參閱 MITM 圖表 1 和 如需更多資訊，請參閱 MITM 圖表 2。

LE 裝置需求條件

LE Advertising

如果是可搜尋模式或無法搜尋的模式，供應商應使用 RPA 來 通告 FastPair 資料

繫結功能

如果是支援 LE 的裝置，探索者必須使用現有的現有資料建立鍵結 LE 連線。通過快速配對金鑰配對驗證後， 供應商應允許與 RPA 建立繫結，並將 IO 功能設為 DisplayYesNo 快速配對密碼金鑰。

LEA 裝置需求條件

LEA 廣告

雙模式裝置： 如果是可偵測模式，供應商應透過 Identity 宣傳快速配對資料 讓我們看看 DNS 解析 進一步探索內部和外部位址 針對無法偵測的模式，供應商應使用 RPA 宣傳快速配對資料。 強烈建議您使用舊版廣告 (BT 4.2) 支援舊版廣告 回溯相容。 每次裝置恢復原廠設定時，都必須變更 IRK。

非雙模式裝置： 如果是可搜尋模式或無法搜尋的模式，「供應商」應使用擴充式 宣傳 FastPair 資料

包含 FP 服務資料的 LE 可連線廣告應包含 CAS UUID 藍牙轉接器設定檔 (BAP 1.0.1) 和 一般音訊設定檔 才能正常運作沒有足夠的空間時，無法看到的廣告 但由於手機包含電池和 SASS 資料，因此這類廣告無法支援傳統廣告。 的情況下， 就必須在掃描回應中加入 CAS UUID。

LEA 獎勵能力

探險家必須使用現有的 LE 連線建立鍵結。通過後 快速配對金鑰式配對驗證，雙模式供應商應允許 與身分和 RPA 建立繫結，非雙模式供應商可以 與 RPA 建立繫結，並將 IO 功能設為 DisplayYesNo 以快速配對 密碼金鑰驗證。

元件之間的內部通訊管道

現有的 GATT 連線會保留，以在 其他元件主要鍵結元件應處理訊息 以及其其餘元件之間的提交內容。

內部通訊僅供 Initial Pair 和 Subsequent Pair 使用

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

變更 IO 功能的時間

  • 通過鍵型配對程序後，將 IO 功能變更為 DisplayYesNo
    • 如果裝置含有多個元件，所有元件都應設為 DisplayYesNo
    • 「供應商」 不將 IO 功能變更為 DisplayYesNo 為 Retroactive Pair，其位元 3 的鍵式配對要求設為 1，請參閱 呼叫提供者給供應商的訊息
  • 將 IO 功能變更為預設設定
    • 初始配對
      • 如果 LE 連線已中斷，請結束快速配對工作階段
      • 建立主要金鑰後，如果沒有寫入其他密碼金鑰 並在 15 秒內結束快速配對工作階段
      • 收到其他密碼金鑰寫入要求後，如果元件 沒有在 15 秒內建立鍵結，結束快速配對工作階段
      • 所有元件建立關聯後，如未寫入帳戶金鑰 在 15 秒內提出要求，結束快速配對工作階段
      • 收到帳戶金鑰寫入要求後，將逾時時間設為 15 秒 結束快速配對工作階段。
    • 後續配對
      • 如果 LE 連線已中斷，請結束快速配對工作階段
      • 建立主要金鑰後，如果沒有寫入其他密碼金鑰 在 15 秒內提出要求，結束快速配對工作階段
      • 收到其他密碼金鑰寫入要求後，如果元件 沒有在 15 秒內建立鍵結，結束快速配對工作階段
      • 所有元件都建立繫結後，結束快速配對工作階段

隱藏使用者介面指示

當耳機沒有準備好配對時，供應商應使用 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 的協調組合，以減少 每次進行服務探索並加快連線速度，供應商應 實作藍牙 5.1 中定義的 GATT 快取。

快速配對需求條件

LE Advertising

針對可探索模式或不可搜尋模式 (如果裝置有多個 元件、快速配對資料，需透過主要元件進行通告。如果 裝置無法進行後續配對，次要元件可 宣傳快速配對資料，提供額外功能。看 隱藏 UI 標示。

GATT 服務可見性

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

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

情境 1：尋求者不支援 LEA 時

「供應商」應與未宣告的「尋求者」回溯相容 而且支援 LEA。

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

情境 2：當尋人支援 LEA 時

元件
  • 提供者
    • 支援 A2DP/HFP/LEA
    • 單一元件
  • 追求者
    • 支援 A2DP/HFP/LEA
初始配對 / 後續配對的預期行為
  • 供應商宣傳快速配對服務 資料 (0xFE2C) 和身分地址 (初始) 或 RPA (後續)。
    • 使用舊版廣告
  • 尋找工具會傳送金鑰型配對要求
    • 金鑰式配對要求的位元-5 設為 1
  • 提供者傳送以金鑰為基礎的配對回應，訊息類型為 0x02
    • 位元-0 應為 0
    • Bit-1 應為 1
    • 地址是身分地址
  • 尋檢人建立聯繫 LE 運輸支援 LE 連線
    • CTKD 的方向從 LE 到 BR/EDR
    • LE 的 IO 功能已設為 DisplayYesNo
  • 尋求者和供應商進行快速配對密碼金鑰驗證程序

情境 3：調查員支援 LEA 和 CSIP 時

元件
  • 提供者
    • 支援 A2DP/HFP/LEA
    • 多個元件
      • 主要組件為 BR/EDR/LE
      • 次要元件僅適用於 LE
  • 追求者
    • 支援 A2DP/HFP/LEA
初始配對 / 後續配對的預期行為
  • 主要元件宣傳快速配對 服務資料 (0xFE2C)，以及身分地址 (初始) 或 RPA (後續)。
    • 使用舊版廣告
  • 探索者將金鑰式配對要求傳送至主要元件
    • 金鑰式配對要求的位元-5 設為 1
  • 主要元件會傳送金鑰型配對回應 (訊息類型為 0x02)
    • 位元-0 應為 0
    • Bit-1 應為 1
    • 地址如下 ：
      • 第一個地址是主要元件的身分地址
      • 第二個地址是次要元件的可繫結位址 第二元件也會使用這個地址進行 CSIP 通告
  • 尋檢人建立聯繫 確認所有 LE 連線的元件
    • CTKD 的方向從 LE 到 BR/EDR
    • LE 的 IO 功能已設為 DisplayYesNo
  • 尋檢人建立關係 其位址來自金鑰式配對延伸回應的元件
    • IO 功能必須為 DisplayYesNo，否則會拒絕配對要求
  • 透過 MITM 防護程序， 第二元件，「供應商」應在這兩種情況下導入
  • 追尋者會等待與次要元件建立繫結

MITM 的循序圖

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

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

從已讀取的元件取得密碼金鑰

已知問題

LEA 專用 FP 已經過最佳化調整，可與 Android V 搭配使用。

相反地，我們也遇到許多支援 LEA 的耳機問題 但針對 LEA 實作缺少正確的快速配對 (即只有快速配對通過) 傳統版)。具體來說，像是未產生提供者的 RPA 時 來自正確的身分解析金鑰 (IRK)，地址就無法解析。 雖然我們未能測試完整的耳機清單 我們的有限測試發現各種問題，包括失敗 顯示耳機電池通知，沒有音訊自動切換 (SASS) 包括廣泛功能、 廣泛初始與後續配對失敗等

因此，我們強烈建議合作夥伴導入快速配對 LEA 新裝置和實地裝置的規格 (透過無線更新) 支援雙重模式。