Especificación del accesorio de red de Encontrar mi dispositivo

v1.3

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

Nota: Si te interesa integrar las especificaciones de accesorios de Encontrar mi dispositivo, envía un formulario de propuesta de dispositivo. Pronto compartiremos más detalles sobre los pasos de integración y la certificación.

Especificación de GATT

Se debe agregar una característica de atributos genéricos (GATT) adicional al servicio de vinculación rápida con la siguiente semántica:

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

Tabla 1: Características del servicio de vinculación rápida para FMDN.

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 de la característica de la tabla 1, lo que genera un búfer con el siguiente formato:

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

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

Luego, el buscador calcula una clave de autenticación única que se usará 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 el conocimiento de una o más de las siguientes claves:

• Clave de cuenta: Es la clave de 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 Acciones de píxeles contadores. 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 le acaben los espacios de claves de cuenta gratuitos.

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

  • Los proveedores que obtengan compatibilidad con FMDN después de vincularse (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 píxeles contadores después de la actualización de firmware, siempre que el usuario que realizó la actualización sea el propietario actual del proveedor.

• Clave de identidad efímera (EIK): Es una clave de 32 bytes que el buscador elige de forma aleatoria cuando realiza el proceso de aprovisionamiento de FMDN. Esta clave se usa para derivar las claves de criptografía que se usan para encriptar de extremo a extremo los informes de ubicación. El Buscador nunca se lo 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), se trunca 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 seguimiento no deseado: Se define como SHA256(ephemeral identity key || 0x03), truncada 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.

Octet	Tipo de datos	Descripción	Valor
0	uint8	ID de datos	0x00: Lee los parámetros del píxel contador 0x01: Lee el estado de aprovisionamiento 0x02: Establece la clave de identidad efímera 0x03: Borrar clave de identidad efímera
1	uint8	Longitud de los datos	varía
Entre 2 y 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, AES-ECB-128 encriptado con la clave de la cuenta. Si el proveedor ya tiene un conjunto de claves de identidad efímera, envía también 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 píxeles contadores.

Octet	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
Entre 2 y 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 los píxeles contadores.

Octet	Tipo de datos	Descripción	Valor
0	uint8	ID de datos	0x05: Hacer sonar 0x06: Leer el estado del timbre
1	uint8	Longitud de los datos	varía
Entre 2 y 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 del tono, la duración del tono y el volumen del tono. 0x06: n/a

Tabla 4: Solicitud de llamada.

Octet	Tipo de datos	Descripción	Valor
0	uint8	ID de datos	0x07: Activa el modo de protección contra el seguimiento no deseado 0x08: Desactiva el modo de protección contra seguimientos no deseados
1	uint8	Longitud de los datos	varía
Entre 2 y 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 seguimientos no deseados.

Las operaciones de escritura correctas activan las notificaciones que se indican en la tabla 6.

Las notificaciones con un ID de datos distinto de 0x05: Cambio de estado de la llamada deben enviarse 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 del píxel contador 0x01: Lee el estado de aprovisionamiento 0x02: Establece la clave de identidad efímera 0x03: Borra la clave de identidad efímera 0x04: Lee la clave de identidad efímera con el consentimiento del usuario 0x05: Cambio de estado de la llamada 0x06: Lee el estado de llamada. 0x07: Activa el modo de protección contra el seguimiento no deseado 0x08: Desactiva el modo de protección contra seguimientos no deseados
1	uint8	Longitud de los datos	varía
Entre 2 y 9	array de bytes	Autenticación	Información detallada 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 timbre, encriptados con AES-ECB-128 con la clave de la cuenta (relleno con cero) 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, AES-ECB-128 encriptada con la clave de la cuenta 0x05: 4 bytes que indican el estado nuevo y el activador del cambio 0x06: 3 bytes que indican los componentes que están sonando de forma activa y la cantidad de decisegundos restantes para sonar Otros IDs de datos usan datos adicionales vacíos

Tabla 6: Respuesta del servicio de píxeles contadores.

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 muestra en respuesta a una solicitud de escritura cuando falla la autenticación (incluido el caso en el que se usó un nonce antiguo).
0x81	Valor no válido	Se muestra cuando se proporciona un valor no válido o los datos recibidos tienen una cantidad inesperada de bytes.
0x82	Sin consentimiento del usuario	Se muestra en respuesta a una solicitud de escritura con el ID de datos 0x04: Leer 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

Lee el parámetro del píxel contador

El buscador puede consultar al proveedor los parámetros del píxel contador realizando una operación de escritura en la característica que consiste en 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 muestra un error de autenticación.

Si se realiza de forma correcta, el proveedor notifica con una respuesta de la tabla 6 con el ID de datos 0x00. El proveedor construye el segmento de datos de la siguiente manera:

Octet	Tipo de datos	Descripción	Valor
0	uint8	Potencia calibrada	La potencia calibrada tal como se recibió 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 de reloj	Es el valor de reloj actual 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	La cantidad de componentes que pueden sonar: 0x00: Indica que el dispositivo no puede sonar. 0x01: Indica que solo un componente puede hacer sonar el dispositivo. 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 la funda, pueden sonar de forma independiente.
7	uint8	Funciones de timbre	Las opciones compatibles son las siguientes: 0x00: No está disponible la selección de volumen de llamada. 0x01: Hay disponible una selección de volumen de tono. Si se establece, el proveedor debe aceptar y controlar 3 niveles de volumen, como se indica en Operación de timbre.
8-15	array de bytes	Relleno	Relleno cero para la encriptación AES

Los datos deben estar encriptados con AES-ECB-128 con 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).

Cómo leer el estado de aprovisionamiento del píxel contador

El buscador puede consultar al proveedor el estado de aprovisionamiento de la baliza realizando una operación de escritura en la característica que consiste en 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 cuenta almacenadas en el dispositivo.

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

Si se realiza de forma correcta, el proveedor notifica con una respuesta de la tabla 6 con el ID de datos 0x01. El proveedor construye el segmento de datos de la siguiente manera:

Octet	Tipo de datos	Descripción	Valor
0	uint8	Estado de aprovisionamiento	Una máscara de bits con los siguientes valores: Bit 1 (0x01): Se establece si se configuró una clave de identidad efímera para el dispositivo. Bit 2 (0x02): Se establece si la clave de autenticación única proporcionada coincide con la clave de la cuenta del propietario.
De 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 el píxel contador, 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).

Configura una clave de identidad efímera

Para aprovisionar un proveedor desaprovisionado como una baliza de FMDN o cambiar la clave de identidad efímera de un proveedor ya aprovisionado, el Seeker 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 de un solo uso proporcionada coincide con la clave de la cuenta del propietario.
• Si se proporcionó un hash de una clave de identidad efímera, la clave de identidad efímera con hash 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 ya no se haya aprovisionado como un píxel contador de FMDN.

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

Si se realiza correctamente, AES-ECB-128 recupera la clave de identidad efímera desencriptando con la clave de cuenta coincidente. La clave debe conservarse en el dispositivo y, desde ese momento, el proveedor debe comenzar a anunciar los fotogramas FMDN. La clave de identidad efímera nueva se aplica inmediatamente después de que finaliza 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 la 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 de un solo uso 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 un píxel contador de FMDN o falla la verificación, se muestra un error de autenticación.

Si se realiza correctamente, el proveedor olvida la clave y deja de anunciar tramas de FMDN. 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).

Lee la clave de identidad efímera con el consentimiento del usuario

Esta opción solo está disponible para recuperar una clave perdida, ya que el buscador solo la almacena de forma local. Por lo tanto, esta función está disponible solo cuando el dispositivo está en modo de vinculación o durante un tiempo limitado después de que se presiona 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 simple, pero no almacena la EIK.

Para leer el 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 con hash 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 muestra un error de autenticación.

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

Si se realiza correctamente, el proveedor notifica 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 hacer sonar

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:

Octet	Tipo de datos	Descripción	Valor
0	uint8	Operación de timbre	Una máscara de bits con los siguientes valores: Bit 1 (0x01): Hacer sonar auricular derecho Bit 2 (0x02): Tono de llamada a la izquierda Bit 3 (0x04): Caso de timbre 0xFF: Hacer sonar todos los componentes 0x00: Detener el sonido
1 - 2	uint16	Tiempo de espera	El tiempo de espera en decisegundos. No debe ser cero ni ser mayor que el equivalente a 10 minutos. El proveedor usa este valor para determinar durante cuánto tiempo debe sonar antes de silenciarse. El tiempo de espera anula el que ya está vigente si ya está sonando algún componente del dispositivo. Si la operación de anillo se establece en 0x00, se ignora el tiempo de espera.
3	uint8	Volumen	0x00: Configuración predeterminada 0x01: Bajo 0x02: Medio 0x03: Alto El significado exacto de estos valores depende de la implementación.

Cuando recibe 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 un píxel contador de FMDN o falla la verificación, se muestra un error de autenticación. Sin embargo, si el proveedor tiene activada la protección contra el seguimiento no deseado y la solicitud de activación de la protección contra el seguimiento no deseado tenía activada la marca de autenticación de omisión de timbre, el proveedor debe omitir esa verificación. Se espera que el solicitante proporcione los datos de autenticación, pero se pueden establecer en un valor arbitrario.

Cuando comienza o finaliza el tono de llamada, 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:

Octet	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 de rango). 0x02: Detenido (se agotó el tiempo de espera) 0x03: Detener (se presiona el botón) 0x04: Detenido (solicitud de GATT)
1	uint8	Componentes de timbre	Una máscara de bits de los componentes que suenan de forma activa, como se define en la solicitud.
2 - 3	uint16	Tiempo de espera	El tiempo restante para hacer sonar en decisegundos. Si el dispositivo dejó de sonar, se debe mostrar 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 sonido solicitado cuando se recibe una solicitud para sonar o para dejar de sonar, el proveedor debe enviar una notificación con un estado de timbre o 0x00: Iniciado o 0x04: Detenido (solicitud GATT), respectivamente. Esta solicitud anula los parámetros del estado existente para que se pueda extender la duración del sonido.

Si el proveedor tiene un botón físico (o si está habilitada la función de sensor táctil), ese botón debería detener la función de timbre si se presiona mientras el timbre está activo.

Nota: En el caso de los proveedores que incluyen la detección de uso en la cabeza, considera verificar que el dispositivo no esté en la cabeza antes de que suene con volumen máximo. Si la detección de uso en la cabeza no es compatible o no es confiable, aumenta el volumen gradualmente (para que el usuario tenga tiempo de detener el timbre o quitarse los auriculares).

Nota: El proveedor debe seguir sonando independientemente del estado de conexión del buscador que solicitó el timbre. Esto evita que el dispositivo deje de sonar porque se pierde la conexión debido a que el cliente se aleja demasiado del dispositivo. Entonces, no se puede encontrar el dispositivo porque dejó de sonar y está demasiado lejos del cliente para que vuelva a sonar.

Obtén el estado de la llamada del píxel contador

Para obtener el estado de llamada del píxel contador, 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 de anillo.

Si el proveedor no está aprovisionado como una baliza FMDN o si la verificación falla, el proveedor muestra un error no autenticado.

Si se realiza correctamente, el proveedor notifica con una respuesta de la tabla 6 con el ID de datos 0x06. El proveedor construye el segmento de datos de la siguiente manera:

Octet	Tipo de datos	Descripción	Valor
0	uint8	Componentes de timbre	Son los componentes que suenan de forma activa, como se define en la solicitud de tono.
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 mostrar 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 el seguimiento no deseado

El objetivo del modo de protección contra el seguimiento no deseado es 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 Encontrar mi dispositivo puede reenviar una solicitud de activación no deseada del modo de protección contra seguimiento a través de la red de Encontrar mi dispositivo. 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 seguimiento no deseado.

Para activar o desactivar el modo de protección contra seguimiento no deseado del píxel contador, 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:

Octet	Tipo de datos	Descripción	Valor
0	uint8	Marcas de control	0x01: Omitir la autenticación por timbre. Cuando se establece, las solicitudes de timbre no se autentican mientras el dispositivo está en 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 tienen efecto hasta que se desactiva el modo de protección contra el seguimiento no deseado.

