Ta strona została przetłumaczona przez Cloud Translation API.

Specyfikacja akcesoriów sieciowych Znajdź moje urządzenie

v1.3

Specyfikacja akcesoriów w sieci Znajdź moje urządzenie (FMDN) definiuje w pełni szyfrowaną metodę śledzenia urządzeń z technologią Bluetooth Low Energy (BLE). Na tej stronie opisujemy FMDN jako rozszerzenie specyfikacji Szybkie parowanie. Dostawcy powinni włączać to rozszerzenie, jeśli mają urządzenia zgodne z FMDN i chcą włączyć na nich śledzenie lokalizacji.

Specyfikacja GATT

Do usługi szybkiego parowania należy dodać dodatkową cechę atrybutu ogólnego (GATT) o tej semantyce:

Charakterystyka usługi szybkiego parowania	Zaszyfrowano	Uprawnienia	UUID
Działania typu beacon	Nie	Odczyt, zapis i powiadomienie	`FE2C1238-8366-4814-8EB0-01DE32100BEA`

Tabela 1. Charakterystyka usługi Szybkie parowanie w FMDN.

Uwierzytelnianie

Operacje wymagane przez to rozszerzenie są wykonywane jako operacja zapisu zabezpieczona mechanizmem typu test-odpowiedź. Przed wykonaniem żadnej operacji powinien on wykonać operację odczytu na podstawie cechy w tabeli 1, co spowoduje utworzenie bufora w takim formacie:

Oktet	Typ danych	Opis	Wartość
0	uint8	Numer wersji głównej protokołu	0x01
1–8	tablica bajtów	Jednorazowa losowa liczba jednorazowa	różni się

Każda operacja odczytu powinna skutkować inną liczbą jednorazową, a jedna taka wartość powinna być prawidłowa tylko w przypadku jednej operacji. Liczba jednorazowa musi zostać unieważniona nawet wtedy, gdy operacja się nie powiedzie.

Moduł wyszukiwania oblicza następnie jednorazowy klucz uwierzytelniania, który zostanie użyty w kolejnym żądaniu zapisu. Klucz uwierzytelniania jest obliczany zgodnie z opisem w tabelach 2–5. W zależności od żądanej operacji wnioskodawca potwierdza znajomość co najmniej jednego z tych kluczy:

Klucz konta: 16-bajtowy klucz konta Szybkie parowanie zgodnie ze specyfikacją Szybkiego parowania.

Klucz do konta właściciela: gdy użytkownik po raz pierwszy uzyskuje dostęp do cechy działań Beacon, dostawca wybiera jeden z dotychczasowych kluczy konta jako klucz konta właściciela. Wybranego klucza konta właściciela nie można zmienić, dopóki dostawca nie zostanie przywrócony do ustawień fabrycznych. Dostawca nie może usuwać klucza konta właściciela, gdy skończą się wolne przedziały kluczy konta.

Dostawcy, którzy obsługują już FMDN przy pierwszym sparowaniu (lub obsługują ją po przywróceniu ustawień fabrycznych), wybierają pierwszy klucz konta, ponieważ jest to jedyny istniejący klucz konta, gdy aplikacja Seeker odczytuje stan udostępniania podczas parowania.
Dostawcy, którzy obsługują FMDN po sparowaniu urządzenia (np. w wyniku aktualizacji oprogramowania), mogą wybrać dowolny dotychczasowy klucz konta. Rozsądnie można wybrać pierwszy klucz konta, który będzie używany do odczytywania stanu udostępniania na podstawie czynności beaconu po aktualizacji oprogramowania, przy założeniu, że użytkownik, który wykonał aktualizację, jest obecnym właścicielem dostawcy.

Efemeryczny klucz tożsamości (EIK): 32-bajtowy klucz wybierany losowo przez osobę wyszukującą podczas procesu udostępniania FMDN. Ten klucz służy do generowania kluczy kryptograficznych używanych do pełnego szyfrowania raportów o lokalizacji. Seeker nigdy nie ujawnia go dla backendu.

Klucz odzyskiwania: zdefiniowany jako SHA256(ephemeral identity key || 0x01), skrócony do pierwszych 8 bajtów. Klucz jest przechowywany w backendzie. Za pomocą go instruktora może odzyskać EIK, o ile użytkownik wyrazi zgodę, naciskając przycisk na urządzeniu.
Klucz pierścieniowy: zdefiniowany jako SHA256(ephemeral identity key || 0x02), obcięty do pierwszych 8 bajtów. Klucz jest przechowywany w backendzie, a poszukiwacz może go używać tylko do dzwonienia na urządzeniu.
Niechciany klucz ochrony śledzenia: zdefiniowany jako SHA256(ephemeral identity key || 0x03), obcięty do pierwszych 8 bajtów. Klucz jest przechowywany w backendzie, a poszukiwacz może go użyć tylko do aktywowania trybu ochrony przed niechcianym śledzeniem.

Operacje

Format danych zapisanych na cechy jest podany w tabelach 2–5. Każda operacja została szczegółowo omówiona w dalszej części tej sekcji.

Oktet	Typ danych	Opis	Wartość
0	uint8	Identyfikator danych	0x00: odczyt parametrów obrazu typu beacon 0x01: Odczytywanie stanu obsługi administracyjnej 0x02: ustawianie efemerycznego klucza tożsamości 0x03: wyczyść efemeryczny klucz tożsamości
1	uint8	Długość danych	różni się
2–9	tablica bajtów	Jednorazowy klucz uwierzytelniania	Pierwsze 8 bajtów pliku `HMAC-SHA256(account key, protocol major version number \|\| the last nonce read from the characteristic \|\| data ID \|\| data length \|\| additional data)`
10 – var	tablica bajtów	Dodatkowe dane	0x00: nie dotyczy 0x01: nie dotyczy 0x02: 32 bajty to efemeryczny klucz tożsamości, AES-ECB-128 szyfrowany kluczem konta. Jeśli dostawca ma już zestaw efemerycznych kluczy tożsamości, wyślij też pierwsze 8 bajtów funkcji `SHA256(current ephemeral identity key \|\| the last nonce read from the characteristic)` 0x03: pierwsze 8 bajtów pola `SHA256(ephemeral identity key \|\| the last nonce read from the characteristic)`

Tabela 2. Prośba o utworzenie obrazu typu beacon.

