Security model and Assumptions

The integrity of RATSd is essential. It's helpful to include build-provenance (such as in-toto attestation) for both the daemon (lead-attester) and the modules (sub-attesters).

However, we are still determining how to verify the build-provenance of the artifacts. Presently, we assume that the OS verifies this.

We expect the build attesters to include the user-supplied nonce in their generated evidence.

To validate the integrity of RATSd and its signing key, there are two options:

• Bind RATSd to a security device (such as TPM)
• Use an attested CSR

We will initially use an attested CSR.