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 như một phần mở rộng cho quy cách Ghép nối nhanh. 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 những thiết bị đó.

Quy cách GATT

Bạn nên thêm một đặc điểm thuộc tính chung (GATT) khác 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, Người tìm kiếm 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 sau:

Octet Loại dữ liệu Mô tả Giá trị
0 uint8 Số phiên bản lớn 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. Số chỉ dùng một lần phải không hợp lệ 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:

Vận hành

Đị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 <0 Dữ liệu khác
  • 0x00: n/a
  • 0x01: n/a
  • 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 cấp phép cho 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 cho thiết bị báo hiệu.

Octet Loại dữ liệu Mô tả Giá trị
0 uint8 Mã dữ liệu
  • 0x05: Đổ chuông
  • 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: n/a

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 <0 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 đệm bằng 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 decisecond 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 một 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 thông 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 với 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ề 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 có mã nhận dạng dữ liệu 0x00. Nhà cung cấp tạo đoạn 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 2 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, tai nghe 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 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 cấp phép của beacon bằng cách 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 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 có 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 một lần được cung cấp khớp với khoá tài khoản 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 lưu 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 hình 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 phản hồi từ bảng 6 với 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 đèn hiệu 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 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 với 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 đó, khả 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à sự đồng ý của người dù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 có 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).

Thao tác đổ chuông

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 Thao tác đổ chuông 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): Vỏ điện thoại có giá đỡ dạng vò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 phần mười giây. Không được bằng 0 và không được lớn hơn 10 phút.
Nhà cung cấp 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 thao tác đổ chuông được đặt 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ệ khỏi hoạt độ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ệ khỏi hoạt độ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 chờ)
  • 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, bạn nên trả về 0x0000.

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), 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 thiết bị theo dõi, 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 4 có mã nhận dạng dữ liệu 0x06. Nhà cung cấp xác minh rằng khoá xác thực dùng một lần được cung cấp khớp với khoá đổ 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 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 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 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 vòng tất cả giá trị nhận dạng như mô tả trong phần Xoay vòng 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 cho 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ệ khỏi hoạt động theo dõi không mong muốn của thiết bị phát tín hiệu, 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 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 quy trình 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ờ chỉ có hiệu lực cho đến khi chế độ bảo vệ chống theo dõi không mong muốn bị vô hiệu hoá.

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ì 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 sẽ 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 thể hiện 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 được xác thực.

Khi chế độ bảo vệ chống theo dõi không mong muốn bị vô hiệu hoá, đèn hiệu sẽ bắt đầu xoay địa chỉ MAC với 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. Loại khung sẽ được đặt lại thành 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 với mã nhận dạng dữ liệu 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).

Tìm chính xác

Phần này trình bày chi tiết quy trình và các thao tác bổ sung cần thiết để tìm kiếm chính xác. Các quy tắc tương tự cho đặc điểm GATT và Xác thực sẽ được áp dụng ở đây như được xác định trong phần quy cách GATT. Tính năng Tìm chính xác là không bắt buộc.

Loại tính năng tìm kiếm chính xác phụ thuộc vào loại công nghệ đo khoảng cách được hỗ trợ trên các thiết bị tham gia tìm kiếm chính xác. Bạn có thể tìm thấy các công nghệ đo khoảng cách được hỗ trợ trong quy cách Đo khoảng cách: Trình tự và tải trọng thông báo ngoài băng tần. Các phần sau sẽ khám phá loại trải nghiệm tìm kiếm chính xác mà bạn có thể mong đợi dựa trên công nghệ đo khoảng cách được sử dụng.

Quy trình Tìm chính xác

Phần này khám phá luồng thông báo FHNA cho tính năng Tìm kiếm chính xác. Hình 1 cho thấy luồng tin nhắn và các đoạn văn giải thích chi tiết hơn về từng tin nhắn.

Quy trình nhắn tin của tính năng Tìm kiếm chính xác

