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

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

[Nicolai Stange]

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.

I'm proposing, to do what TLS' ECDHE_ECDSA does, i.e. to make the KBS
sign its ephemeral ECDH key with a static ECDSA key and include that
signature in the attestation response.

Make the SVSM to verify the signature and memorize the KBS' ECDSA key
internally. For clarity: the SVSM would not verify any certificate
chain by itself.

With that, the SVSM can prove to any party that it's using a secret
obtained from that particular KBS instance, as identified by its
associated public ECDSA key:
- provide evidence that it's a well-behaving SVSM speaking (by means of
  another SNP report or some token obtained from the KBS in the course
  of attestation, ...),
- present the memorized KBS ECDSA key.

Motivation
----------
The SVSM persistence implementation will be using the secret obtained
from the attestation for protecting the externally stored data, c.f. my
"CocoonFs" PR at [2]. That is, the key will be used for both,
authentication and confidentiality protections.

That's inherently prone to MITM attacks: if the adversary is able to
control the persistence key, then it can read and modify the persisted
data.

My first thought on how to address this (and Tyler's initial reaction as
well), was to simply require that the VM owner ("end user") got to
create the persistence FS offline in a secure environment before first
use -- based on the presumption that if a wrong key was being returned
from the attestation process, then the SVSM would refuse to open the FS.

However, after thinking more about it, I came to the conclusion that
this workflow wouldn't be ideal from a practicality POV, and also,
wouldn't solve the problem in full.

First, a MITM can also mkfs a FS image with a key of his choice. The
implication is that the end user would not only have to create the
filesystem itself, but also populate its contents, like manufacturing
the TPM state offline and whatnot. And I'm not sure that would even
cover all potential applications of the persistence feature, like the
UEFI store.

Moreover, having the end user mkfs the FS image and transfer it into
e.g. the public cloud somehow might turn out impractical.

Also, having the end user mkfs the FS image requires that she got access
to the persistence key in the first place, unnecessarily extending the
set of entrusted parties. (And also, perhaps complicating the deployment
process, because that key would have to get enrolled into the KBS
somehow).

OTOH, if we were to have the persistence secret linked to the KBS' ECDSA
key, then
- we could mkfs the persistence FS from the SVSM upon first use and
- manufacture everything like TPM state from within the SVSM as needed.

AFAICS, it would even be possible for an organization to run something
like a "TPM EK CA", issuing credentials for the SVSM-manufactured TPM
EKs when presented with the KBS ECDSA key (alongside the SVSM evidence
in some form) from the SVSM.

Note how the overall process would be fully unattended and also, that an
organization wouldn't have to trust its VM owners / end users at all,
but could still trust the TPMs, simply by operating a KBS + an
associated "TPM EK CA".

What do you think, does it make sense?

Thanks,

Nicolai

[1] https://github.com/coconut-svsm/svsm/pull/828#issuecomment-3354168024
[2] https://github.com/coconut-svsm/svsm/pull/806

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

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

[James Bottomley]

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

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

[Nicolai Stange]

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.

For more context, there's a SVSM-PR from myself pending to use the
"CocoonFs" format specifically designed for this purpose, c.f. [1], or
[2] on the format itself. More FS formats may get introduced to the SVSM
in the future in case there's a demand.

Where the filesystem gets formatted and the TPM (, UEFI, ...) state
stored thereon manufactured respectively is subject of the discussion
here, I think. That is, AFAICS it depends on whether and how the
filesystem root key obtained from the KBS can get authenticated.

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.

That on its own is quite useless of course (unless the expected KBS
ECDSA key would somehow get embedded into e.g. the IGVM), but the SVSM
could then subsequently present the KBS ECDSA key to relying parties, as
a confirmation that it's using a filesystem root key supplied by that
particular KBS.

Thanks!

Nicolai

[1] https://github.com/coconut-svsm/svsm/pull/806
[2] https://coconut-svsm.github.io/cocoon-tpm/cocoonfs/cocoonfs-format.html

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

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

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

[James Bottomley]

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:

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

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

[Tyler Fanelli]

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.


Tyler

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

[Nicolai Stange]

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)

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

[Nicolai Stange]

James Bottomley <James.Bottomley@HansenPartnership.com> writes:

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

Yes, the goal of all this is to render such scenarios impossible.


> [...]
>> 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?

