特性

ファスト ペアリング サービス

Fast Pair プロバイダは、次の 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: 事前共有鍵は、なりすまし防止の公開鍵/秘密鍵ペアと、シーカー独自の公開鍵/秘密鍵ペア（ペア設定の試行ごとに変更される）に基づいています。

    • プロバイダーがペア設定モードになっている。
    • シーカーは、プロバイダーがなりすまし防止秘密鍵を所有していることを確認します。

    ペア設定モードでは、プロバイダは通常の方法でもペア設定できます。たとえば、ファスト ペアリングの鍵ベースのペア設定をサポートしていないデバイスとペア設定できます。

  • ケース 2: 事前共有キーがアカウント キーのいずれかである。

    • 通常、プロバイダはペア設定モードになっていません。（ただし、これは必須ではありません。プロバイダは、ペア設定モードでもアカウントキーの使用をサポートする必要があります）。
    • シーカーとプロバイダは、それぞれがアカウントキーを所有していることを確認します。

どちらのケースも、使用する事前共有キーが異なるだけで非常に類似しているため、手順にまとめられています。

データ形式

各形式の使用方法については、手順をご覧ください。

オクテット データ型 説明 値 必須かどうか
0～15 uint128 暗号化されたリクエスト 可変 必須
16 ～ 79 公開鍵 可変 省略可

表 1.1: シーカーによって特性に書き込まれた暗号化されたリクエスト。

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

表 1.2.1: 未加工リクエスト（タイプ 0x00）。 表 1.1 の暗号化されたリクエストから復号化されます。

オクテット データ型 説明 値 必須かどうか
0 uint8 メッセージの種類 0x10 = アクション リクエスト 必須
1 uint8 フラグ
  • ビット 0（MSB）: デバイス アクションの場合は 1、それ以外の場合は 0。
  • ビット 1: 追加データ特性が続く場合は 1、それ以外の場合は 0。
  • ビット 2 ～ 7 は将来の使用のために予約されており、無視されます。
 varies 必須
2 ～ 7 uint48 次のいずれかです。
  • プロバイダの現在の BLE アドレス
  • プロバイダの公開アドレス
 varies 必須
8 uint8 メッセージ グループ 異なる フラグビット 0 が設定されている場合は必須
9 uint8 メッセージ コード varies フラグビット 0 が設定されている場合は必須
10 uint8 フラグに依存:
  • ビット 0 が設定されている: 追加データの長さが 6 未満
  • ビット 1 が設定されている: データ ID
 異なる フラグビット 0 または 1 が設定されている場合は必須
11 - n 追加データ 異なる 省略可
n - 15 ランダムな値（ソルト） varies 必須

表 1.2.2: 生リクエスト（タイプ 0x10）。 表 1.1 の暗号化されたリクエストから復号。

オクテット データ型 説明 値
0 uint8 メッセージの種類 0x01 = キーベースのペア設定レスポンス
1 - 6 uint48 プロバイダの公開（BR/EDR）アドレス 異なる
7 ～ 15 ランダムな値（ソルト） varies

表 1.3: 未加工の回答。暗号化され、 表 1.4 の暗号化されたレスポンスが生成されます。

オクテット データ型 説明 値
0 ～ 15 uint128 暗号化されたレスポンス 異なる

表 1.4: プロバイダからシーカーに通知経由で送信される暗号化されたレスポンス。

特性: パスキー

この特性は、 鍵ベースのペア設定手順で使用されます。

オクテット データ型 説明 値
0～15 uint128 暗号化されたパスキー ブロック varies

表 2.1: 暗号化されたパスキー ブロック。使用方法については、キーベースのペア設定手順を参照してください。

オクテット データ型 説明 値
0 uint8 メッセージの種類 次のいずれか:
  • 0x02 = シーカーのパスキー
  • 0x03 = プロバイダのパスキー
1 - 3 unit32 6 桁のパスキー 異なる
4 ～ 15 ランダムな値（ソルト） varies

表 2.2: 未加工のパスキー ブロック。 表 2.1 の復号版。

特性: アカウント キー

ペア設定後、ファスト ペアリング シーカーはファスト ペアリング プロバイダにアカウントキーを書き込みます。

オクテット データ型 説明 値
0～15 uint128 アカウントキー（暗号化） 異なる

