12.2. Schutz konzeptioneller Nachrichten

Jede Lösung, die Informationen in einer konzeptionellen Nachricht (siehe Abschnitt 8) übermittelt, muss Ende-zu-Ende-Integritätsschutz und Schutz vor Replay-Angriffen unterstützen. Sie muss oft auch zusätzliche Sicherheitseigenschaften unterstützen, einschließlich:

• Ende-zu-Ende-Verschlüsselung,
• Schutz vor Denial-of-Service,
• Authentifizierung,
• Auditing,
• feinkörnige Zugriffskontrolle und
• Protokollierung.

Abschnitt 10 erörtert Möglichkeiten, wie Frische in dieser Architektur zum Schutz vor Replay-Angriffen verwendet werden kann.

Um die Sicherheit zu bewerten, die eine bestimmte Bewertungsrichtlinie bietet, ist es wichtig, die Stärke der Vertrauenswurzel zu verstehen, z. B. ob es sich um veränderbare Software oder Firmware handelt, die nach dem Booten schreibgeschützt ist, oder um unveränderliche Hardware/ROM.

Es ist auch wichtig, dass die Bewertungsrichtlinie selbst sicher erhalten wurde. Wenn ein Angreifer Bewertungsrichtlinien und Bestätigungen oder Referenzwerte für eine vertrauende Partei oder einen Verifizierer konfigurieren oder ändern kann, ist die Integrität des Prozesses kompromittiert.

Sicherheitsschutzmaßnahmen in der RATS-Architektur können auf verschiedenen Ebenen angewendet werden, sei es durch ein Übertragungsprotokoll oder ein Informationskodierungsformat. Diese Architektur erwartet, dass konzeptionelle Nachrichten basierend auf dem Rolleninteraktionskontext Ende-zu-Ende geschützt werden. Wenn beispielsweise ein Attestierer Beweise produziert, die über eine andere Entität weitergeleitet werden, die nicht die Rollen des Attestierers oder des beabsichtigten Verifizierers implementiert, sollte die Weiterleitungsentität nicht erwarten, Zugriff auf die Beweise zu haben.

Die RATS-Architektur ermöglicht es einer Entität, in mehreren Rollen zu fungieren (Abschnitt 6) und für zusammengesetzte Geräte (Abschnitt 3.3). Implementierer müssen ihre Designs bewerten, um sicherzustellen, dass die angenommenen Sicherheitseigenschaften der einzelnen Komponenten und Rollen trotz fehlender Trennung weiterhin bestehen und dass kein emergentes Risiko eingeführt wird. Die Einzelheiten dieser Bewertung hängen von der Implementierung und dem Anwendungsfall ab; daher liegen sie außerhalb des Geltungsbereichs dieses Dokuments. Isolationsmechanismen in Software oder Hardware, die Attestierungsumgebungen und Zielumgebungen (Abschnitt 3.1) trennen, können die Bewertung eines Implementierers und die daraus resultierenden Designentscheidungen unterstützen.