Duplicate
Details
Details
Assignee
Thomas Fossati
Thomas FossatiReporter
Thomas Fossati
Thomas FossatiPriority
UndecidedEpic Name
Rust Library
Checklist
Checklist
Sentry
Sentry
Created September 27, 2023 at 11:39 AM
Updated October 25, 2023 at 5:52 AM
Resolved October 25, 2023 at 5:52 AM
Context and high-level requirements
As part of the RME/CCA enablement in the https://github.com/confidential-containers project, we need to build a library that can parse and verify evidence coming from a CCA attester.
The library’s immediate use is to extend the https://github.com/confidential-containers/attestation-service, which is a Rust-only codebase, therefore the library will be developed in Rust. CoCo is not the only use case though, so it makes sense to build this piece of functionality as a stand-alone, reusable block.
The evidence format, a composite https://datatracker.ietf.org/doc/draft-ietf-rats-eat/ token, is detailed in Section A7 of the Realm Management Monitor (RMM) Specification.
The library will be hosted as a standalone repo under the https://github.com/veraison organisation.
API
The API is A “CCA token” class with three public methods:
Parse a CBOR-encoded buffer received from the attester (or relying party) into a new CCA token object
Verify a CCA token, including:
cryptographically (both signatures and Platform-Realm binding), using pCPAK retrieved from the supplied endorsement store, and
against the “golden” values supplied in the ref-value store.
Serialise the claims-sets (both Platform and Realm) into a JSON object.
The latter is for needed for including in EAR as well as for compatibility with OPA, in case the claims-set needs to be further processed by an OPA policy downstream.
Note: It is assumed that the Endorsement and RefValue stores are populated from a trusted source.
The result of the verification is an AR4SI (https://datatracker.ietf.org/doc/draft-ietf-rats-ar4si ) code-point, which can be used by the caller to construct an https://datatracker.ietf.org/doc/draft-fv-rats-ear/ token.
pub struct CcaToken { // Platform part // Realm part } pub enum AR4SI { // AR4SI codepoints } pub struct EndorsementStore { // associative array mapping: // InstIDs into pCPAKs } pub struct RefValueStore { // associative array mapping: // Platform::ImplIDs into Platform::ref-values // Realm::IDs(?) into Realm::ref-values } impl CcaToken { pub fn from_bytes(bytes: Vec<u8>) -> Result<CcaToken, Error> { /* ... */ } pub fn verify(&self, nonce: Vec<u8>, EndorsementStore: es, RefValueStore: rvs) -> Result<AR4SI, Error> { /* ... */ } pub fn to_json(&self) -> Result<String> }The user must be able to access the
ccc-realm-challengeclaim in the Realm token to allow freshness checks independently of verification.Endorsements and Ref-Value Stores schema
{ "ref-values": [ { "platform": { "implementation-id": "/BASE64+ENCODED+VAL/", "instance-id": "/BASE64+ENCODED+VAL/", "config": "/BASE64+ENCODED+VAL/", "sw-components": [ { "component-type": "[OPTIONAL] e.g., BL", "measurement-value": "/BASE64+ENCODED+VAL/", "signer-id": "/BASE64+ENCODED+VAL/", "version": "[OPTIONAL] e.g., 1.0.2rc5" }, { /* as many entries as needed */} ] }, "realm": { "personalization-value": "/BASE64+ENCODED/", "initial-measurement": "/BASE64+ENCODED+VAL/", "extensible-measurements": [ "/BASE64+ENCODED+VAL/", "/BASE64+ENCODED+VAL/", "/BASE64+ENCODED+VAL/", "/BASE64+ENCODED+VAL/" ] } }, { / as many entries as needed */} ], "verification-keys": [ { "implementation-id": "/BASE64+ENCODED+VAL/", "instance-id": "/BASE64+ENCODED+VAL/", "cpak-pub": "/BASE64+ENCODED+VAL/" }, { / as many entries as needed */ } ] }Verification algorithm
Since the RMM spec does not detail the verification algorithm, I am giving an outline in the following.
Platform Evidence Verification
The procedure to verify CCA Platform Evidence is as follows:
Extract CCA platform implementation identifier ImplID from the Platform claims-set (note that the use of a not-yet-authenticated claim is not a problem in this case);
Extract CCA platform instance identifier InstID from the Platform claims-set;
Use the CCA platform implementation identifier ImplID and instance identifier InstID to look up the associated CPAK public key, pCPAK
Use the found CPAK public key pCPAK to verify the signature over the Platform claims-set;
Extract the lifecycle state claim LifeCycleState and check its value is “secured” (0x30);
Use the CCA platform implementation identifier ImplID to look up the relevant Reference Values for the boot state;
Extract the platform boot state (SwComponents) from the Platform claims-set and check the reported values match the corresponding Reference Values
Extract the platform configuration Config from the Platform claims-set and check its value matches the corresponding Reference Value
The Platform Verifier is also responsible for checking the correctness of the binding between Realm and Platform Evidence.
The procedure to verify the binding is as follows:
Extract the RAK public key pRAK from the Realm claims-set;
Extract the nonce claim from the Platform claims-set;
Hash the RAK public key and ensure it matches the nonce claim value from step 2;
Use the RAK public key pRAK to verify the COSE Sign1 signature over the Realm claims-set.
If any of the steps above -- platform verification and binding check -- fail, the Platform Evidence is not verified, and the system must not be considered trustworthy.
Otherwise, the Platform Evidence is verified, and the Verifier can trust the system to implement the CCA security guarantee, in particular for the Realm it is interacting with. The Verifier can then continue with a further appraisal of the Realm Evidence.
Realm Evidence Verification
To fully verify the Realm Evidence, the organization that develops the Realm application needs to convey, over a mutually authenticated channel, the following information to the Realm Verifier:
Reference Value(s) for the Realm boot state, in particular, the RIM;
(Optionally) Reference Values for the REMs.
The procedure to verify Realm Evidence is as follows:
Extract the RAK public key pRAK from the Realm claims-set;
Use the RAK public key pRAK to verify the COSE Sign1 signature over the Realm claims-set;
Check freshness (received challenge (nonce) == sent challenge);
Extract the Realm initial measurements RIM from the Realm claims-set and check its value matches the corresponding Reference Value;
Optionally, based on policy, extract the Realm extended measurements REM from the Realm claims-set and check their value match the corresponding Reference Value(s)
Optionally, based on policy, extract the Realm personalization value RPV from the Realm claims-set and check its value matches the corresponding Reference Value
Note that steps 1-2 are also part of the binding checks made by the Platform Verifier and can be avoided here if the Realm and Platform Verifiers cooperate.
In some circumstances, the guest OS deployed within a Realm may be sourced from a different organization than the Realm application and this must be considered when sourcing the appropriate Reference Values.