9. Claims-Kodierungsformate
9. Claims-Kodierungsformate
Abbildung 8 veranschaulicht eine Beziehung, zu der Remote-Attestierung hinzugefügt werden soll:
.-------------. .------------. Anfrage gegen
| +-------------->| | Sicherheits-
| Attester | Zugriff auf | Relying | richtlinie
| | eine Ressource| Party | bewerten
'-------------' '------------'
Abbildung 8: Typischer Ressourcenzugriff
In diesem Diagramm kann das Protokoll zwischen dem Attester und einer Relying Party je nach Anwendungsfall ein beliebiges neues oder bestehendes Protokoll sein (z. B. HTTP(S), CoAP(S), Resource-Oriented Lightweight Information Exchange (ROLIE) [RFC8322], 802.1x, OPC UA [OPCUA] usw.).
Typischerweise verfügen solche Protokolle bereits über Mechanismen zur Übermittlung von Sicherheitsinformationen für Authentifizierungs- und Autorisierungszwecke. Gängige Formate umfassen JSON Web Tokens (JWTs) [RFC7519], CWTs [RFC8392] und X.509-Zertifikate.
Die Nachrüstung bereits eingesetzter Protokolle mit Remote-Attestierung erfordert das Hinzufügen von RATS-Konzeptnachrichten zu den bestehenden Datenflüssen. Dies muss auf eine Weise erfolgen, die die Sicherheitseigenschaften der beteiligten Systeme nicht beeinträchtigt, und sollte die vom zugrunde liegenden Protokoll bereitgestellten Erweiterungsmechanismen verwenden. Wenn beispielsweise ein TLS-Handshake um Remote-Attestierungsfähigkeiten erweitert werden soll, kann Attestierungs-Evidence in eine ad-hoc X.509-Zertifikatserweiterung (z. B. [TCG-DICE]) oder in einen neuen TLS-Zertifikatstyp (z. B. [TLS-CWT]) eingebettet werden.
Insbesondere bei eingeschränkten Knoten besteht der Wunsch, die Menge an Parsing-Code zu minimieren, die in einer Relying Party erforderlich ist, um sowohl den Footprint als auch die Angriffsfläche zu minimieren. Obwohl es möglich wäre, ein CWT in ein JWT oder ein JWT in eine X.509-Erweiterung usw. einzubetten, besteht der Wunsch, die Informationen in einem Format zu kodieren, das bereits von der Relying Party unterstützt wird.
Dies motiviert die Existenz eines gemeinsamen „Informationsmodells", das den Satz der mit Remote-Attestierung verbundenen Informationen auf kodierungsunabhängige Weise beschreibt und mehrere Kodierungsformate (CWT, JWT, X.509 usw.) ermöglicht, die dieselben Informationen in das von der Relying Party benötigte Claims-Format kodieren.
Abbildung 9 veranschaulicht, dass Evidence und Attestation Results über mehrere potenzielle Kodierungsformate ausgedrückt werden können, sodass sie von verschiedenen bestehenden Protokollen übermittelt werden können. Sie motiviert auch, warum der Verifier möglicherweise auch dafür verantwortlich ist, Evidence zu akzeptieren, die Claims in einem Format kodiert, während Attestation Results ausgegeben werden, die Claims in einem anderen Format kodieren.
Evidence Attestation Results
.--------------. CWT CWT .-------------------.
| Attester-A +-----------. .---------->| Relying Party V |
'--------------' | | `-------------------'
v |
.--------------. JWT .---------+--. JWT .-------------------.
| Attester-B +-------->| +-------->| Relying Party W |
'--------------' | | `-------------------'
| |
.--------------. X.509 | | X.509 .-------------------.
| Attester-C +-------->| Verifier +-------->| Relying Party X |
'--------------' | | `-------------------'
| |
.--------------. TPM | | TPM .-------------------.
| Attester-D +-------->| +-------->| Relying Party Y |
'--------------' '---------+--' `-------------------'
^ |
.--------------. other | | other .-------------------.
| Attester-E +-----------' '---------->| Relying Party Z |
'--------------' `-------------------'
Abbildung 9: Mehrere Attesters und Relying Parties mit
verschiedenen Formaten