Robotik
Robotik-Sicherheit für ROS-2-Roboter und Drohnen
Robotik-Sicherheit bedeutet, Software, Firmware, Kommunikation und Update-Pfad eines Roboters oder einer Drohne vor Angriffen zu schützen, die Daten offenlegen oder unsicheres Verhalten verursachen könnten. Für einen ROS-2-Roboter oder eine Drohne heißt das: SROS 2 für den DDS-Verkehr erzwingen, die Firmware von Companion-Computer und Flight-Controller auf aktuellem Patchstand halten und jedes Paket von Dritten nachverfolgen, das Sie ausliefern.
Free-Tarif, keine Kreditkarte erforderlich.
Wie sieht die Angriffsfläche eines Roboters oder einer Drohne aus?
Ein moderner Roboter ist ein kleines verteiltes System auf Rädern, Beinen oder Propellern: ein Echtzeit-Controller für Bewegung und funktionale Sicherheit, ein Companion-Computer für Wahrnehmung und Konnektivität, Middleware, die die Prozesse verbindet, Funkverbindungen und ein Update-Mechanismus. Jede Schicht bringt Code von Dritten mit, und jede Grenze zwischen Schichten ist eine Schnittstelle, die ein Angreifer auszunutzen versuchen kann.
- Middleware: ROS-2-Knoten tauschen Nachrichten über DDS aus. Ohne aktivierte Sicherheit werden Teilnehmer nicht authentifiziert, sodass alles im selben Netz und in derselben DDS-Domain Topics lesen und Nachrichten veröffentlichen kann.
- Companion-Computer: meist Linux, mit Kernel, Systembibliotheken, Netzwerkdiensten und Fernzugang, die alle gepatcht werden müssen.
- Flight-Controller: PX4 läuft auf Flugsteuerungsboards hauptsächlich auf dem Echtzeitbetriebssystem NuttX; ArduPilot läuft auf ChibiOS auf STM32-basierten Boards und unterstützt auch Linux-basierte Boards.
- Telemetrieverbindungen: MAVLink verbindet Flight-Controller, Companion-Computer und Bodenstationen. Die Nachrichtensignierung von MAVLink 2 lässt ein System prüfen, ob Nachrichten aus einer vertrauenswürdigen Quelle stammen, verschlüsselt sie aber nicht.
- Over-the-Air-Updates: Ein ungeschützter Update-Kanal erlaubt einem Angreifer, Schadcode auf jedem Gerät zu installieren.
- Pakete von Dritten: ROS-Pakete, Python- und C++-Bibliotheken, Container-Images und Herstellertreiber, die Sie nicht geschrieben haben, aber ausliefern.
Wie funktioniert die Sicherheit von ROS 2 (SROS 2)?
Die Sicherheit von ROS 2 baut auf der Spezifikation DDS-Security auf. Die Designdokumentation von ROS 2 beschreibt drei eingesetzte Plugins: Authentifizierung jedes Teilnehmers mit X.509-Zertifikaten, signiert von einer Zertifizierungsstelle, der Sie vertrauen; Zugriffskontrolle, bei der signierte Governance- und Berechtigungsdateien festlegen, wie die Domain gesichert wird und welche Topics jeder Teilnehmer lesen oder schreiben darf; und ein kryptografisches Plugin, das authentifizierte Verschlüsselung mit AES-GCM bereitstellt. Laufzeitunterstützung und Werkzeuge heißen Secure ROS 2 (SROS 2), und die Sicherheitsdateien werden pro Enklave in einem Keystore organisiert.
Das Detail, auf das es in der Praxis am meisten ankommt: Standardmäßig ist keine dieser Funktionen aktiviert. Sicherheit wird über die Umgebungsvariable ROS_SECURITY_ENABLE eingeschaltet, und solange ROS_SECURITY_STRATEGY nicht auf Enforce steht, startet ein Prozess, der seine Sicherheitsdateien nicht findet, ohne Sicherheit, statt mit einem Fehler abzubrechen. Nutzen Sie für ein Produkt Enforce, verwalten Sie Zertifizierungsstellen und private Schlüssel wie jedes andere Produktions-Secret, und prüfen Sie die Berechtigungen, wann immer Knoten hinzukommen, damit ein Kameratreiber keine Geschwindigkeitsbefehle veröffentlichen kann.
Sicherheit von Drohnen-Firmware: Flight-Controller, Companion-Computer und Updates
Die Sicherheit von Drohnen-Firmware teilt sich entlang der Hardware. Der Flight-Controller führt den Autopiloten auf einem Mikrocontroller mit Echtzeitbetriebssystem aus. Der Companion-Computer ähnelt eher einem kleinen Server und kommuniziert mit dem Flight-Controller über MAVLink oder, bei PX4, auch über uXRCE-DDS für ROS 2. Behandeln Sie beide als zwei Produkte: mit unterschiedlichen Toolchains, Update-Pfaden und Wegen, Komponenten aufzulisten.
Für beide sind die Maßnahmen vertraut. Kennen Sie die exakten Komponenten und Versionen jedes Builds; signieren Sie Firmware und prüfen Sie Signaturen vor der Installation; sichern Sie Debug-Schnittstellen und Bootloader ab; und halten Sie fest, welche Firmware-Version auf welchem Fluggerät läuft. Aktivieren Sie auf Funkverbindungen die Nachrichtensignierung von MAVLink 2, wo sie unterstützt wird.
Gilt der Cyber Resilience Act für Roboter und Drohnen?
Die Cyberresilienz-Verordnung (Cyber Resilience Act, CRA) gilt für Produkte mit digitalen Elementen, die auf dem EU-Markt bereitgestellt werden und deren Zweckbestimmung oder vernünftigerweise vorhersehbare Verwendung eine direkte oder indirekte Datenverbindung mit einem Gerät oder Netz einschließt. Ein Roboter oder eine Drohne mit einer solchen Verbindung fällt in der Regel unter diese Definition, sofern keine Ausnahme greift. Damit gelten für Produkte, die ab dem 11. Dezember 2027 in Verkehr gebracht werden, die grundlegenden Anforderungen aus Anhang I und die Behandlung von Schwachstellen sowie seit dem 11. September 2026 die Pflicht nach Artikel 14, aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle zu melden. Der CRA gilt nicht für Produkte, die nach der Verordnung (EU) 2018/1139, der EU-Verordnung zur Flugsicherheit, zertifiziert sind; prüfen Sie daher die Lage für jedes Drohnenmodell.
Robotikhersteller treffen meist auf ein zweites Gesetz: die Maschinenverordnung (EU) 2023/1230, die ab dem 20. Januar 2027 gilt und Sicherheitsanforderungen zum Schutz gegen Korrumpierung sowie an Steuerungen enthält, die böswilligen Versuchen standhalten. Nach Erwägungsgrund 53 des CRA könnte die Erfüllung des CRA die Einhaltung dieser Anforderungen erleichtern, den Zusammenhang muss der Hersteller aber nachweisen. Die Maschinenverordnung nimmt Beförderungsmittel für die Beförderung in der Luft aus, ebenso luftfahrttechnische Produkte, die unter die Verordnung (EU) 2018/1139 fallen, soweit diese die einschlägigen Anforderungen abdeckt; prüfen Sie also, wie beide Ausnahmen auf eine Drohne anzuwenden sind.
Pakete von Dritten in ROS und ihre Abhängigkeiten absichern
Robotersoftware wird aus Ökosystemen zusammengesetzt: ROS-Pakete, deklariert in package.xml, Systemabhängigkeiten, aufgelöst über rosdep-Keys, Quell-Repositories, eingebunden mit vcstool-.repos-Dateien, Python- und C++-Bibliotheken und darunter die Linux-Distribution. Der CRA verlangt die gebotene Sorgfalt bei Komponenten Dritter, auch quelloffenen (Artikel 13 Absatz 5), und eine SBOM, die mindestens die obersten Abhängigkeiten abdeckt (Anhang I Teil II). In der Praxis müssen Sie wissen, welche Versionen in dem Image gelandet sind, das Sie ausgeliefert haben, nicht nur, welche der Workspace angefordert hat.
Praktische Schritte: Versionen in rosdep- und .repos-Dateien festlegen; die SBOM aus dem gebauten Image oder Container erzeugen, nicht nur aus Quell-Manifesten; die Sicherheitshinweise Ihrer DDS-Implementierung und Ihrer Linux-Distribution verfolgen; das End-of-Life-Datum der ROS-2-Distribution im Blick behalten, auf der Sie aufbauen; und jedem Robotermodell einen Unterstützungszeitraum und einen Update-Pfad geben, den Sie über seine gesamte Lebensdauer tatsächlich liefern können.
Heute in KROMSE verfügbar
KROMSE deckt heute mehrere Schichten der Software eines Roboters ab; robotikspezifische Schwachstellendaten stehen noch auf der Roadmap.
- ROS-Paketmanifeste (package.xml, rosdep-Keys, vcstool-.repos-Dateien) werden im Inventar aufgeführt; die meisten werden noch nicht mit Sicherheitshinweisen abgeglichen, außer Komponenten, die auf einen Commit oder Tag auf einer öffentlichen Code-Hosting-Plattform festgelegt sind oder eine Paketkennung für PyPI, npm, crates.io oder Go haben.
- Abhängigkeiten von ROS-Knoten werden gegen OSV.dev geprüft, wo ein unterstütztes Lockfile oder Manifest vorhanden ist, etwa pip-Requirements, Poetry oder uv für Python. C++-Build-Dateien wie CMake, Conan und vcpkg werden aufgeführt und größtenteils noch nicht mit Sicherheitshinweisen abgeglichen.
- Quellcodeanalyse für 11 Sprachen, darunter C, C++ und Python.
- Linux-Firmware-Images für Companion-Computer bis 512 MB werden entpackt; Pakete und Binärdateien werden auf bekannte Schwachstellen geprüft, und das Root-Dateisystem wird zusätzlich auf Fehlkonfigurationen und Secrets geprüft.
- PX4-.px4-Dateien werden entpackt und wie andere Firmware gescannt, die darin enthaltenen NuttX-Komponenten werden aber noch nicht identifiziert.
- Container-Images in einer aus dem Internet erreichbaren Registry, etwa die Images, in denen Ihre ROS-2-Knoten laufen, werden auf Schwachstellen, Fehlkonfigurationen und Secrets analysiert.
Als Nächstes geplant
Auf der Roadmap, noch nicht verfügbar. Die Termine sind Zielmarken, keine Zusagen; diese Seite wird an dem Tag aktualisiert, an dem eine Funktion live geht.
- Geplant · Q4 2026 (Dezember)Robotik-Sicherheit. KROMSE wird ROS-2-Sicherheitshinweise, die Identifizierung von Komponenten in PX4- und ArduPilot-Firmware sowie robotikspezifische Schwachstellendaten ergänzen.
- Geplant · Q1 2027Bare-Metal- und RTOS-Firmware. KROMSE wird Komponenten in Firmware ohne Linux-Dateisystem identifizieren, etwa in Bare-Metal- und RTOS-Images auf Basis von FreeRTOS oder Zephyr.
- Geplant · Q1 2027Nachweise zur Maschinenverordnung. KROMSE wird Nachweise für die cybersicherheitsbezogenen Anforderungen der EU-Maschinenverordnung (EU) 2023/1230 sammeln, direkt neben Ihrer CRA-Dokumentation.
Häufige Fragen
Ist ROS 2 standardmäßig sicher?
Nein. ROS 2 kann über SROS 2 DDS-Security für Authentifizierung, Zugriffskontrolle und Verschlüsselung nutzen, aber die Designdokumentation von ROS 2 hält fest, dass keine dieser Sicherheitsfunktionen standardmäßig aktiviert ist. Sie aktivieren sie mit ROS_SECURITY_ENABLE und sollten ROS_SECURITY_STRATEGY auf Enforce setzen, damit ein Knoten ohne gültige Sicherheitsdateien nicht startet, statt ungeschützt zu laufen.
Was ist SROS 2?
SROS 2, kurz für Secure ROS 2, ist die Sammlung von Funktionen und Werkzeugen, die DDS-Security in ROS 2 verfügbar macht. Es nutzt X.509-Zertifikate für die Authentifizierung, signierte Governance- und Berechtigungsdateien für die Zugriffskontrolle und AES-GCM für authentifizierte Verschlüsselung; die Sicherheitsdateien liegen pro Enklave in einem Keystore. Das Design von ROS 2 beschreibt außerdem ein Kommandozeilenwerkzeug ros2 security, das diese Dateien erzeugt.
Gilt der Cyber Resilience Act für Drohnen?
Das kann sein. Der CRA erfasst Produkte mit digitalen Elementen, die eine Datenverbindung mit einem Gerät oder Netz haben, und damit viele Drohnen; er gilt aber nicht für Produkte, die nach der Verordnung (EU) 2018/1139, der EU-Verordnung zur Flugsicherheit, zertifiziert sind. Ob eine bestimmte Drohne ausgenommen ist, hängt von ihrer Zertifizierung ab. KROMSE entscheidet nicht, ob ein Gesetz anwendbar ist; klären Sie die Lage daher für jedes Modell.
Kann KROMSE PX4- oder ArduPilot-Firmware scannen?
Teilweise. PX4-.px4-Dateien werden entpackt und wie andere Firmware gescannt, die NuttX-Komponenten darin werden aber noch nicht identifiziert, das Ergebnis ist also begrenzt. ArduPilot-Firmware und andere Bare-Metal- oder RTOS-Images werden heute nicht unterstützt. Linux-basierte Images für Companion-Computer bis 512 MB werden entpackt und gescannt. Die Identifizierung von Komponenten für PX4 und ArduPilot steht auf der Roadmap.
Was sollte ein Roboterhersteller für den CRA zuerst vorbereiten?
Beginnen Sie mit einem Inventar: einer SBOM für jedes ausgelieferte Robotermodell und jede Firmware-Version, die den Companion-Computer, die Controller-Firmware und den ROS-Workspace abdeckt. Legen Sie dann einen Unterstützungszeitraum fest, einen signierten Update-Pfad, den Sie über diesen Zeitraum liefern können, eine Strategie für die koordinierte Offenlegung von Schwachstellen mit Kontaktadresse und einen Prozess, um aktiv ausgenutzte Schwachstellen innerhalb von 24 Stunden nach Kenntnisnahme zu melden.
Verwandte Leitfäden
Quellen
- ROS-2-Design: Integration von DDS-Security in ROS 2
- ROS-2-Dokumentation: Distributionen am Ende ihrer Lebensdauer (End-of-Life)
- PX4-Dokumentation: Architekturüberblick
- PX4-Dokumentation: Companion-Computer
- ArduPilot-Entwicklerdokumentation: Einführung
- MAVLink: Nachrichtensignierung
- Verordnung (EU) 2024/2847 (Cyberresilienz-Verordnung), EUR-Lex
- Verordnung (EU) 2023/1230 (Maschinenverordnung), EUR-Lex