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.
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.
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:
Last updated