Especificación del accesorio de red de Encontrar mi dispositivo

v1.3

La especificación del accesorio de red de Encontrar mi dispositivo (FMDN) define un enfoque encriptado de extremo a extremo para el seguimiento de dispositivos con balizas Bluetooth de bajo consumo (BLE). En esta página, se describe FMDN como una extensión de la especificación de Vinculación rápida. Los proveedores deben habilitar esta extensión si tienen dispositivos compatibles con FMDN y están dispuestos a habilitar el seguimiento de ubicación para esos dispositivos.

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

Especificación GATT

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

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

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

Proporción de eficiencia energética (EER)

Las operaciones que requiere esta extensión se realizan como una operación de escritura, protegida por un mecanismo de respuesta y desafío. Antes de realizar cualquier operación, se espera que Seeker realice una operación de lectura de 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	0 × 01
1 - 8	array de bytes	Nonce aleatorio único	varía

Cada operación de lectura debe dar como resultado un nonce diferente, y un nonce único debe ser válido para una sola operación. Se debe invalidar el nonce incluso si la operación falló.

Luego, Seeker calcula una clave de autenticación de un solo uso 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, Seeker demuestra que conoce 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 de acciones del píxel contador. No se puede cambiar la clave de la cuenta de propietario elegida hasta que se restablezca la configuración de fábrica del proveedor. El proveedor no debe quitar la clave de la cuenta de propietario cuando se queda sin ranuras de claves de cuenta gratuitas.

  • Los proveedores que ya admiten FMDN cuando se vinculan por primera vez (o 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 Seeker lee el estado de aprovisionamiento durante la vinculación.

  • Los proveedores que obtienen compatibilidad con FMDN después de estar vinculados (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 las características de acciones del píxel contador después de la actualización del firmware, si se supone 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 Seeker de forma aleatoria cuando realiza el proceso de aprovisionamiento de FMDN. Esta clave se usa para derivar claves criptográficas que se usan para la encriptación de extremo a extremo en los informes de ubicación. El objeto Seeker nunca lo revela en el backend.

• Clave de recuperación: Se define como SHA256(ephemeral identity key || 0x01), truncada a los primeros 8 bytes. La clave se almacena en el backend, y Seeker puede usarla para recuperar el 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 Seeker solo puede usarla para hacer sonar el dispositivo.

• Clave de protección contra seguimiento no deseada: Se define como SHA256(ephemeral identity key || 0x03), truncada a los primeros 8 bytes. La clave se almacena en el backend y Seeker 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: Leer los parámetros del píxel contador 0x01: Leer el estado de aprovisionamiento 0x02: Configurar clave de identidad efímera 0x03: Borrar la 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	0 x 00: N/A 0x01: N/A 0x02: 32 bytes que son la clave de identidad efímera, AES-ECB-128 encriptada con la clave de la cuenta. Si el proveedor ya tiene configurada una clave 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íxel contador.

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	0 × 08
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 clave de aprovisionamiento de píxel contador.

Octeto	Tipo de datos	Descripción	Valor
0	uint8	ID de datos	0x05: Hacer sonar 0x06: Leer el estado de tono
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 y el volumen del tono. 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: Desactivar el modo de protección contra seguimiento no deseado
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 seguimiento no deseada.

Las escrituras correctas activan notificaciones, como se muestra en la tabla 6.

Las notificaciones con un ID de datos que no sea 0x05: cambio de estado de 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: Leer los parámetros del píxel contador 0x01: Leer el estado de aprovisionamiento 0x02: Configurar clave de identidad efímera 0x03: Borrar 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: Leer el estado de tono 0x07: Activa el modo de protección contra seguimiento no deseado 0x08: Desactivar el modo de protección contra seguimiento no deseado
1	uint8	Longitud de los datos	varía
Entre 2 y 9	array de bytes	Proporción de eficiencia energética (EER)	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 llamada, AES-ECB-128 encriptado con la clave de cuenta (sin relleno) 0x01: 1 byte que indica el estado del 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 nuevo estado y el activador del cambio 0x06: 3 bytes que indican los componentes que están llamando de forma activa y la cantidad de decimales restantes para que suene Los demás IDs de datos usan datos adicionales vacíos

Tabla 6: Respuesta del servicio de píxel contador

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

Código	Descripción	Notas
0 × 80	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 anterior).
0 × 81	El valor no es válido	Se muestra cuando se proporciona algún valor no válido o cuando los datos recibidos tienen una cantidad de bytes inesperada.
0 × 82	Sin consentimiento del usuario	Se muestra en respuesta a una solicitud de escritura con el ID de datos 0x04: Read e efímer Identity key with user consentimiento cuando el dispositivo no está en modo de vinculación.

Tabla 7: Códigos de error de GATT.

Lee el parámetro de la baliza

El buscador puede consultar al proveedor los parámetros del píxel contador mediante 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 proporcionada por única vez coincida con cualquiera de las claves de cuenta almacenadas en el dispositivo.

Si falla la verificación, el proveedor muestra un error sin autenticar.

Si se ejecuta 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:

Octeto	Tipo de datos	Descripción	Valor
0	uint8	Potencia calibrada	La potencia calibrada recibida a 0 m (un valor en el rango [-100, 20]). Representado como un número entero con firma, con una resolución de 1 dBm
1 a 4	uint32	Valor de reloj	El valor actual del reloj en segundos (big endian).
5	uint8	Selección de curva	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 sonar. 0x02: Indica que dos componentes, los auriculares izquierdo y el 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	Capacidades de llamada	Las opciones compatibles son las siguientes: 0x00: La selección del volumen de tono no está disponible. 0x01: Selección del volumen de tono disponible. Si se configura, el proveedor debe aceptar y controlar 3 niveles de volumen como se indica en Operación hacer sonar.
8-15	array de bytes	Padding	Sin relleno para la encriptación AES.

Los datos deben estar encriptados AES-ECB-128 con la clave de cuenta que se usó 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).

