Observations and Problems upon the RVPS ideas #1
Comments
|
hi @Xynnn007 !
A target environment (TE) is what is "measured." A reference value (RV) comprises one or more measurements associated with a TE that need to be matched together against evidence.
Each TE has a unique key that is constructed from an underlying identifier (either a class or an instance id) and further refined using namespacing parameters (at a minimum, the attestation scheme identifier).
Yes, you got the gist. I hope I haven't confused you with my inline annotations :-)
This is a string that needs to be coordinated between verifier and RVPS. For example, for CCA realm TEs it could be
hmm I don't think that was my intention. Apologies for the confusion. |
|
Thanks @thomas-fossati for the answers. Let me try to summurize what is in my mind:
There is another problem. How to decide the |
Cool. I'll inline my notes.
Yes. (A further check that is maybe worth making explicit is that the signer is someone known and also authorised to speak about the TEs in the manifest.)
Yes.
Yes.
AS should pass the TE identifier extracted from evidence, and pass it alongside the "TEE type" to the KeyMinter and get back the TE_id to use in the query. |
|
Nice. I think the proposal gives a good guide to handle compound measurements. However, I think we should think more about the last question, s.t.
When I designed RVPS I met a similiar problem and I thought a lot about this, but did not get a perfect result. The reason is for different archs, we cannot ensure to have a claim in the evidence that has enough
There are two models for RVPS. A client will directly query RVPSThere will be two roles, s.t. RVPS and the RVPS client. The data flow would be This is ok and easy. The client itself can carry a AS queries RVPSThis is critical. There will be three roles, s.t. AS, RVPS and the AS client. The data flow would be This means that either the AS client or the AS should define the
If the parameter In this way, both RVPS and AS could have a relative "clean" API without functionality coupling. The next step is to handle the TEE identity in component like KBS. The whole path would roughly be
Another issue is that the Finally, even if we use RVPS to provide reference values, AS still has its own policy engine which can be used to define any reference values manually. This may be functionally overlapped, but still seems reasonable due to different scenarios. I may have rambled a lot, but I hope that during the communication process we can gradually get closer to the final form. |
|
The core idea beneath this proposal is that RVP and Attester synchronise on how to identify the Target Environment that is to be appraised. To make a concrete example, Arm CCA evidence has two TEs:
The Platform TE has a compound identifier made of the "implementation" and "instance" identifiers. For the Realm TE, the RIM claim can be used as an identifier. Given that, the related RVs can be constructed using those IDs and associating the expected measurements. I am not entirely familiar with AMD SEV-SNP and Intel TDX, but I'd have expected something similar would be available in their respective Evidence formats. For example, AMD's CHIP_ID seems similar to Arm's Platform TE id. |
|
I might get your point. The reference values might have two parts
Does this distinguishment make sense to you? It makes sense that the verifier/validator (s.t. RVPS & AS) should know which firmware parts and content part TE should be used. In CCA we can use The problem lies in the content parts. We do not have a context of what "content"/software stack will be injected into the TEE. Although you mentioned in Arm CCA, |
💯 / 💯
cool
true. There is no explicit TE_ID in Arm CCA for the Realm/content part. However, at least to a pretty decent degree of approximation, the measurement itself can be treated as an instance identifier, given its intrinsic entropy.
I was not aware of this. It is certainly something worth exploring - do you have docs to share? Though, depending on the KBS protocol would lock RVPS into the CoCo ecosystem, which may or may not be desirable -- e.g., AFAIU there have been recent talks in the community to ensure that the core building blocks can be reusable outside CoCo. |
The components are aimed to be used outside CoCo. Let me make it clear: RVP & RVPS side.There might be two typical roles as mentioned firmware parts owner and content part owner. The former could be like OEM. The latter could be like CoCo. A typical firmware part I recommend that the and the core data of its content could be shown like (there might be some other metadata like the signer, the signature, the expire time, etc., which I does not list) {
"platform_token": {
"impl_id": "...",
"sw_components": "...",
...
}
}A typical content part In this example, and its content could be shown like (there might also be some other metadata like the signer, the signature, the expire time, etc., which I does not list) {
"realm_token": {
"rim": "...",
"rem": "...",
...
}
}ASThe aim of AS is only to check the evidence's endorsement, and the content against the given policy and AS will directly connect to the RVPS. So, when doing attestation, Another choice is AS would have a configuration that defines which KBSThe aim of KBS is to perform KBS attestation protocol and provision the client permission to access resources. We might need prepare some set-ups that tells which To leverage SummaryIn this way, the three components can be used separately. Let's just see what API they expose to understand what they are. You might not be familiar with all the components, but it does not matter as I just want to say they are relative independent and can surely be used outside CoCo.
|
If you mean what I said Justin once gave a speech. See https://www.youtube.com/watch?v=_n9FxY3vxvs 15:44 the architecture diagram. All architectures would have similar components. |
|
Hi @Xynnn007 thanks for the detailed overview. I have one comment on one of your main points, i.e., using human-readable TE identifiers. I think this is great as long as humans are in the loop. However, I don't think this is desirable at the communication boundary between AS and RVPS. This is because AS deals in evidence payloads, and evidence has no notion of any human-readable aliasing. For example, CCA platform evidence only knows about the implementation ID it carries. Translating it to some kind of text string requires a trusted resolver in the loop, and therefore a new architectural dependency. |
|
@thomas-fossati You are right. Firmware Parts could depend on e.g. CoCo community publishes a series of binaries to be deployed into the Realm for Arm platform, together with a shape manifest recording A user needs to configure the CoCo-AS to correctly verify the TE that be equipmented with the binaries mentioned. One of the important things is to configure the Case 1: If we do not have a human readable stringThe user browses CoCo’s homepage to find the corresponding release information about the Case 2: If we have a human readable stringThe user also browses CoCo’s homepage to find the corresponding release information about the But furthermore, RVPS could also serve as a public service like Or, a machine-readble one Just like an image in In the absence of more actual user feedback and other opinions, I am ok with both (human-readable or no-must-human-readable) currently. |
|
Hi @Xynnn007, thanks again for your continuous and fruitful engagement :-) Your last comment has made me think that maybe I should step back a bit to reassess the first principles on which I've based my original proposal. Recap: To me, a Reference Value (RV) is a mirror image of Evidence that we ask the Verifier to reckon as describing a trustworthy environment. Environments (both target and attesting) are defined in the RATS architecture as first-class objects, so it seemed like a good idea to be able to define such Environments while appraising them. Now, one can observe that Evidence’s claims can be usually (*) partitioned into two categories: immutable and mutable. (*) This is true for DICE, PSA and CCA platform, to cite a few. The idea in my mind was to conceptualise the immutable claims as an “ID” of the environment to be appraised, and the mutable claims as the “measurements” of that environment. Now, as you have aptly noticed, this mental model breaks down in the Realm case because there is no immutable claim that can be naturally promoted to an ID: in fact, all Realm claims are mutable. So, instead of artificially promoting RIM as an “ephemeral” ID, as I did in my original proposal, it’s probably better to drop the TE_id idea altogether because it creates more confusion than order :-) However, from a practical standpoint, when matching RV against Evidence we need to efficiently look up candidates from a potentially very big stash of RVs. Therefore, having some kind of lookup key looks like a necessity. So, I suggest we repurpose what I previously called "TE_id" to "RV lookup key" with visibility limited to RVSP and AS (i.e., without humans in the loop). Re-scanning the original proposal, I reckon that just by renaming "TE_id" to "rv_key" (or similar) and adjusting the semantics accordingly, the whole architecture still stands. If we need to add richer metadata to the RV, we can always recycle the "endorsed values" concept from CoRIM, where at the time the manifest is created, "endorsed values" pertaining to the specific CoCo workload (e.g., name, version, author, link into a transparency log, etc.) can be added alongside the expected RVs as extra info that AS could (if it wants to) add to the returned attestation result. WDYT? |
|
Thanks @thomas-fossati ! I think the abstraction of I totally agree we should have some key like The problem is how to define the I am willing and happy to be involved in the spec work. After that, we can start to do the refactoring upon RVPS. |
I think it's easier if it's evidence-based because then we can avoid depending on a new translation component.
Awesome, thanks! How should we continue this work? Is it OK to converge on a design here, or should we move it to the CoCo repo? BTW, I wanted to make a couple of further additions to my original proposal, namely:
|
Done in b797d2d |
|
Which makes me feel more that we should define a non-evidence-based |
Hi @thomas-fossati , thanks for the design and idea. I think this is also strongly related to thread confidential-containers/trustee#238.
Here are some understandings after reading. Please correct me if any is not right
TE, which defines a specific set of claims (rv) that must be matched at the same time.TEhas a relative key in RVPS for callers to index the intendedTE. The key is in format likervps:cca+realm:02c4.... How to get the key name? It is calculated by the black boxKeyMinter, which receives parameters MediaType (a constant?), tee typeE, andscheme-specific-idAre these right?
Here are also some questions. Please forgive me for the sally questions:
scheme-specific-idshould be used when get the key fromKeyMinter?In https://github.com/thomas-fossati/rvps-ideas?tab=readme-ov-file#ingest-push-model step (5), does it mean that in
Storethe value ofk[i]contains only onerv?The text was updated successfully, but these errors were encountered: