Specyfikacja akcesoriów sieciowych Znajdź moje urządzenie

v1.3

Specyfikacja akcesoriów sieci usługi Znajdź moje urządzenie (FMDN) definiuje szyfrowane od końca do końca podejście do śledzenia urządzeń z Bluetooth Low Energy (BLE) z beaconami. Ta strona opisuje FMDN jako rozszerzenie specyfikacji Fast Pair. Dostawcy powinni włączyć to rozszerzenie, jeśli mają urządzenia zgodne z FMDN i chcą włączyć śledzenie lokalizacji na tych urządzeniach.

Specyfikacja GATT

Do usługi Fast Pair należy dodać dodatkową cechę atrybutów ogólnych (GATT) z taką semantyką:

Charakterystyka usługi Szybkie parowanie Zaszyfrowane Uprawnienia UUID
Działania beacon Nie odczytywać, zapisywać i powiadamiać. FE2C1238-8366-4814-8EB0-01DE32100BEA

Tabela 1. Charakterystyka usługi Szybkie parowanie dla FMDN

Uwierzytelnianie

Operacje wymagane przez to rozszerzenie są wykonywane jako operacje zapisu zabezpieczone mechanizmem wyzwanie-odpowiedź. Przed wykonaniem jakiejkolwiek operacji Seeker powinien wykonać operację odczytu z charakterystyki w tabeli 1, co spowoduje buforowanie w takim formacie:

Oktet Typ danych Opis Wartość
0 uint8 Numer wersji głównej protokołu 0x01
1–8 tablica bajtów Losowy jednorazowy identyfikator nonce zmienia się

Każda operacja odczytu powinna prowadzić do uzyskania innego nonce, a jeden nonce powinien być ważny tylko dla jednej operacji. Wartość nonce musi zostać unieważniona nawet wtedy, gdy operacja się nie udała.

Następnie oblicza klucz uwierzytelniający jednorazowy, który będzie używany w następnym żądaniu zapisu. Klucz uwierzytelniania jest obliczany zgodnie z opisem w tabelach 2–5. W zależności od żądanej operacji, Poszukiwacz potwierdza znajomość co najmniej jednego z tych kluczy:

Operacje

Format danych zapisywanych w charakterystyce podano w tabelach 2–5. Więcej informacji o każdej z tych operacji znajdziesz w dalszej części tego artykułu.

Oktet Typ danych Opis Wartość
0 uint8 Identyfikator danych
  • 0x00: odczytaj parametry beacona.
  • 0x01: odczyt stanu obsługi administracyjnej
  • 0x02: Ustaw klucz tożsamości tymczasowej
  • 0x03: Wyczyść klucz tożsamości
1 uint8 Długość danych zmienia się
2–9 tablica bajtów Klucz uwierzytelniający jednorazowy Pierwsze 8 bajtów adresu 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, które są kluczem tożsamości ulotnej, szyfrowanym przy użyciu klucza konta za pomocą AES-ECB-128. Jeśli dostawca ma już ustawiony klucz tożsamości o krótkim czasie ważności, wyślij też pierwsze 8 bajtów:SHA256(current ephemeral identity key || the last nonce read from the characteristic)
  • 0x03: pierwsze 8 bajtów wartości SHA256(ephemeral identity key || the last nonce read from the characteristic)

Tabela 2. Prośba o wdrożenie beacona

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

Tabela 3. Prośba o odzyskanie klucza konfiguracji beacona

Oktet Typ danych Opis Wartość
0 uint8 Identyfikator danych
  • 0x05: Ring
  • 0x06: odczytywanie stanu dzwonienia
1 uint8 Długość danych zmienia się
2–9 tablica bajtów Klucz uwierzytelniający jednorazowy Pierwsze 8 bajtów adresu 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 trwania dzwonienia i głośność dzwonienia.
  • 0x06: nie dotyczy

Tabela 4. Prośba o dzwonienie.

Oktet Typ danych Opis Wartość
0 uint8 Identyfikator danych
  • 0x07: Aktywuj tryb ochrony przed niechcianym śledzeniem
  • 0x08: dezaktywowanie trybu ochrony przed niechcianym śledzeniem
1 uint8 Długość danych zmienia się
2–9 tablica bajtów Klucz uwierzytelniający jednorazowy Pierwsze 8 bajtów adresu 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 elementu SHA256(ephemeral identity key || the last nonce read from the characteristic)

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

Pomyślne zapisy wywołują powiadomienia zgodnie z tabelą 6.

Powiadomienia z identyfikatorem danych innym niż 0x05: zmiana stanu dzwonka należy wysłać przed zakończeniem transakcji zapisu, która powoduje wysłanie powiadomienia, czyli przed wysłaniem odpowiedzi PDU na żądanie zapisu.

Oktet Typ danych Opis Wartość
0 uint8 Identyfikator danych
  • 0x00: odczytaj parametry beacona.
  • 0x01: odczyt stanu obsługi administracyjnej
  • 0x02: Ustaw klucz tożsamości tymczasowej
  • 0x03: Wyczyść klucz tożsamości
  • 0x04: odczyt tymczasowego klucza tożsamości za zgodą użytkownika
  • 0x05: zmiana stanu dzwonka
  • 0x06: odczytywanie stanu dzwonienia
  • 0x07: Aktywuj tryb ochrony przed niechcianym śledzeniem
  • 0x08: dezaktywowanie trybu ochrony przed niechcianym śledzeniem
