Pick a name

[fitzthum]

kbs-rs is a relatively generic name. This is not supposed to be the "official" attestation server for CC and it currently has a relatively narrow scope. Maybe we should pick a name that is less generic. On the other hand, the project is probably going to grow at least a little bit so we should choose a name that does not limit this or cause confusion in the future.

Specifically, we are thinking about supporting an online kbc/kbs for SEV(-ES) and maybe supporting this online approach via an encrypted image for Secure Execution. None of the other attestation servers support either of these options. We have also talked about supporting SNP and maybe even TDX, but we don't have any concrete plans for this. EAA/Verdictd already supports these platforms. I don't yet know the best path forward for SNP.

I am not attached to the current name, so if we can think of something that is a bit less generic while still being somewhat flexible, I am all for it. On the other hand, if we are clear about purpose and scope elsewhere in the project, maybe the name doesn't really matter that much.

[jiazhang0]

I think kbs is a hardware irrelevant component and it acts as the term "relaying party" according to RATS arch. Instead, what is really communicating with KBC to directly or indirectly retrieve the evidence (yes, this is only case where a runtime attestation procedure uses) is "verifier". From a long term, it is better to separate them. kbs is a specific instance of relaying party, which might be vendor-specific, and it is highly related to business and use case. "verifier" can be a layered design: the upper layer is general (with an appraisal policy engine), and the lower is hardware TEE vendor-specific (Intel PCS/PCCS, AMD KDS). If the lower is implemented by a set of low level verifier drivers for various hardware TEE platforms (sgx, tdx, snp and so on) with proper encapsulation, the entire "verifier" can be general.

I suggest we can share a general "verifier" which encapsulates all possible low level verifier drivers with modulization design. Verdictd can be a candidate of "verifier".

[fitzthum]

Yes, in general I think it's a good idea to separate the attestation server from the platform-specific logic that validates launch information. Ideally the attestation server will be modular just like the attestation agent.

There are a couple of different ways to break it down, but I think what you're saying is that there is

• KBS / AS - implements the API that talks to KBC, calls appropriate verifier
• Verifier
  • Policy validation - i.e. is the launch measurement what I expect
  • Platform validation - i.e. is the attestation report correctly signed

I think this is a pretty good way of thinking about it. This kbs is so simple that I didn't bother to separate out the different components. In fact it is mainly focused on policy validation, which I felt was missing from some of the existing options. I think it is a good idea to minimize code duplication, especially at the lowest level.

[jiazhang0]

KBS / AS - implements the API that talks to KBS, calls appropriate verifier

typo? implements the API that talks to "KBC"?

[jiazhang0]

KBS / AS - implements the API that talks to KBC, calls appropriate verifier

I think there are several functions that KBS / AS needs to implement from a long term:

• retrieve the attestation results returned by verifier as input and then authorize the operation requested by attester if approved by KBS / AS.
• support access methods to KMS and DB (related issue addressed) in modulization.
• normalized message formats (JWT or CBOR or anything else), interaction model and transport protocols used between KBS-verifier and KBS-KBC.

[hdxia]

What is the scope of the KBS here? and what is the architecture design for KBS? without the scope/goal and architecture design agreed by community, it is hard to understand the issue here.

From our experience of KBS implementation, KBS needs to deal with key policy management, different types of attestation, and support different kinds of KMS (very user and CSP specific). and there are quite a few KBS implementations out there. why cannot we point to existing implementations, but create a new project to reimplement?

[sameo]

It seems this conversation is drifting into an architectural one, although we're only looking for a name that reflects more accurately the scope of this new code base :-)

There are clearly some interesting proposals as to how we could architect a attestation/secret/key backend for CC here, and I think this is not really the current scope of kbs-rs. @fitzthum, please correct me if I'm wrong here. Extending the scope of the CC project to fully support attestation and verification backends is something we should discuss in a separate issue, although I believe that by including an attestation agent implementation to the project, we should at least provide the first part of its server counter part as well (The above mentioned attestation server).

Now, to get back to the topic of that issue (remember, renaming the project :-)), I would characterise the proposed code as:

• A good example of how an attestation agent KBC and a KBS could interact
• SEV-ES specific
• Compatible with the attestation agent offline KBC
• Bundled: It includes everything from the attestation server (server end of the KBC), the verifier, the policies and the database stored secrets

