Bluetooth Low Energy（BLE）デバイス

BLE デバイス向けの Google ファスト ペアリング サービス（GFPS）の実装は次のとおりです。 Bluetooth コア仕様 v4.2 以降と互換性があります。

ファスト ペアリング仕様の次の追加条項により、 Low Energy（LE）のみのデバイスと GFPS の Low Energy Audio（LEA）デバイスの場合。

適合性レベル

本仕様書に記載されているキーワード「shall」、「なければならない」、「will」、「should」、「may」、「can」は、以下のとおりです。

用語 説明
shall 必須要件 - 要件を定義するために使用します。
must 次の表現に使用:
前述の必須要件の自然な結果
または
明白な事実の表明（状況にかかわらず常に当てはまる）。
will 事実 - 事実の表明でのみ使用される
should をおすすめする - いくつかの可能性の中から、1 つが特に適しているが必須ではないことを示すために使用。
5 月 許可対象 - オプションを許可するために使用します。
データ プロダクト できる - 主張を因果的に関連付けるために使用します。

キーベースのペアリング特性

シーカーからプロバイダへのメッセージ

キーベースのペアリング特性の未加工リクエスト type 0x00 は、ビット 4 を使用する。 シーカーが BLE Device Specification に対応しているかどうかを示し、 シーカーが LE Audio に対応しているかどうかを示すビット 5。

オクテット データ型 説明 値 必須かどうか
0 uint8 メッセージの種類 0x00 = キーベースのペアリング リクエスト 必須
1 uint8 フラグ
  • ビット 0（MSB）: 非推奨となり、シーカーにより無視されます。
  • ビット 1：1 は、シーカーがプロバイダにボンディングを開始するよう要求し、この要求がシーカーの BR/EDR アドレスを含む場合。それ以外の場合は 0。
  • ビット 2：1 は、シーカーがプロバイダが既存の名前を通知することを要求した場合。それ以外の場合は 0。
  • ビット 3: アカウントキーを過去に遡って書き込む場合: 1。それ以外の場合は 0。
  • ビット 4: シーカーが BLE デバイス仕様をサポートしている場合は 1。それ以外の場合は 0。
  • ビット 5: シーカーが LE Audio をサポートしている場合は 1。それ以外の場合は 0。
  • ビット 6 ～ 7 は、将来の使用のために予約されており、無視します。
 場合によって異なる 必須
2 ～ 7 uint48 次のいずれか:
  • プロバイダの現在の BLE アドレス
  • プロバイダの ID アドレス
 場合によって異なる 必須
8 ～ 13 uint48 追求者の BR/EDR 住所 場合によって異なる フラグビット 1 または 3 が設定されている場合にのみ存在します。
n - 15 ランダム値（ソルト） 場合によって異なる 必須

プロバイダから探索者へのメッセージ

リクエストのビット 4 が設定されている場合、次の新しいレスポンス メッセージ type 0x02: キーベースのペアリング特性を使用して、追加のボンディングを提供できる 探索ユーザーのオプションです

オクテット データ型 説明 値
0 uint8 メッセージの種類 0x02 = キーベースのペア設定拡張レスポンス
1 uint8 フラグ
  • ビット 0（MSB）：プロバイダが LE 専用デバイスの場合 1、それ以外の場合は 0。ビット 0 が 1 に設定されている場合、シーカーはビット 1 が 1 に設定されていると想定します。
  • ビット 1：プロバイダが LE ボンディングを優先する場合は 1、それ以外の場合は 0。
  • ビット 2: 2 番目のアドレスのアドレス タイプがランダムの場合は 1、パブリックの場合は 0。
  • ビット 3 ～ 7 は将来の使用のために予約されており、無視します。
 場合によって異なる
2 uint8 プロバイダのアドレスの数
（現在のバージョンでは、数値が 3 以上の場合、ブロック暗号モードを AES-CTR に変更する必要があるため、数値は 1 または 2 です）		 場合によって異なる
3 - 8 または
3 - 14
  • 最初のアドレスは、一次組織の ID アドレスで、BR/EDR ボンディングが望ましい場合はボンディング可能とする
  • 第 2 のアドレスは、第 2 の宛先が利用可能な場合、その第 2 のボンディング可能なアドレスとなる
 場合によって異なる
9 ～ 15 または 15 ランダム値（ソルト） 場合によって異なる