1 uint8 Długość danych zmienia się
2–9 tablica bajtów Uwierzytelnianie Szczegóły operacji
10 – var tablica bajtów Dodatkowe dane
  • 0x00: 8 bajtów określających moc transmisji, wartość zegara, metodę szyfrowania i możliwości dzwonienia, zaszyfrowane algorytmem AES-ECB-128 za pomocą klucza konta (z wypełnieniem zerami)
  • 0x01: 1 bajt wskazujący stan obsługi, a następnie bieżący identyfikator tymczasowy (20 lub 32 bajty)
  • 0x04: 32 bajty, które są kluczem tożsamości, szyfrowane algorytmem AES-ECB-128 za pomocą klucza konta
  • 0x05: 4 bajty wskazujące nowy stan i wyzwalacz zmiany
  • 0x06: 3 bajty wskazujące komponenty aktywnie dzwoniące i liczbę decysekund pozostałych do zakończenia dzwonienia
  • Identyfikatory innych danych używają pustych danych dodatkowych

Tabela 6. Odpowiedź usługi beacona

Tabela 7 zawiera listę możliwych kodów błędów GATT zwracanych przez operacje.

Kod Opis Uwagi
0x80 Nieuwierzytelnione Zwracany w odpowiedzi na żądanie zapisu, gdy uwierzytelnianie się nie powiedzie (w tym w przypadku, gdy użyto starego numeru losowego).
0x81 Nieprawidłowa wartość Zwracana, gdy podana jest nieprawidłowa wartość lub otrzymane dane mają nieoczekiwaną liczbę bajtów.
0x82 Brak zgody użytkownika Zwracany w odpowiedzi na żądanie zapisu z identyfikatorem danych 0x04: odczyt klucza tożsamości tymczasowej z zgodą użytkownika, gdy urządzenie nie jest w trybie parowania.

Tabela 7. Kody błędów GATT

Odczyt parametrów beacona

Poszukiwacz może wysłać do dostawcy zapytanie o parametry beacona, wykonując operację zapisu do cechy, która składa się z żądania z tabeli 2 z identyfikatorem danych 0x00. Usługodawca sprawdza, czy podany jednorazowy klucz uwierzytelniający jest zgodny z kluczami konta zapisanymi na urządzeniu.

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

W przypadku powodzenia dostawca wysyła powiadomienie z odpowiedzią z tabeli 6 z identyfikatorem danych 0x00. Dostawca tworzy segment danych w ten sposób:

Oktet Typ danych Opis Wartość
0 uint8 Skalibrowana moc Skalibrowana moc otrzymana na 0 m (wartość w zakresie [-100, 20]). Reprezentowana jako liczba całkowita ze znakiem, z 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 rozszerzonej reklamy)
6 uint8 Komponenty Liczba komponentów zdolnych do dzwonienia:
  • 0x00: oznacza, że urządzenie nie może dzwonić.
  • 0x01: wskazuje, że tylko jeden komponent może dzwonić.
  • 0x02: wskazuje, że 2 słuchawki (lewa i prawa) mogą dzwonić niezależnie.
  • 0x03: oznacza, że 3 komponenty – lewe i prawe słuchawki oraz etui – mogą dzwonić niezależnie.
7 uint8 Funkcje dzwonienia Obsługiwane opcje:
  • 0x00: Wybór głośności dzwonienia jest niedostępny.
  • 0x01: Dostępna opcja wyboru głośności dzwonka. Jeśli jest ustawiona, dostawca musi akceptować i obsługiwać 3 poziomy głośności zgodnie z opisem działania dzwonka.
8-15 tablica bajtów Dopełnienie Dodawanie zera do szyfrowania AES.

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

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

Czytanie stanu obsługiwania beacona

W celu sprawdzenia stanu obsługiwania sygnalizatora Seeker może wysłać do dostawcy zapytanie, wykonując operację zapisu do charakterystyki, która jest żądaniem z tabeli 2 o identyfikatorze danych 0x01. Usługodawca sprawdza, czy podany jednorazowy klucz uwierzytelniania jest zgodny z jednym z kluczy konta zapisanych na urządzeniu.

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

W przypadku powodzenia dostawca wysyła powiadomienie z odpowiedzią z tabeli 6 z identyfikatorem danych 0x01. Dostawca tworzy segment danych w ten sposób:

Oktet Typ danych Opis Wartość
0 uint8 Stan obsługi administracyjnej Maska bitowa o tych wartościach:
  • Bit 1 (0x01): ustawiony, jeśli dla urządzenia ustawiony jest klucz tożsamości tymczasowej.
  • Bit 2 (0x02): ustaw, jeśli podany klucz jednorazowego uwierzytelniania jest zgodny z kluczem konta właściciela.
1–20 lub 32 tablica bajtów Bieżący identyfikator tymczasowy 20 lub 32 bajty (w zależności od używanej metody szyfrowania) wskazujące bieżący identyfikator tymczasowy reklamowany przez beacon, jeśli został ustawiony na urządzeniu.

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

Ustawianie klucza tożsamości o krótkim czasie ważności

Aby udostępnić nieskonfigurowanego dostawcę jako sygnał FMDN lub zmienić tymczasowy klucz tożsamości już skonfigurowanego dostawcy, szukający wykonuje operację zapisu do cechy, która składa się z żądania z tabeli 2 z identyfikatorem danych 0x02. Dostawca potwierdza, że:

  • Podany jednorazowy klucz uwierzytelniający jest zgodny z kluczem konta właściciela.
  • Jeśli podano hasz klucza tożsamości tymczasowej, zaszyfrowany klucz tożsamości tymczasowej jest zgodny z bieżącym kluczem tożsamości tymczasowej.
  • Jeśli nie podano hasha klucza tożsamości tymczasowej, sprawdź, czy dostawca nie został już udostępniony jako sygnał FMDN.

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

W przypadku powodzenia klucz tożsamości jest odszyfrowywany przy użyciu klucza konta dopasowanego za pomocą algorytmu AES-ECB-128. Klucz powinien być przechowywany na urządzeniu, a od tego momentu dostawca powinien zacząć reklamować ramki FMDN. Nowy klucz tożsamości tymczasowej zacznie obowiązywać natychmiast po zakończeniu połączenia BLE. Dostawca wysyła powiadomienie z tabeli 6 z identyfikatorem danych 0x02.

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

