This article provides answers to some of the most common questions about Azure Attestation.
If your Azure issue is not addressed in this article, you can also submit an Azure support request on the Azure support page.
What is Trusted Hardware Identity Management (THIM) and its role in enclave attestation
Trusted Hardware Identity Management (THIM) defines the Azure security baseline for the Azure Confidential computing (ACC) nodes from Intel and caches the data. The cached information will be further used by Azure Attestation in validating Trusted Execution Environments (TEEs).
THIM is recommended for the following reasons:
- Offers high availability
- Reduces dependencies on externally hosted services and internet connectivity.
- Fetches the latest versions of Intel certificates, CRLs, Trusted Computing Base (TCB) information and Quoting Enclave identity of the ACC nodes from Intel. The service hence confirms the Azure security baseline to be referred by Azure Attestation while validating the TEEs, greatly reducing attestation failures due to invalidation or revocation of Intel certificates
Is SGX attestation supported by Azure Attestation in non-Azure environments
No. Azure Attestation depends on the security baseline stated by Trusted Hardware Identity Management (THIM) to validate the TEEs. THIM is currently designed to support only Azure Confidential computing nodes.
What validations does Azure Attestation perform for attesting SGX enclaves
Azure Attestation is a unified framework for remotely attesting different types of TEEs. Azure Attestation:
- Validates if the trusted root of a signed enclave quote belongs to Intel.
- Validates if the enclave quote meets the Azure security baseline as defined by Trusted Hardware Identity Management (THIM).
- Validates if the SHA256 hash of Enclave Held Data (EHD) in the attestation request object matches the first 32 bytes of reportData field in the enclave quote.
- Allows customers to create an attestation provider and configure a custom policy. In addition to the above validations, Azure Attestation evaluates the enclave quote against the policy. Policies define authorization rules for the enclave and also dictate issuance rules for generating the attestation token. To confirm if intended software is running in an enclave, customers can add authorization rules to verify if mrsigner and mrenclave fields in the enclave quote matches the values of customer binaries.
How can a verifier obtain the collateral for SGX attestation supported by Azure Attestation
In general, for the attestation models with Intel as the root of trust, attestation client talks to enclave APIs to fetch the enclave evidence. Enclave APIs internally call Intel PCK caching service to fetch Intel certificates of the node to be attested. The certificates are used to sign the enclave evidence thereby generating a remotely attestable collateral.
The same process can be implemented for Azure Attestation. However to leverage the benefits offered by Trusted Hardware Identity Management (THIM), after installing ACC virtual machine, it is recommended to install Azure DCAP library. Based on the agreement with Intel, when Azure DCAP library is installed, the requests for generating enclave evidence are redirected from Intel PCK caching service to THIM. Azure DCAP library is supported in Windows and Linux-based environments.
How to shift to Azure Attestation from other attestation models
- After installing Azure Confidential computing virtual machine, install Azure DCAP library (Windows/ Linux) to leverage the benefits offered by Trusted Hardware Identity Management (THIM).
- Remote attestation client needs to be authored which can retrieve the enclave evidence and send requests to Azure Attestation. See code samples for reference
- Attestation requests can be sent to the REST API endpoint of default providers or custom attestation providers
- Azure Attestation APIs are protected by Azure AD authentication. Hence the client that invokes attest APIs must be able to obtain and pass a valid Azure AD access token in the attestation request
How can the relying party verify the integrity of attestation token and confirm that Azure Attestation is running inside an enclave
Attestation token generated by Azure Attestation is signed using a self-signed certificate. The signing certificates are exposed via an OpenID metadata endpoint. Relying party can retrieve the signing certificates from this endpoint and perform signature verification of the attestation token. The signing certificate also includes SGX quote of the TEE inside which Azure Attestation runs. If relying party also prefers to check if Azure Attestation is running inside a valid SGX enclave, the SGX quote can be retrieved from the signing certificate and locally validated.
How long is an attestation token valid?
Validity time of the attestation token is 8 hours. There is currently no provision to customize the value.
How to identify the certificate to be used for signature verification from the OpenID metadata endpoint
Multiple certificates exposed in the OpenID metadata endpoint correspond to different use cases (e.g. SGX attestation) supported by Azure Attestation. As per the standards specified by RFC 7515, the certificate with key ID (kid) matching the kid parameter in the attestation token header is to be used for signature verification. If no matching kid is found, then it is expected to try all the certificates exposed by OpenID metadata endpoint.
Is it possible for the relying party to share secrets with the validated Trusted Execution Environments (TEEs)
Public key generated within an enclave can be expressed in the Enclave Held Data (EHD) property of the attestation request object sent by the client to Azure Attestation. After confirming if SHA256 hash of EHD is expressed in reportData field of the quote, Azure Attestation includes EHD in the attestation token. Relying party can use the EHD from the verified attestation response to encrypt the secrets and share with the enclave. See Azure Attestation basic concepts for more information.
Where does Azure Attestation store customer data?
Azure Attestation stores customer data at rest, during processing and replication for BCDR purposes within the geography the customer deploys the service instance in.