Confidential Computing and TEE Deployment
This domain tests deployment: how confidential VMs and enclaves are operated at scale, how secrets are released to them, and which parts of the cloud stack remain in the threat model.
Deployment model
- Confidential computing protects data in use with hardware memory encryption and attestation. The hypervisor and cloud operator are outside the TCB for guest confidentiality, but they still control scheduling, so denial of service remains.
- Platforms: Intel TDX and AMD SEV-SNP for confidential VMs; Intel SGX for process-level enclaves. Containers use confidential containers, for example Kata with a guest TEE, plus attestation agents.
- Devices are the weak point: virtio, GPUs, and NICs can see plaintext unless protected by mechanisms such as TDISP or SEV-TIO. Treat unaccelerated I/O as out of scope or add device attestation.
Key release and policy
- A KMS releases secrets only after verifying an attestation token against a policy: measurement allowlist, minimum TCB version, nonce freshness, and workload identity. The secret is wrapped to the guest's ephemeral key.
- Attestation freshness and caching matter: a token issued at boot is stale after migration or upgrade. Re-attest after events and on secret renewal.
Operations
- Live migration must preserve confidentiality and integrity; SEV-SNP and TDX define migration agents and attestation of the destination. An unverified migration target can exfiltrate memory.
- Performance: memory encryption adds overhead, and EPC paging in SGX is costly. Side channels remain a shared-cloud risk; do not place high-value secrets next to attacker-controlled workloads without isolation.
Worked example
A confidential Kubernetes pod must decrypt a customer database. The pod starts in a TDX VM; an attestation agent fetches a TDX quote with a nonce from the KMS. The KMS policy requires the expected MRTD, a patched TDX module version, and a signed workload identity claim. It then releases a wrapped data key. If the host later migrates the VM, the new destination must re-attest before the key is renewed; otherwise a compromised host could migrate the VM and read memory. Reasoning: policy binds key release to measurement and freshness.
Traps
- Saying confidential computing hides memory access patterns.
- Forgetting that the host can deny service.
- Trusting a boot-time attestation forever.
- Assuming all devices are inside the TCB.