コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
メッセージ認証コード
音声の切り替えを設定するには、メッセージ ストリームを使用します。
音声切り替えメッセージ。このような重要な構成の場合、プロバイダは
(ファスト ペアリング モジュール)ではなく、GMSCore(ファスト ペアリング モジュール)から送信される
別のアプリを表示します
MAC(メッセージ認証コード)を生成する
FP シーカーがデバイス構成メッセージにメッセージ認証コードを追加
取得します。メッセージの MAC は、次の最初の 8 バイトで構成されます。
sha256(concat((K ^ opad), sha256(concat((K ^ ipad), concat(nonce, message)))))
ここで
- K は concat(アカウントキー、48 バイトの ZERO)によって生成されます。
- message はメッセージ ストリームの追加データです。
- nonce は concat(session_nonce, message_nonce) で生成されます。セッション
nonce と message nonce については、次のセクションで定義します。
- opad は 64 バイトの外側パディングで、指定された値を持つ繰り返しバイトで構成されます。
0x5C
。
- ipad は 64 バイトの内部パディングで、その数値の繰り返しバイトで構成されます。
0x36
。
セッションのノンスとメッセージのノンス
リプレイ攻撃を防ぐために、プロバイダはノンスが
あります。両方のプロバイダでクロックまたはカウンタの同期が維持されるため、
シーカーが単純でない場合、プロバイダがセッションのノンスを生成します。
(接続ごと)で、接続中のすべてのメッセージと共有されます。
一方、シーカーは(メッセージごとに)メッセージのノンスを生成します。このノンスは、
メッセージごとに生成されます。各メッセージの MAC を生成するためのノンスは、
セッションのノンスとメッセージのノンスの組み合わせ(例:
concat(session_nonce, message_nonce) 。
セッションのノンスは、デバイス情報イベント グループに追加されます。
メッセージ グループ名 |
値 |
デバイス情報イベント |
0x03 |
メッセージ コード名 |
値 |
セッションのノンス |
0x0A |
RFCOMM によって、セッション ノンスが生成され、シーカーに送信される
接続:
オクテット |
データ型 |
説明 |
値 |
0 |
uint8 |
デバイス情報イベント |
0x03 |
1 |
uint8 |
セッションのノンス |
0x0A |
2 ~ 3 |
uint16 |
追加データ長 |
0x0008 |
4 ~ 11 |
|
セッションのノンス |
場合によって異なる |
MAC が必要な場合にメッセージを送信するために、シーカーはメッセージのノンスを送信します。
メッセージと一緒に送信されます。
オクテット |
データ型 |
説明 |
値 |
0 |
uint8 |
メッセージ グループ |
場合によって異なる |
1 |
uint8 |
メッセージ コード |
場合によって異なる |
2 ~ 3 |
uint16 |
追加データ長(追加データ長 + 16) |
場合によって異なる |
4 ~ n |
|
追加データ |
場合によって異なる |
n+1 ~ n+8 |
|
メッセージのノンス |
場合によって異なる |
n+9 ~ n+16 |
|
メッセージ認証コード |
場合によって異なる |
MAC(メッセージ認証コード)を確認する
メッセージ認証コードが含まれるメッセージを受信すると、
生成関数と同じ関数を使用して検証する必要があります。つまり
受信された MAC は、最初の 8 バイトに等しく
sha256(concat((K ^ opad), sha256(concat((K ^ ipad), concat(section_nonce, message_nonce, message)))))
ここで
- K は
concat(account key, 48-byte ZEROs)
によって生成され、Provider は
は、保存されているすべてのアカウントキーを走査して MAC を検証します。
- message はメッセージの追加データ(メッセージのノンスと MAC を除く)です
表示されます。
MAC が正しい場合、プロバイダは
表示されます。それ以外の場合、プロバイダはエラー理由 0x3 -
メッセージ認証コードが正しくないため、許可されていません。
特に記載のない限り、このページのコンテンツはクリエイティブ・コモンズの表示 4.0 ライセンスにより使用許諾されます。コードサンプルは Apache 2.0 ライセンスにより使用許諾されます。詳しくは、Google Developers サイトのポリシーをご覧ください。Java は Oracle および関連会社の登録商標です。
最終更新日 2025-08-13 UTC。
[null,null,["最終更新日 2025-08-13 UTC。"],[[["\u003cp\u003eMessage Authentication Codes (MACs) are used to verify that Fast Pair configuration messages originate from Google Mobile Services (GMSCore) and not other apps.\u003c/p\u003e\n"],["\u003cp\u003eMACs are generated using HMAC-SHA256, incorporating session and message nonces to prevent replay attacks.\u003c/p\u003e\n"],["\u003cp\u003eProviders initiate a session nonce upon RFCOMM connection and seekers generate a unique message nonce for each message.\u003c/p\u003e\n"],["\u003cp\u003eTo verify a message, providers compute the MAC using the received data and compare it with the received MAC, using stored account keys for verification.\u003c/p\u003e\n"],["\u003cp\u003eIf MAC verification fails, the provider sends a NAK message indicating an incorrect authentication code.\u003c/p\u003e\n"]]],["Message Authentication Code (MAC) ensures messages originate from GMSCore. The Seeker generates a MAC using HMAC-SHA256, derived from a key (K), nonce, and message data. The nonce combines a per-connection session nonce (Provider-generated) and a per-message nonce (Seeker-generated). The Seeker transmits the message nonce and MAC with each message. The Provider verifies the MAC using the same function and stored keys, acting on the message only if the MAC is correct. If not, a NAK is sent.\n"],null,["Message Authentication Code\n---------------------------\n\n[Message streams](/nearby/fast-pair/specifications/extensions/messagestream#MessageStream \"message stream\") are used to configure Audio switch, see\n[Audio switch messages](/nearby/fast-pair/specifications/extensions/sass#MacOfSassMessages \"MAC of Audio switch Messages\"). For these important configurations, the Provider needs\nto ensure that the message is sent by GMSCore (Fast Pair module) and not any\nother app on the Seeker.\n| **Note:** Google recommends implementing the [Cryptographic Test Cases](/nearby/fast-pair/specifications/appendix/cryptotestcases \"Link to the Cryptographic Test Cases.\") to ease verification of these requirements.\n\n### Generate MAC (message authentication code)\n\nFP Seeker adds a message authentication code for device configuration messages\nusing HMAC-SHA256. The MAC of the message consists of the first 8 bytes of: \n\n sha256(concat((K ^ opad), sha256(concat((K ^ ipad), concat(nonce, message)))))\n\nwhere\n\n1. *K* is generated by concat(account key, 48-byte ZEROs).\n2. *message* is the additional data of Message stream.\n3. *nonce* is generated by concat(session_nonce, message_nonce); session nonce and message nonce are defined in the following section.\n4. *opad* is 64 bytes of outer padding, consisting of repeated bytes valued `0x5C`.\n5. *ipad* is 64 bytes of inner padding, consisting of repeated bytes valued `0x36`.\n\n### Session nonce and message nonce\n\nTo prevent a replay attack, the Provider needs to ensure that a nonce is not\nrepeated. Since maintaining clock or counter synchronization on both Provider\nand Seeker is not straightforward, the Provider generates the session nonce\n(per connection), which is shared with all messages during the connection,\nwhile the Seeker generates the message nonce (per message), which is randomly\ngenerated for each message. The nonce for generating the MAC of each message is\nthe combination of session nonce and message nonce, i.e.\nconcat(session_nonce, message_nonce).\n\nWe add a session nonce to the Device information event group:\n\n| Message Group Name | Value |\n|--------------------------|-------|\n| Device information event | 0x03 |\n\n| Message Code Name | Value |\n|-------------------|-------|\n| Session nonce | 0x0A |\n\nThe session nonce should be generated and sent to the Seeker when RFCOMM\nconnects:\n\n| Octet | Data Type | Description | Value |\n|--------|-----------|--------------------------|----------|\n| 0 | uint8 | Device information event | 0x03 |\n| 1 | uint8 | Session nonce | 0x0A |\n| 2 - 3 | uint16 | Additional data length | 0x0008 |\n| 4 - 11 | | session nonce | *varies* |\n\nTo send a message when a MAC is required, the Seeker will send a message nonce\nand the MAC together with the message.\n\n| Octet | Data Type | Description | Value |\n|----------------|-----------|---------------------------------------------------------|----------|\n| 0 | uint8 | Message group | *varies* |\n| 1 | uint8 | Message code | *varies* |\n| 2 - 3 | uint16 | Additional data length(the additional data length + 16) | *varies* |\n| 4 - n | | Additional data | *varies* |\n| n + 1 - n + 8 | | Message nonce | *varies* |\n| n + 9 - n + 16 | | Message authentication code | *varies* |\n\n### Verify MAC (message authentication code)\n\nUpon receiving a message with the message authentication code, the Provider\nshall verify it by using the same function as the generating function. That is,\nthe received MAC should be equal to the first 8 bytes of \n\n sha256(concat((K ^ opad), sha256(concat((K ^ ipad), concat(section_nonce, message_nonce, message)))))\n\nwhere:\n\n1. *K* is generated by `concat(account key, 48-byte ZEROs)`, and the Provider shall traverse all stored account keys to verify the MAC.\n2. *message* is the additional data (excluding message nonce and MAC) of the Message stream.\n\nIf the MAC is correct, then the Provider shall follow the instruction of the\nmessage. Otherwise, the Provider shall send a NAK with the error reason, 0x3 -\nnot allowed due to incorrect message authentication code."]]