Attestation types and scenarios

Computing is an essential part of our daily lives. It powers everything from our smartphones to critical infrastructure. Increasingly strict regulatory environments, the prevalence of cyberattacks, and the growing sophistication of attackers make it difficult to trust the authenticity and integrity of the computing technologies that we depend on. Attestation is a technique to verify the software and hardware components of a system. It's a critical process for establishing and ensuring that the computing technologies we rely on are trustworthy.

In this article, we look at what attestation is, the types of attestation that Microsoft offers today, and how you can use these types of attestation scenarios in Microsoft solutions.

What is attestation?

In remote attestation, one peer (the attester) produces believable information about itself (the evidence) to enable a remote peer (the relying party) to decide whether to consider that attester as a trustworthy peer. Another vital party (the verifier) carries out the remote attestation procedures. In simple terms, attestation is a way of proving that a computer system is trustworthy.

To understand what attestation is and how it works in practice, this article compares the process of attestation in computing to real-life examples with passports and background checks.

The definition and models used in this article are outlined in the Internet Engineering Task Force (IETF) remote attestation procedures (RATs) architecture document. To learn more, see Internet Engineering Task Force: Remote attestation procedures (RATs) architecture.

Passport model

Two passport scenarios are presented in this section.

Passport model: Immigration desk

1. A citizen wants a passport to travel to a foreign country/region. The citizen submits evidence requirements to their host country/region.

2. The host country/region receives the evidence of policy compliance from the individual and verifies whether the supplied evidence proves that the individual complies with the policies for being issued a passport:

   • The birth certificate is valid and wasn't altered.
   • The issuer of the birth certificate is trusted.
   • The individual isn't part of a restricted list.

3. If the host country/region decides that the evidence meets their policies, the host country/region issues a passport for the citizen.

4. The citizen travels to a foreign nation, but first must present their passport to the foreign country/region's border patrol agent for evaluation.

5. The foreign country/region's border patrol agent checks a series of rules on the passport before trusting it:

   • The passport is authentic and wasn't altered.
   • A trusted country/region produced the passport.
   • The passport isn't expired or revoked.
   • The passport conforms to the policy of a visa or age requirement.

6. The foreign country/region's border patrol agent approves the passport and the citizen can enter the foreign country/region.

Passport model: Computing

1. A Trusted Execution Environment (TEE), which is also known as an attester, wants to retrieve secrets from a secrets manager, also known as a relying party. To retrieve secrets from the secrets manager, the TEE must prove to the secrets manager that it's trustworthy and genuine. The TEE submits its evidence to a verifier to prove that it's trustworthy and genuine. The evidence includes the hash of its executed code, the hash of its build environment, and its certificate generated by its manufacturer.

2. The verifier, which is an attestation service, evaluates whether the evidence given by the TEE meets the following requirements for being trusted:

   • The certificate is valid and wasn't altered.
   • The issuer of the certificate is trusted.
   • The TEE evidence isn't part of a restricted list.

3. If the verifier decides that the evidence meets the defined policies, the verifier creates an attestation result and gives it to the TEE.

4. The TEE wants to exchange secrets with the secrets manager. First it must present its attestation result to the secrets manager for evaluation.

5. The secrets manager checks a series of rules on the attestation result before trusting it:

   • The attestation result is authentic and wasn't altered.
   • A trusted authority produced the attestation result.
   • The attestation result isn't expired or revoked.
   • The attestation result conforms to configured administrator policy.

6. The secrets manager approves the attestation result and exchanges secrets with the TEE.

Background check model

Two background check scenarios are presented in this section.

Background check: School verification

1. A person is doing a background check with a potential employer to obtain a job. The person submits their education background from the school they attended to the potential employer.

2. The employer retrieves the education background from the person and forwards this information to the respective school to be verified.

3. The school evaluates whether the education background given by the person meets the school records.

4. The school issues an attestation result that verifies that the person's education background matches their records and sends it to the employer.