El proveedor verifica que la clave de autenticación única proporcionada coincida con la clave de protección contra seguimiento no deseada. Si el proveedor no se aprovisiona como un píxel contador de FMDN o falla la verificación, se muestra un error de autenticación.

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

Cuando se inhabilita 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 seguimiento no deseada.
• La clave de identidad efímera con hash coincide con la clave de identidad efímera actual.

Si el proveedor no se aprovisiona como un píxel contador de FMDN o falla la verificación, el proveedor muestra un error de autenticación.

Cuando se desactiva el modo de protección contra seguimiento no deseado, el píxel contador 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 se realiza correctamente, el proveedor notifica con una respuesta de la tabla 6 con 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).

Marcos anunciados

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

Nota: Se recomienda publicar las tramas de FMDN incluso cuando el dispositivo está en modo de bajo consumo, ya que esto permite encontrar el dispositivo si se pierde. En algunos dispositivos, es posible que no se puedan publicar anuncios cuando el dispositivo está apagado debido a las implicaciones en la duración de la batería. En esos casos, se recomienda activar el dispositivo periódicamente y publicar anuncios durante un período breve (p.ej., activarlo cada 10 minutos y publicar anuncios durante 10 segundos).

La trama de FMDN lleva una clave pública que usa cualquier cliente compatible que contribuya a la red de crowdsourcing para encriptar los informes de ubicación. Hay dos tipos de claves de curva elíptica disponibles: una clave de 160 bits que se ajusta a tramas BLE 4 heredadas o una clave de 256 bits que requiere BLE 5 con capacidades publicitarias extendidas. La implementación del proveedor determina qué curva se usa.

Nota: El uso de claves de 256 bits significa que los teléfonos más antiguos que no admiten BLE 5 no pueden analizar ni informar dispositivos de publicidad, lo que reduce el tamaño de la red.

Una trama FMDN se estructura de la siguiente manera.

Octeto	Valor	Descripción
0	0x02	Longitud
1	0 × 01	Marca el valor del tipo de datos
2	0x06	Marca datos
3	0x18 o 0x19	Longitud
4	0 × 16	Valor del tipo de datos de los datos del servicio
5	0xAA	UUID de servicio de 16 bits
6	0xFE	…
7	0 x 40 o 0 x 41	Tipo de trama FMDN con indicación de modo de protección contra el seguimiento no deseado
8.27		Identificador efímero de 20 bytes
28		Marcas con hash

Tabla 8: Trama FMDN que admite una curva de 160 bits.

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

Octet	Valor	Descripción
0	0x02	Longitud
1	0 × 01	Marca el valor del tipo de datos
2	0x06	Marca datos
3	0x24 o 0x25	Longitud
4	0 × 16	Valor del tipo de datos de los datos del servicio
5	0xAA	UUID de servicio de 16 bits
6	0xFE	…
7	0 x 40 o 0 x 41	Tipo de trama FMDN con indicación de modo de protección contra el seguimiento no deseado
8..39		Identificador efímero de 32 bytes
40		Marcas con hash

Tabla 9: Marco de FMDN compatible con una curva de 256 bits

Procesamiento de identificador efímero (EID)

AES-ECB-256 encripta la siguiente estructura de datos con la clave de identidad efímera para generar un valor aleatorio:

Octet	Campo	Descripción
0 - 10	Relleno	Valor = 0xFF
11	K	Exponente del período de rotación
12 - 15	TS[0]...TS[3]	Contador de tiempo del píxel contador, en formato big-endian de 32 bits Se borran los bits más bajos.
16 - 26	Relleno	Valor = 0x00
27	K	Exponente del período de rotación
28 - 31	TS[0]…TS[3]	Contador de tiempo del contador de tiempo del contador, en formato big-endian de 32 bits. Se borran los bits más bajos.

Tabla 10: Construcción de un número seudoaleatorio.

Nota: Se supone que el dispositivo tiene un contador de tiempo de 32 bits en segundos.

Nota: El exponente del período de rotación es fijo y se establece en 10, lo que corresponde a 1,024 segundos.

El resultado de este procesamiento es un número de 256 bits, denominado r'.

En el resto del cálculo, se usan SECP160R1 o SECP256R1 para las operaciones criptográficas de curva elíptica. Consulta las definiciones de curva en SEC 2: Parámetros de dominio de curva elíptica recomendados, que define Fp, n y G a los que se hace referencia a continuación.

