Confidential Computing – Ich sehe was, was sonst keiner sieht

„Cloud first“ heißt das Mantra zurzeit in mehr als einem Unternehmen und damit ist vor allem Public Cloud gemeint. Ob das sinnvoll ist oder nicht, sei dahingestellt, aber so sieht der Trend eben aus. Allerdings gab es bis dato, vor allem im datenschutzaffinen Deutschland ein paar No-Go Areas für Applikationen in der Public Cloud. Immer dann, wenn es um besonders schützenswerte Daten ging, wenn Unternehmen der Finanzbranche oder öffentliche Auftraggeber betroffen waren, wurde die rote Fahne gehisst. Denn das Allheilmittel für Vertraulichkeit – Verschlüsselung – ließ sich in der Cloud zwar auf Transportwege (in-transit) oder auf die Massenspeicher (at-rest) anwenden, nicht aber auf die Daten während der Verarbeitung. Das sieht nun anders aus. Alle großen Hyperscaler haben seit etwa einem Jahr verschiedene Maßnahmen zur Verarbeitungsverschlüsselung im Angebot, meist unter dem Oberbegriff „Confidential Computing“. Immer geht es darum, Daten und manchmal auch Code bei der Ausführung zu schützen. Damit könnte, entsprechendes Sicherheitskonzept vorausgesetzt, der Cloud Provider tatsächlich zu keinem Zeitpunkt Einblick in Kundendaten nehmen, selbst wenn er oder eine staatliche Stelle das wollten.

Im Detail kann Confidential Computing mehrere Dinge bedeuten, je nach Umsetzung. Oft wird beispielsweise ein Hardware Security Module (HSM) schon als Confidential Computing bezeichnet. Ein HSM sichert aber in erster Linie Secrets, zum Beispiel Schlüssel für kryptographische Verfahren in besonders geschützter Hardware. Ein HSM ist sehr oft Bestandteil von Confidential Computing, aber es verwehrt keine Einblicke in Code und Daten bei der Ausführung. Ein weiteres Konzept ist homomorphische Verschlüsselung. Mit ihr lassen sich Daten im verschlüsselten Zustand verarbeiten, auch die CPU kennt den Klartext der Daten nicht. Damit wird aber nur die Vertraulichkeit sichergestellt, nicht die Integrität von Daten und Code. „Richtiges“ Confidential Computing kann beides und die mittlerweile etablierten Verfahren beherrschen das mehr oder weniger gut. Den Anfang machte Microsoft bereits 2017 basierend auf Prozessortechnologie von Intel: Software Guard Extensions (SGX). SGX nutzt einen abgeschotteten Bereich innerhalb der CPU, eine so genannte Enklave, zur Ausführung von Code und Daten. Diese Enklave, ein Trusted Execution Environment (TEE), ist vor allen anderen Prozessen, selbst mit root-Berechtigung geschützt.

Für ein TEE gibt es vom Confidential Computing Consortium (CCC) allgemeingültige Definitionen. So soll ein TEE Datenintegrität, Datenvertraulichkeit und Code-Integrität gewährleisten. Die SGX-Enklaven stellen sicher, dass nur autorisierte Daten verarbeitet werden (Vertraulichkeit) und nur freigegebener Code ausgeführt wird (Integrität). Es gibt allerdings keinen Standard, dem sich Enklaven unterwerfen und mehrere Frameworks, um Anwendungen für eine Enklave zu entwickeln. Google setzt auf Asylo während Microsoft OpenEnclave propagiert.

