検索ハブ ネットワーク アクセサリの仕様

v1.3

Find Hub Network（FHN）アクセサリ仕様は、ビーコンを送信する Bluetooth Low Energy（BLE）デバイスを追跡するためのエンドツーエンドの暗号化アプローチを定義します。このページでは、Fast Pair 仕様の拡張機能としての FHN について説明します。プロバイダは、FHN に対応するデバイスを所有しており、それらのデバイスの位置情報の追跡を有効にすることを希望する場合、この拡張機能を有効にする必要があります。

GATT 仕様

次のセマンティクスで、追加の汎用属性（GATT）特性を Fast Pair サービスに追加する必要があります。

ファスト ペアリング サービスの特性	暗号化あり	権限	UUID
ビーコン アクション	いいえ	読み取り、書き込み、通知	FE2C1238-8366-4814-8EB0-01DE32100BEA

表 1: FHN の Fast Pair サービスの特性。

認証

この拡張機能に必要なオペレーションは、チャレンジ レスポンス メカニズムで保護された書き込みオペレーションとして実行されます。オペレーションを実行する前に、シーカーは表 1 の特性から読み取りオペレーションを実行することが想定されます。これにより、次の形式のバッファが生成されます。

オクテット	データ型	説明	値
0	uint8	プロトコルのメジャー バージョン番号	0x01
1 - 8	バイト配列	1 回限りのランダム ノンス	varies

読み取りオペレーションごとに異なるノンスが生成され、1 つのノンスは 1 つのオペレーションに対してのみ有効です。オペレーションが失敗した場合でも、ノンスは無効にする必要があります。

次に、シーカーは、後続の書き込みリクエストで使用される 1 回限りの認証鍵を計算します。認証キーは、表 2 ～ 5 に記載されているように計算されます。リクエストされたオペレーションに応じて、Seeker は次の 1 つ以上の鍵の知識を証明します。

• アカウント キー: Fast Pair 仕様で定義されている 16 バイトの Fast Pair アカウント キー。

• 所有者アカウント キー: シーカーが Beacon Actions 特性に初めてアクセスしたときに、プロバイダは既存のアカウント キーの 1 つを所有者アカウント キーとして選択します。選択したオーナー アカウント キーは、プロバイダが工場出荷時の状態にリセットされるまで変更できません。プロバイダは、無料のアカウントキー スロットがなくなったときに、オーナー アカウントキーを削除してはなりません。

  • 初回ペア設定時に FHN をすでにサポートしているプロバイダ（または、出荷時の設定にリセットした後のペア設定時に FHN をサポートしているプロバイダ）は、最初の鍵を選択します。これは、ペア設定中にシーカーがプロビジョニング状態を読み取る際に存在する唯一の鍵であるためです。

  • ペア設定後に FHN サポートを取得したプロバイダ（ファームウェア アップデートなど）は、既存のアカウントキーを選択できます。ファームウェアの更新を行ったユーザーがプロバイダの現在の所有者であると仮定すると、ファームウェアの更新後にビーコン アクション特性からプロビジョニング状態を読み取るために使用される最初のアカウント キーを選択するのは妥当です。

• エフェメラル ID 鍵（EIK）: FHN プロビジョニング プロセスを実行するときに Seeker がランダムに選択する 32 バイトの鍵。この鍵は、位置情報のレポートのエンドツーエンド暗号化に使用される暗号鍵を導出するために使用されます。Seeker はバックエンドにそれを公開しません。

• 復元キー: SHA256(ephemeral identity key || 0x01) として定義され、最初の 8 バイトに切り捨てられます。鍵はバックエンドに保存され、ユーザーがデバイスのボタンを押して同意した場合、シーカーは鍵を使用して EIK を復元できます。

• リングキー: SHA256(ephemeral identity key || 0x02) として定義され、最初の 8 バイトに切り詰められます。キーはバックエンドに保存され、Seeker はデバイスを鳴らすためだけにキーを使用できます。

• 望ましくないトラッキング保護キー: SHA256(ephemeral identity key || 0x03) として定義され、最初の 8 バイトに切り捨てられます。キーはバックエンドに保存され、シーカーは 望ましくないトラッキングの保護モードを有効にするためにのみ使用できます。

運用

特性に書き込まれるデータの形式は、表 2 ～ 5 に示されています。各オペレーションについては、このセクションの後半で詳しく説明します。

オクテット	データ型	説明	値
0	uint8	データ ID	0x00: ビーコン パラメータを読み取る 0x01: プロビジョニング状態を読み取る 0x02: エフェメラル ID 鍵を設定する 0x03: 一時的な ID キーをクリア
1	uint8	データ長	varies
2 ～ 9	バイト配列	ワンタイム認証キー	HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data) の最初の 8 バイト
10 - var	バイト配列 <0x	追加データ <0x	0x00: なし 0x01: n/a 0x02: アカウント鍵で AES-ECB-128 暗号化されたエフェメラル識別鍵である 32 バイト。プロバイダがすでにエフェメラル ID 鍵セットを持っている場合は、SHA256(current ephemeral identity key || the last nonce read from the characteristic) の最初の 8 バイトも送信します。 0x03: SHA256(ephemeral identity key || the last nonce read from the characteristic) の最初の 8 バイト

表 2: ビーコン プロビジョニング リクエスト。

オクテット	データ型	説明	値
0	uint8	データ ID	0x04: ユーザーの同意を得て一時的な ID 鍵を読み取る
1	uint8	データ長	0x08
2 ～ 9	バイト配列	ワンタイム認証キー	HMAC-SHA256(recovery key, protocol major version number || the last nonce read from the characteristic || data ID || data length) の最初の 8 バイト

表 3: ビーコン プロビジョニング キー復元リクエスト。

オクテット	データ型	説明	値
0	uint8	データ ID	0x05: Ring 0x06: 着信中の状態を読み取る
1	uint8	データ長	varies
2 ～ 9	バイト配列	ワンタイム認証キー	HMAC-SHA256(ring key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data) の最初の 8 バイト
10 - var	バイト配列	追加データ	0x05: 着信状態、着信時間、着信音量を示す 4 バイト。 0x06: なし

表 4: 着信要求。

オクテット	データ型	説明	値
0	uint8	データ ID	0x07: 望ましくないトラッキング防止モードを有効にする 0x08: 不要なトラッキング防止モードを無効にする
1	uint8	データ長	varies
2 ～ 9	バイト配列	ワンタイム認証キー	HMAC-SHA256(unwanted tracking protection key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data) の最初の 8 バイト
10 - var	バイト配列	追加データ	0x07: 1 バイトの制御フラグ（省略可） 0x08: SHA256(ephemeral identity key || the last nonce read from the characteristic) の最初の 8 バイト

表 5: 望ましくないトラッキング防止リクエスト。

書き込みが成功すると、表 6 に記載されている通知がトリガーされます。

0x05: Ring state change 以外のデータ ID を含む通知は、通知をトリガーする書き込みトランザクションが完了する前、つまり書き込みリクエストのレスポンス PDU が送信される前に送信されるべきです。

オクテット	データ型	説明	値
0 <0x0	uint8	データ ID <0x	0x00: ビーコン パラメータを読み取る 0x01: プロビジョニング状態を読み取る 0x02: エフェメラル ID 鍵を設定する 0x03: 一時的な ID キーをクリア 0x04: ユーザーの同意を得て一時的な ID 鍵を読み取る 0x05: 着信状態の変更 0x06: 着信中の状態を読み取る 0x07: 望ましくないトラッキング防止モードを有効にする 0x08: 不要なトラッキング防止モードを無効にする
1	uint8	データ長	varies
2 ～ 9 人	バイト配列	認証	オペレーションごとの詳細
10 - var <	バイト配列 <0x	追加データ <0x	0x00: 送信電力、クロック値、暗号化方式、着信機能を示す 8 バイト。アカウントキーで AES-ECB-128 暗号化（ゼロパディング） 0x01: プロビジョニング状態を示す 1 バイト。該当する場合は、現在のエフェメラル ID（20 または 32 バイト）が続く 0x04: 一時的な ID 鍵である 32 バイト。アカウント鍵で AES-ECB-128 暗号化 0x05: 新しい状態と変更のトリガーを示す 4 バイト 0x06: 3 バイト。アクティブに呼び出し中のコンポーネントと、呼び出しの残り時間（デシ秒単位）を示す 他のデータ ID は空の追加データを使用する

表 6: ビーコン サービス レスポンス。

表 7 に、オペレーションから返される可能性のある GATT エラーコードを示します。

コード	説明	メモ
0x80	未認証	認証が失敗した場合（古いノンスが使用された場合を含む）に、書き込みリクエストへのレスポンスとして返されます。
0x81	無効な値	無効な値が指定された場合、または受信したデータのバイト数が想定外の場合に返されます。
0x82	ユーザーの同意なし	デバイスがペア設定モードでない場合に、データ ID 0x04: Read ephemeral identity key with user consent を含む書き込みリクエストへのレスポンスとして返されます。

表 7: GATT エラーコード。

ビーコンのパラメータを読み取る

シーカーは、データ ID 0x00 の表 2 のリクエストで構成される特性に書き込みオペレーションを実行することで、ビーコンのパラメータについてプロバイダにクエリできます。プロバイダは、提供されたワンタイム認証キーがデバイスに保存されているアカウントキーのいずれかと一致することを確認します。

検証に失敗した場合、プロバイダは認証されていないエラーを返します。

成功すると、プロバイダはデータ ID 0x00 の表 6 のレスポンスで通知します。プロバイダは次のようにデータ セグメントを構築します。

オクテット	データ型	説明	値
0	uint8	調整済みの電力	0 m で受信した調整済みの電力（[-100, 20] の範囲の値）。1 dBm の分解能で符号付き整数として表されます。
1～4	uint32	クロック値	現在のクロック値（秒単位、ビッグ エンディアン）。
5	uint8	カーブの選択	暗号化に使用される楕円曲線: 0x00（デフォルト）: SECP160R1 0x01: SECP256R1（拡張アドバタイジングが必要）
6 <0x0	uint8	コンポーネント <	着信可能なコンポーネントの数: 0x00: デバイスが着信音を鳴らすことができないことを示します。 0x01: 1 つのコンポーネントのみが着信音を鳴らすことができることを示します。 0x02: 左右のイヤホンという 2 つのコンポーネントが個別に鳴動できることを示します。 0x03: 左のイヤホン、右のイヤホン、ケースの 3 つのコンポーネントが個別に鳴動できることを示します。
7 <0x0	uint8	着信機能	サポートされているオプションは です。 0x00: 着信音の音量選択は利用できません。 0x01: 着信音の音量を選択できます。設定されている場合、プロバイダは着信音の操作で示されているように、3 つの音量レベルを受け入れて処理する必要があります。
8～15	バイト配列	パディング	AES 暗号化のゼロ パディング。

データは、リクエストの認証に使用されるアカウントキーで AES-ECB-128 暗号化する必要があります。

認証セグメントは、HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data after encryption || 0x01) の最初の 8 バイトとして定義されます。

ビーコンのプロビジョニング状態を読み取る

