¿Seguridad modular para un UAV de fotografía?

Cuando el módulo principal solo se comunica con el módulo de radio a través del módulo de seguridad, el módulo de seguridad podría hacer toda la comunicación con el servidor base firmada y encriptada sin que el módulo principal se dé cuenta.

Pero la comunicación entre el servidor base y el UAV no es el único vector de ataque en el que se podría pensar.

Los UAV a menudo están equipados con diferentes tipos de sensores. Cuando tiene una vulnerabilidad al interpretar los datos de ese sensor en el módulo principal, eso podría explotarse (por ejemplo, desencadenar un desbordamiento de enteros al interpretar el nivel de brillo de un sensor fotográfico apuntándolo con un láser). Y puede olvidarse de filtrar también los datos del sensor a través del módulo de seguridad, porque el módulo de seguridad no puede saber qué tipo de entrada de sensor activará un error en el módulo principal.

El mismo vector de ataque se aplica cuando hay datos maliciosos que se originan en el propio servidor base. Cuando el servidor base no es confiable, el módulo de seguridad no podrá hacer nada al respecto porque no sabe qué actividad maliciosa buscar. Este vector de ataque también podría manifestarse cuando el servidor base recibe información de alguna fuente externa y la transmite al UAV sin filtrar.

Además, no protegería contra el acceso físico. Un atacante con acceso físico podría colocar un tercer chip entre el módulo principal y el módulo de encriptación para MITM, la comunicación no encriptada entre estos dos chips (suponiendo que estamos hablando de dos módulos que están separados físicamente y no solo lógicamente separados del mismo chip) )

  

ataques remotos o ataques físicos a un único UAV que puede dar control sobre una flota de UAV similares

Si ese es su único objetivo, entonces la arquitectura de seguridad del propio UAV es irrelevante. Todo lo que necesita es evitar los secretos de clase, es decir, no tener nada que ambos quieran mantener en secreto e incluir en cada dispositivo. Cualquier buena arquitectura de seguridad evita los secretos de clase. Esto significa que no confíe en la seguridad por oscuridad y, para cualquier criptografía, use diferentes claves en cada dispositivo. Cada UAV genera sus propias claves secretas para uso interno, y tiene sus propias claves privadas para comunicarse con el exterior.

Sin embargo, si está preocupado por los ataques, entonces los UAV tienen activos (y probablemente son activos en sí mismos). Por eso, la arquitectura de seguridad del dispositivo obviamente importa.

Contra los ataques de software realizados desde el exterior, tiene sentido un módulo de seguridad dedicado. Haga que medie en todas las comunicaciones y sea el repositorio de claves criptográficas que se utilizan para la comunicación. También hágalo responsable de garantizar la integridad y realizar actualizaciones de software en otros componentes, tal vez almacene el firmware para todos los demás componentes.

Sin embargo, todavía deberá asegurarse de que los componentes individuales estén libres de errores. El módulo dedicado actúa como un cortafuegos contra solicitudes maliciosas desde el exterior, pero si los otros módulos se comportan mal con comandos válidos, el juego se pierde. Si un error en un servocontrol provoca que el UAV se caiga en lugar de subir y se bloquea, el módulo de seguridad no puede ayudar con eso.

Debe pensar en la base de confianza de su dispositivo . ¿Qué partes del dispositivo son críticas para su correcto funcionamiento? Como explica Philipp , la respuesta es lotes . Se necesitan muchos sensores, motores, etc. para que el UAV funcione correctamente (comenzando con: no se estrella). Si el módulo del controlador obtiene datos incorrectos, o si los motores no giran a la velocidad solicitada por el controlador, el dispositivo se comportará mal; por lo tanto, todos los sensores y motores son parte de la base confiable.

Lo mejor que puedes esperar es una arquitectura donde la mayoría de los componentes solo puedan afectarse a sí mismos, por ejemplo. un sensor de mal comportamiento no puede modificar las lecturas de otro sensor o impedir que el otro sensor informe. Este ejemplo requiere un aislamiento adecuado en los buses de datos y una autenticación adecuada de cada sensor en su controlador.

Contra los ataques de hardware, este modelo se descompone aún más. Si alguien tiene acceso físico al dispositivo, tendrá acceso bastante fácil a muchos buses de datos. Lo que informa el sensor no es necesariamente lo que recibe el controlador: podría tratarse de datos inyectados por el atacante. Para evitar esto, debe llevar la criptografía a todos los sensores. Esto eleva el nivel de un atacante, pero no es una panacea. Un atacante con acceso físico siempre puede perturbar las lecturas del sensor, haciendo que el sensor realice informes precisos de información inútil, por ejemplo. ocultando una cámara, sosteniendo una fuente de calor cerca de un termómetro, etc.