透過集合功能整理內容
你可以依據偏好儲存及分類內容。
訊息驗證碼
訊息串流可用來設定音訊自動切換,請參閱
音訊自動切換訊息。針對這些重要設定,供應商需要
確保訊息是由 GMSCore (快速配對模組) 傳送,而不是任何
熱門搜尋工具
產生 MAC (訊息驗證碼)
FP Seeker 會為裝置設定訊息新增訊息驗證碼
接著使用 HMAC-SHA256訊息的 MAC 由下列的前 8 個位元組組成:
sha256(concat((K ^ opad), sha256(concat((K ^ ipad), concat(nonce, message)))))
媒介
- K 是由 concat(帳戶金鑰,48 位元組) 產生。
- message 是訊息串流的其他資料。
- nonce 是由 concat(session_nonce, message_nonce) 產生工作階段
以下章節會定義 Nonce 和 message Nonce。
- opad 是外部邊框間距的 64 個位元組,包含值的重複位元組
0x5C
。
- ipad 是 64 個位元組的內部邊框間距,由具值的重複位元組組成
0x36
。
工作階段 Nonce 和訊息 Nonce
為防止重播攻擊,供應商必須確保 Nonce 不會
可以重複執行自從在兩個供應商平台持續進行時鐘或計數器同步作業
但 Seeker 也不清楚
供應商產生工作階段 Nonce 時
每個連線都會在連線期間與所有郵件共用
搜尋器產生訊息 Nonce (每則訊息) 時,系統會隨機產生
不會產生費用用於產生每則訊息 MAC 的 Nonce 為
亦即「工作階段 Nonce」和「message Nonce」的組合。
concat(session_nonce, message_nonce)。
我們在「裝置資訊」事件群組中加入一個工作階段 Nonce:
執行 RFCOMM 時,應產生工作階段 Nonce 並傳送至尋找器
連線:
八位元 |
資料類型 |
說明 |
值 |
0 |
uint8 |
裝置資訊事件 |
0x03 |
1 |
uint8 |
工作階段 Nonce |
0 軸 |
2 - 3 |
uint16 |
額外資料長度 |
0x0008 |
4 - 11 |
|
工作階段 Nonce |
各不相同 |
為了在需使用 MAC 的情況下傳送訊息,Seeker 會傳送訊息 Nonce
以及 MAC 與其訊息
八位元 |
資料類型 |
說明 |
值 |
0 |
uint8 |
訊息群組 |
各不相同 |
1 |
uint8 |
訊息代碼 |
各不相同 |
2 - 3 |
uint16 |
其他資料長度(額外資料長度 + 16) |
各不相同 |
4 - n |
|
額外資料 |
各不相同 |
n + 1 - n + 8 |
|
訊息 Nonce |
各不相同 |
n + 9 - n + 16 |
|
訊息驗證碼 |
各不相同 |
驗證 MAC (訊息驗證碼)
收到內含訊息驗證碼的訊息後,供應商便會
必須使用與產生函式相同的函式進行驗證。也就是說
接收的 MAC 應等於
sha256(concat((K ^ opad), sha256(concat((K ^ ipad), concat(section_nonce, message_nonce, message)))))
其中:
- K 是由
concat(account key, 48-byte ZEROs)
和提供者產生
必須週遊所有儲存的帳戶金鑰來驗證 MAC。
- 「message」是
訊息串流。
如果 MAC 正確無誤,則供應商應按照
撰寫新的電子郵件訊息否則,供應商必須傳送 NAK 和錯誤原因 0x3 -
因訊息驗證碼錯誤導致不允許使用。
除非另有註明,否則本頁面中的內容是採用創用 CC 姓名標示 4.0 授權,程式碼範例則為阿帕契 2.0 授權。詳情請參閱《Google Developers 網站政策》。Java 是 Oracle 和/或其關聯企業的註冊商標。
上次更新時間:2025-08-13 (世界標準時間)。
[null,null,["上次更新時間:2025-08-13 (世界標準時間)。"],[[["\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."]]