Secure Boot vs Authenticated Boot: Embedded-Sicherheit

Wenn Sie ein eingebettetes System entwerfen, egal ob Industrieanlage, IoT-Sensor oder Automotive-Steuergerät, entscheidet die Boot-Phase über die Sicherheit des gesamten Geräts. Was in den ersten Millisekunden nach dem Reset geschieht, legt fest, ob Ihr Gerät nur vertrauenswürdigen Code ausführt oder einem Angreifer eine dauerhafte, tief verankerte Hintertür bietet. Genau deshalb sind Secure Boot und die damit oft verwechselten Konzepte Measured Boot und Authenticated Boot so zentral.

Dieser Artikel klärt zuerst die Begriffe präzise (und räumt mit einer verbreiteten Ungenauigkeit auf), zeigt dann anhand realer Plattformen wie UEFI, ARM Trusted Firmware-A, Intel Boot Guard, Android Verified Boot und U-Boot, wie diese Verfahren tatsächlich implementiert werden, und benennt zum Schluss echte Angriffe und Grenzen (BlackLotus, TPM-Sniffing). Am Ende können Sie fundiert entscheiden, ob Sie für Ihr Projekt ein blockierendes, ein messendes oder ein kombiniertes Verfahren brauchen.

Kurz vorweg der wichtigste Unterschied in einem Satz: Secure Boot stoppt den Startvorgang bei einer ungültigen Signatur, während nicht-blockierende Verfahren (Measured Boot, Trusted Boot und das uneinheitlich verwendete "Authenticated Boot") den Boot fortsetzen und die Prüfergebnisse nur protokollieren.

Root of Trust und Chain of Trust: das Fundament

Jedes Boot-Sicherheitsverfahren steht und fällt mit einem Punkt, dem alles andere blind vertraut. Ohne diesen Ausgangspunkt gibt es keine Sicherheit, sondern nur eine Kette von Annahmen.

Root of Trust: Hardware schlägt Software

Der Root of Trust (RoT) ist der unveränderliche Ausgangspunkt des Vertrauens. Man unterscheidet zwei Ausprägungen:

• Hardware Root of Trust: Der Startcode und der Referenzschlüssel liegen physisch unveränderbar im Silizium, typischerweise in einem maskenprogrammierten Boot-ROM und in OTP-eFuses (One Time Programmable), in einem Secure Element oder in einer Physically Unclonable Function (PUF). Nach der Fertigung lässt sich dieser Anker nicht mehr verändern. In der ARM-Welt übernimmt zum Beispiel die erste Boot-Stufe BL1 diese Rolle, laut ARM-Dokumentation gilt sie "implicitly trusted (by virtue of immutability)", weil sie im ROM liegt.
• Software Root of Trust: Das Vertrauen basiert auf einer Softwarekomponente, die ihrerseits geladen und potenziell verändert werden kann. Das ist schwächer, weil ein Angreifer, der diese Komponente manipuliert, die gesamte Kette aushebelt.

Für ernsthafte Sicherheit gilt: Der erste prüfende Code und der zugehörige öffentliche Schlüssel gehören in unveränderlichen Speicher. Die U-Boot-Dokumentation formuliert das für den Public Key unmissverständlich: "It is critical that the public key be secure and cannot be tampered with. It can be stored in read-only memory, or perhaps protected by other on-chip crypto provided by some modern SOCs."

Chain of Trust: Vertrauen weiterreichen

Die Chain of Trust (CoT) überträgt das Vertrauen vom RoT Stufe für Stufe: Jede Komponente verifiziert die nächste, bevor sie die Kontrolle übergibt. Ein typisches Schema lautet Boot-ROM prüft Bootloader, Bootloader prüft Kernel, Kernel prüft Anwendungen. Bricht ein einziges Glied, ist alles danach kompromittiert.

Digitale Signaturen sind dabei einer einfachen Prüfsumme (CRC) klar überlegen. Ein CRC erkennt nur zufällige Bitfehler, aber eine Signatur schützt vor gezielter Manipulation, weil ein Angreifer ohne den privaten Signierschlüssel des Herstellers keine gültige Signatur erzeugen kann. Wichtig ist auch die Unterscheidung von Authentifizierung und Verschlüsselung: Authentifizierung stellt Herkunft und Unverändertheit sicher (Integrität und Authentizität), während Verschlüsselung die Vertraulichkeit (etwa proprietärer Algorithmen) schützt. Beides ergänzt sich, ersetzt sich aber nicht.

