Zusammenfassung

  • RFC 9019 beschreibt Firmware-Updates als autorisierte entfernte Codeausführung. Eine Signatur authentifiziert Autor und Manifest; ob dieser Autor die verlangte Aktion ausführen darf, entscheidet eine getrennte Richtlinie.
  • Autor, Gerätebetreiber, Netzbetreiber, Nutzer und Trust Provisioning Authority können unterschiedliche Rechte besitzen. RFC 9124 unterstützt mehrere Signaturen, damit verschiedene Rollen gemeinsam eine Installation erlauben können.
  • Ein lokaler Firmware-Änderungsbeleg kann Manifest, Richtlinie, Wartungsfenster, Aktivierung und beobachtetes Ergebnis verbinden. Er ist ein redaktioneller Vorschlag von Daniel Kade, kein neues SUIT-Feld.

Eine gültige Signatur ist starke Evidenz. Sie belegt, dass ein akzeptierter Schlüssel das Manifest geschützt hat und die erfassten Bytes unverändert blieben. Der Payload-Digest verbindet die empfangene Abbildung mit diesen authentisierten Anweisungen. Ohne diese Eigenschaften wäre der Updateweg ein Angriffskanal.

Doch Herkunft und Integrität sind enger als Ausführungsbefugnis. RFC 9019 wurde im April 2021 als IETF Informational RFC veröffentlicht. Das Dokument nennt ein Update „autorisierte entfernte Codeausführung“ und sagt, dass authentisierte Autorenidentitäten in die Autorisierung eingehen, Autoren unterschiedliche Berechtigungen besitzen und das Gerät prüfen muss, ob die verlangte Aktion von der Berechtigung des Unterzeichners umfasst ist.

Ein Vertrauensschlüssel ist daher kein Universalschlüssel. Er kann für eine Geräteklasse, eine Komponente, eine Notfallkorrektur oder einen Zeitraum gelten. Die Signatur beantwortet, wer die Anweisung geschützt hat. Die Richtlinie beantwortet, welche Änderung diese Identität veranlassen darf.

Sequenznummer und Firmwareversion dürfen auseinanderlaufen

RFC 9124 verlangt eine monoton steigende Manifestsequenz, damit ein Angreifer kein älteres, noch gültig signiertes Manifest erneut einspielt. Gleichzeitig stellt es klar: Diese Sequenz ist kein Firmware-Versionsfeld. Ein neues Manifest mit höherer Sequenz darf gezielt eine ältere Firmwareversion autorisieren.

Das ist für kontrollierte Wiederherstellung notwendig. Versagt eine neue Version, kann die zuständige Instanz eine neue Entscheidung treffen und auf ein bekanntes Abbild zurückkehren. Die Autorisierung ist neu, deshalb steigt die Sequenz. Der Softwarestand sinkt, weil genau das beschlossen wurde.

Ein Dashboard, das jede niedrigere Version als Angriff markiert, verwechselt Richtung mit Legitimität. Zu prüfen sind Manifestsequenz, Rückrollberechtigung, Ausgangszustand, Zielgruppe und Begründung. Umgekehrt beweist eine höhere Firmwareversion keine Erlaubnis. Ein überprivilegierter echter Schlüssel kann ebenfalls „neueren“ Code außerhalb seines Mandats liefern.

Manifesthistorie und Versionshistorie erzählen unterschiedliche Geschichten. Die erste dokumentiert Entscheidungen, die zweite ausgeführte Zustände. Gerade im Störfall muss sichtbar bleiben, warum ein älteres Abbild unter einer neueren Entscheidung lief.

Die Architektur kennt mehrere Machtträger

RFC 9019 unterscheidet Autor, Gerätebetreiber, Netzbetreiber, Nutzer und Trust Provisioning Authority, kurz TPA. Die TPA verteilt Trust Anchors und Autorisierungsrichtlinien und darf Rechte delegieren. Der Autor erzeugt das Image; der Betreiber verantwortet den täglichen Betrieb; der Netzbetreiber kontrolliert eine andere Oberfläche.

In einem einfachen Produkt können alle Rollen bei einer Organisation liegen. Eine Signatur kann genügen, wenn die lokale Richtlinie dieser Identität alle nötigen Rechte zuweist. Es gibt keine universelle Forderung nach einem menschlichen Klick oder genau zwei Signaturen.

