Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang
Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.
Mã xác thực thư
Luồng tin nhắn được dùng để định cấu hình tính năng Chuyển đổi âm thanh, xem
Thông báo chuyển đổi âm thanh. Đối với những cấu hình quan trọng này, Nhà cung cấp cần
nhằm đảm bảo thông báo được gửi bởi GMSCore (mô-đun Ghép nối nhanh) chứ không phải bất kỳ
ứng dụng khác trên Seeker.
Tạo MAC (mã xác thực thư)
FP Seeker thêm một mã xác thực tin nhắn cho các thông báo cấu hình thiết bị
bằng HMAC-SHA256. MAC của thông báo bao gồm 8 byte đầu tiên của:
sha256(concat((K ^ opad), sha256(concat((K ^ ipad), concat(nonce, message)))))
trong đó
- K được tạo bằng concat(khoá tài khoản, 48 byte bằng các chữ số không).
- tin nhắn là dữ liệu bổ sung của Luồng tin nhắn.
- số chỉ dùng một lần do concat(session_nonce, message_nonce); phiên
Số chỉ dùng một lần và số chỉ dùng một lần thông báo được định nghĩa trong phần sau.
- opad là 64 byte khoảng đệm bên ngoài, bao gồm các byte lặp lại có giá trị
0x5C.
- ipad là 64 byte khoảng đệm bên trong, bao gồm các byte lặp lại có giá trị
0x36.
Số chỉ dùng một lần của phiên và số chỉ dùng một lần theo tin nhắn
Để ngăn chặn một cuộc tấn công phát lại, Nhà cung cấp cần đảm bảo rằng số chỉ dùng một lần không
lặp lại. Vì việc duy trì đồng bộ hoá bộ đếm hoặc đồng hồ trên cả hai Nhà cung cấp
và Trình tìm kiếm không đơn giản, Nhà cung cấp sẽ tạo số chỉ dùng một lần của phiên
(cho mỗi kết nối), được chia sẻ với tất cả tin nhắn trong quá trình kết nối,
còn Trình tìm kiếm tạo số chỉ dùng một lần thông báo (mỗi thư), được lấy ngẫu nhiên
được tạo cho mỗi tin nhắn. Số chỉ dùng một lần để tạo MAC của mỗi thông báo là
tổ hợp số chỉ dùng một lần của phiên và số chỉ dùng một lần của thông báo, tức là
concat(session_nonce; message_nonce).
Chúng ta thêm một số chỉ dùng một lần theo phiên vào nhóm sự kiện Thông tin thiết bị:
| Tên nhóm tin nhắn |
Giá trị |
| Sự kiện thông tin thiết bị |
0x03 |
| Tên mã tin nhắn |
Giá trị |
| Số chỉ dùng một lần của phiên |
0x0A |
Số chỉ dùng một lần của phiên phải được tạo và gửi tới Trình tìm kiếm khi RFCOMM
kết nối:
| Bộ tám |
Loại dữ liệu |
Mô tả |
Giá trị |
| 0 |
uint8 |
Sự kiện thông tin thiết bị |
0x03 |
| 1 |
uint8 |
Số chỉ dùng một lần của phiên |
0x0A |
| 2–3 |
uint16 |
Thời lượng dữ liệu bổ sung |
0x0008 |
| 4–11 |
|
số chỉ dùng một lần của phiên |
khác nhau |
Để gửi tin nhắn khi cần có MAC, người tìm kiếm sẽ gửi một số chỉ dùng một lần tin nhắn
và MAC cùng với thông báo.
| Bộ tám |
Loại dữ liệu |
Mô tả |
Giá trị |
| 0 |
uint8 |
Nhóm thư |
khác nhau |
| 1 |
uint8 |
Mã tin nhắn |
khác nhau |
| 2–3 |
uint16 |
Độ dài dữ liệu bổ sung(độ dài dữ liệu bổ sung + 16) |
khác nhau |
| 4 – n |
|
Dữ liệu bổ sung |
khác nhau |
| n + 1 - n + 8 |
|
Số chỉ dùng một lần tin nhắn |
khác nhau |
| n + 9 - n + 16 |
|
Mã xác thực thư |
khác nhau |
Xác minh MAC (mã xác thực thư)
Khi nhận được một tin nhắn có mã xác thực tin nhắn, Nhà cung cấp
sẽ xác minh điều này bằng cách sử dụng cùng một hàm với hàm tạo. Tức là
MAC nhận được phải bằng 8 byte đầu tiên của
sha256(concat((K ^ opad), sha256(concat((K ^ ipad), concat(section_nonce, message_nonce, message)))))
trong đó:
- K do
concat(account key, 48-byte ZEROs) tạo và Nhà cung cấp
sẽ truyền tải tất cả các khoá tài khoản được lưu trữ để xác minh MAC.
- tin nhắn là dữ liệu bổ sung (không bao gồm số chỉ dùng một lần tin nhắn và MAC) của
luồng Tin nhắn.
Nếu MAC đúng thì Nhà cung cấp phải thực hiện theo hướng dẫn của
. Nếu không, Nhà cung cấp sẽ gửi NAK kèm theo lý do lỗi, 0x3 –
không được phép do mã xác thực tin nhắn không chính xác.
Trừ phi có lưu ý khác, nội dung của trang này được cấp phép theo Giấy phép ghi nhận tác giả 4.0 của Creative Commons và các mẫu mã lập trình được cấp phép theo Giấy phép Apache 2.0. Để biết thông tin chi tiết, vui lòng tham khảo Chính sách trang web của Google Developers. Java là nhãn hiệu đã đăng ký của Oracle và/hoặc các đơn vị liên kết với Oracle.
Cập nhật lần gần đây nhất: 2025-08-13 UTC.
[[["Dễ hiểu","easyToUnderstand","thumb-up"],["Giúp tôi giải quyết được vấn đề","solvedMyProblem","thumb-up"],["Khác","otherUp","thumb-up"]],[["Thiếu thông tin tôi cần","missingTheInformationINeed","thumb-down"],["Quá phức tạp/quá nhiều bước","tooComplicatedTooManySteps","thumb-down"],["Đã lỗi thời","outOfDate","thumb-down"],["Vấn đề về bản dịch","translationIssue","thumb-down"],["Vấn đề về mẫu/mã","samplesCodeIssue","thumb-down"],["Khác","otherDown","thumb-down"]],["Cập nhật lần gần đây nhất: 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."]]
