Proof of Cloud: Data Center Execution Assurance for Confidential VMs

This paper introduces Data Center Execution Assurance (DCEA), a cryptographic framework that binds Confidential VM attestations to platform-level TPM evidence to provide verifiable proof that workloads are executing within a trusted data center, thereby preventing proxy and relay attacks that existing mechanisms cannot detect.

The Gist

Imagine you hire a high-security vault to store your most valuable secrets. You want to be 100% sure that:

1. The vault is made of the right materials (it's a real, secure vault).
2. The vault is actually sitting in the bank you hired, not in a guy's garage down the street.

The Problem: The "Fake Garage" Scam
Currently, if you ask a cloud provider (like Google or AWS), "Is my data safe?" they show you a digital ID card. This card says, "Yes, this is a real Intel TDX vault, and the software inside is clean."

But here's the catch: The ID card doesn't say where the vault is.

A clever (and malicious) cloud operator could take that valid ID card, walk over to their own unsecured server room (or even a hacked machine in their basement), and run your "secure" workload there. They could then show you the ID card and say, "See? It's secure!"

In reality, your data is sitting on hardware they control completely, where they could potentially steal your keys or spy on you using physical tricks (like plugging a wire into the memory chip). The current technology proves what is running, but not where it is running.

The Solution: "Proof of Cloud" (DCEA)
The authors of this paper propose a new system called Data Center Execution Assurance (DCEA). Think of it as a double-lock system that ties the vault to the specific building it's in.

Here is how it works, using a simple analogy:

The Analogy: The "Sealed Box" and the "Building Manager"

Imagine you have a Smart Box (your Confidential VM) that contains your secrets.

• The Smart Box has a built-in sensor that checks its own internal software. It says, "I am running the correct code."
• The Building Manager (the Cloud Provider's hardware) has a Security Logbook (the TPM/Trusted Platform Module). This logbook records exactly what software is running on the floor where the box is sitting.

The Old Way:
You ask the Smart Box, "Are you safe?"
The Box says, "Yes, I am!" (It shows you its internal sensor reading).
Result: You don't know if the Box is in the Bank or in the Manager's garage.

The New Way (DCEA):
The system forces the Smart Box and the Building Manager to shake hands and sign a joint document.

1. The Handshake: The Smart Box asks the Building Manager, "What does your Security Logbook say about the floor I'm on?"

2. The Cross-Check: The Smart Box looks at its own internal sensor readings and compares them to the Manager's Logbook.

   • Do they match? If the Box says "I'm running Code A" and the Logbook says "Floor 1 is running Code A," then Great! They are in sync.
   • Do they mismatch? If the Box says "I'm running Code A" but the Logbook says "Floor 1 is running Code B" (or if the Manager is trying to fake the Logbook), the system screams ALARM.

3. The "Seal": The most important part is that the Building Manager's Logbook is sealed to the physical building. You can't just copy the Logbook from the Bank and paste it onto the Manager's garage door. The Logbook is physically tied to the specific server rack in the data center.

Why is this a big deal?

1. It stops the "Mix-and-Match" Scam
Previously, a bad actor could take a valid ID from a real data center and a valid ID from a secure server, and glue them together to trick you. DCEA breaks the glue. It proves that the software and the physical hardware are in the same place at the same time.

2. It works even if the Manager is a Liar
The system assumes the Cloud Provider's software (the "Manager") might be evil and trying to trick you. But because the system relies on hardware roots of trust (physical chips that can't be hacked by software), the Manager can't fake the evidence. If they try to lie, the math doesn't add up, and the verifier (you) knows immediately.

3. It's like a "Notary Public" for the Cloud
Think of DCEA as a digital notary. It doesn't just check your ID; it checks your ID and the GPS coordinates of the building you are standing in, and it stamps a document saying, "This person is definitely in this building."

The Bottom Line

This paper introduces a way to prove that your private data is running in a trusted data center, not on a random computer controlled by a hacker or a rogue employee.

It combines two sources of truth:

1. The Chip's Truth: "I am a secure processor."
2. The Building's Truth: "I am a secure data center."

By binding them together, you get "Proof of Cloud." You can finally sleep at night knowing your secrets aren't just "secure," they are also "secure here," and nowhere else.

Technical Summary

Here is a detailed technical summary of the paper "Proof of Cloud: Data Center Execution Assurance for Confidential VMs".

1. Problem Statement

Confidential Virtual Machines (CVMs) utilize Trusted Execution Environments (TEEs) like Intel TDX and AMD SEV-SNP to protect data in use. However, current TEE attestation mechanisms suffer from a critical blind spot: they certify what code is running, but not where it is running.

• The Gap: Standard attestations verify the CPU model, microcode, and software state but provide no cryptographic evidence that the workload is executing within a specific, trusted physical data center.
• The Threat: A malicious operator (or a compromised cloud provider) can take a valid attestation from a trusted machine and "proxy" or "relay" it to a different machine under their physical control. This enables Mix-and-Match Proxy Attacks, where an attacker combines a legitimate TEE report from one machine with a different physical chassis to falsely claim trusted execution.
• Consequence: External verifiers (e.g., DeFi users, banks, genomics firms) cannot cryptographically confirm that their sensitive data is being processed in a secure, physically isolated environment, leaving them vulnerable to active hardware tampering (e.g., bus interposition, side-channel attacks) that TEEs explicitly exclude from their threat models.

2. Methodology: Data Center Execution Assurance (DCEA)

The authors propose DCEA, a protocol that generates a "Proof of Cloud" by cryptographically binding the CVM's runtime state to the physical infrastructure's boot state.

Core Mechanism

DCEA combines two independent Roots of Trust (RoT):

1. TEE Manufacturer RoT: The standard TEE attestation (e.g., Intel TDX Quote) which verifies the guest OS and runtime integrity.
2. Infrastructure Provider RoT: A Trusted Platform Module (TPM) or virtual TPM (vTPM) quote that verifies the host platform's boot state (firmware, hypervisor, OS).

The Binding Process

The protocol creates a cryptographic link between the CVM and the physical chassis:

• Measured Launch: The host platform uses Dynamic Root of Trust for Measurement (DRTM), such as Intel TXT, to measure the boot sequence (firmware, hypervisor, vTPM) and extend these values into Platform Configuration Registers (PCRs) in the physical TPM.
• Key Sealing: The vTPM's Attestation Key (AK) is sealed to these specific PCR values. This means the AK can only be used to sign quotes if the host software stack matches the measured state exactly.
• In-Guest Verification: The CVM (Trust Domain) requests a quote from the vTPM. It then compares the vTPM's PCR measurements against its own runtime measurements (RTMRs).
• Cross-Linking: The CVM embeds the hash of the vTPM's public key into its own attestation report. The verifier checks that:
  1. The TEE report and vTPM quote share consistent measurements.
  2. The vTPM quote is signed by a key sealed to the specific physical platform's boot state.
  3. The physical TPM's Endorsement Key (EK) certificate chain originates from the trusted cloud provider.

Deployment Scenarios

• Scenario I (Managed CVM): The cloud provider manages the host OS and vTPM. The binding relies on the provider's operational integrity and the consistency of the vTPM quote with the TEE report.
• Scenario II (Bare-Metal): The tenant controls the host OS/hypervisor on a bare-metal server with a discrete TPM (dTPM). This offers stronger guarantees as the entire stack is measured and sealed, preventing even a malicious host operator from altering the boot state without detection.

3. Key Contributions

1. Formalization of Environment Provenance: The paper identifies and formalizes "environment provenance" as a first-class security objective, highlighting the lack of physical location binding in current TEE threat models.
2. DCEA Protocol Design: A novel protocol that links TEE runtime measurements with platform-level TPM evidence, anchoring workloads to a specific physical chassis.
3. Formal Security Proof: Using the Universal Composability (UC) framework and the AGATE model, the authors prove that DCEA emulates an ideal "location-aware TEE." This proves resilience against advanced proxy attacks, even when the host software stack is fully adversarial.
4. Implementation & Evaluation: A working prototype on Google Cloud Platform (GCP) using Intel TDX and Intel TXT. The evaluation demonstrates that DCEA mitigates a broad range of attacks (A1–A6) with minimal performance overhead.

4. Results and Security Analysis

The authors identified six specific attack vectors and demonstrated how DCEA mitigates them:

Attack Vector	Description	DCEA Mitigation
A1: Relay/Proxy	Attacker relays quotes from a trusted machine to a malicious one.	Hardware Binding: The vTPM AK is sealed to the local host's PCR state. A proxy machine cannot use the remote machine's key because its local PCRs do not match the seal policy.
A2: Quote Forgery	Forging vTPM quotes or PCR values.	Sealing: The AK cannot sign unless the host state matches the sealed policy.
A3: Inconsistency	Mismatch between TEE RTMRs and vTPM PCRs.	Cross-Check: The CVM verifies that its internal runtime measurements match the vTPM's boot measurements.
A4: Channel Interception	MITM attacks on communication between CVM and vTPM.	End-to-End Integrity: Hardware-bound signatures prevent tampering with the quote content.
A5: Identity Substitution	Reusing valid EK certificates from different hardware.	Unique Binding: The TEE report includes the hash of the specific vTPM AK, linking the identity to the specific execution environment.
A6: Component Compromise	Running a malicious vTPM binary.	Measured Launch: The malicious binary alters the PCR values, breaking the seal on the AK, rendering it unusable.

Performance: The implementation on GCP bare-metal instances showed low overhead, making the protocol practical for production use.

5. Significance

• Closing the "Location-Oblivious" Gap: DCEA transforms the data center from a "black box" into a verifiable security boundary. It allows external parties to cryptographically confirm that a workload is running in a specific, trusted facility.
• Enabling Adversarial Trust Models: This is crucial for Decentralized Finance (DeFi) and other permissionless systems where participants do not trust the infrastructure provider. It allows for "verifiable execution-location guarantees."
• Defense Against Physical Attacks: By ensuring the workload is in a trusted data center, DCEA effectively prevents active physical attacks (like bus interposition) that TEEs otherwise assume are impossible to prevent without physical custody.
• Generalizability: While prototyped on Intel TDX, the design is applicable to other TEEs (AMD SEV-SNP, ARM CCA) and can be adapted for on-premise hardware with tamper-evident enclosures.

In conclusion, Proof of Cloud (DCEA) provides the missing link between software attestation and physical reality, enabling a new class of privacy-preserving applications where the location of computation is as verifiable as the code being executed.