Proof of Cloud: Data Center Execution Assurance for Confidential VMs

Die Arbeit stellt DCEA vor, ein System, das durch die kryptografische Verknüpfung von CVM-Attestierungen mit plattformweiten TPM-Beweisen erstmals nachweisbare Garantien für die Ausführung vertraulicher virtueller Maschinen innerhalb eines vertrauenswürdigen Rechenzentrums bietet und so komplexe Proxy-Angriffe verhindert.

Das Wesentliche

Hier ist eine einfache Erklärung der Forschungspapier „Proof of Cloud" (Beweis der Cloud) auf Deutsch, verpackt in anschauliche Bilder und Metaphern.

Das große Problem: Der „Geisterfahrer" in der Cloud

Stellen Sie sich vor, Sie mieten einen hochsicheren, panzerartigen Tresor (das ist Ihr Vertrauensbereich oder CVM), um Ihre wertvollsten Geheimnisse darin zu lagern. Dieser Tresor ist so gebaut, dass selbst der Hausmeister (der Server-Betreiber) nicht hineinschauen kann, solange er nicht physisch den Tresor aufbricht.

Das Problem ist: Der Tresor kann Ihnen einen Zettel geben, der besagt: „Ich bin ein echter, sicherer Tresor und ich führe den richtigen Code aus." Aber dieser Zettel sagt nichts darüber aus, wo der Tresor steht.

Ein betrügerischer Hausmeister könnte den Tresor eigentlich in sein eigenes, unsicheres Lagerhaus stellen, wo er ihn mit einem Bohrgerät aufbohren und die Geheimnisse stehlen kann. Aber er schickt Ihnen trotzdem den offiziellen Zettel vom echten Tresor. Für Sie sieht alles sicher aus, aber in Wirklichkeit sind Ihre Daten in Gefahr.

In der IT-Welt nennt man das das Problem der verlorenen Standortbindung. Die Technologie weiß was läuft, aber nicht wo.

Die Lösung: Der „Proof of Cloud" (Beweis der Wolke)

Die Autoren dieses Papiers haben eine Lösung namens DCEA (Data Center Execution Assurance) entwickelt. Man kann sich das wie einen zweistufigen Sicherheitscheck vorstellen, der zwei verschiedene Wächter zusammenbringt.

Stellen Sie sich die Cloud als eine riesige Festung vor.

1. Wächter A (Der Tresor selbst): Er sagt: „Ich bin intakt und führe den richtigen Code aus."
2. Wächter B (Der Festungswächter/TPM): Er sitzt direkt am Gebäude und sagt: „Ich kann bestätigen, dass dieser Tresor tatsächlich in meinem Gebäude steht und nicht in einem Keller bei einem Betrüger."

DCEA zwingt diese beiden Wächter, sich die Hand zu reichen.

Wie funktioniert das? (Die Analogie)

Stellen Sie sich vor, Sie schicken einen Boten (Ihre Daten) in einen sicheren Raum.

• Der alte Weg: Der Bot kommt zurück und sagt: „Ich war in einem sicheren Raum." Das reicht dem Empfänger nicht, weil der Bot auch lügen könnte.
• Der neue Weg (DCEA): Der Bot kommt zurück und hat zwei Siegel dabei:
  1. Das Siegel des Raumes (dass er sicher war).
  2. Das Siegel des Gebäudes (dass der Raum hier steht).

Das Geniale an DCEA ist, dass diese beiden Siegel miteinander verknüpft sind. Wenn der Betrüger versucht, das Siegel des Raumes aus dem echten Gebäude zu stehlen und auf einen falschen Raum in seinem Keller zu kleben, passt das Gebäude-Siegel nicht mehr. Die Zahlen stimmen nicht überein. Der Betrug wird sofort aufgedeckt.

Die zwei Szenarien

Das Papier beschreibt zwei Arten, wie diese Festung aussehen kann:

1. Die gemietete Wohnung (Managed CVM): Sie mieten einen Raum in einem großen Hotel. Der Hotelmanager kontrolliert den Flur und die Tür. Sie vertrauen dem Manager, dass er die Schlüssel nicht kopiert. DCEA prüft hier, ob der Manager ehrlich ist und die Tür nicht manipuliert hat.
2. Das eigene Haus (Bare-Metal): Sie mieten ein ganzes Haus, bauen aber nur einen kleinen, sicheren Safe darin auf. Hier vertrauen Sie dem Hausbesitzer gar nicht. DCEA prüft hier, ob der Safe wirklich in diesem Haus steht, selbst wenn der Hausbesitzer versucht, den Safe zu täuschen.

Warum ist das wichtig?

Früher mussten Sie einfach darauf vertrauen, dass der Cloud-Anbieter (wie Google oder Amazon) ehrlich ist. Aber in der Welt von Dezentralen Finanzen (DeFi) oder bei sensiblen Daten (wie medizinischen Daten oder KI-Modellen) reicht blindes Vertrauen nicht mehr.

