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

v1.3

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

GATT の仕様

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

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

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

エネルギー効率比率(EER)

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

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

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

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

Operations

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

オクテット データ型 説明
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: エフェメラル ID 鍵である 32 バイト。アカウントキーで暗号化された 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 バイト配列 ワンタイム認証キー 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 データの長さ 場合によって異なる
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 - 変数 バイト配列 追加データ
  • 0x05: 呼び出し状態、呼び出し時間、音量を示す 4 バイト。
  • 0x06: 該当なし

表 4: 呼び出し中のリクエスト

オクテット データ型 説明
0 uint8 データ ID
  • 0x07: 不要なトラッキング保護モードを有効にする
  • 0x08: 不要なトラッキング保護モードを無効にする
1 uint8 データの長さ 場合によって異なる
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 - 変数 バイト配列 追加データ
  • 0x07: 1 バイトの制御フラグ(省略可)
  • 0x08: SHA256(ephemeral identity key || the last nonce read from the characteristic) の最初の 8 バイト

表 5: 望ましくないトラッキング保護リクエスト

書き込みに成功すると、表 6 に示すように通知がトリガーされます。

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

オクテット データ型 説明
0 uint8 データ ID
  • 0x00: ビーコン パラメータの読み取り
  • 0x01: プロビジョニング状態の読み取り
  • 0x02: エフェメラル ID 鍵を設定する
  • 0x03: エフェメラル ID 鍵を消去
  • 0x04: ユーザーの同意に基づく一時的な ID 鍵の読み取り
  • 0x05: リング状態の変更
  • 0x06: 呼び出し状態の読み取り
  • 0x07: 不要なトラッキング保護モードを有効にする
  • 0x08: 不要なトラッキング保護モードを無効にする
1 uint8 データの長さ 場合によって異なる
2 ~ 9 バイト配列 エネルギー効率比率(EER) オペレーションごとの詳細
10 - 変数 バイト配列 追加データ
  • 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 からのリクエストで構成される特性に対して書き込みオペレーションを実行することにより、プロバイダにビーコンのパラメータを照会できます。プロバイダは、提供されたワンタイム認証キーがデバイスに保存されているアカウントキーのいずれかと一致することを確認します。

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

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

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

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

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

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

オクテット データ型 説明
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 キーを変更するには、シーカーはテーブル 2 からのデータ ID 0x02 のリクエストで構成される特性への書き込みオペレーションを実行します。プロバイダは、以下を確認します。

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

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

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

  • 指定されたワンタイム認証キーが、オーナー アカウント キーと一致している。
  • ハッシュ化されたエフェメラル 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 を読み取るために、シーカーは特性への書き込みオペレーションを実行します。書き込みオペレーションは、テーブル 3 からのデータ ID 0x04 のリクエストで構成されます。プロバイダは、次のことを確認します。

  • ハッシュ化された復旧キーが、想定される復旧キーと一致すること。
  • デバイスが 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 からのリクエストで構成される特性への書き込みオペレーションを実行して、音声の再生をプロバイダに要求できます。プロバイダは、次のようにデータ セグメントを構成します。

オクテット データ型 説明
0 uint8 呼び出し操作 次の値を持つビットマスク:
  • ビット 1(0x01): 右をリング
  • ビット 2(0x02): 左を鳴らす
  • ビット 3(0x04): リングケース
  • 0xFF: すべてのコンポーネントを鳴らす
  • 0x00: 着信音を停止
1 ~ 2 uint16 タイムアウト タイムアウト(デシ秒)。ゼロにはできません。また、10 分以下の値にする必要があります。
プロバイダはこの値を使用して、自身を消音にするまでの時間を決定します。デバイスのいずれかのコンポーネントがすでに鳴っている場合は、タイムアウトによってすでに有効なタイムアウトがオーバーライドされます。

リング オペレーションが 0x00 に設定されている場合、タイムアウトは無視されます。
3 uint8 ボリューム
  • 0x00: デフォルト
  • 0x01: 低
  • 0x02: 中
  • 0x03: 高
これらの値の正確な意味は、実装によって異なります。

リクエストを受領したプロバイダは、以下を確認します。

  • 指定されたワンタイム認証鍵がリング鍵と一致する。
  • リクエストされた状態が、呼び出し可能なコンポーネントと一致している。

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

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

不要なトラッキング防止モードを有効にした場合

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

オクテット データ型 説明
0 uint8 コントロール フラグ
  • 0x01: 認証の着信音をスキップします。設定すると、望ましくないトラッキング保護モードでは、呼び出し中のリクエストは認証されません。
フラグが設定されていない場合(バイトがすべてゼロの場合)は、データ セクションを完全に省略して空のデータ セクションを送信できます。
このフラグは、不要なトラッキング保護モードが無効になるまで有効です。

プロバイダは、提供された 1 回限りの認証キーが不要なトラッキング保護キーと一致することを確認します。プロバイダが 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 フレームは、クラウドソーシング ネットワークに貢献するサポート クライアントによる位置情報レポートの暗号化に使用される公開鍵を保有します。楕円曲線キーには、従来の BLE 4 フレームに適合する 160 ビットキーと、拡張アドバタイジング機能を備えた BLE 5 を必要とする 256 ビットキーの 2 種類があります。プロバイダの実装により、使用する曲線が決まります。

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 フレーム

エフェメラル識別子(EID)の計算

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

オクテット 項目 説明
0 ~ 10 パディング 値 = 0xFF
11 K 回転期間の指数
12 ~ 15 TS[0]...TS[3] ビーコン時間カウンタ(32 ビット ビッグ エンディアン形式)。下位 K 個のビットがクリアされます。
16 ~ 26 パディング 値 = 0x00
27 K 回転期間の指数
28 ~ 31 TS[0]...TS[3] ビーコン時間カウンタ(32 ビット ビッグ エンディアン形式)。下位 K 個のビットがクリアされます。

表 10: 擬似乱数の構成。

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

残りの計算では、SECP160R1 または SECP256R1 が楕円曲線暗号オペレーションに使用されます。次に参照する FpnG を定義する、 SEC 2: Recommended Elliptic Curve Domain Parameters の曲線の定義をご覧ください。

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

ハッシュされたフラグ

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

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

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

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

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

EID による暗号化

メッセージ m を暗号化するために、訪問者(ビーコンから Rx を読み取った人)は次のことを行います。

  1. EID の計算セクションで定義されているように、Fp で乱数 s を選択します。
  2. S = s * G を計算します。
  3. 曲線方程式に代入して R = (Rx, Ry) を計算し、可能な結果から任意の Ry 値を選択します。
  4. 256 ビット AES 鍵 k = HKDF-SHA256((s * R)x) を計算します。ここで、(s * R)x は、曲線乗算結果の x 座標です。ソルトが指定されていません。
  5. URxLRx をそれぞれ Rx の上位 80 ビットと下位 80 ビットに(ビッグ エンディアン形式)します。同様に、SUSxLSx を定義します。
  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. 曲線方程式に代入して S = (Sx, Sy) を計算し、可能な結果から任意の 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 秒ごとに行われます。ビーコンが新しい識別子のアドバタイジングを開始する正確な時点は、ウィンドウ内でランダム化する必要があります。

ローテーション時間をランダム化するための推奨されるアプローチは、次に予想されるローテーション時間(ランダム化が適用されていない場合)に、1 ~ 204 秒の範囲の正のランダム化時間係数を足した値に設定することです。

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

停電からの復旧

エフェメラル ID の解決は、アドバタイジング時のクロック値に強く関連付けられているため、停電が発生した場合にプロバイダがクロック値を復元できることが重要です。プロバイダは現在のクロック値を少なくとも 1 日に 1 回は不揮発性メモリに書き込むことをおすすめします。また、起動時に NVM をチェックして、初期化元の値が存在するかどうかを確認することをおすすめします。エフェメラル識別子のリゾルバは、妥当なクロックドリフトとこのタイプの電力損失からの回復の両方を可能にするのに十分な時間枠で解決を実装します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

これを許可するには、プロバイダはファームウェア バージョン プロパティ(コード 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 キーと保存されているすべてのアカウントキー(所有者のアカウントキーを含む)を消去する必要があります。

出荷時設定へのリセット(手動またはプログラム)後、プロバイダはファスト ペアリングのアドバタイズをすぐに開始してはいけません。ユーザーがデバイスを削除した直後にペア設定フローが開始されないようにするためです。

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

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

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

  • FMDN 対応デバイスは、付近のデバイス コンソールに登録され、「デバイスを探す」機能が有効になっている必要があります。
  • デバイスは、DULT 仕様の実装バージョンで定義されているアクセサリの非所有者のサービスおよび特性(アクセサリ情報の操作や非所有者のコントロールなど)を実装する必要があります。
  • DULT 仕様で定義されているように、下位互換性期間中に、このドキュメントで定義されているように、アドバタイズされたフレームに変更はありません。
  • このドキュメントで定義されている「望ましくないトラッキング保護モード」は、DULT の仕様で定義されている「分離状態」にマッピングされます。
  • アクセサリ情報のオペコードを実装するためのガイドライン:
    • Get_Product_Data は、コンソールから提供されたモデル ID を、8 バイトの要件に合わせてゼロパディングして返します。たとえば、モデル ID 0xFFFFFF は 0x0000000000FFFFFF として返されます。
    • Get_Manufacturer_Name と Get_Model_Name は、コンソールで指定された値と一致している必要があります。
    • Get_Accessory_Category は、デバイスのタイプに適したカテゴリが他にない場合、汎用の「Location Tracker」の値を返します。
    • Get_Accessory_Capabilities は、着信音と BLE ID ルックアップのサポートを示す必要があります。
    • Get_Network_ID は Google の識別子(0x02)を返す必要があります。
  • Get_Identifier オペコードを実装するためのガイドライン:
    • ユーザーが「識別」モードを有効にしてから 5 分間のみ、有効なレスポンスを返すようにする必要があります。このモードでは複数のボタンを押す必要があります。映像または音声のシグナルにより、プロバイダがそのモードに入ったことをユーザーに示す必要があります。このモードを有効にするためのモデル固有の手順は、認定の要件として Google に提供する必要があります。また、手順の更新または変更の 10 日前までに行う必要があります。
    • レスポンスは、現在のエフェメラル識別子の最初の 10 バイトと、HMAC-SHA256(recovery key, the truncated current ephemeral identifier) の最初の 8 バイトという構成になります。
  • Sound_Start オペコードを実装するためのガイドライン:
    • このコマンドにより、使用可能なすべてのコンポーネントで着信音が鳴ります。
    • サポートされている音量を最大限活用してください。
    • 推奨される着信音の時間は 12 秒です。
  • ロケータタグには、デバイスを出荷時の設定にリセットせずにユーザーが一時的にアドバタイズを停止できるメカニズム(複数のボタンを押すなど)を含める必要があります。
    • 無効化の手順は、一般公開されている URL で文書化し、認証の要件として Google に提供する必要があります。この情報は、手順の更新または変更の 10 日以上前に行う必要があります。
    • URL はローカライズに対応している必要があります。クライアントに応じて、言語はクエリ パラメータ(「hl=en」)として、または「accept-language」HTTP ヘッダーを使用して提供されます。

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

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

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

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

互換性

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

変更履歴

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