Lee el estado de aprovisionamiento de la baliza

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 falla la verificación, el proveedor muestra un error sin autenticar.

Si se ejecuta 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:

Octeto	Tipo de datos	Descripción	Valor
0	uint8	Estado de aprovisionamiento	Una máscara de bits con los siguientes valores: Bit 1 (0x01): Indica si se establece una clave de identidad efímera para el dispositivo. Bit 2 (0x02): Establece si la clave de autenticación de un solo uso proporcionada coincide con la clave de la cuenta del propietario.
1-20 o 32	array de bytes	Identificador efímero actual	20 o 32 bytes (según el método de encriptación que se utilice) que indican el ID efímero actual anunciado por 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 FMDN, o cambiar la clave de identidad efímera de un proveedor ya aprovisionado, 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, esta 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 una baliza FMDN.

Si falla la verificación, el proveedor muestra un error sin autenticar.

Si se realiza de forma correcta, la clave de identidad efímera se recupera mediante el método AES-ECB-128 desencriptando con la clave de cuenta coincidente. La clave debe conservarse en el dispositivo y, a partir de ese momento, el proveedor debe comenzar a anunciar tramas FMDN. La nueva clave de identidad efímera 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 del contador del proveedor, 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 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 una baliza FMDN o la verificación falla, muestra un error sin autenticar.

Si la operación es exitosa, el proveedor olvida la clave y deja de anunciar los marcos 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).

Leer 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 Seeker solo almacena la clave 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 presionó un botón físico en el dispositivo (lo que constituye el consentimiento del usuario).

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

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

Si falla la verificación, el proveedor muestra un error sin autenticar.

Si el dispositivo no está en modo de vinculación, el proveedor mostrará un mensaje de error que indica que no hay consentimiento del usuario.

Si se ejecuta de forma correcta, 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:

Octeto	Tipo de datos	Descripción	Valor
0	uint8	Operación de hacer sonar	Una máscara de bits con los siguientes valores: Bit 1 (0x01): Hacer sonar a la derecha Bit 2 (0x02): Hacer sonar a la izquierda Bit 3 (0x04): Ring case 0xFF: Hacer sonar todos los componentes 0x00: Dejar de hacer sonar
1 - 2	uint16	Tiempo de espera	Tiempo de espera en decisegundos. No debe ser cero y no debe ser mayor que el equivalente de 10 minutos. El proveedor usa este valor para determinar cuánto tiempo debe sonar antes de silenciarse a sí mismo. El tiempo de espera anula el que ya está vigente si algún componente del dispositivo ya está sonando. Si la operación de anillo 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 que:

• La clave de autenticación de un solo uso proporcionada coincide con la clave de anillo.
• El estado solicitado coincide con los componentes que pueden sonar.

Si el proveedor no se aprovisiona como una baliza FMDN o la verificación falla, muestra un error sin autenticar. Sin embargo, si el proveedor tiene activa la protección contra seguimiento no deseado y la marca de autenticación que activa la protección contra seguimiento no deseada activa la marca de autenticación por sonido de omisión, el proveedor debe omitir esa verificación. Aún se espera que Seeker proporcione los datos de autenticación, pero se podría configurar en un valor arbitrario.

Cuando el sonido inicia o finaliza, 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 sonido	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: Detenido (presionar un botón) 0x04: Detenido (solicitud GATT)
1	uint8	Componentes que hacen sonar	Es una máscara de bits de los componentes que suenan activamente, como se define en la solicitud.
2 - 3	uint16	Tiempo de espera	El tiempo restante para que suene en decimales. Si el dispositivo dejó de sonar, debería devolverse 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 se encuentra en el estado de sonido solicitado cuando se recibe una solicitud para hacer sonar o detener el sonido, el proveedor debe enviar una notificación con un estado de sonido o 0x00: Iniciado o 0x04: Detenido (solicitud GATT), respectivamente. Esta solicitud anula los parámetros del estado existente, de modo que se pueda extender la duración del sonido.

Si el proveedor tiene un botón físico (o la función de tacto está habilitada), ese botón debe detener la función de sonido si se lo presiona mientras el sonido está activo.

Nota: En el caso de los proveedores que incluyen detección de cabeza, comprueba que el dispositivo no esté sobre la cabeza antes de sonar al volumen máximo. Si la detección de cabeza no es compatible o no es confiable, aumenta el volumen de forma gradual (para que el usuario pueda dejar de sonar o quitarse los auriculares).

Nota: El proveedor debería seguir sonando, independientemente del estado de conexión del Seeker que solicitó el sonido. De esta manera, se evita una situación en la que el dispositivo deja de sonar porque se pierde la conexión debido a que el cliente se aleja demasiado del dispositivo. Por lo tanto, no se puede encontrar el dispositivo porque dejó de sonar y está demasiado lejos del cliente para que vuelva a solicitar que suene.

Cómo obtener el estado de sonido de la baliza

Para obtener el estado de llamada del píxel contador, Seeker 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 única proporcionada coincida con la clave de anillo.

Si el proveedor no se aprovisiona como una baliza FMDN o si la verificación falla, el proveedor muestra un error sin autenticar.

Si se ejecuta de forma correcta, 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:

Octeto	Tipo de datos	Descripción	Valor
0	uint8	Componentes que hacen sonar	Los componentes que suenan de forma activa, como se define en la solicitud de llamada.
1 - 2	uint16	Tiempo de espera	El tiempo restante para que suene en decimales. Ten en cuenta que si el dispositivo no suena, debería devolverse 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 seguimiento no deseado

El modo de protección contra seguimiento no deseado se diseñó para permitir que los clientes identifiquen 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 retransmitir una solicitud no deseada de activación 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 de forma temporal una dirección MAC fija, lo que permite a los clientes detectar el dispositivo y advertir 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, Seeker 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 habilites 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: Se omite la autenticación por llamada. Cuando se configura, las solicitudes de sonido no se autentican cuando se utiliza el modo de protección contra seguimiento no deseado. Si no se establece ninguna marca (el byte es ceros), es válido omitir la sección de datos por completo y enviar una sección de datos vacía. Las marcas solo se aplican 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 una baliza FMDN o la verificación falla, muestra un error sin autenticar.

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 privada de MAC a una vez cada 24 horas. El identificador efímero anunciado debe seguir rotando como de costumbre. El tipo de marco debe establecerse en 0x41. El estado también se refleja en la sección de marcas con hash.

Cuando inhabilitas el modo de protección contra seguimiento no deseado

El Proveedor verifica lo siguiente:

• La clave de autenticación única 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 una baliza FMDN o si la verificación falla, el proveedor muestra un error sin autenticar.

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