Wyczyszczenie klucza tożsamości o krótkim czasie ważności

Aby anulować ustawienie części beacona w Dostawcy, Poszukiwacz wykonuje operację zapisu do tej cechy, która składa się z żądania z tabeli 2 z identyfikatorem danych 0x03. Dostawca potwierdza, że:

  • Podany jednorazowy klucz uwierzytelniający jest zgodny z kluczem konta właściciela.
  • Zaszyfrowany klucz tożsamości tymczasowej jest zgodny z bieżącym kluczem tożsamości tymczasowej.

Jeśli dostawca nie jest skonfigurowany jako sygnał FMDN lub weryfikacja się nie powiedzie, zwraca błąd nieautoryzowany.

W przypadku powodzenia dostawca usuwa klucz i przestaje wyświetlać ramki FMDN. Dostawca wysyła powiadomienie z tabeli 6 z identyfikatorem danych 0x03. Segment uwierzytelniania to pierwsze 8 bajtów parametru HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || 0x01).

Odczytywanie klucza tożsamości tymczasowej z użyciem zgody użytkownika

Ta opcja jest dostępna tylko do odzyskania utraconego klucza, ponieważ klucz jest przechowywany tylko lokalnie przez szukającego. Ta funkcja jest dostępna tylko wtedy, gdy urządzenie jest w trybie parowania lub przez ograniczony czas po naciśnięciu fizycznego przycisku na urządzeniu (co stanowi zgodę użytkownika).

Aby móc odzyskać klucz jawny, Seeker musi przechowywać klucz odzyskiwania na zapleczu, ale nie przechowuje samego klucza EIK.

Aby odczytać EIK, Seeker wykonuje operację zapisu do tej cechy, która składa się z żądania z tabeli 3 o identyfikatorze danych 0x04. Dostawca weryfikuje, że:

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

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

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

W przypadku powodzenia dostawca wysyła powiadomienie z odpowiedzią z tabeli 6 z identyfikatorem danych 0x04.

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

Działanie dzwonka

Poszukiwacz może poprosić dostawcę o odtworzenie dźwięku, wykonując operację zapisu do tej cechy, która składa się z żądania z tabeli 4 o identyfikatorze danych 0x05. Dostawca tworzy segment danych w ten sposób:

Oktet Typ danych Opis Wartość
0 uint8 Dzwonek Maska bitowa o tych wartościach:
  • Bit 1 (0x01): dzwonek w prawej.
  • Bit 2 (0x02): dzwonek w lewej słuchawce
  • Bit 3 (0x04): obudowa dzwonka
  • 0xFF: dzwonek dla wszystkich komponentów
  • 0x00: zatrzymać dzwonienie
1–2 uint16 Czas oczekiwania Czas oczekiwania w decysekundach. Nie może być równa 0 ani większa niż 10 minut.
Dostawca używa tej wartości, aby określić, jak długo ma dzwonić, zanim zamilknie. Czas oczekiwania zastępuje ten, który jest już aktywny, jeśli jakikolwiek element urządzenia już dzwoni.

Jeśli operacja dzwonienia ma wartość 0x00, limit czasu jest ignorowany.
3 uint8 Głośność
  • 0x00: domyślny
  • 0x01: Niski
  • 0x02: Średnia
  • 0x03: wysoki
Dokładne znaczenie tych wartości zależy od implementacji.

Po otrzymaniu prośby dostawca weryfikuje, czy:

  • Podany jednorazowy klucz uwierzytelniający jest zgodny z kluczem w pierścieniu.
  • Żądany stan odpowiada komponentom, które mogą dzwonić.

Jeśli dostawca nie jest skonfigurowany jako sygnał FMDN lub weryfikacja się nie powiedzie, zwraca błąd nieautoryzowany. Jeśli jednak dostawca ma włączoną ochronę przed niechcianym śledzeniem, a żądanie wywołujące ochronę przed niechcianym śledzeniem miało włączone pole wyboru pomijania uwierzytelniania podczas dzwonienia, dostawca powinien pominąć to sprawdzenie. Dane uwierzytelniające nadal musi podać osoba poszukująca, ale mogą one mieć dowolną wartość.

Gdy dzwonienie się rozpoczyna lub kończy, wysyłane jest powiadomienie zgodnie z tabelą 6 z identyfikatorem danych 0x05. Treść powiadomienia jest zdefiniowana w ten sposób:

Oktet Typ danych Opis Wartość
0 uint8 Stan dzwonienia
  • 0x00: Started
  • 0x01: nie udało się uruchomić ani zatrzymać (wszystkie żądane komponenty są poza zasięgiem)
  • 0x02: zatrzymano (przekroczony limit czasu).
  • 0x03: zatrzymanie (naciśnięcie przycisku)
  • 0x04: zatrzymany (żądanie GATT)
1 uint8 Komponenty dzwonienia Bitmaska komponentów aktywnie dzwoniących, jak określono w żądaniu.
2–3 uint16 Czas oczekiwania Pozostały czas dzwonienia w decysekundach. Jeśli urządzenie przestało dzwonić, zwracana wartość to 0x0000.

Segment uwierzytelniania to pierwsze 8 bajtów parametru 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 lub zatrzymania dzwonienia urządzenie jest już w wymaganym stanie dzwonienia, dostawca powinien wysłać powiadomienie ze stanem dzwonienia 0x00: Started (Rozpoczęto) lub 0x04: Stopped (Zatrzymano) (żądanie GATT). To żądanie zastępuje parametry bieżącego stanu, dzięki czemu można wydłużyć czas dzwonienia.

