Especificación del accesorio de red de Localizador

v1.3

La especificación de accesorios de la Red de Localizador (FHN) define un enfoque encriptado de extremo a extremo para hacer un seguimiento de los dispositivos Bluetooth de bajo consumo (BLE) que emiten balizas. En esta página, se describe la FHN como una extensión de la especificación de Fast Pair. Los proveedores deben habilitar esta extensión si tienen dispositivos compatibles con FHN y desean habilitar el seguimiento de la ubicación para esos dispositivos.

Especificación de GATT

Se debe agregar una característica de atributos genéricos (GATT) adicional al servicio de Fast Pair con la siguiente semántica:

Característica del servicio de Vinculación rápida	Encriptado	Permisos	UUID
Acciones de baliza	No	Leer, escribir y notificar	FE2C1238-8366-4814-8EB0-01DE32100BEA

Tabla 1: Características del servicio de Vinculación rápida para la FHN.

Autenticación

Las operaciones que requiere esta extensión se realizan como una operación de escritura, protegida por un mecanismo de desafío-respuesta. Antes de realizar cualquier operación, se espera que el buscador realice una operación de lectura desde la característica de la tabla 1, lo que genera un búfer con el siguiente formato:

Octeto	Tipo de datos	Descripción	Valor
0	uint8	Número de versión principal del protocolo	0x01
1 - 8	array de bytes	Nonce aleatorio de un solo uso	varía

Cada operación de lectura debe generar un nonce diferente, y un solo nonce debe ser válido solo para una operación. El nonce se debe invalidar incluso si la operación falló.

Luego, el buscador calcula una clave de autenticación de un solo uso para usarla en una solicitud de escritura posterior. La clave de autenticación se calcula como se describe en las tablas 2 a 5. Según la operación que se solicite, el buscador demuestra conocimiento de una o más de las siguientes claves:

• Clave de la cuenta: Es la clave de la cuenta de Vinculación rápida de 16 bytes, como se define en la especificación de Vinculación rápida.

• Clave de la cuenta de propietario: El proveedor elige una de las claves de cuenta existentes como la clave de la cuenta de propietario la primera vez que un buscador accede a la característica de acciones de baliza. La clave de la cuenta de propietario elegida no se puede cambiar hasta que se restablezca la configuración de fábrica del proveedor. El proveedor no debe quitar la clave de la cuenta del propietario cuando se agoten los espacios disponibles para las claves de cuentas gratuitas.

  • Los proveedores que ya admiten FHN cuando se vinculan por primera vez (o que lo admiten cuando se vinculan después de restablecer la configuración de fábrica) eligen la primera clave de cuenta, ya que esta es la única clave de cuenta existente cuando el buscador lee el estado de aprovisionamiento durante la vinculación.

  • Los proveedores que obtienen asistencia de FHN después de que ya se vincularon (por ejemplo, a través de una actualización de firmware) pueden elegir cualquier clave de cuenta existente. Es razonable elegir la primera clave de cuenta que se usa para leer el estado de aprovisionamiento de la característica de acciones de baliza después de la actualización de firmware, suponiendo que el usuario que realizó la actualización es el propietario actual del proveedor.

• Clave de identidad efímera (EIK): Es una clave de 32 bytes que elige el buscador de forma aleatoria cuando realiza el proceso de aprovisionamiento de la FHN. Esta clave se usa para derivar claves criptográficas que se utilizan para encriptar de extremo a extremo los informes de ubicación. El buscador nunca la revela al backend.

• Clave de recuperación: Se define como SHA256(ephemeral identity key || 0x01) y se trunca a los primeros 8 bytes. La clave se almacena en el backend y el buscador puede usarla para recuperar la EIK, siempre que el usuario exprese su consentimiento presionando un botón en el dispositivo.

• Clave de anillo: Se define como SHA256(ephemeral identity key || 0x02), truncada a los primeros 8 bytes. La clave se almacena en el backend y el buscador solo puede usarla para hacer sonar el dispositivo.

• Clave de protección contra rastreo no deseado: Se define como SHA256(ephemeral identity key || 0x03) y se trunca a los primeros 8 bytes. La clave se almacena en el backend y el buscador solo puede usarla para activar el modo de protección contra seguimiento no deseado.

Operaciones

El formato de los datos escritos en la característica se proporciona en las tablas 2 a 5. Cada una de las operaciones se analiza con más detalle más adelante en esta sección.

Octeto	Tipo de datos	Descripción	Valor
0	uint8	ID de datos	0x00: Lee los parámetros de baliza 0x01: Lee el estado de aprovisionamiento 0x02: Establece la clave de identidad efímera 0x03: Borra la clave de identidad efímera
1	uint8	Longitud de los datos	varía
2 a 9	array de bytes	Clave de autenticación de un solo uso	Los primeros 8 bytes de HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data)
10, var	array de bytes	Datos adicionales	0x00: n/a 0x01: n/a 0x02: 32 bytes que son la clave de identidad efímera, encriptada con AES-ECB-128 con la clave de la cuenta. Si el proveedor ya tiene un conjunto de claves de identidad efímeras, también envía los primeros 8 bytes de SHA256(current ephemeral identity key || the last nonce read from the characteristic). 0x03: Los primeros 8 bytes de SHA256(ephemeral identity key || the last nonce read from the characteristic)

Tabla 2: Solicitud de aprovisionamiento de baliza.

Octeto	Tipo de datos	Descripción	Valor
0	uint8	ID de datos	0x04: Leer la clave de identidad efímera con el consentimiento del usuario
1	uint8	Longitud de los datos	0x08
2 a 9	array de bytes	Clave de autenticación de un solo uso	Los primeros 8 bytes de HMAC-SHA256(recovery key, protocol major version number || the last nonce read from the characteristic || data ID || data length)

Tabla 3: Solicitud de recuperación de la clave de aprovisionamiento de baliza.

Octeto	Tipo de datos	Descripción	Valor
0	uint8	ID de datos	0x05: Ring 0x06: Lee el estado de llamada
1	uint8	Longitud de los datos	varía
2 a 9	array de bytes	Clave de autenticación de un solo uso	Los primeros 8 bytes de HMAC-SHA256(ring key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data)
10, var	array de bytes	Datos adicionales	0x05: 4 bytes que indican el estado de llamada, la duración de la llamada y el volumen de la llamada. 0x06: n/a

Tabla 4: Solicitud de llamada.

Octeto	Tipo de datos	Descripción	Valor
0	uint8	ID de datos	0x07: Activa el modo de protección contra seguimiento no deseado 0x08: Desactiva el modo de protección contra seguimiento no deseado
1	uint8	Longitud de los datos	varía
2 a 9	array de bytes	Clave de autenticación de un solo uso	Los primeros 8 bytes de HMAC-SHA256(unwanted tracking protection key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data)
10, var	array de bytes	Datos adicionales	0x07: 1 byte de marcas de control (opcional) 0x08: Los primeros 8 bytes de SHA256(ephemeral identity key || the last nonce read from the characteristic)

Tabla 5: Solicitud de protección contra rastreo no deseado.

Las escrituras exitosas activan las notificaciones que se indican en la tabla 6.

Las notificaciones con un ID de datos distinto de 0x05: Cambio de estado de timbre se deben enviar antes de que se complete la transacción de escritura que activa la notificación, es decir, antes de que se envíe una PDU de respuesta para la solicitud de escritura.