Seeker は、表 2 のデータ ID 0x01 のリクエストで構成される特性に書き込みオペレーションを実行することで、ビーコンのプロビジョニング状態について Provider にクエリを実行できます。プロバイダは、提供された 1 回限りの認証キーがデバイスに保存されているアカウントキーのいずれかと一致することを確認します。

検証に失敗すると、プロバイダは未認証エラーを返します。

成功すると、プロバイダはデータ ID 0x01 のテーブル 6 のレスポンスで通知します。プロバイダは次のようにデータ セグメントを構築します。

オクテット	データ型	説明	値
0 <0x0	uint8	プロビジョニング状態	次の値を持つビットマスク: ビット 1（0x01）: デバイスにエフェメラル ID 鍵が設定されている場合に設定します。 ビット 2（0x02）: 提供された 1 回限りの認証キーがオーナー アカウント キーと一致する場合に設定します。
1 ～ 20 または 32	バイト配列	現在の一時的な識別子	ビーコンがアドバタイズする現在の一時 ID を示す 20 または 32 バイト（使用されている暗号化方式によって異なります）。デバイスに一時 ID が設定されている場合。

認証セグメントは、HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data || 0x01) の最初の 8 バイトとして定義されます。

エフェメラル ID 鍵を設定する

プロビジョニングされていないプロバイダを FHN ビーコンとしてプロビジョニングする、またはすでにプロビジョニングされているプロバイダの一時的な ID 鍵を変更するために、シーカーは、データ ID 0x02 の表 2 のリクエストで構成される特性に対して書き込みオペレーションを実行します。プロバイダは、次のことを確認します。

• 提供されたワンタイム認証キーがオーナー アカウントのキーと一致している。
• エフェメラル ID 鍵のハッシュが提供された場合、ハッシュ化されたエフェメラル ID 鍵は現在のエフェメラル ID 鍵と一致します。
• エフェメラル ID 鍵のハッシュが提供されていない場合は、プロバイダが FHN ビーコンとしてすでにプロビジョニングされていないことを確認します。

検証に失敗すると、プロバイダは未認証エラーを返します。

成功すると、一致するアカウントキーを使用して AES-ECB-128 で復号化することで、エフェメラル ID キーが復元されます。キーはデバイスに保存され、その時点からプロバイダは FHN フレームのアドバタイズを開始します。新しい一時 ID キーは、BLE 接続が終了するとすぐに有効になります。プロバイダは、データ ID 0x02 の表 6 のレスポンスで通知します。

認証セグメントは、HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || 0x01) の最初の 8 バイトとして定義されます。

エフェメラル ID 鍵をクリアする

プロバイダのビーコン部分のプロビジョニングを解除するには、シーカーが特性に対して書き込みオペレーションを実行します。これは、データ ID 0x03 のテーブル 2 からのリクエストで構成されます。プロバイダは、次のことを確認します。

• 提供されたワンタイム認証キーがオーナー アカウントのキーと一致している。
• ハッシュ化されたエフェメラル ID キーが現在のエフェメラル ID キーと一致します。

プロバイダが FHN ビーコンとしてプロビジョニングされていない場合、または検証に失敗した場合、未認証エラーが返されます。

成功すると、プロバイダはキーを忘れ、FHN フレームの広告を停止します。プロバイダは、データ ID 0x03 の表 6 のレスポンスで通知します。認証セグメントは、HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || 0x01) の最初の 8 バイトとして定義されます。

ユーザーの同意を得てエフェメラル ID キーを読み取る

このオプションは、紛失したキーを復元する場合にのみ使用できます。キーは Seeker によってローカルにのみ保存されるためです。そのため、この機能は、デバイスがペア設定モードになっている場合、またはデバイスの物理ボタンが押されてから（ユーザーの同意とみなされます）一定の時間が経過するまでの間のみ利用できます。

Seeker は、クリアテキスト キーを復元できるように、復元キーをバックエンドに保存する必要がありますが、EIK 自体は保存しません。

EIK を読み取るため、シーカーは特性に対して書き込みオペレーションを実行します。これは、データ ID 0x04 のテーブル 3 からのリクエストで構成されます。プロバイダは、次のことを確認します。

• ハッシュ化された復元キーが、想定される復元キーと一致します。
• デバイスが EIK リカバリモードになっている。

検証に失敗すると、プロバイダは未認証エラーを返します。

デバイスがペア設定モードでない場合、プロバイダは No User Consent エラーを返します。

成功すると、プロバイダはデータ ID 0x04 のテーブル 6 のレスポンスで通知します。

認証セグメントは、HMAC-SHA256(recovery key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data || 0x01) の最初の 8 バイトとして定義されます。

着信音の操作

シーカーは、データ ID 0x05 の表 4 のリクエストで構成される特性への書き込みオペレーションを実行することで、プロバイダに音を再生するようリクエストできます。プロバイダは次のようにデータ セグメントを構築します。

オクテット	データ型	説明	値
0 <0x0	uint8	着信音の操作 <0x0A	次の値を持つビットマスク: ビット 1（0x01）: 右リング ビット 2（0x02）: 左を鳴らす ビット 3（0x04）: リングケース 0xFF: すべてのコンポーネントを鳴らす 0x00: 着信音を停止
1 - 2	uint16	タイムアウト <0x	タイムアウト（デシ秒単位）。0 より大きく、10 分相当を超えない値にする必要があります。 プロバイダはこの値を使用して、着信音を鳴らしてから消音するまでの時間を決定します。デバイスのコンポーネントのいずれかがすでに鳴っている場合、タイムアウトはすでに有効になっているタイムアウトをオーバーライドします。 リング オペレーションが 0x00 に設定されている場合、タイムアウトは無視されます。
3 <0x0	uint8	音量 <0x	0x00: デフォルト 0x01: 低 0x02: 中 0x03: 高 これらの値の正確な意味は実装によって異なります。

