Secure Boot auf dem NXP i.MX8M Mini: Was die CRA wirklich von IoT-Herstellern fordert

Abb. 1: Chain of Trust auf dem NXP i.MX8M Mini. Fünf Stufen, vier Authentifizierungen, ein in Silizium gebrannter Anker. An Stufe 4 wechselt der Mechanismus von HAB auf CONFIG_FIT_SIGNATURE.

Über diesem Anker liegen fünf aufeinanderfolgende Stufen, jede durch die vorhergehende authentifiziert:

•Stufe 1: BootROM läuft beim Power-on an, unveränderlich im Silizium, und konsultiert den SRK-Hash aus den eFuses.

•Stufe 2: SPL + DDR-Firmware bringt den Hauptspeicher zum Laufen und wird von der BootROM gegen den SRK-Hash verifiziert.

•Stufe 3: ATF, OP-TEE, U-Boot lädt der SPL aus dem FIT-verketteten flash.bin und authentifiziert die Komponenten über die HAB-APIs.

•Stufe 4: FIT-Image mit Kernel, Device Tree und initramfs wird von U-Boot verifiziert. Hier entscheidet sich, ob Secure Boot wirksam ist.

•Stufe 5: Userland startet aus dem authentifizierten initramfs. Die Root-Partition kann zusätzlich per dm-verity integritätsgeschützt eingebunden werden.

Ab dem „Closed”-Zustand akzeptiert die BootROM nur noch Images, deren Signatur gegen den SRK-Hash validiert werden kann. Ein falsch gebrannter Hash brickt das Gerät irreversibel. Jeder Serienprozess braucht deshalb eine belastbare Vorprüfung, idealerweise automatisiert über UUU-Skripte mit impliziten SRK-Checks.

Der Übergang, der oft übersehen wird

Die Authentifizierungsmechanismen sind nicht über die gesamte Kette hinweg identisch. Zwischen Stufe 1 und Stufe 3 arbeitet HABv4 im SoC gegen den SRK-Hash aus den eFuses. Eine einzige flash.bin mit SPL, DDR-Firmware, ATF, OP-TEE und U-Boot wird als FIT-Struktur signiert und in einem Durchgang verifiziert. Dieser Teil der Kette ist hardwareseitig erzwungen.

Bei Stufe 4 übergibt HAB anCONFIG_FIT_SIGNATURE in U-Boot. U-Boot verifiziert das FIT-Image mit Kernel, Device Tree und initramfs gegen einen Public Key, der in seinem eigenen Device Tree eingebettet ist. Dieser Public Key wurde in Stufe 3 als Teil des U-Boot-DTB über HAB mitsigniert. Der Trust fließt also konsistent weiter, aber das Werkzeug ist ein anderes.

Das ist der Schritt, der in frühen Integrationen regelmäßig übersehen wird. Und zwar aus einem strukturellen Grund: Er ist nicht hardwareseitig erzwungen. Man kann U-Boot signieren, ausliefern und betreiben, ohne CONFIG_FIT_SIGNATURE einzuschalten. Die BootROM meckert nicht, der HAB-Status zeigt keine Events, und hab_status meldet saubere Konfiguration. Erst wer die U-Boot-Konfiguration und die FIT-Signatur explizit prüft, merkt, ob die Kette durchgezogen ist oder bei U-Boot endet.

Die saubere Implementierung umfasst mindestens:

• CONFIG_FIT_SIGNATURE=y und CONFIG_SPL_FIT_SIGNATURE=y in der U-Boot-Konfiguration

• Eine eigene PKI-Pipeline für den FIT-Signierungs-Key, getrennt vom SRK

• Public Key als /signature-Node im U-Boot-DTB, mitsigniert durch HAB

• Der Kernel-FIT enthält einen configurations-Block mit signature-Node, verifiziert beim Boot

Stufe 5 wechselt den Mechanismus nochmals, typischerweise auf dm-verity mit einem Hash-Tree, der im signierten initramfs aus Stufe 4 verankert ist.

Was Yocto dazu beiträgt

Yocto integriert den kompletten Signing-Flow reproduzierbar in die Build-Pipeline. Layer wie meta-variscite-hab oder vergleichbare BSP-Erweiterungen kapseln die CST-Aufrufe, CSF-Templates und imx-mkimage-Parameter so, dass aus einem sauber konfigurierten Build am Ende ein signierter flash.bin herausfällt, inklusive signiertem FIT auf Stufe 4. Genauso wichtig für die CRA-Dokumentation: Yocto erzeugt per create-spdx.bbclass oder CycloneDX-Äquivalent eine vollständige Software Bill of Materials. Genau das verlangt Anhang I, Teil II der CRA im Rahmen des Vulnerability-Handling.

Damit verschiebt sich ein großer Teil der Compliance-Arbeit von der Dokumentation in den Build. Was reproduzierbar buildbar ist, ist auditierbar.

Drei Punkte, die in frühen Reviews regelmäßig fehlen

•Key-Management als Produktlebenszyklus-Thema. SRKs müssen über 10 bis 15 Jahre verfügbar, geschützt und rotierbar bleiben. HSM-Integration gehört in die Architektur, nicht in die Panik-Phase kurz vor Serienstart.

•SRK-Revocation aktiv nutzbar halten. HABv4 erlaubt die Sperrung einzelner SRKs über die SRK_REVOKE-Fuses. Wer das von Anfang an in den Feldupdate-Prozess einbaut, kann auf einen kompromittierten Key reagieren, ohne die Geräte einzusammeln.

•Secure Boot ohne Secure Update ist unvollständig. Ein signierter Boot auf den Stufen 1 bis 4 nützt wenig, wenn das OTA-Verfahren eine unsignierte Ersatz-Firmware flashen kann. Die CRA verlangt ausdrücklich sichere, automatisierte Updates und eine klare Trennung zwischen Security- und Feature-Updates.

Die zeitliche Realität

Ein Secure-Boot-Rollout auf einem neuen Produkt ist kein Sprint. Realistisch sind sechs bis zwölf Monate zwischen erstem PKI-Setup und fertigem Serienprozess mit durchgängig signierten Stufen 1 bis 4, funktionierendem Feldupdate, SBOM-Pipeline und Incident-Response-Prozess. Wer die Deadline vom 11. Dezember 2027 treffen will, braucht den fertigen Stack bis Mitte 2027. Die Arbeit beginnt also jetzt, nicht 2027.

Am Beispiel desi.MX8M Mini zeigt sich: Secure Boot ist der Ankerpunkt eines stimmigen Security-Konzepts. Erfahrungen aus Security-Architektur-Projekten nach ISO 21434 im Automotive-Umfeld bestätigen, dass sich eine saubere, TARA-basierte Argumentation direkt auf IoT-Produkte übertragen lässt. Die CRA macht aus dieser Methodik jetzt Pflicht für den gesamten EU-Markt.

Wer heute ein Embedded-Linux-Produkt entwirft und Secure Boot „später” einplant, baut am neuen Markt vorbei.

Werner Böhme ist Geschäftsführer der awb-it GmbH und freier Ingenieur für Embedded Systems und Security. Schwerpunkte: Secure Boot aufi.MX– und XMC-Plattformen, Yocto Linux, CRA-Konformität, ISO 21434.