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

On 10/17/25 7:31 AM, Nicolai Stange wrote:
> Tyler Fanelli <[email protected]> writes:
> 
>> On 10/14/25 5:40 PM, James Bottomley wrote:
>>> 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:
>>>
>>
>> We intend for the guest's rootfs to be sealed to the persistent TPM
>> found in encrypted storage. The malicious host could switch the TPM,
>> but that TPM wouldn't be able to unseal the rootfs.
>>
>> This doesn't directly prevent the attack you mention above, but it
>> would be a DoS.
> 
> So if I understand correctly (please correct if I'm wrong), a successful
> unlock of the guest's LUKS-protected rootfs would act as a proxy for
> "the SVSM is using the right/genuine CocoonFs image" in a sense?

That's not necessarily how I see it. Instead, I think it acts as a proxy 
for "this SVSM has proven to be running in an encrypted enclave and is a 
validated version that I trust, I can now continue with the boot process 
and load my guest firmware/OS". We attested the bedrock of our TCB in a 
sense.

> 
> The problem with that, for remote parties, is how would they verify that
> LUKS disk XY had been successfully unlocked (assuming the guest has a
> LUKS protected rootfs in the first place)?
> 
> I mean, take keylime for example. If I'm not mistaken, the verifier
> component has a list of trusted "OEM IAK/IDevID Certificate CAs" ([1])
> configured for its $TPM_CERT_STORE ([2]), with the IAK/IDevID being
> signing keys on the TPM. (*) The TPM's IAK/IDevID being signed by such
> a trusted CA is what establishes trust in the TPM and its measurements
> as far as the remote party is concerned.
> 
> With "trust" meaning trust that
> - the TPM implementation is correct and
> - the IAK/IDevIDs are keys on the TPM and never leave it.
> 
> In our setup, with the SVSM attesting to the KBS, it's ultimately the
> KBS enforcing the first part, by only ever releasing the persistence key
> to well-behaving, i.e. attested SVSMs.

Precisely. The only scenario protected against is one in which the 
persistence key is released to an SVSM that isn't verified to be 
well-behaving or within an encrypted enclave.

> The second part however, is true
> only if the SVSM actually does use the secret key obtained from that
> very KBS for the TPM state persistence.
>

Sure. TEE attestation only verifies an enclave's TCB. It makes no 
assumption of what is done with the secrets once it's attested.

> So if a relying party, perhaps a "OEM IAK/IDevID or EK Certificate CA"
> requested to issue IAK/IDevID certificates for the SVSM's TPM, wants to
> establish this trust, it needs to verify both parts.
> 
> For that, we need confirmation that the key from the KBS is used for the
> persistence.

I've been making the following assumptions:

- The vTPM was provisioned and stored within encrypted storage.
- The key for this storage is stored on a KBS.
- The key will only be released to attested SVSMs.

Therefore, the very fact that you are presented with this vTPM is 
implicitly confirming that the key from the KBS was used for 
persistence, because the vTPM wouldn't be decrypted otherwise.

> Proof of possession of some secret pre-provisioned offline
> into the CocoonFs image, like a LUKS key, might work, but I don't see a
> straightforward way to make that universal and also, it would make the
> initial setup more complicated than need be, IMO.

One note: KBS attestation produces an EAR token:

https://www.ietf.org/archive/id/draft-ietf-rats-ear-01.txt

Once SVSM successfully attests, it will receive this token. It would 
then write the token into encrypted storage as a sort of artifact. If 
the eventual guest would like to then read the token and verify it with 
the attestation server that SVSM used, it's able to do so.

Not exactly "proof of posession" of a key, but proof of attestation that 
the guest can use.

> In particular, access
> to the persistence key is required for that.
>
> If OTOH we were to follow the route to associate the KBS with a ECDSA
> key, and use that for (indirectly) authenticating the received secret,
> then we could make the SVSM present that to the organization's "OEM
> IAK/IDevID or EK Certificate CA", alongside evidence it's a SVSM, and
> the CA would issue a "OEM IAK/IDevID or EK Certificate", because it
> recognizes the KBS ECDSA key and trusts the associated KBS (and trusts
> the SVSM to have verified the ECDSA signature). From then on, relying
> parties like keylime would only have to trust that CA, and workflows
> would be no different from any other TPM. Note that it wouldn't matter
> when and where the initial TPM state is getting manufactured.
> 

It seems that this is attempting to cryptographically prove the 
assumptions about the TPM that I made above. I'm in favor of that, as 
the implicitness of having the TPM proving the guest is attested is 
likely not enough.

> Moreover, any subsequent usage of a certified IAK/IDevID or EK would
> henceforth be an implicit proof that the genuine CocoonFs image is being
> used, which could perhaps be used for establishing trust in the state
> stored by any other subsystem on the SVSM's persistent storage (UEFI
> etc.) -- as per its global authentication: if anything on the filesystem
> is genuine, then everything is.
> 
Sounds reasonable to me.


Tyler