Octeto	Tipo de datos	Descripción	Valor
0	uint8	ID de datos	0x00: Lee los parámetros de baliza 0x01: Lee el estado de aprovisionamiento 0x02: Establece la clave de identidad efímera 0x03: Borra la clave de identidad efímera 0x04: Leer la clave de identidad efímera con el consentimiento del usuario 0x05: Cambio de estado de llamada 0x06: Lee el estado de llamada 0x07: Activa el modo de protección contra seguimiento no deseado 0x08: Desactiva el modo de protección contra seguimiento no deseado
1	uint8	Longitud de los datos	varía
2 a 9	array de bytes	Autenticación	Detalles por operación
10, var	array de bytes	Datos adicionales	0x00: 8 bytes que indican la potencia de transmisión, el valor del reloj, el método de encriptación y las capacidades de llamada, encriptados con AES-ECB-128 con la clave de la cuenta (con ceros a la derecha) 0x01: 1 byte que indica el estado de aprovisionamiento, seguido del ID efímero actual (20 o 32 bytes) si corresponde 0x04: 32 bytes que son la clave de identidad efímera, encriptada con AES-ECB-128 con la clave de la cuenta 0x05: 4 bytes que indican el nuevo estado y el activador del cambio 0x06: 3 bytes que indican los componentes que están sonando activamente y la cantidad de decísegundos restantes para que suene Otros IDs de datos usan datos adicionales vacíos

Tabla 6: Respuesta del servicio de balizas.

En la tabla 7, se enumeran los posibles códigos de error de GATT que muestran las operaciones.

Código	Descripción	Notas
0x80	Sin autenticar	Se devuelve en respuesta a una solicitud de escritura cuando falla la autenticación (incluido el caso en el que se usó un nonce anterior).
0x81	Valor no válido	Se devuelve cuando se proporciona un valor no válido o los datos recibidos tienen una cantidad inesperada de bytes.
0x82	No hay consentimiento del usuario	Se devuelve en respuesta a una solicitud de escritura con el ID de datos 0x04: Leer la clave de identidad efímera con el consentimiento del usuario cuando el dispositivo no está en modo de vinculación.

Tabla 7: Códigos de error de GATT.

Leer el parámetro de la baliza

El buscador puede consultar al proveedor sobre los parámetros de la baliza realizando una operación de escritura en la característica que consta de una solicitud de la tabla 2 con el ID de datos 0x00. El proveedor verifica que la clave de autenticación única proporcionada coincida con alguna de las claves de la cuenta almacenadas en el dispositivo.

Si la verificación falla, el proveedor devuelve un error de no autenticación.

Si la operación se realiza correctamente, el proveedor envía una notificación con una respuesta de la tabla 6 con el ID de datos 0x00. El proveedor construye el segmento de datos de la siguiente manera:

Octeto	Tipo de datos	Descripción	Valor
0	uint8	Potencia calibrada	Potencia calibrada recibida a 0 m (un valor en el rango [-100, 20]). Se representa como un número entero firmado, con una resolución de 1 dBm.
1 a 4	uint32	Valor del reloj	Es el valor actual del reloj en segundos (big endian).
5	uint8	Selección de curvas	La curva elíptica que se usa para la encriptación: 0x00 (predeterminado): SECP160R1 0x01: SECP256R1 (requiere publicidad extendida)
6	uint8	Componentes	Cantidad de componentes que pueden sonar: 0x00: Indica que el dispositivo no puede sonar. 0x01: Indica que solo un componente puede sonar. 0x02: Indica que dos componentes, los auriculares izquierdo y derecho, pueden sonar de forma independiente. 0x03: Indica que tres componentes (los auriculares izquierdo y derecho, y el estuche) pueden sonar de forma independiente.
7	uint8	Capacidades de llamada	Las opciones compatibles son las siguientes: 0x00: La selección del volumen de llamada no está disponible. 0x01: Selección de volumen del tono disponible. Si se configura, el proveedor debe aceptar y controlar 3 niveles de volumen, como se indica en Operación de timbre.
8-15	array de bytes	Padding	Es el relleno con ceros para la encriptación AES.

Los datos deben encriptarse con AES-ECB-128 y la clave de la cuenta que se usa para autenticar la solicitud.

El segmento de autenticación se define como los primeros 8 bytes de HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data after encryption || 0x01).

Leer el estado de aprovisionamiento de la baliza

El buscador puede consultar al proveedor sobre el estado de aprovisionamiento de la baliza realizando una operación de escritura en la característica que consta de una solicitud de la tabla 2 con el ID de datos 0x01. El proveedor verifica que la clave de autenticación única proporcionada coincida con cualquiera de las claves de la cuenta almacenadas en el dispositivo.

Si la verificación falla, el proveedor devuelve un error de no autenticación.

Si la operación se realiza correctamente, el proveedor envía una notificación con una respuesta de la tabla 6 que incluye el ID de datos 0x01. El proveedor construye el segmento de datos de la siguiente manera:

Octeto	Tipo de datos	Descripción	Valor
0	uint8	Estado de aprovisionamiento	Es una máscara de bits que tiene los siguientes valores: Bit 1 (0x01): Se establece si se configura una clave de identidad efímera para el dispositivo. Bit 2 (0x02): Se establece si la clave de autenticación de un solo uso proporcionada coincide con la clave de la cuenta del propietario.
1 a 20 o 32	array de bytes	Identificador efímero actual	20 o 32 bytes (según el método de encriptación que se use) que indican el ID efímero actual que anuncia la baliza, si se configuró uno para el dispositivo.

El segmento de autenticación se define como los primeros 8 bytes de HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data || 0x01).

Cómo establecer una clave de identidad efímera

Para aprovisionar un proveedor no aprovisionado como baliza de FHN o cambiar la clave de identidad efímera de un proveedor ya aprovisionado, el buscador realiza una operación de escritura en la característica que consiste en una solicitud de la tabla 2 con el ID de datos 0x02. El proveedor verifica lo siguiente:

• La clave de autenticación única proporcionada coincide con la clave de la cuenta del propietario.
• Si se proporcionó un hash de una clave de identidad efímera, el hash de la clave de identidad efímera coincide con la clave de identidad efímera actual.
• Si no se proporcionó un hash de una clave de identidad efímera, verifica que el proveedor no se haya aprovisionado ya como baliza de FHN.

Si la verificación falla, el proveedor devuelve un error de no autenticación.

Si la operación se realiza correctamente, la clave de identidad efímera se recupera con el algoritmo de desencriptación AES-ECB-128 usando la clave de cuenta coincidente. La clave debe persistir en el dispositivo y, a partir de ese momento, el proveedor debe comenzar a anunciar los fotogramas de FHN. La nueva clave de identidad efímera entra en vigencia inmediatamente después de que se cierra la conexión BLE. El proveedor notifica con una respuesta de la tabla 6 con el ID de datos 0x02.

El segmento de autenticación se define como los primeros 8 bytes de HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || 0x01).

Borra la clave de identidad efímera

Para desaprovisionar la parte de baliza del proveedor, el buscador realiza una operación de escritura en la característica, que consiste en una solicitud de la tabla 2 con el ID de datos 0x03. El proveedor verifica lo siguiente:

• La clave de autenticación única proporcionada coincide con la clave de la cuenta del propietario.
• La clave de identidad efímera con hash coincide con la clave de identidad efímera actual.

Si el proveedor no se aprovisiona como baliza de FHN o falla la verificación, se muestra un error de no autenticación.

Si la operación se realiza correctamente, el proveedor olvidará la clave y dejará de anunciar fotogramas de FHN. El proveedor notifica con una respuesta de la tabla 6 con el ID de datos 0x03. El segmento de autenticación se define como los primeros 8 bytes de HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || 0x01).

Cómo leer la clave de identidad efímera con el consentimiento del usuario

Esta opción solo está disponible para recuperar una llave perdida, ya que el buscador solo la almacena de forma local. Por lo tanto, esta capacidad solo está disponible cuando el dispositivo está en modo de vinculación o durante un tiempo limitado después de que se presionó un botón físico en el dispositivo (lo que constituye el consentimiento del usuario).

