RAM-Schranke
RAM-Verschlüsselung bei AMD und Intel
AMD-Epyc-Prozessoren für Server können RAM verschlüsseln, um Sicherheitsrisiken zu vermeiden. Intel will mit einer ähnlichen Technik nachziehen und stellt mit den Software Guard Extensions (SGX) schon jetzt verschlüsselte RAM-Enklaven bereit: ein Überblick.
Die jüngsten Serverprozessoren von AMD und Intel haben neuartige Funktionen, um Daten vor starken Angreifern zu schützen: Sie verschlüsseln den Arbeitsspeicher teilweise oder ganz. Nicht einmal Administratoren mit physischem Zugriff auf einen Server sollen sensible Daten lesen können, die in einer virtuellen Maschine laufen. Die neuen CPU-Funktionen SME, SEV, SGX, TME und MKTME (siehe Tabelle rechts) helfen außerdem, Schäden durch Software-Angriffe zu begrenzen: Selbst wenn ein System bereits von Malware befallen ist, sollen vertrauenswürdige Operationen weiter möglich sein, nämlich in verschlüsselten Enklaven. Damit geht RAM-Verschlüsselung deutlich über bisherige Schutzmaßnahmen hinaus. Zu Letzteren gehört beispielsweise die Adressraumisolation, deren Mängel die Seitenkanalangriffe Meltdown und Spectre drastisch aufgezeigt haben.
Physische Attacken
Physische Angriffe setzen lokalen Zugriff auf einen Computer durch einen Angreifer vor Ort voraus. Ein einfaches Beispiel ist das Auslesen einer unverschlüsselten Festplatte. In kritischen Umgebungen sind Festplatten deshalb verschlüsselt; außer einer Kopie der Festplattendaten braucht ein Angreifer dann noch den Schlüssel. An den wiederum kommt er aber nur heran, wenn das Zielsystem läuft und der Schlüssel als Klartext im Hauptspeicher liegt.
Vor zehn Jahren zeigte der sogenannte Cold-Boot-Angriff, wie man einen solchen Schlüssel ergattert: Wird die Energieversorgung des Hauptspeichers (RAM) unterbrochen, verschwindet dessen Inhalt nicht sofort; die Speicherzellen fallen vielmehr erst innerhalb von einigen Sekunden bis Minuten wieder in ihren Ausgangszustand zurück. Dieser Effekt lässt sich durch Kühlung des Hauptspeichers mit Kältespray deutlich verlängern. Erhält ein Angreifer also Zugriff auf ein laufendes System, so kann er unter Umständen kritische Inhalte aus dem Arbeitsspeicher extrahieren – etwa indem er nach einem Kaltstart ein minimales Spezial-Betriebssystem startet, das den RAM-Inhalt auf einen USB-Datenträger kopiert.
Es gibt aber auch noch andere Möglichkeiten, den Inhalt von DRAM-Chips auszulesen, etwa über gehackte PCI-Express-Karten oder Thunderbolt-Peripherie mit DMA (Direct Memory Access). Schließlich kommen nichtflüchtige Speichermodule zum Einsatz, etwa NVDIMMs mit Flash-„Fallschirm“ gegen Stromausfälle und die kommenden 3D-XPoint-Speichermodule von Intel. Solches „persistent Memory“ lässt sich in einem zweiten System physisch auslesen, selbst wenn das eigentliche Zielsystem nicht (mehr) läuft. In allen diesen Fällen verstärkt RAM-Verschlüsselung den Datenschutz.
Attacken von innen
Die neuen Hardware-Erweiterungen, vor allem Intel SGX, sollen aber auch gegen potenziell bösartige Prozesse mit hohen Privilegien (Zugriffsrechten) und sogar gegen ein kompromittiertes Betriebssystem schützen. Zwei Anwendungszwecke liegen auf der Hand. So lässt sich SGX für Digital Rights Management (DRM) verwenden, also um bestimmte Software oder Daten vor dem Benutzer zu verbergen. Der zweite Einsatzfall betrifft angemietete Cloud-Dienste, beispielsweise eine virtuelle Maschine (VM) in einem fremden Rechenzentrum, die sensible Daten oder geheimgehaltenen Programmcode verarbeitet.
Für DRM wird SGX bereits genutzt, etwa von Netflix beim Streaming von Ultra-HD-Filmen und von Cyberlink bei PowerDVD Ultra: Dieser Software-Decoder spielt auch kopiergeschützte Inhalte von Ultra-HD Blu-ray ab. Der geheime Schlüssel für das Videomaterial wird dabei nur in einer verschlüsselten SGX-Enklave verwendet, die weder das Betriebssystem noch laufende Programme auslesen können. Der dekodierte Videodatenstrom wird dann mit anderen Methoden wie Protected Audio-Video Path (PAVP) und High Definition Content Protection (HDCP) geschützt zum Display übertragen. Deshalb lässt er sich nicht abgreifen, umleiten oder auf der Festplatte speichern.
Beim Cloud-Datenschutz mit AMD SEV und Intel SGX liegt der Fall etwas anders. Hier geht es darum, das Vertrauen sozusagen zu verlagern. Denn bei den typischen Cloud-Dienstleistern wie Amazon AWS, Google Cloud oder Microsoft Azure haben die jeweiligen Administratoren im Prinzip die Möglichkeit, sämtliche Daten aus dem Server-RAM zu lesen. Ist dieser Arbeitsspeicher jedoch mit Hardware-Funktionen des Prozessors verschlüsselt, dann kann ein Cloud-Anbieter glaubhaft versichern, Nutzerdaten und Programmcode weder manipulieren noch auslesen zu können. Ein Kunde des Dienstleisters muss diesem dann nicht mehr vertrauen – aber sehr wohl den CPU-Funktionen und der Schlüsselgewalt von AMD oder Intel.
Bisherige Schutzmaßnahmen
Bisher gab es keine Hardwareerweiterungen für Standardprozessoren, die gegen physische oder höher privilegierte Angreifer schützen. Mit AES-NI stellen Prozessoren von AMD und Intel seit geraumer Zeit lediglich Befehle für die Implementierung von Verschlüsselungsverfahren bereit, die aber vor allem zur Beschleunigung von AES-Algorithmen dienen. Dazu kommt das Trusted Platform Module (TPM), eine Art aufgelötete SmartCard als Vertrauensanker. Das TPM bietet im Wesentlichen drei Grundoperationen: Binding, Sealing und Remote Attestation. Binding erlaubt es, Code oder Daten so zu verschlüsseln, dass sie sich nur auf demselben Gerät wieder entschlüsseln lassen. Sealing funktioniert ähnlich wie Binding, bezieht zusätzlich aber noch die aktuelle Plattform-Konfiguration mit ein, etwa die BIOS-Einstellungen, das laufende Betriebssystem und aktuell laufende Software. Nur wenn diese Faktoren im selben Zustand sind wie bei der Versiegelung, lassen sich Daten wieder entsiegeln. Remote Attestation schließlich erlaubt es einer entfernten Partei, beispielsweise einem Software-Hersteller, die aktuelle Plattformkonfiguration zu überprüfen. Der Hersteller liefert Code oder Daten nur dann aus oder gibt sie frei, wenn sich das System in einem von ihm gewollten Zustand befindet. Remote Attestation lässt sich etwa auch verwenden, um nur solchen Notebooks den VPN-Zugriff auf das interne Netzwerk einer Firma zu gewähren, auf denen bestimmte (Virenschutz-)Software installiert ist.
Zu den bekannten Einsatzbereichen von TPMs gehört der Schutz des Bootvorgangs vor Manipulationen (Measured Launch). Dabei legt das TPM Hash-Werte der Firmware und des Bootloaders in seinen geschützten Speicherbereichen ab, den Platform Configuration Registers. Außerdem kann die Windows-Festplattenverschlüsselung BitLocker ein TPM für das Sealing des Schlüssels nutzen: Die Daten auf der Platte oder SSD lassen sich dann nicht mehr entschlüsseln, wenn man den Datenträger vom Mainboard trennt.
Ein großer Nachteil des TPM ist allerdings, dass sämtliche Operationen auf einem einzigen, unveränderlichen Vertrauensanker aufbauen. Zudem müsste man für eine Messung der Vertrauenswürdigkeit per TPM die gesamte Konfiguration eines Systems betrachten, nämlich über den oben beschriebenen Measured Launch hinaus auch Hashes für sämtliche Komponenten des Betriebssystems, für alle Treiber und jede geladene Software speichern. Damit ist das TPM weder für DRM noch für das Szenario eines nicht vertrauenswürdigen Cloud-Providers geeignet, da entweder der Hersteller oder der Kunde den ganzen Softwarestack kontrollieren müssten. Gegen physische Angriffe auf den Hauptspeicher kann das TPM auch nicht schützen, da zumindest laufende Software oder gerade verwendete Daten im Klartext im Speicher liegen.
Mit Trusted Execution Technology (TXT) hat Intel einige Zusatzfunktionen in Prozessoren eingebaut, mit deren Hilfe das TPM kleine Code-Abschnitte schützen kann. Doch auch TXT kommt eher selten zum Einsatz, unter anderem weil für den Wechsel zur vertrauenswürdigen TXT-Software im Prinzip ein CPU-Reset nötig ist, was sich auf die Performance auswirkt.
Einen anderen Ansatz hat der CPU-Entwickler ARM gewählt, um sensible Daten auf Mobilgeräten wie Smartphones zu schützen: ARM TrustZone teilt das System in zwei Welten, die „Secure World“ und die „Non-Secure World“. Sie sind strikt voneinander getrennt, selbst höher privilegierte Software innerhalb der Non-Secure World einschließlich des Betriebssystems kann nicht auf Code und Daten in der Secure World zugreifen. Die Verbindung beider Welten findet über einen sogenannten Monitor-Call statt, der ähnlich wie ein Systemaufruf in das Betriebssystem zu verstehen ist. Die strikte Trennung bei ARM TrustZone geht über eine reine Softwaretrennung hinaus: Ein „Secure Bit“ auf dem internen Bus des Chips sorgt dafür, dass bestimmte Baugruppen und Zusatzchips nur aus der Secure World heraus erreichbar sind. Damit lassen sich beispielsweise Fingerabdruckleser sicher anbinden, um den gesamten Prozess der Authentifizierung im sicheren Bereich abzuwickeln.
TrustZone ist bei allen seit 2014 neu vorgestellten AMD-Prozessoren integriert, und zwar in Form eines eingebetteten ARM-Cortex-A5-Kerns mit TrustZone. Darauf läuft ein kleines System, das beispielsweise TPM-Funktionen bereitstellt (Firmware-TPM 2.0, fTPM 2.0). AMD spricht vom Platform Security Processor (PSP) beziehungsweise vom Secure Processor. Samsung verwendet TrustZone bei seinen Android-Smartphones für die Sicherheitsfunktion Samsung Knox.
Abseits von solchen Ansätzen, die TrustZone mit proprietärer Software nutzen, kommt TrustZone selten zum Einsatz. Einerseits steht kein einfaches SDK zur Verfügung, andererseits funktioniert TrustZone je nach konkreter Umsetzung im jeweiligen ARM-SoC etwas anders. Schließlich gibt es auch keine Möglichkeit, mehrere Secure Worlds parallel zu verwenden; stattdessen ist ein kleines Spezial-Betriebssystem nötig, welches mehrere sichere Anwendungen verwaltet. Das wiederum steigert aber die Komplexität des Codes und somit die Anzahl der Angriffsmöglichkeiten. Schließlich kann TrustZone auch den Hauptspeicher nicht verschlüsseln, schützt also nicht vor physischen Attacken.
Intel SGX
Intel-Prozessoren ab der Generation Skylake (Core i-6000, Xeon Scalable Processor) haben die Funktion Software Guard Extensions (SGX), die man bei manchen Systemen im BIOS-Setup einschalten muss. SGX erlaubt es, Vertrauensanker dynamisch einzurichten. Außerdem gibt es nicht nur eine sichere Welt wie beim TPM und bei TrustZone, sondern viele sogenannte sichere Enklaven. Letztere lassen sich im normalen Adressraum eines Prozesses einrichten und sind trotzdem durch Hardware-Mechanismen vor höher privilegierter Software geschützt. Code in der SGX-Enklave läuft zudem mit hoher Performance. Das zur Verschlüsselung verwendete Geheimnis erzeugt der Prozessor bei jedem Systemstart automatisch neu. Es verlässt den Prozessor nie, ist also auch nicht auslesbar. Jeder SGX-taugliche Prozessor enthält zwei „eingebrannte“ (fused), individuelle und zufällige 128-Bit-Schlüssel. Anhand des Root Provisioning Key, den Intel in einer Datenbank aufbewahrt, lässt sich nachweisen, dass der Prozessor tatsächlich existiert. Und vom Root Seal Key, den Intel nicht speichert, kann eine SGX-Enklave Sealing-Schlüssel ableiten, um verschlüsselte Daten außerhalb der Enklave zu schützen.
Eine SGX-Applikation besteht in der Regel aus einem ungeschützten Teil und einem in der Enklave laufenden, geschützten Teil. Bevor Software eine einzige Enklave nutzen kann, muss sie diese erstellen. Alle dazu nötigen Operationen sind privilegiert und lassen sich deshalb nur im Kernelmodus (Ring 0) verwenden. Folglich ist außer einer SGX-fähigen CPU auch ein spezieller Treiber vonnöten, den es ab Windows 10 und als Linux-Kernelmodul gibt.
Um eine Enklave zu nutzen, baut die zugehörige Applikation zuerst das Layout der Enklave mit nicht vertrauenswürdigem Code zusammen. Anschließend kommuniziert die Applikation mit dem Treiber, um die Enklave zu „messen“: Dabei werden das Speicher-Layout und der Inhalt gehasht und der Speicherschutz eingeschaltet.
Danach haben weder die Applikation noch höher privilegierte Software die Möglichkeit, in die Enklave hineinzusehen, also Daten zu lesen. Um mit dem Code in der Enklave zu kommunizieren, muss die Applikation ein spezielles Interface nutzen, weil bei jedem Wechsel zwischen regulärem Code und Enklavencode eine Art Kontextwechsel stattfindet. Ähnlich wie bei einem Systemaufruf sichert der Prozessor dabei Register- und Stackinhalte, damit keine geschützten Daten aus der Enklave in die Applikation entwischen. Eine typische Enklave stellt einen Satz an Funktionen bereit, die Parameter von der Applikation in die Enklave übertragen und Werte zurückgeben.
Theoretisch lassen sich beliebige Funktionen innerhalb einer SGX-Enklave implementieren. Praktisch ist die Programmierumgebung einer Enklave allerdings stark eingeschränkt. So sind zum Beispiel Systemaufrufe innerhalb einer Enklave verboten, diese muss der ungeschützte Teil der Applikation erledigen. Auch ist die Größe einer Enklave statisch begrenzt, bei bisherigen Prozessoren auf maximal 128 MByte; manches BIOS-Setup erlaubt es, das noch weiter zu reduzieren. Wegen dieser Restriktionen lässt sich vorhandener Code üblicherweise nicht einfach in Enklaven portieren, sondern die jeweilige Funktion muss stattdessen speziell für SGX geschrieben werden.
Wurde die Enklave einmal gestartet, ist sie vor fremden Zugriffen geschützt – also auch vor dem prüfenden Blick eines Virenscanners. Um zu verhindern, dass sich Schadsoftware per SGX im System festsetzt, sollte eine entfernte vertrauenswürdige Partei das Layout einer Enklave nach der Initialisierung überprüfen. Dies ist durch entfernte Attestierung (Remote Attestation) mithilfe eines kryptografischen Messwerts möglich, den die Hardware beim Initialisieren erzeugt. Derzeit ist dazu der Zugriff auf einen Attestation-Server von Intel nötig. Das klappt zwar nach kostenloser Registrierung, setzt aber Vertrauen in Intel voraus.
Wer SGX-Code schreibt, muss ihn mit einem von Intel zertifizierten Entwicklerschlüssel signieren, damit der Prozessor den Code ausführt – außer im Debugging-Modus. Intel stellt hier hohe Anforderungen an Firmen, die beispielsweise einige Maßnahmen zum Schutz ihrer geheimen Schlüssel nachweisen müssen, etwa durch ein Hardware Security Module (HSM). Das schränkt den Kreis der potenziellen SGX-Programmierer ein. Außerdem bestimmt Intel auch mit, welche Software überhaupt laufen darf. Zudem wurden Spectre-Angriffe auch auf SGX-Enklaven bekannt. Weil schließlich das Betriebssystem immer noch zentrale Elemente wie das Layout der Page-Tabellen oder das Scheduling steuert, kann es indirekt viel über das Verhalten von Enklaven lernen – auch hier gibt es Angriffsmöglichkeiten.
AMD SME und SEV
Wohl auch in Kenntnis der praktischen Probleme von Intel SGX geht AMD einen anderen Weg bei der RAM-Abschottung und konzentriert sich auf wenige Anwendungsszenarien. Secure Memory Encryption (SME) ist auf Business-PCs und Notebooks mit AMD Ryzen Pro verfügbar und schützt vor physischen Angriffen wie der Cold-Boot-Attacke. Secure Encrypted Virtualization (SEV) beim Serverprozessor AMD Epyc zielt auf nicht vertrauenswürdige Cloud-Provider, die sensible Kundendaten aus dem Server-RAM auslesen könnten.
SME verschlüsselt den gesamten Hauptspeicher mit einem einzigen Schlüssel transparent in Hardware (AES-128). Dies hat den Vorteil, dass weder das Betriebssystem noch ein eventuell verwendeter Hypervisor angepasst werden müssen. Allerdings sind Maßnahmen für DMA-fähige Geräte nötig: Entweder Treiber, die Zugriffe auf verschlüsselte I/O-Adressen markieren, indem sie das Crypto- oder C-Bit (Bit 47) im jeweiligen Page Table Entry (PTE) setzen. Oder die I/O Memory Management Unit (IOMMU) erledigt das, etwa für 32-Bit-Geräte.
Bei SME entschlüsselt der Prozessor für laufende Anwendungen das RAM transparent – also auch für einen Software-Angreifer. Somit schützt SME nicht gegen Malware auf dem System oder vor Zugriffen des Betriebssystems. SEV hingegen arbeitet mit mehreren Schlüsseln, je einem für einen bestimmten Speicherbereich. Mit SEV lassen sich folglich mehrere parallel laufende virtuelle Maschinen (VMs) voneinander abschotten. Selbst wenn Malware aus einer VM ausbricht und das RAM einer anderen VM liest, sieht sie also nur verschlüsselte Daten.
SEV kann beliebig große Speicherbereiche einrichten. Der Hypervisor setzt dazu pro VM einen Schlüssel (ASID), mit dem die CPU alle RAM-Pages verschlüsselt, die zur selben VM gehören. Die Schlüssel verwaltet der erwähnte AMD Secure Processor (PSP) auf Basis von ARM TrustZone.
Obwohl der Hypervisor viele VM-Funktionen steuert, darunter Geräteemulation und Scheduling, muss man ihm nicht mehr vollständig vertrauen. Würde ein manipulierter Hypervisor falsche Schlüssel setzen, obwohl die VM vorher mit einem anderen Schlüssel gestartet wurde, würden bei der Entschlüsselung fehlerhafte Daten gelesen – und die Daten in der VM blieben geschützt. Um einer entfernten Partei zu garantieren, dass die VM beim ersten Start nicht fehlerhaft zusammengesetzt wurde, verlässt sich auch AMD auf einen Attestierungsmechanismus. Hier muss man also AMD vertrauen – analog zu Intel SGX.
Intel TME und MKTME
Wiederum als Antwort auf SME und SEV sowie wohl auch wegen der praktischen Einschränkungen von SGX plant Intel zwei neue Funktionen, allerdings erst für künftige Prozessoren – welche, wurde noch nicht verraten. Intel Total Memory Encryption (TME) und Multi-Key Total Memory Encryption (MKTME) ähneln jedenfalls im Wesentlichen AMD SME und SEV.
TME nutzt einen in der Regel beim Systemstart generierten 128-Bit-Schlüssel, um den gesamten Speicher zu verschlüsseln, und zwar per AES-XTS. Analog zu SME hilft TME also nur gegen physische Angriffe, nicht aber gegen Software-Angriffe. Speziell für NVRAMs plant Intel auch die Unterstützung von nichtflüchtigen Schlüsseln. Wie bei SME verbleiben Daten in Caches sowie auch alle Daten innerhalb des Prozessors im Klartext.
MKTME ermöglicht die Verwaltung verschiedener Geheimnisse – etwa durch einen Hypervisor – zur Verschlüsselung einzelner RAM-Pages. Im Unterschied zu AMD SEV lässt MKTME jedoch den Hypervisor nicht einfach Schlüssel setzen, sondern schreibt nur eine Key ID in die Page-Tabelle. Somit ist je nach Anzahl der Bits, die für die Key ID reserviert werden, nur eine beschränkte Anzahl an Schlüsseln und damit gleichzeitig gegeneinander geschützter VMs möglich. In der aktuellen Skizze plant Intel, dafür sechs Bits zu nutzen, das reicht für 64 VMs.
Bisher sind noch wenige Details über TME und MKTME bekannt, die aktuelle Spezifikation kann sich auch noch ändern. Anscheinend will Intel – anders als AMD bei SEV – jedoch wohl keine zusätzlichen Möglichkeiten für entfernte Attestierung einführen. Somit ermöglicht MKTME alleine nur eine sichere Abschottung, aber keine Garantie für die korrekte Funktion einer VM auf der Hardware eines nicht vertrauenswürdigen Cloud-Providers. Deshalb wiederum ist zu vermuten, dass TME und MKTME in zukünftigen CPUs zusammen mit SGX angeboten wird, also beide Hardwareerweiterungen gemeinsam verfügbar sein werden.
Systemvergleich
Die neuen Krypto-Funktionen fürs RAM versprechen höhere Sicherheit. Doch sie lassen sich nicht „mal eben schnell“ einsetzen. SGX braucht eine Registrierung bei Intel sowie spezifischen Code, der erheblichen Einschränkungen unterworfen ist – maximal 128 MByte, keine Systemaufrufe. Das schränkt die Einsatzmöglichkeiten stark ein.
Auch wenn Intel SGX für das Szenario eines nicht vertrauenswürdigen Cloud-Provider beworben hat, passt AMD SEV für dieses Szenario besser. Mit SEV lässt sich bestehender Code viel leichter weiternutzen, da nur der Hypervisor und der Kernel des Gastbetriebssystems angepasst sein müssen. Aktuelle Versionen von KVM unterstützen SEV bereits.
Allerdings widerspricht SEV dem klassischen Trusted-Computing-Konzept, bei dem man stets versucht, die Trusted Computing Base (TCB) innerhalb einer sicheren Umgebung so klein wie möglich zu halten, um die Angriffsfläche zu minimieren. Im Falle von SEV umfasst die TCB jedoch eine komplette VM. Außerdem muss man AMD vertrauen und es besteht kein Schutz gegen Malware, die bereits in eine VM eingedrungen ist.
Bei genauerem Hinsehen zeigt sich, dass der Weg zum breiten Einsatz von RAM-Verschlüsselung noch weit ist. AMD SEV und Intels TME/MKTME dürften vor allem für Cloud-Dienstleister interessant sein, die ihren Kunden höhere Sicherheit bieten wollen. Privatanwender werden mit RAM-Verschlüsselung zunächst kaum in Kontakt kommen – bis auf SGX als DRM-Funktion oder transparent durch SME/TME. (ciw@ct.de)
Dokumentation zum Thema: ct.de/yukc