5. The employer, otherwise known as the relying party, might check a series of rules on the attestation result before trusting it:

   • The attestation result is authentic, wasn't altered, and comes from the school.
   • A trusted school produced the attestation result.

6. The employer approves the attestation result and hires the person.

Background check: Computing

1. A TEE, otherwise known as an attester, wants to retrieve secrets from a secrets manager, also known as a relying party. To retrieve secrets from the secrets manager, the TEE must prove that it's trustworthy and genuine. The TEE sends its evidence to the secrets manager to prove that it's trustworthy and genuine. The evidence includes the hash of its executed code, the hash of its build environment, and its certificate generated by its manufacturer.

2. The secrets manager retrieves the evidence from the TEE and forwards it to the verifier to be verified.

3. The verifier service evaluates whether the evidence given by the TEE meets defined policy requirements for being trusted:

   • The certificate is valid and wasn't altered.
   • The issuer of the certificate is trusted.
   • The TEE evidence isn't part of a restricted list.

4. The verifier creates an attestation result for the TEE and sends it to the secrets manager.

5. The secrets manager checks a series of rules on the attestation result before trusting it:

   • The attestation result is authentic and wasn't altered.
   • A trusted authority produced the attestation result.
   • The attestation result isn't expired or revoked.
   • The attestation result conforms to configured administrator policy.

6. The secrets manager approves the attestation result and exchanges secrets with the TEE.

Types of attestation

Attestation services are used in two distinct ways. Each method provides its own benefits.

Cloud provider

Azure Attestation is a customer-facing service and a framework for attesting TEEs like Intel Software Guard Extensions (SGX) enclaves, virtualization-based security (VBS) enclaves, Trusted Platform Modules, Trusted Launch, and confidential virtual machines (VMs). Benefits from using a cloud provider's attestation service, such as Azure Attestation, include:

• It's freely available.
• The source code is available for government customers via the Microsoft Code Center Premium Tool.
• It protects data while in use by operating within an Intel SGX enclave.
• It attests multiple TEEs in one single solution.
• It offers a strong service-level agreement.

Build your own

You can create your own attestation mechanisms to trust your computing infrastructure from tools provided by cloud and hardware providers. Building your own attestation processes for Microsoft solutions might require the use of Trusted Hardware Identity Management (THIM). This solution handles cache management of certificates for all TEEs that reside in Azure. It provides trusted computing base information to enforce a minimum baseline for attestation solutions. Benefits from building and using your own attestation service include:

• 100% control over the attestation processes to meet regulatory and compliance requirements.
• Customization of integrations with other computing technologies.

Attestation scenarios at Microsoft

You can choose between the cloud provider and build-your-own attestation services for many Microsoft attestation scenarios. The following sections introduce Azure offerings and the attestation scenarios that are available.

VMs with application enclaves

VMs with application enclaves are enabled by Intel SGX. Organizations can create enclaves that protect data and keep data encrypted while the CPU processes the data. You can attest Intel SGX enclaves in Azure with Azure Attestation and on your own. For more information, see:

• Intel SGX attestation home page
• Cloud provider: Intel SGX sample code attestation with Azure Attestation
• Build your own: Open enclave attestation

Confidential virtual machines

Confidential VMs are enabled by AMD SEV-SNP. Organizations can have hardware-based isolation between VMs and underlying host management code (including hypervisor). You can attest your managed confidential VMs in Azure with Azure Attestation and on your own. For more information, see:

• Confidential VMs attestation home page
• Cloud provider: What is guest attestation for confidential VMs?
• Build your own: Fetch and verify raw AMD SEV-SNP report on your own

Confidential containers on Azure Container Instances

Confidential containers on Azure Container Instances provide a set of features and capabilities to further secure your standard container workloads to achieve higher data security, data privacy, and runtime code integrity goals. Confidential containers run in a hardware-backed TEE that provides intrinsic capabilities like data integrity, data confidentiality, and code integrity. For more information, see:

• Cloud provider: Attestation in confidential containers on Azure Container Instances