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

v1.3

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

注: 位置情報タグまたは非聴覚デバイスを Find Hub ネットワーク アクセサリと統合することに関心がある場合は、Find Hub デバイス提案フォームに記入してください。オーバーイヤー ヘッドフォンまたは TWS ヘッドフォンに Find Hub のサポートを追加することに関心がある場合は、代わりにファスト ペアリングのデバイス提案フォームにご記入ください。

GATT 仕様

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

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

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

認証

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

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

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

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

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

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

  • 初回ペア設定時に 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: n/a 0x01: n/a 0x02: アカウント鍵で AES-ECB-128 暗号化されたエフェメラル ID 鍵である 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: ユーザーの同意を得て一時的な ID 鍵を読み取るの書き込みリクエストに対するレスポンスとして返されます。

表 7: GATT エラーコード。

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

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

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

成功すると、プロバイダはデータ 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 バイトとして定義されます。

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

シーカーは、表 2 のデータ ID 0x01 のリクエストで構成される特性に書き込みオペレーションを実行することで、プロバイダにビーコンのプロビジョニング状態をクエリできます。プロバイダは、提供された 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 バイトとして定義されます。

着信音の操作

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

オクテット	データ型	説明	値
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: Started（開始）もしくは 0x04: Stopped（停止）（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 回に減らす必要があります。アドバタイズされる一時的な識別子は、通常どおりローテーションを続ける必要があります。フレームタイプは 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 バイトとして定義されます。

高精度検出機能

このセクションでは、正確な検索に必要なフローと追加のオペレーションについて詳しく説明します。GATT 仕様のセクションで定義されているように、GATT 特性と認証に関する同じルールがここでも適用されます。「探す」機能はオプションです。

高精度検索の種類は、高精度検索に関与するデバイスでサポートされている測距テクノロジーの種類によって異なります。サポートされている測距テクノロジーについては、測距: 帯域外メッセージ シーケンスとペイロードの仕様をご覧ください。以降のセクションでは、使用される測距テクノロジーに基づいて、どのような精度の高い検索エクスペリエンスが期待できるかについて説明します。

高精度検出機能のフロー

このセクションでは、高精度測位の FHNA メッセージ フローについて説明します。図 1 はメッセージのフローを示しており、各メッセージについては段落で詳しく説明しています。

図 1: 一般的な高精度測位のメッセージ フロー

イニシエーター デバイスは、Find Hub アプリがインストールされており、高精度測位機能が有効になっているデバイスです。イニシエータは、別のデバイスを検索しようとしているデバイスです。

レスポンダー デバイスは、イニシエーター デバイスによって検出されようとしているデバイスです。

イニシエータ デバイスは、レンジング機能リクエスト メッセージをレスポンダ デバイスに送信します。このメッセージには、レスポンダ デバイスから知りたいレンジング技術がリストされます。レスポンダー デバイスは、どの測距テクノロジーがサポートされているか、その機能は何かに関する情報を含む測距機能レスポンス通知で応答します。レスポンダーは、イニシエータがリクエストした情報のみを含めます。機能のリストは、レスポンダー デバイスが優先する測距テクノロジーの優先度に基づいて並べ替えられます。リストの先頭の機能が最も優先度が高くなります。

イニシエータ デバイスは、レンジング構成メッセージでフォローアップします。このメッセージで、レンジングに使用する各レンジング テクノロジーの構成を定義します。このメッセージを受信すると、レスポンダー デバイスは、提供された構成を使用して、該当するテクノロジーの測距を開始する必要があります。レスポンダー デバイスは、各個別の測距テクノロジーが正常に開始されたかどうかの結果を含む、測距構成レスポンス通知を返送します。一部の測距テクノロジーでは、測距セッションを成功させるために、イニシエータ デバイスとレスポンダ デバイスの両方で開始する必要があります。一方、イニシエータ デバイスでのみ開始すればよいテクノロジーもありますが、そのようなテクノロジーでも、レスポンダ デバイスは成功結果を返信する必要があります。特定の測距技術の動作については、後述のセクションで詳しく説明します。

イニシエータ デバイスが Precision Finding セッションを停止する準備ができたら、レスポンダに Stop Ranging メッセージを送信し、どの測距テクノロジーが測距を停止しなければならないかを示します。Responder デバイスは、Stop Ranging Response 通知で応答します。これは、リクエストされた測距テクノロジーによる測距が正常に停止したことを示します。

FHNA BLE GATT 通信チャネルが Precision Finding セッションの途中で切断されたが、一部の測距テクノロジーがまだ測距している場合、レスポンダー デバイスはタイムアウト メカニズムを実装して、無期限に測距しないようにします。詳細はユースケースによって異なります。

