Zusammenfassung

  • RFC 9684 definiert YANG-RPCs für TPM-1.2/2.0-Quotes mit frischer Nonce sowie für BIOS-, IMA- und Network-Equipment-Boot-Logs.
  • Eine korrekte Signatur und ein passender Log-Replay belegen die ausgewählte Messfläche; sie garantieren weder vollständige Abdeckung noch richtige Reference Values.
  • AK/AIK-Bindung, Messpolicy, Appraisal, Attestation Result, Relying-Party-Entscheidung, Enforcement und Netzwirkung brauchen eigene Nachweise.

Der TPM antwortete mit einer gültigen Signatur. Der PCR-Wert war stabil und frisch. Erst die Konfigurationsprüfung zeigte, dass die Systemsoftware diesen PCR überhaupt nicht erweiterte. Das Messgerät hatte korrekt eine Zahl geschützt, der Betrieb hatte ihr nur zu viel Bedeutung gegeben.

RFC 9684 liefert mit CHARRA eine gemeinsame Schnittstelle zum Abruf von Evidence. Ein YANG-Client kann PCRs auswählen, eine Quote anfordern und Messlogs beziehen. Das schafft Interoperabilität bei der Erhebung, nicht automatisch ein Vertrauensurteil.

Die Nonce schützt den Zeitpunkt, nicht den Umfang

Der Client muss eine frische Nonce mit ausreichender Entropie liefern. Der Attester bindet sie an die Antwort, sodass eine alte Quote nicht als neue Antwort wiederverwendet werden kann.

Diese Freshness-Aussage gilt für genau diese Evidence. Sie ergänzt keinen ausgelassenen PCR, misst keine Datei außerhalb der IMA Policy und verhindert keine Änderung nach der Quote. Bei Composite Devices erklärt sie auch nicht, welcher TPM welchen Bestandteil misst.

RFC 9684 lässt die Kommunikation der TPM-Komponenten-Beziehung ausdrücklich außerhalb seines Scopes. Mit mtpm können ohne certificate-name mehrere TPMs antworten. Die Auswahl eines Zertifikats ist nur dann sinnvoll, wenn eine belastbare Karte Zertifikat, TPM, Control Unit, Line Card und Funktion verbindet.

Ein Challenge Receipt muss deshalb Gerät, RPC, Nonce, TPM-Version, Zertifikat, Hash Bank, PCR-Indizes, Log-Typ und Selection-Policy-Version enthalten. Ein einzelnes pass verliert nach Kartentausch, Key Rotation oder Image Update seine erklärende Kraft.

Ein Signaturschlüssel bestätigt seine Rolle nicht selbst

Eine TPM-2.0-Antwort kann TPMS_QUOTE_INFO, Quote-Signatur, Zertifikatsnamen, Uptime und unterstützende unsigned PCR values enthalten. Die Signatur schützt die Struktur; PCR-Werte helfen bei der Rekonstruktion; das Zertifikat verbindet den Schlüssel mit der erwarteten Attestation-Rolle.

Der Empfänger muss prüfen, ob ein TPM-1.2-Zertifikat eine aktive AIK oder ein TPM-2.0-Zertifikat eine aktive AK bezeichnet und ob die Kontrolle des privaten Schlüssels für den Ziel-TPM legitim bestätigt wurde. Eine mathematisch gültige Signatur eines anderen Schlüssels ist kein Beleg für die Zielkomponente.

Konfigurierbare Support-Strukturen können einen falschen Key Type, ein nicht zur AK gehörendes Zertifikat, nicht unterstützte Algorithmen oder nie erweiterte PCRs angeben. Der RPC kann dabei fehlerfrei bleiben.

NETCONF und RESTCONF schützen den Management-Austausch. Sie entscheiden nicht über Key Authority, Component Coverage oder den richtigen Baseline. Transport-Authentizität und Evidence-Appraisal sind getrennte Receipts.

PCR und Log können gemeinsam unvollständig sein

PCRs sammeln Messungen als Rolling Hash. Das Event Log liefert die Sequenz, die ein Verifier nachspielen und mit der signierten Evidence vergleichen kann. Anschließend lassen sich einzelne Messwerte gegen Reference Values prüfen.

Die Konsistenz gilt innerhalb der Messpolicy. IMA Templates bestimmen Log-Felder; die IMA Policy bestimmt gemessene Dateien. RFC 9684 hält fest: Ohne Policy entstehen keine Messungen, IMA ist praktisch deaktiviert. Ein leeres Log kann daher perfekt zu seinem PCR passen.

BIOS/UEFI-, IMA- und Network-Equipment-Boot-Logs decken unterschiedliche Phasen ab. Komponenten können parallel starten. Ein legitimes Patch verändert Hashes und verlangt aktualisierte Reference Integrity Manifests. Ein Mismatch kann Manipulation, genehmigte Migration oder einen falschen Baseline bedeuten.

Der prüfbare Datensatz trennt Measurement-Policy-Version, Coverage, Raw Log, Replay, Herkunft und Gültigkeit der Reference Values, Ausnahmen und Appraisal Policy. Ein proprietärer Gesamtscore reicht nicht, wenn später der Baseline als Fehlerquelle erkannt wird.

Attestation Result und Betriebsentscheidung sind nicht identisch

RFC 9334 trennt Attester, Verifier und Relying Party. Der Attester produziert Evidence, der Verifier appraised sie und erzeugt ein Attestation Result, die Relying Party nutzt es für eine konkrete Transaktion. RFC 9683 stellt den Network-Device-Kontext bereit.

RFC 9684 standardisiert vor allem den Evidence-Abruf. Ein Result kann für Inventar genügen und für Routing Admission nicht. Ein negatives Result kann Wartung, Funktionseinschränkung oder Human Review auslösen, ohne ein universelles Abschaltsignal zu sein.

Nach der Entscheidung muss der Enforcement Point selbst quittieren: Wurde der Port isoliert, die Session entfernt, Traffic verlagert und Service erhalten? Eine TPM Quote beobachtet diese Wirkung nicht. Sensor, Entscheidungsträger und Aktor dürfen nicht zu einem Symbol verschmelzen.

Auch der Abruf braucht Least Privilege

Logs verraten Hashes und Versionsdetails, die verwundbare Software erkennbar machen können. Große Log Requests verbrauchen Ressourcen und können Denial-of-Service-Druck erzeugen. RFC 9684 verlangt daher Schutz durch NACM mit deny-all als Default für nicht autorisierte Verifier.

Lokale Policy muss Requester, Komponenten, Frequenz, Volumen, Aufbewahrung und Zugriff festlegen. Zu wenig Messung erzeugt falsche Sicherheit; zu viel Extraktion vergrößert Offenlegung und Last. Das gemeinsame YANG-Modell ersetzt diese Abwägung nicht.

Die minimale Anfangsspezifikation hält den gemeinsamen Kern klein. Realitätsebenen zerlegen „attested“ in Nonce, Scope, Key, Baseline und Decision. Running-Code-Primat verlangt den Nachweis der tatsächlichen Durchsetzung.

CHARRA macht eine TPM-Antwort portabel. Erst der verantwortliche Verifier macht daraus ein zeit- und scopegebundenes Urteil; erst das autorisierte System mit Enforcement Receipt macht daraus eine Betriebswirklichkeit.

Quellen