2025-11-18T12:28:13.304767

Proof of Cloud: Data Center Execution Assurance for Confidential VMs

Rezabek, Mahhouk, Miller et al.
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.
academic

Proof of Cloud: Data Center Execution Assurance for Confidential VMs

Grundinformationen

  • Paper-ID: 2510.12469
  • Titel: Proof of Cloud: Data Center Execution Assurance for Confidential VMs
  • Autoren: Filip Rezabek, Moe Mahhouk, Andrew Miller, Stefan Genchev, Quintus Kilbourn, Georg Carle, Jonathan Passerat-Palmbach
  • Klassifizierung: cs.CR (Kryptographie und Sicherheit), cs.DC (Verteilte, parallele und Cluster-Computing)
  • Veröffentlichungsdatum: 14. Oktober 2024 (arXiv Preprint)
  • Paper-Link: https://arxiv.org/abs/2510.12469

Zusammenfassung

Vertrauliche virtuelle Maschinen (CVMs) schützen Daten während der Verarbeitung durch die Ausführung von Workloads in hardwareisolierten Umgebungen. Sie erben jedoch auch die Einschränkungen der zugrunde liegenden Hardware. Vertrauenswürdige Ausführungsumgebungen (TEEs) erzwingen diese Isolation, aber ihre Bedrohungsmodelle schließen Angreifer mit physischem Zugriff explizit aus. Kommerzielle TEEs (wie Intel TDX) gehen davon aus, dass Infrastrukturanbieter die Hardware nicht auf physischer Ebene ausnutzen. Dies erzeugt einen Widerspruch: Mandanten müssen der Integrität des Anbieters auf Hardware-Ebene vertrauen, aber bestehende Remote-Attestation kann nicht überprüfen, ob eine CVM tatsächlich auf einer physisch vertrauenswürdigen Plattform läuft. Dieser Artikel schlägt ein Design für Data Center Execution Assurance (DCEA) vor, das einen „Cloud-Beweis" generiert, der die CVM durch vTPM-verankerte Messungen an ihre zugrunde liegende Plattform bindet und sicherstellt, dass CVM-Startnachweis und TPM-Attestation auf denselben physischen Gehäuse verweisen.

Forschungshintergrund und Motivation

Problemdefinition

Aktuelle vertrauliche virtuelle Maschinen (CVMs) weisen einen kritischen Sicherheitsmangel auf: Während TEE nachweisen kann, „welcher Code ausgeführt wird", kann es nicht nachweisen, „wo der Code ausgeführt wird". Dieser „ortsunabhängige" Blindfleck ermöglicht es böswilligen Operatoren, scheinbar vertrauenswürdige Workloads auf ihrer eigenen kontrollierten Hardware auszuführen und gleichzeitig gültige Nachweise zu erzeugen.

Bedeutung des Problems

  1. Bedrohungsmodell-Mängel: Das Bedrohungsmodell kommerzieller TEEs (Intel TDX, AMD SEV-SNP) geht davon aus, dass Angreifer keinen physischen Zugriff auf Server haben, aber diese Annahme kann nicht überprüft werden
  2. Praktische Angriffsfälle: Kürzliche Angriffe haben Intel SGX-Attestation-Schlüssel durch physischen Zugriff extrahiert
  3. Hochrisiko-Anwendungen: Dezentralisierte Finanzen (DeFi) und andere sensible Bereiche verlassen sich zunehmend auf TEE-Schutz für wertvolle Vermögenswerte, aber die Teilnehmer vertrauen sich gegenseitig nicht

Einschränkungen bestehender Methoden

  • Standard-TEE-Attestation überprüft nur CPU-Modell, Mikro-Code und Startzustand, enthält aber keine Nachweise über den Prozessor-Installationsort
  • Kann nicht erkennen, wenn böswillige Operatoren Workloads in unkontrollierte Umgebungen migrieren
  • Es fehlt ein kryptographischer Mechanismus zur Überprüfung der TEE-Position

Kernbeiträge

  1. Definition des DCEA-Bedrohungsmodells: Für CVM- und Bare-Metal-Szenarien mit verschiedenen Angreifer-Fähigkeiten
  2. Design einer praktischen DCEA-Architektur: Bindung von TD-Attestation an Plattform-Messungen über vTPM
  3. Bewertung der Machbarkeit und Sicherheit der Methode: Einschließlich detaillierter Protokoll-Implementierung und Angriffsmilderungsmaßnahmen
  4. Bereitstellung einer Referenzimplementierung: Kandidaten-Implementierung auf Google Cloud und Intel TDX unter Verwendung von Intel TXT für vertrauenswürdiges Booten

Methodische Details

Aufgabendefinition

DCEA zielt darauf ab, Remote-Verifiern kryptographische Nachweise zu liefern, die belegen, dass vertrauliche Workloads nicht nur in einem verifizierten Software- und Hardware-Zustand, sondern auch in einer bekannten Infrastrukturumgebung ausgeführt werden.

