Re: [DISCUSSION] svsm: attestation: if and how to authenticate the provided secret

On Tue, 2025-10-14 at 10:45 +0200, Nicolai Stange wrote:
> Hi all,
> 
> as I don't want to hijack Tyler's recent attestation PR, I'd like to
> continue a discussion started there and best summarized in the
> comment at [1] here.
> 
> The question is whether or not to have the KBS authenticate the
> secret returned to the SVSM upon a successful attestation.
> 
> The current state is that authenticated encryption is being used in
> the protocol (AES-KW + AES-GCM), but that's only bound to an
> ephemeral ECDH key, hence doesn't link to any root of trust.

Could we wind back a bit?  This discussion seems to be starting in the
middle.  Where does the encrypted state actually come from?

The threat being that if an attacker can supply the TPM state to your
confidential VM, they know all the TPM parameters, including the
private keys, and can fake any attestation.   In the non-CVM world, the
state is usually part of the VM image (encrypted), but this happens
because the TPM is running outside the VM envelope and suspend or
shutdown can pull the encrypted state as part of the device state of
the VM image.  In the CVM world the state is stored inside CVM in the
SVSM and has to be inaccessible to the guest.  It is possible for the
SVSM to encrypt the TPM state and pass it to the guest which then saves
it in the VM image.  In that case, proof of correctness can simply be
supplying a key capable of decrypting the image.

However, in a container (or immutable VM) world, there's no image
update to save and the TPM state has to be saved somewhere separately
(and at a location under the control of untrusted entities) so there
has to be a strong binding between the encrypted TPM state and the CVM
to prevent a state substitution attack (i.e. the CVM has to validate
it's pulling the correct TPM state before using it).

Regards,

James