# Secure Boot: Acht Fehler, die wir immer wieder in Geräten finden

Secure Boot scheitert öfter an Konfiguration als an Kryptografie: ungebrannte eFuses, offene Debug-Ports, lückenhafte Ketten, kein Anti-Rollback. Acht Fehler mit Fix.

Source: https://zyberum.com/de/insights/secure-boot-typische-fehler · Updated: 2026-10-07

Secure Boot scheitert selten an falscher Kryptografie. Es scheitert, weil die Kette unvollständig ist, weil eine Fuse nie gebrannt wurde, weil ein Debug-Port noch offen ist oder weil sich eine alte, signierte Firmware zurückflashen lässt. In unseren Hardware- und Steuergeräte-Pentests sehen wir dieselben acht Fehler quer durch Consumer-Geräte, Haushaltsgeräte, IoT-Module und Automotive-Controller. Hier sind sie, jeweils mit Fix.

## 1. Implementiert, aber nicht aktiviert

Das Designdokument beschreibt Secure Boot. Der Bootloader enthält den Prüfcode. Die eFuse, die die Prüfung verpflichtend macht, wurde in der Fertigung nie gebrannt, oder das Gerät läuft noch im Entwicklungsmodus, der unsignierte Images erlaubt.

Das finden wir regelmäßig, denn das Aktivieren von Secure Boot ist unumkehrbar, und jemand in Fertigung oder Entwicklung wollte nicht derjenige sein, der es tut. Bei ESP32-basierten Modulen ist der Entwicklungsmodus für Flash-Verschlüsselung und Secure Boot während der Inbetriebnahme bequem und bei der Auslieferung ein Risiko.

**Fix:** ein dokumentierter Fertigungsschritt, der die Fuses brennt und prüft, plus ein Check im End-of-Line-Test, der den Fuse-Zustand zurückliest. Wir prüfen Seriengeräte, nie Engineering Samples.

## 2. Debug-Ports noch offen

JTAG, SWD oder ein Hersteller-Download-Modus umgehen die Kette komplett: die CPU nach der Prüfung anhalten, RAM patchen oder Schlüsselmaterial und entschlüsselte Firmware aus dem Speicher lesen. Bei einem Gerät eines Haushaltsgeräteherstellers war der JTAG-Port offen, während Secure Boot aktiv war; die Boot-Kette war korrekt und bedeutungslos.

**Fix:** Debug-Schnittstellen in der Serie deaktivieren oder sperren (eFuse, Debug-Authentifizierung mit gerätespezifischem Schlüssel, Ausleseschutz) und die ROM-Download-Modi abschalten. Auf dem Tisch prüfen, nicht im Datenblatt.

## 3. Die Kette endet zu früh

Das ROM prüft den Bootloader, der Bootloader prüft den Kernel, und danach wird allem vertraut: dem Root-Dateisystem, der Applikation, dem Device Tree, der Konfigurationspartition, der Firmware eines zweiten Mikrocontrollers oder Funkmoduls. Ein Root-Dateisystem ohne dm-verity ist beschreibbar, und ein beschreibbares Dateisystem mit einem ungeprüften Startskript ist Codeausführung bei jedem Boot.

**Fix:** die Kette auf jedes Stück Code und Konfiguration ausdehnen, das das Verhalten beeinflusst: dm-verity oder signiertes squashfs für Linux, signierte Applikations-Images für Mikrocontroller, signierte Konfiguration oder Konfiguration, die gegen ein signiertes Schema geprüft wird, und Prüfung der Co-Prozessor-Firmware durch den Hauptcontroller.

## 4. Kein Anti-Rollback

Die Signaturprüfung besteht für jedes Image, das der Hersteller je signiert hat, auch für das von vor zwei Jahren mit der bekannten Schwachstelle. Ein Angreifer mit einer Kopie des alten Updates flasht es zurück und nutzt den alten Bug.

**Fix:** ein monotoner Versionszähler in eFuses oder einem geschützten Speicherbereich, den der Bootloader mit der Image-Version vergleicht, und eine Regel, wann er erhöht wird. Auf vielen Chips hat der Zähler nur eine begrenzte Zahl von Schritten, also bei Sicherheitsfixes erhöhen, nicht bei jedem Release.