Oktet	Typ danych	Opis	Wartość
0	uint8	Identyfikator danych	0x04: odczyt efemerycznego klucza tożsamości za zgodą użytkownika
1	uint8	Długość danych	0x08
2–9	tablica bajtów	Jednorazowy klucz uwierzytelniania	Pierwsze 8 bajtów pliku `HMAC-SHA256(recovery key, protocol major version number \|\| the last nonce read from the characteristic \|\| data ID \|\| data length)`

Tabela 3. Prośba o przywrócenie klucza przez Beacon.

Oktet	Typ danych	Opis	Wartość
0	uint8	Identyfikator danych	0x05: Dzwonek 0x06: Odczytywanie stanu dzwonienia
1	uint8	Długość danych	różni się
2–9	tablica bajtów	Jednorazowy klucz uwierzytelniania	Pierwsze 8 bajtów pliku `HMAC-SHA256(ring key, protocol major version number \|\| the last nonce read from the characteristic \|\| data ID \|\| data length \|\| additional data)`
10 – var	tablica bajtów	Dodatkowe dane	0x05: 4 bajty wskazujące stan dzwonienia, czas dzwonienia i głośność dzwonienia. 0x06: nie dotyczy

Tabela 4. Żądanie dzwonienia.

Oktet	Typ danych	Opis	Wartość
0	uint8	Identyfikator danych	0x07: Aktywowanie trybu ochrony przed niechcianym śledzeniem 0x08: Dezaktywuj tryb ochrony przed niechcianym śledzeniem
1	uint8	Długość danych	różni się
2–9	tablica bajtów	Jednorazowy klucz uwierzytelniania	Pierwsze 8 bajtów pliku `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	tablica bajtów	Dodatkowe dane	0x07: 1 bajt flag sterujących (opcjonalnie) 0x08: pierwsze 8 bajtów pola `SHA256(ephemeral identity key \|\| the last nonce read from the characteristic)`

Tabela 5. Prośba o ochronę przed niechcianym śledzeniem.

Powiadomienia dotyczące aktywatorów zostały zapisane zgodnie z tabelą 6.

Powiadomienia o identyfikatorze danych innym niż 0x05: zmiana stanu dzwonienia powinny być wysyłane przed zakończeniem transakcji zapisu, która powoduje wysłanie powiadomienia, czyli przed wysłaniem PDU odpowiedzi na żądanie zapisu.

Oktet	Typ danych	Opis	Wartość
0	uint8	Identyfikator danych	0x00: odczyt parametrów obrazu typu beacon 0x01: Odczytywanie stanu obsługi administracyjnej 0x02: ustawianie efemerycznego klucza tożsamości 0x03: wyczyść efemeryczny klucz tożsamości 0x04: odczyt efemerycznego klucza tożsamości za zgodą użytkownika 0x05: Zmiana stanu dzwonka 0x06: Odczytywanie stanu dzwonienia 0x07: Aktywowanie trybu ochrony przed niechcianym śledzeniem 0x08: Dezaktywuj tryb ochrony przed niechcianym śledzeniem
1	uint8	Długość danych	różni się
2–9	tablica bajtów	Uwierzytelnianie	Szczegółowy dla operacji
10 – var	tablica bajtów	Dodatkowe dane	0x00: 8 bajtów wskazujących moc transmisji, wartość zegara, metodę szyfrowania i możliwości dzwonienia, kod AES-ECB-128 zaszyfrowany kluczem konta (bez dopełniania) 0x01: 1 bajt wskazujący stan udostępniania, po którym następuje bieżący identyfikator tymczasowy (20 lub 32 bajty), jeśli ma to zastosowanie. 0x04: 32 bajty to efemeryczny klucz tożsamości, AES-ECB-128 szyfrowany kluczem konta 0x05: 4 bajty wskazujące nowy stan i aktywator zmiany 0x06: 3 bajty wskazujące komponenty, które aktywnie dzwonią, i liczbę decysekund do końca dzwonienia Inne identyfikatory danych używają pustych danych dodatkowych

Tabela 6. Odpowiedź usługi Beacon.

W tabeli 7 znajdziesz listę możliwych kodów błędów GATT zwracanych przez operacje.

Kod	Opis	Uwagi
0x80	Nieuwierzytelnione	Zwracana w odpowiedzi na żądanie zapisu w przypadku niepowodzenia uwierzytelnienia (łącznie z użyciem starej liczby jednorazowej).
0x81	Nieprawidłowa wartość	Zwracana, gdy podasz nieprawidłową wartość lub odebrane dane mają nieoczekiwaną liczbę bajtów.
0x82	Brak zgody użytkownika	Zwracany w odpowiedzi na żądanie zapisu z identyfikatorem danych 0x04: odczyt efemerycznego klucza tożsamości za zgodą użytkownika, gdy urządzenie nie jest w trybie parowania.

Tabela 7. Kody błędów GATT.

Odczyt parametru beaconu

Poszukiwacz może wysłać zapytanie do dostawcy o parametry beaconu, wykonując operację zapisu na cechy składającej się z żądania z tabeli 2 o identyfikatorze danych 0x00. Dostawca sprawdza, czy podany klucz jednorazowego uwierzytelniania pasuje do dowolnego z kluczy konta zapisanych na urządzeniu.

Jeśli weryfikacja się nie powiedzie, dostawca zwróci nieuwierzytelniony błąd.

Po powodzeniu dostawca powiadamia o tym, wysyłając odpowiedź z tabeli 6 o identyfikatorze danych 0x00. Dostawca skonstruuje segment danych w następujący sposób:

Oktet	Typ danych	Opis	Wartość
0	uint8	Skalibrowane zasilanie	Skalibrowana moc otrzymana w punkcie 0 (wartość z zakresu [-100, 20]). Wartość reprezentowana jako liczba całkowita ze znakiem o rozdzielczości 1 dBm.
1–4	uint32	Wartość zegara	Bieżąca wartość zegara w sekundach (big endian).
5	uint8	Wybór krzywej	Krzywa eliptyczna używana do szyfrowania: 0x00 (domyślnie): SECP160R1 0x01: SECP256R1 (wymaga rozszerzonego wyświetlania reklam)
6	uint8	Komponenty	Liczba komponentów, które mogą dzwonić: 0x00: oznacza, że urządzenie nie może dzwonić. 0x01: wskazuje, że tylko jeden komponent może dzwonić. 0x02: oznacza, że 2 komponenty – lewa i prawa słuchawka – mogą dzwonić niezależnie. 0x03: oznacza, że 3 komponenty – lewa i prawa słuchawka oraz etui mogą dzwonić niezależnie.
7	uint8	Funkcje dzwonienia	Obsługiwane opcje: 0x00: wybór głośności dzwonka jest niedostępny. 0x01: dostępna jest głośność dzwonka. Jeśli zasada jest skonfigurowana, dostawca musi zaakceptować i obsługiwać 3 poziomy głośności zgodnie z opisem w sekcji operacja dzwonienia.
8-15	tablica bajtów	Dopełnienie	Brak dopełnienia w przypadku szyfrowania AES.

Dane powinny być zaszyfrowane za pomocą klucza konta AES-ECB-128 używanego do uwierzytelniania żądania.

Segment uwierzytelniania to pierwsze 8 bajtów danych HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data after encryption || 0x01).

Odczytywanie stanu obsługi beaconu

Poszukiwacz może wysłać zapytanie do dostawcy o stan udostępniania beaconu, wykonując operację zapisu do cechy składającej się z żądania z tabeli 2 o identyfikatorze danych 0x01. Dostawca sprawdza, czy podany klucz jednorazowego uwierzytelniania pasuje do dowolnego z kluczy konta zapisanych na urządzeniu.

Jeśli weryfikacja się nie powiedzie, dostawca zwróci nieuwierzytelniony błąd.

Po powodzeniu dostawca powiadamia o tym, wysyłając odpowiedź z tabeli 6 o identyfikatorze danych 0x01. Dostawca skonstruuje segment danych w następujący sposób:

Oktet	Typ danych	Opis	Wartość
0	uint8	Stan obsługi administracyjnej	Maska bitowa o tych wartościach: Bit 1 (0x01): ustaw, jeśli dla urządzenia ustawiono efemeryczny klucz tożsamości. Bit 2 (0x02): ustaw, jeśli podany klucz jednorazowego uwierzytelniania pasuje do klucza konta właściciela.
1-20 lub 32	tablica bajtów	Bieżący identyfikator efemeryczny	20 lub 32 bajty (w zależności od używanej metody szyfrowania) wskazujące bieżący identyfikator tymczasowy rozgłaszany przez beacon, jeśli został on ustawiony dla urządzenia.

Ustaw efemeryczny klucz tożsamości

Aby udostępnić Dostawcy bez obsługi administracyjnej jako beacon FMDN lub zmienić efemeryczny klucz tożsamości już udostępnionego dostawcy, mechanizm wyszukiwania wykonuje operację zapisu na cechy składającej się z żądania z tabeli 2 o identyfikatorze danych 0x02. Dostawca sprawdza, czy:

Podany klucz jednorazowego uwierzytelniania pasuje do klucza konta właściciela.
Jeśli podano hasz efemerycznego klucza tożsamości, zaszyfrowany efemeryczny klucz tożsamości pasuje do bieżącego efemerycznego klucza tożsamości.
Jeśli nie podano skrótu efemerycznego klucza tożsamości, sprawdź, czy dostawca nie został już udostępniony jako beacon FMDN.

Jeśli weryfikacja się nie powiedzie, dostawca zwróci nieuwierzytelniony błąd.

Po zakończeniu operacji efemeryczny klucz tożsamości jest odszyfrowywany przez AES-ECB-128 przy użyciu dopasowanego klucza konta. Klucz powinien być zapisany na urządzeniu i od tego momentu Dostawca powinien rozpocząć reklamowanie ramek FMDN. Nowy efemeryczny klucz tożsamości zaczyna działać natychmiast po zakończeniu połączenia BLE. Dostawca powiadamia o tym z tabeli 6 o identyfikatorze danych 0x02.

Segment uwierzytelniania to pierwsze 8 bajtów danych HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || 0x01).

Wyczyść efemeryczny klucz tożsamości

Aby cofnąć udostępnianie przez dostawcę części obrazu typu beacon, użytkownik przeprowadza operację zapisu w ramach tej cechy, składając żądanie z tabeli 2 o identyfikatorze danych 0x03. Dostawca sprawdza, czy:

Podany klucz jednorazowego uwierzytelniania pasuje do klucza konta właściciela.
Zaszyfrowany efemeryczny klucz tożsamości pasuje do bieżącego efemerycznego klucza tożsamości.

Jeśli dostawca nie jest udostępniony jako beacon FMDN lub weryfikacja się nie powiedzie, zostanie zwrócony nieuwierzytelniony błąd.

Po powodzeniu Dostawca zapomina klucz i przestaje wyświetlać reklamy ramek FMDN. Dostawca powiadamia o tym z tabeli 6 o identyfikatorze danych 0x03. Segment uwierzytelniania to pierwsze 8 bajtów danych HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || 0x01).

Odczytywanie efemerycznego klucza tożsamości za zgodą użytkownika

Ta opcja jest dostępna tylko w przypadku utraty utraconego klucza, ponieważ jest on przechowywany tylko lokalnie przez osobę wyszukującą. Dlatego ta funkcja jest dostępna tylko wtedy, gdy urządzenie jest w trybie parowania lub przez pewien czas po naciśnięciu fizycznego przycisku na urządzeniu (co stanowi zgodę użytkownika).

Poszukiwacz musi zapisać klucz odzyskiwania w backendzie, aby móc go odzyskać, ale nie przechowuje samego EIK.

Aby odczytać EIK, Seeker wykonuje operację zapisu w obrębie tej cechy, spójną z żądania z tabeli 3 o identyfikatorze danych 0x04. Dostawca sprawdza, czy:

Zaszyfrowany klucz odzyskiwania jest zgodny z oczekiwanym kluczem odzyskiwania.
Urządzenie jest w trybie przywracania EIK.

Jeśli weryfikacja się nie powiedzie, dostawca zwróci nieuwierzytelniony błąd.

Jeśli urządzenie nie jest w trybie parowania, Dostawca zwraca błąd „Brak zgody użytkownika”.

Po zakończeniu dostawca wysyła powiadomienie z odpowiedzią z tabeli 6 o identyfikatorze danych 0x04.

Segment uwierzytelniania to pierwsze 8 bajtów danych HMAC-SHA256(recovery key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data || 0x01).

Dzwonek

Poszukiwacz może poprosić dostawcę o odtworzenie dźwięku, wykonując operację zapisu na tym obiekcie – żądanie z tabeli 4 o identyfikatorze danych 0x05. Dostawca skonstruuje segment danych w następujący sposób:

Oktet	Typ danych	Opis	Wartość
0	uint8	Dzwonek	Maska bitowa o tych wartościach: Bit 1 (0x01): dzwonienie w prawo Bit 2 (0x02): dzwonek w lewo Bit 3 (0x04): obudowa pierścieniowa 0xFF: dzwonienie wszystkich komponentów 0x00: Wyłącz dzwonek
1–2	uint16	Czas oczekiwania	Limit czasu w decysekundach. Nie może wynosić zero ani być większe niż równowartość 10 minut. Dostawca używa tej wartości do określenia, jak długo ma dzwonić przed wyciszeniem. Jeśli dowolny komponent urządzenia już dzwoni, limit czasu zastępuje ten, który już obowiązuje. Jeśli operacja dzwonienia ma wartość 0x00, limit czasu jest ignorowany.
3	uint8	Głośność	0x00: domyślny 0x01: niski 0x02: średni 0x03: wysoki Dokładne znaczenie tych wartości zależy od implementacji.

Po otrzymaniu żądania Dostawca sprawdza, czy:

Podany klucz jednorazowego uwierzytelniania pasuje do klucza Ring.
Żądany stan pasuje do komponentów, które mogą dzwonić.

Jeśli dostawca nie jest udostępniony jako beacon FMDN lub weryfikacja się nie powiedzie, zostanie zwrócony nieuwierzytelniony błąd. Jeśli jednak dostawca ma aktywną ochronę przed niechcianym śledzeniem, a w wywołanym żądaniu tej ochrony była włączona flaga uwierzytelniania polegającego na pomijaniu, dostawca powinna pominąć to sprawdzanie. Dane uwierzytelniania nadal powinny być dostarczane przez poszukiwacza, ale można je ustawić na dowolną wartość.

Po rozpoczęciu lub zakończeniu dzwonienia wysyłane jest powiadomienie, jak podano w tabeli 6 o identyfikatorze danych 0x05. Treść powiadomienia jest określona w następujący sposób:

Oktet	Typ danych	Opis	Wartość
0	uint8	Stan dzwonienia	0x00: rozpoczęto 0x01: nie można uruchomić lub zatrzymać (wszystkie żądane komponenty są poza zakresem) 0x02: zatrzymano (przekroczenie limitu czasu) 0x03: zatrzymano (naciśnięcie przycisku) 0x04: zatrzymane (żądanie GATT)
1	uint8	Komponenty dzwonienia	Maska bitowa aktywnych komponentów, zgodnie z definicją w żądaniu.
2–3	uint16	Czas oczekiwania	Pozostały czas dzwonienia w sekundach. Jeśli urządzenie przestało dzwonić, powinien zwrócić wartość 0x0000.

Segment uwierzytelniania to pierwsze 8 bajtów danych HMAC-SHA256(ring key, protocol major version number || the nonce used to initiate the ringing command || data ID || data length || additional data || 0x01).

Jeśli po otrzymaniu żądania dzwonienia urządzenie jest już w żądanym stanie dzwonienia, dostawca powinien wysłać powiadomienie ze stanem dzwonienia albo odpowiednio 0x00: rozpoczęte lub 0x04: zatrzymane (żądanie GATT). To żądanie zastępuje parametry obecnego stanu, co pozwala wydłużyć czas dzwonienia.

Jeśli dostawca ma przycisk fizyczny (lub włączony jest wykrywanie dotyku), jego naciśnięcie powinno zatrzymywać funkcję dzwonienia w czasie, gdy dzwonek jest aktywny.

Pobieranie stanu dzwonienia beaconu

Aby uzyskać stan dzwonienia beaconu, poszukiwacz wykonuje operację zapisu dla cechy, składając żądanie z tabeli 4 o identyfikatorze danych 0x06. Dostawca sprawdza, czy podany klucz jednorazowego uwierzytelniania pasuje do klucza testowego.

Jeśli dostawca nie jest udostępniony jako beacon FMDN lub jeśli weryfikacja się nie powiedzie, dostawca zwróci nieuwierzytelniony błąd.

Po zakończeniu dostawca powiadamia o tym, wysyłając odpowiedź z tabeli 6 o identyfikatorze danych 0x06. Dostawca skonstruuje segment danych w następujący sposób:

Oktet	Typ danych	Opis	Wartość
0	uint8	Komponenty dzwonienia	Komponenty, które aktywnie dzwonią, zgodnie z definicją w żądaniu dzwonka.
1–2	uint16	Czas oczekiwania	Pozostały czas dzwonienia w sekundach. Pamiętaj, że jeśli urządzenie nie dzwoni, powinno zwrócić 0x0000.

Segment uwierzytelniania to pierwsze 8 bajtów danych HMAC-SHA256 (ring key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data || 0x01).

Tryb ochrony przed niechcianym śledzeniem

Tryb ochrony przed niechcianym śledzeniem ma umożliwiać każdemu klientowi identyfikowanie urządzeń naruszających zasady bez komunikacji z serwerem. Domyślnie dostawca powinien przeprowadzić rotację wszystkich identyfikatorów zgodnie z opisem w sekcji Rotacja identyfikatorów. Usługa Znajdź moje urządzenie może przekazywać niechciane żądanie aktywacji trybu ochrony przed śledzeniem przez sieć usługi Znajdź moje urządzenie. W ten sposób dostawca tymczasowo używa stałego adresu MAC, co pozwala klientom wykrywać urządzenie i ostrzegać użytkownika o możliwym niechcianym śledzeniu.

Aby włączyć lub wyłączyć niechciany tryb ochrony przed śledzeniem przez beacon, poszukiwacz wykonuje operację zapisu dla cechy, składając żądanie z tabeli 5 o identyfikatorze danych 0x07 lub 0x08.

W przypadku włączania trybu ochrony przed niechcianym śledzeniem

Dostawca skonstruuje segment danych w następujący sposób:

Oktet	Typ danych	Opis	Wartość
0	uint8	Flagi kontrolne	0x01: pominięcie uwierzytelniania dzwonka. Jeśli zasada jest skonfigurowana, w trybie ochrony przed niechcianym śledzeniem żądania przychodzące nie są uwierzytelniane. Jeśli nie ustawiasz żadnej flagi (bajt to same zera), można całkowicie pominąć sekcję danych i wysłać pustą sekcję danych. Flagi będą działać tylko do momentu wyłączenia trybu ochrony przed niechcianym śledzeniem.

Dostawca sprawdza, czy podany klucz jednorazowego uwierzytelniania pasuje do niechcianego klucza ochrony śledzenia. Jeśli dostawca nie jest udostępniony jako beacon FMDN lub weryfikacja się nie powiedzie, zostanie zwrócony nieuwierzytelniony błąd.

Gdy włączony jest tryb ochrony przed niechcianym śledzeniem, sygnał typu beacon powinien ograniczyć częstotliwość rotacji adresu prywatnego MAC do raz na 24 godziny. Reklamowany identyfikator efemeryczny powinien się zmieniać jak zwykle. Jako typ ramki należy ustawić 0x41. Stan jest też widoczny w sekcji flag zahaszowanej.

Gdy wyłączysz tryb ochrony przed niechcianym śledzeniem

Dostawca sprawdza, czy:

Podany klucz jednorazowego uwierzytelniania pasuje do klucza ochrony przed niechcianym śledzeniem.
Zaszyfrowany efemeryczny klucz tożsamości pasuje do bieżącego efemerycznego klucza tożsamości.

Jeśli dostawca nie jest udostępniony jako beacon FMDN lub weryfikacja się nie powiedzie, dostawca zwróci nieuwierzytelniony błąd.

Po wyłączeniu trybu ochrony przed niechcianym śledzeniem beacon powinien ponownie zacząć obracać adres MAC ze normalną szybkością, synchronizowane z efemeryczną rotacją identyfikatora. Należy ustawić format ramki z powrotem na 0 x 40. Stan jest też widoczny w sekcji flag zahaszowanych.

Jeśli operacja się uda, dostawca powiadomi Cię z odpowiedzią z tabeli 6 o identyfikatorze danych 0x07 lub 0x08.

Segment uwierzytelniania to pierwsze 8 bajtów danych HMAC-SHA256(unwanted tracking protection key, protocol major version number || the last nonce read from the characteristic || data ID || data length || 0x01).

Reklamowane ramki

Po udostępnieniu dostawca powinien rozgłaszać ramki FMDN co najmniej raz na 2 sekundy. Jeśli ramki Szybkiego parowania są rozgłaszane, dostawca powinien przeplatać ramki FMDN ze zwykłymi reklamami Szybkiego parowania. Na przykład co 2 sekundy Dostawca powinien reklamować 7 reklam z funkcją Szybkie parowanie i 1 reklamę FMDN.

Ramka FMDN zawiera klucz publiczny służący do szyfrowania raportów o lokalizacji przez dowolnego klienta obsługującego dane, który przyczynia się do tworzenia sieci crowdsourcingu. Dostępne są 2 rodzaje kluczy krzywych eliptycznych: 160-bitowy klucz pasujący do starszych klatek BLE 4 klatek i 256-bitowy klucz wymagający BLE 5 z rozszerzonymi możliwościami wyświetlania reklam. Implementacja dostawcy określa, która krzywa jest używana.

Oto struktura ramki FMDN.

Oktet	Wartość	Opis
0	0x02	Długość
1	0x01	Wartość typu danych flag
2	0x06	Dane dotyczące zgłoszeń
3	0x18 lub 0x19	Długość
4	0x16	Wartość typu danych usługi
5	0xAA	16-bitowy identyfikator UUID usługi
6	0xFE	...
7	0x40 lub 0x41	Typ ramki FMDN ze wskazaniem trybu ochrony przed niepożądanym śledzeniem
8..27		20-bajtowy identyfikator efemeryczny
28		Zaszyfrowane flagi

Tabela 8. Ramka FMDN obsługująca 160-bitową krzywą.

Tabela 9 zawiera przesunięcia bajtów i wartości dla 256-bitowej krzywej.

Oktet	Wartość	Opis
0	0x02	Długość
1	0x01	Wartość typu danych flag
2	0x06	Dane dotyczące zgłoszeń
3	0x24 lub 0x25	Długość
4	0x16	Wartość typu danych usługi
5	0xAA	16-bitowy identyfikator UUID usługi
6	0xFE	...
7	0x40 lub 0x41	Typ ramki FMDN ze wskazaniem trybu ochrony przed niepożądanym śledzeniem
8,,39		32-bajtowy identyfikator efemeryczny
40		Zaszyfrowane flagi

Tabela 9. Ramka FMDN obsługująca 256-bitową krzywą.

Obliczanie identyfikatora efemerycznego (EID)

W przypadku algorytmu AES-ECB-256 kod losowy jest szyfrowany za pomocą efemerycznego klucza tożsamości w następującej strukturze danych:

Oktet	Zaawansowana	Opis
0–10	Dopełnienie	Wartość = 0xFF
11	K	Wykładnik okresu rotacji
12–15	TS[0]...TS[3]	Licznik czasu beaconu w 32-bitowym formacie bigendian. Najmniejsze bity są wyczyszczone.
16–26	Dopełnienie	Wartość = 0x00
27	K	Wykładnik okresu rotacji
28–31	TS[0]...TS[3]	Licznik czasu beaconu w 32-bitowym formacie bigendian. Najmniejsze bity są wyczyszczone.

Tabela 10. Konstrukcja liczby pseudolosowej.

Wynikiem tego obliczenia jest 256-bitowa liczba oznaczona jako r'.

W pozostałych obliczeniach do operacji kryptograficznych krzywych eliptycznych służą SECP160R1 lub SECP256R1. Definicje krzywych znajdziesz w dokumencie SEC 2: zalecane parametry domeny krzywych eliptycznych, które określają parametry Fp, n i G wymienione poniżej.

r' jest teraz prognozowany w polu skończonym Fp przez obliczenie r = r' mod n. Na koniec oblicz R = r * G, który jest punktem na krzywej reprezentującym używany klucz publiczny. Beacon reklamuje jako swój identyfikator efemeryczny parametr Rx, który jest współrzędną x obiektu R.

Zaszyfrowane flagi

Wartość w polu zahaszowanych flag jest obliczana w ten sposób (do bitów odwołuje się od najbardziej do najmniej istotnej):

Bity 0–4: zarezerwowane (ustawione na zera).
Bity 5–6 wskazują poziom baterii urządzenia w ten sposób:
- 00: brak obsługi wskaźnika poziomu baterii
- 01: Normalny poziom baterii
- 10: słaba bateria
- 11: Bardzo niski poziom baterii (wymagana wkrótce wymiana)
Bit 7 ma wartość 1, jeśli beacon jest w trybie ochrony przed niechcianym śledzeniem, albo 0, jeśli nie jest.

Aby wygenerować ostateczną wartość tego bajtu, zostaje on przekształcony w parametr xor przy użyciu najmniejszego bajtu wartości SHA256(r).

Pamiętaj, że r należy wyrównać do rozmiaru krzywej. Dodaj zera jako najbardziej istotne bity, jeśli ich reprezentacja jest krótsza niż 160 lub 256 bitów. Jeśli jej reprezentacja jest większa niż 160 lub 256 bitów, powinna zostać skrócona.

Jeśli beacon nie obsługuje wskaźnika poziomu baterii i nie działa w trybie ochrony przed niechcianym śledzeniem, może całkowicie pomijać ten bajt w reklamie.

Szyfrowanie za pomocą EID

Aby zaszyfrować wiadomość m, osoba, która widziała Rx z beaconu, może wykonać te czynności:

Wybierz losową liczbę s w parametrze Fp, jak określono w sekcji Obliczanie identyfikatorów EID.
Oblicz S = s * G.
Oblicz R = (Rx, Ry), podstawiając równanie krzywej i wybierając dowolną wartość Ry z możliwych wyników.
Oblicz 256-bitowy klucz AES k = HKDF-SHA256((s * R)x), gdzie (s * R)x to współrzędna x wyniku mnożenia krzywej. Nie określono soli.
Niech URx i LRx będą odpowiednio górnymi i dolnymi 80-bitami Rx w formacie bigendian. W podobny sposób definiują USx i LSx dla S.
Oblicz nonce = LRx || LSx.
Oblicz (m’, tag) = AES-EAX-256-ENC(k, nonce, m).
Wyślij (URx, Sx, m’, tag) do właściciela, prawdopodobnie za pomocą niezaufanej usługi zdalnej.

Odszyfrowywanie wartości zaszyfrowanych za pomocą EID

Klient właściciela, który posiada EIK i wykładnik okresu rotacji, odszyfrowuje wiadomość w ten sposób:

Dla parametru URx uzyskaj wartość licznika czasu beaconu, na podstawie której obliczana jest wartość URx. Może to zrobić przez klienta właściciela, który oblicza wartości Rx dla wartości licznika czasu beaconu z niedalekiej przyszłości i niedalekiej przyszłości.
Biorąc pod uwagę wartość licznika czasu beaconu, na której opiera się parametr URx, oblicz przewidywaną wartość r zgodnie z definicją w sekcji Obliczanie identyfikatorów EID.
Oblicz wartość R = r * G i sprawdź zgodność z wartością URx podaną przez osobę.
Oblicz S = (Sx, Sy), podstawiając równanie krzywej i wybierając dowolną wartość Sy z możliwych wyników.
Oblicz k = HKDF-SHA256((r * S)x), gdzie (r * S)x to współrzędna x wyniku mnożenia krzywej.
Oblicz nonce = LRx || LSx.
Oblicz m = AES-EAX-256-DEC(k, nonce, m’, tag).

Rotacja identyfikatorów

W przypadku ramek FMDN musi być używany rozpoznawalny (RPA) lub nietrwały (NRPA) adres BLE. RPA jest wymagany w przypadku urządzeń LE Audio (LEA) i zalecany w przypadku innych urządzeń z wyjątkiem tagów lokalizatora, które nie używają powiązań.

Reklamy korzystające z Szybkiego parowania, reklamy FMDN i odpowiadające im adresy BLE powinny być wyświetlane naprzemiennie w tym samym czasie. Obrót powinien odbywać się średnio co 1024 sekundy. Dokładny punkt, w którym beacon zaczyna reklamować nowy identyfikator, musi być losowy w obrębie okna.

Zalecanym sposobem randomizacji czasu rotacji jest ustawienie go na następny przewidywany czas rotacji (jeśli nie zastosowano randomizacji czasu) plus dodatni wynikowy współczynnik czasu z zakresu od 1 do 204 sekund.

Gdy urządzenie działa w trybie ochrony przed niechcianym śledzeniem, adres BLE reklamy FMDN powinien być naprawiony, ale RPA w przypadku niewykrywalnych reklam w FP (np. Szybkie parowanie) musi się zmieniać. Dozwolone są różne adresy dla różnych protokołów.

Przywracanie po utracie zasilania

Rozpoznawanie identyfikatora efemerycznego jest silnie powiązane z wartością zegara w momencie wyświetlenia reklamy, dlatego ważne jest, aby Dostawca mógł przywrócić swoją wartość zegarową w przypadku utraty zasilania. Zaleca się, aby dostawca co najmniej raz dziennie zapisywał bieżącą wartość zegara w pamięci nieulotnej. Podczas rozruchu dostawca sprawdza, czy dostępna jest wartość, która służy do zainicjowania. Algorytmy rozpoznawania efemerycznego identyfikatora implementowałyby rozdzielczość w określonym przedziale czasu, zapewniającą zarówno uzasadniony dryf zegara, jak i ten typ odzyskiwania utraconych energii.

Usługodawcy powinni dołożyć wszelkich starań, aby zminimalizować dryfy zegara, ponieważ przedział czasu na rozwiązanie problemu jest ograniczony. Należy zaimplementować co najmniej 1 dodatkową metodę synchronizacji zegara (reklamę niewykrywalnych ramek Szybkiego parowania lub zaimplementowanie strumienia wiadomości).

Wytyczne dotyczące wdrażania Szybkiego parowania

W tej sekcji opisano specjalne aspekty implementacji Szybkiego parowania w przypadku dostawców obsługujących FMDN.

Wskazówki dotyczące tagów lokalizatora

Jeśli Dostawca był sparowany, ale FMDN nie został udostępniony w ciągu 5 minut (lub jeśli aktualizacja OTA została zastosowana podczas sparowania urządzenia, ale nie było obsługiwane przez FMDN), Dostawca powinien przywrócić konfigurację fabryczną i wyczyścić zapisane klucze konta.
Po sparowaniu dostawcy nie powinien on zmieniać swojego adresu MAC, dopóki nie zostanie udostępniony FMDN lub nie upłynie 5 minut.
Jeśli efemeryczny klucz tożsamości zostanie usunięty z urządzenia, powinno ono zostać przywrócone do ustawień fabrycznych oraz wyczyścić zapisane klucze konta.
Dostawca powinien odrzucać zwykłe próby parowania Bluetooth i akceptować tylko parowanie za pomocą Szybkiego parowania.
Dostawca musi mieć mechanizm, który umożliwia użytkownikom tymczasowe zatrzymanie wyświetlania reklam bez przywracania ustawień fabrycznych na urządzeniu (np. przez naciśnięcie kombinacji przycisków).
Po utracie zasilania urządzenie powinno rozgłaszać niewykrywalne ramki Szybkiego parowania do czasu następnego wywołania odczytów parametrów beaconu. Dzięki temu poszukiwacz może wykryć urządzenie i zsynchronizować zegar, nawet jeśli wystąpiła znaczna różnica w danych.
W przypadku reklamowania niewykrywalnych ramek Szybkiego parowania nie należy włączać powiadomień interfejsu.
Wykrywalne ramki Szybkiego parowania nie powinny być reklamowane, gdy dostawca zapewnia obsługę FMDN.
Dostawca nie powinien ujawniać żadnych informacji umożliwiających identyfikację (np. nazw lub identyfikatorów) w sposób nieuwierzytelniony.

Wytyczne dla poszczególnych urządzeń Bluetooth

W tej sekcji opisujemy szczególne aspekty klasycznych urządzeń Bluetooth, które obsługują FMDN.

Obsługa FMDN dla już sparowanych urządzeń

Dostawca nie zawsze ma dostęp do FMDN podczas parowania z Poszukiwaczem, ale jakiś czas później. W takim przypadku dostawca może nie mieć aktualnego adresu MAC BLE, który jest wymagany do nawiązania połączenia GATT. Dostawca musi obsługiwać co najmniej jeden z tych sposobów, aby uzyskać adres BLE, gdy jest on sparowany:

Dostawca może okresowo rozgłaszać dane konta w ramach Szybkiego parowania, co pozwala szukającym znaleźć adres BLE za pomocą skanowania BLE.
To podejście jest odpowiednie dla dostawców, którzy nie implementują strumienia wiadomości.
Dostawca może dostarczyć te dane za pomocą strumienia wiadomości w ramach Szybkiego parowania przez klasyczną wersję Bluetooth.
Ta metoda jest odpowiednia dla dostawców, którzy nie reklamują ramek Szybkiego parowania po połączeniu z Poszukiwaczem przez Bluetooth.

Wykorzystanie obu metod zwiększa szanse, że użytkownik będzie w stanie obsługiwać urządzenie na potrzeby FMDN.

Strumień wiadomości w Szybkim parowaniu

Dostawca może wdrożyć strumień wiadomości w ramach Szybkiego parowania i użyć go do powiadamiania osoby wyszukującej o informacjach o urządzeniu. Wdrożenie strumienia wiadomości umożliwia włączenie niektórych funkcji opisanych w tej sekcji.

Dostawca powinien wysyłać komunikaty z informacjami o urządzeniu po każdym utworzeniu kanału RFCOMM strumienia wiadomości.

Wersja oprogramowania (kod informacji o urządzeniu 0x09) i możliwość śledzenia

Gdy w ramach aktualizacji oprogramowania system dodaje obsługę FMDN u dostawcy, połączony poszukiwacz może powiadomić o tym użytkownika i zaoferować jego obsługę. W przeciwnym razie użytkownik będzie musiał ręcznie przejść do listy urządzeń Bluetooth, aby zainicjować obsługę administracyjną FMDN.

Aby to umożliwić, dostawca powinien użyć właściwości Wersja oprogramowania układowego (kod 0x09) do zgłaszania wartości ciągu znaków reprezentującej wersję oprogramowania. Dodatkowo dostawca powinien obsługiwać protokół, który informuje osobę wyszukującą o zmianach możliwości w wyniku aktualizacji oprogramowania.

Oktet	Typ danych	Opis	Wartość
0	uint8	Zdarzenie dotyczące informacji o urządzeniu	0x03
1	uint8	Wersja oprogramowania	0x09
2–3	uint16	Dodatkowa długość danych	różni się
var	tablica bajtów	Ciąg znaków wersji	różni się

Tabela 11. Zdarzenie dotyczące informacji o urządzeniu: aktualizacja wersji oprogramowania.

Jeśli po otrzymaniu żądania aktualizacji możliwości (0x0601) dostawca włączył obsługę śledzenia FMDN, powinien odpowiedzieć, jak pokazano w tabeli 12.

Oktet	Typ danych	Opis	Wartość
0	uint8	Zdarzenie synchronizacji możliwości urządzenia	0x06
1	uint8	Śledzenie FMDN	0x03
2–3	uint16	Dodatkowa długość danych	0x0007
4	uint8	Stan obsługi FMDN	0x00, jeśli nie ma obsługi administracyjnej; 0x01, jeśli udostępnianie jest obsługiwane przez dowolne konto
5–10	tablica bajtów	Aktualny adres MAC urządzenia BLE	różni się

Tabela 12. Zdarzenie synchronizacji możliwości urządzenia: dodatkowa możliwość śledzenia.

Obecny identyfikator efemeryczny (kod informacji o urządzeniu 0x0B)

Dostawca może używać aktualnego identyfikatora efemerycznego (kod 0x0B) do raportowania bieżącego identyfikatora EID i wartości zegara, gdy dostawca udostępnia FMDN, w celu synchronizacji wnioskodawcy w przypadku odchylenia zegara (np. z powodu rozładowania baterii). W przeciwnym razie Seeker inicjuje w tym celu droższe i mniej niezawodne połączenie.

Oktet	Typ danych	Opis	Wartość
0	uint8	Zdarzenie dotyczące informacji o urządzeniu	0x03
1	uint8	Bieżący identyfikator efemeryczny	0 x 0 mld
2–3	uint16	Dodatkowa długość danych	0x0018 lub 0x0024
4–7	tablica bajtów	Wartość zegara	Przykład: 0x13F9EA80
8-19 lub 31	tablica bajtów	Bieżący identyfikator EID	Przykład: 0x1122334455667788990011223344556677889900

Tabela 13. Zdarzenie dotyczące informacji z urządzenia: synchronizacja zegara.

Przywrócono ustawienia fabryczne

W przypadku urządzeń, które obsługują resetowanie do ustawień fabrycznych, po przywróceniu ustawień fabrycznych dostawca musi zatrzymać sygnalizowanie i wyczyścić tymczasowy klucz tożsamości oraz wszystkie zapisane klucze konta, w tym klucz konta właściciela.

Po przywróceniu ustawień fabrycznych (ręcznym lub automatycznym) dostawca nie powinien od razu rozpocząć wyświetlania reklam Szybkiego parowania, aby zapobiec rozpoczęciu procesu parowania natychmiast po usunięciu urządzenia przez użytkownika.

Zapobieganie niechcianemu śledzeniu

Certyfikowane urządzenia FMDN muszą też spełniać wymagania przedstawione w wersji implementacji specyfikacji międzyplatformowej wykrywania niechcianych lokalizatorów lokalizacji (DULT).

Wskazówki dotyczące zgodności z FMDN, aby zapewnić zgodność ze specyfikacją DULT:

Każde urządzenie zgodne z FMDN musi być zarejestrowane w konsoli urządzeń w pobliżu i mieć włączoną funkcję „Znajdź moje urządzenie”.
Urządzenie musi implementować usługę niebędącą właścicielem akcesorium oraz cechę zdefiniowaną w implementacji specyfikacji DULT, w tym operacje związane z informacjami o akcesoriach i elementami sterującymi nienależącymi do właściciela.
W okresie zgodności wstecznej, zgodnie z definicją w specyfikacji DULT, rozgłaszana ramka nie zmienia się zgodnie z definicją w tym dokumencie.
„Tryb ochrony przed niechcianym śledzeniem” zdefiniowany w tym dokumencie jest mapowany na „stan oddzielony” zdefiniowany w specyfikacji DULT.
Wytyczne dotyczące wdrażania kodów operacyjnych Accessory Information (Informacje o akcesoriach):
- Atrybut Get_Product_Data powinien zwracać identyfikator modelu podany przez konsolę, z zerem dopełniającym, aby spełnić wymaganie dotyczące 8 bajtów. Na przykład identyfikator modelu 0xFFFFFF jest zwracany jako 0x0000000000FFFFFF.
- Wartości Get_Manufacturer_Name i Get_Model_Name powinny być zgodne z wartościami podanymi w konsoli.
- Jeśli żadna inna kategoria lepiej nie pasuje do typu urządzenia, metoda get_Accessory_Category może zwracać ogólną wartość „Location Tracker”.
- Get_Accessory_Capabilities musi określać obsługę dzwonienia i wyszukiwania identyfikatora BLE.
- Get_Network_ID powinna zwracać identyfikator Google (0x02).
Wskazówki dotyczące implementacji kodu operacyjnego Get_Identifier:
- Operacja powinna zwracać prawidłową odpowiedź tylko przez 5 minut po aktywowaniu przez użytkownika trybu „identyfikacji”, który wymaga kombinacji naciśnięć przycisku. Sygnał wizualny lub dźwiękowy powinien informować użytkownika, że dostawca włączył dany tryb. Instrukcje aktywowania tego trybu na potrzeby konkretnego modelu należy przekazać Google w ramach wymogu certyfikacji oraz co najmniej 10 dni przed aktualizacją lub modyfikacją instrukcji.
- Odpowiedź składa się z pierwszych 10 bajtów bieżącego identyfikatora efemerycznego, po których następuje pierwsze 8 bajtów pola HMAC-SHA256(recovery key, the truncated current ephemeral identifier).
Wytyczne dotyczące implementacji kodu operacyjnego Sound_Start:
- To polecenie powinno aktywować dzwonienie we wszystkich dostępnych komponentach.
- Należy użyć maksymalnej obsługiwanej głośności.
- Zalecany czas dzwonienia to 12 sekund.
Tagi lokalizatora muszą zawierać mechanizm, który umożliwia użytkownikom tymczasowe zatrzymanie wyświetlania reklam bez przywracania ustawień fabrycznych (np. przez naciśnięcie kombinacji przycisków).
- Instrukcje dotyczące wyłączania muszą być udokumentowane pod publicznie dostępnym adresem URL i przekazane Google jako wymagane do uzyskania certyfikatu oraz co najmniej 10 dni przed aktualizacją lub zmianą instrukcji.
- Adres URL powinien obsługiwać lokalizację. W zależności od klienta język jest dostarczany jako parametr zapytania („hl=pl”) lub za pomocą nagłówka HTTP „Accept-language”.

Wytyczne dotyczące protokołów przełączania

Można używać tylko jednego protokołu naraz. Upewnij się, że na urządzeniu może działać tylko jedna sieć. Ten wymóg jest niezbędny, aby mieć pewność, że poufne dane użytkownika nie mieszają się między różnymi protokołami.
Zalecamy wdrożenie na urządzeniu procedury twardego resetu, która umożliwi użytkownikowi ponowne skonfigurowanie urządzenia w innej sieci.
Proces aktualizowania urządzenia do sieci powinien być przyjazny dla użytkownika i równy dla różnych sieci. Użytkownik musi mieć możliwość wybrania sieci, z której chce korzystać, nie preferując żadnej z nich. Ta procedura musi zostać zatwierdzona przez zespół Google.

Aktualizacje oprogramowania

Procesem i dystrybucją aktualizacji OTA powinien zarządzać partner przy użyciu własnego przepływu pracy związanego z aplikacją mobilną lub internetową.

Zgodność

Sieć usługi Znajdź moje urządzenie wymaga włączenia usług lokalizacyjnych i Bluetootha. Wymaga zasięgu sieci komórkowej lub połączenia z internetem. Działa na Androidzie 9 i nowszych oraz w niektórych krajach.

Historia zmian

Wersja FMDN	Data	Komentarz
v1		Pierwsze wydanie specyfikacji FMDN z możliwością wcześniejszego dostępu.
v1.1	luty 2023 r.	Dodaliśmy jawny opis trybu ochrony przed niechcianym śledzeniem. Dodaliśmy opcję pomijania uwierzytelniania żądań dzwonka w trybie ochrony przed niechcianym śledzeniem.
v1.2	kwiecień 2023 r.	Zaktualizowano definicję hasła AK właściciela. Dodaliśmy rekomendację dotyczącą odzyskiwania energii po utracie zasilania w tagach lokalizatora. Dodaliśmy wyjaśnienie dotyczące randomizacji adresów MAC. Dodaliśmy wyjaśnienie dotyczące rotacji adresów MAC w trybie ochrony przed niechcianym śledzeniem. Dodaliśmy wskazówkę dotyczącą dezaktywacji tagu lokalizatora.
v1.3	grudzień 2023 r.	Dodaliśmy doprecyzowanie identyfikacji informacji udostępnianych przez tagi lokalizatora. Dodaliśmy wymóg implementacji wymagań dotyczących zapobiegania niechcianemu śledzeniu. Dodaliśmy wytyczne dotyczące urządzeń z możliwością przełączania.