Asegurar protocolos inalámbricos utilizando LoRaWAN como ejemplo

Hola Habr

Una vez más, me gustaría hablar sobre cómo se proporciona el nivel básico (léase: mínimo necesario) de seguridad de datos en redes inalámbricas utilizadas en dispositivos IoT, utilizando LoRaWAN como ejemplo.

¿Por qué LoRaWAN? En primer lugar, porque es un estándar bien descrito y bien desarrollado que debe guiarse como referencia si está desarrollando algún tipo de protocolo inalámbrico. En segundo lugar, porque es una solución de IoT muy nativa y típica; Por supuesto, puede desmontar la seguridad en Wi-Fi o LTE, pero para la mayoría de los desarrolladores esto será un análisis inútil: es poco probable que necesite escribir su propia implementación de Wi-Fi. En tercer lugar, son los dispositivos IoT de baja potencia en los que los desarrolladores guardan cada byte que a menudo resultan ser los que tienen más fugas: aquí LoRaWAN da una buena idea de cómo guardar bytes y no ser atacado. Cuarto, finalmente, porque literalmente en los últimos días, varios de nuestros clientes pidieron que les contaran más sobre la protección de datos en LoRaWAN, y con este artículo mato dos pájaros de un tiro.


Mensajería LoRaWAN entre servidor y dispositivo

Aunque el esquema de mensajes en LoRaWAN en la imagen parece bastante simple, esta simplicidad es engañosa: tiene mucho trabajo por hacer, y ni un solo píxel es superfluo. Ahora entenderás por qué.

Analizaremos el uso de LoRaWAN 1.0.2 como ejemplo y nos enfrentaremos a posibles amenazas, ya que un buen desarrollador siempre debe pensar no en cómo se protege su sistema, sino en cómo se puede romper. De lo contrario, alguien más lo pensará por él.

Entonces, ¿cuáles son las principales amenazas en la red inalámbrica y cómo protegerse de ellas?

Intercepción de datos del usuario.

La amenaza más simple es una intercepción de datos regular: Dado que las ondas de radio se propagan sin control, absolutamente cualquier persona puede tomar un receptor sintonizado al rango y tipo de modulación deseado, y escuchar todo lo que transmite.

La forma más fácil de protegerse contra esto es el cifrado de datos.

En LoRaWAN, los datos del usuario se cifran utilizando el algoritmo AES-128 con una longitud de clave de 128 bits (16 bytes), respectivamente. AES es un algoritmo confiable, sin embargo, en microcontroladores mínimamente modernos que ni siquiera tienen un bloque de cifrado de hardware, su uso no implica una sobrecarga significativa: en un Cortex-M3 con una frecuencia de 48 MHz, un bloque de 16 bytes se cifra en aproximadamente 100 μs desde cero.

Repetición de datos

En algunos casos, un atacante no necesita saber exactamente qué está transmitiendo allí. Por ejemplo, si su sensor tiene una ventana cerrada que transmite una cosa, y una abierta transmite otra cosa, entonces puede grabar una sin entrar en los detalles de su contenido, silenciar el sensor y para que el sistema no sospeche que algo está mal debido a la falta de paquetes desde el sensor: difunde el mensaje previamente grabado.

En LoRaWAN, se agrega un contador a cada paquete . Si un paquete llega al servidor de red con un contador igual o menor que el anterior, entonces este paquete simplemente se descarta. Con dos bytes por metro y una velocidad típica de transmisión de mensajes en el sistema IoT, durará mucho tiempo; por ejemplo, incluso una estación meteorológica doméstica que transmite la temperatura cada minuto la desbordará solo después de un mes y medio (LoRaWAN permite un contador de 4 bytes).

Sin embargo, existe un problema obvio: después de un desbordamiento, un paquete con el número 0 vendrá del dispositivo, que, obviamente, será menor que cualquier otro número, pero el servidor de red debería percibirlo correctamente y comenzar el conteo de paquetes nuevamente. Además, el dispositivo puede reiniciar el contador simplemente reiniciando.

Esto se logra de dos maneras:

• Antes de enviar dicho paquete, el dispositivo debe someterse al procedimiento de registro en la red (en la red LoRaWAN, este procedimiento se llama Join)
• el servidor permite la llegada del siguiente paquete con el número 0, mientras que la cuenta regresiva comienza de nuevo

Ambos esquemas se usan en LoRaWAN dependiendo de cómo se active el dispositivo: OTAA o ABP (hablaremos de ellos a continuación). La primera opción se usa para OTAA, mientras que el dispositivo también recibe nuevas claves de cifrado, por lo que incluso un atacante que haya pasado un mes y medio debajo de su estación meteorológica no podrá transmitir ningún paquete grabado previamente para que el sistema lo acepte.

Para ABP, en el que no hay un procedimiento de registro en la red, se utiliza la segunda opción; sin embargo, si el período de desbordamiento del contador excede significativamente la vida útil estimada del dispositivo y se puede desactivar. En el caso de un reinicio accidental después de enviar cada paquete, dicho dispositivo final almacena el valor del contador en la memoria no volátil.

