Confidential Computing
Rechenzentren vor Cyberangriffen schützen
Confidential Compute (CC) verspricht eine Antwort auf die wachsende Bedrohungslage. CC ist eine neue, lang herbeigesehnte Technologie, die bislang aber nur bei den Hyperscalern Azure, AWS und Google zum Schutz ihrer Infrastruktur Verwendung findet, in virtuellen Maschinen (VMs) wie auch in Container-basierten Kubernetes-Umgebungen. Sie ermöglicht erstmals das Ausführen der Container- oder VM-Umgebungen in verschlüsselter Form.
Confidential Compute bedeutet: Zu jedem Zeitpunkt des Betriebs ist der Container oder die VM verschlüsselt. Wann immer Daten gespeichert und Programme ausgeführt werden, erfolgt dies dank der Laufzeitverschlüsselung kryptografisch isoliert vom Rest des Systems. Einzig die CPU ist imstande, die verschlüsselte Umgebung zu entschlüsseln, die Programminstruktionen auszuführen und das Ergebnis wieder verschlüsselt im Speicher abzulegen.
AMD und Intel haben still und leise existierende CPUs um Sicherheitsfunktionen erweitert, die solche Operationen performant implementieren. Die Intel-Technik basiert auf SGX/TDX (Software Guard Extensions/SGX plus Trusted Platform Module, kurz TPM), diejenige von AMD auf SEV (Secure Encrypted Virtualization), zu finden in Intels Skylake-Serie und AMDs Epyc-Reihen.
Für Datacenter ergeben sich dadurch vollkommen neuartige Sicherheitsmodelle: Ein Confidential Environment läuft isoliert vom Rest des Systems, der Software-Stack spielt dabei keine Rolle. Auch wenn das Betriebssystem mit BIOS und Treibern und/oder der Hypervisor kompromittiert sind, bleibt die Applikation nach außen hin eine Blackbox. Einzig die CPU ist befähigt, die Applikation in der Umgebung auszuführen. Manipulationen am Environment hingegen lassen sich mittels Attestierung und Environment-Signierung aufdecken.
Dies macht wichtige Techniken, die bei Cyberangriffen zum Einsatz kommen, wirkungslos, darunter Container Escapes, Hypervisor Exploits, Kernel Exploits und Root-Kits. Aber auch physische Attacken durch Zugriff auf die Hardware lassen sich ausschließen: eine Offline-DRAM-Analyse (zum Beispiel Cold Boot), DDR-Bus-Manipulation, TCB (Trusted Computing Base) Rollbacks (etwa CPU-Firmware-Austausch), Malicious Interrupts oder auch Malicious DMA (Direct Memory Access) – und ebenso Social-Engineering-Angriffe durch korrumpierte Beschäftigte.
Die Begründung ist einfach: Alle aufgeführten Angriffstechniken haben gemein, dass sie über die gewonnenen höheren Privilegien auf die Applikationen und damit den Speicherbereich der Applikationen lesend und schreibend zugreifen. Bislang hat der Zugriff auf den Speicherbereich dazu geführt, dass Angreifer die Programmausführung manipulieren und sensible Daten wie Admin-Passwörter auslesen konnten.
Ist die Applikation in einem Confidential Environment, ist ein Auslesen und Manipulieren des Speicherbereichs prinzipiell noch immer möglich, doch führt es nicht zum gewohnten Ergebnis: Ein Auslesen des Speichers liefert nur verschlüsselte Mikroinstruktionen der Applikation. Ohne den entsprechenden Dechiffrierungsschlüssel, der durch die TPM-ähnlichen Eigenschaft der CPU geschützt ist, müsste der Angreifer erst noch das AES-Verfahren brechen. Ein Manipulieren des Speichers fällt durch die zusätzliche Integritätskontrolle des AES-Verfahrens auf. Bei einer Schlüssellänge von 128 Bit kann man nach heutigen Stand davon ausgehen, dass es schwierig ist, das AES-Verfahren zu brechen.
Confidential Compute im Detail
Ein Confidential Environment unterscheidet sich von einer normalen Umgebung durch die verschlüsselte und authentifizierte Ausführung: Applikationen starten in einer sogenannten Enklave. Dafür reserviert die CPU vor dem Bootprozess einen Bereich des physischen Speichers. Dies ist ein Prozess, den das Host-Betriebssystem in den Bereich lädt, und den die CPU mittels AES verschlüsselt. Ein Schlüssel-Management für die Enklave ist weder notwendig noch gewünscht: Nur die CPU kennt den Schlüssel, der von einem eindeutigen Hardwareschlüssel abgeleitet und nach jedem Bootvorgang frisch generiert wird. Die Möglichkeit, den Schlüssel per Software auszulesen, beispielsweise über die Firmware-API, ist im Design bewusst ausgeschlossen.
Die CPU fungiert hier erstmalig wie ein HSM (Hardware-Security-Modul): Nur die CPU, genauer die ALU (Arithmetic Logic Unit) benötigt die Mikroinstruktionen in unverschlüsselter Form. Die MMU (Memory Management Unit), welche die verschlüsselten Instruktionen vom DRAM abruft, ist um eine AES-Logik erweitert. Sie entschlüsselt die Speicherbereiche, bevor diese die ALU erreichen. Analog verschlüsselt die AES-Logik die Ergebnisse der ALU erst, wenn sie in den physischen Speicher geschrieben werden. Sowohl ALU, MMU und HSM sind Bestandteil der CPU und fest im Silizium miteinander verankert (Trust Anchor). Zudem hat die hardwarenahe Implementierung der AES-Logik den Vorteil, dass de Ver- und Entschlüsselung keine Leistungseinbußen hervorrufen, denn sie erfolgen direkt im „Kern“ der CPU.
Eine weitere CC-Neuerung ist die Möglichkeit, das Environment zu authentifizieren. Der Autor des Environments signiert das Image. Damit haben Environments nicht nur eine eindeutige kryptografische Identität, sondern lassen sich einfach standardisieren und zertifizieren. So ist es beispielsweise vorstellbar, dass unabhängige Zertifizierungsstellen Referenz-Images bereitstellen, die das Erfüllen von Compliance-Anforderungen vereinfachen. Referenz-Images können Docker- oder VM-Images sein, die hinsichtlich Sicherheitsschwachstellen untersucht sind, oder die aufgrund der Art, wie sie persönliche Daten verarbeiten und speichern, den Regularien entsprechen. Damit sind sie insbesondere für den Einsatz im Gesundheits- und Finanzwesen oder dem Öffentlichen Dienst geeignet.
- Rechenzentren vor Cyberangriffen schützen
- Remote Attestation und Secret Provisioning
Lesen Sie mehr zum Thema