BLE デバイス仕様をサポートするプロバイダは、ビット 4 とビット 5 を読み取るものとします。 シーカーの能力を理解するには

  • ビット 4 が 0 の場合、プロバイダはビット 5 を無視し、type 0x01 形式で応答する。
  • ビット 4 が 1 のとき
    • LE のみのプロバイダの場合、LE を示すために type 0x02 を返す必要があります。 推奨されます。
    • デュアルモード プロバイダの場合、type 0x02 で応答して次のいずれかを示すことができます。 BR/EDR または LE のボンディングが望ましい。
  • LE Audio（LEA）デュアルモード プロバイダに関するケースについては、以下をご覧ください。 例: LEA デュアルモード プロバイダとペア設定する（参照用）

メッセージ ストリームの PSM（プロトコル サービス マルチプレクサ）の特性

BLE デバイスのメッセージ ストリームをサポートするため、ファスト ペアリングを確立して メッセージを送受信するための BLE L2CAP チャネルを維持します。ファスト ペアリング L2CAP サーバーは、LE クレジット ベースのフロー制御を実装する必要があります。

この特性により、シーカーは PSM 値を読み取り、 PSM 値によって保護されています。

ファスト ペアリング サービスの特性 暗号化あり 権限 UUID
メッセージ ストリーム PSM はい 読み取り FE2C1239-8366-4814-8EB0-01DE32100BEA
オクテット データ型 説明 値
0 uint8 州
  • 0x00 = 不明。FP Seeker は数回再試行する
  • 0x01 = 接続の準備完了
  • 0x02 = 使用不可今回は FP Seeker はこのコンポーネントを使用して接続しません
 場合によって異なる
1 - 2 uint16 PSM 値は 0x80 から 0xFF までの範囲であること。 場合によって異なる

注: TWS には、 プライマリとセカンダリですこれらのコンポーネントの役割は、 特定の状況では交換可能です。A を主成分、B を 2 次コンポーネント: コンポーネント A のバッテリーの消耗がするため、コンポーネント B は このシナリオはrole switchと呼ばれます。

role switch の後、プロバイダが ファスト ペアリングのメッセージ ストリームを処理できないため、 接続をルーティングしますその後、ファスト ペアリングを求めるユーザーは L2CAP を再確立できる 新しいプライマリコンポーネントとの間の 新しいメッセージストリーム接続が行われます

その他のパスキー特性

この特性により、追加の IP アドレスで MITM 保護が 説明します。

CSIS Fake Member MITM 保護

ファスト ペアリングを使用するには、ペア設定手順の一環として MITM 保護が必要です。CSIS として は MITM 保護を提供していません。現時点の複数の用途向けの FP は 追加で MITM 保護を提供するために拡張する必要がある 説明します。

特性の定義

ファスト ペアリング サービスの特性 暗号化あり 権限 UUID
追加のパスキー はい 読み取り、書き込み、通知 FE2C123A-8366-4814-8EB0-01DE32100BEA

メッセージ

メッセージ形式は、読み取り、書き込み、通知オペレーションに適用されます。

暗号化されたデータ形式

暗号化されたデータはファスト ペアリング GATT 接続を使用して送信されます。

オクテット データ型 説明 値
0-15 uint128 暗号化された追加のパスキー ブロック 可変
元データ形式

共有シークレットを使用して暗号化されたデータを復号した後、形式は次のようになります。

オクテット データ型 説明 値
0 uint8 メッセージの種類 <ph type="x-smartling-placeholder">
    </ph>のいずれか
  • 0x00 = シーカーのパスキー
  • 0x01 = プロバイダのパスキー
1～3 uint24 6 桁のパスキー 可変
4-9 uint48 ターゲット ボンディング コンポーネントのアドレス 可変
10 uint8 ステータス コード。読み取りオペレーションでのみ使用されます。 次のいずれか:
  • 0x00 = 成功
  • 0x01 = 保留中。FP シーカーがタイムアウトするまで再試行する
  • 0x02 = 失敗。FP シーカー停止の再試行
11～15 ランダム値（ソルト） 可変

