「デバイスを探す」ネットワーク アクセサリの仕様

v1.3

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

注: 「デバイスを探す」アクセサリの仕様を統合する場合は、デバイスの提案フォームを送信してください。統合手順と認定に関する詳細は近日公開予定です。

GATT 仕様

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

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

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

認証

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

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

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

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

• アカウント キー: ファスト ペアリング仕様で定義されている 16 バイトのファスト ペアリング アカウント キー。

• 所有者アカウント キー: シーカーがビーコン アクション特性に初めてアクセスしたときに、プロバイダは既存のアカウント キーのいずれかを所有者アカウント キーとして選択します。選択した所有者アカウント キーは、プロバイダを工場出荷時の設定にリセットするまで変更できません。無料のアカウント キー スロットが不足している場合、プロバイダはオーナー アカウント キーを削除できません。

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

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

• エフェメラル ID キー（EIK）: FMDN プロビジョニング プロセスの実行時にシーカーがランダムに選択する 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	データ長	変動あり
2 ～ 9	バイト配列	1 回限りの認証キー	HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data) の最初の 8 バイト
10 - var	バイト配列	追加データ	0x00: なし 0x01: なし 0x02: 32 バイトのエフェメラル ID 鍵。アカウント鍵で AES-ECB-128 で暗号化されています。プロバイダにエフェメラル 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	バイト配列	1 回限りの認証キー	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: リング 0x06: 着信状態の読み取り
1	uint8	データ長	変動あり
2 ～ 9	バイト配列	1 回限りの認証キー	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	データ長	変動あり
2 ～ 9	バイト配列	1 回限りの認証キー	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 に示す通知がトリガーされます。

データ ID が 0x05: リングの状態の変化以外の通知は、通知をトリガーする書き込みトランザクションが完了する前に送信する必要があります。つまり、書き込みリクエストのレスポンス PDU が送信される前に送信する必要があります。

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

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

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

コード	説明	メモ
0x80	未認証	認証に失敗した場合（古いノンスが使用された場合を含む）に、書き込みリクエストへの応答として返されます。
0x81	無効な値	無効な値が指定された場合や、受信したデータのバイト数が想定外の場合に返されます。
0x82	ユーザーの同意なし	デバイスがペア設定モードでないときに、データ ID が 0x04: ユーザーの同意を得てエフェメラル ID 鍵を読み取るの書き込みリクエストに応答して返されます。

表 7: GATT エラーコード。

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

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

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

成功すると、プロバイダはテーブル 6 からデータ ID 0x00 のレスポンスを返します。プロバイダは、次のようにデータセグメントを作成します。

オクテット	データ型	説明	値
0	uint8	調整済みの電力	0 m で受信したキャリブレーション済み電力（[-100, 20] の範囲内の値）。1 dBm の解像度で符号付き整数として表されます。
1～4	uint32	時計の値	現在のクロック値（秒単位、ビッグ エンディアン）。
5	uint8	曲線の選択	暗号化に使用される楕円曲線: 0x00（デフォルト）: SECP160R1 0x01: SECP256R1（拡張アドバタイジングが必要）
6	uint8	コンポーネント	着信可能なコンポーネントの数: 0x00: デバイスが着信音を鳴らすことができないことを示します。 0x01: 1 つのコンポーネントのみが着信音を鳴らすことができることを示します。 0x02: 2 つのコンポーネント（左と右のイヤホン）が個別に着信できることを示します。 0x03: 左と右のイヤホンとケースの 3 つのコンポーネントが個別に着信できることを示します。
7	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 回限りの認証キーが、デバイスに保存されているアカウント キーのいずれかと一致することを検証します。

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

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

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

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

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

プロビジョニングされていないプロバイダを FMDN ビーコンとしてプロビジョニングする場合、またはすでにプロビジョニングされているプロバイダのエフェメラル ID キーを変更する場合、シーカーは、データ ID 0x02 の表 2 のリクエストで構成される特性への書き込みオペレーションを実行します。プロバイダは、次のことを確認します。