In einer Lieferkette verteilen sich die Rechte. Ein Funkmodullieferant signiert seine Komponente, aber nicht den Stillstand einer Anlage. Ein Verteildienst transportiert das Image, ohne es erstellen zu dürfen. Ein Sicherheitsteam genehmigt Dringlichkeit, während der Betreiber festlegt, wann ein physischer Prozess unterbrochen werden kann.

Die TPA-Richtlinie ist die Verfassung des Updatewegs. Sie verbindet Schlüssel mit Rollen und Rollen mit Komponenten, Geräteklassen, Aktionen, Grenzen und Delegationen. Ist sie veraltet oder zu breit, kann die Kryptografie vollständig korrekt sein und trotzdem eine unbefugte Änderung zulassen.

Ein Trust Anchor sagt, welcher Schlüssel Evidenz vorlegen darf. Er sagt nicht automatisch, ob der Schlüssel den Bootloader ändern, alle Geräte erreichen, allein handeln oder weitere Rechte delegieren darf. Diese Aussagen benötigen eine aktuelle Richtlinie.

Mehrere Signaturen sind Rollen, keine Stimmen

RFC 9019 verwendet ein Beispiel aus kritischer Infrastruktur: Der authentische Autor kann keine einseitige Installationsbefugnis besitzen. Das Gerät darf sowohl Autoren- als auch Betreibersignatur verlangen. Die zweite Signatur bestätigt nicht noch einmal die Herkunft. Sie fügt die Entscheidung des örtlich Verantwortlichen hinzu.

RFC 9124 verlangt, dass ein Manifestformat mehrere Signaturen tragen kann, damit Parteien mit verschiedenen Berechtigungen gemeinsam die Installation autorisieren. Der Betreiber soll Änderungen an seinen Geräten ausdrücklich billigen und die Interoperabilität der Produktfamilie schützen können.

Bloßes Zählen wäre falsch. Zwei Schlüssel in der Rolle „Autor“ erfüllen keine Regel „Autor plus Betreiber“. Drei allgemeine Signaturen ersetzen keine fehlende Sicherheitsrolle. Der Prüfer muss Rolle, Richtlinienversion, Geltungsbereich und abgedeckte Aktion jeder Signatur bewerten.

Auch Delegation muss erklärt werden. Wer durfte den neuen Schlüssel ernennen, für welche Komponente, bis wann und mit welchem Recht zur Weiterdelegation? Eine gültige Schlüsselkette ist erst dann eine Autorisierungskette, wenn diese Grenzen erhalten bleiben.

Vorautorisierung schützt Ressourcen und Zuständigkeit

Der Firmware Consumer prüft das Manifest und entscheidet, ob er das Image beschaffen soll. RFC 9019 nennt eine Vorautorisierung: Vor weiterem Aufwand wird festgestellt, ob die signierende Instanz das Update durchführen darf. Das spart Bandbreite, Energie und Flashzyklen bei eingeschränkten Geräten.

Die verlangte Aktion hat Struktur. Eine App-Berechtigung deckt nicht automatisch Bootcode. Ein zeitlich begrenztes Notfallmandat gilt nicht dauerhaft. Das Recht für eine Sensorfamilie erstreckt sich nicht auf industrielle Steuerung. Der Payload-Digest schützt die Bytes, definiert aber keine dieser Kompetenzen.

Der Status Tracker kann Verfügbarkeit melden, Geräteeigenschaften empfangen und einen Updateprozess auslösen. Er kann von verschiedenen Akteuren betrieben werden. Die technische Fähigkeit zum Auslösen verleiht weder Autoren- noch Betreiberrechte. Speicherung, Transport, Trigger und Genehmigung bleiben getrennt.

Ebenso bestimmt der Autor nicht automatisch den sicheren Zeitpunkt. Ein echtes dringendes Update kann eintreffen, während ein physischer Prozess nicht unterbrochen werden darf, eine Abhängigkeit fehlt oder kein belastbares Rückfallabbild verfügbar ist.

Authentisch heißt nicht anwendbar

Viele IoT-Produkte enthalten mehrere Mikrocontroller. Eine Änderung kann mehrere Images, Abhängigkeiten, ein genaues Vorgängerabbild, Speicherziele und koordinierte Aktivierung verlangen. RFC 9124 umfasst Hersteller-, Klassen-, Geräte- und Komponentenkennungen, Vorgängerdigests, Abhängigkeiten und Verarbeitungsschritte, weil ein echtes Image zum aktuellen Zustand nicht passen kann.