El buscador debe almacenar la clave de recuperación en el backend para poder recuperar la clave de texto no encriptado, pero no almacena la EIK en sí.

Para leer la EIK, el buscador realiza una operación de escritura en la característica, que consiste en una solicitud de la tabla 3 con el ID de datos 0x04. El Proveedor verifica lo siguiente:

• La clave de recuperación hasheada coincide con la clave de recuperación esperada.
• El dispositivo está en modo de recuperación de EIK.

Si la verificación falla, el proveedor devuelve un error de no autenticación.

Si el dispositivo no está en modo de vinculación, el proveedor devuelve un error de No User Consent.

Si la operación se realiza correctamente, el proveedor envía una notificación con una respuesta de la tabla 6 con el ID de datos 0x04.

El segmento de autenticación se define como los primeros 8 bytes de HMAC-SHA256(recovery key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data || 0x01).

Operación de llamada

El buscador puede pedirle al proveedor que reproduzca un sonido realizando una operación de escritura en la característica, que consiste en una solicitud de la tabla 4 con el ID de datos 0x05. El proveedor construye el segmento de datos de la siguiente manera:

Octeto	Tipo de datos	Descripción	Valor
0	uint8	Operación de llamada	Es una máscara de bits que tiene los siguientes valores: Bit 1 (0x01): Hacer sonar auricular derecho Bit 2 (0x02): Hacer sonar auricular izquierdo Bit 3 (0x04): Estuche 0xFF: Llamar a todos los componentes 0x00: Detener el sonido
1 - 2	uint16	Tiempo de espera	Es el tiempo de espera en decisegundos. No debe ser cero ni mayor que el equivalente a 10 minutos. El proveedor usa este valor para determinar cuánto tiempo debe sonar antes de silenciarse. El tiempo de espera anula el que ya está en efecto si algún componente del dispositivo ya está sonando. Si la operación de llamada se establece en 0x00, se ignora el tiempo de espera.
3	uint8	Volumen	0x00: Predeterminado 0x01: Baja 0x02: Medio 0x03: Alta El significado exacto de estos valores depende de la implementación.

Al recibir la solicitud, el Proveedor verifica lo siguiente:

• La clave de autenticación única proporcionada coincide con la clave del anillo.
• El estado solicitado coincide con los componentes que pueden sonar.

Si el proveedor no se aprovisiona como baliza de FHN o falla la verificación, se muestra un error de no autenticación. Sin embargo, si el proveedor tiene activa la protección contra el seguimiento no deseado, y la solicitud de protección contra el seguimiento no deseado que activó la protección tenía activada la marca de omitir la autenticación de llamada, el proveedor debe omitir esa verificación. Aún se espera que el buscador proporcione los datos de autenticación, pero se pueden establecer en un valor arbitrario.

Cuando comienza o finaliza el timbre, se envía una notificación como se indica en la tabla 6 con el ID de datos 0x05. El contenido de la notificación se define de la siguiente manera:

Octeto	Tipo de datos	Descripción	Valor
0	uint8	Estado de llamada	0x00: Iniciado 0x01: No se pudo iniciar o detener (todos los componentes solicitados están fuera del rango) 0x02: Detenido (se agotó el tiempo de espera) 0x03: Detenido (presión del botón) 0x04: Detenido (solicitud de GATT)
1	uint8	Componentes de llamada	Es una máscara de bits de los componentes que suenan activamente, como se define en la solicitud.
2 a 3	uint16	Tiempo de espera	Es el tiempo restante para que suene el teléfono en decisegundos. Si el dispositivo dejó de sonar, se debe devolver 0x0000.

El segmento de autenticación se define como los primeros 8 bytes de HMAC-SHA256(ring key, protocol major version number || the nonce used to initiate the ringing command || data ID || data length || additional data || 0x01).

Si el dispositivo ya está en el estado de llamada solicitado cuando se recibe una solicitud para llamar o detener la llamada, el proveedor debe enviar una notificación con un estado de llamada o 0x00: Started o 0x04: Stopped (solicitud de GATT), respectivamente. Esta solicitud anula los parámetros del estado existente, de modo que se pueda extender la duración del timbre.

Si el proveedor tiene un botón físico (o si el sensor táctil está habilitado), ese botón debe detener la función de llamada si se presiona mientras la llamada está activa.

Obtén el estado de llamada del balizamiento

Para obtener el estado de llamada del baliza, el buscador realiza una operación de escritura en la característica, que consiste en una solicitud de la tabla 4 con el ID de datos 0x06. El proveedor verifica que la clave de autenticación de un solo uso proporcionada coincida con la clave del anillo.

Si el proveedor no se aprovisiona como baliza de FHN o si falla la verificación, el proveedor devuelve un error de no autenticación.

Si la operación se realiza correctamente, el proveedor envía una notificación con una respuesta de la tabla 6 con el ID de datos 0x06. El proveedor construye el segmento de datos de la siguiente manera:

Octeto	Tipo de datos	Descripción	Valor
0	uint8	Componentes de llamada	Son los componentes que están sonando activamente, según se define en la solicitud de llamada.
1 - 2	uint16	Tiempo de espera	Es el tiempo restante para que suene el teléfono en decisegundos. Ten en cuenta que, si el dispositivo no está sonando, se debe devolver 0x0000.

El segmento de autenticación se define como los primeros 8 bytes de HMAC-SHA256 (ring key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data || 0x01).

Modo de protección contra rastreo no deseado

El modo de protección contra seguimiento no deseado tiene como objetivo permitir que cualquier cliente identifique dispositivos abusivos sin comunicación con el servidor. De forma predeterminada, el proveedor debe rotar todos los identificadores como se describe en Rotación de ID. El servicio de Localizador puede retransmitir una solicitud de activación del modo de protección contra rastreo no deseado a través de la red de Localizador. De esta manera, el servicio hace que el proveedor use temporalmente una dirección MAC fija, lo que permite que los clientes detecten el dispositivo y adviertan al usuario sobre un posible rastreo no deseado.

Para activar o desactivar el modo de protección contra el seguimiento no deseado de la baliza, el buscador realiza una operación de escritura en la característica, que consiste en una solicitud de la tabla 5 con el ID de datos 0x07 o 0x08, respectivamente.

Cuando se habilita el modo de protección contra seguimiento no deseado

El proveedor construye el segmento de datos de la siguiente manera:

Octeto	Tipo de datos	Descripción	Valor
0	uint8	Marcas de control	0x01: Omite la autenticación de llamada. Cuando se configura, las solicitudes de llamada no se autentican mientras se está en el modo de protección contra seguimiento no deseado. Si no se establece ninguna marca (el byte es todo ceros), es válido omitir la sección de datos por completo y enviar una sección de datos vacía. Las marcas solo están vigentes hasta que se desactiva el modo de protección contra seguimiento no deseado.

El proveedor verifica que la clave de autenticación de un solo uso proporcionada coincida con la clave de protección contra seguimiento no deseado. Si el proveedor no se aprovisiona como baliza de FHN o falla la verificación, se muestra un error de no autenticación.

Cuando se activa el modo de protección contra seguimiento no deseado, la baliza debe reducir la frecuencia de rotación de la dirección MAC privada a una vez cada 24 horas. El identificador efímero anunciado debe seguir rotando como de costumbre. El tipo de trama debe establecerse en 0x41. El estado también se refleja en la sección marcas hash.

Cuándo inhabilitar el modo de protección contra seguimiento no deseado

El proveedor verifica lo siguiente:

• La clave de autenticación de un solo uso proporcionada coincide con la clave de protección contra el seguimiento no deseado.
• La clave de identidad efímera con hash coincide con la clave de identidad efímera actual.

Si el proveedor no se aprovisiona como baliza de FHN o falla la verificación, el proveedor devuelve un error de no autenticación.

