Cechy

Usługa Szybkie parowanie

Dostawca szybkiego parowania musi mieć następującą usługę GATT.

Usługa UUID
Usługa Szybkie parowanie 0xFE2C

Usługa ta będzie miała następujące cechy:

Charakterystyka usługi Szybkiego parowania Zaszyfrowane Uprawnienia UUID
Identyfikator modelu Nie Odczyt FE2C1233-8366-4814-8EB0-01DE32100BEA
Parowanie na podstawie klucza Nie Pisanie i powiadamianie FE2C1234-8366-4814-8EB0-01DE32100BEA
Klucz dostępu Nie Pisanie i powiadamianie FE2C1235-8366-4814-8EB0-01DE32100BEA
Klucz konta Nie Zapis FE2C1236-8366-4814-8EB0-01DE32100BEA

Usługa informacji o urządzeniu

Dostawca szybkiego parowania powinien też obsługiwać usługę informacji o urządzeniu.

Usługa UUID
Usługa informacji o urządzeniu 0x180A

Wyszukiwarka Szybkiego parowania korzysta z tych cech:

Nazwa Zaszyfrowane Uprawnienia UUID
Wersja oprogramowania Nie Odczyt 0x2A26

Charakterystyka: identyfikator modelu

Dzięki temu urządzenie wyszukujące może odczytywać identyfikator modelu w razie potrzeby, poza sytuacjami, w których urządzenie reklamuje się w trybie wykrywalności. Zawsze powinna zwracać te dane:

Oktet Typ danych Opis Wartość
0–2 uint24 Identyfikator modelu różni się

Cechy: parowanie oparte na kluczu

Ta charakterystyka kontroluje procedurę parowania opartego na kluczu. W tej procedurze określony poziom zaufania jest ustanawiany przez sprawdzenie, czy zarówno Wyszukujący, jak i Dostawca mają klucz PSK. Klucz jest inny w każdym przypadku:

  • Przypadek 1. Klucz wstępny jest oparty na parze kluczy publiczny/prywatny chroniącej przed fałszowaniem oraz na parze kluczy publiczny/prywatny urządzenia wyszukującego, która będzie się zmieniać przy każdej próbie parowania.

    • Urządzenie jest w trybie parowania.
    • Weryfikator sprawdza, czy dostawca ma klucz prywatny chroniący przed fałszowaniem.

    Pamiętaj, że w trybie parowania dostawca może też oczywiście sparować urządzenie w zwykły sposób, np. z urządzeniem, które nie obsługuje parowania opartego na kluczu w szybkim parowaniu.

  • Przypadek 2. Klucz PSK jest jednym z kluczy konta.

    • Dostawca zwykle nie jest w trybie parowania. (Nie jest to jednak wymagane – dostawca powinien obsługiwać używanie klucza konta nawet w trybie parowania).
    • Osoba szukająca i usługodawca potwierdzają, że druga strona ma klucz konta.

Oba przypadki są bardzo podobne, z wyjątkiem używanego klucza wstępnego, dlatego zostały połączone w procedurze.

Format danych

Zobacz procedurę, aby dowiedzieć się, jak używać poszczególnych formatów.

Oktet Typ danych Opis Wartość Obowiązkowe?
0–15 uint128 Zaszyfrowane żądanie różni się Obowiązkowe
16–79 Klucz publiczny różni się Opcjonalny

Tabela 1.1. Zaszyfrowane żądanie zapisane w charakterystyce przez urządzenie wyszukujące.

Oktet Typ danych Opis Wartość Obowiązkowe?
0 uint8 Typ komunikatu 0x00 = Prośba o sparowanie na podstawie klucza Obowiązkowe
1 uint8 Flagi
  • Bit 0 (MSB): wycofany i ignorowany przez Seeker.
  • Bit 1: 1, jeśli urządzenie wysyłające żądanie prosi urządzenie odbierające żądanie o rozpoczęcie procesu parowania, a żądanie zawiera adres BR/EDR urządzenia wysyłającego żądanie. W przeciwnym razie zwraca 0.
  • Bit 2: 1, jeśli osoba wysyłająca prośbę żąda, aby dostawca powiadomił o istniejącej nazwie. W przeciwnym razie zwraca 0.
  • Bit 3: 1, jeśli dotyczy to wstecznego zapisu klucza konta. W przeciwnym razie zwraca 0.
  • Bity 4–7 są zarezerwowane do wykorzystania w przyszłości i należy je ignorować.
