Thông số kỹ thuật của phụ kiện mạng Trung tâm tìm thiết bị

v1.3

Quy cách phụ kiện của Mạng lưới Trung tâm tìm thiết bị (FHN) xác định một phương pháp mã hoá hai đầu để theo dõi các thiết bị Bluetooth năng lượng thấp (BLE) phát tín hiệu. Trang này mô tả FHN là một phần mở rộng cho quy cách Fast Pair. Nhà cung cấp nên bật tiện ích này nếu có các thiết bị tương thích với FHN và sẵn sàng bật tính năng theo dõi vị trí cho các thiết bị đó.

Quy cách GATT

Bạn nên thêm một đặc điểm thuộc tính chung (GATT) bổ sung vào Dịch vụ Ghép nối nhanh với ngữ nghĩa sau:

Đặc điểm của dịch vụ Ghép nối nhanh Đã mã hóa Quyền mã nhận dạng duy nhất (UUID)
Thao tác với beacon Không Đọc, ghi và thông báo FE2C1238-8366-4814-8EB0-01DE32100BEA

Bảng 1: Đặc điểm của Dịch vụ Ghép nối nhanh đối với FHN.

Xác thực

Các thao tác mà tiện ích này yêu cầu được thực hiện dưới dạng thao tác ghi, được bảo mật bằng cơ chế thử thách – phản hồi. Trước khi thực hiện bất kỳ thao tác nào, Seeker dự kiến sẽ thực hiện thao tác đọc từ đặc điểm trong bảng 1, dẫn đến một vùng đệm có định dạng như sau:

Octet Loại dữ liệu Mô tả Giá trị
0 uint8 Số phiên bản chính của giao thức 0x01
1 – 8 mảng byte Số chỉ dùng một lần ngẫu nhiên tuỳ thuộc

Mỗi thao tác đọc phải tạo ra một số chỉ dùng một lần khác nhau và một số chỉ dùng một lần chỉ được hợp lệ cho một thao tác duy nhất. Số chỉ dùng một lần phải bị vô hiệu hoá ngay cả khi thao tác không thành công.

Sau đó, Seeker sẽ tính toán một khoá xác thực dùng một lần để sử dụng trong yêu cầu ghi tiếp theo. Khoá xác thực được tính như mô tả trong các bảng từ 2 đến 5. Tuỳ thuộc vào thao tác được yêu cầu, Người tìm kiếm chứng minh kiến thức về một hoặc nhiều khoá sau:

Hoạt động tính toán

Định dạng của dữ liệu được ghi vào đặc điểm được trình bày trong các bảng từ 2 đến 5. Mỗi thao tác sẽ được thảo luận chi tiết hơn ở phần sau của phần này.

Octet Loại dữ liệu Mô tả Giá trị
0 uint8 Mã dữ liệu
  • 0x00: Đọc các tham số của beacon
  • 0x01: Đọc trạng thái cấp phép
  • 0x02: Đặt khoá nhận dạng tạm thời
  • 0x03: Xoá khoá nhận dạng tạm thời
1 uint8 Độ dài dữ liệu tuỳ thuộc
2 – 9 mảng byte Khoá xác thực một lần 8 byte đầu tiên của HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data)
10 – var mảng byte Dữ liệu khác
  • 0x00: n/a
  • 0x01: không áp dụng
  • 0x02: 32 byte là khoá nhận dạng tạm thời, được mã hoá AES-ECB-128 bằng khoá tài khoản. Nếu Nhà cung cấp đã có một bộ khoá nhận dạng tạm thời, hãy gửi 8 byte đầu tiên của SHA256(current ephemeral identity key || the last nonce read from the characteristic)
  • 0x03: 8 byte đầu tiên của SHA256(ephemeral identity key || the last nonce read from the characteristic)

Bảng 2: Yêu cầu cung cấp beacon.

Octet Loại dữ liệu Mô tả Giá trị
0 uint8 Mã dữ liệu 0x04: Đọc khoá nhận dạng tạm thời khi có sự đồng ý của người dùng
1 uint8 Độ dài dữ liệu 0x08
2 – 9 mảng byte Khoá xác thực một lần 8 byte đầu tiên của HMAC-SHA256(recovery key, protocol major version number || the last nonce read from the characteristic || data ID || data length)

Bảng 3: Yêu cầu khôi phục khoá cấp phép của beacon.

Octet Loại dữ liệu Mô tả Giá trị
0 uint8 Mã dữ liệu
  • 0x05: Ring
  • 0x06: Đọc trạng thái đổ chuông
1 uint8 Độ dài dữ liệu tuỳ thuộc
2 – 9 mảng byte Khoá xác thực một lần 8 byte đầu tiên của HMAC-SHA256(ring key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data)
10 – var mảng byte Dữ liệu khác
  • 0x05: 4 byte cho biết trạng thái đổ chuông, thời lượng đổ chuông và âm lượng đổ chuông.
  • 0x06: không áp dụng

Bảng 4: Yêu cầu đổ chuông.

Octet Loại dữ liệu Mô tả Giá trị
0 uint8 Mã dữ liệu
  • 0x07: Kích hoạt chế độ bảo vệ chống theo dõi ngoài ý muốn
  • 0x08: Huỷ kích hoạt chế độ bảo vệ chống theo dõi không mong muốn
1 uint8 Độ dài dữ liệu tuỳ thuộc
2 – 9 mảng byte Khoá xác thực một lần 8 byte đầu tiên của HMAC-SHA256(unwanted tracking protection key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data)
10 – var mảng byte Dữ liệu khác
  • 0x07: 1 byte cờ điều khiển (không bắt buộc)
  • 0x08: 8 byte đầu tiên của SHA256(ephemeral identity key || the last nonce read from the characteristic)

Bảng 5: Yêu cầu bảo vệ khỏi hoạt động theo dõi không mong muốn.

Các thao tác ghi thành công sẽ kích hoạt thông báo như được liệt kê trong bảng 6.

Thông báo có mã nhận dạng dữ liệu khác với 0x05: Thay đổi trạng thái chuông phải được gửi trước khi giao dịch ghi kích hoạt thông báo hoàn tất, tức là trước khi PDU phản hồi cho yêu cầu ghi được gửi.

Octet Loại dữ liệu Mô tả Giá trị
0 uint8 Mã dữ liệu
  • 0x00: Đọc các tham số của beacon
  • 0x01: Đọc trạng thái cấp phép
  • 0x02: Đặt khoá nhận dạng tạm thời
  • 0x03: Xoá khoá nhận dạng tạm thời
  • 0x04: Đọc khoá nhận dạng tạm thời khi có sự đồng ý của người dùng
  • 0x05: Thay đổi trạng thái chuông
  • 0x06: Đọc trạng thái đổ chuông
  • 0x07: Kích hoạt chế độ bảo vệ chống theo dõi ngoài ý muốn
  • 0x08: Huỷ kích hoạt chế độ bảo vệ chống theo dõi không mong muốn
