Frequently asked questions for Microsoft Azure Attestation

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 Azure PCK caching service and its role in enclave attestation

Azure PCK caching service 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).

Azure PCK caching service:

  • 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 Azure PCK caching service to validate the TEEs. Azure PCK caching service 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 Azure PCK caching service.
  • 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 Azure PCK caching service, 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 Azure PCK caching service. 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 Azure PCK caching service.
  • 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

Attestation token generated by Azure Attestation is signed using a self-signed certificate. The 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. Validity time of the attestation token is 8 hours.

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.