Hình 1 Quy trình thông báo điển hình của tính năng Tìm kiếm chính xác

Thiết bị khởi tạo là thiết bị có ứng dụng Trung tâm tìm thiết bị và nơi tính năng Tìm kiếm chính xác được bật. Thiết bị khởi tạo là thiết bị đang cố gắng tìm thiết bị khác.

Thiết bị Phản hồi là thiết bị mà thiết bị Khởi tạo đang cố gắng tìm.

Thiết bị Khởi tạo sẽ gửi thông báo Yêu cầu về khả năng đo khoảng cách đến thiết bị Phản hồi, trong đó thiết bị này sẽ liệt kê những công nghệ đo khoảng cách mà thiết bị Khởi tạo muốn tìm hiểu từ thiết bị Phản hồi. Thiết bị phản hồi sẽ trả lời bằng thông báo Phản hồi về khả năng đo khoảng cách, trong đó có thông tin về những công nghệ đo khoảng cách được hỗ trợ và khả năng của những công nghệ đó. Thiết bị phản hồi sẽ chỉ cung cấp thông tin do thiết bị khởi tạo yêu cầu. Danh sách các khả năng sẽ được sắp xếp dựa trên mức độ ưu tiên của công nghệ đo khoảng cách mà thiết bị Phản hồi ưu tiên, trong đó công nghệ đầu tiên trong danh sách có mức độ ưu tiên cao nhất.

Sau đó, thiết bị Khởi tạo sẽ tiếp tục bằng thông báo Cấu hình đo khoảng cách, trong đó thiết bị này sẽ xác định cấu hình cho từng công nghệ đo khoảng cách mà thiết bị muốn đo. Khi nhận được thông báo này, thiết bị Phản hồi phải bắt đầu đo khoảng cách cho các công nghệ hiện có bằng cách sử dụng cấu hình được cung cấp. Thiết bị phản hồi sẽ gửi lại một thông báo phản hồi Cấu hình đo khoảng cách, trong đó có kết quả về việc từng công nghệ đo khoảng cách riêng lẻ có bắt đầu thành công hay không. Một số công nghệ đo khoảng cách phải được bắt đầu trên cả thiết bị Khởi tạo và thiết bị Phản hồi để có một phiên đo khoảng cách thành công, trong khi đối với những công nghệ khác, chỉ cần bắt đầu trên thiết bị Khởi tạo, nhưng thiết bị Phản hồi vẫn phải trả lời bằng kết quả thành công cho các công nghệ đó. Bạn có thể tìm hiểu thêm về hành vi của công nghệ đo khoảng cách cụ thể trong các phần sau.

Sau khi thiết bị Khởi tạo sẵn sàng dừng phiên Tìm kiếm chính xác, thiết bị này sẽ gửi thông báo Dừng đo khoảng cách đến thiết bị phản hồi, cho biết những công nghệ đo khoảng cách nào phải dừng đo khoảng cách. Thiết bị Responder sẽ phản hồi bằng thông báo Phản hồi dừng đo khoảng cách, cho biết rằng thiết bị đã dừng đo khoảng cách thành công bằng các công nghệ đo khoảng cách được yêu cầu.

Trong trường hợp kênh giao tiếp FHNA BLE GATT bị ngắt giữa phiên Tìm kiếm chính xác, nhưng trong khi một số công nghệ đo khoảng cách vẫn đang đo khoảng cách, thiết bị phản hồi sẽ triển khai cơ chế thời gian chờ để đảm bảo rằng thiết bị không đo khoảng cách vô thời hạn. Thông tin chi tiết sẽ tuỳ thuộc vào từng trường hợp sử dụng.

Xin lưu ý rằng thiết bị phản hồi không được giả định rằng thứ tự của các thao tác sẽ luôn giống nhau. Ví dụ: thiết bị phản hồi phải có thể xử lý nhiều thao tác yêu cầu Khả năng đo khoảng cách liên tiếp, hoặc thậm chí là một thao tác Cấu hình đo khoảng cách trực tiếp mà không cần yêu cầu khả năng trước đó.