主要コンポーネント（最初に結合されるコンポーネント）はファスト ペアリングの橋渡しをする シーカーと追加の結合コンポーネント。この特性は、次の条件を満たす必要があります。 次のガイドラインを遵守してください。

  • ファスト ペアリング探索者から書き込みリクエストを受け取った場合、プロバイダは
    • ボンディングされるコンポーネントのアドレスを設定する
    • ボンディングするコンポーネントにパスキーを送信する
    • ステータス コードを保留（0x01）に設定する
  • コンポーネントからパスキーを受け取る前に読み取りリクエストを受け取ったとき プロバイダはメッセージを返すものとし、
    • パスキー、任意の値
    • ボンディングされるコンポーネントのアドレス
    • 保留中のステータス コード、0x01
  • プロバイダがファスト ペアリング探索に通知を送信する前に、結果を設定する 読み取りリクエストの
    • ボンディングされるコンポーネントのパスキー
    • ボンディングされるコンポーネントのアドレス
    • 成功ステータス コード、0x00
  • プロバイダ側で回復不能なエラーが発生した場合は、結果を設定します。
    • パスキー、任意の値
    • ボンディングされるコンポーネントのアドレス
    • 失敗ステータス コード、0x02

MITM の図 1 と 詳しくは、MITM の図 2 をご覧ください。

LE デバイスの要件

LE 広告

検出可能モードまたは検出不可モードについて、プロバイダは RPA を使用して以下を行うものとします。 ファスト ペアリングのデータをアドバタイズします。

結合能力

LE 対応デバイスの場合、シーカーは既存の LE 接続。ファスト ペアリング キーに基づくペアリングの検証に合格すると、 プロバイダは RPA とのボンディングを許可し、IO 機能を DisplayYesNo に設定するものとします。 。

LEA デバイスの要件

LEA の広告

デュアルモード デバイスの場合: 検出可能モードでは、プロバイダは ID を使用してファスト ペアリング データをアドバタイズするものとします。 あります。 検出不可モードの場合、プロバイダは RPA を使用してファスト ペアリング データをアドバタイズするものとします。 古いバージョンをサポートするには、従来のアドバタイズメント（BT 4.2）を使用することを強くおすすめします。 下位互換性を確保します。 デバイスが出荷時設定にリセットされるたびに IRK を変更する必要があります。

デュアルモード以外のデバイスの場合: 検出可能モードまたは検出不可モードについては、プロバイダは拡張 RPA によるアドバタイジング（BT 5.0）によって、ファスト ペアリング データをアドバタイズします。

FP サービスデータを含む LE 接続可能アドバタイズメントには、 CAS UUID: Bluetooth アダプター プロファイル（BAP 1.0.1） 一般的な音声プロファイル 要件があります十分なスペースがない場合に検出不能なアドバタイズメントに使用する場合 バッテリーと SASS のデータが含まれているため、従来の広告に その場合は、スキャン レスポンスに CAS UUID を含める必要があります。

LEA ボンディング能力

シーカーは既存の LE コネクションとの絆を深める必要がある。合格後 ファスト ペアリング キーベースのペアリング検証。デュアルモード プロバイダは、 ID アドレスおよび RPA とのボンディングを可能にし、非デュアルモードのプロバイダは RPA とのボンディングを行い、ファスト ペアリングで IO 機能を DisplayYesNo に設定する パスキーによる確認。

コンポーネント間の内部通信チャネル

既存の GATT 接続は維持され、ネットワークで MITM 保護が実行されます。 追加コンポーネントを使用できます。プライマリ ボンディング コンポーネントは、 ファスト ペアリング シーカーとその残りのコンポーネントの間で、パフォーマンスが向上します。

内部通信は Initial Pair と Subsequent Pair に使用されます。

  • キーベースのペア設定手順がプライマリ コンポーネントをパスすると、 残りの IO 機能を変更するメッセージを送信する必要があります。 コンポーネント
  • ファスト ペアリングが完了すると、プライマリ コンポーネントはリセットを求めるメッセージを送信します。 残りのコンポーネントの IO 機能
  • 追加パスキー手順を実行する場合、主要コンポーネントは ファスト ペアリング シーカーとその残りのコンポーネントの間でパスキーが配信される

