Secure Boot

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.