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 Szybkiego parowania. Dostawcy powinni włączyć to rozszerzenie, jeśli mają urządzenia zgodne z FHN i chcą włączyć śledzenie lokalizacji tych urządzeń.

Uwaga: jeśli chcesz zintegrować lokalizator lub urządzenie inne niż słuchawki z akcesorium sieci Centrum lokalizacji, wypełnij formularz propozycji urządzenia do Centrum lokalizacji. Jeśli chcesz dodać obsługę Centrum lokalizacji do słuchawek nausznych lub TWS, wypełnij formularz propozycji urządzenia z funkcją Szybkie parowanie.

Specyfikacja GATT

Do usługi szybkiego parowania należy dodać dodatkową charakterystykę ogólnych atrybutów (GATT) 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 szybkiego parowania dla FHN.

Uwierzytelnianie

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

Oktet	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 wtedy, gdy operacja się nie powiodła.

Następnie Seeker oblicza 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 wyszukująca 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ń sygnalizatora 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 udostępniania FHN. Ten klucz służy do tworzenia 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 identyfikatora EIK, pod warunkiem że użytkownik wyrazi zgodę, naciskając przycisk na urządzeniu.

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

• Klucz ochrony przed niechcianym śledzeniem: zdefiniowany jako SHA256(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.

Oktet	Typ danych	Opis	Wartość
0	uint8	Identyfikator danych	0x00: Odczyt parametrów beacona 0x01: Odczyt stanu udostępniania 0x02: Ustawianie klucza tożsamości tymczasowej 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ą efemerycznym 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 elementu SHA256(ephemeral identity key || the last nonce read from the characteristic)

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

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	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 obsługi sygnału.

Oktet	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.

Oktet	Typ danych	Opis	Wartość
0	uint8	Identyfikator danych	0x07: Aktywuj 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.

Oktet	Typ danych	Opis	Wartość
0	uint8	Identyfikator danych	0x00: Odczyt parametrów beacona 0x01: Odczyt stanu udostępniania 0x02: Ustawianie klucza tożsamości tymczasowej 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: Aktywuj 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 (dopeł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 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 użycia starej liczby jednorazowej).
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 wysłać do urządzenia udostępniającego zapytanie o parametry sygnału, wykonując operację zapisu w przypadku charakterystyki składającej się z żądania z tabeli 2 z identyfikatorem danych 0x00. Dostawca sprawdza, czy podany jednorazowy klucz uwierzytelniania jest zgodny z dowolnym kluczem konta przechowywanym 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:

Oktet	Typ danych	Opis	Wartość
0	uint8	Skalibrowana moc	Skalibrowana moc odebrana w odległości 0 m (wartość z zakresu [-100, 20]). Wartość jest podawana jako liczba całkowita ze znakiem, z dokładnością do 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: wskazuje, ż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 w przypadku 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 udostępniania beacona

Urządzenie wyszukujące może wysłać do urządzenia udostępniającego 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 zwróci 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:

Oktet	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 sprawdza, czy:

• Podany jednorazowy klucz uwierzytelniający pasuje do klucza konta właściciela.
• Jeśli podano skrót tymczasowego klucza tożsamości, skrócony tymczasowy klucz tożsamości pasuje do bieżącego tymczasowego klucza tożsamości.
• Jeśli nie podano skrótu tymczasowego klucza tożsamości, sprawdź, czy dostawca nie został już skonfigurowany jako beacon FHN.

Jeśli weryfikacja się nie powiedzie, dostawca zwróci 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 dopasowanego 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 działać 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 sprawdza, czy:

• Podany jednorazowy klucz uwierzytelniający pasuje do klucza 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 lokalizują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, wyszukiwarka musi przechowywać klucz odzyskiwania na serwerze backendu, 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 zwróci 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:

Oktet	Typ danych	Opis	Wartość
0	uint8	Działanie dzwonka	Maska bitowa o tych wartościach: Bit 1 (0x01): uruchom dzwonek w prawej słuchawce. Bit 2 (0x02): uruchom 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 wyłączy dźwięk. Limit czasu zastępuje ten, który jest już aktywny, jeśli którykolwiek komponent urządzenia już dzwoni. Jeśli operacja dzwonka ma wartość 0x00, czas oczekiwania 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 sprawdza, czy:

• Podany jednorazowy klucz uwierzytelniający jest zgodny z kluczem dzwonka.
• Żądany stan pasuje do komponentów, 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 aktywną 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 mogą mieć dowolną wartość.

Gdy dzwonek zacznie dzwonić lub przestanie, 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: 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 dostawca ma przycisk fizyczny (lub włączoną funkcję dotykową), powinien on zatrzymywać dzwonienie, gdy zostanie naciśnięty podczas aktywnego dzwonienia.

Uwaga: w przypadku dostawców, którzy uwzględniają wykrywanie założenia słuchawek na głowę, przed włączeniem dzwonka z maksymalną głośnością sprawdź, czy urządzenie nie jest założone na głowę. Jeśli wykrywanie założenia słuchawek na głowę nie jest obsługiwane lub nie działa niezawodnie, stopniowo zwiększaj głośność (aby użytkownik miał czas na zatrzymanie dzwonka lub zdjęcie słuchawek).

Uwaga: dostawca powinien kontynuować dzwonienie niezależnie od stanu połączenia osoby, która poprosiła o dzwonienie. Zapobiega to sytuacji, w której urządzenie przestaje dzwonić, ponieważ połączenie zostało utracone z powodu oddalenia się klienta od urządzenia. Wtedy nie można znaleźć urządzenia, ponieważ przestało dzwonić i jest zbyt daleko od klienta, aby ponownie poprosić o dzwonienie.

Pobieranie stanu dzwonienia lokalizatora

Aby uzyskać stan dzwonienia beacona, urządzenie wyszukujące wykonuje operację zapisu w charakterystyce, która polega na wysłaniu żą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:

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, 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 umożliwiać każdemu klientowi identyfikowanie urządzeń, które są 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 przed możliwym niechcianym śledzeniem.

Aby włączyć lub wyłączyć tryb ochrony przed niechcianym śledzeniem sygnału nawigacyjnego, 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:

Oktet	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 ustawiono żadnej flagi (bajt składa się z samych zer), można całkowicie pominąć sekcję danych i wysłać pustą sekcję danych. Flagi działają tylko do momentu dezaktywacji trybu ochrony przed niechcianym śledzeniem.

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

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

Podczas wyłączania trybu ochrony przed niechcianym śledzeniem

Dostawca sprawdza, czy:

• 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 zwróci 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 zahaszowane 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).