1 uint8 Độ dài dữ liệu tuỳ thuộc
2 – 9 mảng byte Xác thực Chi tiết theo từng thao tác
10 – var mảng byte Dữ liệu khác
  • 0x00: 8 byte cho biết công suất truyền, giá trị đồng hồ, phương thức mã hoá và khả năng đổ chuông, được mã hoá AES-ECB-128 bằng khoá tài khoản (được thêm số 0)
  • 0x01: 1 byte cho biết trạng thái cung cấp, theo sau là mã nhận dạng tạm thời hiện tại (20 hoặc 32 byte), nếu có
  • 0x04: 32 byte là khoá nhận dạng tạm thời, được mã hoá AES-ECB-128 bằng khoá tài khoản
  • 0x05: 4 byte cho biết trạng thái mới và điều kiện kích hoạt cho thay đổi
  • 0x06: 3 byte cho biết các thành phần đang đổ chuông và số lượng phần mười giây còn lại để đổ chuông
  • Các mã nhận dạng dữ liệu khác sử dụng dữ liệu bổ sung trống

Bảng 6: Phản hồi của dịch vụ beacon.

Bảng 7 liệt kê các mã lỗi GATT có thể được trả về bởi các thao tác.

Mã Mô tả Ghi chú
0x80 Chưa được xác thực Trả về để phản hồi yêu cầu ghi khi quá trình xác thực không thành công (bao gồm cả trường hợp sử dụng số chỉ dùng một lần cũ).
0x81 Giá trị không hợp lệ Trả về khi bạn cung cấp bất kỳ giá trị không hợp lệ nào hoặc dữ liệu nhận được có số lượng byte ngoài dự kiến.
0x82 Không có sự đồng ý của người dùng Trả về để phản hồi yêu cầu ghi có mã nhận dạng dữ liệu 0x04: Đọc khoá nhận dạng tạm thời khi có sự đồng ý của người dùng khi thiết bị không ở chế độ ghép nối.

Bảng 7: Mã lỗi GATT.

Đọc tham số của beacon

Seeker có thể truy vấn Provider để biết các thông số của beacon bằng cách thực hiện thao tác ghi vào đặc điểm bao gồm một yêu cầu từ bảng 2 có mã nhận dạng dữ liệu 0x00. Nhà cung cấp xác minh rằng khoá xác thực một lần được cung cấp khớp với bất kỳ khoá tài khoản nào được lưu trữ trên thiết bị.

Nếu không xác minh được, Nhà cung cấp sẽ trả về một lỗi chưa xác thực.

Khi thành công, Nhà cung cấp sẽ thông báo bằng một phản hồi trong bảng 6 có mã nhận dạng dữ liệu 0x00. Nhà cung cấp tạo phân khúc dữ liệu như sau:

Octet Loại dữ liệu Mô tả Giá trị
0 uint8 Công suất đã hiệu chỉnh Công suất đã hiệu chỉnh nhận được ở khoảng cách 0 m (giá trị trong phạm vi [-100, 20]). Được biểu thị dưới dạng số nguyên có dấu, với độ phân giải 1 dBm.
1 – 4 uint32 Giá trị đồng hồ Giá trị đồng hồ hiện tại tính bằng giây (big endian).
5 uint8 Chọn đường cong Đường cong elip đang được dùng để mã hoá:
  • 0x00 (mặc định): SECP160R1
  • 0x01: SECP256R1 (yêu cầu quảng cáo mở rộng)
6 uint8 Thành phần Số lượng thành phần có khả năng đổ chuông:
  • 0x00: Cho biết thiết bị không đổ chuông được.
  • 0x01: Cho biết chỉ một thành phần duy nhất có khả năng đổ chuông.
  • 0x02: Cho biết rằng hai thành phần (tai nghe bên trái và bên phải) có thể đổ chuông độc lập.
  • 0x03: Cho biết 3 thành phần (tai nghe bên trái, bên phải và hộp sạc) có thể đổ chuông độc lập.
7 uint8 Khả năng đổ chuông Các lựa chọn được hỗ trợ là:
  • 0x00: Không có lựa chọn âm lượng chuông.
  • 0x01: Có thể chọn âm lượng chuông. Nếu được đặt, Nhà cung cấp phải chấp nhận và xử lý 3 mức âm lượng như được chỉ ra trong phần Thao tác đổ chuông.
8-15 mảng byte Khoảng đệm Đệm bằng 0 để mã hoá AES.

Dữ liệu phải được mã hoá bằng AES-ECB-128 bằng khoá tài khoản dùng để xác thực yêu cầu.

Phân đoạn xác thực được xác định là 8 byte đầu tiên của HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data after encryption || 0x01).

Đọc trạng thái cấp phép của beacon

Người tìm kiếm có thể truy vấn Nhà cung cấp về trạng thái cung cấp của đèn hiệu bằng cách thực hiện thao tác ghi vào đặc điểm bao gồm một yêu cầu từ bảng 2 có mã nhận dạng dữ liệu là 0x01. Nhà cung cấp xác minh rằng khoá xác thực một lần được cung cấp khớp với bất kỳ khoá tài khoản nào được lưu trữ trên thiết bị.

Nếu không xác minh được, Nhà cung cấp sẽ trả về một lỗi chưa xác thực.

Khi thành công, Nhà cung cấp sẽ thông báo bằng một phản hồi từ bảng 6 với mã nhận dạng dữ liệu 0x01. Nhà cung cấp tạo phân khúc dữ liệu như sau:

Octet Loại dữ liệu Mô tả Giá trị
0 uint8 Trạng thái cấp phép Một mặt nạ bit có các giá trị sau:
  • Bit 1 (0x01): Đặt nếu khoá nhận dạng tạm thời được đặt cho thiết bị.
  • Bit 2 (0x02): Đặt nếu khoá xác thực dùng một lần được cung cấp khớp với khoá tài khoản của chủ sở hữu.
1 – 20 hoặc 32 mảng byte Giá trị nhận dạng tạm thời hiện tại 20 hoặc 32 byte (tuỳ thuộc vào phương thức mã hoá đang được sử dụng) cho biết mã nhận dạng tạm thời hiện tại mà đèn hiệu quảng cáo, nếu có một mã nhận dạng được đặt cho thiết bị.

Phân đoạn xác thực được xác định là 8 byte đầu tiên của HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data || 0x01).

Đặt khoá nhận dạng tạm thời

Để cung cấp một Nhà cung cấp chưa được cung cấp dưới dạng một tín hiệu FHN hoặc thay đổi khoá nhận dạng tạm thời của Nhà cung cấp đã được cung cấp, Người tìm kiếm sẽ thực hiện một thao tác ghi vào đặc điểm bao gồm một yêu cầu từ bảng 2 có mã nhận dạng dữ liệu 0x02. Nhà cung cấp xác minh rằng:

  • Khoá xác thực một lần được cung cấp khớp với khoá tài khoản chủ sở hữu.
  • Nếu bạn cung cấp một hàm băm của khoá nhận dạng tạm thời, thì khoá nhận dạng tạm thời đã băm sẽ khớp với khoá nhận dạng tạm thời hiện tại.
  • Nếu bạn chưa cung cấp hàm băm của khoá nhận dạng tạm thời, hãy xác minh rằng Nhà cung cấp chưa được cung cấp dưới dạng một beacon FHN.

Nếu không xác minh được, Nhà cung cấp sẽ trả về một lỗi chưa xác thực.

Khi thành công, khoá nhận dạng tạm thời sẽ được khôi phục bằng cách giải mã AES-ECB-128 bằng khoá tài khoản đã khớp. Khoá này sẽ được duy trì trên thiết bị và kể từ thời điểm đó, Nhà cung cấp sẽ bắt đầu quảng cáo các khung FHN. Khoá nhận dạng tạm thời mới có hiệu lực ngay sau khi kết nối BLE bị chấm dứt. Nhà cung cấp thông báo bằng một phản hồi trong bảng 6 có mã dữ liệu 0x02.

Phân đoạn xác thực được xác định là 8 byte đầu tiên của HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || 0x01).

Xoá khoá nhận dạng tạm thời

Để huỷ cung cấp phần beacon của Nhà cung cấp, Người tìm kiếm sẽ thực hiện thao tác ghi vào đặc điểm, bao gồm một yêu cầu từ bảng 2 có mã nhận dạng dữ liệu 0x03. Nhà cung cấp xác minh rằng:

  • Khoá xác thực một lần được cung cấp khớp với khoá tài khoản chủ sở hữu.
  • Khoá nhận dạng tạm thời đã băm khớp với khoá nhận dạng tạm thời hiện tại.

Nếu Nhà cung cấp không được cung cấp dưới dạng một tín hiệu FHN hoặc quá trình xác minh không thành công, thì Nhà cung cấp sẽ trả về một lỗi chưa được xác thực.

Khi thành công, Nhà cung cấp sẽ quên khoá và ngừng quảng cáo các khung FHN. Nhà cung cấp thông báo bằng một phản hồi trong bảng 6 có mã nhận dạng dữ liệu là 0x03. Phân đoạn xác thực được xác định là 8 byte đầu tiên của HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || 0x01).

Đọc khoá nhận dạng tạm thời khi có sự đồng ý của người dùng

Tuỳ chọn này chỉ dùng để khôi phục khoá bị mất, vì khoá chỉ được Người tìm kiếm lưu trữ cục bộ. Do đó, chức năng này chỉ hoạt động khi thiết bị ở chế độ ghép nối hoặc trong một khoảng thời gian giới hạn sau khi người dùng nhấn nút vật lý trên thiết bị (hành động này được coi là người dùng đồng ý).

Người yêu cầu phải lưu trữ khoá khôi phục trên máy chủ phụ trợ để có thể khôi phục khoá văn bản thuần tuý, nhưng không lưu trữ chính EIK.

Để đọc EIK, Seeker thực hiện một thao tác ghi vào đặc điểm, bao gồm một yêu cầu từ bảng 3 có mã nhận dạng dữ liệu 0x04. Nhà cung cấp xác minh rằng:

  • Khoá khôi phục đã băm khớp với khoá khôi phục dự kiến.
  • Thiết bị đang ở chế độ khôi phục EIK.

Nếu không xác minh được, Nhà cung cấp sẽ trả về một lỗi chưa xác thực.

Nếu thiết bị không ở chế độ ghép nối, Nhà cung cấp sẽ trả về lỗi Không có sự đồng ý của người dùng.

Khi thành công, Nhà cung cấp sẽ thông báo bằng một phản hồi từ bảng 6 với mã nhận dạng dữ liệu 0x04.

Phân đoạn xác thực được xác định là 8 byte đầu tiên của HMAC-SHA256(recovery key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data || 0x01).

Hoạt động của Ring

Người tìm kiếm có thể yêu cầu Nhà cung cấp phát âm thanh bằng cách thực hiện thao tác ghi vào đặc điểm, bao gồm một yêu cầu từ bảng 4 có mã nhận dạng dữ liệu là 0x05. Nhà cung cấp tạo phân khúc dữ liệu như sau:

Octet Loại dữ liệu Mô tả Giá trị
0 uint8 Hoạt động của Ring Một mặt nạ bit có các giá trị sau:
  • Bit 1 (0x01): Đổ chuông bên phải
  • Bit 2 (0x02): Đổ chuông bên trái
  • Bit 3 (0x04): Trường hợp đổ chuông
  • 0xFF: Đổ chuông tất cả các thành phần
  • 0x00: Dừng đổ chuông
1 – 2 uint16 Hết giờ Thời gian chờ tính bằng deci giây. Không được bằng 0 và không được lớn hơn 10 phút.
Nhà cung cấp sử dụng giá trị này để xác định thời gian đổ chuông trước khi tự tắt tiếng. Thời gian chờ sẽ ghi đè thời gian chờ hiện tại (nếu có) nếu bất kỳ thành phần nào của thiết bị đang đổ chuông.

Nếu bạn đặt thao tác đổ chuông thành 0x00, thì thời gian chờ sẽ bị bỏ qua.
3 uint8 Âm lượng
  • 0x00: Mặc định
  • 0x01: Thấp
  • 0x02: Trung bình
  • 0x03: Cao
Ý nghĩa chính xác của các giá trị này phụ thuộc vào việc triển khai.

Sau khi nhận được yêu cầu, Nhà cung cấp sẽ xác minh rằng:

  • Khoá xác thực một lần được cung cấp khớp với khoá vòng.
  • Trạng thái được yêu cầu khớp với các thành phần có thể đổ chuông.

Nếu Nhà cung cấp không được cung cấp dưới dạng một tín hiệu FHN hoặc quá trình xác minh không thành công, thì Nhà cung cấp sẽ trả về một lỗi chưa được xác thực. Tuy nhiên, nếu Nhà cung cấp có tính năng bảo vệ chống theo dõi không mong muốn đang hoạt động và yêu cầu kích hoạt tính năng bảo vệ chống theo dõi không mong muốn có cờ xác thực bỏ qua chuông đang bật, thì Nhà cung cấp nên bỏ qua bước kiểm tra đó. Người tìm kiếm vẫn phải cung cấp dữ liệu xác thực, nhưng có thể đặt dữ liệu này thành một giá trị bất kỳ.

Khi chuông bắt đầu hoặc kết thúc, một thông báo sẽ được gửi như trong bảng 6 với mã nhận dạng dữ liệu 0x05. Nội dung của thông báo được xác định như sau:

Octet Loại dữ liệu Mô tả Giá trị
0 uint8 Trạng thái đổ chuông
  • 0x00: Đã bắt đầu
  • 0x01: Không bắt đầu hoặc dừng được (tất cả các thành phần được yêu cầu đều nằm ngoài phạm vi)
  • 0x02: Đã dừng (hết thời gian)
  • 0x03: Đã dừng (nhấn nút)
  • 0x04: Đã dừng (yêu cầu GATT)
1 uint8 Thành phần đổ chuông Một mặt nạ bit của các thành phần đang đổ chuông, như được xác định trong yêu cầu.
2 – 3 uint16 Hết giờ Thời gian còn lại để đổ chuông tính bằng phần mười giây. Nếu thiết bị đã ngừng đổ chuông, thì 0x0000 sẽ được trả về.

Phân đoạn xác thực được xác định là 8 byte đầu tiên của HMAC-SHA256(ring key, protocol major version number || the nonce used to initiate the ringing command || data ID || data length || additional data || 0x01).

Nếu thiết bị đã ở trạng thái đổ chuông theo yêu cầu khi nhận được yêu cầu đổ chuông hoặc ngừng đổ chuông, thì Nhà cung cấp phải gửi một thông báo có trạng thái đổ chuông hoặc 0x00: Đã bắt đầu hoặc 0x04: Đã dừng (yêu cầu GATT), tương ứng. Yêu cầu này sẽ ghi đè các thông số trạng thái hiện có, để có thể kéo dài thời lượng đổ chuông.

Nếu Nhà cung cấp có nút vật lý (hoặc đã bật cảm ứng), thì nút đó sẽ dừng chức năng đổ chuông nếu được nhấn trong khi chuông đang đổ.

Lấy trạng thái đổ chuông của thiết bị báo hiệu

Để biết trạng thái đổ chuông của beacon, Seeker thực hiện một thao tác ghi vào đặc điểm, bao gồm một yêu cầu từ bảng 4 có mã nhận dạng dữ liệu là 0x06. Nhà cung cấp xác minh rằng khoá xác thực một lần được cung cấp khớp với khoá vòng.

Nếu Nhà cung cấp không được cung cấp dưới dạng một tín hiệu FHN hoặc nếu quá trình xác minh không thành công, thì Nhà cung cấp sẽ trả về một lỗi chưa được xác thực.

Khi thành công, Nhà cung cấp sẽ thông báo bằng một phản hồi từ bảng 6 có mã nhận dạng dữ liệu 0x06. Nhà cung cấp tạo phân khúc dữ liệu như sau:

Octet Loại dữ liệu Mô tả Giá trị
0 uint8 Thành phần đổ chuông Các thành phần đang đổ chuông, như được xác định trong yêu cầu đổ chuông.
1 – 2 uint16 Hết giờ Thời gian còn lại để đổ chuông tính bằng phần mười giây. Xin lưu ý rằng nếu thiết bị không đổ chuông, thì 0x0000 sẽ được trả về.

Phân đoạn xác thực được xác định là 8 byte đầu tiên của HMAC-SHA256 (ring key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data || 0x01).

Chế độ bảo vệ khỏi hoạt động theo dõi không mong muốn

Chế độ bảo vệ chống hoạt động theo dõi không mong muốn được thiết kế để cho phép mọi ứng dụng xác định các thiết bị có hành vi sai trái mà không cần giao tiếp với máy chủ. Theo mặc định, Nhà cung cấp phải xoay tất cả giá trị nhận dạng như mô tả trong phần Xoay giá trị nhận dạng. Dịch vụ Trung tâm tìm thiết bị có thể chuyển tiếp yêu cầu kích hoạt chế độ bảo vệ chống theo dõi không mong muốn thông qua mạng lưới Trung tâm tìm thiết bị. Bằng cách này, dịch vụ sẽ khiến Nhà cung cấp tạm thời sử dụng một địa chỉ MAC cố định, cho phép các ứng dụng phát hiện thiết bị và cảnh báo người dùng về khả năng bị theo dõi không mong muốn.

Để kích hoạt hoặc huỷ kích hoạt chế độ bảo vệ chống theo dõi không mong muốn của thiết bị báo hiệu, Người tìm kiếm thực hiện một thao tác ghi vào đặc điểm, bao gồm một yêu cầu từ bảng 5 với mã nhận dạng dữ liệu lần lượt là 0x07 hoặc 0x08.

Khi bật chế độ bảo vệ khỏi hoạt động theo dõi không mong muốn

Nhà cung cấp tạo phân khúc dữ liệu như sau:

Octet Loại dữ liệu Mô tả Giá trị
0 uint8 Cờ kiểm soát
  • 0x01: Bỏ qua bước xác thực bằng cách đổ chuông. Khi được đặt, các yêu cầu đổ chuông sẽ không được xác thực trong chế độ bảo vệ khỏi hoạt động theo dõi không mong muốn.
Nếu không có cờ nào được đặt (byte đều là số 0), thì bạn có thể bỏ qua hoàn toàn phần dữ liệu và gửi một phần dữ liệu trống.
Các cờ này chỉ có hiệu lực cho đến khi chế độ bảo vệ chống theo dõi không mong muốn bị tắt.

Nhà cung cấp xác minh rằng khoá xác thực một lần được cung cấp khớp với khoá bảo vệ chống theo dõi không mong muốn. Nếu Nhà cung cấp không được cung cấp dưới dạng một tín hiệu FHN hoặc quy trình xác minh không thành công, thì Nhà cung cấp sẽ trả về một lỗi chưa xác thực.

Khi chế độ bảo vệ chống theo dõi không mong muốn được kích hoạt, đèn hiệu sẽ giảm tần suất xoay địa chỉ riêng tư MAC xuống còn một lần mỗi 24 giờ. Giá trị nhận dạng tạm thời được quảng cáo phải tiếp tục xoay vòng như bình thường. Bạn nên đặt loại khung thành 0x41. Trạng thái này cũng được phản ánh trong phần cờ băm.

Khi tắt chế độ bảo vệ chống theo dõi không mong muốn

Nhà cung cấp xác minh rằng:

  • Khoá xác thực một lần được cung cấp khớp với khoá bảo vệ khỏi hành vi theo dõi không mong muốn.
  • Khoá nhận dạng tạm thời đã băm khớp với khoá nhận dạng tạm thời hiện tại.

Nếu Nhà cung cấp không được cung cấp dưới dạng một tín hiệu FHN hoặc không xác minh được, thì Nhà cung cấp sẽ trả về một lỗi chưa xác thực.

Khi chế độ bảo vệ chống theo dõi không mong muốn bị tắt, beacon sẽ bắt đầu xoay địa chỉ MAC ở tốc độ bình thường trở lại, đồng bộ hoá với quá trình xoay mã nhận dạng tạm thời. Bạn nên đặt loại khung về 0x40. Trạng thái này cũng được phản ánh trong phần cờ băm.

Khi thành công, Nhà cung cấp sẽ thông báo bằng một phản hồi từ bảng 6 có mã nhận dạng dữ liệu là 0x07 hoặc 0x08.

Phân đoạn xác thực được xác định là 8 byte đầu tiên của HMAC-SHA256(unwanted tracking protection key, protocol major version number || the last nonce read from the characteristic || data ID || data length || 0x01).

Khung quảng cáo

Sau khi cung cấp, Nhà cung cấp dự kiến sẽ quảng cáo các khung FHN ít nhất một lần sau mỗi 2 giây. Nếu các khung Ghép nối nhanh được quảng cáo, Nhà cung cấp nên xen kẽ các khung FHN trong quảng cáo Ghép nối nhanh thông thường. Ví dụ: cứ 2 giây một lần, Nhà cung cấp sẽ quảng cáo 7 quảng cáo Fast Pair và 1 quảng cáo FHN.

