Robotique
Cybersécurité robotique pour les robots ROS 2 et les drones
La cybersécurité robotique protège les logiciels, le firmware, les communications et le circuit de mise à jour d’un robot ou d’un drone contre les attaques qui pourraient exposer des données ou provoquer un comportement dangereux. Pour un robot ROS 2 ou un drone, cela signifie appliquer SROS 2 au trafic DDS, tenir à jour les correctifs du firmware de l’ordinateur compagnon et du contrôleur de vol, et suivre chaque paquet tiers que vous livrez.
Offre Free, sans carte bancaire.
Quelle est la surface d’attaque d’un robot ou d’un drone ?
Un robot moderne est un petit système distribué sur roues, sur pattes ou sous hélices : un contrôleur temps réel pour le mouvement et la sécurité, un ordinateur compagnon pour la perception et la connectivité, un middleware qui relie les processus, des liaisons radio et un mécanisme de mise à jour. Chaque couche apporte du code tiers, et chaque frontière entre deux couches est une interface qu’un attaquant peut tenter d’exploiter.
- Middleware : les nœuds ROS 2 échangent des messages via DDS. Sans sécurité activée, les participants ne sont pas authentifiés : tout ce qui se trouve sur le même réseau et le même domaine DDS peut lire les topics et publier des messages.
- Ordinateurs compagnons : généralement sous Linux, avec un noyau, des bibliothèques système, des services réseau et un accès à distance qui doivent tous recevoir des correctifs.
- Contrôleurs de vol : PX4 fonctionne principalement sur le système d’exploitation temps réel NuttX sur des cartes de contrôle de vol ; ArduPilot fonctionne sur ChibiOS sur des cartes à base de STM32 et prend aussi en charge des cartes sous Linux.
- Liaisons de télémétrie : MAVLink relie contrôleurs de vol, ordinateurs compagnons et stations sol. La signature des messages MAVLink 2 permet à un système de vérifier que les messages proviennent d’une source de confiance, mais elle ne les chiffre pas.
- Mises à jour à distance (OTA) : un canal de mise à jour non protégé permet à un attaquant d’installer du code malveillant sur toutes les unités.
- Paquets tiers : paquets ROS, bibliothèques Python et C++, images de conteneurs et pilotes de fournisseurs que vous n’avez pas écrits, mais que vous livrez.
Comment fonctionne la sécurité de ROS 2 (SROS 2) ?
La sécurité de ROS 2 s’appuie sur la spécification DDS-Security. La documentation de conception de ROS 2 décrit trois plugins utilisés : l’authentification de chaque participant par des certificats X.509 signés par une autorité de certification à laquelle vous faites confiance ; le contrôle d’accès, où des fichiers de gouvernance et de permissions signés définissent la façon dont le domaine est sécurisé et les topics que chaque participant peut lire ou écrire ; et un plugin cryptographique qui fournit un chiffrement authentifié avec AES-GCM. Le support d’exécution et les outils portent le nom de Secure ROS 2 (SROS 2), et les fichiers de sécurité sont organisés par enclave dans un keystore.
Le point qui compte le plus en pratique : par défaut, aucune de ces fonctions n’est activée. La sécurité s’active avec la variable d’environnement ROS_SECURITY_ENABLE et, sauf si ROS_SECURITY_STRATEGY vaut Enforce, un processus qui ne trouve pas ses fichiers de sécurité démarre sans sécurité au lieu d’échouer. Pour un produit, utilisez Enforce, gérez les autorités de certification et les clés privées comme n’importe quel autre secret de production, et revoyez les permissions à chaque ajout de nœud, pour qu’un pilote de caméra ne puisse pas publier de commandes de vitesse.
Sécurité du firmware des drones : contrôleurs de vol, ordinateurs compagnons et mises à jour
La sécurité du firmware d’un drone se découpe selon le matériel. Le contrôleur de vol exécute l’autopilote sur un microcontrôleur doté d’un système d’exploitation temps réel. L’ordinateur compagnon se rapproche d’un petit serveur, et communique avec le contrôleur de vol via MAVLink ou, avec PX4, également via uXRCE-DDS pour ROS 2. Traitez-les comme deux produits : chaînes de compilation, circuits de mise à jour et méthodes d’inventaire des composants diffèrent.
Pour les deux, les mesures sont connues. Connaissez les composants et les versions exacts de chaque build ; signez le firmware et vérifiez les signatures avant installation ; verrouillez les interfaces de débogage et les chargeurs d’amorçage ; et tenez un registre de la version de firmware qui tourne sur chaque cellule. Sur les liaisons radio, activez la signature des messages MAVLink 2 lorsqu’elle est prise en charge.
Le Cyber Resilience Act s’applique-t-il aux robots et aux drones ?
Le règlement sur la cyberrésilience (Cyber Resilience Act, CRA) s’applique aux produits comportant des éléments numériques mis à disposition sur le marché de l’UE dont la destination ou l’utilisation raisonnablement prévisible comprend une connexion de données directe ou indirecte à un appareil ou à un réseau. Un robot ou un drone doté d’une telle connexion relèvera généralement de cette définition, sauf exclusion applicable. Cela entraîne l’application des exigences essentielles de l’annexe I et de la gestion des vulnérabilités aux produits mis sur le marché à partir du 11 décembre 2027 et, depuis le 11 septembre 2026, l’obligation prévue à l’article 14 de notifier les vulnérabilités activement exploitées et les incidents graves. Le CRA ne s’applique pas aux produits certifiés conformément au règlement (UE) 2018/1139, le règlement de l’UE sur la sécurité de l’aviation civile : vérifiez donc la situation de chaque modèle de drone.
Les fabricants de robots rencontrent généralement une deuxième législation : le règlement (UE) 2023/1230 sur les machines, applicable à partir du 20 janvier 2027, qui comprend des exigences de sécurité relatives à la protection contre la corruption et à des systèmes de commande capables de résister aux tentatives malveillantes. Le considérant 53 du CRA indique que le respect du CRA pourrait faciliter le respect de ces exigences, mais c’est au fabricant de démontrer ce lien. Le règlement sur les machines exclut les moyens de transport par air, ainsi que les produits aéronautiques couverts par le règlement (UE) 2018/1139 dans la mesure où ce règlement couvre les exigences pertinentes : vérifiez donc comment ces deux exclusions s’appliquent à un drone.
Sécuriser les paquets ROS tiers et les dépendances
Les logiciels robotiques s’assemblent à partir d’écosystèmes : paquets ROS déclarés dans des fichiers package.xml, dépendances système résolues par des clés rosdep, dépôts sources récupérés avec des fichiers .repos de vcstool, bibliothèques Python et C++, et la distribution Linux sous-jacente. Le CRA exige une diligence raisonnable à l’égard des composants tiers, y compris open source (article 13, paragraphe 5), et un SBOM couvrant au moins les dépendances de niveau supérieur (annexe I, partie II). En pratique, vous devez savoir quelles versions se sont retrouvées dans l’image que vous avez livrée, et pas seulement celles que demandait l’espace de travail.
Étapes pratiques : fixez les versions dans les fichiers rosdep et .repos ; générez le SBOM à partir de l’image ou du conteneur construit, et pas seulement à partir des manifestes sources ; suivez les avis de sécurité de votre implémentation DDS et de votre distribution Linux ; surveillez la date de fin de vie de la distribution ROS 2 sur laquelle vous vous appuyez ; et donnez à chaque modèle de robot une période d’assistance et un circuit de mise à jour que vous pouvez réellement assurer pendant toute sa durée de vie.
Disponible aujourd’hui dans KROMSE
KROMSE couvre dès aujourd’hui plusieurs couches des logiciels d’un robot ; les données de vulnérabilités propres à la robotique figurent encore dans la feuille de route.
- Les manifestes de paquets ROS (package.xml, clés rosdep, fichiers .repos de vcstool) sont recensés dans l’inventaire ; la plupart ne sont pas encore rapprochés des avis de sécurité, sauf les composants fixés sur un commit ou un tag d’une forge publique, ou dotés d’un identifiant de paquet PyPI, npm, crates.io ou Go.
- Les dépendances des nœuds ROS sont confrontées à OSV.dev lorsqu’un lockfile ou un manifeste pris en charge existe, comme les fichiers pip requirements, Poetry ou uv pour Python. Les fichiers de build C++ comme CMake, Conan et vcpkg sont recensés, et le plus souvent pas encore rapprochés des avis de sécurité.
- Analyse du code source pour 11 langages, dont C, C++ et Python.
- Les images firmware Linux des ordinateurs compagnons, jusqu’à 512 Mo, sont extraites ; les paquets et les binaires sont vérifiés pour détecter des vulnérabilités connues, et le système de fichiers racine est aussi contrôlé pour détecter des erreurs de configuration et des secrets.
- Les fichiers .px4 de PX4 sont extraits de leur enveloppe et analysés comme les autres firmwares, mais les composants NuttX qu’ils contiennent ne sont pas encore identifiés.
- Les images de conteneurs d’un registre accessible depuis Internet, comme celles dans lesquelles s’exécutent vos nœuds ROS 2, sont analysées à la recherche de vulnérabilités, d’erreurs de configuration et de secrets.
Prochainement
Sur la feuille de route, pas encore disponible. Les dates sont des objectifs, pas des promesses ; cette page change le jour où une fonctionnalité est mise en service.
- À venir · T4 2026 (décembre)Sécurité de la robotique. KROMSE ajoutera les avis de sécurité ROS 2, l’identification des composants dans les firmwares PX4 et ArduPilot, et des données de vulnérabilités propres aux robots.
- À venir · T1 2027Firmware bare-metal et RTOS. KROMSE identifiera les composants des firmwares dépourvus de système de fichiers Linux, comme les images bare-metal et RTOS basées sur FreeRTOS ou Zephyr.
- À venir · T1 2027Preuves pour le règlement Machines. KROMSE rassemblera les preuves relatives aux exigences liées à la cybersécurité du règlement (UE) 2023/1230 sur les machines, à côté de votre dossier CRA.
Questions fréquentes
ROS 2 est-il sécurisé par défaut ?
Non. ROS 2 peut utiliser DDS-Security pour l’authentification, le contrôle d’accès et le chiffrement via SROS 2, mais la documentation de conception de ROS 2 indique qu’aucune de ces fonctions de sécurité n’est activée par défaut. Vous les activez avec ROS_SECURITY_ENABLE, et vous devriez régler ROS_SECURITY_STRATEGY sur Enforce pour qu’un nœud sans fichiers de sécurité valides refuse de démarrer au lieu de s’exécuter sans protection.
Qu’est-ce que SROS 2 ?
SROS 2, ou Secure ROS 2, est l’ensemble des fonctions et des outils qui exposent DDS-Security dans ROS 2. Il utilise des certificats X.509 pour l’authentification, des fichiers de gouvernance et de permissions signés pour le contrôle d’accès, et AES-GCM pour le chiffrement authentifié, avec des fichiers de sécurité stockés par enclave dans un keystore. La conception de ROS 2 décrit aussi un outil en ligne de commande, ros2 security, pour générer ces fichiers.
Le Cyber Resilience Act s’applique-t-il aux drones ?
C’est possible. Le CRA couvre les produits comportant des éléments numériques dotés d’une connexion de données à un appareil ou à un réseau, ce qui inclut de nombreux drones, mais il ne s’applique pas aux produits certifiés conformément au règlement (UE) 2018/1139, le règlement de l’UE sur la sécurité de l’aviation civile. L’exclusion d’un drone donné dépend de sa certification. KROMSE ne détermine pas si une législation s’applique : vérifiez la situation de chaque modèle.
KROMSE peut-il analyser un firmware PX4 ou ArduPilot ?
En partie. Les fichiers .px4 de PX4 sont extraits de leur enveloppe et analysés comme les autres firmwares, mais les composants NuttX qu’ils contiennent ne sont pas encore identifiés : le résultat est donc limité. Le firmware ArduPilot et les autres images bare-metal ou RTOS ne sont pas pris en charge aujourd’hui. Les images Linux d’ordinateurs compagnons jusqu’à 512 Mo sont extraites et analysées. L’identification des composants pour PX4 et ArduPilot figure dans la feuille de route.
Que doit préparer en priorité un fabricant de robots pour le CRA ?
Commencez par un inventaire : un SBOM pour chaque modèle de robot et chaque version de firmware publiés, couvrant l’ordinateur compagnon, le firmware du contrôleur et l’espace de travail ROS. Définissez ensuite une période d’assistance, un circuit de mise à jour signé que vous pouvez assurer pendant cette période, une politique de divulgation coordonnée des vulnérabilités avec une adresse de contact, et un processus pour notifier les vulnérabilités activement exploitées dans les 24 heures suivant leur prise de connaissance.
Guides associés
Sources
- Conception de ROS 2 : intégration de DDS-Security dans ROS 2
- Documentation ROS 2 : distributions en fin de vie
- Documentation PX4 : vue d’ensemble de l’architecture
- Documentation PX4 : ordinateurs compagnons
- Documentation développeur ArduPilot : introduction
- MAVLink : signature des messages
- Règlement (UE) 2024/2847 (règlement sur la cyberrésilience), EUR-Lex
- Règlement (UE) 2023/1230 (règlement sur les machines), EUR-Lex