🌐 Dieser Artikel ist auch verfügbar auf: English

Secure Boot vs Authenticated Boot – Sicherheit im Embedded System

Secure Boot vs Authenticated Boot – Sicherheit im Embedded System

Wenn Du an ein eingebettetes System (z. B. eine Industrieanlage, ein IoT-Device oder eine Automotive-Steuerung) denkst, dann wird Dir schnell klar: Die Boot-Phase ist eine der kritischsten Phasen überhaupt. Hier wird der Grundstein gelegt, ob Dein Gerät sicher startet oder eine Angriffsfläche bietet. Genau deswegen ist das Thema Secure Boot im Bereich der Embedded Systems heutzutage so relevant. Genauso wichtig – aber oft weniger gut verstanden – ist das Konzept des Authenticated Boot. In diesem Artikel zeige ich Dir, worin sich beide Verfahren unterscheiden, wann welches Verfahren sinnvoll ist – und wie Du sie umsetzt (inklusive Code-Beispiele).

Ziel des Artikels ist es, Dir eine praxisnahe, verständliche und handlungsorientierte Übersicht zu liefern, damit Du in Deinem Projekt entscheiden kannst, ob Secure Boot, Authenticated Boot – oder beide – die richtige Lösung sind.

Grundlagen & Verständnis

Damit wir denselben Wissensstand haben, schauen wir zunächst auf die Begriffe und Mechanismen.

Was ist Secure Boot?

  • Secure Boot sorgt dafür, dass nur signierte und vertrauenswürdige Software beim Boot-Prozess ausgeführt wird.
  • Es beginnt mit einem Root of Trust (RoT) – z. B. gespeicherte Public Keys in One-Time-Programmable (OTP) eFuses oder einem Secure Element.
  • Anschließend wird eine Kette gestartet, eine Chain of Trust: Bootloader verifiziert Kernel, Kernel verifiziert ggf. Anwendersoftware.
  • Beispielhaft in Embedded Systems: Ein MCU-Bootloader liest Flash, prüft Signatur mit dem publizierten Public-Key – wenn falsch → Boot stoppt oder wechselt in sicheren Modus.

Was ist Authenticated Boot?

Beim Authenticated Boot wird der Integritätsstatus der Software geprüft, bevor sie ausgeführt wird. Das System verifiziert die Authentizität der Firmware (z. B. über eine digitale Signatur oder Hash-Prüfung), stoppt aber nicht unbedingt den Startvorgang, wenn etwas nicht stimmt. Stattdessen kann:

  • ein Fehlercode gesetzt,
  • ein Sicherheitsstatus im Flash oder EEPROM hinterlegt, oder
  • eine Diagnosemeldung an das übergeordnete System (z. B. Gateway oder zentrale ECU) gesendet werden.

Dadurch bleibt das System betriebsfähig, aber es ist bekannt, dass eine potenziell kompromittierte Firmware ausgeführt wird.

Vergleich und Schlüsselbegriffe

  • Root of Trust (RoT): Der unveränderbare Anfangspunkt (z. B. BootROM, eFuse) für Vertrauensbildung.
  • Chain of Trust: Jede Stufe verifiziert die nächste – z. B. BootROM → Bootloader → Kernel → Apps.
  • Firmware Integrity: Sicherstellung, dass Firmware unverändert und authentisch ist.
  • Bootloader Security: Der Bootloader ist kritische Software – er muss sicher starten, verifizieren, ggf. verschlüsseln.

Praxisnahe Umsetzung

Jetzt wird’s konkret: Du willst Secure Boot oder Authenticated Boot in einem Embedded-Projekt umsetzen – wie gehst Du vor?

1. Hardware-Vorbereitung

  • Stelle sicher, dass Dein SoC oder Mikrocontroller eine BootROM oder Hardware-Root-of-Trust bietet. Beispiel: Ein ARM Cortex-M mit OTP-eFuses, oder ein SoC mit Secure Boot Funktion.
  • Speicher die öffentlichen Schlüssel oder Hashes der vertrauenswürdigen Firmware an einem nicht veränderbaren Ort (z. B. eFuses, Secure Element).
  • Aktiviere ggf. Debug-Schnittstellen Abschaltung, Schutzmechanismen (z. B. JTAG deaktivieren) – damit Zusatzangriffe ausgeschlossen sind.

