Resume the development on this general KBS project

[jiazhang0]

Essentially, this project is part of general attestation infrastructure design for CC community. See https://github.com/confidential-containers/confidential-containers/issues/119 for details.

However, the progress of this project is not ongoing as expected and thus we still don't have a prototype yet. As a member of promoting the establishment of the general attestation infrastructure for CC community, I hope to seek a successor to resume the development of this general KBS project and make it available in a future CoCo release with attestation-service.

As part of the general attestation infrastructure for CC community, the attestation-service project has already had a prototype, and recently it integrates the Reference Values Provider Service (RVPS) module to retrieve the trusted reference values from supply chain / artifact provenances to accomplish a full functionality of attestation service, according to RATS architecture. In addition, this attestation service implements a verifier driver framework to support multiple verifier drivers for various TEEs. The last piece of puzzle is the message protocol between KBS and attestation-service. Obviously, this work requires a KBS to make it happen.

Sergio seems to be interested in this. He proposed the enhancements on the KBS message protocol between KBS and KBC. According to https://github.com/confidential-containers/kbs/issues/7, Sergio has already had a reference KBS at https://github.com/virtee/reference-kbs.

So we can chose to resume KBS development, or alternately use Sergio’s initial implementation if he would like. Either would need to meet the following requirements:

• Make the KBS implementation take place in this project in CoCo community.
• Adapt the defined KBS message protocol.
• KBS needs to interact with attestation-service for evidence verification and returning attestation results.

[jiazhang0]

@sameo @fitzthum @jialez0 @peterzcst @hdxia @confidential-containers/attestation-service-maintainers

[fitzthum]

@jiazhang0 thanks for the update. I agree with everything you are saying. I think the reference KBS is a strong contender. As far as I know it implements the KBS and the attester together. I think we are still committed to having those as separate components so we may need some adjustments.

At least now we don't have to use Go.

[larrydewey]

cc @slp

[slp]

reference-kbs implements both KBS and AS as a single entity to simplify the deployment for users who want to test the waters of Confidential Computing. In fact, we even provide a ready-to-go reference-kbs container image.

That said, I think it should be relatively easy to refactor the code and place the AS functionality behind a built-time conditional (a cargo feature, in Rust lingo), so it can fulfill both roles with the same code base.

Now, another question is about where the project should reside. Since the KBS attestation protocol is generic enough to support many Confidential Computing execution models, KBS implementations can potentially go beyond the scope Confidential Containers, which makes me think VirTEE (which intends to host components that can be used in Virtualization-based Confidential Computing, in general) is a more appropriate home for them (adding maintainers from the various stakeholders). But I reckon there may be some strong reasons to have it here, so if that's the case, please let me know.

[jialez0]

Now, another question is about where the project should reside. Since the KBS attestation protocol is generic enough to support many Confidential Computing execution models, KBS implementations can potentially go beyond the scope Confidential Containers, which makes me think VirTEE (which intends to host components that can be used in Virtualization-based Confidential Computing, in general) is a more appropriate home for them (adding maintainers from the various stakeholders). But I reckon there may be some strong reasons to have it here, so if that's the case, please let me know.

I still think that at present, the confidential container organization is the most appropriate location for KBS, because the confidential container here is actually a broad concept. It not only includes the virtual machine based TEE execution form, but also includes the process level execution form like SGX. There may be more in the future. You can understand the "confidential container" as the product of the combination of HW-TEE and the cloud native system, and KBS plays a role mainly in this scenario where HW-TEE runs on a third-party hosting cloud native infrastructure.

[fitzthum]

I don't have super strong feelings about where the KBS should live, but here are a few thoughts.

Today the CC project contains the AA and the AS. It might be nice to have all the components for the entire flow in the same project. Of course now that we've defined the spec we can theoretically use a generic KBS, but I think there are still a number of pieces that need to be tightly coupled. For instance, the interaction between the KBS and the AS isn't really documented. Beyond figuring out an API between the two, users also need to consider the behavior of both when writing policies for the KBS which depend on outcomes from the AS. This doesn't mean that they have to live in the same place, but it might be nice.

There is something similar between the AS and the KBS. While the general API is well documented, the KBS will need to perform a number of duties that are somewhat project-specific. For instance signature verification depends on the get_resource endpoint of the KBS. We need to make sure the KBS will support that. The KBS could handle signatures and policies as generic blobs, but it might be nicer if the KBS knew something about them or was even able to automatically generate policy files. This is a bit vague a this point, but the point is that there is a fairly strong link between features that we might want in the KBS and the way that the AA and CC more generally use the KBS. I think this goes beyond the API.

[jialez0]

Today the CC project contains the AA and the AS. It might be nice to have all the components for the entire flow in the same project. Of course now that we've defined the spec we can theoretically use a generic KBS, but I think there are still a number of pieces that need to be tightly coupled. For instance, the interaction between the KBS and the AS isn't really documented. Beyond figuring out an API between the two, users also need to consider the behavior of both when writing policies for the KBS which depend on outcomes from the AS. This doesn't mean that they have to live in the same place, but it might be nice.

Agree. As for the interaction between AS and KBS, I added a README document in PR in the AS warehouse, which describes this part: https://github.com/confidential-containers/attestation-service/pull/18

[sameo]

There is something similar between the AS and the KBS. While the general API is well documented, the KBS will need to perform a number of duties that are somewhat project-specific. For instance signature verification depends on the get_resource endpoint of the KBS. We need to make sure the KBS will support that. The KBS could handle signatures and policies as generic blobs, but it might be nicer if the KBS knew something about them or was even able to automatically generate policy files. This is a bit vague a this point, but the point is that there is a fairly strong link between features that we might want in the KBS and the way that the AA and CC more generally use the KBS. I think this goes beyond the API.

I agree as well. I also don't have very strong feelings about it, my main concern being about having a well maintained reference implementation of the spec. @slp, although there are no absolutely mandatory reasons for moving your kbs implementation here, it seems that people tend to think this would be a better place for it (mostly for interaction with the other services). Would you consider moving it here and thus making it the "official" reference implementation? Obviously, you'd have full admin rights on the repo, etc.

[slp]

If this helps to get more people involved in reference-kbs, it's probably worth it. I guess we should also move the kbs-types crate here, and create a group in crates.io to manage its releases.

[jialez0]

If this helps to get more people involved in reference-kbs, it's probably worth it. I guess we should also move the kbs-types crate here, and create a group in crates.io to manage its releases.

@slp Sounds great! But does this mean that we need two repo, one called kbs and the other called kbs-type?

[sameo]

If this helps to get more people involved in reference-kbs, it's probably worth it. I guess we should also move the kbs-types crate here, and create a group in crates.io to manage its releases.

@slp Sounds great! But does this mean that we need two repo, one called kbs and the other called kbs-type?

I hope we can have the kbs repo hold those two.

[sameo]

@slp If you're ok moving reference-kbs and kbs-type into this repo, should I open a PR for that? Or are you planning to do the move yourself?

[slp]

@sameo Sorry to keep you waiting. I've been thinking a lot about this, and I honestly prefer to keep both kbs-types and reference-kbs at VirTEE, as way to guarantee they are seen as project neutral components, just as sev and sevctl. We'll of course welcome contributions and, ideally, we should eventually get multiple code owners designated.

[sameo]

@sameo Sorry to keep you waiting.

No worries @slp.

I've been thinking a lot about this, and I honestly prefer to keep both kbs-types and reference-kbs at VirTEE, as way to guarantee they are seen as project neutral components, just as sev and sevctl.

I think the move was not an obvious one, so we understand your logic here. reference-kbs is somehow a bit SEV and pre-attestation specific, so it makes sense for it to not be perceived as a generic and agnostic implementation of KBS.

We'll of course welcome contributions and, ideally, we should eventually get multiple code owners designated.

One thing we may start working on is having part of kbs-types extracted as a non-TEE specific crate for the generic kbs data types? @jialez0 wdyt?

[slp]

One thing we may start working on is having part of kbs-types extracted as a non-TEE specific crate for the generic kbs data types? @jialez0 wdyt?

FWIW, the SEV types are gated behind the tee-sev feature. Without it, only the base KBS types are brought into the context.

[jialez0]

FWIW, the SEV types are gated behind the tee-sev feature. Without it, only the base KBS types are brought into the context.

@slp Such encapsulation is good, so if so, could the general part of kbs-types be maintained under the CoCo (Confidential Containers) organization together with its definition document? If not, if we want to update them in the future, we need to update the definition document in CoCo kbs repo, and then update the kbs-types code in virTEE. Is this a bit inappropriate?