Secure Boot: Was die Signaturprüfung schützt, und was nicht

Fast jedes Hardware-Projekt, das wir bewerten, hat eine Position „Secure Boot: aktiviert". Sie steht im Security-Konzept, in den Datasheet-Highlights, manchmal in den Zertifizierungsunterlagen. Und in fast jeder Bewertung finden wir dieselbe Lücke: Das Team vertraut dem Feature, aber niemand hat aufgeschrieben, was das Feature tatsächlich verspricht. Secure Boot verifiziert Signaturen. Das ist eine präzise, enge Aussage, und die Distanz zwischen dieser Aussage und „auf dem Gerät läuft nur unsere Software" ist die Stelle, an der echte Produkte scheitern.

Diese Note handelt von dieser Distanz. Nicht davon, wie man Secure Boot auf einem bestimmten SoC aktiviert, das beschreibt die Vendor-Dokumentation,, sondern davon, welche Eigenschaften eine Boot-Kette durch Signaturprüfung gewinnt und welche nicht. Es ist das Erste, was wir rekonstruieren, wenn wir ein Gerät ansehen, und es ist eine nützliche Übung für das eigene Produkt, bevor es jemand anders tut.

Was Secure Boot tatsächlich verifiziert

Secure Boot ist eine Kette von Prüfungen, kein einzelner Schalter. Die Boot-ROM, fest im Silizium, enthält einen Public Key oder dessen Hash oder misst an ihm. Sie verifiziert die erste ladbare Stage, bevor sie sie ausführt. Diese Stage verifiziert die nächste, und so weiter bis zum Betriebssystem. Jedes Glied entscheidet: Habe ich Evidenz, dass der nächste Block authentisch ist, und vertraue ich dem Mechanismus, der prüft?

Das wichtige Wort ist authentisch. Eine Signaturprüfung beantwortet exakt eine Frage: Stammt dieses Image unverändert von dem, der den zugehörigen Private Key hält? Das ist es, was sie schützt. Klicken Sie sich durch die Kette und beachten Sie, wie wenig des Boot-Vorgangs von dieser Frage tatsächlich abgedeckt ist.

Zwei Dinge fallen in echten Ketten auf. Erstens: Die Wurzel zählt mehr als die Glieder, liegt der Public Key nicht in OTP/eFuse gebrannt, sondern auf demselben Flash wie die Images, die er verifiziert, lässt sich die Kette auf einen Angreifer-Key um-pointieren. Zweitens: Ketten haben Enden, und was nach der letzten verifizierten Stage geladen wird, erbt Vertrauen, das es nie erworben hat.

Der unsignierte Mittelteil: Konfiguration und Device Trees

Der häufigste Befund in Boot-Chain-Reviews ist kein gebrochenes Signaturverfahren. Es ist ein unsignierter Device Tree neben einem signierten Kernel. Der DTB beschreibt die Hardware: Memory Map, Peripherie, Console-Parameter, welche Nodes aktiv sind. Ein manipulierter Device Tree kann Speicher um-mappen, eine sichere Peripherie deaktivieren, die Console umleiten oder reservierte Bereiche ändern, ohne ein einziges Byte signierten Codes anzufassen. Der Kernel bootet, jede Signatur gilt, und der Angreifer ist bereits im Addressraum.

Dasselbe gilt für Boot-Argumente, Konfigurations-Blobs, Kalibrierdaten und Firmware externer Co-Prozessoren. Was die Boot-Kette unverifiziert kopiert, ist Angriffsfläche, egal, was das Security-Konzept sagt.

Was Signaturen nicht abdecken

Die Signaturprüfung ist bewusst blind für drei Fragen, die in Produkten enorm viel zählen:

• Aktualität. Ein altes, ordnungsgemäß signiertes Image ist so gültig wie das neueste. Downgrade-Schutz ist ein eigener Mechanismus, monotone Counter, und eine eigene Engineering-Entscheidung. Wir behandeln ihn vertieft in Firmware Anti-Rollback.
• Umfang. Die Signatur deckt exakt die Bytes ab, die zur Signierzeit gehasht wurden. Kernel: signiert. Device Tree: oft nicht. Root-Filesystem: nur mit Verified Boot (dm-verity), das in den meisten Embedded-Linux-Builds optional ist.
• Korrektheit des Prüfers. Die Prüfung selbst ist Code. Allein 2026 haben ein U-Boot-FIT-Signatur-Bypass (CVE-2026-46728, gefixt ab Release 2026.04) und eine UEFI-Shim-Secure-Boot-Schwachstelle (CVE-2026-8863) gezeigt: Der Mechanismus, der Ihre Trust-Grenze erzwingt, muss wie jede andere Komponente gepatcht werden, nur eben auf einer Boot-ROM häufig nicht.

Secure Boot vs. Measured Boot

Es lohnt sich, beide zu trennen, weil sie unterschiedliche Fragen beantworten, und Produkte manchmal beides brauchen. Secure Boot erzwingt: Image fällt durch die Prüfung, Boot bricht ab. Measured Boot protokolliert: jede Stage hasht die nächste in ein Log oder ein TPM-PCR, und das System, oder ein entfernter Prüfer, kann später rekonstruieren, was gelaufen ist. Erzwingung ohne Messung liefert keine Evidenz-Spur; Messung ohne Erzwingung lässt den Angriff laufen, dokumentiert ihn aber. Auf Produkten mit TPM ist die Attestation des Mess-Logs ans Backend oft die stärkere Architektur: Die Flotte erkennt ein manipuliertes Gerät selbst dann, wenn die lokale Erzwingung eine Lücke hat.

Die Fehler, die wir in Reviews finden

Wiederkehrend, über Hersteller und Produktklassen hinweg:

• Development-Keys in der Produktion, weil das OTP nie gebrannt wurde, die Kette verifiziert gegen einen Key, den der Angreifer auch hat.
• Secure Boot auf der primären Kette, während ein Recovery- oder Field-Service-Mode Images mit deaktivierter Prüfung lädt.
• Prüfergebnisse werden geloggt, Fehler aber nur geloggt, der Boot läuft trotzdem weiter.
• Ein signierter Bootloader, der für „Feld-Diagnostik" kernels von USB oder SD lädt, außerhalb des verifizierten Pfads.
• Eine Produktfamilie, ein Signing-Key, keine Revocation-Story, ein Key-Event in der Signatur-Infrastruktur wird zum Recall-scale-Ereignis über alle jemals produzierten Geräte.

Was Sie am eigenen Produkt prüfen sollten

Marketing weg und sechs Fragen mit Evidenz beantworten, nicht mit dem Reference Manual:

• Wo genau liegt der Root-Public-Key, und lässt er sich ohne Silizium-Arbeit ändern?
• Welche Artefakte im Boot-Pfad sind signiert. Kernel, DTB, Initramfs, Rootfs, Co-Prozessor-Firmware?
• Was passiert nach der letzten verifizierten Stage?
• Gibt es einen Pfad. Recovery, Diagnostik, RMA,, der die Prüfung umgeht?
• Wie rotieren Sie den Signing-Key auf bereits ausgelieferten Geräten?
• Wenn der Prüfer selbst eine CVE hat: Welche Ihrer Produkte sind betroffen, und woher wissen Sie das?

Wenn die Antworten aufgeschrieben und langweilig sind, ist Ihr Secure Boot wahrscheinlich echt. Wenn sie einen Anruf beim Silizium-Hersteller erfordern, ist es eine Checkbox, und die Checkbox richtet mehr Schaden an als Nutzen, weil sie alle davon abhält, weiterzufragen.