IO 機能の変更にかかる時間

  • キーベースのペアリング手順に合格した場合に IO 機能を DisplayYesNo に変更
    • デバイスに複数のコンポーネントがある場合は、すべてのコンポーネントを DisplayYesNo
    • ただし、プロバイダが IO 機能を DisplayYesNo に変更しない（ビット 3 が Retroactive Pair） Key-based Pairing Request が 1 に設定されている場合は、 シーカーからプロバイダへのメッセージ
  • IO 機能をデフォルト設定に変更する
    • 最初のペア設定
      • LE 接続が切断された場合は、ファスト ペアリング セッションを終了します
      • プライマリがボンディングされた後、追加のパスキーの書き込みがない場合 リクエストしたら、ファスト ペアリング セッションを終了します
      • 追加のパスキー書き込みリクエストを受信した後で、そのコンポーネントが 15 秒以内に結合されていません。ファスト ペアリング セッションを終了します
      • すべてのコンポーネントが結合された後、アカウントキーの書き込みがない場合 リクエストしたら、ファスト ペアリング セッションを終了します
      • アカウント キーの書き込みリクエストを受信したら、タイムアウトを 15 秒に設定します。 ファスト ペアリング セッションを終了
    • 2 回目以降のペア設定
      • LE 接続が切断された場合は、ファスト ペアリング セッションを終了します
      • プライマリがボンディングされた後、追加のパスキーの書き込みがない場合 リクエストしたら、ファスト ペアリング セッションを終了します
      • 追加のパスキー書き込みリクエストを受信した後で、そのコンポーネントが 15 秒以内に結合されていません。ファスト ペアリング セッションを終了します
      • すべてのコンポーネントが結合されたら、ファスト ペアリング セッションを終了します

UI 表示の非表示

ヘッドセットをペア設定する準備ができていない場合、プロバイダは type 0b0010 を使用するものとします。 アカウントキー データの非表示 UI 設定を設定し、シーカーに表示しないように設定します。 後続のペア設定 UI（広告ペイロード: ファスト ペアリングのアカウント データを参照）。

LE Audio デバイスの要件

Bluetooth の要件

Android、LE Audio ヘッドセットの推奨事項をご覧ください。

CTKD のサポート

デュアルモード デバイスでは、LE から BR/EDR への CTKD が必須であり、 BAP の要件。

目標に関するお知らせ

ペリフェラル デバイスは、接続を求めるために Targeted Announcement を使用します 。ターゲットを絞ったお知らせは BAP と CAP で定義 CAP 1.0 表 8.4（p48/58）に沿った接続管理

GATT EATT サーバーのサポート

EATT により、中央デバイスは複数の GATT トランザクションを並行して送信できる デバイスがボンディングされるとき。CSIP をサポートするデバイスでは、次の値が増えます。 プロファイル接続のパフォーマンスを向上させてから、すぐに CSIP ボンディングを開始する 他のイヤフォンの手順を踏んでください

プロバイダが単一のデバイスではなく、CSIP 実装との調整されたセットである場合は、 接続を高速化するため、プロバイダは Bluetooth 5.1 で定義された GATT キャッシュを実装している。

ファスト ペアリングの要件

LE 広告

検出可能モードまたは検出不可モードについて、デバイスに複数の ファスト ペアリングデータは、主要コンポーネントによってアドバタイズされます。もし それ以降のペア設定の準備が整っていない場合、セカンダリ コンポーネントは 拡張機能のためにファスト ペアリング データをアドバタイズする。 UI 表示の非表示

GATT サービスの公開設定

GATT データベースは、すべての LE トランスポート GATT 接続で同じである必要があります。LE Audio サービス（0x184E）は、ファスト ペアリング接続の GATT データベースに含まれるものとします。

例: LEA デュアルモード プロバイダとのペア設定

シナリオ 1 - シーカーが LEA をサポートしていない場合

プロバイダには、シーカーとの下位互換性がないシーカーとの下位互換性が サポートしています

コンポーネント
  • プロバイダ: A2DP/HFP/LEA
  • シーカー: A2DP/HFP
最初のペア / 後続のペアで想定される動作
  • プロバイダがファスト ペアリング サービスをアドバタイズしている ID アドレス（初期）または RPA（後続）を持つデータ（0xFE2C）
    • 従来の広告を使用
  • シーカーはプロバイダの 初期の ID アドレスを使用したアドバタイズ、または後続のペア設定のための RPA
  • シーカーがキーベースのペアリング リクエストを送信する
    • キーベースのペアリングリクエストのフラグビット 5 が 0 に設定される
  • プロバイダは、鍵ベースのペアリング応答に、パブリック アドレスを含めて送信します。 次のとおりです。
    • メッセージタイプ 0x01 が使用される場合、アドレスはパブリックアドレスである。
    • メッセージ タイプ 0x02 が使用されている場合
      • ビット 0 は 0 にします。
      • ビット 1 は 0 とします。
      • 住所は公的住所とします
  • BR/EDR トランスポートで絆を深める「探求者」
    • BR/EDR で IO 機能が DisplayYesNo に設定されている
  • シーカーとプロバイダがファスト ペアリングのパスキーの検証手続きを行う

