Zusammenfassung

  • Für Remote Attestation muss ein Bericht unter Umständen vor SUIT_Command_Invoke signiert werden; suit-report-reason-invoke-pending behauptet deshalb kein späteres Ergebnis.
  • SUIT_Record enthält komprimierte Wegpunkte. Erst das exakt per Digest gebundene Manifest macht Sequenz, Offset und Komponentenindex interpretierbar.
  • Ein belastbarer Abschluss braucht getrennte Belege für Freshness, Berichtsumgebung, Kontrollübergabe, erste Ausführung, Dauerbetrieb und Servicewirkung.

Der Sprung hinter die Beobachtungsgrenze

Der Manifest Processor hat Bedingungen ausgewertet und Befehle abgearbeitet. Jetzt soll er den aktualisierten Code aufrufen. Dieser Aufruf kann die Kontrolle dauerhaft übertragen. Was danach geschieht, ist für den bisherigen Prozessor möglicherweise nicht mehr sichtbar.

Attestation Evidence muss jedoch noch in der vertrauenswürdigen Umgebung signiert werden. Das verleitet dazu, vor dem Sprung bereits success einzutragen. Der Bericht wäre sauber geschützt, seine Aussage aber zeitlich falsch.

draft-ietf-suit-report-22 führt deshalb suit-report-reason-invoke-pending ein. Die Invocation steht unmittelbar bevor; ihr endgültiger Ausgang ist unbekannt. Der Text sagt ausdrücklich, ein bedingungsloser Erfolgswert wäre irreführend, falls der Aufruf später scheitert.

Dieser Status ist weder Fehlerdiagnose noch Erfolg mit Vorbehalt. Er markiert, bis zu welchem Zeitpunkt der signierende Teil des Systems tatsächlich Kenntnis hatte.

Ein Wegpunkt benötigt seine Karte

Der Bericht spart Platz, indem er das Manifest als Wörterbuch nutzt. Ein Record nennt den Pfad im Abhängigkeitsbaum, die aktive Command Sequence, einen Byte-Offset, den Komponentenindex und gemessene Eigenschaften. Er wiederholt den vollständigen Befehl nicht.

Folglich darf ein Empfänger die Records nur mit dem passenden Manifest rekonstruieren. Dieses muss über suit-report-manifest-digest validiert werden. Existiert im Root Manifest eine Referenz-URI, muss der Bericht denselben Wert tragen. Ohne das passende Manifest verbietet der Entwurf die Rekonstruktion.

Eine Sequence Number genügt nicht. Bei mehreren vertrauenswürdigen Signierern kann dieselbe Nummer mehrfach vorkommen. Der charakteristische Digest identifiziert dagegen die konkreten Bytes, in denen Offset und Index ihre Bedeutung erhalten.

system-property-claims können früher verarbeitet werden, weil sie eine Component Identifier direkt enthalten. Diese Ausnahme bestätigt, dass ein nackter Index keine selbsttragende Identität ist.

Archivierung muss daher Bericht und Manifest gemeinsam behandeln. Ein authentischer Bericht ohne Wörterbuch bleibt unverändert, aber nicht mehr zuverlässig auswertbar.

Gültig, frisch und trotzdem unvollständig

Ein Nonce kann Freshness und Replay-Schutz liefern. Liefert der authentifizierende Container bereits Freshness, etwa durch eine Attestation Challenge, darf das Feld fehlen.

Die Kontrollen beantworten verschiedene Fragen. Die Signatur schützt Herkunft und Integrität. Freshness ordnet die Aussage der aktuellen Sitzung zu. Der Digest bestimmt das Manifest. Die Messungen qualifizieren die Software, die den Bericht erzeugte. Der Result-Wert begrenzt schließlich die Aussage zum Signaturzeitpunkt.

Ein frisches invoke-pending bleibt offen. Ein alter success kann echt sein und zum falschen Boot gehören. Ein exakter Digest kann mit einer nicht akzeptierten Berichtsumgebung kombiniert sein.

Ein einziges Label „verified“ verschweigt diese Unterschiede.

Auch der Beweiserzeuger wird geprüft

Soll ein SUIT Report als Attestation Evidence dienen, muss seine Erzeugungsumgebung gemessen sein. Revision 22 nennt Manifest Processor, Report Generator sowie relevante Bootloader und Betriebssysteme.

Die Maßnahme verhindert, dass allein der Schlüssel den Erzeuger legitimiert. Ein veränderter Generator könnte mit einem gültigen Schlüssel eine konsistente Geschichte signieren. Die Containerprüfung zeigt dann Unversehrtheit, nicht die Erwartungskonformität des Produzenten.

RFC 9334 trennt Attester, Verifier und Relying Party. Der Attester liefert Evidence. Der Verifier bewertet sie nach einer Policy und erzeugt Attestation Results. Die Relying Party entscheidet. Im SUIT-Fall rekonstruiert der Verifier zusätzlich mit dem passenden Manifest die Wegpunkte und übersetzt sie in auswertbare Claims.

Die Entscheidung über Vertrauen bleibt lokal. Sie entsteht nicht automatisch durch ein korrektes COSE-Objekt.

Sichere Übertragung bewahrt die Aussagegrenze

Remote Reports benötigen einen authentisierten und vertraulichen Kanal oder gleichwertigen Schutz. EAT, COSE und sichere Transportprotokolle sind mögliche Wege. Verlangt die lokale Policy Authentisierung, darf der Recipient keinen unauthentisierten Ersatz senden; ein Teilbericht unterliegt derselben Integritätspolitik.

Das verhindert Spoofing, Veränderung und Offenlegung. Es macht aus „gleich wird aufgerufen“ aber nicht „ist erfolgreich gelaufen“.

Nach der Übergabe braucht der Betrieb neue Zeugen: Erreichen des Entry Points, Lebenszeichen über die geforderte Dauer und eine Beobachtung der Servicewirkung. Jeder Zeuge sollte seine Reichweite offenlegen.

Ein Abschluss mit mehreren Quittungen

Zu sichern sind Originalbytes, Schutzverfahren, Signierer, Validierung und Freshness-Mechanismus. Danach folgen Root-Manifest-Digest, exaktes Manifest und rekonstruierter Pfad. Anschließend werden Processor, Generator, Bootloader und OS anhand ihrer Messungen bewertet.

Der ursprüngliche Status bleibt erhalten: success, expliziter Fehler, implizite Übergabe oder invoke-pending. Laufzeitbelege werden angehängt, nicht rückwirkend in den Bericht geschrieben.

authentischer Bericht → Freshness → exaktes Manifest → Rekonstruktion → gemessene Umgebung → Übergabe → Ausführung → Servicewirkung

Beim Rechercheabschluss war Revision 22 ein aktiver Internet-Draft mit Ziel Proposed Standard. Sie befand sich in der RFC-Editor-Warteschlange und war durch eine Referenz zweiter Generation blockiert. Sie war kein RFC und kein Implementierungsnachweis.

Quellen