Specyfikacja akcesoriów sieci Centrum lokalizacji

v1.3

Specyfikacja akcesoriów sieci Centrum lokalizacji (FHN) określa w pełni zaszyfrowane podejście do śledzenia urządzeń Bluetooth Low Energy (BLE) wysyłających sygnały. Na tej stronie opisujemy FHN jako rozszerzenie specyfikacji Fast Pair. Dostawcy powinni włączyć to rozszerzenie, jeśli mają urządzenia zgodne z FHN i chcą włączyć śledzenie lokalizacji tych urządzeń.

Specyfikacja GATT

Do usługi szybkiego parowania należy dodać dodatkową charakterystykę GATT (Generic Attributes) o tej semantyce:

Charakterystyka usługi Szybkiego parowania	Zaszyfrowane	Uprawnienia	UUID
Działania związane z beaconami	Nie	Odczytywanie, zapisywanie i powiadamianie	FE2C1238-8366-4814-8EB0-01DE32100BEA

Tabela 1. Charakterystyka usługi Szybkie parowanie dla FHN.

Uwierzytelnianie

Operacje wymagane przez to rozszerzenie są wykonywane jako operacja zapisu, zabezpieczona mechanizmem wyzwanie-odpowiedź. Przed wykonaniem jakiejkolwiek operacji wyszukiwarka powinna wykonać operację odczytu z charakterystyki w  tabeli 1, co spowoduje utworzenie bufora w tym formacie:

Octet	Typ danych	Opis	Wartość
0	uint8	Numer wersji głównej protokołu	0x01
1–8	tablica bajtów	Jednorazowy losowy ciąg znaków	różni się

Każda operacja odczytu powinna generować inny nonce, a pojedynczy nonce powinien być ważny tylko w przypadku jednej operacji. Wartość nonce musi zostać unieważniona, nawet jeśli operacja się nie powiodła.

Wyszukiwarka oblicza następnie jednorazowy klucz uwierzytelniania, który będzie używany w kolejnym żądaniu zapisu. Klucz uwierzytelniający jest obliczany zgodnie z opisem w tabelach 2–5. W zależności od żądanej operacji osoba wysyłająca żądanie musi udowodnić, że zna co najmniej jeden z tych kluczy:

• Klucz konta: 16-bajtowy klucz konta Szybkiego parowania zdefiniowany w specyfikacji Szybkiego parowania.

• Klucz konta właściciela: dostawca wybiera jeden z istniejących kluczy konta jako klucz konta właściciela, gdy użytkownik po raz pierwszy uzyskuje dostęp do charakterystyki Beacon Actions. Klucza wybranego 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ę bezpłatne miejsca na klucze kont.

  • Dostawcy, którzy obsługują FHN podczas pierwszego parowania (lub obsługują je podczas parowania po przywróceniu ustawień fabrycznych), wybierają pierwszy klucz konta, ponieważ jest to jedyny istniejący klucz konta, gdy urządzenie wyszukujące odczytuje stan udostępniania podczas parowania.

  • Dostawcy, którzy uzyskają obsługę FHN po sparowaniu (np. w wyniku aktualizacji oprogramowania), mogą wybrać dowolny istniejący klucz konta. Rozsądne jest wybranie pierwszego klucza konta, który jest używany do odczytywania stanu udostępniania z charakterystyki działań beacon po aktualizacji oprogramowania sprzętowego, przy założeniu, że użytkownik, który przeprowadził aktualizację, jest obecnym właścicielem dostawcy.

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

• Klucz odzyskiwania: zdefiniowany jako SHA256(ephemeral identity key || 0x01), skrócony do pierwszych 8 bajtów. Klucz jest przechowywany na backendzie, a wyszukiwarka może go użyć do odzyskania klucza EIK, pod warunkiem że użytkownik wyrazi zgodę, naciskając przycisk na urządzeniu.

• Klucz pierścieniowy: zdefiniowany jako SHA256(ephemeral identity key || 0x02), skrócony do pierwszych 8 bajtów. Klucz jest przechowywany na serwerze backendu, a osoba szukająca może go używać tylko do dzwonienia na urządzenie.

• Klucz ochrony przed niechcianym śledzeniem: zdefiniowany jakoSHA256(ephemeral identity key || 0x03), skrócony do pierwszych 8 bajtów. Klucz jest przechowywany na serwerze backendu, a osoba wyszukująca może go używać tylko do aktywowania trybu ochrony przed niechcianym śledzeniem.

Operacje

Format danych zapisywanych w charakterystyce podano w tabelach 2–5. Każda z tych operacji zostanie omówiona szczegółowo w dalszej części tej sekcji.

Octet	Typ danych	Opis	Wartość
0	uint8	Identyfikator danych	0x00: Odczyt parametrów beacona 0x01: Odczytaj stan obsługi administracyjnej 0x02: Set ephemeral identity key 0x03: wyczyść klucz tożsamości tymczasowej;
1	uint8	Długość danych	różni się
2–9	tablica bajtów	Jednorazowy klucz uwierzytelniający	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: n/a 0x01: n/a 0x02: 32 bajty, które są tymczasowym kluczem tożsamości, zaszyfrowanym za pomocą AES-ECB-128 przy użyciu klucza konta. Jeśli dostawca ma już ustawiony tymczasowy klucz tożsamoś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 SHA256(ephemeral identity key || the last nonce read from the characteristic)

