Proof of Cloud: Data Center Execution Assurance for Confidential VMs

TL;DR

This paper addresses the gap in remote attestation that reveals code identity but not the physical hosting location of confidential workloads. It introduces Data Center Execution Assurance (DCEA), a design that binds a Confidential VM (CVM) to its physical platform via a dual-root-of-trust architecture combining vTPM-based measurements and provider-owned attestations. The approach supports both provider-managed softwar e stacks (Scenario I) and bare-metal deployments (Scenario II), with a four-step protocol (measured launch, key provisioning, in-guest evidence binding, and verifier workflow) that yields verifiable composite evidence resistant to replay, proxying, and other attacks, including the “Frankenstein proxy” variant. A concrete implementation and attack mitigations are discussed, including performance considerations on Intel TDX/vTPM-enabled platforms, and the work outlines practical paths for deploying high-assurance, confidential workloads in minimally trusted cloud environments. Overall, DCEA provides a concrete, deployable path to prove Cloud provenance, enabling secure, location-aware confidential computing at scale.

Abstract

Confidential Virtual Machines (CVMs) protect data in use by running workloads inside hardware-isolated environments. In doing so, they also inherit the limitations of the underlying hardware. Trusted Execution Environments (TEEs), which enforce this isolation, explicitly exclude adversaries with physical access from their threat model. Commercial TEEs, e.g., Intel TDX, thus assume infrastructure providers do not physically exploit hardware and serve as safeguards instead. This creates a tension: tenants must trust provider integrity at the hardware layer, yet existing remote attestation offers no way to verify that CVMs actually run on physically trusted platforms, leaving today's CVM deployments unable to demonstrate that their guarantees align with the TEE vendor's threat model. We bridge this confidence gap with Data Center Execution Assurance (DCEA), a design generating "Proofs of Cloud". DCEA binds a CVM to its underlying platform using vTPM-anchored measurements, ensuring CVM launch evidence and TPM quotes refer to the same physical chassis. This takes advantage of the fact that data centers are often identifiable via TPMs. Our approach applies to CVMs accessing vTPMs and running on top of software stacks fully controlled by the cloud provider, as well as single-tenant bare-metal deployments with discrete TPMs. We trust providers for integrity (certificate issuance), but not for the confidentiality of CVM-visible state. DCEA enables remote verification of a CVM's platform origin and integrity, mitigating attacks like replay and attestation proxying. We include a candidate implementation on Google Cloud and Intel TDX that leverages Intel TXT for trusted launch. Our design refines CVMs' threat model and provides a practical path for deploying high-assurance, confidential workloads in minimally trusted environments.

Figures (9)

• Figure 1: Overview of the host stack using and Intel . Intel extends values to the hypervisor. Later, we bind the to the host OS and seal the to the . The attestation values overlap with values Futral201310.1145/3652597. The stack does not cover all fields.
• Figure 2: Overview of the stack of with individual information covered by respective values. Intel extends the values to the hypervisor and beyond Futral2013.
• Figure 3: Simplified TEE attestation flow for various deployments. The provider controls the grey dotted boxes. For Bare/CVM flow, we have in the trusted area (green) all relevant components running in the . In the case of Paravisor, certain components of Paravisor and its firmware are not trusted (orange) as they might not always be open-source.
• Figure 4: Overview of parties in the threat model. Each party's color is used in subsequent figures as a line color. Depending on the scenarios, it is possible that some parties overlap in their roles.
• Figure 5: Overview of Scenario I (S1) and II (S2) introducing components within and outside of it, differentiated by the color code. Green corresponds to a trusted component and orange to an untrusted component. We assume for S1 the components below as spatially trusted, as in many cases, the details and possible verification of the used source code are not possible. This differs for S2, where the components can be made deterministically open-source. The line bound matches the colors for individual parties as per \ref{['fig:setting-threat-model']}.