Precyzyjne znajdowanie

W tej sekcji opisujemy przepływ i dodatkowe operacje potrzebne do precyzyjnego wyszukiwania. Obowiązują tu te same zasady dotyczące charakterystyki GATT i uwierzytelniania, które zostały określone w sekcji specyfikacji GATT. Precyzyjne znajdowanie jest opcjonalne.

Rodzaj dokładnego wyszukiwania zależy od typu technologii pomiaru odległości obsługiwanych na urządzeniach biorących udział w dokładnym wyszukiwaniu. Obsługiwane technologie pomiaru odległości znajdziesz w specyfikacji Pomiar odległości: sekwencja wiadomości poza pasmem i ładunek. W dalszych sekcjach dowiesz się, jakiej dokładności można się spodziewać w zależności od użytej technologii pomiaru odległości.

Proces precyzyjnego znajdowania

W tej sekcji opisujemy przepływ wiadomości FHNA w przypadku precyzyjnego znajdowania. Rysunek 1 przedstawia przepływ wiadomości, a w akapitach znajdziesz szczegółowe wyjaśnienia dotyczące każdej z nich.

Ilustracja 1. Typowy przepływ wiadomości w przypadku precyzyjnego znajdowania

Urządzenie inicjujące to urządzenie, na którym jest zainstalowana aplikacja Centrum lokalizacji i na którym włączono funkcję precyzyjnego znajdowania. Inicjator to urządzenie, które próbuje znaleźć inne urządzenie.