Cuando se desactiva el modo de protección contra seguimiento no deseado, la baliza debería comenzar a rotar la dirección MAC a una velocidad normal nuevamente, sincronizada con la rotación del identificador efímero. El tipo de trama debe volver a establecerse en 0x40. El estado también se refleja en la sección Marcas con hash.

Si la operación se realiza correctamente, el proveedor envía una notificación con una respuesta de la tabla 6 que incluye el ID de datos 0x07 o 0x08.

El segmento de autenticación se define como los primeros 8 bytes de HMAC-SHA256(unwanted tracking protection key, protocol major version number || the last nonce read from the characteristic || data ID || data length || 0x01).

Búsqueda precisa

En esta sección, se detallan el flujo y las operaciones adicionales necesarios para la búsqueda precisa. Aquí se aplican las mismas reglas para la característica GATT y la autenticación que se definen en la sección de especificaciones de GATT. La Búsqueda precisa es opcional.

El tipo de búsqueda de precisión depende del tipo de tecnologías de rango admitidas en los dispositivos que participan en la búsqueda de precisión. Las tecnologías de rango admitidas se pueden encontrar en la especificación Ranging: Out-of-band message sequence and payload. En secciones posteriores, se explora qué tipo de experiencia de búsqueda de precisión se puede esperar según la tecnología de rango utilizada.

Flujo de la Búsqueda precisa

En esta sección, se explora el flujo de mensajes de FHNA para la Búsqueda Precisa. En la Figura 1, se muestra el flujo de los mensajes, y en los párrafos, se explica cada mensaje con más detalle.

Fig. 1: Flujo de mensajes típico de la Búsqueda precisa

El dispositivo iniciador es el que tiene la app de Localizador y desde el que se activó la función de Búsqueda precisa. El iniciador es el dispositivo que intenta encontrar el otro dispositivo.

El dispositivo de respuesta es el que intenta encontrar el dispositivo iniciador.

El dispositivo iniciador envía un mensaje de solicitud de capacidad de medición de distancia al dispositivo respondedor, en el que se enumeran las tecnologías de medición de distancia sobre las que le interesa obtener información del dispositivo respondedor. El dispositivo de respuesta responderá con la notificación de respuesta de capacidad de medición de distancia, que contiene información sobre qué tecnologías de medición de distancia son compatibles y cuáles son sus capacidades. El responder incluirá solo la información que solicitó el iniciador. La lista de capacidades se ordenará según la prioridad de la tecnología de medición de distancia que prefiera el dispositivo de respuesta, y la primera de la lista tendrá la prioridad más alta.

Luego, el dispositivo iniciador enviará un mensaje de configuración de rango, en el que definirá la configuración de cada tecnología de rango con la que desea determinar el rango. Al recibir este mensaje, el dispositivo de respuesta debe comenzar a determinar el rango de las tecnologías aplicables con los parámetros de configuración proporcionados. El dispositivo de respuesta enviará una notificación de respuesta de configuración de rango, que contiene los resultados sobre si cada tecnología de rango individual se inició correctamente. Algunas tecnologías de medición de distancia deben iniciarse tanto en el dispositivo iniciador como en el dispositivo de respuesta para que la sesión de medición de distancia sea exitosa, mientras que para otras solo es necesario que se inicie en el dispositivo iniciador. Aun así, el dispositivo de respuesta debe responder con un resultado exitoso para esas tecnologías. Encontrarás más información sobre el comportamiento específico de la tecnología de medición en secciones posteriores.

Una vez que el dispositivo iniciador esté listo para detener la sesión de Búsqueda precisa, enviará un mensaje de Stop Ranging al dispositivo de respuesta, en el que se indicará qué tecnologías de medición deben detener la medición. El dispositivo de respuesta responderá con una notificación de respuesta de detención del rango, lo que indica que detuvo correctamente el rango con las tecnologías de rango solicitadas.

En el caso de que el canal de comunicación FHNA BLE GATT se desconecte a mitad de la sesión de Precision Finding, pero mientras algunas de las tecnologías de medición de distancia sigan midiendo, el dispositivo de respuesta implementará un mecanismo de tiempo de espera para garantizar que no mida la distancia de forma indefinida. Los detalles dependerán de cada caso de uso.

Ten en cuenta que el dispositivo de respuesta no debe suponer que el orden de las operaciones siempre será el mismo. Por ejemplo, el dispositivo de respuesta debe poder controlar varias operaciones de solicitud de capacidad de rango seguidas o incluso una operación de configuración de rango directa sin la solicitud de capacidad anterior.

Operaciones de Búsqueda precisa

En la tabla 8, se muestran las operaciones de FHNA definidas en este documento que se requieren para la Búsqueda Precisa. Cada subsección define el mensaje de FHNA para cada una de las operaciones, mientras que el contenido del campo Additional Data hace referencia a la especificación de Ranging: Out-of-band message sequence and payload.

Operación	ID de datos	Descripción
Solicitud de capacidad de medición de distancia	0x0A	Operación de solicitud de capacidad que enviará el dispositivo iniciador al dispositivo de respuesta. El contenido de los datos de esta operación enumerará todas las tecnologías de rango sobre las que el iniciador desea obtener información del dispositivo de respuesta.
Respuesta de capacidad de alcance	0x0A	Esta es la respuesta de notificación a la operación de solicitud de capacidad de rango. Contiene información sobre las capacidades de cada tecnología de rango admitida que solicitó el iniciador.
Configuración de rango	0x0B	La operación de configuración de rango contiene las configuraciones para las tecnologías de rango con las que el dispositivo iniciador desea comenzar a determinar el rango con el dispositivo respondedor.
Respuesta de configuración de rango	0x0B	Esta es la respuesta de notificación a la operación de configuración de rango. Contiene datos sobre si el dispositivo de respuesta inició correctamente el rango con las tecnologías de rango solicitadas según la configuración proporcionada.
RFU	0x0C	La operación con este ID de datos no se usa y está reservada para uso futuro.
Detener el rango	0x0D	La operación Stop Ranging que envía el dispositivo iniciador contiene información sobre las tecnologías de rango con las que el dispositivo respondedor debe dejar de determinar el rango.
Detener la respuesta de rango	0x0D	Es la respuesta de notificación a la operación Stop Ranging. Contiene datos sobre si la operación de detención de una tecnología de medición específica se realizó correctamente o no.

Tabla 8: Operaciones de Búsqueda Precisa.

Operación de solicitud de capacidad de rango

En la tabla 9, se define el mensaje de solicitud de capacidad de rango.

Octeto	Tipo de datos	Descripción	Valor
0	uint8	ID de datos	0x0A: Operación de solicitud de capacidad de rango
1	uint8	Longitud de los datos	varía
2	array de bytes	Clave de autenticación de un solo uso	Los primeros 8 bytes de HMAC-SHA256(clave de la cuenta, número de versión principal del protocolo || el último nonce leído de la característica || ID de datos || longitud de los datos || datos adicionales).
10	array de bytes	Datos adicionales	Mensaje de Solicitud de capacidad de rango, según se define en la especificación de Ranging: Out-of-band message sequence and payload (tanto el encabezado como la carga útil)

Tabla 9: Solicitud de capacidad de medición de distancia.

Operación de respuesta de capacidad de rango

En la tabla 10, se define el mensaje de respuesta de capacidad de rango.

Octeto	Tipo de datos	Descripción	Valor
0	uint8	ID de datos	0x0A: Respuesta de capacidad de rango
1	uint8	Longitud de los datos	varía
2	array de bytes	Clave de autenticación de un solo uso	Los primeros 8 bytes de HMAC-SHA256(clave de la cuenta, número de versión principal del protocolo || el último nonce leído de la característica || ID de datos || Longitud de datos || Datos adicionales || 0x01).
10	array de bytes	Datos adicionales	Mensaje de Ranging Capability Response, según se define en la especificación de Ranging: Out-of-band message sequence and payload (encabezado y carga útil)

