Virtual platform attestation protocol?

[deeglaze]

In GCP we have as part of every Shielded VM's vTPM an endorsement key certificate that includes x.509 extensions that bind a quote to platform identity metadata. This is zone, project name, project id, instance name, instance id (I think). Platform identity has value even if it does mean trusting the host to provide it.

Both SEV-SNP and TDX have ways of binding host data to a VM launch with HOSTDATA or MRCONFIG[ID] respectively, but those can't be used for authenticity claims. I'm still unsure what they're meant for.

This isn't plan of record, just cooking an idea, but does a platform-issued AKcert from a host-controlled per-instance EK sound appealing to anyone else? To get that, we'd need to agree on a hypervisor-SVSM protocol for the certificate signing request. I would hate to impose a PCKS#10 implementation on Coconut-SVSM though, so this might need to wait for C509's ratification as an RFC https://www.ietf.org/archive/id/draft-ietf-cose-cbor-encoded-cert-07.html

[stefano-garzarella]

As I mentioned in the last call, we're looking on early attestation in SVSM and we need something similar to identify each CVM. Essentially, we need a unique ID to be used with the attestation server to deliver the right encryption key to unlock the SVSM state stored in a host file and exposed to SVSM as a virtio-blk or NVRAM device. More info here (I'll post ASAP on the ML): https://docs.google.com/document/d/11ZsxP8jsviP3ddp9Hrn0rf6inttNw_Pbnz0psXlxlPs

We also thought at HOSTDATA to put that id, otherwise in the SEV-SNP firmware ABI spec, there is 4.6 Identity Block section: The identity block contains the expected launch digest of the guest, information uniquely identifying the guest, the guest policy bitfield, and a signature by the guest owner.

Can it be used also for this use case?

[deeglaze]

The unique ID for a SEV-SNP VM is the ReportID field, but if you want it to be persistent across cold boots, then it's all based on the control plane maintaining some sense of sameness. You would need a platform-held secret to sign information that's cryptographically bound to a secret used on the quote, like the Attestation Key. It can't be exported information like HOSTDATA.

If you get a report and share it for it for verification, that same HOSTDATA could be used by someone else to claim they're from the cloud platform the report came from. Not great. We'd like for that platform claim to be protected.

In GCE we have a certificate authority that provides both EK certs and AK certs. The EK certs have the control plane instance information that is also queryable from a metadata server. The AK certs we also provide from the same CA since the TPM anonymous credential activation protocol isn't valuable for cloud VMs. The VMM <-> Coconut SVSM direct communication removes the need for such complexities.

The AK can be different every boot, but the EK will be stable. You can use a different credential activation service if you want in order to issue AK certs separately from the VMM, but I don't see value in that.

Since the platform claim is bound to a non-exportable secret, the AKpriv, and the AKpriv signs the tpm quote, and the AKpub is included in the SVSM services manifest, I think that gives us a strong cryptographic binding that every quote can be verified to be coming from a TEE hosted on the certifying platform.

[stefano-garzarella]

@deeglaze thank you very much for the details!

So, IIUC the proposal, we should create a communication channel between VMM and SVSM (similar to what we were planning to do with the remote attestation proxy). This channel will be used by the host to inject EK and AK into SVSM, right?

[deeglaze]

We’d only inject the EK, since the AK is secret to the VM. We would send out the AKpub for certification though. At Google we have a paravirtual firmware device that supports a few different calls, including a feature negotiation protocol to allow copyless migration to different VMM versions that may have more or fewer feature support. This will be necessary to allow svsm to run in cloud production and evolve over time.

The device has a request page just like ghcb, and once populated, we use io ports to ring a doorbell for the VMM to read it and respond. This was written for persistent uefi variable support, so it also has a slower port-only communication channel for when the uefi doesn’t own the page tables anymore. It’s a bit clunky and could benefit from a redesign for svsm support and removal of some Google only code we add to ovmf before we publish the fork for transparency.

[deeglaze]

I've been talking more with my colleagues, and there should be no need for the host to hold any secret other than the CA private key that signs certificates. The NVDATA sealing key release protocol is something that we want to optionally depend on platform-provided claims, like project id and instance id. I know the Trustee KBS has their own key release protocol, but I'm hoping we can design a more service-agnostic key release protocol for Coconut-SVSM to get an NVDATA sealing key released to it before initializing the vTPM.

I'd need to know more details about the network proxy we expect to have access to in order to establish a connection to a key management service in the first place. Do we have anyone who's volunteered for that design work?

[stefano-garzarella]

I've been talking more with my colleagues, and there should be no need for the host to hold any secret other than the CA private key that signs certificates. The NVDATA sealing key release protocol is something that we want to optionally depend on platform-provided claims, like project id and instance id. I know the Trustee KBS has their own key release protocol, but I'm hoping we can design a more service-agnostic key release protocol for Coconut-SVSM to get an NVDATA sealing key released to it before initializing the vTPM.

Yeah, agree on that!

I'd need to know more details about the network proxy we expect to have access to in order to establish a connection to a key management service in the first place. Do we have anyone who's volunteered for that design work?

I'm the one who volunteered :-) I still have to send the proposal, but the draft is here: https://docs.google.com/document/d/11ZsxP8jsviP3ddp9Hrn0rf6inttNw_Pbnz0psXlxlPs

For the proxy, I still have to complete the second proposal in the document which we think could be agnostic enough and allow implementing any protocol in the proxy side, demanding to SVSM just the attestation report generation and asking for a secret from the attestation server. In our case, it will be a key used to unlock a persistent SVSM state, but can be used for anything else. I'll put more details in the next days in the document, but feel free to comment/suggest.

[ereshetova]

@deeglaze I have noticed this thread late, but what is really missing in our design for MRCONFIG that you are saying it cannot be used for authenticity claims: "Both SEV-SNP and TDX have ways of binding host data to a VM launch with HOSTDATA or MRCONFIG[ID] respectively, but those can't be used for authenticity claims. I'm still unsure what they're meant for."