Wenn Sie tiefer in die allgemeinen Grundlagen einsteigen möchten, hilft unser Überblick zu den Grundlagen der Embedded Security als Rahmen für Integrität und Authentizität.

Secure Boot: Definition und Enforcement

Secure Boot (auch Verified Boot) prüft jede Boot-Stufe kryptografisch vor der Ausführung und stoppt den Boot bei Fehlschlag. Das ist der entscheidende Punkt: Secure Boot ist ein blockierendes Enforcement. Nur signierte, vertrauenswürdige Software wird ausgeführt, alles andere wird abgewiesen.

Das Grundprinzip auf einem einfachen Mikrocontroller sieht als Pseudocode so aus:

// Boot-ROM: der oeffentliche Schluessel ist bereits im OTP programmiert
extern const uint8_t public_key[];  // im Boot-ROM / OTP, unveraenderlich
bool verify_signature(const uint8_t* image, size_t len, const uint8_t* sig);

void bootrom_main(void) {
    uint8_t* bootloader = (uint8_t*) FLASH_BASE;
    size_t bl_len = get_length(bootloader);
    uint8_t* signature = (uint8_t*) (FLASH_BASE + bl_len);

    if (!verify_signature(bootloader, bl_len, signature)) {
        // Signatur ungueltig: kein Boot
        error_halt();
    }
    // Signatur gueltig: Kontrolle an den Bootloader uebergeben
    jump_to(bootloader);
}

Das Boot-ROM ist hier Teil des Root of Trust und prüft den Bootloader, bevor dieser überhaupt läuft. Solche Mechanismen sind im ROM-Code vieler MCU-Familien fest verdrahtet, etwa bei Infineon AURIX, NXP S32K oder Renesas RH850.

UEFI Secure Boot: PK, KEK, db und dbx

In der PC- und Server-Welt regelt UEFI Secure Boot das Vertrauen nicht über einen einzelnen OTP-Schlüssel, sondern über vier NVRAM-Variablen in strikter Hierarchie:

• PK (Platform Key): oberste Ebene, vom Gerätehersteller ausgegeben, signiert den KEK. Es gibt genau einen PK pro System.
• KEK (Key Exchange Key): autorisiert Änderungen an db und dbx (im Windows-Kontext von Microsoft ausgestellt).
• db (Signature Database): Liste vertrauenswürdiger Zertifikate und Hashes. Ein Bootloader muss hier gelistet sein, um zu starten.
• dbx (Forbidden Signatures Database): die Sperrliste. Sie hat immer Vorrang: Steht ein Bootloader in der dbx, wird er selbst dann blockiert, wenn seine Signatur an sich gültig wäre.

Beim Boot prüft die Firmware also zwei Bedingungen: Ist der Bootloader mit einem db-Eintrag signiert und steht er nicht in der dbx? Nur dann läuft er.

Wie aufwendig die Pflege dieser Datenbanken in der Praxis ist, zeigt der von Microsoft für 2026 angekündigte Zertifikatswechsel mit mehreren neuen db- und dbx-Einträgen. Microsoft belegt diesen Wechsel primär (support.microsoft.com, "Windows Secure Boot certificate expiration and CA updates", sowie der Windows IT Pro Blog): Die KEK CA 2011 und die UEFI CA 2011 laufen im Juni 2026 aus und müssen durch neue Zertifikate ersetzt werden. Lediglich das taggenaue Datum 27. Juni 2026 stammt aus Drittanbieter-Quellen und sollte nicht als offiziell fixiert gelten. Festhalten lässt sich unabhängig vom genauen Tag: Schlüsselverwaltung ist kein einmaliger Akt, sondern eine Aufgabe über die gesamte Produktlebensdauer.

Achtung bei der Übertragung: Die vierstufige PK/KEK/db/dbx-Hierarchie ist UEFI-spezifisch. Ein einfacher MCU-Bootloader hat meist nur einen einzigen öffentlichen Schlüssel im OTP, keine Datenbankhierarchie. Behandeln Sie beide Welten getrennt.

Measured Boot, Trusted Boot und "Authenticated Boot": die Begriffs-Nuance

Hier liegt die häufigste Verwechslung des ganzen Themenfelds, und genau hier wird der bestehende Sprachgebrauch oft ungenau. Sortieren wir die Begriffe sauber.

