12.2. Conceptual Message Protection
Any solution that conveys information in any conceptual message (see Section 8) must support end-to-end integrity protection and replay attack prevention. It often also needs to support additional security properties, including:
- end-to-end encryption,
- denial-of-service protection,
- authentication,
- auditing,
- fine-grained access controls, and
- logging.
Section 10 discusses ways in which freshness can be used in this architecture to protect against replay attacks.
To assess the security provided by a particular appraisal policy, it is important to understand the strength of the root of trust, e.g., whether it is mutable software or firmware that is read-only after boot or immutable hardware/ROM.
It is also important that the appraisal policy was obtained securely itself. If an attacker can configure or modify appraisal policies and Endorsements or Reference Values for a Relying Party or a Verifier, then integrity of the process is compromised.
Security protections in the RATS architecture may be applied at different layers, whether by a conveyance protocol or an information encoding format. This architecture expects conceptual messages to be end-to-end protected based on the role interaction context. For example, if an Attester produces Evidence that is relayed through some other entity that doesn't implement the Attester or the intended Verifier roles, then the relaying entity should not expect to have access to the Evidence.
The RATS architecture allows for an entity to function in multiple roles (Section 6) and for composite devices (Section 3.3). Implementers need to evaluate their designs to ensure that the assumed security properties of the individual components and roles still hold despite the lack of separation and that emergent risk is not introduced. The specifics of this evaluation will depend on the implementation and the use case; hence, they are out of scope for this document. Isolation mechanisms in software or hardware that separate Attesting Environments and Target Environments (Section 3.1) can support an implementer's evaluation and resulting design decisions.