Design der Kernarchitektur

Duale Vertrauenswurzeln

DCEA etabliert zwei parallele Vertrauenswurzeln:

  1. TEE-Vertrauenswurzel: Von TEE-Herstellern wie Intel
  2. Infrastruktur-Vertrauenswurzel: Von Cloud-Anbietern, implementiert über TPM/vTPM

Zwei Bereitstellungsszenarien

Szenario 1 (S1): Verwaltete CVM

  • CVM läuft auf vom Anbieter verwalteter Virtualisierungsebene mit vTPM
  • Cloud-Anbieter verwaltet Host-OS und vTPM-Infrastruktur
  • Bindung durch Konsistenzprüfung von vTPM-Attestation und TD-Attestation

Szenario 2 (S2): Bare-Metal-Bereitstellung

  • Single-Tenant-Bare-Metal-Server mit direktem Zugriff auf diskretes TPM
  • Host-Software-Stack ist nicht vertrauenswürdig, nur Hardware-Garantien
  • Nutzt Intel TXT zur Etablierung einer Vertrauenskette vom TPM zur CVM

Technische Implementierungsdetails

Vierschrittiges DCEA-Protokoll

  1. Etablierung vertrauenswürdigen Bootens und Plattform-Wurzel: Verwendung von Intel TXT für sicheres Booten, Messung früher Boot-Elemente in PCR 17-18
  2. Konfiguration und Versiegelung von Attestation-Schlüsseln: TPM generiert AK und versiegelt privates Schlüsselmaterial unter PCR 17-18-Richtlinie
  3. Bindung von Gast-Nachweisen: TD bettet Hash des öffentlichen vTPM-AK-Schlüssels in seinen Attestation-Bericht ein
  4. Verifizierer-Workflow für zusammengesetzte Nachweise: Verifizierer initiiert nonce-basierte Herausforderung, erhält TD-Bericht und TPM-Attestation

Wichtige technische Innovationen

  • PCR-RTMR-Kreuzprüfung: Erkennung von Inkonsistenzen durch Vergleich von TPM-PCR-Werten und TD-RTMR-Werten
  • Schlüsselversionierungsmechanismus: Versiegelung des vTPM-AK auf spezifische PCR-Werte, Verhinderung der Verwendung in nicht übereinstimmenden Umgebungen
  • Transitive Bindung: Erstellung transitiver Bindung vom TD-Nachweis zu Host-Stack-Messungen über AK-Hash

Sicherheitsanalyse

Bedrohungsmodell

  • Angreifer-Fähigkeiten: Kontrolle über Host-OS, Hypervisor und Virtualisierungs-Stack; kann Nachrichten abfangen, verzögern, wiedergeben oder injizieren
  • Angreifer-Einschränkungen: Keine physische Manipulation möglich; CPU- und TPM-Hersteller sind vertrauenswürdig; Infrastruktur des Cloud-Anbieters ist vertrauenswürdig

Angriffsvektoren und Mitigationsmaßnahmen

AngriffstypAngriffsbeschreibungMitigationsmaßnahme
A1: Attestation-/MessfälschungFälschung von vTPM-Attestation oder Injektion falscher PCR/RTMR-WerteQE-signierte TD + versiegelte AK-Attestation
A2: Relay-/Proxy-AngriffeWeiterleitung von Attestation-Anfragen an entfernte ehrliche MaschineNonce + TD-eingebetteter AK-Hash + AK-Versiegelung
A3: Messung-InkonsistenzPCR-Werte stimmen nicht mit TD-RTMR übereinVerifizierer prüft TD RTMR gegen PCR 17-18
A4: Kanal-Abfangen/ManipulationMan-in-the-Middle-Angriff auf TD-zu-vTPM-PfadEndpunkt-Bindung über AK + Signaturprüfung
A5: Identitäts- und SchlüsselersetzungFälschung von TPM-EK-Zertifikat oder Ersetzung erwarteter AKEK-verankerter AK-Ursprung + TD-eingebettete erwartete AKpub
A6: Kompromiss privilegierter KomponentenAusführung modifizierter böswilliger vTPM-BinärdateivTPM/Host-Messung in PCR 18

Experimentelle Einrichtung und Ergebnisse

Implementierungsplattform

  • Zielplattform: Intel TDX auf Google Cloud Platform
  • Technologie-Stack: Intel TXT, TPM 2.0, QEMU-Hypervisor
  • Testumgebung: GCP- und OVH-Hosts in der Region Kanada

Leistungsbewertung

Leistungstests mit 500 aufeinanderfolgenden Operationen auf TPM und vTPM:

OperationstypHardware-TPMvTPM
Attestation-Generierung~0,55 Sekunden~0,30 Sekunden
Signatur-Operationen~0,40 Sekunden~0,15 Sekunden