## 5. Schlüssel wie Konfiguration behandelt

Ein Signaturschlüssel für die ganze Produktfamilie, abgelegt auf dem Build-Server oder im Repository. Ein Entwicklungsschlüssel, der vor der Serie nie ersetzt wurde. Keine Möglichkeit, einen Schlüssel nach einem Leak zurückzuziehen: Beim ursprünglichen ESP32 speichert Secure Boot V2 zum Beispiel einen einzigen Public-Key-Digest ohne Revocation, und mehrere andere Controller sind ähnlich.

**Fix:** Produktionsschlüssel in einem HSM oder zumindest auf einer Offline-Maschine erzeugen, Entwicklungs- und Produktionsschlüssel trennen, einen Chip oder ein Verfahren wählen, das mehrere Schlüssel und Revocation unterstützt, und festhalten, wer was signieren darf.

## 6. Ein Hash, wo eine Signatur hingehört, oder eine Prüfung zum falschen Zeitpunkt

Zwei Varianten desselben Fehlers. Der Bootloader vergleicht einen SHA-256 des Images mit einem daneben gespeicherten Wert: Wer das Image schreiben kann, kann den Hash schreiben. Oder der Bootloader prüft die Signatur des Images im Flash und lädt das Image danach erneut aus dem Flash, mit einem Zeitfenster, um den Inhalt zwischen Prüfung und Nutzung auszutauschen. Beides haben wir in Update-Handlern öfter gesehen als im Boot-Code, aber im Boot-Code tut es am meisten weh.

**Fix:** eine asymmetrische Signatur mit einem öffentlichen Schlüssel prüfen, der selbst geschützt ist (im ROM, in eFuses oder durch die vorherige Stufe), und die Kopie im RAM prüfen, die danach ausgeführt wird.

## 7. Verschlüsselung mit Authentifizierung verwechselt

Der Flash ist verschlüsselt, also hält das Team die Firmware für geschützt. Aber Verschlüsselung ohne Authentifizierung verhindert keine Veränderung: Wer Bits im Chiffrat kippt, kippt Bits im Klartext, und wer den Loader glitcht, überspringt eine Prüfung, die nie eine war. Bei TriCore/AURIX-Controllern haben wir ein verwandtes Missverständnis gesehen: Das Boot-ROM prüft die Boot Mode Header auf Konsistenz, nicht auf Authentizität, und authentisches Booten muss im HSM implementiert werden. Bei einem Leistungselektronik-Steuergerät war das nicht geschehen, und der Applikations-Flash akzeptierte jedes Image mit gültiger Prüfsumme.

**Fix:** Vertraulichkeit und Integrität als zwei Anforderungen behandeln. Flash-Verschlüsselung und Signaturprüfung beide aktivieren und authentifizierte Verschlüsselung für Daten verwenden, die außerhalb der geprüften Images liegen.

## 8. Fault Injection nicht bedacht

Ein einzelnes `if (verify(image) == OK)` ist eine Instruktion, die sich überspringen lässt. Spannungs- oder Takt-Glitching im richtigen Moment kippt diesen Sprung, und Forschung an mehreren weit verbreiteten Controllern hat gezeigt, dass das gegen ROM-Code funktioniert. Bei einem Gerät in großer Stückzahl muss der Angreifer einmal Erfolg haben und kann die Methode dann veröffentlichen.

**Fix:** redundante Prüfungen mit unterschiedlichen Codepfaden, zufällige Verzögerungen, Vergleich des Ergebnisses gegen eine nicht triviale Konstante statt gegen null und, wo der Chip es bietet, Hardware-Glitch-Detektoren. Bei hochwertigen Produkten nehmen wir Fault Injection in den Test auf, um zu sehen, wie viel Aufwand ein Angriff kostet.

## Was wir testen

