Zadbaj o dobrą organizację dzięki kolekcji
Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.
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.
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
Przykład 1. Udana próba parowania (bez modelu „man in the middle”).Przykład 2. Próba sparowania z udziałem człowieka „man in the middle” nie powiodła się.
[null,null,["Ostatnia aktualizacja: 2025-08-13 UTC."],[[["\u003cp\u003eFast Pair utilizes BLE for initial key exchange and then triggers BR/EDR pairing for secure connection.\u003c/p\u003e\n"],["\u003cp\u003eThe Provider verifies the Seeker's authenticity using encryption, a shared secret, and a numeric comparison pairing method.\u003c/p\u003e\n"],["\u003cp\u003eAccount Keys are exchanged securely after successful pairing to enable seamless future connections.\u003c/p\u003e\n"],["\u003cp\u003eThe process includes anti-spoofing measures like public key cryptography and salt tracking to enhance security.\u003c/p\u003e\n"],["\u003cp\u003eThe Provider initiates the BR/EDR pairing to address compatibility issues with certain devices.\u003c/p\u003e\n"]]],[],null,["Fast Pair Procedure\n-------------------\n\n### Procedure\n\n| **Note:** Google recommends implementing the [Cryptographic Test Cases](/nearby/fast-pair/specifications/appendix/cryptotestcases \"Link to the Cryptographic Test Cases.\") to ease verification of these requirements.\n\nInstead of immediately invoking any of the normal BR/EDR or BLE bonding\nprocedures, the Seeker first enables Notifications on the Key-based Pairing\ncharacteristic, and then writes the data in [Table 1.1](/nearby/fast-pair/specifications/characteristics#table1.1 \"table 1.1\") to it.\n\nWhen handling a write request from a Fast Pair Seeker, the Fast Pair Provider\nshall do the following:\n\n1. If the optional Public Key field **is present** :\n 1. If the device is not in pairing mode, ignore the write and exit.\n 2. Otherwise:\n 1. Use the received Public Key (a 64-byte point on the secp256r1 elliptic curve), the pre-installed [Anti-Spoofing Private Key](/nearby/fast-pair/specifications/configuration#antispoofing \"Anti-Spoofing\") - also secp256r1, and the Elliptic-Curve Diffie-Hellman algorithm to generate a 256-bit AES key.\n 2. Use SHA-256 to hash the 256-bit AES key.\n 3. Take the first 128 bits of the result. This is the Anti-Spoofing AES Key, used in the next step.\n2. Using AES-128, attempt to decrypt the value. Since the value is a single\n 16-byte AES block, no IV or multi-block cipher mode is necessary.\n\n 1. Which key to use:\n 1. If an Anti-Spoofing AES Key was generated in step 1, use that key.\n 2. Otherwise, try each key in the persisted Account Key List.\n 2. If a key successfully decrypts the value, break, and continue to the next step.\n 3. The value is decrypted successfully if the output matches the format in\n [Table 1.2.1](/nearby/fast-pair/specifications/characteristics#table1.2.1 \"table 1.2.1\") or [Table 1.2.2](/nearby/fast-pair/specifications/characteristics#table1.2.2 \"table 1.2.2\") - (that is, if it\n contains either the Fast Pair Provider's current BLE address, or the Fast\n Pair Provider's public address).\n\n NOTE: At the end of the packet there is a salt attached. When\n possible, these salts should be tracked, and if the Provider receives a\n request containing an already used salt, the request should be ignored to\n prevent replay attacks.\n 4. As an alternative to tracking salts, if the write includes the Provider's\n private address, another way to prevent replay attacks is to bring\n forward the time of the next resolvable private address rotation so that\n the rotation occurs before the next Key-based Pairing write will be\n accepted.\n\n3. If no key could successfully decrypt the value, ignore the write and exit.\n\n 1. Keep a count of these failures. **When the failure count hits 10, fail\n all new requests immediately. Reset the failure count after 5 minutes,\n after power on, or after a success.**\n4. Otherwise, save the successful key as *K* . Mark this *K* as usable for\n decrypting Passkey and Personalized name writes received on this LE link, but\n not other writes nor any writes on any other link. Start a timer to discard\n *K* after 10 seconds if pairing has not been started. Also discard *K* if\n this LE link disconnects.\n\n5. Produce the 16-byte Raw Response shown in [Table 1.3](/nearby/fast-pair/specifications/characteristics#table1.3 \"table 1.3\"), by\n concatenating the type and the Provider's BR/EDR address, and then filling\n the remainder of the packet with a block of random bytes (that is, a salt).\n\n6. Encrypt the Raw Response with K to produce the 16-byte Encrypted Response\n shown in [Table 1.4](/nearby/fast-pair/specifications/characteristics#table1.4 \"table 1.4\"). Send this via a notify on the Key-based Pairing\n characteristic.\n\n7. Read the request flag:\n\n 1. **If the Request's Flags byte has bit 2 set to 1** , notify [Additional Data characteristic](/nearby/fast-pair/specifications/characteristics#AdditionalData \"Characteristic - Additional Data\") with personalized name.\n 2. **If the Request's Flags byte has bit 1 set to 1:**\n 1. This indicates that the Seeker is requesting the Provider to initiate bonding to the Seeker's BR/EDR address, which is present in bytes 8-13.\n 2. Send a pairing request to the Seeker's BR/EDR address. The pairing request must be as described below (\"During pairing\" step).\n 3. Reason this is needed: Having the Provider initiate works around an issue on some devices.\n 3. **If the Request's Flags byte has bit 1 set to 0:**\n 1. Wait up to 10 seconds for a pairing request. If none is received, exit.\n 2. Note that this might be a BR/EDR request, from a different address (the Seeker's public address, instead of its resolvable private address). We will re-verify during pairing that the requesting device is in possession of *K*.\n8. During pairing:\n\n 1. When a **pairing request/response packet** is received from the Seeker: If the Device Capabilities in the request are NoInput/NoOutput, end pairing, to avoid using the Just Works pairing method.\n 2. For the pairing request/response packet sent by the Provider: Set the Device Capabilities field to **Display/YesNo** and set Authentication Requirements to **MITM Protection Required** . This triggers the Numeric Comparison pairing method (also known as [Passkey Confirmation](https://developer.android.com/reference/android/bluetooth/BluetoothDevice.html#PAIRING_VARIANT_PASSKEY_CONFIRMATION) on Android). We rely on this to confirm that the requesting device is in fact the Fast Pair Seeker, and that there is no man-in-the-middle. See [examples](#ProcedureExamples).\n 3. Reason this is needed: The Out-of-Band pairing method would be a better fit, but the platform does not expose it on all desired versions of Android.\n9. When **confirmation of the passkey is needed** , wait up to 10 seconds for a\n write to the [Passkey characteristic](/nearby/fast-pair/specifications/characteristics#Passkey \"passkey\").\n\n 1. Normally, with this pairing method, the user would confirm that the passkeys displayed on each device's screen are identical. Instead, only for this pairing, we transfer them over BLE, encrypted with the trusted pre-shared key.\n 2. Note that this approach should not be taken for devices that have a screen or a keyboard as it makes a slight compromise on MITM protection. Fast Pair currently does not support those device types yet because of this.\n 3. If the 10 second timer expires without a passkey being written, then discard *K*.\n10. When a **value is written to the Passkey characteristic** , this is the\n Encrypted Passkey Block. Decrypt it with K to yield a Raw Passkey Block, with\n format shown in [Characteristic: Passkey](/nearby/fast-pair/specifications/characteristics#Passkey \"passkey\") *\\\u003e* [Table 2.2](/nearby/fast-pair/specifications/characteristics#table2.2 \"table 2.2\") - (type =\n Seeker's Passkey).\n\n11. If decryption fails, ignore the write and discard *K*.\n\n12. Otherwise, the Raw Passkey Block contains a 6-digit passkey\n *P~Seeker~*, which is the passkey that the Seeker expects.\n\n13. Compare *P~Seeker~* with our own expected passkey,\n *P~Provider~*.\n\n 1. If the values are equal, reply \"yes\" to the confirmation.\n 2. Otherwise, reply \"no\" to the confirmation, causing pairing to fail.\n14. Regardless of whether pairing failed, produce another Raw Passkey Block, with\n format shown in [Characteristic: Passkey](/nearby/fast-pair/specifications/characteristics#Passkey \"passkey\") *\\\u003e* [Table 2.2](/nearby/fast-pair/specifications/characteristics#table2.2 \"table 2.2\"),\n containing our own expected passkey, *P~Provider~*.\n\n 1. Ensure the block has the correct type (Provider's Passkey; see table). NOTE: Do not reuse the salt from the Passkey Block received from the Seeker. Generate a new random value.\n15. Encrypt the Raw Passkey Block with *K*, and send the resulting Encrypted\n Passkey Block via a notify on the Passkey characteristic.\n\n16. If the Seeker receives and decrypts the correct passkey *P*, the Seeker will\n also reply \"yes\" to the confirmation, and pairing will succeed.\n\n 1. If the pairing succeeds, then mark *K* as usable for decrypting Account Key writes on this LE link, but not for any subsequent Passkey writes nor any writes on any other link. Start a timer to discard *K* after 10 seconds. Also discard *K* following any attempt to write an Account Key and, as per step 4, if the LE link disconnects.\n 2. If the pairing fails, discard *K*.\n17. Switch the device capabilities field back to default I/O capabilities and\n Authentication Requirements to default so that new\n pairings continue as expected.\n\nNote that for Providers that don't require bonding, the Seeker does not send a\npairing request to the Provider, that is step 8 - step 17 are skipped. Also,\n\"K\" is used in [Account Key characteristic](/nearby/fast-pair/specifications/characteristics#AccountKey \"Account Key\").\n\n##### Examples\n\n***Example 1:** Successful pairing attempt\n(no man-in-the-middle).* ***Example 2:** Failed pairing attempt, with a\nman-in-the-middle.*"]]