書き込みリクエストを受信すると、ファスト ペアリング プロバイダは次の処理を行います。

  1. 手順のステップ 4 で生成された共有シークレットを使用して、アカウント キーを復号します。
    • 保証が必要なプロバイダの場合（一般的）:
      • 復号する前に、共有シークレットがステップ 12 のパスキー リクエストの復号に使用されたことを確認します。このシークレットを使用してこのステップが成功していない場合は、この書き込みを無視して終了します。
    • この時点で、このペア設定では共有シークレット（手順の K）は再び使用されません。この鍵で暗号化されたリクエストは、手順を再開せずに拒否する必要があります。
  2. 復号された値が 0x04 または 0xFF で始まることを確認します。一致しない場合は、この書き込みを無視して終了します。
    • 値が 0x04 の場合:
      • 永続化されたアカウント鍵リストに、新しい値用のスペースがあるかどうかを確認します。
      • そうでない場合は、最も長く使用されていない値をリストから削除します。
      • 新しい値をリストに追加します。
    • 値が 0xFF の場合:
      • これを一時的なペア設定セッションとして扱い、オペレーションを実行しません。
      • これは、アカウントキーを遡って書き込むフローで発生する可能性があります。
      • 鍵を保存せず、アカウント鍵リスト、暗号化、MAC 計算で使用しないでください。
      • ボンドの削除は、機能固有のイベントまたはタイムアウトによってトリガーされます。LE 音声の共有 の場合、一時的なセッションの切断から 10 分後に BLE ボンドとリンクキーを削除することを強くおすすめします。

リスト内のアカウントキーは、キーベースのペア設定で使用されます。

特性: ファームウェア リビジョン

この特性により、シーカーは必要に応じてプロバイダのファームウェア リビジョンを読み取ることができます。常に次のデータを返す必要があります。

オクテット データ型 説明 値
0 - var utf8s ファームウェア リビジョン コード varies

プロバイダに複数のファームウェア（左のイヤホン、右のイヤホン、ケースの 3 つのファームウェアなど）がある場合でも、1 つの utf8 文字列にカプセル化する必要があります。プロバイダは、特殊なケースに対して特定の文字列を返すこともできます。

  1. status-updating: プロバイダが現在新しいファームウェアに更新中の場合。また、プロバイダはステージングされたファームウェアのバージョンを返すこともできます。

  2. status-abnormal: プロバイダが異常な状態の場合。たとえば、ファームウェアの更新に失敗したために誤動作している場合などです。この値により、Seeker はユーザーに今すぐ更新する必要があることを知らせるメッセージを表示します。

プロバイダは、デバイスの追跡を防ぐため、ファームウェア リビジョン特性へのアクセスを制限する必要があります。推奨される制限:

  • ボンディングされたデバイスはいつでもアクセスできる必要があります
  • プロバイダーが検出可能な場合、どのデバイスでもアクセスできる

プロバイダがハブを探すをサポートする場合は、追加の実装が必要です。詳しくは、Find Hub のファームウェアの更新をご覧ください。

特性: 追加データ

このサービスには次の特徴があります。

Fast Pair Service の特性 暗号化あり 権限 UUID
データ いいえ 書き込みと通知 FE2C1237-8366-4814-8EB0-01DE32100BEA
古い Fast Pair Service の特性（2021 年 1 月 1 日にサポート終了予定） 暗号化あり 権限 UUID
データ いいえ 書き込みと通知 0x1237

この特性に書き込みまたは通知を行う前に、特性 FE2C1234-8366-4814-8EB0-01DE32100BEA を介してハンドシェイクを行い、共有シークレットを取得する必要があります。この特性を流れるデータの暗号化には AES-CTR が使用されます。そのアルゴリズムは以下で定義されています。このモードは、1 つの 16 バイト ブロックを超えるデータに対してより安全です。データの完全性を確保するために HMAC-SHA256 が使用されます。これについても以下で定義します。

オクテット 説明 値
0～7 HMAC-SHA256 の最初の 8 バイト。 異なる
8 ～ 15 AES-CTR 暗号化で使用されるノンス。 varies
16 - var 暗号化されたデータ。 異なる

表 3.1: データパケット。プロバイダからシーカーに通知を介して送信されるか、シーカーからプロバイダに書き込みを介して送信されます。

オクテット データ型 説明 値
0 - var byte array データ varies。表 1.2.2 のデータ ID に従ってデコードします。
  • 0x01（パーソナライズされた名前）: utf8s

表 3.2: 元データ。 表 3.1 の暗号化されたデータから復号されます。

通知がリクエストされた場合（表 1.2.1 のビット 2 を介してパーソナライズされた名前をリクエストするなど）、ファスト ペアリング プロバイダは次の処理を行うものとします。

  1. ノンス用に暗号学的にランダムな 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(encryptedBlock[0], encryptedBlock[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 バイトを データ パケットのプレフィックスとして使用します。

書き込みリクエストを受け取ると、ファスト ペアリング プロバイダは次の処理を行います。

  1. HMAC-SHA256 の最初の 8 バイトをチェックして、データの整合性を検証します。

  2. AES-CTR を使用して暗号化されたデータを復号します。各ブロックは、

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

    ここで

    1. encryptedBlock[i] は、encrypted_data[i * 16] から始まる 16 バイトのブロックです。最後のブロックは 16 バイト未満にできます。
    2. AES 鍵はハンドシェイクから生成または識別されます（例:
        ）。
      1. 命名フロー 1 では、ECDH から取得され、このペア設定で再び使用されることはありません。この鍵で暗号化されたリクエストは、手順を再開せずに拒否する必要があります。
      2. 命名フロー 2 では、アカウント キーです。

  3. concat(clearBlock[0], clearBlock[1],...) を実行して、元データを作成します。