Tabla 10: Respuesta de capacidad de alcance.

Operación de configuración de rango

En la tabla 11, se define el mensaje de configuración de rango.

Octeto	Tipo de datos	Descripción	Valor
0	uint8	ID de datos	0x0B: Establece la configuración de rango
1	uint8	Longitud de los datos	varía
2	array de bytes	Clave de autenticación de un solo uso	Los primeros 8 bytes de HMAC-SHA256(clave de la cuenta, número de versión principal del protocolo || el último nonce leído de la característica || ID de datos || longitud de los datos || datos adicionales).
10	array de bytes	Datos adicionales	Mensaje de Configuración de rango, según se define en la especificación de Ranging: secuencia y carga útil de mensajes fuera de banda (encabezado y carga útil)

Tabla 11: Configuración de rango.

Operación de respuesta de configuración de rango

En la tabla 12, se define el mensaje de respuesta de configuración de rango.

Octeto	Tipo de datos	Descripción	Valor
0	uint8	ID de datos	0x0B: Respuesta de configuración de rango
1	uint8	Longitud de los datos	varía
2	array de bytes	Clave de autenticación de un solo uso	Los primeros 8 bytes de HMAC-SHA256(clave de la cuenta, número de versión principal del protocolo || el último nonce leído de la característica || ID de datos || Longitud de datos || Datos adicionales || 0x01).
10	array de bytes	Datos adicionales	Mensaje de Ranging Configuration Response, según se define en la especificación de Ranging: Out-of-band message sequence and payload (tanto el encabezado como la carga útil)

Tabla 12: Respuesta de configuración de rango.

Detener la operación de medición de distancia

En la tabla 13, se define el mensaje Stop Ranging.

Octeto	Tipo de datos	Descripción	Valor
0	uint8	ID de datos	0x0D: Detención de rango
1	uint8	Longitud de los datos	varía
2	array de bytes	Clave de autenticación de un solo uso	Los primeros 8 bytes de HMAC-SHA256(clave de la cuenta, número de versión principal del protocolo || el último nonce leído de la característica || ID de datos || longitud de los datos).
10	array de bytes	Datos adicionales	Mensaje de Stop Ranging, según se define en la especificación Ranging: Out-of-band message sequence and payload (tanto el encabezado como la carga útil)

Tabla 13: Detener el rango.

Detener la operación de respuesta de rango

En la tabla 14, se define el mensaje de respuesta de detención del rango.

Octeto	Tipo de datos	Descripción	Valor
0	uint8	ID de datos	0x0D: Respuesta de detención de rango
1	uint8	Longitud de los datos	varía
2	array de bytes	Clave de autenticación de un solo uso	Los primeros 8 bytes de HMAC-SHA256(clave de la cuenta, número de versión principal del protocolo || el último nonce leído de la característica || ID de datos || Longitud de datos || Datos adicionales || 0x01).
10	array de bytes	Datos adicionales	Mensaje de Stop Ranging Response, según se define en la especificación de Ranging: Out-of-band message sequence and payload (tanto el encabezado como la carga útil)

Tabla 14: Detener la respuesta de rango.

Protección contra rastreo no deseado con la función de Búsqueda precisa

Cuando se activa el modo de protección contra seguimiento no deseado, como se describe en la sección de protección contra seguimiento no deseado, el mismo flujo que se aplica para omitir las verificaciones de autenticación de los mensajes de llamada también se aplica a todos los mensajes de Búsqueda precisa definidos en este documento para los dispositivos que quieran admitir esta función.

Especificaciones de la tecnología de rango para la Búsqueda precisa

En esta sección, se incluyen detalles específicos de la tecnología de medición de distancias.

Especificaciones de la banda ultraancha (UWB)

Son detalles específicos de la UWB.

Nivel de Búsqueda precisa

En las sesiones de búsqueda precisa que usan UWB como tecnología de medición de distancia, se puede esperar ver información sobre la distancia y la dirección. El intervalo de alcance debe ser de al menos 240 ms, aunque se recomienda 96 ms para una orientación óptima.

IDs de configuración

Los datos de configuración fuera de banda intercambiados para la UWB no contienen un conjunto completo de parámetros configurables disponibles que la UWB requiere para iniciar una sesión de medición de distancia con UWB. Algunos parámetros se seleccionan de forma implícita con el ID de configuración elegido.

Cada ID de configuración es un conjunto de parámetros de configuración de UWB predefinidos que están documentados públicamente. Para el caso de uso de la Búsqueda Precisa, el dispositivo de respuesta debe admitir el ID de configuración 6 y, de manera opcional, el ID de configuración 3.

Iniciador y respondedor de UWB

En el caso de uso de la Búsqueda precisa, el dispositivo que se indica como dispositivo iniciador en este documento será el dispositivo de respuesta de UWB, y el dispositivo que se indica como dispositivo de respuesta en este documento será el dispositivo iniciador de UWB. Esto se debe a que el dispositivo iniciador de UWB consume menos energía que el dispositivo de respuesta de UWB, y, en la mayoría de los casos, el dispositivo de respuesta será un periférico con batería limitada.

Esto significa que el dispositivo de respuesta debe indicar que admite el rol de iniciador de UWB en el mensaje de respuesta de la capacidad de medición de distancia.

Otros parámetros relacionados con la UWB

• Se debe admitir el canal 9
• Para obtener una orientación óptima, se recomienda un intervalo de medición de 96 ms. De lo contrario, se debe admitir un intervalo de 240 ms.
• Se recomienda una duración de ranura de 1 ms para ahorrar batería, pero también se admite una de 2 ms.
• El chip UWB debe ser compatible con FIRA v1.2 y P-STS como mínimo.
• El BPRF es obligatorio, mientras que el HPRF es opcional, pero se recomienda. El modo seleccionado o admitido se determina según el índice de preámbulo seleccionado o admitido.
• Tipo de seguridad de la sesión: P-STS

Detalles de la detección de canales (CS) de BLE

Son detalles específicos de CS de BLE.

Nivel de Búsqueda precisa

Las sesiones de Búsqueda precisa que usan CS como tecnología de medición de distancia solo proporcionarán mediciones de distancia. Por el momento, no se proporciona la direccionalidad.

Vinculación requerida entre dispositivos

Las sesiones de Búsqueda precisa que usan Channel Sounding no funcionarán si los dispositivos no están vinculados. Se requiere una vinculación existente entre el dispositivo iniciador y el dispositivo de respuesta. Esta especificación no proporciona una forma de crear una vinculación entre los dispositivos. En cambio, depende del desarrollador del caso de uso establecer este vínculo entre los dispositivos.

Acción obligatoria por parte del equipo de respuesta para CS

A diferencia de la UWB, en la que ambos dispositivos deben llamar explícitamente a las APIs de inicio y detención de la medición de distancia de la UWB, en el caso de CS, solo el dispositivo iniciador debe llamar a la pila de Bluetooth para iniciar la medición de distancia de CS. El resto de la inicialización del lado del dispositivo de respuesta se realiza dentro de la banda con Bluetooth (BT). Esto significa que, al recibir el mensaje de configuración de rango o el mensaje de detención de rango para CS, el lado del dispositivo de respuesta no tiene que hacer nada si el BT está habilitado, más que responder con la notificación del mensaje de respuesta de configuración de rango. El dispositivo de respuesta podría usar esos mensajes como un activador para actualizar la IU en la que hay una pantalla o, independientemente de tener una pantalla, podría usarse para brindar comentarios visuales sobre el estado del dispositivo, por ejemplo, parpadear las luces LED del dispositivo.

