Specyfikacja akcesoriów sieci Centrum lokalizacji

Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.

v1.3

Specyfikacja akcesoriów sieci Centrum lokalizacji (FHN) definiuje szyfrowane od końca do końca podejście do śledzenia urządzeń z beaconami Bluetooth Low Energy (BLE). Ta strona opisuje FHN jako rozszerzenie specyfikacji Fast Pair. Dostawcy powinni włączyć to rozszerzenie, jeśli mają urządzenia zgodne z HNF 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ów	Nie	Odczyt, zapis i powiadamianie	FE2C1238-8366-4814-8EB0-01DE32100BEA

Tabela 1. Charakterystyka usługi Szybkie parowanie w przypadku FHN

Uwierzytelnianie

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

Octet	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 utworzenia 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 uwierzytelniania jednorazowego, który zostanie użyty w następnym żądaniu zapisu. Klucz uwierzytelniania jest obliczany zgodnie z opisem w tabelach 2–5. W zależności od operacji, o której żądanie chodzi, szukający musi wykazać się znajomością co najmniej jednego z tych kluczy:

• Klucz konta: 16-bajtowy klucz konta Szybkiego parowania, zgodnie ze specyfikacją Szybkiego parowania.

• Klucz konta właściciela: dostawca wybiera jeden z dotychczasowych kluczy konta jako klucz konta właściciela przy pierwszym dostępie poszukiwacza do atrybutu działania beacona. Wybranego klucza konta właściciela nie można zmienić, dopóki dostawca nie przywróci ustawień fabrycznych. Dostawca nie może usunąć klucza konta właściciela, gdy zabraknie wolnych slotów na klucze kont.

  • Dostawcy, którzy obsługują już FHN podczas parowania po raz pierwszy (lub obsługują go podczas parowania po przywróceniu ustawień fabrycznych), wybierają pierwszy klucz konta, ponieważ jest to jedyny istniejący klucz konta, gdy Seeker odczytuje stan obsługi podczas parowania.

  • Dostawcy, którzy uzyskają obsługę FHN po sparowaniu (np. poprzez aktualizację oprogramowania), mogą wybrać dowolny klucz konta. Rozsądnym rozwiązaniem jest wybranie pierwszego klucza konta, który jest używany do odczytu stanu obsługi z charakterystyki działań sygnalizatora po aktualizacji oprogramowania układowego, przy założeniu, że użytkownik, który przeprowadził aktualizację, jest bieżącym właścicielem dostawcy.

• Klucz tożsamości tymczasowej (EIK): klucz 32-bajtowy wybrany losowo przez poszukującego podczas procesu obsługi FHN. Ten klucz służy do wyprowadzania kluczy kryptograficznych, które są używane do pełnego szyfrowania raportów o lokalizacji. Seeker nigdy nie ujawnia go backendowi.

• Klucz odzyskiwania: zdefiniowany jako SHA256(ephemeral identity key || 0x01), przycięty do pierwszych 8 bajtów. Klucz jest przechowywany na serwerze, a poszukiwacz może go użyć do odzyskania klucza EIK, o ile użytkownik wyrazi zgodę, naciskając przycisk na urządzeniu.

• Klucz pierścienia: zdefiniowany jako SHA256(ephemeral identity key || 0x02), przycięty do pierwszych 8 bajtów. Klucz jest przechowywany na zapleczu, a poszukiwacz może go użyć tylko do dzwonienia na urządzenie.

• Klucz ochrony przed niechcianym śledzeniem: zdefiniowany jako SHA256(ephemeral identity key || 0x03), przycięty do pierwszych 8 bajtów. Klucz jest przechowywany na zapleczu, a poszukiwacz może go użyć tylko do aktywacji trybu ochrony przed niechcianym śledzeniem.

Operacje

Format danych zapisywanych w charakterystyce podano w tabelach 2–5. Każdą z tych operacji omówimy dokładniej w dalszej części tego rozdziału.

Octet	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 uwierzytelniania jednorazowego	Pierwsze 8 bajtów 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 okazowej, 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 beaconów

Octet	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 uwierzytelniania jednorazowego	Pierwsze 8 bajtów 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

Octet	Typ danych	Opis	Wartość
0	uint8	Identyfikator danych	0x05: Ring 0x06: odczyt stanu dzwonienia
1	uint8	Długość danych	zmienia się
2–9	tablica bajtów	Klucz uwierzytelniania jednorazowego	Pierwsze 8 bajtów 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.

Octet	Typ danych	Opis	Wartość
0	uint8	Identyfikator danych	0x07: Włączanie trybu ochrony przed niechcianym śledzeniem 0x08: dezaktywowanie trybu ochrony przed niechcianym śledzeniem
1	uint8	Długość danych	zmienia się
2–9	tablica bajtów	Klucz uwierzytelniania jednorazowego	Pierwsze 8 bajtów 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 adresu 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.

