Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Procedura di accoppiamento rapido
Procedura
Anziché richiamare immediatamente una qualsiasi delle normali procedure di collegamento BR/EDR o BLE, il richiedente attiva prima le notifiche sulla caratteristica di accoppiamento basato su chiavi, quindi vi scrive i dati della Tabella 1.1.
Durante la gestione di una richiesta di scrittura da parte di un utente che cerca l'accoppiamento rapido, il provider dell'accoppiamento rapido deve:
Se il campo facoltativo Chiave pubblica è presente:
Se il dispositivo non è in modalità di associazione, ignora la scrittura e esci.
In caso contrario:
Utilizza la chiave pubblica ricevuta (un punto di 64 byte sulla curva ellittica secp256r1), la chiave privata anti-spoofing preinstallata, anch'essa secp256r1, e l'algoritmo Diffie-Hellman a curva ellittica per generare una chiave AES a 256 bit.
Utilizza SHA-256 per eseguire l'hashing della chiave AES a 256 bit.
Prendi i primi 128 bit del risultato. Questa è la chiave AES
anti-spoofing, utilizzata nel passaggio successivo.
Utilizzando AES-128, prova a decriptare il valore. Poiché il valore è un singolo
blocco AES a 16 byte, non è necessaria alcuna modalità di crittografia IV o multi-blocco.
Quale chiave usare:
Se nel passaggio 1 è stata generata una chiave AES anti-spoofing, utilizza questa chiave.
In caso contrario, prova con ciascuna chiave nell'elenco permanente delle chiavi dell'account.
Se una chiave decripta il valore, si interrompe e continua con il passaggio successivo.
Il valore viene decriptato correttamente se l'output corrisponde al formato indicato nella Tabella 1.2.1 o nella Tabella 1.2.2, ovvero se contiene l'indirizzo BLE corrente del provider di accoppiamento rapido o l'indirizzo pubblico del provider di accoppiamento rapido.
NOTA: alla fine della confezione c'è attaccato un sale. Ove possibile, questi sali devono essere monitorati e, se il provider riceve una richiesta contenente un sale già utilizzato, la richiesta deve essere ignorata per evitare attacchi di ripetizione.
In alternativa al monitoraggio dei sali, se la scrittura include l'indirizzo privato del provider, un altro modo per prevenire gli attacchi di ripetizione è anticipare la data e l'ora della successiva rotazione dell'indirizzo privato risolvibile, in modo che la rotazione avvenga prima che venga accettata la successiva scrittura di accoppiamento basato su chiavi.
Se nessuna chiave è in grado di decriptare il valore, ignora la scrittura e l'uscita.
Tieni traccia di questi errori. Quando il numero di errori raggiunge 10, non soddisfare immediatamente tutte le nuove richieste. Ripristina il conteggio degli errori dopo 5 minuti, dopo l'accensione o l'esito positivo.
In caso contrario, salva la chiave riuscita come K. Contrassegna questa K come utilizzabile per decriptare le scritture di passkey e nomi personalizzati ricevute su questo link LE, ma non altre scritture o scritture su altri link. Avvia un timer per eliminare
K dopo 10 secondi se l'accoppiamento non è stato avviato. Ignora anche K se questo link LE si disconnette.
Produci la risposta non elaborata da 16 byte mostrata nella Tabella 1.3 concatenando il tipo e l'indirizzo BR/EDR del provider, quindi riempiendo il resto del pacchetto con un blocco di byte casuali (ossia un sale).
Cripta la risposta non elaborata con K per produrre la risposta criptata a 16 byte mostrata nella Tabella 1.4. Invialo tramite una notifica sulla caratteristica Accoppiamento basato su chiave.
Leggi il flag della richiesta:
Se il byte dei flag della richiesta ha il bit 2 impostato su 1, invia una notifica alla caratteristica dei dati aggiuntivi con un nome personalizzato.
Se il byte dei flag della richiesta ha il bit 1 impostato su 1:
Ciò indica che il Cercatore richiede al provider di avviare il collegamento all'indirizzo BR/EDR del richiedente, che è presente nei byte 8-13.
Invia una richiesta di associazione all'indirizzo BR/EDR del Cercante. La richiesta
di accoppiamento deve essere descritta di seguito (passaggio "Durante l'accoppiamento").
Motivo della necessità: chiedere al provider di avviare risolve un problema su alcuni dispositivi.
Se il byte dei flag della richiesta ha il bit 1 impostato su 0:
Attendi fino a 10 secondi per la richiesta di accoppiamento. Se non ne viene ricevuto nessuno, esci.
Tieni presente che potrebbe essere una richiesta BR/EDR, proveniente da un indirizzo diverso
(l'indirizzo pubblico del Cercante anziché il suo indirizzo privato risolvibile).
Verificheremo di nuovo durante l'accoppiamento che il dispositivo richiedente sia in possesso di K.
Durante l'accoppiamento:
Quando il cercatore riceve un pacchetto di richiesta/risposta di accoppiamento:
Se le Funzionalità del dispositivo nella richiesta sono NoInput/NoOutput, termina l'accoppiamento per evitare di utilizzare il metodo di accoppiamento Just Works.
Per il pacchetto di richiesta/risposta di accoppiamento inviato dal provider: imposta il campo
Device Capabilities su Display/YesNo e imposta i requisiti di autenticazione su
Protezione MITM richiesta. In questo modo viene attivato il metodo di accoppiamento numerico (noto anche come conferma della passkey su Android).
Ci basiamo su questi dati per confermare che il dispositivo richiedente sia effettivamente il Ricercatore
di accoppiamento rapido e che non esista un man-in-the-middle. Visualizza alcuni esempi.
Motivo della necessità: il metodo di accoppiamento Out-of-Band sarebbe più adatto, ma la piattaforma non lo espone a tutte le versioni di Android desiderate.
Quando è necessaria la conferma della passkey, attendi fino a 10 secondi per la
scrittura della caratteristica della passkey.
Normalmente, con questo metodo di accoppiamento, l'utente conferma che le passkey visualizzate sullo schermo di ogni dispositivo sono identiche. Solo per questo accoppiamento li trasferiamo tramite BLE, criptati con la chiave precondivisa attendibile.
Tieni presente che questo approccio non deve essere adottato per i dispositivi dotati di
schermo o tastiera, in quanto compromette leggermente la protezione MITM.
Al momento l'accoppiamento rapido non supporta ancora questi tipi di dispositivi per questo motivo.
Se il timer di 10 secondi scade senza che sia stata scritta una passkey, ignora K.
Quando un valore viene scritto nella caratteristica della passkey, questo è il blocco della passkey criptata. Decriptala con K per generare un blocco passkey non elaborato, il cui formato è mostrato in Caratteristica: passkey>Tabella 2.2 - (tipo =
Passkey del cercatore).
Se la decrittografia non va a buon fine, ignora la scrittura e ignora K.
In caso contrario, il Raw Passkey Block contiene una passkey di 6 cifre PSeeker, ovvero la passkey che si aspetta.
Confronta PSeeker con la nostra passkey prevista,
PProvider.
Se i valori sono uguali, rispondi "yes" alla conferma.
In caso contrario, rispondi "no" alla conferma, causando il mancato accoppiamento.
Indipendentemente dal fatto che l'accoppiamento non sia riuscito, produci un altro blocco di passkey non elaborato, con il formato mostrato in Caratteristica: passkey>Tabella 2.2, contenente la nostra passkey prevista, PProvider.
Assicurati che il tipo del blocco sia corretto (passkey del provider, vedi tabella).
NOTA: non riutilizzare il sale del Blocco passkey ricevuto dal
Ricercatore. Genera un nuovo valore casuale.
Cripta il blocco di passkey non elaborato con K e invia il risultante blocco di passkey criptata tramite una notifica sulla caratteristica della passkey.
Se il cercatore riceve e decripta la passkey P corretta, risponderà "sì" alla conferma e l'accoppiamento andrà a buon fine.
Se l'accoppiamento va a buon fine, contrassegna K come utilizzabile per decriptare le scritture della chiave dell'account su questo link LE, ma non per le scritture successive o le scritture di passkey su altri link. Avvia un timer per eliminare K dopo 10
secondi. Elimina anche il simbolo K dopo qualsiasi tentativo di scrittura di una chiave dell'account e, come indicato nel passaggio 4, se il link LE si disconnette.
Se l'accoppiamento non va a buon fine, elimina K.
Ripristina il campo delle capacità del dispositivo sulle funzionalità I/O predefinite e i requisiti di autenticazione sui valori predefiniti in modo che i nuovi accoppiamenti continuino come previsto.
Tieni presente che, per i provider che non richiedono il bonding, il richiedente non invia una richiesta di accoppiamento al provider, ovvero i passaggi dai passaggi 8 e 17 vengono ignorati. Inoltre,
"K" viene utilizzato nella caratteristica della chiave dell'account.
Esempi
Esempio 1: tentativo di accoppiamento riuscito
(nessun man in the middle).Esempio 2: tentativo di accoppiamento non riuscito, con
un man in the middle.
[null,null,["Ultimo aggiornamento 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.*"]]