różni się Obowiązkowe
2–7 uint48 Spełnia jeden z tych warunków:
  • Obecny adres BLE dostawcy
  • Adres publiczny dostawcy
różni się Obowiązkowe
8–13 uint48 Adres BR/EDR urządzenia wyszukującego różni się Występuje tylko wtedy, gdy ustawiony jest bit 1 lub 3 flag
n - 15 Wartość losowa (salt) różni się Obowiązkowe

Tabela 1.2.1. Surowe żądanie (typ 0x00). Odszyfrowane z zaszyfrowanego żądania w tabeli 1.1.

Oktet Typ danych Opis Wartość Obowiązkowe?
0 uint8 Typ komunikatu 0x10 = prośba o działanie Obowiązkowe
1 uint8 Flagi
  • Bit 0 (MSB): 1, jeśli jest to działanie na urządzeniu, w przeciwnym razie 0.
  • Bit 1: 1, jeśli po nim nastąpi cecha danych dodatkowych, w przeciwnym razie 0.
  • Bity 2–7 są zarezerwowane do wykorzystania w przyszłości i należy je ignorować.
różni się Obowiązkowe
2–7 uint48 Spełnia jeden z tych warunków:
  • Obecny adres BLE dostawcy
  • Adres publiczny dostawcy
różni się Obowiązkowe
8 uint8 Wyślij wiadomość do grupy różni się Wymagane, jeśli ustawiony jest bit 0 flag
9 uint8 Kod wiadomości różni się Wymagane, jeśli ustawiony jest bit 0 flag
10 uint8 Zależy od flag:
  • Bit 0 jest ustawiony: długość danych dodatkowych jest mniejsza niż 6
  • Bit 1 jest ustawiony: identyfikator danych
różni się Wymagane, jeśli ustawiony jest bit 0 lub 1 flag
11 - n Dodatkowe dane różni się Opcjonalny
n - 15 Wartość losowa (salt) różni się Obowiązkowe

Tabela 1.2.2: surowe żądanie (typ 0x10). Odszyfrowane z zaszyfrowanego żądania w tabeli 1.1.

Oktet Typ danych Opis Wartość
0 uint8 Typ komunikatu 0x01 = odpowiedź na parowanie oparte na kluczu
1–6 uint48 Publiczny adres dostawcy (BR/EDR) różni się
7–15 Wartość losowa (salt) różni się

Tabela 1.3. Odpowiedź nieprzetworzona. zaszyfrowane w celu wygenerowania zaszyfrowanej odpowiedzi w tabeli 1.4.

Oktet Typ danych Opis Wartość
0–15 uint128 Zaszyfrowana odpowiedź różni się

Tabela 1.4. Zaszyfrowana odpowiedź wysłana przez dostawcę do osoby poszukującej za pomocą powiadomienia.

Cechy: klucz dostępu

Ta cecha jest używana podczas procedury parowania opartego na kluczu.

Oktet Typ danych Opis Wartość
0–15 uint128 Zaszyfrowany blok klucza dostępu różni się

Tabela 2.1. Zaszyfrowany blok klucza dostępu. Więcej informacji znajdziesz w sekcji Procedura parowania na podstawie klucza.

Oktet Typ danych Opis Wartość
0 uint8 Typ komunikatu Jedna z tych wartości:
  • 0x02 = klucz dostępu poszukiwacza
  • 0x03 = klucz dostępu dostawcy
1–3 unit32 6-cyfrowy klucz dostępu różni się
4–15 Wartość losowa (salt) różni się

Tabela 2.2. Surowy blok klucza dostępu. Odszyfrowana wersja Tabeli 2.1.

Charakterystyka: klucz konta

Po sparowaniu urządzenie wyszukujące Szybkiego parowania zapisze klucz konta na urządzeniu dostarczającym Szybkie parowanie.

Oktet Typ danych Opis Wartość
0–15 uint128 Klucz konta (zaszyfrowany) różni się