With the approach I currently have in mind there would be no
differentiation between first and subsequent boots: the SVSM receives a
new KBS ECDSA key for every boot/attestation cycle, memorizes the
current one in RAM only and would leave it to external parties to
implement policy based on that. For example, as outlined in my reply to
Tyler's mail ([1]), one could implement an IAK/IDevId or EK CA that
would issue certificates based on whether the SVSM presents a recognized
and trusted KBS' ECDSA pubkey.


> In which case it's Trust on First Use but it works, provided the KBS
> key can be stored reliably within the image and,

When you're saying "image", do you mean the SVSM persistence/CocoonFs
image containing the TPM state, or the guest's rootfs image? From the
context I suppose you're referring to the latter?

I think in this case Tyler is right when saying that if the LUKS rootfs
image is sealed by the TPM, then a successful unsealing operation would
be proof already that the correct SVSM persistence/CocoonFs image key is
being used. The problem would be how to prove in a generic way that the
expected LUKS rootfs was unlocked successfully.


> I assume, for immutable images the key will be provisioned inside the
> initial image?

For clarity, the SVSM persistence/CocoonFs image is currently assumed to
always be mutable, which is why I'm supposing you're referring to the
guest rootfs image here.

[If nothing else, there are plans to explore the feasability of
 implementing rollback protection on top of CooconFs, simply by sending
 the Merkle tree root HMAC off to a trusted party upon each
 update. Writing something at FS opening time would then guarantee a
 linear TPM state history, i.e. no forks/clones etc, but that requires
 mutability.]

Either way, AFAICS, the only way to enable the SVSM to verify on its own
that it's using the expected persistence/CocoonFs image would be to
embed the expected KBS ECDSA key into the IGVM, but I haven't really
thought this through yet.

Thanks!

Nicolai

[1] https://lore.kernel.org/r/877bwtzrvl.fsf@

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

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

[James Bottomley]

On Tue, 2025-10-14 at 21:33 -0400, Tyler Fanelli wrote:
> On 10/14/25 5:40 PM, James Bottomley wrote:
[...]
> > 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.

Not necessarily.  If I control the host, I also control what you boot
in all stages.  If you simply take booting up as proof, then I can
substitute both the KBS and the boot system, so you'll boot with my
image but if you're running a trusted service in the VM, it's now my
service.  An examination of the launch measurement by a trusted KBS
would defeat this, which is why I substituted the KBS as well.

The point being that there has to be validation on both sides.  If you
want a KBS to deliver a boot key by which your boot sequence continuing
is your validation, you still need to prove that you contacted the
correct KBS in the first place otherwise your launch measurement might
not actually have been validated.

Regards,

James

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

[Daniel P. Berrangé]

On Fri, Oct 17, 2025 at 09:25:18AM -0400, James Bottomley wrote:
> On Tue, 2025-10-14 at 21:33 -0400, Tyler Fanelli wrote:
> > On 10/14/25 5:40 PM, James Bottomley wrote:
> [...]
> > > 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.
> 
> Not necessarily.  If I control the host, I also control what you boot
> in all stages.  If you simply take booting up as proof, then I can
> substitute both the KBS and the boot system, so you'll boot with my
> image but if you're running a trusted service in the VM, it's now my
> service.  An examination of the launch measurement by a trusted KBS
> would defeat this, which is why I substituted the KBS as well.
> 
> The point being that there has to be validation on both sides.  If you
> want a KBS to deliver a boot key by which your boot sequence continuing
> is your validation, you still need to prove that you contacted the
> correct KBS in the first place otherwise your launch measurement might
> not actually have been validated.

For protection aganist that threat the guest owner would need to validate
either the TPM identity, or the root FS identity, or both, once the VM is
first accessed after booting.

In the root FS case, systemd measures the primary encryption key of any
unlocked LUKS volume into PCR 15. If the user has prior knowledge of
the expected hash they can use a TPM quote to validate that the root FS
volume has not been substituted, and in turn that validates that the
TPM state has not been substituted as the LUKS keyslot would have been
sealed to the TPM.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

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

[Tyler Fanelli]

On 10/17/25 7:31 AM, Nicolai Stange wrote:
> 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?

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

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

[James Bottomley]

