Rechnen im versiegelten Raum: Confidential Computing und die Grenzen des Nichtvertrauens

Der Aufhänger: Die Lücke, die alle Verschlüsselung offenlässt

Es gibt eine Routine, die in jedem halbwegs reifen IT-Betrieb inzwischen selbstverständlich ist. Daten auf der Festplatte? Verschlüsselt – BitLocker, LUKS, serverseitige Verschlüsselung im Objektspeicher. Daten auf dem Netzwerk? Verschlüsselt – TLS überall, am besten mit Zertifikatsrotation und Perfect Forward Secrecy. Zwei der drei klassischen Datenzustände sind damit abgedeckt: data at rest und data in transit.

Und dann kommt der dritte Zustand, über den selten gesprochen wird, weil es so lange keine Antwort auf ihn gab: data in use. In der Sekunde, in der eine Anwendung die Daten tatsächlich verarbeitet, müssen sie im Klartext im Arbeitsspeicher liegen. Die Festplattenverschlüsselung hat sie entschlüsselt, TLS hat sie entpackt, und nun liegen sie als nackte Bytes in den RAM-Seiten eines virtuellen Servers. Wer kommt da heran?

Die unangenehme Antwort lautet: der Hypervisor. Und damit alles und jeder, der den Hypervisor kontrolliert. In einer klassischen Virtualisierung ist der Hypervisor der allmächtige Herr über die Gastmaschine – er verwaltet deren Speicherseiten, kann sie jederzeit lesen, umschreiben, auslagern, einen Snapshot ziehen. Das ist kein Fehler, das ist seine Aufgabe. Nur: In der Public Cloud gehört der Hypervisor nicht dir. Er gehört dem Anbieter. Und damit gehört dir, technisch betrachtet, auch nicht die Vertraulichkeit deiner Daten während ihrer Verarbeitung – sie hängt an der Vertrauenswürdigkeit und Kompromittierungsfreiheit eines Software-Stacks, den du weder siehst noch kontrollierst, bedient von einem Personal, das du nie getroffen hast, in einem Rechenzentrum, das du nie betreten wirst.

Jahrelang war die Antwort darauf organisatorisch: Verträge, Zertifizierungen, Auftragsverarbeitungsvereinbarungen, Audits. Das ist nicht nichts – aber es ist Papier. Confidential Computing ist der Versuch, dieselbe Frage mit Silizium zu beantworten. Die Idee: Wenn die CPU selbst dafür sorgt, dass der Hypervisor den Speicher des Gastes nicht im Klartext lesen kann, dann muss man dem Betreiber nicht mehr vertrauen, sondern nur noch dem Chiphersteller und der Mathematik.

Dieser Artikel nimmt dieses Versprechen auseinander. Er zeigt, was genau garantiert wird und was nicht, wie die beiden dominierenden Technologien AMD SEV-SNP und Intel TDX unter der Haube funktionieren, warum Remote Attestation der eigentliche Kern der Sache ist und nicht die Verschlüsselung, was das Ganze an Performance kostet (es gibt harte Messzahlen), und wo die Forschung in den letzten zwei Jahren Risse in die Mauer geschlagen hat. Am Ende steht eine nüchterne Einordnung: Confidential Computing verschiebt das Vertrauen, es beseitigt es nicht.

Teil 1: Was genau behauptet wird

Die Definition

Das Confidential Computing Consortium – ein Projekt der Linux Foundation, in dem unter anderem AMD, Intel, ARM, Google, Microsoft und Red Hat zusammenarbeiten – hat sich auf eine knappe Definition verständigt: Confidential Computing ist der Schutz von Daten während ihrer Verarbeitung durch Berechnung in einer hardwarebasierten, attestierten Trusted Execution Environment.

Jedes Wort darin trägt Last. Hardwarebasiert: Die Garantie kommt nicht von einem Betriebssystem oder einer Bibliothek, sondern von Mechanismen im Prozessor. Attestiert: Es gibt einen kryptographischen Nachweis darüber, dass die Umgebung tatsächlich die ist, für die sie sich ausgibt – ohne diesen Nachweis ist die Verschlüsselung wertlos, dazu kommen wir in Teil 3. Trusted Execution Environment (TEE): der abgeschirmte Bereich selbst.

Die drei Pflichteigenschaften eines TEE

Eine Umgebung darf sich laut Consortium nur dann TEE nennen, wenn sie drei Eigenschaften zusichert:

Datenvertraulichkeit (data confidentiality): Unbefugte können die Daten während der Verarbeitung im TEE nicht einsehen.

Datenintegrität (data integrity): Unbefugte können die Daten während der Verarbeitung nicht hinzufügen, entfernen oder verändern.

Codeintegrität (code integrity): Unbefugte können den im TEE laufenden Code nicht hinzufügen, entfernen oder verändern.

