Der Cyber Resilience Act und sichere OTA-Updates für Embedded Linux

Kurz gesagt: Der EU Cyber Resilience Act macht aus „ausliefern und vergessen” ein Haftungsrisiko. Für ein vernetztes Embedded-Linux-Gerät bedeutet er vor allem eines — Sie müssen über Jahre signierte, überprüfbare Sicherheitsupdates ausliefern können, und genau das macht eine ausfallsichere OTA-Strecke, eine gesicherte Boot-Kette und eine aus dem Build erzeugte SBOM zum technischen Rückgrat der Konformität statt zu optionalem Beiwerk.

Vernetzte Industriegeräte wurden lange ausgeliefert und danach weitgehend sich selbst überlassen. Der Cyber Resilience Act (CRA) beendet dieses Modell: Er behandelt die Fähigkeit, Sicherheitsupdates zu empfangen und einzuspielen, als Eigenschaft des Produkts selbst. Dieser Beitrag betrachtet, was die Verordnung von einem Gerät mit digitalen Elementen verlangt und wie sich diese Pflichten auf einer Embedded-Linux-Plattform in konkrete technische Entscheidungen übersetzen — mit Over-the-Air-Updates (OTA) im Zentrum. Er beschreibt technische Maßnahmen, keine rechtlichen Pflichten: Wie der CRA auf ein konkretes Produkt anzuwenden ist, gehört in die Hand qualifizierter Rechtsberatung.

Was der Cyber Resilience Act von vernetzten Produkten verlangt

Der CRA ist eine EU-Verordnung für „Produkte mit digitalen Elementen” — im Kern jede Hard- oder Software, deren vorgesehene Nutzung eine Datenverbindung zu einem Gerät oder Netz umfasst, was die überwiegende Mehrheit vernetzter Industrie- und Embedded-Produkte einschließt. Statt eine bestimmte Technologie vorzuschreiben, formuliert er grundlegende Cybersicherheitsanforderungen: Produkte müssen von Haus aus sicher gestaltet sein, ohne bekannte ausnutzbare Schwachstellen bereitgestellt werden, Integrität und Vertraulichkeit von Code und Daten schützen und — entscheidend für langlebige Hardware — über einen definierten Unterstützungszeitraum Sicherheitsupdates erhalten. Hinzu kommen Prozesspflichten: ein koordinierter Umgang mit Schwachstellen und die Meldung aktiv ausgenutzter Schwachstellen innerhalb enger Fristen.

Die Verordnung wird nicht auf einen Schlag wirksam. Sie ist Ende 2024 in Kraft getreten, und ihre Pflichten greifen gestaffelt über die folgenden Jahre — die Meldepflichten für aktiv ausgenutzte Schwachstellen zuerst, die zentralen produktbezogenen Pflichten später, etwa 2027. Verstehen Sie konkrete Angaben hier als grobe Orientierung und klären Sie die genauen Termine und deren Anwendung auf Ihr Produkt mit Rechtsberatung. Technisch entscheidend ist: Diese Zeitpläne lassen weniger Spielraum, als es scheint, denn die Entscheidungen, die darüber bestimmen, ob ein Gerät sicher aktualisierbar ist — Partitionslayout, Boot-Kette, Schlüsselverwaltung —, fallen ganz am Anfang eines Plattformlebens und lassen sich nicht kurz vor einer Frist nachrüsten. Nochmals der Hinweis: Dies ist ein technischer Überblick, keine Rechtsberatung.

Von der Pflicht zur technischen Maßnahme

Den meisten grundlegenden Anforderungen des CRA steht auf einem Embedded-Linux-Stack ein direktes technisches Gegenstück gegenüber. Die folgende Zuordnung ist nicht abschließend, und das Erfüllen dieser Maßnahmen stellt für sich genommen keine Konformität her — sie zeigt aber, wo die Verordnung im Build ankommt.

CRA-Anforderung	Konkrete technische Maßnahme unter Embedded-Linux
Sicherheitsupdates über den Unterstützungszeitraum	Ausfallsichere A/B-OTA mit automatischem Rollback; signierte Update-Bundles; Delta-Updates
Integrität und Schutz vor Manipulation	Secure-Boot-Vertrauenskette; signierte Images; schreibgeschütztes dm-verity-Rootfs
Software-Stückliste (SBOM)	Aus dem Build erzeugte SBOM (SPDX über Yocto)
Umgang mit und Beheben von Schwachstellen	CVE-Überwachung gegen NVD-Daten; Backports auf LTS-Zweigen; reproduzierbarer Neubau und erneute Auslieferung
Sicher voreingestellt, minimale Angriffsfläche	Minimales, individuelles Image; keine ungenutzten Dienste; gehärtete Voreinstellungen
Nachvollziehbarkeit ausgelieferter Versionen	Reproduzierbare, gepinnte Builds; signierte, versionierte Release-Artefakte

