Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Procédure d'association express
Procédure
Au lieu d'appeler immédiatement l'une des procédures d'association normales BR/EDR ou BLE, le Seeker active d'abord les notifications sur la caractéristique d'association basée sur des clés, puis y écrit les données du Tableau 1.1.
Lors du traitement d'une requête d'écriture d'un chercheur d'association express, le fournisseur d'Association express doit procéder comme suit:
Si le champ facultatif "Clé publique" est présent :
Si l'appareil n'est pas en mode association, ignorez l'écriture et la fermeture.
Sinon :
Utilisez la clé publique reçue (un point de 64 octets sur la courbe elliptique secp256r1), la clé privée anti-spoofing préinstallée (également secp256r1) et l'algorithme Diffie-Hellman à courbe elliptique pour générer une clé AES 256 bits.
Utilisez SHA-256 pour hacher la clé AES 256 bits.
Prenez les 128 premiers bits du résultat. Il s'agit de la clé AES anti-spoofing, utilisée à l'étape suivante.
À l'aide de l'algorithme AES-128, essayez de déchiffrer la valeur. Étant donné que la valeur est un bloc AES 16 octets unique, aucun mode de chiffrement par vecteur d'initialisation ou multibloc n'est nécessaire.
Quelle clé utiliser :
Si une clé AES anti-spoofing a été générée à l'étape 1, utilisez-la.
Sinon, essayez chaque clé de la liste persistante des clés de compte.
Si une clé parvient à déchiffrer la valeur, interrompre la lecture et passer à l'étape suivante.
La valeur est correctement déchiffrée si le résultat correspond au format du tableau 1.2.1 ou du tableau 1.2.2 (c'est-à-dire, si elle contient l'adresse BLE actuelle du fournisseur d'associations rapides ou l'adresse publique du fournisseur d'Association express).
REMARQUE: un salage est joint à la fin du paquet. Dans la mesure du possible, ces salages doivent être suivis et, si le fournisseur reçoit une requête contenant une valeur de salage déjà utilisée, la requête doit être ignorée pour éviter les attaques par rejeu.
Au lieu de suivre les salages, si l'écriture inclut l'adresse privée du fournisseur, un autre moyen d'empêcher les attaques par rejeu consiste à avancer l'heure de la prochaine rotation des adresses privées pouvant être résolues afin que la rotation ait lieu avant que la prochaine écriture d'association basée sur des clés ne soit acceptée.
Si aucune clé n'a pu déchiffrer la valeur, ignorez l'écriture et la fermeture.
Notez le nombre d'échecs. Lorsque le nombre d'échecs atteint 10, toutes les nouvelles requêtes échouent immédiatement. Réinitialisez le nombre d'échecs après cinq minutes, après mise sous tension ou après une opération réussie.
Sinon, enregistrez la clé réussie sous le nom K. Marquez ce K comme utilisable pour déchiffrer les écritures de clé d'accès et de nom personnalisé reçues sur ce lien LE, mais pas pour d'autres écritures ni pour aucune autre écriture sur aucun autre lien. Démarrez un minuteur à supprimer K au bout de 10 secondes si l'association n'a pas été lancée. Supprimez également K si ce lien LE se déconnecte.
Produisez la réponse brute de 16 octets présentée dans le Tableau 1.3, en concaténant le type et l'adresse BR/EDR du fournisseur, puis en remplissant le reste du paquet avec un bloc d'octets aléatoires (c'est-à-dire un salage).
Chiffrez la réponse brute avec K pour générer la réponse chiffrée de 16 octets présentée dans le tableau 1.4. Envoyez cette information via une notification sur la caractéristique de l'association basée sur des clés.
Lisez l'indicateur de requête:
Si le bit 2 est défini sur 1 pour l'octet d'indicateurs de la requête, envoyez une notification à la caractéristique de données supplémentaires en indiquant un nom personnalisé.
Si le bit 1 est défini sur 1 pour l'octet d'indicateurs de la requête:
Cela indique que le demandeur demande au fournisseur d'initier la liaison à l'adresse BR/EDR du demandeur, qui est présente dans les octets 8 à 13.
Envoyez une demande d'association à l'adresse BR/EDR du chercheur. La demande d'association doit être décrite ci-dessous (étape "Pendant l'association").
Pourquoi cela est nécessaire: le fait de demander au fournisseur de se lancer permet de résoudre un problème sur certains appareils.
Si le bit 1 est défini sur 0 pour l'octet d'indicateurs de la requête:
Attendez jusqu'à 10 secondes pour recevoir une demande d'association. Si vous n'en recevez aucune, quittez.
Notez qu'il peut s'agir d'une requête BR/EDR, provenant d'une adresse différente (l'adresse publique du demandeur, et non son adresse privée pouvant être résolue).
Nous vérifierons à nouveau lors de l'association que l'appareil à l'origine de la demande est en possession de K.
Pendant l'association:
Lorsqu'un paquet de requête/réponse d'association est reçu du demandeur : si les fonctionnalités de l'appareil de la requête sont NoInput/NoOutput, terminez l'association afin d'éviter d'utiliser la méthode d'association Just Works.
Pour le paquet de requête/réponse d'association envoyé par le fournisseur: définissez le champ "Device Capabilities" (Capacités de l'appareil) sur Display/YesNo (Affichage/YesNo), et les exigences d'authentification sur MITM Protection Required (Protection MITM requise). Cela déclenche la méthode d'association par comparaison numérique (également appelée confirmation de clé d'accès sur Android).
Nous nous appuyons sur ces informations pour confirmer que l'appareil à l'origine de la demande est bien le chercheur Association express et qu'il n'y a pas d'homme du milieu. Consultez des exemples.
La raison est la suivante: la méthode d'association externe est mieux adaptée, mais la plate-forme ne l'expose pas sur toutes les versions d'Android souhaitées.
Lorsque la confirmation de la clé d'accès est nécessaire, attendez jusqu'à 10 secondes pour qu'une écriture dans la caractéristique de clé d'accès soit nécessaire.
Normalement, avec cette méthode d'association, l'utilisateur confirme que les clés d'accès affichées sur l'écran de chaque appareil sont identiques. À la place, nous les transférons via BLE, et chiffrées à l'aide de la clé pré-partagée de confiance, uniquement pour cette association.
Notez que cette approche ne doit pas être adoptée pour les appareils dotés d'un écran ou d'un clavier, car elle présente un léger compromis sur la protection MITM.
Pour le moment, l'Association express n'est pas compatible avec ces types d'appareils.
Si le délai de 10 secondes expire sans qu'aucune clé d'accès ne soit écrite, supprimez K.
Lorsqu'une valeur est écrite dans la caractéristique de clé d'accès, il s'agit du bloc de clé d'accès chiffré. Déchiffrez-la avec K pour obtenir un bloc de clé d'accès brut, dont le format est indiqué dans Characteristic: Clé d'accès>Tableau 2.2 (type = Clé d'accès du chercheur).
Si le déchiffrement échoue, ignorez l'écriture et supprimez K.
Sinon, le bloc de clé d'accès brut contient une clé d'accès à six chiffres PSeeker, qui est la clé d'accès attendue par le chercheur.
Comparez PSeeker avec notre propre clé d'accès attendue, PProvider.
Si les valeurs sont égales, répondez "oui" à la confirmation.
Sinon, répondez "non" à l'invite de confirmation, ce qui entraîne l'échec de l'association.
Que l'association ait échoué ou non, générez un autre bloc de clé d'accès brut, avec le format indiqué dans Characteristic: Passkey>Tableau 2.2, contenant notre propre clé d'accès attendue, PProvider.
Vérifiez que le type de bloc est correct (clé d'accès du fournisseur ; voir le tableau).
REMARQUE: Ne réutilisez pas le salage du bloc de clé d'accès reçu du demandeur. Générez une nouvelle valeur aléatoire.
Chiffrez le bloc de clé d'accès brut avec K et envoyez le bloc de clé d'accès chiffré obtenu via une notification sur la caractéristique de clé d'accès.
S'il reçoit et déchiffre la clé d'accès P appropriée, il répond également "oui" à la confirmation, et l'association aboutit.
Si l'association réussit, marquez K comme utilisable pour déchiffrer les écritures de la clé de compte sur ce lien LE, mais pas pour toute écriture ultérieure de clé d'accès ni aucune autre écriture sur un autre lien. Démarrez un minuteur pour supprimer K au bout de 10 secondes. Supprimez également K après toute tentative d'écriture d'une clé de compte et, conformément à l'étape 4, si le lien LE se déconnecte.
Si l'association échoue, supprimez la touche K.
Redéfinissez le champ "Fonctionnalités de l'appareil" sur les fonctionnalités d'E/S par défaut et rétablissez la valeur par défaut "Exigences d'authentification" pour que les nouvelles associations se poursuivent comme prévu.
Notez que pour les fournisseurs qui ne nécessitent pas d'association, le demandeur n'envoie pas de requête d'association au fournisseur. Les étapes 8 à 17 sont ignorées. En outre, "K" est utilisé dans la caractéristique de clé de compte.
Exemples
Exemple 1:Tentative d'association réussie (pas de "man-in-the-middle").Exemple 2:Échec de la tentative d'association, avec un homme du milieu
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/08/13 (UTC).
[null,null,["Dernière mise à jour le 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.*"]]