On Fri, 2025-10-17 at 14:47 +0100, Daniel P. Berrangé wrote:
> On Fri, Oct 17, 2025 at 09:25:18AM -0400, James Bottomley wrote:
> > On Tue, 2025-10-14 at 21:33 -0400, Tyler Fanelli wrote:
> > > On 10/14/25 5:40 PM, James Bottomley wrote:
> > [...]
> > > > 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.
> > 
> > Not necessarily.  If I control the host, I also control what you
> > boot in all stages.  If you simply take booting up as proof, then I
> > can substitute both the KBS and the boot system, so you'll boot
> > with my image but if you're running a trusted service in the VM,
> > it's now my service.  An examination of the launch measurement by a
> > trusted KBS would defeat this, which is why I substituted the KBS
> > as well.
> > 
> > The point being that there has to be validation on both sides.  If
> > you want a KBS to deliver a boot key by which your boot sequence
> > continuing is your validation, you still need to prove that you
> > contacted the correct KBS in the first place otherwise your launch
> > measurement might not actually have been validated.
> 
> For protection aganist that threat the guest owner would need to
> validate either the TPM identity, or the root FS identity, or both,
> once the VM is first accessed after booting.
> 
> In the root FS case, systemd measures the primary encryption key of
> any unlocked LUKS volume into PCR 15. If the user has prior knowledge
> of the expected hash they can use a TPM quote to validate that the
> root FS volume has not been substituted, and in turn that validates
> that the TPM state has not been substituted as the LUKS keyslot would
> have been sealed to the TPM.

I agree this would work ... but it's a who guards the guards problem
and the above solution needs another guard to guard the first one (the
KBS).

Another possible solution, which allows the KBS to be the only guard,
is to have the KBS launch the VM, meaning it knows it should get a
launch measurement back from the launched VM to release keys and can
shut it down if it doesn't.

Regards,

James

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

[Daniel P. Berrangé]

On Fri, Oct 17, 2025 at 03:48:38PM -0400, James Bottomley wrote:
> On Fri, 2025-10-17 at 14:47 +0100, Daniel P. Berrangé wrote:
> > On Fri, Oct 17, 2025 at 09:25:18AM -0400, James Bottomley wrote:
> > > On Tue, 2025-10-14 at 21:33 -0400, Tyler Fanelli wrote:
> > > > On 10/14/25 5:40 PM, James Bottomley wrote:
> > > [...]
> > > > > 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.
> > > 
> > > Not necessarily.  If I control the host, I also control what you
> > > boot in all stages.  If you simply take booting up as proof, then I
> > > can substitute both the KBS and the boot system, so you'll boot
> > > with my image but if you're running a trusted service in the VM,
> > > it's now my service.  An examination of the launch measurement by a
> > > trusted KBS would defeat this, which is why I substituted the KBS
> > > as well.
> > > 
> > > The point being that there has to be validation on both sides.  If
> > > you want a KBS to deliver a boot key by which your boot sequence
> > > continuing is your validation, you still need to prove that you
> > > contacted the correct KBS in the first place otherwise your launch
> > > measurement might not actually have been validated.
> > 
> > For protection aganist that threat the guest owner would need to
> > validate either the TPM identity, or the root FS identity, or both,
> > once the VM is first accessed after booting.
> > 
> > In the root FS case, systemd measures the primary encryption key of
> > any unlocked LUKS volume into PCR 15. If the user has prior knowledge
> > of the expected hash they can use a TPM quote to validate that the
> > root FS volume has not been substituted, and in turn that validates
> > that the TPM state has not been substituted as the LUKS keyslot would
> > have been sealed to the TPM.
> 
> I agree this would work ... but it's a who guards the guards problem
> and the above solution needs another guard to guard the first one (the
> KBS).

The problem might be pushed even further up the stack to the application
level. For example, the authentic disk image is likely to contain one, or
more secrets which cannot be replicated by the person substituting the
fake TPM state & root FS. The SSH host key is one example, but HTTPS
server certificates might be another.

> Another possible solution, which allows the KBS to be the only guard,
> is to have the KBS launch the VM, meaning it knows it should get a
> launch measurement back from the launched VM to release keys and can
> shut it down if it doesn't.

Injecting the KBS into the VM launch sequence feels like it could be
a challenge to integrate, if it makes the CVM launch flow significantly
different from the regular VM launch flow.

Overall the intent of the SVSM pre-boot attestation was to make it
easy to shift all workloads between traditional VMs and CVMs, without
imposing mandatory special steps on guest owners - they would want to
opt-in to full validation if their usage demands that level of extra
assurance. 

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|