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ę 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 typu 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 jeśli operacja się nie powiodła.
Następnie wyszukujący 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 wysyłająca żądanie musi udowodnić, że zna co najmniej 1 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 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. Możesz wybrać pierwszy klucz konta użyty do odczytania stanu udostępniania z charakterystyki działań beaconu po aktualizacji oprogramowania sprzętowego, zakładając, ż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 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ś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 jako
SHA256(ephemeral identity key || 0x03), skrócony do pierwszych 8 bajtów. Klucz jest przechowywany na serwerze backendu, a wyszukiwarka 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 |
|
| 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 |
|
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 beaconów.
| Oktet | Typ danych | Opis | Wartość |
|---|---|---|---|
| 0 | uint8 | Identyfikator danych |
|
| 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 |
|
Tabela 4. Prośba o dzwonienie.
| Oktet | Typ danych | Opis | Wartość |
|---|---|---|---|
| 0 | uint8 | Identyfikator danych |
|
| 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 |
|
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 |
|
| 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 |
|
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 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: Odczytaj klucz tożsamości efemerycznej 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 uwierzytelniający 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:
| 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:
|
| 6 | uint8 | Komponenty | Liczba komponentów, które mogą dzwonić:
|
| 7 | uint8 | Funkcje dzwonienia | Obsługiwane opcje:
|
| 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 obsługi administracyjnej beacona
Urządzenie wyszukujące może wysłać do urządzenia udostępniającego zapytanie o stan udostępniania beacona, 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:
| Oktet | Typ danych | Opis | Wartość |
|---|---|---|---|
| 0 | uint8 | Stan udostępniania | Maska bitowa o tych wartościach:
|
| 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 tymczasowego klucza tożsamości, 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 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 dotyczącą sygnalizatora, 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 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, usługa Seeker 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 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:
| Oktet | Typ danych | Opis | Wartość |
|---|---|---|---|
| 0 | uint8 | Działanie dzwonka | Maska bitowa o tych wartościach:
|
| 1–2 | uint16 | Czas oczekiwania | Czas oczekiwania w decysekundach. Nie może być zerem ani wartością większą 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ść |
|
Po otrzymaniu prośby dostawca sprawdza, czy:
- Podany jednorazowy klucz uwierzytelniający jest zgodny z kluczem dzwonka.
- Żą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 zaczyna dzwonić lub przestaje, 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 |
|
| 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łączone wykrywanie dotyku), powinien on zatrzymać dzwonienie, jeśli zostanie naciśnięty podczas aktywnego dzwonienia.
Pobieranie stanu dzwonienia lokalizatora
Aby uzyskać stan dzwonienia beacona, urządzenie wyszukują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 nieuwierzytelniony.
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 na celu umożliwienie każdemu klientowi identyfikowania 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ć niechciane żądanie aktywacji trybu ochrony przed ś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 wysyłające wykonuje operację zapisu do charakterystyki, która składa się z żą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 |
Flagi działają 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 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 identyfikator tymczasowy powinien nadal zmieniać się jak zwykle. Typ ramki powinien być ustawiony na 0x41. Stan jest też widoczny w sekcji zaszyfrowanych flag.
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 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 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).
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 wyszukiwanie jest opcjonalne.
Rodzaj precyzyjnego wyszukiwania zależy od typu technologii pomiaru odległości obsługiwanych przez urządzenia biorące w nim udział. 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 wyszukiwania. Rysunek 1 przedstawia przepływ wiadomości, a akapit wyjaśnia każdą z nich bardziej szczegółowo.

