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

v1.3

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

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

GATT 仕様

次のセマンティクスで、追加の汎用属性（GATT）特性をファスト ペアリング サービスに追加する必要があります。

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

表 1: FHN のファスト ペアリング サービスの特性。

認証

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

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

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

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

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

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

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

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

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

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

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

• 望ましくないトラッキング防止キー: 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: なし 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: 着信音状態の変更以外のデータ 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 バイトとして定義されます。

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

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

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

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

オクテット	データ型	説明	値
0 <0x0	uint8	プロビジョニング状態	次の値を持つビットマスク: ビット 1（0x01）: デバイスにエフェメラル ID 鍵が設定されている場合に設定します。 ビット 2（0x02）: 提供された 1 回限りの認証キーが所有者アカウント キーと一致する場合に設定します。
1 ～ 20 または 32	バイト配列	現在のエフェメラル ID	ビーコンがアドバタイズする現在の一時 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 フレームのブロードキャストを停止します。プロバイダは、表 6 のレスポンスでデータ ID 0x03 を使用して通知します。認証セグメントは、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 のローテーションで説明されているように、すべての識別子をローテーションする必要があります。デバイスを探すハブサービスは、デバイスを探すハブネットワークを介して望ましくないトラッキング保護モードの有効化リクエストを中継できます。これにより、プロバイダは一時的に固定 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 アプリがインストールされており、高精度測位機能が有効になっているデバイスです。イニシエータは、別のデバイスを検索しようとしているデバイスです。

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

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

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

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

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

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

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

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

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

表 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	バイト配列	追加データ	Ranging: Out-of-band message sequence and payload 仕様で定義されている Ranging Configuration メッセージ（ヘッダーとペイロードの両方）

表 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	バイト配列	追加データ	Ranging: Out-of-band message sequence and payload 仕様で定義されている Stop Ranging メッセージ（ヘッダーとペイロードの両方）

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

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

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

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

表 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 の測距開始 API と測距停止 API を明示的に呼び出す必要がある UWB とは異なり、CS では、イニシエータ デバイスのみが Bluetooth スタックを呼び出して CS 測距を開始する必要があります。レスポンダ側の残りの初期化は、Bluetooth（BT）を使用してインバンドで行われます。つまり、CS の測距構成メッセージまたは測距停止メッセージを受信すると、レスポンダ側は、測距構成レスポンス メッセージ通知で応答する以外に、BT が有効になっている場合は何もする必要はありません。レスポンダ デバイスは、これらのメッセージをトリガーとして使用して、画面がある場合は 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 つのファスト ペアリング アドバタイズと 1 つの FHN アドバタイズをアドバタイズする必要があります。

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

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

FHN フレームは、クラウドソーシング ネットワークに貢献するサポート対象のクライアントが位置情報レポートの暗号化に使用する公開鍵を伝送します。2 種類の楕円曲線鍵（従来の BLE 4 フレームに適合する 160 ビット鍵、または拡張アドバタイズ機能付きの 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. コンピューティング S = s * G。
3. 曲線方程式に代入し、可能な結果から任意の Ry 値を選択して R = (Rx, Ry) を計算します。
4. (s * R)x が曲線乗算結果の x 座標である 256 ビットの AES 鍵 k = HKDF-SHA256((s * R)x) を計算します。ソルトは指定されていません。
5. URx と LRx を、それぞれビッグ エンディアン形式の Rx の上位 80 ビットと下位 80 ビットとします。同様に、S に対して USx と LSx を定義します。
6. コンピューティング nonce = LRx || LSx。
7. コンピューティング (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. コンピューティング nonce = LRx || LSx。
7. コンピューティング 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 をサポートするプロバイダでのファスト ペアリング実装の特別な側面について説明します。

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

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

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

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

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

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

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

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

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

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

プロバイダは、メッセージ ストリームが確立されるたびに 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 用にプロビジョニングされている場合に、現在のエフェメラル ID（コード 0x0B）を使用して、現在の EID とクロック値をレポートし、クロックのドリフト（バッテリー切れなど）が発生した場合にシーカーを同期できます。そうしないと、シーカーはこの目的のために、コストが高く信頼性の低い接続を開始します。

オクテット	データ型	説明	値
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 に登録され、「Find Hub」機能が有効になっている必要があります。
• デバイスは、アクセサリ情報オペレーションや非所有者コントロールなど、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 分間のみ有効なレスポンスを返す必要があります。このモードを有効にするには、ボタンの組み合わせを押す必要があります。プロバイダがこのモードに入ったことを示す視覚的または音声的なシグナルをユーザーに表示する必要があります。このモードを有効にするモデル固有の手順は、認証の要件として Google に提供する必要があり、手順の更新または変更の少なくとも 10 日前までに提供する必要があります。
  • レスポンスは、現在のエフェメラル 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 は、まずこの仕様で定義されているプロビジョニング状態を読み取り、認証鍵を提供してから、ファームウェア リビジョンを読み取ります。この処理は同じ接続で行われます。ファームウェア リビジョンを読み取ろうとしたときに、プロバイダがバインドされておらず、同じ接続で認証されたオペレーションが正常に完了していない場合、プロバイダは認証されていないエラーを返す必要があります。

互換性

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

変更履歴

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