Urządzenie odpowiadające to urządzenie, które próbuje znaleźć urządzenie inicjujące.

Urządzenie inicjujące wysyła do urządzenia odpowiadającego wiadomość z żądaniem informacji o możliwościach pomiaru odległości. W wiadomości tej wymienia technologie pomiaru odległości, o których chce się dowiedzieć od urządzenia odpowiadającego. Urządzenie odpowiadające wyśle powiadomienie Ranging Capability Response (Odpowiedź dotycząca możliwości pomiaru odległości), które zawiera informacje o obsługiwanych technologiach pomiaru odległości i ich możliwościach. Odpowiadający uwzględni tylko informacje, o które poprosił inicjator. Lista funkcji będzie posortowana według priorytetu technologii pomiaru odległości preferowanej przez urządzenie odpowiadające. Najwyższy priorytet będzie mieć pierwsza pozycja na liście.

Urządzenie inicjujące wyśle następnie wiadomość Ranging Configuration (Konfiguracja pomiaru odległości), w której określi konfigurację każdej technologii pomiaru odległości, z której chce korzystać. Po otrzymaniu tej wiadomości urządzenie odpowiadające musi rozpocząć pomiar odległości w przypadku odpowiednich technologii przy użyciu podanych konfiguracji. Urządzenie odpowiadające wyśle powiadomienie z odpowiedzią na konfigurację pomiaru odległości, które zawiera wyniki informujące, czy poszczególne technologie pomiaru odległości zostały uruchomione. Niektóre technologie pomiaru odległości muszą być uruchamiane zarówno na urządzeniu inicjującym, jak i odpowiadającym, aby sesja pomiaru odległości zakończyła się powodzeniem. W przypadku innych technologii wystarczy, że zostaną uruchomione na urządzeniu inicjującym, ale urządzenie odpowiadające musi zwrócić wynik pozytywny. Więcej informacji o konkretnych technologiach pomiaru odległości znajdziesz w dalszych sekcjach.

Gdy urządzenie inicjujące będzie gotowe do zakończenia sesji precyzyjnego wyszukiwania, wyśle do urządzenia odpowiadającego komunikat Stop Ranging (Zatrzymaj pomiar odległości), wskazując, które technologie pomiaru odległości mają przestać mierzyć odległość. Urządzenie odpowiadające wyśle powiadomienie Stop Ranging Response, które będzie oznaczać, że udało mu się zatrzymać pomiar odległości przy użyciu żądanych technologii pomiaru odległości.

Jeśli kanał komunikacji FHNA BLE GATT zostanie odłączony w trakcie sesji precyzyjnego wyszukiwania, ale niektóre technologie pomiaru odległości nadal będą działać, urządzenie odpowiadające zastosuje mechanizm limitu czasu, aby nie mierzyć odległości w nieskończoność. Szczegóły zależą od konkretnego przypadku użycia.

Pamiętaj, że urządzenie odpowiadające nie może zakładać, że kolejność operacji będzie zawsze taka sama. Na przykład urządzenie odpowiadające musi być w stanie obsłużyć kilka kolejnych operacji żądania możliwości pomiaru odległości lub nawet bezpośrednią operację konfiguracji pomiaru odległości bez poprzedzającego żądania możliwości.

Operacje precyzyjnego znajdowania

Tabela 8 zawiera operacje FHNA zdefiniowane w tym dokumencie, które są wymagane w przypadku precyzyjnego wyszukiwania. W każdej podsekcji zdefiniowano wiadomość FHNA dla poszczególnych operacji, a zawartość pola Dodatkowe dane odnosi się do specyfikacji Określanie odległości: sekwencja wiadomości poza pasmem i ładunek.

Operacja	Identyfikator danych	Opis
Prośba o możliwość pomiaru odległości	0x0A	Operacja żądania możliwości, która zostanie wysłana przez urządzenie inicjujące do urządzenia odpowiadającego. Dane tej operacji będą zawierać listę wszystkich technologii pomiaru odległości, o których inicjator chce uzyskać informacje z urządzenia odpowiadającego.
Odpowiedź dotycząca możliwości pomiaru odległości	0x0A	Jest to odpowiedź na powiadomienie dotyczące operacji Ranging Capability Request. Zawiera informacje o funkcjach każdej obsługiwanej technologii pomiaru odległości, o które poprosił inicjator.
Konfiguracja pomiaru odległości	0x0B	Operacja konfiguracji pomiaru odległości zawiera konfiguracje technologii pomiaru odległości, za pomocą których urządzenie inicjujące chce rozpocząć pomiar odległości od urządzenia odpowiadającego.
Odpowiedź na konfigurację pomiaru odległości	0x0B	Jest to odpowiedź na powiadomienie dotyczące operacji konfiguracji pomiaru odległości. Zawiera dane o tym, czy urządzenie odpowiadające rozpoczęło pomiar odległości przy użyciu żądanych technologii pomiaru odległości na podstawie podanej konfiguracji.
RFU	0x0C	Operacja z tym identyfikatorem danych nie jest używana i jest zarezerwowana do wykorzystania w przyszłości.
Zatrzymaj pomiar odległości	0x0D	Operacja Stop Ranging wysłana przez urządzenie inicjujące zawiera informacje o technologiach pomiaru odległości, w przypadku których urządzenie odpowiadające musi przerwać pomiar.
Stop Ranging Response	0x0D	Jest to odpowiedź na powiadomienie dotyczące operacji Stop Ranging. Zawiera informacje o tym, czy operacja zatrzymania w przypadku konkretnej technologii pomiaru odległości zakończyła się powodzeniem.

Tabela 8. Operacje precyzyjnego znajdowania.

Operacja Ranging Capability Request

W tabeli 9 zdefiniowano komunikat Ranging Capability Request.

Oktet	Typ danych	Opis	Wartość
0	uint8	Identyfikator danych	0x0A – operacja żądania możliwości określania odległości
1	uint8	Długość danych	różni się
2	tablica bajtów	Jednorazowy klucz uwierzytelniający	Pierwsze 8 bajtów funkcji HMAC-SHA256(klucz konta, numer głównej wersji protokołu || ostatni odczytany z charakterystyki nonce || identyfikator danych || długość danych || dane dodatkowe).
10	tablica bajtów	Dane dodatkowe	Komunikat Ranging Capability Request zdefiniowany w specyfikacji Ranging: Out-of-band message sequence and payload (zarówno nagłówek, jak i ładunek).

Tabela 9. Żądanie możliwości określania odległości.

Operacja odpowiedzi dotycząca możliwości pomiaru odległości

W tabeli 10 zdefiniowano komunikat Ranging Capability Response.

Oktet	Typ danych	Opis	Wartość
0	uint8	Identyfikator danych	0x0A: Odpowiedź dotycząca możliwości pomiaru odległości
1	uint8	Długość danych	różni się
2	tablica bajtów	Jednorazowy klucz uwierzytelniający	Pierwsze 8 bajtów funkcji HMAC-SHA256(klucz konta, numer głównej wersji protokołu || ostatni odczytany z charakterystyki nonce || identyfikator danych || długość danych || dane dodatkowe || 0x01).
10	tablica bajtów	Dane dodatkowe	Komunikat Ranging Capability Response zdefiniowany w specyfikacji Ranging: Out-of-band message sequence and payload (zarówno nagłówek, jak i ładunek).

Tabela 10. Odpowiedź dotycząca możliwości pomiaru odległości.

Operacja konfiguracji pomiaru odległości

Tabela 11 zawiera definicję wiadomości Ranging Configuration.