Das ist präziser, als es auf den ersten Blick wirkt. Vertraulichkeit allein wäre nämlich wenig wert. Ein Angreifer, der den Speicher nicht lesen, aber beliebig verändern kann, kann die Berechnung so lange verbiegen, bis sie ihm das Ergebnis selbst verrät. Genau deshalb heißt die relevante AMD-Technologie auch SEV-SNP – Secure Nested Paging – und nicht mehr nur SEV: Die erste Generation von AMDs Secure Encrypted Virtualization verschlüsselte den Gastspeicher, schützte ihn aber nicht gegen Manipulation durch den Hypervisor. AMDs eigenes Whitepaper von Januar 2020 trägt den Titel Strengthening VM Isolation with Integrity Protection and More – das nachgeschobene Wort "Integrity" ist die ganze Geschichte.

Optional, aber nicht garantiert, kommen weitere Eigenschaften hinzu: Codevertraulichkeit (auch der Algorithmus selbst bleibt geheim), authentifizierter Start, Attestierbarkeit und Wiederherstellbarkeit.

Was ausdrücklich nicht geschützt wird

Hier wird es für die Praxis interessant, und hier ist das Consortium bemerkenswert ehrlich. Im Bedrohungsmodell enthalten sind: Softwareangriffe auf Host-Betriebssystem, Hypervisor und Firmware; Protokollangriffe auf die Attestierung; kryptographische Angriffe; einfache physische Angriffe wie das Auslesen kalter DRAM-Module, Bus- oder Cache-Mitschnitte, eingesteckte Angriffsgeräte; sowie grobe Lieferketten-Manipulationen wie nachträglich angebrachte Debug-Ports.

Nicht enthalten sind: aufwendige physische Angriffe mit invasivem Hardwarezugriff über längere Zeit; Lieferkettenangriffe weiter oben in der Kette, etwa bei der Chipfertigung oder der Schlüsselinjektion; und Verfügbarkeitsangriffe. Letzteres ist wichtig und wird oft übersehen: Ein TEE schützt deine Daten davor, gelesen oder verfälscht zu werden – es schützt deine VM nicht davor, vom Betreiber einfach abgeschaltet zu werden. Der Hypervisor bleibt Herr über Rechenzeit, Speicherzuteilung und Lebensdauer.

Und dann steht da noch eine Annahme, die das Dokument selbst als von der Forschung angefochten markiert: Das Modell nimmt an, dass es keine ausnutzbaren Seitenkanäle gibt. Teil 5 dieses Artikels handelt genau davon.

Teil 2: Wie die Hardware das macht

Es gibt grob zwei Generationen von TEEs, und die Verschiebung zwischen ihnen erklärt, warum Confidential Computing erst jetzt in der Breite ankommt.

Die erste Generation: Enklaven im Prozess

Intels SGX (Software Guard Extensions, ab 2015) war der prominenteste Vertreter des Enklaven-Modells: Eine Anwendung legt einen kleinen, besonders geschützten Speicherbereich an, in dem nur ein sorgfältig minimierter Teil ihres Codes läuft. Das ergibt eine sehr kleine Trusted Computing Base – die Menge an Code, dem man vertrauen muss, ist winzig, was sicherheitstheoretisch ideal ist.

Praktisch war es eine Zumutung. Bestehende Anwendungen liefen nicht einfach in einer Enklave; man musste sie aufteilen, Systemaufrufe über eine Grenze hinweg marshallen, mit engen Speicherlimits leben. Für den überwiegenden Teil realer Workloads – eine Datenbank, ein Applikationsserver, ein ML-Training – war der Umbauaufwand prohibitiv.

Die zweite Generation: die ganze VM als geschützter Raum

Die heute relevante Antwort heißt Confidential VM (CVM): Nicht ein Stück Code wird abgeschirmt, sondern eine komplette virtuelle Maschine samt eigenem Betriebssystemkern. Der Deal ist genau umgekehrt zu SGX: Die Trusted Computing Base wird groß (das gesamte Gast-OS ist drin, mit all seinen Lücken), aber der Umbauaufwand sinkt auf fast null – ein unveränderter Linux-Server läuft darin.

Die zwei marktbeherrschenden Implementierungen sind AMD SEV-SNP und Intel TDX (Trust Domain Extensions). Eine gründliche, von Masanori Misono, Dimitrios Stavrakakis, Nuno Santos und Pramod Bhatotia veröffentlichte Vermessung beider Plattformen (TU München und INESC-ID Lissabon, erschienen 2024 in den Proceedings of the ACM on Measurement and Analysis of Computing Systems) hat die Architekturen und ihre Kosten erstmals systematisch verglichen. Ihre Befunde bilden das Rückgrat der nächsten beiden Abschnitte.

Speicherverschlüsselung: Wer hält den Schlüssel?

Der Grundmechanismus ist in beiden Fällen gleich: Ein Speichercontroller im Prozessor verschlüsselt und entschlüsselt Speicherseiten transparent beim Weg zwischen CPU-Cache und DRAM, mit einem Schlüssel, der pro VM eindeutig ist und den die Software nie zu Gesicht bekommt. Liest der Hypervisor eine Seite des Gastes, erhält er Chiffrat.