• 提供された 1 回限りの認証キーが所有者のアカウント キーと一致している。
• エフェメラル ID キーのハッシュが指定されている場合、ハッシュ化されたエフェメラル ID キーは現在のエフェメラル ID キーと一致します。
• エフェメラル ID 鍵のハッシュが指定されていない場合は、プロバイダが FMDN ビーコンとしてプロビジョニングされていないことを確認します。

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

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

認証セグメントは、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 からのリクエストで構成される、特性への書き込みオペレーションを実行します。プロバイダは、次のことを確認します。

• 提供された 1 回限りの認証キーが所有者のアカウント キーと一致している。
• ハッシュ化されたエフェメラル ID 鍵が現在のエフェメラル ID 鍵と一致している。

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

成功すると、プロバイダはキーを削除し、FMDN フレームのアドバタイズを停止します。プロバイダは、表 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 キーを読み取る

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

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

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

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

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

デバイスがペア設定モードでない場合は、プロバイダはユーザーの同意なしのエラーを返します。

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

認証セグメントは、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	uint8	リングの操作	次の値を持つビットマスク。 ビット 1（0x01）: 右側を鳴らす ビット 2（0x02）: 左を鳴らす ビット 3（0x04）: リングケース 0xFF: すべてのコンポーネントを鳴らす 0x00: 着信音を停止
1 ～ 2	uint16	タイムアウト	タイムアウト（デシ秒単位）。0 以外で、10 分を超えないようにしてください。 プロバイダは、この値を使用して、サイレントになるまでの着信音の長さを決定します。デバイスのコンポーネントがすでに鳴っている場合、タイムアウトはすでに有効になっているタイムアウトをオーバーライドします。 リング オペレーションが 0x00 に設定されている場合、タイムアウトは無視されます。
3	uint8	ボリューム	0x00: デフォルト 0x01: 低 0x02: 中程度 0x03: 高 これらの値の正確な意味は実装によって異なります。

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

• 提供された 1 回限りの認証キーがリングキーと一致している。
• リクエストされた状態が、着信できるコンポーネントと一致している。

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

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

オクテット	データ型	説明	値
0	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 からのリクエストで構成される、特性への書き込みオペレーションを実行します。プロバイダは、提供された 1 回限りの認証キーがリングキーと一致することを確認します。

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

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

オクテット	データ型	説明	値
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 のローテーションで説明されているように、すべての ID をローテーションする必要があります。「デバイスを探す」サービスは、「デバイスを探す」ネットワークを介して、望ましくないトラッキング保護モードの有効化リクエストをリレーできます。これにより、サービスはプロバイダが一時的に固定 MAC アドレスを使用するようにします。これにより、クライアントはデバイスを検出し、望ましくない追跡の可能性についてユーザーに警告できます。

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

望ましくないトラッキング防止モードを有効にするとき

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

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

プロバイダは、提供された 1 回限りの認証キーが望ましくないトラッキング防止キーと一致することを確認します。プロバイダが FMDN ビーコンとしてプロビジョニングされていない場合や検証に失敗した場合は、未認証のエラーが返されます。

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

不要なトラッキング防止モードを無効にするとき

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

• 指定された 1 回限りの認証キーが、望ましくないトラッキング防止キーと一致している。
• ハッシュ化されたエフェメラル ID 鍵が現在のエフェメラル ID 鍵と一致している。

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

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

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

認証セグメントは、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 回以上 FMDN フレームをアドバタイズする必要があります。ファスト ペアリング フレームがアドバタイズされる場合、プロバイダは通常のファスト ペアリング アドバタイズ内に FMDN フレームをインターリーブする必要があります。たとえば、プロバイダは 2 秒ごとに 7 つの Fast Pair アドバタイズと 1 つの FMDN アドバタイズをアドバタイズする必要があります。

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

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

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

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

FMDN フレームの構造は次のとおりです。

