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

v1.3

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

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

GATT 仕様

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

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

表 1: FMDN の高速ペア設定サービスの特性

認証

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

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

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

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

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

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

  • 初回ペア設定時に 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 に記載されています。各オペレーションについては、このセクションの後半で詳しく説明します。

Octet	データ型	説明	値
0	uint8	データ ID	0x00: ビーコン パラメータの読み取り 0x01: プロビジョニングの状態を読み取る 0x02: エフェメラル ID キーを設定 0x03: エフェメラル ID キーを消去
1	uint8	データ長	変動あり
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 - 変数	バイト配列	追加データ	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: ビーコンのプロビジョニング リクエスト。

Octet	データ型	説明	値
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: ビーコンのプロビジョニング キーの復元リクエスト。

Octet	データ型	説明	値
0	uint8	データ ID	0x05: リング 0x06: 呼び出し状態の読み取り
1	uint8	データ長	変動あり
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: 着信リクエスト。

Octet	データ型	説明	値
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 が送信される前に送信する必要があります。

Octet	データ型	説明	値
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: エフェメラル ID 鍵である 32 バイト。アカウント鍵で AES-ECB-128 で暗号化されています。 0x05: 新しい状態と変更のトリガーを示す 4 バイト 0x06: アクティブに呼び出しているコンポーネントと呼び出し中の残りのデシ秒数を示す 3 バイト その他のデータ ID が空の追加データを使用している

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

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

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

表 7: GATT エラーコード

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

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

検証に失敗した場合、プロバイダは未認証のエラーを返します。

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

Octet	データ型	説明	値
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 のリクエストで構成される特性への書き込みオペレーションを実行することで、プロバイダにビーコンのプロビジョニング ステータスをクエリできます。プロバイダは、提供されたワンタイム認証キーが、デバイスに保存されているアカウントキーのいずれかと一致することを確認します。

検証に失敗した場合、プロバイダは未認証のエラーを返します。

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

Octet	データ型	説明	値
0	uint8	プロビジョニングのステータス	次の値を持つビットマスク: ビット 1（0x01）: デバイスにエフェメラル ID キーが設定されている場合に設定されます。 ビット 2（0x02）: 指定されたワンタイム認証キーがオーナー アカウント キーと一致する場合に設定されます。
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 キーを設定する

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

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

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

成功すると、一致したアカウント鍵を使用して AES-ECB-128 が復号し、エフェメラル ID キーを復元します。鍵はデバイスに保持され、その時点でプロバイダは FMDN フレームのアドバタイズを開始する必要があります。新しいエフェメラル 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 のリクエストで構成される、特性への書き込みオペレーションを実行します。プロバイダは以下を確認します。

• 提供された 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 バイトとして定義されます。

着信音の操作

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

Octet	データ型	説明	値
0	uint8	リング オペレーション	次の値を持つビットマスク。 ビット 1（0x01）: 右側に鳴らす ビット 2（0x02）: 左を鳴らす ビット 3（0x04）: リングケース 0xFF: すべてのコンポーネントを鳴らす 0x00: 着信音を停止
1 ～ 2	uint16	タイムアウト	10 進数のタイムアウト。0 以外で、10 分を超えないようにする必要があります。 プロバイダは、この値を使用して、サイレントになるまでの着信音の長さを決定します。デバイスのいずれかのコンポーネントがすでに鳴っている場合、タイムアウトはすでに有効になっているタイムアウトをオーバーライドします。 [呼び出し音動作] が 0x00 に設定されている場合、タイムアウトは無視されます。
3	uint8	ボリューム	0x00: デフォルト 0x01: 低 0x02: 中程度 0x03: 高 これらの値の正確な意味は実装によって異なります。

リクエストを受け取ると、プロバイダは以下を確認します。

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

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

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

Octet	データ型	説明	値
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 のレスポンスを返します。プロバイダは、次のようにデータセグメントを構築します。

Octet	データ型	説明	値
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 のリクエストで構成される、特性への書き込みオペレーションを実行します。

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

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

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

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

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

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

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

