Ciberseguridad en LoRa y LoRaWAN – Contexto y un poco de historia

Desde el inicio del siglo XXI, el concepto de Internet de las Cosas (IoT) ha ido variando gradualmente desde una serie de vagas ideas relacionadas con la interconexión de objetos cotidianos e Internet hacia una serie de tecnologías, prácticas e infraestructuras cada vez mejor definidas.

La ubicuidad de estos objetos y su conexión a Internet se pudo hacer compatible gracias a las redes LPWAN (Low Power Wide Area Networks), concepto paraguas que engloba diversas tecnologías de comunicación inalámbrica y banda estrecha como LoRaWAN, SigFox o ZigBee que permiten este tipo de interconexiones con un consumo energético relativamente pequeño. Desde el punto de vista de la ciberseguridad, la omnipresencia de estas redes implica un incremento proporcional de las superficies de ataque de un sistema por lo que, en este sentido, su estudio es una labor necesaria.

Debido a su popularidad, la siguiente serie de artículos se centrará en la seguridad de las redes LoRaWAN, desde la capa física hasta los despliegues de mayor nivel.

LoRa y LoRaWAN

LoRaWAN es una tecnología de comunicaciones inalámbricas de baja potencia y área amplia basada en redes en estrella entre los dispositivos IoT y las pasarelas LoRaWAN (gateways), y redes IP desde los gateways hasta los servidores de red y aplicación.

Los dispositivos LoRaWAN se comunican con los gateways de forma inalámbrica empleando normalmente el estándar LoRa en bandas ICM. Es importante entonces establecer la diferencia entre LoRa y LoRaWAN: LoRa es una tecnología de capa física que establece cómo distintos dispositivos de baja potencia se comunican entre sí de forma inalámbrica empleando una modulación propietaria de banda estrecha denominada CSS (Chirp Spread Spectrum), mientras que LoRaWAN es una tecnología de acceso al medio (MAC) para redes en estrella que proporciona, entre otros, servicios de autenticación, cifrado y adaptación dinámica del ancho de banda.

La especificación de LoRaWAN, a diferencia de LoRa, ha sido puesta a disposición del público por la LoRa Alliance, la cual se da en dos grandes versiones, la 1.0 y la 1.1, difiriendo fundamentalmente en la gestión de claves.

Aunque la especificación de LoRa se ha mantenido cerrada y restringida a los fabricantes de chips LoRa, las características del protocolo fueron absolutamente determinadas mediante la ingeniería inversa de las señales intercambiadas por Matthew Knight y Balint Seeber. Esta investigación resultó en la creación de un módulo de GNU Radio (gr-lora) cuyo código fuente se puede descargar libremente desde GitHub.

LoRa al desnudo

LoRa es un protocolo de capa física en comunicaciones inalámbricas privativo y diseñado por Semtech para trabajar en las bandas ICM alrededor de 900 MHz (la frecuencia exacta depende de la región). En particular, en la Unión Europea, la frecuencia de trabajo cae alrededor de los 868 MHz. En las bandas ICM conviven múltiples tecnologías de comunicaciones que, por legislación, deben cumplir ciertas normas de aceptancia, potencia o ciclo de trabajo (que en estas bandas está entre el 0,1% y el 1%). Debido a esto último, la información enviada por LoRa adquiere forma de ráfagas con duración y frecuencia limitadas, por lo que puede pasar un tiempo de varios segundos entre el envío de una trama y la siguiente.

De cara a mejorar la inmunidad a la interferencia de otras tecnologías, LoRa emplea una modulación de espectro ensanchado denominada CSS (Chirp Spread Spectrum), en la cual la información digital se codifica como distintas rotaciones de rampas de frecuencia dentro de los límites de cada canal denominadas “chirps”:

En la Unión Europea (región ITU-1), la banda de 868 se divide en 10 canales LoRa, con anchos de 125 y 250 kHz para comunicaciones ascendentes (nodo-pasarela) y de 125 kHz solo para canales descendentes (pasarela-nodo). Siendo fijo el ancho de estos canales, la tasa de bits transmitida se controla ajustando dos parámetros: el spreading factor (SF) y el chirp rate (CR). Estos parámetros son en realidad sinónimos de “bits por símbolo” (que acepta valores entre 7 y 12) y “tasa de símbolos” respectivamente. Además, estos parámetros no son independientes, ya que la tasa de símbolos se calcula a partir de los bits por símbolo dividiendo el ancho de banda del canal por 2^SF. Es decir, incrementar el SF en una unidad (un bit) duplica la cantidad de símbolos que se pueden codificar y, al mismo tiempo, reduce la cantidad de chirps que se envían a la mitad.