El segundo esquema, por supuesto, es menos seguro, pero en la práctica es permisible: un atacante no debe registrar ningún paquete, sino específicamente cero. Si lo desea, puede hacer que su contenido sea diferente de todos los demás paquetes; por ejemplo, no transmita datos, sino información sobre el tipo y la configuración del dispositivo; entonces su intercepción y repetición no dará nada razonable.

Contador falsificado

Sin embargo, la pregunta surge de inmediato: ¿qué pasa si el contador es falso? Puede ponerlo en la parte encriptada del paquete, pero luego la cantidad real de datos del usuario disminuirá en dos bytes. No solo puede cifrar los datos del usuario, sino que, en primer lugar, debe adaptarse al tamaño de bloque de 16 bytes y, en segundo lugar, la carga en el servidor de red aumentará, lo que tendrá que descifrarlo primero para cualquier acción en el paquete (en el esquema, cuando solo se cifran los datos del usuario, si el paquete se ignora formalmente, entonces no es necesario descifrar nada).

Es obvio que no nos importa si el atacante conoce o no el número de paquete; en el esquema con el re-registro de la red (OTAA) este conocimiento no lo ayudará en absoluto, y en ABP esperará mucho tiempo junto al mar para conocer el clima, es decir. La próxima llegada del paquete con el número N-1.

Por lo tanto, es suficiente no permitirle cambiar este número.

Para hacer esto, todo el paquete en LoRaWAN está firmado con una firma criptográfica: AES-CMAC, esta firma en el estándar se llama MIC, Código de integridad de mensajes. Comprueba que el paquete completo , incluidos todos los encabezados y datos, ha llegado al servidor sin cambios.

Es decir, después de haber aceptado el siguiente paquete, podemos examinar rápidamente su contador (dirección del remitente, etc.), y si es nuestro y correcto, entonces ya verificamos la firma (gastando recursos adicionales), y si la firma también es correcta, descifre los datos y transmita ellos más lejos.

Seguimiento de datos que no cambian

Desafortunadamente para nosotros, no es suficiente para evitar que un atacante entienda los datos o al menos los repita; en algunos casos será suficiente para que entienda que no están cambiando. Un ejemplo de libro de texto son los medidores de agua en el hogar: si solo quiere saber si los propietarios están en casa, no le importa exactamente cuántos litros hay, es importante que sepa si este valor está aumentando .

Obviamente, el cifrado de datos es un procedimiento reversible (se pueden descifrar), lo que significa que los mismos datos cifrados con la misma clave siempre se ven iguales. Al recibir paquetes de un medidor de agua que no cambia las lecturas, puede, sin descifrar el paquete , comprender que no cambian.

Hacer frente a esto es bastante simple: los datos o la clave deben cambiar. Para cambiar los datos, puede agregarles sal, unos pocos bytes aleatorios que simplemente se descartan después del descifrado. Lamentablemente, 16 bytes de un paquete ya son escasos, por lo que, en el caso general, no queremos gastar de 2 a 4 bytes en basura real.

LoRaWAN usa un esquema más complicado . ¿Recuerdas que tenemos un contador de paquetes? Por lo tanto, este contador en particular más información sobre el dispositivo y el paquete (dirección corta del dispositivo en la red LoRaWAN, dirección de transferencia de datos, contador de 16 bytes) se encriptan usando el algoritmo AES, y el resultado XOR está con el paquete de datos del usuario.

Como resultado, los bytes de carga útil no se desperdician, y cada mensaje se ve diferente independientemente de si la carga ha cambiado o no.

PD Hay otra opción, un poco más simple: usar el contador de mensajes como los últimos N bytes de la clave. En este caso, la clave será nueva cada vez, pero porque Dado que el servidor conoce el valor del contador de mensajes (está en la parte no cifrada del mensaje), podrá restaurarlo. Menos: si su paquete consta de varios bloques de 16 bytes y tienen los mismos datos, después del cifrado seguirán siendo los mismos.

El atacante ha aprendido la clave de cifrado.

Es una situación muy real: IoT se caracteriza por el uso de una gran cantidad de dispositivos, sobre los cuales es posible que no tenga suficiente control confiable sobre el acceso a personas externas (y si también es un operador de red, entonces sus clientes son, por definición, externos).

Por lo tanto, si todos sus dispositivos tienen la misma clave de cifrado, el propietario de cualquiera de ellos puede escuchar el tráfico de cualquier otro dispositivo (en términos generales, si tiene la capacidad de modificar el firmware, entonces para tal operación puede que ni siquiera conozca la clave explícitamente). el nuevo firmware lo toma del mismo lugar que el anterior y solo nos da los datos de otras personas).

LoRaWAN implementa dos esquemas para usar claves, individuales para cada dispositivo:

• Activación por aire, OTAA: el servidor de red genera claves cada vez que se registra un dispositivo en él
• Activación por personalización: las claves las establece el fabricante y se almacenan en el dispositivo, sin cambiar nunca

Hay al menos dos claves en total: AppSKey, que cifra los datos del usuario, y NwkSKey, que firma el mensaje.