Die SGX-Enklave führt nur Code aus, der durch einen „Attestation“ genannten Service berechtigt wurde. Damit erfüllt SGX die Anforderung, sowohl Vertraulichkeit als auch Integrität zu bewahren. Auch IBM nutzt bei seinem Cloud-Angebot SGX als Basistechnik für Confidential Computing. Der Nachteil: Man kann seine Applikation nicht einfach auf einem SGX-fähigen Prozessor laufen lassen und von den Fähigkeiten profitieren. Die Applikation muss spezifisch angepasst werden, damit Datenkonzept und Algorithmen SGX nutzen. Eine Alternative sind Meta-Applikationen wie Anjuna, die eine Art „Hülle“ um die Zielanwendung legen. Die funktionieren aber nicht auf allen Betriebssystemen und mit allen Zielapplikationen out-of-the-box, in der Regel sind dafür Anpassungen notwendig.

So wie Intel hat auch AMD eine Confidential Computing-Technologie in seinen Prozessoren verbaut. Die heißt Secure Encrypted Virtualization (SEV) und bietet gegenüber SGX einfachere Anwendbarkeit und weniger Perfomanceeinbußen. Allerdings kann sie die Integrität des Speichers nicht gewährleisten und schützt den Code nicht gegenüber dem Besitzer der Compute-Plattform, was SGX durch das Attestation-Konstrukt bewerkstelligt. Von den großen Hyperscalern setzt Google Cloud Computing (GCP) AMDs SEV ein. Eine Erweiterung des Konzepts, Secure Nested Paging (SEV-SNP) beherrscht auch Integritätsschutz, wird aber im Moment von keinem Hyperscaler angeboten.

Ganz ohne Prozessor-basierte Schutzmaßnahmen geht Amazon bei AWS an Confidential Computing heran. Dessen „Nitro“ VMs sind an eine EC2-Instanz angeflanscht. Sie erben einen Teil der CPU und RAM-Ressourcen von der VM und führen damit den vertraulichen Code aus. Die Attestation wird durch den Nitro Hypervisor gewährleistet und ist in den AWS Key Management Service integriert. In punkto Sicherheitslevel bietet Nitro weniger als eine SGX-Enklave, dafür ist Nitro ohne Änderungen an der Applikation nutzbar. Das verspricht auch Google mit seinen Confidential VMs auf Basis der zweiten Generation von AMDs EPYC Prozessoren mit SEV. Der Speicher wird dabei durch einen VM-dedizierten Schlüssel geschützt. Die CPU erzeugt den Schlüssel während des VM-Setups und verwaltet ihn eigenständig in einem geschützten Speicherbereich innerhalb der CPU. So können weder Google noch andere VMs auf dem gleichen Host auf Daten in der VM zugreifen. Diese Confidential VMs von Google basieren auf den Shielded VMs, die, neben den angesprochenen Maßnahmen, auch umfangreich gehärtet und gegen Angriffe wie Root- und Bootkits geschützt werden.

Alle Public Cloud-Anwender haben durch die jeweiligen Angebote die Möglichkeit, eine höhere Form der Datensicherheit zu erlangen. Allerdings schützt nur SGX mit eigens dafür entwickelten Applikationen oder einer Meta-Applikation wirklich vor Zugriff durch alle Parteien. Immerhin: Wenn die Anforderungen so hoch sind, wird sich auch eine Anpassung lohnen. Ganz ohne Nebenwirkungen sind die Confidential Computing Maßnahmen ohnehin nicht. Die Leistungseinbußen liegen je nach Technologie und Hyperscaler zwischen 1 und 6 Prozent. Die Attestation, sofern sie durch einen den Prozessorhersteller oder eine weitere Partei durchgeführt wird, ist ebenfalls ein Angriffsvektor. Dazu kommen erste Proof-of-Concepts, dass Schadsoftware, die gezielt in einer Enklave ausgeführt wird, vollkommen unsichtbar für alle anderen Prozesse wie eine Anti-Malware-Software ist. Und zu guter Letzt hat sich SGX als anfällig für den Intel-Bug Spectre erwiesen. Wenn die Enklaven wirklich die Kronjuwelen der Organisation beinhalten, sind erfolgreiche Seitenkanalangriffe das Letzte, was man als Anwender erleben will.