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 つ以上のキーに関する知識を証明します。
アカウントキー: ファスト ペアリング仕様で定義されている 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 バイトで切り捨てられます。鍵はバックエンドに保存され、シーカーは望ましくないトラッキング保護モードを有効にするためにのみこの鍵を使用できます。
Operations
特性に書き込まれるデータの形式を表 2 ~ 5 に示します。各オペレーションについては、このセクションで後ほど詳しく説明します。
オクテット | データ型 | 説明 | 値 |
---|---|---|---|
0 | uint8 | データ 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 - 変数 | バイト配列 | 追加データ |
|
表 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 |
|
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 - 変数 | バイト配列 | 追加データ |
|
表 4: 呼び出し中のリクエスト
オクテット | データ型 | 説明 | 値 |
---|---|---|---|
0 | uint8 | データ ID |
|
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 - 変数 | バイト配列 | 追加データ |
|
表 5: 望ましくないトラッキング保護リクエスト
書き込みに成功すると、表 6 に示すように通知がトリガーされます。
データ ID が 0x05: Ring state change 以外の場合は、通知をトリガーする書き込みトランザクションが完了する前、つまり書き込みリクエストのレスポンス PDU が送信される前に送信する必要があります。
オクテット | データ型 | 説明 | 値 |
---|---|---|---|
0 | uint8 | データ ID |
|
1 | uint8 | データの長さ | 場合によって異なる |
2 ~ 9 | バイト配列 | エネルギー効率比率(EER) | オペレーションごとの詳細 |
10 - 変数 | バイト配列 | 追加データ |
|
表 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 | 曲線の選択 | 暗号化に使用される楕円曲線:
|
6 | uint8 | コンポーネント | 呼び出し可能なコンポーネントの数:
|
7 | uint8 | 着信音機能 | サポートされているオプションは次のとおりです。
|
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 ~ 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 ~ 2 | uint16 | タイムアウト | タイムアウト(デシ秒)。ゼロにはできません。また、10 分以下の値にする必要があります。 プロバイダはこの値を使用して、自身を消音にするまでの時間を決定します。デバイスのいずれかのコンポーネントがすでに鳴っている場合は、タイムアウトによってすでに有効なタイムアウトがオーバーライドされます。 リング オペレーションが 0x00 に設定されている場合、タイムアウトは無視されます。 |
3 | uint8 | ボリューム |
|
リクエストを受領したプロバイダは、以下を確認します。
- 指定されたワンタイム認証鍵がリング鍵と一致する。
- リクエストされた状態が、呼び出し可能なコンポーネントと一致している。
プロバイダが FMDN ビーコンとしてプロビジョニングされていない場合、または検証が失敗した場合は、未認証エラーが返されます。ただし、プロバイダで不要なトラッキング防止機能が有効になっていて、不要なトラッキング保護リクエストをトリガーするときに認証の着信音をスキップするフラグがオンになっている場合、プロバイダはそのチェックをスキップする必要があります。認証データはシーカーから提供されることが想定されますが、任意の値に設定できます。
呼び出し音が開始または終了すると、表 6 に示すようにデータ ID 0x05 で通知が送信されます。通知の内容は次のように定義されます。
オクテット | データ型 | 説明 | 値 |
---|---|---|---|
0 | uint8 | 呼び出し状態 |
|
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 | コントロール フラグ |
このフラグは、不要なトラッキング保護モードが無効になるまで有効です。 |
プロバイダは、提供された 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
が楕円曲線暗号オペレーションに使用されます。次に参照する Fp
、n
、G
を定義する、
SEC 2: Recommended Elliptic Curve Domain Parameters の曲線の定義をご覧ください。
r = r' mod n
を計算して、r'
が有限体 Fp
に射影されるようになりました。最後に、R = r * G
を計算します。これは、使用されている公開鍵を表す曲線上の点です。ビーコンは Rx
(R
の x
座標)をエフェメラル識別子としてアドバタイズします。
ハッシュされたフラグ
ハッシュされたフラグのフィールドは次のように計算されます(ビットは最上位から下位の順に参照されます)。
- ビット 0 ~ 4: 予約済み(ゼロに設定)。
- ビット 5 ~ 6 は、デバイスのバッテリー残量を次のように示します。
- 00: バッテリー残量表示はサポートされていません
- 01: 通常のバッテリー残量
- 10: バッテリー残量が少ない
- 11: バッテリー残量が非常に少なくなっています(まもなくバッテリーの交換が必要です)
- ビーコンが不要なトラッキング保護モードの場合、ビット 7 は 1 に設定され、それ以外の場合は 0 に設定されます。
このバイトの最終値を生成するために、SHA256(r)
の最下位バイトで XOR 演算が行われます。
r は曲線のサイズに合わせます。表現が 160 または 256 ビットより短い場合は最上位ビットとしてゼロを追加し、表現が 160 または 256 ビットより大きい場合は最上位ビットを切り捨てる必要があります。
ビーコンがバッテリー残量表示をサポートせず、望ましくないトラッキング保護モードでない場合は、このバイトをアドバタイズから完全に省略できます。
EID による暗号化
メッセージ m
を暗号化するために、訪問者(ビーコンから Rx
を読み取った人)は次のことを行います。
- EID の計算セクションで定義されているように、
Fp
で乱数s
を選択します。 S = s * G
を計算します。- 曲線方程式に代入して
R = (Rx, Ry)
を計算し、可能な結果から任意のRy
値を選択します。 - 256 ビット AES 鍵
k = HKDF-SHA256((s * R)x)
を計算します。ここで、(s * R)x
は、曲線乗算結果のx
座標です。ソルトが指定されていません。 URx
とLRx
をそれぞれRx
の上位 80 ビットと下位 80 ビットに(ビッグ エンディアン形式)します。同様に、S
のUSx
とLSx
を定義します。nonce = LRx || LSx
を計算します。(m’, tag) = AES-EAX-256-ENC(k, nonce, m)
を計算します。- 信頼できないリモート サービス経由で、
(URx, Sx, m’, tag)
をオーナーに送信します。
EID で暗号化された値の復号
EIK とローテーション期間の指数を持つオーナーのクライアントは、次のようにメッセージを復号します。
- 指定された
URx
について、URx
の基になっているビーコン時間カウンタ値を取得します。 これは、所有者のクライアントが過去および近い将来のビーコン時間カウンタ値のRx
値を計算することによって実行できます。 URx
に基づくビーコン時間カウンタの値から、EID の計算セクションで定義されているr
の予測値を計算します。R = r * G
を計算し、サイトから提供されたURx
の値と一致することを確認します。- 曲線方程式に代入して
S = (Sx, Sy)
を計算し、可能な結果から任意のSy
値を選択します。 k = HKDF-SHA256((r * S)x)
を計算します。ここで、(r * S)x
は曲線の乗算結果のx
座標です。nonce = LRx || LSx
を計算します。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 月 |
|
v1.3 | 2023 年 12 月 |
|