Urządzenie Bluetooth Low Energy (BLE)
Implementacja usługi Google Szybkie parowanie (GFPS) na urządzeniach BLE jest zgodna ze specyfikacją Bluetooth Core w wersji 4.2 lub nowszej.
Ten dodatek do specyfikacji Szybkiego parowania umożliwia obsługę urządzeń korzystających tylko z technologii Low Energy (LE) i Low Energy Audio (LEA) w GFPS.
Poziomy zgodności
Słowa kluczowe „shall”, „must”, „will”, „should”, „may” i „can” wymienione w specyfikacji są wyjaśnione poniżej:
| Okres obowiązywania | Opis |
|---|---|
| shall | is required to (jest wymagane do) – służy do definiowania wymagań. |
| must | jest używane do wyrażenia: naturalnej konsekwencji wcześniej określonego obowiązkowego wymagania LUB niepodważalnego stwierdzenia faktu (które jest zawsze prawdziwe niezależnie od okoliczności). |
| będzie | it is true that – używane tylko w stwierdzeniach dotyczących faktów. |
| should | is recommended that – używane do wskazania, że spośród kilku możliwości jedna jest zalecana jako szczególnie odpowiednia, ale nie jest wymagana. |
| maj | is permitted to (może) – służy do zezwalania na opcje. |
| możemy | is able to (jest w stanie) – używane do powiązania stwierdzenia w sposób przyczynowo-skutkowy. |
Charakterystyka parowania opartego na kluczach
Wiadomość od osoby poszukującej do dostawcy
Nieprzetworzone żądanie type 0x00 cechy parowania opartego na kluczach używa bitu 4 do wskazania, czy urządzenie poszukujące obsługuje specyfikację urządzenia BLE, oraz bitu 5 do wskazania, czy urządzenie poszukujące obsługuje LE Audio.
| Oktet | Typ danych | Opis | Wartość | Obowiązkowe? |
|---|---|---|---|---|
| 0 | uint8 |
Typ komunikatu | 0x00 = prośba o parowanie na podstawie klucza |
Obowiązkowe |
| 1 | uint8 |
Flagi
|
różne | Obowiązkowe |
| 2–7 | uint48 |
Wykonaj 1 z tych czynności:
|
różne | Obowiązkowe |
| 8–13 | uint48 |
Adres BR/EDR urządzenia poszukującego | różne | Obecny tylko wtedy, gdy ustawiony jest bit flagi 1 lub 3 |
| n – 15 | losowa wartość (salt), | różne | Obowiązkowe |
Wiadomość od dostawcy do poszukującego
Gdy bit 4 żądania jest ustawiony, można użyć nowego komunikatu odpowiedzi type 0x02 dla cechy parowania opartego na kluczach, aby udostępnić poszukującemu dodatkowe opcje powiązania.
| Oktet | Typ danych | Opis | Wartość |
|---|---|---|---|
| 0 | uint8 |
Typ komunikatu | 0x02 = długa odpowiedź dotycząca parowania na podstawie klucza |
| 1 | uint8 |
Flagi
|
różne |
| 2 | uint8 |
Liczba adresów dostawcy (w obecnej wersji liczba ta wynosi 1 lub 2, ponieważ jeśli liczba jest większa lub równa 3, musimy zmienić tryb szyfrowania blokowego na AES-CTR) |
różne |
| 3–8 lub 3–14 |
|
różne | |
| 9–15 lub 15 | losowa wartość (salt), | różne |
Dostawca, który obsługuje specyfikację urządzenia BLE, powinien odczytać bity 4 i 5, aby poznać możliwości urządzenia poszukującego.
- Gdy bit 4 ma wartość 0, dostawca powinien zignorować bit 5 i odpowiedzieć w formacie
type 0x01. - Gdy bit 4 ma wartość 1,
- W przypadku dostawcy obsługującego tylko LE powinien on odpowiedzieć
type 0x02, aby wskazać preferencję parowania LE. - W przypadku dostawcy działającego w trybie dualnym może on odpowiedzieć
type 0x02, aby wskazać preferencję powiązania BR/EDR lub LE.
- W przypadku dostawcy obsługującego tylko LE powinien on odpowiedzieć
- W przypadku urządzeń LE Audio (LEA) w trybie dualnym zapoznaj się z artykułem Przykład: parowanie z urządzeniem LEA w trybie dualnym.
Charakterystyka PSM (multipleksera usługi protokołu) strumienia wiadomości
Aby obsługiwać strumień wiadomości na urządzeniach BLE, Szybkie parowanie ustanawia i utrzymuje kanał BLE L2CAP do wysyłania i odbierania wiadomości. Szybkie parowanie Serwer L2CAP powinien implementować kontrolę przepływu opartą na kredytach LE.
Ta cecha umożliwia Poszukującemu odczytanie wartości PSM, a następnie nawiązanie bezpiecznego połączenia L2CAP na podstawie wartości PSM.
| Charakterystyka usługi Szybkie parowanie | Zaszyfrowane | Uprawnienia | UUID |
|---|---|---|---|
| Strumień wiadomości PSM | Tak | Odczyt | FE2C1239-8366-4814-8EB0-01DE32100BEA |
| Oktet | Typ danych | Opis | Wartość |
|---|---|---|---|
| 0 | uint8 |
Stan
|
różne |
| 1–2 | uint16 |
Wartość PSM musi mieścić się w zakresie od 0x80 do 0xFF | różne |
Uwaga: w przypadku TWS występują 2 komponenty: główny i dodatkowy. W pewnych warunkach role tych komponentów są wymienne. Załóżmy, że A jest komponentem głównym , a B – dodatkowym. Z powodu rozładowania baterii w komponencie A komponent B musi przejąć rolę komponentu głównego. Ten scenariusz nazywa się role switch.
Jeśli po upływie role switch dostawca nie może obsłużyć strumienia wiadomości Szybkiego parowania, powinien aktywnie rozłączyć istniejące połączenie L2CAP. Urządzenie poszukujące Szybkiego parowania może wtedy ponownie nawiązać połączenie strumienia wiadomości L2CAP z nowym komponentem głównym.
Dodatkowa cecha klucza dostępu
Ta charakterystyka ma zapewnić ochronę przed atakami MITM na dodatkowych komponentach.
Ochrona przed atakami MITM z użyciem fałszywego elementu CSIS
Szybkie parowanie wymaga ochrony przed atakami typu MITM w ramach procedury parowania. Ponieważ CSIS nie zapewnia ochrony przed atakami typu MITM, obecny projekt FP dla wielu komponentów musi zostać rozszerzony, aby zapewnić ochronę przed atakami typu MITM w przypadku dodatkowych komponentów.
Definicja cechy
| Charakterystyka usługi Szybkie parowanie | Zaszyfrowane | Uprawnienie | UUID |
|---|---|---|---|
| Dodatkowy klucz dostępu | Nie | Odczyt,zapis,powiadomienie | FE2C123A-8366-4814-8EB0-01DE32100BEA |
Wiadomości
Format wiadomości jest stosowany do operacji odczytu, zapisu i powiadomień.
Format zaszyfrowanych danych
Zaszyfrowane dane są wysyłane za pomocą połączenia GATT Szybkiego parowania.
| Oktet | Typ danych | Opis | Wartość |
|---|---|---|---|
| 0-15 | uint128 | Zaszyfrowany blok dodatkowego klucza dostępu | różne |
Format nieprzetworzonych danych
Po odszyfrowaniu zaszyfrowanych danych za pomocą wspólnego klucza tajnego format jest taki jak poniżej:
| Oktet | Typ danych | Opis | Wartość |
|---|---|---|---|
| 0 | uint8 | Typ komunikatu | jedna z tych wartości:
|
| 1-3 | uint24 | 6-cyfrowy klucz dostępu | różne |
| 4-9 | uint48 | Adres docelowego komponentu powiązania | różne |
| 10 | uint8 | Kod stanu, używany tylko przez operację odczytu | Jedna z tych możliwości:
|
| 11-15 | losowa wartość (salt), | różne |
Komponent główny (pierwszy powiązany komponent) jest mostem między urządzeniem wykrywającym Szybkie parowanie a dodatkowymi powiązanymi komponentami. Charakterystyka powinna być zgodna z tymi wytycznymi:
- Po otrzymaniu prośby o zapis od urządzenia poszukującego Szybkiego parowania dostawca powinien:
- Ustaw adres komponentu, który jest powiązany
- Wysyłanie klucza dostępu do komponentu, który jest parowany
- Ustaw kod stanu na Oczekujący, 0x01
- W przypadku otrzymania żądania odczytu przed otrzymaniem klucza dostępu od powiązanego komponentu dostawca powinien zwrócić komunikat z
- Klucz dostępu, dowolna wartość
- Adres komponentu, który jest powiązany
- Kod stanu oczekiwania, 0x01
- Zanim dostawca wyśle powiadomienie do urządzenia poszukującego Szybkiego parowania, ustawia wynik żądania odczytu na
- Klucz dostępu z komponentu, który jest parowany
- Adres komponentu, który jest powiązany
- Kod stanu powodzenia, 0x00
- Jeśli po stronie dostawcy wystąpi nieodwracalny błąd, ustaw wynik na
- Klucz dostępu, dowolna wartość
- Adres komponentu, który jest powiązany
- Kod stanu błędu: 0x02
Więcej informacji znajdziesz na schemacie MITM 1 i schemacie MITM 2.
Wymagania dotyczące urządzeń LE
LE Advertising
W trybie wykrywalnym i niewykrywalnym dostawca powinien używać RPA do rozgłaszania danych Szybkiego parowania.
Możliwość łączenia
W przypadku urządzeń obsługujących LE poszukujący musi utworzyć powiązanie z istniejącym połączeniem LE. Po przejściu weryfikacji parowania opartego na kluczach w ramach Szybkiego parowania dostawca powinien zezwolić na powiązanie z RPA i ustawić funkcję IO na DisplayYesNo na potrzeby weryfikacji klucza dostępu w ramach Szybkiego parowania.
Wymagania dotyczące urządzeń LEA
Reklamy LEA
Urządzenia z trybem dualnym: W trybie wykrywalnym dostawca powinien rozgłaszać dane Szybkiego parowania z adresem tożsamości. W trybie niewykrywalnym dostawca powinien rozgłaszać dane Szybkiego parowania z RPA. Zdecydowanie zalecamy używanie starszych reklam (BT 4.2), aby zapewnić zgodność wsteczną ze starszymi urządzeniami. Klucz IRK należy zmienić po każdym przywróceniu urządzenia do ustawień fabrycznych.
W przypadku urządzeń bez trybu dualnego: W trybie wykrywalnym lub niewykrywalnym dostawca powinien używać rozszerzonego rozgłaszania (BT 5.0) z RPA do rozgłaszania danych Szybkiego parowania.
Reklama LE z możliwością połączenia zawierająca dane usługi FP musi zawierać identyfikator UUID CAS zgodnie z wymaganiami profilu adaptera Bluetooth (BAP 1.0.1) i profilu Common Audio.
Dostawca może wskazać obsługę LEA, podając identyfikator UUID CAS (0x1853) w danych usługi (typ AD 0x16) lub 16-bitowych identyfikatorach UUID klasy usługi (typ AD 0x02 lub 0x03), niezależnie od trybu wykrywania.
W przypadku niewykrywalnych reklam, jeśli w starszej reklamie nie ma wystarczającej ilości miejsca z powodu uwzględnienia danych o baterii i SASS, w odpowiedzi na skanowanie należy uwzględnić identyfikator UUID CAS.
Możliwość powiązania LEA
Poszukujący musi utworzyć powiązanie z istniejącym połączeniem LE. Po przejściu weryfikacji parowania opartego na kluczach Szybkiego parowania dostawca trybu dualnego powinien zezwolić na powiązanie z adresem tożsamości i RPA, a dostawca trybu innego niż dualny powinien zezwolić na powiązanie z RPA i ustawić funkcję IO na DisplayYesNo na potrzeby weryfikacji klucza dostępu Szybkiego parowania.
Wewnętrzny kanał komunikacji między komponentami
Istniejące połączenie GATT jest utrzymywane w celu ochrony przed atakami MITM na dodatkowe komponenty. Główny powiązany komponent powinien obsługiwać dostarczanie wiadomości między urządzeniem wykrywającym Szybkie parowanie a pozostałymi komponentami.
Komunikacja wewnętrzna jest używana w Initial Pair i Subsequent Pair
- Gdy procedura parowania opartego na kluczach zostanie przekazana do głównego komponentu, główny komponent powinien wysłać wiadomość, aby zmienić możliwości wejścia/wyjścia pozostałych komponentów.
- Po zakończeniu szybkiego parowania komponent główny powinien wysłać wiadomość, aby zresetować funkcję wejścia/wyjścia pozostałych komponentów.
- Podczas procedury dodatkowego klucza dostępu komponent główny powinien obsługiwać dostarczanie kluczy dostępu między urządzeniem poszukującym Szybkiego parowania a pozostałymi komponentami.
Czas na zmianę możliwości wejścia/wyjścia
- Zmień funkcję wejścia/wyjścia na DisplayYesNo po zakończeniu procedury parowania opartego na kluczach.
- Jeśli urządzenie ma kilka komponentów, wszystkie powinny być ustawione na DisplayYesNo.
- Wyjątkiem, w którym dostawca nie powinien zmieniać funkcji IO na DisplayYesNo, jest
Retroactive Pair, którego bit 3 żądania parowania opartego na kluczach jest ustawiony na 1. Zobacz Wiadomość od poszukującego do dostawcy.
- Zmień funkcję wejścia/wyjścia na ustawienie domyślne
- Początkowe parowanie
- Jeśli połączenie LE zostanie przerwane, zakończ sesję szybkiego parowania.
- Jeśli po powiązaniu urządzenia głównego w ciągu 15 sekund nie pojawi się dodatkowe żądanie zapisu klucza dostępu, zakończ sesję Szybkiego parowania.
- Po otrzymaniu dodatkowej prośby o zapisanie klucza dostępu, jeśli komponent, który jest parowany, nie zostanie sparowany w ciągu 15 sekund, zakończ sesję Szybkiego parowania.
- Jeśli po sparowaniu wszystkich komponentów 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 limit czasu na 15 sekund, aby zakończyć sesję Szybkiego parowania.
- Kolejne parowanie
- Jeśli połączenie LE zostanie przerwane, zakończ sesję szybkiego parowania.
- Jeśli po powiązaniu urządzenia głównego w ciągu 15 sekund nie pojawi się dodatkowe żądanie zapisu klucza dostępu, zakończ sesję Szybkiego parowania.
- Po otrzymaniu dodatkowej prośby o zapisanie klucza dostępu, jeśli komponent, który jest parowany, nie zostanie sparowany w ciągu 15 sekund, zakończ sesję Szybkiego parowania.
- Po połączeniu wszystkich komponentów zakończ sesję szybkiego parowania.
- Początkowe parowanie
Ukryj wskaźnik interfejsu
Gdy zestaw słuchawkowy nie jest gotowy do sparowania, dostawca powinien użyć type 0b0010, aby ustawić ukrywanie interfejsu dla danych klucza konta, aby poinformować poszukującego, że nie ma wyświetlać kolejnego interfejsu parowania (patrz Ładunek reklamowy: dane konta Szybkiego parowania).
Wymagania dotyczące urządzeń LE Audio
Wymagania dotyczące Bluetootha
Zapoznaj się z rekomendacjami dotyczącymi zestawów słuchawkowych LE Audio na Androidzie.
Obsługa CTKD
W przypadku urządzenia z trybem dualnym CTKD z LE na BR/EDR jest obowiązkowe i zgodne z wymaganiami BAP.
Ogłoszenie docelowe
Urządzenie peryferyjne powinno używać funkcji Targeted Announcement, aby poprosić o połączenie ze sparowanym urządzeniem centralnym. Ogłoszenia kierowane są zdefiniowane w profilach BAP i CAP na potrzeby zarządzania połączeniami zgodnie z tabelą 8.4 (s. 48/58) w CAP 1.0.
Obsługa serwera GATT EATT
EATT umożliwia urządzeniu centralnemu wysyłanie wielu transakcji GATT równolegle, gdy urządzenie jest powiązane. W przypadku urządzenia obsługującego CSIP zwiększy to wydajność połączenia profilu, a następnie szybko rozpocznie procedurę wiązania CSIP dla pozostałych słuchawek.
Niezawodne buforowanie GATT (zdecydowanie zalecane)
Jeśli dostawca nie jest pojedynczym urządzeniem, ale skoordynowanym zestawem z implementacją CSIP, powinien wdrożyć buforowanie GATT zdefiniowane w Bluetooth 5.1, aby skrócić czas wykrywania usług i przyspieszyć połączenie.
Wymagania dotyczące Szybkiego parowania
LE Advertising
W trybie wykrywalnym lub niewykrywalnym, jeśli urządzenie ma wiele komponentów, dane Szybkiego parowania powinny być rozgłaszane przez komponent główny. Jeśli urządzenie nie jest gotowe do kolejnego parowania, komponent dodatkowy może rozgłaszać dane Szybkiego parowania dotyczące rozszerzonych funkcji. Zobacz Ukrywanie wskazania interfejsu.
Widoczność usługi GATT
Baza danych GATT musi być taka sama dla wszystkich połączeń GATT transportu LE. Usługa LE Audio (0x184E) musi być uwzględniona w bazie danych GATT połączenia Szybkiego parowania.
Przykład: parowanie z dostawcą trybu dualnego LEA
Scenariusz 1. Gdy urządzenie poszukujące nie obsługuje LEA
Dostawca musi zapewniać zgodność wsteczną z urządzeniem poszukującym, które nie obsługuje LEA.
Komponenty
- Dostawca: A2DP/HFP/LEA
- Poszukujący: A2DP/HFP
Oczekiwane działanie podczas pierwszego i kolejnych parowań
- Dostawca rozgłasza dane usługi Szybkiego parowania (0xFE2C) z adresem tożsamości (początkowym) lub RPA (kolejnym).
- Korzystanie z reklam starszego typu
- Poszukujący otrzymuje reklamę Dostawcy z adresem tożsamości w przypadku początkowego parowania lub RPA w przypadku kolejnego parowania.
- Poszukujący wysyła prośbę o parowanie na podstawie klucza.
- Bit 5 flagi żądania parowania na podstawie klucza jest ustawiony na 0.
- Dostawca wysyła odpowiedź dotyczącą parowania opartego na kluczach z adresem publicznym w jednym z tych formatów:
- 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 mieć wartość 0
- Adres musi być adresem publicznym.
- Poszukujący tworzy powiązanie z transportem BR/EDR.
- Funkcja wejścia/wyjścia jest ustawiona na DisplayYesNo dla BR/EDR
- Poszukiwacz i Dostawca przeprowadzają procedurę weryfikacji klucza dostępu Szybkiego parowania.
Scenariusz 2. Gdy urządzenie poszukujące obsługuje LEA
Komponenty
- Dostawca
- Obsługa A2DP/HFP/LEA
- Pojedynczy komponent
- Seeker
- Obsługa A2DP/HFP/LEA
Oczekiwane działanie podczas pierwszego i kolejnych parowań
- Dostawca rozgłasza dane usługi Szybkiego parowania (0xFE2C) z adresem tożsamości (początkowym) lub RPA (kolejnym).
- Korzystanie z reklam starszego typu
- Poszukujący wysyła prośbę o parowanie na podstawie klucza.
- Bit 5 flagi żądania parowania na podstawie klucza jest ustawiony na 1.
- Dostawca wysyła odpowiedź dotyczącą parowania opartego na kluczach z typem wiadomości 0x02.
- Bit 0 musi mieć wartość 0.
- Bit-1 musi mieć wartość 1
- Adres jest adresem tożsamości
- Poszukujący tworzy powiązanie z istniejącym połączeniem LE w transporcie LE.
- Kierunek CTKD to LE do BR/EDR
- Funkcja IO jest ustawiona na DisplayYesNo dla LE
- Poszukiwacz i Dostawca przeprowadzają procedurę weryfikacji klucza dostępu Szybkiego parowania.
Scenariusz 3 – gdy poszukujący obsługuje LEA i CSIP
Komponenty
- Dostawca
- Obsługa A2DP/HFP/LEA
- Wiele komponentów
- Główny komponent to BR/EDR/LE
- Komponent dodatkowy jest przeznaczony tylko dla LE
- Seeker
- Obsługa A2DP/HFP/LEA
Oczekiwane działanie podczas pierwszego i kolejnych parowań
- Komponent główny rozgłasza dane usługi Szybkiego parowania (0xFE2C) z adresem tożsamości (początkowym) lub RPA (kolejnym).
- Korzystanie z reklam starszego typu
- Poszukujący wysyła do głównego komponentu prośbę o parowanie na podstawie klucza.
- Bit 5 flagi żądania parowania na podstawie klucza jest ustawiony na 1.
- Komponent główny wysyła odpowiedź dotyczącą parowania opartego na kluczach z typem wiadomości 0x02.
- Bit 0 musi mieć wartość 0.
- Bit-1 musi mieć wartość 1
- Adres:
- Pierwszy adres to adres tożsamości komponentu głównego
- Drugi adres to adres możliwy do powiązania dla komponentu dodatkowego. Drugi komponent również używa tego adresu do rozgłaszania CSIP.
- Poszukujący tworzy powiązanie z komponentem głównym w ramach istniejącego połączenia LE.
- Kierunek CTKD to LE do BR/EDR
- Funkcja IO jest ustawiona na DisplayYesNo dla LE
- Poszukujący tworzy powiązanie z komponentem dodatkowym, którego adres pochodzi z rozszerzonej odpowiedzi parowania na podstawie klucza.
- Funkcja wejścia/wyjścia musi być ustawiona na DisplayYesNo, w przeciwnym razie prośba o sparowanie zostanie odrzucona.
- Urządzenie poszukujące i dostawca wykonują procedurę ochrony przed atakiem typu MITM w celu sparowania komponentu dodatkowego. Dostawca powinien wdrożyć oba scenariusze.
- Poszukiwacz czeka na powiązanie z komponentem dodatkowym.
Diagram sekwencyjny dla MITM
Ta sesja opisuje sekwencję procedury ochrony przed atakami typu MITM.
Pobieranie klucza dostępu z komponentu powiązanego z powiadomieniem
Pobierz klucz dostępu z komponentu, który jest powiązany przez odczyt
Znany problem
Funkcja FP dla LEA została zoptymalizowana pod kątem działania z Androidem V (Android 15).
Z drugiej strony napotkaliśmy wiele problemów ze słuchawkami, które obsługują LEA, ale nie mają prawidłowej implementacji Szybkiego parowania przez LEA (tj. tylko Szybkie parowanie przez Classic). Na przykład gdy adres RPA dostawcy nie jest generowany przez prawidłowy klucz IRK i nie można go rozpoznać. Nie udało nam się przetestować wszystkich konfiguracji słuchawek, ale nasze ograniczone testy wykazały różne problemy, w tym brak wyświetlania powiadomień o baterii słuchawek dousznych, brak funkcji przełączania dźwięku (SASS), powszechne problemy z początkowym i późniejszym parowaniem i inne.
Dlatego zdecydowanie zalecamy partnerom wdrożenie specyfikacji Szybkiego parowania LEA zarówno na nowych urządzeniach, jak i na urządzeniach już używanych (za pomocą aktualizacji bezprzewodowych), które obsługują tryby podwójne.