リクエストを受信すると、プロバイダは次のことを確認します。

• 提供されたワンタイム認証キーがリングキーと一致する。
• リクエストされた状態が、着信音を鳴らすことができるコンポーネントと一致します。

プロバイダが FHN ビーコンとしてプロビジョニングされていない場合、または検証に失敗した場合、未認証エラーが返されます。ただし、プロバイダで不要なトラッキング保護が有効になっており、不要なトラッキング保護リクエストをトリガーしたときに着信認証スキップ フラグがオンになっていた場合、プロバイダはそのチェックをスキップする必要があります。認証データは引き続き Seeker によって提供されることが想定されますが、任意の値に設定できます。

着信が開始または終了すると、表 6 に示すように、データ ID 0x05 の通知が送信されます。通知の内容は次のように定義されます。

オクテット	データ型	説明	値
0 <0x0	uint8	呼び出し状態	0x00: 開始 0x01: 起動または停止に失敗しました（リクエストされたすべてのコンポーネントが範囲外です） 0x02: 停止（タイムアウト） 0x03: 停止（ボタンを押した） 0x04: 停止（GATT リクエスト）
1	uint8	着信コンポーネント	リクエストで定義されている、アクティブに鳴動しているコンポーネントのビットマスク。
2 ～ 3	uint16	タイムアウト	着信の残り時間（デシ秒単位）。デバイスの着信音が停止している場合は、0x0000 を返します。

認証セグメントは、HMAC-SHA256(ring key, protocol major version number || the nonce used to initiate the ringing command || data ID || data length || additional data || 0x01) の最初の 8 バイトとして定義されます。

着信または着信停止のリクエストを受信したときに、デバイスがすでにリクエストされた着信状態にある場合、プロバイダは着信状態の通知、またはそれぞれ 0x00: 開始済み、0x04: 停止済み（GATT リクエスト）のいずれかの通知を送信する必要があります。このリクエストは既存の状態のパラメータをオーバーライドするため、着信音の時間を延長できます。

プロバイダに物理ボタンがある場合（またはタッチ感知が有効になっている場合）、着信中にそのボタンを押すと、着信機能が停止します。

ビーコンの呼び出し状態を取得する

ビーコンの鳴動状態を取得するために、シーカーは、データ ID 0x06 の表 4 のリクエストで構成される特性に対して書き込みオペレーションを実行します。プロバイダは、提供されたワンタイム認証キーがリングキーと一致することを確認します。

プロバイダが FHN ビーコンとしてプロビジョニングされていない場合や、検証に失敗した場合、プロバイダは認証されていないエラーを返します。

成功すると、プロバイダはデータ ID 0x06 のテーブル 6 のレスポンスで通知します。プロバイダは次のようにデータ セグメントを構築します。

オクテット	データ型	説明	値
0	uint8	着信コンポーネント	着信リクエストで定義されている、アクティブに着信しているコンポーネント。
1 - 2	uint16	タイムアウト	着信の残り時間（デシ秒単位）。デバイスが鳴っていない場合は、0x0000 が返されることに注意してください。

認証セグメントは、HMAC-SHA256 (ring key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data || 0x01) の最初の 8 バイトとして定義されます。

不審なトラッキング防止モード

望ましくないトラッキング保護モードは、サーバー通信なしでクライアントが不正使用デバイスを特定できるようにすることを目的としています。デフォルトでは、プロバイダは ID のローテーションの説明に従って、すべての識別子をローテーションする必要があります。Find Hub サービスは、Find Hub ネットワークを介して、望ましくないトラッキング保護モードの有効化リクエストを中継できます。これにより、サービスはプロバイダに固定 MAC アドレスを一時的に使用させ、クライアントがデバイスを検出して、望ましくないトラッキングの可能性をユーザーに警告できるようにします。

ビーコンの不要なトラッキング保護モードを有効または無効にするため、シーカーは、それぞれデータ ID 0x07 または 0x08 の表 5 のリクエストで構成される特性への書き込みオペレーションを実行します。

望ましくないトラッキング防止モードを有効にした場合

プロバイダは次のようにデータ セグメントを構築します。

オクテット	データ型	説明	値
0 <0x0	uint8	制御フラグ <0	0x01: 着信認証をスキップします。設定すると、望ましくないトラッキング保護モードでは着信リクエストが認証されません。 フラグが設定されていない場合（バイトがすべてゼロの場合）、データ セクションを完全に省略して空のデータ セクションを送信しても構いません。 フラグは、望ましくないトラッキング防止モードが無効になるまでのみ有効です。

プロバイダは、提供されたワンタイム認証キーが望ましくないトラッキング保護キーと一致することを確認します。プロバイダが FHN ビーコンとしてプロビジョニングされていない場合や、検証に失敗した場合は、未認証エラーが返されます。

望ましくないトラッキング保護モードが有効になっている場合、ビーコンは MAC プライベート アドレスのローテーション頻度を 24 時間に 1 回に減らす必要があります。アドバタイズされるエフェメラル ID は、通常どおりローテーションを続ける必要があります。フレームタイプは 0x41 に設定する必要があります。この状態は、[ハッシュ化されたフラグ] セクションにも反映されます。

望ましくないトラッキング防止モードを無効にする場合

プロバイダは、次のことを確認します。

• 提供されたワンタイム認証キーが、望ましくないトラッキング防止キーと一致している。
• ハッシュ化されたエフェメラル ID キーが現在のエフェメラル ID キーと一致します。

プロバイダが FHN ビーコンとしてプロビジョニングされていない場合や、検証に失敗した場合、プロバイダは認証されていないエラーを返します。

望ましくないトラッキング保護モードが無効になると、ビーコンはエフェメラル識別子のローテーションと同期して、通常のレートで MAC アドレスのローテーションを再び開始します。フレームタイプは 0x40 に戻す必要があります。この状態は、[ハッシュ化されたフラグ] セクションにも反映されます。

成功すると、プロバイダはデータ ID 0x07 または 0x08 のテーブル 6 のレスポンスで通知します。

認証セグメントは、HMAC-SHA256(unwanted tracking protection key, protocol major version number || the last nonce read from the characteristic || data ID || data length || 0x01) の最初の 8 バイトとして定義されます。

アドバタイズされたフレーム

プロビジョニング後、プロバイダは少なくとも 2 秒ごとに 1 回 FHN フレームをアドバタイズすることが想定されます。ファスト ペアリング フレームがアドバタイズされる場合、プロバイダは通常のファスト ペアリング アドバタイズ内に FHN フレームをインターリーブする必要があります。たとえば、プロバイダは 2 秒ごとに 7 つの Fast Pair 広告と 1 つの FHN 広告をアドバタイズする必要があります。

FHN アドバタイズメントの伝導 Bluetooth 送信電力は、0 dBm 以上に設定する必要があります。

FHN フレームには、クラウドソーシング ネットワークに貢献するサポート対象のクライアントが位置情報レポートの暗号化に使用する公開鍵が含まれています。楕円曲線鍵には、従来の BLE 4 フレームに適合する 160 ビット鍵と、拡張アドバタイズ機能付きの BLE 5 を必要とする 256 ビット鍵の 2 種類があります。使用する曲線は、プロバイダの実装によって決まります。

FHN フレームは次のように構成されています。

オクテット	値	説明
0	0x02	長さ
1	0x01	フラグのデータ型の値
2	0x06	フラグデータ
3	0x18 または 0x19	長さ
4	0x16	サービスデータのデータ型の値
5	0xAA	16 ビットのサービス UUID
6	0xFE	...
7	0x40 または 0x41	不要なトラッキング防止モードの表示を含む FHN フレームタイプ
8..27		20 バイトの一時 ID
28		ハッシュ化されたフラグ

表 8: 160 ビットの曲線に対応する FHN フレーム。

表 9 に、256 ビット曲線のバイト オフセットと値を示します。

オクテット	値	説明
0	0x02	長さ
1	0x01	フラグのデータ型の値
2	0x06	フラグデータ
3	0x24 または 0x25	長さ
4	0x16	サービスデータのデータ型の値
5	0xAA	16 ビットのサービス UUID
6	0xFE	...
7	0x40 または 0x41	不要なトラッキング防止モードの表示を含む FHN フレームタイプ
8..39		32 バイトの一時的な識別子
40		ハッシュ化されたフラグ

表 9: 256 ビットの曲線に対応する FHN フレーム。

一時的な識別子（EID）の計算

ランダムは、次のデータ構造をエフェメラル ID 鍵で AES-ECB-256 暗号化することで生成されます。

オクテット	フィールド	説明
0 ～ 10	パディング	値 = 0xFF
11	K	ローテーション期間の指数
12 ～ 15	TS[0]...TS[3]	ビーコン時間カウンタ（32 ビットのビッグ エンディアン形式）。下位 K ビットがクリアされます。
16 ～ 26	パディング	値 = 0x00
27	K	ローテーション期間の指数
28 ～ 31	TS[0]...TS[3]	ビーコン時間カウンタ（32 ビットのビッグ エンディアン形式）。下位 K ビットがクリアされます。

表 10: 疑似乱数の構築。

この計算の結果は 256 ビットの数値となり、r' と表記されます。

残りの計算では、楕円曲線暗号オペレーションに SECP160R1 または SECP256R1 が使用されます。 SEC 2: 推奨される楕円曲線ドメイン パラメータで曲線定義を参照してください。この定義では、次に参照される Fp、n、G が定義されています。

r' は、r = r' mod n を計算することで有限体 Fp に投影されるようになりました。最後に、使用される公開鍵を表す曲線上の点である R = r * G を計算します。ビーコンは、R の x 座標である Rx をエフェメラル識別子としてアドバタイズします。

ハッシュ化されたフラグ

ハッシュ化されたフラグ フィールドは次のように計算されます（ビットは最上位から最下位の順に参照されます）。

• ビット 0 ～ 4: 予約済み（ゼロに設定）。
• ビット 5 ～ 6 は、デバイスのバッテリー残量を次のように示します。
  • 00: バッテリー残量の表示はサポートされていません
  • 01: 通常のバッテリー残量
  • 10: バッテリー残量が少ない
  • 11: バッテリー残量が非常に少ない（バッテリーの交換がまもなく必要）
• ビーコンが望ましくないトラッキング防止モードの場合はビット 7 が 1 に設定され、それ以外の場合は 0 に設定されます。

このバイトの最終的な値を生成するために、SHA256(r) の最下位バイトとの XOR 演算が行われます。

r は曲線のサイズに合わせる必要があります。表現が 160 ビットまたは 256 ビットより短い場合は、最上位ビットとしてゼロを追加します。表現が 160 ビットまたは 256 ビットより長い場合は、最上位ビットを切り捨てます。

ビーコンがバッテリー残量表示をサポートしておらず、望ましくないトラッキング防止モードでない場合、このバイトをアドバタイズから完全に省略できます。

EID による暗号化

メッセージ m を暗号化するために、サイト（ビーコンから Rx を読み取った）は次の処理を行います。