Oktet	Typ danych	Opis	Wartość
0	uint8	Identyfikator danych	0x0B – Set Ranging Configuration
1	uint8	Długość danych	różni się
2	tablica bajtów	Jednorazowy klucz uwierzytelniający	Pierwsze 8 bajtów funkcji HMAC-SHA256(klucz konta, numer głównej wersji protokołu || ostatni odczytany z charakterystyki nonce || identyfikator danych || długość danych || dane dodatkowe).
10	tablica bajtów	Dane dodatkowe	Komunikat Ranging Configuration zdefiniowany w specyfikacji Ranging: Out-of-band message sequence and payload (zarówno nagłówek, jak i ładunek).

Tabela 11. Konfiguracja pomiaru odległości.

Operacja Ranging Configuration Response

Tabela 12 zawiera definicję komunikatu Ranging Configuration Response.

Oktet	Typ danych	Opis	Wartość
0	uint8	Identyfikator danych	0x0B – Set Ranging Configuration Response
1	uint8	Długość danych	różni się
2	tablica bajtów	Jednorazowy klucz uwierzytelniający	Pierwsze 8 bajtów funkcji HMAC-SHA256(klucz konta, numer głównej wersji protokołu || ostatni odczytany z charakterystyki nonce || identyfikator danych || długość danych || dane dodatkowe || 0x01).
10	tablica bajtów	Dane dodatkowe	Komunikat Ranging Configuration Response zdefiniowany w specyfikacji Ranging: Out-of-band message sequence and payload (zarówno nagłówek, jak i ładunek).

Tabela 12. Odpowiedź na konfigurację pomiaru odległości.

Zatrzymywanie operacji pomiaru odległości

Tabela 13 zawiera definicję komunikatu Stop Ranging.

Oktet	Typ danych	Opis	Wartość
0	uint8	Identyfikator danych	0x0D – Ranging Stop
1	uint8	Długość danych	różni się
2	tablica bajtów	Jednorazowy klucz uwierzytelniający	Pierwsze 8 bajtów funkcji HMAC-SHA256(klucz konta, numer głównej wersji protokołu || ostatni odczytany z charakterystyki nonce || identyfikator danych || długość danych).
10	tablica bajtów	Dane dodatkowe	Komunikat Stop Ranging zdefiniowany w specyfikacji Ranging: Out-of-band message sequence and payload (zarówno nagłówek, jak i ładunek).

Tabela 13. Zatrzymanie pomiaru odległości.

Zatrzymywanie operacji Stop Ranging Response

Tabela 14 zawiera definicję wiadomości Stop Ranging Response.

Oktet	Typ danych	Opis	Wartość
0	uint8	Identyfikator danych	0x0D – Ranging Stop Response
1	uint8	Długość danych	różni się
2	tablica bajtów	Jednorazowy klucz uwierzytelniający	Pierwsze 8 bajtów funkcji HMAC-SHA256(klucz konta, numer głównej wersji protokołu || ostatni odczytany z charakterystyki nonce || identyfikator danych || długość danych || dane dodatkowe || 0x01).
10	tablica bajtów	Dane dodatkowe	Komunikat Stop Ranging Response zdefiniowany w specyfikacji Ranging: Out-of-band message sequence and payload (zarówno nagłówek, jak i ładunek).

Tabela 14. Odpowiedź na żądanie zatrzymania pomiaru odległości.

Ochrona przed niechcianym śledzeniem z funkcją precyzyjnego znajdowania

Gdy włączony jest tryb ochrony przed niechcianym śledzeniem, opisany w sekcji dotyczącej ochrony przed niechcianym śledzeniem, ten sam proces, który dotyczy pomijania sprawdzania uwierzytelniania w przypadku dzwoniących wiadomości, ma zastosowanie do wszystkich wiadomości dotyczących precyzyjnego lokalizowania zdefiniowanych w tym dokumencie dla urządzeń, które chcą obsługiwać tę funkcję.

Szczegóły technologii pomiaru odległości w przypadku precyzyjnego znajdowania