• 指定されたワンタイム認証キーが、不要なトラッキング防止キーと一致している。
• ハッシュされたエフェメラル 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 バイトとして定義されます。

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

プロビジョニング後、プロバイダは FMDN フレームを 2 秒に 1 回以上アドバタイズすることが求められます。ファスト ペアリング フレームがアドバタイズされる場合、プロバイダは通常のファスト ペアリング アドバタイズ内に FMDN フレームをインターリーブする必要があります。たとえば、プロバイダは 2 秒ごとに 7 つのファスト ペアリング アドバタイズと 1 つの FMDN アドバタイズをアドバタイズする必要があります。

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

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

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

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

Octet	値	説明
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 ビット カーブのバイト オフセットと値を示します。

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

表 9: 256 ビット曲線をサポートする FMDN フレーム

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

ランダムな ID 鍵で次のデータ構造を暗号化する AES-ECB-256 によって、ランダムが生成されます。

Octet	フィールド	説明
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 に設定されています。

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

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

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 を使用した暗号化と復号の詳細は、仕様の完全性を確保するためにのみ記載されています。これらはシーカーのみが実装し、プロバイダは実装しません。

メッセージ 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 はローテーションを継続する必要があります。プロトコルごとに異なるアドレスを使用できます。

停電からの復旧

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

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

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

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

ロケータータグ固有のガイドライン

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

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

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

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

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

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

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

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

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

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

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

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

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

Octet	データ型	説明	値
0	uint8	デバイス情報イベント	0x03
1	uint8	ファームウェアのバージョン	0x09
2 ～ 3	uint16	追加データ長	場合によって異なる
var	バイト配列	バージョン文字列	変動あり

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

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

Octet	データ型	説明	値
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 とクロック値を報告し、バッテリー切れなどの原因でクロックがずれた場合にシーケアを同期できます。それ以外の場合は、シーカーは、この目的のためにより高価で信頼性の低い接続を開始します。

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

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

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

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

手動またはプログラムによる出荷時設定へのリセット後、プロバイダは、ユーザーがデバイスを削除した直後にペア設定フローが開始することを防ぐため、すぐにファスト ペアリングの広告を開始しないでください。

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

認定された FMDN デバイスは、 不要なロケーション トラッカーの検出（DULT）に関するクロス プラットフォーム仕様の実装バージョンの要件も満たす必要があります。

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

• FMDN 対応デバイスは、Nearby Device Console に登録し、「デバイスを探す」機能を有効にする必要があります。
• デバイスは、アクセサリ情報オペレーションや所有者以外のコントロールなど、DULT 仕様の実装バージョンで定義されているアクセサリ所有者以外のサービスと特性を実装する必要があります。
• DULT 仕様で定義されている下位互換性の期間中、このドキュメントで定義されているようにアドバタイズされたフレームに変更はありません。
• このドキュメントで定義されている「望ましくないトラッキング防止モード」は、DULT 仕様で定義されている「分離状態」に対応しています。
• アクセサリ情報オペコードを実装するためのガイドライン:
  • Get_Product_Data は、コンソールから提供されたモデル ID を返します。この 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 に提供する必要があります。
  • レスポンスは、現在のエフェメラル識別子の最初の 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 進数でエンコード）を使用します。
• Sound_Start オペコードを実装するためのガイドライン:
  • このコマンドを実行すると、利用可能なすべてのコンポーネントで着信音が鳴ります。
  • サポートされている最大ボリュームを使用する必要があります。
  • 着信音の推奨時間は 12 秒です。
• ロケータ タグには、ユーザーがデバイスを出荷時の設定にリセットせずに広告を一時的に停止できるメカニズム（ボタンの組み合わせを押すなど）を含める必要があります。
  • 無効化の手順は、一般公開されている URL に記載し、認証の要件として Google に提供する必要があります。また、無効化の手順は、その手順を更新または変更する少なくとも 10 日前までに提示する必要があります。
  • URL はローカライズをサポートする必要があります。言語は、クライアントに応じて、クエリ パラメータ（「hl=ja」）または「accept-language」HTTP ヘッダーを使用して指定します。

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

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

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

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

互換性

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

変更履歴

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