Thao tác tìm kiếm chính xác

Bảng 8 cho thấy các thao tác FHNA do tài liệu này xác định là bắt buộc đối với tính năng Tìm kiếm chính xác. Mỗi tiểu mục xác định thông báo FHNA cho từng thao tác, trong khi nội dung trường Dữ liệu bổ sung đề cập đến quy cách Phạm vi: Trình tự thông báo và tải trọng ngoài băng tần.

Hoạt động Mã dữ liệu Mô tả
Yêu cầu về khả năng đo khoảng cách 0x0A Thao tác yêu cầu về khả năng sẽ được thiết bị Khởi tạo gửi đến thiết bị Phản hồi. Nội dung dữ liệu của thao tác này sẽ liệt kê tất cả các công nghệ đo khoảng cách mà Bên khởi tạo muốn biết về thiết bị Bên phản hồi.
Phản hồi về khả năng đo khoảng cách 0x0A Đây là thông báo phản hồi cho thao tác Yêu cầu về khả năng đo khoảng cách. Nội dung này chứa thông tin về các chức năng cho từng công nghệ đo khoảng cách được hỗ trợ mà bên khởi tạo yêu cầu.
Cấu hình đo khoảng cách 0x0B Thao tác Cấu hình đo khoảng cách chứa các cấu hình cho công nghệ đo khoảng cách mà thiết bị Khởi tạo muốn bắt đầu đo khoảng cách với thiết bị Phản hồi.
Phản hồi về cấu hình phạm vi 0x0B Đây là thông báo phản hồi cho thao tác Cấu hình đo khoảng cách. Thông báo này chứa dữ liệu về việc thiết bị Phản hồi có bắt đầu đo khoảng cách thành công bằng các công nghệ đo khoảng cách được yêu cầu hay không dựa trên cấu hình được cung cấp.
RFU 0x0C Thao tác với Mã dữ liệu này không được dùng và được dành riêng cho mục đích sử dụng trong tương lai.
Dừng đo khoảng cách 0x0D Thao tác Stop Ranging (Dừng đo khoảng cách) do thiết bị Initiator gửi chứa thông tin về những công nghệ đo khoảng cách mà thiết bị Responder phải dừng đo khoảng cách.
Dừng phản hồi đo khoảng cách 0x0D Đây là phản hồi thông báo cho thao tác Dừng đo khoảng cách. Nội dung này chứa dữ liệu về việc thao tác dừng đối với công nghệ đo khoảng cách cụ thể có thành công hay không.

Bảng 8: Các thao tác tìm kiếm chính xác.

Thao tác Yêu cầu về khả năng đo khoảng cách

Bảng 9 xác định thông báo Yêu cầu về khả năng đo khoảng cách.

Octet Loại dữ liệu Mô tả Giá trị
0 uint8 Mã dữ liệu 0x0A – Thao tác Yêu cầu khả năng đo khoảng cách
1 uint8 Độ dài dữ liệu thay đổi
2 mảng byte Khoá xác thực một lần 8 byte đầu tiên của HMAC-SHA256(Khoá tài khoản, Số phiên bản chính của giao thức || số chỉ dùng một lần cuối cùng được đọc từ đặc điểm || Mã nhận dạng dữ liệu || Độ dài dữ liệu || Dữ liệu bổ sung).
10 mảng byte Dữ liệu bổ sung Thông báo Yêu cầu về khả năng đo khoảng cách như được xác định trong quy cách Đo khoảng cách: Trình tự và tải trọng thông báo ngoài băng tần (cả tiêu đề và tải trọng)

Bảng 9: Yêu cầu về khả năng đo khoảng cách.

Thao tác Phản hồi về khả năng đo khoảng cách

