Re: SVSM initiated early attestation / guest secrets injection

["Daniel P. Berrangé" <berrange@redhat.com>]

On Fri, Jan 13, 2023 at 10:52:57AM -0800, Dionna Amalie Glaze wrote:
> >
> > Aside from what James' says, one option is to lockdown the OVMF and
> > secureboot chain. eg OVMF built with SecureBoot=on, and instead of
> > having the generic Microsoft keys enrolled, have a distro specific
> > key enrolled. That distro key would have to be one that is only
> > used for signing UKIs (Unified Kernel Images), and the initrd embedded
> > in the UKI would need to be designed abort if it finds the disk is
> > not encrypted.
> >
> 
> IIUC, the disk doesn't need to be encrypted, it needs integrity. We
> can't treat booting to an encrypted disk as booting to the expected
> encrypted disk.

The attacker does not know the keyslot passphrase for the expected
encrypted disk. Thus if the initrd successfully unlocks the root
disk keyslot, we know it was presented the expected one. The only
serious attack is for the encrypted disk to be substituted with an
unencrypted disk, which can be handled by having the initrd refuse
to boot with any unencrypted root disk.

Other attacks on the encrypted disk such as tampering with the
cipher text would be mere denial of service. Use of LUKS AEAD
ciphers would mitigate that, but other integrity checking layers
can work too.

> The secret-holding server should only ever release secrets encrypted
> by an attested vTPM binary (SVSM-generated public key) that has sealed
> the secret to the workload PCRs.
> This kicks the problem to the server and VM having pre-agreed on
> what's the expected combination of OVMF and SVSM. So yes the vTPM gets
> its core secret transferred to it before the PCRs get set to the
> expected values, but that's part of the attestation dance with the
> initial registration with the secret-holding server.

To be clear, I think the vTPM is a good thing, but it does not look
like it is mandatory to me. If you lock down your firmware and initrd
sufficiently strict in its impl, a vTPM is not a blocker. What a vTPM
does is make the system much more flexible, since you can come up with
a wide variety of PCR policies for tieing unlock to. When not having a
vTPM you're effectively having to rely on one very specific policy that
is hardcoded through initrd/firmware impl.

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