Zusammenfassung

  • RFC 10013 definiert für eine gemessene Komponente einen Pflichtnamen und einen Roh- oder Digestwert. Version, Komponenten-Signaturautoritäten und profilabhängige Flags sind optional; JSON und CBOR können die Struktur in einem EAT Measurement Claim transportieren.
  • Die Komponentenautorität signiert nicht automatisch das umschließende EAT. Ein Digestvergleich belegt nur Gleichheit für die gewählte Eingabe, und ein positives Attestation Result belegt weder Eigentum noch Enrollment noch Zugriff auf eine bestimmte Ressource.
  • Nachvollziehbarkeit verlangt die gesamte Kette: Messobjekt und Zeitpunkt, Collector, Attester und Frische, Profil, Reference Value, Verifier-Richtlinie, Attestation Result, Autorisierungsregel der Relying Party und beobachtete Wirkung.

Das Ersatzgerät ist echt — und bleibt draußen

Ein Ersatzsteuergerät soll nach einer Wartung in ein Produktionssegment aufgenommen werden.

Es liefert ein frisches, mit dem erwarteten Attester-Schlüssel signiertes EAT. Die gemessene Komponente nennt den Bootloader, enthält eine bekannte Version und einen SHA-256-Digest, der zum Produktionsreferenzwert passt. Zwei Einträge im authorities-Array entsprechen zugelassenen Firmware-Signierern. Das Profil ist bekannt, der Verifier meldet compliant.

Trotzdem darf die Zugriffssteuerung nicht automatisch Schreibrechte erteilen.

Möglicherweise lag die veränderliche Ladepolicy außerhalb der Messgrenze. Vielleicht akzeptiert der Reference-Value-Satz noch eine seit gestern verwundbare Version. Das Gerät kann technisch gesund und dennoch nicht im Eigentum oder Bestand des Betreibers sein. Es kann Telemetrie liefern dürfen, ohne Prozesswerte zu ändern. Auch die Reihenfolge der authorities kann nur in einem bestimmten Profil eine definierte Bedeutung besitzen.

Die Beweise können korrekt sein, während die Berechtigung fehlt.

RFC 10013 wurde im Juli 2026 auf dem IETF Standards Track veröffentlicht. Er standardisiert die Beschreibung eines abgetasteten Komponentenzustands. Die Spezifikation transportiert Evidenz; sie erteilt kein universelles Vertrauensmandat.

Vor dem Digest steht die Auswahl

Eine gemessene Komponente kann Firmware im Flash, beim Start geladenen Code, eine Laufzeit-Integritätsprüfung, ein Dateisystemobjekt, eine Konfiguration oder ein CPU-Register bezeichnen.

RFC 9393 modelliert mit CoSWID Softwareidentität und Lebenszyklus. Frühstartzustände, Register und nicht dateibasierte Objekte passen nicht immer in ein Softwareinventar. RFC 10013 schließt diese Darstellungslücke.

Er definiert nicht, welche Bytes einzubeziehen sind.

Der Plattformentwurf zieht die Grenze; der Collector liest den eingeschlossenen Zustand. Geschützte Hardware kann die Erhebung absichern, aber keinen ausgelassenen Zustand ergänzen. Ein korrekter Hash über den falschen Ausschnitt bleibt korrekt und unzureichend.

Produktionsnachweise brauchen deshalb Target Environment, Grenze, Collector, Messzeit oder boot epoch und absichtlich ausgeschlossene Abhängigkeiten. „Secure Boot bestanden“ ist ein Ergebnislabel, kein reproduzierbares Messprotokoll.

Running-Code Primacy ordnet die Ebenen: Die Norm liefert gemeinsame Semantik. Betriebsevidenz zeigt, was gelesen, ausgeführt und tatsächlich freigegeben wurde.

Stabiler Name, lokaler Bedeutungsraum

Der Komponentenname ist obligatorisch und menschenlesbar; seine Konvention hängt vom Typ ab. Konsistenz über Releases unterstützt die Verfolgung von Updates. Daraus entsteht kein globaler Namensraum.

Verschiedene Hersteller dürfen ähnliche Namen verwenden. Der Pfad /boot/loader.bin kann bestehen bleiben, obwohl Inhalt oder Rolle wechseln. Ohne Herausgeber und Namensschema kann ein Verifier den falschen Referenzsatz wählen.