Nichts davon ist exotisch; jede dieser Maßnahmen ist im langlebigen Embedded-Linux etablierte Praxis. Der Beitrag des CRA besteht darin, sie verbindlich zu machen und an einen in Jahren gemessenen Unterstützungszeitraum zu binden.

Die Update-Strecke wird zum tragenden Element

Muss ein Gerät über seinen gesamten Unterstützungszeitraum Sicherheitskorrekturen erhalten, ist der Update-Mechanismus keine Komfortfunktion mehr, sondern die Komponente, der sich der Rest des Entwurfs unterordnet. Ein einzelnes Image nach dem Muster „im Feld neu flashen” skaliert nicht auf eine Flotte und versagt spätestens dann, wenn ein Update durch einen Stromausfall unterbrochen wird. Die Anforderung lautet daher nicht nur „können wir ein neues Image einspielen”, sondern „können wir ein neues Image auf Tausende entfernte Geräte über unzuverlässige Netze einspielen, ohne je eines unbrauchbar zu machen”. Alles Weitere folgt aus diesem Satz. Genau so gehen wir die Embedded-Linux-Plattform an: Die Update-Strategie wird vom ersten BSP an mitgedacht, nicht nachträglich aufgesetzt.

Ausfallsichere OTA: A/B-Partitionierung, signierte Images, Delta-Updates

Die etablierte Antwort ist redundante A/B-Partitionierung: zwei Kopien des Root-Dateisystems, von denen jeweils nur eine aktiv ist. Ein Update wird in den inaktiven Slot geschrieben, während das Gerät aus dem aktiven weiterläuft; beim Neustart versucht der Bootloader den neuen Slot, und ein Watchdog oder Health-Check bestätigt den erfolgreichen Start. Bleibt die Bestätigung aus, fällt der Bootloader automatisch auf den bekannten guten Slot zurück. Ein fehlgeschlagenes oder unterbrochenes Update kostet einen Neustart, keinen Serviceeinsatz vor Ort.

Drei ausgereifte Frameworks setzen dieses Muster unter Embedded-Linux um: RAUC, SWUpdate und Mender. Alle unterstützen A/B-Slots, atomare Installation und — unter dem CRA unverzichtbar — kryptografische Signaturen auf dem Update-Artefakt, sodass ein Gerät nur ein mit dem Release-Schlüssel des Herstellers signiertes Image installiert. RAUC etwa beschreibt ein Update als signiertes Bundle mit einem Manifest:

# manifest.raucm — Inhalt eines signierten A/B-Update-Bundles
[update]
compatible=example-board-imx8
version=1.4.0

[bundle]
format=verity          # dm-verity-geschütztes, integritätsgeprüftes Bundle

[image.rootfs]
filename=rootfs.img

Das Bundle wird beim Bauen signiert, und das Gerät prüft diese Signatur gegen ein fest hinterlegtes Zertifikat, bevor es den inaktiven Slot überhaupt anfasst:

# Update-Bundle erzeugen und kryptografisch signieren
rauc bundle \
  --cert=release.cert.pem \
  --key=release.key.pem \
  input-dir/ update-1.4.0.raucb

Für Flotten an langsamen oder volumenbasierten Verbindungen übertragen Delta-Updates nur die geänderten Blöcke zwischen installiertem und neuem Image statt des vollständigen Rootfs — das senkt Bandbreite und Update-Dauer erheblich, was zählt, wenn eine Sicherheitskorrektur schnell jedes Gerät erreichen muss.

Secure Boot und eine lückenlose Vertrauenskette

Signierte Updates nutzen nur, wenn der prüfenden Instanz selbst vertraut werden kann. Genau das etabliert Secure Boot: eine lückenlose Kette, in der jede Stufe die nächste kryptografisch verifiziert. Das unveränderliche Boot-ROM des SoC prüft die Signatur des Bootloaders (anhand eines in OTP-Speicher gebrannten Schlüssel-Hashes), der Bootloader verifiziert Kernel und Device-Tree — typischerweise über ein signiertes U-Boot-FIT-Image —, und der Kernel bindet ein Rootfs ein, dessen Integrität sichergestellt ist, häufig ein schreibgeschütztes, mit dm-verity abgesichertes Dateisystem. Scheitert eine Stufe an der Prüfung, verweigert das Gerät die Ausführung manipulierten Codes.

