Hola queridos amantes de Internet de las cosas. Continuación de notas del proveedor de IoT.
La primera parte > || >
Segunda parte > || >
Tercera parte > || >
La cuarta parteHoy es hora de hablar sobre seguridad en LoRaWAN. Hay muchos rumores y leyendas. Intentaremos averiguar cómo funciona y cuáles son los riesgos.
Para continuar con el tema de la seguridad, tendrá que hacer una pequeña introducción y hablar sobre la inicialización inicial del módulo de radio en la red. Este proceso en LoRaWAN se llama activación.
Por brevedad, enumeraré a continuación los términos que necesitamos. Si te confundes un poco, puedes volver aquí y comprobar. Probablemente tengas que volver, porque Las abreviaturas de muchos términos son muy similares. Además, en esta descripción le daré analogías para que comprenda aproximadamente con qué se puede comparar este o aquel término. No siempre es posible seleccionar analogías exactas, por lo tanto, no juzgue esta columna demasiado estrictamente.
Por lo tanto, la activación en LoRaWAN se puede hacer por aire (OTAA) o por preajuste (ABP).
OTAA (Activación por aire)
En el caso de activación por aire, se deben establecer tres parámetros en nuestro módulo de radio. Su identificador único (DevEUI), el identificador del servidor (AppEUI) y la clave del servidor (AppKey).
En el lado del servidor, el identificador del módulo de radio, el identificador del servidor y la clave también deben estar registrados. Es decir el servidor debe conocer inicialmente el dispositivo que intentará unirse a él. Si conocemos los identificadores y las claves del servidor, pero nuestro DevEUI no está registrado en su base de datos, la conexión fallará.
Tras el encendido inicial, la radio envía el paquete join_request al aire en una de las tres frecuencias de unión predefinidas. Con este paquete, pregunta si hay una red cercana que lo "reconozca". La siguiente es la composición del paquete join_request. Como puede ver, contiene DevEUI y AppEUI, así como DevNonce.
DevNonce es una variable aleatoria. El servidor lo almacena en la memoria durante algún tiempo y si join_request llega con el mismo DevNonce que uno de los anteriores, el servidor ignorará esta solicitud. Esto es para protegerse contra un ataque repetido cuando un atacante puede escribir una solicitud de activación y luego repetirla desde su dispositivo. Por cierto, no todos los estándares de IoT pueden presumir de protección contra este ataque.
AppKey no se usa directamente en este mensaje, pero a través de él se considera la suma de verificación MIC al final del marco.
Necesitaremos esta clave un poco más, en el mensaje de respuesta del servidor join_accept.
Join_request se transmite sin cifrar.
Join_accept se recibirá si el servidor conoce AppEUI y DevEUI, así como si no hay coincidencia en el campo DevNonce y no hay problemas con el MIC. De lo contrario, no habrá respuesta. Si se pasan todas las comprobaciones, el servidor genera un mensaje de respuesta join_accept. Su composición se muestra en la imagen a continuación.
De hecho, se generan dos claves de sesión: el servidor de red (NwkSKey) y el servidor de aplicaciones (AppSKey). Estas claves junto con otra información son encriptadas por AppKey y enviadas al módulo de radio. Además, todos los mensajes se producen con doble cifrado con claves de sesión (con la excepción de los paquetes con comandos MAC, no se cifran con la clave del servidor de la aplicación). NwkSKey no participa en el cifrado de paquetes solo con datos (sin comandos), sino que se considera una suma de verificación a través de él.
NwkSkey y AppSKey son exclusivos de cada módulo de radio individual.
Se utilizan dos claves para la protección de información adicional. Cada vez que llega un paquete del módulo de radio a nuestro sistema, se encriptará parcialmente para el servidor de red y parcialmente para el servidor de aplicaciones. Es decir el servidor de red solo podrá descifrar los mensajes que se dirigen a él (varios mensajes de servicio). El servidor de aplicaciones solo verá el componente útil de los paquetes (en realidad, los datos que se reenvían). Esto es necesario porque el servidor de red con una probabilidad del 99 por ciento estará en el proveedor. Pero el servidor de aplicaciones bien puede ser alojado por el cliente. El doble cifrado dificulta que el proveedor descubra el contenido del paquete.
Además de las dos claves, hay otra cosa importante para unir_aceptar en OTAA: la lista de frecuencias extendida (CFList). Permítame recordarle que inicialmente un módulo de radio solo conoce tres frecuencias en las que puede operar. Después de la activación, se registran frecuencias adicionales para que se comunique.
Esto es muy conveniente si no se sabe exactamente en qué red funcionará el dispositivo. Podemos acordar que en todas las redes 3 frecuencias (+ RX2) siempre coincidirán, y las cinco restantes quedan a criterio del proveedor.
Además, para el futuro, para trabajar con una gran cantidad de dispositivos, CFList se puede utilizar para la agrupación
Esto es cuando divide la red en grupos y dentro de los grupos hay una planificación de frecuencia. Digamos que nuestro módulo de radio conoce las tres frecuencias F1, F2 y F3. Se activa en una de las frecuencias y, si está en el clúster1, recibe una tabla de frecuencias adicional en forma de F4-1, F5-1 y F6-1. Para el grupo 2, obtendrá completamente diferente F4-2, F5-2, F6-2. Al mismo tiempo, podemos configurar todos los módulos de radio de la misma manera y realmente no pensamos cuál caerá en qué clúster. Y en los grupos vecinos, la probabilidad de colisiones disminuirá considerablemente.
ABP (activación por personalización)
Un procedimiento simplificado cuando las claves de sesión se conectan inmediatamente al módulo de radio y se registran inicialmente en el lado del servidor. Conveniente porque no necesita activar, el módulo de radio está listo para usar de inmediato. Nada más conveniente, porque La seguridad en este caso es regular. Además, no puede extraer frecuencias del servidor. Nunca he visto ningún caso de uso real. No lo consideraremos, y todo lo siguiente es sobre OTAA.
¿Y qué hay de la seguridad?
Entonces, en esencia, tenemos la carga principal de cifrado en las claves de sesión del servidor de red y el servidor de aplicaciones.
Considérelos un poco más cuidadosamente.
La principal queja de los críticos del estándar LoRaWAN es que cuando el dispositivo se activa en la red, tenemos dos claves, que luego pueden permanecer sin cambios durante meses. Más precisamente, no pueden cambiar durante años hasta que el dispositivo se vuelva a activar. En condiciones normales, activamos y olvidamos el módulo de radio, por lo que una vida clave de tres a cuatro años es una perspectiva muy realista. En realidad, desde la instalación hasta dejar la batería en cero.
¿Qué tan confiables son nuestras llaves?
La especificación dice que cumplen con el misterioso RFC4493.
Que es esto Este es un algoritmo de cifrado, mejor conocido como AES-CMAC.
No nos metamos en la naturaleza de la criptografía y limitemos a una comprensión común de la imagen. Se presenta en la figura a continuación.
El principio de AES-CMAC es aproximadamente el siguiente: el mensaje cifrado se divide en bloques de 128 bits. Cada bloque se cifra por separado con una clave AES. Además, cuando se cifra el segundo bloque, además de la clave, se utiliza el resultado de cifrado del primero. Y al cifrar el tercero, el resultado del segundo y (indirectamente) el primero. Tal cadena de complicaciones.
¿Qué tan confiable es este principio?
Muy confiable El algoritmo salió hace más de diez años. Desde entonces, ha sido atacado por muchos ataques diferentes y finalmente, en teoría, demostraron que puede ser pirateado. El problema es que se necesitará una gran muestra de paquetes, varios miles, para romperlo. Entonces existe la posibilidad de comprender qué hay dentro de los bloques cifrados.
¿Puede un atacante con el conocimiento necesario obtener esta muestra si estamos hablando de interceptar paquetes LoRaWAN? Vamos a estimar Deje ir los paquetes una vez por hora. En un mes, se enviarán 720 paquetes desde el módulo de radio. No es suficiente
Para una amenaza real, necesitamos un paciente muy paciente que estará escribiendo paquetes durante meses. Y no es un hecho que todavía pueda descifrar el algoritmo y obtener las claves atesoradas. No olvide que será necesario mostrar tanta paciencia con respecto a cada módulo de radio por separado. Y recuerde que enviar paquetes una vez por hora es MUY frecuente. En la práctica, los intervalos son mucho más largos: seis horas o incluso un día.
Pero incluso esta oportunidad fantasmal ahora se cierra después del lanzamiento de la especificación 1.1, donde se implementan los comandos de reactivación y unión al servidor. Hablemos de esta especificación de alguna manera. Por ahora, recuerdo mi pensamiento del artículo anterior: cuando el estándar está abierto y tiene una comunidad, todos sus agujeros son visibles. Durante la actualización, los desarrolladores saben exactamente qué mirar primero.
Como resultado, entendemos que la amenaza de seguridad es bastante ilusoria. En algún lugar de la teoría profunda, el pirateo se puede hacer, pero en la práctica prácticamente no es realista. Ahora multiplique por el valor de la información recibida. ¿Comenzará nuestro atacante a escribir paquetes durante meses para descubrir el contador? Poco probable
LoRaWAN cumple con esa razonable relación precio-rendimiento. Entendemos que la protección se puede mejorar. Pero esta es la potencia informática del final, esta es una carga adicional en la batería, es posible aumentar el tamaño de los paquetes o reducir la carga útil.
Para mí, es más que una tarea de telemetría.
En los comentarios, me alegrará escuchar tanto a mis oponentes como a mis seguidores. Recuerde que el tema de la seguridad siempre requiere discusión y nunca debe descansar en la opinión de una persona.