2. Secure Boot Ablauf (Code-Beispiel)

Angenommen: Ein einfacher BootROM lädt einen Bootloader aus Flash, prüft Signatur mit RSA. (Pseudo-C)

// BootROM: Schritt 1 – öffentlicher Schlüssel schon programmiert
extern const uint8_t public_key[];  // im BootROM, OTP
int verify_signature(const uint8_t* image, size_t len, const uint8_t* sig);
// BootROM Hauptfunktion
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) != 0) {
        // Signatur ungültig – kein Boot
        error_halt();
    }
    // Signatur gültig – springen zum Bootloader
    jump_to(bootloader);
}

Dieser Code zeigt die Kernidee: Der BootROM ist Teil des Root of Trust, er prüft den Bootloader, bevor dieser ausgeführt wird.

3. Authenticated Boot Ablauf (Code-Beispiel)

bool verify_signature(uint8_t* firmware, size_t len, uint8_t* signature) {
    return crypto_verify_signature(firmware, len, signature, PUBLIC_KEY);
}
void authenticated_boot() {
    bool valid = verify_signature(firmware_image, firmware_len, firmware_sig);
    
    if (!valid) {
        log_dtc("Firmware authentication failed");
        set_boot_status(AUTH_FAIL);
    } else {
        set_boot_status(AUTH_OK);
    }
    // Boot wird trotzdem fortgesetzt
    start_firmware();
}

In der Praxis wird so ein Mechanismus oft im ROM-Code des Microcontrollers implementiert, z. B. bei Infineon AURIX, NXP S32K oder Renesas RH850.

4. Kombinierte Szenarien & Embedded Use Cases

  • In der Automobilindustrie z. B. bei ECUs: Man setzt Secure Boot ein, damit nur freigegebene Firmware gestartet wird.
  • In IoT‐Knoten kann Authenticated Boot sinnvoll sein: Gerät sendet Messwerte, verifiziert seinen Startstatus regelmäßig – falls Abweichung → Alarm, statt sofort Blockade.
  • Typischer Ablauf für Secure Boot in Embedded Systems:
    1. BootROM (im SoC) prüft Bootloader-Signatur.
    2. Bootloader prüft Kernel / Firmware-Image.
    3. Firmware prüft Anwendungen oder lädt über sicheren Update-Mechanismus.
    4. Updates sind signiert, anti-rollback geschützt.

5. Typisches Setup: Schlüsselmanagement

  • Erzeuge Schlüsselpaare (Privat beim Hersteller, Öffentlicher Teil ins Gerät).
  • Verwende asymmetrische Verfahren (z. B. RSA oder ECC) zur Signatur.
  • Sichere Lagerung der privaten Schlüssel im Produktionsprozess.
  • Sichere Speicherung des öffentlichen Schlüssels im Gerät (z. B. OTP eFuse, Secure Element).
  • Pflege von Schlüssel-Rotation oder Widerruf: Wenn ein Privatschlüssel kompromittiert ist, muss dies im Feld berücksichtigt werden.

Typische Fehler & Risiken

Wenn Du Secure Boot oder Authenticated Boot implementierst, triffst Du häufig auf folgende Fallstricke – hier in Stichpunkten:

  • Schlüssel im Flash speicherbar: Wenn ein öffentlicher Schlüssel ­oder noch schlimmer der private Schlüssel im externen Flash gespeichert ist, kann ein Angreifer ihn manipulieren.
  • Kein Hardware-Root-of-Trust vorhanden: Wenn Dein BootROM nicht wirklich unveränderbar ist, bricht die gesamte Chain of Trust.
  • Fehler beim Anti-Rollback Schutz: Firmware kann zurückgesetzt oder eine alte Version geladen werden, wenn kein Schutz vorhanden ist.
  • Fehlende Debug-Sperre: JTAG oder andere Debugschnittstellen offen lassen, hilft Angreifern beim Bootprozess Eingriff nehmen.
  • Verwechslung von Authenticated vs. Secure Boot: Wenn Du denkst „ich habe Authenticated Boot, damit bin ich sicher“ – aber in Wahrheit verhindert es nicht das Ausführen unerlaubter Firmware. Z. B. > „While secure boot prevent the boot of a non trusted software, the authenticated boot detects a non trusted software but does not prevent its boot.”

  • Performance-/Ressourcenprobleme: In eingebetteten Systemen mit wenig Speicher oder langsamer CPU kann eine aufwändige Signaturprüfung den Start verzögern.

