Seguridad en redes LoraWAN (Parte II)

En el anterior artículo sobre la seguridad en LoraWAN (Parte I) vimos las medidas que implementa LoraWAN para ofrecer seguridad, pero ahora en este artículo veremos lo que sucede si el implentador que despliega los nodos no tiene en consideración la seguridad desde el diseño (security by design).

Ataques a la infraestructura física:

En la mayoría de las ocasiones, los dispositovos (nodos) suelen desplegarse en exterior, y en muchas de las veces en ubicaciones donde están al alcance de cualquier. Pues bien, esto supone también un riesgo:

  • Un atacante p0dría acceder al nodo para desconectarlo, para desplazarlo de su ubicación inicial, o incluso llegar a influenciar sobre el sensor haciendo que este muestre valores “no reales” que puedan tener impilcaciones.
  • Un atacante podría robar el dispositivo y realizar un ataque físico sobre el. Disponiendo del dispositivo, de tiempo y de las herramietnas adecuadas un posible atacante podría tratar de leer las claves de comunicación de dicho dispositivo mediante los interface de debugging del dispositivo. También podría ocurrir, que si las “keys” no están almacenadas en un lugar seguro se puedan leer desde algún medio de almacenamiento.

Algunos expertos aseguran que se tardaría 16 minutos extraer una clave AES128 de una MCU que no fuese segura. Lo cual, si no se han seguido las buenas prácticas no sólo podría poner en peligro la seguridad del dispositivo sino del resto de dispositivo en caso de que se compartiese la misma key.

Obtención de información a partir de los metadatos:

Se puede caracterizar un dispositivo tan sólo estudiando las comunicaciones que realiza. En muchos casos, estas comunicaciones son periódicas, y predecibles. Aunque no supone un riesgo extremandamente alto, hay que destacar:

  • Un posible atacante podría regitrar la actividad de un dispositivo a través del interface aire (obteniendo información de su comportamiento)
  • Cualquier persona podría desplegar un gateway y escuchar el tráfico aire-aire y capturar información como: DeviceID, Frame Counter, incluso se podría llegar a averiguar el tamaño del payload.

Si tuviésemos un dispositivo que sólo manda mensajes cuando se produce un evento, podríamos caracterizar los mensajes y saber cuándo se ha producido ese evento que dispara la comunicación del dispositivo. Dentro de las buenas prácticas recomendadas, se encuentra la de mandar mensajes de forma aleatoria para evitar que un posible atacante pudiese caracterizar el tráfico de nuestro dispositivo.

Construcción de Gateways maliciosos:

Actualmente en redes como TTN los gateways no requiren autenticación. Por esta razón un atacante podría suplantar la identidad de un gateway existente y actuar en su nombre, permitiendo la recogida de los mensajes. Por otro lado un gateway malicioso, podría enviar mensajes de confirmación de recepción cuando realmente el mensaje no ha llegado a su destino.

Estos problemas quedarían solucionados en la versión 1.1 del protocolo.

Decodificando la capa PHY:

En el 33C3 Matt Knight nos hizo una demostración de cómo decodificar la capa PHY de LoRa usando un receptor de radio SDR y el software gr-lora.

Y hasta aquí un breve repaso sobre la seguridad en LoRaWAN

Anuncios
Tagged with: , , , ,
Publicado en Blog, Spanish (ES)
Twitter
A %d blogueros les gusta esto: