Confidential Computing soll sensible Workloads selbst dann schützen, wenn der Betreiber eines Servers oder dessen Hypervisor nicht vertrauenswürdig ist. Unternehmen nutzen solche Trusted Execution Environments (TEEs) etwa für besonders schützenswerte Analysen, Schlüsselverarbeitung oder vertrauliche KI-Workloads. Dabei stützen sie sich auf Speicherverschlüsselung und Remote Attestation: Der Arbeitsspeicher bleibt für den Host unlesbar, und eine signierte Messung soll belegen, dass wirklich der erwartete Code gestartet wurde.
Die am 14. September veröffentlichte Forschung zu DDRop zeigt jedoch eine wichtige Grenze dieses Modells. Ein Team von KU Leuven, ETH Zürich, Durham University und Google konnte Schreibvorgänge auf dem DDR5-Speicherbus gezielt verschwinden lassen. Dadurch verarbeitet eine geschützte virtuelle Maschine alte, weiterhin korrekt entschlüsselbare Daten, obwohl sie von einem erfolgreichen Update ausgeht. Betroffen sind nach Angaben der Forscher Intel TDX, Intel Scalable SGX und AMD SEV-SNP.
DDRop ist kein Angriff aus dem Internet. Er verlangt privilegierte Softwarekontrolle über den Server sowie einmaligen physischen Zugriff, um eine kleine Platine zwischen Prozessor und Speichermodul einzusetzen. Gerade für Confidential Computing ist diese Einschränkung trotzdem relevant: Die Technik wird ausdrücklich auch dafür beworben, Workloads gegenüber dem Infrastrukturbetreiber abzusichern.
Das technische Problem: Verschlüsselung beweist keine Aktualität
Moderne Server-TEEs verschlüsseln große Arbeitsspeicherbereiche transparent. Damit diese Schutzmechanismen bei Cloud-Workloads mit viel RAM performant und skalierbar bleiben, verzichten die untersuchten Architekturen jedoch auf eine vollständige kryptografische „Freshness“-Garantie. Der Prozessor kann einen alten Ciphertext weiterhin korrekt entschlüsseln. Ohne Versionszähler oder eine vergleichbare Integritätsstruktur erkennt er nicht zwingend, dass dieser Wert nicht mehr der jüngste ist.
DDRop nutzt genau diese Lücke. Der Hardware-Interposer sitzt auf dem DDR5-Bus, erzeugt bei ausgewählten Schreibkommandos einen Paritätsfehler und unterdrückt zugleich die Fehlermeldung an den Prozessor. Das Speichermodul verwirft den Schreibbefehl, während die CPU davon nichts erfährt. Im RAM bleibt ein älterer Wert zurück. Da dessen Verschlüsselung gültig ist, wird er später als scheinbar korrekter Inhalt gelesen.
Laut der Projektseite der Forscher arbeitet die Platine mit nativer DDR5-Geschwindigkeit und kostet in einer Stückliste für zehn Exemplare rund 159 US-Dollar pro System; Forschungs- und Montageaufwand sind darin nicht enthalten. Die vollständigen Hardwaredesigns, Firmware und Proof-of-Concept-Komponenten wurden auf GitHub veröffentlicht. Die Arbeit soll im November auf der ACM CCS 2026 vorgestellt werden.
Von einem verworfenen Schreibzugriff zur manipulierten VM
Besonders weitreichend ist der demonstrierte Pfad gegen Intel TDX. Dort verwaltet ein vertrauenswürdiges TDX-Modul die geschützten Seitentabellen einer Confidential VM. Beim Anlegen einer neuen Tabelle initialisiert die Firmware deren Einträge. Lässt DDRop diese Initialisierungsschreibvorgänge verschwinden, bleiben zuvor präparierte verschlüsselte Werte im Speicher zurück. Ein angreiferkontrollierter Trust Domain kann damit nach Darstellung der Forscher eigene Seiten auf beliebige physische Adressen abbilden.
Im standardmäßigen Logical-Integrity-Modus konnten die Forscher dadurch geschützte Metadaten verändern, den Debug-Modus einer Opfer-VM aktivieren und Klartextspeicher über die Debug-Schnittstelle auslesen. Sie demonstrierten außerdem eine gefälschte Attestation für eine eigene, manipulierte VM: Die Startmessung wurde so überschrieben, dass der nicht vertrauenswürdige Workload wie ein genehmigtes System erschien. Nach Auskunft eines Forschers gegenüber The Register liefen die TDX-Demonstrationen deterministisch in weniger als zwei Minuten und ohne Absturz des Servers.
Intels optionaler Cryptographic-Integrity-Modus begrenzt Teile des Angriffs, weil er Manipulationen zwischen unterschiedlichen Schlüsseldomänen erschwert. Nach Einschätzung der Forscher verhindert er aber nicht zwingend die Fälschung der Messung innerhalb der angreiferkontrollierten VM, da weiterhin eine Freshness-Prüfung fehlt. Bei AMD SEV-SNP war die demonstrierte Wirkung enger: Über die Seitenverschiebung ließ sich der Inhalt einer Opferseite in eine andere Seite kopieren. Die TDX-spezifischen Debug- und Attestation-Angriffe wurden dort nicht gezeigt.
Herstellerreaktionen und Grenzen der Aussage
Intel bestätigt die Veröffentlichung, stuft den beschriebenen physischen Angriff aber als außerhalb seines üblichen Bedrohungsmodells ein. Der Hersteller nennt vier Voraussetzungen: physischen Serverzugriff, Installation des Interposers, privilegierte Softwareausführung und damit keine Remote-Ausnutzbarkeit. Intel prüft nach eigenen Angaben zusätzliche Architekturhärtungen und Erkennungsmechanismen. Genannt werden auch künftige „Platform Owner Endorsements“, mit denen entfernte Parteien feststellen sollen, wer die Hardware physisch besitzt.
AMD bewertet den Angriff ebenfalls als außerhalb des veröffentlichten SEV-SNP-Bedrohungsmodells. Der Hersteller plant dafür weder CVE noch Gegenmaßnahmen. Das AMD-Bulletin nennt mehrere EPYC-4004-, 4005-, 8004-, 9004- und 9005-Serien sowie Instinct MI300A als betroffene Produktfamilien.
Diese Einordnung ist wichtig: DDRop belegt weder einen internetweiten Massenangriff noch einen rein softwarebasierten Ausbruch aus beliebigen Cloud-VMs. Ein Angreifer muss Rack-Zugang und hohe Systemrechte zusammenbringen. Auch Arm CCA wurde nicht getestet. Die veröffentlichten Ergebnisse sind daher vor allem für sehr hohe Schutzbedarfe, nicht für jeden Standardserver, unmittelbar entscheidungsrelevant.
Was Unternehmen jetzt praktisch prüfen sollten
Eine kurzfristige Softwareaktualisierung kann die fehlende Hardware-Freshness nicht nachrüsten. Betreiber und Kunden sollten deshalb nicht nur nach dem TEE-Label fragen, sondern das konkrete Bedrohungsmodell dokumentieren:
- Schutzziel klären: Soll die Confidential VM nur vor anderen Mandanten und einem kompromittierten Hypervisor schützen, oder ausdrücklich auch vor Rechenzentrumsinsidern, Lieferkettenmanipulation und staatlich erzwungenem Hardwarezugriff?
- Physische Kontrollkette prüfen: Zutritte zu Racks, Wartungseinsätze, Hardwaretransport und Austausch von Speichermodulen sollten nachvollziehbar protokolliert und möglichst durch Vier-Augen-Prozesse abgesichert sein.
- Attestation nicht allein entscheiden lassen: Die Freigabe langlebiger Master-Keys oder besonders sensibler Daten sollte nicht ausschließlich an eine einmalige Plattformmessung gekoppelt sein. Zusätzliche Identitäts-, Zeit-, Standort- und Laufzeitsignale begrenzen den Schaden einer falschen Attestation.
- Host-Rechte minimieren: DDRop benötigt privilegierte Softwarekontrolle. Härtung von Hypervisor, Management Plane, Firmwarezugriff und Administrationsidentitäten bleibt daher eine wirksame zweite Barriere.
- Anbieter konkret befragen: Cloud- und Colocation-Verträge sollten benennen, welche CPU-Generation, welcher TDX-Integritätsmodus und welche physischen Anti-Tamper- sowie Lieferkettenkontrollen tatsächlich verwendet werden.
- Kompensierende Kryptografie behalten: Anwendungsseitige Verschlüsselung, kurze Schlüsselgültigkeiten und getrennte Freigabedienste bleiben sinnvoll. Confidential Computing ersetzt kein vollständiges Schlüssel- und Datenzugriffsmodell.
Fazit
DDRop „bricht“ nicht pauschal jede Cloud-Verschlüsselung. Die Forschung zeigt präziser, dass Verschlüsselung ohne Freshness keine vollständige Integritätsgarantie liefert. Alte verschlüsselte Daten können gültig aussehen, obwohl ein neuer Schreibvorgang nie angekommen ist. Bei Intel TDX kann das bis zum Auslesen geschützter VM-Inhalte und zur Manipulation von Attestation reichen.
Für Unternehmen ist die wichtigste Konsequenz architektonisch: Confidential Computing ist eine starke zusätzliche Schutzschicht, aber kein Ersatz für physische Sicherheit, Lieferkettenkontrolle, minimierte Host-Rechte und mehrstufige Schlüsselfreigabe. Wer TEEs für besonders sensible KI- oder Cloud-Workloads nutzt, sollte jetzt prüfen, ob sein tatsächliches Bedrohungsmodell weiter reicht als das der Hardwarehersteller.