| Prüfung | Methode | Zerstörend |
|---|---|---|
| Zustand von Fuses und Option Bytes an Seriengeräten | Rücklesen über Herstellertools oder Debug-Port | Nein |
| Debug- und Download-Modi | JTAG, SWD, UART-Bootloader, USB-DFU abklopfen | Nein |
| Vollständigkeit der Kette | Jede Stufe und Partition verändern, Boot beobachten | Nein |
| Anti-Rollback | Ein älteres signiertes Image flashen | Nein |
| Umgang mit Schlüsseln | Firmware-Analyse, Analyse des Update-Pakets | Nein |
| Glitch-Resistenz | Spannungs- oder Takt-Fault-Injection im Boot-Pfad | Möglicherweise |

Das Ergebnis ist ein Bericht mit den genauen Fuse-Bits, Boot-Stufen und Update-Pfaden, die sich ändern müssen, und ein Retest nach dem Fix. Secure Boot ist außerdem die Stelle, an der die Integritätsanforderung des Cyber Resilience Act und Provision 5.7 der EN 303 645 konkret werden, derselbe Bericht dient also als Nachweis für beides.

Mehr zu Umfang und Preisen auf der Seite [Hardware-Pentest](/de/hardware-pentest), oder buch ein [kostenloses 15-Minuten-Gespräch](/de/kontakt?meeting=quick&interest=hardwarePentest).

## FAQ

**Ist Secure Boot gesetzlich vorgeschrieben?**

Nicht namentlich. Der Cyber Resilience Act verlangt in Anhang I Teil I, dass Produkte die Integrität von Software und Konfiguration gegen unbefugte Veränderung schützen, und EN 303 645 fordert in Provision 5.7 die Prüfung der Software-Integrität mit einem Secure-Boot-Mechanismus. Secure Boot ist der übliche Weg, diese Anforderungen für Firmware zu erfüllen.

**Ersetzt Flash-Verschlüsselung Secure Boot?**

Nein. Verschlüsselung hindert einen Angreifer daran, die Firmware zu lesen; sie hindert ihn nicht daran, veränderte Firmware auszuführen, wenn er sie auf das Gerät bekommt oder den Loader glitcht. Secure Boot prüft die Authentizität, Verschlüsselung schützt die Vertraulichkeit. Die meisten Chips erwarten, dass beides zusammen aktiviert wird.

**Könnt ihr Secure Boot testen, ohne das Gerät zu zerstören?**

Das meiste ja. eFuses, Debug-Ports, die Kette und den Update-Pfad prüfen wir zerstörungsfrei. Fault Injection und Chip-off-Extraktion können ein Gerät töten, deshalb vereinbaren wir vorher, welche Exemplare geopfert werden dürfen.

## Sources

- [NIST SP 800-193: Platform Firmware Resiliency Guidelines](https://csrc.nist.gov/pubs/sp/800/193/final)
- [ETSI EN 303 645 V2.1.1, Provision 5.7 (Software-Integrität)](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf)
- [Espressif ESP-IDF: Secure Boot V2](https://docs.espressif.com/projects/esp-idf/en/latest/esp32/security/secure-boot-v2.html)
- [Verordnung (EU) 2024/2847 (Cyber Resilience Act), Anhang I Teil I](https://eur-lex.europa.eu/eli/reg/2024/2847/oj)

## Related

- [Secure Boot](https://zyberum.com/de/glossar/secure-boot)
- [Debug-Schnittstellen (JTAG, SWD, UART)](https://zyberum.com/de/glossar/debug-schnittstellen-jtag-uart)
- [Hardware Security Module (HSM)](https://zyberum.com/de/glossar/hardware-security-module)
- [Hardware-Pentest: So läuft er ab, Schritt für Schritt](https://zyberum.com/de/insights/hardware-pentest-ablauf)
- [Firmware-Extraktion: Was sie verrät und wie du sie verhinderst](https://zyberum.com/de/insights/firmware-extraktion-anleitung)
- [Wir öffnen das Gehäuse. Dann die Firmware.](https://zyberum.com/de/hardware-pentest)

---
Zyberum GmbH. Canonical page: https://zyberum.com/de/insights/secure-boot-typische-fehler