Obviamente, el esquema OTAA es más conveniente y confiable: las claves pueden cambiar con la frecuencia que desee, se garantiza que son únicas y que nadie las conoce, excepto el servidor de red. En ABP, las claves nunca cambian, la unicidad depende de la conciencia del fabricante del dispositivo (por ejemplo, generamos estas claves a partir de la ID única del microcontrolador, por lo que la probabilidad de su coincidencia en los dos dispositivos es insignificante), y deben almacenarse explícitamente en algún lugar, por lo que al conectar el dispositivo a la red registrarlos en el servidor.

Sin embargo, el procedimiento para obtener claves en OTAA es una historia separada que, si se implementa de manera incorrecta, puede dar lugar a varios tipos más de ataques.

Intercepción de claves generadas.

Obviamente, si se generan nuevas claves cada vez durante el registro en la red, entonces deben sincronizarse entre el dispositivo y el servidor, lo que significa que un atacante puede interceptarlas, rompiendo así toda la protección.

Por lo tanto , los dispositivos LoRaWAN tienen una tercera clave : AppKey, bien conectada al dispositivo y utilizada en un solo momento: al registrarse en la red. Con él, se firma un intercambio de claves de sesión entre el dispositivo y el servidor.

Idealmente, la AppKey debería ser única para cada dispositivo, pero en muchos casos se permite el uso de la misma AppKey, ya que se necesita solo una vez, esto puede reconocerse como válido.

AppKey antes de conectar el dispositivo se ingresa en su configuración en el servidor de red.

Entonces, el dispositivo genera una solicitud de registro (JoinRequest), no la encripta (no tiene información confidencial), sino que la firma con la clave AppKey. El servidor de red, después de recibir este paquete y verificar la dirección del remitente (si este es nuestro dispositivo) y luego la firma, responde con el paquete JoinAccept, en el que transfiere la configuración de red, bueno, en realidad confirma el registro.

¿De dónde vienen las teclas AppSKey y NwkSKey?

Este es el resultado del cifrado AES-128 con la clave AppKey de una combinación del número aleatorio AppNonce, número de clave (1 o 2), ID de red y otro número aleatorio DevNonce enviado por el servidor en la respuesta:

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

Dado que tanto el dispositivo como el servidor después de intercambiar paquetes de registro conocen todos estos parámetros, generarán las mismas claves. Por lo tanto, en ningún momento las claves se transmitirán por radio por sí mismas, pero al mismo tiempo, el dispositivo y el servidor recibirán claves únicas de cifrado y firma de paquetes.

Intercepción de un flujo de datos en sí mismo

¡Pero eso no es todo!

Sí, el evento de registro en la red suele ser algo poco frecuente, pero imagine que un atacante pudo iniciarlo e interceptarlo.

Luego, si simplemente envía el paquete JoinRequest que grabó, sin cambiar nada en él, el servidor responderá con el paquete JoinAccept, generando nuevas claves. Después de esto, el dispositivo atacado simplemente deja de comunicarse con el servidor, porque no inició JoinRequest y no ve ninguna razón para actualizar las claves. Es decir, se repite el mismo ataque, pero ya en el procedimiento de registro en la red.

Un atacante no podrá falsificar los datos, porque para esto necesita conocer las claves, y para obtenerlas necesita conocer la AppKey, que él no conoce. Pero para sacar el dispositivo de la red, puede hacerlo.

Para evitar esto, durante el registro, el dispositivo envía un número aleatorio de DevNonce al servidor (mira, está en los paquetes anteriores). Además del hecho de que las claves se generan sobre la base, tiene otro propósito: el servidor LoRaWAN almacena el archivo DevNonce . Si el dispositivo recibe una solicitud de registro repetida con el DevNonce ya utilizado, el servidor simplemente lo ignorará.

A su vez, el dispositivo está obligado a generar un nuevo DevNonce en cada registro (es decir, el circuito con la retransmisión de paquetes convencionales - "no recibió una respuesta, escupió el mismo paquete en la radio por segunda vez" - no funciona aquí, JoinRequest se vuelve a crear cada vez).

Conclusión

Aunque resultó que había mucho texto y pocas imágenes, incluso este no es un esquema completo de posibles ataques solo en la radio (las preguntas sobre por qué, por ejemplo, la configuración debe estar encriptada en el dispositivo, y dejamos la clave con una clave individual para cada dispositivo fuera de los corchetes, esto ya no se trata de la radio). Por ejemplo, en LoRaWAN 1.1, los esquemas de protección se han vuelto aún más complicados.

Sin embargo, este es un conjunto de caballeros de cualquier protocolo de radio que afirma tener una protección mínima de información digna y al mismo tiempo está diseñado para funcionar en dispositivos de baja potencia en redes de baja velocidad. Además, este es un muy buen ejemplo de implementación no solo de un protocolo seguro, sino de un protocolo escrito para dispositivos de baja potencia y minimizando el consumo de tiempo de uso y potencia de computación siempre que sea posible sin daños significativos a la seguridad.

Y si está diseñando su propio protocolo para IoT, entonces el bien especificado LoRaWAN, combinado con una comprensión de los métodos básicos para realizar ataques, brinda una excelente oportunidad para aprender cómo organizar adecuadamente esta protección.