Is CoRIM appropriate for TDX and SEV-SNP?

[deeglaze]

Hi y'all, I've been looking into CoRIM as a way we might endorse guest firmware for a confidential VM in a way that is usable across both TDX and SEV-SNP, hopefully more technologies in the future. I haven't seen anyone publicly say we should use CoRIM for VM firmware, but it seems the closest standard.

My understanding is that TCG RIM and IETF CoRIM come from the physical machine attestation space, and not virtual machine attestation. I don't see CoMID being useful for CVMs for instance, since guests will be able to request certificates directly from the hardware in their TCB in the future. We're then left with CoRIM as a wrapper for a singular CoSWID for the guest firmware, plus the CoRIM's security version number.

SEV-SNP already has the IDBlock to attest to the fact that the firmware is signed by the party, and has a certain security version number. TDX doesn't have anything similar, but we could use MROWNER to at least indicate the firmware vendor for where a user could download a certificate, named by the MRTD value.

So I'm left with a bit of a struggle with the weight of this format as compared to, say, just generating a throw-away public key and signing an X.509 certificate with information we want about firmware in an x509v3 extension. Basically we'd just have the firmware measurement and the security version number. That format could work very simply in existing code ecosystems that don't already support a new RFC like COSE. It's kind of against NIST SP 800-155 section 3.2.2.4's call for an open standard for firmware integrity, but with publication of the format, it might be open enough.

[nedmsmith]

VMs/TDs are somewhere in between where CoSWID (SWID tags) and CoMID are targeting as a way to track e-assets. SWID/CoSWID have the challenge that it originated from a use case that wanted to track the SW (tags) independently from where it was installed. It didn't try to identify the machine/environments but instead opted to model (roughly) the filesystem layout where the various files existed. The TCG defined a variant RIM that extended SWID to include a "Platform" and "Firmware" components that the SWID can run on. The DICE WG is developing an extension to CoMID that adds a triple record for associating a CoSWID with an "environment" which is the CoMID way of describing components or platform.

Use of X.509 for attestation evidence is documented in the DICE Attestation Architecture specification. There is semantic interoperability between the X.509 evidence format and CoMID.

Using X.509 for endorsement isn't unheard of, but has the complexity that certificates are instance-based vs. class-based. If there are 100K instances of widget-X then there will be 100K instances of the endorsement claims. There is likely a class schema that is common for all 100K certificates since all would be pretty much identical (except for the key / devID parts). That schema is what CoMID + CoSWID are trying to be. The idea that CoRIM (the combination of CoMID + CoSWID + COSE signing) is a way to finalize the schema into a document that has integrity protection. But the various parts are separable, indeed CoRIM defines an 'unsigned' variant. So, for example, an X.509 attribute certificate with an extension for 'unsigned corim' could be a way to integrate into the X.509 world.

But short of defining a schema, the question of what to include/exclude for a given certificate it seems the approach being described is making a few simplifying assumptions that likely would differ for differing components / platforms.

[deeglaze]

Thanks for the response. I don't think we're imaging the same use of endorsement. Each VM in the fleet gets launched with the same firmware that we'd sign on release. There wouldn't be hundreds of thousands of endorsements. The key chain would be short too, like a CSP published VM integrity root key, an intermediate key signed by the root, and that intermediate would sign the endorsement.

Both SWID and CoSWID don't have security version numbers the way comid has, which puts a damper on using them for something like a confidential VM's firmware.

The "file path" way of doing things for RIM is also awkward in the confidential VM case. There doesn't appear to be an expected path to "the firmware" that a tool would know how to pick out from a RIM even with the ReferenceManifestGUID, because the guid names the RIM and not the measured file. I haven't seen these formats actually used, so I'm not sure how these problems are resolved in practice.

How do you think the a firmware vendor and VMM provider should endorse their controlled values of an attestation report? For SEV-SNP it's IDBlock, but for TDX there's nothing, and I don't really see a direct mapping to CoRIM how sign everything like MRTD (the TD measurement), XFAM, and ATTRIBUTES all together to provide a security-versioned and endorsed measurement of the firmware. The CBOR object we might sign would just represent CSP-controlled values of the TEE report, an SVN, the cert chain of the key that signs the object, and maybe a timestamp.

[yogeshbdeshpande]

Hi,

Thank you for nice observation and a good food of thought for CoRIM Authors.
I am not very familiar with both TDX and SEV SNP, but I would certainly like to explain the CoRIM/CoMID capabilities and the extent of flexibility it offers when carrying any reference measurements.

I agree that the concept of a Module Identifier does lead to physical machine attestation space but that does not necessarily mean it restrict the user only to that space.

One can abstract any computing environment as a Module (with a unique identifier) and associate a set of firmware to that module/environment.
This then does provide an environment to uniquely define the set of reference measurements or to carry certificates associated to it. The Information and Data model is flexible for natural extension to multiple firmware or multiple certs in a set of triples represented in a Concise Manner (which is more optimized) than a Certificate Extension in an X509V3 extension.

[thomas-fossati]

hi @deeglaze

Awesome use case, thanks for bringing it to the table.

As @yogeshbdeshpande said, you need an "environment identity" to anchor the CoMID reference value.

In the SNP case, I guess the two natural candidates are the FAMILY_ID and IMAGE_ID carried in the ID block. They sound like an excellent fit for a CoMID environment.class, which can act as the subject of a reference-value triple. Its object being a measurement-map with digest and svn fields set to the ID block's LD and GUEST_SVN respectively.

I haven't done the semantic mapping exercise for TDX, but I'd expect something similar can be achieved. @nedmsmith WDYT?

Obviously, if you need help with laying out the structure we (and cocli) are here to help you!

[nedmsmith]

Some of the observations you make are what motivated the comid work as several of us tried for at least a year to make coswid fs abstration fit embedded systems.

The point of comid/corim is it is a base schema that has many anticipated extension points. If the base schema isn't adequate for capturing a particular measurement, or logical construct, the base schema should be extended (under the umbrella of a standards setting organization).

[thomas-fossati]

@nedmsmith since you are on it, in a previous comment I'd posited the following:

I haven't done the semantic mapping exercise for TDX, but I'd expect something similar can be achieved.

With your TDX hat on, is that something that can be done similarly to SEV SNP?

[nedmsmith]

I'm not an expert on SEV SNP, but it seems possible that most if not all TDX claims can be mapped to something in the base schema. Nevertheless, if there is value in extending the schema to find a more natural mapping that option is also on the table.

[yogeshbdeshpande]

@deeglaze If you are interested in SEV SNP Endorsements, using CoRIM as the schema, please join Veraison Open Source Meeting which happens every Tuesday 04:00 PM UK time. Some of our Open Source Contributors are actively working on Modelling SEV-SNP Endorsements using CoRIM.