なお、レスポンダー デバイスは、オペレーションの順序が常に同じであると想定してはなりません。たとえば、レスポンダー デバイスは、複数の Ranging Capability リクエスト オペレーションを連続して処理できる必要があります。また、先行するケーパビリティ リクエストなしで直接 Ranging Configuration オペレーションを処理できる必要があります。

高精度検出機能のオペレーション

表 8 に、このドキュメントで定義され、高精度測位に必要な FHNA オペレーションを示します。各サブセクションでは、各オペレーションの FHNA メッセージを定義します。一方、追加データ フィールドの内容は、測距: 帯域外メッセージ シーケンスとペイロード仕様を参照します。

オペレーション	データ ID	説明
測距機能のリクエスト	0x0A	イニシエータ デバイスからレスポンダ デバイスに送信されるケーパビリティ リクエスト オペレーション。このオペレーションのデータ コンテンツには、イニシエータがレスポンダ デバイスから知りたいすべての測距テクノロジーがリストされます。
距離測定機能のレスポンス	0x0A	これは、Ranging Capability Request オペレーションに対する通知レスポンスです。これには、イニシエータによってリクエストされた、サポートされている各測距テクノロジーの機能に関する情報が含まれます。
測距構成	0x0B	Ranging Configuration オペレーションには、イニシエータ デバイスがレスポンダー デバイスとの距離測定を開始するために必要な距離測定テクノロジーの構成が含まれます。
Ranging Configuration Response	0x0B	これは、Ranging Configuration オペレーションに対する通知レスポンスです。提供された構成に基づいて、Responder デバイスがリクエストされた測距テクノロジーで測距を正常に開始したかどうかに関するデータが含まれます。
RFU	0x0C	このデータ ID を使用するオペレーションは使用されず、将来の使用のために予約されています。
Stop Ranging	0x0D	イニシエータ デバイスから送信される Stop Ranging オペレーションには、レスポンダー デバイスが測距を停止する必要がある測距テクノロジーに関する情報が含まれています。
Stop Ranging Response	0x0D	これは、Stop Ranging オペレーションに対する通知レスポンスです。特定の測距テクノロジーの停止オペレーションが成功したかどうかを示すデータが含まれます。

表 8: 高精度測位オペレーション。

Ranging Capability Request オペレーション

表 9 は、Ranging Capability Request メッセージを定義します。

オクテット	データ型	説明	値
0	uint8	データ ID	0x0A - 距離測定機能リクエスト オペレーション
1	uint8	データ長	可変
2	バイト配列	ワンタイム認証キー	HMAC-SHA256(アカウント キー、プロトコルのメジャー バージョン番号 || 特性から読み取られた最後のノンス || データ ID || データ長 || 追加データ) の最初の 8 バイト。
10	バイト配列	追加データ	測距: 帯域外メッセージ シーケンスとペイロード仕様で定義されている測距機能リクエスト メッセージ（ヘッダーとペイロードの両方）

表 9: 距離測定機能のリクエスト。

Ranging Capability Response オペレーション

表 10 は、Ranging Capability Response メッセージを定義しています。

オクテット	データ型	説明	値
0	uint8	データ ID	0x0A: 測距機能のレスポンス
1	uint8	データ長	可変
2	バイト配列	ワンタイム認証キー	HMAC-SHA256(アカウントキー, プロトコルのメジャー バージョン番号 || 特性から読み取られた最後のノンス || データ ID || データ長 || 追加データ || 0x01) の最初の 8 バイト。
10	バイト配列	追加データ	測距: 帯域外メッセージ シーケンスとペイロード仕様で定義されている測距機能レスポンス メッセージ（ヘッダーとペイロードの両方）

表 10: 測距機能のレスポンス。

Ranging Configuration オペレーション

表 11 は、Ranging Configuration メッセージを定義しています。

オクテット	データ型	説明	値
0	uint8	データ ID	0x0B - 距離測定構成を設定
1	uint8	データ長	可変
2	バイト配列	ワンタイム認証キー	HMAC-SHA256(アカウント キー、プロトコルのメジャー バージョン番号 || 特性から読み取られた最後のノンス || データ ID || データ長 || 追加データ) の最初の 8 バイト。
10	バイト配列	追加データ	測距: 帯域外メッセージ シーケンスとペイロード仕様で定義されている測距構成メッセージ（ヘッダーとペイロードの両方）

表 11: 測距構成。

Ranging Configuration Response オペレーション

表 12 は、Ranging Configuration Response メッセージを定義します。

オクテット	データ型	説明	値
0	uint8	データ ID	0x0B - 距離測定構成応答を設定
1	uint8	データ長	可変
2	バイト配列	ワンタイム認証キー	HMAC-SHA256(アカウントキー, プロトコルのメジャー バージョン番号 || 特性から読み取られた最後のノンス || データ ID || データ長 || 追加データ || 0x01) の最初の 8 バイト。
10	バイト配列	追加データ	測距: 帯域外メッセージ シーケンスとペイロード仕様で定義されている測距構成レスポンス メッセージ（ヘッダーとペイロードの両方）