Die Wege unterscheiden sich im Detail:

• SEV-SNP markiert über ein spezielles Bit in der Gast-physischen Adresse (das C-Bit), ob eine Seite verschlüsselt oder bewusst geteilt ist. Die Schlüsselverwaltung übernimmt der AMD Secure Processor, ein ARM-basierter Coprozessor auf dem CPU-Die.
• TDX nutzt ein Shared-Bit und zwei verschachtelte Seitentabellen – eine für geteilten, eine für privaten Speicher (die Secure EPT) – mit pro Trust Domain unterschiedlichen Key-IDs. Dazu kommt ein neuer CPU-Modus namens SEAM, in dem eine vertrauenswürdige Softwarekomponente läuft, das TDX-Modul.

Das ist ein philosophischer Unterschied, der in der Praxis zählt: AMD verlagert die Vertrauensanker in einen separaten Hardware-Coprozessor, Intel in signierte, von Intel ausgelieferte Firmware, die in einem privilegierten CPU-Modus läuft. Beide Varianten haben ihre Freunde; das TDX-Modul ist updatebar (gut gegen Lücken, aber eine weitere Komponente, der man vertrauen muss), der Secure Processor ist starrer.

Integritätsschutz: die Buchführung über Seiteneigentum

Verschlüsselung allein verhindert kein Umschreiben. Ein Hypervisor könnte verschlüsselte Seiten vertauschen, duplizieren, oder eine alte Version wieder einspielen (ein Replay). Dagegen braucht es eine manipulationssichere Buchführung darüber, welche physische Seite zu welchem Gast in welcher Gast-physischen Adresse gehört.

• SEV-SNP führt dazu die Reverse Map Table (RMP) – eine vom Hypervisor nicht beschreibbare Tabelle, die jede Host-physische Seite auf ihren Eigentümer und die erwartete Gast-physische Adresse abbildet. Jeder Speicherzugriff wird gegen die RMP geprüft. Wird eine Seite hinter dem Rücken des Gastes umgehängt, schlägt die Prüfung fehl.
• TDX nutzt eine Physical Address Metadata Table (PAMT) sowie ein TD-Owner-Bit und Message Authentication Codes pro Cache-Line.

Dazu kommt in beiden Architekturen eine Regel, die man beim Debuggen von CVMs früh lernt: Der Gast muss Speicher explizit akzeptieren (memory acceptance), bevor er ihn nutzen darf. Das verhindert, dass der Hypervisor dem Gast im Nachhinein fremde Seiten unterschiebt – und ist, wie wir sehen werden, einer der Hauptgründe für die langen Startzeiten.

Teil 3: Attestierung – der eigentliche Kern

Hier kommt der Punkt, an dem Confidential Computing in der Praxis meistens missverstanden wird. Die Verschlüsselung ist nicht das Interessante. Das Interessante ist die Frage: Woher weiß ich, dass meine Daten überhaupt in einem TEE gelandet sind?

Stell dir vor, du schickst deine Geheimnisse in eine VM, die der Anbieter dir als "confidential" verkauft. Wenn du keinen Nachweis verlangst, kann es genauso gut eine ganz normale VM sein, in der jemand mitliest. Die gesamte Sicherheitseigenschaft hängt an einem kryptographischen Beweis, den die Hardware über sich selbst und über den geladenen Code abgibt – und an deiner Bereitschaft, diesen Beweis vor dem Übermitteln der Geheimnisse zu prüfen. Confidential Computing ohne geprüfte Attestierung ist Theater.

Die Rollen: RFC 9334

Die IETF hat 2023 mit RFC 9334 (Remote ATtestation procedureS (RATS) Architecture, Birkholz, Thaler, Richardson, Smith und Pan, informational) ein Vokabular geschaffen, das inzwischen herstellerübergreifend benutzt wird. Es trennt sauber zwischen:

Entscheidend ist die Trennung von Evidence (rohe Messwerte) und Attestation Result (geprüftes Urteil). Nur so lässt sich die schwierige Prüflogik an einen spezialisierten Dienst delegieren, ohne dass jede Anwendung Chiphersteller-Zertifikatsketten selbst verstehen muss.

RFC 9334 beschreibt zwei topologische Muster, deren Namen sich eingeprägt haben:

Passport-Modell: Der Attester holt sich selbst beim Verifier ein Attestation Result ab und legt es bei den Relying Parties vor – wie einen Pass, ausgestellt von einer vertrauten Behörde. Die Relying Party behandelt es als opakes Datum.

Background-Check-Modell: Der Attester schickt seine Evidence an die Relying Party, die sie unverarbeitet an den Verifier weiterleitet und das Urteil zurückbekommt – wie ein Arbeitgeber, der Zeugnisse bei der ausstellenden Stelle nachprüft.

Frische: das unterschätzte Problem