1. EID の計算セクションで定義されているように、Fp の乱数 s を選択します。
2. Compute S = s * G。
3. 曲線方程式に代入し、可能な結果から任意の Ry 値を選択して R = (Rx, Ry) を計算します。
4. 256 ビットの AES 鍵 k = HKDF-SHA256((s * R)x) を計算します。ここで、(s * R)x は曲線乗算結果の x 座標です。ソルトが指定されていません。
5. URx と LRx を、それぞれビッグ エンディアン形式の Rx の上位 80 ビットと下位 80 ビットとします。同様に、S の USx と LSx を定義します。
6. Compute nonce = LRx || LSx。
7. Compute (m’, tag) = AES-EAX-256-ENC(k, nonce, m)。
8. 信頼できないリモート サービスを介して、所有者に (URx, Sx, m’, tag) を送信します。

EID で暗号化された値の復号

EIK とローテーション期間の指数を所有するオーナーのクライアントは、次のようにメッセージを復号します。

1. URx が与えられた場合、URx の基準となるビーコン時間カウンタ値を取得します。これは、所有者のクライアントが、最近の過去と近い将来のビーコン時間カウンタ値の Rx 値を計算することで行えます。
2. URx のベースとなるビーコン時間カウンタ値が与えられた場合、EID の計算セクションで定義されている r の予測値を計算します。
3. R = r * G を計算し、目撃者から提供された URx の値と一致することを確認します。
4. 曲線方程式に代入し、可能な結果から任意の Sy 値を選択して S = (Sx, Sy) を計算します。
5. k = HKDF-SHA256((r * S)x) を計算します。ここで、(r * S)x は曲線乗算結果の x 座標です。
6. Compute nonce = LRx || LSx。
7. Compute m = AES-EAX-256-DEC(k, nonce, m’, tag)。

ID のローテーション

解決可能な（RPA）または解決不可能な（NRPA）BLE アドレスは、FHN フレームのブロードキャストに使用する必要があります。RPA は LE Audio（LEA）デバイスで必須であり、ボンディングを使用しないロケーター タグを除く他のデバイスでは推奨されます。

ファスト ペアリングの広告、FHN の広告、対応する BLE アドレスは同時にローテーションする必要があります。ローテーションは平均して 1,024 秒ごとに行われます。ビーコンが新しい ID のアドバタイズを開始する正確なタイミングは、ウィンドウ内でランダム化する必要があります。

ローテーション時間をランダム化するおすすめの方法は、次の予測されるローテーション時間（ランダム化が適用されていない場合）に、1 ～ 204 秒の範囲の正のランダム化された時間係数を加算することです。

デバイスが望ましくないトラッキング保護モードの場合、FHN アドバタイズメントの BLE アドレスは固定されるべきですが、FP 非検出可能アドバタイズメント（ファスト ペアリングなど）の RPA はローテーションを続ける必要があります。プロトコルごとに異なるアドレスを使用してもかまいません。

停電からの復旧

一時的な識別子の解決は、広告の配信時のクロック値に強く関連付けられているため、停電が発生した場合にプロバイダがクロック値を復元できることが重要です。プロバイダは、少なくとも 1 日に 1 回は現在のクロック値を不揮発性メモリに書き込み、起動時に NVM をチェックして、初期化に使用できる値があるかどうかを確認することが推奨されます。エフェメラル識別子のリゾルバは、妥当なクロック ドリフトとこの種の電源喪失からの復旧の両方を可能にするのに十分な時間枠で解決を実装します。

解決時間枠は限られているため、プロバイダはクロック ドリフトを最小限に抑えるよう引き続きあらゆる努力を払う必要があります。少なくとも 1 つの追加のクロック同期メソッド（検出不可能な Fast Pair フレームの広告、またはメッセージ ストリームの実装）を実装すべきです。

ファスト ペアリングの実装ガイドライン

このセクションでは、FHN をサポートするプロバイダでの Fast Pair 実装の特別な側面について説明します。

位置情報タグ固有のガイドライン

• プロバイダがペア設定されているが、5 分以内に FHN がプロビジョニングされなかった場合（または、デバイスがペア設定されているが FHN がプロビジョニングされていない状態で OTA アップデートが適用された場合）、プロバイダは工場出荷時の構成に戻り、保存されているアカウント キーをクリアする必要があります。
• プロバイダがペア設定された後、FHN がプロビジョニングされるか 5 分が経過するまで、MAC アドレスを変更してはなりません。
• エフェメラル ID キーがデバイスからクリアされた場合、デバイスは出荷時の設定にリセットし、保存されているアカウント キーもクリアする必要があります。
• プロバイダは、通常の Bluetooth ペア設定の試行を拒否し、Fast Pair のペア設定のみを受け入れる必要があります。
• プロバイダは、デバイスを初期状態にリセットすることなく、ユーザーが一時的に広告を停止できるメカニズム（ボタンの組み合わせを押すなど）を含めなければなりません。
• 電源が切れた後、デバイスは、次の read beacon parameters の呼び出しまで、検出不可能なファスト ペアリング フレームをアドバタイズする必要があります。これにより、Seeker は大きなクロック ドリフトが発生した場合でもデバイスを検出し、クロックを同期できます。
• 検出不可能なファスト ペアリング フレームをアドバタイズする場合、UI の表示を有効にすべきではありません。
• プロバイダが FHN 用にプロビジョニングされている間は、検出可能な Fast Pair フレームをアドバタイズしてはなりません。
• プロバイダは、認証されていない方法で識別情報（名前や識別子など）を公開してはなりません。

Classic Bluetooth デバイス固有のガイドライン

このセクションでは、FHN をサポートする従来の Bluetooth デバイスの特別な側面について説明します。

すでにペア設定されているデバイスの FHN プロビジョニング