Jeśli dostawca ma przycisk fizyczny (lub włączone dotykowe czujniki), to po jego naciśnięciu podczas dzwonienia funkcja dzwonienia powinna zostać zatrzymana.

Pobieranie stanu dzwonienia beacona

Aby uzyskać stan dzwonienia beacona, Seeker wykonuje operację zapisu w charakterystyce, która składa się z żądania z tabeli 4 o identyfikatorze danych 0x06. Dostawca weryfikuje, czy podany jednorazowy klucz uwierzytelniania jest zgodny z kluczem pierścienia.

Jeśli dostawca nie jest skonfigurowany jako sygnał FMDN lub jeśli weryfikacja się nie powiedzie, dostawca zwróci błąd nieautoryzowany.

W przypadku powodzenia dostawca wysyła powiadomienie z odpowiedzią z tabeli 6 z identyfikatorem danych 0x06. Dostawca tworzy segment danych w ten sposób:

Oktet Typ danych Opis Wartość
0 uint8 Komponenty dzwonienia Komponenty aktywnie dzwoniące zgodnie z definicją w żądaniu dzwonienia.
1–2 uint16 Czas oczekiwania Pozostały czas dzwonienia w decysekundach. Pamiętaj, że jeśli urządzenie nie dzwoni, zwracana jest wartość 0x0000.

Segment uwierzytelniania to pierwsze 8 bajtów parametru 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żliwić każdemu klientowi identyfikację urządzeń nadużywanych bez komunikacji z serwerem. Domyślnie dostawca powinien rotować wszystkie identyfikatory zgodnie z opisem w sekcji Rotacja identyfikatorów. Usługa Znajdź moje urządzenie może przekazywać prośby o aktywowanie trybu ochrony przed śledzeniem za pomocą sieci Znajdź moje urządzenie. W ten sposób usługa powoduje, że dostawca tymczasowo używa stałego adresu MAC, co umożliwia klientom wykrywanie urządzenia i ostrzeganie użytkownika o możliwym niepożądanym śledzeniu.

Aby aktywować lub dezaktywować tryb ochrony przed niechcianym śledzeniem w beaconie, Seeker wykonuje operację zapisu w charakterystyce, która składa się z żądania z tabeli 5 z identyfikatorem danych 0x07 lub 0x08.

Podczas włączania trybu ochrony przed niechcianym śledzeniem

Dostawca tworzy segment danych w ten sposób:

Oktet Typ danych Opis Wartość
0 uint8 Flagi sterujące
  • 0x01: pomiń uwierzytelnianie podczas dzwonienia. Gdy ta opcja jest ustawiona, żądania dzwonienia nie są uwierzytelniane w trybie ochrony przed niechcianym śledzeniem.
Jeśli nie ustawiono żadnej flagi (bajt zawiera tylko zera), można pominąć sekcję danych i przesłać pustą sekcję danych.
Flagi są aktywne tylko do momentu dezaktywacji trybu ochrony przed niechcianym śledzeniem.

Dostawca weryfikuje, czy podany jednorazowy klucz uwierzytelniający jest zgodny z kluczem ochrony przed niepożądanym śledzeniem. Jeśli dostawca nie jest skonfigurowany jako sygnał FMDN lub weryfikacja się nie powiedzie, zwróci błąd nieautoryzowany.

Gdy włączony jest tryb ochrony przed niechcianym śledzeniem, beacon powinien zmniejszyć częstotliwość rotacji adresów prywatnych MAC do raz na 24 godziny. Reklamowany tymczasowy identyfikator powinien się nadal wyświetlać. Typ ramki powinien być ustawiony na 0x41. Stan jest również widoczny w sekcji flagi zaszyfrowane.

Gdy wyłączasz tryb ochrony przed niechcianym śledzeniem

Dostawca potwierdza, że:

  • Podany jednorazowy klucz uwierzytelniający jest zgodny z kluczem ochrony przed niepożądanym śledzeniem.
  • Zaszyfrowany klucz tymczasowej tożsamości jest zgodny z obecnym kluczem tymczasowej tożsamości.

Jeśli dostawca nie jest skonfigurowany jako sygnał FMDN lub weryfikacja się nie powiedzie, dostawca zwróci błąd nieautoryzowany.

Gdy tryb ochrony przed niechcianym śledzeniem zostanie dezaktywowany, beacon powinien ponownie zacząć zmieniać adres MAC z normalną częstotliwością, zsynchronizowaną z zmianą identyfikatorów efemerycznych. Typ ramki powinien być ustawiony z powrotem na 0x40. Stan jest również widoczny w sekcji flagi z haszowaniem.

W przypadku powodzenia dostawca wysyła powiadomienie z tabeli 6 z identyfikatorem danych 0x07 lub 0x08.

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

Ramki reklamowane

Po zaimplementowaniu funkcji dostawca powinien wyświetlać ramki FMDN co najmniej raz na 2 sekundy. Jeśli reklamowane są ramki Szybkiego parowania, dostawca powinien przeplatać ramki FMDN w ramkach zwykłych reklam Szybkiego parowania. Na przykład co 2 sekundy dostawca powinien wyświetlać 7 reklam Fast Pair i 1 reklamę FMDN.

W przypadku reklam FMDN moc transmisji Bluetooth powinna wynosić co najmniej 0 dBm.

Ramka FMDN zawiera klucz publiczny używany do szyfrowania raportów o lokalizacji przez dowolnego klienta obsługującego, który udostępnia dane crowdsourcingowej sieci. Dostępne są 2 rodzaje kluczy krzywej eliptycznej: 160-bitowy klucz, który pasuje do starszych ramek BLE 4, lub 256-bitowy klucz, który wymaga BLE 5 z rozszerzonymi możliwościami reklamowymi. Którą z krzywych ma być używana, zależy od implementacji dostawcy.

