Un Bluetooth Beacon es un altavoz en una sala llena de gente: difunde el mismo paquete a todos los que estan en rango, sin emparejar y sin autenticar por defecto. Esa apertura es lo que hace a los beacons baratos y faciles de desplegar, pero tambien significa que cualquiera con un telefono puede leer, clonar o falsificar tu trafico de beacon. Este articulo mapea el modelo de amenaza real de un Bluetooth Beacon y los controles de ingenieria que de verdad detienen a un atacante.
Por que un beacon esta expuesto por diseno
Un beacon anuncia para ser oido. Los paquetes de advertising son legibles por cualquier escaneo, y la carga (UUID/Major/Minor de iBeacon, namespace/instance de Eddystone o un MSD propio) se envia en claro salvo que la cifres especificamente. No se negocia ninguna clave al anunciar, asi que la radio no distingue una pasarela legitima de un telefono de un desconocido.
El modelo de amenaza
| Amenaza | Que hace el atacante | Que rompe |
|---|---|---|
| Escucha | Registra advertising pasivamente | Privacidad, fuga de ubicacion |
| Suplantacion | Emite un beacon falso con tus IDs | Fraude de presencia, abuso de disparador |
| Replay | Captura un paquete valido, lo reenvia | Ilusion de «sigue ahi» |
| MITM / pasarela falsa | Suplanta el enlace de subida | Inyeccion, manipulacion |
Escucha: el claro filtra la ubicacion
Un frame iBeacon estandar lleva un UUID fijo mas Major/Minor que a menudo codifican planta, zona o clase de activo. Un atacante en el lobby registra los UUID y en una tarde construye un mapa de tus zonas. Mitigaciones: usa IDs opacos y rotativos; nunca incrustes datos significativos en los campos estaticos; guarda el mapeo real en el servidor.
Suplantacion: presencia falsa
Como el ID del beacon es publico, un atacante emite el mismo UUID/Major/Minor desde una placa de 10 dolares y tu sistema cree que un activo (o un cliente) esta donde no esta. Retail: eventos falsos de «fidelidad presente». Logistica: palets fantasticos. La solucion es autenticidad: el receptor debe verificar criptograficamente que el paquete vino de un tenedor de clave, no solo que el ID coincide.
Replay: captura y reenvio
El replay es el ataque mas simple y el mas facil de pasar por alto. Un atacante graba hoy un paquete valido y lo reenvia la semana que viene para afirmar que el beacon «sigue ahi». Un frame iBeacon crudo no tiene marca de tiempo ni nonce, asi que el receptor no distingue viejo de nuevo. Una marca de tiempo firmada lo derrota.
MITM y la pasarela falsa
Si tu beacon habla con una pasarela por un enlace sin cifrar, una pasarela falsa puede inyectar o modificar lecturas. Lo mismo aplica si el enlace pasarela-a-nube no esta autenticado. Cada salto necesita su propia integridad y, donde el dato es sensible, confidencialidad.
Mitigaciones criptograficas que funcionan
Advertising cifrado. Mete la carga significativa en un blob cifrado (AES-CCM bajo LE Secure Connections o una clave precompartida). La radio sigue emitiendo, pero solo los tenedores de clave pueden leerla.
Beacons firmados. Sella cada paquete con una firma ECDSA sobre la carga mas una marca de tiempo. El receptor verifica antes de confiar:
def firmar_beacon(carga, ts, clave_priv):
msg = carga + ts # ts = contador grueso o unix time
sig = ecdsa_sign(msg, clave_priv) # P-256 o Ed25519
return carga + ts + sig
def verificar_beacon(anuncio, clave_pub, ventana):
carga, ts, sig = separar(anuncio)
if ahora() - ts > ventana: # ej. 60 s
return REPLAY_DETECTADO
return ecdsa_verificar(carga + ts, sig, clave_pub)IDs volatiles rotativos. Refleja el modelo de privacidad de las direcciones privadas resolubles: difunde un ID rotativo derivado de clave que solo tu servidor puede resolver. Un fisgon ve un ID distinto cada pocos minutos y no puede rastrear.
Marca de tiempo + nonce anti-replay. Un contador monotono o una marca de tiempo gruesa dentro del sobre firmado hace unico y efimero cada paquete.
Seguridad vs coste
| Esquema | Confidencialidad | Integridad | Resist. replay | Coste energia | Compatibilidad |
|---|---|---|---|---|---|
| Claro | Ninguna | Ninguna | Ninguna | Ninguno | Universal |
| ID rotativo | Debil | Ninguna | Parcial | Bajo | Universal |
| Firmado | Ninguna | Fuerte | Si (tiempo) | Medio | Necesita verif. |
| Cifrado | Fuerte | Fuerte | Si (nonce) | Alto | Necesita clave |
Aprovisionamiento de claves y raiz hardware
La firma solo es tan confiable como la clave privada. Guardala en un secure element o derivala de un PUF para que no se pueda leer de la imagen del firmware. Es la misma disciplina de root-of-trust del secure boot: la identidad del beacon se graba en fabrica, no se carga de flash en tiempo de ejecucion.
Deteccion operativa
Aun con cripto, vigila el aire:
- Anomalia RSSI: un beacon que de repente lee +20 dB mas fuerte sugiere un suplantador cercano.
- Mismo ID desde dos lugares a la vez: fisicamente imposible – marca.
- Lista blanca de pasarelas: acepta solo subidas de certificados conocidos.
Estandares en los que apoyarse
Apple Find My y la especificacion multiplataforma Detecting Unwanted Location Trackers definen comportamientos anti-acoso (alertas de separacion, pitidos) que debes imitar en etiquetas de consumo. Device Provisioning Protocol (DPP) da un onboarding limpio para pasarelas.
Checklist OEM
1. Decide el modelo de amenaza antes de elegir esquema – la mayoria necesita firmado, no cifrado.
2. Guarda claves en secure element / PUF, nunca en flash de app.
3. Anade marca de tiempo o contador a cada paquete; verifica la ventana.
4. Rota los IDs publicos en un calendario que el servidor resuelva.
5. Envía forma de revocar y re-clavar un beacon comprometido.
Un Bluetooth Beacon gana confianza igual que cualquier cosa: demostrando, en cada paquete, que es quien dice ser.