Ein schreibgeschütztes Rootfs verdient eigene Erwähnung: Es erfüllt die Integritätserwartung und vereinfacht zugleich das Update-Modell, weil veränderlicher Zustand auf eine getrennte Datenpartition beschränkt bleibt. So bleiben die A/B-Slots bit-genau das, was der Release-Build erzeugt hat — und bit-genau das, was Ihre SBOM beschreibt.

SBOM und Schwachstellenmanagement über den Unterstützungszeitraum

Man kann nicht patchen, was man nicht sieht. Die Pflichten des CRA zum Umgang mit Schwachstellen setzen voraus, dass ein Hersteller genau weiß, welche Komponenten — und welche Versionen — in einem ausgelieferten Image stecken. Am zuverlässigsten gelingt das, indem man eine maschinenlesbare Software Bill of Materials (SBOM) direkt aus dem Build erzeugt, statt eine Liste von Hand zusammenzustellen. Ein Yocto-Build kann als Nebenprodukt der Image-Erstellung eine SBOM im SPDX-Format ausgeben, die jedes tatsächlich ausgelieferte Paket beschreibt. Diese Build-seitige Werkzeugkette vertiefen wir im Beitrag zu den Vorteilen von Yocto im industriellen Umfeld; sie ist zentraler Bestandteil unserer Yocto-BSP-Arbeit.

Die SBOM ist die Eingabe für das laufende Schwachstellenmanagement: den Komponentenstand gegen öffentliche CVE-Quellen abgleichen (Yoctos cve-check tut das beim Build gegen NVD-Daten), bewerten, was das Gerät tatsächlich betrifft, die Korrektur auf einem gepflegten LTS-Zweig rückportieren oder aktualisieren, reproduzierbar neu bauen und über die signierte OTA-Strecke ausliefern. Genau diese Schleife — erkennen, patchen, neu bauen, ausrollen — ist die Pflicht „Schwachstellen über den Unterstützungszeitraum behandeln” in technischer Sprache.

Einbettung in einen reproduzierbaren CI-Build mit verwalteten Signaturschlüsseln

All das trägt nur, wenn der Release-Build reproduzierbar ist und die Signaturschlüssel sauber verwaltet werden. Ein reproduzierbarer, gepinnter Build bedeutet, dass das ausgelieferte — und nach einem Patch erneut ausgelieferte — Image exakt jenes ist, das Sie getestet und in der SBOM beschrieben haben, ohne „läuft auf dem Build-Server”-Unschärfe. Die CI-Pipeline sollte bei jedem Release das signierte OTA-Bundle, die SBOM und einen CVE-Report als versionierte Artefakte erzeugen.

Den Signaturschlüsseln gebührt besondere Sorgfalt: Der private Schlüssel, der Updates autorisiert, ist faktisch der Generalschlüssel zur gesamten Flotte. Er gehört in ein Hardware-Sicherheitsmodul oder einen verwalteten Schlüsseldienst — niemals in den Quellbaum, niemals in ein Container-Image und niemals in das Home-Verzeichnis eines Entwicklers. Die CI signiert, indem sie eine Signatur von diesem Dienst anfordert, sodass der Schlüssel selbst nie auf einem Build-Runner landet. Diese Architektur früh richtig aufzusetzen, ist genau die Art von Frage, für die unsere technische Beratung da ist.

Fazit

Der Cyber Resilience Act verlangt von Embedded-Herstellern keine neue Technologie — er verlangt, Praktiken zu übernehmen und über Jahre durchzuhalten, die erfahrene Embedded-Linux-Teams längst kennen: ausfallsichere A/B-OTA mit signierten Images und automatischem Rollback, eine gesicherte Boot-Kette über einem schreibgeschützten Rootfs, eine aus dem Build erzeugte SBOM und eine disziplinierte, reproduzierbare CI, die Signaturschlüssel aus der Gefahrenzone hält. Kein einzelnes Setup „garantiert Konformität”, und die rechtliche Bewertung gehört zu qualifizierter Beratung — aber eine so gebaute Plattform hat die technischen Grundlagen bereits gelegt, statt kurz vor Wirksamwerden der Pflichten in Hektik zu verfallen.

Wenn Sie ein neues Gerät planen oder ein bestehendes auf diesen Stand bringen, nehmen Sie Kontakt auf, um Ihre Update- und Sicherheitsarchitektur zu besprechen.