RAM-Verschlüsselung in AMD Epyc nicht sicher prüfbar

Verschlüsselter Hauptspeicher soll virtuelle Cloud-Maschinen abschotten, doch Schwächen bei der kryptografischen Schlüsselkette unterminieren das Konzept.

In Pocket speichern vorlesen Druckansicht 19 Kommentare lesen
RAM-Verschlüsselung in AMD Epyc nicht sicher prüfbar

Server mit zwei AMD Epyc

(Bild: c't)

Lesezeit: 3 Min.

Sowohl AMD als auch Intel verkaufen Serverprozessoren mit RAM-Verschlüsselung (Memory Encryption). Letztere soll sensible Daten in virtuellen Maschinen auf Cloud-Servern schützen. AMD Secure Encrypted Virtualization (SEV) und Intels Software Guard Extensions (SGX) zielen darauf ab, Cloud-Server sicher nutzen zu können, ohne dem jeweiligen Rechenzentrum und dessen Administratoren vollständig vertrauen zu müssen. Stattdessen muss man jedoch den kryptografischen Zertifikaten von AMD (SEV) oder Intel (SGX) vertrauen beziehungsweise der sicheren Implementierung der jeweiligen Schutzfunktionen.

Mittlerweile haben Experten jedoch mehrere Schwachstellen und Sicherheitslücken sowohl bei AMD SEV als auch bei Intel SGX gefunden. So ist etwa SGX nicht gegen Seitenkanalangriffe wie Spectre, L1TF und MDS/RIDL/Zombieload gefeit und es gibt auch grundlegende Kritik am Konzept. Bei künftigen Xeons will Intel neue Verfahren zur RAM-Verschlüsselung einführen wie Total Memory Encryption (TME) und Multi-Key Total Memory Encryption (MKTME).

Bei AMD SEV verschlüsselt der Speicher-Controller der Epyc-Prozessoren den RAM-Bereich für jede laufende VM mit einem separaten Schlüssel. Dabei spielt der im Prozessor eingebaute AMD Secure Processor (AMD-SP) alias Platform Security Processor (PSP) eine wichtige Rolle. Denn der PSP verwaltet und schützt die Schlüssel, die der Speicher-Controller verwendet. Außerdem stellt der PSP Funktionen bereit, mit denen der Nutzer einer Cloud-VM nachprüfen kann, dass das RAM seiner VM tatsächlich per SEV verschlüsselt ist (Remote Attestation).

Nach dem Start einer verschlüsselten VM erzeugt der PSP einen Hash-Wert über die Konfiguration der VM und deren initialen Speicherinhalt; diesen Hash kann der VM-Nutzer mit einem lokal erstellten Hash vergleichen, um sicherzustellen, dass die Konfiguration stimmt. Allerdings muss der Hash über eine sichere Verbindung übertragen werden, die eine Schlüsselkette schützen soll.

Zur "Remote Attestation" der RAM-Verschlüsselung von AMD-Epyc-Prozessoren sind sichere kryptografische Signaturen nötig.

(Bild: Robert Buhren, TU Berlin)

In dieser Vertrauenskette spielt der von AMD signierte Chip Endorsement Key (CEK) eine Rolle. Sicherheitsforscher zeigen jedoch, dass sich bei der ersten Epyc-Generation (Naples) der CEK über eine manipulierte PSP-Firmware auslesen lässt.

Das hebelt die gesamte Vertrauenskette aus, weil ein böswilliger Mitarbeiter eines Cloud-Dienstleisters damit kryptografische Signaturen fälschen kann. Außerdem lässt sich der erbeutete CEK dazu nutzen, um die Daten einer VM bei der Migration auf einen anderen Epyc-Server zu entschlüsseln.

Zudem hat die PSP keinen Schutz gegen das Einspielen einer älteren Firmware mit Sicherheitslücken (Rollback Protection). Daher lassen sich Epyc-Server auch mit dem PSP-Patch aus dem Juni 2019 nicht gegen das Auslesen des CEK schützen.

Das Team um Robert Buhren von der TU Berlin macht in seinem Paper Vorschläge, wie sich die Schlüsselkette für Remote Attestation bei AMD SEV schützen lässt. Nach dieser Einschätzung reicht dazu aber kein Firmware-Update aus. Bei GitHub steht ein Proof-of-Concept (PoC) für die "Migration Attack" bereit.

Die transparente RAM-Verschlüsselung schottet zwar die RAM-Bereiche parallel laufender VMs voneinander ab. Doch I/O-Zugriffe etwa auf Massenspeicher oder PCIe-Netzwerkkarten müssen unverschlüsselt erfolgen, weil solche I/O-Komponenten die Daten nicht entschlüsseln könnten. Daher entschlüsselt die in den Epycs integrierte IOMMU diese I/O-Daten.

Auch bei I/O-Datentransfers in eine SEV-Enklave lauern Sicherheitsrisiken: Sicherheitsforscher beschreiben Angriffsmöglichkeiten, die sie ausnutzen.

Siehe zu AMD SEV auch:

(ciw)