Công suất truyền Bluetooth được thực hiện cho quảng cáo FHN phải được đặt thành ít nhất 0 dBm.

Khung FHN mang một khoá công khai dùng để mã hoá báo cáo vị trí của mọi ứng dụng hỗ trợ đóng góp cho mạng lưới tìm nguồn từ cộng đồng. Có 2 loại khoá đường cong elip: khoá 160 bit phù hợp với khung BLE 4 cũ hoặc khoá 256 bit yêu cầu BLE 5 có khả năng quảng cáo mở rộng. Phương thức triển khai của Nhà cung cấp sẽ xác định đường cong nào được dùng.

Khung FHN có cấu trúc như sau.

Octet Giá trị Mô tả
0 0x02 Chiều dài
1 0x01 Giá trị loại dữ liệu cờ
2 0x06 Dữ liệu cờ
3 0x18 hoặc 0x19 Chiều dài
4 0x16 Giá trị loại dữ liệu của dữ liệu dịch vụ
5 0xAA UUID dịch vụ 16 bit
6 0xFE ...
7 0x40 hoặc 0x41 Loại khung FHN có chỉ báo chế độ bảo vệ khỏi hành vi theo dõi không mong muốn
8..27 Giá trị nhận dạng tạm thời 20 byte
28 Cờ băm

Bảng 8: Khung FHN hỗ trợ đường cong 160 bit.

Bảng 9 cho biết giá trị và độ lệch byte cho đường cong 256 bit.

Octet Giá trị Mô tả
0 0x02 Chiều dài
1 0x01 Giá trị loại dữ liệu cờ
2 0x06 Dữ liệu cờ
3 0x24 hoặc 0x25 Chiều dài
4 0x16 Giá trị loại dữ liệu của dữ liệu dịch vụ
5 0xAA UUID dịch vụ 16 bit
6 0xFE ...
7 0x40 hoặc 0x41 Loại khung FHN có chỉ báo chế độ bảo vệ khỏi hành vi theo dõi không mong muốn
8..39 Giá trị nhận dạng tạm thời 32 byte
40 Cờ băm

Bảng 9: Khung FHN hỗ trợ đường cong 256 bit.

Tính toán giá trị nhận dạng tạm thời (EID)

Số ngẫu nhiên được tạo bằng cách mã hoá AES-ECB-256 cho cấu trúc dữ liệu sau bằng khoá nhận dạng tạm thời:

Octet Trường Mô tả
0 – 10 Khoảng đệm Giá trị = 0xFF
11 nghìn Số mũ của chu kỳ xoay
12 – 15 TS[0]...TS[3] Bộ đếm thời gian của đèn hiệu, ở định dạng 32 bit big-endian. K bit thấp nhất sẽ bị xoá.
16 – 26 Khoảng đệm Giá trị = 0x00
27 nghìn Số mũ của chu kỳ xoay
28 - 31 TS[0]...TS[3] Bộ đếm thời gian của đèn hiệu, ở định dạng 32 bit big-endian. K bit thấp nhất sẽ bị xoá.

Bảng 10: Cấu trúc của một số giả ngẫu nhiên.

Kết quả của phép tính này là một số có 256 bit, được biểu thị bằng r'.

Đối với phần còn lại của phép tính, SECP160R1 hoặc SECP256R1 được dùng cho các hoạt động mật mã đường cong elip. Xem định nghĩa về đường cong trong SEC 2: Recommended Elliptic Curve Domain Parameters (SEC 2: Các tham số miền đường cong elip được đề xuất), trong đó xác định Fp, n và G được tham chiếu tiếp theo.

r' hiện được chiếu vào trường hữu hạn Fp bằng cách tính r = r' mod n. Cuối cùng, hãy tính toán R = r * G, đây là một điểm trên đường cong biểu thị khoá công khai đang được sử dụng. Đèn hiệu quảng cáo Rx, là toạ độ x của R, làm giá trị nhận dạng tạm thời.

Cờ đã băm

Trường cờ đã băm được tính như sau (các bit được tham chiếu từ quan trọng nhất đến ít quan trọng nhất):

  • Bit 0-4: Dành riêng (đặt thành 0).
  • Các bit 5-6 cho biết mức pin của thiết bị như sau:
    • 00: Không hỗ trợ chỉ báo mức pin
    • 01: Mức pin bình thường
    • 10: Mức pin thấp
    • 11: Mức pin rất thấp (cần sớm thay pin)
  • Bit 7 được đặt thành 1 nếu thiết bị báo hiệu ở chế độ bảo vệ chống theo dõi không mong muốn và 0 nếu không.

Để tạo ra giá trị cuối cùng của byte này, hệ thống sẽ xor-ed với byte ít quan trọng nhất của SHA256(r).

Xin lưu ý rằng r phải được căn chỉnh theo kích thước của đường cong. Thêm số 0 làm các bit có nghĩa nhất nếu giá trị đại diện của khoá ngắn hơn 160 hoặc 256 bit, hoặc các bit có nghĩa nhất sẽ bị cắt bớt nếu giá trị đại diện của khoá lớn hơn 160 hoặc 256 bit.

Nếu không hỗ trợ chỉ báo mức pin và không ở chế độ bảo vệ khỏi hoạt động theo dõi không mong muốn, thì đèn hiệu được phép hoàn toàn bỏ qua byte này trong quảng cáo.

Mã hoá bằng EID

Để mã hoá một thông báo m, người phát hiện (đã đọc Rx từ beacon) sẽ làm như sau:

  1. Chọn một số ngẫu nhiên s trong Fp, như được xác định trong phần tính toán EID.
  2. Điện toán S = s * G.
  3. Tính R = (Rx, Ry) bằng cách thay thế trong phương trình đường cong và chọn một giá trị Ry tuỳ ý trong số các kết quả có thể có.
  4. Tính khoá AES 256 bit k = HKDF-SHA256((s * R)x), trong đó (s * R)x là toạ độ x của kết quả phép nhân đường cong. Chưa chỉ định salt.
  5. Giả sử URx và LRx lần lượt là 80 bit trên và dưới của Rx, ở định dạng big-endian. Tương tự, hãy xác định USx và LSx cho S.
  6. Điện toán nonce = LRx || LSx.
  7. Điện toán (m’, tag) = AES-EAX-256-ENC(k, nonce, m).
  8. Gửi (URx, Sx, m’, tag) cho chủ sở hữu, có thể thông qua một dịch vụ từ xa không tin cậy.

Giải mã các giá trị được mã hoá bằng EID