Ramka FMDN ma taką strukturę:

Oktet Wartość Opis
0 0x02 Długość
1 0x01 Wartość typu danych flagi
2 0x06 Dane flagi
3 0x18 lub 0x19 Długość
4 0x16 Wartość typu danych usługi
5 0xAA 16-bitowy UUID usługi
6 0xFE …
7 0x40 lub 0x41 Typ ramki FMDN z wskaźnikiem trybu ochrony przed niepożądanym śledzeniem
8..27 20-bajtowy identyfikator tymczasowy
28 Zaszyfrowane flagi

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

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

Oktet Wartość Opis
0 0x02 Długość
1 0x01 Wartość typu danych flagi
2 0x06 Dane flagi
3 0x24 lub 0x25 Długość
4 0x16 Wartość typu danych usługi
5 0xAA 16-bitowy UUID usługi
6 0xFE …
7 0x40 lub 0x41 Typ ramki FMDN z wskaźnikiem trybu ochrony przed niepożądanym śledzeniem
8..39 32-bajtowy identyfikator tymczasowy
40 Zaszyfrowane flagi

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

Obliczanie tymczasowego identyfikatora (EID)

Losowa wartość jest generowana przez szyfrowanie AES-ECB-256 z użyciem klucza tożsamości o krótkim czasie ważności dla tej struktury danych:

Oktet Pole Opis
0–10 Dopełnienie Wartość = 0xFF
11 K Wykładnik okresu rotacji
12–15 TS[0]...TS[3] Licznik czasu beacona w formacie 32-bitowym big-endian. Najniższe bity K są czyszczone.
16–26 Dopełnienie Wartość = 0x00
27 K Wykładnik okresu rotacji
28–31 TS[0]...TS[3] Licznik czasu beacona w formacie 32-bitowym big-endian. Najniższe bity K są czyszczone.

Tabela 10: konstrukcja liczby pseudolosowej.

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

W pozostałej części obliczeń do operacji kryptograficznych na krzywej eliptycznej używane są wartości SECP160R1 lub SECP256R1. Definicje krzywych znajdziesz w artykule SEC 2: Recommended Elliptic Curve Domain Parameters (w języku angielskim), w którym zdefiniowano wartości Fp, n i G, do których odwołujemy się w dalszej części dokumentu.

Wartość r' jest teraz rzutowana na ograniczone pole 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 Rx, czyli współrzędne x, jako swój tymczasowy identyfikator.R

Zaszyfrowane flagi

Pole flagi zaszyfrowanej jest obliczane w ten sposób (bity są wskazywane od najbardziej znaczącego do najmniej znaczącego):

  • Bity 0–4: zarezerwowane (ustawione na zera).
  • Bity 5–6 wskazują poziom naładowania baterii urządzenia w następujący sposób:
    • 00: wskaźnik poziomu naładowania baterii nie jest obsługiwany
    • 01: normalny poziom baterii
    • 10: niski poziom naładowania baterii
    • 11: bardzo niski poziom naładowania baterii (wkrótce konieczna będzie jej wymiana)
  • Bit 7 jest ustawiony na 1, jeśli beacon jest w trybie ochrony przed niepożądanym śledzeniem, a w przeciwnym razie na 0.

Aby uzyskać ostateczną wartość tego bajtu, należy go złączyć bitowo z najmniej istotnym bajtem wartości SHA256(r).

Pamiętaj, że r powinien być dopasowany do rozmiaru krzywej. Dodaj zera jako najbardziej znaczące bity, jeśli reprezentacja jest krótsza niż 160 lub 256 bitów, lub obcinaj najbardziej znaczące bity, jeśli reprezentacja jest dłuższa niż 160 lub 256 bitów.

Jeśli beacon nie obsługuje wskazania poziomu naładowania baterii i nie jest w trybie ochrony przed niechcianym śledzeniem, można całkowicie pominąć ten bajt w reklamie.

Szyfrowanie z identyfikatorem EID

Aby zaszyfrować wiadomość m, osoba, która ją zobaczy (czyli odczyta Rx z beacona), wykona te czynności:

  1. Wybierz losową liczbę s w Fp, zgodnie z definicją w sekcji Obliczanie identyfikatora EID.
  2. Oblicz S = s * G.
  3. Oblicz R = (Rx, Ry), zastępując w równaniu krzywej dowolną wartość Ry spośród możliwych wyników.
  4. Oblicz 256-bitowy klucz AES k = HKDF-SHA256((s * R)x), gdzie (s * R)x jest współrzędną x wyniku mnożenia krzywej. Nie podano ciągu zaburzającego.
  5. Niech URx i LRx będą odpowiednio górnymi i dolnymi 80 bitami Rx w formacie big-endian. W podobny sposób zdefiniuj wartości USx i LSx dla atrybutu S.
  6. Oblicz nonce = LRx || LSx.
  7. Oblicz (m’, tag) = AES-EAX-256-ENC(k, nonce, m).
  8. Wyślij (URx, Sx, m’, tag) do właściciela, prawdopodobnie za pomocą niezaufanego zdalnego serwera.

Odszyfrowywanie wartości zaszyfrowanych za pomocą identyfikatora EID

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

  1. Na podstawie wartości URx uzyskaj wartość licznika czasu beacona, na którym opiera się URx. Może to zrobić klient właściciela, obliczając wartości Rx dla wartości licznika czasu beacona w niedawnej przeszłości i najbliższej przyszłości.
  2. Na podstawie wartości licznika czasu sygnalizatora, na którym opiera się URx, oblicz przewidywaną wartość r zgodnie z definicją w sekcji Obliczanie identyfikatora EID.
  3. Oblicz wartość R = r * G i sprawdź, czy jest ona zgodna z wartością URx zliczonego przez widok.
  4. Oblicz S = (Sx, Sy), zastępując w równaniu krzywej dowolną wartość Sy spośród możliwych wyników.
  5. Oblicz k = HKDF-SHA256((r * S)x), gdzie (r * S)x to współrzędna x wyniku mnożenia krzywej.
  6. Oblicz nonce = LRx || LSx.
  7. Oblicz m = AES-EAX-256-DEC(k, nonce, m’, tag).