表 12: 測距構成レスポンス。

測距オペレーションを停止する

表 13 は、Stop Ranging メッセージを定義しています。

オクテット	データ型	説明	値
0	uint8	データ ID	0x0D - 測距停止
1	uint8	データ長	可変
2	バイト配列	ワンタイム認証キー	HMAC-SHA256(アカウント キー, プロトコルのメジャー バージョン番号 || 特性から読み取られた最後のノンス || データ ID || データ長) の最初の 8 バイト。
10	バイト配列	追加データ	測距: 帯域外メッセージ シーケンスとペイロード仕様で定義されている測距の停止メッセージ（ヘッダーとペイロードの両方）

表 13: 測距を停止します。

測距応答オペレーションを停止する

表 14 は、Stop Ranging Response メッセージを定義しています。

オクテット	データ型	説明	値
0	uint8	データ ID	0x0D - 距離測定停止レスポンス
1	uint8	データ長	可変
2	バイト配列	ワンタイム認証キー	HMAC-SHA256(アカウントキー, プロトコルのメジャー バージョン番号 || 特性から読み取られた最後のノンス || データ ID || データ長 || 追加データ || 0x01) の最初の 8 バイト。
10	バイト配列	追加データ	測距: 帯域外メッセージ シーケンスとペイロード仕様で定義されている測距停止レスポンス メッセージ（ヘッダーとペイロードの両方）

表 14: Stop Ranging Response。

高い検出精度のトラッキング防止機能

望ましくないトラッキング保護モードが有効になっている場合（望ましくないトラッキング保護のセクションで説明）、着信メッセージの認証チェックをスキップする際に適用されるフローと同じフローが、この機能をサポートするデバイス向けにこのドキュメントで定義されているすべての高精度な検出メッセージにも適用されます。

高精度検出機能の測距技術の詳細

このセクションには、測距テクノロジー固有の詳細が含まれています。

超広帯域無線（UWB）の詳細

UWB 固有の詳細。

高精度検出のレベル

測距技術として UWB を使用する高精度検出セッションでは、距離と方向の両方の情報が表示されることが想定されます。測距間隔は 240 ミリ秒以上にする必要があります。最適なガイダンスを得るには 96 ミリ秒が推奨されます。

構成 ID

UWB の帯域外構成データには、UWB 測距セッションを開始するために UWB が必要とする構成可能なパラメータの完全なセットが含まれていません。一部のパラメータは、選択した構成 ID によって暗黙的に選択されます。

各 config Id は、 公開されているドキュメントに記載されている、事前定義された UWB 構成パラメータのセットです。高精度検索のユースケースでは、レスポンダー デバイスは config Id 6 をサポートしている必要があり、オプションで config Id 3 をサポートしている必要があります。

UWB イニシエータとレスポンダ

高精度測位のユースケースでは、このドキュメントでイニシエータ デバイスとして記載されているデバイスが UWB レスポンダとなり、このドキュメントでレスポンダ デバイスとして記載されているデバイスが UWB イニシエータとなります。これは、UWB イニシエータ デバイスの消費電力が UWB レスポンダ デバイスよりも少ないためです。また、ほとんどの場合、レスポンダ デバイスはバッテリーが限られた周辺機器になります。

つまり、レスポンダー デバイスは、レンジング機能レスポンス メッセージで UWB イニシエーター ロールをサポートしていることを示す必要があります。

その他の UWB 関連パラメータ

• チャンネル 9 がサポートされている必要があります
• 最適なガイダンスを得るには、96 ミリ秒の測距間隔が推奨されます。それ以外の場合は、240 ミリ秒をサポートする必要があります。
• バッテリー節約のためには 1 ミリ秒のスロット期間が推奨されますが、2 ミリ秒もサポートされています。
• UWB チップは FIRA v1.2 + P-STS 準拠以上である必要があります。
• BPRF は必須、HPRF は推奨されますが省略可能です。サポートされているモードまたは選択されているモードは、サポートされているプリアンブル インデックスまたは選択されているプリアンブル インデックスによって決定されます。
• セッション セキュリティ タイプ: P-STS

BLE チャンネル サウンディング（CS）の詳細

BLE CS 固有の詳細。

高精度検出のレベル

CS を測距テクノロジーとして使用する高精度検出セッションでは、距離のみが測定されます。現時点では方向は提供されません。

デバイス間のペア設定が必要