Tabela 2. Prośba o udostępnienie sygnału.

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	Jednorazowy klucz uwierzytelniający	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 do udostępniania sygnałów.

Octet	Typ danych	Opis	Wartość
0	uint8	Identyfikator danych	0x05: Dzwonek 0x06: Odczytywanie stanu dzwonka
1	uint8	Długość danych	różni się
2–9	tablica bajtów	Jednorazowy klucz uwierzytelniający	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 dzwonka, czas trwania dzwonka i głośność dzwonka. 0x06: n/a

Tabela 4. Żądanie dzwonienia.

Octet	Typ danych	Opis	Wartość
0	uint8	Identyfikator danych	0x07: włącz tryb ochrony przed niechcianym śledzeniem 0x08: Wyłącz tryb ochrony przed niechcianym śledzeniem
1	uint8	Długość danych	różni się
2–9	tablica bajtów	Jednorazowy klucz uwierzytelniający	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 SHA256(ephemeral identity key || the last nonce read from the characteristic)

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

Udane zapisy wywołują powiadomienia wymienione w tabeli 6.

Powiadomienia z identyfikatorem danych innym niż 0x05: zmiana stanu dzwonka powinny być wysyłane przed zakończeniem transakcji zapisu, która wywołuje powiadomienie, czyli przed wysłaniem jednostki PDU odpowiedzi na żądanie zapisu.

Octet	Typ danych	Opis	Wartość
0	uint8	Identyfikator danych	0x00: Odczyt parametrów beacona 0x01: Odczytaj stan obsługi administracyjnej 0x02: Set ephemeral identity key 0x03: wyczyść klucz tożsamości tymczasowej; 0x04: Odczyt tymczasowego klucza tożsamości za zgodą użytkownika 0x05: Zmiana stanu dzwonka 0x06: Odczytywanie stanu dzwonka 0x07: włącz tryb ochrony przed niechcianym śledzeniem 0x08: Wyłącz tryb ochrony przed niechcianym śledzeniem
1	uint8	Długość danych	różni się
2–9	tablica bajtów	Uwierzytelnianie	Szczegółowe informacje o każdej 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, zaszyfrowanych algorytmem AES-ECB-128 za pomocą klucza konta (uzupełnionych zerami). 0x01: 1 bajt wskazujący stan udostępniania, a następnie bieżący tymczasowy identyfikator (20 lub 32 bajty), jeśli ma to zastosowanie. 0x04: 32 bajty, które są tymczasowym kluczem tożsamości, zaszyfrowanym za pomocą AES-ECB-128 przy użyciu klucza konta. 0x05: 4 bajty wskazujące nowy stan i przyczynę zmiany 0x06: 3 bajty wskazujące aktywne dzwonienie komponentów i liczbę pozostałych dziesiętnych części sekundy dzwonienia Inne identyfikatory danych używają pustych danych dodatkowych

Tabela 6. Odpowiedź usługi Beacon.

W tabeli 7 znajdziesz możliwe kody błędów GATT zwracane przez operacje.

Kod	Opis	Uwagi
0x80	Nieuwierzytelnione	Zwracany w odpowiedzi na żądanie zapisu, gdy uwierzytelnianie się nie powiedzie (w tym w przypadku użycia starego losowego ciągu znaków).
0x81	Nieprawidłowa wartość	Zwracany, gdy podano nieprawidłową wartość lub otrzymane dane mają nieoczekiwaną liczbę bajtów.
0x82	Brak zgody użytkownika	Zwracany w odpowiedzi na żądanie zapisu z identyfikatorem danych 0x04: Read ephemeral identity key with user consent (Odczytaj tymczasowy klucz tożsamości za zgodą użytkownika), gdy urządzenie nie jest w trybie parowania.

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

Odczytywanie parametru sygnału

