特徴

GATT サービスのサービスと特性

ファスト ペアリング プロバイダは、以下の 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
ファームウェアのリビジョン × 読み取り 0x2A26

特性: モデル ID

この特性により、シーカーはデバイスが検出可能モードでアドバタイジングしている場合を除き、必要に応じてモデル ID を読み取ることができます。常に次のデータが返されます。

オクテット データ型 説明 値
0 ～ 2 uint24 モデル ID 変わる、変動する（# 文脈に応じて適宜変更）

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

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

  • ケース 1: 事前共有キーは、なりすまし対策の公開鍵/秘密鍵のペアと、ペアリングの試行ごとに変化するシーカー自身の公開鍵/秘密鍵のペアに基づいています。

    • プロバイダはペアリングモードです。
    • シーカーは、プロバイダがなりすまし対策用の秘密鍵を所有していることを確認します。

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

  • ケース 2: 事前共有キーはアカウントキーの一つです。

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

事前共有キーを使用する点を除き、両方のケースは非常に類似しているため、手順で組み合わせます。

データ形式

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

オクテット データ型 説明 値 必須？
0～15 uint128 暗号化されたリクエスト 変わる、変動する（# 文脈に応じて適宜変更） 必須
16 ～ 79 公開鍵 変わる、変動する（# 文脈に応じて適宜変更） 任意

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

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

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

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

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

オクテット データ型 説明 値
0 uint8 メッセージの種類 0x01 = キーベースのペアリング レスポンス
1 ～ 6 uint48 プロバイダの公開（BR/EDR）住所 場合によって異なる
7 ～ 15 ランダム値（ソルト） 場合によって異なる

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

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

表 1.4: プロバイダが通知を介してシーカーに送信する暗号化されたレスポンス

特性: パスキー

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

オクテット データ型 説明 値
0～15 uint128 暗号化されたパスキー ブロック 場合によって異なる

表 2.1: 暗号化されたパスキー ブロック。使用方法については、キーベースのペアリング手順をご覧ください。

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

表 2.2: 未加工パスキー ブロック。 表 2.1 の復号バージョン

特性: アカウントキー

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

オクテット データ型 説明 値
0～15 uint128 アカウント キー（暗号化済み） 場合によって異なる

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

  1. 手順のステップ 4 で生成した共有シークレットを使用して、アカウント キーを復号します。
    1. 復号する前に、ステップ 12 のパスキー リクエストの復号に共有シークレットが使用されていることを確認します。このシークレットを使用してこのステップが成功しなかった場合、この書き込みを無視して終了します。
    2. この時点では、共有シークレット（手順の K）はこのペアリングに再度使用されません。手順を再起動せずにこの鍵で暗号化されたリクエストは拒否されます。
  2. 復号された値が 0x04 で始まることを確認します。含まれていない場合は、この書き込みを無視して終了します。
  3. 永続化されたアカウントキーのリストに、新しい値用のスペースがあるかどうかを確認します。
  4. そうでない場合は、最も長い間使われていない値をリストから削除します。
  5. 新しい値をリストに追加します。

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

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

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

オクテット データ型 説明 値
0 - var utf8s ファームウェア リビジョン コード 場合によって異なる

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

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

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

特性: 追加データ

このサービスの特性は次のとおりです。

ファスト ペアリング サービスの特性 暗号化 権限 UUID
データ × 書き込みと通知 FE2C1237-8366-4814-8EB0-01DE32100BEA
従来のファスト ペアリング サービスの特性（2021 年 1 月 1 日にサポート終了予定） 暗号化 権限 UUID
データ × 書き込みと通知 0x1237

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

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

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

オクテット データ型 説明 値
0 - var byte array データ 変動する場合は、表 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 バイトの 0) によって生成され、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. encryptionBlock[i] は、encrypted_data[i * 16] から始まる 16 バイトのブロックです。最後のブロックは 16 バイト未満にできます。
    2. handshake から AES 鍵が生成または識別される。例:
      1. 命名フロー 1 で、これは ECDH からのものであり、このペア設定で再度使用されることはありません。手順を再起動せずにこの鍵で暗号化されたリクエストは拒否する必要があります。
      2. 命名フロー 2 ではアカウントキーになります。

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