Embedded Security für Gerätehersteller:
was vor der Hardware-Freigabe entschieden sein muss
Teil 1
Viele Angriffe auf Geräte brauchen keine unbekannte Lücke (Zero-Day). Sie nutzen Entscheidungen, die lange vor der Auslieferung gefallen sind.
Verfasst von Philipp Knaack, MSc | CTO, Danube Dynamics
ca. 23 Minuten Lesezeit
Am 29. Dezember 2025 wurden in Polen mehr als 30 Wind- und Photovoltaikparks, ein großes Heizkraftwerk und ein Fertigungsbetrieb angegriffen. Laut CERT Polska beschädigten die Angreifer die Firmware von Fernwirkstationen (RTUs), Schutzrelais und seriellen Geräteservern, löschten Systemdateien und setzten Geräte zurück (CERT Polska). Hinein kamen sie über VPN-Zugänge ohne Mehrfaktor-Authentisierung (MFA), auf vielen Geräten galten noch die Standard-Zugangsdaten (Help Net Security, The Hacker News).
Einen Zero-Day brauchte dafür niemand. Die Parks produzierten weiter Strom, verloren aber die Verbindung zum Verteilnetzbetreiber und damit Überwachung und Fernsteuerung. Im großen Heizkraftwerk sollte ein Wiper, Schadsoftware zum gezielten Löschen, die Daten auf den Rechnern im internen Netz unwiederbringlich vernichten. Gestoppt hat ihn laut CERT Polska die EDR-Software des Betreibers (Endpoint Detection and Response), die verdächtiges Verhalten auf Rechnern erkennt und blockiert. In einem kleineren Heizkraftwerk war die Kraft-Wärme-Kopplung laut Folgebericht vom August 2026 kurz unterbrochen (CERT Polska, Folgebericht). Um abgeflossene Daten geht es bei solchen Angriffen selten. Stillstand ist der eigentliche Schaden.
Das Wichtigste in Kürze:
- Die wichtigsten Security-Entscheidungen fallen vor der Hardware-Freigabe, danach kostet dieselbe Maßnahme oft eine Gerätegeneration.
- Ein abgeschottetes Netz ersetzt nicht, dass das Gerät selbst prüft, welche Firmware und welche Befehle es annimmt.
- Schlüssel pro Gerät und ein früh geplanter Schlüsseltausch begrenzen den Schaden eines Lecks auf ein Gerät statt auf die Serie.
- Secure Boot ist nur so stark wie die Signaturprüfung im Bootloader; den Vertrauensanker liefert der Prozessor oder ein externer Baustein vor ihm.
Was bei der Auslegung nicht berücksichtigt und deshalb nicht verbaut wurde, lässt sich im Feld kaum nachrüsten.
Abb. 1: Die Sicherheitskette einer Gerätegeneration. Die ersten drei Glieder bilden Security by Design, zwei davon liegen vor der Hardware-Freigabe.
Zielgruppe
Dieser Beitrag richtet sich an Gerätehersteller sowie Maschinen- und Anlagenbauer, die Linux-Geräte oder Mikrocontroller entwickeln. Er zeigt, welche Security-Fragen in welcher Reihenfolge zu beantworten sind: vom Schutzbedarf über die Chain of Trust bis zu den Schlüsseln und der Prüfung vor der Serie. Teil 2 behandelt das Gerät im Feld: Lieferkette, Schwachstellen und Bestandsgeräte.
Was heißt Security by Design bei einem Embedded-Gerät?
Im Kern ist Security by Design eine Frage der Reihenfolge: Die Sicherheitsarchitektur steht fest, bevor die Hardware freigegeben ist. Schutzziele, Anforderungen, Bauteile, Fertigung und Betrieb werden in dieser Folge entschieden. Was danach kommt, lässt sich nur innerhalb dessen ergänzen, was die Hardware hergibt. Das gilt für ein Linux-Gerät genauso wie für einen Mikrocontroller, nur die Sicherheitsfunktionen der Controller sind andere.
Vier Schritte, dazu Prozess und Auslieferungszustand
Schutzziele und Angriffsflächen festlegen
Sicherheitsanforderungen ableiten
Hardware danach auslegen
Fertigung und Betrieb einrichten
Zwei Punkte fallen dabei oft unter den Tisch. Der Entwicklungsprozess gehört dazu, weil viele Lücken ganz gewöhnliche Programmierfehler sind. Reviews, statische Analyse und risikobasiertes Testen sind Security-Maßnahmen. Und der Auslieferungszustand entscheidet, wie angreifbar ein Gerät am ersten Tag ist (Secure by Default: sichere Voreinstellungen ab Werk).
Hundertprozentige Sicherheit gibt es nicht.
Realistisch ist, einen Angriff so aufwendig zu machen, dass er sich nicht rechnet, mit mehreren Schichten, von denen jede die Schwäche einer anderen abfängt (Defense in Depth).
Der Cyber Resilience Act (CRA) schreibt diese Reihenfolge für alle Hersteller fest: Cybersicherheitsrisiken bewerten und das Ergebnis in Planung, Entwicklung, Fertigung und Wartung berücksichtigen [1]. Wer ohnehin so arbeitet, hat die Nachweise in den Entwicklungsunterlagen, statt sie später am fertigen Gerät zu rekonstruieren. Weitere Gesetze und Normen stehen in der FAQ.
Fragen, die sich das Team stellen muss
- Liegen die Sicherheitsanforderungen schriftlich vor, bevor die Hardware freigegeben wird?
- Wer entscheidet, auf welche Maßnahme bewusst verzichtet wird, und wo steht die Begründung?
- Welche Normen und Nachweise fordern Kunden und Zielmärkte?
[1] VO (EU) 2024/2847 (Cyber Resilience Act), Art. 13 Abs. 2 und Anhang I Teil I. EUR-Lex
Wogegen muss ein Embedded-Gerät geschützt werden, und wo ist es angreifbar?
Schutzziele und Angriffsflächen festzulegen ist der erste Schritt, und er bestimmt alle weiteren. Ohne festgelegte Schutzziele werden Maßnahmen entweder zu teuer oder zu schwach. Die Angriffsflächen machen sie konkret: Erst wer weiß, wo ein Gerät angreifbar ist, kann entscheiden, wie viel Schutz an welcher Stelle nötig ist. Am Ende stehen dokumentierte Anforderungen und ein bewusst akzeptiertes Restrisiko.
Schutzziele und Schutzbedarf festlegen
Klassisch sind Integrität, Vertraulichkeit und Verfügbarkeit.
Bei Embedded-Geräten kommen Know-how und Lizenzen dazu, weil der Wert oft in Firmware, Algorithmen oder einem KI-Modell steckt. Am meisten klärt die Frage nach dem schlechtesten Fall: Steht dann eine Anlage, sind Personen gefährdet, droht Nachbau oder ein Rückruf?
Wie viel Aufwand ein Angreifer treiben wird, lässt sich mit den Security Levels der IEC 62443 einordnen.
Von Level 1 gegen zufällige Fehlbedienung bis Level 4 gegen hoch motivierte Angreifer mit erweiterten Ressourcen (Übersicht IEC 62443). Ab Level 3 kommen Angriffe wie Glitching in Betracht, also gezielte Störungen von Spannung oder Takt, um eine Prüfung zu überspringen. Dagegen helfen vor allem Controller mit eingebauten Schutzfunktionen, etwa einer Überwachung von Spannung und Takt.
Der Schutzbedarf sagt auch, was man sich sparen kann. Eine Maßnahme, die das Schutzziel nicht voranbringt, kostet Startzeit, Bauteile oder Debug-Möglichkeiten und bringt nichts. Reichen die richtig aktivierten Sicherheitsfunktionen des SoC für den Schutzbedarf, ist das ein Ergebnis und kein Versäumnis.
Fünf Ebenen, an denen Angreifer ansetzen
Tabelle 1 ordnet reale Vorfälle der letzten Jahre fünf Ebenen zu. In jedem Fall stand eine davon schlicht offen.
| Ebene | typischer Fehler | Beispiel | Gegenmaßnahme |
|---|---|---|---|
| Physisch | Debug offen, ROM-Bootloader von außen auslösbar | Fusée Gelée (2018): Fehler im Boot-ROM des NVIDIA Tegra X1, per Update nicht behebbar | Debug per Fuse sperren, ROM-Bootloader deaktivieren |
| Boot | fremde Firmware startet | Cisco ASA 5500-X (2025): Bootkit ohne Secure Boot | Chain of Trust |
| Betriebssystem, Dienste | Standardzugang, offene Dienste | Kimwolf (Android-Debug-Zugang ADB ab Werk offen), CVE-2025-7503 (fest codiertes Telnet-Passwort) | Secure by Default, Härtung |
| Kommunikation | Replay, Man-in-the-Middle, nicht signierte Updates | Hoymiles-Wechselrichter: Firmware-Updates per Funk ohne Authentifizierung | gegenseitige Authentifizierung, signierte Updates |
| Build, Lieferkette | Schadcode im Build | Keenadu (2026): Backdoor in Tablet-Firmware, vermutlich über kompromittierte Entwicklerwerkzeuge eingeschleust | Build-Sicherheit, SBOM |
Tab. 1: Angriffsebenen mit Beispiel und Gegenmaßnahme. Quellen: BleepingComputer, The Hacker News, Krebs on Security, GitHub Advisory, CCC, Risky Bulletin
Sechs Regeln für den Auslieferungszustand
Secure by Default heißt konkret: Sobald ein Gerät das Labor verlässt, gelten feste Regeln, auch für Pilot- und Testgeräte.
Wie schnell offene Zugänge gefunden werden, zeigt Kimwolf aus Tab. 1. Laut Krebs on Security umfasste das Botnetz rund zwei Millionen Geräte, viele davon über einen ab Werk offenen Debug-Zugang erreichbar (Krebs on Security). Die sechs Regeln:
- Kein Entwicklungs-Image außerhalb des Labors.
- Keine Standardpasswörter. Zugangsdaten je Gerät oder Vergabe bei der Inbetriebnahme.
- Debug im Seriengerät dauerhaft gesperrt. Per Fuse oder SoC-Konfiguration, auch ohne bestückten Stecker.
- Nur benötigte Dienste. Was nicht läuft, muss nicht gepatcht werden.
- Read-only RootFS im Seriengerät. Änderungen nur über den definierten Update-Weg.
- Fernzugriff nur geräteinitiiert und authentisiert. Das Gerät baut die Verbindung selbst auf, im Kundennetz bleiben eingehende Ports zu.
„Unser Gerät hängt im abgeschotteten Netz, da kann nichts passieren.”
Der Satz fällt in Projektgesprächen regelmäßig und greift zu kurz, weil die Annahme selten hält und nichts über das Gerät selbst aussagt.
In Polen war das Leitsystemnetz über VPN ohne MFA erreichbar, der Folgebericht beschreibt zusätzlich einen privaten Mobilfunkzugang (APN), über den sich alle angeschlossenen Geräte gegenseitig erreichen konnten, laut CERT Polska eine verbreitete Fehlkonfiguration. Stuxnet gelangte 2010 in die abgeschottete Anlage in Natanz laut ETH Zürich höchstwahrscheinlich per USB-Stick (CSS ETH Zürich). Beim Satellitennetz KA-SAT von Viasat war am 24. Februar 2022 ein als vertrauenswürdig geltendes Managementnetz das Problem: Laut Viasat löschten die Angreifer nach dem Einstieg über einen fehlkonfigurierten VPN-Zugang Modems mit regulären Managementbefehlen, fast 30.000 wurden ersetzt (BleepingComputer). Rund 5.800 Windenergieanlagen von Enercon, die über KA-SAT angebunden waren, verloren laut pv magazine die Fernüberwachung und liefen blind weiter (pv magazine).
Isolation ist eine Annahme über das Netz des Betreibers. Ob ein Gerät manipulierte Firmware startet, ist eine Eigenschaft des Geräts.
Im IT-Umfeld heißt diese Lehre Zero Trust: kein Vertrauen allein aufgrund des Netzwerkstandorts (NIST SP 800-207). Im Gerät bedeutet das eigene Identität, gegenseitige Authentisierung und minimale Rechte, auf einem kleinen Mikrocontroller ohne Netz naturgemäß nur zum Teil. Segmentierung, also die Trennung von Netzen, hat trotzdem ihren Platz. Ihre stärkste Form ist die Datendiode, ein unidirektionales Gateway ohne physikalischen Rückweg (NIST SP 800-82 Rev. 3). Der Preis: Updates und Fernwartung brauchen einen Weg ins Gerät, und gegen den USB-Stick des Servicetechnikers hilft auch die Diode nicht. Für Hersteller von Edge-Geräten und Gateways ist sie eine Architekturentscheidung mit Folgen für den Update-Weg.
Fragen, die sich das Team stellen muss
- Was soll geschützt werden: Funktion, Daten, Know-how oder der Zugang zum Netz dahinter?
- Welche Schnittstellen sind nach der Fertigung noch erreichbar: am Gerät, über Netzwerk oder über Funk?
- Bleibt das Gerät über seine gesamte Laufzeit ohne Verbindung, auch bei Service und Updates?
Welche Hardware braucht eine Chain of Trust, und was schützt das Gerät nach dem Start?
Eine Chain of Trust braucht einen Vertrauensanker, den niemand verändern kann, und der sitzt im Prozessor. Das Boot-ROM prüft den Bootloader gegen einen Schlüssel-Hash in den Fuses, danach prüft jede Stufe die nächste. Fehlt der Anker im gewählten Controller, bleibt nur ein externer Baustein vor dem Prozessor, eine Entscheidung auf der Leiterplatte. Nach dem Start übernehmen Kommunikationsschutz und Härtung.
Aus Schutzzielen werden Anforderungen an Bauteile
Im zweiten und dritten Schritt werden aus Schutzzielen Anforderungen und aus Anforderungen Bauteile.
- Welches Schlüsselmaterial muss aufs Gerät, und muss es physischem Zugriff standhalten?
- Über welchen Weg kommen Updates, und was muss am Ende nachweisbar sein?
Jede Antwort grenzt die Auswahl an Controllern ein, deshalb gehören diese Fragen vor die Hardware-Freigabe.
Jede Stufe prüft die nächste
Auf einem Linux-Gerät prüft das Boot-ROM den Bootloader gegen den Hash des öffentlichen Schlüssels in den eFuses, der Bootloader prüft Kernel und Device Tree, der Kernel prüft das Root-Dateisystem über dm-verity und die Applikation kommt nur als signierter Softwarestand aufs Gerät. Auf dem Mikrocontroller ist die Kette kürzer, die Logik gleich: Ein unveränderlicher Bootbereich prüft einen Bootloader wie MCUboot, der prüft die Applikation (MCUboot).
Ein TPM oder Secure Element bringt kein Secure Boot, die erste Prüfung macht das Boot-ROM.
Solche Bausteine übernehmen die andere Hälfte: Geheimnisse ablegen, Krypto-Operationen ausführen, Identität nachweisen. Das ist ihr Grundgedanke: Die privaten Schlüssel liegen auf einem minimalen, hochsicheren System und verlassen es nie. Der Bus zwischen SoC und Baustein muss trotzdem selbst abgesichert sein, sonst lässt er sich auf der Leiterplatte mitlesen oder manipulieren.
Fehlt der Anker im Prozessor, gibt es einen Ausweg: einen externen Baustein, der den Flash prüft, bevor der Prozessor startet. Im Serverumfeld heißt das Platform Firmware Resilience (NIST SP 800-193), Bausteine wie der Lattice MachXO3D sind dafür ausgelegt (Lattice). Das kostet Platz, Bauteile und Entwicklungsaufwand, ist für die nächste Generation eines Bestandsgeräts aber eine realistische Option.
Signieren und Verschlüsseln ersetzen sich nicht.
Für die Signaturprüfung braucht das Gerät kein Geheimnis, nur einen öffentlichen Schlüssel, der sich nicht austauschen lässt. Für die Entschlüsselung muss ein Geheimnis ins Gerät, das sich nicht auslesen lässt. Wer Verschlüsselung erst nach der Hardware-Freigabe beschließt, stellt oft fest, dass die Hardware keinen solchen Speicher hat.
| Signieren | Verschlüsseln | |
|---|---|---|
| Schutzziel | Integrität und Herkunft | Vertraulichkeit |
| Verhindert | Start manipulierter oder fremder Firmware | Lesen und Analysieren der Firmware |
| Leistet nicht | Schutz vor Auslesen und Nachbau | Nachweis von Herkunft und Unversehrtheit |
| Was im Gerät liegen muss | öffentlicher Schlüssel oder dessen Hash, nicht geheim | geheimer Schlüssel, nicht auslesbar |
| Typischer Anlass | jedes vernetzte oder updatefähige Gerät | Algorithmus, KI-Modell, Nachbauschutz |
Tab. 2: Signieren und Verschlüsseln im Vergleich.
Das schwächste Glied ist oft die Signaturprüfung selbst
Binarly veröffentlichte im Juli 2026 sechs Schwachstellen in der Signaturprüfung von FIT-Images in U-Boot (Binarly). Zwei erlauben Codeausführung, weil der FIT-Parser das Image auswertet, bevor die Signaturprüfung abgeschlossen ist; der betroffene Code steckt seit v2013.07 in U-Boot (techveda). Eine CVE gibt es nicht, die Funde laufen als BRLY-2026-037 bis -042. Ein stabiles Release mit Fix fehlte laut The Hacker News noch, v2026.10 ist für Oktober angekündigt (The Hacker News, abgerufen am 24.09.2026). Ganz ohne Secure Boot wird es schlimmer: Auf Cisco-Firewalls der Reihe ASA 5500-X überstand 2025 ein Bootkit Neustarts und Software-Upgrades (The Hacker News).
Abb. 2: Jede Stufe prüft die nächste. Kritisch ist der Bootloader, wenn er das Image auswertet, bevor die Prüfung abgeschlossen ist
Hardware nach den Anforderungen auslegen
In der Auswahl zählen wenige, harte Kriterien: Boot-ROM mit Signaturprüfung, Fuses für den Anker, mehrere Schlüsselplätze mit Sperrmöglichkeit, Flash für zwei Firmware-Slots samt Bootloader, passende Krypto-Beschleunigung, Platz für ein Secure Element und ein dauerhaft sperrbarer Debug-Zugang. Dazu kommt eine oft vergessene Reserve: eine Schnittstelle für ein späteres Sicherheitsmodul. Damit lässt sich eine Sicherheitsfunktion auch nach der Hardware-Freigabe noch ergänzen. Eine neue Gerätegeneration ist das fast immer, die Hardware muss dafür aber nicht neu entwickelt werden (Beispiel im Praxisteil).
Ein nicht bestückter Debug-Stecker ist eine Hürde und kein Schutz. Erreichbar bleibt die Schnittstelle über Testpunkte, Vias oder freigelegte Leiterbahnen. Schutz bietet nur die dauerhafte Sperre per Fuse.
Die Kehrseite: eFuses sind irreversibel, ein falsch gebrannter Hash führt dazu, dass Geräte keine neue Firmware mehr annehmen. Die Verifikation verlängert den Start, ein gesperrter Debug-Zugang erschwert die Fehleranalyse an Rückläufern, und nicht jeder Mikrocontroller hat Hardware-Krypto für die gewünschten Verfahren. Planen lässt sich das gut. Teuer wird es erst, wenn es in der Serie auffällt.
Nach dem Start: Kommunikation und Härtung
Den Start schützt die Chain of Trust. Den Betrieb nicht.
Gerät und Gegenstelle authentisieren sich gegenseitig mit der Geräteidentität aus dem Provisioning in der Fertigung (nächster Abschnitt). Verbindungen sind verschlüsselt und integritätsgeschützt, Sequenzzähler verhindern Replay, Updates und Steuerbefehle nimmt das Gerät nur signiert an.
Im System gilt Least Privilege:
Dienste und Applikation laufen getrennt, ohne root und nur mit den Rechten, die sie brauchen. Nach außen sind nur die Schnittstellen offen, die der Betrieb erfordert. Auf dem Mikrocontroller übernehmen Speicherschutz und Isolation diese Rolle, soweit der Controller sie bietet. Das ist Zero Trust im Gerät. Ob die Geräte in Polen oder bei KA-SAT damit anders reagiert hätten, lässt sich von außen nicht beurteilen.
Begrenzte Rechte haben dabei eine Grenze:
Gegen einen legitimen Befehl wie „auf Werkseinstellungen zurücksetzen“ helfen sie nicht, sonst wäre auch der legitime Einsatz blockiert. Entscheidend ist dann, dass das Gerät solche Befehle nur von einer authentisierten Gegenstelle annimmt und nicht deshalb, weil sie aus dem vermeintlich richtigen Netz kommen.
Fragen, die sich das Team stellen muss
- Prüft der Controller beim Start die Signatur des Bootloaders, und sieht er mehrere Schlüssel vor, von denen einzelne gesperrt werden können?
- Gibt es einen Speicherort für Schlüssel, der sich auch bei physischem Zugriff nicht auslesen lässt?
- Lässt sich auch der Bootloader im Feld sicher aktualisieren?
Wie kommen Schlüssel sicher ins Gerät, und was muss vor der Serie geprüft sein?
Die Schlüsselverwaltung entscheidet, ob ein kompromittierter Schlüssel ein einzelnes Gerät trifft oder die ganze Serie, und ob ein Gerät nach zehn Jahren noch Updates annimmt. Das ist der vierte Schritt von Security by Design. Er umfasst Schlüsselhierarchie und Provisioning in der Fertigung und endet mit der Prüfung vor der Serie. Tausch, Sperrung und Ablauf im Feld behandelt Teil 2.
Schlüsselhierarchie und Provisioning in der Fertigung
Der Root-Schlüssel liegt offline in einem Hardware-Sicherheitsmodul (HSM), darunter Zwischenzertifikate und Signierschlüssel, Freigaben laufen im Vier-Augen-Prinzip. Was ein eigener Schlüssel je Gerät bringt, zeigt ein Beispiel: 20.000 Geräte authentisieren sich am Server des Herstellers, aus einem einzigen wird der Schlüssel extrahiert.
| Ein Schlüssel für die Serie | Ein Schlüssel pro Gerät | |
|---|---|---|
| Geräte, als die sich der Angreifer ausgeben kann | 20.000 | 1 |
| Geräte, die beim Sperren ihren Zugang verlieren | 20.000 | 1 |
| Zusätzlicher Aufwand | keiner | einmalig ca. 2 Personenmonate Tooling, dazu Provisioning-Aufwand je Gerät, der sich größtenteils automatisieren lässt |
| Zusätzliche Voraussetzung | keine | Verfahren für Erzeugung, Zuordnung und Sperrung je Gerät |
Tab. 3: Beispiel mit angenommener Seriengröße. Der Tooling-Aufwand stammt aus eigener Projekterfahrung und fällt einmal für die Serie an, unabhängig von ihrer Größe.
Einen sicheren Schlüsselspeicher im SoC oder Secure Element brauchen beide Varianten.
Der Schlüssel pro Gerät ist teurer in der Entwicklung und billiger im Ernstfall. Was er schützt, sind Identität und Zugang, nicht automatisch das Know-how: Ist das Image überall mit demselben Schlüssel verschlüsselt, genügt ein geknacktes Gerät. Eingebracht werden die Schlüssel über vorprovisionierte Secure Elements oder per Injektion beim EMS-Partner, dem Fertigungsdienstleister. In beiden Fällen wird die Fertigung Teil der Vertrauenskette, und es muss geklärt sein, wer einen Schlüssel je im Klartext sieht. Wie teuer Nachlässigkeit wird, zeigte PKfail: Test-Schlüssel für UEFI Secure Boot (Platform Keys) mit dem Vermerk „DO NOT TRUST” steckten laut BleepingComputer in 813 Produkten von 10 Herstellern, in Firmware von 2012 bis 2024 (BleepingComputer, CERT/CC).
Abb. 3: Schlüssel von der Erzeugung bis zum Ablauf. Ein Serienschlüssel macht aus einem Leck einen Serienschaden.
Wie wird vor der Serie nachgewiesen, dass die Anforderungen erfüllt sind?
Zuerst gleicht ein Architektur-Review das Design gegen die Bedrohungsanalyse aus dem ersten Schritt ab. Statische Analyse, Fuzzing der Schnittstellen und ein Penetrationstest am Seriengerät prüfen die Umsetzung, die sechs Regeln für den Auslieferungszustand bilden die letzte Kontrolle. Was offen bleibt, geht ins dokumentierte Restrisiko ein. Im selben Schritt wird der Betrieb vorbereitet: Update-Weg, Supportzeitraum und wer Schwachstellen beobachtet, entscheidet und den Fix liefert (mehr dazu in Teil 2).
Fragen, die sich das Team stellen muss
- Wer erzeugt die Schlüssel, und wer hat Zugriff auf den privaten Teil?
- Wie kommt ein neuer Schlüssel auf ein Gerät im Feld, auch nach langer Offline-Zeit?
- Passt die Gültigkeit der Zertifikate zur geplanten Einsatzdauer des Geräts?
Aus der Praxis
Bei voidsy stand der Schutz von Know-how im Mittelpunkt. Das Unternehmen entwickelt bildgebende Prüfsysteme für die zerstörungsfreie Analyse von Faserverbundwerkstoffen, und der Wert steckt in der Software. Umgesetzt wurde deshalb Schutz vor Reverse Engineering und Manipulation:
- Tamper Detection, die bei einem Eingriff ein Signal an die Security-Software auslöst,
- verschlüsselte Firmware,
- Code Obfuscation,
- robuste Authentisierung
- und Secure Boot.
Das Wissen dazu ging an das Team von voidsy über.
Ein zweiter Punkt aus dem Projekt zeigt, was eine vorgesehene Schnittstelle wert ist. Eine Sicherheitsfunktion wurde nach der Hardware-Freigabe über ein zusätzlich eingebautes Hardware-Modul ergänzt. Formal war das eine neue Gerätegeneration, weil die Schnittstelle aber vorgesehen war, musste die Hardware dafür nicht neu entwickelt werden. Für Geräte, die bereits beim Kunden standen, galt das nicht.
Merksatz:
Die frühe Entscheidung schafft die spätere Option, aber nur für die Geräte, die noch gebaut werden.
Fazit
Wer auf die Vorfälle der letzten Jahre schaut, findet wenig exotische Angriffe und viele Entscheidungen, die bei der Auslegung gefallen sind. Ihr Schaden zeigt sich im Betrieb: In Polen stand die Kraft-Wärme-Kopplung kurz still und die Fernsteuerung der Parks war weg, bei KA-SAT mussten fast 30.000 Modems getauscht werden. In beiden Fällen war der Schaden Stillstand, nicht abgeflossene Daten.
Technisch ist die Liste überschaubar:
-
Schutzbedarf festlegen, bevor die Bauteile feststehen.
-
Einen SoC mit Vertrauensanker und dauerhaft sperrbarem Debug wählen.
-
Schlüssel je Gerät, den Tausch von Anfang an eingeplant.
-
Einen Update-Weg vorsehen, der auch den Bootloader über dieselbe geprüfte Kette aktualisiert.
Nichts davon ist für sich genommen teuer. Teuer wird es, wenn es erst nach der Hardware-Freigabe auf den Tisch kommt.
Der CRA macht zur gemeinsamen Grundausstattung, was sorgfältige Hersteller ohnehin tun, und das verschiebt den Wettbewerb.
Bisher ließ sich ein Gerät ohne Secure Boot, ohne Geräteschlüssel und ohne gepflegten Update-Weg günstiger anbieten. Mit der vollen Geltung des CRA im Dezember 2027 fällt dieser Kostenvorteil weg. Wer die Arbeit schon gemacht hat, liefert die Nachweise aus den Entwicklungsunterlagen und kann Security-Fragebögen von Kunden direkt beantworten. Wer bisher darauf verzichtet hat, muss nachziehen, bei Bestandsgeräten oft auf Hardware, die dafür nicht ausgelegt ist. Der Mehraufwand ist real. Am geringsten fällt er bei der nächsten Gerätegeneration aus, wenn die Entscheidungen vor der Hardware-Freigabe fallen.
Was nach der Auslieferung kommt, behandelt Teil 2: wie Schlüssel und Zertifikate über die Laufzeit gültig bleiben, wie man mit offenen und proprietären Komponenten umgeht, welche Schwachstellen wirklich zählen und was sich bei Geräten machen lässt, die schon im Feld stehen.
Wo steht Ihr Gerät bei der Security?
In einer Potenzialanalyse klären wir mit Ihrem Team, welche Schutzziele Ihr Gerät hat, welche Angriffsebenen offen sind und welche Maßnahmen etwas bringen, auch, wo sich Aufwand sparen lässt. Am meisten lässt sich bewegen, solange die Hardware nicht festgelegt ist. Sie planen eine neue Gerätegeneration oder müssen Geräte im Feld bewerten? Sprechen Sie mit uns.
Die fünf häufigsten Fragen zu Embedded Security
Nein. Isolation ist eine Annahme über das Netz des Betreibers, und sie hält oft nicht: In Polen waren 2025 Leitsysteme über VPN-Zugänge ohne Mehrfaktor-Authentisierung erreichbar, Stuxnet überwand die Trennung in Natanz per USB. Segmentierung und Datendioden bleiben sinnvoll. Das Gerät selbst muss trotzdem nur signierte Firmware starten, Befehle nur authentisiert annehmen und ohne Standardzugänge ausgeliefert werden.
Die Signatur verhindert, dass ein Gerät manipulierte oder fremde Firmware startet, schützt aber nicht vor dem Auslesen. Die Verschlüsselung schützt die Vertraulichkeit. Gezielt verändern lässt sich verschlüsselte Firmware kaum, weil veränderte Teile nach der Entschlüsselung unbrauchbar sind. Den Nachweis, dass die Firmware vom Hersteller stammt und unverändert ist, liefert aber erst die Signatur. Jedes vernetzte oder updatefähige Gerät braucht die Signatur. Verschlüsselung kommt dazu, wenn Algorithmen, KI-Modelle oder Nachbauschutz es verlangen, und setzt einen nicht auslesbaren Schlüsselspeicher voraus.
Laut Cyber Resilience Act der Hersteller des Produkts, also wer es unter eigenem Namen in Verkehr bringt. Ein Entwicklungspartner kann Architektur, Umsetzung und Nachweise liefern, die Pflichten bleiben bei dem, der das Produkt in Verkehr bringt, und nicht beim Lieferanten. Vertraglich sollte deshalb klar sein, wer SBOM, Schwachstellenbeobachtung und Updates über den Supportzeitraum übernimmt. Diese Antwort ersetzt keine Rechtsberatung.
Für Produkte mit digitalen Elementen gilt der Cyber Resilience Act, mit Meldepflichten seit 11. September 2026 und voller Geltung ab 11. Dezember 2027. Für vernetzte Funkgeräte gilt seit 1. August 2025 die delegierte Verordnung zur Funkanlagenrichtlinie (RED), konkretisiert durch die Normenreihe EN 18031, voraussichtlich abgelöst mit voller Geltung des CRA (SCHUTZWERK). Harmonisierte CRA-Normen stehen noch aus; die Frist für die ersten war der 30. August 2026, ein noch nicht beschlossener Entwurf der Kommission verschiebt sie auf den 31. Oktober 2026 (cyberresilienceact.eu, Stand September 2026). Im Industrieumfeld ist zudem IEC 62443 verbreitet.
Eine Kette von Prüfungen beim Start, in der jede Stufe die nächste prüft, bevor sie sie ausführt. Sie beginnt bei einem Vertrauensanker, der sich nicht verändern lässt: dem Boot-ROM des Prozessors mit einem Schlüssel-Hash in den Fuses. Auf einem Linux-Gerät folgen Bootloader, Kernel und Root-Dateisystem, auf dem Mikrocontroller Bootloader und Applikation. Fehlt der Anker im Prozessor, kann ein externer Baustein den Flash vor dem Start prüfen.
Über den Autor.
Philipp Knaack, MSc
CTO I Danube Dynamics
Philipp Knaack verantwortet bei Danube Dynamics Security-Konzepte und Embedded-Architektur. Er hat mehr als 15 Jahre Erfahrung in der Entwicklung von Low-Level-Software, Betriebssystemen und Embedded-Software für kritische Anwendungen und mehr als 10 Jahre in IoT-Management-Software. Studiert hat er Hardware-Software-Engineering und Embedded Systems Design an der FH Oberösterreich in Hagenberg.