Bảng 10 xác định thông báo Phản hồi về khả năng đo khoảng cách.

Octet Loại dữ liệu Mô tả Giá trị
0 uint8 Mã dữ liệu 0x0A: Phản hồi về khả năng đo khoảng cách
1 uint8 Độ dài dữ liệu thay đổi
2 mảng byte Khoá xác thực một lần 8 byte đầu tiên của HMAC-SHA256(Khoá tài khoản, Số phiên bản chính của giao thức || số chỉ dùng một lần cuối cùng được đọc từ đặc điểm || Mã nhận dạng dữ liệu || Độ dài dữ liệu || Dữ liệu bổ sung || 0x01).
10 mảng byte Dữ liệu bổ sung Thông báo Phản hồi về khả năng đo khoảng cách như được xác định trong quy cách Đo khoảng cách: Trình tự thông báo và tải trọng ngoài băng tần (cả tiêu đề và tải trọng)

Bảng 10: Phản hồi về khả năng đo khoảng cách.

Thao tác Cấu hình đo khoảng cách

Bảng 11 xác định thông báo Cấu hình đo khoảng cách.

Octet Loại dữ liệu Mô tả Giá trị
0 uint8 Mã dữ liệu 0x0B – Đặt cấu hình đo khoảng cách
1 uint8 Độ dài dữ liệu thay đổi
2 mảng byte Khoá xác thực một lần 8 byte đầu tiên của HMAC-SHA256(Khoá tài khoản, Số phiên bản chính của giao thức || số chỉ dùng một lần cuối cùng được đọc từ đặc điểm || Mã nhận dạng dữ liệu || Độ dài dữ liệu || Dữ liệu bổ sung).
10 mảng byte Dữ liệu bổ sung Thông báo Cấu hình đo khoảng cách như được xác định trong quy cách Đo khoảng cách: Trình tự thông báo ngoài băng tần và tải trọng (cả tiêu đề và tải trọng)

Bảng 11: Cấu hình đo khoảng cách.

Thao tác Phản hồi cấu hình đo khoảng cách

Bảng 12 xác định thông báo Phản hồi cấu hình đo khoảng cách.

Octet Loại dữ liệu Mô tả Giá trị
0 uint8 Mã dữ liệu 0x0B – Set Ranging Configuration Response (Đặt phản hồi cấu hình đo khoảng cách)
1 uint8 Độ dài dữ liệu thay đổi
2 mảng byte Khoá xác thực một lần 8 byte đầu tiên của HMAC-SHA256(Khoá tài khoản, Số phiên bản chính của giao thức || số chỉ dùng một lần cuối cùng được đọc từ đặc điểm || Mã nhận dạng dữ liệu || Độ dài dữ liệu || Dữ liệu bổ sung || 0x01).
10 mảng byte Dữ liệu bổ sung Thông báo Phản hồi cấu hình đo khoảng cách như được xác định trong quy cách Đo khoảng cách: Trình tự và tải trọng thông báo ngoài băng tần (cả tiêu đề và tải trọng)

Bảng 12: Phản hồi về cấu hình đo khoảng cách.

Dừng thao tác đo khoảng cách

Bảng 13 xác định thông báo Dừng phạm vi.

Octet Loại dữ liệu Mô tả Giá trị
0 uint8 Mã dữ liệu 0x0D – Ranging Stop (Dừng đo khoảng cách)
1 uint8 Độ dài dữ liệu thay đổi
2 mảng byte Khoá xác thực một lần 8 byte đầu tiên của HMAC-SHA256(Khoá tài khoản, Số phiên bản chính của giao thức || số chỉ dùng một lần cuối cùng được đọc từ đặc điểm || Mã nhận dạng dữ liệu || Độ dài dữ liệu).
10 mảng byte Dữ liệu bổ sung Thông báo Stop Ranging như được xác định trong quy cách Ranging: Out-of-band message sequence and payload (cả tiêu đề và tải trọng)

Bảng 13: Dừng đo khoảng cách.

Dừng thao tác Phản hồi phạm vi

Bảng 14 xác định thông báo Phản hồi ngừng đo khoảng cách.

Octet Loại dữ liệu Mô tả Giá trị
0 uint8 Mã dữ liệu 0x0D – Phản hồi dừng đo khoảng cách
1 uint8 Độ dài dữ liệu thay đổi
2 mảng byte Khoá xác thực một lần 8 byte đầu tiên của HMAC-SHA256(Khoá tài khoản, Số phiên bản chính của giao thức || số chỉ dùng một lần cuối cùng được đọc từ đặc điểm || Mã nhận dạng dữ liệu || Độ dài dữ liệu || Dữ liệu bổ sung || 0x01).
10 mảng byte Dữ liệu bổ sung Thông báo Stop Ranging Response (Ngừng phản hồi đo khoảng cách) như được xác định trong quy cách Đo khoảng cách: Trình tự và tải trọng thông báo ngoài băng tần (cả tiêu đề và tải trọng)

Bảng 14: Dừng phản hồi trong phạm vi.

Tính năng chống theo dõi ngoài ý muốn có khả năng tìm kiếm chính xác

Khi chế độ bảo vệ khỏi hoạt động theo dõi không mong muốn được kích hoạt (như mô tả trong phần bảo vệ khỏi hoạt động theo dõi không mong muốn), quy trình áp dụng cho việc bỏ qua các bước kiểm tra xác thực đối với tin nhắn đổ chuông cũng áp dụng cho tất cả tin nhắn Tìm kiếm chính xác được xác định trong tài liệu này cho những thiết bị muốn hỗ trợ tính năng này.

Thông tin cụ thể về Công nghệ đo khoảng cách cho tính năng Tìm kiếm chính xác

Phần này chứa thông tin chi tiết cụ thể về công nghệ đo khoảng cách.

Thông tin cụ thể về băng tần siêu rộng (UWB)

Thông tin cụ thể về UWB.

Mức độ chính xác của tính năng Tìm chính xác

Các phiên Tìm chính xác sử dụng UWB làm công nghệ đo khoảng cách có thể thấy cả thông tin về khoảng cách và hướng. Khoảng thời gian đo khoảng cách cần tối thiểu là 240 mili giây, nên dùng 96 mili giây để có hướng dẫn tối ưu.

Mã cấu hình

Dữ liệu cấu hình ngoài băng tần được trao đổi cho UWB không chứa đầy đủ các thông số có thể định cấu hình mà UWB yêu cầu để bắt đầu phiên đo khoảng cách UWB. Một số tham số được chọn ngầm định theo mã nhận dạng cấu hình đã chọn.

Mỗi mã nhận dạng cấu hình là một tập hợp các thông số cấu hình UWB được xác định trước và được công khai ghi lại. Đối với trường hợp sử dụng Tìm kiếm chính xác, thiết bị phản hồi phải hỗ trợ mã nhận dạng cấu hình 6 và có thể hỗ trợ mã nhận dạng cấu hình 3.

Bộ khởi đầu và bộ phản hồi UWB

Đối với trường hợp sử dụng tính năng Tìm chính xác, thiết bị được ghi nhận là thiết bị Khởi tạo trong tài liệu này sẽ là thiết bị phản hồi UWB và thiết bị được ghi nhận là thiết bị Phản hồi trong tài liệu này sẽ là thiết bị khởi tạo UWB. Điều này là do thiết bị khởi tạo UWB tiêu thụ ít điện năng hơn thiết bị phản hồi UWB và trong hầu hết các trường hợp, thiết bị Phản hồi sẽ là một thiết bị ngoại vi có pin hạn chế.

