Verification

This document describes the Credora Data Verification System (DVS), which has been set up to give proof to customers that data was generated (and signed) inside our Trusted Execution Environments (TEE).

Credora offers clients the possibility to run an entire verification flow that interacts with Credora units running in the production environment.

Before elaborating on the different stages of the verification process, this document details fundamentals of the verification algorithm and the related key management. Then, it provides a tutorial on how to run the verification process.

1 - Background on the Verification Algorithm and Key Management

The Cipher-based message authentication codes (or CMACs) algorithm is at the base of the Credora verification scheme. The CMAC algorithm is a symmetric-key cryptographic primitive used for message authentication. It is based on a block cipher, typically AES (Advanced Encryption Standard). CMAC provides integrity and authenticity of data, ensuring that a message has not been tampered with and comes from the claimed sender.

The core aspect of the Credora DVS is the key management. The key generation leverages material accessible only inside the TEE in order to ensure that the key cannot be generated elsewhere.

The figure below shows the key generation and the signature process. It can be observed that the key is obtained by combining the MR_Enclave, with other two random numbers generated inside the TEE.

Key Generation

It is important to notice that the signature process fails if a different enclave is used for the key generation since the MR_Enclave is part of the key generation process.

• Get the attestation report from Credora's Aggregators: In this phase the attestation report is received from the Credora Aggregator running in the PROD environment.

• Verify the attestation quote against the Credora Azure Attestation Service: The attestation infrastructure leverages the Microsoft Azure Attestation (MAA) service, which in turn uses the Intel ECDSA attestation mechanism. the attestation quote extracted from the report is then verified against the Credora AAS. Note: By default, the target is the Credora AAS that contains an attestation policy specified in the appendix. It can be tuned to connect to clients' owned AAS to use custom attestation policies. In case the attestation is accepted, the MR_ENCLAVE (aka, subkey_a) and the subkey_b are extracted from the attestation report.

• Get aggregated data from the database: The client is then able to connect to the Credora PROD database where aggregated data is available on a per-client basis. The client will download the last N entries that were pushed by the aggregator and extract the signatures and the related subkey_c.

• Verify the signed data: Once all the needed material is available to clients, the final verification can take place. This will happen inside an SGX verifier application which will reconstruct the signing key (similarly to what was done by the Aggregator) and compare the obtained signatures with the ones given in input by the client.

Overview of the Verification flow

3 - How to Run a Verification Procedure

As a first step, you need to access the Credora playground node via the Data Verification System feature. After you have requested and received access, the Data Verification System will appear in the user navigation.

You have restricted access in this node and can only execute a set of commands that allows to interact with Credora aggregator units, and verify that data was actually created in a Credora TEE.

3.1 - Obtain Aggregator Attestation Report

Command:1_get_ra_report

Description: This command creates a TEE-terminated TLS connection with Credora's Aggregator unit to get its Intel SGX RA report. The attestation report returned by the aggregator contains info on the enclave and brings inside the MR_Enclave and subkey_b, which are needed to verify the signed data. The subkey embedded in the attestation quote is fundamental to prove that the key is actually originating from a valid TEE.

Input(s): None

Output(s): ra.report file containing the attestation quote

3.2 - Validate the Attestation Report

Command:2_attest

Description: This command is used to attest the obtained RA report against the Microsoft Azure Attestation Service. In case of a positive attestation result, it extracts the MR_ENCLAVE and the subkey_b from the EnclaveHeldData field. Both are needed at a later stage to reconstruct the key for the signature verification process.

Input(s): ra.report file and address of the Azure RA infrastructure (default: Credora Azure RA Infrastructure)

Output(s): mr.enclave and sub.key files

3.3 - Get Aggregated Data

Command:3_get_scores

Description: This command is used to obtain data from the Credora database where aggregators push their output. The aggregated data contains the related signature and the subkey_c.

Input(s): None

Output(s): scores.data file

3.4 - Verify Aggregated Data

Command:4_verify

Description: this command verifies the that the signature obtained in the previous steps is equal to the one that we generate by passing the aggregated data and the different subkeys

Input(s): score.data, mr.enclave, and sub.key

Output(s): result

Appendix - Azure Attestation Policy

The Azure attestation policy used by default for the attestation is reported below:

version=1.1;
authorizationrules{
    [ type=="x-ms-sgx-is-debuggable", value==false] &&
    [ type=="x-ms-sgx-mrenclave", value=="mrenclave"] => permit(); 
    [ type=="x-ms-sgx-is-debuggable", value==false] &&
    [ type=="x-ms-sgx-mrenclave", value=="mrenclave"] => permit();
};

	
issuancerules{
    c:[type=="nonce", issuer=="CustomClaim"] => add(type="p-nonce", value=c.value);
    ![type=="p-nonce", issuer=="AttestationPolicy"] => add(type="p-nonce", value=0);
    c:[type=="x-ms-sgx-mrsigner"] => issue(type="mrsigner", value=c.value);
    c:[type=="x-ms-sgx-mrenclave"] => issue(type="mrenclave", value=c.value);
    c:[type=="x-ms-sgx-product-id"] => issue(type="prod-id", value=c.value);
    c:[type=="p-nonce"] => issue(type="p-nonce", value=c.value);
    => issue(type="p-attested", value=true);
};