Un BLE Tag estandar es un beacon del tamano de una moneda que se sujeta a las llaves, un portatil, un palet o una pulsera de paciente para poder localizarlo mas tarde. Esa misma comodidad es tambien el peligro: basta con dejarlo en el bolso de alguien sin su conocimiento para convertirlo en un dispositivo de seguimiento. Tras una serie de casos de abuso, Apple y Google publicaron una especificacion conjunta (2023-2024) de “deteccion de seguimiento no deseado” que cualquier tag — no solo los de primera parte — debe respetar para ser tolerado por los telefonos. Este articulo aborda el lado ingenieril: como un tag deduce que se ha separado de su dueno, como avisa a un desconocido en lugar del dueno, y la criptografia que permite a un telefono localizador reportar una posicion sin llegar a saber quien es el dueno.
El modelo de amenaza en dos actores
Solo hay dos partes relevantes:
- Dueno — el telefono emparejado que se vincula legitimamente con el tag y se supone que debe estar cerca.
- No dueno — una persona que ahora lleva el tag sin saberlo (la victima), o un transeunte cuyo telefono simplemente puede oirlo (el localizador).
Un tag bien comportado asume que el dueno esta cerca la mayor parte del tiempo. El estado peligroso es *separado*: el tag se mueve por el mundo pero el telefono del dueno no esta con el. Detectar ese estado, y avisar al no dueno en lugar del dueno, es todo el trabajo de la proteccion anti-rastreo.
Deteccion de separacion: “¿esta mi dueno aqui?”
El tag no puede preguntarle al dueno por Internet — es solo BLE y puede estar fuera de cualquier gateway. Asi que infiere la presencia del dueno localmente:
1. El telefono del dueno, mientras esta emparejado, emite periodicamente un token de presencia autenticado — un paquete BLE rotatorio y firmado que el tag reconoce.
2. El tag escucha durante los huecos de publicidad. Cada intervalo oye el token (dueno presente) o no (una falla).
3. Mantiene un contador de fallas. Cuando las fallas superan un umbral *y* el acelerometro del tag reporta movimiento, transiciona al estado separado.
La compuerta de movimiento importa. Un tag dejado en un estante en casa mientras el dueno se va de viaje no debe sonar una alarma — no hay victima. Un tag que se mueve con un desconocido durante horas si debe hacerlo. Umbrales tipicos: 8-24 h de ausencia acumulada en movimiento antes de la primera alerta.
Un bucle de deteccion minimo:
def tick(tag, owner_token_seen, accel_motion):
if owner_token_seen:
tag.miss_counter = 0
tag.separated = False
return
tag.miss_counter += 1
if tag.miss_counter > ABSENCE_LIMIT and accel_motion:
tag.separated = TrueDos formas en que el tag avisa al desconocido
Una vez separado, el tag debe avisar al *no dueno*, no al dueno:
1. Altavoz en el dispositivo. Un pequeno transductor piezolectrico o magnetico emite un tono. La especificacion multiplataforma exige efectivamente un sonido de aproximadamente >= 60 dB a 0.3 m emitido dentro de una ventana acotada (comunmente 8-24 h tras la separacion). Por eso todo tag de consumo incluye un transductor que no se puede quitar en silencio.
2. Alerta en el telefono del no dueno. Cualquier SO de telefono puede marcar un tag *desconocido* que ha viajado con el. El telefono muestra una notificacion, ofrece “Reproducir sonido”, “Mostrar ultima ubicacion” e instrucciones para desactivar el tag. Para que funcione entre fabricantes, el tag debe anunciar una bandera de estado separado en su carga BLE normal que cualquier SO pueda analizar.
| Capacidad | Telefono del dueno | Telefono del desconocido (no dueno) |
|---|---|---|
| Ve la ubicacion del tag | Si (en vivo + historial) | Solo “visto cerca de ti” |
| Puede reproducir sonido | Si (en cualquier momento) | Si (tras ventana de separacion) |
| Recibe alerta | No (es el dueno) | Si (alerta de rastreador desconocido) |
| Puede desactivar tag | Si (desemparejar) | Limitado (fisico / flujo de SO) |
Busqueda sin conexion: criptografia que oculta al dueno
La parte ingeniosa es *como el telefono de un desconocido reporta la ubicacion del tag al dueno sin que ninguno de los dos conozca la identidad del otro*. Este es el modelo “Find My” / busqueda offline:
- El tag guarda una clave privada maestra. Para cada intervalo de tiempo *i* (a menudo una hora) deriva una clave publica nueva `PK_i = Derive(master_priv, i)` y la difunde — o un hash corto de ella — en el paquete publicitario.
- Un telefono localizador que oye `PK_i` lee su propia ubicacion GNSS/Wi-Fi, cifra `(ubicacion, marca_de_tiempo)` con `PK_i` y sube el texto cifrado a un servidor retransmisor. Sin cuenta, sin identidad.
- El dueno, conocendo `master_priv` y el intervalo actual *i*, recalcula la clave privada correspondiente, obtiene el texto cifrado y descifra la ubicacion.
La propiedad de privacidad: el servidor retransmisor solo ve textos cifrados opacos. No puede vincular dos hallazgos del mismo tag (las claves rotan), ni conocer al dueno. Solo la clave maestra del dueno une los reportes.
Restricciones de ingenieria en un tag diminuto
Aqui es donde se complica para un dispositivo de boton:
- Coste criptografico. Una multiplicacion escalar ECC en un Cortex-M0+/M4 tarda de centenas de milisegundos a segundos y consume corriente de nivel mA. Rotar y volver a derivar claves cada hora en una CR2032 es impracticable, asi que los tags guardan en cache la `PK_i` actual y solo la recalculan en el limite del intervalo — a menudo descargando la derivacion pesada al telefono del dueno, que precomputa un pequeno lote de claves futuras y las envia por la conexion emparejada.
- Deriva de reloj. La rotacion de claves se indexa por tiempo. Si el tag pierde alimentacion (se le quita la pila) su indice de intervalo se reinicia y el dueno no puede descifrar los reportes hasta que el telefono re-sincronice el indice. El firmware debe persistir el indice en memoria no volatil y tolerar la deriva.
- Control de falsos positivos. Si el telefono del dueno esta un momento fuera de alcance BLE, el tag no debe dispararse. El contador de fallas + compuerta de movimiento + un largo limite de ausencia mantienen raras las falsas alarmas.
- Anti-manipulacion. El altavoz y la bandera de separado deben ser dificiles de desactivar en firmware; un tag conforme no expone un “modo silencioso” que sobreviva a la separacion.
Un boceto aproximado de consumo para un tag con anti-rastreo:
| Actividad | Corriente | Ciclo |
|---|---|---|
| Sondeo de acelerometro (movimiento) | 5-50 uA | 1 Hz |
| Escucha de token del dueno (RX) | 3-6 mA | pocos ms / hueco publicitario |
| Servir cache de claves (BLE) | 1-3 mA | esporadico |
| Alerta de altavoz | 20-80 mA | ráfagas, raro |
| Publicidad base | 5-50 uA | continuo |
El coste siempre activo dominante es el acelerometro y la escucha RX periodica; el resto es raro. Una CR2032 sigue durando meses porque el estado separado y el altavoz son excepcionales, no diarios.
Lo que un OEM debe implementar para enviar un tag conforme
Si fabricas un BLE Tag que llevaran personas, la superficie minima de firmware es:
1. Deteccion autenticada de presencia del dueno (token rotatorio firmado desde el telefono emparejado).
2. Temporizador de separacion + compuerta de movimiento con la ventana de ausencia de la especificacion.
3. Alerta audible que cumpla el requisito de dB / latencia, no extraible.
4. Bandera de estado separado en el anuncio BLE para que cualquier SO levante una alerta de rastreador desconocido.
5. Rotacion de claves de busqueda offline (si entras en una red de busqueda) con persistencia del indice entre reinicios.
Si en cambio tu tag es un *tag de activo industrial* bajo supervision constante de gateway, el mismo abuso es posible si un trabajador lo oculta en una chaqueta. Muchas flotas resuelven esto tratando al servidor de flota como el “dueno”: el servidor confirma la presencia por el enlace gateway, y un tag que pierde contacto con el servidor durante el limite entra en el mismo comportamiento separado — solo que la alerta se enruta a seguridad en lugar de a un telefono.
Conclusion
La proteccion anti-rastreo no es una casilla. Es una maquina de estados (dueno presente -> ausente -> separado), un altavoz que no se puede callar, una bandera entre fabricantes y criptografia opcional que mantiene al dueno anonimo. Construyela desde el dia uno, porque los SO de telefono ahora tratan los tags no conformes como hostiles y advierten a los usuarios en cuanto los ven.