Si se ejecuta de forma correcta, 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 fotogramas de Vinculación rápida, el proveedor debe intercalar los fotogramas 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 anunciar las tramas de FMDN, incluso cuando el dispositivo se encuentra en modo de bajo consumo, ya que esto permite encontrarlo si se pierde. En el caso de algunos dispositivos, es posible que no se pueda anunciar cuándo están apagados debido a las consecuencias en la duración de la batería. En esos casos, se recomienda que actives el dispositivo de forma periódica y publiques anuncios durante un período corto (p.ej., despertarse cada 10 minutos y publicar anuncios durante 10 segundos).

La trama FMDN lleva una clave pública, que se utiliza para encriptar los informes de ubicación de cualquier cliente de asistencia que contribuye a la red de participación colectiva. Hay dos tipos de claves de curva elíptica disponibles: una de 160 bits que se adapta a los fotogramas BLE 4 heredados o una de 256 bits que requiere BLE 5 con capacidades de publicidad 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 escanear dispositivos publicitarios ni generar informes sobre ellos, lo que reduce el tamaño de la red.

Una trama FMDN se estructura de la siguiente manera.

Octeto	Valor	Descripción
0	0 × 02	Longitud
1	0 × 01	Valor de los tipos de datos de las marcas
2	0 × 06	Datos de marcas
3	0x18 o 0x19	Longitud
4	0 × 16	Valor del tipo de datos de los datos de servicio
5	0×AA	UUID de servicio de 16 bits
6	0xFE	...
7	0x40 o 0x41	Tipo de trama FMDN con indicación de modo de protección contra seguimiento no deseado
27/8		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 desplazamientos de bytes y los valores de una curva de 256 bits.

Octeto	Valor	Descripción
0	0 × 02	Longitud
1	0 × 01	Valor de los tipos de datos de las marcas
2	0 × 06	Datos de marcas
3	0x24 o 0x25	Longitud
4	0 × 16	Valor del tipo de datos de los datos de servicio
5	0×AA	UUID de servicio de 16 bits
6	0xFE	...
7	0x40 o 0x41	Tipo de trama FMDN con indicación de modo de protección contra seguimiento no deseado
8...39		Identificador efímero de 32 bytes
40		Marcas con hash

Tabla 9: trama FMDN que admite una curva de 256 bits.

Cálculo del identificador efímero (EID)

AES-ECB-256 genera un valor aleatorio mediante la encriptación de la siguiente estructura de datos con la clave de identidad efímera:

Octeto	Field	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 del píxel contador, en formato big-endian de 32 bits Se borran los bits más bajos.
16 a 26	Padding	Valor = 0x00
27	K	Exponente del período de rotación
28 - 31	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.

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 cálculo es un número de 256 bits, denotado 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 definen Fp, n y G a los que se hace referencia a continuación.

Ahora se proyecta r' 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. La baliza 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 del más significativo al menos significativo):

• Bits 0-4: Reservados (se establecen en ceros).
• Los bits 5 a 6 indican el nivel de batería del dispositivo de la siguiente manera:
  • 00: Indicación de nivel de batería no compatible
  • 01: Nivel de batería normal
  • 10: Nivel de batería bajo
  • 11: Nivel de batería muy bajo (próximamente deberás reemplazar la batería)
• El bit 7 se establece en 1 si la baliza se encuentra en un modo de protección contra seguimiento no deseado, y en 0 en el caso contrario.

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

Ten en cuenta que r debe alinearse con el tamaño de la curva. Agrega ceros como bits más significativos si su representación es inferior a 160 o 256 bits, o si los bits más significativos se deben truncar si su representación es superior a 160 o 256 bits.

Si la baliza no admite la indicación del nivel de batería y no se encuentra en el modo de protección contra seguimiento no deseado, se permite 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 a fin de completar la especificación. Solo el buscador los implementa, no el proveedor.

Para encriptar un mensaje m, un observador (que leyó Rx de la baliza) hará lo siguiente:

1. Elige un número al azar 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 de la ecuación de curva y seleccionando un valor Ry arbitrario de los resultados posibles.
4. Calcula la clave AES de 256 bits k = HKDF-SHA256((s * R)x), en la que (s * R)x es la coordenada x del resultado de la multiplicación de curva. No se especificó la sal.
5. Deja que URx y LRx sean los 80 bits superiores e inferiores de Rx, respectivamente, en formato big-endian. De manera similar, define USx y LSx para S.
6. Calcula nonce = LRx || LSx.
7. Calcula (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 que no sea de confianza.

Desencriptación de valores encriptados con EID

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

1. Con URx, obtén el valor del contador de tiempo de la baliza en el que se basa URx. Esto se puede hacer mediante el cliente del propietario que calcula los valores de Rx para los valores del contador de tiempo del píxel contador 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 de EID.
3. Calcula R = r * G y verifica que coincida con el valor de URx que proporcionó el observador.
4. Calcula S = (Sx, Sy) mediante la sustitución de la ecuación de curva y seleccionando un valor Sy arbitrario de los resultados posibles.
5. Calcula k = HKDF-SHA256((r * S)x), en el que (r * S)x es la coordenada x del resultado de la multiplicación de 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 que se puede resolver (RPA) o no se puede resolver (NRPA) para anunciar tramas FMDN. Se requiere RPA para los dispositivos de LE Audio (LEA) y se recomienda para otros dispositivos, a excepción de las etiquetas de localizador 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 preciso en el que la 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 siguiente tiempo de rotación anticipado (si no se aplicó una aleatorización), además de un factor de tiempo aleatorio positivo en el rango de 1 a 204 segundos.

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

Recuperación ante cortes de corriente

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 un corte 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, en el momento del inicio, verifique la NVM para ver si hay un valor presente desde el cual inicializar. Los agentes de resolución del identificador efímero implementarían la resolución durante un período suficiente para permitir un desvío del reloj razonable y este tipo de recuperación de pérdida de energía.

Los proveedores deben hacer todo lo posible para minimizar los desvíos del reloj, ya que el período de resolución es limitado. Se debe implementar al menos un método adicional de sincronización de reloj (publicar marcos de Vinculación rápida no detectables o implementar la transmisión 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 Vinculación rápida en los proveedores que admiten FMDN.

Lineamientos específicos de la etiqueta de ubicación

• Si el proveedor estaba vinculado, pero no se aprovisionó FMDN en 5 minutos (o si se aplicó una actualización OTA mientras el dispositivo está vinculado, pero no aprovisionado por FMDN), el proveedor debe volver a su configuración de fábrica y borrar las claves de cuenta almacenadas.
• Una vez que el proveedor está vinculado, no debe cambiar su dirección MAC hasta que se aprovisione FMDN o hasta que pasen 5 minutos.
• Si la clave de identidad efímera se borra del dispositivo, este deberá restablecer 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 rápida.
• El Proveedor debe incluir un mecanismo que les 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 debería anunciar fotogramas de Vinculación rápida no detectables hasta la siguiente invocación de los parámetros de lectura del píxel contador. Esto permite que Seeker detecte el dispositivo y sincronice el reloj, incluso si se produjo un desvío significativo.
• Cuando se anuncian fotogramas de Vinculación rápida no detectables, no se deben habilitar las indicaciones de la IU.
• No se deben anunciar los fotogramas de Vinculación rápida detectables mientras el proveedor está aprovisionado para FMDN.
• 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 clásicos

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

Aprovisionamiento de FMDN de dispositivos ya vinculados

El proveedor no siempre se aprovisiona para FMDN cuando se sincroniza con Seeker, pero pasa un tiempo después de eso. En ese caso, es posible que el proveedor no tenga una dirección BLE MAC actualizada que sea necesaria para establecer una conexión GATT. El proveedor debe admitir al menos una de las siguientes formas para que Seeker obtenga su dirección BLE mientras esté vinculado:

• El proveedor puede anunciar periódicamente los datos de la cuenta de Vinculación rápida que le permiten al Seeker encontrar su dirección de BLE mediante un análisis de BLE.
  Este enfoque se adapta a 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 se adapta a los proveedores que no anuncian fotogramas de Vinculación rápida mientras están conectados al buscador mediante Bluetooth.

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

Transmisión rápida 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 usuario 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 capacidad de seguimiento

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

Para permitir eso, el proveedor debe usar la propiedad de 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 informa a Seeker sobre los cambios de capacidad debido a las actualizaciones del firmware.

Octeto	Tipo de datos	Descripción	Valor
0	uint8	Evento de información del dispositivo	0x03
1	uint8	Versión de firmware	0 × 09
2 - 3	uint16	Longitud de datos adicional	varía
var	array de bytes	String de la versión	varía

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

Después de recibir una solicitud de actualización de capacidad (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 capacidad del dispositivo	0 × 06
1	uint8	Seguimiento de FMDN	0x03
2 - 3	uint16	Longitud de datos adicional	0x0007
4	uint8	Estado de aprovisionamiento de FMDN	0x00 si no se aprovisionó; 0x01 si lo aprovisionó una cuenta
5 - 10	array de bytes	La dirección MAC actual de BLE del dispositivo	varía

Tabla 12: Evento de sincronización de capacidad del dispositivo: función de seguimiento agregada.

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, para sincronizar el buscador en caso de un desvío del reloj (por ejemplo, debido al agotamiento de la batería). De lo contrario, Seeker inicia una conexión más costosa y menos confiable para este fin.

Octeto	Tipo de datos	Descripción	Valor
0	uint8	Evento de información del dispositivo	0x03
1	uint8	Identificador efímero actual	0x0 mil millones
2 - 3	uint16	Longitud de datos adicional	0x0018 o 0x0024
4 - 7	array de bytes	Valor de reloj	Ejemplo: 0x13F9EA80
8-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

Para dispositivos compatibles con 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 hacer referencia a la baliza y borrar la clave de identidad efímera y todas las claves de cuenta almacenadas, incluida la del propietario.

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

Prevención de 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 rastreadores de ubicación no deseados (DULT).

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

• Todos los dispositivos compatibles con FMDN deben estar registrados en la consola de dispositivos cercanos y tener activada la función "Encontrar mi dispositivo".
• El dispositivo debe implementar el servicio de no propietario del accesorio y la característica definidas 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 usuario.
• Durante el período de retrocompatibilidad, como se define en la especificación de DULT, no hay cambios en el fotograma anunciado, como se define en este documento.
• El "Modo de protección contra seguimiento no deseado" definido en este documento se asigna al "estado de separación" definido por la especificación de DULT.
• Lineamientos para implementar los códigos de operación de Información de accesorios:
  • Get_Product_Data debe mostrar el ID de modelo proporcionado por la consola, sin relleno para cumplir con el 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 de "Herramienta de seguimiento de ubicación" si ninguna otra categoría se ajusta mejor al tipo de dispositivo.
  • Get_Accessory_Capabilities debe indicar la compatibilidad con llamadas, así como la búsqueda de identificadores BLE.
  • Get_Network_ID debe mostrar el identificador de Google (0x02).
• Lineamientos para implementar el código de operación Get_Identifier:
  • La operación debería mostrar una respuesta válida solo durante 5 minutos después de que el usuario active el modo de “identificación”, que requiere una combinación de presiones de botones. Una señal visual o de audio debe indicar 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 como 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 código de operación Sound_Start:
  • El comando debería activar el sonido en todos los componentes disponibles.
  • Se debe usar el volumen máximo admitido.
  • La duración recomendada para hacer sonar el dispositivo es de 12 segundos.
• Las etiquetas de ubicación deben incluir un mecanismo que les 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 mediante el encabezado HTTP "Accept-language".

Lineamientos del protocolo conmutable

• 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 a la vez. Este requisito es necesario para garantizar que no haya una combinación de datos sensibles del usuario entre protocolos variables.
• Se recomienda incorporar un flujo de trabajo de restablecimiento de la configuración de fábrica en el dispositivo que 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 dar 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 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 de edad apta.

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 seguimiento no deseado Se agregó una opción para omitir la autenticación de solicitudes que hacen sonar cuando se usa el modo de protección contra seguimiento no deseado.
v1.2	Abr de 2023	Se actualizó la definición de la AK de un propietario. Se agregó una recomendación para recuperarse de los cortes 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 en el modo de protección contra seguimiento no deseado. Se agregó un lineamiento sobre la necesidad de desactivar una etiqueta de localizador.
v1.3	Dic de 2023	Se agregó una aclaración sobre la identificación de información expuesta por etiquetas de localización. Se agregó un requisito para implementar la especificación de prevención de seguimiento no deseado. Se agregaron lineamientos para dispositivos de protocolo intercambiables.