Ein Attestierungsnachweis ohne Zeitbezug ist nutzlos, denn ein Angreifer könnte einen alten, legitimen Nachweis wiedervorlegen. RFC 9334 nennt drei Mechanismen: explizite Zeitführung mit synchronisierten Uhren und signierten Zeitstempeln (in TEEs heikel, weil die Uhr typischerweise außerhalb der Vertrauensgrenze liegt), implizite Zeitführung per Nonce (der Prüfer schickt eine unvorhersehbare Zufallszahl, die in die Signatur eingehen muss) und Epoch-IDs (ein Verteiler sendet periodisch Epochenkennungen an alle Beteiligten, was Zustand pro Attester vermeidet). In der Praxis dominiert die Nonce.

Wie es konkret aussieht

Bei SEV-SNP signiert der Secure Processor den Attestierungsreport mit einem chipspezifischen Schlüssel, dem VCEK (Versioned Chip Endorsement Key); geprüft wird er über AMDs Zertifikatskette. Bei TDX ist der Report zunächst nur MAC-geschützt und wird von einer SGX-basierten Quoting Enclave in ein signiertes Quote umgewandelt, das über Intels Zertifizierungsdienste verifizierbar ist – ein hübsches Detail: Intels neue VM-Technologie erbt ihren Vertrauensanker von der älteren Enklaven-Technologie.

In beiden Fällen enthält der Report Messwerte über den geladenen Gast-Startzustand (Firmware, Kernel, Initrd, Kommandozeile) sowie Konfigurationsflags – etwa, ob Debugging erlaubt ist. Genau diese Flags zu prüfen ist in der Praxis der häufigste Fehlerfall: Ein Report, der sauber signiert ist, aber "Debug erlaubt" sagt, ist kein Sicherheitsnachweis.

Teil 4: Was es kostet – die Messzahlen

Hier wird oft geraten. Misono und Kollegen haben gemessen, auf Linux 6.8 und den damals aktuellen Hersteller-Stacks. Die Zahlen sind deutlich und instruktiv – und sie zeigen vor allem, wo die Kosten entstehen.

Drei Muster lassen sich daraus ableiten.

Erstens: Die Speicherverschlüsselung selbst ist billig. Rund 16 Nanosekunden zusätzliche Latenz und einstellige Prozentwerte in Speicherbenchmarks – das ist der Preis für AES im Speicherpfad, und der ist erstaunlich gering. Wer glaubt, Confidential Computing sei teuer "weil alles verschlüsselt wird", hat die falsche Ursache im Blick.

Zweitens: Teuer sind die Übergänge. Jeder Wechsel zwischen Gast und Hypervisor – ein VM-Exit – kostet in CVMs ein Mehrfaches, weil Register gesichert, Zustände gewechselt und Prüfungen durchlaufen werden müssen. Das trifft genau die Workloads, die viele solcher Übergänge erzeugen: Netzwerk-I/O vor allem. Im Zusammenspiel mit dem zweiten Kostentreiber – dem Umkopieren über Bounce Buffer, weil DMA-Geräte nicht direkt in verschlüsselten Gastspeicher schreiben dürfen – messen die Autoren bei UDP-Last mit geringer CPU-Auslastung rund 75 % Overhead auf SEV-SNP und 81 % auf TDX, und bei TCP unter hoher CPU-Last Durchsatzeinbrüche von bis zu etwa 60 %.

Drittens: Die Startkosten sind einmalig, aber heftig. Das explizite Akzeptieren von Speicher und die Buchführung auf Hostseite machen das erstmalige Belegen großer Speichermengen deutlich teurer; danach normalisiert sich das Verhalten auf etwa 5 % Abstand zur normalen VM. Für langlebige Server ist das irrelevant. Für ein Modell "pro Anfrage eine frische Confidential VM starten" – naheliegend bei vertraulicher Inferenz – ist es ein ernstes Problem. Bei Rechen-Workloads messen die Autoren mit NPB und passivem OpenMP-Warten im Mittel +41 % (SEV-SNP) und +73 % (TDX), mit einem Extremfall von +431 % auf TDX; aktives Pollen im Gast senkt diese Kosten erheblich, weil es Übergänge vermeidet.

Ein wichtiger Vorbehalt der Autoren selbst: Diese Zahlen gelten für bestimmte Hardware, bestimmte Kernel- und Firmwareversionen und ein damals noch sehr junges Software-Ökosystem. Die Größenordnungen bleiben lehrreich, die genauen Prozentwerte altern schnell.

Teil 5: Die Risse in der Mauer

Confidential Computing hat eine Eigenschaft, die man bei Sicherheitstechnologien selten so deutlich sieht: Das Bedrohungsmodell ist extrem aggressiv. Es nimmt an, dass der Hypervisor bösartig ist – nicht nur fehlerhaft, sondern ein aktiver, privilegierter Angreifer mit vollem Zugriff auf die Hardwareverwaltung. Das ist ein gewaltiger Anspruch, und die Sicherheitsforschung hat ihn in den letzten Jahren systematisch abgeklopft. Zwei Arbeiten derselben Gruppe an der ETH Zürich zeigen besonders gut, wo die Bruchstellen liegen.

Heckler: Angriff über die Klingel an der Tür