The name we want to pick should not be too specific in order to allow for extending that code base to e.g. support SEV-SNP or SE without having to rename it again. But we'd want it to be less generic in order to not confuse people as to what the scope of this project is. Let's brainstorm a little bit with a few proposals:

• offline-kbs - maps to the fact that it currently only works with the offline KBC. It's restrictive
• kbs-bundle, kbs-clump - It's bundled
• kbs-reference, kbs-example - keep it generic while highlighting that it's only a reference/example
• as-example - Same as above, but with attestation server
• croupier, c-croupier, croupie-rs - Trying to be creative around croupier, a much less contentious term...

Feel free to add more, or pick one and let's move on :) I'd much rather spend my time discussing architectural proposals for a generic KBS in CC and/or seeing code contributions to that repo. (whatever the name is)...

[fitzthum]

I think kbs-reference or reference-kbs or simple-kbs would be fine. Any other ideas or preferences?

[sameo]

I think kbs-reference or reference-kbs or simple-kbs would be fine. Any other ideas or preferences?

simple-kbs sounds good.

[Jakob-Naucke]

simple-kbs sounds okay. Not really in favour of *example (sounds like something that isn't actually usable) or *reference* (sounds like we're trying to be more official than anything else) or croupier* (maybe a trigger word to the recovering gambling addict? idk)

[hdxia]

still, I am not sure what we are trying to achieve here, and what is the governance process to add code/example in CC. without good understanding, it is hard to recommend a name. If CC decides to need a KBS, we should go through design process/definition of the goal, similar as other components such as ocicrypt-rs, image-rs, KBC, etc.

[fitzthum]

@hdxia The basic idea with this project is straightforward. It provides a component that is required to use CC with SEV(-ES). Pre-attestation has been out of scope for any of the existing attestation options. When we first setup CC with SEV we provided some python scripts that served a similar purpose, so the basic functionality has been known about for a long time. We wanted to improve those scripts and find a good place to host them. This is the result. The goal is not to create an official or general KBS and it isn't to compete with any other offerings. That said, I don't want to completely lock-in the scope because there may be some improvements like support for online attestation for SEV(-ES) and Secure Execution with encrypted images.

Honestly, I think the scope of this project is simple. The real ambiguity comes from the fact that the broader attestation picture is not yet clear. For example, the solutions for SEV-SNP attestation are still emerging. I don't want to completely rule out SNP support in this project yet because we're only just starting to see what the other options look like. That said, I don't personally plan on working on SNP support here anytime soon and I am fully committed to finding a solution that works best for the whole community. I fully agree that we need should have a rigorous community design process (see Samuel's issue) if we want to develop an official KBS/AS. That is not the goal of this project. This isn't so much like ocicrypt-rs or image-rs which are fundamental pieces of CC that everyone will have to use. This project is more like td-shim or cloud-api-adaptor which are inherently tied to the project but won't be a part of every deployment.

[hdxia]

@fitzthum I think the intention is good, but simple is not that simple to me, but complicated. if this becomes part of CC, it needs to be maintained by CC and every code change needs to be reviewed. however, it will fail and go wild without any design/agreement from the community. if it stays in its own repo and referred by CC, the maintainer can do what they need.

[fitzthum]

@hdxia I guess I just don't see this project being as popular as all that. The init code does most of what we need. I've made some issues regarding a few future improvements. I don't really foresee a massive amount of other development in the near future. It seems like it should be relatively easy to maintain. If some random person comes with a huge PR that complicates things, we will stop and discuss it in the broader context of the community.

[sameo]

I agree with @fitzthum here. Compared with existing implementation, those few hundreds lines of rust code for a complete KBS is arguably simple. We can make sure the scope for this project is to keep it as a simple, standalone KBS.

As a project, we should discuss if we want to implement and support something more generic, complex and supporting many protocols and hardware implementations through https://github.com/confidential-containers/documentation/issues/26

[larrydewey]

@hdxia your argument regarding code maintenance is a valid concern, but falls a bit outside of the scope of this discussion. Perhaps by establishing the project's scope, and then finding a matching name will help to ease concerns about maintainability?

I think simple-kbs accurately describes this project, so it has my vote.

[jiazhang0]

Now, to get back to the topic of that issue (remember, renaming the project :-)), I would characterise the proposed code as:

* A good example of how an attestation agent KBC and a KBS could interact