オクテット	値	説明
0	0x02	長さ
1	0x01	フラグのデータ型の値
2	0x06	フラグデータ
3	0x18 または 0x19	長さ
4	0x16	サービスデータのデータ型の値
5	0xAA	16 ビットのサービス UUID
6	0xFE	...
7	0x40 または 0x41	望ましくないトラッキング防止モードの表示がある FMDN フレームタイプ
8..27		20 バイトのエフェメラル ID
28		ハッシュ化されたフラグ

表 8: 160 ビット カーブをサポートする FMDN フレーム。

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

オクテット	値	説明
0	0x02	長さ
1	0x01	フラグのデータ型の値
2	0x06	フラグデータ
3	0x24 または 0x25	長さ
4	0x16	サービスデータのデータ型の値
5	0xAA	16 ビットのサービス UUID
6	0xFE	...
7	0x40 または 0x41	望ましくないトラッキング防止モードの表示がある FMDN フレームタイプ
8..39		32 バイトのエフェメラル ID
40		ハッシュ化されたフラグ

表 9: 256 ビット カーブをサポートする FMDN フレーム。

エフェメラル ID（EID）の計算

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

オクテット	フィールド	説明
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: 疑似乱数を生成する。

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

注: 回転周期指数は固定され、1024 秒に相当する 10 に設定されています。

この計算の結果は 256 ビットの数値（r'）です。

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

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

ハッシュ化されたフラグ

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

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

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

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

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

EID による暗号化

注: EID を使用した暗号化と復号の詳細は、仕様の完全性を確保するためにのみ記載されています。これらの設定は、提供者ではなく、求職者のみによって実装されます。

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

1. EID の計算セクションで定義されているように、Fp で乱数 s を選択します。
2. 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. 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 のローテーション

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

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

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

デバイスが望ましくないトラッキング防止モードの場合、FMDN アドバタイズメントの BLE アドレスは固定する必要がありますが、FP の検出不能なアドバタイズメント（ファスト ペアリングなど）の RPA はローテーションを継続する必要があります。プロトコルごとに異なるアドレスを使用できます。

停電からの復旧

エフェメラル識別子の解決は、広告掲載時のクロック値に強く関連しているため、電源が切れた場合にプロバイダがクロック値を復元できるようにすることが重要です。プロバイダは、現在のクロック値を 1 日 1 回以上不揮発性メモリに書き込むことをおすすめします。また、起動時にプロバイダが NVM をチェックして、初期化する値が存在するかどうかを確認することをおすすめします。エフェメラル識別子のリゾルバは、妥当なクロック ドリフトとこのタイプの電源喪失復旧の両方を許容するのに十分な時間枠で解決を実装します。

解決時間の制限があるため、プロバイダはクロックのずれを最小限に抑えるよう努める必要があります。少なくとも 1 つの追加クロック同期方法を実装する必要があります（検出不能な Fast Pair フレームのアドバタイズ、またはメッセージ ストリームの実装）。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

表 13: デバイス情報イベント: 時刻の同期。

出荷時の設定にリセットする

出荷時の設定にリセットできるデバイスの場合: 出荷時の設定にリセットすると、プロバイダはビーコンを停止し、エフェメラル ID 鍵と、所有者のアカウント鍵を含むすべての保存済みアカウント鍵を消去する必要があります。

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

不正なトラッキングを防止する

認定 FMDN デバイスは、 望ましくない位置情報トラッカーの検出（DULT）のクロス プラットフォーム仕様の実装バージョンの要件も満たす必要があります。

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

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

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

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

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

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

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

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

トラッキングを防止するには、ファームウェア リビジョン特性へのアクセスを制限する必要があります。シーカーは、まずプロビジョニング状態を読み取り、この仕様で定義されているように認証鍵を提供してから、ファームウェア リビジョンを読み取ります。これは同じ接続で行われ、ファームウェア リビジョンの読み取りが試行され、プロバイダがボンディングされておらず、同じ接続で認証済みオペレーションが正常に完了しなかった場合、プロバイダは未認証のエラーを返す必要があります。

互換性

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

変更履歴

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