Die Version ist optional und kann CoSWID-Schemata wiederverwenden. Semantic Versioning wird im Informationsmodell empfohlen, aber nicht für Register, Konfigurationsblobs und sämtliche Firmware vorgeschrieben.

Stabilität schafft zudem eine Datenschutzspur. Name und Version können Produkt, Patchstand und Konfiguration verraten und ein Gerät über Zeit korrelierbar machen.

Rohwert und Digest begrenzen verschieden

Der Messwert ist roh oder gehasht. Ein Rohwert kann wenige Bytes oder eine große Konfiguration umfassen. Decoder dürfen den Speicher begrenzen; andernfalls wird die Evidenz zum Ressourcenangriff und zur Ablage sensibler Daten.

Beim Digest gehören Algorithmuskennung und Wert zusammen. Die Kennung folgt dem IANA-Register Named Information Hash Algorithms; RFC 10013 verlangt eine starke kryptographische Hashfunktion.

Diese Stärke schützt die konkrete Gleichheitsprüfung. Sie belegt weder Messvollständigkeit noch Referenzqualität, Messzeit, Attester-Schutz oder Zugriffsrecht.

Zwei Signaturen, zwei Aussagen

Eine authority in RFC 10013 kann eine installierte Komponente durch digitale Signatur autoritativ identifizieren. X.509-Zertifikat, Raw Public Key oder Fingerprint können als Kennung dienen. Die Prüfung erfolgt etwa bei der Installation nach einer Architektur wie RFC 9019, beim Boot oder durch einen Launcher.

Diese Signatur ist ausdrücklich nicht die Attester-Signatur über das EAT.

Die Komponentensignatur belegt Provenienz oder Freigabe des Artefakts. Die EAT-Signatur schützt die Claims und bindet sie an eine Attesting Environment. Wer beide zusammenfasst, verliert die Aussage darüber, wer den Zustand beobachtet hat.

Mehrere authorities können Update-System, Flotteneigentümer und Prüfer repräsentieren. Ihre Reihenfolge kann eine Rolle spielen. Das EAT-Profil muss Einsatz, Semantik und Kodierung jedes Eintrags bestimmen.

Flags sind genau acht Byte lang, doch kein Bit besitzt im Basisstandard eine allgemeine Bedeutung. Enthält ein EAT authorities oder flags und kennt der Consumer das Profil nicht, muss er es ablehnen. Eine vermutete Bitbelegung ist keine robuste Abwärtskompatibilität.

Registrierung macht dekodierbar, nicht vertrauenswürdig

CBOR-EAT kann CBOR-Komponenten homogen tragen oder JSON tunneln; JSON-EAT kann JSON direkt tragen oder CBOR in base64url einbetten. IANA registriert application/measured-component+cbor und application/measured-component+json. Das CoRE-Content-Formats-Register vergibt 295 und 296.

Damit ist der Decoder bestimmbar, nicht das Urteil.

Die Aufteilung entspricht Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption: Gemeinsame Felder und Kodierungen bleiben schmal; Profil, Referenzen, Bewertung und Konsequenz bleiben explizite lokale Entscheidungen.

Die offizielle Errata-Suche zu RFC 10013 zeigte am 30. August 2026 keinen Treffer. Das ist ein zeitgebundener Registerstand, kein Implementierungstest.

EAT vereinheitlicht Claims, nicht Schutzstufen

RFC 9711 sagt ausdrücklich: Die Claim-Semantik schreibt kein bestimmtes Sicherheitsniveau der Implementierung oder des Attesters vor. Der Empfänger beurteilt Trustworthiness anhand der Herstellerimplementierung und/oder der Verifier-Verarbeitung.

Ein Hardware-Anker und eine gewöhnliche Anwendung können syntaktisch gleiche EATs liefern und unterschiedlich starke Evidenz erzeugen.

Jeder EAT-Einsatz benötigt Frische gegen Replay. Ein neues Token kann jedoch einen beim Boot erhobenen Wert enthalten. Messzeit, Ausgabezeit und boot epoch müssen getrennt bleiben.

