Reference values in evidence bundle

[deeglaze]

The IETF RATS working group is standardizing a Conceptual Message Wrapper format that allows an attester to bundle different "conceptual messages" to send along the attestation conversation.

Concepts include evidence, endorsement, reference values, and attestation results.

The TCG PC Client Platform Firmware Profile allows for an event log to include unmeasured events to point the verifier to the signed reference measurements of the firmware through an event named after NIST Special Publication 800-155. I've written the extraction logic that can interpret raw data, UEFI variable pointers, and URI pointers. I haven't added UEFI local device path support.

It's often beneficial for an attester to send along any node-cached reference values since there could be updates that haven't made their way to the RVPS before attestation, but are signed by a trusted authority.

The SP800155 event is but one pathway to provide reference measurements. For VMs that don't have mount efivarfs for whatever reason, the AMD extended guest request ABI allows for the host to provide extra data with GUIDed entries of their own (e.g., https://github.com/google/gce-tcb-verifier/blob/main/sev/endorsement.go#L31)

The format I've proposed for signed firmware measurements is a couple years old at this point, and I've been working with the IETF to get CoRIM to a better state for us to use, so let me know if Trustee would accept any GCE-specific logic for interpreting our signed protobuf thing or if you'll wait until we deploy CoRIMs.

We haven't had much of an industry discussion on what CoRIM profile we should use for SEV-SNP and TDX anyway, so with that format comes further interpretation that's still undecided.

[fitzthum]

At the moment our reference value provider is simplistic. It is a key-value store that is provisioned by the operator of the KBS. We are on the verge of implementing something more sophisticated (hopefully), so your issue is well-timed.

Two things that we have discussed are adopting a more expressive format for reference values (potentially CoRIM) and introducing a mechanism to share contextual values such as a workload class between host, guest, workload, relying party, verifier, etc. I think this is related to what you mention.

We have not discussed sharing reference values directly from the guest/worker, but this seems like it could be a reasonable thing to do. You might be able to implement something like this with init-data and a sophisticatd Rego policy. Otherwise we would probably need to think about extending the KBS protocol. I'd need to think more about how to support this.

Another approach would be to add your extraction logic to the RVPS such that the GCE manifest thing could be consumed directly. This probably wouldn't help you push reference values from a worker node to the verifier, but it would at least allow the RVPS to consume the reference values. In theory the RVPS should be able to consume reference values from many different formats, so this could be a natural fit. On the other hand, we're not yet sure how to best handle these reference values internally so there is still some thinking needed here.

[deeglaze]

The extraction logic that needs to touch the network is a fallback option if you don't have the reference values forwarded by the attester, that's true, but that requires the reference values to be served online rather than only through presentation to the guest via cert chain or UEFI variable. That's not always the case.

[deeglaze]

I'm probably asking for a big protocol change to use CMWs to allow for more media type and conceptual message type freedom, yeah.. :-/

[Xynnn007]

I think this makes sense in some cases where attesters send fresh evidence along with signed reference values. At the same time, we should also offer enough flexibility for users to determine whether or not to accept such kind of reference value source and also the verification granularity (like signer, expired/ , etc).

Do you have any plan or concrete design for this?

[deeglaze]

Our attestation flow has been homebrewed to link up to the existing vTPM tool we had for Shielded VMs in Google Compute Engine, but I'm looking at how we can better support the more open ecosystem of CNCF and CCC projects.

The concrete plan for us has been to multivariate. I publish our signed measurements to a cloud storage bucket with an object name derived from the golden measurements. The object is our own VMLaunchEndorsement protobuf message format that has signed golden measurements for a single firmware release. There can be multiple measurements because both TDX's TDVF and AMD SEV-SNP without SVSM have different measurements depending on the size of the machine (ick). We might be able to change that later, but for now I copy-paste for all expected measurements.

I provide the same signed document to the VM (or will, when I can finally flip the flag) in the AMD SEV-SNP extended guest request aux_blob at a specific GUID.
For TDX there is no aux_blob, and the TCG just published a new spec last December that allows writing an unmeasured event that has a RimLocatorType that actually directs a verifier to how to get the reference measurements. I post two such events. One is an event that points to a UEFI variable we inject, and another with a URI that points to the firmware signature in the cloud storage bucket.

The derived object name is no longer a required strategy with this SP800155 event, but I haven't gotten rid of it yet. I'm still trying to upstream the opt/org.tianocode/sp800155evts fw_cfg passthrough to get events easily posted from the VMM side tianocore/edk2#5738

[Xynnn007]

@deeglaze Have you ever considered another way, s.t. add Google attester/verifier plugins in both AA and AS? In this way, you can implement any claims of the attester environment, thus on the verifier side any policy could be written with proper golden reference value.

Like what Azure did