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

[Nicolai Stange <nstange@suse.de>]

Tyler Fanelli <tfanelli@redhat.com> 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 <James.Bottomley@HansenPartnership.com> 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?

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. 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.

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. 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. 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.

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.

Thanks!

Nicolai

[1] TCG "TPM 2.0 Keys for Device Identity and Attestation", ver 1.00, rev 12
[2] https://keylime.readthedocs.io/en/v7.12.1/user_guide/idevid_and_iak.html
(*) Other solutions might do something similar, but with trust
    established through the TPM's EKs instead of IAK/IDeveID, in turn
    certified by the TPM/Platform manufacturer. C.f. TCG TPM 2.0
    Library, v184, part 0 ("Introduction"), sec. 4.5.3
    ("Attestation"). On a high level, the concept is the same: there's
    some key on the TPM, certified by some CA to be trusted by relying
    verifiers in order to establish trust in the TPM.

-- 
SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nürnberg, Germany
GF: Ivo Totev, Andrew McDonald, Werner Knoblich
(HRB 36809, AG Nürnberg)