Rotacja identyfikatorów

Do reklamowania ramek FMDN należy używać adresów BLE, które można rozwiązać (RPA) lub nie można rozwiązać (NRPA). RPA jest wymagana w przypadku urządzeń LE Audio (LEA) i zalecana w przypadku innych urządzeń, z wyjątkiem tagów lokalizacyjnych, które nie korzystają z wiązania.

Reklama Szybkiego parowania, reklama FMDN i odpowiednie adresy BLE powinny być wyświetlane naprzemiennie. Rotacja powinna odbywać się średnio co 1024 sekund. Dokładny moment, w którym beacon zaczyna reklamować nowy identyfikator, musi być losowy w ramach tego okna.

Zalecane podejście do losowego ustalania czasu rotacji polega na ustawieniu go na następny przewidywany czas rotacji (jeśli nie została zastosowana losowość) plus dodatni losowy współczynnik czasu w zakresie od 1 do 204 sekund.

Gdy urządzenie jest w trybie ochrony przed niepożądanym śledzeniem, adres BLE reklamy FMDN powinien być stały, ale RPA dla reklamy FP, która nie może być wykryta (np. Fast Pair), musi się nadal wyświetlać. Dozwolone jest używanie różnych adresów dla różnych protokołów.

Przywracanie po utracie zasilania

Rozwiązanie tymczasowego identyfikatora jest ściśle powiązane z wartością zegara w momencie wyświetlenia reklamy, dlatego ważne jest, aby dostawca mógł odzyskać wartość zegara w przypadku utraty zasilania. Zalecamy, aby dostawca zapisywał bieżącą wartość zegara w pamięci nieulotnej co najmniej raz dziennie, a podczas uruchamiania sprawdzał, czy w pamięci nieulotnej jest wartość, z której można zainicjować urządzenie. Rozwiązania identyfikatora ulotnego byłyby wdrażane w okresie wystarczającym do uwzględnienia rozchodzenia się zegara i tego typu odzyskiwania po utracie zasilania.

Dostawcy powinni jednak dołożyć wszelkich starań, aby zminimalizować odchylenia zegara, ponieważ okno czasu rozdzielania jest ograniczone. Należy zastosować co najmniej 1 dodatkową metodę synchronizacji zegara (reklamowe niewykrywalne ramki Fast Pair lub implementację strumienia wiadomości).

Wskazówki dotyczące implementacji Szybkiego parowania

W tej sekcji opisujemy szczególne aspekty implementacji Szybkiego parowania w przypadku dostawców, którzy obsługują FMDN.

Wytyczne dotyczące tagu lokalizatora

  • Jeśli dostawca został sparowany, ale FMDN nie został skonfigurowany w ciągu 5 minut (lub jeśli aktualizacja OTA została zastosowana, gdy urządzenie jest sparowane, ale nie zostało skonfigurowane z FMDN), dostawca powinien przywrócić konfigurację fabryczną i wyczyścić zapisane klucze konta.
  • Po sparowaniu dostawca nie powinien zmieniać adresu MAC, dopóki nie zostanie skonfigurowany FMDN lub nie upłynie 5 minut.
  • Jeśli tymczasowy klucz tożsamości zostanie wyczyszczony z urządzenia, urządzenie powinno przywrócić ustawienia fabryczne i wyczyścić również zapisane klucze kont.
  • Dostawca powinien odrzucać próby parowania Bluetooth i akceptować tylko parowanie Fast Pair.
  • Dostawca musi uwzględnić mechanizm, który umożliwia użytkownikom tymczasowe wstrzymanie wyświetlania reklam bez przywracania ustawień fabrycznych urządzenia (np. przez naciśnięcie kombinacji przycisków).
  • Po utracie zasilania urządzenie powinno wyświetlać niewykrywalne ramki Szybkiego parowania do czasu następnego wywołania parametrów odczytu beacona. Dzięki temu wykrywacz może wykryć urządzenie i zsynchronizować zegar nawet wtedy, gdy wystąpiła znaczna zmiana zegara.
  • W przypadku reklamowania niewykrywalnych ramek Szybkiego parowania nie należy włączać wskazań interfejsu.
  • Ramki Szybkiego parowania, które można wykryć, nie powinny być reklamowane, gdy dostawca jest udostępniany w ramach FMDN.
  • Dostawca nie może ujawniać żadnych informacji umożliwiających identyfikację w sposób niezaufamy (np. imion lub identyfikatorów).

Wytyczne dotyczące klasycznego Bluetootha na konkretnych urządzeniach

W tej sekcji opisano specjalne aspekty klasycznych urządzeń Bluetooth obsługujących FMDN.

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

Dostawca nie zawsze jest przygotowany do obsługi FMDN podczas parowania z poszukiwaczem, ale po chwili to nastąpi. 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 1 z tych sposobów uzyskania adresu BLE przez poszukującego, gdy urządzenie jest już sparowane:

  • Usługodawca może okresowo reklamować dane konta Fast Pair, które umożliwiają Użytkownikowi znalezienie adresu BLE przez skanowanie BLE.
    To podejście jest odpowiednie dla dostawców, którzy nie implementują strumienia wiadomości.
  • Dostawca może udostępniać te dane za pomocą strumienia wiadomości Szybkiego parowania w ramach klasycznego Bluetootha.
    To podejście jest odpowiednie dla dostawców, którzy nie reklamują ramek Szybkiego parowania podczas połączenia z urządzeniem poszukującym przez Bluetooth.

