Attestations¶

Learn what attestations are, how hardware-rooted proofs work in confidential compute, and how Caution verifies enclave integrity.

What attestations are¶

The backbone of confidential compute consists of hardware trust anchors that provide mechanisms to isolate workloads and encrypt memory, along with protected private keys that can be used to attest to (vouch for) what is running inside a confidential compute workload.

Different hardware platforms such as Intel TDX, AMD SEV-SNP, TPM 2.0, and Nitro provide attestation capabilities: they can measure the state of a server and provide cryptographic signatures of hashes of that data. This is what "attestations" are. They are also referred to as cryptographic remote attestations.

AWS Nitro support today

Caution currently supports deployments on AWS Nitro Enclaves. We are actively working on support for Intel TDX, AMD SEV-SNP, and TPM 2.0 attestations.

How attestation verification works¶

When you run caution verify, the CLI performs a multi-step verification process to prove that the code running in a remote enclave matches exactly what you expect.

1. Generate a challenge nonce¶

The CLI generates a random 32-byte nonce (number used once). This nonce prevents replay attacks. An attacker cannot reuse an old attestation document because each verification requires a fresh nonce.

2. Request attestation from the enclave¶

The CLI sends the nonce to the enclave's public /attestation endpoint. Caution proxies that path internally to bootproofd on reserved port 49502. The enclave's Nitro Security Module (NSM) generates an attestation document that includes:

The nonce (echoed back)
PCR values (Platform Configuration Registers), cryptographic measurements of the enclave image
A certificate chain signed by the AWS Nitro root CA
A manifest containing source URLs and commit hashes

The attestation document is signed using COSE (CBOR Object Signing and Encryption) with the NSM's private key.

3. Verify the attestation document¶

The CLI verifies the attestation document:

Certificate chain verification - Validates that the signing certificate chains back to the AWS Nitro root CA, proving the attestation came from genuine Nitro hardware
Signature verification - Verifies the COSE signature using the certificate's public key
Nonce verification - Confirms the returned nonce matches the one sent, preventing replay attacks

4. Reproduce the build¶

Using the manifest from the attestation (which contains source URLs and commit hashes), the CLI reproduces the enclave build locally. This generates the expected PCR values - the same cryptographic measurements that would result from building the exact same code.

5. Compare PCR values¶

Finally, the CLI compares:

PCR0 - Hash of the enclave image
PCR1 - Hash of the Linux kernel and bootstrap
PCR2 - Hash of the application

If all PCR values match, the verification passes. This proves that the remote enclave is running exactly the code specified in the manifest, built in exactly the same way.

✓ Certificate chain verified against AWS Nitro root CA
✓ COSE signature verification passed
✓ Nonce verified (prevents replay attacks)
✓ Attestation verification PASSED

Review the source code yourself

During verification, all source code is pulled to ~/.cache/caution/reproductions/local/<your_build_id>. The verification process output will show you the exact location. You can inspect this directory to review the exact code used to build the enclave image running inside the enclave.

What PCR values represent¶

Attestation verification compares these PCR measurements to confirm the enclave is running the expected image, kernel, and application code.

PCR	Description
PCR0	Enclave image file - a hash of the entire enclave image
PCR1	Linux kernel and bootstrap - measures the kernel and init process
PCR2	Application - measures your application code

Because these are cryptographic hashes, even a single byte change in the source code produces completely different PCR values.

Multi-hardware attestation¶

Single-hardware trust problem¶

Most solutions today are based on a single confidential compute technology. Using confidential compute is a good upgrade over standard ways to run software, but it roots trust in a single manufacturer that provides the confidential compute technology. Like all companies, large manufacturers are susceptible to bugs and compromise. By rooting trust in only one piece of hardware, users of this technology expose themselves to single points of failure (SPOFs).

Multi-hardware trust solution¶

To address the risk of rooting trust in a single hardware vendor, along with inherited risks across software, firmware, hardware supply chains, and operational practices, the team behind Caution designed EnclaveOS. Caution currently supports AWS Nitro Enclaves, and a new version of EnclaveOS with multi-hardware support is in active development. You can learn more in this blog post.

This OS is designed to leverage multiple attestation technologies for a single workload, requiring all of them to agree on the workload state before its integrity is considered intact. This hardware-level distribution of trust is unique to Caution and EnclaveOS at the time of writing.