r' ahora se proyecta en el campo finito Fp cuando se calcula 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. El píxel contador anuncia Rx, que es la coordenada x de R, como su identificador efímero.

Marcas con hash

El campo de marcas con hash se calcula de la siguiente manera (se hace referencia a los bits de la más significativa a la menos significativa):

• Bits del 0 al 4: Reservados (se establecen 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 muy bajo (se debe reemplazar la batería pronto)
• El bit 7 se establece en 1 si la baliza está en modo de protección contra seguimiento no deseado, y en 0 si no lo está.

Para producir el valor final de este byte, se realiza un xor con el byte menos importante de SHA256(r).

Ten en cuenta que r debe alinearse con el tamaño de la curva. Se deben agregar ceros como los bits más significativos si su representación es más corta que 160 o 256 bits, o bien los bits más significativos deben truncarse si su representación es mayor que 160 o 256 bits.

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

Encriptación con EID

Nota: Los siguientes detalles para la encriptación y desencriptación con EID solo se incluyen para completar la especificación. Solo el buscador los implementa, no el proveedor.

Para encriptar un mensaje m, un observador (que leyó Rx del píxel contador) haría lo siguiente:

1. Elige un número aleatorio s en Fp, como se define en la sección Cálculo de EID.
2. Calcula S = s * G.
3. Calcula R = (Rx, Ry) mediante la sustitución en la ecuación de la curva y elige 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 curvas. No se especificó la sal.
5. Supongamos que URx y LRx son los 80 bits superiores e inferiores de Rx, respectivamente, en formato big-endian. De manera similar, define USx y LSx para S.
6. Procesar nonce = LRx || LSx
7. Procesar (m’, tag) = AES-EAX-256-ENC(k, nonce, m)
8. Enviar (URx, Sx, m’, tag) al propietario, posiblemente a través de un servicio remoto no confiable

Desencriptación de valores encriptados con EID

El cliente del propietario, que está en posesión de EIK y el exponencial del período de rotación, desencripta el mensaje de la siguiente manera:

1. Dado URx, obtén el valor del contador de tiempo del píxel contador en el que se basa URx. El cliente del propietario puede calcular los valores de Rx para los valores del contador de tiempo de la baliza del pasado reciente y el futuro cercano.
2. Dado el valor del contador de tiempo del píxel contador 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 si coincide con el valor de URx que proporciona el visor.
4. Calcula S = (Sx, Sy) mediante la sustitución en la ecuación de la curva y la elección de 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. Calcula nonce = LRx || LSx.
7. Calcula m = AES-EAX-256-DEC(k, nonce, m’, tag).

Rotación de ID

Se debe usar una dirección BLE resolvable (RPA) o no resolvable (NRPA) para los tramas de FMDN publicitarias. La RPA es obligatoria para los dispositivos LE Audio (LEA) y se recomienda para otros dispositivos, a excepción de las etiquetas de localización que no usan vinculación.

El anuncio de Vinculación rápida, el anuncio de FMDN y las direcciones BLE correspondientes deben rotar al mismo tiempo. La rotación debe ocurrir cada 1,024 segundos en promedio. El punto exacto en el que el píxel contador comienza a anunciar el identificador nuevo debe ser aleatorio dentro del período.

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 y positivo en el rango de 1 a 204 segundos.

Cuando el dispositivo está en el modo de protección contra seguimiento no deseado, se debe corregir la dirección BLE del anuncio FMDN, pero la RPA del anuncio no detectable de FP (como la Vinculación rápida) debe seguir girando. Se puede usar direcciones diferentes para los diferentes protocolos.

Recuperación ante un corte de energía

La resolución del identificador efímero está fuertemente 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 se produce una pérdida de energía. Se recomienda que el proveedor escriba su valor de reloj actual en la memoria no volátil al menos una vez al día y que, durante el inicio, verifique la NVM para ver si hay un valor presente desde el que inicializar. Los resolutores del identificador efímero implementarían la resolución en un período suficiente para permitir una deriva de reloj razonable y este tipo de recuperación de pérdida de energía.

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

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

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

Lineamientos específicos de las etiquetas de ubicación

• Si el proveedor se vinculó, pero no se aprovisionó FMDN en un plazo de 5 minutos (o si se aplicó una actualización OTA mientras el dispositivo está vinculado, pero no aprovisionado para FMDN), 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 debería cambiar su dirección MAC hasta que se aprovisione la FMDN o hasta que transcurran 5 minutos.
• Si se borra la clave de identidad efímera del dispositivo, este debería realizar un restablecimiento de la configuración de fábrica y borrar las claves de cuenta almacenadas.
• El proveedor debe rechazar los intentos normales de vinculación por Bluetooth y aceptar solo la vinculación por Vinculación rápida.
• 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 un corte de energía, el dispositivo debe anunciar fotogramas de Vinculación rápida no detectables hasta la siguiente invocación de los parámetros de la baliza de lectura. Esto permite que el buscador detecte el dispositivo y sincronice el reloj, incluso si se produjo un desvío significativo 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 vinculación rápida detectables no deben anunciarse mientras el proveedor se aprovisiona para FMDN.
• El proveedor no debe exponer información de identificación de manera no autenticada (p.ej., nombres o identificadores).

Lineamientos específicos de la versión clásica de Bluetooth para dispositivos

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

Aprovisionamiento de FMDN de dispositivos ya sincronizados

El proveedor no siempre se aprovisiona para FMDN 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 BLE actualizada que se requiere 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 publicar periódicamente los datos de la cuenta de Vinculación rápida que permiten que el dispositivo de búsqueda encuentre su dirección BLE a través de un análisis 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 tramas de Vinculación rápida mientras están conectados al buscador a través de Bluetooth.

La compatibilidad con ambos enfoques aumenta las probabilidades de que el usuario pueda aprovisionar el dispositivo para FMDN.

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 establece el canal RFCOMM de transmisión de mensajes.

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

Cuando una actualización de firmware agrega compatibilidad con FMDN al proveedor, un buscador conectado puede notificarle al usuario al respecto y ofrecerse a aprovisionarlo. De lo contrario, el usuario debe navegar a la lista de dispositivos Bluetooth de forma manual para iniciar el aprovisionamiento de FMDN.

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

Octet	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 los datos adicionales	varía
var	array de bytes	Cadena de versión	varía

Tabla 11: Evento de información del dispositivo (versión de firmware actualizada)

Cuando recibe una solicitud de actualización de capacidades (0x0601), si el proveedor habilitó la compatibilidad con el seguimiento de FMDN, debe responder como se muestra en la tabla 12.

Octeto	Tipo de datos	Descripción	Valor
0	uint8	Evento de sincronización de capacidades del dispositivo	0x06
1	uint8	Seguimiento de FMDN	0x03
2 a 3	uint16	Longitud de datos adicionales	0 × 0007
4	uint8	Estado de aprovisionamiento de FMDN	0x00 si no se aprovisionó; 0x01 si lo aprovisionó cualquier cuenta
5 - 10	array de bytes	La dirección MAC BLE actual del dispositivo	varía

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

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

El proveedor puede usar el identificador efímero actual (código 0x0B) para informar el EID y el valor del reloj actuales cuando el proveedor se aprovisiona para FMDN, a fin de sincronizar el Seeker en caso de un desvío del reloj (por ejemplo, debido a que se agotó la batería). De lo contrario, el buscador inicia una conexión más costosa y menos confiable para este fin.

Octet	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 adicionales	0x0018 o 0x0024
4 - 7	array de bytes	Valor del reloj	Ejemplo: 0x13F9EA80
De 8 a 19 o 31	array de bytes	EID actual	Ejemplo: 0x1122334455667788990011223344556677889900

Tabla 13: 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 un restablecimiento de la configuración de fábrica, el proveedor debe dejar de enviar píxeles contadores 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 Fast Pair de inmediato para evitar que el flujo de vinculación comience inmediatamente después de que el usuario borre el dispositivo.

Prevención del seguimiento no deseado

Los dispositivos FMDN certificados también deben cumplir con los requisitos de la versión de implementación de la especificación multiplataforma para la detección de dispositivos de rastreo de ubicación no deseados (DULT).

Lineamientos relevantes específicos de la FMDN para cumplir con la especificación DULT:

• Cualquier dispositivo compatible con FMDN debe estar registrado en la consola de dispositivos cercanos y tener activada la función "Encontrar mi dispositivo".
• El dispositivo debe implementar el servicio de accesorios para personas que no son propietarios y la característica definida en la versión de implementación de la especificación de DULT, incluidas las operaciones de información del accesorio y los controles para usuarios no propietarios.
• Durante el período de retrocompatibilidad, como se define en la especificación de DULT, no se realizan cambios en la trama anunciada, como se define en este documento.
• El "modo de protección contra el seguimiento no deseado" que se define en este documento se asigna al "estado separado" que define la especificación de DULT.
• Lineamientos para implementar los opcodes de Información de accesorios:
  • Get_Product_Data debe mostrar el ID de modelo que proporciona la consola, con padding cero para ajustarse al requisito de 8 bytes. Por ejemplo, el ID de modelo 0xFFFFFF se muestra como 0x0000000000FFFFFF.
  • Get_Manufacturer_Name y Get_Model_Name deben coincidir con los valores proporcionados en la consola.
  • Get_Accessory_Category puede mostrar el valor genérico "Localizador de ubicación" si no hay otra categoría que se ajuste mejor al tipo de dispositivo.
  • Get_Accessory_Capabilities debe indicar la compatibilidad con el sonido, así como la búsqueda de identificadores BLE.
  • Get_Network_ID debe mostrar el identificador de Google (0x02).
• Lineamientos para implementar el opcode Get_Identifier:
  • La operación solo debe mostrar una respuesta válida durante 5 minutos después de que el usuario activó el modo "identificación", que requiere una combinación de presiones de botones. Una señal visual o de audio debe indicarle al usuario que el proveedor ingresó a 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, con codificación hexadecimal.
  • Como parámetro pid, usa la misma respuesta que se creó para Get_Product_Data, con codificación hexadecimal.
• Lineamientos para implementar la operación Sound_Start:
  • El comando debería activar el timbre en todos los componentes disponibles.
  • Se debe usar el volumen máximo admitido.
  • La duración recomendada para el tono de llamada es de 12 segundos.
• Las etiquetas de ubicación 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 de inhabilitación deben documentarse 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=es-419") o con el encabezado HTTP "accept-language".

Lineamientos sobre protocolos intercambiables

• Solo se debe usar un protocolo a la vez. Asegúrate de que no más de una red pueda funcionar en el dispositivo de forma simultánea. Este requisito es necesario para garantizar que no se mezclen datos sensibles del usuario entre distintos protocolos.
• Se recomienda incorporar un flujo de trabajo de restablecimiento de la configuración de fábrica en el dispositivo que le permita al usuario volver a configurar un dispositivo 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. Un usuario debe poder elegir qué red quiere usar sin darle preferencia a ninguna. El equipo de Google debe aprobar este flujo.

Actualizaciones de firmware

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

Compatibilidad

La red de Encontrar mi dispositivo 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 FMDN	Fecha	Comentario
v1		Versión inicial de la especificación de FMDN para el acceso anticipado.
v1.1	Feb 2023	Se agregó una indicación de texto simple del modo de protección contra el seguimiento no deseado. Se agregó una opción para omitir la autenticación de las solicitudes de timbre mientras el dispositivo está en modo de protección contra seguimiento no deseado.
v1.2	Abr 2023	Se actualizó la definición del AK de un propietario. Se agregó una recomendación para recuperarse de la pérdida de energía en las etiquetas de localizador. Se agregó una aclaración para la aleatorización de direcciones MAC. Se agregó una aclaración sobre la rotación de direcciones MAC mientras se está en el modo de protección contra seguimiento no deseado. Se agregó un lineamiento sobre cómo tener una forma de desactivar una etiqueta de localizador.
v1.3	Diciembre de 2023	Se agregó una aclaración sobre la información de identificación que exponen las etiquetas de localizador. Se agregó un requisito para implementar la especificación de prevención de seguimiento no deseado. Se agregaron lineamientos para dispositivos de protocolo conmutables.