Obsługa obu tych metod zwiększa szanse, że użytkownik będzie mógł skonfigurować urządzenie na potrzeby FMDN.

Strumień wiadomości Szybkiego parowania

Dostawca może wdrożyć strumień wiadomości Szybkiego parowania i używać go do powiadamiania Pragnącego o informacjach o urządzeniu. Wdrożenie strumienia wiadomości umożliwia korzystanie z pewnych funkcji opisanych w tej sekcji.

Dostawca powinien wysyłać wiadomości z informacjami o urządzeniu za każdym razem, gdy zostanie nawiązany kanał strumieniowego przesyłania danych RFCOMM.

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

Gdy aktualizacja oprogramowania sprzętowego dodaje obsługę FMDN do dostawcy, połączony poszukiwacz może powiadomić użytkownika o tym i zaproponować wdrożenie. W przeciwnym razie użytkownik musi ręcznie przejść do listy urządzeń Bluetooth, aby rozpocząć konfigurowanie FMDN.

Aby to umożliwić, dostawca powinien użyć właściwości Wersja oprogramowania układowego (kod 0x09), aby przekazać wartość ciągu znaków reprezentującą wersję oprogramowania układowego. Dodatkowo dostawca powinien obsługiwać protokół, który informuje poszukującego o zmianach w możliwościach spowodowanych aktualizacjami oprogramowania.

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

Tabela 11. Zdarzenie dotyczące informacji o urządzeniu: zaktualizowano wersję oprogramowania.

Po otrzymaniu prośby o aktualizację możliwości (0x0601) dostawca, jeśli ma włączoną obsługę śledzenia FMDN, powinien odpowiedzieć zgodnie z tabelą 12.

Oktet Typ danych Opis Wartość
0 uint8 Zdarzenie synchronizacji funkcjonalności urządzenia 0x06
1 uint8 Śledzenie FMDN 0x03
2–3 uint16 Długość dodatkowych danych 0x0007
4 uint8 Stan obsługi administracyjnej FMDN 0x00, jeśli nie jest skonfigurowany; 0x01, jeśli jest skonfigurowany przez dowolne konto
5–10 tablica bajtów bieżący adres MAC BLE urządzenia. zmienia się

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

Bieżący identyfikator tymczasowy (kod informacji o urządzeniu 0x0B)

Dostawca może używać bieżącego identyfikatora tymczasowego (kod 0x0B), aby zgłaszać bieżący identyfikator EID i wartość zegara, gdy dostawca jest skonfigurowany pod kątem FMDN, aby zsynchronizować Seekera w przypadku przesunięcia zegara (np. z powodu wyczerpania baterii). W przeciwnym razie w tym celu inicjuje 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 tymczasowy 0x0B
2–3 uint16 Długość dodatkowych 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 o urządzeniu: synchronizacja zegara

Przywrócono ustawienia fabryczne

W przypadku urządzeń, które obsługują przywracanie do ustawień fabrycznych: jeśli zostanie wykonane przywracanie do ustawień fabrycznych, dostawca musi zatrzymać beaconing i usunąć klucz tożsamości tymczasowej oraz wszystkie zapisane klucze kont, w tym klucz konta właściciela.

Po przywróceniu ustawień fabrycznych (ręcznie lub programowo) dostawca nie powinien od razu reklamować funkcji Fast Pair, aby zapobiec uruchamianiu procesu parowania bezpośrednio po usunięciu urządzenia przez użytkownika.

Zapobieganie niechcianemu śledzeniu

Certyfikowane urządzenia FMDN muszą też spełniać wymagania określone w wersji implementacji specyfikacji międzyplatformowej Detecting Unwanted Location Trackers (DULT).

