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 ellas los datos de la Tabla 1.1.

Cuando se administra una solicitud de escritura desde un buscador de Vinculación rápida, el proveedor de Vinculación rápida debe hacer lo siguiente:

  1. Si el campo opcional Clave pública está presente, haz lo siguiente:
    1. Si el dispositivo no está en modo de vinculación, ignora la escritura y sal.
    2. De lo contrario, haz lo siguiente:
      1. Usa la clave pública recibida (un punto de 64 bytes en la curva elíptica secp256r1), la clave privada antifalsificación de identidad preinstalada, también secp256r1, y el algoritmo de curva elíptica Diffie-Hellman para generar una clave AES de 256 bits.
      2. Usa SHA-256 para aplicar la codificación hash a la clave AES de 256 bits.
      3. Toma los primeros 128 bits del resultado. Esta es la clave AES antifalsificación que se usa en el siguiente paso.

  2. Usa AES-128 para intentar desencriptar el valor. Dado que el valor es un bloque AES único de 16 bytes, no se necesita ningún modo de cifrado IV o de varios bloques.

    1. Qué clave debes usar:
      1. Si se generó una clave AES antifalsificación en el paso 1, úsala.
      2. De lo contrario, prueba cada clave de la lista de claves de cuenta persistente.
    2. Si una clave desencripta correctamente el valor, falla y continúa con el siguiente paso.

    3. 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. Siempre que sea posible, se debe realizar un seguimiento de estas sales y, si el proveedor recibe una solicitud que contiene una sal que ya se usó, se debe ignorar la solicitud para evitar ataques de repetición.

    4. Como alternativa al seguimiento de las sales, si la escritura incluye la dirección privada del proveedor, otra forma de evitar los ataques de repetición es mostrar la hora de la siguiente rotación de 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.

  3. Si ninguna clave pudo desencriptar el valor correctamente, ignora la escritura y la salida.

    1. Mantén un recuento de estas fallas. Cuando el recuento de fallas 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 un éxito.

  4. De lo contrario, guarda la clave exitosa como K. Marca esta K como utilizable para desencriptar la llave de acceso y escrituras de nombres personalizados recibidas en este vínculo de LE, pero no otras escrituras ni ninguna otra escritura 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.

  5. Produce 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).

  6. Encriptar la respuesta sin procesar con K para producir la respuesta encriptada de 16 bytes que se muestra en la Tabla 1.4 Envía esto a través de una notificación sobre la característica de vinculación basada en claves.

  7. Lee la marca de solicitud:

    1. Si el byte de marcas de la solicitud tiene el bit 2 configurado en 1, notifica a la característica de datos adicionales con el nombre personalizado.
    2. Si el byte de marcas de la solicitud tiene el bit 1 configurado en 1, haz lo siguiente:
      1. Esto indica que el buscador le está solicitando al proveedor que inicie la vinculación con la dirección BR/EDR del buscador, que está presente en bytes 8 a 13.
      2. Envía una solicitud de vinculación a la dirección BR/EDR del Seeker. La solicitud de vinculación debe ser la que se describe a continuación (paso "Durante la sincronización").
      3. Razón por la que esto es necesario: Hacer que el proveedor se inicie puede solucionar un problema en algunos dispositivos.
    3. Si el byte de marcas de la solicitud tiene el bit 1 configurado en 0:
      1. Espera hasta 10 segundos para recibir una solicitud de sincronización. Si no se recibe ninguno, sal.
      2. Ten en cuenta que puede ser una solicitud BR/EDR de una dirección diferente (la dirección pública del buscador, en lugar de su dirección privada que se puede resolver). Durante la vinculación, volveremos a verificar que el dispositivo solicitante tenga K.

  8. Durante la vinculación:

    1. 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.
    2. Para el paquete de solicitud de vinculación/respuesta que envió el proveedor: Configura el campo Funciones del dispositivo en Display/YesNo y establece los requisitos de autenticación en Se requiere protección de MITM. 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). Nos basamos en esto para confirmar que el dispositivo solicitante es en realidad el buscador de Vinculación rápida y que no existe un intermediario. Consulta los ejemplos.
    3. 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 deseadas de Android.

  9. Cuando se necesite la confirmación de la llave de acceso, espera hasta 10 segundos para que se escriba en la característica de la llave de acceso.

    1. Por lo general, con este método de vinculación, el usuario debe confirmar 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.
    2. Ten en cuenta que este enfoque no se debe adoptar para dispositivos que tienen una pantalla o un teclado, ya que se compromete ligeramente con la protección MITM. Por este motivo, la Vinculación rápida aún no admite esos tipos de dispositivos.
    3. Si el temporizador de 10 segundos vence sin que se escriba una llave de acceso, descarta K.

  10. Cuando un valor se escribe en la característica de la llave de acceso, este es el bloque de clave de acceso encriptado. Desencriptarlo con K para generar un bloque de clave de acceso sin procesar, con el formato que se muestra en Characteristic: Passkey > Tabla 2.2 - (type = Seeker's Passkey).

  11. Si falla la desencriptación, ignora la escritura y descarta K.

  12. De lo contrario, el bloque de clave de acceso sin procesar contiene una llave de acceso de 6 dígitos PSeeker, que es la que espera el buscador.

  13. Compara PSeeker con nuestra propia llave de acceso esperada, PProvider.

    1. Si los valores son iguales, responda "sí" a la confirmación.
    2. De lo contrario, responde "no" a la confirmación, lo que hará que falle la vinculación.

  14. Independientemente de si falla la vinculación, genera otro bloque de clave de acceso sin procesar con el formato que se muestra en Characteristic: Passkey > Tabla 2.2, que contenga nuestra propia llave de acceso esperada, PProvider.

    1. 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 llave de acceso que recibió del buscador. Genera un valor aleatorio nuevo.

  15. Encripta el bloque de clave de acceso sin procesar con K y envía el bloque de clave de acceso encriptado resultante a través de una notificación en la característica de la llave de acceso.

  16. 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.

    1. Si la vinculación se realiza correctamente, marca K como utilizable para desencriptar escrituras de claves de cuenta en este vínculo de LE, pero no para escrituras de llave de acceso posteriores ni escrituras en ningún otro vínculo. Inicia un temporizador para descartar K después de 10 segundos. También descarta K después de cualquier intento de escribir una clave de cuenta y, según el paso 4, si se desconecta el vínculo de LE.
    2. Si la sincronización falla, descarta K.

  17. Vuelve a cambiar el campo de capacidades del dispositivo a las funciones de E/S predeterminadas y a los requisitos de autenticación a la configuración predeterminada para que las vinculaciones nuevas continúen como se espera.

Ejemplos
Ejemplo 1: Intento de vinculación exitoso (ningún intermediario).
Ejemplo 2: Se produjo un error de vinculación con un intermediario.