Wichtigste Erkenntnisse:

  • Hardware-TPM ist etwa eine Größenordnung langsamer als Software-vTPM
  • vTPM-Leistung ist stabiler, Hardware-TPM zeigt mehr Schwankungen
  • Für einmalige Attestation-Operationen ist der Leistungs-Overhead akzeptabel

Cloud-Plattform-Unterstützung

PlattformCVM-UnterstützungvTPM-UnterstützungBare-Metal-UnterstützungHardware-TPM
GCP✓✓✓✓
Azure✓✓××
AWS×✓××

Verwandte Arbeiten

Ortsbindungs-Attestation

Bestehende Lösungen stützen sich typischerweise auf verzögerungsbasierte Verifizierung oder externe Geolokalisierungssignale wie GPS, weisen aber Probleme mit Netzwerk-Pfad-Rauschen oder mangelnder Genauigkeit auf.

Schutz vor Proxy-Angriffen

Der in diesem Artikel vorgeschlagene „Frankenstein-Proxy"-Angriff erweitert bestehende Verbindungsangriff-Konzepte, wobei der Angreifer mehrere Hardware-Geräte statt einer einzelnen Plattform besitzt.

Datenschutzmechanismen

Verwandte Arbeiten betonen Bedenken hinsichtlich der Offenlegung sensibler Informationen in Certificate Transparency Logs. Dieser Artikel schlägt die Verwendung von Zero-Knowledge-Proofs zur Minderung von Nachverfolgungsrisiken vor.

Schlussfolgerungen und Diskussion

Hauptschlussfolgerungen

  1. DCEA überbrückt erfolgreich die Lücke zwischen TEE-Bedrohungsmodell und praktischen Bereitstellungsanforderungen
  2. Durch duale Vertrauenswurzeln und PCR-RTMR-Kreuzvalidierung wird effektiv gegen sechs Haupttypen von Software-Angriffen verteidigt
  3. Die Implementierung auf bestehenden Hardware-Plattformen beweist die Machbarkeit des Ansatzes

Einschränkungen

  1. PCR-Messung-Prozess-Abhängigkeit: PCR-Messungen können zwischen verschiedenen Plattformen oder Virtualisierungs-Stacks variieren
  2. Multi-Tenant-Umgebungs-Herausforderungen: vTPM-Komponenten-Wiederverwendung kann die Eindeutigkeit der Attestation-Garantien schwächen
  3. Datenschutzüberlegungen: vTPM-Zertifikat-Ketten können Bereitstellungsdetails offenlegen

Zukünftige Richtungen

  1. Erweiterung auf AMD-Plattformen: Erfordert AMD SEV-SNP mit ähnlicher RTMR-Funktionalität
  2. Globales Schlüssel-Register: Etablierung von AK-Eindeutigkeitsverifizierung basierend auf Blockchain oder Certificate Transparency
  3. Zero-Knowledge-Proof-Integration: Implementierung datenschutzschonender Plattform-Verifizierung

Tiefgreifende Bewertung

Stärken

  1. Problemrelevanz: Adressiert kritische Sicherheitslücke bei CVM-Bereitstellung
  2. Methodische Innovation: Erstmaliger systematischer Ansatz zur Ortsbindungs-Attestation
  3. Hohe Praktikabilität: Auf bestehenden kommerziellen Plattformen einsetzbar
  4. Umfassende Sicherheitsanalyse: Identifiziert und mindert mehrere Angriffsvektoren
  5. Vollständige Implementierung: Detaillierte Protokoll-Implementierung und Leistungsbewertung

Mängel

  1. Plattformabhängigkeit: Derzeit hauptsächlich auf Intel TDX beschränkt, begrenzte AMD-Unterstützung
  2. Vertrauensannahmen: Erfordert weiterhin Vertrauen in physische Sicherheit und Zertifikatsvergabe des Cloud-Anbieters
  3. Leistungs-Overhead: Hardware-TPM-Operationen sind relativ langsam
  4. Komplexität: Protokoll-Implementierung ist komplex und erschwert die Bereitstellung

Auswirkungen

  1. Akademischer Beitrag: Bietet neue Sicherheits-Garantie-Dimension für vertrauliches Computing
  2. Praktischer Wert: Bedeutsam für hochriskante Anwendungen wie DeFi
  3. Standardisierungs-Potenzial: Kann zukünftige TEE-Standard-Entwicklung beeinflussen

Anwendungsszenarien

  • Dezentralisierte Finanzanwendungen (DeFi)
  • Multi-Party-Computation-Szenarien
  • Cloud-Computing-Workloads mit hohen Sicherheitsanforderungen
  • Vertrauliche Computing-Anwendungen mit Ortsverfizierungsanforderungen

Literaturverzeichnis

Das Papier zitiert 55 verwandte Arbeiten, die wichtige Arbeiten aus mehreren Bereichen abdecken, darunter TEE-Technologie, TPM-Spezifikationen, Cloud-Computing-Sicherheit und kryptographische Protokolle, und bietet damit eine solide theoretische Grundlage für die Forschung.