Urządzenie Bluetooth Low Energy (BLE)
Implementacja usługi Szybkie parowanie Google (GFPS) na urządzeniach BLE jest zgodna ze specyfikacją Bluetooth Core w wersji 4.2 lub nowszej.
Ten dodatek do specyfikacji Szybkie parowanie umożliwi obsługę w GFGS (tylko Low Energy) (LE) i Low Energy Audio (LEA).
Poziomy zgodności
Poniżej objaśniono słowa kluczowe „musi”, „muszą”, „będzie”, „powinien”, „może” i „może” wymienione w specyfikacji:
| Termin | Opis |
|---|---|
| powinna | jest wymagany – służy do definiowania wymagań. |
| musi | służy do wyrażania: naturalnej konsekwencji wcześniej wspomnianego obowiązkowego wymagania LUB niepodważalnego stwierdzenia faktu (które jest zawsze prawdziwe niezależnie od okoliczności). |
| will | to prawda, że – używane tylko w przypadku stwierdzeń. |
| should | Zalecamy – użyte, gdy spośród kilku możliwości jedna jest szczególnie polecana, ale nie jest wymagana. |
| może | is permitted to – służy do zezwalania na opcje. |
| puszka | jest w stanie – służy do łączenia stwierdzeń w sposób przyczynowo-skutkowy. |
Cecha parowania na podstawie klucza
Wiadomość od poszukującego do dostawcy
Żądanie w postaci danych type 0x00 charakterystyki parowania na podstawie klucza używa bitu 4 do wskazania, czy urządzenie szukające obsługuje specyfikację urządzenia BLE, oraz bitu 5 do wskazania, czy urządzenie szukające obsługuje Bluetooth LE Audio.
| Octet | Typ danych | Opis | Wartość | Czy jest wymagane? |
|---|---|---|---|---|
| 0 | uint8 |
Typ wiadomości | 0x00 = prośba o sparowanie na podstawie klucza |
Obowiązkowe |
| 1 | uint8 |
Flagi
|
zmienia się | Obowiązkowe |
| 2–7 | uint48 |
Wykonaj 1 z tych czynności:
|
zmienia się | Obowiązkowe |
| 8–13 | uint48 |
Adres BR/EDR osoby poszukującej | zmienia się | Występuje tylko wtedy, gdy ustawiony jest bit flagi 1 lub 3. |
| n – 15 | Wartość losowa (sól) | zmienia się | Obowiązkowe |
Wiadomość od dostawcy do szukającego
Gdy bit 4 w żądaniu jest ustawiony, nowy komunikat odpowiedzi type 0x02 dla funkcji parowania na podstawie klucza może służyć do udostępniania dodatkowych opcji parowania poszukiwaczowi.
| Octet | Typ danych | Opis | Wartość |
|---|---|---|---|
| 0 | uint8 |
Typ wiadomości | 0x02 = rozszerzona odpowiedź parowania na podstawie klucza |
| 1 | uint8 |
Flagi
|
zmienia się |
| 2 | uint8 |
Liczba adresów dostawcy (w bieżącej wersji liczba wynosi 1 lub 2, ponieważ musimy zmienić tryb szyfrowania blokowego na AES-CTR, jeśli liczba >= 3) |
różni się |
| 3–8 lub 3–14 |
|
zmienia się | |
| 9–15 lub 15 | Losowa wartość (sól) | zmienia się |
Dostawca, który obsługuje specyfikację urządzenia BLE, powinien odczytać bit 4 i 5, aby poznać możliwości szukającego.
- Gdy bit 4 ma wartość 0, Dostawca zignoruje bit 5 i zareaguje w formacie
type 0x01. - Gdy bit 4 ma wartość 1,
- W przypadku dostawcy obsługującego tylko LE usługa powinna odpowiadać z wartością
type 0x02, aby wskazać preferencje dotyczące wiązania LE. - W przypadku dostawcy w trybie podwójnym może odpowiadać parametrem
type 0x02, aby wskazać preferencję BR/EDR lub wiązania LE.
- W przypadku dostawcy obsługującego tylko LE usługa powinna odpowiadać z wartością
- W przypadku dostawców w trybie podwójnym LE Audio (LEA) zapoznaj się z przykładem: parowanie z dostawcą w trybie podwójnym LEA.
Charakterystyka PSM (multiplekser usługi protokołu) strumienia wiadomości
Aby obsługiwać strumień wiadomości na urządzeniach BLE, Fast Pair utworzy i utrzyma kanał BLE L2CAP do wysyłania i odbierania wiadomości. Serwer Fast Pair L2CAP powinien stosować kontrolę przepływu na podstawie kredytu LE.
Ta cecha pozwala narzędziu Seeker odczytywać wartość PSM, a następnie nawiązać bezpieczne połączenie L2CAP za pomocą wartości PSM.
| Charakterystyka usługi Szybkie parowanie | Zaszyfrowane | Uprawnienia | UUID |
|---|---|---|---|
| PSM strumienia wiadomości | Tak | Odczyt | FE2C1239-8366-4814-8EB0-01DE32100BEA |
| Octet | Typ danych | Opis | Wartość |
|---|---|---|---|
| 0 | uint8 |
Stan
|
zmienia się |
| 1–2 | uint16 |
Wartość PSM musi mieścić się w zakresie od 0x80 do 0xFF. | zmienia się |
Uwaga: w przypadku TWS są 2 składniki: podstawowa i dodatkowa. W pewnych sytuacjach te komponenty mogą pełnić te same funkcje. Przy założeniu, że komponent A jest komponentem głównym, a komponentem B – składnikiem drugorzędnym, ponieważ z powodu rozładowywania się baterii składnika A komponent B musi pełnić rolę głównego komponentu. Ten scenariusz nazywa się role switch.
Po role switch, jeśli dostawca nie obsługuje strumienia komunikatów Szybkie parowanie, powinien zapobiegawczo rozłączać istniejące połączenie L2CAP. Następnie wyszukiwarka Szybkiego parowania może ponownie nawiązać połączenie z strumieniem wiadomości L2CAP z nowym komponentem głównym.
Dodatkowa cecha klucza dostępu
Ta cecha zapewnia ochronę przed MITM w dodatkowych komponentach.
Ochrona przed MITM w przypadku fałszywych członków CSIS
Szybkie parowanie wymaga ochrony MITM w ramach procedury parowania. Ponieważ CSIS nie zapewnia ochrony przed MITM, obecną konstrukcję FP dla wielu komponentów należy rozszerzyć, aby zapewnić ochronę przed MITM w dodatkowych komponentach.
Definicja cechy
| Charakterystyka usługi Szybkie parowanie | Zaszyfrowane | Uprawnienie | UUID |
|---|---|---|---|
| Dodatkowy klucz dostępu | Tak | Odczyt,zapis,powiadomienie | FE2C123A-8366-4814-8EB0-01DE32100BEA |
Wiadomości
Format wiadomości ma zastosowanie do operacji odczytu, zapisu i powiadamiania.
Format zaszyfrowanych danych
Zaszyfrowane dane są wysyłane za pomocą połączenia GATT Szybkiego parowania.
| Octet | Typ danych | Opis | Wartość |
|---|---|---|---|
| 0-15 | uint128 | Zaszyfrowany blok dodatkowych kluczy dostępu | różni się |
Format nieprzetworzonych danych
Po odszyfrowaniu zaszyfrowanych danych za pomocą wspólnego klucza tajnego format jest taki, jak poniżej.
| Octet | Typ danych | Opis | Wartość |
|---|---|---|---|
| 0 | uint8 | Typ wiadomości |
|
| 1-3 | uint24 | 6-cyfrowy klucz dostępu | różni się |
| 4-9 | uint48 | Adres komponentu powiązania docelowego | różni się |
| 10 | uint8 | Kod stanu, używany tylko w ramach operacji odczytu | Jedna z opcji
|
| 11-15 | Losowa wartość (sól) | różni się |
Podstawowy (pierwszy połączony komponent) jest łącznikiem między urządzeniem Fast Pair Seeker a dodatkowymi komponentami łączenia. Cecha musi być zgodna z wytycznymi:
- Po otrzymaniu prośby o zapisywanie danych od poszukującego Szybkie parowanie dostawca:
- Ustaw adres komponentu, który jest łączony
- Przesyłanie klucza dostępu do komponentu, który ma być połączony
- Ustaw kod stanu na „Oczekuje”, 0x01
- Po otrzymaniu żądania odczytu przed otrzymaniem klucza dostępu od komponentu będącego w powiązaniu dostawca zwraca wiadomość z
- Klucz dostępu, dowolna wartość
- Adres komponentu, który ma być połączony
- Kod stanu oczekujący: 0x01
- Zanim dostawca wyśle powiadomienie do szukającego Szybkiego parowania, ustawia wynik żądania odczytu na
- klucz dostępu z połączonego komponentu;
- Adres komponentu, który ma być połączony
- Kod stanu powodzenia 0x00
- Ustaw wynik, jeśli po stronie dostawcy pojawi się nieodwracalny błąd.
- Klucz dostępu, dowolna wartość
- Adres komponentu, który ma być połączony
- Kod stanu błędu 0x02
Więcej informacji znajdziesz w diagramie MITM 1 i diagramie MITM 2.
Wymagania dotyczące urządzeń LE
LE Advertising
W przypadku trybu wykrywalnego lub niewykrywalnego Dostawca powinien używać RPA do reklamowania danych Szybkiego parowania.
Możliwość łączenia
W przypadku urządzeń obsługujących LE Seeker musi utworzyć wiązanie z istniejącym połączeniem LE. Po przejściu weryfikacji parowania na podstawie klucza Szybkiego parowania dostawca powinien zezwolić na łączenie z RPA i ustawić opcję IO na DisplayYesNo w przypadku weryfikacji klucza Szybkiego parowania.
Wymagania dotyczące urządzeń LEA
LEA Advertising
W przypadku urządzeń obsługujących dwa tryby: W trybie wykrywania dostawca musi reklamować dane Szybkiego parowania za pomocą adresu tożsamości. W przypadku trybu niewykrywalnego Dostawca reklamuje dane Szybkiego parowania za pomocą RPA. Zdecydowanie zalecamy używanie starszych reklam (BT 4.2) w celu zapewnienia zgodności wstecznej ze starszymi urządzeniami. Należy zmienić IRK za każdym razem, gdy urządzenie zostanie przywrócone do ustawień fabrycznych.
Urządzenia w trybie innym niż podwójny: W przypadku trybu wykrywalnego lub niewykrywalnego Dostawca używa reklam rozszerzonych (BT 5.0) z RPA do reklamowania danych za pomocą Szybkiego parowania.
Reklamy z możliwością połączenia LE zawierające dane usługi FP muszą zawierać identyfikator UUID CAS zgodnie z wymaganiami profilu adaptera Bluetooth (BAP 1.0.1) i profilu wspólnego dźwięku. W przypadku reklam niewykrywalnych, jeśli w starszej wersji reklamy brakuje miejsca z powodu uwzględnienia danych o baterii i SASS, w takim przypadku należy uwzględnić identyfikator CAS UUID w odpowiedzi na skanowanie.
Możliwość łączenia w trybie LEA
Seeker musi utworzyć powiązanie z istniejącym połączeniem LE. Po przejściu weryfikacji parowania za pomocą klucza Szybkiego parowania dostawca w trybie podwójnym powinien zezwolić na parowanie z adresem tożsamości i RPA, a dostawca w trybie innym niż podwójnym powinien zezwolić na parowanie z RPA i ustawić opcję IO na DisplayYesNo w przypadku weryfikacji klucza Szybkiego parowania.
wewnętrzny kanał komunikacji między komponentami,
Istniejące połączenie GATT jest utrzymywane, aby zapewnić ochronę MITM w dodatkowych komponentach. Główny powiązany komponent będzie obsługiwać dostarczanie wiadomości między narzędziem Szybkie parowanie i jego pozostałymi komponentami.
Komunikacja wewnętrzna jest używana w przypadku Initial Pair i Subsequent Pair
- Jeśli procedura parowania opartego na kluczach zakończy się w przypadku składnika głównego, składnik główny wyśle wiadomość, aby zmienić możliwości zamówienia reklamowego jego pozostałych komponentów.
- Po zakończeniu Szybkiego parowania komponent główny wysyła wiadomość, aby zresetować interfejs I/O pozostałych komponentów.
- Podczas wykonywania procedury dodatkowego klucza dostępu komponent podstawowy powinien obsługiwać dostarczanie kluczy dostępu między wyszukiwaczem Szybkiego parowania a pozostałymi komponentami.
Czas na zmianę możliwości operacji wejścia-wyjścia
- Zmień zdolność IO na DisplayYesNo, gdy procedura parowania na podstawie klucza zostanie zakończona pomyślnie.
- Jeśli urządzenie składa się z wielu komponentów, wszystkie z nich powinny być ustawione na: DisplayYesNo
- Jedynym wyjątkiem, w którym dostawca nie może zmienić możliwości IO na DisplayYesNo, jest
Retroactive Pair, w którym bit 3 żądania parowania na podstawie klucza ma wartość 1. Więcej informacji znajdziesz w wiadomości od poszukującego do dostawcy.
- Zmień ustawienie funkcji IO na domyślne
- Wstępne parowanie
- Jeśli połączenie LE zostanie przerwane, zakończ sesję Szybkiego parowania.
- Gdy urządzenie podstawowe zostanie sparowane, jeśli w ciągu 15 sekund nie pojawi się dodatkowa prośba o zapisanie klucza dostępu, zakończ sesję Szybkiego parowania
- Jeśli po otrzymaniu dodatkowego żądania zapisu klucza dostępu powiązany komponent nie zostanie powiązany w ciągu 15 sekund, zakończ sesję Szybkie parowanie
- Gdy wszystkie komponenty zostaną połączone, jeśli w ciągu 15 sekund nie zostanie wysłane żądanie zapisu klucza konta, zakończ sesję Szybkiego parowania.
- Po otrzymaniu żądania zapisu klucza konta ustaw czas oczekiwania na 15 sekund, aby zakończyć sesję Szybkiego parowania
- Kolejne parowanie
- Jeśli połączenie LE zostanie przerwane, zakończ sesję Szybkiego parowania.
- Gdy urządzenie podstawowe zostanie sparowane, jeśli w ciągu 15 sekund nie zostanie wysłane dodatkowe żądanie zapisu klucza dostępu, zakończ sesję Fast Pair
- Po otrzymaniu dodatkowego żądania zapisu klucza dostępu, jeśli urządzenie, które ma być sparowane, nie zostanie sparowane w ciągu 15 sekund, zakończ sesję Szybkiego parowania
- Po sparowaniu wszystkich komponentów zakończ sesję Szybkiego parowania
- Wstępne parowanie
Ukryj wskaźniki interfejsu
Gdy zestaw słuchawkowy nie jest gotowy do parowania, dostawca musi użyć type 0b0010, aby ustawić ustawienie ukrywania interfejsu użytkownika dla danych klucza konta, aby poinformować poszukującego, że nie należy wyświetlać kolejnego interfejsu parowania (patrz dane reklamowe: dane konta Fast Pair).
Wymagania LE Audio
Wymagania dotyczące Bluetootha
Zobacz zalecenia dotyczące słuchawek z Bluetooth LE na Androida.
Zespół pomocy CTKD
W przypadku urządzenia w trybie podwójnym obowiązkowe jest CTKD z LE do BR/EDR zgodnie z wymaganiami BAP.
Ogłoszenie dotyczące celu
Urządzenie peryferyjne musi używać komunikatu kierowanego, aby zainicjować połączenie z podłączonym urządzeniem centralnym. W dokumentach BAP i CAP definiuje się komunikaty kierowane w celu zarządzania połączeniami zgodnie z tabelą 8.4 specyfikacji CAP w wersji 1.0 (s. 48/58).
Obsługa serwera GATT EATT
EATT umożliwia urządzeniu centralnemu wysyłanie wielu transakcji GATT równolegle, gdy urządzenie jest połączone. W przypadku urządzenia obsługującego protokół CSIP zwiększy wydajność połączenia profilu i wkrótce rozpocznie procedurę łączenia innych słuchawek za pomocą CSIP.
Buforowanie w trybie GATT (zalecane)
Jeśli dostawca nie jest pojedynczym urządzeniem, ale zamiast tego jest to skoordynowany zestaw z implementacją CSIP, aby zmniejszyć liczbę prób wykrywania usługi i przyspieszyć nawiązywanie połączenia, dostawca powinien zaimplementować buforowanie GATT zdefiniowane w Bluetooth 5.1.
Wymagania dotyczące Szybkiego parowania
LE Advertising
W przypadku trybu wykrywalności lub trybu niewykrywalności, jeśli urządzenie ma kilka komponentów, dane Szybkiego parowania będą reklamowane przez komponent główny. Jeśli urządzenie nie jest gotowe do kolejnego parowania, komponent pomocniczy może wyświetlać dane Szybkiego parowania w celu rozszerzenia funkcji. Zobacz Ukrywanie wskazania w interfejsie użytkownika.
Widoczność usługi GATT
Baza danych GATT musi być taka sama dla wszystkich połączeń GATT z transportem LE. Usługa LE Audio (0x184E) musi być uwzględniona w bazie danych GATT połączenia Szybkie parowanie.
Przykład: parowanie z dostawcą w trybie podwójnym LEA
Scenariusz 1 – gdy Seeker nie obsługuje LEA
Dostawca musi mieć zgodność wsteczną z aplikacją Seeker, która nie obsługuje LEA.
Komponenty
- Dostawca: A2DP/HFP/LEA
- Seeker: A2DP/HFP
Oczekiwane działanie w przypadku początkowego parowania / kolejnego parowania
- Dostawca reklamuje dane usługi Fast Pair (0xFE2C) z adresem tożsamości (pierwotnie) lub RPA (następnie).
- Korzystanie z reklam starszego typu
- Użytkownik otrzymuje reklamę dostawcy z adresem tożsamości na potrzeby początkowego lub RPA na potrzeby kolejnego parowania
- Szukający wysyła żądanie parowania na podstawie klucza
- Bit-5 żądania parowania opartego na kluczu jest ustawione na 0
- Dostawca wysyła odpowiedź w ramach parowania opartego na kluczu z publicznym adresem w jednym z tych miejsc:
- Jeśli używany jest typ wiadomości 0x01, adres musi być adresem publicznym.
- Jeśli używany jest typ wiadomości 0x02:
- Bit 0 musi mieć wartość 0.
- Bit 1 musi być równy 0
- Adres powinien być adresem publicznym.
- The Seeker tworzy wiązanie z transportem BR/EDR
- Możliwość zamówienia reklamowego jest ustawiona na DisplayYesNo dla BR/EDR
- Procedura weryfikacji klucza dostępu w ramach Szybkiego parowania w narzędziu Seeker i dostawca
Scenariusz 2 – gdy Seeker obsługuje LEA
Komponenty
- Dostawca
- Obsługa A2DP/HFP/LEA
- Jeden składnik
- Seeker
- Obsługa A2DP/HFP/LEA
Oczekiwane działanie w przypadku początkowego parowania / kolejnego parowania
- Dostawca reklamuje dane usługi Fast Pair (0xFE2C) z adresem tożsamości (pierwotnie) lub RPA (następnie).
- Korzystanie z reklam starszego typu
- Seeker wysyła żądanie parowania opartego na kluczu.
- Bit-5 żądania parowania opartego na kluczu jest ustawione na 1
- Usługodawca wysyła odpowiedź na żądanie parowania z kluczem z typem wiadomości 0x02
- Bit 0 musi mieć wartość 0.
- Bit 1 musi być 1
- Adres to adres tożsamości
- Seeker tworzy połączenie z istniejącym połączeniem LE w ramach transportu LE.
- Kierunek CTKD to LE do BR/EDR
- Ustawienie „IO capability” ma wartość „DisplayYesNo” dla LE.
- Użytkownik i dostawca przechodzą procedurę weryfikacji klucza dostępu Szybkie parowanie
Scenariusz 3 – gdy Seeker obsługuje LEA i CSIP
Komponenty
- Dostawca
- Obsługa A2DP/HFP/LEA
- Wiele komponentów
- Główny komponent to BR/EDR/LE
- Składowa dodatkowa jest tylko dla LE
- Seeker
- Obsługa A2DP/HFP/LEA
Oczekiwane działanie w pierwszej / kolejnej parze
- Główny komponent reklamuje dane usługi Fast Pair (0xFE2C) z adresem tożsamości (początkowy) lub RPA (następny).
- Korzystanie z reklam starszego typu
- Szukający wysyła żądanie parowania na podstawie klucza do głównego komponentu.
- Bit 5 flagi w prośbie o sparowanie na podstawie klucza ma wartość 1
- Główny komponent wysyła odpowiedź na żądanie parowania z kluczem z typem wiadomości 0x02
- Bit 0 musi mieć wartość 0.
- Bit 1 musi być 1
- Adres:
- Pierwszy adres to adres tożsamości głównego komponentu.
- Drugi adres to adres, który można połączyć z drugim komponentem. Drugi komponent używa tego adresu do reklamy CSIP.
- Seeker tworzy połączenie z głównym komponentem na istniejącym połączeniu LE.
- Kierunek CTKD to LE do BR/EDR
- Możliwość wejścia-wyjścia jest ustawiona na DisplayYesNo dla LE
- Poszukiwacz tworzy wiązanie z komponentem dodatkowym, którego adres pochodzi z rozszerzonej odpowiedzi na parowanie oparte na kluczach
- Możliwości interfejsu wejścia/wyjścia powinny być ustawione na „Tak” lub „Nie”. W przeciwnym razie prośba o sparowanie zostanie odrzucona.
- Procedura zabezpieczania Wyszukiwacza i Dostawcy w celu sparowania komponentu dodatkowego Dostawca musi wdrożyć w obu scenariuszach.
- Szukający oczekuje na połączenie z podrzędnym komponentem
Schemat sekwencyjny MITM
Ta sesja ma na celu opisanie sekwencji procedury ochrony MITM.
Pobieranie klucza dostępu z urządzenia, które jest połączone za pomocą powiadomienia
Pobieranie klucza dostępu z komponentu połączonego przez odczyt
Znany problem
Funkcja FP dla LEA została zoptymalizowana pod kątem działania z Androidem V(Android 15).
Z kolei w zestawach słuchawkowych, które obsługują LEA, ale nie ma odpowiedniej implementacji Szybkiego parowania na LEA (np. Szybkie parowanie zamiast Classic), Dotyczy to na przykład sytuacji, gdy RPA dostawcy nie jest generowany za pomocą prawidłowego klucza rozwiązywania tożsamości (IRK), a adres nie może zostać rozwiązany. Nie udało nam się przetestować wyczerpującej listy konfiguracji słuchawek, ale przeprowadzone przez nas testy wykazały różne problemy, w tym brak wyświetlania powiadomień o baterii słuchawek, brak funkcji przełączania dźwięku (SASS), powszechne błędy początkowe i późniejsze parowania.
Dlatego zdecydowanie zalecamy partnerom implementację specyfikacji Fast Pair-LEA w przypadku zarówno nowych, jak i dotychczasowych urządzeń (za pomocą aktualizacji OTA), które obsługują tryby podwójne.