デバイスがペア設定されていない場合、チャンネル サウンディングを使用した高精度測位セッションは機能しません。イニシエータとレスポンダ デバイス間の既存のボンドが必要です。この仕様では、デバイス間のボンドを作成する方法は提供されていません。代わりに、デバイス間のこのバインドを確立するのはユースケースのデベロッパーの責任となります。

CS の回答者側で必要な対応

UWB では、両方のデバイスが UWB の距離測定開始 API と距離測定停止 API を明示的に呼び出す必要がありますが、CS では、イニシエータ デバイスのみが Bluetooth スタックを呼び出して CS の距離測定を開始する必要があります。レスポンダー側の残りの初期化は、Bluetooth（BT）を使用してインバンドで行われます。つまり、CS の Ranging Configuration メッセージまたは Stop Ranging メッセージを受信したときに、レスポンダー側は、BT が有効になっている場合は、Ranging Configuration Response メッセージ通知で応答する以外に何もする必要はありません。レスポンダー デバイスは、これらのメッセージをトリガーとして使用して、画面がある場合は UI を更新したり、画面の有無にかかわらず、デバイスの状態に関する視覚的なフィードバック（デバイスの LED の点滅など）に使用したりする可能性があります。

Wi-Fi NAN RTT

Wi-Fi NAN RTT の詳細。

高精度検出のレベル

測距テクノロジーとして Wi-Fi NAN RTT を使用する高精度検出セッションでは、距離のみが測定され、方向は現時点では提供されません。

BLE RSSI

BLE RSSI の詳細。

高精度検出のレベル

BLE RSSI のみを測距技術として使用する高精度測位セッションでは、BLE RSSI は正確な測距技術ではないため、距離情報も方向情報も取得できません。代わりに、デバイスが近いか遠いかを示すガイダンスが表示されます。

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

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

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

注: デバイスが低電力モードの場合でも、FHN フレームをアドバタイズすることをおすすめします。これにより、デバイスを紛失した場合に見つけられるようになります。一部のデバイスでは、バッテリー寿命への影響のため、デバイスの電源がオフのときにアドバタイズできない場合があります。このような場合は、デバイスを定期的に起動して、短時間（10 分ごとに起動して 10 秒間アドバタイズするなど）アドバタイズすることを強くおすすめします。

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

注: 256 ビットキーを使用すると、BLE 5 をサポートしていない古いスマートフォンは、アドバタイズ デバイスをスキャンしてレポートできないため、ネットワークのサイズが縮小されます。

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		ハッシュ化されたフラグ

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

表 16 に、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		ハッシュ化されたフラグ

表 16: 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 個の最下位ビットがクリアされます。

表 17: 疑似乱数の構成。

注: デバイスには秒単位の 32 ビットのタイム カウンタがあると想定されます。

注: ローテーション期間の指数は固定で、1024 秒に対応する 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 による暗号化

注: EID を使用した暗号化と復号化に関する以下の詳細は、仕様の完全性を確保するためにのみ含まれています。これらは Provider ではなく Seeker のみが実装します。

メッセージ 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 のローテーション

アドバタイズ FHN フレームには、解決可能な（RPA）または解決不可能な（NRPA）BLE アドレスを使用する必要があります。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 の呼び出しまで、検出不可能なファスト ペアリング フレームをアドバタイズする必要があります。これにより、大きなクロック ドリフトが発生した場合でも、シーカーはデバイスを検出してクロックを同期できます。
• 検出不可能なファスト ペアリング フレームをアドバタイズする場合、UI の表示を有効にすべきではありません。
• プロバイダが FHN 用にプロビジョニングされている間は、検出可能な Fast Pair フレームをアドバタイズすべきではありません。
• プロバイダは、認証されていない方法で識別情報（名前や識別子など）を公開してはなりません。

クラシック Bluetooth デバイス固有のガイドライン

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

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

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

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

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

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

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

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

ファームウェア バージョン（デバイス情報コード 0x09）とトラッキング機能

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

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

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

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

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

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

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

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

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

オクテット	データ型	説明	値
0	uint8	デバイス情報イベント	0x03
1	uint8	現在の一時的な識別子	0x0B
2 ～ 3	uint16	追加データ長	0x0018 または 0x0024
4 - 7	バイト配列	クロック値	例: 0x13F9EA80
8 - 19 または 31	バイト配列	現在の EID	例: 0x1122334455667788990011223344556677889900

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

出荷時の設定にリセット

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

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

望ましくないトラッキングの防止

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

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

• FHN 対応デバイスは、Nearby Device Console に登録され、「ハブを探す」機能が有効になっている必要があります。
• デバイスは、アクセサリ情報オペレーションや非所有者コントロールなど、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 月	位置情報タグによって公開される個人情報の特定に関する説明を追加しました。 望ましくないトラッキング防止仕様を実装する要件を追加しました。 切り替え可能なプロトコル デバイスのガイドラインを追加しました。