12.2. Protezione dei messaggi concettuali
Qualsiasi soluzione che trasmette informazioni in qualsiasi messaggio concettuale (vedere Sezione 8) deve supportare la protezione dell'integrità end-to-end e la prevenzione degli attacchi di replay. Spesso deve anche supportare ulteriori proprietà di sicurezza, tra cui:
- crittografia end-to-end,
- protezione denial-of-service,
- autenticazione,
- auditing,
- controlli di accesso granulari, e
- logging.
La Sezione 10 discute i modi in cui la freschezza può essere utilizzata in questa architettura per proteggere contro gli attacchi di replay.
Per valutare la sicurezza fornita da una particolare politica di valutazione, è importante comprendere la forza della radice di fiducia, ad esempio, se si tratta di software mutabile o firmware di sola lettura dopo l'avvio o hardware/ROM immutabile.
È anche importante che la politica di valutazione sia stata ottenuta in modo sicuro. Se un attaccante può configurare o modificare le politiche di valutazione e gli Endorsements o i Reference Values per una Relying Party o un Verifier, allora l'integrità del processo è compromessa.
Le protezioni di sicurezza nell'architettura RATS possono essere applicate a diversi livelli, sia mediante un protocollo di trasporto che un formato di codifica delle informazioni. Questa architettura si aspetta che i messaggi concettuali siano protetti end-to-end in base al contesto di interazione dei ruoli. Ad esempio, se un Attester produce Evidence che viene inoltrata attraverso qualche altra entità che non implementa i ruoli di Attester o Verifier previsto, allora l'entità di inoltro non dovrebbe aspettarsi di avere accesso all'Evidence.
L'architettura RATS consente a un'entità di funzionare in più ruoli (Sezione 6) e per dispositivi compositi (Sezione 3.3). Gli implementatori devono valutare i loro progetti per garantire che le proprietà di sicurezza assunte dei singoli componenti e ruoli rimangano valide nonostante la mancanza di separazione e che non venga introdotto rischio emergente. Le specifiche di questa valutazione dipenderanno dall'implementazione e dal caso d'uso; pertanto, sono fuori dall'ambito di questo documento. I meccanismi di isolamento nel software o nell'hardware che separano gli Attesting Environments e i Target Environments (Sezione 3.1) possono supportare la valutazione di un implementatore e le decisioni di progettazione risultanti.