Procedura szybkiego parowania
Procedura
Zamiast natychmiast wywoływać standardowe procedury wiązania BR/EDR lub BLE, aplikacja Seeker najpierw włącza powiadomienia o charakterze parowania opartego na kluczu, a potem zapisuje w niej dane z tabeli 1.1.
Podczas obsługi żądania zapisu z funkcji poszukiwacza Szybkiego parowania dostawca Szybkiego parowania musi wykonać te czynności:
- Jeśli opcjonalne pole Klucz publiczny jest dostępne:
- Jeśli urządzenie nie jest w trybie parowania, zignoruj zapis i zamknij.
- W przeciwnym razie:
- Użyj otrzymanego klucza publicznego (64-bajtowego punktu na krzywej eliptycznej secp256r1), zainstalowanego klucza prywatnego przed podszywaniem się (również secp256r1) oraz algorytmu eliptycznego krzywej Diffiego-Hellmana, aby wygenerować 256-bitowy klucz AES.
- Za pomocą algorytmu SHA-256 zaszyfruj 256-bitowy klucz AES.
- Pobierz pierwsze 128 bitów wyniku. Jest to klucz AES Anti-Spoofing, który zostanie użyty w następnym kroku.
Spróbuj odszyfrować wartość za pomocą AES-128. Wartość to pojedynczy 16-bajtowy blok AES, więc nie jest potrzebny tryb IV ani wieloblokowy szyfr.
- Jakiego klucza użyć:
- Jeśli w kroku 1 został wygenerowany klucz AES zapobiegający podszywaniu się, użyj go.
- W przeciwnym razie wypróbuj każdy klucz na stałej liście kluczy konta.
- Jeśli klucz odszyfrowuje wartość, złam i przejdź do następnego kroku.
Wartość zostanie odszyfrowana, jeśli dane wyjściowe są zgodne z formatem określonym w tabeli 1.2.1 lub tabeli 1.2.2 (czyli jeśli zawiera ona aktualny adres BLE dostawcy Szybkiego parowania lub adres publiczny dostawcy Szybkiego parowania).
UWAGA: Na końcu opakowania jest dołączona sól. Gdy to możliwe, należy śledzić te ciągi zaburzające, a jeśli dostawca otrzyma żądanie zawierające już wykorzystywaną sól, należy je zignorować, aby zapobiec atakom metodą powtórzenia.
Alternatywą dla ciągu zaburzającego śledzenie, jeśli zapis obejmuje prywatny adres dostawcy, innym sposobem zapobiegania atakom typu replay jest skrócenie czasu kolejnej rotacji adresu prywatnego, tak aby rotacja miała miejsce przed następnym zapisem związanym z parowaniem opartym na kluczu.
- Jakiego klucza użyć:
Jeśli żaden klucz nie mógł odszyfrować wartości, zignoruj zapis i zamknij.
- Zapisuj liczbę tych błędów. Gdy liczba błędów osiągnie 10, wszystkie nowe żądania natychmiast zostaną odrzucone. Zresetuj licznik błędów po 5 minutach, po włączeniu lub po pomyślnym zakończeniu.
W przeciwnym razie zapisz poprawny klucz jako K. Oznacz ten K jako użyteczny do odszyfrowywania zapisów klucza dostępu i spersonalizowanej nazwy otrzymanych za pomocą tego linku LE, ale nie do innych zapisów ani żadnych zapisów w innych linkach. Jeśli parowanie się nie rozpoczęło, uruchom licznik czasu, który po 10 sekundach odrzuci K. Jeśli to połączenie LE zostanie rozłączone, odrzuć też K.
Utwórz 16-bajtową nieprzetworzoną odpowiedź widoczną w tabeli 1.3, łącząc typ i adres BR/EDR dostawcy, a następnie wypełniając pozostałą część pakietu blokiem losowych bajtów (czyli solą).
Zaszyfruj nieprzetworzoną odpowiedź za pomocą klucza K, aby wygenerować 16-bajtową zaszyfrowaną odpowiedź przedstawioną w tabeli 1.4. Wyślij go za pomocą powiadomienia na temat pary klucz-wartość.
Przeczytaj flagę żądania:
- Jeśli bajt flag żądania ma bit 2 ustawiony na 1, wyślij powiadomienie o charakterze danych dodatkowych z indywidualną nazwą.
- Jeśli bajt flag żądania ma bit 1 ustawiony na 1:
- Oznacza to, że poszukiwacz prosi dostawcy o zainicjowanie powiązania z adresem BR/EDR osoby poszukiwającej, która jest podana w bajtach 8–13.
- Wyślij prośbę o sparowanie na adres BR/EDR Seeker. Żądanie parowania musi być zgodne z opisem poniżej („Podczas parowania”).
- Powód, dla którego jest to konieczne: zlecając Dostawcy czynności, można rozwiązać problem na niektórych urządzeniach.
- Jeśli bajt flag żądania ma bit 1 ustawiony na 0:
- Odczekaj 10 sekund na prośbę o sparowanie. Jeśli nie otrzymasz żadnej wiadomości, wyjdź.
- Pamiętaj, że może to być żądanie BR/EDR wysłane z innego adresu (publicznego adresu osoby poszukiwającej, a nie jej możliwego adresu prywatnego). Podczas parowania ponownie sprawdzimy, czy urządzenie, które wysyła żądanie, jest w posiadaniu K.
Podczas parowania:
- Po otrzymaniu od poszukiwacza pakietu żądania/odpowiedzi sparowania: jeśli funkcje urządzenia w żądaniu to NoInput/NoExit, zakończ parowanie, aby uniknąć używania metody parowania Just Works.
- W przypadku żądania parowania/pakietu odpowiedzi wysłanego przez dostawcę: w polu „Możliwości urządzenia” ustaw Display/YesNo, a w polu Authentication (Wymagania dotyczące uwierzytelniania) wybierz MITM Protection Protection (Wymagana ochrona MITM). Powoduje to aktywowanie metody parowania liczbowego (nazywanego potwierdzeniem klucza dostępu w Androidzie). Na podstawie tych informacji potwierdzamy, że urządzenie wysyłające żądanie to rzeczywiście poszukiwacz szybkiego parowania i że nie ma żadnego człowieka w środku. Zobacz przykłady.
- Powód, dla którego jest to konieczne: metoda parowania poza zakresem byłaby lepsza, ale platforma nie udostępnia jej we wszystkich pożądanych wersjach Androida.
Gdy wymagane jest potwierdzenie klucza dostępu, poczekaj maksymalnie 10 sekund na zapisanie w charakterze klucza dostępu.
- Zwykle w przypadku tej metody parowania użytkownik potwierdza, że klucze dostępu wyświetlane na ekranie każdego urządzenia są identyczne. Tylko do tego parowania przenosimy je przez BLE, szyfrowane za pomocą zaufanego klucza wstępnego.
- Pamiętaj, że nie należy stosować tej metody w przypadku urządzeń z ekranem lub klawiaturą, ponieważ w nieznacznym stopniu wpływa to na ochronę MITM. Z tego powodu Szybkie parowanie nie obsługuje obecnie urządzeń tego typu.
- Jeśli 10-sekundowy czas wygaśnie bez zapisywania klucza dostępu, odrzuć K.
Gdy wartość zostanie zapisana w charakterze klucza dostępu, będzie to blokada zaszyfrowanego klucza dostępu. Odszyfruj go za pomocą K, aby uzyskać blok z nieprzetworzonym kluczem dostępu w formacie pokazanym w sekcji Charakterystyka: klucz dostępu > Tabela 2.2 (typ = Klucz dostępu Seeker).
Jeśli odszyfrowanie się nie uda, zignoruj zapis i odrzuć K.
W przeciwnym razie blok Raw Passkey zawiera 6-cyfrowy klucz dostępu PSeeker, czyli oczekiwanego klucza dostępu.
Porównaj usługę PSeeker z naszym własnym oczekiwanym kluczem dostępu – PProvider.
- Jeśli wartości są równe, odpowiedz „yes” na potwierdzenie.
- W przeciwnym razie odpowiedz „nie” na potwierdzenie, co spowoduje błąd parowania.
Niezależnie od tego, czy parowanie się nie udało, utwórz kolejny blok nieprzetworzonego klucza dostępu z formatem podanym w polu Charakterystyka: klucz dostępu > Tabela 2.2, zawierający nasz własny oczekiwany klucz dostępu – PProvider.
- Upewnij się, że blok ma prawidłowy typ (klucz dostawcy; patrz tabela). UWAGA: nie używaj ponownie soli z bloku klucza dostępu otrzymanego od Seeker. Wygeneruj nową losową wartość.
Zaszyfruj blokadę nieprzetworzonego klucza dostępu za pomocą K i wyślij wynikową blokadę zaszyfrowanego klucza dostępu za pomocą powiadomienia w charakterze klucza dostępu.
Jeśli poszukiwacz otrzyma i odszyfruje prawidłowy klucz P, odpowie też „tak” na potwierdzenie, a parowanie się powiedzie.
- Jeśli parowanie się powiedzie, oznacz K jako możliwość użycia do odszyfrowywania klucza konta za pomocą tego linku LE, ale nie przy kolejnych operacjach zapisu klucza dostępu ani żadnych innych operacji zapisu w innym linku. Uruchom licznik czasu, który po 10 sekundach odrzuci K. Po każdej próbie zapisania klucza konta odrzuć też K, a jeśli połączenie LE zostanie przerwane (jak w kroku 4).
- Jeśli parowanie się nie uda, odrzuć K.
Aby nowe pary działały zgodnie z oczekiwaniami, w polu możliwości urządzenia ustaw domyślne funkcje wejścia-wyjścia i wymagania dotyczące uwierzytelniania.
Pamiętaj, że w przypadku dostawców, którzy nie wymagają wiązania, Seeker nie wysyła żądania parowania do dostawcy, co oznacza krok 8 – krok 17. Wartość „K” jest też używana w polu Kluczowa cecha konta.
Przykłady
