GoKawiilI’ve been doing remote attestation work on confidential VMs. This post is one piece of that: whatever the attestation ends up looking like, the machine still needs an identity it can hold and use afterwards, and in my case that means authenticating to other services with mutual TLS.
An application that does mutual TLS authenticates with a client certificate, and on disk that is almost always two files. client.crt is the one you show: it carries a public key and a CA’s signature over that key, and it isn’t a secret. client.key is the one you sign the handshake with, and the server checks that signature against the public key in the certificate you just showed it.
So the identity is entirely in the second file, and your process reads it into memory at startup. From that moment the key is in a heap dump, a core file, a swapped page, a hypervisor snapshot of the VM’s memory, and in reach of anything that gets code execution in the process. Copy it and you are that machine everywhere that machine is trusted: the secret store, the internal API that only accepts client certificates, the database that maps a certificate subject to a role.
A key in a file is not really a machine identity. It’s a bearer credential that happens to be stored on a machine, and whoever reads it becomes that machine, anywhere, until somebody notices and revokes the certificate.
The threat model is narrow. What I’m defending against is an attacker who gets read access inside the guest: a file read, a core dump, an SSRF that reaches the filesystem, a backup that went somewhere it shouldn’t. I want them to leave without a working copy of the machine’s identity.
What I’m not defending against is someone with persistent code execution using that identity while they’re still on the box. That’s a different problem and a TPM doesn’t solve it.
So the key I need has four properties. It signs TLS handshakes, because that is how the identity gets used. It never exists outside the machine, so that reading memory or a disk gets an attacker nothing they can carry away. It needs no second credential to reach it, because whatever that credential was would immediately become the new thing worth stealing. And it works with an ordinary TLS stack, because I don’t want a bespoke protocol between two services that already speak TLS perfectly well.
A TPM does all four. It will sign with a key and it will not hand the key over, so the process never holds a secret at all. On the machine I’ve been using that’s a virtual TPM, and I wrote about the chip itself in an earlier post. Being a confidential VM helps with exactly one item on that exposure list, since guest memory is encrypted against the host and a snapshot taken from underneath gets ciphertext. Everything else on the list happens inside the guest, where memory encryption doesn’t help.
why not something else
Three alternatives come up before a TPM does, and all three are reasonable. Each of them misses at least one of the four properties.
... continue reading