En la práctica, como la cantidad de bits por unidad de tiempo es producto del CR por el SF, y como para un aumento lineal del SF se produce una disminución exponencial del CR, lo que sucede es que para mayores SF se obtienen menores tasas de transmisión de información. Esto permite ajustar la velocidad de envío de información en función de factores como la contención del canal, ruido, etcétera.

De cara a aumentar la resiliencia de la transmisión, la información es transformada en varios pasos antes de ser enviada al medio. En particular:

• Los símbolos se ordenan en código Gray (de forma que la confusión de un símbolo con el adyacente sólo impacte en un bit)
• La información es aleatorizada aplicando un XOR bit a bit a la misma junto una secuencia de whitening, la cual no se corresponde con ninguna de las documentadas por Semtech. Esta secuencia de whitening fue derivada experimentalmente por Knight y Seeber (2016).
• Los bits son reordenados con un entrelazador diagonal cuya descripción precisa tampoco aparece en las patentes de Semtech. El algoritmo de entrelazamiento también fue descifrado experimentalmente por Knight y Seeber (2016).
• Se dota de redundancia a la información mediante el empleo de códigos Hamming de tasas variables de 4/5, 4/6, 4/7 y 4/8, con ordenaciones de bit no estándares.

El resultado de estas transformaciones (debido a los bits de paridad introducidos por los códigos Hamming) es una tasa de envío más reducida pero mayor robustez contra ruido e interferencias.

Una vez que el receptor ha sido capaz de sincronizarse con el preámbulo de una ráfaga y descodificar la información contenida en él, el resultado es una trama LoRa PHY con la siguiente estructura:

Preámbulo

Cabecera (4/8)

Payload (4/N)

CRC (opcional)

Donde la cabecera tiene una tasa de codificación fija de 4/8 (mayor redundancia posible) e incluye información como el tamaño del payload, la tasa de codificación del payload y si hay un CRC presente o no. Es en este payload donde se incluyen las tramas LoRaWAN (tramas MAC).

LoRaWAN al desnudo

Si LoRa PHY define cómo se deben intercambiar paquetes a nivel físico, LoRaWAN especifica cómo utilizar esos paquetes para crear redes. Además, a diferencia de LoRa PHY, la espcificación LoRaWAN es abierta y permite implementaciones libres.

Las redes LoRaWAN son redes en estrella en las que uno o varios nodos finales se comunican con uno o más concentradores / pasarelas mediante LoRa PHY. La información recibida por las pasarelas LoRa es enviada a servidores de aplicación a través de una red de retorno (backhaul) de tipo IP, los cuales a su vez pueden responder a las tramas recibidas. LoRaWAN también ofrece servicios de autenticación, confidencialidad, e integridad mediante AES128.

Un servidor de red, ubicado entre las pasarelas y los servidores de aplicación, se encarga de gestionar el acceso a la red, eliminar paquetes duplicados, ajustar las tasas de transmisión, determinar la mejor pasarela para enviar una respuesta de los servidores de aplicación, etcétera.

En esta arquitectura, el servidor de red a veces se desacopla en el servidor de unión (Join Server), encargado de determinar quién tiene acceso a la red y el servidor de red propiamente dicho, el cual gestiona el resto de servicios MAC.

Los distintos elementos que integran la red hacen necesaria la existencia de una serie de identificadores que permitan diferenciarlos de los demás. Estos identificadores son:

• DevEUI: identificador de 64 bits, único para cada dispositivo final y gestionado por el fabricante.
• AppEUI: identificador de 64 bits, gestionado por el operador de los servidores de unión y que identifica los distintos servidores de aplicación en el otro extremo de la red.
• DevAddr: identificador de 32 bits, gestionado por el servidor de red, que identifica unívocamente a un dispositivo final que ha completado el procedimiento de activación en la red. De forma análoga a las direcciones IP, hasta 24 de los bits más significativos del DevAddr componen el identificador de red (NetID) y es asignado por la LoRa Alliance. Este identificador permite aprovechar la cobertura de otras redes para acceder a la red deseada mediante mecanismos de roaming.

Aunque toda la comunicación LoRa se da entre los nodos finales y las pasarelas, todos los servicios de capa MAC de LoRaWAN se implementan en el servidor de red. En las redes LoRaWAN las pasarelas son meros repetidores de las tramas LoRa que reciben desde las bandas ICM y la red de retorno. Por lo tanto, interactuar con la capa MAC de LoRa es interactuar con el servidor de red.

