[RFC] Reference Value Generation about trustee HOT 10 OPEN

Nice question. As the design of RVPS (the architecture confidential-containers/confidential-containers#122, section As a single executable), we leave related API, which support different entities include the users themselves to provide the guest-os, kernel, and other artifacts' reference values. The reference values can be build and calculated using related tools mentioned in this proposal, like tdx stack. When the RVPS+AS+KBS is finished, related cli-tool will also be on the schedule.

Oh, okay, this makes sense and I agree with that, please, ignore my comment above. :-)

from trustee.

What if a 3rd party and not CoCo provide the guest-os, kernel, or other artifacts? Which also means 3rd party reference values.

from trustee.

What if a 3rd party and not CoCo provide the guest-os, kernel, or other artifacts? Which also means 3rd party reference values.

Nice question. As the design of RVPS (the architecture confidential-containers/confidential-containers#122, section As a single executable), we leave related API, which support different entities include the users themselves to provide the guest-os, kernel, and other artifacts' reference values. The reference values can be build and calculated using related tools mentioned in this proposal, like tdx stack. When the RVPS+AS+KBS is finished, related cli-tool will also be on the schedule.

We suppose different software vendors publish their artifacts in a publisher-subscriber model. In this way users can decide which vendor to subscribe the binary & reference value or directly input the reference values of the binaries built by themselves.
No matter who are the vendors/software chain owners, it will be reasonable for CoCo to provide a community-version binaries and related reference values. In such a way to let the users who have no special requirements for custormized reference values and trust CoCo to set-up their own confidential containers.

from trustee.

About the process, the most important thing is step 2. This step ensures the binaries are published by CoCo community, then the logic of calculating reference values and using the published reference values will make sense.

I'm not entirely sure this is the way to go. While we provide a set of binaries that can be used by customers, there's no way what we provide is optmised for customers and / or can be used by customers without any kind of modification.

The way I see the project being used is customers being able to build their own custom images and proving way to other users to verify those.

from trustee.

I haven't found any PR on appraisal policies are we going to use OPA (Open Policy Agent)?

from trustee.

I haven't found any PR on appraisal policies are we going to use OPA (Open Policy Agent)?

Are you referring to https://github.com/confidential-containers/attestation-service/blob/main/src/lib.rs#L87?

from trustee.

The reference values for the guest-os and essentially anything between firmware and container measurement is more in the realm of TPM policy around a reference event log. The disk image provider has to provide a signed reference event log and then it's up to policy to decide if a given event log is close enough to the reference to be acceptable, since reordering, dropping, adding, etc might be permitted with additional policy.

The Keylime project is working to condense their policy generation into a single tool. After that, I think it's a good idea to recodify the policies in terms of a CoRIM profile, so the interpretation can be collectively agreed upon via the profile name and documented semantics.

from trustee.

@deeglaze In historical time, from the practical view of CoCo, we were protecting integrity of rootfs (a.k.a guest image, is this referring to disk image you mentioned?) by dm-verity, whose ability is provided by linux kernel. Once the kernel is verified as expected, the kernel cmdline of dm-verity that includes the rootfs hash can be checked.

We did not find a TPM eventlog type to record guest image hash then. If such type exists the verification chain could be easier. Do you have any ideas?

Also, afaic CoRIM is now not easy to use. So in order to quickly bridge the verification logic, we invented this Sample format to directly give reference values ​​​​for specific claims.

What about the policy you mentioned for Keylime? Is that suitable for the verification case?

from trustee.

By disk image I mean any measured disk contents, ideally designed in a way that doesn't break the boot measurement chain of custody, so yes the dm-verity solution we've all independently implemented is one form of that. We don't have much of a good story past PCR9.

If by "record the guest image hash" you mean just the kernel cmdline with its dmverity root hash, then I don't have a standard representation for that. We do want to publish the reference values we create for our distribution we use in attested environments, but right now they're just internal configuration for a proprietary attestation verification service :(

The policy for Keylime is more of an embedded DSL in Python for combining event log matching functions. They haven't yet modeled the policy in the form of a configuration language that could be evaluated safely by a policy engine that doesn't trust its input policies. They are heading in that direction though IIUC, so that's something to keep an eye on. They certainly understand TPMs really well.

from trustee.

@deeglaze Thanks for the context. As you pointed out, we do not have a good story of PCR9 (All files read, including kernel image). From the practical view, starting with definition on both producer and consumer side without following mature standard is not a bad choice. That means, in coco

1. we could make it clear what we want to measure except containers in TEE.
2. Those components are all built and provided by kata community
3. verification/reference value logic could be aligned with that.

In the future, if good and mature standard is found, we can try to align to that.

wdyt?

cc @fitzthum

from trustee.