Urządzenie wyszukujące może wysyłać do urządzenia udostępniającego zapytania o parametry sygnału, wykonując operację zapisu w charakterystyce składającej się z żądania z tabeli 2 z identyfikatorem danych 0x00. Dostawca sprawdza, czy podany jednorazowy klucz uwierzytelniania pasuje do któregokolwiek z kluczy konta przechowywanych na urządzeniu.

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

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 odebrana w odległości 0 m (wartość z zakresu [-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 rozszerzonego reklamowania)
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 elementy, lewa i prawa słuchawka, mogą dzwonić niezależnie. 0x03: oznacza, że 3 elementy – lewa i prawa słuchawka oraz etui – mogą dzwonić niezależnie od siebie.
7	uint8	Funkcje dzwonienia	Obsługiwane opcje: 0x00: Wybór głośności dzwonka jest niedostępny. 0x01: dostępny wybór głośności dzwonka. Jeśli ta opcja jest ustawiona, dostawca musi akceptować i obsługiwać 3 poziomy głośności, jak wskazano w sekcji Działanie dzwonka.
8-15	tablica bajtów	Dopełnienie	Wypełnianie zerami na potrzeby szyfrowania AES.

Dane powinny być zaszyfrowane algorytmem AES-ECB-128 przy użyciu 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

Wyszukiwarka może wysłać do dostawcy zapytanie o stan udostępniania sygnału, wykonując operację zapisu w charakterystyce składającej się z żądania z tabeli 2 z identyfikatorem danych 0x01. Dostawca sprawdza, czy podany jednorazowy klucz uwierzytelniania pasuje do któregokolwiek z kluczy konta przechowywanych na urządzeniu.

Jeśli weryfikacja się nie powiedzie, dostawca zwraca błąd nieuwierzytelnienia.

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 na urządzeniu jest ustawiony tymczasowy klucz tożsamości. Bit 2 (0x02): ustawiony, jeśli podany jednorazowy klucz uwierzytelniania pasuje do klucza konta właściciela.
1–20 lub 32	tablica bajtów	Bieżący identyfikator tymczasowy	20 lub 32 bajtów (w zależności od używanej metody szyfrowania) wskazujących bieżący tymczasowy identyfikator rozgłaszany przez beacon, jeśli jest on 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 tymczasowego klucza tożsamości

Aby udostępnić nieudostępnionego dostawcę jako beacon FHN lub zmienić tymczasowy klucz tożsamości już udostępnionego dostawcy, poszukujący wykonuje operację zapisu w charakterystyce składającej 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 skrót tymczasowego klucza tożsamości, zaszyfrowany tymczasowy klucz tożsamości jest zgodny z obecnym tymczasowym kluczem tożsamości.
• Jeśli nie podano skrótu klucza tożsamości tymczasowej, sprawdź, czy dostawca nie został już skonfigurowany jako beacon FHN.

Jeśli weryfikacja się nie powiedzie, dostawca zwraca błąd nieuwierzytelnienia.

Jeśli operacja się powiedzie, klucz tożsamości tymczasowej zostanie odzyskany przez odszyfrowanie go za pomocą algorytmu AES-ECB-128 przy użyciu pasującego klucza konta. Klucz powinien być przechowywany na urządzeniu, a od tego momentu dostawca powinien zacząć reklamować ramki FHN. Nowy tymczasowy klucz tożsamości zacznie obowiązywać natychmiast po zakończeniu połączenia BLE. Dostawca wysyła powiadomienie z odpowiedzią 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).

Wyczyść klucz tożsamości tymczasowej

Aby wycofać z użycia część dostawcy związaną z beaconem, poszukujący wykonuje operację zapisu w charakterystyce, która polega na wysłaniu żą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 tymczasowy klucz tożsamości jest zgodny z obecnym tymczasowym kluczem tożsamości.

Jeśli dostawca nie jest skonfigurowany jako beacon FHN lub weryfikacja się nie powiedzie, zwracany jest błąd nieuwierzytelnienia.

Po pomyślnym zakończeniu procesu dostawca zapomina klucz i przestaje reklamować ramki FHN. Dostawca wysyła powiadomienie z odpowiedzią 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 tymczasowego klucza tożsamości za zgodą użytkownika

Ta opcja jest dostępna tylko w przypadku odzyskiwania utraconego klucza, ponieważ jest on przechowywany lokalnie przez urządzenie wyszukujące. Dlatego 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 w formie zwykłego tekstu, wyszukujący musi przechowywać klucz odzyskiwania na backendzie, ale nie przechowuje samego klucza EIK.

Aby odczytać EIK, urządzenie wysyłające wykonuje operację zapisu w charakterystyce, która polega na wysłaniu żądania z tabeli 3 z identyfikatorem danych 0x04. Dostawca potwierdza, że:

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

Jeśli weryfikacja się nie powiedzie, dostawca zwraca błąd nieuwierzytelnienia.

