Microsoft Azure Attestation
Microsoft Azure Attestation is a unified solution for remotely verifying the trustworthiness of a platform and integrity of the binaries running inside it. The service supports attestation of the platforms backed by Trusted Platform Modules (TPMs) alongside the ability to attest to the state of Trusted Execution Environments (TEEs) such as Intel® Software Guard Extensions (SGX) enclaves, Virtualization-based Security (VBS) enclaves, Trusted Platform Modules (TPMs), Trusted launch for Azure VMs and Azure confidential VMs.
Attestation is a process for demonstrating that software binaries were properly instantiated on a trusted platform. Remote relying parties can then gain confidence that only such intended software is running on trusted hardware. Azure Attestation is a unified customer-facing service and framework for attestation.
Azure Attestation enables cutting-edge security paradigms such as Azure Confidential computing and Intelligent Edge protection. Customers have been requesting the ability to independently verify the location of a machine, the posture of a virtual machine (VM) on that machine, and the environment within which enclaves are running on that VM. Azure Attestation empowers these and many additional customer requests.
Azure Attestation receives evidence from compute entities, turns them into a set of claims, validates them against configurable policies, and produces cryptographic proofs for claims-based applications (for example, relying parties and auditing authorities).
Azure Attestation supports both platform- and guest-attestation of AMD SEV-SNP based Confidential VMs (CVMs). Azure Attestation-based platform attestation happens automatically during critical boot path of CVMs, with no customer action needed. For more information on guest attestation, see Announcing general availability of guest attestation for confidential VMs.
Use cases
Azure Attestation provides comprehensive attestation services for multiple environments and distinctive use cases.
AMD SEV-SNP attestation on Confidential VMs
Azure Confidential VM (CVM) is based on AMD processors with SEV-SNP technology. CVM offers VM OS disk encryption option with platform-managed keys or customer-managed keys and binds the disk encryption keys to the virtual machine's TPM. When a CVM boots up, SNP report containing the guest VM firmware measurements will be sent to Azure Attestation. The service validates the measurements and issues an attestation token that is used to release keys from Managed-HSM or Azure Key Vault. These keys are used to decrypt the vTPM state of the guest VM, unlock the OS disk and start the CVM. The attestation and key release process is performed automatically on each CVM boot, and the process ensures the CVM boots up only upon successful attestation of the hardware.
AMD SEV-SNP attestation on Confidential Containers
Azure Confidential Containers is based on AMD processors with SEV-SNP technology. Confidential containers, hosted on Azure Container Instances and on Azure Kubernetes Service (in preview) offer the ability to run groups of containers in an SEV-SNP protected trusted execution environment which isolates that group of containers from the container management control plane and other running containers. Attestation in confidential containers involves fetching the AMD hardware attestation report directly from the processor. This can be accomplished with our SKR sidecar container or compiled directly into your application logic. The hardware report can then be exchanged with Azure Attestation and managed-HSM or Premium Azure Key Vault (AKV) to retrieve secrets. You can also provide the hardware report to your own key vault system as desired.
Trusted Launch attestation
Azure customers can prevent bootkit and rootkit infections by enabling trusted launch for their virtual machines (VMs). When the VM is Secure Boot and vTPM enabled with guest attestation extension installed, vTPM measurements get submitted to Azure Attestation periodically for monitoring boot integrity. An attestation failure indicates potential malware, which is surfaced to customers via Microsoft Defender for Cloud, through Alerts and Recommendations.
TPM attestation
Trusted Platform Modules (TPM) based attestation is critical to provide proof of a platform's state. A TPM acts as the root of trust and the security coprocessor to provide cryptographic validity to the measurements (evidence). Devices with a TPM can rely on attestation to prove that boot integrity isn't compromised and use the claims to detect feature state enablement during boot.
Client applications can be designed to take advantage of TPM attestation by delegating security-sensitive tasks to only take place after a platform has been validated to be secure. Such applications can then make use of Azure Attestation to routinely establish trust in the platform and its ability to access sensitive data.
SGX enclave attestation
Intel® Software Guard Extensions (SGX) refers to hardware-grade isolation, which is supported on certain Intel CPU models. SGX enables code to run in sanitized compartments known as SGX enclaves. Access and memory permissions are then managed by hardware to ensure a minimal attack surface with proper isolation.
Client applications can be designed to take advantage of SGX enclaves by delegating security-sensitive tasks to take place inside those enclaves. Such applications can then make use of Azure Attestation to routinely establish trust in the enclave and its ability to access sensitive data.
Intel® Xeon® Scalable processors only support ECDSA-based attestation solutions for remotely attesting SGX enclaves. Utilizing ECDSA based attestation model, Azure Attestation supports validation of Intel® Xeon® E3 processors and Intel® Xeon® Scalable processor-based server platforms.
Note
To perform attestation of Intel® Xeon® Scalable processor-based server platforms using Azure Attestation, users are expected to install Azure DCAP version 1.10.0 or higher.
Open Enclave attestation
Open Enclave (OE) is a collection of libraries targeted at creating a single unified enclaving abstraction for developers to build TEE-based applications. It offers a universal secure app model that minimizes platform specificities. Microsoft views it as an essential stepping-stone toward democratizing hardware-based enclave technologies such as SGX and increasing their uptake on Azure.
OE standardizes specific requirements for verification of an enclave evidence. This qualifies OE as a highly fitting attestation consumer of Azure Attestation.
Azure Attestation runs in a TEE
Azure Attestation is critical to Confidential Computing scenarios, as it performs the following actions:
- Verifies if the enclave evidence is valid.
- Evaluates the enclave evidence against a customer-defined policy.
- Manages and stores tenant-specific policies.
- Generates and signs a token that is used by relying parties to interact with the enclave.
To keep Microsoft operationally out of trusted computing base (TCB), critical operations of Azure Attestation like quote validation, token generation, policy evaluation and token signing are moved into an SGX enclave.
Why use Azure Attestation
Azure Attestation is the preferred choice for attesting TEEs as it offers the following benefits:
- Unified framework for attesting multiple environments such as TPMs, SGX enclaves and VBS enclaves.
- Allows creation of custom attestation providers and configuration of policies to restrict token generation.
- Protects its data while-in use with implementation in an SGX enclave or Confidential Virtual Machine based on AMD SEV-SNP.
- Highly available service
How to establish trust with Azure Attestation
- Verify if attestation token is generated by Azure Attestation - Attestation token generated by Azure Attestation is signed using a self-signed certificate. The signing certificates URL is exposed via an OpenID metadata endpoint. Relying party can retrieve the signing certificate and perform signature verification of the attestation token. See code samples for more information
- Verify if Azure Attestation is running inside an SGX enclave - The token signing certificates include SGX quote of the TEE inside which Azure Attestation runs. If relying party 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. See code samples for more information
- Validate binding of Azure Attestation SGX quote with the key that signed the attestation token – Relying party can verify if hash of the public key that signed the attestation token matches the report data field of the Azure Attestation SGX quote. See code samples for more information
- Validate if Azure Attestation code measurements match the Azure published values - The SGX quote embedded in attestation token signing certificates includes code measurements of Azure Attestation, like MRSIGNER. If relying party is interested to validate if the SGX quote belongs to Azure Attestation running inside Azure, MRSIGNER value can be retrieved from the SGX quote in attestation token signing certificate and compared with the value provided by Azure Attestation team. If you're interested to perform this validation, submit a request on Azure support page. Azure Attestation team will reach out to you when we plan to rotate the MRSIGNER.
Mrsigner of Azure Attestation is expected to change when code signing certificates are rotated. The Azure Attestation team follows the below rollout schedule for every mrsigner rotation:
i. Azure Attestation team notifies the upcoming MRSIGNER value with a two-month grace period for making relevant code changes
ii. After the two-month grace period, Azure Attestation starts using the new MRSIGNER value
iii. Three months post notification date, Azure Attestation stops using the old MRSIGNER value
Business Continuity and Disaster Recovery (BCDR) support
Business Continuity and Disaster Recovery (BCDR) for Azure Attestation enables you to mitigate service disruptions resulting from significant availability issues or disaster events in a region.
Clusters deployed in two regions operate independently under normal circumstances. In the case of a fault or outage of one region, the following takes place:
- Azure Attestation BCDR provides seamless failover in which customers don't need to take any extra step to recover.
- The Azure Traffic Manager for the region will detect that the health probe is degraded and switches the endpoint to paired region.
- Existing connections won't work and will receive internal server error or timeout issues.
- All control plane operations will be blocked. Customers won't be able to create attestation providers in the primary region.
- All data plane operations, including attest calls and policy configuration, will be served by secondary region. Customers can continue to work on data plane operations with the original URI corresponding to primary region.