Activación LoRaWAN: OTAA frente a ABP y gestión de claves

Antes de que un dispositivo LoRaWAN pueda enviar o recibir datos, debe completar un proceso llamado activación — el paso en el que el dispositivo obtiene su dirección de red y sus claves de sesión. El método de activación que elija afecta a la seguridad, la complejidad del despliegue y las operaciones diarias.

La especificación LoRaWAN define dos métodos de activación: OTAA (Over-The-Air Activation) y ABP (Activation By Personalization). Este artículo desglosa cómo funciona cada uno, los compara en paralelo y ofrece orientación práctica para la selección.

OTAA: Over-The-Air Activation

OTAA es el método de activación recomendado. Los dispositivos se envían sin claves de sesión y completan la autenticación por el aire tras el primer encendido.

Cómo funciona

La activación OTAA ocurre en tres pasos:

1. El dispositivo envía una Join Request

El dispositivo transmite una Join Request que contiene:

La Join Request se autentica con un MIC (Message Integrity Code) calculado usando la AppKey, lo que garantiza que el mensaje no ha sido manipulado.

2. El servidor de red valida y envía una Join Accept

Al recibir la Join Request, el servidor de red:

1. Busca la AppKey del dispositivo (y la NwkKey en LoRaWAN 1.1) por JoinEUI/AppEUI
2. Verifica el MIC para confirmar la integridad del mensaje
3. Comprueba el DevNonce para evitar la repetición (cada DevNonce solo puede usarse una vez)
4. Si tiene éxito, asigna una DevAddr (dirección de red del dispositivo de 32 bits)
5. Genera un Join Nonce (valor aleatorio del lado del servidor de red)
6. Construye y cifra un mensaje Join Accept con la AppKey

La Join Accept contiene:

3. El dispositivo deriva sus claves de sesión

El dispositivo descifra la Join Accept con su AppKey y luego deriva las claves de sesión a partir de la AppKey, el JoinNonce, el DevNonce y el NetID.

LoRaWAN 1.0.x (1.0.2 / 1.0.3 / 1.0.4) deriva dos claves:

• NwkSKey (Network Session Key): cálculo del MIC para mensajes de la capa MAC y cifrado de comandos MAC
• AppSKey (Application Session Key): cifrado de la carga útil de la aplicación

Derivación simplificada:

NwkSKey = aes_encrypt(AppKey, 0x01 | AppNonce | NwkID | DevNonce)
AppSKey = aes_encrypt(AppKey, 0x02 | AppNonce | NwkID | DevNonce)

LoRaWAN 1.1 introduce la separación de claves, derivando cuatro claves:

• FNwkSIntKey: Forward Network Session Integrity Key
• SNwkSIntKey: Serving Network Session Integrity Key
• NwkSEncKey: Network Session Encryption Key
• AppSKey: Application Session Key

LoRaWAN 1.1 cambia el nombre de AppEUI a JoinEUI y separa la NwkKey de la AppKey, lo que permite la separación de claves a nivel de red y a nivel de aplicación — la base para el roaming seguro.

Propiedades de seguridad de OTAA

• Las claves nunca viajan por el aire: la AppKey/NwkKey se aprovisionan en el dispositivo y en el servidor de red; las claves de sesión se derivan de forma independiente en ambos lados. Solo la Join Accept cifrada cruza la interfaz aérea.
• Protección contra repetición de DevNonce: cada DevNonce puede usarse exactamente una vez; los servidores registran los valores usados.
• Rotación de claves: un dispositivo puede volver a unirse en cualquier momento para obtener claves de sesión nuevas.
• Compatibilidad con roaming: el diseño de separación de claves de LoRaWAN 1.1 permite el roaming entre redes.

ABP: Activación por personalización

ABP omite por completo el procedimiento de unión. Los dispositivos se aprovisionan previamente con todos los parámetros de comunicación en el momento de fabricación y comienzan a enviar inmediatamente después del encendido.

Qué se aprovisiona previamente

Lo siguiente debe escribirse en el dispositivo antes del envío y registrarse en el servidor de red con antelación:

Los dispositivos ABP no necesitan un DevEUI, JoinEUI ni AppKey (a menos que se planee migrar a OTAA más adelante).

Cómo funciona

Un dispositivo ABP pasa directamente a funcionar tras el encendido:

1. Usa el DevAddr preconfigurado como su dirección de origen
2. Calcula los MIC con NwkSKey y cifra los comandos MAC con NwkSKey
3. Cifra/descifra los datos de aplicación con AppSKey
4. Comienza a transmitir en los canales predeterminados

No hay intercambio de Join Request / Join Accept.

El problema del contador de tramas

Los dispositivos ABP deben gestionar sus contadores de tramas de enlace ascendente (FCntUp) y de enlace descendente (FCntDown). Los servidores de red rastrean estos contadores para prevenir ataques de repetición: si un dispositivo se reinicia y su contador se restablece por debajo del valor que el servidor registró por última vez, sus tramas serán rechazadas.

