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

[Nicolai Stange <nstange@suse.de>]

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)