Secure Boot für vernetzte Ladestationen, im Feld ausgerollt
Wie wir die Linux-Ladestationen eines europäischen OEM um eine verifizierte Boot-Kette, verschlüsselten Speicher und ein sicheres Flash-Tool ergänzt haben, auch bereits installierte Einheiten, ohne die Hardware zu ändern.
- Branche
- Energie
- Leistungen
- Embedded Software
- Cybersecurity
Ein europäischer OEM liefert öffentliche Ladestationen für Parknetze in Innenstädten, Einkaufszentren, Flughäfen und Bürocampus. Die Ladestationen laufen rund um die Uhr und bleiben über OCPP, MQTT und Cloud-APIs für Abrechnung, Monitoring aus der Ferne und Energiemanagement verbunden.
Mit wachsender Zahl der Installationen gingen Firmware-Updates über instabile Netze hinaus, Servicetechniker griffen über Wartungsports von Drittanbietern auf Geräte zu, und öffentliche Infrastruktur wurde zunehmend zum Angriffsziel. Gleichzeitig machte der EU Cyber Resilience Act sicheres Softwaredesign, verifizierte Firmware-Integrität und langfristiges Schwachstellenmanagement zur gesetzlichen Pflicht.
Auf einen Blick
- Branche
- Energie
- Leistungen
- Embedded Software
- Cybersecurity
Planen Sie etwas Ähnliches? Ein erfahrener Ingenieur antwortet innerhalb eines Werktags.
Die Herausforderung
Gelegentliche Firmwarefehler und unzuverlässige Updates schadeten der Zuverlässigkeit, und ohne eingebauten Schutz waren die Ladestationen manipulierbar. Kompromittierte OTA-Kanäle hätten nicht autorisierten Code oder den Diebstahl der Zertifikate für die Cloud-Kommunikation ermöglichen können, mit Risiko für das gesamte Ladenetz.
Secure Boot in der neuen Produktion einzuführen war nur die halbe Aufgabe. Auch Ladestationen, die bereits im Feld waren, mussten aufgerüstet werden, und sobald Secure Boot aktiv war, bestanden die bestehenden OTA- und USB-Update-Tools die Signaturprüfung nicht mehr, und die Fabrikskripte wurden von den neuen Schlüssel- und Partitionsregeln blockiert.
Der OEM konnte die Mainboards der installierten Ladestationen tauschen, was teuer und langsam ist, oder die Firmware im Feld mit einem Tool aktualisieren, das Secure-Boot-Images sicher aufspielt. Er entschied sich für den zweiten Weg und beauftragte uns mit Entwurf und Umsetzung.
Wer den CRA ignoriert, riskiert den Verlust der Zertifizierung, Produktrückrufe und den Ausschluss von öffentlichen Ausschreibungen.
Unser Ansatz
Hardware Root of Trust: Boot-Integrität verankert im Boot-ROM des SoC, mit dem SHA-256-Hash des öffentlichen RSA-Schlüssels und gerätespezifischen Salts im OTP.
Signierte mehrstufige Boot-Kette: Signaturprüfungen für den EEPROM-Bootloader und RSA-2048-Validierung des Haupt-Boot-Images auf dem eMMC, sodass jede Stufe verifiziert wird: ROM → Bootloader → Boot-Image → Kernel.
Sicherer Kernel und initramfs: Kernel, Device Tree und initramfs werden erst nach der Signaturprüfung geladen; ein Entschlüsseler im initramfs nutzt Schlüssel, die aus OTP-Salt und SoC-ID abgeleitet werden.
Verschlüsselte, verifizierte Partitionen: dm-crypt für die Schlüssel- und Nutzerpartitionen, Integritätsprüfung eines schreibgeschützten SquashFS-Root-Dateisystems und OverlayFS für kontrollierte beschreibbare Bereiche.
Sicheres Flash- und Migrationstool: ein eigenes Werkzeug für gestufte Upgrades im Feld: zuerst ein signiertes Übergangs-Image, dann sicheres Brennen der OTP-Schlüssel und Neusignierung des Bootloaders, mit Wiederherstellungspfaden, damit kein Gerät unbrauchbar wird.
Verifizierte OTA-Pipeline: nur signierte Firmware-Pakete, mit rollbacksicherer Update-Logik, die die Secure-Boot- und Integritätsregeln einhält.
Compliance by Design: Die Architektur ist darauf ausgelegt, die Anforderungen des EU Cyber Resilience Act und der IEC 62443-4-2 zu erfüllen: authentifizierter Boot, verschlüsselter Speicher und langfristiges Schwachstellenmanagement.
Tech-Stack: Raspberry-Pi-Bootloader, Armbian, SquashFS + OverlayFS + ext4, systemd, perf und ftrace, OCPP und MQTT, auf einem Broadcom-BCM2712-SoC mit 2 GB RAM und 32 GB eMMC.
Die Herausforderung
Gelegentliche Firmwarefehler und unzuverlässige Updates schadeten der Zuverlässigkeit, und ohne eingebauten Schutz waren die Ladestationen manipulierbar. Kompromittierte OTA-Kanäle hätten nicht autorisierten Code oder den Diebstahl der Zertifikate für die Cloud-Kommunikation ermöglichen können, mit Risiko für das gesamte Ladenetz.
Secure Boot in der neuen Produktion einzuführen war nur die halbe Aufgabe. Auch Ladestationen, die bereits im Feld waren, mussten aufgerüstet werden, und sobald Secure Boot aktiv war, bestanden die bestehenden OTA- und USB-Update-Tools die Signaturprüfung nicht mehr, und die Fabrikskripte wurden von den neuen Schlüssel- und Partitionsregeln blockiert.
Der OEM konnte die Mainboards der installierten Ladestationen tauschen, was teuer und langsam ist, oder die Firmware im Feld mit einem Tool aktualisieren, das Secure-Boot-Images sicher aufspielt. Er entschied sich für den zweiten Weg und beauftragte uns mit Entwurf und Umsetzung.
Wer den CRA ignoriert, riskiert den Verlust der Zertifizierung, Produktrückrufe und den Ausschluss von öffentlichen Ausschreibungen.
Unser Ansatz
Hardware Root of Trust: Boot-Integrität verankert im Boot-ROM des SoC, mit dem SHA-256-Hash des öffentlichen RSA-Schlüssels und gerätespezifischen Salts im OTP.
Signierte mehrstufige Boot-Kette: Signaturprüfungen für den EEPROM-Bootloader und RSA-2048-Validierung des Haupt-Boot-Images auf dem eMMC, sodass jede Stufe verifiziert wird: ROM → Bootloader → Boot-Image → Kernel.
Sicherer Kernel und initramfs: Kernel, Device Tree und initramfs werden erst nach der Signaturprüfung geladen; ein Entschlüsseler im initramfs nutzt Schlüssel, die aus OTP-Salt und SoC-ID abgeleitet werden.
Verschlüsselte, verifizierte Partitionen: dm-crypt für die Schlüssel- und Nutzerpartitionen, Integritätsprüfung eines schreibgeschützten SquashFS-Root-Dateisystems und OverlayFS für kontrollierte beschreibbare Bereiche.
Sicheres Flash- und Migrationstool: ein eigenes Werkzeug für gestufte Upgrades im Feld: zuerst ein signiertes Übergangs-Image, dann sicheres Brennen der OTP-Schlüssel und Neusignierung des Bootloaders, mit Wiederherstellungspfaden, damit kein Gerät unbrauchbar wird.
Verifizierte OTA-Pipeline: nur signierte Firmware-Pakete, mit rollbacksicherer Update-Logik, die die Secure-Boot- und Integritätsregeln einhält.
Compliance by Design: Die Architektur ist darauf ausgelegt, die Anforderungen des EU Cyber Resilience Act und der IEC 62443-4-2 zu erfüllen: authentifizierter Boot, verschlüsselter Speicher und langfristiges Schwachstellenmanagement.
Tech-Stack: Raspberry-Pi-Bootloader, Armbian, SquashFS + OverlayFS + ext4, systemd, perf und ftrace, OCPP und MQTT, auf einem Broadcom-BCM2712-SoC mit 2 GB RAM und 32 GB eMMC.
Unser Ansatz
Was das für Sie bedeutet: Secure Boot und CRA-Bereitschaft lassen sich auch bei Produkten nachrüsten, die bereits im Feld sind, ohne Hardware-Redesign und ohne Rückruf.
Compliance by Design: Die Architektur ist darauf ausgelegt, die Anforderungen des EU Cyber Resilience Act und der IEC 62443-4-2 zu erfüllen: authentifizierter Boot, verschlüsselter Speicher und langfristiges Schwachstellenmanagement.
Tech-Stack: Raspberry-Pi-Bootloader, Armbian, SquashFS + OverlayFS + ext4, systemd, perf und ftrace, OCPP und MQTT, auf einem Broadcom-BCM2712-SoC mit 2 GB RAM und 32 GB eMMC.


