Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
Procedimiento de Vinculación rápida
Procedimiento
En lugar de invocar inmediatamente cualquiera de los procedimientos normales de vinculación BR/EDR o BLE, el buscador primero habilita las notificaciones en la característica de vinculación basada en claves y, luego, escribe en él los datos de la Tabla 1.1.
Cuando maneje una solicitud de escritura de un buscador de vinculación rápida, el proveedor de vinculación rápida hará lo siguiente:
Si el campo opcional Clave pública está presente, haz lo siguiente:
Si el dispositivo no está en modo de vinculación, ignora la escritura y sal.
De lo contrario, sigue estos pasos:
Usa la clave pública recibida (un punto de 64 bytes en la curva elíptica secp256r1), la clave privada contra falsificación de identidad preinstalada (también secp256r1) y el algoritmo de curva elíptica Diffie-Hellman para generar una clave AES de 256 bits.
Usa SHA-256 para aplicar un hash a la clave AES de 256 bits.
Toma los primeros 128 bits del resultado. Esta es la clave AES antifalsificación, que se usará en el siguiente paso.
Usa AES-128 para intentar desencriptar el valor. Dado que el valor es un bloque de AES único de 16 bytes, no se necesita un modo de cifrado IV o de varios bloques.
Qué clave usar:
Si se generó una clave AES contra la falsificación de identidad en el paso 1, úsala.
De lo contrario, prueba cada clave de la Lista de claves de la cuenta guardada.
Si una clave desencripta correctamente el valor, deja de hacerlo y continúa con el siguiente paso.
El valor se desencripta correctamente si el resultado coincide con el formato de la Tabla 1.2.1 o la Tabla 1.2.2 (es decir, si contiene la dirección BLE actual del proveedor de Vinculación rápida o la dirección pública del proveedor de Vinculación rápida).
NOTA: Al final del paquete, hay una sal adjunta. Cuando sea posible, se debe realizar un seguimiento de estas sales y, si el proveedor recibe una solicitud que contiene una sal ya usada, se debe ignorar la solicitud para evitar ataques de repetición.
Como alternativa al seguimiento de las sales, si la escritura incluye la dirección privada del proveedor, otra manera de evitar los ataques de repetición es adelantar la hora de la siguiente rotación de la dirección privada que se puede resolver para que la rotación ocurra antes de que se acepte la siguiente escritura de vinculación basada en claves.
Si ninguna clave pudo desencriptar correctamente el valor, ignora la escritura y la salida.
Lleva un recuento de estas fallas. Cuando el recuento de errores llega a 10, fallan todas las solicitudes nuevas de inmediato. Restablece el recuento de fallas después de 5 minutos, después de encender el dispositivo o después de una ejecución correcta.
De lo contrario, guarda la clave exitosa como K. Marca esta K como utilizable para desencriptar llaves de acceso y escrituras de nombres personalizados recibidas en este vínculo de LE, pero no otras escrituras ni escrituras en ningún otro vínculo. Inicia un temporizador para descartar K después de 10 segundos si no se inició la vinculación. También descarta K si se desconecta este vínculo de LE.
Genera la respuesta sin procesar de 16 bytes que se muestra en la Tabla 1.3. Para ello, concatena el tipo y la dirección BR/EDR del proveedor y, luego, completa el resto del paquete con un bloque de bytes aleatorios (es decir, una sal).
Encripta la respuesta sin procesar con K para producir la respuesta encriptada de 16 bytes que se muestra en la Tabla 1.4. Se envía a través de una notificación sobre la característica de vinculación basada en claves.
Lee la marca de la solicitud:
Si el byte de marcas de la solicitud tiene el bit 2 configurado en 1, notifica Característica de datos adicionales con un nombre personalizado.
Si el byte de marcas de la solicitud tiene el bit 1 configurado en 1, haz lo siguiente:
Esto indica que el buscador le está solicitando al proveedor que inicie la vinculación a la dirección BR/EDR del buscador, que está presente en bytes 8-13.
Envía una solicitud de vinculación a la dirección BR/EDR del Seeker. La solicitud de vinculación debe ser como se describe a continuación (paso "Durante la vinculación").
Razón necesaria: Hacer que el proveedor inicie el servicio soluciona un problema en algunos dispositivos.
Si el byte de marcas de la solicitud tiene el bit 1 configurado en 0, haz lo siguiente:
Espera hasta 10 segundos para recibir una solicitud de vinculación. Si no recibes ninguna, sal.
Ten en cuenta que puede ser una solicitud BR/EDR de una dirección diferente (la dirección pública del Seeker, en lugar de la dirección privada que se puede resolver).
Volveremos a verificar durante la vinculación que el dispositivo solicitante tenga K.
Durante la vinculación:
Cuando se recibe un paquete de solicitud/respuesta de vinculación de Seeker: si las capacidades del dispositivo en la solicitud son NoInput/NoOutput, finaliza la vinculación para evitar el uso del método de vinculación Just Works.
Para el paquete de solicitud/respuesta de vinculación que envía el proveedor, establece el campo Device Capabilities en Display/YesNo y establece los requisitos de autenticación en MITM Protection Required. De esta manera, se activa el método de vinculación de comparación numérica (también conocido como Confirmación de llave de acceso en Android).
Confiamos en esto para confirmar que el dispositivo solicitante es, de hecho, el buscador de Vinculación rápida y que no hay ningún intermediario. Consulta los ejemplos.
Motivo por el que esto es necesario: El método de vinculación fuera de banda sería una mejor opción, pero la plataforma no lo expone en todas las versiones de Android deseadas.
Por lo general, con este método de vinculación, el usuario confirmaría que las llaves de acceso que se muestran en la pantalla de cada dispositivo son idénticas. En cambio, solo para esta vinculación, las transferimos a través de BLE, encriptadas con la clave precompartida de confianza.
Ten en cuenta que este enfoque no se debe adoptar para dispositivos que tienen pantalla o teclado, ya que compromete ligeramente la protección de MITM.
Por este motivo, la Vinculación rápida aún no admite esos tipos de dispositivos.
Si el temporizador de 10 segundos finaliza sin que se escriba una llave de acceso, descarta K.
Cuando se escribe un valor en la característica de la llave de acceso, este es el bloque de llave de acceso encriptado. Desencriptarlo con K para obtener un bloque de llave de acceso sin procesar, con el formato que se muestra en Characteristic: Passkey>Table 2.2 - (type =
Seeker's Passkey).
Si falla la desencriptación, ignora la escritura y descarta K.
De lo contrario, el Bloque de llaves de acceso sin procesar contiene una llave de acceso de 6 dígitos PSeeker, que es la llave de acceso que espera el buscador.
Compara PSeeker con nuestra propia llave de acceso esperada, PProvider.
Si los valores son iguales, responde “yes” a la confirmación.
De lo contrario, responde "no" a la confirmación, lo que hará que falle la vinculación.
Independientemente de si la vinculación falló, produce otro bloque de llave de acceso sin procesar con el formato que se muestra en Characteristic: Passkey>Tabla 2.2, que contiene nuestra propia llave de acceso esperada, PProvider.
Asegúrate de que el bloque tenga el tipo correcto (llave de acceso del proveedor; consulta la tabla).
NOTA: No vuelvas a usar la sal del bloque de llaves de acceso que recibió del buscador. Genera un nuevo valor aleatorio.
Encripta el bloque de llave de acceso sin procesar con K y envía el bloque de llave de acceso encriptada resultante a través de una notificación sobre la característica de la llave de acceso.
Si el buscador recibe y desencripta la llave de acceso P correcta, también responderá "sí" a la confirmación, y la vinculación tendrá éxito.
Si la vinculación se realiza correctamente, marca K como utilizable para desencriptar las escrituras de la clave de cuenta en este vínculo de LE, pero no para las escrituras de llaves de acceso posteriores ni las escrituras en ningún otro vínculo. Inicia un temporizador para descartar K después de 10 segundos. También descarta K luego de cualquier intento de escribir una clave de cuenta y, según el paso 4, si se desconecta el vínculo de LE.
Si la vinculación falla, descarta K.
Vuelve a cambiar el campo de capacidades del dispositivo a las funciones de E/S predeterminadas y los
requisitos de autenticación a los valores predeterminados para que las nuevas vinculaciones continúen como se espera.
Ten en cuenta que, en el caso de los proveedores que no requieren vinculación, Seeker no envía una solicitud de vinculación al proveedor. Se omite el paso 8: se omite el paso 17. Además, "K" se usa en Característica clave de la cuenta.
Ejemplos
Ejemplo 1: Intento de vinculación exitoso (sin intermediario).Ejemplo 2: Intento de vinculación fallido con un intermediario.
[null,null,["Última actualización: 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.*"]]