Ta sekcja zawiera szczegóły dotyczące technologii pomiaru odległości.

Szczegóły dotyczące łącza ultraszerokopasmowego (UWB)

Szczegóły dotyczące technologii UWB.

Poziom precyzyjnego znajdowania

Podczas sesji precyzyjnego znajdowania z użyciem technologii UWB do określania odległości można oczekiwać informacji zarówno o odległości, jak i o kierunku. Interwał pomiaru odległości musi wynosić co najmniej 240 ms, a w celu uzyskania optymalnych wskazówek zalecana jest wartość 96 ms.

Identyfikatory konfiguracji

Dane konfiguracyjne wymieniane poza pasmem dla UWB nie zawierają pełnego zestawu dostępnych parametrów konfiguracyjnych, których UWB wymaga do rozpoczęcia sesji pomiaru odległości UWB. Niektóre parametry są wybierane niejawnie przez wybrany identyfikator konfiguracji.

Każdy identyfikator konfiguracji to zestaw wstępnie zdefiniowanych parametrów konfiguracji UWB, które są publicznie udostępniane w dokumentacji. W przypadku precyzyjnego znajdowania urządzenie odpowiadające musi obsługiwać identyfikator konfiguracji 6 i opcjonalnie identyfikator konfiguracji 3.

Inicjator i odbiornik UWB

W przypadku precyzyjnego znajdowania urządzenie oznaczone w tym dokumencie jako urządzenie inicjujące będzie urządzeniem odpowiadającym UWB, a urządzenie oznaczone w tym dokumencie jako urządzenie odpowiadające będzie urządzeniem inicjującym UWB. Dzieje się tak, ponieważ urządzenie inicjujące UWB zużywa mniej energii niż urządzenie odpowiadające UWB, a w większości przypadków urządzenie odpowiadające będzie urządzeniem peryferyjnym z ograniczoną baterią.

Oznacza to, że urządzenie odpowiadające musi wskazać, że obsługuje rolę inicjatora UWB w wiadomości Ranging Capability Response.

Inne parametry związane z UWB

• Musi być obsługiwany kanał 9
• Aby uzyskać optymalne wskazówki, zalecany jest interwał pomiaru odległości wynoszący 96 ms. W przeciwnym razie musi być obsługiwany interwał 240 ms.
• Aby oszczędzać baterię, zalecany jest czas trwania przedziału wynoszący 1 ms, ale obsługiwany jest też czas 2 ms.
• Chip UWB musi być zgodny co najmniej ze standardem FIRA w wersji 1.2 i P-STS.
• Wymagany jest BPRF, a HPRF jest zalecany, ale opcjonalny. Obsługiwany lub wybrany tryb jest określany przez obsługiwany lub wybrany indeks preambuły.
• Typ zabezpieczeń sesji: P-STS

Szczegóły dotyczące sondowania kanału BLE (CS)

Szczegóły dotyczące BLE CS.

Poziom precyzyjnego znajdowania

Sesje precyzyjnego znajdowania, w których CS jest używany jako technologia pomiaru odległości, będą powodować pomiary tylko odległości. Kierunek nie jest obecnie podawany.

Wymagane połączenie między urządzeniami

Sesje dokładnego wyszukiwania z użyciem sondowania kanału nie będą działać, jeśli urządzenia nie są sparowane. Wymagane jest istniejące połączenie między urządzeniem inicjującym a urządzeniem odpowiadającym. Ta specyfikacja nie umożliwia tworzenia powiązań między urządzeniami. Zamiast tego to deweloper zakresu zastosowań musi nawiązać to połączenie między urządzeniami.

Działanie wymagane po stronie odpowiadającego w przypadku obsługi klienta