Ein Differenzupdate scheitert am falschen Vorgänger. Zwei einzeln gültige Komponenten können gemeinsam inkompatibel sein. Ein Abbild für benachbarte Hardware kann korrekt signiert und dennoch abzulehnen sein. Das sind keine Signaturfehler.

Hinzu kommen lokale Bedingungen: stillgelegte Maschine, Reserveenergie, anwesender Techniker, gesunder Canary, aktualisierter Abhängigkeitsdienst. Das gemeinsame Manifest beschreibt gemeinsame Voraussetzungen. Der Betreiber weist nach, dass sein Standort die zusätzlichen Bedingungen erfüllt.

„Verfügbar“, „heruntergeladen“, „gespeichert“, „autorisiert“, „installiert“ und „laufend“ sind verschiedene Zustände. Ein einziges Grün verbirgt den letzten wirklich bewiesenen Übergang.

Update abgeschlossen kann vor dem Neustart liegen

RFC 9019 trennt Consumer und Verifier. Der Consumer verarbeitet das Manifest und speichert das Image. Der Verifier, häufig der Bootloader, prüft es vor der Ausführung erneut. Ist es ungültig, braucht das Gerät eine andere gültige Auswahl oder eine neue Beschaffungsmöglichkeit.

Im Beispielablauf wird „Firmware Update Completed“ gemeldet, bevor Neustart, Secure-Boot-Prüfung und Aktivierung erfolgen. Die Meldung ist für ihre Phase korrekt. Sie kann kein späteres Ereignis beweisen.

Der Bootloader kann ablehnen. Das Gerät kann starten, ohne den Dienst wiederherzustellen. Nur ein Teil der Controller kann wechseln. Recovery kann das alte Image auswählen. Die Verbindung kann vor dem Statusbericht ausfallen. Der Server kennt den dauerhaften Zustand noch nicht.

Erforderlich ist begrenzte Evidenz nach dem Boot: ausgewähltes Image, Komponentensatz, Startresultat, Recoveryzustand und Gesundheit wesentlicher Funktionen. Attestierung kann zeigen, was läuft; sie beweist nicht allein die ursprüngliche Erlaubnis oder ein sicheres physisches Ergebnis.

Ein Beleg für die Firmwareänderung

Der praktische Vorschlag ist ein lokaler, minimierter Beleg, der eine authentisierte Änderung bis zum Ergebnis verfolgt. Er bindet Manifesthash, Payload-Digest, Sequenz, deklarierte Version, Geräteklasse, Komponente sowie Vorgänger- und Abhängigkeitszustand. Dazu kommen Richtlinienversion, Unterzeichnerrollen und erfüllte Freigabemenge.

Danach hält er die Zulassung fest: Kohorte, Wartungsfenster, Standortbedingungen, Canary-Ergebnis, Recoverypfad, Verantwortlicher und Entscheidung. Schlüssel, detaillierte Gerätekennungen, Topologie und Schwachstellenlage gehören in geschützte Verweise, nicht in ein öffentliches Inventar.

Schließlich trennt er Download, Speicherung, Installation, Verifier-Annahme, Aktivierung, Gesundheit und Wiederherstellung. Bei bewusstem Rückgang nennt er das höher sequenzierte Manifest und den endgültigen Laufzustand. Zeitweilige Rechte und Delegationen werden geschlossen.

Der Beleg ist ein redaktioneller Vorschlag von Daniel Kade, kein SUIT-Element, keine IETF-Pflicht, kein Remote-Befehl und kein TPA-Produkt. Er verhindert, dass exakte Kryptografie Fragen außerhalb ihres Geltungsbereichs entscheidet.

Der in RFC 8240 dokumentierte IoTSU-Workshop bewahrte Fragen zu Eigentum, Zustimmung, Recovery, Supportende und Erfolgsmessung. Der Bericht ist keine Norm. Er zeigt jedoch, warum der Lebenszyklus nie in einer Signatur aufging.

Heng Lus Ansatz trennt Mindeststandard, lokale Entscheidung, freiwillige Übernahme, laufende Ausführung und beobachtetes Ergebnis. RFC 9019 und RFC 9124 liefern die gemeinsame Sprache. Die lokale Richtlinie verteilt Macht, das Gerät führt aus, Beobachtung schließt oder öffnet die Entscheidung erneut.

Eine höhere Sequenz kann bewusst ältere Software tragen. Entscheidend ist, wer genau diese Änderung autorisiert hat.

Quellen