Audit und Plan
Ein detailliertes Audit bestätigte, dass Secure Boot, signierte Firmware-Validierung und ein neues Flash-Tool die CRA-Anforderungen erfüllen und installierte Ladestationen schützen können, ohne die Hardware zu ändern.
Hardware Root of Trust
Boot-Integrität verankert im Boot-ROM des SoC, mit dem SHA-256-Hash des öffentlichen RSA-Schlüssels und gerätespezifischen Salts im OTP.
Signierte mehrstufige Boot-Kette
Signaturprüfungen für den EEPROM-Bootloader und RSA-2048-Validierung des Haupt-Boot-Images auf dem eMMC, sodass jede Stufe verifiziert wird: ROM → Bootloader → Boot-Image → Kernel.
Sicherer Kernel und initramfs
Kernel, Device Tree und initramfs werden erst nach der Signaturprüfung geladen; ein Entschlüsseler im initramfs nutzt Schlüssel, die aus OTP-Salt und SoC-ID abgeleitet werden.
Verschlüsselte, verifizierte Partitionen
Dm-crypt für die Schlüssel- und Nutzerpartitionen, Integritätsprüfung eines schreibgeschützten SquashFS-Root-Dateisystems und OverlayFS für kontrollierte beschreibbare Bereiche.
Sicheres Flash- und Migrationstool
Ein eigenes Werkzeug für gestufte Upgrades im Feld: zuerst ein signiertes Übergangs-Image, dann sicheres Brennen der OTP-Schlüssel und Neusignierung des Bootloaders, mit Wiederherstellungspfaden, damit kein Gerät unbrauchbar wird.
Verifizierte OTA-Pipeline
Nur signierte Firmware-Pakete, mit rollbacksicherer Update-Logik, die die Secure-Boot- und Integritätsregeln einhält.
Ergebnisse
- 80 % weniger Firmware-Schwachstellen nach Einführung der signierten Boot-Kette und verifizierter Updates
- Ladestationen starten nur von vertrauenswürdigen, vom Hersteller signierten Images
- Keine Geräterückrufe: installierte Ladestationen sicher im Feld migriert
- Architektur ausgelegt auf die Anforderungen von EU CRA und IEC 62443-4-2, ohne Hardware-Redesign
Servicekosten und Ausfallzeiten sanken, die installierten Ladestationen erhielten eine längere Lebensdauer, und der OEM stärkte seinen Ruf in Sachen Sicherheit und seinen Zugang zu öffentlichen Ausschreibungen.
Planen Sie etwas Ähnliches?
Sagen Sie uns, wo Sie stehen. Ein erfahrener Ingenieur antwortet innerhalb eines Werktags.
Eingesetzte Leistungen
Sprechen Sie mit einem Ingenieur, nicht mit dem Vertrieb
Idee, Prototyp, Produktion oder eine Flotte im Feld: Sagen Sie uns, wo Sie stehen. Ein erfahrener Ingenieur antwortet innerhalb eines Werktags.
Ihre Vorteile:
- Erfahrene Embedded-Ingenieure
- Hardware, Firmware und Cloud
- Vom Prototyp zur Flotte
- Klarer Umfang und nächste Schritte
- Direkte technische Antworten
- Kein Verkaufsgespräch
Wie geht es weiter?
Ein kostenloses 30-minütiges Gespräch mit einem erfahrenen Ingenieur
Ein kurzes technisches Erstgespräch
Ein Angebot mit Umfang, Zeitplan und Kosten