How to Build a Confidential Attestation Client
summary
Explains how an attestation client inside a confidential guest can be turned into an evidence factory attack that impersonates many tenants by producing valid measurements, and shows two mitigations: make measurements less generic via per-guest fields like host data or ID block, or revoke/report-generation capability (delete VM keys or poison PCRs) so a compromised guest can only ever issue one report. Covers practical gaps: lack of network stack, using a KBS URI in host data, and adopting IETF RATS/EAT-style metadata instead of a single hash.
AI-written summary · about
chapters (8)
- 0:00Introduction to attestation client
- 1:25Security risks of generic evidence
- 4:14Mitigating evidence factory attacks
- 8:53Host data and ID block solutions
- 11:00Metadata in attestation reports
- 13:08EAT format for attestation
- 14:12Attestation working group resources
- 15:37Network access challenges
related talks
24mThe elephants in the confidential room: Attestation and verification
36mHiding Attestation with Linux Keyring in Confidential Virtual Machines
25mDemystifying remote attestation
47mAMD SEV-SNP Attestation: Establishing Trust in Guests
40mDon’t Trust Opaque Clouds, Cryptographically Verify Instead!
26mTrust Is the Next Bottleneck: Why the Agentic Economy Needs Confidential
59mLayered Attestation of a Cross-Domain System
29mA Simple Protocol for Remote Attestation of System Integrity