Measured Boot: messen statt blockieren

Measured Boot berechnet vor der Ausführung jeder Stufe einen Hash und protokolliert ihn sicher, ohne den Boot zu blockieren. Die ARM-Dokumentation bringt es auf den Punkt: "Measured Boot is the process of computing and securely recording hashes of code and critical data at each stage in the boot chain before the code/data is used." Und explizit zur Abgrenzung: "Unlike Trusted Board Boot, Measured Boot does not block execution based on verification failures." Measured Boot authentifiziert also nicht, es hält nur fest, was gestartet wurde.

Diese Messungen landen typischerweise in den Platform Configuration Registers (PCRs) eines TPM (Trusted Platform Module). PCRs werden nie überschrieben, sondern nur per Extend-Operation erweitert. Die Formel lautet:

neuer PCR-Wert = Hash( alter PCR-Wert || neue Messung )

Am Ende des Boots ist ein PCR damit das kumulative, manipulationsresistente Ergebnis aller Messungen dieser Kategorie in exakt dieser Reihenfolge. ARM TF-A nutzt zum Beispiel PCR0 für Image-Messungen und PCR1 für kritische Daten.

Remote Attestation: der eigentliche Zweck des Messens

Warum misst man, wenn man nichts blockiert? Wegen der Remote Attestation. Der TPM kann eine signierte "Quote" der PCR-Werte erzeugen und an einen entfernten Prüfer (Verifier) senden. Dieser vergleicht die Quote gegen eine Policy erwarteter Werte und entscheidet, ob die Plattform in einem vertrauenswürdigen Zustand gestartet ist. So kann ein Backend-Server einem Gerät den Zugang verweigern, obwohl das Gerät lokal problemlos gebootet ist. Measured Boot verlagert die Konsequenz also von "sofort lokal blockieren" auf "später remote entscheiden".

Trusted Boot: die NIST-Terminologie

Das offizielle NIST-Glossar kennt den Begriff Measured Boot indirekt unter dem Namen Trusted Boot: "A system boot where aspects of the hardware and firmware are measured and compared against known good values to verify their integrity and thus their trustworthiness." (NISTIR 8320A und 8320B). Auch das ist ein messender, kein per se blockierender Vorgang.

Und was ist "Authenticated Boot"?

Jetzt die wichtige Klarstellung: "Authenticated Boot" ist kein einheitlich standardisierter Begriff. Das NIST-Glossar enthält keinen eigenen Eintrag dafür, NIST verwendet stattdessen "Trusted Boot". In der Praxis kursieren für "Authenticated Boot" mindestens zwei Lesarten:

1. Lesart A (in vielen Blogs, Herstellertexten und auch in der Vorgängerfassung dieses Artikels): Es findet eine Signatur- oder Integritätsprüfung statt, aber der Boot wird bei Fehlschlag nicht gestoppt. Stattdessen wird ein Fehlerstatus gesetzt, im Flash oder EEPROM protokolliert oder an ein übergeordnetes System (Gateway, zentrale ECU) gemeldet. Funktional ist das nahezu deckungsgleich mit dem, was ARM, TCG und NIST "Measured Boot" beziehungsweise "Trusted Boot" nennen.
2. Lesart B (in älterer, TCG-naher Literatur, als kursierende Lesart zu verstehen): "Authenticated boot verifies that the software running on the system is coming from an authorized vendor", also als Herkunftsprüfung, ausdrücklich unterschieden von Measured Boot als reiner Integritätsprüfung. In dieser Lesart wären es zwei verschiedene Mechanismen. Diese Deutung stammt aus einer Sekundärzusammenfassung mit TCG-Bezug und ließ sich nicht an einem selbst gelesenen TCG-Originaldokument verifizieren. Nehmen Sie sie deshalb als eine kursierende Lesart, nicht als feststehende TCG-Kanonik.

Das eigentlich Wichtige ist bei beiden Lesarten identisch und wird von praktisch allen Quellen geteilt: Der Boot wird nicht blockiert, das Ergebnis wird nur protokolliert oder gemeldet. Weil "Authenticated Boot" so uneinheitlich gebraucht wird, verwenden moderne Standards (TCG, ARM, NIST) inzwischen die präziseren Begriffe Measured Boot beziehungsweise Trusted Boot. Wir behalten "Authenticated Boot" im Titel bei, weil der Begriff verbreitet gesucht wird, ordnen ihn im Text aber sauber ein.

Ein Pseudocode für das messende, nicht-blockierende Verhalten:

bool verify_signature(uint8_t* firmware, size_t len, uint8_t* signature) {
    return crypto_verify_signature(firmware, len, signature, PUBLIC_KEY);
}

void authenticated_boot(void) {
    bool valid = verify_signature(firmware_image, firmware_len, firmware_sig);

    if (!valid) {
        log_dtc("Firmware authentication failed");   // Fehler protokollieren
        set_boot_status(AUTH_FAIL);                  // Status setzen / melden
    } else {
        set_boot_status(AUTH_OK);
    }
    // Boot wird in JEDEM Fall fortgesetzt
    start_firmware();
}

Der Kontrast zum Secure-Boot-Beispiel weiter oben ist der Kern des gesamten Vergleichs: Dort steht error_halt(), hier steht start_firmware() unabhängig vom Prüfergebnis.

Reale Plattform-Implementierungen im Vergleich

Statt bei abstrakten Definitionen zu bleiben, lohnt der Blick auf fünf reale Plattformen. Sie zeigen, dass blockierende und messende Verfahren keine Gegensätze sind, sondern in der Praxis oft nebeneinander oder kombiniert auftreten.

UEFI Secure Boot

Die PK/KEK/db/dbx-Mechanik haben wir oben erklärt. UEFI Secure Boot arbeitet zur Laufzeit und verifiziert vor allem den Betriebssystem-Bootloader. Wichtig ist die Erkenntnis: Es schützt die Firmware, die diese Prüfung durchführt, nicht selbst. Genau hier setzt Intel Boot Guard an.

Intel Boot Guard

Intel Boot Guard ist ein CPU-hardwarebasierter Root of Trust, der das Firmware-Image selbst absichert, also die Ebene unterhalb von UEFI Secure Boot. Laut TianoCore-Community-Dokumentation (nicht Intels eigenem Datenblatt, deshalb attribuiert) läuft die Vertrauenskette so:

CPU-Reset
  -> Mikrocode verifiziert das Boot-Guard-ACM (via eingebettetem ACM-Public-Key-Hash)
  -> ACM verifiziert das Key Manifest (via Key-Hash im write-once PCH-Register)
  -> ACM verifiziert das Boot Policy Manifest (via Key Manifest, im Feld aktualisierbar)
  -> ACM verifiziert den IBB (Initial Boot Block, via Boot Policy Manifest)
  -> IBB verifiziert den OBB (OEM Boot Block)

Das ACM (Authenticated Code Module) ist von Intel signiert und läuft vor dem BIOS. Zwei Details sind bemerkenswert. Erstens die Speicherorte, die man nicht gleichsetzen sollte: Der Root-Key-Hash wird unveränderlich in Field Programmable Fuses (FPFs) gebrannt, die in der Management Engine (ME) liegen. Das im Ablauf genannte write-once PCH-Register ist davon ein separater, nur einmal beschreibbarer Mechanismus, beide sind nicht dasselbe. Key Manifest und Boot Policy Manifest lassen sich dagegen im Feld aktualisieren (etwa bei einem BIOS-Update mit neuem Signierschlüssel). Zweitens die Modi: Laut dieser Dokumentation kann Boot Guard "in one of two modes: measured boot or verified boot, with a third option combining both" betrieben werden, festgelegt per Fuse während der Fertigung. Das ist der stärkste Beleg dafür, dass Secure Boot (blockierend) und Measured Boot (messend) kombinierbare Modi ein und desselben Bausteins sind, kein Entweder-oder.

ARM Trusted Firmware-A (TBBR und Measured Boot)

ARM Trusted Firmware-A ist die Referenzbasis praktisch aller modernen ARM-Cortex-A-SoCs und zeigt beide Mechanismen im selben Codebase. Der Trusted Board Boot (TBBR, Spezifikation ARM DEN0006D) authentifiziert alle Firmware-Images entlang der Kette BL1, BL2, BL31, BL32, BL33 und blockiert bei Fehlschlag. Interessant: Die Kette nutzt selbstsignierte X.509v3-Zertifikate ganz ohne Certificate Authority. Die TF-A-Dokumentation stellt klar: "All certificates are self-signed. There is no need for a Certificate Authority (CA)", weil die Validierung am Zertifikatsinhalt hängt, nicht an der Aussteller-Legitimität. Es gibt zwei Zertifikatstypen, Key Certificates (verifizieren Public Keys) und Content Certificates (enthalten Image-Hashes). Der Standard-Hash-Algorithmus für den ROTPK ist SHA-256. Erzeugt werden die Zertifikate mit dem Host-Tool cert_create, optional verschlüsselt encrypt_fw die Firmware.