シーカーとペア設定したときに FHN のプロバイダが常にプロビジョニングされるわけではなく、しばらくしてからプロビジョニングされます。その場合、プロバイダは GATT 接続の確立に必要な最新の BLE MAC アドレスを持っていない可能性があります。プロバイダは、シーカーがペア設定済みの BLE アドレスを取得するための次の方法のうち少なくとも 1 つをサポートしなければなりません。

• プロバイダは、BLE スキャンを通じてシーカーが BLE アドレスを見つけられるように、Fast Pair アカウント データを定期的にアドバタイズできます。
  このアプローチは、メッセージ ストリームを実装しないプロバイダに適しています。
• プロバイダは、従来の Bluetooth 経由のファスト ペアリング メッセージ ストリームを介してこのデータを提供できます。
  このアプローチは、Bluetooth 経由でシーカーに接続している間、ファスト ペアリング フレームをアドバタイズしないプロバイダに適しています。

両方の方法をサポートすることで、ユーザーが FHN 用にデバイスをプロビジョニングできる可能性が高まります。

ファスト ペアリングのメッセージ ストリーム

プロバイダは、ファスト ペアリング メッセージ ストリームを実装し、それを使用してシーカーにデバイス情報を通知できます。メッセージ ストリームを実装すると、このセクションで説明する特定の機能が有効になります。

プロバイダは、メッセージ ストリームの RFCOMM チャネルが確立されるたびに、デバイス情報メッセージを 1 回送信する必要があります。

ファームウェア バージョン（デバイス情報コード 0x09）と追跡機能

ファームウェア アップデートでプロバイダに FHN サポートが追加されると、接続されたシーカーがユーザーにそのことを通知し、プロビジョニングを提案できます。それ以外の場合、ユーザーは Bluetooth デバイスのリストを手動で開いて FHN プロビジョニングを開始する必要があります。

これを許可するには、プロバイダはファームウェア バージョン プロパティ（コード 0x09）を使用して、ファームウェア バージョンを表す文字列値をレポートする必要があります。また、プロバイダは、ファームウェアの更新による機能の変更をシーカーに通知するプロトコルをサポートする必要があります。

オクテット	データ型	説明	値
0	uint8	デバイス情報イベント	0x03
1	uint8	ファームウェアのバージョン	0x09
2 ～ 3	uint16	追加データ長	varies
var	バイト配列	バージョン文字列	varies

表 11: デバイス情報イベント: ファームウェア バージョンが更新されました。

ケイパビリティ更新リクエスト（0x0601）を受信したとき、プロバイダが FHN トラッキングのサポートを有効にしている場合は、表 12 に示すように応答する必要があります。

オクテット	データ型	説明	値
0	uint8	デバイスの機能の同期イベント	0x06
1	uint8	FHN トラッキング	0x03
2 ～ 3	uint16	追加データ長	0x0007
4	uint8	FHN プロビジョニング状態	プロビジョニングされていない場合は 0x00、いずれかのアカウントによってプロビジョニングされている場合は 0x01
5～10	バイト配列	デバイスの現在の BLE MAC アドレス	varies

表 12: デバイス機能の同期イベント: トラッキング機能を追加。

現在のエフェメラル ID（デバイス情報コード 0x0B）

プロバイダは、FHN 用にプロビジョニングされたときに、現在のエフェメラル識別子（コード 0x0B）を使用して現在の EID とクロック値をレポートし、クロックのずれ（バッテリー切れなどによる）が発生した場合にシーカーを同期できます。そうでない場合、Seeker はこの目的のために、よりコストがかかり信頼性の低い接続を開始します。

オクテット	データ型	説明	値
0	uint8	デバイス情報イベント	0x03
1	uint8	現在のエフェメラル ID	0x0B
2 ～ 3	uint16	追加データ長	0x0018 または 0x0024
4 ～ 7	バイト配列	クロック値	例: 0x13F9EA80
8 - 19 または 31	バイト配列	現在の EID	例: 0x1122334455667788990011223344556677889900

表 13: デバイス情報イベント: クロック同期。

出荷時の設定にリセット

出荷時の設定にリセットをサポートするデバイスの場合: 出荷時の設定にリセットが実行された場合、プロバイダはビーコンの送信を停止し、所有者のアカウントキーを含む、一時的な ID キーと保存されているすべてのアカウントキーを消去しなければなりません。

出荷時の設定にリセットした後（手動またはプログラムによる）、プロバイダはすぐに Fast Pair のアドバタイズを開始してはなりません。これは、ユーザーがデバイスを削除した直後にペア設定フローが開始されるのを防ぐためです。

不審なトラッキングの防止

認定 FHN デバイスは、 望ましくない位置情報トラッカーの検出（DULT）に関するクロス プラットフォーム仕様の実装バージョンの要件も満たさなければなりません。

DULT 仕様に準拠するための FHN 固有の関連ガイドライン:

• FHN 対応デバイスは、付近のデバイス コンソールに登録され、「ハブを探す」機能が有効になっている必要があります。
• デバイスは、アクセサリ情報オペレーションや非所有者コントロールなど、DULT 仕様の実装バージョンで定義されているアクセサリ非所有者サービスと特性を実装しなければなりません。
• DULT 仕様で定義されている下位互換性の期間中、このドキュメントで定義されているアドバタイズ フレームに変更はありません。
• このドキュメントで定義されている「望ましくないトラッキング保護モード」は、DULT 仕様で定義されている「分離状態」にマッピングされます。
• アクセサリ情報オペコードの実装に関するガイドライン:
  • Get_Product_Data は、コンソールから提供されたモデル ID を 8 バイトの要件に合わせてゼロパディングして返す必要があります。たとえば、モデル ID 0xFFFFFF は 0x0000000000FFFFFF として返されます。
  • Get_Manufacturer_Name と Get_Model_Name は、コンソールで提供される値と一致する必要があります。
  • Get_Accessory_Category は、デバイスのタイプに適合するカテゴリが他にない場合、一般的な「位置情報トラッカー」の値を返すことができます。
  • Get_Accessory_Capabilities は、着信音と BLE ID 検索のサポートを示さなければなりません。
  • Get_Network_ID は、Google の識別子（0x02）を返します。
