Para que un dispositivo sea parte de una red LoRaWAN tiene que ser personalizado y activado.
La personalización se realiza al darle un identificador único a cada dispositivo. Se requiere dos identificadores, el primero para conocer el dispositivo final y otro para saber a qué aplicación corresponde dicho dispositivo.
La activación puede ser lograda de dos maneras, Activación por aire (OTAA) o mediante la Activación por personalización (ABP).
OTAA
Para la activación OTAA, el dispositivo debe seguir un procedimiento de unión previo a participar en el intercambio de data con el servidor de red. El procedimiento de unión requiere que se realice la personalización del dispositivo con la siguiente información antes de empezar:
- Identificador de dispositivo (DevEUI): es una ID global del dispositivo final que utiliza el protocolo de direccionamiento IEEE EUI64 que identifica de forma exclusiva el dispositivo final. Es similar a una dirección MAC y algunos dispositivos tienen incorporada su propio DevEUI.
- Identificador de aplicación (AppEUI): Es un ID global de aplicación basado en el protocolo de direccionamiento IEEE EUI64. Se almacena en el dispositivo final antes de ejecutar el procedimiento de activación. Identifica el servidor de aplicación y es similar a un número de puerto. En algunos documentos se refieren a éste como JoinEUI.
- Clave de aplicación (AppKey): es una clave simétrica AES-128 (Advanced Encryption Standard) de 128 bits específica para cada dispositivo final. Es utilizada para generar el Código de integridad del mensaje (MIC) para asegurar la integridad de los mensajes. El dispositivo y el servidor deben almacenar la misma AppKey.
El DevNonce es un número aleatorio generado por el dispositivo al realizar la solicitud de unión a la red. Para cada dispositivo final, el servidor rastrea cierta cantidad de valores de DevNonce usados por el dispositivo en el pasado e ignora cualquier solicitud del dispositivo con estos valores.
Proceso de activación mediante OTAA
En el dispositivo están ya definidos el DevEUI, AppEUI y el AppKey.
El dispositivo final envía un mensaje de solicitud de unión a la red el cual contiene el DevNonce, AppEUI y el DevEUI, sobre este mensaje se genera el MIC a partir del AppKey.
El mensaje de solicitud de unión no está encriptado. El dispositivo no puede activarse sólo con enviar la solicitud al servidor de red, debe esperar la respuesta de éste. Cuando el mensaje llega al servidor de red, éste verifica que el DevNonce no haya sido utilizado previamente, luego calcula su propio MIC a partir de los DevEUI y AppEUI que ha recibido y el AppKey guardado en él.
El dispositivo es autenticado si el MIC del dispositivo y el calculado por el servidor son iguales.
Una vez aceptado, el servidor genera los siguientes valores: DevAddr, AppNonce y NetID.
- Dirección de dispositivo (DevAddr): Es un número de 32 bits que identifica el dispositivo con la red actual. El DevAddr es similar a una dirección IP de un cliente.
- AppNonce: o JoinNonce, es un valor de contador específico del dispositivo (que nunca se repite) proporcionado por el servidor de unión y utilizado por el dispositivo final para derivar las claves de sesión red y de aplicación.
- NetID: Un identificador de red.
Luego el servidor de red envía el mensaje de unión aceptada el cual está encriptado con el AppKey y se le genera un MIC. Este mensaje contiene el DevAddr, AppNonce y NetID, además agrega a este mensaje otros campos: DLSettings (proporciona algunos de los parámetros de enlace descendente), RxDelay (que es el retraso entre TX y RX) y el CFList (que es una lista opcional de parámetros de la red a la que se une el dispositivo final). El campo opcional CFList es específico de la región y se define en la capa física (PHY).
Una vez que el mensaje de respuesta de solicitud de acceso a la red llega al dispositivo final, ambos extremos (nodo y servidor) almacenarán los mismos AppNonce y DevNonce. A partir de estos valores se generan las claves para encriptar la información, es decir las claves de sesión de red y aplicación: NwkSKey y AppSKey, respectivamente.
El nodo y el servidor de red generan cada uno sus claves de sesión, las cuales después de todo el proceso de unión deben ser iguales.
El servidor de red envía la clave de sesión de aplicación al servidor de aplicación.
De esta manera se personaliza y activa el dispositivo mediante OTAA, terminando con la generación de las llaves para la encriptación.
ABP
En determinadas circunstancias, los dispositivos finales pueden activarse mediante personalización. La activación por personalización vincula directamente un dispositivo final a una red específica sin pasar por la solicitud de unión (procedimiento de aceptación de unión).
La activación de un dispositivo final por personalización significa que el DevAddr y las dos claves de sesión NwkSKey y AppSKey se almacenan directamente en el dispositivo final en lugar del DevEUI, AppEUI y AppKey. El dispositivo final está equipado con la información requerida para participar en una red LoRa específica cuando se inicia. Cada dispositivo debe tener un conjunto único de NwkSKey y AppSKey.
Comprometer las claves de un dispositivo no debe comprometer la seguridad de las comunicaciones de otros dispositivos. El proceso para construir esas claves debe ser tal que las claves no puedan derivarse de ninguna manera de la información disponible públicamente como la dirección de nodo.
Se considera que es el menos seguro debido a que este método omite todos los pasos de unión a la red de OTAA. Además, las claves se almacenan en el dispositivo, a diferencia de OTAA que se generan a partir del proceso de unión. Sin embargo, sigue manteniendo la encriptación de dos niveles de LoRaWAN.
Referencias
- LoRa Alliance, Inc. (2017), “LoRaWAN 1.1 Specification,” [Online]. Disponible en: https://lora-alliance.org/sites/default/files/2018-04/lorawantm_specification_-v1.1.pdf.
- LoRa Alliance, Inc. (2017), “LoRaWAN Backend Interfaces 1.0 Specification.” Disponible en: https://lora-alliance.org/sites/default/files/2018-04/lorawantm-backend-interfaces-v1.0.pdf