W przeciwieństwie do UWB, gdzie oba urządzenia muszą wywoływać interfejs API rozpoczęcia i zakończenia pomiaru odległości UWB, w przypadku CS tylko urządzenie inicjujące musi rozpocząć pomiar odległości CS, wywołując stos Bluetooth. Reszta inicjowania po stronie urządzenia odpowiadającego odbywa się w paśmie przy użyciu Bluetootha (BT). Oznacza to, że po otrzymaniu wiadomości Ranging Configuration lub Stop Ranging dla CS strona odpowiadająca nie musi nic robić, jeśli Bluetooth jest włączony, poza wysłaniem powiadomienia z odpowiedzią na wiadomość Ranging Configuration. Urządzenie odpowiadające może używać tych wiadomości jako wyzwalacza do aktualizowania interfejsu, jeśli ma ekran. Może też używać ich do wizualnego informowania o stanie urządzenia, np. migania diod LED, niezależnie od tego, czy ma ekran.

Wi-Fi NAN RTT

Szczegółowe informacje o RTT w Wi-Fi NAN.

Poziom precyzyjnego znajdowania

Sesje precyzyjnego znajdowania, w których jako technologia pomiaru odległości używana jest funkcja Wi-Fi NAN RTT, będą powodować pomiary tylko odległości. W tej chwili nie jest podawany kierunek.

RSSI BLE

Szczegółowe informacje o RSSI BLE.

Poziom precyzyjnego znajdowania

Sesje precyzyjnego znajdowania, w których jako technologia pomiaru odległości używany jest tylko wskaźnik RSSI BLE, nie będą w stanie uzyskać informacji o odległości ani kierunku, ponieważ wskaźnik RSSI BLE nie jest dokładną technologią pomiaru odległości. Zamiast tego użytkownik zobaczy wskazówki informujące, że urządzenie jest blisko lub daleko.

Rozgłaszane ramki

Po zakończeniu obsługi administracyjnej 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.

Uwaga: zalecamy reklamowanie ramek FHN nawet wtedy, gdy urządzenie jest w trybie niskiego zużycia energii, ponieważ umożliwia to znalezienie urządzenia w przypadku jego utraty. W przypadku niektórych urządzeń reklamowanie, gdy są one wyłączone, może być niemożliwe ze względu na wpływ na żywotność baterii. W takich przypadkach zdecydowanie zalecamy okresowe wybudzanie urządzenia i wyświetlanie reklam przez krótki czas (np. wybudzanie co 10 minut i wyświetlanie reklam przez 10 sekund).

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.

Uwaga: używanie 256-bitowych kluczy oznacza, że starsze telefony, które nie obsługują BLE 5, nie mogą skanować urządzeń reklamowych ani przesyłać o nich informacji, co zmniejsza rozmiar sieci.

Ramka FHN ma taką strukturę:

Oktet	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 15. Ramka FHN obsługująca 160-bitową krzywą.

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

Oktet	Wartość	Opis
0	0x02	Długość
1	0x01	Wartość typu danych flag
2	0x06	Dane dotyczące 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 16. Ramka FHN obsługująca 256-bitową krzywą.

Obliczanie identyfikatora tymczasowego (EID)

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

Oktet	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 17. Konstrukcja liczby pseudolosowej.

Uwaga: zakłada się, że urządzenie ma 32-bitowy licznik czasu w sekundach.

Uwaga: wykładnik okresu rotacji jest stały i wynosi 10, co odpowiada 1024 sekundom.

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

W pozostałej części obliczeń do operacji kryptograficznych na krzywych eliptycznych używane są wartości SECP160R1 lub SECP256R1. Definicje krzywych znajdziesz w sekcji SEC 2: Recommended Elliptic Curve Domain Parameters, w której zdefiniowano parametry Fp, n i G wspomniane dalej.

Wartość r' jest teraz rzutowana na pole 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 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 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

Uwaga: poniższe szczegóły dotyczące szyfrowania i odszyfrowywania za pomocą identyfikatorów EID są podane wyłącznie w celu uzupełnienia specyfikacji. Wdraża je tylko osoba poszukująca, a nie dostawca.

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