• Get_Identifier オペコードの実装に関するガイドライン:
  • このオペレーションは、ユーザーが「識別」モードを有効にしてから 5 分間のみ有効なレスポンスを返します。このモードを有効にするには、ボタンの組み合わせを押す必要があります。プロバイダがそのモードに入ったことをユーザーに知らせる視覚的または音声的なシグナルが必要です。そのモードを有効にするためのモデル固有の手順は、認証の要件として、また、手順の更新または変更の少なくとも 10 日前に、Google に提供する必要があります。
  • レスポンスは、現在のエフェメラル ID の最初の 10 バイトと HMAC-SHA256(recovery key, the truncated current ephemeral identifier) の最初の 8 バイトを連結した形式で構成されます。
• NFC 経由で ID を実装するためのガイドライン:
  • URL として find-my.googleapis.com/lookup を使用します。
  • e パラメータとして、Get_Identifier 用に作成されたレスポンスを 16 進数でエンコードして使用します。
  • pid パラメータには、Get_Product_Data 用に作成したレスポンスと同じものを 16 進数でエンコードして使用します。
• デバイスには、音を出す機能と着信機能をサポートすることが義務付けられています。DULT 仕様では、ISO 532-1:2017 で定義されているとおり、音発生器は最小 60 Phon のピーク音量を出す必要があります。
• Sound_Start オペコードの実装ガイドライン:
  • このコマンドを実行すると、利用可能なすべてのコンポーネントで着信音が鳴ります。
  • サポートされている最大音量を使用する必要があります。
  • 着信音の推奨時間は 12 秒です。
• 位置情報タグには、デバイスを初期状態にリセットすることなく、ユーザーが一時的に広告を停止できるメカニズム（ボタンの組み合わせを押すなど）を含める必要があります。
  • 無効化の手順は、一般公開されている URL に記載し、認証の要件として、手順の更新または変更の少なくとも 10 日前までに Google に提供する必要があります。
  • URL はローカライズに対応している必要があります。クライアントに応じて、言語はクエリ パラメータ（「hl=en」）として提供されるか、「accept-language」HTTP ヘッダーを使用して提供されます。

切り替え可能なプロトコルのガイドライン

• 一度に使用できるプロトコルは 1 つのみです。デバイスで同時に動作できるネットワークが 1 つだけであることを確認します。この要件は、さまざまなプロトコル間でユーザーの機密データが混在しないようにするために必要です。
• ハードリセット ワークフローをデバイスに組み込み、ユーザーが別のネットワークでデバイスを再設定できるようにすることが推奨されます。
• デバイスをネットワークに更新するプロセスは、ユーザーフレンドリーで、ネットワーク間で公平である必要があります。ユーザーは、ネットワークのいずれかを優先することなく、使用するネットワークを選択できる必要があります。このフローは Google チームの承認が必要です。

ファームウェア アップデート

OTA アップデートのプロセスと配信は、パートナーが独自のモバイルアプリまたはウェブアプリのワークフローを使用して管理する必要があります。

ファスト ペアリングは、利用可能な OTA アップデートをユーザーに通知する機能に対応しています。このメカニズムを使用するには:

• 最新のファームウェア バージョンは、Nearby Device Console で更新する必要があります。
• コンパニオン アプリは Nearby Device Console で設定する必要があります。ファームウェア更新インテントをサポートする必要があります。
• プロバイダは、ファームウェア リビジョン GATT 特性を実装する必要があります。

トラッキングを防ぐため、ファームウェア リビジョン特性へのアクセスを制限する必要があります。Seeker は、まずこの仕様で定義されているプロビジョニング状態を読み取り、認証鍵を提供してから、ファームウェア リビジョンを読み取ります。この処理は同じ接続で行われます。ファームウェア リビジョンを読み取ろうとしたときに、Provider がペア設定されておらず、同じ接続で認証されたオペレーションが正常に完了していない場合、Provider は認証されていないエラーを返す必要があります。

互換性

Find Hub ネットワークでは、位置情報サービスと Bluetooth をオンにする必要があります。モバイル サービスまたはインターネット接続が必要です。一部の国の Android 9 以降で利用できます（年齢制限あり）。

変更履歴

FHN バージョン	日付	コメント
v1		早期アクセス向けの FHN 仕様の初回リリース。
v1.1	2023 年 2 月	望ましくないトラッキング防止モードのクリアテキスト表示を追加しました。 望ましくないトラッキング保護モードで、着信リクエストの認証をスキップするオプションを追加しました。
v1.2	2023 年 4 月	オーナーの AK の定義を更新しました。 ロケータータグで電源喪失から復元するための推奨事項を追加しました。 MAC アドレスのランダム化に関する説明を追加しました。 望ましくないトラッキング保護モードでの MAC アドレスのローテーションに関する説明を追加しました。 位置情報タグを無効にする方法に関するガイドラインを追加しました。
v1.3	2023 年 12 月	位置情報タグによって公開される識別情報に関する説明を追加しました。 望ましくないトラッキング防止仕様を実装する要件を追加しました。 切り替え可能なプロトコル デバイスのガイドラインを追加しました。