特性

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

ファスト ペアリング プロバイダは、以下の 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: 事前共有キーがなりすまし対策の公開鍵/秘密鍵に基づいている シーカー固有の公開鍵/秘密鍵のペアが含まれます。 ペア設定の試行。

    • プロバイダがペア設定モードになっています。
    • シーカーは、プロバイダが 秘密鍵を提供します。

    ペアリングモードの場合、プロバイダはもちろん、 たとえば、Fast ペアのキーベースのペアリング。

  • ケース 2: 事前共有キーがアカウントキーの 1 つである。

    • 通常、プロバイダがペア設定モードになっていません。（ただし、これは 要件 - プロバイダは、ログイン状態でもアカウント キーの使用をサポート ペア設定モード] をタップします）。
    • シーカーとプロバイダはそれぞれ、相手方が できます。

事前共有キーを使用する点を除き、どちらのケースも非常によく似ています。 プロシージャで組み合わせられます。

データ形式

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

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

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

オクテット データ型 説明 値 必須かどうか
0 uint8 メッセージの種類 0x00 = キーベースのペアリング リクエスト 必須
1 uint8 フラグ
  • ビット 0（MSB）: 非推奨となり、シーカーにより無視されます。
  • ビット 1: 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 で生成された共有シークレットを使用して、アカウント キーを復号 手順をご覧ください。
    • ボンディングを必要とするプロバイダの場合（共通）: <ph type="x-smartling-placeholder">
        </ph>
      • 復号する前に、その共有シークレットを使用して復号された パスキーをリクエストします。これを使用してこのステップに合格しなかった場合は、 この書き込みを無視して終了します。
    • この時点では、共有シークレット（手順の K）は使用されません。 これもまたこのペアリングですこの鍵で暗号化されたリクエスト 拒否されるはずです。
  2. 復号された値が 0x04 で始まっていることを確認します。含まれていない場合は、 書き留めて終了します。
  3. 永続的なアカウントキーのリストに新しいアカウント キー用のスペースがあるかどうかを確認します。 あります。
  4. 使用されていない場合は、最も長い間使用されていない値をリストから削除します。
  5. 新しい値をリストに追加します。

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

特徴：ファームウェアのリビジョン

この特性により、Seeker はデバイスのファームウェア リビジョンを読み取れます。 プロバイダによって異なります。常に次のデータが返されます。

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

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

  1. status-renew: プロバイダが現在新しいファームウェアにアップデート中かどうか。 または、ステージングしたファームウェアのバージョンをプロバイダから返すこともできます。

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

プロバイダは、ファームウェア リビジョンの特性に対するアクセスを、 追跡できないようにします。推奨される制限事項:

  • ボンディングされたデバイスは常にアクセスできなければならず、
  • プロバイダが検出可能であれば、すべてのデバイスにアクセス可能にする必要がある

特性: 追加データ

このサービスは、次の特徴を有するものとします。

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

この特性への書き込みや通知を行う前に、 特性 FE2C1234-8366-4814-8EB0-01DE32100BEA による handshake を使用して、 共有シークレットを作成します。このネットワークを流れるデータの暗号化には AES-CTR が使用されます そのアルゴリズムは以下に定義されています。このモードは 16 バイトのブロックを超えるデータでも 安全に保護されますHMAC-SHA256 は データの整合性を確保するために使用する。これについても以下に定義する。

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

表 3.1: プロバイダからシーカーへ シーカーからプロバイダに書き込みで通知または送信します。

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

表 3.2: 元データ。鍵暗号鍵（KEK）で暗号化されたデータから 表 3.1.

通知が要求されたとき（例: 通知のビット 2 を介してパーソナライズされた名前をリクエストする 表 1.2.1 を参照）、ファスト ペアリング プロバイダは以下を行うものとします。

  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 バイトの ZERO）によって生成されます。 shared_secret は、プロシージャのステップ 4 で生成されたものです。
    2. opad は 64 バイトの外側のパディングで、 0x5C。
    3. iPad は 64 バイトの内部パディングで、繰り返しのバイト値で 0x36。

  5. HMAC-SHA256 の最初の 8 バイトを Data 。

書き込みリクエストを受け取った場合、ファスト ペアリング プロバイダは以下を行うものとします。

  1. 先頭の 8 バイトをチェックして、データの完全性を検証 HMAC-SHA256。

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

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

    ここで

    1. encryptionBlock[i] は、encrypted_data[i * 16] から始まる 16 バイトのブロックです。 最後のブロックは 16 バイト未満にする必要があります。
    2. AES 鍵が handshake から生成または識別されます。たとえば、 <ph type="x-smartling-placeholder">
        </ph>
      1. 命名フロー 1 では、これは ECDH からのものであり、 このペアリングにも使用できます。暗号化された状態で到着するすべての 鍵に置き換える必要があります。 拒否されます。
      2. 命名フロー 2 では、これはアカウント キーです。

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