1. Wybierz losową liczbę s z zakresu Fp, zgodnie z definicją w sekcji Obliczanie identyfikatora EID.
2. ObliczeniaS = 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 krzywej. Nie określono ciągu zaburzającego.
5. Niech URx i LRx będą odpowiednio górnymi i dolnymi 80 bitami wartości Rx w formacie big-endian. W podobny sposób zdefiniuj USx i LSx dla S.
6. Obliczenianonce = LRx || LSx
7. Obliczenia(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 niedawnej przeszłości i bliskiej przyszłości.
2. Na podstawie wartości licznika czasu sygnału, na której opiera się wartość URx, oblicz przewidywaną wartość r zgodnie z opisem w sekcji Obliczanie identyfikatora EID.
3. Oblicz R = r * G i sprawdź, czy jest zgodna z wartością URx podaną przez osobę, która zauważyła problem.
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 krzywej.
6. Obliczenianonce = LRx || LSx
7. Obliczeniam = 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 rozpoznać (RPA) lub którego nie można rozpoznać (NRPA). 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 rozgłaszać 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 dodatkowy 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 niewidocznym (np. szybkiego parowania) musi się zmieniać. Dopuszczalne jest używanie różnych adresów dla różnych protokołów.

Przywracanie po utracie zasilania

Rozwiązywanie identyfikatora tymczasowego 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 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 dokonać inicjalizacji. Rozwiązania identyfikatora tymczasowego będą realizować rozpoznawanie w oknie czasowym 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 minimalizować 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 upłynie 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 kont.
• 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. 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ń korzystających z klasycznego Bluetootha

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

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

Dostawca nie zawsze jest obsługiwany przez FHN podczas parowania z Odbiorcą, 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 przez urządzenie wyszukujące adresu BLE, 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 wyszukiwarką 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ń komunikatów 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 utworzony strumień 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 udostępnienie. W przeciwnym razie 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), aby zgłosić 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 układowego.

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

Tabela 18. Zdarzenie informacji o urządzeniu: zaktualizowana wersja oprogramowania układowego.

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

Oktet	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 19. 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 dostawca jest skonfigurowany pod kątem FHN, aby zsynchronizować urządzenie wyszukujące w przypadku odchylenia zegara (np. z powodu wyczerpania baterii). W przeciwnym razie Seeker zainicjuje w tym celu droższe i mniej niezawodne połączenie.

Oktet	Typ danych	Opis	Wartość
0	uint8	Zdarzenie dotyczące informacji o urządzeniu	0x03
1	uint8	Bieżący identyfikator 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 20. Zdarzenie dotyczące informacji o urządzeniu: synchronizacja zegara.

Przywróć do ustawień fabrycznych

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 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.

Ochrona przed niechcianym śledzeniem

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

Wskazówki dotyczące FHN, które pomogą zachować 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ę „Centrum lokalizacji”.
• 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, zdefiniowanym w specyfikacji DULT, nie ma zmian w reklamowanej ramce zdefiniowanej w tym dokumencie.
• „Tryb ochrony przed niechcianym śledzeniem” zdefiniowany w tym dokumencie odpowiada „stanowi odseparowanemu” 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 dotyczące aktywowania 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 lokalizacyjne muszą zawierać mechanizm, który umożliwia użytkownikom tymczasowe zatrzymanie rozgłaszania 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 wymagane, aby zapobiec mieszaniu się poufnych danych użytkowników w ramach różnych protokołów.
• Zalecamy wdrożenie w 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.

Aby zapobiec śledzeniu, należy ograniczyć dostęp do charakterystyki Wersja oprogramowania. Urządzenie wysyłające 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.	Dodano 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. Dodaliśmy rekomendację dotyczącą przywracania lokalizatora po utracie zasilania. 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 umożliwiających identyfikację ujawnianych przez tagi lokalizatora. Dodaliśmy wymaganie dotyczące wdrożenia specyfikacji zapobiegania niechcianemu śledzeniu. Dodaliśmy wskazówki dotyczące urządzeń z protokołem przełączanym.