Điều này có nghĩa là thiết bị Phản hồi cần cho biết rằng thiết bị này hỗ trợ vai trò của thiết bị khởi tạo UWB trong thông báo Phản hồi về khả năng đo khoảng cách.

  • Phải hỗ trợ kênh 9
  • Để có hướng dẫn tối ưu, bạn nên sử dụng khoảng thời gian đo khoảng cách là 96 mili giây, nếu không thì phải hỗ trợ 240 mili giây.
  • Bạn nên dùng khoảng thời gian khe là 1 mili giây để tiết kiệm pin, nhưng hệ thống cũng hỗ trợ khoảng thời gian 2 mili giây.
  • Chip UWB phải tuân thủ ít nhất FIRA phiên bản 1.2 + P-STS.
  • BPRF là thông số bắt buộc, HPRF là thông số không bắt buộc nhưng nên dùng. Chế độ được hỗ trợ hoặc được chọn do chỉ mục phần mở đầu được hỗ trợ hoặc được chọn xác định.
  • Loại bảo mật phiên: P-STS
Thông tin cụ thể về BLE Channel Sounding (CS)

Thông tin cụ thể về BLE CS.

Mức độ chính xác của tính năng Tìm chính xác

Các phiên Tìm chính xác sử dụng CS làm công nghệ đo khoảng cách sẽ chỉ đo khoảng cách, hiện không cung cấp thông tin về hướng.

Yêu cầu liên kết giữa các thiết bị

Các phiên Tìm kiếm chính xác sử dụng tính năng Đo kênh sẽ không hoạt động nếu các thiết bị không được liên kết. Bạn cần có mối liên kết hiện có giữa thiết bị khởi tạo và thiết bị phản hồi. Quy cách này không cung cấp cách tạo mối liên kết giữa các thiết bị. Thay vào đó, nhà phát triển trường hợp sử dụng sẽ thiết lập mối liên kết này giữa các thiết bị.

Bên phản hồi cần hành động đối với CS

Không giống như UWB, nơi cả hai thiết bị đều phải gọi API bắt đầu đo khoảng cách và dừng đo khoảng cách UWB một cách rõ ràng, đối với CS, chỉ thiết bị khởi tạo mới phải bắt đầu đo khoảng cách CS bằng cách gọi ngăn xếp Bluetooth, phần còn lại của quá trình khởi tạo ở phía thiết bị phản hồi sẽ diễn ra trong băng tần bằng Bluetooth (BT). Điều này có nghĩa là khi nhận được thông báo Ranging Configuration (Cấu hình đo khoảng cách) hoặc Stop Ranging (Ngừng đo khoảng cách) cho CS, bên phản hồi không cần làm gì nếu đã bật BT, ngoài việc trả lời bằng thông báo Ranging Configuration Response (Phản hồi cấu hình đo khoảng cách). Thiết bị phản hồi có thể sử dụng những thông báo đó làm tín hiệu kích hoạt để cập nhật giao diện người dùng khi có màn hình, hoặc bất kể có màn hình hay không, thiết bị phản hồi có thể được dùng để phản hồi bằng hình ảnh về trạng thái của thiết bị, ví dụ: nhấp nháy đèn LED của thiết bị.

RTT NAN Wi-Fi

Thông tin cụ thể về RTT NAN Wi-Fi.

Mức độ chính xác của tính năng Tìm chính xác

Các phiên Tìm chính xác sử dụng Wi-Fi NAN RTT làm công nghệ đo khoảng cách sẽ chỉ đo khoảng cách, hiện tại không cung cấp thông tin về hướng.

RSSI BLE

Thông tin cụ thể về RSSI BLE.

Mức độ chính xác của tính năng Tìm chính xác

Các phiên Tìm kiếm chính xác chỉ sử dụng BLE RSSI làm công nghệ đo khoảng cách sẽ không thể nhận được thông tin về khoảng cách hoặc hướng, do BLE RSSI không phải là công nghệ đo khoảng cách chính xác. Thay vào đó, người dùng sẽ thấy hướng dẫn cho biết thiết bị ở gần hoặc ở xa.

