Attestation Service
A TEE Attestation Service is an essential component in the security architecture of trusted computing environments. It plays a critical role in verifying the integrity and authenticity of TEEs.
The Credora infrastructure ensures that every enclave must be attested before managing confidential data.
The Credora Attestation Service leverages the Microsoft Azure Attestation (MAA) infrastructure, which in turn uses the Intel ECDSA attestation mechanism. The MAA service receives Attestation Quotes of Credora TEEs and validates them based on pre-defined policies.
An attestation quote is a digitally signed piece of data that serves as proof of the state of a TEE. It typically includes information about the hardware, software, and data within the secure environment, as well as a timestamp and a digital signature.
Credora can also provide the Attestation Quotes to clients interested in validating them.
The attestation quotes prove that:
Credora applications are running in SGX enclaves
Enclaves are not compiled with Debug symbols
Enclaves are running on up to date firmware with no vulnerabilities
A particular version of Gramine-SGX runtime and of a Gramine manifest are used
Upon request, we can provide access to a Credora playground node via a web-based terminal available at https://privaton-sandbox.credora.io/<client username> .
Once inside, the client can send a request to our PROD TEE-secured units to get the attestation quote.
The obtained result goes through the "quote validator" provided by Azure, responsible for:
Calling the Azure Attestation service for validation, passing it the remote quote and enclave held data found in the quote file
Validating that the Azure Attestation JWT passes signature validation and is issued by the expected party
Validating that the Azure Attestation JWT claim values match the parsed data in the JSON file for the well known fields like Security Version Number, ProductID, MRSIGNER, MRENCLAVE, IsDebug
Producing a report in the console with the results
The most relevant fields in the attestation result are:
Attestation provider - Indicating that the attestation is verified by Azure, meaning that the node could only run in an Azure cluster.
MRENCLAVE & MRSIGNER - Confirming that the hash of the enclave and of Gramine-SGX are correct, and that the Credora enclave signing key has been used.
One of the main goals of attestation is to demonstrate to clients that the binary running in the enclave is the binary that is supposed to run. Attestation policies provide two mechanisms for this purpose. One is the mrenclave claim which is the hash of the binary that is supposed to run in an enclave. With the mrenclave the binary hash changes even with trivial changes to the code. While the mrsigner is a hash of a key that is used to sign the enclave binary. In this way, the client can track the status of the KMS code and key.
IsDebuggable - To prove that the Credora enclaves have debug disabled.
Enclaves can be loaded with debugging disabled or enabled. Debugging support is designed to allow developers to troubleshoot the code running in an enclave. In a production system, debugging could enable an administrator to examine the content of the enclave, which would reduce the level of protection the enclave provides. The recommended policy disables debugging to ensure that if a malicious admin tries to turn on debugging support by taking over the enclave machine, attestation will fail.
Enclave Held Data - To prove that the enclave held data is verified.
Data critical for the security of the application (e.g., a deployment configuration hash) is taken into account in the RA procedure as a hashed (SHA256) enclave held data.
ProductID - The ProductID of the enclave matches the product ID assigned to the Credora enclaves
Each enclave has a unique product ID that differentiates the enclave from other enclaves. The product ID assigned to the Key Management System (KMS) enclave is 306.
Security Version - The security version number (SVN) of the library is greater than 0.
In case a security issue is discovered and fixed, Credora will deploy a new version of the enclave with a new (incremented) SVN. We will announce upgrades of the SVN. By updating the policy to match the recommended policy we can ensure that if a malicious administrator tries to load an older and insecure enclave, attestation will fail.
Last updated