Jeśli urządzenie nie jest w trybie parowania, dostawca zwraca błąd No User Consent (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

Urządzenie wyszukujące może poprosić urządzenie udostępniające o odtworzenie dźwięku, wykonując operację zapisu w charakterystyce, która składa się z żądania z tabeli 4 z identyfikatorem danych 0x05. Dostawca tworzy segment danych w ten sposób:

Octet	Typ danych	Opis	Wartość
0	uint8	Działanie dzwonka	Maska bitowa o tych wartościach: Bit 1 (0x01): uruchom dzwonek w prawej Bit 2 (0x02): dzwonek w lewej Bit 3 (0x04): etui z uchwytem 0xFF: zadzwoń do wszystkich komponentów 0x00: Wyłącz dzwonek
1–2	uint16	Czas oczekiwania	Czas oczekiwania w decysekundach. Nie może wynosić zera ani być większy niż odpowiednik 10 minut. Dostawca używa tej wartości, aby określić, jak długo ma dzwonić, zanim się wyciszy. Limit czasu zastępuje ten, który jest już aktywny, jeśli którykolwiek element urządzenia już dzwoni. Jeśli operacja dzwonienia ma wartość 0x00, czas oczekiwania jest ignorowany.
3	uint8	Głośność	0x00: Domyślna 0x01: niski 0x02: średni 0x03: wysoki Dokładne znaczenie tych wartości zależy od implementacji.

Po otrzymaniu prośby dostawca sprawdza, czy:

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

Jeśli dostawca nie jest skonfigurowany jako beacon FHN lub weryfikacja się nie powiedzie, zwracany jest błąd nieuwierzytelnienia. Jeśli jednak dostawca ma włączoną ochronę przed niechcianym śledzeniem, a żądanie, które ją wywołało, miało włączoną flagę pomijania uwierzytelniania przez dzwonienie, dostawca powinien pominąć to sprawdzenie. Dane uwierzytelniające nadal powinny być dostarczane przez wyszukującego, ale można ustawić dowolną wartość.

Gdy dzwonek zacznie dzwonić lub przestanie, wysyłane jest powiadomienie zgodnie z tabelą 6 z identyfikatorem danych 0x05. Treść powiadomienia jest określona w ten sposób:

Octet	Typ danych	Opis	Wartość
0	uint8	Stan dzwonienia	0x00: rozpoczęto 0x01: Nie udało się uruchomić ani zatrzymać (wszystkie żądane komponenty są poza zakresem) 0x02: Zatrzymano (przekroczono limit czasu) 0x03: Zatrzymano (naciśnięcie przycisku) 0x04: Zatrzymano (żądanie GATT)
1	uint8	Komponenty dzwonienia	Bitmaska komponentów, które aktywnie dzwonią, zgodnie z definicją w żądaniu.
2–3	uint16	Czas oczekiwania	Pozostały czas dzwonienia w decysekundach. Jeśli urządzenie przestało dzwonić, należy zwrócić wartość 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 urządzenie jest już w żądanym stanie dzwonienia, gdy otrzyma żądanie dzwonienia lub zatrzymania dzwonienia, dostawca powinien wysłać powiadomienie ze stanem dzwonienia lub odpowiednio 0x00: Started (Rozpoczęto) lub 0x04: Stopped (Zatrzymano) (żądanie GATT). To żądanie zastępuje parametry istniejącego stanu, dzięki czemu można wydłużyć czas dzwonienia.

Jeśli urządzenie dostawcy ma przycisk fizyczny (lub jest włączona funkcja wykrywania dotyku), powinien on zatrzymać dzwonienie, jeśli zostanie naciśnięty, gdy dzwonienie jest aktywne.

Pobieranie stanu dzwonienia lokalizatora

Aby uzyskać stan dzwonienia beacona, urządzenie wysyłające wykonuje operację zapisu w charakterystyce, która składa się z żądania z tabeli 4 z identyfikatorem danych 0x06. Dostawca sprawdza, czy podany jednorazowy klucz uwierzytelniania pasuje do klucza pierścienia.

Jeśli dostawca nie jest skonfigurowany jako beacon FHN lub weryfikacja się nie powiedzie, zwraca błąd nieuwierzytelnienia.

W przypadku powodzenia dostawca wysyła powiadomienie z odpowiedzią z tabeli 6 z identyfikatorem 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, należy zwrócić 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 na celu umożliwienie każdemu klientowi identyfikowania urządzeń, które mogą być wykorzystywane do nadużyć, 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 niechcianym śledzeniem przez sieć Centrum lokalizacji. 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 niechcianym śledzeniu.

Aby włączyć lub wyłączyć tryb ochrony przed niechcianym śledzeniem sygnału, urządzenie wyszukujące wykonuje operację zapisu w charakterystyce, która polega na wysłaniu żądania z tabeli 5 z identyfikatorem danych 0x07 lub 0x08.

Włączanie trybu ochrony przed niechcianym śledzeniem

Dostawca tworzy segment danych w ten sposób:

Octet	Typ danych	Opis	Wartość
0	uint8	Flagi kontrolne	0x01: Pomiń uwierzytelnianie przez dzwonienie. Gdy to ustawienie jest włączone, żądania dzwonka nie są uwierzytelniane w trybie ochrony przed niechcianym śledzeniem. Jeśli nie jest ustawiona żadna flaga (bajt składa się z samych zer), można całkowicie pominąć sekcję danych i wysłać pustą sekcję danych. Flagi są aktywne tylko do momentu dezaktywacji trybu ochrony przed niechcianym śledzeniem.

Dostawca sprawdza, czy podany jednorazowy klucz uwierzytelniający jest zgodny z kluczem ochrony przed niechcianym śledzeniem. Jeśli dostawca nie jest skonfigurowany jako beacon FHN lub weryfikacja się nie powiedzie, zwracany jest błąd nieuwierzytelnienia.

Gdy włączony jest tryb ochrony przed niechcianym śledzeniem, sygnał powinien zmniejszyć częstotliwość rotacji prywatnego adresu MAC do 1 razu na 24 godziny. Reklamowany identyfikator tymczasowy powinien nadal zmieniać się jak zwykle. Typ ramki powinien być ustawiony na 0x41. Stan jest też widoczny w sekcji zahaszowane flagi.

Wyłączanie trybu ochrony przed niechcianym śledzeniem

Dostawca potwierdza, że:

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

Jeśli dostawca nie jest skonfigurowany jako beacon FHN lub weryfikacja się nie powiedzie, dostawca zwraca błąd nieuwierzytelnienia.

Gdy niechciany tryb ochrony przed śledzeniem zostanie wyłączony, beacon powinien ponownie zacząć obracać adres MAC z normalną częstotliwością, zsynchronizowaną z rotacją identyfikatora tymczasowego. Typ ramki powinien zostać przywrócony do wartości 0x40. Stan jest też widoczny w sekcji zaszyfrowane flagi.

W przypadku powodzenia dostawca wysyła powiadomienie z odpowiedzią 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).

