Zusammenfassung

  • Ein measured component enthält stabilen Namen, optionale Version, Rohwert oder algorithmusgebundenen Digest und optional IDs von Stellen, die die Komponente signieren oder autoritativ identifizieren. Diese IDs benennen nicht den Attester des umschließenden EAT.
  • Bedeutung und Reihenfolge von authorities sowie 64 Profil-Flags werden im EAT-Profil festgelegt. Kennt ein Consumer das Profil nicht und sieht diese Felder, muss er das Token ablehnen.
  • Der belastbare Beleg verbindet Messziel, Wert, Komponentensignierer, Profil, äußere Signatur, Frische, Referenzen, Verifier-Policy, Ergebnis und die eigene Autorisierung der Relying Party.

Bei einer Sicherheitsprüfung sind zwei grüne Häkchen sichtbar: „component signature valid“ und „token signature valid“. Das Interface legt nahe, dass derselbe Akteur zweimal bestätigt wurde. Das Protokoll sagt etwas anderes.

RFC 10013 erschien im Juli 2026 als Standards-Track-Dokument von Simon Frost, Thomas Fossati, Hannes Tschofenig und Henk Birkholz. Der IETF-Datatracker dokumentiert Tschofenigs langjährige Sicherheitsarbeit; die Universität der Bundeswehr München nennt ihn seit März 2026 Professor für Secure Networks. Das belegt Beitrag und aktuelle Rolle, nicht Alleinautorschaft oder Herrschaft über Deployments.

Die Messung bleibt vor der Bewertung

Eine gemessene Komponente kann Firmware, Bootloader, geladenes Programm, Datei, Konfiguration oder CPU-Register sein. Der Name ist obligatorisch, die Version optional. Der Wert ist roh oder ein Digest mit Algorithmus.

Optional kommen authorities und acht Byte Profil-Flags hinzu. Keine dieser Strukturen beweist, dass die richtige Zielumgebung gemessen wurde, dass der Sammler unverfälscht war, die Probe frisch ist oder der Referenzwert für den aktuellen Zweck gilt.

Ein passender Hash kann aus einem alten Zustand wiederholt werden. Ein falsches Ziel kann korrekt vermessen werden. RFC 9711 verlangt für EAT Authentizität und Integrität, verspricht aber kein einheitliches Sicherheitsniveau der Claims oder Attester. Ein starker Umschlag kann schwache Beobachtung tragen.

Die Authority-ID gehört zur Komponentensignatur

RFC 10013 beschreibt eine Authority als Stelle, die eine Komponente durch digitale Signatur autoritativ identifizieren kann. Die Prüfung erfolgt etwa bei Installation oder Ausführung. Die ID kann Zertifikat, Raw Public Key, Thumbprint oder eine andere schlüsselgebundene Kennung sein.

Unmittelbar danach begrenzt der Text die Aussage: Diese Signatur ist nicht die Attester-Signatur auf den EAT-Evidence. Eine Authority-ID zeigt daher nicht von selbst auf den Signierer des umschließenden Tokens.

Firmware-Autor, Update-System, Flotteneigentümer und Prüfer können Komponenten genehmigen. Später misst eine Attesting Environment den Target-Zustand und signiert Evidence. Die Akteure können derselben Organisation angehören; daraus folgt keine technische Gleichheit.

RFC 9019 trennt auch bei Updates Authentifizierung und Erlaubnis. Ein gültiger Autor kann eine Firmware signieren, während eine kritische Anlage zusätzlich Betreiberfreigabe verlangt. Eine nachweisbare Stimme erhält nicht automatisch das Mandat der nächsten.

Das Profil ist der notwendige Schlüssel zur Bedeutung

Mehrere Authorities können in einer Reihenfolge stehen, deren Sinn vom Deployment abhängt. Auch die 64 Flags haben keine universelle Semantik. Der Parser erkennt Positionen, nicht Rollen.