Dos enfoques comunes:

• Restablecimiento del lado del servidor: restablecer manualmente los contadores de tramas del dispositivo en la plataforma (adecuado para depuración)
• Persistencia del lado del dispositivo: almacenar los contadores en almacenamiento no volátil y reanudar desde el último valor tras el reinicio (obligatorio para producción)

Lleva esta guía a tu proyecto

ManThink ofrece productos IoT para conectar dispositivos, desplegar redes y trabajar con datos. Consulta estos recursos de producto junto con las recomendaciones técnicas del artículo:

GD61 Gateway LoRaWAN para interiores · ThinkLink

Conoce los productos de ManThink y consulta tu proyecto →

OTAA vs ABP: comparación lado a lado

¿Cuál debería usar?

Use OTAA cuando

• Despliegues de producción — cualquier flota más allá de un puñado de dispositivos debería usar OTAA
• La seguridad importa — datos sensibles o requisitos de cumplimiento
• Gran escala — el DevAddr se asigna dinámicamente, evitando conflictos
• Se necesita roaming — despliegues entre redes o multirregión
• Redes LoRaWAN 1.1 — las funciones de seguridad de 1.1 dependen de OTAA

ABP es aceptable cuando

• Desarrollo y depuración — validar rápidamente la comunicación del dispositivo sin el handshake de unión
• Enseñanza y demostraciones — simplificar el flujo para que los estudiantes se centren en el intercambio de datos
• Despliegues muy pequeños y fijos — uno o dos dispositivos en un entorno controlado con bajos requisitos de seguridad
• Escenarios solo de enlace ascendente — dispositivos que solo transmiten, con necesidades mínimas de gestión de claves (aun así, sopesar el compromiso de seguridad)

Un error común

"ABP ahorra energía porque no hay procedimiento de unión."

No realmente. El procedimiento de unión cuesta muy poco — una Join Request y una Join Accept, normalmente completadas en unos segundos. En comparación con la vida útil de la batería de varios años de un dispositivo, la energía de la fase de unión es insignificante. Lo que ABP realmente ahorra es esfuerzo de configuración durante el desarrollo — y en producción esa comodidad tiene como costo una menor seguridad y una mayor sobrecarga operativa.

Notas prácticas

OTAA en la práctica

1. DevEUI debe ser globalmente único: use un EUI-64 de IEEE derivado de la MAC del dispositivo; nunca codifique un valor predeterminado de forma fija
2. Almacene AppKey de forma segura: es la clave raíz — su compromiso significa que toda la comunicación del dispositivo puede ser descifrada. Prefiera un elemento seguro, o al menos el cifrado de flash del MCU
3. Persista DevNonce: debe residir en almacenamiento no volátil e incrementarse continuamente entre reinicios. Una reversión provoca que el servidor de red rechace las Join Requests
4. Implemente reintento de join con backoff: evite saturar el canal si la red no está disponible temporalmente
5. Escuche en las ventanas de join: Join Accept llega en RX1 (predeterminado 5 s) y RX2 después de la Join Request; el dispositivo debe estar escuchando

ABP en la práctica

1. Persista los contadores de tramas: almacene FCntUp y FCntDown en almacenamiento no volátil (registros de respaldo RTC, flash o EEPROM)
2. Planifique DevAddr con cuidado: el NwkID de 7 bits debe coincidir con el NetID del servidor de red; la dirección de 25 bits debe ser única dentro de la red
3. Proteja las claves en la fabricación: las claves ABP se escriben en la fabricación — manténgalas fuera de los registros de producción y de los registros de prueba
4. Nunca confirme claves en repositorios públicos: si comparte código en GitHub o similar, no codifique NwkSKey y AppSKey de forma fija

Trabajar con la plataforma ThinkLink

En ThinkLink:

• Dispositivos OTAA: registre DevEUI y AppKey en la plataforma; el dispositivo se une automáticamente tras el encendido
• Dispositivos ABP: registre DevAddr, NwkSKey y AppSKey; el dispositivo se comunica de inmediato
• La plataforma muestra el estado de join y los contadores de tramas de cada dispositivo
• Si se produce un conflicto de contador de tramas, restablézcalo desde la página de gestión del dispositivo

Resumen

En conclusión: use OTAA en producción, ABP solo para depuración y enseñanza. Si tiene más de diez dispositivos, o si los dispositivos están en entornos que no puede controlar físicamente, OTAA es la única opción sensata.

Escrito conforme a las especificaciones LoRaWAN 1.0.4 y 1.1. Los detalles del protocolo siguen los documentos de especificación de LoRa Alliance; los consejos operativos se basan en la experiencia de la plataforma ThinkLink.

ThinkLink es el producto de plataforma IoT de ManThink, que ofrece gestión de red LoRaWAN, operaciones de dispositivos y servicios de datos.