Secure Boot vs. Firmware Signing vs. Code Signing: Die Unterschiede erklärt

Die drei Begriffe werden in Roadmaps und Vendor-Decks synonym verwendet, und diese Verwechslung ist teuer: Teams beschaffen Signing-Infrastruktur und nennen es Secure Boot, oder sie aktivieren Secure Boot und nennen ihr Update-Mechanismismus sicher. Dabei sind es drei verschiedene Controls, an drei verschiedenen Stellen des Systems, die drei verschiedene Fragen beantworten. Diese Note trennt sie, und zeigt, was jede einzelne für ein Produkt wirklich leistet.

Code Signing: eine Aussage über Ihre Pipeline

Code Signing passiert zur Build-Zeit, auf Ihrer Infrastruktur. Der Build-Server oder ein dedizierter Signing-Service hasht ein Artefakt. Binary, Container-Image, Paket, und erzeugt eine Signatur mit einem Private Key, der in einem HSM oder Signing-Service liegt. Die Aussage der Signatur: Dieses Artefakt stammt unverändert aus dieser Pipeline.

Diese Aussage ist real und wertvoll. Sie ist auch komplett serverseitig. Eine Signatur im Release-System sagt nichts darüber, was ein beliebiges Gerät im Feld mit dem Artefakt macht. Code Signing ist eine notwendige Zutat für Produkt-Sicherheit, und schützt für sich genommen exakt nichts auf dem Gerät.

Firmware Signing: eine Aussage über Ihr Update

Firmware Signing ist Code Signing, angewandt auf den Update-Pfad. Der Release-Prozess signiert das OTA-Paket: Image, Manifest, Versions-Metadaten. Lädt ein Gerät ein Update, kann es das Paket gegen einen Public Key verifizieren, bevor es auf Flash schreibt. Die Aussage: Dieses Update ist authentisch und vollständig.

Zwei Eigenschaften trennen Firmware Signing von einem generischen Signaturschritt. Erstens: Die Verifikation läuft auf dem Gerät, im Updater, der Updater ist damit Teil Ihrer Trust-Grenze und verdient dieselbe Prüfung wie die Boot-Kette. Zweitens: Das Paket trägt meist mehr als ein Image. Version, Ziel-Hardware, Abhängigkeiten. All das zusammen zu signieren verhindert, dass ein Angreifer ehrliche Komponenten zu einem unehrlichen Ganzen mischt, etwa das Versionsfeld zurückzusetzen und das Image zu behalten. Und selbst das verhindert keinen Rollback, wie wir in Firmware Anti-Rollback behandeln: Ein altes, voll gültiges, voll signiertes Paket ist exakt so authentisch wie das neue.

Secure Boot: Erzwingung auf dem Gerät

Secure Boot ist die einzige der drei Controls, die lokal bei jedem Start erzwungen wird. Die Boot-ROM verifiziert jede Stage gegen einen im Silizium verankerten Key, bei jedem Boot, offline, ganz gleich, ob je ein Update kam. Die Aussage: Dieses Gerät verweigert Software, die der Hersteller nicht signiert hat.

Das ist eine viel stärkere Eigenschaft als Signing allein, und eine viel engere, als Teams annehmen. Secure Boot kennt nur die Artefakte in der verifizierten Kette. Konfiguration, Device Trees, beschreibbare Root-Filesysteme und Co-Prozessor-Firmware liegen außerhalb, solange die Kette sie nicht explizit abdeckt (siehe Secure Boot: Was die Signaturprüfung schützt).

Wer verifiziert was, und wo die Keys liegen

Die drei Controls implizieren drei Key-Estates, und diese altern unterschiedlich:

• Build-Signing-Keys schützen die Pipeline-Integrität. Ein Compromise bedeutet: Angreifer können eigene Artefakte als Ihre ausgeben. Rotation ist ein Release-Prozess-Ereignis, schmerzhaft, aber beherrschbar.
• Release-/Firmware-Signing-Keys schützen Updates. Ein Compromise bedeutet: Angreifer können der Flotte „Updates" unterjubeln. Rotation erfordert eine Story für Geräte, die nur dem alten Key vertrauen, hier wird Key-Rotation zur Produkt-Architektur.
• Der Device-Root-of-Trust (der Public-Key-Hash in OTP/eFuse) schützt die Boot-Kette. Er ist bewusst schwer änderbar, was bedeutet: Der Key, auf den er zeigt, muss über eine sauber designte, verifizierte Kette rotierbar sein. Sonst ist Ihre Wurzel ein permanenter Single Point of Failure.

Warum Sie alle drei brauchen

Jede Control fällt anders aus, und sie decken die Fehlermodi der anderen ab. Ein signiertes Update (Firmware Signing) begrenzt, was ein Angreifer übers Netzwerk injizieren kann, aber ein kompromittierter Updater könnte trotzdem direkt auf Flash schreiben; Secure Boot fängt das Ergebnis beim nächsten Boot. Secure Boot verweigert unsignierten Code, aber wenn Ihre Build-Pipeline ungekontrolliert ist, kommt „unsignierter Angreifer-Code" gar nicht vor: Der Angreifer liefert innerhalb Ihrer Signaturen. Code Signing diszipliniert die Pipeline, Firmware Signing den Kanal, Secure Boot das Gerät.

Wenn wir ein Produkt bewerten, rekonstruieren wir, welche der drei tatsächlich existieren, nicht, welche im Security-Konzept stehen. Ein überraschend häufiges Ergebnis: zwei von drei, und die Lücke exakt auf der Schicht, die niemand demonstriert hat. Die Frage lautet nie „Signieren Sie Ihre Firmware?" Sie lautet: Was verifiziert sie, wo, und was passiert, wenn diese Verifikation fehlschlägt?