• Für Banken: Sie wollen sicher sein, dass ihre Kundenkonten nicht auf einem Server in einem Land mit schlechten Sicherheitsstandards laufen.
• Für KI-Firmen: Sie wollen beweisen, dass ihr teurer KI-Algorithmus wirklich auf ihrer Hardware läuft und nicht von einem Konkurrenten gestohlen wurde.

Das Ergebnis

Die Forscher haben gezeigt, dass man diese Verbindung zwischen „Was läuft" und „Wo es läuft" technisch herstellen kann, ohne dass die Systeme langsam werden. Sie haben einen mathematischen Beweis geliefert, dass selbst wenn der Hausmeister (der Server-Betreiber) böse ist und versucht, die Beweise zu fälschen, er nicht lügen kann, ohne dass es auffällt.

Zusammengefasst:
DCEA ist wie ein GPS-Tracker für digitale Geheimnisse. Es stellt sicher, dass Ihre Daten nicht nur in einem sicheren Tresor sind, sondern dass dieser Tresor auch wirklich dort steht, wo Sie glauben, dass er steht – und nicht irgendwo anders, wo jemand mit einem Bohrgerät wartet.

Technische Zusammenfassung

Hier ist eine detaillierte technische Zusammenfassung des Papers „Proof of Cloud: Data Center Execution Assurance for Confidential VMs" auf Deutsch:

Titel: Proof of Cloud: Data Center Execution Assurance for Confidential VMs (DCEA)

Autoren: Filip Rezabek, Moe Mahhouk, Andrew Miller, Quintus Kilbourn, Georg Carle, Jonathan Passerat-Palmbach (Flashbots, TU München, Imperial College London).

---

1. Problemstellung

Confidential Virtual Machines (CVMs) nutzen Trusted Execution Environments (TEEs) wie Intel TDX oder AMD SEV-SNP, um Daten während der Verarbeitung zu schützen. Die aktuellen Remote-Attestierungsmechanismen dieser TEEs zertifizieren zwar, welcher Code ausgeführt wird (Integrität des Software-Stacks), liefern jedoch keine kryptografischen Beweise darüber, wo dieser Code ausgeführt wird (Physischer Standort).

• Die Lücke: TEEs gehen davon aus, dass der Cloud-Anbieter die Hardware nicht physisch manipuliert (z. B. keine Bus-Interposition oder Side-Channel-Angriffe). Ein böswilliger Betreiber könnte jedoch eine validierte Attestierung von einem vertrauenswürdigen Rechenzentrum stehlen und diese mit einer CVM auf einer ungesicherten Hardware in einem anderen, unkontrollierten Umfeld kombinieren.
• Folge: Dies ermöglicht sogenannte „Proxy-Angriffe" (oder „Mix-and-Match"-Angriffe), bei denen ein Angreifer die Attestierung eines vertrauenswürdigen Systems nutzt, um vorzutäuschen, dass eine vertrauliche Workload in einem sicheren Rechenzentrum läuft, obwohl sie tatsächlich auf kompromittierter Hardware läuft.
• Risiko: Für Anwendungen wie DeFi, Genomik oder KI-Inferenz, bei denen die Datenhoheit kritisch ist, fehlt dem externen Verifizierer (Client) die Möglichkeit, die physische Herkunft und Integrität der Infrastruktur kryptografisch zu bestätigen.

2. Methodik: Data Center Execution Assurance (DCEA)

Die Autoren schlagen DCEA vor, ein Design, das eine „Proof of Cloud" generiert, indem es die CVM-Attestierung an Beweise eines plattformweiten Trusted Platform Modules (TPM) bindet.

Kernprinzip:
DCEA verbindet zwei unabhängige Vertrauensanker (Roots of Trust):

1. TEE-Hersteller: (z. B. Intel/AMD) liefert die Attestierung des CVM-Inhalts (Code, Konfiguration).
2. Infrastruktur-Anbieter: (Cloud-Provider) liefert die Attestierung der physischen Plattform über ein TPM (oder vTPM).

Technische Umsetzung:

• Bindung: Die Laufzeit-Messungen des TEE (z. B. Intel TDX RTMRs) werden mit den Boot-Messungen des vTPM (Platform Configuration Registers, PCRs) verknüpft.
• Zwei Szenarien:
  • Szenario I (Managed CVM): Der Provider verwaltet Host-OS und vTPM. Die Bindung erfolgt über die Konsistenz der Messwerte zwischen TEE und vTPM.
  • Szenario II (Bare-Metal): Der Tenant nutzt eine dedizierte Bare-Metal-Server mit einem physischen TPM (dTPM). Hier wird Intel TXT (Trusted Execution Technology) genutzt, um den gesamten Boot-Prozess (Firmware, Hypervisor, vTPM) in den PCRs 17-18 zu messen. Der Attestierungsschlüssel (AK) des vTPM wird an diesen gemessenen Zustand „versiegelt" (Sealed).
• Verifizierungsprozess: Der Verifizierer fordert sowohl den TDX-Quote als auch den vTPM-Quote an. Im CVM selbst wird geprüft, ob die Messwerte übereinstimmen (z. B. ob der Hash des vTPM-öffentlichen Schlüssels im TDX-Report enthalten ist und ob die PCRs mit den TEE-Messungen übereinstimmen).

3. Wichtige Beiträge (Key Contributions)

1. Formalisierung von „Environment Provenance": Die Autoren definieren erstmals die physische Infrastruktur-Bindung als primäres Sicherheitsziel für CVMs und identifizieren die aktuelle Blindstelle in TEE-Threat-Modellen.
2. Design und Implementierung von DCEA: Entwicklung eines Protokolls, das CVMs kryptografisch an einen spezifischen physischen Chassis bindet, indem es TEE-Reports mit TPM-Quotes verknüpft.
3. Formaler Sicherheitsbeweis: Unter Verwendung des AGATE-Frameworks im Universal Composability (UC)-Modell wird bewiesen, dass DCEA auch bei einem böswilligen Host-Software-Stack (Hypervisor, OS) ein ideales, standortbewusstes TEE emuliert. Es widersteht fortgeschrittenen Relay- und Proxy-Angriffen.
4. Praktische Evaluation: Implementierung auf Google Cloud (GCP) mit Intel TDX und Intel TXT auf Bare-Metal-Instanzen. Die Evaluation zeigt, dass der Overhead gering ist und das System praktikabel einsetzbar ist.

4. Ergebnisse und Angriffsabwehr

Das System wurde gegen sechs spezifische Angriffsvektoren (A1–A6) getestet, die von einem böswilligen Host-Operator ausgehen könnten:

• A1: Relay & Proxy (Mix-and-Match): Ein Angreifer leitet TPM-Interaktionen zu einer anderen Maschine weiter.
  • Abwehr: Durch die Versiegelung des Attestierungsschlüssels (AK) an den spezifischen Boot-Zustand (PCRs 17-18) und die Prüfung der Konsistenz zwischen TEE-Messungen und TPM-PCRs ist ein solcher Angriff unmöglich. Ein mismatch führt sofort zur Ablehnung.
• A2–A6 (Forgery, Inconsistency, Channel Interception, Identity Substitution, Compromise):
  • Abwehr: Da der AK nur unter dem exakten, gemessenen Zustand entsiegelt werden kann, können manipulierte Software-Stacks oder gefälschte Zertifikate keine gültigen Signaturen erzeugen. Die Einbettung des Hashs des vTPM-Keys im TEE-Report verhindert Identitätsdiebstahl.

Performance:
Die Implementierung zeigt einen minimalen Overhead. Die zusätzlichen Schritte (TPM-Quote anfordern, Konsistenzprüfung im CVM) sind effizient und machen DCEA für produktive Umgebungen geeignet.

5. Bedeutung und Implikationen

• Schließung der Threat-Model-Lücke: DCEA erweitert das TEE-Threat-Modell, indem es die physische Umgebung als vertrauenswürdigen Teil der Sicherheitskette integriert, ohne dabei auf die Annahme eines ehrlichen Cloud-Betreibers angewiesen zu sein (solange dieser keine physischen Angriffe startet).
• Vertrauenswürdige Dezentrale Systeme: Für Bereiche wie DeFi, wo Teilnehmer sich nicht gegenseitig vertrauen, bietet DCEA die notwendige kryptografische Gewissheit, dass sensible Berechnungen tatsächlich in einem zertifizierten Rechenzentrum stattfinden.
• Unabhängigkeit vom Hypervisor: Im Gegensatz zu früheren Ansätzen, die auf der Integrität des Hypervisors basierten, garantiert DCEA die Integrität selbst dann, wenn der Hypervisor kompromittiert ist (insbesondere im Bare-Metal-Szenario).
• Allgemeine Anwendbarkeit: Obwohl das Prototyp auf Intel TDX basiert, ist das Konzept auf andere TEEs (wie ARM CCA oder AMD SEV-SNP) übertragbar, sofern diese vergleichbare Attestierungsprimitive bieten.

Fazit:
DCEA transformiert die „Ausführungsposition" von einer impliziten Annahme zu einer verifizierbaren Sicherheitseigenschaft. Es ermöglicht externen Verifizierern, mit hoher Sicherheit zu bestätigen, dass eine vertrauliche Workload auf der Hardware eines vertrauenswürdigen Cloud-Anbieters läuft und nicht auf einer manipulierten oder ungesicherten Infrastruktur.