Darum muss das EAT-Profil erklären, ob Authorities genutzt werden, wofür jeder Eintrag steht und wie er interpretiert wird. Dasselbe gilt für Flags. Ist das Profil unbekannt und eines der Felder vorhanden, verlangt RFC 10013 Ablehnung.

Der Consumer darf Unbekanntes nicht wegwerfen, die Reihenfolge eines anderen Produkts übernehmen oder eine gültige Außensignatur als Ersatz verwenden. Die Signatur schützt Bytes, nicht deren nicht vorhandenes Wörterbuch.

Hier wirkt Minimum Initial Specification: Die gemeinsame Ebene normiert das portable Format und eine klare Grenze gegen Raten. Lokale Rollen bleiben im lokalen Profil. Interoperabilität entsteht durch benannte Semantik, nicht durch eine globale Authority-Fiktion.

Damit wird die Reihenfolge des Rollouts relevant. Sendet der Producer ein neues Profil zu früh, lehnt der konforme Verifier ab. Akzeptiert ein Verifier unbekannte Felder still, liefert er zwar Verfügbarkeit, aber keine erklärbare Entscheidung.

Nach dem Attester entscheidet noch der Resource Owner

Der Attester erzeugt Evidence und schützt sie; Nonce oder andere Mittel sichern Frische. Der Verifier prüft Schlüsselherkunft, Target-Bindung und Attesting Environment, vergleicht Claims mit Reference Values und führt seine Appraisal Policy aus.

Das Ergebnis ist ein Attestation Result. Nach RFC 9334 wendet die Relying Party ihre eigene Policy auf Ressource und Operation an. Ein gesundes Gerät kann der falschen Organisation gehören. Eine freigegebene Komponente kann für Telemetrie geeignet, für Steuerung aber unbefugt sein.

Vier Principals bleiben getrennt: Component Authority, Attester, Verifier und Resource Owner. Kein gemeinsames Token macht den einen zum Vertreter des anderen. Das ist die Agency-Grenze innerhalb der technischen Kette.

Stabiler Name, stabile Korrelation

Ein gleichbleibender Komponentenname erleichtert Updates und Vergleiche. RFC 10013 warnt zugleich, dass Name und Version Software oder Konfiguration offenlegen und Stabilität Tracking ermöglichen kann.

Wiederverwendete Authority-Key-IDs verstärken die Korrelation. Das Profil sollte festlegen, wer Details benötigt. Ein Verifier kann Rohmessungen erhalten, während die Relying Party nur ein begrenztes, zeitgebundenes Resultat braucht.

Datenminimierung bedeutet nicht, Auditmaterial zu vernichten. Sie trennt die intern reproduzierbare Akte von einer unnötig globalen Gerätekennung.

Der reproduzierbare Beleg

Bewahren Sie EAT oder Content-Object, Media Type, Encoding, Profil und Version auf. Notieren Sie äußeren Algorithmus, Attester-Key, Herkunft des Verifikationsschlüssels, Nonce, Sammel- und Empfangszeit sowie Verifier-Version.

Für jede Komponente folgen Name, Versionskonvention, Target, Sampling-Grenze, Raw/Digest, Algorithmus und Wert. Authority-Reihenfolge, Profildefinition, Komponentensignatur und Ergebnis bleiben verknüpft. Flags werden roh und dekodiert gespeichert.

Die Appraisal-Akte nennt Reference-Value-Provider, Set/Version, Vergleiche, fehlende Messungen, Policy/Version und exaktes Attestation Result. Die Relying Party ergänzt Ressource, Operation, Policy, Entscheidung, Einschränkungen, Ablauf und Remediation.

So unterscheiden sich unbekanntes Profil, nicht akzeptierter Komponentensignierer, ungültige Außensignatur, alte Evidence, Digest-Abweichung und „compliant, aber nicht autorisiert“. Jeder Zustand hat einen anderen Owner.

Running-Code Primacy verlangt die Beobachtung dessen, was die Implementierung tatsächlich tat. Ein Pass/Fail ohne Eingaben und Policies beseitigt diese Beobachtbarkeit.

Quellen