Benedict Schlüter, Supraja Sridhara, Mark Kuhne, Andrin Bertschi und Shweta Shinde präsentierten 2024 auf dem 33. USENIX Security Symposium einen Angriff namens Heckler. Die Beobachtung dahinter ist bestechend einfach: Der Hypervisor darf dem Gast weiterhin Interrupts zustellen – das ist nötig, damit der Gast überhaupt mit der Außenwelt arbeiten kann. Aber der Gastkern kann einen injizierten Interrupt nicht von einem echten unterscheiden. Er führt den zugehörigen Handler aus. Und Handler haben Nebenwirkungen auf Register und Programmzustand.

Der Angriff: Der Hypervisor wartet (per Page-Fault-Tracing präzise getimt) auf einen bestimmten Punkt im Programmablauf des Opfers und injiziert dort einen gezielt gewählten Interrupt.

Das Paradebeispiel ist int 0x80, Linux' alter Systemaufruf-Einsprung. Dieser Handler liest eax als Aufrufnummer und schreibt das Ergebnis zurück nach eax. Wenn der Angreifer ihn genau dann injiziert, wenn eax eine 0 enthält, wird daraus ein Wert ungleich null. Und nun kommt die Pointe: Injiziert man das direkt nach der Rückkehr von auth_password in OpenSSH, wird aus dem Rückgabewert "Passwort falsch" ein "Passwort richtig" – Authentifizierung mit beliebigem Passwort, auf SEV-SNP und TDX gleichermaßen. Dasselbe Prinzip bei sudo, angewandt auf die Rückgabe der Leerpasswort-Prüfung von PAM, hebt einen unprivilegierten Nutzer auf root. Beide Angriffe hintereinander – erst Shell über SSH, dann root über sudo – ergeben eine vollständige Übernahme der angeblich geschützten VM.

Auf SEV-SNP fanden die Autoren zusätzlich, dass Fließkomma-Ausnahmen (int 0x0, 9, 16) als SIGFPE bis in den Userspace durchschlagen und dort anwendungseigene Signal-Handler als Gadgets missbraucht werden können; sie demonstrierten damit verfälschte Ergebnisse in einem Java-Statistikwerkzeug, einem Julia-Textanalysepaket und einem C-Neuronalnetz – ein reiner Integritätsbruch, ohne jemals Speicher gelesen zu haben.

Die Mitigation für int 0x80 (CVE-2024-25744) besteht in einem Kernel-Patch, der die IA32-Emulation in SEV- und TDX-Gästen standardmäßig abschaltet. Für die übrigen Interrupts (CVE-2024-25743) argumentieren die Autoren, dass Software die Unterscheidung prinzipiell nicht leisten kann und es Hardware-Filterung braucht – wie TDX sie für Interrupts unter 31 bereits teilweise umsetzt. Dass TDX hier besser dastand, war weniger Glück als Design.

Heracles: Wenn Determinismus zum Orakel wird

Noch grundsätzlicher ist der 2025 auf der ACM CCS vorgestellte Angriff Heracles von Benedict Schlüter, Christoph Wech und Shweta Shinde. Er zielt auf eine Eigenschaft der Speicherverschlüsselung selbst.

SEV-SNP verschlüsselt mit AES-XEX und einem Tweak, der aus der physischen DRAM-Adresse abgeleitet wird. Das ist ein guter Gedanke: Dadurch ergibt derselbe Klartext an verschiedenen Adressen verschiedene Chiffrate, man kann also nicht einfach Blöcke über den Speicher hinweg vergleichen. Aber die Tweaks sind über die Lebensdauer des Gastes statisch – und damit ist die Verschlüsselung an einer gegebenen Adresse deterministisch: Derselbe Klartext an derselben Adresse ergibt immer dasselbe Chiffrat.

Der Hypervisor kann Chiffrat lesen (das ist erlaubt) und verschlüsselte Gastseiten im DRAM über Verwaltungs-APIs verschieben (das ist nötig). Beim Verschieben wird die Seite mit dem Tweak ihres neuen Ortes neu verschlüsselt. Daraus bauen die Autoren ein Klartext-Orakel: Der Angreifer legt einen geratenen Wert in eine Seite, die er selbst kontrolliert, verschiebt diese Seite an die frühere Adresse des Opfers und vergleicht das entstehende Chiffrat mit einem vorher gespeicherten Schnappschuss. Trifft es zu, war die Vermutung richtig.

Ein ganzer 16-Byte-Block lässt sich so nicht durchprobieren. Mit vier Primitiven, die byteweise Kopiervorgänge, gewählte Datenoffsets und wiederholte oder hochzählende Werte ausnutzen, verkleinern die Autoren die Suche auf etwa ein Byte zu einer Zeit. Demonstriert haben sie das Auslesen von Kernel-memcpy-Daten, bash- und sudo-Passwörtern, mbedtls-Exponenten (und damit Schlüsseln) sowie Mongoose-Session-Cookies – bei etwa 0,5 bis 2,5 Sekunden pro Byte. AMDs Reaktion erfolgte als Funktionsänderung in der SEV-SNP-ABI 1.58, nicht als CVE.

