Add CCA Realm Reference Values #98

yogeshbdeshpande · 2023-12-12T10:57:04Z

CCA Realm Reference Value examples

Signed-off-by: Yogesh Deshpande <yogesh.deshpande@arm.com>

thomas-fossati · 2023-12-12T12:39:46Z

cocli/data/templates/comid-cca-realm-refval.json

+                            "type": "uuid",
+                            "value": "CD1F0E55-26F9-460D-B9D8-F7FDE171787C"


It'd be handy to have a stable identifier for a given workload, but that's not the case in CCA. I think we should use the RIM value to identify this (ephemeral) environment.

This is a stable identifier for the workload. We cannot request supply chain to ask for RIM to be the Identifier.
It is perfectly fine to tag a UUID for the Stable Identifier. This is more practical!

We cannot request supply chain to ask for RIM to be the Identifier.

why not?

It is perfectly fine to tag a UUID for the Stable Identifier. This is more practical!

How is it more practical to have to invent (and keep track of) an identifier that has no real linkage to the reference value data supplied?

Supply Chain is free to choose any real identifier they want for their Workload.
The Class ID is extensible!

This model proposes : UUID as a Workload Identifier.

This ID will be relayed in the EAR(Veraison Extension) when RIM and REM Matches to RP,

In case two Workloads Have Identical RIM's we can then use the UUID to mention both of them in EAR.

Supply Chain is free to choose any real identifier they want for their Workload.
The Class ID is extensible!

This model proposes : UUID as a Workload Identifier.

I appreciate that. My point is we are making things more complex than they need to be, without a good reason.

This ID will be relayed in the EAR(Veraison Extension) when RIM and REM Matches to RP,

not sure, what is RP?

In case two Workloads Have Identical RIM's we can then use the UUID to mention both of them in EAR.

I don't understand what "mention both of them in EAR" means.

RP Here refers to Relying Party!
Mention both of them in EAT Attestation Results!

Also there is no complexity in tagging UUID as a Workload Identity. It is just an example Identifier to uniquely identify a Workload!

Realm specs talks about GUID as one of the identifier for a Workload. Going by that logic: UUID makes perfect sense to me!

Also there is no complexity in tagging UUID as a Workload Identity. It is just an example Identifier to uniquely identify a Workload!

I argue there is extra complexity because now the roles need to coordinate among themselves to keep track of yet another identifier which has no concrete relationship whatsoever with the workload.

Realm specs talks about GUID as one of the identifier for a Workload.
Going by that logic: UUID makes perfect sense to me!

Can you point me to the document where it is suggested to identify a given workload class using GUIDs?

Also there is no complexity in tagging UUID as a Workload Identity. It is just an example Identifier to uniquely identify a Workload!

I argue there is extra complexity because now the roles need to coordinate among themselves to keep track of yet another identifier which has no concrete relationship whatsoever with the workload.

Can you please explain what are the Roles involved here: If I understand correctly, there is ONLY one Supply Chain Entity the Work load Creator here!

Realm specs talks about GUID as one of the identifier for a Workload.
Going by that logic: UUID makes perfect sense to me!

Can you point me to the document where it is suggested to identify a given workload class using GUIDs?

This ID will be relayed in the EAR(Veraison Extension) when RIM and REM Matches to RP,

If that kind of payload identification is needed (on top of what is already provided by the trustworthiness vector), the relying party is going to want an endorsed value that provides information about the SW run by the workload rather than an opaque identifier.

I argue there is extra complexity because now the roles need to coordinate among themselves to keep track of yet another identifier which has no concrete relationship whatsoever with the workload.

Can you please explain what are the Roles involved here: If I understand correctly, there is ONLY one Supply Chain Entity the Work load Creator here!

RP and RVP.

thomas-fossati · 2023-12-12T12:44:48Z

cocli/data/templates/comid-cca-realm-refval.json

+                "measurements": [
+                    {
+                        "value": {
+                            "digests": [
+                                "sha-384;QoS1aUymwNLPR4mguVrIAlyBjeUjBDZL580pgbLS7caFsyInfsJYGZYkE9jJssH1"
+                            ]
+                        }
+                    },
+                    {
+                        "value": {
+                            "digests": [
+                                "sha-384;IQe752H8pS2VE2oTVNt6TdV7Gya+DT2nHZ6yOYazS6YVq/ZRTPNeWp6lWgMtBop4"
+                            ]
+                        }
+                    },
+                    {
+                        "value": {
+                            "digests": [
+                                "sha-384;QQe752H8pS2VE2oTVNt6TdV7Gya+DT2nHZ6yOYazS6YVq/ZRTPNeWp6lWgMtBop4"
+                            ]
+                        }
+                    },
+                    {
+                        "value": {
+                            "digests": [
+                                "sha-384;JQe752H8pS2VE2oTVNt6TdV7Gya+DT2nHZ6yOYazS6YVq/ZRTPNeWp6lWgMtBop4"
+                            ]
+                        }
+                    },
+                    {
+                        "value": {
+                            "digests": [
+                                "sha-384;MQe752H8pS2VE2oTVNt6TdV7Gya+DT2nHZ6yOYazS6YVq/ZRTPNeWp6lWgMtBop4"
+                            ]


two observations:

CoRIM only allows one measurement-map in a reference-triple-record

these measurements are not named, so it's not clear what they refer to (I assume there is some sort of positional convention to distinguish RIM from REMs?)

Observation - 1: Correct: However we need to change that in the base CoRIM Schema.

All these Measurements belong to one Environment so really has to be in One Measurement Map

Yes, the positional convention is implicit, The first value will always be RIM Value and the subsequent will be REM's

We can add a comment in the Supply Chain Documentation that the first measurement always has to be RIM

Observation - 1: Correct: However we need to change that in the base CoRIM Schema.

That is not going to happen. There is too much resistance to that.

Observation - 1: Correct: However we need to change that in the base CoRIM Schema.

That is not going to happen. There is too much resistance to that.

I plan to re-initiate the discussion:

Observation - 1: Correct: However we need to change that in the base CoRIM Schema.

That is not going to happen. There is too much resistance to that.

I plan to re-initiate the discussion:

good luck :-) FWIW, I think there are very valid concerns for not reintroducing multiplicity there: the ramifications in terms of ref-val matching are deep.

thomas-fossati · 2023-12-12T12:57:43Z

cocli/data/templates/comid-cca-realm-refval.json

+            }
+        ]
+    }
+}


