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

On Tue, 2025-10-14 at 22:56 +0200, Nicolai Stange wrote:
> James Bottomley <[email protected]> writes:
> 
> > On Tue, 2025-10-14 at 10:45 +0200, Nicolai Stange wrote:
> > > 
> > > 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?
> 
> Sorry for being unclear -- this is one of the open questions, see
> below.
> 
> 
> > 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.
> 
> The current plan is to not involve the guest at all. Instead
> - a (small) block device will get attached to the SVSM, via virtio
>   currently,
> - there will be a filesystem on that block device, which is encrypted
> + authenticated with a (symmetric) "filesystem root key" known only
> to the SVSM and
> - that filesystem root key will get revealed by the KBS to the SVSM
> upon
>   successful attestation.
> 
> The TPM state will be stored in a file on that filesystem. UEFI data
> in another and so on.

On this, how does the guest know it's pulled in the correct image?  If
I were a malicious host, I could encrypt my own TPM image, accept your
attestation to a KBS I control and release a key that decrypts my
malicious image.  I think you give the answer below:

[...]
> FTR, I'm trying to make a point for formatting and manufacturing
> everything from within the SVSM upon first use, and to bind the
> received filesystem root key to an ECDSA key associated with the KBS,
> via:
> - KBS signs its ephemeral ECDH public key with that ECDSA key,
> - the shared key from ECDH is used for authenticated encryption of
>   the secret, which includes the filesystem root key.

So on first boot the CVM binds via public key to the KBS it's given and
checks this key on subsequent boot time interactions with the KBS?  In
which case it's Trust on First Use but it works, provided the KBS key
can be stored reliably within the image and, I assume, for immutable
images the key will be provisioned inside the initial image?

Regards,

James