Eine Boot-Kette kann Signaturen korrekt verifizieren und trotzdem umgehbar sein. Alternative Boot-Quellen, Debug-Zustände, Recovery-Images, veraltete vertraute Schlüssel oder Downgrade-Pfade können einen gültigen Weg zu Code schaffen, den das Design ausschließen wollte. Die Security-Eigenschaft hält nur, wenn jeder Übergang von unveränderlichem Trust zu veränderbarer Firmware die intendierte Policy bewahrt.
Der Fehler liegt selten in der Kryptografie. Er liegt in den Übergängen: ein Bootloader, der seinen Nachfolger verifiziert, aber nicht die Konfiguration, die er liest; ein Recovery-Modus, der ein älteres signiertes Image akzeptiert; ein Debug-Zustand, der die Produktion überlebt; ein Trust-Anker, der ohne Verifikation aktualisiert werden kann. Jedes Glied ist isoliert vertretbar, die Kette bricht, wo sie sich treffen.
Deshalb sagt „Signatur-Verifikation aktiviert“ auf einer Feature-Liste fast nichts. Die sinnvolle Frage ist: Welche Pfade existieren von Reset zur Ausführung, und erzwingt jeder von ihnen dieselbe Policy.
Die Security-Eigenschaft hängt von mehreren technischen Annahmen ab.
- Root of Trust Wo die erste unveränderliche Trust-Entscheidung liegt und wie sie konfiguriert ist (OTP, Fuses, ROM).
- Boot-Stufen-Verifikation Welche Stufen die nächste Komponente verifizieren und welche Metadata die Signatur abdeckt.
- Alternative Boot-Pfade USB, Recovery, Service, Fallback, externer Flash oder Wechselmedien als Wege zur Code-Ausführung.
- Rollback-Policy Ob ältere, aber gültig signierte Images irgendwo in der Kette akzeptabel bleiben.
- Debug- und Lifecycle-Zustand Ob Produktionseinstellungen abschwächbar, umgehbar oder im Development-Modus belassen sind.
- Key-Lifecycle Wie Trust-Anker provisioniert, ersetzt oder widerrufen werden, und ob alte Keys weiterhin Boot autorisieren.
- Verifikations-Logik Ob die Implementierung prüft, was das Design annimmt, einschließlich Metadata und Konfiguration.
Die Signatur ist gültig; die Trust-Policy ist es nicht.
Die ROM verifiziert den Bootloader. Der Bootloader verifiziert die Firmware. Jede Prüfung gelingt. Der Recovery-Pfad akzeptiert dann ein älteres Image, gültig vom Hersteller signiert, aber mit einer bekannten Schwachstelle, die vor zwei Releases gefixt wurde.
Signierte, angreifbare Firmware läuft. Keine Prüfung ist fehlgeschlagen, die Policy, die das Image hätte ausschließen sollen, wurde auf diesem Pfad nie ausgeführt.
Die Annahme im implementierten Produkt verifizieren.
Wir mappen die implementierte Boot-Kette, identifizieren Trust-Entscheidungen und alternative Ausführungspfade, und testen dann die Annahmen, die den Übergang von Reset zu vertrauter Firmware schützen. Das kann Hardware-Konfiguration, Bootloader- und Firmware-Analyse, Recovery-Testing und kryptografischen Review umfassen.
- Neue Secure-Boot-Implementierung
- Neuer MCU, SoC oder Bootloader
- Produkt wechselt von Development zu Production-Lifecycle
- Recovery-Mechanismus hinzugefügt oder geändert
- Signing-Key-Migration
- Anti-Rollback-Verhalten muss vor Release verifiziert werden