Blickdichte Wolken
Confidential Computing mit verschlüsselten Cloud-Containern verhindert neugierige Blicke von Cloud-Anbietern und Dritten.
Gerade bei sicherheits- und datenschutzrechtlichen Anwendungen ist umstritten, ob einer öffentlichen Cloud zu trauen ist (vgl. Schrems-II, Privacy-Shield etc.) – das hindert noch immer viele Unternehmen, ihre IT dorthin zu migrieren. Confidential Container sollen jetzt eine Möglichkeit bieten, Applikationen in der Cloud innerhalb einer Black-Box auszuführen: Zu keinem Zeitpunkt sieht die Cloud, was im Container passiert. So ist erstmals eine ganzheitliche technische Lösung im Spiel, um Datenschutzanforderungen unabhängig vom Cloud-Betreiber zu erfüllen.
Die Bereitstellung elastischer Rechen- und Speicherkapazität in der Cloud hat den Einsatz von Software grundlegend verändert: Unternehmen können nun auf eine Infrastruktur aufbauen, ohne selbst für ihren Betrieb verantwortlich zu sein und kaufen nur die Kapazität ein, die tatsächlich gerade benötigt wird. Diese Flexibilität, gekoppelt mit einfacher Skalierbarkeit, spart Kosten – aber kann man „der Cloud“ auch vertrauen? Diese kritische Fragestellung ist weiterhin durchaus berechtigt und nicht nur moralischer oder philosophischer Natur – Datenschutz und Datensouveränität sind zwei wesentliche Aspekte jeglicher Cloud-Lösung, die in den letzten Jahren zu Recht kontrovers debattiert wurden.
Gerade bei den verbreiteten Angeboten von US-Unternehmen setzen die EU Datenschutzgrundverordnung (DSGVO/GDPR) sowie die Rechtsprechung des Europäischen Gerichtshofs (EuGH) dem Cloud-Einsatz deutliche Schranken – nicht zuletzt aufgrund des US Clarifying Lawful Overseas Use of Data (CLOUD) Act [1,2,3], der etwa dem FBI die Befugnis erteilt, auf gehostete Daten – auch von EU-Bürgern – zuzugreifen. Eine strenge Auslegung des sogenannten Schrems-II-Urteils des EuGH hat die Vergabekammer Baden-Württemberg im Juli 2022 vollzogen: Im konkreten Fall hatte sich ein in der EU ansässiges Tochterunternehmen eines US-Anbieters für Cloud-Dienstleistungen an einem Vergabeverfahren beteiligt. Obwohl sich die zur Leistungserbringung eingesetzten Server innerhalb der EU befanden, hat die Vergabekammer einen Verstoß gegen die Datenschutzgrundverordnung festgestellt [4].
Confidential Computing
Confidential (Cloud-) Computing liefert eine technische Lösung, um zwischen der Bereitstellung der Computing-Infrastruktur und dem eigentlichen Nutzen dieser Infrastruktur sicher zu trennen – und so eine Compliance mit den Regularien zu erzielen. Confidential-Computing-Container führen, vereinfacht gesprochen, Applikationen in einer Black-Box aus, sodass der Cloud-Anbieter nicht sehen kann, was der Container tut.
Neu ist an diesem Verfahren, dass nicht nur das Speichern (Data in Rest) und/oder der Transport (Data in Transit), sondern erstmalig auch die Verarbeitung von Daten zu jedem Zeitpunkt für den Infrastrukturbetreiber intransparent ist (Data in Use). Die Datenverarbeitung wird selbst vom Betriebssystem und den darauf laufenden Anwendungen isoliert. Auch während der Verarbeitung haben weder der (Cloud-) Dienstanbieter noch Administratoren Zugriff auf die Daten.
Entwicklungsschritte und alternative Konzepte
Technologie ist evolutionär, so auch Confidential Computing. Das Rechnen auf verschlüsselten Daten ist in der Kryptografie ein fundamentales Problem. Lösungsansätze sind die Fully Homomorphic Encryption (FHE, siehe etwa [5,6,7]) und Secure Multi-Party-Computation (MPC, siehe etwa [8,9,10]). Obwohl diese Methoden vielversprechend klingen und in den letzten Jahren Performancemance-Verbesserungen erzielt wurden, haben die damit verbundenen Lösungen (noch) eine erhebliche praktische Beschränkung: Eine Auswertung ist derzeit auf der Abstraktion einer Funktion möglich. Was man aber in der Praxis möchte, ist die effiziente Ausführung eines Turing-vollständigen Programms, das aus Schleifen, Sprüngen, Verzweigungen oder Nebenläufigkeit besteht. Es wird noch einiges an grundlegendem Forschungsaufwand notwendig sein, um existierende Kryptografie-Verfahren auf diese Abstraktionsebene zu heben.
Ein weiterer historischer Meilenstein war das Trusted Computing (siehe etwa https://trustedcomputinggroup.org), in dessen Architekturen ein kryptografischer Co-Prozessor, das Trusted-Computing-Module (TPM), die Funktionen der CPU um vertrauensbildende Maßnahmen sowie sicheren Speicher erweitert hat – die Implementierung kryptografischer Algorithmen sowie die Bereitstellung von (Seitenkanal-resistenten) Registern gehört ebenfalls zu dessen Aufgaben. Im Desktop-Bereich helfen TPMs beim Absichern des Bootprozesses oder der Festplattenverschlüsselung (z. B. bei Microsofts Bitlocker). Im Cloud-Bereich werden TPMs sowie Hardware-Security-Modules (HSMs) im Key-Management eingesetzt. Kritisch an diesem Ansatz sind – gerade im Server-Segment – die hohen Zusatzkosten zu sehen, aber auch die eingeschränkten kryptografischen Algorithmen.
Security-Erweiterungen in Prozessoren
Confidential-Computing versucht nun, das Beste aus beiden Ansätzen zu vereinen: Moderne Prozessoren wurden mittlerweile um eigene Sicherheitsfunktionen erweitert – und besitzen quasi ein TPM innerhalb der CPU. Diese Funktionalität ermöglicht es, Software in sogenannten Enklaven ablaufen zu lassen: Eine Enklave ist eine verschlüsselte Ausführungsumgebung mit der Eigenschaft, dass die CPU selbst zur Laufzeit die Mikroinstruktionen des „eingeschlossenen“ (enclaved) Programms entschlüsselt, ausführt und wieder verschlüsselt im Speicher ablegt. Der Schlüssel verlässt die CPU nicht – er kann nicht ausgelesen werden.
Eine weitere Funktion ist die Verifizierbarkeit einer Enklave: Über ein kryptografisches Protokoll lässt sich beweisen, dass ein bestimmtes Programm in einer Enklave auf einer dedizierten Plattform tatsächlich ausgeführt wurde. Das ist besonders im Confidential Cloud-Computing nützlich, um einen Nachweis aus der Ferne zu bekommen, dass die gewünschten Applikationen auch wirklich auf der zugewiesenen Cloud ausgeführt werden.
Um das Confidential-Computing-Paradigma praktisch umzusetzen, war die Verfügbarkeit der genann-ten Sicherheitsfunktionen notwendig. Intel nennt seine Erweiterung Security Guard Extension (SGX), bei AMD heißt die entsprechende Produktlinie Secure Encrypted Virtualization (SEV) – und ARM bereitet eine vergleichbare Plattform als Nachfolger seiner TrustZone vor.
Server-Plattformen unterstützen die Erweite-rungen seit der Einführung von Intels Skylake- beziehungsweise AMDs Epyc-Architektur. Ein weiterer Meilenstein war der Upstream der entsprechenden Treiber in den Linux-Kernel: Seit Mai 2021 (Kernel 5.11) unterstützt auch das freie Betriebssystem die Sicherheitserweiterungen, sodass Confidential-Computing-Applikationen seither serienmäßig entwickelt werden können.
Diese Entwicklungen haben Hyperscaler wie Azure, GCP oder AWS in ihr Angebot übernommen. Zum Redaktionsschluss im September 2022 boten diese Dienste erste VM-Konfigurationen an, wenn auch teil-weise noch im Review, welche die Hardware- und Software-Voraussetzung erfüllen, um Confidential-Computing-Applikationen ausführen zu können. Mit anderen Worten: Die notwendige Cloud-Infrastruktur wird jetzt erstmals bereitgestellt – nun bedarf es nur noch passender Software.
Abbildung 1: Confidential Container sind Programme und Daten, die in einem verschlüsselten Speicherbereich geladen werden, sodass Inhalt und Ausführung in verschlüsselter Form authentifizierbar und verifizierbar sind.
Confidential Cloud-Container
Container-Verfahren sind aus dem Cloud-Computing nicht mehr wegzudenken. Ein Container ist heute das essenziellste Bauteil einer Cloud-Anwendung – in der einfachsten Form eine Applikation. Container lassen sich effizient starten, stoppen oder migrieren und komponieren. Docker-Container sind am weitesten verbreitet und werden durch Kubernetes-verwandte Anwendungen einfach gemanagt. Aber auch hypervisorbasierte Ansätze wie Amazons Firecracker haben die Leichtigkeit von Containern übernommen, sodass ein effizientes Ausführen von Applikationen in VMs ebenfalls denkbar ist und man hier von einer vergleichbaren Technologie sprechen darf.
Container-Verschlüsselung und -Authentifikation
Ein Confidential Container unterscheidet sich von einem normalen Container durch seine verschlüsselte und authentifizierte Ausführung (siehe Abb. 1). Applikationen werden in einer Enklave gestartet: Dafür reserviert die CPU vor dem Bootprozess einen Bereich des physischen Speichers. Ein Prozess, den das Betriebssystem in diesen Bereich lädt, wird von der CPU verschlüsselt – und nur die CPU kennt den Schlüssel, der von einem eindeutigen Hardware-Schlüssel abgeleitet und nach jedem Bootvorgang neu generiert wird. Die TPM-Eigenschaft der CPU schützt den Schlüssel vor Extraktion.
Eine weitere Neuerung von Confidential Containern ist ihre Authentifizierbarkeit: Der Autor des Containers signiert das Image. Damit haben Container nicht nur eine Identität, sondern können auch einfach standardisiert und zertifiziert werden. So ist es vorstellbar, dass unabhängige Zertifizierungsstellen Referenz-Images bereitstellen, die die Erfüllung von Compliance-Anforderungen in der Cloud vereinfachen.
Container-Attestation und Secret-Provisioning
Einen Container in einer Cloud auszuführen, lässt einige Fragen offen: Wenn man keinen Zugang zur Infrastruktur hat, woher weiß man, welcher Container gestartet wurde? Wird der Container auch tatsächlich in einer Enklave ausgeführt? Die Antworten liegen in der Remote-Attestation: einem kryptografischen Protokoll, das es Nutzern oder Autoren eines Confidential Containers ermöglicht, zu verifizieren, ob der gewünschte Container in der gewünschten Enklave ausgeführt wird – dabei haben nicht nur Container, sondern auch die Cloud-Hardware eine Identität. Vom eindeutigen Hardware-Schlüssel der CPU wird ein Attestierungsschlüsselpaar abgeleitet, das beim CPU-Hersteller registriert und zertifiziert wird (quasi als X509-Zertifikat).
Wenn nun ein Nutzer nach der Attestierung seines Containers fragt, agiert die CPU wie ein Auditor: Sie analysiert den Container und erzeugt einen Report, der den Hash-Wert des Containers sowie optional auch die Identität der Cloud-Plattform enthält. Der Nutzer muss nur noch den Hash-Wert mit dem vom Autor erzeugten Referenzwert vergleichen und gegebenenfalls die Identität der Plattform überprüfen.
Confidential Container sind Images, die im Dateisystem abgelegt werden. Geheimnisse, wie Schlüssel oder schutzwürdige Daten, die man darin ablegen würde (z. B. TLS-Serverzertifikat mit geheimem Schlüssel), ließen sich gegebenenfalls rekonstruieren. Confidential Container nutzen darum einen Trick, um vertrauliche Daten nachzuladen (Abb. 2): Nachdem die Applikation in die Enklave geladen, aber bevor sie gestartet wird, baut man einen sicheren TLS-Kanal zu einem Container-Provisioning-Server auf. Dieser überprüft mittels Remote-Attestation die Identität des Containers und spielt die fehlenden schutzwürdigen Daten in die Enklave ein. Erst dann wird die eigentliche Applikation gestartet – mit dem Unterschied, dass die notwendigen Geheimnisse der Applikation nun bereitstehen, sie aber durch die Enklave geschützt sind.
Abbildung 2: Schematischer Ablauf des Secret-Provisioning – nachdem Container und Plattform attestiert wurden (1), entscheidet der Nutzer zusätzliche „Secrets“ bereitzustellen (2), die über einen TLS-Kanal in den Container kommuniziert
werden (3)
Confidential-Cloud-Trust-Model
Fasst man die beschriebenen Eigenschaften zusammen, so ergibt sich ein vollkommen neues Vertrauensmodell für die Cloud: Ein Confidential-Cloud-Container läuft isoliert von allen anderen Containern einer Cloud. Dabei spielt der Software-Stack der Cloud keine Rolle. Selbst wenn das darunter liegende Betriebssystem mit BIOS und Treibern und/oder der Hypervisor kompromittiert sein sollten, bleibt die Applikation weiterhin eine Black-Box (Abb. 1) – einzig und allein die CPU ist befähigt, die Software im Container auszuführen. Und Manipulationen am Container lassen sich durch Attestierung sowie eine Container-Signatur aufdecken.
Damit reduziert sich das Cloud-Vertrauensmodell auf das Vertrauen in die CPU. Der CPU zu vertrauen, ist jedoch die fundamentale Annahme beim Computing. Vertraut man schon der CPU nicht, zum Beispiel, weil man einen Hardware-Trojaner vermutet oder Seitenkanal-Angriffe realistisch sind, dann helfen auch keine softwareseitigen Schutzmaßnahmen wie kryptografische Algorithmen – auch sie ließen sich dann aushebeln. Das Vertrauen in die CPU ist der atomarste Ankerpunkt. Dem liegen auch wirtschaftliche Interessen der CPU-Hersteller zugrunde: Sie haben keinen Anreiz, ihre Reputation als Vertrauensanker zu gefährden. In einem hart umkämpften Chip-Markt wäre das Bekanntwerden möglicher Hintertüren oder Anomalien im Chip wohl mit dem Niedergang des anbietenden Unternehmens gleichzusetzen.
Technologiepioniere in DACH und den USA
Angetrieben durch die strengen regulatorischen Anforderungen, ist es nicht überraschend, dass Unternehmen aus der DACH-Region und den USA Vorreiter der Confidential-Computing-Technologie sind, da sich hier – beziehungsweise im Brückenschlag über den Atlantik – das größte Wertschöpfungspotenzial bietet. Zu den Pionieren zählen Firmen wie Fortanix (US), Anjuna (US), Cysec (CH), Edgeless System (DE), Scontain (DE) und enclaive.io (DE) – wobei die beiden letzteren auch Open-Source-Lösungen für Confidential Container bereitstellen (siehe https://gitlab.scontain.com bzw. https://github.com/enclaive).
Fazit
Dank Confidential Computing ist ein Zugriff Dritter auf Daten in unverschlüsselter Form auch während ihrer Verarbeitung unmöglich. Die Methode könnte somit eine Möglichkeit eröffnen, Datenverarbeitung in den USA und anderen Nicht-EU-Staaten rechtskonform zu gestalten. Im Einklang mit den durch den EuGH im Schrems-II-Urteil dargelegten Anforderungen an einen sicheren Datentransfer in Drittstaaten gewährleistet die Technologie, dass während des Übermittlungsprozesses, der Speicherung und besonders der weiteren Verarbeitung (personenbezogene) Daten durchgängig verschlüsselt bleiben.
So lässt sich auch bei einer Cloud-Datenverarbeitung im Ausland nahezu ausschließen, dass Dritte, einschließlich des Cloud-Service-Anbieters oder fremder Nachrichtendienste, auf die Daten in unverschlüsselter Form zugreifen – zumindest lässt sich dieses Risiko bei der Anwendung von dem Stand der Technik entsprechender Verschlüsselungsstandards signifikant verringern.
Damit unterscheidet sich Confidential Computing entscheidend von den bisher verwendeten Ansätzen zur Verschlüsselung in der Cloud. Zudem setzt Confidential Cloud-Computing neue Maßstäbe für technisch organisatorische Maßnahmen für den Datenschutz nach DSGVO/GDPR (vgl. [11]).
Prof. Dr. Sebastian Gajek ist Professor für IT-Sicherheit an der Hochschule Flensburg und Technischer Direktor bei enclaive.io.
Literatur
[1] U. S. Congress, H.R.4943 – CLOUD Act, Juni 2018, congress.gov/bill/115th-congress/house-bill/4943
[2] U. S. Department of Justice, Promoting Public Safety, Privacy, and the Rule of Law Around the World, The Purpose and Impact of the CLOUD Act, Whitepaper, April 2019, www.justice.gov/dag/page/file/1153436/download
[3] U. S. Department of Justice, Cloud Act Resources, Portalseite, August 2022, www.justice.gov/dag/cloudact
[4] Tobias Haar, Cloud-Dienste: Vergabekammer verbietet Angebot von US-Tochterunternehmen, heise online, August 2022, https://heise.de/-7204620
[5] Bernard Marr, What Is Homomorphic Encryption? And Why Is It So Transformative?, Forbes Enterprise Tech Blog, November 2019, www.forbes.com/sites/bernard-marr/2019/11/15/what-is-homomorphic-encryption-and-why-is-it-so-transformative/
[6] Wikipedia, Homomorphic encryption, April 2006 bis September 2022, https://en.wikipedia.org/wiki/Homomorphic_encryption
[7] Martin Albrecht, Melissa Chase, Hao Chen, Jintai Ding, Shafi Goldwasser, Sergey Gorbunov, Shai Halevi, Jeffrey Hoffstein, Kim Laine, Kristin Lauter, Satya Lokam, Daniele Micciancio, Dustin Moody, Travis Morrison, Amit Sahai, Vinod Vaikuntanathan, Homomorphic Encryption Standard, An Open Industry / Government / Academic Consortium to Advance Secure Computation, November 2018, https://homomorphicencryption.org/standard/
[8] Microsoft, Multiparty computing architecture design, Azure Application Architecture Guide, Mai 2022, https://learn.microsoft.com/en-us/azure/architecture/guide/blockchain/multiparty-compute
[9] Yehuda Lindell, Secure Multiparty Computation (MPC), Cryptology ePrint Archive 2020/300, Januar 2021, https://eprint.iacr.org/2020/300.pdf
[10] MPC Alliance, Multiparty computation (MPC) wiki, https://wiki.mpcalliance.org
[11] Dennis-Kenji Kipker, Verschlüsselung gleich Anonymisierung?, <kes> 2022#1, S. 26