Was man daraus lernen sollte

Ich bin der Meinung, dass die richtige Lesart dieser Arbeiten nicht "Confidential Computing ist gebrochen" lautet, sondern etwas Konkreteres: Die Schnittstellen sind das Problem, nicht die Kryptographie. In beiden Fällen war nicht AES zu schwach. Beim einen Angriff war es der Interrupt-Kanal, beim anderen die Speicherverwaltungs-API – also genau jene Stellen, an denen das TEE notwendigerweise noch mit dem unvertrauten Hypervisor sprechen muss.

Das ist ein wiederkehrendes Muster der Rechnerarchitektur: Die Vertraulichkeitsgarantie gilt für den Datenpfad, aber Rechner haben nicht nur Datenpfade. Sie haben Steuerpfade, Mikroarchitektur, Zeitverhalten, Zustandsverwaltung. Wer Wenn der Prozessor zu viel rät: Spectre, Meltdown und die Sünde der spekulativen Ausführung kennt, erkennt die Verwandtschaft sofort: Dort war es die spekulative Ausführung, die eine formal korrekte Isolation durch ihr beobachtbares Zeitverhalten unterlief. Auch Bits, die von selbst umkippen: Rowhammer und die physikalische Schwachstelle des Arbeitsspeichers gehört in diese Familie – der Speicher hält seine Abstraktion nicht ein, wenn man ihn physikalisch genug reizt. Das Bedrohungsmodell des Consortiums nimmt explizit an, es gäbe keine ausnutzbaren Seitenkanäle; diese Annahme ist nicht erfüllt, sondern lediglich ein mit jedem Patch neu verhandelter Zustand.

Teil 6: Wofür es sich trotzdem lohnt

Wenn das Versprechen angeknackst ist – wozu dann der Aufwand? Die Antwort liegt in einer nüchternen Betrachtung dessen, wogegen Confidential Computing tatsächlich gut wirkt.

Die drei Szenarien, die wirklich tragen

Erstens: Haftungs- und Zugriffsreduktion statt Angriffsresistenz. Der häufigste reale Nutzen ist nicht die Abwehr eines staatlich finanzierten Angreifers, sondern die Beseitigung ganzer Klassen von Zugriffsmöglichkeiten: der neugierige Administrator, das falsch konfigurierte Monitoring-Werkzeug, der Speicher-Dump, der versehentlich in einem Support-Ticket landet, der Snapshot im Backup. Gegen opportunistischen und fahrlässigen Zugriff wirkt die Technologie sehr gut – und das ist statistisch das, was tatsächlich passiert.

Zweitens: mehrseitige Berechnung mit gegenseitigem Misstrauen. Zwei Krankenhäuser wollen ihre Patientenkohorten gemeinsam auswerten, ohne einander die Rohdaten zu geben. Zwei Banken wollen Betrugsmuster korrelieren. Hier ist das TEE ein neutraler Dritter aus Silizium: Beide Parteien attestieren, welcher Code dort läuft, und schicken ihre Daten erst, wenn der Nachweis passt. Es ist bemerkenswert, dass dies exakt dasselbe Problem ist, das Beweisen ohne zu verraten: Zero-Knowledge-Beweise von Ali Babas Höhle bis zu zk-SNARKs auf rein mathematischem Wege löst – und ebenso jenes, das Der Zufall, der die Privatsphäre schützt: Differential Privacy und die Kunst, nichts über den Einzelnen zu verraten statistisch angeht. Drei Technologien, drei Vertrauensanker: Hardware, Mathematik, Statistik. Die Hardware-Variante ist mit Abstand die performanteste und mit Abstand die am stärksten annahmenbehaftete.

Drittens: vertrauliche Inferenz und Modellschutz. Wer ein Sprachmodell auf fremder Infrastruktur betreiben will, hat zwei Geheimnisse zu schützen: die Nutzereingaben und die Modellgewichte. Confidential Computing ist derzeit der einzige Weg, beides gleichzeitig zu adressieren, ohne die Berechnung um Größenordnungen zu verteuern – weshalb der Ausbau auf GPUs (vertraulicher Modus mit verschlüsseltem Host-GPU-Transfer) der aktuell meistbeachtete Entwicklungsstrang ist.

Die Betriebsrealität

Drei Dinge entscheiden in der Praxis über Erfolg oder Scheitern eines CVM-Projekts, und keines davon ist die Verschlüsselung:

Attestierung muss durchgesetzt werden, nicht nur verfügbar sein. Wenn deine Geheimnisverwaltung Schlüssel ausliefert, bevor sie einen gültigen, frischen, gegen Sollwerte geprüften Report gesehen hat, hast du einen schönen Haken auf der Compliance-Liste und keine Sicherheitseigenschaft. Der korrekte Ablauf ist immer: VM startet → attestiert → erhält erst daraufhin ihre Schlüssel aus einem Key-Management-Dienst, der die Attestierung prüft.