Odpowiednie wytyczne dotyczące FMDN, aby zachować zgodność ze specyfikacją DULT:

  • Każde urządzenie zgodne z FMDN musi być zarejestrowane w konsoli urządzeń w pobliżu oraz mieć włączoną funkcję „Znajdź moje urządzenie”.
  • Urządzenie musi implementować usługę i cechę akcesorium dla osób innych niż właściciel, zdefiniowane w wersji implementacji specyfikacji DULT, w tym operacje Informacje o akcesorium i elementy sterujące dla osób innych niż właściciel.
  • W okresie zgodności wstecznej, zgodnie ze specyfikacją DULT, nie ma żadnych zmian w reklamowanym interfejsie, zgodnie z definicją w tym dokumencie.
  • „Tryb ochrony przed niepożądanym śledzeniem” zdefiniowany w tym dokumencie odpowiada „oddzielnemu stanowi” zdefiniowanemu w specyfikacji DULT.
  • Wskazówki dotyczące implementowania opcode Accessory Information:
    • W ramach wywołania Get_Product_Data powinien zostać zwrócony identyfikator modelu dostarczony przez konsolę, uzupełniony zerami zerowymi, aby spełniał wymóg 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.
    • Funkcja Get_Accessory_Category może zwrócić ogólną wartość „Lokalizacja lokalizatora”, jeśli żadna inna kategoria nie pasuje lepiej do typu urządzenia.
    • W przypadku elementu Get_Accessory_Capabilities musisz wskazać obsługę dzwonienia oraz wyszukiwania identyfikatora BLE.
    • Funkcja Get_Network_ID powinna zwracać identyfikator Google (0x02).
  • Wskazówki dotyczące implementowania kodu operacji Get_Identifier:
    • Operacja powinna zwracać prawidłową odpowiedź tylko przez 5 minut od momentu, gdy użytkownik aktywował tryb „identyfikacji”, który wymaga naciśnięcia kilku przycisków. Użytkownik powinien zostać poinformowany o wejściu dostawcy w ten tryb za pomocą sygnału wizualnego lub dźwiękowego. Instrukcje dotyczące aktywowania tego trybu, które są specyficzne dla danego modelu, muszą zostać przesłane do Google jako wymagania certyfikacyjne co najmniej 10 dni przed aktualizacją lub zmianą instrukcji.
    • Odpowiedź jest konstruowana w ten sposób: pierwsze 10 bajtów bieżącego tymczasowego identyfikatora, a następnie pierwsze 8 bajtów HMAC-SHA256(recovery key, the truncated current ephemeral identifier).
  • Wytyczne dotyczące implementacji identyfikatora za pomocą NFC:
    • Jako adres URL użyj find-my.googleapis.com/lookup.
    • Jako parametr e użyj tej samej odpowiedzi, która została utworzona w przypadku metody Get_Identifier, zakodowanej w szeszxie.
    • Jako parametr pid użyj tej samej odpowiedzi, która została utworzona dla Get_Product_Data, zakodowanej w systemie szesnastkowym.
  • Urządzenie musi mieć generator dźwięku i obsługiwać funkcję dzwonienia. Zgodnie ze specyfikacją DULT urządzenie wytwarzające dźwięk musi emitować dźwięk o minimalnej głośności szczytowej 60 Phon zgodnie z normą ISO 532-1:2017.
  • Wskazówki dotyczące implementacji kodu operacji Sound_Start:
    • Polecenie powinno wywołać dzwonienie we wszystkich dostępnych komponentach.
    • Należy użyć maksymalnej obsługiwanej objętości.
    • Zalecana długość dzwonienia to 12 sekund.
  • Tagi lokalizatora muszą zawierać mechanizm, który umożliwia użytkownikom tymczasowe wstrzymanie wyświetlania reklam bez przywracania urządzenia do ustawień fabrycznych (np. przez naciśnięcie kombinacji przycisków).
    • Instrukcje wyłączenia muszą być opisane w dostępnym publicznie adresie URL i przekazane Google jako wymagane do uzyskania certyfikatu co najmniej 10 dni przed aktualizacją lub modyfikacją instrukcji.
    • Adres URL powinien obsługiwać lokalizację. W zależności od klienta język zostanie podany jako parametr zapytania („hl=pl”) lub za pomocą nagłówka HTTP „accept-language”.

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

  • Należy używać tylko jednego protokołu naraz. Upewnij się, że na urządzeniu może działać jednocześnie tylko jedna sieć. To wymaganie jest potrzebne, aby zapewnić, że poufne dane użytkowników nie są mieszane z danymi z różnych protokołów.
  • Zalecamy wdrożenie na urządzeniu procesu twardego resetowania, który pozwoli użytkownikowi ponownie skonfigurować urządzenie z inną siecią.
  • Proces aktualizacji urządzenia w ramach sieci powinien być przyjazny dla użytkownika i równy w różnych sieciach. Użytkownik musi mieć możliwość wyboru sieci, której chce używać, bez faworyzowania którejkolwiek z nich. Ten proces musi zostać zatwierdzony przez zespół Google.

Aktualizacje oprogramowania

Procesem i dystrybucją aktualizacji OTA powinien zarządzać partner, korzystając z własnego procesu obsługi aplikacji mobilnych lub internetowych.

Szybkie parowanie umożliwia wysyłanie powiadomień do użytkownika z informacjami o dostępnych aktualizacjach OTA. Aby korzystać z tego mechanizmu:

  • Najnowsza wersja oprogramowania powinna zostać zaktualizowana w konsoli urządzenia skoncentrowanego na lokalizacji.
  • Aplikacja towarzysząca powinna być skonfigurowana w konsoli Urządzenia w pobliżu. Powinien obsługiwać intencję aktualizacji oprogramowania.
  • Dostawca powinien zaimplementować charakterystyczną cechę GATT wersja oprogramowania układowego.

Aby zapobiec śledzeniu, dostęp do właściwości wersja oprogramowania układowego powinien być ograniczony. Najpierw odczytuje stan obsługi i przekaże klucz uwierzytelniający zgodnie z definicją w tej specyfikacji, a dopiero potem odczyta wersję oprogramowania układowego. Będzie to możliwe dzięki temu samemu połączeniu. Jeśli próba odczytu wersji oprogramowania układowego nie powiedzie się, ponieważ dostawca nie jest połączony ani uwierzytelniony, dostawca powinien zwrócić błąd nieautoryzowany.

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. Obowiązują ograniczenia wiekowe.

Historia zmian

Wersja FMDN Data Komentarz
v1 Pierwsza wersja specyfikacji FMDN udostępniona w ramach wcześniejszego dostępu.
v1.1 luty 2023 r.
  • Dodano wyraźne wskazanie trybu ochrony przed niechcianym śledzeniem.
  • Dodano opcję pomijania uwierzytelniania żądań dzwonienia w trybie ochrony przed niechcianym śledzeniem.
1.2 Kwiecień 2023 r.
  • Zaktualizowano definicję AK właściciela.
  • Dodano rekomendację dotyczącą przywracania po utracie zasilania w lokalizatorach.
  • Dodaliśmy wyjaśnienie losowania adresu MAC.
  • Dodaliśmy wyjaśnienie dotyczące rotacji adresów MAC w trybie ochrony przed śledzeniem niepożądanym.
  • Dodaliśmy wskazówki dotyczące sposobu dezaktywowania tagu lokalizatora.
v1.3 Grudzień 2023 r.
  • Dodaliśmy wyjaśnienie dotyczące informacji identyfikacyjnych udostępnianych przez tagi lokalizacyjne.
  • Dodano wymóg wdrożenia specyfikacji zapobiegania niechcianemu śledzeniu.
  • Dodaliśmy wskazówki dotyczące urządzeń z przełączalnym protokołem.