Ứng dụng của chủ sở hữu (có EIK và số mũ của khoảng thời gian xoay vòng) sẽ giải mã thông báo như sau:

  1. Với URx, hãy lấy giá trị bộ đếm thời gian của beacon mà URx dựa vào. Việc này có thể được thực hiện bằng cách tính toán các giá trị Rx của máy tính phía máy khách của chủ sở hữu cho các giá trị bộ đếm thời gian của đèn hiệu trong quá khứ gần và tương lai gần.
  2. Dựa trên giá trị bộ đếm thời gian của beacon mà URx dựa vào, hãy tính giá trị dự kiến của r như được xác định trong phần Tính toán EID.
  3. Tính toán R = r * G và xác minh xem có khớp với giá trị của URx do người phát hiện cung cấp hay không.
  4. Tính S = (Sx, Sy) bằng cách thay thế trong phương trình đường cong và chọn một giá trị Sy tuỳ ý trong số các kết quả có thể có.
  5. Tính k = HKDF-SHA256((r * S)x) trong đó (r * S)x là toạ độ x của kết quả phép nhân đường cong.
  6. Điện toán nonce = LRx || LSx.
  7. Điện toán m = AES-EAX-256-DEC(k, nonce, m’, tag).

Thay đổi định kỳ mã nhận dạng

Bạn phải sử dụng địa chỉ BLE có thể phân giải (RPA) hoặc không thể phân giải (NRPA) để quảng cáo các khung FHN. RPA là yêu cầu bắt buộc đối với các thiết bị Âm thanh năng lượng thấp (LEA) và nên dùng cho các thiết bị khác, ngoại trừ thẻ định vị không sử dụng tính năng liên kết.

Quảng cáo Ghép nối nhanh, quảng cáo FHN và(các) địa chỉ BLE tương ứng phải thay đổi đồng thời. Trung bình, quá trình xoay sẽ diễn ra sau mỗi 1024 giây. Điểm chính xác mà tại đó đèn hiệu bắt đầu quảng cáo mã nhận dạng mới phải được ngẫu nhiên hoá trong cửa sổ.

Phương pháp được đề xuất để ngẫu nhiên hoá thời gian xoay là đặt thời gian đó thành thời gian xoay dự kiến tiếp theo (nếu không áp dụng phương pháp ngẫu nhiên hoá) cộng với một hệ số thời gian ngẫu nhiên dương trong khoảng từ 1 đến 204 giây.

Khi thiết bị ở chế độ bảo vệ khỏi hoạt động theo dõi không mong muốn, địa chỉ BLE của quảng cáo FHN phải được cố định, nhưng RPA cho quảng cáo không thể phát hiện FP (chẳng hạn như Fast Pair) phải tiếp tục xoay vòng. Bạn có thể sử dụng các địa chỉ khác nhau cho các giao thức khác nhau.

Khôi phục sau khi mất điện

Việc phân giải giá trị nhận dạng tạm thời có liên quan chặt chẽ đến giá trị đồng hồ của giá trị nhận dạng đó tại thời điểm quảng cáo, vì vậy, điều quan trọng là Nhà cung cấp có thể khôi phục giá trị đồng hồ nếu có sự cố mất điện. Nhà cung cấp nên ghi giá trị đồng hồ hiện tại vào bộ nhớ không biến đổi ít nhất một lần mỗi ngày và khi khởi động, Nhà cung cấp sẽ kiểm tra NVM để xem có giá trị nào cần khởi tạo hay không. Các trình phân giải giá trị nhận dạng tạm thời sẽ triển khai quy trình phân giải trong một khoảng thời gian đủ để cho phép cả độ lệch đồng hồ hợp lý và loại khôi phục sau khi mất điện này.

Nhà cung cấp vẫn phải nỗ lực hết mình để giảm thiểu sai lệch đồng hồ, vì khung thời gian phân giải có giới hạn. Bạn nên triển khai ít nhất một phương thức đồng bộ hoá đồng hồ bổ sung (quảng cáo khung Fast Pair không thể phát hiện hoặc triển khai luồng thông báo).

Nguyên tắc triển khai tính năng Ghép nối nhanh

Phần này mô tả các khía cạnh đặc biệt của việc triển khai tính năng Ghép nối nhanh trên các Nhà cung cấp hỗ trợ FHN.

Nguyên tắc cụ thể về thiết bị định vị

  • Nếu Nhà cung cấp đã được ghép nối nhưng FHN chưa được cung cấp trong vòng 5 phút (hoặc nếu bản cập nhật OTA được áp dụng trong khi thiết bị được ghép nối nhưng chưa được cung cấp FHN), thì Nhà cung cấp sẽ quay về cấu hình ban đầu và xoá các khoá tài khoản đã lưu trữ.
  • Sau khi được ghép nối, Nhà cung cấp không được thay đổi địa chỉ MAC cho đến khi FHN được cung cấp hoặc cho đến khi 5 phút trôi qua.
  • Nếu khoá nhận dạng tạm thời bị xoá khỏi thiết bị, thiết bị sẽ đặt lại về trạng thái ban đầu và xoá cả các khoá tài khoản đã lưu.
  • Nhà cung cấp nên từ chối các lần ghép nối Bluetooth thông thường và chỉ chấp nhận ghép nối bằng tính năng Ghép nối nhanh.
  • Nhà cung cấp phải có một cơ chế cho phép người dùng tạm thời dừng quảng cáo mà không cần đặt lại thiết bị về trạng thái ban đầu (ví dụ: nhấn tổ hợp nút).
  • Sau khi mất điện, thiết bị sẽ quảng cáo các khung hình Ghép nối nhanh không thể phát hiện cho đến khi lệnh đọc các tham số của beacon được gọi tiếp theo. Nhờ đó, Thiết bị tìm kiếm có thể phát hiện thiết bị và đồng bộ hoá đồng hồ ngay cả khi đồng hồ bị lệch đáng kể.
  • Khi quảng cáo các khung Ghép nối nhanh không thể phát hiện, bạn không nên bật các chỉ báo trên giao diện người dùng.
  • Không nên quảng cáo các khung Ghép nối nhanh có thể phát hiện trong khi Nhà cung cấp được cung cấp cho FHN.
  • Nhà cung cấp không được tiết lộ bất kỳ thông tin nhận dạng nào theo cách chưa được xác thực (ví dụ: tên hoặc giá trị nhận dạng).

Nguyên tắc cụ thể theo thiết bị Bluetooth Classic

Phần này mô tả các khía cạnh đặc biệt của thiết bị Bluetooth truyền thống hỗ trợ FHN.

Cấp phép FHN cho các thiết bị đã được ghép nối

Không phải lúc nào Nhà cung cấp cũng được cấp quyền sử dụng FHN khi ghép nối với Người tìm kiếm, mà là một lúc sau đó. Trong trường hợp đó, Nhà cung cấp có thể không có địa chỉ MAC BLE mới nhất cần thiết để thiết lập kết nối GATT. Nhà cung cấp phải hỗ trợ ít nhất một trong những cách sau để Người tìm kiếm lấy địa chỉ BLE khi đã được ghép nối:

  • Nhà cung cấp có thể định kỳ quảng cáo dữ liệu tài khoản Fast Pair cho phép Thiết bị tìm kiếm tìm thấy địa chỉ BLE của thiết bị thông qua một lượt quét BLE.
    Phương pháp này phù hợp với những Nhà cung cấp không triển khai luồng tin nhắn.
  • Nhà cung cấp có thể cung cấp dữ liệu này thông qua luồng thông báo Ghép nối nhanh qua Bluetooth thông thường.
    Phương pháp này phù hợp với những Nhà cung cấp không quảng cáo khung Ghép nối nhanh khi kết nối với Thiết bị tìm kiếm qua Bluetooth.

