特性

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

ファスト ペアリング プロバイダは、次の 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

この特性により、デバイスが検出可能モードでアドバタイズしているとき以外にも、必要に応じて Seeker がモデル ID を読み取ることができます。常に次のデータを返す必要があります。

オクテット データ型 説明 値
0 ～ 2 uint24 モデル ID 可変

特性: キーベースのペア設定

この特性は、キーベースのペア設定手順を制御します。この手順では、シーカーとプロバイダの両方が事前共有キーを所有していることを確認することで、一定の信頼レベルが確立されます。キーはケースごとに異なります。

  • ケース 1: 事前共有鍵は、スプーフィング対策の公開鍵/秘密鍵のペアと、ペア設定を試みるたびに変化するシーカー独自の公開鍵/秘密鍵のペアに基づいています。

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

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

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

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

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

データ形式

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

オクテット データ型 説明 値 必須かどうか
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 アドレス varies フラグ ビット 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 メッセージ グループ varies フラグビット 0 が設定されている場合は必須
9 uint8 メッセージ コード varies フラグビット 0 が設定されている場合は必須
10 uint8 フラグに依存:
  • ビット 0 が設定されている: 追加のデータ長が 6 未満
  • ビット 1 が設定されている: データ ID
 varies フラグ ビット 0 または 1 が設定されている場合は必須
11 - n 追加データ varies 省略可
n - 15 ランダムな値（ソルト） varies 必須

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

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

表 1.3: 生のレスポンス。 表 1.4 の暗号化されたレスポンスを生成するために暗号化されます。

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

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

特性: パスキー

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

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

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

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

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

特性: アカウント キー

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

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

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

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

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

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

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

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

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

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

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

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

  • ペア設定されたデバイスはいつでもアクセスできる必要があります
  • Provider が検出可能な場合、どのデバイスでもアクセスできる

特性: 追加データ

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

ファスト ペアリング サービスの特性 暗号化あり 権限 UUID
データ いいえ 書き込みと通知 FE2C1237-8366-4814-8EB0-01DE32100BEA
古いファスト ペアリング サービス特性（2021 年 1 月 1 日に非推奨となる予定） 暗号化あり 権限 UUID
データ いいえ 書き込みと通知 0x1237

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

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

表 3.1: プロバイダからシーカーに通知経由で送信される、またはシーカーからプロバイダに書き込み経由で送信されるデータ パケット。

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

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

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

  1. Nonce 用に暗号学的にランダムな 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 バイトのゼロ) によって生成されます。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],...) を実行して、生データを作成します。