シナリオ 2 - シーカーが LEA をサポートしている場合

コンポーネント
  • プロバイダ
    • A2DP/HFP/LEA に対応
    • 単一コンポーネント
  • シーカー
    • A2DP/HFP/LEA のサポート
最初のペア / 後続のペアで想定される動作
  • プロバイダがファスト ペアリング サービスをアドバタイズしている ID アドレス（初期）または RPA（後続）を持つデータ（0xFE2C）
    • 従来の広告を使用
  • シーカーがキーベースのペアリング リクエストを送信する
    • キーベースのペアリングリクエストのフラグビット 5 が 1 に設定される
  • プロバイダがキーベースのペアリング応答をメッセージ タイプ 0x02 で送信
    • ビット 0 は 0 にします。
    • ビット 1 は 1 とします。
    • アドレスは [Identity address] です。
  • 探求者は既存の人々との絆を深める LE トランスポート上の LE 接続
    • CTKD の方向は LE から BR/EDR へ
    • LE の IO 機能が DisplayYesNo に設定されている
  • シーカーとプロバイダがファスト ペアリングのパスキーの検証手続きを行う

シナリオ 3 - シーカーが関連する LEA と CSIP をサポートしている場合

コンポーネント
  • プロバイダ
    • A2DP/HFP/LEA をサポート
    • 複数のコンポーネント
      • 主要コンポーネントは BR/EDR/LE
      • セカンダリ コンポーネントは LE のみ
  • シーカー
    • A2DP/HFP/LEA をサポート
最初のペア / 後続のペアで想定される動作
  • 主要コンポーネントがファスト ペアリングをアドバタイズする ID アドレス（初期）または RPA（以降）を持つサービスデータ（0xFE2C）。
    • 従来の広告を使用
  • シーカーがキーベースのペアリング リクエストをプライマリ コンポーネントに送信する
    • キーベースのペアリングリクエストのフラグビット 5 が 1 に設定される
  • プライマリ コンポーネントは、メッセージ タイプ 0x02 のキーベースのペア設定レスポンスを送信します。
    • ビット 0 は 0 にします。
    • ビット 1 は 1 とします。
    • 住所は次のとおりです。
      • 最初のアドレスはプライマリ コンポーネントの ID アドレスです。
      • 2 番目のアドレスは、セカンダリ コンポーネントのボンディング可能なアドレスです。 2 番目のコンポーネントもこのアドレスを使用して CSIP アドバタイズを行います。
  • 探求者は主流との絆を深める コンポーネントを既存の LE 接続の
    • CTKD の方向は LE から BR/EDR へ
    • LE の IO 機能が DisplayYesNo に設定されている
  • 探求者は二次的な人間との絆を深める そのアドレスが Key-based Pairing Extended Response であるコンポーネント
    • IO 機能は DisplayYesNo になります。それ以外の場合は、ペアリング要求が拒否されます。
  • シーカーとプロバイダは、IP アドレスをペアリングするための MITM 保護手続きを行います。 第二のコンポーネントである場合、プロバイダは、
  • シーカーはセカンダリ コンポーネントと結合されるまで待機する

MITM のシーケンス図

このセッションでは、MITM 保護手順のシーケンスについて説明します。

通知によってボンディングされるコンポーネントからパスキーを取得する

読み取りによってボンディングされるコンポーネントからパスキーを取得する

報告されている問題

LEA の FP は、Android V で動作するように最適化されています。

逆に、LEA に対応したヘッドセットでは問題も多数発生しています。 適切なファスト ペアリングが実装されていない LEA がない（すなわち、ファスト ペアリングのみ クラシック）。具体的には、たとえば、プロバイダの RPA が生成されない場合に発生することがあります。 正しい ID 解決鍵（IRK）によって認証され、アドレスを解決できません。 ヘッドセットの包括的なリストをテストすることはできませんでしたが、 限定テストの結果、さまざまな問題が明らかになりました。たとえば、 イヤホンのバッテリー通知を表示する、音声の切り替え機能なし（SASS） 初期およびその後の広範なペアリングエラーなど

そのため、ファスト ペアリング-LEA を実装することを強くおすすめします。 新規デバイスと現場の既存デバイスの両方の仕様に対応 （無線（OTA）アップデート）によって、デュアルモードをサポートします。