Po otrzymaniu żądania zapisu dostawca Szybkiego parowania powinien wykonać te czynności:

  1. Odszyfruj klucz konta za pomocą udostępnionego hasła wygenerowanego w kroku 4 w procedurze.
    • W przypadku dostawców, którzy wymagają zabezpieczenia (często):
      • Przed odszyfrowaniem sprawdź, czy do odszyfrowania żądania klucza dostępu z kroku 12 użyto udostępnionego hasła. Jeśli ten krok nie został wykonany przy użyciu tego klucza tajnego, zignoruj ten zapis i zakończ działanie.
    • Na tym etapie udostępnione hasło (K w procedurze) nie będzie już używane w przypadku tego parowania. Wszelkie żądania, które przychodzą zaszyfrowane tym kluczem bez ponownego uruchomienia procedury, powinny zostać odrzucone.
  2. Sprawdź, czy odszyfrowana wartość zaczyna się od 0x04 lub 0xFF. Jeśli nie, zignoruj ten zapis i zakończ działanie.
    • Jeśli wartością jest 0x04:
      • Sprawdź, czy w utrwalonej liście kluczy konta jest miejsce na nową wartość.
      • Jeśli nie, usuń z listy najrzadziej używaną wartość.
      • Dodaj nową wartość do listy.
    • Jeśli wartością jest 0xFF:
      • Potraktuj to jako tymczasową sesję parowania i nie wykonuj żadnej operacji.
      • Może się to zdarzyć w przypadku procesu Wsteczne zapisywanie klucza konta.
      • Nie przechowuj klucza i nie używaj go na liście kluczy konta, do szyfrowania ani do obliczeń MAC.
      • Usunięcie powiązania jest wywoływane przez zdarzenie specyficzne dla funkcji lub przekroczenie limitu czasu. W przypadku udostępniania dźwięku LE zdecydowanie zalecamy usunięcie powiązania BLE i klucza połączenia po 10 minutach od rozłączenia sesji tymczasowej.

Klucze kont na liście są używane podczas parowania opartego na kluczach.

Charakterystyka: Wersja oprogramowania

Ta cecha umożliwia urządzeniu wyszukującemu odczytywanie w razie potrzeby wersji oprogramowania urządzenia udostępniającego. Zawsze powinna zwracać te dane:

Oktet Typ danych Opis Wartość
0 – var utf8s Kod wersji oprogramowania układowego różni się

Nawet jeśli u dostawcy jest więcej niż 1 firmware (np. 3 firmware dla lewej słuchawki, prawej słuchawki i etui), powinien on być zamknięty w jednym ciągu znaków UTF-8. Dostawca może też zwracać konkretne ciągi znaków w przypadku specjalnych sytuacji:

  1. status-updating: jeśli dostawca aktualizuje obecnie oprogramowanie układowe do nowej wersji. Dostawca może też zwrócić wersję przygotowanego oprogramowania.

  2. status-abnormal: jeśli dostawca jest w stanie nieprawidłowym. Na przykład urządzenie nie działa prawidłowo, ponieważ nie udało się zaktualizować oprogramowania. Ta wartość spowoduje, że usługa Seeker wyświetli komunikat informujący użytkownika o konieczności natychmiastowej aktualizacji.

Dostawca powinien ograniczyć dostęp do charakterystyki wersji oprogramowania układowego, aby zapobiec śledzeniu urządzenia. Sugerowane ograniczenia:

  • sparowane urządzenia powinny mieć dostęp w dowolnym momencie;
  • każde urządzenie powinno mieć dostęp, gdy dostawca jest wykrywalny;

Cechy: dane dodatkowe

Ta usługa ma następującą cechę.

Charakterystyka usługi Szybkiego parowania Zaszyfrowane Uprawnienia UUID
Dane Nie Pisanie i powiadamianie FE2C1237-8366-4814-8EB0-01DE32100BEA
Stara charakterystyka usługi Szybkie parowanie (wycofana 1 stycznia 2021 r.) Zaszyfrowane Uprawnienia UUID
Dane Nie Pisanie i powiadamianie 0x1237

Przed zapisaniem lub powiadomieniem o tej charakterystyce musi nastąpić uzgadnianie połączenia za pomocą charakterystyki FE2C1234-8366-4814-8EB0-01DE32100BEA, aby uzyskać udostępnione hasło. Do szyfrowania danych przesyłanych przez tę charakterystykę będzie używany algorytm AES-CTR, którego definicja znajduje się poniżej. Ten tryb jest bezpieczniejszy w przypadku danych, które wykraczają poza pojedynczy 16-bajtowy blok. Do zapewnienia integralności danych będzie używany algorytm HMAC-SHA256, który również jest zdefiniowany poniżej.

Oktet Opis Wartość
czasami Pierwsze 8 bajtów HMAC-SHA256. różni się
8–15 Wartość nonce używana przez szyfrowanie AES-CTR. różni się
16 - var zaszyfrowane dane, różni się

Tabela 3.1. Pakiet danych wysyłany przez Dostawcę do Wyszukującego za pomocą powiadomienia lub wysyłany przez Wyszukującego do Dostawcy za pomocą zapisu.

Oktet Typ danych Opis Wartość
0 – var byte array Dane różni się, zdekoduj go zgodnie z identyfikatorem danych tabeli 1.2.2:
  • 0x01(spersonalizowana nazwa): utf8s

Tabela 3.2. Dane surowe. odszyfrowane z zaszyfrowanych danych w tabeli 3.1.

Gdy zostanie wysłana prośba o powiadomienie (np. prośba o spersonalizowaną nazwę za pomocą bitu 2 w tabeli 1.2.1), dostawca Fast Pair powinien wykonać te czynności:

  1. Wygeneruj 8 bajtów losowych danych kryptograficznych dla wartości Nonce.
  2. Szyfruj dane za pomocą AES-CTR, gdzie każdy 16-bajtowy blok jest generowany przy użyciu

    encryptedBlock[i] = clearBlock[i] ^ AES(key, concat((uint8) i, 0x00000000000000, nonce))
    

    gdzie

    1. Klucz AES to udostępnione hasło z kroku 4 w procedurze.
    2. clearBlock[i] to 16-bajtowy blok rozpoczynający się od data[i * 16]. Ostatni blok może mieć mniej niż 16 bajtów.
  3. Wykonaj funkcję concat(encryptedBlock[0], encryptedBlock[1],...), aby utworzyć zaszyfrowane dane.

  4. Wygeneruj HMAC-SHA256, wykonując te czynności:

    sha256(concat((K ^ opad), sha256(concat((K ^ ipad), concat(nonce, encrypted_data)))))
    

    gdzie

    1. K jest generowany przez concat(shared_secret, 48-byte ZEROs), a shared_secret pochodzi z kroku 4 w procedurze.
    2. opad to 64-bajtowe zewnętrzne dopełnienie składające się z powtarzających się bajtów o wartości 0x5C.
    3. Wewnętrzne dopełnienie w przypadku urządzenia iPad ma 64 bajty i składa się z powtarzających się bajtów o wartości 0x36.
  5. Pierwsze 8 bajtów z HMAC-SHA256 traktuj jako prefiks pakietu danych.

Po otrzymaniu żądania zapisu dostawca Szybkiego parowania powinien wykonać te czynności:

  1. Sprawdź integralność danych, weryfikując pierwsze 8 bajtów HMAC-SHA256.
  2. Odszyfruj zaszyfrowane dane za pomocą AES-CTR, gdzie każdy blok jest generowany przy użyciu

    clearBlock[i] = encryptedBlock[i] ^ AES(key, concat((uint8) i, 0x00000000000000, nonce))
    

    gdzie

    1. encryptedBlock[i] to 16-bajtowy blok rozpoczynający się od encrypted_data[i * 16]. Ostatni blok może mieć mniej niż 16 bajtów.
    2. Klucz AES jest generowany lub identyfikowany na podstawie uzgadniania połączenia, np.
      1. w procesie nadawania nazw 1 pochodzi z ECDH i nie będzie ponownie używana w tym parowaniu; Wszelkie żądania, które przychodzą zaszyfrowane tym kluczem bez ponownego uruchomienia procedury, powinny zostać odrzucone.
      2. w procesie nadawania nazw 2 jest to klucz konta.
  3. Wykonaj funkcję concat(clearBlock[0], clearBlock[1],...), aby utworzyć dane pierwotne.