Desde el punto de vista de la ciberseguridad, las comunicaciones son protegidas mediante AES128 tanto para cifrado como para firma de mensajes, confiriendo cierto grado de confidencialidad e integridad. El desacoplo del backend IP en servidores de red y aplicación motiva el empleo de dos claves AES128: una para proteger los metadatos de la capa MAC (clave de sesión de red, o NwkSKey), y otra para proteger los payloads de aplicación (clave de sesión de aplicación, o AppSKey).

El proceso de registro en la red se denomina activación, y tiene implicaciones en la gestión de estas claves. LoRaWAN ofrece dos métodos de activación:

• • OTAA (Over-The-Air Activation): es el mecanismo más simple y al mismo tiempo el más recomendado. El nodo final envía un paquete MAC de tipo “Join Request”, el cual contiene el DevEUI del dispositivo, el AppEUI del servidor de aplicación con el que quiere comunicarse y cierto valor pseudoaleatorio denominado Esta solicitud está además firmada con un código de integridad de mensajes (MIC), empleando una clave de 128 bits denominada AppKey, precompartida por los nodos, la red y los servidores de aplicación. La autenticación se consigue validando la corrección del MIC a partir del AppKey.Si la solicitud es aceptada, la red responde con un mensaje de tipo “Join Accept” cuyo contenido está cifrado con la AppKey, e incluye los parámetros AppNonce y el NetID. Ambos extremos generan un par AppSKey / NewSKey efímero en base a la información intercambiada, con una validez limitada al período de presencia en la red hasta la siguiente activación.
• ABP (Activation By Personalisation): Al emplear este modo, los nodos cuentan con la DevAddr, NwkSKey y AppSkey configurados de antenamo. Debido a que esta información ya existe, los nodos pueden comunicarse con la red directamente sin intercambiar mensajes de Join.

Por regla general, se suele recomendar emplear OTAA, ya que el procedimiento de activación genera un par de claves de sesión efímeras AppSKey y NwkSKey distintas cada vez. En el caso de ABP, el aprovisionamiento y ciclo de vida de las claves queda a discreción del usuario.

Un aspecto importante a tener en cuenta al tratar con OTAA en LoRaWAN 1.0 es que su seguridad estriba en un algoritmo de derivación de claves que viene dado por:

NwkSKey = AES128(AppKey, 0x01|AppNonce|NetID|DevNonce|pad16)
AppSKey = AES128(AppKey, 0x02|AppNonce|NetID|DevNonce|pad16)

Es decir, como se utiliza el mismo material de claves para generar el AppSKey y el NwkSKey, el servidor de red podría utilizar los tokens intercambiados para derivar el también el AppSKey. Debido a que por el servidor de red pasan todos los paquetes de la red, podría así mismo descifrar todos los paquetes de la red que se activen mediante OTAA. Es decir, en LoRaWAN 1.0 la seguridad de la información de las aplicaciones está sujeta a la confianza que se tenga en la infraestructura de red. En despliegues privados, donde el propietario del servidor de red es el mismo que el de las aplicaciones, esto no supone un problema mayor que el derivado de la presencia de la misma clave en dos elementos distintos del sistema. Sin embargo, cuando el propietario de los servidores de aplicación es distinto al proveedor de servicios de red, el primero está confiando implícitamente en el compromiso del segundo de no interceptar sus comunicaciones. Este es, por ejemplo, el caso de The Things Network.

Este problema de confianza ha sido corregido en la especificación LoRaWAN 1.1, la cual introduce un segundo token de autenticación (el NwkKey) el cual se utiliza para derivar solamente la clave de sesión de red. Sin embargo, debido a la escasa implantación de LoRaWAN 1.1 y a la gran cantidad de dispositivos compatibles únicamente con LoRaWAN 1.0, se contemplan dos escenarios de downgrade a la versión 1.0:

• Dispositivo final 1.1, servidor de red 1.0: el dispositivo final ignora la AppKey de la que dispone y emplea la NwkKey para derivar tanto la AppSKey y la NwkSkey.
• Dispositivo final 1.0, servidor de red 1.1: curiosamente, este caso no está documentado en la especificación. Sin embargo, si se permitiese la activación de un dispositivo 1.0 contra una red 1.1, esta tendría que utilizar el AppKey para cifrar tanto los payloads de aplicación como los metadatos de la capa MAC, volviendo al caso inicial.

Se puede concluir que, en cualquiera de los casos, la aceptación de elementos 1.0 en la red provoca los mismos problemas de confianza. En el siguiente caso se investigará las consecuencias de la retrocompatibilidad de LoRaWAN 1.1 con LoRaWAN 1.0, y su impacto en la confianza de los despliegues.

Descubre nuestro trabajo y nuestros servicios de ciberseguridad en www.tarlogic.com/es/

En TarlogicTeo y en TarlogicMadrid.