This looks very clumsy. I suggest we extend the CoRIM measurement map with CCA-specific claims instead:

[ { "environment": { "instance": { "id": { "type": "arm-cca.rim", "value": "1000000000000000000000000000000000000000000000000000000000000000" } } } }, { "measurement-map": { "mval": { "personalization": "5468652...", "RIM": "1000000000000000000000000000000000000000000000000000000000000000", "REM": [ "0000000000000000000000000000000000000000000000000000000000000001", "0000000000000000000000000000000000000000000000000000000000000010", "0000000000000000000000000000000000000000000000000000000000000100", "0000000000000000000000000000000000000000000000000000000000010000" ], "measurement-algo": "sha-256" } } } ]

RAK Hash Algorithm Identifier and Personalization Values will NOT come from Supply Chain!
They will not be provisioned.

Only provisioned will be a Workload Identity, RIM and REM.

Also effectively RIM and REM are Digests and using Digest to represent Reference Values is perfectly correct!

Also effectively RIM and REM are Digests and using Digest to represent Reference Values is perfectly correct!
Instead of minting custom map with no added gain!

RAK Hash Algorithm Identifier and Personalization Values will NOT come from Supply Chain!

why not? And if not, should we expect another actor to supply those values? If so, who?

I need to check again with our CCA experts before adding this as an Optional Parameter!

I am happy to do that, if I find that there is a possibility Hypervisor Gets the same from external sources:

I need to check again with our CCA experts before adding this as an Optional Parameter!

I am happy to do that, if I find that there is a possibility Hypervisor Gets the same from external sources:

$ lkvm run --realm \ --measurement-algo=["sha256", "sha512"] \ --disable-sve \ <normal-vm-options>

😄

the measurement-algo here may be the hash algorithm used for Calculating RIM and REM Measurements? Isn't it?

all realm measurmements (see §A7.2.3.1.5 of the realm spec.)

yes this measurement-algo is expected to be the one set by External Supply Chain.

It is different then RAK Hash Algo, which was referred earlier!

Add CCA Realm Reference Values

3436da0

Signed-off-by: Yogesh Deshpande <yogesh.deshpande@arm.com>

yogeshbdeshpande requested a review from thomas-fossati December 12, 2023 11:00

thomas-fossati reviewed Dec 12, 2023

View reviewed changes

yogeshbdeshpande closed this Feb 21, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add CCA Realm Reference Values #98

Add CCA Realm Reference Values #98

yogeshbdeshpande commented Dec 12, 2023

thomas-fossati Dec 12, 2023

yogeshbdeshpande Dec 12, 2023

thomas-fossati Dec 12, 2023

yogeshbdeshpande Dec 12, 2023

thomas-fossati Dec 12, 2023

yogeshbdeshpande Dec 12, 2023

thomas-fossati Dec 12, 2023

yogeshbdeshpande Dec 12, 2023

thomas-fossati Dec 12, 2023

thomas-fossati Dec 12, 2023

thomas-fossati Dec 12, 2023

yogeshbdeshpande Dec 12, 2023

thomas-fossati Dec 12, 2023

yogeshbdeshpande Dec 12, 2023

thomas-fossati Dec 12, 2023

thomas-fossati Dec 12, 2023 •

edited

Loading

yogeshbdeshpande Dec 12, 2023

yogeshbdeshpande Dec 12, 2023

yogeshbdeshpande Dec 12, 2023

thomas-fossati Dec 12, 2023

yogeshbdeshpande Dec 12, 2023 •

edited

Loading

thomas-fossati Dec 12, 2023

yogeshbdeshpande Dec 12, 2023

thomas-fossati Dec 12, 2023

yogeshbdeshpande Dec 12, 2023

		"type": "uuid",
		"value": "CD1F0E55-26F9-460D-B9D8-F7FDE171787C"

Add CCA Realm Reference Values #98

Add CCA Realm Reference Values #98

Conversation

yogeshbdeshpande commented Dec 12, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

thomas-fossati Dec 12, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

yogeshbdeshpande Dec 12, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

thomas-fossati Dec 12, 2023 •

edited

Loading

yogeshbdeshpande Dec 12, 2023 •

edited

Loading