RTT de NAN de Wi-Fi

Son detalles específicos del RTT de NAN de Wi-Fi.

Nivel de Búsqueda precisa

Las sesiones de Búsqueda precisa que usan Wi-Fi NAN RTT como tecnología de medición solo generarán mediciones de distancia. Por el momento, no se proporciona direccionalidad.

RSSI de BLE

Son detalles específicos del RSSI de BLE.

Nivel de Búsqueda precisa

Las sesiones de Encuentra con precisión que solo usan el RSSI de BLE como tecnología de rango no podrán obtener la información de distancia ni de dirección, ya que el RSSI de BLE no es una tecnología de rango precisa. En su lugar, el usuario verá una guía que indica que el dispositivo está cerca o lejos.

Marcos anunciados

Después del aprovisionamiento, se espera que el proveedor anuncie los fotogramas de FHN al menos una vez cada 2 segundos. Si se anuncian tramas de Vinculación rápida, el proveedor debe intercalar las tramas de FHN dentro de los anuncios regulares de Vinculación rápida. Por ejemplo, cada dos segundos, el proveedor debe anunciar siete anuncios de Fast Pair y un anuncio de FHN.

La potencia de transmisión de Bluetooth conducida para los anuncios de FHN debe establecerse en al menos 0 dBm.

El marco de FHN contiene una clave pública que usa cualquier cliente compatible que contribuya a la red de colaboración para encriptar los informes de ubicación. Hay dos tipos de claves de curva elíptica disponibles: una clave de 160 bits que se adapta a los marcos heredados de BLE 4 o una clave de 256 bits que requiere BLE 5 con capacidades de publicidad extendidas. La implementación del proveedor determina qué curva se usa.

Un fotograma de FHN se estructura de la siguiente manera.

Octeto	Valor	Descripción
0	0x02	Longitud
1	0x01	Valor del tipo de datos de marcas
2	0x06	Datos de marcas
3	0x18 o 0x19	Longitud
4	0x16	Valor del tipo de datos de los datos de servicio
5	0xAA	UUID de servicio de 16 bits
6	0xFE	…
7	0x40 o 0x41	Tipo de fotograma de FHN con indicación del modo de protección contra seguimiento no deseado
8..27		Identificador efímero de 20 bytes
28		Marcas con hash

Tabla 15: Frame de FHN que admite una curva de 160 bits.

En la tabla 16, se muestran los desplazamientos y los valores de bytes para una curva de 256 bits.

Octeto	Valor	Descripción
0	0x02	Longitud
1	0x01	Valor del tipo de datos de marcas
2	0x06	Datos de marcas
3	0x24 o 0x25	Longitud
4	0x16	Valor del tipo de datos de los datos de servicio
5	0xAA	UUID de servicio de 16 bits
6	0xFE	…
7	0x40 o 0x41	Tipo de fotograma de FHN con indicación del modo de protección contra seguimiento no deseado
8..39		Identificador efímero de 32 bytes
40		Marcas con hash

Tabla 16: Frame de FHN que admite una curva de 256 bits.

Cálculo del identificador efímero (EID)

Se genera un número aleatorio encriptando la siguiente estructura de datos con AES-ECB-256 y la clave de identidad efímera:

Octeto	Campo	Descripción
0 - 10	Padding	Valor = 0xFF
11	K	Exponente del período de rotación
12 a 15	TS[0]…TS[3]	Contador de tiempo de baliza, en formato big-endian de 32 bits. Se borran los bits menos significativos.
16 - 26	Padding	Valor = 0x00
27	K	Exponente del período de rotación
28 - 31	TS[0]…TS[3]	Contador de tiempo de baliza, en formato big-endian de 32 bits. Se borran los bits menos significativos.

Tabla 17: Construcción de un número pseudoaleatorio.

El resultado de este cálculo es un número de 256 bits, que se denota como r'.

Para el resto del cálculo, se usan SECP160R1 o SECP256R1 para las operaciones criptográficas de curva elíptica. Consulta las definiciones de curvas en SEC 2: Recommended Elliptic Curve Domain Parameters, que define Fp, n y G a los que se hace referencia a continuación.

Ahora, r' se proyecta en el campo finito Fp calculando r = r' mod n. Por último, calcula R = r * G, que es un punto en la curva que representa la clave pública que se usa. La baliza anuncia Rx, que es la coordenada x de R, como su identificador efímero.

Marcas con hash

El campo de marcas hash se calcula de la siguiente manera (los bits se referencian del más significativo al menos significativo):

• Bits 0 a 4: Reservados (establecidos en ceros).
• Los bits 5 y 6 indican el nivel de batería del dispositivo de la siguiente manera:
  • 00: No se admite la indicación del nivel de batería
  • 01: Nivel de batería normal
  • 10: Nivel de batería bajo
  • 11: Nivel de batería extremadamente bajo (pronto se deberá reemplazar la batería)
• El bit 7 se establece en 1 si la baliza está en el modo de protección contra seguimiento no deseado y en 0 en caso contrario.

Para producir el valor final de este byte, se realiza una operación XOR con el byte menos significativo de SHA256(r).

Ten en cuenta que r debe estar alineado con el tamaño de la curva. Agrega ceros como bits más significativos si su representación es más corta que 160 o 256 bits, o bien trunca los bits más significativos si su representación es más larga que 160 o 256 bits.

Si la baliza no admite la indicación del nivel de batería y no está en el modo de protección contra seguimiento no deseado, se permite omitir este byte por completo del anuncio.

Encriptación con EID

Para encriptar un mensaje m, un observador (que leyó Rx desde la baliza) haría lo siguiente:

1. Elige un número aleatorio s en Fp, como se define en la sección Cálculo del EID.
2. Compute S = s * G.
3. Calcula R = (Rx, Ry) sustituyendo en la ecuación de la curva y eligiendo un valor Ry arbitrario de los resultados posibles.
4. Calcula la clave AES de 256 bits k = HKDF-SHA256((s * R)x), donde (s * R)x es la coordenada x del resultado de la multiplicación de la curva. No se especificó la sal.
5. Sean URx y LRx los 80 bits superiores e inferiores de Rx, respectivamente, en formato big-endian. De manera similar, define USx y LSx para S.
6. Compute nonce = LRx || LSx.
7. Compute (m’, tag) = AES-EAX-256-ENC(k, nonce, m).
8. Envía (URx, Sx, m’, tag) al propietario, posiblemente a través de un servicio remoto no confiable.

Desencriptación de valores encriptados con el EID

El cliente del propietario, que posee la EIK y el exponente del período de rotación, desencripta el mensaje de la siguiente manera:

1. Dado URx, obtén el valor del contador de tiempo de baliza en el que se basa URx. Esto lo puede hacer el cliente del propietario calculando los valores de Rx para los valores del contador de tiempo de baliza del pasado reciente y el futuro cercano.
2. Dado el valor del contador de tiempo de baliza en el que se basa URx, calcula el valor anticipado de r como se define en la sección Cálculo del EID.
3. Calcula R = r * G y verifica que coincida con el valor de URx proporcionado por el avistador.
4. Calcula S = (Sx, Sy) sustituyendo en la ecuación de la curva y eligiendo un valor Sy arbitrario de los resultados posibles.
5. Calcula k = HKDF-SHA256((r * S)x), donde (r * S)x es la coordenada x del resultado de la multiplicación de la curva.
6. Compute nonce = LRx || LSx.
7. Compute m = AES-EAX-256-DEC(k, nonce, m’, tag).

Rotación de ID

Se debe usar una dirección BLE resoluble (RPA) o no resoluble (NRPA) para anunciar tramas de FHN. Se requiere la RPA para los dispositivos LE Audio (LEA) y se recomienda para otros dispositivos, con la excepción de los dispositivos de rastreo que no usan vinculación.

El anuncio de Vinculación rápida, el anuncio de FHN y las direcciones BLE correspondientes deben rotar al mismo tiempo. La rotación debe ocurrir cada 1,024 segundos en promedio. El punto preciso en el que el baliza comienza a anunciar el nuevo identificador debe ser aleatorio dentro de la ventana.

El enfoque recomendado para aleatorizar el tiempo de rotación es establecerlo en el próximo tiempo de rotación previsto (si no se aplicó ninguna aleatorización) más un factor de tiempo aleatorio positivo en el rango de 1 a 204 segundos.

Cuando el dispositivo está en el modo de protección contra rastreo no deseado, la dirección BLE del anuncio de FHN debe ser fija, pero el RPA del anuncio de FP no detectable (como Fast Pair) debe seguir rotando. Es aceptable usar direcciones diferentes para los distintos protocolos.

Recuperación ante cortes de energía

La resolución del identificador efímero está muy vinculada a su valor de reloj en el momento del anuncio, por lo que es importante que el proveedor pueda recuperar su valor de reloj si hay una pérdida de energía. Se recomienda que el proveedor escriba el valor actual del reloj en la memoria no volátil al menos una vez al día y que, en el momento del inicio, el proveedor verifique la NVM para ver si hay un valor presente desde el cual inicializar. Los resolutores del identificador efímero implementarían la resolución durante un período suficiente para permitir tanto la desviación razonable del reloj como este tipo de recuperación ante la pérdida de energía.

Los proveedores deben seguir haciendo todo lo posible para minimizar las desviaciones del reloj, ya que el período de resolución es limitado. Se debe implementar al menos un método adicional de sincronización del reloj (marcos de Fast Pair no detectables para publicidad o implementación del flujo de mensajes).

Lineamientos para la implementación de la Vinculación rápida

En esta sección, se describen aspectos especiales de la implementación de Fast Pair en proveedores que admiten FHN.

Lineamientos específicos para la etiqueta de ubicación

• Si el proveedor se vinculó, pero no se aprovisionó la FHN en un plazo de 5 minutos (o si se aplicó una actualización OTA mientras el dispositivo estaba vinculado, pero no se aprovisionó la FHN), el proveedor debe volver a su configuración de fábrica y borrar las claves de la cuenta almacenadas.
• Después de que se vincula el proveedor, no debe cambiar su dirección MAC hasta que se aprovisione la FHN o hasta que transcurran 5 minutos.
• Si se borra la clave de identidad efímera del dispositivo, este debe restablecer la configuración de fábrica y borrar también las claves de la cuenta almacenadas.
• El proveedor debe rechazar los intentos normales de vinculación por Bluetooth y aceptar solo la vinculación con Fast Pair.
• El proveedor debe incluir un mecanismo que permita a los usuarios detener temporalmente la publicidad sin restablecer la configuración de fábrica del dispositivo (por ejemplo, presionando una combinación de botones).
• Después de una pérdida de energía, el dispositivo debe anunciar tramas de Vinculación rápida no detectables hasta la siguiente invocación de read beacon parameters. Esto permite que el buscador detecte el dispositivo y sincronice el reloj, incluso si se produjo una desviación significativa del reloj.
• Cuando se anuncian marcos de Vinculación rápida no detectables, no se deben habilitar las indicaciones de la IU.
• Los marcos de Fast Pair detectables no se deben anunciar mientras el proveedor esté aprovisionado para FHN.
• El proveedor no debe exponer información de identificación de manera no autenticada (p.ej., nombres o identificadores).

Lineamientos específicos para dispositivos Bluetooth Classic

En esta sección, se describen aspectos especiales de los dispositivos Bluetooth clásicos que admiten FHN.

Aprovisionamiento de FHN de dispositivos ya vinculados

El proveedor no siempre se aprovisiona para FHN cuando se vincula con el buscador, sino un tiempo después. En ese caso, es posible que el proveedor no tenga una dirección MAC de BLE actualizada que se requiera para establecer una conexión GATT. El proveedor debe admitir al menos una de las siguientes formas para que el buscador obtenga su dirección BLE mientras ya está vinculado:

• El proveedor puede anunciar periódicamente los datos de la cuenta de Fast Pair que permiten que el buscador encuentre su dirección BLE a través de un análisis de BLE.
  Este enfoque es adecuado para los proveedores que no implementan el flujo de mensajes.
• El proveedor puede proporcionar estos datos a través del flujo de mensajes de Vinculación rápida a través de Bluetooth clásico.
  Este enfoque es adecuado para los proveedores que no anuncian marcos de Vinculación rápida mientras están conectados al buscador a través de Bluetooth.

Admitir ambos enfoques aumenta las probabilidades de que el usuario pueda aprovisionar el dispositivo para la FHN.

Flujo de mensajes de Vinculación rápida

El proveedor puede implementar el flujo de mensajes de Vinculación rápida y usarlo para notificar al buscador sobre la información del dispositivo. La implementación del flujo de mensajes habilita ciertas funciones, como se describe en esta sección.

El proveedor debe enviar mensajes de información del dispositivo una vez cada vez que se establezca el canal RFCOMM de la transmisión de mensajes.

Versión de firmware (código de información del dispositivo 0x09) y capacidad de seguimiento

Cuando una actualización de firmware agrega compatibilidad con FHN al proveedor, un buscador conectado puede notificar al usuario sobre esto y ofrecerle aprovisionarlo. De lo contrario, el usuario deberá navegar a la lista de dispositivos Bluetooth de forma manual para iniciar el aprovisionamiento de FHN.

Para permitirlo, el proveedor debe usar la propiedad Firmware version (versión de firmware, código 0x09) para informar un valor de cadena que represente la versión de firmware. Además, el proveedor debe admitir el protocolo que le permite al buscador conocer los cambios de capacidad debido a las actualizaciones de firmware.

Octeto	Tipo de datos	Descripción	Valor
0	uint8	Evento de información del dispositivo	0x03
1	uint8	Versión de firmware	0x09
2 a 3	uint16	Longitud de datos adicionales	varía
var	array de bytes	Cadena de versión	varía

Tabla 18: Evento de información del dispositivo: versión de firmware actualizada.

Al recibir una solicitud de actualización de capacidad (0x0601), si el proveedor habilitó la compatibilidad con el seguimiento de FHN, debe responder como se muestra en la tabla 12.

Octeto	Tipo de datos	Descripción	Valor
0	uint8	Evento de sincronización de capacidad del dispositivo	0x06
1	uint8	Seguimiento de FHN	0x03
2 a 3	uint16	Longitud de datos adicionales	0x0007
4	uint8	Estado de aprovisionamiento de FHN	0x00 si no se aprovisionó; 0x01 si se aprovisionó con alguna cuenta
5 - 10	array de bytes	Dirección MAC de BLE actual del dispositivo	varía

Tabla 19: Evento de sincronización de capacidad del dispositivo: Se agregó la capacidad de seguimiento.

Identificador efímero actual (código 0x0B de información del dispositivo)

El proveedor puede usar el identificador efímero actual (código 0x0B) para informar el EID actual y el valor del reloj cuando se aprovisiona el proveedor para FHN, y sincronizar el buscador en caso de una desviación del reloj (por ejemplo, debido a una batería agotada). De lo contrario, el buscador iniciará una conexión más costosa y menos confiable para este propósito.

Octeto	Tipo de datos	Descripción	Valor
0	uint8	Evento de información del dispositivo	0x03
1	uint8	Identificador efímero actual	0x0B
2 a 3	uint16	Longitud de datos adicional	0x0018 o 0x0024
4 - 7	array de bytes	Valor del reloj	Ejemplo: 0x13F9EA80
8 a 19 o 31	array de bytes	EID actual	Ejemplo: 0x1122334455667788990011223344556677889900

Tabla 20: Evento de información del dispositivo: Sincronización del reloj.

Restablecer configuración de fábrica

En el caso de los dispositivos que admiten el restablecimiento de la configuración de fábrica, si se realiza este restablecimiento, el proveedor debe dejar de emitir balizas y borrar la clave de identidad efímera y todas las claves de cuenta almacenadas, incluida la clave de cuenta del propietario.

Después de un restablecimiento de la configuración de fábrica (manual o programático), el proveedor no debe comenzar a anunciar la Vinculación rápida de inmediato para evitar que el flujo de vinculación comience inmediatamente después de que el usuario borre el dispositivo.

Prevención de rastreo no deseado

Los dispositivos FHN certificados también deben cumplir con los requisitos de la versión de implementación de la especificación multiplataforma para Detecting Unwanted Location Trackers (DULT).

Lineamientos pertinentes específicos para FHN para cumplir con las especificaciones de DULT:

• Cualquier dispositivo compatible con FHN debe estar registrado en la Consola de dispositivos cercanos y tener activada la capacidad "Buscar concentrador".
• El dispositivo debe implementar el servicio y la característica de accesorio que no es propietario definidos en la versión de implementación de la especificación de DULT, incluidas las operaciones de Información del accesorio y los Controles de no propietario.
• Durante el período de compatibilidad con versiones anteriores, según se define en la especificación de DULT, no se realizan cambios en el fotograma publicitado, tal como se define en este documento.
• El "modo de protección contra seguimiento no deseado" que se define en este documento se correlaciona con el "estado separado" que define la especificación de DULT.
• Lineamientos para implementar los opcodes de Accessory Information:
  • Get_Product_Data debe devolver el ID del modelo proporcionado por la consola, con ceros a la izquierda para cumplir con el requisito de 8 bytes. Por ejemplo, el ID de modelo 0xFFFFFF se devuelve como 0x0000000000FFFFFF.
  • Get_Manufacturer_Name y Get_Model_Name deben coincidir con los valores proporcionados en la consola.
  • Get_Accessory_Category puede devolver el valor genérico "Localizador" si ninguna otra categoría se ajusta mejor al tipo de dispositivo.
  • Get_Accessory_Capabilities debe indicar la compatibilidad con el timbre y la búsqueda del identificador BLE.
  • Get_Network_ID debería devolver el identificador de Google (0x02).
• Lineamientos para implementar el opcode Get_Identifier:
  • La operación solo debe devolver una respuesta válida durante 5 minutos después de que el usuario activó el modo de "identificación", que requiere una combinación de pulsaciones de botones. Una señal visual o de audio debe indicarle al usuario que el proveedor ingresó en ese modo. Las instrucciones específicas del modelo para activar ese modo se deben proporcionar a Google como requisito para la certificación y, al menos, 10 días antes de cualquier actualización o modificación de las instrucciones.
  • La respuesta se construye de la siguiente manera: los primeros 10 bytes del identificador efímero actual, seguidos de los primeros 8 bytes de HMAC-SHA256(recovery key, the truncated current ephemeral identifier).
• Lineamientos para implementar el identificador a través de NFC:
  • Como URL, usa find-my.googleapis.com/lookup.
  • Como parámetro e, usa la misma respuesta que se construyó para Get_Identifier, codificada en hexadecimal.
  • Como parámetro pid, usa la misma respuesta que se construyó para Get_Product_Data, codificada en hexadecimal.
• Es obligatorio que el dispositivo incluya un generador de sonido y admita la función de llamada. Según las especificaciones de DULT, el dispositivo de alerta debe emitir un sonido con una sonoridad máxima de 60 fonios, como mínimo, según se define en la norma ISO 532-1:2017.
• Lineamientos para implementar el opcode Sound_Start:
  • El comando debe activar el sonido en todos los componentes disponibles.
  • Se debe usar el volumen máximo admitido.
  • La duración recomendada para el timbre es de 12 segundos.
• Las etiquetas de localizador deben incluir un mecanismo que permita a los usuarios detener temporalmente la publicidad sin restablecer la configuración de fábrica del dispositivo (por ejemplo, presionando una combinación de botones).
  • Las instrucciones para inhabilitar la función deben estar documentadas en una URL disponible públicamente y proporcionarse a Google como requisito para la certificación y, al menos, 10 días antes de cualquier actualización o modificación de las instrucciones.
  • La URL debe admitir la localización. Según el cliente, el idioma se proporcionará como un parámetro de consulta ("hl=en") o con el encabezado HTTP "accept-language".

Lineamientos de protocolos intercambiables

• Solo se debe usar un protocolo a la vez. Asegúrate de que no haya más de una red que pueda operar en el dispositivo de forma simultánea. Este requisito es necesario para garantizar que no se mezclen datos sensibles del usuario entre los diferentes protocolos.
• Se sugiere incorporar un flujo de trabajo de restablecimiento completo en el dispositivo que permita al usuario volver a configurarlo con una red diferente.
• El proceso de actualización de un dispositivo a una red debe ser fácil de usar y equitativo entre las redes. El usuario debe poder elegir qué red quiere usar sin darle preferencia a una de las redes. El equipo de Google debe aprobar este flujo.

Actualizaciones de firmware

El socio debe administrar el proceso y la distribución de las actualizaciones OTA con su propio flujo de trabajo de la app para dispositivos móviles o web.

La Vinculación rápida admite la entrega de notificaciones al usuario para informarle sobre las actualizaciones inalámbricas disponibles. Para usar este mecanismo, haz lo siguiente:

• La versión de firmware más reciente debería actualizarse en la consola de dispositivos cercanos.
• Se debe configurar una app complementaria en la consola de dispositivos cercanos. Debe admitir la intención de actualización de firmware.
• El proveedor debe implementar la característica GATT Firmware revision.

Para evitar el seguimiento, se debe restringir el acceso a la característica Revisión de firmware. Primero, Seeker leerá el estado de aprovisionamiento y proporcionará una clave de autenticación, como se define en esta especificación, y solo entonces leerá la revisión del firmware. Esto se hará a través de la misma conexión. Si se intenta leer la revisión del firmware y el proveedor no está vinculado ni se completó correctamente una operación autenticada a través de esa misma conexión, el proveedor debe devolver un error de no autenticación.

Compatibilidad

La red de Localizador requiere que los servicios de ubicación y el Bluetooth estén activados. Requiere servicio de telefonía celular o conexión a Internet. Funciona en Android 9 y versiones posteriores en determinados países para usuarios que cumplen con los requisitos de edad.

Registro de cambios

Versión de FHN	Fecha	Comentario
v1		Es el lanzamiento inicial de la especificación de FHN para el acceso anticipado.
v1.1	Feb 2023	Se agregó una indicación en texto no cifrado del modo de protección contra el seguimiento no deseado. Se agregó una opción para omitir la autenticación de las solicitudes de llamada mientras se está en el modo de protección contra el rastreo no deseado.
v1.2	Abr 2023	Se actualizó la definición de la AK de un propietario. Se agregó una recomendación para recuperarse de la pérdida de energía en las etiquetas de ubicación. Se agregó una aclaración sobre la aleatorización de direcciones MAC. Se agregó una aclaración sobre la rotación de la dirección MAC cuando se está en el modo de protección contra el rastreo no deseado. Se agregó un lineamiento sobre cómo desactivar una etiqueta de localizador.
v1.3	Dic 2023	Se agregó una aclaración sobre la información de identificación que exponen las etiquetas de ubicación. Se agregó un requisito para implementar la especificación de prevención del seguimiento no deseado. Se agregaron lineamientos para dispositivos con protocolos intercambiables.