Análisis y desarrollo de medidas de seguridad avanzadas para la protección de comunicaciones en vehículos aéreos no tripulados

ESCUELA T´ ECNICA SUPERIOR DE INGENIER´ IA INFORM´ ATICA Trabajo fin de Grado Grado en Ingenier´ıa Inform´atica – Tecnolog´ıas Inform´aticas An´alisis y Desarrollo de Medidas de Seguridad Avanzadas para la Protecci´on de Comunicaciones en Veh´ıculos A´ereos no Tripulados Realizado por: Alejandro Pariente Migoya Dirigido por: Juli´an Viejo Cort´es Mouhsine Kassimi Farhaoui Departamento de Tecnolog´ıa Electr´onica Sevilla, Julio de 2024 - Segunda convocatoria I Resumen En este trabajo de fin de grado se lleva a cabo un an´alisis de los principales protocolos de comunicaci´on para veh´ıculos a´ereos no tripulados (del ingl´es Unmanned Aerial Vehicle o UAV) y sus comunes vulnerabilidades de red. Se presenta una soluci´on experimental que implementa un cifrado de extremo a extremo en la comunicaci´on entre un UAV basado en ArduPilot y la estaci´on de control en tierra QGroundControl, utilizando el algoritmo de cifrado ChaCha20. Mediante modificaciones en los protocolos MAVLink y en los sistemas de software involucrados en la comunicaci´on, se ha logrado un flujo de comunicaci´on seguro sin comprometer significativamente el rendimiento del sistema. Esta soluci´on garantiza la protecci´on de datos sensibles durante las misiones de vuelo, asegurando que solo los operadores con la clave privada necesaria puedan descifrar la informaci´on transmitida. As´ı, se contribuye a la seguridad y fiabilidad de las operaciones con UAV en contextos donde se maneja cada vez m´as informaci´on sensible. Finalmente, se han realizado pruebas exhaustivas que verifican el correcto funcionamiento del sistema. Abstract The unmanned aerial vehicle (UAV) industry’s influence is increasing so rapidly over time, as is the responsibility they carry as a payload during a given flight mission. As technology evolves, UAVs are equipped with more complex and expensive sensors that can capture huge amounts of sensitive data in just a few minutes. Hence, in some scenarios, ensuring the confidentiality and integrity of communications is becoming critical factor. To achieve this, this study proposes an experimental solution that shows how the entire communication stream between an ArduPilot-based UAV and the QGroundControl ground control station can be provided with end-to-end encryption capabilities without substantially affecting performance thanks to the ChaCha20 encryption algorithm. Agradecimientos A mi padre, madre y hermana que siempre me han apoyado sin dudarlo y me han visto crecer durante este largo camino. A mi familia m´as cercana y mis mejores amigos, en especial a Carlos y ´ Angel por hacer de estos a˜nos en Sevilla unos tan agradables. Y, por supuesto, a mi II abuela Paqui que me ha visto crecer y siempre ha estado presente en todo este tiempo en el que he aprendido mucho sobre ingenier´ıa inform´atica pero, sobre todo, a ser mejor persona. Muchas gracias. III Tabla de contenidos 1. Introducci´on 1 1.1. Motivaci´on ...................................... 2 1.2. Estructura del documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definici´on de objetivos 4 3. Aportaci´on realizada 4 4. Planificaci´on 5 4.1. Planificaci´on temporal y costes de desarrollo . . . . . . . . . . . . . . . . . . . . 5 4.1.1. Descripci´on de tareas y roles . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1.2. Cronograma.................................. 6 4.1.3. Estimaci´ondecostes............................. 6 4.2. Planderiesgos .................................... 7 4.2.1. Identificaci´on de riesgos . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2.2. C´omo actuar en consecuencia . . . . . . . . . . . . . . . . . . . . . . . . 7 4.3. Plandepruebas.................................... 8 4.4. Plandemejoras.................................... 8 4.5. Plandecomunicaci´on ................................ 9 5. Estado del arte 9 5.1. Principales protocolos de comunicaci´on . . . . . . . . . . . . . . . . . . . . . . . 10 5.1.1. MAVLink (Micro Air Vehicle Link) . . . . . . . . . . . . . . . . . . . . . 10 5.1.2. UAVCAN (DroneCAN y OpenCyphal) . . . . . . . . . . . . . . . . . . . 12 5.1.3. DDS (Data Distribution Service) . . . . . . . . . . . . . . . . . . . . . . 14 5.1.4. ROS (Robot Operating System) . . . . . . . . . . . . . . . . . . . . . . 16 5.2. Descripci´on de vulnerabilidades y ataques de red comunes a los UAVs . . . . . 17 5.2.1. Diferentes tipos de ataques de red . . . . . . . . . . . . . . . . . . . . . 18 5.3. Estudios relacionados y antecedentes . . . . . . . . . . . . . . . . . . . . . . . . 20 5.3.1. UAVCAN................................... 21 5.3.2. DDS (Data Distribution Service) . . . . . . . . . . . . . . . . . . . . . . 21 5.3.3. ROS (Robot Operating System) . . . . . . . . . . . . . . . . . . . . . . 23 IV 5.3.4. MAVLink (Micro Air Vehicle Link) . . . . . . . . . . . . . . . . . . . . . 24 5.4. Algoritmo de cifrado ChaCha20 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 5.4.1. Quarter Round (Cuarto de Ronda) . . . . . . . . . . . . . . . . . . . . . 27 5.4.2. Block Function (Funci´on de Bloque) . . . . . . . . . . . . . . . . . . . . 29 5.4.3. Operaci´onXOR ............................... 29 6. An´alisis de requisitos 30 6.1. Actoresinvolucrados................................. 30 6.2. Requisitos funcionales y no funcionales . . . . . . . . . . . . . . . . . . . . . . . 31 7. Esquema de trabajo 32 8. Dise˜no 33 8.1. Metodolog´ıa...................................... 33 8.2. Decisiones sobre componentes hardware, software y herramientas involucradas . 34 8.2.1. Protocolo de comunicaci´on . . . . . . . . . . . . . . . . . . . . . . . . . 34 8.2.2. Algoritmo de cifrado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 8.2.3. Firmware para el autopiloto . . . . . . . . . . . . . . . . . . . . . . . . . 35 8.2.4. Hardware autopiloto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 8.2.5. Software de control en tierra (GCS) . . . . . . . . . . . . . . . . . . . . 37 8.2.6. Ordenador de abordo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 8.2.7. Lenguaje de programaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . 38 8.2.8. Herramienta de an´alisis de tr´afico de red . . . . . . . . . . . . . . . . . . 39 8.3. Configuraci´on inicial del sistema (punto de partida) . . . . . . . . . . . . . . . 39 8.3.1. Compilar y ejecutar QGroundControl desde su repositorio fuente . . . . 39 8.3.2. Compilar el firmware ArduPilot desde su repositorio fuente . . . . . . . 40 8.3.3. Subir el firmware ArduPilot a CubePilot CubeOrange a trav´es de QGround- Control .................................... 42 8.3.4. Comunicaci´on inicial entre CubePilot CubeOrange y QGroundControl . 43 8.3.5. Definir diferentes modelos de comunicaci´on con fines de realizaci´on de pruebas .................................... 43 9. Implementaci´on 46 9.1. Desarrollo del algoritmo de cifrado ChaCha20 . . . . . . . . . . . . . . . . . . . 47 V 9.1.1. Funciones principales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 9.1.2. Funciones secundarias . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 9.1.3. Ejemplo sobre el proceso completo de cifrado/descifrado con el algoritmo ChaCha20 desarrollado . . . . . . . . . . . . . . . . . . . . . . . . . 54 9.2. Integrar el algoritmo ChaCha20 en la librer´ıa MAVLink . . . . . . . . . . . . . 56 9.2.1. Generador de la librer´ıa de c´odigo MAVLink . . . . . . . . . . . . . . . 56 9.2.2. Incluir chacha20.h donde se genera la librer´ıa MAVLink . . . . . . . . . 57 9.2.3. Integrar el cifrado y descifrado en la librer´ıa MAVLink . . . . . . . . . . 59 9.2.4. Reemplazar los m´odulos MAVLink de ArduPilot y QGroundControl por elMAVLinkmodificado ........................... 63 10.Pruebas y resultados 65 10.1. Validaci´on de la comunicaci´on entre el autopiloto y la GCS tras la securizaci´on delprotocolo ..................................... 65 10.2. Pruebas de sniffing de la comunicaci´on utilizando Wireshark . . . . . . . . . . . 68 10.2.1. Sniffing de comunicaci´on MAVLink sin cifrar . . . . . . . . . . . . . . . 68 10.2.2. Sniffing de comunicaci´on MAVLink cifrada de extremo a extremo . . . . 70 10.3. Impacto en el rendimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 10.3.1. Medir impacto en el rendimiento usando perf . . . . . . . . . . . . . . . 73 11.Conclusiones 75 12.Desarrollos futuros 76 VI ´ Indice de figuras 1. Diagrama de Gantt de la planificaci´on inicial del proyecto . . . . . . . . . . . . 6 2. Evoluci´on de los operadores de drones registrados en AESA[2] . . . . . . . . . . 10 3. Desglose de un paquete MAVLink v2.0 . . . . . . . . . . . . . . . . . . . . . . . 11 4. L´ınea temporal de protocolos de comunicaci´on . . . . . . . . . . . . . . . . . . 13 5. Arquitectura de UAVCAN en cuanto a sus tipos de estructuras de datos . . . . 14 6. Interoperabilidad de DDS entre diferentes especificaciones de diferentes proveedores[11] ................... 15 7. Servicio de publicaci´on y suscripci´on en DDS . . . . . . . . . . . . . . . . . . . 16 8. Arquitectura general para la seguridad de DDS[14] . . . . . . . . . . . . . . . . 22 9. Comparaci´on de uso de la CPU (MAVLink sin cifrado vs. diferentes algoritmos criptogr´aficos)..................................... 25 10. Operaci´on Quarter Round propia del algoritmo ChaCha . . . . . . . . . . . . . 28 11. Proceso de cifrado y descifrado de ChaCha20 . . . . . . . . . . . . . . . . . . . 30 12. FirmwarePX4autopilot............................... 35 13. FirmwareArdupilot ................................. 35 14. Autopiloto CubePilot CubeOrange . . . . . . . . . . . . . . . . . . . . . . . . . 36 15. Estaci´on de control en tierra APM Planner . . . . . . . . . . . . . . . . . . . . 37 16. Estaci´on de control en tierra QGroundControl . . . . . . . . . . . . . . . . . . . 38 17. Salida esperada en la terminal al finalizar compilaci´on de QGroundControl . . 40 18. Salida esperada en la terminal al finalizar compilaci´on de ArduPilot . . . . . . 41 19. Cargar el firmware ArduPilot a trav´es de QGroundControl . . . . . . . . . . . 42 20. Mensajes mostrados en MAVLink Inspector . . . . . . . . . . . . . . . . . . . . 43 21. Conexi´on directa v´ıa USB entre el autopiloto y la GCS . . . . . . . . . . . . . . 44 22. Autopiloto conectado directamente a la Raspberry Pi y comunicaci´on reenviada alaGCSv´ıaMAVProxy............................... 45 23. Conexi´on como en Modelo B pero con atacante interceptando la comunicaci´on 46 24. Ejemplo aislado de cifrado y descifrado usando ChaCha20 . . . . . . . . . . . . 55 25. Resultado mostrado en la terminal del ejemplo de cifrado y descifrado usando ChaCha20....................................... 56 26. Proceso de generado de la librer´ıa MAVLink . . . . . . . . . . . . . . . . . . . . 59 27. Proceso de cifrado de un mensaje MAVLink . . . . . . . . . . . . . . . . . . . . 61 VII 28. Proceso de descifrado durante el desglose de un mensaje MAVLink . . . . . . . 63 29. Comunicaci´on estable entre el autopiloto y la GCS tras las modificaciones de securizaci´on usando el modelo de red A . . . . . . . . . . . . . . . . . . . . . . 66 30. Recepci´on de mensajes MAVLink del autopiloto por parte de la GCS . . . . . . 67 31. Comunicaci´on securizada entre el Dron y la GCS . . . . . . . . . . . . . . . . . 68 32. Sniffing de comunicaci´on MAVLink no cifrada utilizando Wireshark . . . . . . . 70 33. Sniffing de comunicaci´on MAVLink cifrada usando Wireshark . . . . . . . . . . 71 34. Desglose del mensaje cifrado con ChaCha20 interceptado con Wireshark . . . . 72 35. C´odigo sobre el que medir el impacto en CPU de la implementaci´on . . . . . . 73 36. Impacto en la velocidad de ejecuci´on de una operaci´on de empaquetado / desempaquetado usando MAVLink por defecto y MAVLink con ChaCha20 . . . . 74 VIII ´ Indice de tablas 1. Planificaci´ontemporal................................ 5 2. Estimaci´ondecostes................................. 6 3. Estimaci´on de costes de material . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Campos en el desglose del paquete MAVLink v2.0 . . . . . . . . . . . . . . . . 11 5. An´alisis de avances en securizaci´on previos basados en UAVCAN . . . . . . . . 21 6. An´alisis de avances en securizaci´on previos basados en DDS . . . . . . . . . . . 23 7. An´alisis de avances en securizaci´on previos basados en ROS . . . . . . . . . . . 24 8. An´alisis de avances en securizaci´on previos basados en MAVLink . . . . . . . . 26 9. Matriz de estado inicial del algoritmo ChaCha . . . . . . . . . . . . . . . . . . 27 10. Matriz SM ejemplo.................................. 28 11. Matriz SM ejemplo transformaci´on de columna . . . . . . . . . . . . . . . . . . 28 12. Matriz SM ejemplo transformaci´on diagonal . . . . . . . . . . . . . . . . . . . . 29 13. An´alisis de tiempo de ejecuci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 IX este trabajo. Estos se muestran en la Tabla 3. Equipo Unidades Coste (€) CubePilot CubeOrange 1 Uds. 495 € Dell Latitude 1 Uds. 650 € Dell Precision 1 Uds. 1.600 € Raspberry Pi 3B 1 Uds. 80 € Cable ethernet CAT 6a 1 Uds. 10 € Total (€) 2.835 € Tabla 3: Estimaci´on de costes de material Finalmente, y teniendo en cuenta las dos tablas anteriores, se estima un presupuesto de 5.555 €totales para este proyecto. 4.2. Plan de riesgos En esta secci´on se pretende identificar, evaluar y gestionar los posibles riesgos que podr´ıan afectar negativamente al desarrollo y los resultados de este proyecto. Se busca establecer estrategias de mitigaci´on para garantizar la viabilidad y el ´exito del trabajo. En este sentido, el plan de riesgos no solo vela contra potenciales contratiempos, sino que hace posible una planificaci´on m´as robusta. 4.2.1. Identificaci´on de riesgos Estos son los riesgos a tener en cuenta seg´un la naturaleza de este proyecto: 1. Falta de documentaci´on en l´ınea. 2. Fallos en el funcionamiento de alg´un componente hardware cr´ıtico en el desarrollo. 3. Problemas de escalabilidad de alguno de los softwares (software GCS o firmware del autopiloto). 4. Problemas inesperados durante la implementaci´on. 4.2.2. C´omo actuar en consecuencia De ser necesario enfrentar alguno de los riesgos previamente listados, se proceder´a del siguiente modo: 7 1. Si surge falta de documentaci´on en l´ınea: a) Recurrir al tutor o al cotutor en pos de m´as informaci´on o recomendaciones sobre fuentes de documentaci´on. 2. Si alg´un componente hardware cr´ıtico en el desarrollo falla: a) Pedir ayuda al soporte t´ecnico del equipo correspondiente. b) Valorar la posibilidad de adquirir uno nuevo. c) Adaptar el desarrollo a este cambio. 3. Si se detectan problemas de escalabilidad en alguno de los softwares o firmwares: a) Valorar la posibilidad de usar una herramienta software o firmware alternativa. 4. Ante problemas inesperados durante la implementaci´on: a) Analizar la situaci´on con detenimiento. b) Exponer ventajas y desventajas de invertir demasiado tiempo en resolver el problema a toda costa. c) Como ´ultima alternativa, hablar con el tutor y pedir consejo, pudiendo concluir en un cambio en la fecha de entrega. 4.3. Plan de pruebas Para validar la implementaci´on que se llevar´a a cabo en este proyecto, es necesario pasar por una serie de pruebas: 1. Comprobar que la comunicaci´on entre el autopiloto y la GCS se da normalmente. 2. Verificar que el rendimiento tanto de la comunicaci´on como del autopiloto y la GCS se mantiene similar al rendimiento con la configuraci´on por defecto de los mismos. 3. Asegurar que el cifrado es robusto mediante ataques de red que lo certifiquen. 4.4. Plan de mejoras 1. Integraci´on de las medidas de securizaci´on en el protocolo de comunicaci´on con un mayor nivel de abstracci´on del software que lo incluya. 8 2. Implementar un sistema de distribuci´on de claves privadas entre el autopiloto y la GCS. 3. Desarrollo de interfaz que posibilite al usuario final seleccionar si desea aplicar el cifrado de la comunicaci´on o no en una operaci´on concreta. 4.5. Plan de comunicaci´on Durante el desarrollo de este proyecto, el autor se apoyar´a en la ayuda y orientaci´on que tanto el tutor como el cotutor ofrecen. Se llevar´an a cabo las reuniones necesarias para apoyar la continuidad del trabajo, y recibir feedback sobre su literatura y desarrollo a nivel t´ecnico. 5. Estado del arte Los veh´ıculos a´ereos no tripulados, com´unmente conocidos como drones (aunque el t´ermino dron engloba a todo veh´ıculo no tripulado sea a´ereo, terrestre o acu´atico), han supuesto una importante transformaci´on de la tecnolog´ıa aeron´autica. Estas aeronaves est´an dise˜nadas para operar sin pilotos a bordo, y sus aplicaciones abarcan una amplia gama de sectores e industrias. Los UAVs vienen en varios tama˜nos, desde peque˜nos drones de consumo hasta grandes y sofisticados sistemas militares y comerciales[1]. Su versatilidad y capacidades han propiciado avances sustanciales en campos como la teledetecci´on, la recopilaci´on de datos, la vigilancia y la log´ıstica. La utilizaci´on de los veh´ıculos a´ereos no tripulados es muy amplia y cada vez hay m´as operadores como evidencian los datos proporcionados por AESA (ver Figura 2), destacando su importancia en diversos ´ambitos como el militar y de defensa, la agricultura, las misiones de b´usqueda y rescate, la vigilancia del medio ambiente, la inspecci´on de infraestructuras, la fotograf´ıa y la cinematograf´ıa. 9 Figura 2: Evoluci´on de los operadores de drones registrados en AESA[2] 5.1. Principales protocolos de comunicaci´on Para interactuar, monitorizar y controlar estos UAVs durante una misi´on determinada, se utilizan protocolos de comunicaci´on espec´ıficos para drones. En este estudio, se analizar´an los principales y se expondr´an sus caracter´ısticas m´as distintivas de modo que quede claro el papel que juega cada uno. 5.1.1. MAVLink (Micro Air Vehicle Link) MAVLink es un protocolo ligero y de c´odigo abierto ampliamente usado para la comunicaci´on bidireccional entre UAVs y GCSs. Su uso est´a muy extendido en el sector de los UAVs, especialmente en la comunidad de drones de c´odigo abierto (en proyectos como ArduPilot y PX4), y admite funciones tanto de telemetr´ıa como de comandos y control[3]. Detalles sobre la comunicaci´on MAVLink MAVLink fue dise˜nado como una librer´ıa de Marshaling, un proceso con alto grado de abstracci´on que serializa los mensajes y comandos que deben llegar a un destino remoto en un formato binario espec´ıfico (p.e., un stream de bytes). Es esta caracter´ıstica la que hace que el protocolo sea tan ligero, a diferencia de otras t´ecnicas de serializaci´on como JSON[4]. La 10 comunicaci´on MAVLink se basa en el env´ıo y recepci´on de mensajes y comandos desde y hacia el UAV o GCS. Estos tienen identificadores ´unicos y se definen en los llamados dialectos XML, que posteriormente se utilizan para generar la librer´ıa de c´odigo de MAVLink. A continuaci´on, se muestra una imagen sobre la estructura de un paquete MAVLink v2.0 serializado (ver Figura 3). En ella, se pueden ver todos los campos y su orden a nivel de byte: Figura 3: Desglose de un paquete MAVLink v2.0 La Tabla 4 pretende describir con m´as detalle la raz´on de ser de cada uno de los campos del paquete anteriormente mostrado. Index de Byte Nombre Descripci´on 0 STX STX es utilizado para indicar el comienzo de un nuevo paquete (253 para MAVLink v2 y 254 para v1). Cualquier sistema que no entienda la versi´on del protocolo omitir´a el paquete 1 LEN Indica la longitud del payload 2 INC FLAGS Flags usadas para verificar que haya compatibilidad en la comunicaci´on 3 CMP FLAGS Flags que pueden ignorarse si no son comprendidas 4 SEQ Usado para detectar p´erdida de paquetes 5 SYS ID ID del sistema que env´ıa el mensaje 6 COMP ID ID del componente que env´ıa el mensaje 7 al 9 MSG ID Tipo del mensaje del payload. Usado para decodificar los datos (de Bytes a objetos) Siendo n hasta 255: 10 al (9+n) PAYLOAD Payload o datos del mensaje (10+n) al (11+n) CHECKSUM Checksum (12+n) al (25+n) SIGNATURE Firma (Opcional) Tabla 4: Campos en el desglose del paquete MAVLink v2.0 Para que pueda establecerse una conexi´on MAVLink entre dos dispositivos, tiene lugar lo que 11 se conoce como protocolo Heartbeat (del espa˜nol latido de coraz´on). Durante este proceso, se anuncia la existencia de un dispositivo en la red MAVLink, junto con su SYS ID, COMP ID, tipo de veh´ıculo, autopiloto, versi´on de MAVLink, etc. Se˜nalar que cada dispositivo y componente debe emitir regularmente su HEARTBEAT para mantener la conexi´on viva. Aplicaciones comunes Se utiliza como protocolo de comunicaci´on en UAVs que realizan misiones b´usqueda y rescate, en el sector de la agricultura, y en monitorizaci´on medioambiental. Otras aplicaciones son inspecci´on de infraestructuras, como edificios o cableados. Tambi´en usado en misiones relacionadas con el mundo del cine y la publicidad. 5.1.2. UAVCAN (DroneCAN y OpenCyphal) UAVCAN es un protocolo de comunicaci´on dise˜nado espec´ıficamente para su uso en UAVs y otros sistemas rob´oticos. Construido sobre CAN (Controller Area Network), este proporciona un medio de comunicaci´on estandarizado y fiable entre los distintos componentes de un UAV, como sensores, actuadores y controladores de vuelo. Cabe destacar que actualmente no existe algo como UAVCAN, al menos formalmente, pues el proyecto ha sido recientemente dividido (ver Figura 4) en: DroneCAN (anteriormente conocido como UAVCAN v0, y tambi´en incorpora UAVCAN v0.5), por otro lado tenemos OpenCyphal (anteriormente conocido como UAVCAN v1)[9]. Clarificado esto, mencionar que en este trabajo de fin de grado se referir´a a UAVCAN generalmente, a no ser que sea cr´ıtico especificar que versi´on se emplea. 12 Figura 4: L´ınea temporal de protocolos de comunicaci´on Detalles sobre la comunicaci´on UAVCAN Las redes UAVCAN son peer-to-peer, donde cada nodo tiene un identificador ´unico. Estos se pueden comunicar entre s´ı usando cualquiera de los siguientes dos m´etodos de comunicaci´on: Broadcasting (publish/subscribe): m´etodo principal de intercambio de datos con sem´antica de publicaci´on/suscripci´on. Invocaci´on de servicios (petici´on/respuesta): m´etodo de comunicaci´on para interacciones de tipo solicitud/respuesta entre peers. Para cada m´etodo de comunicaci´on, se utiliza un conjunto predefinido de estructuras de datos, donde cada una de ellas tiene un identificador ´unico conocido como Data Type ID (DTID). Tal y como se ve en la Figura 5, algunas estructuras de datos son est´andar y vienen dadas por la especificaci´on del protocolo; otras pueden ser espec´ıficas de una aplicaci´on o un proveedor concretos (n´otese la analog´ıa con los dialectos MAVLink). Esta l´ogica de asignar DTIDs tanto a cada tipo de mensaje publicado como a cada nodo de la red permite aplicar redundancia mediante la utilizaci´on de pares con una id´entica funcionalidad dentro de la misma red. 13 Figura 5: Arquitectura de UAVCAN en cuanto a sus tipos de estructuras de datos Las estructuras de datos y servicios se definen mediante el Data Structure Description Language (DSDL) o lenguaje de descripci´on de estructuras de datos. Las definiciones DSDL se utilizan para generar autom´aticamente el c´odigo de serializaci´on/deserializaci´on de mensajes para un determinado lenguaje de programaci´on. La herramienta que genera el c´odigo fuente a partir de los archivos de definici´on DSDL se denomina compilador DSDL. El enfoque DSDL permite al compilador determinar est´aticamente el tama˜no de cada estructura de datos, lo que ayuda a optimizar las implementaciones del protocolo en t´erminos de consumo de memoria y rendimiento. Por ´ultimo, mencionar que UAVCAN cuenta con una serie de funciones de alto nivel ya implementadas como health monitoring,network discovery,time synchronization, etc[7]. Aplicaciones comunes UAVCAN es usado en varios componentes de un UAV como sensores, avi´onica (electr´onica aplicada a la aviaci´on) y terminales remotas. 5.1.3. DDS (Data Distribution Service) DDS es un est´andar abierto gestionado por el grupo internacional OMG (Object Management Group) formado por m´as de 200 organizaciones. Provee una API bien definida que permite al desarrollador escribir c´odigo portable entre proveedores[10]. DDS no ata a sus usuarios a un 14 proveedor en particular, pudiendo cambiar de uno a otro tanto como sea necesario durante los ciclos de desarrollo (ver Figura 6). La primera versi´on, DDS 1.0. se hizo p´ublica en 2003, mientras que actualmente ya se encuentra disponible la versi´on 1.4. (desde 2015). Figura 6: Interoperabilidad de DDS entre diferentes especificaciones de diferentes proveedores[11] Detalles sobre la comunicaci´on DDS La especificaci´on de DDS describe dos niveles de interfaces: DCPS yDLRL. La primera es una interfaz de bajo nivel conocida como Data-Centric Publish-Subscribe (ver Figura 7). Esta tiene como misi´on hacer un reparto de la informaci´on de forma eficiente a los receptores apropiados. Por su parte, Data Local Reconstruction Layer es una interfaz de m´as alto nivel que permite la integraci´on de DDS en la capa de aplicaci´on. A muy bajo nivel, DDS implementa el protocolo RTPS (Real Time Publish Subscribe Protocol), que lo dota de un alto grado de interoperabilidad entre aplicaciones con diferentes implementaciones de DDS. 15 Figura 7: Servicio de publicaci´on y suscripci´on en DDS Aplicaciones comunes Se utiliza a menudo en sistemas UAV complejos en los que se requiere un alto grado de intercambio de datos y coordinaci´on entre m´ultiples componentes, como sensores, avi´onica y unidades de control de vuelo (autopiloto). En aplicaciones militares, DDS es utilizado para facilitar el intercambio de datos en tiempo real entre varios componentes del sistema. Otro caso de uso es en la infraestructura del espacio a´ereo (control del tr´afico a´ereo, asistencia de navegaci´on, sistemas de comunicaci´on piloto-controladores de tr´afico a´ereo, etc.). Telepresencia en drones submarinos durante misiones de sumersi´on profunda (miles de metros de profundidad)[12]. 5.1.4. ROS (Robot Operating System) Aunque no es un protocolo de comunicaci´on en el sentido tradicional, ROS es un conjunto de librer´ıas y herramientas software que facilitan el desarrollo de aplicaciones rob´oticas, incluidos los UAV. Incluye sus propios mecanismos de comunicaci´on peer-to-peer entre procesos, que suelen utilizarse para gestionar y coordinar los distintos componentes de un sistema rob´otico (UAV en este caso). Detalles sobre la comunicaci´on ROS La comunicaci´on en ROS se basa en el patr´on publicaci´on-suscripci´on entre nodos (o procesos) del sistema. Cada uno de estos nodos o procesos puede tanto publicar datos como 16 Referencia Objetivo Ventajas Desventajas Comentario [15] Mejora en el marco de la seguridad del protocolo DDS Reducci´on de la superficie de vulnerabilidades Recursos de computaci´on adicionales, concluyendo en menor viabilidad en sistemas limitados Es bueno reforzar la seguridad de DDS, aunque la mejora es poca y su rendimiento se ver´ıa afectado Tabla 6: An´alisis de avances en securizaci´on previos basados en DDS 5.3.3. ROS (Robot Operating System) Las comunicaciones en UAVs pueden ser securizadas empleando un m´etodo basado en ECIES (Criptograf´ıa de Curva El´ıptica) como ha sido previamente demostrado en el trabajo [17]. Dicho estudio usa ROS como el n´ucleo de la comunicaci´on con objeto de interconectar los diferentes nodos del sistema. Se ha demostrado que si un intruso es capaz de acceder a la red local de un sistema UAV, este ser´ıa capaz de impersonar a la GCS y tomar un control indeseado del mismo, pudiendo desembocar en una maniobra no deseada que ponga en riesgo la integridad de edificios o personas. La soluci´on basada en ECIES ha resultado ser una t´ecnica factible para incrementar la seguridad en los sistemas de comunicaciones que utilizan ROS, sin perder la versatilidad y facilidad que proporciona tal protocolo. Tal y como se ve en la Tabla 7, existe otro estudio que propone mejorar la seguridad de un UAV basado en ROS mediante la implementaci´on de mecanismos de seguridad en los nodos master, publisher y subscriber[18]. Afirma que esta medida no atiende todas las vulnerabilidades del sistema, pero s´ı las m´as cr´ıticas: 1. Usuarios no autorizados registrando nodos en el sistema. 2. Nodos no autorizados inyectando datos fraudulentos que pueden afectar al vuelo del dron. 23 Referencia Objetivo Ventajas Desventajas Comentario [17] Sistema de seguridad que permita autentificar la identidad de la GCS e impedir comandos no autorizados de intrusos a. Mitigar ataques MITM hijacking. b. Abstracci´on en la recepci´on de mensajes al UAV. A˜nade complejidad al sistema de comunicaci´on Algoritmos RSA y ECDSA para mejorar seguridad de comunicaciones UAV-GCS. [18] Implementar caracter´ısticas de securizaci´on a nivel de nodos (master, publisher y subscriber) El estado de seguridad mejora respecto al por defecto Hay otras vulnerabilidades no contempladas Buen aporte a la regulaci´on de uso y registro de nodos ROS Tabla 7: An´alisis de avances en securizaci´on previos basados en ROS 5.3.4. MAVLink (Micro Air Vehicle Link) Como se ha definido anteriormente, MAVLink es un protocolo dise˜nado para ser ligero, dejando al descubierto vulnerabilidades cr´ıticas en la comunicaci´on: confidencialidad, integridad y disponibilidad. Existe un estudio que ha desarrollado un proyecto llamado MAVSec [6], que propone una soluci´on a la confidencialidad (ver Tabla 8). Su soluci´on consiste en aplicar algoritmos de cifrado a los paquetes MAVLink antes de su env´ıo, y de descifrado tras su recepci´on. Se llegan a comparar varios algoritmos como AES-CTR, AES-CBC, RC4 y ChaCha20, mostrando as´ı el impacto que tienen en el rendimiento del sistema (ver Figura 9). 24 Figura 9: Comparaci´on de uso de la CPU (MAVLink sin cifrado vs. diferentes algoritmos criptogr´aficos) A pesar de ser un gran aporte, el proyecto carece de buena y detallada documentaci´on sobre c´omo se lleva a cabo la implementaci´on a nivel de c´odigo, y c´omo se integrar´ıa en MAVLink. Por otra parte, el proyecto de c´odigo abierto que ata˜ne a MAVSec, que se encuentra en GitHub, lleva a˜nos sin ser actualizado y parece no haber seguido unas pautas de dise˜no adecuadas durante su desarrollo. Esto hace que su futuro uso, modificaciones o ampliaciones del proyecto sean poco viables. Finalmente, mencionar que solo implementa esta soluci´on a nivel de simulaci´on, es decir, no han utilizado un hardware autopiloto real al que cargarle un firmware modificado. Tampoco se aprecia que hayan aplicado dichos cambios en alg´un software GCS para comprobar que la comunicaci´on se hace efectiva en ambas direcciones de un sistema b´asico de comunicaci´on de un UAV. 25 Referencia Objetivo Ventajas Desventajas Comentario [6] Usar algoritmos de cifrado para garantizar la protecci´on de paquetes MAVLink entre los UAV y GCS Salvaguarda la confidencialidad e integridad de la comunicaci´on Implementaci´on pobre y obsoleta Un buen aporte que podr´ıa ser ampliado con una nueva implementaci´on Tabla 8: An´alisis de avances en securizaci´on previos basados en MAVLink 5.4. Algoritmo de cifrado ChaCha20 El cifrado de extremo a extremo que tendr´a lugar en la comunicaci´on entre el autopiloto y la GCS se realizar´a mediante ChaCha20. Este es un algoritmo de cifrado sim´etrico cuya l´ogica se explicar´a a continuaci´on. Se˜nalar que, para ello, me basar´e en el est´andar RFC 7539 definido por la IETF (Internet Engineering Task Force). La IETF es la principal organizaci´on de desarrollo de est´andares de Internet. Los est´andares que elabora, de forma voluntaria, suelen ser adoptados por usuarios de Internet y operadores de redes. Comenzar´e hablando sobre el algoritmo ChaCha, el cual se describe utilizando un “vector” o “matriz” de estado de 64 Bytes (SM a partir de ahora). Es una matriz cuadrada de dimensi´on 4x4 en la que cada celda representa 32 bits (4 Bytes). La notaci´on matricial es m´as conveniente visualmente y da una mejor noci´on de c´omo se aplican transformaciones a la misma. La SM viene dada por: Las celdas de la primera fila son una constante “c”: 0x61707865, 0x3320646e,0x79622d32, 0x6b206574. Esta constante es producto de serializar la cadena de texto “expand 32-byte k” en little-endian, y es propia del algoritmo ChaCha. Las celdas de las dos siguientes filas corresponden con la clave privada de 256 bits “k” representada en little-endian, celda por celda. La primera celda de la ´ultima fila contiene al contador de bloques “b”. Las ´ultimas 3 celdas corresponden con el nonce “n” escrito en little-endian como la clave. El nonce (del ingl´es Number Used Once) no debe necesariamente ser secreto. ChaCha20 es una variante espec´ıfica de ChaCha en la que se realizan 20 rondas de transformaciones (u 80 cuartos de ronda). En la Tabla 9 puede verse la matriz de estado inicial 26 (SM0). c[0-3] c[4-7] c[8-11] c[12-15] k[3-0] k[7-4] k[11-8] k[15-12] k[19-16] k[23-20] k[27-24] k[31-28] b[0-3] n[3-0] n[7-4] n[11-8] Tabla 9: Matriz de estado inicial del algoritmo ChaCha El proceso de cifrado o descifrado de datos usando ChaCha20 se lleva a cabo a partir de tres procesos principales, que son el Quarter Round (cuarto de ronda), el Block Function (funci´on de bloque) y la operaci´on final XOR. 5.4.1. Quarter Round (Cuarto de Ronda) El Quarter Round es una de las operaciones b´asicas de ChaCha, y opera con 4 enteros sin signo de 32 bits como entrada. La operaci´on Quarter Round se aplica directamente sobre las celdas de la matriz SM, por lo que sus 4 entradas a, b, c, d son nada m´as y nada menos que estas (ver Figura 10). Quarter Round puede realizar dos tipos de transformaciones en la matriz: transformaciones de columnas y transformaciones diagonales, y depende de a qu´e celdas correspondan los par´ametros de entrada de la funci´on. 27 Figura 10: Operaci´on Quarter Round propia del algoritmo ChaCha Por ejemplo, dada la siguiente matriz SM : 0123 4567 8 9 10 11 12 13 14 15 Tabla 10: Matriz SM ejemplo Una transformaci´on de columna QUARTERROUND(1,5,9,13) aplicar´ıa trasformaciones a la segunda columna de la matriz SM tal y como se ve en la Figura 11. 0 *1 2 3 4 *5 6 7 8 *9 10 11 12 *13 14 15 Tabla 11: Matriz SM ejemplo transformaci´on de columna 28 Por otro lado, en la Figura 12 se muestra una transformaci´on diagonal QUARTERROUND(2,7,8,13) que aplica la transformaci´on a las celdas de dicha diagonal. 0 1 *2 3 4 5 6 *7 *8 9 10 11 12 *13 14 15 Tabla 12: Matriz SM ejemplo transformaci´on diagonal 5.4.2. Block Function (Funci´on de Bloque) Por su parte, Block Function hace uso de Quarter Round constantemente. Puede decirse que Block Function modifica la matriz de estado SM aplic´andole varias transformaciones propias de Quarter Round. Block Function recibe como entradas los siguientes par´ametros: Clave privada de 256 bits que consiste en 8 enteros de 32 bits Nonce de 96 bits que consiste de 3 enteros de 32 bits Contador de bloques de 32 bits Block Function crea la matriz de estado inicial SM0 para cada bloque a partir de los elementos descritos al inicio de este apartado, luego se encarga de aplicar ciertas transformaciones a la misma. Aqu´ı es justamente cuando se especifica a nivel implementaci´on que se est´a utilizando ChaCha20 (y no simplemente ChaCha) como algoritmo de cifrado. Esto es, se aplican 20 rondas de transformaciones, entre transformaciones de columnas y diagonales. La matriz SM de ChaCha tiene 16 celdas, por lo que Quarter Round debe aplicarse 4 veces por cada ronda de transformaciones de columnas y diagonales respectivamente, de ah´ı su nombre. Tras las 20 rondas, la siguiente operaci´on a realizar es una suma de matrices entre SM ySM0. Finalmente, la funci´on devuelve el resultado serializado en little-endian. 5.4.3. Operaci´on XOR La funci´on principal que se encarga de cifrar o descifrar los datos es la funci´on XOR. Esta divide los datos que se desean cifrar o descifrar en bloques de 64 bytes como m´aximo. Por cada uno de los bloques necesarios, se llama a Block Function y, posteriormente, se realiza una operaci´on XOR entre el bloque y la matriz SM que Block Function ha generado. Y como 29 esta misma funci´on XOR de ChaCha20 se puede usar tanto para cifrar como para descifrar datos, no se definir´a una funci´on por separado para cada proceso. A continuaci´on, en la Figura 11, se muestra un gr´afico que resume el proceso de cifrado o descifrado de datos usando ChaCha20: Figura 11: Proceso de cifrado y descifrado de ChaCha20 En la figura se aprecian dos fases bien diferenciadas, una de ellas es la equivalente al proceso de generar y transformar la matriz de estado SM a partir de la clave privada, el nonce, la constante de ChaCha y el contador de bloques. Durante el generado de la SM, las operaciones que tienen lugar son las ya descritas Quarter Round y Block Function. Es esta misma SM es la que actuar´a como llave y har´a posible el cifrado/descifrado de los datos en el momento en que pasamos por la operaci´on XOR. 6. An´alisis de requisitos En esta secci´on se describen los requisitos funcionales y no funcionales que influencian al dise˜no y desarrollo de la soluci´on dada por este estudio. Tambi´en se introducen los actores involucrados en el sistema. 6.1. Actores involucrados Actor Desarrollador: persona encargada del desarrollo de todo el Sistema 30 Actor Operador: persona con la formaci´on y autorizaci´on necesarias para intervenir en una misi´on de vuelo, controlando el Dron a trav´es de la GCS o control manual si es necesario Actor Dron: veh´ıculo a´ereo no tripulado controlado por el Operador y en constante comunicaci´on con la GCS Actor GCS: software de control de misiones de vuelo que es ejecutado en un equipo autorizado en tierra, el cual es a su vez monitorizado por el Operador Actor Sistema: viene dado por la interacci´on entre los actores anteriormente descritos y satisface los requisitos expuestos m´as adelante 6.2. Requisitos funcionales y no funcionales Requisitos funcionales (RF) •RF01 - El Sistema deber´a contar con una clave privada ´unicamente conocida por el UAV y la GCS durante la conexi´on •RF02 - El Sistema deber´a implementar algoritmo de cifrado ChaCha20 para asegurar comunicaci´on MAVLink entre dispositivos •RF03 - El Dron deber´a aceptar el firmware ArduPilot adaptado sin afectar a sus funcionalidades •RF04 - El GCS deber´a aceptar las modificaciones MAVLink necesarias sin afectar a sus funcionalidades Requisitos no funcionales (RNF) •RNF01 - El Sistema deber´a garantizar la confidencialidad de datos •RNF02 - El Desarrollador deber´a adaptar los algoritmos de cifrado/descifrado para que se ajusten al perfil de bajo consumo requerido por el Dron •RNF03 - El Sistema deber´a implementar una soluci´on que minimice la necesidad de intervenci´on manual •RNF04 - El Sistema deber´a salvaguardar el rendimiento de la comunicaci´on tras implementar el cifrado ChaCha20 31 •RNF05 - El Sistema deber´a asegurar que el cifrado ChaCha20 sea robusto y resistente a ataques criptogr´aficos conocidos, protegiendo la confidencialidad de los datos transmitidos 7. Esquema de trabajo En este apartado se expondr´an las fases de desarrollo de este proyecto, as´ı como las subtareas pertinentes a cada una de ellas. El esfuerzo de dise˜no e implementaci´on se sostendr´a sobre todas estas etapas descritas a continuaci´on. Fases de desarrollo del proyecto: Fase 0: planificaci´on de la implementaci´on del proyecto mediante un an´alisis del marco general del mismo (Objetivo 1) •Tarea 0.1: decidir qu´e protocolo de comunicaci´on de drones se utilizar´a para llevar a cabo la securizaci´on •Tarea 0.2: seleccionar y organizar las herramientas (tanto software como hardware) necesarias para llevar a cabo la implementaci´on m´as tarde Fase 1: dise˜nar y configurar el sistema de comunicaci´on con el dron •Tarea 1.1: establecer un punto de partida en el que las herramientas seleccionadas y el sistema inicial funcionan correctamente (como deber´ıan por defecto) Fase 2: an´alisis y entendimiento del hardware/software/firmware seleccionados en sus valores por defecto •Tarea 2.1: estudiar en detalle el flujo de comunicaci´on del protocolo MAVLink •Tarea 2.2: estudiar en detalle el rol del protocolo MAVLink tanto en el software QGroundControl (GCS) como en ArduPilot (firmware autopiloto) Fase 3: an´alisis sobre los algoritmos de cifrado de inter´es (ChaCha20) •Tarea 3.1: adquirir/desarrollar/optimizar el c´odigo relativo a los algoritmos de cifrado a implementar 32 dos principalmente en dichos lenguajes, lo que hace que esta decisi´on tenga mucho sentido. Adem´as, MAVLink ofrece la posibilidad de generar la librer´ıa de comunicaci´on en diversos lenguajes, entre ellos C, que es el que se usar´a. Por ´ultimo, mencionar que C/C++ son id´oneos para el desarrollo de software en este tipo de sistemas gracias a su eficiente manejo de memoria y recursos en el contexto de software embebido y firmware. 8.2.8. Herramienta de an´alisis de tr´afico de red Por ´ultimo, se˜nalar que para la realizaci´on de algunas pruebas se har´a uso de la herramienta de an´alisis de tr´afico de redes Wireshark. Es una herramienta gratuita muy vers´atil que servir´a para hacer ciertas comprobaciones a lo largo de la implementaci´on, pues cuenta con un plugin que lo capacita para entender tramas MAVLink. Por un lado, se llevar´an a cabo test en los que Wireshark servir´a para monitorear el tr´afico de la comunicaci´on y comprobar que los resultados son los esperados. Por otro lado, se usar´a para realizar ataques de sniffing o MITM en los que se interceptar´a la comunicaci´on MAVLink antes y despu´es de ser cifrada y as´ı llegar a conclusiones. No es necesario obtener una versi´on concreta de esta herramienta. 8.3. Configuraci´on inicial del sistema (punto de partida) Es importante establecer un punto de partida del sistema y sus componentes para una mejor comprensi´on del mismo. Por ello se explicar´a paso a paso c´omo todas sus partes han sido configuradas inicialmente. Adem´as, se definir´an varios modelos acerca de c´omo se conectan entre s´ı; cada uno de ellos cobra sentido para ciertas pruebas a lo largo de la implementaci´on. 8.3.1. Compilar y ejecutar QGroundControl desde su repositorio fuente Para compilar y ejecutar QGroundControl en su versi´on v4.2.9 a partir de su repositorio de GitHub se tendr´a en cuenta que se realizar´a en un equipo con Ubuntu 22.04 LTS. QGC ofrece un modo de compilaci´on usando una imagen propia de Docker que se encuentra dentro del mismo proyecto, y es el camino que se seguir´a. 1. Abrir una terminal en la ubicaci´on donde se desee clonar el repositorio de QGC. 2. Ejecutar el comando git clone https://github.com/mavlink/qgroundcontrol – recurse-submodules para clonar el repositorio. La opci´on “–recurse-submodules” especifica que se clonar´an sus respectivos subm´odulos recursivamente de forma autom´atica. 39 3. Entrar a la carpeta descargada llamada “qgroundcontrol” con el comando cd qgroundcontrol. 4. Ejecutar el comando git checkout v4.2.9. Con esto estamos apuntando a la rama de QGroundControl correspondiente a la versi´on v4.2.9. 5. Ejecutar el script “install-qt-linux.sh” mediante el comando ./deploy/docker/installqt-linux.sh. Este instalar´a Qt, que es una dependencia de QGroundControl. 6. Ahora, se necesita crear una carpeta para poder compilar el proyecto. Lanzar el comando mkdir build. 7. Crear la imagen de docker de QGC mendiante el comando docker build –file ./deploy/docker/Dockerfile-build-linux -t qgc-linux-docker . . 8. Ya es posible compilar el proyecto, para ello hay que ejecutar el comando docker run – rm -v $PWD:/project/source -v $PWD/build:/project/build qgc-linux-docker. 9. Tras unos minutos el proyecto estar´a correctamente compilado (ver Figura 17) y se habr´a generado un ejecutable que nos permite lanzar QGroundControl. Para ello hay que hacer doble click en el archivo “QGroundControl” ubicado en build/staging/. Figura 17: Salida esperada en la terminal al finalizar compilaci´on de QGroundControl Una vez tenemos QGroundControl abierto podemos pasar a configurar el autopiloto. 8.3.2. Compilar el firmware ArduPilot desde su repositorio fuente Para compilar el firmware ArduPilot que posteriormente se flashear´a al CubePilot CubeO- range, tendremos que seguir los siguientes pasos: 1. Abrir una terminal en la ubicaci´on donde se desee clonar el repositorio de ArduPilot. 40 2. Ejecutar el comando git clone https://github.com/ArduPilot/ardupilot –recursesubmodules para clonar el repositorio. La opci´on “–recurse-submodules” especifica que se clonar´an sus respectivos subm´odulos recursivamente de forma autom´atica. 3. Al igual que con QGC, hay que entrar a la carpeta descargada llamada “ardupilot” con el comando cd ardupilot. 4. En este caso se utilizar´a un commit espec´ıfico del repositorio, para apuntar a ´el, ejecutar el comando git checkout e7bf9d2. 5. El siguiente paso es ejecutar el script que instala dependencias en el sistema. Para ello ejecutar el comando ./Tools/environment install/install-prereqs-ubuntu.sh. 6. Luego, es necesario configurar el proyecto especificando qu´e tipo de autopiloto es el que llevar´a este firmware. El comando ./waf configure –board CubeOrange es el que debemos ejecutar. 7. Finalmente, compilaremos ArduPilot especificando el tipo de veh´ıculo objetivo, en este caso no es cr´ıtico pues no se har´an pruebas con un veh´ıculo real volando. Ejecutaremos el siguiente comando: ./waf copter. 8. Despu´es de unos minutos, el firmware ArduPilot estar´a correctamente compilado (ver Figura 18) y listo para ser subido al autopiloto CubePilot CubeOrange. El archivo de inter´es que ha sido generado para ello est´a ubicado en build/bin/arducopter.apj. Figura 18: Salida esperada en la terminal al finalizar compilaci´on de ArduPilot 41 8.3.3. Subir el firmware ArduPilot a CubePilot CubeOrange a trav´es de QGround- Control Para flashear el firmware ArduPilot que hemos compilado previamente al autopiloto CubePilot CubeOrange, es necesario conectar el autopiloto a QGroundControl mediante conexi´on USB serial. Para ello: 1. Abrir la aplicaci´on de QGroundControl. 2. Ir a la pesta˜na Select Tool a la que se accede dando click en el logotipo de QGC de la esquina superior derecha de la aplicaci´on. 3. Entrar en la pesta˜na Vehicle Setup y luego en la pesta˜na Firmware. 4. Conectar el autopiloto al equipo mediante USB serial. 5. En el desplegable que aparece a la derecha, marcar la opci´on de Advanced Settings y seleccionar Custom Firmware File en el desplegable de abajo del todo (ver Figura 19). 6. Finalmente, se selecciona el firmware previamente compilado llamado arducopter.apj y se cargar´a en unos instantes. Figura 19: Cargar el firmware ArduPilot a trav´es de QGroundControl 42 8.3.4. Comunicaci´on inicial entre CubePilot CubeOrange y QGroundControl En este punto, se har´a una sencilla comprobaci´on para ver que al conectar el autopiloto con QGroundControl se aprecia una conexi´on estable. Despu´es de que hayamos cargado ArduPilot en el autopiloto, necesitamos desconectar y volver a conectar el autopiloto a nuestro equipo. As´ı QGroundControl lo detectar´a como sistema MAVLink y comenzar´an a comunicarse. Tras la reconexi´on, ambas partes se comunican entre s´ı correctamente. Esto se sabe por que QGroundControl muestra un indicador de color verde en la barra superior cuando un autopiloto muestra una conexi´on estable. En este caso, y como estamos utilizando QGroundControl y ArduPilot con su configuraci´on por defecto, la comunicaci´on MAVLink que est´a teniendo lugar a trav´es del la conexi´on USB no cuenta con ninguna caracter´ıstica de securizaci´on. Finalmente, mencionar que si vamos a la pesta˜na “MAVLink Inspector” dentro de QGround- Control, podemos ver un registro en tiempo real de todos los mensajes MAVLink que el autopiloto le est´a enviando (ver Figura 20). Figura 20: Mensajes mostrados en MAVLink Inspector 8.3.5. Definir diferentes modelos de comunicaci´on con fines de realizaci´on de pruebas Debido a la naturaleza del desarrollo software de este proyecto, es interesante y muy ´util establecer diferentes modelos de comunicaci´on (b´asicos y m´as complejos). Esto es, seg´un el tipo de prueba a realizar nos bastar´a con un modelo u otro. Por ejemplo, para comprobar si una nueva caracter´ıstica implementada se est´a ejecutando correctamente dentro del autopiloto es suficiente con conectarlo al equipo que est´e ejecutando QGroundControl mediante USB serial y depurarlo. 43 El m´as b´asico se definir´a como Modelo A de ahora en adelante (ver Figura 21), y consta de una conexi´on simple y directa entre la GCS (QGroundControl) y el autopiloto (CubePilot CubeOrange). Figura 21: Conexi´on directa v´ıa USB entre el autopiloto y la GCS El Modelo A es ideal para realizar cargas de firmware y pruebas r´apidas de conexi´on o para probar si la implementaci´on funciona correctamente en un nivel b´asico o de “debug”. Extendiendo el Modelo A se encuentra el Modelo B que a˜nade un tercer componente al sistema: la Raspberry Pi (ver Figura 22). Este modelo nos acerca m´as a un sistema de comunicaci´on m´as realista. La Raspberry Pi funcionar´a sobre Raspberry Pi OS, y estar´a configurada para aceptar conexiones remotas v´ıa SSH (con el fin de poder controlarla desde el mismo equipo que ejecuta QGroundControl y no necesitar perif´ericos extra). En este modelo, el CubeOrange no estar´a conectado directamente a QGroundControl, sino que se conectar´a v´ıa USB a la Raspberry Pi. Ser´a necesario instalar MAVProxy en ella para reenviar el tr´afico MAVLink que le llega desde CubeOrange hasta el ordenador ejecutando QGroundControl. La Raspberry Pi estar´a conectada mediante un puente en la misma red en la que est´a el ordenador que ejecuta QGroundControl. 44 Figura 22: Autopiloto conectado directamente a la Raspberry Pi y comunicaci´on reenviada a la GCS v´ıa MAVProxy Finalmente, para llevar a cabo pruebas de ataques de red contra el flujo de comunicaci´on GCS - autopiloto, se propone el Modelo C, que no es m´as que una extensi´on del Modelo B en la que se incluye un equipo destinado a atentar contra la confidencialidad e integridad de la comunicaci´on (ver Figura 23). Este estar´a en la misma red que el resto, y usar´a Wireshark para interceptar la comunicaci´on. 45 Figura 23: Conexi´on como en Modelo B pero con atacante interceptando la comunicaci´on Descritas estas decisiones de dise˜no, est´a todo preparado para comenzar a desarrollar e implementar el c´odigo necesario. Todos los detalles se expondr´an a continuaci´on. 9. Implementaci´on En este apartado se mostrar´a paso a paso y con detalle todo lo que haga falta desarrollar, modificar y/o implementar en este sistema de comunicaci´on MAVLink que sucede entre ArduPilot y QGroundControl, tal y como se describe en apartados previos. Por un lado, ser´a necesario aplicar el conocimiento sobre ChaCha20 descrito en el estudio previo con objeto de desarrollar c´odigo utilizable. Este contar´a con las funciones Quarter Round, Block Function y XOR, as´ı como otras funciones secundarias a nivel de bit, que nos permitir´an cifrar y descifrar arrays de bytes (paquetes MAVLink serializados en este caso). Luego, se har´a accesible dicho c´odigo de ChaCha20 tanto desde el m´odulo MAVLink de 46 ArduPilot, como del de QGroundControl. Esto es porque todos los nodos de la comunicaci´on que utilicen MAVLink necesitan compartir las mismas funcionalidades, as´ı como dialectos. De lo contrario, la comunicaci´on simplemente no podr´a tener lugar; si un nodo (digamos que QGroundControl) implementa ChaCha20 y el otro (digamos que ArduPilot) no lo implementa, ambos ser´an incapaces de comprender los paquetes MAVLink que reciben del otro. Adem´as de hacer este c´odigo de ChaCha20 accesible, es necesario que se haga uso de sus funciones dentro del c´odigo de MAVLink del nodo respectivo. Para ello, es primordial comprender el proceso de generado de la librer´ıa de c´odigo MAVLink, pues es durante este cuando se crean archivos que definen las funciones y utilidades est´andares de MAVLink, as´ı como el c´odigo relativo al procesado de ambos, recepci´on y env´ıo, de cada tipo de mensaje (previamente definidos en el dialecto XML). Por lo tanto, como se desea modificar parte de estas utilidades (para dotarlas de una capa de cifrado/descifrado), se tendr´a que modificar el modo en el que operan para que contemplen las funciones de ChaCha20. Una vez hayamos incorporado las modificaciones necesarias, se proceder´a a repetir el proceso de configuraci´on/compilaci´on tanto de ArduPilot como de QGroundControl. Haciendo esto, conseguimos tener unos ejecutables y/o archivos binarios de esos componentes que cuenten con soporte para el cifrado de MAVLink usando el algoritmo de cifrado/descifrado ChaCha20. 9.1. Desarrollo del algoritmo de cifrado ChaCha20 En esta secci´on se mostrar´a el pseudo-c´odigo relevante al algoritmo ChaCha20 desarrollado. Este ha sido escrito en el lenguaje de programaci´on C en base a la informaci´on ya descrita en el estudio previo. Por supuesto, cada bloque de pseudo-c´odigo proporcionado tendr´a su pertinente explicaci´on. Se˜nalar que el algoritmo de cifrado ChaCha20 ha sido desarrollado en un archivo de cabecera de C (chacha20.h) el cual est´a conformado por varias funciones. Por un lado, encontramos las funciones m´as relevantes de ChaCha20, como Quarter Round o Block Function y, por otro lado, funciones secundarias pero necesarias para realizar operaciones a nivel de bit, como conversiones a/desde little-endian. 47 9.1.1. Funciones principales A continuaci´on se describen las funciones que juegan un papel principal en el c´odigo de ChaCha20. Se han separado seg´un la tarea que cada una debe hacer, de tal manera que cada funci´on lleve a cabo un ´unico cometido. Estas hacen uso unas de otras, y a su vez, de otras funciones menores las cuales ser´an expuestas m´as adelante. Funci´on quarterRound La funci´on quarterRound realiza una operaci´on que consiste en una serie de sumas, operaciones XOR y rotaciones de bits aplicadas a los elementos de la matriz de estado x. Estas operaciones se corresponden a las transformaciones por columnas o diagonales descritas en el estudio previo. Que se lleve a cabo una u otra depende de qu´e ´ındices haya recibido la funci´on como par´ametros. Algorithm 1 quarterRound Require: x: Matriz de estado de ChaCha20 Require: a, b, c, d:´ Indices para la operaci´on Quarter Round 1: x[a]←x[a] + x[b] 2: x[d]←unsigned32LeftRotation(x[d]⊕x[a],16) 3: x[c]←x[c] + x[d] 4: x[b]←unsigned32LeftRotation(x[b]⊕x[c],12) 5: x[a]←x[a] + x[b] 6: x[d]←unsigned32LeftRotation(x[d]⊕x[a],8) 7: x[c]←x[c] + x[d] 8: x[b]←unsigned32LeftRotation(x[b]⊕x[c],7) Donde + define una suma m´odulo 232 (en algunos lenguajes, esto se denomina suma sin acarreo sobre una palabra de 32 bits), ⊕define una operaci´on OR exclusiva (XOR), y unsigned32LeftRotation(a, n) es una funci´on que realiza una rotaci´on de nbytes a la izquierda al array a. Par´ametros: •x: un puntero a la matriz de estado de ChaCha20 •a,b,c,d: ´ındices de los elementos en la matriz de estado que participan en la operaci´on de cuarto de ronda Funci´on blockFunction 48 Figura 24: Ejemplo aislado de cifrado y descifrado usando ChaCha20 55 Para este ejemplo se han definido la clave privada, el nonce y el array de bytes correspondiente al mensaje que se desea cifrar, el cual es una simple oraci´on Hola, este es un mensaje privado que quiero cifrar.. Recordemos que la funci´on xorOperation realiza tanto el cifrado como el descifrado de los datos, es decir, la primera vez que la ejecutemos pas´andole el mensaje legible como entrada, la salida ser´a el mensaje cifrado. Al volver a aplicar la operaci´on sobre el mensaje cifrado, el resultado ser´a el mensaje original. Salida por terminal Como resultado de ejecutar el anterior script, podemos ver como efectivamente el mensaje privado es cifrado y descifrado exitosamente (ver Figura 25). Figura 25: Resultado mostrado en la terminal del ejemplo de cifrado y descifrado usando ChaCha20 9.2. Integrar el algoritmo ChaCha20 en la librer´ıa MAVLink En esta secci´on se tomar´a el algoritmo ChaCha20 que ha sido desarrollado y se incluir´a y usar´a dentro de la librer´ıa MAVLink. Para realizar estas modificaciones en la librer´ıa MAVLink, es imprescindible comprender c´omo es generada en primer lugar. 9.2.1. Generador de la librer´ıa de c´odigo MAVLink Tal y como se explic´o en el estudio previo, en MAVLink, los mensajes, comandos, enumerados, par´ametros, y toda pieza involucrada en la comunicaci´on son definidas en archivos .xml conocidos como dialectos. Existen varios dialectos por defecto, como minimal,ardupilotmega, common, etc., aunque pueden crearse dialectos totalmente personalizados al uso. Para generar la librer´ıa de c´odigo de MAVLink se hace uso de un script Python propio del protocolo llamado mavgenerate.py, el cual se encuentra dentro de su c´odigo fuente. 56 Este script, adem´as de los dialectos XML, tambi´en hace uso de otro conjunto de cabeceras C para generar el c´odigo de la librer´ıa MAVLink. Estas son: checksum.h,mavlink conversions.h, mavlink get info.h,mavlink helpers.h,mavlink sha256.h,mavlink types.h yprotocol.h. Cada una de ellas tiene dentro el c´odigo necesario para hacer funcionar de forma robusta la librer´ıa. checksum.h: provee funciones para calcular checksums CRC de mensajes MAVLink mavlink conversions.h: contiene funciones para convertir entre diferentes tipos de datos MAVLink mavlink get info.h: define funciones para obtener informaci´on sobre la versi´on y compatibilidad del protocolo MAVLink mavlink helpers.h: incluye funciones auxiliares para codificar y decodificar mensajes MAVLink mavlink sha256.h: ofrece implementaciones para generar hashes SHA-256 utilizados en MAVLink mavlink types.h: declara tipos de datos y estructuras b´asicas utilizadas por MAVLink protocol.h: define la estructura principal y las operaciones del protocolo MAVLink usadas en los archivos anteriores Concretamente, para usar el generador mavgenerate.py se especifican un dialecto XML sobre el que se basar´a la librer´ıa, la carpeta de destino donde se guardar´a la librer´ıa generada, la versi´on a utilizar del protocolo (v1.0 ´o v2.0) y el lenguaje en base al que se generar´a (C, C++, Java, Lua, etc.). Las cabeceras anteriormente mencionadas son directamente copiadas al directorio destino, y todo lo descrito en el dialecto especificado ser´a parseado por el generador y se utilizar´a para generar otras cabeceras que se corresponden con definici´on de mensajes, comandos, etc. 9.2.2. Incluir chacha20.h donde se genera la librer´ıa MAVLink Para poder incluir el algoritmo ChaCha20 escrito en C, tendremos que modificar el c´odigo fuente del generador de MAVLink para que tambi´en copie la cabecera chacha20.h al generar la librer´ıa (al igual que las otras cabeceras). Para ello, se seguir´an los siguientes pasos: 57 Abrir el archivo mavgen c.py que se encuentra dentro del repositorio de MAVLink en la carpeta pymavlink/generator/ En la funci´on copy fixed headers tenemos que modificar el diccionario hlist, el cual contiene pares version :lista de cabeceras. Vamos a a˜nadir la cabecera “chacha20” a la lista que se corresponde con la versi´on “2.0” Ahora, tenemos que colocar manualmente la cabecera chacha20.h dentro de la carpeta /pymavlink/generator/C/include v2.0/ Tras estos pasos, cada vez que generemos la librer´ıa de c´odigo MAVLink v2.0, el archivo chacha20.h ser´a copiado all´a donde hayamos especificado la carpeta de destino (ver Figura 26). Por ejemplo, si hemos especificado a mavgenerate.py que genere la librer´ıa MAVLink para C en la carpeta generated/ y en base al dialecto common, esta contar´a con el siguiente contenido: generated/ •common/ ◦Cabeceras espec´ıficas para el dialecto common •checksum.h •mavlink conversions.h •mavlink get info.h •mavlink helpers.h •mavlink sha256.h •mavlink types.h •protocol.h •chacha20.h 58 Figura 26: Proceso de generado de la librer´ıa MAVLink 9.2.3. Integrar el cifrado y descifrado en la librer´ıa MAVLink Aqu´ı tendremos que realizar dos modificaciones clave, una de ellas en la cabecera mavlink helpers.h y la otra dentro del previamente mencionado archivo mavgen c.py. La primera se har´a en una funci´on llamada mav finalize message chan send la cual, a bajo nivel, realiza el empaquetamiento y env´ıo de mensajes MAVLink (ver Figura 27). La segunda se har´a en la funci´on generate message h de mavgen c.py, encargada de escribir el contenido de las cabeceras autogeneradas de cada mensaje MAVLink para un determinado dialecto. Modificar la funci´on mav finalize message chan send de mavlink helpers.h 59 Algorithm 9 mav finalize message chan send Require: chan: Canal de MAVLink Require: msgid: ID del mensaje Require: packet: Paquete de datos Require: min length: Longitud m´ınima del mensaje Require: length: Longitud del mensaje Require: crc extra: Valor extra de CRC 1: status ←Estado de chan 2: header len ←Longitud de la cabecera del mensaje 3: incompat flags ←0 4: length ←mav trim payload(packet, length) 5: 6: {Configurar encabezado para MAVLink 2} 7: buf[0] ←MAV LINK STX 8: buf[1] ←length 9: buf[2] ←incompat flags 10: buf[3] ←compat flags 11: buf[4] ←status.current tx seq 12: buf[5] ←mavlink system.sysid 13: buf[6] ←mavlink system.compid 14: buf[7] ←msgid&0xFF 15: buf[8] ←(msgid ≫8)&0xFF 16: buf[9] ←(msgid ≫16)&0xFF 17: 18: {*Cifrar packet con ChaCha20 y almacenar en encrypt} 19: encrypt ←xorOperation(key, counter, nonce, packet, length) 20: 21: status →current tx seq ++ 22: checksum ←crc calculate(buf, header len) 23: checksum ←crc accumulate buffer(packet, length) 24: checksum ←crc accumulate(crc extra) 25: ck[0] ←(uint8t)(checksum&0xF F) 26: ck[1] ←(uint8t)(checksum ≫8) 27: 28: MAV LINK START UART SEND(chan, header len + 3 + (uint16 t)length) 29: mavlink send uart(chan, (constchar∗)buf, header len + 1) 30: 31: {*Enviar encrypt por UART} 32: mavlink send uart(chan, (constchar∗)encrypt, length) 33: 34: mavlink send uart(chan, (constchar∗)ck, 2) 35: MAV LINK END UART SEND(chan, header len + 3 + (uint16 t)length) Lo primero que hay que mencionar es que, al inicio del archivo mavlink helpers.h tenemos que escribir la l´ınea #include “chacha20.h” para poder hacer uso de las funciones del algoritmo 60 de cifrado/descifrado. Luego, una vez identificado el punto exacto en el que se realiza el env´ıo de los mensajes MAVLink dentro de esta funci´on, la modificaci´on consiste, en pocas palabras, en reemplazar dicho paquete por su versi´on cifrada. De este modo, el paquete que se acaba enviando est´a cifrado utilizando la funci´on xorOperation del algoritmo ChaCha20 desarrollado. Mencionar que las l´ıneas modificadas han sido resaltadas con un asterisco (*) en el pseudo-c´odigo. Figura 27: Proceso de cifrado de un mensaje MAVLink Modificar la funci´on generate message h de mavgen c.py Esta funci´on escrita en Python se dedica principalmente a escribir texto dentro de las cabeceras C de los mensajes MAVLink que se van generando para un dialecto determinado. Por ello, 61 el c´odigo a modificar no es c´odigo escrito en C como tal, si no una cadena de texto que se corresponder´ıa con c´odigo C. No obstante, y por el bien de la claridad de la explicaci´on, se mostrar´a un pseudo-c´odigo gen´erico de lo que ser´ıa el resultado de haber generado las funciones correspondientes en dichas cabeceras de mensajes. Lo primero, y al igual que en mav finalize message chan send, hemos de incluir chacha20.h en el c´odigo, en este caso a˜nadiendo la l´ınea #include “../chacha20.h” al principio del c´odigo. Dicho esto, se tienen que hacer modificaciones en dos funciones: mavlink msg pack chan y mavlink msg decode. El cometido de la funci´on mavlink msg pack chan es empaquetar (o formatear) un mensaje espec´ıfico en un formato que puede ser enviado a trav´es de un canal MAVLink. El resultado es un paquete de datos que est´a listo para ser transmitido pero, a diferencia de mav finalize message chan send, esta funci´on no realiza el env´ıo del paquete. Algorithm 10 mavlink msg pack chan Require: system id: ID del sistema Require: component id: ID del componente Require: chan: Canal de MAVLink Require: msg: Mensaje MAVLink a empaquetar Require: valor1: Valores espec´ıficos de cada mensaje {As´ı con cada valor del mensaje espec´ıfico} 1: packet ←Estructura de mensaje 2: packet.campo1←valor1{As´ı con cada campo del mensaje espec´ıfico} 3: 4: {*Cifrar packet con ChaCha20 y almacenar en encrypt} 5: encrypt ←xorOperation(key, counter, nonce, packet, length) 6: 7: {*Copiar los datos del mensaje cifrado al paquete ‘msg’} 8: memcpy(MAV PAY LOAD NON CONST(msg), encrypt, LEN) 9: 10: msg.msgid ←MAV LINK MSG ID 11: return mavlink finalize message(msg, system id, component id, MIN LEN, LEN, CRC) En cuanto a mavlink msg decode, esta se utiliza para desempaquetar (o interpretar) un mensaje MAVLink recibido y almacenarlo en su estructura de datos correspondiente. Dando por hecho que los mensajes recibidos contendr´an datos cifrados de antemano (ver Figura 28), necesitaremos descifrarlos usando xorOperation. 62 Algorithm 11 mavlink msg decode Require: msg: Mensaje MAVLink a desempaquetar Require: packet: Estructura del paquete espec´ıfico a desempaquetar 1: length ←msg.len 2: packet encrypted ←MAV PAY LOAD(msg) 3: 4: {*Descifrar packet encrypted con ChaCha20 y almacenar en decrypt} 5: decrypt ←xorOperation(key, counter, nonce, packet encrypted, length) 6: 7: {*Copiar los datos del mensaje descifrado al paquete ‘packet’} 8: memcpy(packet, decrypt, length) Figura 28: Proceso de descifrado durante el desglose de un mensaje MAVLink 9.2.4. Reemplazar los m´odulos MAVLink de ArduPilot y QGroundControl por el MAVLink modificado Tras haber implementado el cifrado y descifrado de ChaCha20 en MAVLink, ha llegado el momento de reemplazar la librer´ıa MAVLink que usan tanto ArduPilot como QGroundControl para que la comunicaci´on entre ellos est´e cifrada de extremo a extremo. El modo en 63 que se realizar´a este reemplazo no es igual para un software y para el otro. En el caso de QGroundControl, basta con ejecutar el generador mavgenerate.py y especificarle que guarde la librer´ıa generada dentro de QGroundControl. Por otro lado, ArduPilot genera autom´aticamente la librer´ıa de c´odigo de su m´odulo MAVLink cada vez que se compila el proyecto, con que lo que tendremos que hacer es reemplazar estos archivos de c´odigo que hemos modificado previamente dentro del m´odulo MAVLink de ArduPilot. C´omo modificar el m´odulo MAVLink de QGroundControl Los pasos a seguir son los siguientes: 1. Ejecutar el generador mavgenerate.py que se encuentra dentro del repositorio de MA- VLink 2. Especificar como dialecto XML ardupilotmega.xml 3. Establecer la ruta de guardado de la librer´ıa a generar como “qgroundcontrol/libs/mavlink/include/mavlink/v2.0/” 4. Seleccionar como lenguaje C 5. Dar click en “generate” Despu´es de este sencillo proceso, podremos ver que la librer´ıa de MAVLink de QGroundControl ahora cuenta con las modificaciones. Por ´ultimo, habr´ıa que volver a compilar el proyecto QGroundControl para poder ejecutarlo y utilizarlo con estas nuevas caracter´ısticas (seguir los pasos descritos en el apartado de dise˜no). C´omo modificar el m´odulo MAVLink de ArduPilot Los pasos a seguir son los siguientes: 1. Localizar los archivos mavlink helpers.h,mavgen c.py ychacha20.h que han sido modificados y/o desarrollados 2. Copiarlos en sus respectivas rutas dentro del m´odulo MAVLink de ArduPilot, el cual se encuentra en “ardupilot/modules/mavlink/” Ahora, al volver a compilar el proyecto ArduPilot se generar´a su librer´ıa MAVLink contemplando las modificaciones de securizaci´on. Indicar que hay que volver a seguir los pasos descritos en el apartado de dise˜no para flashear este firmware modificado al autopiloto CubePilot 64 acuerdo al modelo de red C descrito en el apartado de dise˜no. Esto es, por un lado, el autopiloto estar´a directamente conectado a la Raspberry Pi y esta redirigir´a el tr´afico MAVLink al equipo que est´a ejecutando QGroundControl. Por otro lado, tendremos otro equipo que se encargar´a de interceptar la comunicaci´on y capturarla utilizando Wireshark. Todos los dispositivos est´an en la misma red. Figura 33: Sniffing de comunicaci´on MAVLink cifrada usando Wireshark En la Figura 34 puede verse que la ´unica informaci´on perceptible son las direcciones ip origen y destino y un hash no entendible al ojo humano que solo puede descifrarse utilizando la clave secreta de ChaCha20. En el desglose de una de las tramas puede verse que Wireshark ha reconocido que el paquete ha sido cifrado usando ChaCha20 expresamente, pero al no conocer la clave privada ni el nonce, no es capaz de descifrar los datos. 71 Figura 34: Desglose del mensaje cifrado con ChaCha20 interceptado con Wireshark Esto demuestra que no es posible ver el contenido de los paquetes MAVLink que son interceptados cuando se emplea el cifrado ChaCha20, velando as´ı por la confidencialidad de la informaci´on. 10.3. Impacto en el rendimiento Se han realizado mediciones del impacto a nivel computacional de la implementaci´on. Para ello, se ha escrito un script perf test.cpp de C++ (ver Figura 35) el cual realiza 1.000.000 empaquetamientos y desempaquetamientos de mensajes MAVLink (concretamente de mensajes heartbeat). La raz´on por la que se est´a midiendo el rendimiento en un script aislado es por que lo que nos interesa medir es tiempo de ejecuci´on cuando ejecutamos las funciones MAVLink antes y despu´es de implementar ChaCha20. El c´odigo luce tal que as´ı: 72 Figura 35: C´odigo sobre el que medir el impacto en CPU de la implementaci´on 10.3.1. Medir impacto en el rendimiento usando perf Para medir el tiempo de ejecuci´on se usar´a la herramienta perf de Linux, la cual es una herramienta muy vers´atil para analizar el rendimiento de programas. Se utiliza principalmente para tareas de profiling, que permiten a desarrolladores entender el estado de los recursos del sistema mientras se ejecuta un determinado programa. Para usar perf se seguir´an los siguientes pasos: 1. Instalar perf en el equipo con el comando sudo apt-get install linux-tools-common linux-tools-generic 2. Analizar el impacto en la CPU del script perf test.cpp desarrollado. Para ello, lanzar el comando perf stat ./perf-test.out una vez utilizando MAVLink sin modificar y otra vez utilizando MAVLink modificado Tras ejecutar el comando apuntando hacia el script sin y con las modificaciones de MAVLink, vemos que tiempo total necesario para ejecutar el script es mayor cuando se utiliza MAVLink 73 modificado (ver Tabla 13). Tiempo total ejecuci´on Tiempo ejecuci´on por operaci´on MAVLink por defecto 0.220393007 s Tiempo total / n´umero operaciones = 0.000000220 s MAVLink modificado 5.882865904 s Tiempo total / n´umero operaciones = 0.000005883 s Tabla 13: An´alisis de tiempo de ejecuci´on Hay una diferencia en el tiempo de ejecuci´on de unos cinco segundos entre el test que ha utilizado MAVLink por defecto y el que ha usado MAVLink con cifrado y descifrado Cha- Cha20. Sin embargo, esta medici´on se ha realizado tras ejecutar un mill´on de iteraciones. Si miramos la diferencia de tiempo que hay entre una operaci´on singular vemos que esta es casi imperceptible, concretamente de 0.000005663 segundos ´o 5.663 microsegundos (ver Figura 36). Figura 36: Impacto en la velocidad de ejecuci´on de una operaci´on de empaquetado / desempaquetado usando MAVLink por defecto y MAVLink con ChaCha20 Podemos entonces concluir que las modificaciones realizadas no tienen un impacto significativo a efectos pr´acticos en el rendimiento de la comunicaci´on. Por lo tanto, no se dar´a un excesivo estr´es computacional ni al CubeOrange ni a QGroundControl, que son los dos nodos de la comunicaci´on que utilizan MAVLink. 74 11. Conclusiones La motivaci´on de este trabajo ha sido desde el principio conocer en profundidad los diferentes protocolos de comunicaciones de UAVs con objeto de entender c´omo dotarlos de una capa de securizaci´on. Velando as´ı por la confidencialidad de la comunicaci´on que fluye entre un sistema a´ereo no tripulado y una estaci´on de control en tierra, y a la que s´olo los operadores de misiones de vuelo deber´ıan ser capaces de acceder. Se han valorado diversas opciones y tecnolog´ıas en cuanto a qu´e protocolo protagonizar´ıa este proyecto, y qu´e herramientas software y componentes hardware adicionales podr´ıan llegar a ser de utilidad para que el desarrollo concluyese de la forma m´as fruct´ıfera posible. Se ha visto que la selecci´on MAVLink/ArduPilot/QGroundControl/ChaCha20 era prometedora especialmente por la alta compatibilidad que existe entre dichas tecnolog´ıas y el inmenso soporte y comunidad que los respaldan. El esfuerzo de investigaci´on y an´alisis del software a modificar ha sido un ´exito, pues se ha logrado comprender como tanto MAVLink aisladamente como QGroundControl o ArduPilot gestionaban sus comunicaciones entrantes y salientes en este tipo de sistemas de comunicaci´on punto a punto. Gracias a ello, ha sido posible introducir diversas modificaciones de securizaci´on a diferentes niveles de abstracci´on en dichos softwares, dando cabida a un flujo de comunicaci´on cifrado de extremo a extremo que ofrece un buen compromiso rendimiento-seguridad con respecto al estado inicial del sistema que no contaba con ninguna medida de protecci´on. Es importante recalcar que, como MAVLink siempre formar´a parte de proyectos mayores (QGroundControl, ArduPilot, PX4, APM Planner, MAVProxy, etc.) es com´un toparse con decisiones de dise˜no propias de tales softwares que pueden a˜nadir complejidad a la forma en la que se desee realizar la modificaci´on en MAVLink. Es decir, que no podremos crear una ´unica versi´on modificada de la librer´ıa MAVLink que sea incluida por cualquier software y esperar que funcione sin ning´un problema. Estandarizar esto requerir´ıa de esfuerzos y equipos de desarrollo mayores. Finalmente, se han llevado a cabo pruebas de verificaci´on del buen funcionamiento de la comunicaci´on cifrada de forma satisfactoria. Se ha alcanzado el objetivo final de este proyecto, que es el de desarrollar medidas de seguridad avanzadas para la protecci´on de comunicaciones en UAVs, sin afectar perceptiblemente a su rendimiento. 75 12. Desarrollos futuros Como posibles futuros desarrollos ser´ıa interesante contemplar mejoras a nivel de c´odigo que permitan una integraci´on de esta versi´on de MAVLink modificada con un mayor nivel de abstracci´on del software que lo incluya. Adem´as, podr´ıa implementarse un sistema de distribuci´on de claves privadas ´unicas por cada nueva conexi´on, lo que har´ıa al sistema m´as robusto. Tambi´en podr´ıa valorarse el desarrollo de una interfaz de usuario sencilla que permita elegir entre diferentes algoritmos de cifrado o, directamente, si se desea o no utilizar cifrado de extremo a extremo en la comunicaci´on de una misi´on de vuelo concreta. Referencias [1] Propuesta para establecer reglas comunes para la operaci´on de drones en Europa. (2015, septiembre). EASA - European Union. enlace [2] DRONES - Prevenci´on de riesgos laborales y Seguridad Aeron´autica. (2023, noviembre). Instituto Nacional de Seguridad y Salud En el Trabajo. enlace [3] MAVLink Developer Guide. (2017, mayo). MAVLink. Recuperado 10 de febrero de 2024, de enlace [4] Anis Koubaa, Azza Allouch, Maram Alajlan & Yasir Javed Abdelfettah Belghith & Mohamed Khalgui. Micro Air Vehicle Link (MAVlink) in a Nutshell: A Survey. IEEE Access. PP. 1-1. 10.1109/ACCESS.2019.2924410. enlace [5] Joseph A. Marty. Vulnerability Analysis of the MAVLink Protocol for Command and Control of Unmanned Aircraft. Air Force Institute of Technology Wright-Patterson AFB, OH Graduate School of Engineering and Management. enlace [6] Azza Allouch, Omar Cheikhrouhou, Anis Koubaa, Mohamed Khalgui, Tarek Abbes. MAVSec: Securing the MAVLink Protocol for Ardupilot/PX4 Unmanned Aerial Systems. enlace [7] UAVCAN - Basic Concepts. (2017, agosto). UAVCAN V0 (Legacy). Recuperado 11 de febrero de 2023, de enlace 76 [8] Fadhila Tlili, Samiha Ayed, & Lamia Chaari Fourati. Dynamic Intrusion Detection Framework for UAVCAN Protocol Using AI. Association for Computing Machinery, New York, NY, USA, Article 120, 1–10. enlace [9] UAVCAN v1 is now Cyphal. (2022, March 25). OpenCyphal Forum. Recuperado 6 de marzo de 2024, de enlace [10] OMG Data Distribution Service (DDS). (2015, abril). OMG. enlace [11] What can DDS do for You? (2012, enero). OMG. enlace [12] Neil Puthuff (2020, octubre). ROS 2 + DDS Interoperation [V´ıdeo]. Real-Time Innovations. enlace [13] Florencia Cabral Berenfus. (2021, diciembre). Security vulnerabilities on the Data Distribution Service (DDS). Ubuntu Blog. Recuperado 15 de marzo de 2024, de enlace [14] OMG: DDS Security (DDS-SECURITY). (2021, octubre). DDS Foundation Wiki. Recuperado 15 de marzo de 2024, de enlace [15] Jinze Du, Chengtai Gao & Tao Feng. Formal Safety Assessment and Improvement of DDS Protocol for Industrial Data Distribution Service. Future Internet. 15. 24. 10.3390/fi15010024. enlace [16] ROS - Introduction. (2018, agosto). ROS. Recuperado 20 de febrero de 2024, de enlace [17] Manuel J. Fernandez, Pedro J. Sanchez-Cuevas, Guillermo Heredia & Anibal Ollero. Securing UAV communications using ROS with custom ECIES-based method. 2019 Workshop on Research, Education and Development of Unmanned Aerial Systems (RED UAS), Cranfield, UK, 2019, pp. 237-246, doi: 10.1109/REDUAS47371.2019.8999685. enlace [18] Hyojun Lee, Jiyoung Yoon, Min-Seong Jang & Kyung-Joon Park. A Robot Operating System Framework for Secure UAV Communications. Sensors 2021, 21, 1369. enlace [19] Enlace al repositorio de ArduPilot. enlace [20] Enlace a especificaciones de CubePilot CubeOrange. enlace [21] Enlace al repositorio de QGroundControl. enlace 77