Octet	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: odczyt stanu dzwonienia 0x07: Włączanie trybu 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 o krótkim czasie ważności, szyfrowanym przy użyciu klucza konta za pomocą AES-ECB-128 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 pozwoleniem użytkownika, gdy urządzenie nie jest w trybie parowania.

Tabela 7. Kody błędów GATT

Odczyt parametrów beacona

Szukający może wysłać zapytanie do dostawcy 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 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 0x00. Dostawca tworzy segment danych w ten sposób:

Octet	Typ danych	Opis	Wartość
0	uint8	Skalibrowana moc	Skalibrowana moc 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 elementy – 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ępny wybór 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	Dodanie 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).

Odczytywanie stanu obsługi administracyjnej beacona

W celu uzyskania informacji o stanie obsługiwania sygnalizatora Seeker może wysłać do dostawcy zapytanie, wykonując operację zapisu do właściwości, która składa się z żądania z tabeli 2 o identyfikatorze danych 0x01. Usługodawca sprawdza, czy podany jednorazowy klucz uwierzytelniający 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:

Octet	Typ danych	Opis	Wartość
0	uint8	Stan udostępniania	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ł FHN 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. Usługodawca 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ż skonfigurowany jako sygnał FHN.

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

W przypadku powodzenia klucz tożsamości jest odszyfrowywany za pomocą algorytmu AES-ECB-128 przy użyciu klucza konta, które zostało dopasowane. Klucz powinien być przechowywany na urządzeniu, a od tego momentu dostawca powinien zacząć wyświetlać reklamy w ramkach FHN. 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 parametru 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

Aby odmówić udostępnienia części beacona dostawcy, szukający wykonuje operację zapisu do cechy, która składa się z żądania z tabeli 2 z identyfikatorem danych 0x03. Usługodawca 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 znacznik FHN lub weryfikacja się nie powiedzie, zwraca nieautoryzowany błąd.

W przypadku powodzenia dostawca usuwa klucz i przestaje wyświetlać ramki FHN. 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).

Czytanie klucza tożsamości tymczasowej za zgodą użytkownika

Ta opcja jest dostępna tylko do odzyskania utracone klucza, ponieważ klucz jest przechowywany 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 z identyfikatorem 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).

Dzwonienie

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:

Octet	Typ danych	Opis	Wartość
0	uint8	Dzwonienie	Maska bitowa o tych wartościach: Bit 1 (0x01): dzwonek w prawej. Bit 2 (0x02): dzwonek w lewej. 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: Średni 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 znacznik FHN lub weryfikacja się nie powiedzie, zwraca nieautoryzowany błąd. 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:

Octet	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: zatrzymano (żądanie GATT)
1	uint8	Komponenty dzwonienia	Bitmaska komponentów aktywnie dzwoniących, jak określono w prośbie.
2–3	uint16	Czas oczekiwania	Pozostały czas dzwonienia w decysekundach. Jeśli urządzenie przestało dzwonić, zwracana jest wartość 0x0000.

Segment uwierzytelniania to pierwsze 8 bajtów pola 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 zmysły), 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 do tej cechy, która składa się z żądania z tabeli 4 o identyfikatorze danych 0x06. Dostawca weryfikuje, czy podany klucz uwierzytelniania jednorazowego jest zgodny z kluczem szyfrowania.

Jeśli dostawca nie jest skonfigurowany jako znacznik FHN lub weryfikacja się nie powiedzie, dostawca zwróci błąd niezweryfikowany.

W przypadku powodzenia dostawca wysyła powiadomienie z odpowiednią wartością w tabeli 6 o identyfikatorze danych 0x06. Dostawca tworzy segment danych w ten sposób:

Octet	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 Centrum lokalizacji może przekazywać żądanie aktywacji trybu ochrony przed śledzeniem za pomocą sieci Centrum lokalizacji. W ten sposób usługa powoduje, że dostawca tymczasowo używa stałego adresu MAC, co pozwala klientom wykryć urządzenie i ostrzec użytkownika przed możliwym niechcianym śledzeniem.

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.

Gdy włączysz tryb ochrony przed niechcianym śledzeniem

Dostawca tworzy segment danych w ten sposób:

Octet	Typ danych	Opis	Wartość
0	uint8	Flagi sterujące	0x01: pomiń uwierzytelnianie podczas dzwonienia. Gdy ta opcja jest ustawiona, żądania wywołania 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 czasu dezaktywacji trybu ochrony przed niechcianym śledzeniem.

Dostawca weryfikuje, czy podany jednorazowy klucz uwierzytelniania jest zgodny z kluczem ochrony przed niepożądanym śledzeniem. Jeśli dostawca nie jest skonfigurowany jako sygnał FHN 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 też widoczny w sekcji flagi zaszyfrowane.

Wyłączanie trybu ochrony przed niechcianym śledzeniem

Usługodawca potwierdza, że:

• Podany jednorazowy klucz uwierzytelniania jest zgodny z kluczem ochrony przed niepożądanym śledzeniem.
• Zaszyfrowany klucz tożsamości tymczasowej jest zgodny z bieżącym kluczem tożsamości tymczasowej.

Jeśli dostawca nie jest skonfigurowany jako znacznik FHN lub weryfikacja się nie powiedzie, dostawca zwróci błąd niezweryfikowany.

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

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 zarezerwowaniu dostawca powinien wyświetlać ramki FHN co najmniej raz na 2 sekundy. Jeśli reklamowane są ramki Szybkiego parowania, dostawca powinien przeplatać ramki FHN w ramkach reklam Szybkiego parowania. Na przykład co 2 sekundy dostawca powinien wyświetlać 7 reklam Fast Pair i 1 reklamę FHN.

W przypadku reklam FHN moc nadawania Bluetooth powinna wynosić co najmniej 0 dBm.

Ramka FHN zawiera klucz publiczny używany do szyfrowania raportów o lokalizacji przez dowolnego klienta obsługującego, który przyczynia się do tworzenia sieci crowdsourcingowej. Dostępne są 2 rodzaje kluczy na 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 nich należy zastosować, zależy od implementacji dostawcy.

Ramka FHN ma taką strukturę:

Octet	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 FHN z wskaźnikiem trybu ochrony przed niepożądanym śledzeniem
8..27		20-bajtowy identyfikator tymczasowy
28		Zaszyfrowane flagi

Tabela 8: ramka FHN obsługująca krzywą 160-bitową.

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

Octet	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 FHN z wskaźnikiem trybu ochrony przed niepożądanym śledzeniem
8..39		32-bajtowy identyfikator tymczasowy
40		Zaszyfrowane flagi

Tabela 9: ramka FHN 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:

Octet	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 pole ograniczone 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ą odwoływane od najbardziej do najmniej istotnego):

• 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 naładowania baterii
  • 10: Niski poziom baterii
  • 11: bardzo niski poziom naładowania baterii (wkrótce trzeba będzie wymienić baterię)
• Bit 7 jest ustawiony na 1, jeśli beacon jest w trybie ochrony przed niechcianym śledzeniem, i na 0 w przeciwnym razie.

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 obserwująca (która odczytała Rx z beacona) wykona te czynności:

1. Wybierz losową liczbę s w Fp, zgodnie z definicją w sekcji Obliczanie identyfikatora EID.
2. Obliczanie S = s * G.
3. Oblicz R = (Rx, Ry), podstawiwszy wartość w równaniu krzywej i wybierając 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 to współrzędna 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. Obliczanie nonce = LRx || LSx.
7. Obliczanie (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 licznika czasu beacona w ostatniej przeszłości i najbliższej przyszłości.
2. Na podstawie wartości licznika czasu beacona, na którym opiera się URx, oblicz przewidywaną wartość r zgodnie z opisem 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), podstawiwszy wartość w równaniu krzywej i wybierając dowolną wartość Sy spośród możliwych wyników.
5. Oblicz k = HKDF-SHA256((r * S)x), gdzie (r * S)x jest współrzędną x wyniku mnożenia krzywej.
6. Obliczanie nonce = LRx || LSx.
7. Obliczanie m = AES-EAX-256-DEC(k, nonce, m’, tag).

Rotacja identyfikatorów

Do reklamowania za pomocą ramek FHN 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ń z protokołem 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 funkcji FHN i odpowiednie adresy BLE powinny być wyświetlane naprzemiennie w tym samym czasie. Rotacja powinna odbywać się średnio co 1024 sekundy. Dokładny moment, w którym beacon zaczyna reklamować nowy identyfikator, musi być losowy w ramach tego okna.

Zalecanym podejściem do losowania czasu rotacji jest ustawienie go na następny przewidywany czas rotacji (jeśli nie została zastosowana losowa kolejność) 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 FHN powinien być stały, ale RPA dla reklamy FP, która nie może być wykryta (np. szybkie parowanie), 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. Zaleca się, aby dostawca zapisywał bieżącą wartość zegara do pamięci nieulotnej co najmniej raz dziennie, a podczas uruchamiania sprawdzał, czy w pamięci NVM jest obecna wartość, z której można zainicjować urządzenie. Rozwiązania identyfikatora ulotnego byłyby wdrażane w okresie wystarczającym do uwzględnienia rozsądnego przesunięcia 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 jedną dodatkową metodę synchronizacji zegara (reklamowanie niewykrywalnych ramek Fast Pair lub wdrożenie strumienia wiadomości).

Wskazówki dotyczące implementacji Szybkiego parowania

Ta sekcja opisuje szczególne aspekty implementacji Szybkiego parowania w przypadku dostawców, którzy obsługują FHN.

Wytyczne dotyczące tagu lokalizatora

• Jeśli dostawca został sparowany, ale w ciągu 5 minut nie udało się skonfigurować FHN (lub jeśli aktualizacja OTA została zastosowana, gdy urządzenie było sparowane, ale nie skonfigurowano FHN), 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 FHN 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 wyszukiwarka 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ń w interfejsie.
• Ramki Szybkiego parowania, które można wykryć, nie powinny być reklamowane, gdy dostawca jest udostępniany w ramach funkcji HNI.
• Dostawca nie może ujawniać żadnych informacji umożliwiających identyfikację w sposób niezaufamy (np. imion lub identyfikatorów).

Wytyczne dotyczące urządzeń z klasycznym Bluetooth

Ta sekcja opisuje szczególne aspekty klasycznych urządzeń Bluetooth, które obsługują FHN.

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

Dostawca nie zawsze jest przygotowany do obsługi FHN podczas parowania z poszukującym, ale po pewnym czasie. 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 szukającym przez Bluetooth.

Obsługa obu tych metod zwiększa szanse na to, że użytkownik będzie mógł skonfigurować urządzenie do obsługi FHN.

Strumień wiadomości Szybkiego parowania

Dostawca może stosować strumień wiadomości Szybkiego parowania, aby powiadamiać żądającego o informacje o urządzeniu. Zaimplementowanie 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ę FHN 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 funkcji HNF.

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

Octet	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 Informacje o urządzeniu: zaktualizowano wersję oprogramowania.

Po otrzymaniu żądania aktualizacji możliwości (0x0601) dostawca, jeśli ma włączone obsługiwanie śledzenia FHN, powinien odpowiedzieć zgodnie z tabelą 12.

Octet	Typ danych	Opis	Wartość
0	uint8	Zdarzenie synchronizacji funkcjonalności urządzenia	0x06
1	uint8	Śledzenie FHN	0x03
2–3	uint16	Długość dodatkowych danych	0x0007
4	uint8	Stan obsługi administracyjnej FHN	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 przesyłać bieżący identyfikator EID i wartość zegara, gdy dostawca jest skonfigurowany pod kątem FHN, 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.

Octet	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 przywrócenie 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 urządzenia do ustawień fabrycznych (ręcznie lub programowo) dostawca nie powinien od razu reklamować funkcji Fast Pair, aby zapobiec uruchamianiu procesu parowania natychmiast po usunięciu urządzenia przez użytkownika.

Zapobieganie niechcianemu śledzeniu

Certyfikowane urządzenia FHN muszą też spełniać wymagania określone w wersji implementacji specyfikacji na potrzeby wykrywania niechcianych urządzeń śledząco-lokalizacyjnych (DULT).

Wskazówki dotyczące FHN, które są zgodne ze specyfikacją DULT:

• Urządzenie zgodne z HNF musi być zarejestrowane w konsoli Urządzenia w pobliżu i musi mieć włączoną funkcję „Znajdź Huba”.
• 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 kodów operacji Informacje o akcesoriach:
  • W ramach wywołania Get_Product_Data powinien zostać zwrócony identyfikator modelu dostarczony przez konsolę, uzupełniony zerami o wartościach 0, 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ść „Lokalizator”, 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 aktywacji tego trybu, które są specyficzne dla danego modelu, muszą zostać przekazane 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ć wbudowany 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 certyfikacji 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 będą 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 pracy w przypadku aplikacji mobilnych lub internetowych.

Szybkie parowanie umożliwia wysyłanie powiadomień do użytkownika z informacją 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ć funkcję GATT Rewizja 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ć Centrum lokalizacji wymaga włączenia usług lokalizacyjnych i Bluetootha. Wymaga zasięgu sieci komórkowej lub połączenia z internetem. Usługa działa w określonych krajach i wymaga Androida 9 lub nowszego oraz spełnienia wymagań dotyczących wieku.

Historia zmian

Wersja FHN	Data	Komentarz
v1		Pierwsza wersja specyfikacji FHN udostępniona w ramach wcześniejszego dostępu.
v1.1	luty 2023 r.	Dodano tryb ochrony przed niepożądanym śledzeniem z wyraźnym oznaczeniem. 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.