Frequently asked questions for Microsoft Azure Attestation

Trusted Hardware Identity Management (THIM) fetches the Azure security baseline for the Azure Confidential computing (ACC) nodes from Intel and caches the data. Azure Attestation also uses the cached information 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.
• Periodically fetches the newer versions of Intel certificates, CRLs, Trusted Computing Base (TCB) information, and Quoting Enclave identity of the ACC nodes from Intel. The service 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.

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.

During SGX attestation process, Azure Attestation performs the following validations:

• Validates if the trusted root of signed enclave quote belongs to Intel
• Validates if the TEE quote meets Azure security baseline as defined by Trusted Hardware Identity Management (THIM)
• If customer created an attestation provider and configured a custom policy, in addition to the above validations, Azure Attestation evaluates the TEE quote against the attestation policy. Customers can use attestation policies to define authorization rules for the TEE and also dictate issuance rules for generating the attestation token.

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 thus generating a remotely attestable collateral.

The same process can be implemented for Azure Attestation. However to reap 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.

• After installing Azure Confidential computing virtual machine, install Azure DCAP library (Windows/ Linux) to reap 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.
• In 2018-09-01-preview API version, the client needs to send Microsoft Entra access token along with the evidence to SGX attest API endpoint. The Microsoft Entra access token is not a required parameter to perform SGX attestation in 2020-10-01 API version.

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. For more information, see code samples.

Validity time of the attestation token is 8 hours. There is currently no provision to customize the value.

Multiple certificates exposed in the OpenID metadata endpoint correspond to different use cases (for example, 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.

At the time of TEE evidence creation, code running inside the TEE can include arbitrary information in the evidence. For e.g. the TEE can create one or more asymmetric key pairs, serialize the public key components of these key pairs as JWKS JSON string and include the JWKS JSON string in the TEE evidence as RunTimeData { quote, JWKS JSON string }. Azure Attestation checks if SHA256 hash of the RuntimeData matches the lower 32 bytes of the quote's "report data" attribute. Post evaluating the TEE evidence, Azure Attestation generates JWT with the JWKS available as a claim named "keys" under the "x-ms-runtime" claim. The RunTimeData can be further used by relying party to establish secure channel and securely transmit data to the TEE.

Azure Attestation stores customer data at rest, during processing and replication for BCDR purposes within the geography the customer deploys the service instance in.