* SEV-ES specific

* Compatible with the attestation agent offline KBC

* Bundled: It includes everything from the attestation server (server end of the KBC), the verifier, the policies and the database stored secrets

@sameo @fitzthum @hdxia If we are targeting to implement a sample-kbs, it should be simple enough without so many features to describe. About sample-kbs, AA has already one: https://github.com/confidential-containers/attestation-agent/tree/main/sample_kbs It proves how a hardware-irrelevant kbs is possibly communicated with kbc to provide the connection with attestation-agent. More specific, the specific hardware support such as SEV-ES should not be part of sample-kbs. It should go the general kbs/product/sev-specific implementation (to be discussed in https://github.com/confidential-containers/documentation/issues/26 ). Even pre-attestation is unique, but it doesn't mean it cannot be described as runtime attestation with a high level design. I think the function scope and naming of this project should match up. The features described above sounds more like a general kbs and it just provides the first support for SEV-ES TEE. If so, I would vote keep kbs-rs without renaming it. Otherwise, sample-kbs should be simple, generic, essential and hardware-irrelevant.

In summary, once we are trying to fill more things into sample-kbs, it will tend to talk about a general attestation service/kbs IMO.

[fitzthum]

@jiazhang0 The sample KBS in AA has a different purpose (and should maybe be renamed). That sample KBS implements the wrap_key interface that the AA does not implement. That sample is really for use with skopeo so that you can encrypt a container image. It does not implement the un_wrap_key interface or any interface with a KBC so you can't really use it to decrypt containers. You can use the json file that the sample KBS builds with the offline_fs_kbc but this is only secure if you have an encrypted disk image. In other words, the sample KBS isn't hardware independent. In fact it really only works with Secure Execution.

But the proposal here is to change the name to simple-kbs not sample-kbs. I agree that this isn't really a sample. Instead, it's just a small, self-contained KBS that doesn't work for all platforms but is very easy to use in certain circumstances. I think there will always be a tradeoff between a simple KBS that people can quickly setup and easily look through the source of and a fully-featured KBS that supports multiple differing attestation schemes. I think that simple-kbs is a pretty good name and a pretty good direction for this project.

As you say, a general KBS could support pre-attestation, but as I understand it none of the current general-purpose offerings do. Adding support for pre-attestation would increase complexity even more and I think it is probably wise to focus a general KBS only on platforms that do runtime attestation. As long as we can come to some agreement on a general KBS, I don't think there would be any need to add support for runtime attestation here.

[jiazhang0]

But the proposal here is to change the name to simple-kbs not sample-kbs.

Oops! I didn't recognize it sorry.

I agree that this isn't really a sample. Instead, it's just a small, self-contained KBS that doesn't work for all platforms but is very easy to use in certain circumstances. I think there will always be a tradeoff between a simple KBS that people can quickly setup and easily look through the source of and a fully-featured KBS that supports multiple differing attestation schemes. I think that simple-kbs is a pretty good name and a pretty good direction for this project.

I agree on its position. The following statements looks out-of-scope of simple-kbs:

That said, I don't want to completely lock-in the scope because there may be some improvements like support for online attestation for SEV(-ES) and Secure Execution with encrypted images.

But I understand your contradiction point, as you mentioned, which is caused by the broader attestation picture is not yet clear.

As you say, a general KBS could support pre-attestation, but as I understand it none of the current general-purpose offerings do. Adding support for pre-attestation would increase complexity even more and I think it is probably wise to focus a general KBS only on platforms that do runtime attestation. As long as we can come to some agreement on a general KBS, I don't think there would be any need to add support for runtime attestation here.

Agreed. Getting some agreement on a general KBS would be helpful to define the scope of this project. Otherwise, this project will need to support more hardware platforms for the same purpose as you currently mentioned for SEV(-ES) platform, and by then the scope of project will be re-discussed again.

About how to handle pre-attestation in a same manner with runtime attestation, I have some ideas. But currently it is not the moment.

[fitzthum]

Ok it seems like simple-kbs is the leading contender. I want to change the name early next week and try to merge the init PR.

I want to reiterate that this not a hugely ambitious project. I know some people might be skeptical about that, but I can at least guarantee that I don't have time to do anything more ambitious than what I have already outlined. Like I said, if other people want to reshape the scope of the project, we will step on the brakes and make sure that it fits with the community.