Parallel dazu, und ausdrücklich orthogonal, existiert das TF-A-Feature Measured Boot: Es misst nach dem Laden in PCR0 (Images) und PCR1 (kritische Daten), unabhängig vom TBBR-Ergebnis, und blockiert nicht. In der Praxis kombiniert man beides: TBBR blockiert bei Fehlschlag, Measured Boot liefert zusätzlich die Grundlage für Remote Attestation.

Android Verified Boot (AVB)

Android Verified Boot (auch Verified Boot 2.0, Referenz seit Android 8.0) verlangt, dass "all executable code and data that is part of the Android version being booted" vor der Nutzung kryptografisch verifiziert wird. Interessant ist die abgestufte Strategie:

• Kleine Partitionen (boot, dtbo) werden komplett geladen, ihr Hash wird berechnet und verglichen. Passt er nicht, startet Android nicht.
• Große Dateisysteme nutzen dm-verity mit einem Hash-Baum, der während des Ladens kontinuierlich verifiziert, ein pragmatischer Kompromiss bei mehreren Gigabyte großen Partitionen.

Ebenso differenziert ist die Fehlerreaktion: Im "restart"-Modus startet das Gerät bei Fehler sofort neu, danach schaltet der Bootloader in den "eio"-Modus (I/O Error), zeigt dem Nutzer einen Fehlerbildschirm und erlaubt weiterhin Datenrettung oder Update, statt das Gerät zu "bricken". Das ist ein Musterbeispiel dafür, wie man Enforcement und Betriebsfähigkeit zusammenbringt. Dazu kommt ein partitionsweiser Rollback-Schutz in manipulationssicherem Speicher.

U-Boot Verified Boot

U-Boot ist der verbreitetste Bootloader im Linux-Embedded-Bereich. Sein Verified Boot nutzt RSA-Signaturen und FIT-Images (Flattened Image Tree). Eine architektonische Feinheit wird oft missverstanden: Nicht jedes einzelne Image trägt eine eigene Signatur, sondern die FIT-Konfiguration wird signiert, und diese Signatur deckt zusätzlich die Hashes aller referenzierten Images ab. Für die Chain of Trust empfiehlt die U-Boot-Dokumentation ausdrücklich, "to use a different key at each stage": Master-Key signiert Stufe 1, deren Image enthält den Public Key für Stufe 2, und so weiter. Der Master-Public-Key gehört in Read-only-Speicher, üblicherweise im Device Tree, der in u-boot.dtb einkompiliert wird.

Praxisnahe Umsetzung

Vom Verständnis zur Implementierung. Diese Schritte gelten unabhängig von der konkreten Plattform.

1. Hardware vorbereiten

• Wählen Sie ein SoC oder einen MCU mit echtem Hardware Root of Trust (Boot-ROM plus OTP-eFuses, Secure Element oder PUF).
• Speichern Sie die öffentlichen Schlüssel oder deren Hashes an einem nach der Fertigung unveränderlichen Ort.
• Deaktivieren Sie offene Debug-Schnittstellen (JTAG, SWD) im Produktivzustand, sonst greift ein Angreifer an der Boot-Prüfung vorbei.

2. Schlüssel richtig verwalten

• Erzeugen Sie asymmetrische Schlüsselpaare (RSA oder ECC). Der private Schlüssel bleibt beim Hersteller, der öffentliche Teil kommt unveränderbar ins Gerät. Die PKI-Grundlagen dazu erläutern wir im Artikel zu den Grundlagen von HTTPS und Zertifikaten.
• Nutzen Sie unterschiedliche Schlüssel je Kettenstufe (siehe U-Boot) und planen Sie Schlüsselwiderruf ein. Reale Plattformen halten dafür mehrere OTP-eFuses vor.
• Schützen Sie den privaten Schlüssel im Produktionsprozess, idealerweise in einem HSM. cert_create in ARM TF-A unterstützt zum Beispiel PKCS11-HSM-URIs.

