RVPS limitations #238
Comments
|
Hi @thomas-fossati Thanks for the issue.
Same problems exist in other architecture like TDX. Currently we will flatten the evidence claim. See https://github.com/confidential-containers/kbs/blob/main/attestation-service/attestation-service/src/utils.rs#L84-L141 for an example of unit test. In this way we can use simple key-value pairs in RVPS. This is surely not the best solution, but currently it can help to reduce the complexity of the compound structure.
This may be reasonable. Currently RVPS is used in conjunction with AS, and we are still completing the overall functionality of the remote attestation architecture. RVPS multi-tenancy would be a later consideration and TBO I did not think much about the design of multi-tenant. In addition, in some existing scenarios, we will run a separate CoCo-AS+RVPS service for each tenant in a single-tenant model. Although this may not be the best method, it can temporarily solve some problems.
Yes. Currently this part is still in baby state. There is a component named
This is a interesting idea. Current AS will query RVPS only for allow list. We will think more about this. |
|
Hi @Xynnn007
I am not sure I fully understand. What I think I am hearing is that for TDX you are actually using:
If this is how the store is meant to be used - i.e., the value in the key-value pair is just an opaque string (it doesn’t matter if it’s some JSON, flattened or raw, or a base64-encoded “anything”, as long as the consuming verifier knows what to expect and how to interpret it), then I suggest to rename the hash_value to something that makes the intention clear.
Sure, allocating one RVP+Verifier to a specific tenant is one way to work around this. But there’s another dimension to multi-tenancy, i.e., the fact that even a single tenant will, in general, consume multiple evidence formats. And I am not sure (please correct me if I’m wrong) that the lookup key is currently namespaced based on the attestation scheme, i.e., that the store is clearly partitioned.
The pre-processor looks like a pretty sensible place to put the AAA function. However, my point was that once the supply chain actor is authenticated, the authorisation info (role, ACL, …) needs to be propagated through the processing pipeline down into the store layer, and there are no placeholders for that, currently.
Cool! And thank you! |
OK, I think I understand what you meant. However, I don't see how this really solves the problem of bundling a bunch of separate measurements into a single, compound reference value. For example, suppose I have only two possible acceptable states for my CCA realm:
{
"initial-measurement": "a1",
"extensible-measurements": [
"b101", "b102", "b103", "b104"
],
"personalization-value": "c1"
}
{
"initial-measurement": "a2",
"extensible-measurements": [
"b201", "b202", "b203", "b204"
],
"personalization-value": "c2"
}If I use the same "flattening" strategy as in the TDX example you linked above, the reference values I'd end up supplying to the RVPS would be: {
"cca.initial-measurement": [ "a1", "a2" ],
"cca.extensible-measurements.0": [ "b101", "b201" ],
"cca.extensible-measurements.1": [ "b102", "b202" ],
"cca.extensible-measurements.2": [ "b103", "b203" ],
"cca.extensible-measurements.3": [ "b104", "b204" ],
"cca.personalization-value": [ "c1", "c2" ]
}correct? Now suppose that some mix-and-match evidence like the following comes in: {
"initial-measurement": "a1",
"extensible-measurements": [
"b201", "b102", "b203", "b104"
],
"personalization-value": "c2"
}It would be a match because all the reference values, taken independently, are known and good. But, in this combination, they do not describe an acceptable state for the attester. |
|
@thomas-fossati Currently we can edit any rego policy inside OPA of attestation service, which will help the user to handle such combination reference values by manually configure that. However it is not elegant enough and requires the policy composer have more knowledge. Could you provide a more concrete scenario that a compound reference value makes sense while the individual ingredients does not? Maybe we should take this into consideration? This requires some logic changes of the interface between CoCo-AS and RVPS. cc @jialez0 |
Yes; as you say, mixing reference value with appraisal policy is not ideal. Primarily because it blurs the distinction between the verifier owner and the reference value providers which, in general, are separate roles operated by separate entities. Therefore, only a minimal amount of coordination among them should be required - ideally, no coupling at all.
Individual ingredients always make sense :-) But for "expected state" recipes that require more than a single ingredient, you want to be able to specify the recipe too. So, except for the simplest of attesters that are identified by a singleton measurement, a compound reference value seems to be always needed. And once you have that, the singleton becomes just a special case of such (more powerful) primitive.
I don't know (yet) the interface between CoCo-AS and RVPS, but I appreciate that rethinking this will have non-trivial downstream consequences. However, for longer-term sustainability, it's better to get the building blocks right even though this might be somewhat painful :-) |
|
/cc |
Today I started reviewing the RVPS implementation and have a few observations that I wanted to share.
Semantic squashing
Whilst I get the ethos behind the choice of a uniform format for the ref-value type, I also think the assumption that ref-values are simple, stand-alone (id, hash) pairs hurts the usability of the service.
As a concrete example, Arm CCA workloads have ref-values with the following shape:
{ "initial-measurement": "48b2245b81dc07b9de288872ee8b68d3cde1a0d1a4ac47540d03a5ae3bcaaf4f", "extensible-measurements": [ "2459b963cbba21426c35d2d14696e1276937a43904c20f879ea843219cfa91fe", "de9dd6746a35d665e0ba9c4764c05fb732d6da82982fd1cb6e037884044c484d", "a8b7369d7e326138a2ef3f830196d43d43c3db922a5fc94da8aaeb93559e1a80", "6ae61d7f4603304adf786dca761990c70599848e27bc2b548f10abb23189e736" ], "personalization-value": "00fa9623e7d40d168e652e0f8b9d651112697adec1e7b227c738c22137611f0f58b5d5de4a6e624076b083395df9a41b7993abb4a9026f1174b56183e5a94650" }where:
initial-measurementmeasures the boot bitsextensible-measurementsis for the run-timepersonalisation-valuecontains user data supplied at launchI wouldn't know how to fit that compound structure into the current RVPS data model unless I either make drastically simplifying (and lossy) assumptions on what information I decide to cut off (with the consequent deterioration of the quality/fidelity of the verification process), or I cram the whole JSON above into the hash value ;-).
Both outcomes are highly undesirable.
An alternative approach is to maintain the simple key-value interface for the verifier, skip normalizing in the RVPS, and let the scheme-specific code in the verifier interpret the fetched ref-values.
Sharding of the store
From an initial (and admittedly superficial) code inspection, it is unclear if/how the sharding of the potentially multi-tenant and multi-scheme store is being addressed.
The keys are not explicitly namespaced and it looks like the extractors will just use what they've been supplied. Assuming that the keys will be globally unique is obviously unsafe.
Besides, I was unable to find any authn/authz associated with the supply-chain actor or at least a placeholder for that. What is the assumed threat model? One fundamental attribute of the ref-value provider is its trustworthiness, which needs to be somehow demonstrated to the verifier before the latter can act on its inputs.
Known bad values
It'd be nice to be able to provide negative ref-values alongside positive ones (i.e., deny- vs allow-lists). In general, this improves the quality of attestation results (e.g., see AR4SI).
The text was updated successfully, but these errors were encountered: