Trusted execution environments

This page defines the terms the rest of the documentation uses and names the mechanisms this product actually relies on. It explains the vendors' technology only as far as the router depends on it, and links to the vendors' own documentation for the rest, so you can check our claims against primary sources.

Definitions

Trusted execution environment (TEE). A part of a processor that runs code in isolation from everything else on the machine, in memory that is encrypted with keys held in the hardware. Code outside the environment, including the host operating system, the hypervisor and anyone with administrative access to the machine, cannot read that memory.

Confidential virtual machine. A whole virtual machine running inside such an environment, rather than a single process. Both platforms below work this way, which is why a deployment is measured as a VM image rather than as an application binary.

Launch measurement. A digest of the initial state of that VM: the firmware, the kernel and the configuration it was started with. The hardware computes it during launch and refuses to change it afterwards. Two VMs launched from the same artefacts produce the same measurement, which is what makes a measurement a usable identity for an image.

Attestation report, or quote. A statement signed by the processor that contains the launch measurement, the platform's security state, and a field the VM may fill with data of its own. On AMD this is called the attestation report; on Intel it is called a quote. The signature chains to the hardware vendor.

REPORT_DATA. The field the VM fills in. It is what binds a report to something outside it. In this product the VM puts the digest of a public key there, so the report attests not only "a genuine TEE ran this image" but "that TEE holds this key".

Remote attestation. Sending such a report to a party that did not produce it, who verifies the signature chain, rebuilds the expected measurement from published artefacts, compares the two, and decides.

What attestation proves

A report that verifies proves three things, and only these:

• the code ran on genuine hardware of the stated vendor, in a confidential VM;
• the VM was launched from an image whose measurement equals the value in the report;
• whatever the VM committed to in REPORT_DATA belongs to that VM.

What it does not prove

• That the code is correct, safe or does what its name suggests. A measurement identifies an image; it says nothing about the quality or intent of what is inside it. Deciding that an image is acceptable is a separate judgement, which is why this product carries a registry of signed measurements and why you pin a digest.
• That the hardware has no vulnerabilities. A report states the platform's security version numbers; it cannot vouch for the absence of flaws in the processor or its firmware.
• Anything about the GPU. See Deployment topology for what is and is not attested in the deployments this documentation describes.
• That a specific request was handled inside the environment. Attestation is about the environment, not about one message. Binding your connection to the attested environment is a separate step, and it is the one the evidence chain describes.
• Protection against traffic analysis. Sizes, timings and connection fingerprints are outside what any of this addresses.

The mechanisms this product uses

Both are verified offline, against vendor root certificates the verifier carries, using the certificates the evidence itself ships. Revocation lists are a separate, opt-in step: a list that cannot be fetched leaves revocation unknown, never clean.

On Azure confidential VMs the report belongs to Microsoft's paravisor rather than to the guest image directly, so the image is measured by the VM's virtual TPM instead. The hardware report commits to the paravisor's runtime data, Microsoft's certificate chain vouches for the vTPM key that data names, that key's quote over PCR 4 and PCR 9 is replayed from the firmware event log, and the runtime data commits to the public key being attested. The measurement is then SHA-256(vm-config flags ‖ PCR4′ ‖ PCR9′). Microsoft Azure Attestation is not consulted; the check stays offline.

The production router runs on a confidential VM of this kind. A verification against it today reports the evidence type as Intel TDX (Azure); the full report is on Read a verdict.

Primary sources

• Intel Trust Domain Extensions: developer overview
• Azure confidential computing: product documentation and attestation solutions
• AMD Secure Encrypted Virtualization: AMD's own tooling and documentation live in the AMDSEV repository; the normative description of the mechanism is AMD's white paper SEV-SNP: Strengthening VM Isolation with Integrity Protection and More
• The measurement registry and the VM build artefacts this product rebuilds measurements from: Super-Protocol/sp-vm

Next: Super Swarm, the cloud that runs these VMs and publishes what they are.