Rozgłaszane ramki

Po udostępnieniu dostawca powinien reklamować ramki FHN co najmniej raz na 2 sekundy. Jeśli ramki Szybkiego parowania są reklamowane, dostawca powinien przeplatać ramki FHN ze zwykłymi reklamami Szybkiego parowania. Na przykład co 2 sekundy dostawca powinien wyświetlać 7 reklam Fast Pair i 1 reklamę FHN.

Moc nadawania Bluetooth w przypadku reklam FHN powinna być ustawiona na co najmniej 0 dBm.

Ramka FHN zawiera klucz publiczny używany do szyfrowania raportów o lokalizacji przez dowolnego klienta obsługującego sieć crowdsourcingową. Dostępne są 2 rodzaje kluczy krzywych eliptycznych: 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. Implementacja dostawcy określa, która krzywa jest używana.

Ramka FHN ma taką strukturę:

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

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

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

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

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

Obliczanie identyfikatora tymczasowego (EID)

Liczba losowa jest generowana przez zaszyfrowanie za pomocą AES-ECB-256 tej struktury danych kluczem tożsamości tymczasowej:

Octet	Pole	Opis
0–10	Dopełnienie	Wartość = 0xFF
11	K	Wykładnik okresu rotacji
12–15	TS[0]...TS[3]	Licznik czasu sygnału w 32-bitowym formacie big-endian. K najmniej znaczących bitów jest wyzerowanych.
16–26	Dopełnienie	Wartość = 0x00
27	K	Wykładnik okresu rotacji
28–31	TS[0]...TS[3]	Licznik czasu sygnału w 32-bitowym formacie big-endian. K najmniej znaczących bitów jest wyzerowanych.

Tabela 10. Konstrukcja liczby pseudolosowej.

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

W pozostałej części obliczeń symbole SECP160R1 i SECP256R1 są używane w operacjach kryptograficznych na krzywych eliptycznych. Definicje krzywych znajdziesz w sekcji SEC 2: Recommended Elliptic Curve Domain Parameters (Zalecane parametry domeny krzywej eliptycznej), w której zdefiniowano parametry Fp, n i G wspomniane dalej.

Wartość r' jest teraz rzutowana na ciało skończone Fp przez obliczenie r = r' mod n. Na koniec oblicz R = r * G, czyli punkt na krzywej reprezentujący używany klucz publiczny. Beacon emituje Rx, czyli współrzędną x punktu R, jako swój identyfikator tymczasowy.

Zaszyfrowane flagi

Pole zaszyfrowanych flag jest obliczane w ten sposób (bity są podawane od najbardziej do najmniej znaczącego):

• Bity 0–4: zarezerwowane (ustawione na zera).
• Bity 5–6 wskazują poziom baterii urządzenia w ten sposób:
  • 00. Wskaźnik poziomu naładowania baterii nie jest obsługiwany
  • 01. Normalny poziom baterii
  • 10. Niski poziom baterii
  • 11. Krytycznie niski poziom baterii (wkrótce trzeba będzie ją wymienić)
• Bit 7 ma wartość 1, jeśli lokalizator jest w trybie ochrony przed niechcianym śledzeniem, a w przeciwnym razie ma wartość 0.

Aby uzyskać ostateczną wartość tego bajtu, wykonuje się na nim operację XOR z najmniej znaczącym bajtem wartości SHA256(r).

Pamiętaj, że r powinno być dopasowane do rozmiaru krzywej. Jeśli reprezentacja jest krótsza niż 160 lub 256 bitów, dodaj zera jako najbardziej znaczące bity. Jeśli reprezentacja jest dłuższa niż 160 lub 256 bitów, najbardziej znaczące bity powinny zostać obcięte.

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

Szyfrowanie za pomocą identyfikatora EID

Aby zaszyfrować wiadomość m, osoba, która odczytała Rx z beacona, musi wykonać te czynności:

1. Wybierz losową liczbę s w Fp, zgodnie z definicją w sekcji Obliczanie identyfikatora EID.
2. Compute S = s * G
3. Oblicz R = (Rx, Ry), podstawiając wartości do równania krzywej i wybierając dowolną wartość Ry z 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 krzywych. Nie określono ciągu zaburzającego.
5. Niech URx i LRx będą odpowiednio górnymi i dolnymi 80 bitami liczby Rx w formacie big-endian. W podobny sposób zdefiniuj USx i LSx dla S.
6. Compute nonce = LRx || LSx
7. Compute (m’, tag) = AES-EAX-256-ENC(k, nonce, m)
8. Wysyłanie (URx, Sx, m’, tag) do właściciela, prawdopodobnie za pomocą niezaufanej usługi zdalnej.

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 parametru URx uzyskaj wartość licznika czasu sygnału, na którym opiera się parametr URx. Może to zrobić urządzenie klienta właściciela, obliczając wartości Rx dla wartości licznika czasu sygnału w niedalekiej przeszłości i przyszłości.
2. Na podstawie wartości licznika czasu sygnału, na której opiera się wartość URx, oblicz oczekiwaną wartość r zgodnie z opisem w sekcji Obliczanie identyfikatora EID.
3. Oblicz R = r * G i sprawdź, czy jest zgodny z wartością URx podaną przez osobę, która widziała zdarzenie.
4. Oblicz S = (Sx, Sy), podstawiając wartości do równania krzywej i wybierając dowolną wartość Sy z możliwych wyników.
5. Oblicz k = HKDF-SHA256((r * S)x), gdzie (r * S)x to współrzędna x wyniku mnożenia krzywych.
6. Compute nonce = LRx || LSx
7. Compute m = AES-EAX-256-DEC(k, nonce, m’, tag)

Rotacja identyfikatorów

Do reklamowania ramek FHN musi być używany adres BLE, który można (RPA) lub którego nie można (NRPA) rozpoznać. RPA jest wymagane w przypadku urządzeń LE Audio (LEA) i zalecane w przypadku innych urządzeń, z wyjątkiem lokalizatorów, które nie korzystają z powiązania.

Reklama szybkiego parowania, reklama FHN i odpowiednie adresy BLE powinny zmieniać się w tym samym czasie. Rotacja powinna następować średnio co 1024 sekundy. Dokładny moment, w którym beacon zaczyna reklamować nowy identyfikator, musi być losowy w ramach okna.

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

Gdy urządzenie jest w trybie ochrony przed niechcianym śledzeniem, adres BLE reklamy FHN powinien być stały, ale adres RPA reklamy FP w trybie niewykrywalności (np. szybkiego parowania) musi się zmieniać. Dopuszczalne jest używanie różnych adresów dla różnych protokołów.

Przywracanie po utracie zasilania

Rozwiązanie identyfikatora tymczasowego jest ściśle powiązane z wartością zegara w momencie wyświetlenia reklamy, dlatego ważne jest, aby w przypadku utraty zasilania dostawca mógł odzyskać wartość zegara. Zaleca się, aby dostawca zapisywał bieżącą wartość zegara w pamięci nietrwałej co najmniej raz dziennie, a po uruchomieniu sprawdzał, czy w pamięci nietrwałej znajduje się wartość, na podstawie której można zainicjować zegar. Rozwiązania identyfikatora tymczasowego będą realizować rozpoznawanie w okresie wystarczającym do uwzględnienia zarówno rozsądnego odchylenia zegara, jak i tego typu przywracania zasilania.

Usługodawcy powinni nadal dokładać wszelkich starań, aby zminimalizować odchylenia zegara, ponieważ okno czasu rozwiązania jest ograniczone. Należy wdrożyć co najmniej 1 dodatkową metodę synchronizacji zegara (reklamowanie niewykrywalnych ramek Fast Pair lub wdrożenie strumienia wiadomości).

Wytyczne dotyczące implementacji Szybkiego parowania

W tej sekcji opisujemy specjalne aspekty wdrożenia szybkiego parowania u dostawców obsługujących FHN.

Szczegółowe wytyczne dotyczące tagu lokalizatora

