Un nodo LoRaWAN en el medio de una finca o una camaronera transmite por radio, sin cables ni control físico sobre el aire que atraviesa la señal. Cualquiera con un gateway compatible y dentro del rango puede capturar esos paquetes. Que eso no sea un problema de seguridad depende enteramente de una pieza: el cifrado AES-128 que protege cada trama desde el momento en que sale de la antena del dispositivo. Entender cómo funciona —y dónde se ha demostrado débil en la práctica— es clave para desplegar una red que no solo funcione, sino que sea confiable.
Qué cifra AES-128 y qué solo firma
LoRaWAN no aplica un único cifrado “de punta a punta” indiferenciado: separa dos funciones criptográficas con dos claves distintas.
- AppSKey (Application Session Key): cifra el payload, es decir, los datos del sensor (temperatura, oxígeno disuelto, nivel de combustible). Solo el dispositivo y la aplicación final —no el operador de la red— tienen esta clave, así que ni el network server ve el dato en claro.
- NwkSKey (Network Session Key, dividida en
FNwkSIntKeyySNwkSIntKeydesde LoRaWAN 1.1): calcula el MIC (Message Integrity Code), un sello de 4 bytes que certifica que la trama no fue alterada ni proviene de un dispositivo desconocido.
Esta separación es intencional: en un despliegue con un proveedor de red pública (como The Things Network o un operador de telecomunicaciones), el operador enruta el tráfico y verifica su integridad, pero nunca puede leer el contenido del sensor. Esa garantía es la que hace viable compartir infraestructura de gateways entre distintos clientes sin comprometer la confidencialidad de cada uno.
Cómo se cifra realmente una trama: CCM* y AES-CTR
El payload no se cifra con AES en modo simple (ECB), que dejaría patrones repetidos visibles en el texto cifrado. LoRaWAN usa una variante del modo CCM* (Counter with CBC-MAC, una construcción estandarizada en IEEE 802.15.4) que combina dos mecanismos AES-128:
- Cifrado en modo contador (CTR): el payload se combina por XOR con un flujo de bytes generado al cifrar un bloque contador con AppSKey. Ese contador incorpora el frame counter (
FCntUp/FCntDown), que aumenta con cada mensaje enviado. - Autenticación con CMAC: el MIC se calcula aplicando AES-CMAC sobre la trama completa con NwkSKey, produciendo los 4 bytes que el servidor de red valida antes de aceptar el paquete.
El frame counter cumple aquí el papel de un nonce: mientras nunca se repita para la misma clave de sesión, dos tramas jamás se cifran con el mismo flujo de bytes. Esa es, además, la primera línea de defensa contra ataques de repetición (replay): el servidor de red descarta cualquier trama cuyo contador sea menor o igual al último valor válido recibido de ese dispositivo.
Dónde se ha roto esta garantía en la práctica
La teoría es sólida, pero investigaciones de seguridad sobre LoRaWAN 1.0.x —incluyendo trabajo publicado por NCC Group y análisis académicos posteriores— identificaron un escenario real donde el esquema falla: dispositivos en modo ABP (activación por personalización, con claves de sesión fijas de fábrica) que pierden alimentación y reinician su frame counter a 0 en memoria volátil, mientras el servidor conserva el último valor recibido. Si el firmware no persiste el contador en memoria no volátil, el dispositivo puede terminar reutilizando un par (clave, contador) ya usado, lo que en un cifrado por flujo como CTR abre la puerta a un ataque de crib dragging: con dos tramas cifradas con el mismo flujo de clave, el atacante puede recuperar información del texto plano mediante XOR entre ambos cifrados, sin necesidad de romper AES en sí.
La propia especificación reconoció el problema: LoRaWAN 1.0.4 exige explícitamente que los contadores no se reinicien a cero tras un reinicio, obligando a guardarlos en flash o EEPROM. Repasamos esta diferencia entre modos de activación con más detalle en nuestro artículo sobre OTAA vs. ABP: en OTAA, cada join genera un DevAddr y claves de sesión nuevas, lo que elimina de raíz el riesgo de reutilizar un contador con la misma clave.
El punto débil real no es el algoritmo, es la clave raíz
AES-128 en sí no tiene ataques prácticos conocidos: con 2^128 combinaciones posibles, la fuerza bruta es inviable con cualquier cómputo actual o previsible. El riesgo operativo está en otro lugar: la AppKey (la clave raíz de la que se derivan las claves de sesión en OTAA) se graba una sola vez en el dispositivo y, si un atacante obtiene acceso físico al nodo, puede intentar extraerla leyendo directamente la memoria del microcontrolador —salvo que el firmware active los fuses de protección de lectura (readout protection) que traen la mayoría de los MCU modernos.
Por eso, en un despliegue serio, la seguridad de la red depende de tres prácticas concretas, no solo del algoritmo:
- Provisionar cada AppKey de forma única por dispositivo, nunca compartir una misma clave entre lotes de nodos (una clave filtrada en un dispositivo no debe comprometer al resto de la red).
- Activar la protección de lectura de flash del microcontrolador al programar el firmware en fábrica, para que la clave no sea legible ni con acceso físico directo.
- Usar OTAA en vez de ABP siempre que el dispositivo pueda completar el intercambio Join Request/Join Accept, precisamente para heredar la rotación automática de claves de sesión que evita el escenario de reutilización de contador descrito arriba.
LoRaWAN 1.1: separar aún más las responsabilidades
LoRaWAN 1.1 introdujo un cambio estructural: donde 1.0.x deriva NwkSKey y AppSKey de una única AppKey, 1.1 separa dos claves raíz —AppKey (para el application server) y NwkKey (para el network server y el join server)—. Esto permite que un operador de red y el propietario de la aplicación mantengan raíces de confianza completamente independientes, algo relevante cuando el join server, el network server y el application server pertenecen a organizaciones distintas. En la práctica, la mayoría de redes desplegadas hoy —incluyendo ChirpStack y The Things Stack en sus configuraciones más comunes— siguen operando en 1.0.x, así que el modelo de una sola clave raíz por dispositivo sigue siendo el escenario más frecuente en campo.
Qué significa esto para un despliegue de campo
Para sensores de monitoreo agrícola o acuícola desplegados a kilómetros de la oficina, la seguridad del cifrado no es un ejercicio académico: un atacante que falsifique lecturas de oxígeno disuelto o manipule un comando hacia un actuador remoto puede causar pérdidas reales de producción. Las decisiones que realmente mueven la aguja de seguridad son las de aprovisionamiento —OTAA por defecto, claves únicas por dispositivo, protección de lectura de flash activa— y no una configuración fina del algoritmo, que ya viene resuelta por el estándar. El Gateway LoRaWAN de Yubox y los nodos que se conectan a él siguen este esquema: AES-128 con OTAA de fábrica, sin exponer claves de sesión fijas en producción.
Conclusión
AES-128 en LoRaWAN combina cifrado (AppSKey, para confidencialidad del payload) y autenticación (NwkSKey, para el MIC) sobre una estructura CCM* que ya ha sido auditada extensamente. Las vulnerabilidades documentadas no rompen el algoritmo: explotan implementaciones descuidadas —contadores no persistidos, claves compartidas entre dispositivos, memoria sin proteger—. Una red bien aprovisionada, con OTAA y buenas prácticas de fábrica, hereda toda la seguridad que el estándar promete.
¿Necesita validar el aprovisionamiento de claves de su red LoRaWAN o evaluar el nivel de seguridad de un despliegue existente? Escríbanos: revisamos la arquitectura y le ayudamos a cerrar los puntos débiles antes de que sean un problema.