La gestión de claves criptográficas es la base operativa de los despliegues seguros de balizas Bluetooth. Aunque el hardware de la baliza y el diseño RF reciben la mayor atención de ingeniería, el aprovisionamiento de claves, los calendarios de rotación y los procedimientos de revocación determinan si una flota de 10.000 balizas permanece segura tras dos años en campo. Este artículo ofrece una guía práctica de ingeniería para gestionar claves de cifrado en despliegues de balizas a gran escala.
Tipos de claves en los sistemas de balizas
| Tipo de clave | Propósito | Tamaño típico | Frecuencia de rotación |
|---|---|---|---|
| Clave de identidad EID | Genera identificadores efímeros para ADV | 128 bits (AES-128) | Diaria |
| EIRK (clave de resolución de identidad) | Resuelve RPA a la identidad real | 128 bits | Nunca (aprovisionada una vez) |
| Clave de sesión EAD | Cifra la carga ADV (BT 5.4+) | 128 bits | Por sesión o diaria |
| Clave de emparejamiento OOB | Emparejamiento LE Secure Connections | 256 bits (ECDSA P-256) | Por despliegue |
| Clave de firma de firmware | Verificación de imagen OTA | 256 bits (ECDSA P-256 privada) | Nunca (en el servidor) |
Rotación de claves EID: el desafío de la renovación diaria
Los identificadores efímeros (EID) requieren una rotación de claves sincronizada entre la baliza y el servidor. La baliza genera una nueva identidad ADV cada día mediante una derivación basada en el tiempo a partir de la clave maestra. Si los relojes de la baliza y el servidor se desvían en más de ±12 horas, la resolución EID falla.
// EID derivation (simplified, based on iBeacon EID spec)
// beacon side (runs at midnight UTC):
def derive_eid(master_key, day_counter):
# PRK = HMAC-SHA256(master_key, day_counter)
prk = hmac_sha256(master_key, struct.pack('>I', day_counter))
# EID = AES-128-ECB(prk[0:16], 0x00000000...)
eid = aes128_ecb(prk[0:16], b'\x00' * 16)
return eid[0:4] # 4-byte EID for ADV
// Server side (same derivation, pre-computed lookup table):
// day 20010: EID = 0xA3F1BC02
// day 20011: EID = 0x7E44D819
// day 20012: EID = 0x12CF95A0
Gestión de la deriva del reloj: las balizas BLE utilizan típicamente osciladores de cristal de 32.768 kHz con una precisión de ±20 ppm. A lo largo de 365 días, la deriva en el peor caso = 20e-6 × 86400 × 365 = ±631 segundos (~10,5 minutos). Esto está dentro de la tolerancia de ±12 horas para EID diario, pero las ventanas de rotación semanal o mensual requieren sincronización periódica de la hora mediante conexión BLE.
Distribución de claves: flujos de trabajo de aprovisionamiento seguro
El pre-aprovisionamiento de claves a más de 10.000 balizas requiere un flujo de trabajo seguro y auditable. Tres enfoques con compromisos:
| Método | Velocidad | Seguridad | Escalabilidad |
|---|---|---|---|
| Pre-aprovisionamiento (grabado en fábrica) | Rápido (por lotes) | Alta (acceso físico controlado) | Limitado por la unicidad de claves |
| Aprovisionamiento OTA (BLE) | ~10 s/baliza | Media (MANA posible durante la ventana) | 10K unidades en ~28 horas |
| Aprovisionamiento por toque NFC | ~2 s/baliza | Alta (proximidad física) | 10K unidades en ~6 horas |
El aprovisionamiento por toque NFC se recomienda para despliegues de alta seguridad. La estación de aprovisionamiento escribe la clave maestra EID, la EIRK y la clave de sesión EAD en la memoria flash segura de la baliza (Protected Storage en nRF52) mediante NFC. La baliza entra inmediatamente en modo seguro y no puede volver a aprovisionarse sin un restablecimiento de fábrica.
Revocación de claves: gestión de balizas comprometidas
Cuando una baliza es robada físicamente o se sospecha que su material de clave está comprometido, el gestor de la flota debe revocar sus claves. Estrategias de revocación:
- Revocación individual: añadir la EIRK de la baliza a una lista negra en el servidor. Coste: búsqueda O(1) por paquete ADV. Escala hasta ~100.000 entradas antes de requerir optimización con filtro Bloom.
- Rotación de claves segmentada: la flota se divide en segmentos de claves (A/B/C). Si el segmento B está comprometido, solo se rotan las claves del segmento B (20% de la flota). Las balizas no afectadas siguen operando.
- Rotación global de claves: rotación de emergencia de todas las claves de la flota. Requiere re-aprovisionar todas las balizas. Coste: ~28 horas para 10K unidades vía OTA BLE. Reservado para compromisos catastróficos.
Almacenamiento seguro de claves en la baliza
El material de clave debe almacenarse en memoria protegida por hardware para evitar su extracción vía JTAG, SWD o volcado de firmware. nRF52 Secure Debug (nRF52840+) deshabilita permanentemente el acceso de depuración tras el aprovisionamiento. Protecciones alternativas:
| Método de almacenamiento | Dificultad de extracción | Plataformas |
|---|---|---|
| KMU (unidad de gestión de claves) | Prácticamente imposible (motor AES de hardware) | nRF52840, nRF5340 |
| Flash protegida (ACL) | Difícil (requiere exploit de firmware) | serie nRF52 |
| Cifrado de flash ESP32 | Media (clave en efuse, grabable) | ESP32, ESP32-C3 |
| Flash sin protección | Fácil (lectura SWD) | Cualquiera (no recomendado) |
Ciclo de vida de la clave: del aprovisionamiento a la retirada
- Generación: el servidor de claves genera claves únicas por baliza (o por segmento). Las claves maestras usan CSPRNG (no LFSR pseudoaleatorio).
- Aprovisionamiento: las claves se escriben en la baliza vía NFC/BLE. Secure Debug habilitado → claves escritas → Secure Debug deshabilitado permanentemente.
- Uso activo: la baliza deriva EIDs diarios, cifra ADV con claves EAD. El servidor mantiene una base de datos de claves sincronizada.
- Rotación: rotación periódica de claves (recomendado: trimestral para claves maestras, diaria para claves de sesión EID).
- Revocación: la EIRK de la baliza comprometida se añade a la lista negra del servidor. El firmware del gateway se actualiza para rechazar EIRKs en la lista negra.
- Retirada: la baliza se devuelve físicamente. Borrado seguro (borrado de flash + restablecimiento de fábrica). Las claves se eliminan de la base de datos del servidor.
Arquitectura de gestión de claves a escala de flota
Para despliegues que superan las 1.000 balizas, se hace necesario un servicio dedicado de gestión de claves (KMS). Componentes de la arquitectura:
- Servidor de claves: generación y almacenamiento de claves respaldados por HSM. API REST para el aprovisionamiento de balizas y la distribución de claves a los gateways.
- Agente de aprovisionamiento: herramienta CLI/Python que se comunica con las balizas vía NFC/BLE para inyectar claves. Registra cada evento de aprovisionamiento con el número de serie de la baliza, la marca de tiempo y el ID del operador.
- Sincronización de claves del gateway: los gateways obtienen periódicamente los calendarios de rotación de claves y las listas negras del servidor de claves vía HTTPS (autenticación mutua mTLS).
- Registrador de auditoría: registro inmutable de todas las operaciones de claves (aprovisionar, rotar, revocar). Almacenado en una base de datos de solo anexión para cumplimiento normativo.
La gestión de claves criptográficas para flotas de Bluetooth Beacon es la diferencia entre un despliegue que se degrada de forma elegante y uno que se convierte en un pasivo de seguridad tras 12 meses. La combinación de rotación EID diaria, aprovisionamiento NFC, almacenamiento protegido por hardware y revocación segmentada proporciona defensa en profundidad a escala de flota. Nuestro equipo ofrece diseño de arquitectura de gestión de claves y automatización de aprovisionamiento para despliegues de Bluetooth Beacon —contáctenos para una consultoría técnica.