• Jeśli dostawca został sparowany, ale FHN nie został udostępniony w ciągu 5 minut (lub jeśli aktualizacja OTA została zastosowana, gdy urządzenie było sparowane, ale nie udostępniono 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 udostępniona usługa FHN lub nie minie 5 minut.
• Jeśli klucz tożsamości tymczasowej zostanie usunięty z urządzenia, powinno ono przywrócić ustawienia fabryczne i usunąć zapisane klucze konta.
• Dostawca powinien odrzucać zwykłe próby parowania Bluetooth i akceptować tylko parowanie Fast Pair.
• Dostawca musi udostępnić mechanizm, który umożliwia użytkownikom tymczasowe zatrzymanie wyświetlania reklam bez przywracania urządzenia do ustawień fabrycznych (np. przez naciśnięcie kombinacji przycisków).
• Po utracie zasilania urządzenie powinno emitować niewidoczne ramki Szybkiego parowania do momentu następnego wywołania funkcji read beacon parameters (odczyt parametrów beacona). Dzięki temu urządzenie wyszukujące może wykryć urządzenie i zsynchronizować zegar, nawet jeśli wystąpiło znaczne odchylenie zegara.
• Podczas reklamowania niewykrywalnych ramek Szybkiego parowania nie należy włączać elementów interfejsu.
• Ramki Szybkiego parowania, które można wykryć, nie powinny być reklamowane, gdy dostawca jest skonfigurowany pod kątem FHN.
• Dostawca nie powinien udostępniać żadnych informacji umożliwiających identyfikację w sposób nieuwierzytelniony (np. imion i nazwisk lub identyfikatorów).

Wytyczne dotyczące urządzeń Bluetooth Classic

W tej sekcji opisujemy specjalne aspekty klasycznych urządzeń Bluetooth, które obsługują FHN.

Obsługa administracyjna FHN w przypadku urządzeń, które są już sparowane

Dostawca nie zawsze jest przygotowany do FHN podczas parowania z osobą szukającą pomocy, ale po pewnym czasie. W takim przypadku dostawca może nie mieć aktualnego adresu BLE MAC, który jest wymagany do nawiązania połączenia GATT. Dostawca musi obsługiwać co najmniej 1 z tych sposobów uzyskiwania adresu BLE przez urządzenie wyszukujące, gdy jest ono już sparowane:

• Dostawca może okresowo reklamować dane konta Fast Pair, które umożliwiają urządzeniu wyszukującemu znalezienie adresu BLE za pomocą skanowania BLE.
  To podejście jest odpowiednie dla dostawców, którzy nie wdrażają strumienia wiadomości.
• Wydawca może udostępniać te dane za pomocą strumienia wiadomości Szybkiego parowania przez Bluetooth Classic.
  To podejście jest odpowiednie dla dostawców, którzy nie wyświetlają ramek Szybkiego parowania, gdy są połączeni z urządzeniem wyszukującym przez Bluetooth.

Obsługa obu tych metod zwiększa szanse użytkownika na skonfigurowanie urządzenia pod kątem FHN.

Strumień wiadomości Szybkiego parowania

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

Dostawca powinien wysyłać wiadomości z informacjami o urządzeniu raz za każdym razem, gdy zostanie nawiązane połączenie RFCOMM w strumieniu wiadomości.

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

Gdy aktualizacja oprogramowania sprzętowego doda do dostawcy obsługę FHN, połączony lokalizator może powiadomić o tym użytkownika i zaproponować mu jego skonfigurowanie. W innym przypadku użytkownik musi ręcznie przejść do listy urządzeń Bluetooth, aby rozpocząć obsługę administracyjną FHN.

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

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	różni się
var	tablica bajtów	Ciąg znaków wersji	różni się

Tabela 11. Zdarzenie dotyczące informacji o urządzeniu: zaktualizowana wersja oprogramowania.

Po otrzymaniu żądania aktualizacji funkcji (0x0601), jeśli dostawca włączył obsługę śledzenia FHN, powinien odpowiedzieć zgodnie z tabelą 12.

Octet	Typ danych	Opis	Wartość
0	uint8	Zdarzenie dotyczące synchronizacji funkcji 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 udostępniony; 0x01, jeśli jest udostępniony przez jakiekolwiek konto
5–10	tablica bajtów	Aktualny adres MAC BLE urządzenia	różni się

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

Aktualny identyfikator tymczasowy (kod informacji o urządzeniu 0x0B)

Dostawca może użyć bieżącego identyfikatora tymczasowego (kod 0x0B), aby zgłosić bieżący identyfikator EID i wartość zegara, gdy jest on udostępniany na potrzeby FHN, aby zsynchronizować wyszukiwarkę w przypadku odchylenia zegara (np. z powodu wyczerpania baterii). W przeciwnym razie Seeker zainicjuje w tym celu 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óć ustawienia fabryczne

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

Po przywróceniu urządzenia do ustawień fabrycznych (ręcznym lub programowym) dostawca nie powinien od razu rozpoczynać reklamowania szybkiego parowania, aby zapobiec rozpoczęciu procesu parowania natychmiast po usunięciu urządzenia przez użytkownika.

Zapobieganie niechcianemu śledzeniu

Certyfikowane urządzenia FHN muszą też spełniać wymagania w wersji implementacyjnej specyfikacji międzyplatformowej dotyczącej wykrywania niechcianych lokalizatorów (DULT).

Odpowiednie wytyczne dotyczące FHN, które zapewniają zgodność ze specyfikacją DULT:

• Każde urządzenie zgodne z FHN musi być zarejestrowane w konsoli urządzeń w pobliżu i mieć włączoną funkcję „Znajdź hub”.
• Urządzenie musi implementować usługę i charakterystykę Accessory Non-Owner zdefiniowane w wersji specyfikacji DULT, w tym operacje Accessory Information i Non-owner controls.
• W okresie zgodności wstecznej, określonym w specyfikacji DULT, nie ma zmian w reklamowanej ramce zdefiniowanej w tym dokumencie.
• „Tryb ochrony przed niechcianym śledzeniem” zdefiniowany w tym dokumencie odpowiada „stanowi rozdzielenia” zdefiniowanemu w specyfikacji DULT.
• Wskazówki dotyczące implementowania kodów operacji Accessory Information:
  • Funkcja Get_Product_Data powinna zwracać identyfikator modelu podany przez konsolę, uzupełniony zerami do 8 bajtów. Na przykład identyfikator modelu 0xFFFFFF jest zwracany jako 0x0000000000FFFFFF.
  • Funkcje Get_Manufacturer_Name i Get_Model_Name powinny odpowiadać wartościom podanym 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.
  • Funkcja Get_Accessory_Capabilities musi wskazywać 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 po aktywowaniu przez użytkownika trybu „identyfikacji”, który wymaga kombinacji naciśnięć przycisków. Sygnał wizualny lub dźwiękowy powinien informować użytkownika, że dostawca wszedł w ten tryb. Instrukcje aktywacji tego trybu dla danego modelu muszą zostać przekazane Google jako wymaganie certyfikacji i co najmniej 10 dni przed wprowadzeniem jakichkolwiek aktualizacji lub modyfikacji instrukcji.
  • Odpowiedź jest tworzona w ten sposób: pierwsze 10 bajtów bieżącego identyfikatora tymczasowego, a następnie pierwsze 8 bajtów wartości HMAC-SHA256(recovery key, the truncated current ephemeral identifier).
• Wskazówki dotyczące wdrażania 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 dla funkcji Get_Identifier, zakodowanej w formacie szesnastkowym.
  • Jako parametr pid użyj tej samej odpowiedzi, która została utworzona dla funkcji Get_Product_Data, zakodowanej w formacie szesnastkowym.
• Urządzenie musi zawierać głośnik i obsługiwać funkcję dzwonienia. Zgodnie ze specyfikacją DULT urządzenie emitujące dźwięk musi emitować dźwięk o minimalnej głośności szczytowej 60 fonów zgodnie z normą ISO 532-1:2017.
• Wskazówki dotyczące implementowania kodu operacji Sound_Start:
  • Polecenie powinno wywołać dzwonienie na 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 urządzenia do ustawień fabrycznych (np. naciśnięcie kombinacji przycisków).
  • Instrukcje wyłączania muszą być udokumentowane w publicznie dostępnym adresie URL i przekazane Google jako wymaganie certyfikacji co najmniej 10 dni przed wprowadzeniem jakichkolwiek aktualizacji lub modyfikacji instrukcji.
  • Adres URL powinien obsługiwać lokalizację. W zależności od klienta język będzie podawany jako parametr zapytania („hl=en”) lub w nagłówku HTTP „accept-language”.

Wytyczne dotyczące protokołów z możliwością przełączania

• W danym momencie należy używać tylko jednego protokołu. Upewnij się, że na urządzeniu może działać jednocześnie tylko jedna sieć. Jest to konieczne, aby zapobiec mieszaniu się poufnych danych użytkowników w ramach różnych protokołów.
• Zalecamy wdrożenie na urządzeniu procesu resetowania, który umożliwi użytkownikowi ponowne skonfigurowanie urządzenia w innej sieci.
• Proces aktualizacji urządzenia do sieci powinien być przyjazny dla użytkownika i sprawiedliwy dla wszystkich sieci. Użytkownik musi mieć możliwość wyboru sieci, z której chce korzystać, bez preferowania żadnej z nich. Ten proces musi zostać zatwierdzony przez zespół Google.

Aktualizacje oprogramowania

Proces i dystrybucja aktualizacji OTA powinny być zarządzane przez partnera za pomocą jego własnego procesu aplikacji mobilnej lub internetowej.

Szybkie parowanie obsługuje dostarczanie powiadomień do użytkownika, informując o dostępnych aktualizacjach OTA. Aby korzystać z tego mechanizmu:

• Najnowsza wersja oprogramowania powinna zostać zaktualizowana w konsoli urządzeń w pobliżu.
• W konsoli urządzeń w pobliżu należy skonfigurować aplikację towarzyszącą. Powinna obsługiwać intencję aktualizacji oprogramowania.
• Dostawca powinien zaimplementować charakterystykę GATT Wersja oprogramowania układowego.

Aby zapobiec śledzeniu, należy ograniczyć dostęp do charakterystyki Wersja oprogramowania. Najpierw odczyta stan udostępniania i poda klucz uwierzytelniania zgodnie z tą specyfikacją, a dopiero potem odczyta wersję oprogramowania. Będzie to odbywać się w ramach tego samego połączenia. Jeśli podjęta zostanie próba odczytania wersji oprogramowania sprzętowego, a dostawca nie jest powiązany ani nie przeprowadzono z nim uwierzytelnionej operacji w ramach tego samego połączenia, powinien on zwrócić błąd nieuwierzytelnienia.

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 w ramach wcześniejszego dostępu.
v1.1	luty 2023 r.	Dodaliśmy wskazanie w postaci zwykłego tekstu trybu ochrony przed niepożądanym śledzeniem. Dodaliśmy opcję pomijania uwierzytelniania żądań dzwonienia w trybie ochrony przed niechcianym śledzeniem.
1.2	kwiecień 2023 r.	Zaktualizowano definicję klucza dostępu właściciela. Dodano rekomendację dotyczącą przywracania lokalizatora po utracie zasilania w tagach. Dodaliśmy wyjaśnienie dotyczące randomizacji adresu MAC. Dodaliśmy wyjaśnienie dotyczące rotacji adresu MAC w trybie ochrony przed niechcianym śledzeniem. Dodaliśmy wytyczne dotyczące możliwości dezaktywacji lokalizatora.
v1.3	Grudzień 2023 r.	Dodaliśmy wyjaśnienie dotyczące informacji identyfikacyjnych ujawnianych przez tagi lokalizatora. Dodaliśmy wymaganie dotyczące wdrożenia specyfikacji zapobiegania niechcianemu śledzeniu. Dodaliśmy wytyczne dotyczące urządzeń z protokołem przełączanym.