Antes de que un dispositivo LoRaWAN pueda transmitir su primer dato, necesita “activarse”: obtener una dirección de red y las claves de sesión con las que va a cifrar y firmar cada paquete. El estándar define dos formas de hacerlo —OTAA (Over-The-Air Activation) y ABP (Activation By Personalization)— y la elección no es un detalle de firmware menor: afecta la seguridad de la red, qué tan fácil es reemplazar un nodo dañado y si un dispositivo puede moverse entre redes sin reconfigurarlo a mano.
Qué necesita todo dispositivo LoRaWAN para transmitir
Da igual el método de activación: al final del proceso, el nodo termina con tres elementos en memoria:
- DevAddr: una dirección de 32 bits que lo identifica dentro de la red actual (no es única globalmente, solo dentro de esa red).
- NwkSKey (clave de sesión de red): protege la integridad de cada paquete frente al servidor de red, que verifica el MIC (Message Integrity Code) de 4 bytes en cada trama.
- AppSKey (clave de sesión de aplicación): cifra el contenido útil (payload) de punta a punta con AES-128, de modo que ni el propio servidor de red ve los datos del sensor en claro —solo la aplicación que tiene esa clave puede leerlos.
La diferencia entre OTAA y ABP está en cómo llegan esos tres valores al dispositivo.
OTAA: el dispositivo negocia sus claves con la red
En OTAA, el nodo no trae un DevAddr ni claves de sesión grabadas de fábrica. En su lugar, viene con tres identificadores permanentes:
- DevEUI: identificador global de 64 bits (EUI-64) único del dispositivo, análogo a una dirección MAC.
- JoinEUI (llamado AppEUI en LoRaWAN 1.0.x): identifica al join server que debe procesar la solicitud.
- AppKey: una clave raíz AES-128 que nunca viaja por el aire. Con ella, tanto el dispositivo como el join server derivan de forma independiente las claves de sesión.
Cuando el nodo se enciende por primera vez (o necesita reactivarse), envía un Join Request con su DevEUI, JoinEUI y un número aleatorio de un solo uso llamado DevNonce. Si el join server valida la solicitud —y en LoRaWAN 1.0.x rechaza cualquier DevNonce ya usado antes, para frenar ataques de repetición—, responde con un Join Accept cifrado con el AppKey. Ese mensaje trae el DevAddr y los parámetros de red; a partir de ahí, dispositivo y servidor derivan NwkSKey y AppSKey de forma independiente, sin haberlas transmitido nunca por el aire.
El resultado práctico: cada vez que un nodo hace join, obtiene un DevAddr y unas claves de sesión nuevas. Si alguien capturara tráfico de una sesión anterior, esas claves ya no sirven para la sesión actual.
ABP: las claves de sesión vienen grabadas de fábrica
En ABP no hay negociación: el DevAddr, el NwkSKey y el AppSKey se graban directamente en el dispositivo (por ejemplo, al programarlo o configurarlo por USB) y se cargan con los mismos valores en el servidor de red. El nodo puede empezar a transmitir de inmediato, sin esperar un intercambio Join Request/Join Accept.
Eso resuelve un problema real en ciertos entornos: si el dispositivo nunca tiene cobertura suficiente para completar un join (por ejemplo, algunos nodos que solo transmiten y no tienen ventana de recepción fiable), ABP evita depender de ese intercambio inicial.
El costo es que esas claves de sesión son fijas mientras no se reprogramen a mano. Si un atacante llega a comprometerlas, no hay forma de rotarlas de forma remota: hay que reprogramar el dispositivo físicamente.
El problema del contador de tramas en ABP
Cada trama LoRaWAN incluye un contador (frame counter) que aumenta con cada uplink y que el servidor de red usa, junto con la clave de sesión, para cifrar el payload en modo CTR. Ese contador cumple la misma función que un nonce: si dos tramas se cifraran alguna vez con la misma clave y el mismo valor de contador, un atacante que capture ambas podría deducir información sobre el texto plano por XOR de los dos cifrados.
En OTAA esto no es un problema porque cada join genera un DevAddr y claves de sesión nuevas, así que el contador siempre repite desde un punto distinto en términos criptográficos. En ABP, en cambio, la clave de sesión es la misma indefinidamente: si el dispositivo pierde alimentación y el contador se reinicia a 0 en memoria volátil —mientras el servidor sigue esperando el valor donde se quedó—, se puede llegar a repetir un par (clave, contador) ya usado. Por esta razón, la especificación LoRaWAN 1.0.4 exige explícitamente que los contadores de dispositivos ABP nunca se reinicien a cero tras un reinicio, lo que obliga a guardar el contador en memoria no volátil (flash o EEPROM) y no solo en RAM.
En la práctica, esto convierte a ABP en una opción que exige más disciplina de implementación en el firmware: hay que persistir el contador correctamente para no reabrir la vulnerabilidad que el propio estándar identificó y corrigió.
Comparación rápida
| OTAA | ABP | |
|---|---|---|
| Qué se graba de fábrica | DevEUI, JoinEUI, AppKey | DevAddr, NwkSKey, AppSKey |
| Claves de sesión | Nuevas en cada join | Fijas hasta reprogramar |
| Requiere intercambio inicial | Sí (Join Request/Accept) | No, transmite de inmediato |
| Rotación de claves ante compromiso | Automática (nuevo join) | Manual, reprogramando el nodo |
| Riesgo de reutilización de contador | Prácticamente nulo | Real si no hay memoria persistente |
| Recomendación del estándar y la mayoría de network servers | Preferida | Solo casos puntuales |
Cuál elegir en un despliegue real
Para la gran mayoría de despliegues de campo —sensores de humedad de suelo, oxígeno disuelto, calidad de aire, energía o combustible—, OTAA es la opción recomendada: no exige provisionar manualmente DevAddr y claves de sesión en el servidor, permite reemplazar un nodo dañado por otro nuevo con solo cargar su DevEUI/AppKey al backend, y renueva las claves de sesión automáticamente ante cualquier reinicio o pérdida de cobertura prolongada. El Sensor HUB de Yubox opera en OTAA de fábrica, con ADR activo, precisamente para simplificar el aprovisionamiento cuando se despliegan decenas o cientos de nodos en una red de gateways LoRaWAN.
ABP conserva sentido en escenarios acotados: laboratorios de prueba sin cobertura fiable durante el desarrollo del firmware, dispositivos legacy que nunca implementaron el procedimiento de join, o pruebas de concepto rápidas donde no vale la pena levantar un join server. Fuera de esos casos, la combinación de mejor seguridad y menor esfuerzo operativo hace que casi todos los fabricantes —y casi todos los network servers modernos, como ChirpStack o The Things Stack— recomienden OTAA como default.
Conclusión
OTAA y ABP resuelven el mismo problema —darle a un nodo una dirección y unas claves de sesión— por caminos opuestos: uno negocia y renueva esas claves en cada join, el otro las fija de una vez en fábrica. Esa diferencia se traduce en seguridad (rotación automática vs. claves fijas), en operación (aprovisionar un DevEUI vs. sincronizar contadores manualmente) y en resiliencia ante fallos de memoria. Para casi cualquier despliegue de producción en campo, OTAA es la elección correcta desde el primer nodo.
¿Está diseñando una red LoRaWAN y no sabe qué método de activación conviene para su caso? Escríbanos: revisamos su arquitectura y le ayudamos a definir el aprovisionamiento correcto desde el arranque del proyecto.