Việc hỗ trợ cả hai phương pháp này sẽ làm tăng khả năng người dùng có thể cung cấp thiết bị cho FHN.

Luồng thông báo của tính năng Ghép nối nhanh

Nhà cung cấp có thể triển khai luồng thông báo Ghép nối nhanh và dùng luồng này để thông báo cho Người tìm kiếm về Thông tin thiết bị. Việc triển khai luồng thông báo sẽ cho phép một số tính năng như mô tả trong phần này.

Nhà cung cấp nên gửi thông báo về thông tin thiết bị mỗi khi kênh RFCOMM của luồng thông báo được thiết lập.

Phiên bản chương trình cơ sở (mã thông tin thiết bị 0x09) và khả năng theo dõi

Khi bản cập nhật chương trình cơ sở thêm tính năng hỗ trợ FHN cho Nhà cung cấp, một Thiết bị tìm kiếm được kết nối có thể thông báo cho người dùng về điều đó và đề nghị cung cấp tính năng này. Nếu không, người dùng phải chuyển đến danh sách thiết bị Bluetooth theo cách thủ công để bắt đầu quy trình cấp phép FHN.

Để cho phép điều đó, Nhà cung cấp nên sử dụng thuộc tính Phiên bản phần mềm (mã 0x09) để báo cáo một giá trị chuỗi đại diện cho phiên bản phần mềm. Ngoài ra, Nhà cung cấp phải hỗ trợ giao thức cho phép Người tìm kiếm biết về các thay đổi về Khả năng do bản cập nhật chương trình cơ sở.

Octet Loại dữ liệu Mô tả Giá trị
0 uint8 Sự kiện thông tin thiết bị 0x03
1 uint8 Phiên bản chương trình cơ sở 0x09
2 – 3 uint16 Độ dài dữ liệu bổ sung tuỳ thuộc
var mảng byte Chuỗi phiên bản tuỳ thuộc

Bảng 11: Sự kiện thông tin thiết bị: phiên bản chương trình cơ sở đã cập nhật.

Khi nhận được yêu cầu cập nhật khả năng (0x0601), nếu Nhà cung cấp đã bật tính năng hỗ trợ theo dõi FHN, thì Nhà cung cấp đó phải phản hồi như minh hoạ trong bảng 12.

Octet Loại dữ liệu Mô tả Giá trị
0 uint8 Sự kiện đồng bộ hoá khả năng của thiết bị 0x06
1 uint8 Theo dõi FHN 0x03
2 – 3 uint16 Độ dài dữ liệu bổ sung 0x0007
4 uint8 Trạng thái cấp phép FHN 0x00 nếu chưa được cung cấp; 0x01 nếu được cung cấp bởi bất kỳ tài khoản nào
5 - 10 mảng byte Địa chỉ MAC BLE hiện tại của thiết bị tuỳ thuộc

Bảng 12: Sự kiện đồng bộ hoá chức năng của thiết bị: đã thêm chức năng theo dõi.

Giá trị nhận dạng tạm thời hiện tại (mã thông tin thiết bị 0x0B)

Nhà cung cấp có thể sử dụng giá trị nhận dạng tạm thời hiện tại (mã 0x0B) để báo cáo EID và giá trị đồng hồ hiện tại khi Nhà cung cấp được cung cấp cho FHN, nhằm đồng bộ hoá Người tìm kiếm trong trường hợp đồng hồ bị lệch (ví dụ: do hết pin). Nếu không, Người tìm kiếm sẽ bắt đầu một kết nối tốn kém hơn và kém tin cậy hơn cho mục đích này.

Octet Loại dữ liệu Mô tả Giá trị
0 uint8 Sự kiện thông tin thiết bị 0x03
1 uint8 Giá trị nhận dạng tạm thời hiện tại 0x0B
2 – 3 uint16 Độ dài dữ liệu bổ sung 0x0018 hoặc 0x0024
4 – 7 mảng byte Giá trị đồng hồ Ví dụ: 0x13F9EA80
8 – 19 hoặc 31 mảng byte EID hiện tại Ví dụ: 0x1122334455667788990011223344556677889900

Bảng 13: Sự kiện thông tin thiết bị: đồng bộ hoá đồng hồ.

Đặt lại về trạng thái ban đầu

Đối với những thiết bị hỗ trợ tính năng đặt lại về trạng thái ban đầu: nếu quá trình đặt lại về trạng thái ban đầu được thực hiện, Nhà cung cấp phải ngừng phát tín hiệu và xoá khoá nhận dạng tạm thời cũng như tất cả các khoá tài khoản đã lưu trữ, bao gồm cả khoá tài khoản của chủ sở hữu.

Sau khi khôi phục cài đặt gốc (thủ công hoặc theo chương trình), Nhà cung cấp không nên bắt đầu quảng cáo tính năng Ghép nối nhanh ngay lập tức để ngăn quy trình ghép nối bắt đầu ngay sau khi người dùng xoá thiết bị.

Ngăn chặn hoạt động theo dõi không mong muốn

Các thiết bị FHN được chứng nhận cũng phải đáp ứng các yêu cầu trong phiên bản triển khai của quy cách đa nền tảng để Phát hiện thiết bị theo dõi vị trí không mong muốn (DULT).