Die Sollwerte müssen reproduzierbar sein. Ein Report liefert Messwerte über Firmware, Kernel und Initrd. Du musst wissen, welche Werte richtig sind – also reproduzierbare Builds oder wenigstens eine verlässliche Lieferkette für die Sollwerte haben. Hier schließt sich interessanterweise der Kreis zu Der Baum, der die Wahrheit verdichtet: Merkle-Bäume und die Kunst der effizienten Integritätsprüfung: Transparenzprotokolle über veröffentlichte Soll-Messwerte sind der naheliegende Weg, dieses Problem herstellerunabhängig zu lösen, und genau diesen Weg gehen aktuelle Architekturen für vertrauliche KI-Dienste.

Die Trusted Computing Base bleibt groß. In einer CVM ist der gesamte Gastkern im Vertrauensbereich. Eine Lücke im Gast-Kernel ist eine Lücke im TEE. Confidential Computing schützt dich vor dem Betreiber – nicht vor dir selbst. Wer die Angriffsfläche ernsthaft verkleinern will, kombiniert CVMs mit minimalen Gastimages, wie sie sich im Umfeld von Die Wette auf fremden Code: Firecracker microVMs und das Ende des Container-VM-Dilemmas etabliert haben.

Eine Vergleichstabelle zur Orientierung

Teil 7: Das übergeordnete Denkprinzip

Tritt man einen Schritt zurück, dann ist Confidential Computing weniger eine Verschlüsselungstechnologie als eine Verschiebung des Vertrauensankers. Vorher musste man dem Betreiber vertrauen: seinem Personal, seinen Prozessen, seinem Hypervisor, seinem Rechenzentrumszugang. Nachher muss man dem Chiphersteller vertrauen: seinem Siliziumdesign, seiner Firmware, seiner Zertifikatskette, seiner Schlüsselinjektion in der Fertigung – und dem eigenen Gastimage.

Das ist unbestreitbar ein Fortschritt, weil die neue Vertrauensbasis kleiner, einheitlicher und prüfbarer ist. Eine Zertifikatskette lässt sich verifizieren; die Integrität eines Rechenzentrumsbetriebs lässt sich nur bezeugen. Aber es ist eben nicht "Zero Trust" im wörtlichen Sinne, und der Marketingbegriff "niemandem mehr vertrauen müssen" ist falsch. Vertrauen ist in verteilten Systemen keine Größe, die man eliminiert – es ist eine Größe, die man verlagert, verkleinert und überprüfbar macht.

Dasselbe Muster findet man überall, wo Sicherheit ernst genommen wird: Der Schlüssel, der nach jeder Nachricht stirbt: Das Signal-Protokoll, die Double Ratchet und die Kunst der Ende-zu-Ende-Verschlüsselung verlagert das Vertrauen vom Serverbetreiber auf die Geräte der Gesprächspartner, ohne es abzuschaffen. Ernte jetzt, entschlüssle später: Post-Quanten-Kryptographie und das Rennen gegen den Quantencomputer verlagert es von einem mathematischen Härteproblem auf ein anderes, von dem man hofft, dass es länger hält. Die ehrliche Frage lautet nie "vertraue ich?", sondern immer: "wem genau, wofür, und woran würde ich merken, dass das Vertrauen gebrochen wurde?"

Erkenntnis zum Mitnehmen

Die praktische Lehre lässt sich in einen Satz fassen: Confidential Computing ist nur so stark wie die Attestierung, die du tatsächlich erzwingst – und nur so stark wie das kleinste Gastimage, das du darin laufen lässt.

Konkret heißt das für jede Bewertung einer solchen Architektur, drei Fragen zu stellen, und zwar in dieser Reihenfolge:

1. Wird attestiert, und zwar vor der Schlüsselherausgabe? Wenn Geheimnisse fließen, bevor ein frischer, gegen bekannte Sollwerte geprüfter Report vorliegt, ist die Technologie Dekoration. Prüfe dabei ausdrücklich die Konfigurationsflags, nicht nur die Signatur.
2. Wer ist Verifier, und wessen Sollwerte gelten? Wenn derselbe Anbieter, vor dem du dich schützen willst, auch der Verifier ist und die Sollwerte setzt, hast du das Vertrauen nicht verlagert, sondern nur umbenannt.
3. Wie groß ist die Trusted Computing Base im Gast? Jedes Paket im Gastimage ist Teil deines TEE. Ein vollständiges Allzweck-Linux in einer Confidential VM ist ein Fortschritt gegenüber einer normalen VM, aber kein hermetischer Raum.

Und als Erwartungsmanagement: Rechne mit einstelligen Prozentkosten bei speicherlastigen und hohen zweistelligen bei netzwerklastigen Workloads, mit deutlich längeren Startzeiten, und damit, dass die Angriffsforschung weiterläuft. Confidential Computing hebt die Kosten eines Angriffs durch den Betreiber von "Konfigurationsänderung" auf "veröffentlichungswürdige Forschungsarbeit". Das ist viel. Es ist nicht unendlich.

