# Secure Boot > Secure Boot ist ein Mechanismus, bei dem jede Stufe des Gerätestarts die kryptografische Signatur der nächsten Stufe prüft, bevor sie sie ausführt, beginnend bei einer unveränderlichen Vertrauenswurzel im ROM oder in einmal programmierbarem Speicher. Er verhindert, dass veränderte oder fremde Firmware läuft. Praktisch verlangen UN R155, ETSI EN 303 645 und der Cyber Resilience Act ihn, und er gehört zu den ersten Dingen, die wir im Hardware-Pentest prüfen. Secure Boot prüft die Signatur jeder Firmware-Stufe, bevor sie läuft. Wie die Kette funktioniert, wo sie spezifiziert ist und wo sie in echten Geräten scheitert. Source: https://zyberum.com/de/glossar/secure-boot · Updated: 2026-10-07 ## Was ist Secure Boot? Secure Boot ist ein Startprozess, bei dem jedes Stück Code geprüft wird, bevor es ausgeführt wird. Die erste Stufe, typischerweise ein in den Chip eingebranntes Boot-ROM, hält oder referenziert einen öffentlichen Schlüssel (oft als Hash in eFuses) und verifiziert die Signatur des ersten Bootloaders. Der Bootloader verifiziert die nächste Stufe und so weiter bis zum Betriebssystemkern, dem Root-Dateisystem und der Anwendung. Die Abfolge heißt Chain of Trust oder Vertrauenskette; das unveränderliche erste Glied ist die Root of Trust. Passt eine Signatur nicht, verweigert das Gerät den Start, fällt auf ein Recovery-Image zurück oder geht in einen gesperrten Zustand. Die Optionen des Angreifers schrumpfen auf Angriffe gegen die Root of Trust selbst (Fault Injection, Hardwarefehler) oder gegen die Signaturschlüssel. ## Wo ist es definiert? Einen einzelnen Standard gibt es nicht. UEFI Secure Boot für PCs und Server ist in der UEFI-Spezifikation festgelegt (Platform Key, Key Exchange Key, Signaturdatenbanken db und dbx). Für Arm-Applikationsprozessoren beschreiben die Trusted-Board-Boot-Anforderungen, umgesetzt in Trusted Firmware-A, die Kette von BL1 im ROM über BL2 und BL31 bis zum Rich OS. NIST SP 800-193 definiert Schutz-, Erkennungs- und Wiederherstellungsanforderungen für Plattform-Firmware, darunter dass die Root of Trust unveränderlich ist und Updates authentifiziert werden. Mikrocontroller-Hersteller spezifizieren eigene Abläufe: Hardware-Sicherheitsmodule auf Automotive-Mikrocontrollern verifizieren den Applikations-Flash beim Start, IoT-SoCs bieten Secure Boot über eFuse-gesperrte Schlüssel-Digests. Regulierung verweist indirekt darauf: UN R155 Anhang 5 nennt Softwaremanipulation als Bedrohung und Integritätsschutz der Software als Maßnahme; ETSI EN 303 645 Provision 5.7 verlangt, dass Softwareintegrität über Secure-Boot-Mechanismen verifiziert wird; der Cyber Resilience Act fordert in Anhang I den Schutz der Integrität von Software und Firmware. ## Was es in der Praxis bedeutet Secure Boot ist fast immer "umgesetzt" und oft nicht wirksam. Was wir in Steuergeräte- und IoT-Tests regelmäßig finden: - **Entwicklungskonfiguration ausgeliefert.** Die Signaturprüfung existiert, aber die Fuse, die sie erzwingt, wurde nie gebrannt, oder im Schlüssel-Hash-Slot steckt noch der Testschlüssel des Herstellers. - **Unvollständige Kette.** Der Bootloader wird verifiziert, das Linux-Root-Dateisystem nicht (kein dm-verity, kein signiertes SquashFS). Ein Angreifer ändert ein Startskript und besitzt das Gerät bei intakter Kette. - **Umgehung über einen anderen Modus.** Ein UART-Recovery-Kommando, ein USB-Bootmodus oder eine Diagnoseroutine lädt unsignierten Code. - **Kein Anti-Rollback.** Ein signiertes, aber altes, verwundbares Image wird wieder akzeptiert. - **Time-of-check-Lücken.** Das Image wird im externen Flash verifiziert und dann zur Ausführung erneut gelesen. Den Inhalt dazwischen zu tauschen ist ein bekannter Angriff auf günstige SPI-Designs. Bei einem Leistungselektronik-Steuergerät mit AURIX-Mikrocontroller umfasst das Review die HSM-Bootkonfiguration, die UCB-Einstellungen und ob die Applikation über UDS geflasht werden kann, ohne dass das HSM sie erneut validiert. Diese Details richtig zu bekommen ist der Großteil der Arbeit. ## Häufige Missverständnisse Secure Boot schützt nicht vor Schwachstellen in korrekt signiertem Code: Ein Pufferüberlauf in einer signierten Anwendung läuft als signierter Code. Schlüssel macht er auch nicht sicher; liegt der Signaturschlüssel auf einem Build-Server ohne Zugriffskontrolle, ist die Kette nur so vertrauenswürdig wie dieser Server. Und "Secure Boot enabled" im Datenblatt sagt nichts über die Konfiguration im ausgelieferten Gerät. ## FAQ **Ist Secure Boot dasselbe wie verschlüsselte Firmware?** Nein. Secure Boot prüft Authentizität und Integrität über eine Signatur; den Code versteckt er nicht. Firmware-Verschlüsselung schützt die Vertraulichkeit und braucht einen Schlüssel auf dem Gerät. Viele Produkte brauchen beides: Signaturprüfung gegen Manipulation, Verschlüsselung gegen Reverse Engineering und Klonen. Eins ohne das andere lässt eine Lücke. **Verhindert Secure Boot Firmware-Extraktion?** Für sich nicht. Secure Boot verhindert, dass unsignierter Code läuft; er hindert einen Angreifer nicht daran, den Flash über einen Debug-Port oder durch Auslöten des Chips zu lesen. Ausleseschutz, gesperrte Debug-Schnittstellen und Verschlüsselung sind eigene Maßnahmen. Eine umgangene oder fehlende Signaturprüfung macht die Extraktion leichter, weil der Angreifer einen eigenen Dumper laufen lassen kann. **Wie testet ihr Secure Boot?** Wir lesen die Fuse- und Option-Byte-Konfiguration, prüfen, ob der Hash des öffentlichen Schlüssels wirklich gesperrt ist, ändern ein Byte eines signierten Images und verifizieren, dass das Gerät es ablehnt, testen, ob Debug- oder Recovery-Modi die Prüfung umgehen, prüfen Anti-Rollback und schauen die ganze Kette bis zum Dateisystem an. Bei Automotive-Mikrocontrollern gehört die HSM-Konfiguration dazu. Ein vollständiger Test dauert Tage, nicht Stunden. ## Sources - [NIST SP 800-193 Platform Firmware Resiliency Guidelines](https://csrc.nist.gov/pubs/sp/800/193/final) - [UEFI Forum: UEFI Specification (Secure Boot und Treibersignierung)](https://uefi.org/specifications) - [Trusted Firmware-A: Trusted Board Boot design](https://trustedfirmware-a.readthedocs.io/en/latest/design/trusted-board-boot.html) - [ETSI EN 303 645 Cyber Security for Consumer Internet of Things (Provision 5.7, Softwareintegrität)](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf) ## Related - [Firmware-Extraktion](https://zyberum.com/de/glossar/firmware-extraktion) - [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) - [Secure Boot: Acht Fehler, die wir immer wieder in Geräten finden](https://zyberum.com/de/insights/secure-boot-typische-fehler) - [Wir öffnen das Gehäuse. Dann die Firmware.](https://zyberum.com/de/hardware-pentest) --- Zyberum GmbH. Canonical page: https://zyberum.com/de/glossar/secure-boot