Các nguyên tắc liên quan dành riêng cho FHN để tuân thủ quy cách DULT:

  • Mọi thiết bị tương thích với FHN đều phải được đăng ký trong Nearby Device Console và đã kích hoạt tính năng "Tìm thấy trung tâm".
  • Thiết bị phải triển khai dịch vụ và đặc điểm Không phải chủ sở hữu phụ kiện được xác định trong phiên bản triển khai của quy cách DULT, bao gồm cả các thao tác Thông tin về phụ kiện và Chế độ kiểm soát không phải chủ sở hữu.
  • Trong thời gian tương thích ngược, theo quy định trong thông số kỹ thuật DULT, không có thay đổi nào đối với khung hình được quảng cáo như quy định trong tài liệu này.
  • "Chế độ bảo vệ chống theo dõi không mong muốn" được xác định trong tài liệu này tương ứng với "trạng thái tách biệt" do quy cách DULT xác định.
  • Nguyên tắc triển khai mã thao tác Thông tin về phụ kiện:
    • Get_Product_Data phải trả về mã nhận dạng mô hình do bảng điều khiển cung cấp, được thêm số 0 để đáp ứng yêu cầu 8 byte. Ví dụ: mã nhận dạng mô hình 0xFFFFFF được trả về dưới dạng 0x0000000000FFFFFF.
    • Get_Manufacturer_Name và Get_Model_Name phải khớp với các giá trị được cung cấp trong bảng điều khiển.
    • Get_Accessory_Category có thể trả về giá trị chung "Thiết bị theo dõi vị trí" nếu không có danh mục nào khác phù hợp hơn với loại thiết bị.
    • Get_Accessory_Capabilities phải cho biết khả năng hỗ trợ đổ chuông cũng như tra cứu giá trị nhận dạng BLE.
    • Get_Network_ID phải trả về giá trị nhận dạng của Google (0x02).
  • Nguyên tắc triển khai mã lệnh Get_Identifier:
    • Thao tác này chỉ được trả về một phản hồi hợp lệ trong 5 phút sau khi người dùng kích hoạt chế độ "nhận dạng". Chế độ này yêu cầu kết hợp các lần nhấn nút. Một tín hiệu hình ảnh hoặc âm thanh phải cho người dùng biết rằng nhà cung cấp đã chuyển sang chế độ đó. Bạn phải cung cấp cho Google hướng dẫn cụ thể theo từng mẫu để kích hoạt chế độ đó như một yêu cầu để được chứng nhận và ít nhất 10 ngày trước khi có bất kỳ bản cập nhật hoặc sửa đổi nào đối với hướng dẫn.
    • Phản hồi được tạo như sau: 10 byte đầu tiên của giá trị nhận dạng tạm thời hiện tại, theo sau là 8 byte đầu tiên của HMAC-SHA256(recovery key, the truncated current ephemeral identifier).
  • Nguyên tắc triển khai Mã nhận dạng qua NFC:
    • Dùng find-my.googleapis.com/lookup làm URL.
    • Là tham số e, hãy sử dụng cùng một phản hồi như được tạo cho Get_Identifier, được mã hoá hex.
    • Là tham số pid, hãy sử dụng cùng một phản hồi như được tạo cho Get_Product_Data, được mã hoá hex.
  • Thiết bị bắt buộc phải có một bộ tạo âm thanh và hỗ trợ chức năng đổ chuông. Theo quy cách DULT, nhà sản xuất âm thanh phải phát ra âm thanh có độ lớn đỉnh tối thiểu là 60 Phon theo định nghĩa của ISO 532-1:2017.
  • Nguyên tắc triển khai mã lệnh Sound_Start:
    • Lệnh này sẽ kích hoạt chuông trong tất cả các thành phần có sẵn.
    • Bạn nên sử dụng âm lượng tối đa được hỗ trợ.
    • Thời lượng đổ chuông đề xuất là 12 giây.
  • Thiết bị theo dõi phải có một cơ chế cho phép người dùng tạm thời dừng quảng cáo mà không cần đặt lại thiết bị về trạng thái ban đầu (ví dụ: nhấn tổ hợp nút).
    • Hướng dẫn vô hiệu hoá phải được ghi lại trong một URL công khai và được cung cấp cho Google như một yêu cầu để được chứng nhận và ít nhất 10 ngày trước khi có bất kỳ nội dung cập nhật hoặc sửa đổi nào đối với hướng dẫn.
    • URL phải hỗ trợ bản địa hoá. Tuỳ thuộc vào ứng dụng, ngôn ngữ sẽ được cung cấp dưới dạng một tham số truy vấn ("hl=en") hoặc bằng cách sử dụng tiêu đề HTTP "accept-language".

Nguyên tắc về giao thức có thể chuyển đổi

  • Mỗi lần chỉ được dùng một giao thức. Đảm bảo rằng không có quá một mạng có thể hoạt động trên thiết bị cùng một lúc. Yêu cầu này là cần thiết để đảm bảo không có sự trộn lẫn dữ liệu người dùng nhạy cảm giữa các giao thức khác nhau.
  • Bạn nên tích hợp quy trình đặt lại cứng vào thiết bị để cho phép người dùng thiết lập lại thiết bị bằng một mạng khác.
  • Quá trình cập nhật thiết bị lên một mạng phải thân thiện với người dùng và công bằng giữa các mạng. Người dùng phải có thể chọn mạng mà họ muốn sử dụng mà không ưu tiên một trong các mạng. Quy trình này cần được nhóm Google phê duyệt.

Các bản cập nhật chương trình cơ sở

Đối tác phải quản lý quy trình và việc phân phối bản cập nhật OTA bằng quy trình riêng của họ trên ứng dụng di động hoặc ứng dụng web.

Fast Pair hỗ trợ gửi thông báo cho người dùng, thông báo về các bản cập nhật OTA hiện có. Để sử dụng cơ chế này:

Để ngăn chặn việc theo dõi, bạn nên hạn chế quyền truy cập vào đặc điểm Bản sửa đổi phần mềm. Trước tiên, Seeker sẽ đọc trạng thái cấp phép và cung cấp khoá xác thực (như được xác định trong quy cách này), sau đó mới đọc bản sửa đổi phần mềm. Việc này sẽ được thực hiện thông qua cùng một kết nối. Nếu có một nỗ lực đọc bản sửa đổi chương trình cơ sở và Nhà cung cấp không được liên kết cũng như không hoàn tất thành công một thao tác được xác thực qua cùng một kết nối đó, thì Nhà cung cấp sẽ trả về một lỗi chưa được xác thực.

Khả năng tương thích

Bạn phải bật dịch vụ vị trí và Bluetooth thì mới dùng được mạng lưới Trung tâm tìm thiết bị. Cần phải có dịch vụ di động hoặc kết nối Internet. Hoạt động trên hệ điều hành Android 9 trở lên tại một số quốc gia nhất định và dành cho người dùng đủ tuổi.

Nhật ký thay đổi

Phiên bản FHN Ngày Bình luận
v1 Bản phát hành đầu tiên của quy cách FHN để truy cập sớm.
v1.1 Feb 2023
  • Thêm một chỉ báo văn bản thuần tuý về chế độ bảo vệ khỏi hành vi theo dõi không mong muốn.
  • Thêm một lựa chọn để bỏ qua việc xác thực các yêu cầu đổ chuông khi ở chế độ bảo vệ khỏi hoạt động theo dõi không mong muốn.
v1.2 Tháng 4 năm 2023
  • Đã cập nhật định nghĩa về AK của chủ sở hữu.
  • Thêm đề xuất về cách khôi phục sau khi mất điện trong thẻ định vị.
  • Thêm nội dung làm rõ về tính năng ngẫu nhiên hoá địa chỉ MAC.
  • Thêm nội dung làm rõ về tính năng xoay vòng địa chỉ MAC khi ở chế độ bảo vệ khỏi hoạt động theo dõi không mong muốn.
  • Thêm một nguyên tắc về việc phải có cách vô hiệu hoá thẻ định vị.
v1.3 Tháng 12 năm 2023
  • Thêm nội dung làm rõ về thông tin nhận dạng do thẻ định vị hiển thị.
  • Đã thêm một yêu cầu để triển khai quy cách ngăn chặn hoạt động theo dõi không mong muốn.
  • Thêm nguyên tắc cho các thiết bị có giao thức có thể chuyển đổi.