Eine Frage zum Nachdenken

Confidential Computing löst das Problem, dass man dem Betreiber nicht vertrauen will, indem es das Vertrauen zum Chiphersteller verschiebt – zu einem Unternehmen, dessen Siliziumdesign du nicht einsehen, dessen Fertigung du nicht auditieren und dessen Schlüsselinjektion du nicht überprüfen kannst. Zugleich zeigen Heckler und Heracles, dass auch diese Vertrauensbasis Lücken hat, die erst durch externe Forschung sichtbar wurden.

Wenn Vertrauen in verteilten Systemen also nie verschwindet, sondern nur die Adresse wechselt: Nach welchem Kriterium entscheidest du eigentlich, welche Adresse besser ist? Ist es die Größe der zu vertrauenden Komponente, die Anzahl unabhängiger Prüfer, die Geschwindigkeit, mit der Lücken öffentlich werden – oder schlicht die Frage, wessen Interessen am besten mit deinen eigenen übereinstimmen? Und wo in deiner eigenen Architektur hast du ein Vertrauen platziert, dessen Bruch du gar nicht bemerken würdest?

Querverweise im Vault

• Wenn der Prozessor zu viel rät: Spectre, Meltdown und die Sünde der spekulativen Ausführung – die mikroarchitektonische Urform desselben Problems: formal korrekte Isolation, die durch Seitenkanäle unterlaufen wird.
• Bits, die von selbst umkippen: Rowhammer und die physikalische Schwachstelle des Arbeitsspeichers – was passiert, wenn der Speicher seine eigene Abstraktion nicht einhält; relevant für das physische Bedrohungsmodell von TEEs.
• Beweisen ohne zu verraten: Zero-Knowledge-Beweise von Ali Babas Höhle bis zu zk-SNARKs – dasselbe Ziel (rechnen, ohne zu verraten) mit Mathematik statt Hardware als Vertrauensanker.
• Der Zufall, der die Privatsphäre schützt: Differential Privacy und die Kunst, nichts über den Einzelnen zu verraten – der statistische Zugang zum selben Spannungsfeld zwischen Nutzen und Vertraulichkeit.
• Der Baum, der die Wahrheit verdichtet: Merkle-Bäume und die Kunst der effizienten Integritätsprüfung – die Datenstruktur hinter Transparenzprotokollen für Attestierungs-Sollwerte.
• Die Wette auf fremden Code: Firecracker microVMs und das Ende des Container-VM-Dilemmas – Isolation fremden Codes auf geteilter Infrastruktur, die komplementäre Fragestellung.
• Der Schlüssel, der nach jeder Nachricht stirbt: Das Signal-Protokoll, die Double Ratchet und die Kunst der Ende-zu-Ende-Verschlüsselung – Vertrauensverlagerung vom Betreiber auf die Endpunkte.
• Ernte jetzt, entschlüssle später: Post-Quanten-Kryptographie und das Rennen gegen den Quantencomputer – wie langlebig die kryptographischen Annahmen sind, auf denen auch Attestierungsketten beruhen.

Quellen

• Confidential Computing Consortium (2021): A Technical Analysis of Confidential Computing, Version 1.2, Oktober 2021 (Errata-Fassung vom 28.09.2021). Linux Foundation. https://confidentialcomputing.io/wp-content/uploads/sites/10/2023/03/CCC-A-Technical-Analysis-of-Confidential-Computing-v1.3_unlocked.pdf
• Birkholz, H., Thaler, D., Richardson, M., Smith, N., Pan, W. (2023): Remote ATtestation procedureS (RATS) Architecture. RFC 9334, IETF, Januar 2023 (Informational). https://www.rfc-editor.org/rfc/rfc9334.html
• Misono, M., Stavrakakis, D., Santos, N., Bhatotia, P. (2024): Confidential VMs Explained: An Empirical Analysis of AMD SEV-SNP and Intel TDX. Proceedings of the ACM on Measurement and Analysis of Computing Systems 8(3), Artikel 36. DOI: 10.1145/3700418. https://dl.acm.org/doi/10.1145/3700418
• Schlüter, B., Sridhara, S., Kuhne, M., Bertschi, A., Shinde, S. (2024): Heckler: Breaking Confidential VMs with Malicious Interrupts. Proc. 33rd USENIX Security Symposium, Philadelphia. https://www.usenix.org/system/files/usenixsecurity24-schluter.pdf
• Schlüter, B., Wech, C., Shinde, S. (2025): Heracles: Chosen Plaintext Attack on AMD SEV-SNP. Proc. ACM Conference on Computer and Communications Security (CCS '25), Taipeh. https://heracles-attack.github.io/Heracles-CCS2025.pdf
• AMD (2020): AMD SEV-SNP: Strengthening VM Isolation with Integrity Protection and More. White Paper, Januar 2020 (Dokument 70366). https://docs.amd.com/v/u/en-US/SEV-SNP-strengthening-vm-isolation-with-integrity-protection-and-more

← All articles