Wie vermeidest Du sie?

  • Sorge für eine solide Hardwarebasis mit unveränderbarem BootROM oder Secure Element.
  • Implementiere klare Prozesse für Schlüsselmanagement, Freigabeprozesse und Firmware-Updates.
  • Teste Szenarien mit Fehlermodus („ungültige Signatur“, „alte Firmware“) und stelle sicher, dass das System angemessen reagiert (z. B. Boot stoppt oder sichert herunterfährt).
  • Dokumentiere klar, ob Dein System Secure Boot blockierend oder Authenticated Boot nur messend ist – und kommuniziere das auch gegenüber Stakeholdern.

Best Practices & Handlungsempfehlungen

Hier meine konkreten Empfehlungen für Deine Embedded‐Projekte:

  1. Beginne früh mit dem Boot-Sicherheitsdesign

    • Entscheide bereits in der Architekturphase, ob Secure Boot oder Authenticated Boot erforderlich sind. Hardware-Constraints, Kosten und Zielplattform beeinflussen die Wahl.

  2. Verwende eine echte Root of Trust-Komponente

    • Ein BootROM oder Secure Element, das unveränderbar ist, bildet das Fundament der Sicherheit. Ohne RoT bricht die Chain of Trust.

  3. Implementiere eine saubere Chain of Trust

    • BootROM → Bootloader → Firmware → Anwendungen. Jede Stufe prüft die nächste. Achte auf klare Übergänge und Signaturen.

  4. Sichere Schlüssel und Signaturen korrekt

    • Privat­schlüssel dürfen niemals im Feld sein. Öffentliche Schlüssel müssen unveränderbar im Gerät sein. Anti-Rollback, Schlüssel-Rotation und sichere Speicherung sind Pflicht.

  5. Wähle die passende Methode: Blockieren vs Messen

    • Wenn Du maximale Sicherheit willst (z. B. Automotive, Medizintechnik): Secure Boot (blockierend).

    • Wenn Flexibilität und Monitoring wichtiger sind (z. B. IoT mit Fernüberwachung): Authenticated Boot (messend) kann ausreichend sein.

  6. Implementiere sichere Update-Mechanismen

    • Signiere Updates, prüfe Versionen, verhindere Downgrade. Self-Update sollte Teil der Boot-Security sein.

  7. Teste Fehlerszenarien und Angriffe

    • Simuliere kom­pro­mittierte Firmware, manipulierte Signatur, Debug-Schnittstelle offen. Überprüfe, wie Dein System reagiert.

  8. Dokumentiere und kommuniziere Deine Boot-Sicherheitsstrategie

    • Stakeholder (z. B. Zulieferer, regulatorische Instanzen) sollen verstehen, ob Secure Boot oder Authenticated Boot genutzt wird, was die Maßnahmen sind und welche Sicherheiten gelten.

Fazit

Du siehst: In Embedded Systems ist die Boot-Phase keineswegs trivial – sie ist ein zentraler Angriffsvektor und deshalb sollte sie bewusst und strukturiert behandelt werden. Mit Secure Boot erreichst Du eine starke Blockade gegen nicht vertrauenswürdige Software; mit Authenticated Boot bekommst Du eine flexiblere Lösung mit Mess- und Monitoring-Fähigkeit.

Und was kommt als Nächstes? In Zukunft wird sich das Thema „Boot Security“ weiterentwickeln: Multi-Core und heterogene SoCs stellen neue Anforderungen (z. B. formale Verifikation von Boot-Primitiven). Auch Remote Attestation und sichere Lieferkette (Supply Chain) gewinnen mehr Gewicht – gerade im Umfeld von Industrie 4.0 und vernetzten Embedded Geräten. Wenn Du also heute eine solide Boot-Sicherheitsstrategie implementierst, bist Du bestens aufgestellt für kommende Anforderungen.