Khung hình được 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 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 Ghép nối nhanh 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 được bất kỳ ứng dụng khách hỗ trợ nào sử dụng để mã hoá báo cáo vị trí. Ứng dụng khách này đóng góp cho mạng lưới tìm nguồn dữ liệu 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. Việc triển khai của Nhà cung cấp sẽ xác định đường cong nào được sử dụng.

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

Octet Giá trị Mô tả
0 0x02 Độ dài
1 0x01 Giá trị loại dữ liệu cờ
2 0x06 Dữ liệu cờ
3 0x18 hoặc 0x19 Độ 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ệ chống 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 15: Khung FHN hỗ trợ đường cong 160 bit.

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

Octet Giá trị Mô tả
0 0x02 Độ dài
1 0x01 Giá trị loại dữ liệu cờ
2 0x06 Dữ liệu cờ
3 0x24 hoặc 0x25 Độ 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ệ chống 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 16: 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 big-endian 32 bit. 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 big-endian 32 bit. K bit thấp nhất sẽ bị xoá.

Bảng 17: 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 thay pin sớm)
  • 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 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 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ì beacon đượ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ừ đèn hiệu) 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) 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 Rx giá trị 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).

Xoay vòng 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 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 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 xoay vòng cùng một lúc. Trung bình, quá trình xoay vòng phải diễn ra sau mỗi 1024 giây. Điểm chính xác mà đè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ế độ Chố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ư Ghép nối nhanh) 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ó mối liên hệ chặt chẽ với 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 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à tại thời điểm 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 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 Ghép nối nhanh 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 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 đèn hiệu được gọi tiếp theo. Điều này cho phép Thiết bị tìm kiếm 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 có hỗ trợ FHN.

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

Nhà cung cấp không phải lúc nào cũng được cấp quyền truy cập vào FHN khi ghép nối với Người tìm kiếm, nhưng sau đó một thời gian thì có. 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 Ghép nối nhanh 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 quá trình quét BLE.
    Cách tiếp cận này phù hợp với những Nhà cung cấp không triển khai luồng thông báo.
  • 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 truyền 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 thông tin thiết bị mỗi khi thiết lập Luồng thông báo.

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 cung cấp FHN.

Để cho phép điều đó, Nhà cung cấp phải sử dụng thuộc tính Phiên bản chương trình cơ sở (mã 0x09) để báo cáo một giá trị chuỗi đại diện cho phiên bản chương trình cơ sở. 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 18: 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ư 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 19: Sự kiện đồng bộ hoá khả năng của thiết bị: đã thêm khả 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 giá trị EID và đồ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 pin yếu). 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 20: 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 người dùng đặt lại về trạng thái ban đầu, 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 đặt lại về trạng thái ban đầu (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 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 nhiều 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 định nghĩa trong quy cách DULT, không có thay đổi nào đối với khung hình được quảng cáo như định nghĩa 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 mã 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:
    • Sử 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, bộ tạo â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 nên 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 đồng thời trên thiết bị. Bạn cần phải đáp ứng yêu cầu này để đả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 các bản cập nhật qua mạng (OTA) bằng quy trình làm việc của riêng họ trên ứng dụng di động hoặc ứng dụng web.

Tính năng Ghép nối nhanh 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, quyền truy cập vào đặc điểm Bản sửa đổi chương trình cơ sở cần bị hạn chế. Trước tiên, Seeker sẽ đọc trạng thái cung cấp và cung cấp khoá xác thực, như được xác định trong quy cách này, rồi sau đó mới đọc bản sửa đổi chương trình cơ sở. 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

Cần phải bật dịch vụ vị trí và Bluetooth để sử dụng 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 ban đầu của quy cách FHN để tiếp cận 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ó thể chuyển đổi giao thức.