Rys. 1. Typowy przepływ wiadomości w przypadku precyzyjnego wyszukiwania
Urządzenie inicjujące to urządzenie, na którym jest zainstalowana aplikacja Centrum lokalizacji i na którym włączono funkcję precyzyjnego wyszukiwania. Urządzenie inicjujące to urządzenie, które próbuje znaleźć inne urządzenie.
Urządzenie odpowiadające to urządzenie, które jest wyszukiwane przez 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. Pierwsza pozycja na liście będzie miała najwyższy priorytet.
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 wiadomość Stop Ranging (Zatrzymaj pomiar odległości), wskazującą, które technologie pomiaru odległości mają przestać działać. 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.
Urządzenie odpowiadające nie może zakładać, że kolejność operacji będzie zawsze taka sama. Np. urządzenie odpowiadające musi być w stanie obsłużyć kilka kolejnych operacji żądania możliwości pomiaru odległości, a 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. Każda podsekcja definiuje wiadomość FHNA dla każdej z operacji, a zawartość pola Dodatkowe dane odnosi się do specyfikacji Ranging: 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. |
| Stop Ranging | 0x0D | Operacja Stop Ranging wysłana przez urządzenie inicjujące zawiera informacje o tym, z których technologii pomiaru odległości urządzenie odpowiadające musi zrezygnować. |
| 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 wyszukiwania precyzyjnego.
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 pomiaru odległości.
Operacja odpowiedzi na zapytanie o możliwości pomiaru odległości
W tabeli 10 zdefiniowano komunikat odpowiedzi dotyczący możliwości określania odległości.
| Oktet | Typ danych | Opis | Wartość |
|---|---|---|---|
| 0 | uint8 | Identyfikator danych | 0x0A: Ranging Capability 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 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 odpowiedzi na konfigurację pomiaru odległości.
| 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ą dokładnego 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 dokładnego znajdowania
Ta sekcja zawiera szczegóły dotyczące technologii pomiaru odległości.
Szczegóły dotyczące łącza ultraszerokopasmowego (UWB)
Szczegóły dotyczące UWB.
Poziom precyzyjnego znajdowania
Podczas sesji precyzyjnego znajdowania z użyciem technologii UWB do pomiaru 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 funkcji precyzyjnego wyszukiwania 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
- Kanał 9 musi być obsługiwany
- 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 z 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 do pomiaru odległości używana jest technologia CS, będą podawać tylko odległość. Kierunek nie jest obecnie podawany.
Wymagane połączenie między urządzeniami
Sesje precyzyjnego 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 ustanowić 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 wiadomości 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 jest on wyświetlany na ekranie. 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 czasie błądzenia (RTT) w przypadku 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. Kierunek nie jest obecnie podawany.
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ówkę, że urządzenie jest blisko lub daleko.
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. O tym, która krzywa jest używana, decyduje implementacja dostawcy.
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 | Zahaszowane 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 | Zahaszowane 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.
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 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 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 lokalizatora, musi wykonać te czynności:
- Wybierz losową liczbę
swFp, zgodnie z definicją w sekcji Obliczanie identyfikatora EID. - Obliczenia
S = s * G - Oblicz
R = (Rx, Ry), podstawiając wartości do równania krzywej i wybierając dowolną wartośćRyz możliwych wyników. - Oblicz 256-bitowy klucz AES
k = HKDF-SHA256((s * R)x), gdzie(s * R)xto współrzędnaxwyniku mnożenia krzywych. Nie określono ciągu zaburzającego. - Niech
URxiLRxbędą odpowiednio górnymi i dolnymi 80 bitami liczbyRxw formacie big-endian. W podobny sposób zdefiniujUSxiLSxdlaS. - Obliczenia
nonce = LRx || LSx - Obliczenia
(m’, tag) = AES-EAX-256-ENC(k, nonce, m) - 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:
- Na podstawie parametru
URxuzyskaj wartość licznika czasu sygnału, na którym opiera się parametrURx. Może to zrobić urządzenie klienta właściciela, obliczając wartościRxdla wartości licznika czasu sygnału w niedalekiej przeszłości i przyszłości. - Na podstawie wartości licznika czasu sygnału, na której opiera się wartość
URx, oblicz przewidywaną wartośćrzgodnie z opisem w sekcji Obliczanie identyfikatora EID. - Oblicz
R = r * Gi sprawdź, czy jest zgodny z wartościąURxpodaną przez osobę, która widziała zdarzenie. - Oblicz
S = (Sx, Sy), podstawiając wartości do równania krzywej i wybierając dowolną wartośćSyz możliwych wyników. - Oblicz
k = HKDF-SHA256((r * S)x), gdzie(r * S)xto współrzędnaxwyniku mnożenia krzywej. - Obliczenia
nonce = LRx || LSx - Obliczenia
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 niepodlegającej wykrywaniu (np. szybkiego parowania) musi się zmieniać. Możesz używać 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 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 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 minie 5 minut.
- Jeśli klucz tożsamości tymczasowej zostanie usunięty z urządzenia, powinno ono przywrócić ustawienia fabryczne i wyczyścić 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ń Bluetooth Classic
W tej sekcji opisujemy specjalne aspekty klasycznych urządzeń Bluetooth, które obsługują FHN.
Obsługa administracyjna FHN w przypadku sparowanych już urządzeń
Podczas parowania z osobą poszukującą pomocy dostawca nie zawsze jest od razu gotowy do udzielenia pierwszej pomocy, ale może to nastąpić 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 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 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.
Bieżący 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 wyszukiwarka 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óć 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.
Ochrona przed niechcianym śledzeniem
Certyfikowane urządzenia FHN muszą też spełniać wymagania w wersji implementacyjnej specyfikacji międzyplatformowej 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ę „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, zgodnie ze specyfikacją 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 aktywacji tego trybu dla konkretnego 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
eużyj tej samej odpowiedzi, która została utworzona dla funkcji Get_Identifier, zakodowanej w formacie szesnastkowym. - Jako parametr
pidużyj tej samej odpowiedzi, która została utworzona dla funkcji Get_Product_Data, zakodowanej w formacie szesnastkowym.
- Jako adres URL użyj
- 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 oraz 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łu 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 do ustawień fabrycznych, 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.
- Aplikacja towarzysząca powinna być skonfigurowana w konsoli urządzeń w pobliżu. 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
| FHN Version | Data | Komentarz |
|---|---|---|
| v1 | Pierwsza wersja specyfikacji FHN w ramach wcześniejszego dostępu. | |
| v1.1 | luty 2023 r. |
|
| 1.2 | kwiecień 2023 r. |
|
| v1.3 | Grudzień 2023 r. |
|