Robótica
Ciberseguridad en robótica para robots ROS 2 y drones
La ciberseguridad en robótica protege el software, el firmware, las comunicaciones y el mecanismo de actualización de un robot o un dron frente a ataques que podrían exponer datos o provocar un comportamiento inseguro. En un robot ROS 2 o un dron, eso significa aplicar SROS 2 al tráfico DDS, mantener parcheado el firmware del ordenador de a bordo y del controlador de vuelo, y controlar cada paquete de terceros que distribuyes.
Plan gratuito, sin tarjeta.
¿Cuál es la superficie de ataque de un robot o un dron?
Un robot moderno es un pequeño sistema distribuido sobre ruedas, patas o hélices: un controlador en tiempo real para el movimiento y la seguridad, un ordenador de a bordo (companion computer) para la percepción y la conectividad, un middleware que conecta los procesos, enlaces de radio y un mecanismo de actualización. Cada capa aporta código de terceros, y cada frontera entre capas es una interfaz que un atacante puede intentar aprovechar.
- Middleware: los nodos de ROS 2 intercambian mensajes a través de DDS. Si la seguridad no está activada, los participantes no se autentican, así que cualquier cosa que esté en la misma red y el mismo dominio DDS puede leer topics y publicar mensajes.
- Ordenadores de a bordo: normalmente Linux, con un kernel, bibliotecas del sistema, servicios de red y acceso remoto que necesitan parches.
- Controladores de vuelo: PX4 funciona principalmente sobre el sistema operativo en tiempo real NuttX en placas de control de vuelo; ArduPilot funciona sobre ChibiOS en placas basadas en STM32 y también admite placas basadas en Linux.
- Enlaces de telemetría: MAVLink conecta controladores de vuelo, ordenadores de a bordo y estaciones de tierra. La firma de mensajes de MAVLink 2 permite a un sistema verificar que los mensajes proceden de una fuente de confianza, pero no los cifra.
- Actualizaciones inalámbricas (OTA): un canal de actualización sin protección permite a un atacante instalar código malicioso en todas las unidades.
- Paquetes de terceros: paquetes de ROS, bibliotecas de Python y C++, imágenes de contenedor y drivers de proveedores que no has escrito tú, pero que sí distribuyes.
¿Cómo funciona la seguridad de ROS 2 (SROS 2)?
La seguridad de ROS 2 se basa en la especificación DDS-Security. La documentación de diseño de ROS 2 describe tres plugins en uso: autenticación de cada participante con certificados X.509 firmados por una autoridad de certificación de confianza; control de acceso, en el que archivos firmados de gobernanza y de permisos definen cómo se protege el dominio y qué topics puede leer o escribir cada participante; y un plugin criptográfico que proporciona cifrado autenticado con AES-GCM. El soporte en tiempo de ejecución y las herramientas se denominan Secure ROS 2 (SROS 2), y los archivos de seguridad se organizan por enclave en un almacén de claves (keystore).
El detalle que más importa en la práctica: por defecto, ninguna de estas funciones está activada. La seguridad se activa con la variable de entorno ROS_SECURITY_ENABLE y, salvo que ROS_SECURITY_STRATEGY se configure como Enforce, un proceso que no encuentra sus archivos de seguridad arranca sin seguridad en lugar de fallar. En un producto, usa Enforce, gestiona las autoridades de certificación y las claves privadas como cualquier otro secreto de producción, y revisa los permisos cada vez que se añadan nodos, para que el driver de una cámara no pueda publicar comandos de velocidad.
Seguridad del firmware de drones: controladores de vuelo, ordenadores de a bordo y actualizaciones
La seguridad del firmware de drones se divide según el hardware. El controlador de vuelo ejecuta el piloto automático en un microcontrolador con un sistema operativo en tiempo real. El ordenador de a bordo se parece más a un pequeño servidor y se comunica con el controlador de vuelo mediante MAVLink o, con PX4, también mediante uXRCE-DDS para ROS 2. Trátalos como dos productos: cadenas de herramientas, vías de actualización y formas de enumerar componentes distintas.
En ambos, los controles son conocidos. Conoce los componentes y versiones exactos de cada build; firma el firmware y verifica las firmas antes de instalarlo; bloquea las interfaces de depuración y los bootloaders; y lleva un registro de qué versión de firmware ejecuta cada aeronave. En los enlaces de radio, activa la firma de mensajes de MAVLink 2 donde esté disponible.
¿Se aplica el Reglamento de Ciberresiliencia a robots y drones?
El Reglamento de Ciberresiliencia (Cyber Resilience Act, CRA) se aplica a los productos con elementos digitales comercializados en el mercado de la UE cuya finalidad prevista o uso razonablemente previsible incluya una conexión de datos directa o indirecta con un dispositivo o una red. Un robot o un dron con una conexión así suele entrar en esa definición, salvo que se aplique una exclusión. Eso conlleva los requisitos esenciales del anexo I y la gestión de las vulnerabilidades para los productos introducidos en el mercado a partir del 11 de diciembre de 2027 y, desde el 11 de septiembre de 2026, la obligación del artículo 14 de notificar las vulnerabilidades aprovechadas activamente y los incidentes graves. El CRA no se aplica a los productos certificados con arreglo al Reglamento (UE) 2018/1139, el reglamento de la UE sobre seguridad aérea, así que comprueba la situación de cada modelo de dron.
Los fabricantes de robots suelen toparse con una segunda norma: el Reglamento (UE) 2023/1230 relativo a las máquinas, que se aplica a partir del 20 de enero de 2027 e incluye requisitos esenciales de salud y seguridad sobre la protección contra la corrupción y sobre sistemas de mando capaces de resistir intentos hostiles. El considerando 53 del CRA indica que cumplir el CRA podría facilitar el cumplimiento de esos requisitos, pero el fabricante tiene que demostrar la relación. El Reglamento de Máquinas excluye los medios de transporte por aire, y los productos aeronáuticos incluidos en el Reglamento (UE) 2018/1139 en la medida en que este cubra los requisitos pertinentes, así que comprueba cómo se aplican ambas exclusiones a un dron.
Proteger los paquetes y dependencias de ROS de terceros
El software de un robot se ensambla a partir de ecosistemas: paquetes de ROS declarados en package.xml, dependencias del sistema resueltas mediante claves de rosdep, repositorios de código obtenidos con archivos .repos de vcstool, bibliotecas de Python y C++, y la distribución de Linux que hay debajo. El CRA exige diligencia debida con los componentes de terceros, incluidos los de código abierto (artículo 13(5)), y un SBOM que incluya, como mínimo, las dependencias de máximo nivel (anexo I, parte II). En la práctica, necesitas saber qué versiones acabaron en la imagen que distribuiste, no solo cuáles pedía el workspace.
Pasos prácticos: fija las versiones en los archivos de rosdep y .repos; genera el SBOM a partir de la imagen o el contenedor compilados, no solo de los manifiestos del código fuente; sigue los avisos de seguridad de tu implementación de DDS y de tu distribución de Linux; controla la fecha de fin de vida de la distribución de ROS 2 sobre la que construyes; y asigna a cada modelo de robot un período de soporte y una vía de actualización que puedas mantener de verdad durante toda su vida útil.
Disponible hoy en KROMSE
Hoy KROMSE cubre varias capas del software de un robot; los datos de vulnerabilidades específicos de robots siguen en la hoja de ruta.
- Los manifiestos de paquetes de ROS (package.xml, claves de rosdep, archivos .repos de vcstool) se enumeran en el inventario; la mayoría todavía no se contrasta con avisos, salvo los componentes fijados a un commit o una etiqueta en una forja pública o con un identificador de paquete de PyPI, npm, crates.io o Go.
- Las dependencias de los nodos de ROS se contrastan con OSV.dev cuando existe un lockfile o manifiesto compatible, como pip requirements, Poetry o uv para Python. Los archivos de compilación de C++, como CMake, Conan y vcpkg, se enumeran y, en su mayoría, todavía no se contrastan con avisos.
- Análisis de código fuente para 11 lenguajes, entre ellos C, C++ y Python.
- Las imágenes de firmware Linux para ordenadores de a bordo, de hasta 512 MB, se desempaquetan; los paquetes y los binarios se comprueban en busca de vulnerabilidades conocidas, y el sistema de archivos raíz también se revisa en busca de configuraciones incorrectas y secretos.
- Los archivos .px4 de PX4 se extraen de su envoltorio y se analizan como cualquier otro firmware, pero todavía no se identifican los componentes NuttX que contienen.
- Las imágenes de contenedor de un registro accesible desde internet, como las imágenes en las que se ejecutan tus nodos de ROS 2, se analizan en busca de vulnerabilidades, configuraciones incorrectas y secretos.
Próximamente
En la hoja de ruta, todavía no disponible. Las fechas son objetivos, no promesas; esta página cambia el mismo día en que una funcionalidad está operativa.
- Próximamente · T4 2026 (diciembre)Seguridad para robótica. KROMSE añadirá avisos de ROS 2, identificación de componentes dentro del firmware de PX4 y ArduPilot, y datos de vulnerabilidades específicos de robots.
- Próximamente · T1 2027Firmware bare-metal y RTOS. KROMSE identificará componentes en firmware sin sistema de archivos Linux, como imágenes bare-metal y RTOS basadas en FreeRTOS o Zephyr.
- Próximamente · T1 2027Evidencias para el Reglamento de Máquinas. KROMSE reunirá evidencias para los requisitos relacionados con la ciberseguridad del Reglamento (UE) 2023/1230 relativo a las máquinas, junto a tu expediente CRA.
Preguntas frecuentes
¿ROS 2 es seguro por defecto?
No. ROS 2 puede usar DDS-Security para autenticación, control de acceso y cifrado mediante SROS 2, pero la documentación de diseño de ROS 2 indica que ninguna de estas funciones de seguridad está activada por defecto. Se activan con ROS_SECURITY_ENABLE, y conviene configurar ROS_SECURITY_STRATEGY como Enforce para que un nodo sin archivos de seguridad válidos no arranque, en lugar de ejecutarse sin protección.
¿Qué es SROS 2?
SROS 2, o Secure ROS 2, es el conjunto de funciones y herramientas que exponen DDS-Security en ROS 2. Usa certificados X.509 para la autenticación, archivos firmados de gobernanza y de permisos para el control de acceso, y AES-GCM para el cifrado autenticado, con los archivos de seguridad almacenados por enclave en un almacén de claves. El diseño de ROS 2 también describe una herramienta de línea de comandos, ros2 security, para generar estos archivos.
¿Se aplica el Reglamento de Ciberresiliencia a los drones?
Puede aplicarse. El CRA abarca los productos con elementos digitales que tienen una conexión de datos con un dispositivo o una red, lo que incluye muchos drones, pero no se aplica a los productos certificados con arreglo al Reglamento (UE) 2018/1139, el reglamento de la UE sobre seguridad aérea. Que un dron concreto quede excluido depende de su certificación. KROMSE no decide si una norma se aplica, así que confirma la situación de cada modelo.
¿Puede KROMSE analizar firmware de PX4 o ArduPilot?
En parte. Los archivos .px4 de PX4 se extraen de su envoltorio y se analizan como cualquier otro firmware, pero todavía no se identifican los componentes NuttX que contienen, así que el resultado es limitado. El firmware de ArduPilot y otras imágenes bare-metal o RTOS no son compatibles hoy. Las imágenes de ordenadores de a bordo basadas en Linux de hasta 512 MB se desempaquetan y se analizan. La identificación de componentes de PX4 y ArduPilot está en la hoja de ruta.
¿Qué debería preparar primero un fabricante de robots para el CRA?
Empieza por un inventario: un SBOM por cada modelo de robot y versión de firmware publicados, que cubra el ordenador de a bordo, el firmware del controlador y el workspace de ROS. Después, fija un período de soporte, una vía de actualización firmada que puedas mantener durante ese período, una política de divulgación coordinada de vulnerabilidades con una dirección de contacto y un proceso para notificar las vulnerabilidades aprovechadas activamente en un plazo de 24 horas desde que tengas conocimiento de ellas.
Guías relacionadas
Fuentes
- Diseño de ROS 2: integración de DDS-Security en ROS 2
- Documentación de ROS 2: distribuciones al final de su vida útil
- Documentación de PX4: visión general de la arquitectura
- Documentación de PX4: ordenadores de a bordo (companion computers)
- Documentación para desarrolladores de ArduPilot: introducción
- MAVLink: firma de mensajes
- Reglamento (UE) 2024/2847 (Reglamento de Ciberresiliencia), EUR-Lex
- Reglamento (UE) 2023/1230 relativo a las máquinas, EUR-Lex