3. Herstellerspezifische Schlüsselspeicher kennen

Wie unterschiedlich der Schlüsselspeicher real ausfällt, zeigen drei Beispiele aus einem Fidus-Webinar. Behandeln Sie diese Details als Vendor-Angabe (nicht datenblattgeprüft):

• AMD Zynq UltraScale+ MPSoC: RSA-Public-Key in OTP-eFuses, dazu drei AES-Schlüsselstufen, Black Keys (per PUF regeneriert, nie im Klartext gespeichert), Grey Keys (mit einem Family Key verschlüsselt) und Red Keys (Klartext in batteriegepuffertem RAM, am unsichersten).
• NXP i.MX8: nutzt das CAAM-Modul und laut Quelle vier OTP-eFuses für die Public-Key-Speicherung.
• STM32MP: nutzt die BSEC-Komponente zur Ableitung geräteindividueller Schlüsselinformationen in OTP-eFuses.

4. FPGA-Bitstreams nicht vergessen

Ein oft übersehener Fall: Bei FPGAs schützt die Bitstream-Authentifizierung die Hardware-Konfiguration, also welche Logik geladen wird. Sie schützt aber nicht automatisch die Software, die auf Soft-Cores läuft. Diese braucht eine eigene, zusätzliche Authentifizierung. Wer das übersieht, hat eine echte Lücke in der Kette.

Angriffe und Grenzen: Wenn Secure Boot nicht reicht

Secure Boot ist stark, aber kein Allheilmittel. Zwei reale Fälle zeigen die Grenzen.

BlackLotus: Secure-Boot-Bypass ohne Kryptobruch

BlackLotus ist laut ESET-Forschung (Veröffentlichung 1. März 2023) das erste in-the-wild UEFI-Bootkit, das UEFI Secure Boot auf vollständig aktualisierten Windows-11-Systemen umgeht. Laut ESET wurde es seit mindestens 6. Oktober 2022 für rund 5.000 US-Dollar in Untergrundforen verkauft (das ist Threat-Intelligence, kein absolutes Faktum).

Der entscheidende Punkt: Der Angriff bricht die Kryptografie nicht. Er nutzt die Schwachstelle CVE-2022-21894 ("Baton Drop") in einer legitim signierten, aber veralteten Windows-Boot-Anwendung aus, die es erlaubt, die Secure-Boot-Policy per truncatememory-BCD-Option aus dem Speicher zu entfernen, bevor sie geladen wird. Danach verankert BlackLotus sein eigenes Zertifikat über den Machine Owner Key (MOK) dauerhaft im System und startet fortan über eine legitime, Microsoft-signierte Shim-Komponente.

Die eigentliche Schwäche ist strukturell: Obwohl bereits im Januar 2022 gepatcht, waren die betroffenen alten Binärdateien (Stand des ESET-Berichts 2023) noch nicht in der UEFI-Sperrliste (dbx). Genau deshalb funktionierte der Angriff auf gepatchten Systemen weiter. Der Grund für die Verzögerung ist ein Governance-Dilemma: "Revoking broadly-used Windows binaries could make thousands of outdated systems, recovery images, or backups unbootable." Die Lehre: Kryptografisch korrektes Secure Boot heißt nicht automatisch unumgehbar. Die Wirksamkeit hängt von der Pflege der Sperrliste und der Reaktionsgeschwindigkeit der gesamten Lieferkette ab.

TPM-Sniffing: Schlüssel auf dem Bus abgreifen

Der zweite Fall betrifft die Grenze zwischen Secure Boot und Datenschutz. Die Dolos Group demonstrierte, dass sich der BitLocker-Schlüssel eines Laptops abgreifen lässt, obwohl Secure Boot, Firmware-Passwort und IOMMU-Schutz aktiv waren. Der Grund: Bei einem diskreten, über SPI, I2C oder LPC angebundenen TPM verlässt der entsiegelte Schlüssel den Chip im Klartext über den Bus zur CPU. Ein einfacher Logikanalysator am SPI-Bus genügt zum Mitschneiden.

Die Kernerkenntnis, zusammengefasst über trmm.net (Trammell Hudson): Secure Boot validiert nur die Boot-Kette, es verhindert nicht die Schlüsselextraktion aus einem physisch zugänglichen TPM. Secure Boot und TPM-basierte Verschlüsselung sind zwei getrennte Sicherheitsschichten. Als Gegenmaßnahmen nennt die Quelle, in steigender Wirksamkeit: TPM-Autorisierungswerte mit Dictionary-Attack-Schutz, verschlüsselte TPM-Sessions (Parameter Encryption), den Wechsel von einem diskreten TPM zu einem Firmware-TPM (fTPM) im CPU-Package und schließlich Remote Attestation, bei der man dem lokalen System gar nicht erst vertraut. Der Trend zu fTPM (Intel PTT, AMD fTPM) hat hier eine seiner konkreten Begründungen.

Typische Fehler und Risiken

Bei der Umsetzung tauchen immer wieder dieselben Fallstricke auf:

• Schlüssel im beschreibbaren Flash: Liegt der öffentliche (oder schlimmer, der private) Schlüssel im externen Flash, kann ein Angreifer ihn manipulieren. Der Anker gehört in unveränderlichen Speicher.
• Kein echter Hardware Root of Trust: Ist das Boot-ROM nicht wirklich unveränderbar, bricht die gesamte Chain of Trust.
• Fehlender Anti-Rollback-Schutz: Ohne Schutz lässt sich eine alte, verwundbare Firmware-Version zurückspielen.
• Offene Debug-Schnittstellen: Ein aktives JTAG umgeht die Boot-Prüfung.
• Verwechslung von messend und blockierend: Wer meint, ein messendes Verfahren verhindere die Ausführung unerlaubter Firmware, irrt. Es erkennt und protokolliert nur, es blockiert nicht.
• Updates ungeprüft lassen: Viele prüfen die erste Boot-Stufe sorgfältig, vergessen aber, dass OTA- und Feld-Updates exakt dieselbe Strenge brauchen. Auch Recovery-Images müssen signiert sein.
• Recovery nicht mitgedacht: Das ist der am häufigsten übersehene Punkt. NIST SP 800-193 (Platform Firmware Resiliency Guidelines, erstveröffentlicht am 4. Mai 2018) beschreibt drei Säulen: Protection (nicht autorisierte Firmware verhindern, hier gehört Secure Boot hin), Detection (Manipulation erkennen, hier gehören Measured und Trusted Boot hin) und Recovery (den integren Zustand wiederherstellen, etwa über ein Golden Image oder einen Recovery-Bootloader). Der bloße Boot-Stopp ohne Wiederherstellungspfad kann ein Gerät dauerhaft unbrauchbar machen: "A successful attack on platform firmware could render a system inoperable, perhaps permanently."

Best Practices und Checkliste

1. Früh planen: Entscheiden Sie bereits in der Architekturphase über blockierend, messend oder kombiniert. Hardware-Constraints, Kosten und Zielplattform bestimmen die Wahl.
2. Echten Hardware Root of Trust nutzen: Boot-ROM plus OTP-eFuse, Secure Element oder PUF. Ohne unveränderlichen Anker bricht alles.
3. Chain of Trust lückenlos abdecken: Jede Stufe verifiziert die nächste, und zwar auch bei Feld-Updates und Recovery-Images.
4. Schlüssel sauber verwalten: private Schlüssel im HSM, öffentliche unveränderlich im Gerät, unterschiedliche Schlüssel je Stufe, Widerruf einplanen.
5. Verfahren bewusst wählen: maximale Härte (Automotive, Medizintechnik) spricht für blockierendes Secure Boot, Monitoring und Remote Attestation für messende Verfahren. Reale Plattformen wie Intel Boot Guard und ARM TF-A erlauben beides zugleich.
6. Recovery einplanen: Definieren Sie nach NIST SP 800-193 einen sicheren Wiederherstellungspfad, nicht nur einen Boot-Stopp.
7. Sichere Updates: Updates signieren, Versionen prüfen, Downgrade verhindern.
8. Fehlerfälle testen: ungültige Signatur, alte Firmware, offene Debug-Schnittstelle. Prüfen Sie, ob das System reagiert wie dokumentiert.
9. Physische Angriffe bedenken: diskretes TPM gegen fTPM abwägen, TPM-Sessions verschlüsseln, bei hohem Schutzbedarf Remote Attestation.
10. Compliance im Blick behalten: Im europäischen Markt setzen der Cyber Resilience Act (CRA) und die BSI-Richtlinie TR-03183 Integritätsanforderungen an Software (den genauen Wortlaut von TR-03183 vor einer harten Zitierung im Originaldokument prüfen). Für den Industrie- und Automotive-Kontext lohnt der Blick auf unseren Artikel zur Common-Criteria-Zertifizierung nach ISO/IEC 15408 für die Evaluierung von Secure-Element-Komponenten.

Häufige Fragen

Was ist der Unterschied zwischen Secure Boot und Authenticated Boot?

Secure Boot prüft jede Boot-Stufe vor der Ausführung kryptografisch und stoppt den Start bei ungültiger Signatur, es ist also ein blockierendes Enforcement. "Authenticated Boot" ist dagegen kein einheitlich standardisierter Begriff: In der verbreiteten Lesart findet zwar ebenfalls eine Signatur- oder Integritätsprüfung statt, der Boot wird bei Fehlschlag aber nicht gestoppt, sondern das Ergebnis nur protokolliert oder gemeldet. Moderne Standards (TCG, ARM, NIST) verwenden dafür die präziseren Begriffe Measured Boot beziehungsweise Trusted Boot.

Blockiert Secure Boot den Start bei einem Fehler?

Ja, genau das ist sein Kern. Secure Boot (auch Verified Boot) verifiziert jede Stufe vor der Ausführung und weist alles ab, was nicht signiert und vertrauenswürdig ist. Bei einer ungültigen Signatur wird der Startvorgang gestoppt (im Pseudocode error_halt()), im Gegensatz zu messenden Verfahren, die den Boot in jedem Fall fortsetzen.

Was ist Measured Boot (Trusted Boot)?

Measured Boot berechnet vor jeder Stufe einen Hash und protokolliert ihn sicher, ohne den Boot zu blockieren. Die Messungen landen typischerweise in den Platform Configuration Registers (PCRs) eines TPM und bilden die Grundlage für Remote Attestation, bei der ein entfernter Prüfer den Boot-Zustand bewertet. Das NIST-Glossar führt denselben messenden Vorgang unter dem Namen Trusted Boot.

Kann Secure Boot umgangen werden?

Ja, auch kryptografisch korrektes Secure Boot ist nicht automatisch unumgehbar. Das Bootkit BlackLotus umging 2023 UEFI Secure Boot auf vollständig aktualisierten Windows-11-Systemen, ohne die Kryptografie zu brechen: Es nutzte die Schwachstelle CVE-2022-21894 in einer legitim signierten, aber veralteten Boot-Anwendung. Die Wirksamkeit von Secure Boot hängt daher stark von der Pflege der Sperrliste (dbx) ab.

Braucht Secure Boot ein TPM?

Nein, Secure Boot selbst benötigt kein TPM. Es prüft Signaturen gegen einen Schlüssel im unveränderlichen Speicher (etwa OTP-eFuses oder NVRAM). Ein TPM wird für Measured Boot und Remote Attestation gebraucht, weil dort die Messwerte in den PCRs gespeichert und signiert bereitgestellt werden. Secure Boot und TPM-basierte Verschlüsselung sind zwei getrennte Sicherheitsschichten.

Fazit

Die Boot-Phase ist kein Nebenschauplatz, sondern ein zentraler Angriffsvektor. Der wichtigste Unterschied lässt sich in einem Satz merken: Secure Boot blockiert, messende Verfahren protokollieren. Secure Boot (Verified Boot) stoppt bei ungültiger Signatur, während Measured Boot und Trusted Boot messen und die Grundlage für Remote Attestation legen. "Authenticated Boot" ist dabei ein uneinheitlich verwendeter Begriff, den moderne Standards zunehmend durch die präziseren Bezeichnungen ersetzen.

Reale Plattformen zeigen, dass beide Ansätze keine Gegensätze sind: Intel Boot Guard lässt sich per Fuse auf messend, blockierend oder beides konfigurieren, und ARM TF-A führt TBBR und Measured Boot nebeneinander. Zugleich beweisen BlackLotus und TPM-Sniffing, dass korrekt implementierte Kryptografie nur so stark ist wie die Governance der Sperrlisten und der Schutz vor physischem Zugriff. Wer früh plant, einen echten Hardware Root of Trust nutzt, die Kette bis zu Updates und Recovery lückenlos absichert und das Verfahren bewusst wählt, baut ein Gerät, das den kommenden Anforderungen aus Remote Attestation, Supply-Chain-Sicherheit und fTPM-Migration gewachsen ist.