Der Claim measres beschreibt das Ergebnis einer Referenzwertprüfung — Erfolg, Fehler, nicht ausgeführt oder abwesend — und ist laut RFC 9711 nicht das Gesamtergebnis eines Verifiers. measres=success als „Gerät vertrauenswürdig“ auszugeben, erweitert das Feld unzulässig.

RFC 9783 zum PSA Attestation Token zeigt mögliche Policies: exakter Messwert, zulässige Releasefolge oder anerkannter Signierer. Diese Regeln gewähren unterschiedliche Freiräume.

Der Verifier bewertet, die Relying Party autorisiert

RFC 9334 trennt die RATS-Rollen. Der Attester erzeugt Evidence. Der Reference Value Provider liefert Sollwerte. Der Endorser bürgt für bestimmte Fähigkeiten. Der Verifier wendet Appraisal Policy for Evidence an und erzeugt Attestation Results. Die Relying Party entscheidet über konkrete Daten oder Aktionen.

Eine Implementierung darf Rollen bündeln. Die Entscheidungen bleiben unterscheidbar.

Reference Values besitzen Provider, Version, Gültigkeitsbeginn und Rücknahme. Nach einer Schwachstellenmeldung kann derselbe Digest unzulässig werden, ohne dass sich das Gerät ändert. Die Referenzverwaltung übt damit Remote-Autorität über eine Flotte aus.

Der Verifier übersetzt herstellerspezifische Evidence in nutzbare Resultate. Das konzentriert Vertrauen; Ergebnis, Identität, Policy-Version, Evidence-Stärke und Frische müssen zusammenbleiben.

Gesundheit ist keine Berechtigung. RFC 9334 beschreibt, dass ein Unternehmen gesunde Geräte eines Herstellers erkennen und dennoch nur eigene Geräte zulassen kann. Ein gesundes Fremdgerät bleibt fremd.

Die Relying Party kennt Ressource, Operation, Enrollment, Eigentum, Konto und Schadenshöhe. Ein Attestation Result ist ein Eingangswert, kein Zugriffsbescheid.

Der Auditpfad besteht aus Übergängen

Messgrenze → Collector und Zeit → Wert → Name/Version → Bedeutung der authorities → EAT-Signierer/Frische → Profil → Reference Value → Verifier-Policy/Resultat → Relying-Party-Policy → Freigabe → Wirkung.

Ein Boolean kann diesen Pfad nicht ersetzen.

Nach einem Vorfall müssen fehlende Messung, veraltete Referenz, fehlerhaftes Appraisal und überbreite Autorisierung auseinanderfallen. Ohne Zwischenschritte verweisen alle Teams auf denselben grünen Status.

Heng Lus Analyse von Realitätsschichten und symbolischer Macht erklärt das Risiko: Name, Digest, Signatur und Resultat repräsentieren ausgewählten Zustand. Ihre Autorität hängt davon ab, dass sie nicht mit der ganzen laufenden Realität verwechselt werden.

Messdaten wandern weiter als das Gerät

Name und Version offenbaren Software und Patchstand; stabile Benennung ermöglicht Tracking. Rohwerte können Konfigurationen preisgeben.

Entschlüsselt ein Consumer das EAT und verteilt Claim-Teilmengen, ist der ursprüngliche Schutz entfernt. RFC 9711 verlangt gleichwertigen Kommunikationsschutz und minimale Offenlegung.

Die praktische Ebene der Datensouveränität erfordert eine Liste aller Verifier, Logs, Traces, Analytics- und Supportsysteme. Hardwareeigentum kontrolliert nicht automatisch die Kopien ihres Zustands.

Jeder Consumer erhält nur den Zweckbedarf: ein begrenztes Attestation Result für Zugriff, eine Version für Remediation, nicht stets Rohkonfiguration und dauerhafte Gerätekennung.

Die Norm endet an der richtigen Stelle

RFC 10013 standardisiert Objekt, JSON/CBOR, Profilpflicht, starke Digests, Ablehnung unbekannter Semantik und Datenschutzwarnungen. Er erklärt kein Gerät für gut.

Collector, Attester, Komponentensignierer, Reference Value Provider, Verifier und Relying Party behalten je eigene Verantwortung.

Eine gültige Messung beginnt die Entscheidung. Sie enthält die Berechtigung nicht.