Autoren: Thomas Fricke, Axel Saß, Jens Freimann

Lizenz: Deed - Attribution-NonCommercial-NoDerivatives 4.0 International - Creative Commons CC BY-NC-ND 4.0

Thomas Fricke arbeitet als Cloud Sicherheits Architekt und entwirft sichere Architekturen für kritische Infrastrukturen im Bereich Energie, Übertragungsnetze, Verkehr, Gesundheit und Finanzen. Er berät Firmen und Behörden Umfeld zum Thema Kubernetes, OpenShift und Cloud Security. Er hat bei der Gründung von OpenCode.de, dem Sovereign Tech Fund und bei OpenDesk mitgewirkt. Er ist Mitgründer von Mitigant.io

Axel Saß arbeitet als Chief Architect in der Field CTO Organization bei Red Hat. Hierbei geht es vor allem um die Stärkung der Zusammenarbeit der Vertriebsorganisation, des Produktmanagements und der Engineering Abteilungen mit dem Ziel, innovative Lösungen und Services zusammen mit Kunden zu implementieren. Ein spezieller Fokus liegt derzeit auf Confidential Computing.

Jens Freimann verantwortet als Engineering Manager bei Red Hat die Produktentwicklung für OpenShift Sandboxed Containers und Trustee. Im Mittelpunkt seiner Arbeit steht die Weiterentwicklung von Confidential Computing-Technologien auf Basis offener Standards wie dem CNCF-Projekt „Confidential Containers“. Er steuert die technische Zusammenarbeit mit einem Ökosystem aus Hardware-, Cloud- und Softwarepartnern, um für Schlüsselkunden sichere und souveräne IT-Lösungen zu realisieren.

Management Zusammenfassung

Management Summary: Confidential Computing im Überblick

Die IT-Security steht vor neuen Herausforderungen, insbesondere beim Schutz von Daten während der Nutzung (Data in Use), was durch den Digital Operational Resiliency Act (DORA) erstmals berücksichtigt wird.

Confidential Computing schützt sensible Daten und Applikationslogik indem Berechnungen oder Ausführen von Logik in hardwarebasierten Trusted Execution Environments (TEEs) stattfinden. Diese TEEs gibt es in zwei Hauptformen: VM-basierte TEEs (Confidential VMs), die eine ganze virtuelle Maschine isolieren und verschlüsseln (z.B. Intel TDX, AMD SEV-SNP), und prozessbasierte TEEs, auch “Enklaven” genannt, die einzelne Anwendungsprozesse in einem geschützten Speicherbereich ausführen (wie bei Intel SGX). Beide Ansätze erhöhen die Sicherheit, indem sie Daten selbst vor privilegierten Administratoren schützen. Dies geschieht einerseits durch die Rückgabe von expliziten Anfragen zu Inhalten von Speicherbereichen und andererseits durch eine TEE bereitgestellte Speicherverschlüsselung, die Daten auch dann schützt Daten, wenn ein Angreifer physischen Zugriff auf die Hardware hat, da der Arbeitsspeicher in Echtzeit ver- und entschlüsselt wird und somit das Auslesen der Speichermodule oder das Abhören des Speicherbusses keine Klartextdaten preisgibt. Dies schafft eine klare Trennung zwischen operativer Administration und sensiblen Informationen. Dennoch hat die Technologie auch Grenzen und erfordert eine sorgfältige Einbettung in ein umfassendes Sicherheitskonzept.

Vorteile

• Höhere Datensicherheit
  Daten bleiben selbst gegenüber privilegierten Systemadministratoren geschützt, wodurch das Risiko von Insider Angriffen deutlich sinkt.

• Reduzierte Angriffsfläche
  Durch isolierte TEEs wird der potenzielle Zugriff auf sensible Daten verringert.

• Unterstützung von Zero Trust und Digital Sovereignty
  Rollen und Zugriffsrechte können besser voneinander getrennt werden, was die Einhaltung von Sicherheitsrichtlinien und Compliance erleichtert. Im Sinne einer Integration in ein Zero Trust Konzept https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Zero-Trust/zero-trust_node.html entspricht Confidential Computing der Musterarchtitektur und die Attestierung dem Policy Decision Point (PDP) vollständig. Die Einbeziehung von User Interaktionen und externen Systemen werden in unserem Dokument weitgehend diskutiert.

• Sinkende Risiken durch ältere Hardware
  Zwar tauchen weiterhin gelegentlich Lücken auf, doch meist in Verbindung zu Software, zum Beispiel Treibern, die zum Betreiben von älteren Bestandteilen der Hardware benötigt wird. Die Angriffsfläche in neuen, speziell gesicherten Bereichen ist dabei im Vergleich zum gesamten Software Stack relativ klein.

Herausforderungen

• Technische Reife
  Confidential Computing ist noch nicht flächendeckend erprobt. Schwachstellen beruhen aber häufig auf älteren CPU- und Firmware-Bestandteilen.

• Komplexität des Betriebs
  Die Attestation (Prüfung der Unverfälschtheit von Enklaven) ist anspruchsvoll und benötigt klar getrennte Rollen in der Administration.

• Microcode und Firmwareupdates
  Ein zuverlässiger und schneller Prozess zum Einspielen von Updates ist entscheidend. Embargo-Phasen erfordern eine enge Kooperation mit Hardware-,Cloud-Anbietern und Kunden. Ziel hierbei ist es allen Beteiligten die Möglichkeit zu geben, Risikomitigation zu betreiben. Zum Beispiel müssen Kunden entscheiden, ob die avisierte Lücke, ohne genau den Mechanismus zu beschreiben, wie diese ausgenutzt werden kann durch geeignete Maßnahmen verhindert werden kann

• Beschränkter Schutzumfang
  Probleme in Anwendungen oder Organisation (zum Beispiel SQL Injections oder unzuverlässiges Personal) werden nur teilweise gelöst.

Empfehlungen

• Einstieg durch Pilotprojekte
  Führen Sie ein Proof-of-Concept durch, um Nutzen und Machbarkeit in Ihrer Umgebung zu bewerten.

• Rollen klar definieren
  Trennen Sie Verantwortlichkeiten für Server Betrieb und Attestation, um das Sicherheitsniveau zu sichern.

• Kontinuierliche Firmwarepflege
  Etablieren Sie ein strukturiertes Update Verfahren für Microcode und Firmware, damit Sicherheitslücken schnell geschlossen werden können.

• Ganzheitliche Absicherung
  Setzen Sie Confidential Computing als Ergänzung zu bestehenden Sicherheitsmaßnahmen ein. Es ist kein Ersatz für grundlegende Schutzmechanismen und organisatorische Maßnahmen.

• Zusammenarbeit mit Anbietern
  Arbeiten Sie eng mit Hardware und Cloud Partnern zusammen, um rechtzeitig auf neue Bedrohungen zu reagieren und Updates umzusetzen.

Confidential Computing bietet die Möglichkeit, hochsensible Daten besser zu schützen und das Risiko von unbefugten Zugriffen durch klare Trennung von Zuständigkeiten zu reduzieren. Obwohl noch nicht alle Hardware- und Firmware-Risiken vollständig ausgeschlossen sind, ist die Angriffsfläche im Vergleich zu vielen anderen Komponenten spürbar kleiner. Wer jetzt schrittweise vorgeht und erste Pilotprojekte durchgeführt, kann die Technologie sinnvoll in die eigene Sicherheitsarchitektur integrieren und frühzeitig wertvolle Erfahrungen sammeln.

Einleitung

Die Herausforderungen im Bereich der IT Security steigen immer weiter. Es steigt die Anzahl der Angreifer, es steigen aber auch die technischen Möglichkeiten, Inhalte zu schützen. Eine neue Möglichkeit ist, den Inhalt von Anwendungen während ihrer Ausführung (Data in Use) zu schützen. Bereits bekannt sind das Schützen von Daten (Data at Rest) und das Schützen von Daten während des Transfers im Netzwerk (Data in Transit). Das Schützen von Daten während der Ausführung ist eine neue Komponente, die Confidential Computing genannt wird. Erstmals berücksichtigt dies der Digital Operational Resiliency Act (DORA).

Um die Einführung von Confidential Computing zu unterstützen arbeitet die IT Industrie an einer Standardisierung dieser Services. In dieser Community (https://confidentialcomputing.io/about/members/) sind Hardware-, Softwarehersteller und Cloud Provider vertreten. Gemeinsam wollen sie die Verbreitung von Confidential Computing vorantreiben. Auf dem Confidential Computing Summit in San Francisco hat zum Beispiel Microsoft angekündigt Hauptservices Ihrer Cloud Services ( Payment / Subscription management ) in Confidential Umgebung in ihrem Azure Cloud Angebot zu verlagern.[1] Da es keinen Preisunterschied zwischen Confidential Computing-fähigen Cloud-Instanzen und solchen ohne geben soll, wird davon ausgegangen, dass in nicht allzu ferner Zukunft die Kunden dieser Services die freie Wahl haben, welche Implementierung sie nutzen wollen und somit Confidential Computing zum Standard werden wird.

Da keine Preisdifferenzierung für Confidential Computing-fähige Cloud-Instanzen erwartet wird, ist es wahrscheinlich, dass Kunden in naher Zukunft die freie Wahl bei der Implementierung haben werden, wodurch Confidential Computing zum Standard avanciert.

Wie können diese neuen Mechanismen Unternehmen helfen, Daten besser zu schützen? Nachfolgend befindet sich eine Erklärung der technischen Grundlagen.

Confidential Computing zielt darauf ab, sensible Daten während ihrer Verarbeitung zu schützen, indem Berechnungen in Hardware basierten TEEs durchgeführt werden. Dies bietet ein hohes Maß an Sicherheit für sensible Daten und stärkt die Vertrauensbasis in verschiedenen Bereichen der IT-Infrastruktur. Im Folgenden wird dargestellt, wie Confidential Computing die einzelnen Schichten der dargestellten Grafik verändert und welche Unterschiede im Vergleich zu herkömmlichen Sicherheitsmodellen bestehen. Das kann nur gewährleistet werden, wenn alle für die Sicherheit des TEE eingesetzten Komponenten vertrauenswürdig sind.

Die Enklave erlaubt, eine Grenze zwischen Prozessen und ihren Daten in der Enklave, die Teil der Trusted Computing Base (TCB) sind, und außerhalb der Enklave zu ziehen. Innerhalb der TCB sind dann auch hardwarenahe Komponenten wie der Microcode der CPU, Firmware und die Software zur Attestierung. Dabei dürfen in der Betrachtung auch die Komponenten nicht vergessen werden, die an der Peripherie der CPU liegen wie Memory, Netzwerkhardware und BIOS.

Die Enklave erlaubt auch, eine Grenze in der Administration zu ziehen. Während Administratoren normalerweise auf alle Ressourcen auf einem Host zugreifen können, ist hier der Inhalt von Prozessen in der Enklave geschützt. Damit können auch Zugriffe durch das Bedienpersonal weiter eingeschränkt werden.

Das Konzept ist somit vergleichbar mit Zero-Admin (Zero Privileges) in Git Ops, wo auch Hosts nicht mehr ohne Änderung eines Git Repositories modifiziert werden können, wodurch sie nachweisbar dokumentiert werden. In Kombination mit Enklaven können die Vorteile beider Ansätze eine neue Stufe der Sicherheit erreichen.

Übergreifende Sicherheitskonzepte in Confidential Computing

In dem folgenden Abschnitt werden Grundkonzepte von Confidential Computing näher beleuchtet. Hierbei wird vor allem auf Designkonzepte, die zur Steigerung der Sicherheit genutzt werden, fokussiert. Beginnen wir mit der Trusted Computing Base (TCB).

Trusted Computing Base (TCB)

Die Trusted Computing Base (TCB) ist die Summe aller Komponenten, denen man für die Sicherheit eines Systems zwingend vertrauen muss. Das Ziel von Confidential Computing ist es, diese TCB, und damit die Angriffsfläche, radikal zu reduzieren.

Während in traditionellen Systemen die TCB riesig ist und den Hypervisor, das Host-OS und dessen Administratoren umfasst, reduziert eine Trusted Execution Environment (TEE) sie auf nur noch die CPU und den Anwendungscode.

Diese grundlegende Einteilung in “vertrauenswürdig” (innerhalb der TCB) und “nicht vertrauenswürdig” (außerhalb) muss für jede Schicht des IT-Stacks wiederholt werden, von der Hardware bis zum Betrieb. Mittels Remote Attestation lässt sich der Zustand der TCB für die jeweilige Schicht kryptografisch nachweisen, um das Vertrauen in die gesamte Kette sicherzustellen.

Trusted Execution Environment (TEE)

Eine Trusted Execution Environment (TEE), im Sinne moderner Infrastruktur wie sie das Confidential Computing Consortium definiert, ist eine durch die CPU-Hardware geschaffene, vollständig isolierte Umgebung für eine virtuelle Maschine (VM).

Technologien wie Intel® TDX und AMD SEV-SNP ermöglichen es, eine solche Confidential VM (CVM) zu betreiben. Der gesamte von der VM genutzte Arbeitsspeicher wird dabei in Echtzeit mit Schlüsseln verschlüsselt, die ausschließlich die CPU selbst verwaltet.

Dies schafft eine starke Schutzbarriere: Versucht eine nicht autorisierte Komponente von außen, wie der Hypervisor oder ein Tool des Cloud-Administrators, auf den Speicher der VM zuzugreifen, setzt die CPU dies hardwareseitig durch und gibt statt der echten Daten nur Nullen zurück.

Attestation

Um Vertrauen in eine entfernte, isolierte Umgebung (die TEE) aufzubauen muss sichergestellt werden, dass der neu hinzugekommene Bereich ebenfalls die gleichen Sicherheitsanforderungen erfüllt. Dieser kryptografische Nachweisprozess wird Attestation genannt. Die sicherheitsrelevante Überprüfung des Zustands einer TEE und ihrer zugrundeliegenden Infrastrukturkomponenten. .

Die Komponenten, die diesen Nachweis erbringen (innerhalb der TEE) und die ihn prüfen (der Attestation Service), bilden zusammen ein kritisches System. Der gesamte Prozess, inklusive des Transports über die Netze, die Software und Updates, muss vertrauenswürdig sein, idealerweise aufgesetzt durch einen vollautomatischen Mechanismus. Zertifikatsalgorithmen und Schlüssel, die die Vertrauensrichtlinien definieren, müssen durch die Anwender kontrolliert werden, um Hintertüren zu vermeiden.

Im Rahmen der Attestierung werden kryptografische Beweise (Evidence) gesammelt und an einen Attestation Service geschickt. Dieser überprüft die Beweise anhand einer vordefinierten Richtlinie (Policy) und attestiert daraufhin die Vertrauenswürdigkeit der TEE.

Attestation ist immer dann notwendig, wenn Geheimnisse (wie bzw. zur Entschlüsselung notwendige Schlüssel) an die TEE gesendet werden sollen. Um die Offenlegung von Daten zu verhindern, wird ein “Seal/Unseal”-Muster verwendet. Sensible Daten werden vorab für eine bestimmte TEE verschlüsselt. Erst nachdem diese TEE per attestation ihre Identität und Integrität bewiesen hat, wird der zur Entschlüsselung benötigte Schlüssel freigegeben.

Es wird unterschieden zwischen einem Remote und einem Local Attestation Service. Bei einem Local Attestation Service wird ein Service genutzt, der sich in derselben Umgebung befindet, wie die Plattform, auf der die TEE läuft. Nachteil hierbei ist, dass dabei die Rollen Cloud Provider und Attestation Provider durch denselben Anbieter zur Verfügung gestellt werden. Das führt zu einer Reduktion der Sicherheit. Grundsätzlich sollte aber die Attestation durch einen unabhängigen, vom Anwender kontrollierten Remote Attestation Service durchgeführt werden. Dieser Service wird selbst in einer hochsicheren vertrauenswürdigen Umgebung (seiner eigenen TCB) betrieben.

In der abgebildeten Darstellung wird als Attestation Service das OpenSource Projekt Trustee eingesetzt. Hier werden alle notwendigen Services bereitgestellt, die zur Implementierung eines Remote Attestation Services notwendig sind. Der Prozess setzt sich aus einer Reihe von Schritten zusammen.

• In der TEE soll eine verschlüsselte Ressource mit einem Key entschlüsselt werden.

• Die Anfrage nach einer Attestation wird an einen Relying Service geschickt. Der Service holt sich die Evidence (Parameter der Umgebung) anhand derer man feststellen kann, dass die TEE als sicher bezeichnet werden kann von der CPU, auf der die TEE läuft.

• Diese Evidence wird mit verschiedenen Schlüsseln innerhalb der TEE signiert. ( CPU, VM, CPU Provider ) und an den Attestation-Service zurückgesendet. Dieser Service bedarf einer Verbindung zu der Trust Authority der Hardware Provider ( AMD, Intel ) um die letzte Stufe zu signieren. In einer nicht mit dem Internet verbundenen Umgebung müssen die Hardware-Zertifikate der Hersteller anderweitig verfügbar gemacht werden, dies variiert je nach Hersteller.

• Dort wird die Evidence anhand der Signaturen auf Richtigkeit geprüft.

• Diese übermittelten Werte werden mit in dem Verifier (Teil des Attestation Service ) gespeicherten Referenzwerten (entsprechend der Policy) verglichen.

• Bei Übereinstimmung wird dem Relying Service das Ergebnis der erfolgreichen Attestation gesendet.

• Daraufhin wird der notwendige Schlüssel zur Entschlüsselung an die TEE versendet und die Daten können entschlüsselt werden.

Der gewählte Weg implementiert Security by Design. Es wird also die Sicherheit des gesamten Prozesses sichergestellt, durch die genutzten Designprinzipien und die Reihenfolge des Freigabe des Schlüssels. Das heißt, sollte die Attestation nicht erfolgreich durchgeführt werden, wird auch der Schlüssel nicht zur Verfügung gestellt. Und somit sind in der nicht attestierten TEE auch keine unverschlüsselten Daten/Business Logik verfügbar.

Attestierung von VMs während des Bootens

\[AMD\]\[Trustee\]

– per Remote Attestation die Echtheit dieses Berichts, indem die AMD-Zertifikate geprüft und der gemessene Startzustand mit den erwarteten Werten abgeglichen wird. Nur nach erfolgreicher Verifikation werden vertrauliche Geheimnisse (z. B. ein Disk-Verschlüsselungsschlüssel) für die VM freigegeben, sodass erst dann der Zugriff der CVM auf diese sensiblen Daten ermöglicht wird.

Separation der Rollen und Verantwortung

Der Prozess der Attestierung wird von verschiedenen Rollen durchgeführt. Je konsolidierter diese Rollen auf einen Teilnehmer sind, desto leichter ist es, dass durch Einfluss von Dritten auf diese eine Partei eine Sicherheitslücke erzeugt wird und Daten so nach außen gelangen. Mit der Separation dieses Rollenkonzepts auf mehrere Teilnehmer steigt die gesamte Sicherheit von Confidential Computing.

Die Separation von Verantwortung im Detail

Für einen Angriff muss ein unbemerkter Zugriff auf die Hardware mit einer Sicherheitslücke der Hardware zusammenkommen. Eine Manipulation der Hardware ist schwer auszuschließen, wenn nicht weitere Maßnahmen wie physische Versiegelung und Überwachung hinzukommen.

Sicherheitslücken in der Hardware wie in der Firmware, dem Microcode, dem Bios können durch Audits abgeschwächt werden, wie z.B. beschrieben in Intel Trust Domain Extensions Security Research and Assurance

Umso wichtiger ist Confidential Computing auf Edge Devices, also außerhalb der geschützten Cloud Zone. Diese Geräte können ohne den physischen Schutz, der in Rechenzentren Standard ist, in Umgebungen stehen, wo allgemeiner physischer Zugrff durch nicht vertrauenswürdige Personen möglich ist., Beispielsweise in Produktionsstraßen in Fabriken, in Arztpraxen, Infrastruktur oder buchstäblich auf dem Feld stehen.

Der bisherige Schutz durch Perimeter Security, also durch in Zonen aufgeteilte Netze, reicht in Zukunft nicht mehr aus. Eine zusätzliche Absicherung der Hardware, die eine Isolierung auch bei direktem physischen Zugriff so schwierig wie möglich macht, ist dringend geboten. Die heute ausgerollten Geräte entsprechen dem Stand der Technik der 1990er Jahre und sind dementsprechend veraltet und brauchen dringend ein Upgrade bei Verschlüsselung der Daten im Transport, bei der Speicherung und beim Compute.

Hierbei werden verschiedene Rollen unterschieden, wie in der oberen Grafik zu sehen ist.

• Der Cloud Provider

  • Es wird grundsätzlich angenommen, dass der Cloud Provider durch nationale Gesetze dazu gezwungen werden kann, Zugriff auf die Daten zur Verfügung zu stellen, sofern er diesen hat. (Siehe US CLOUD Act oder DSGVO und CLOUD Act – rechtliche Risiken beim Datentransfer in die USA )

• Der Hardware Provider

  • Der Hardware Provider stellt die physikalische Umgebung in Form einer CPU zur Verfügung, die mit Confidential Computing Diensten erweitert wurde. Es gibt derzeit verschiedene Hersteller, die an dem Confidential Computing Consortium teilnehmen und dementsprechend auf einem gemeinsamen Standard Confidential Computing umsetzen. Der verwendete Code in der Hardware ist grundsätzlich nicht offen gelegt. Sollte es allerdings eine Backdoor geben, so muss diese von außen zugänglich sein. Das kann durch geeignete Firewall Regeln verhindert werden. Des Weiteren würde ein Bekanntwerden einer solchen Backdoor zu einem erheblichen Vertrauensverlust für diesen Hersteller führen, der dazu führen würde, dass diese Anbieter grundsätzlich nicht mehr am Markt bestehen würden.

• Der/Die Software Provider

  • Die Software Provider stellen die Basis Software Komponenten zur Verfügung, die zum Beispiel den Attestation Service implementieren. Hierbei sorgt die Verwendung von Open Source zu einer erhöhten Sicherheit.

• Der Attestation Service Provider

  • Der Betreiber des Attestation Services. Dieser Service sollte sich in der Trusted Computing Base (TCB) befinden. Zum einen braucht dieser Service gesicherten Zugang zum Key Management Service und zum anderen muss er von Eingriffen von außen geschützt sein.

• Der Kunde des Services

  • Der Nachfrager nach dem Betrieb eines zu schützenden Services, der in einer Cloud betrieben werden soll. Bei ihm wird immer angenommen, dass es bereits geeignete Maßnahmen zur Absicherung gibt bzw. dass es für einen internen Angriff geeignetere/einfachere Möglichkeiten gibt, an die Informationen zu kommen.

Gesteigerte Sicherheit durch verteilte Rollen (Separation of Duty)

Um einen Zugang zu erhalten, müssen immer mehrere dieser Rollen zusammenarbeiten. Bei der folgenden Erläuterung wird immer angenommen, dass der Cloud Provider durch nationale Gesetze zu einer Kooperation gezwungen wird.

• Angriff mit Hilfe des Attestation Providers und des Cloud Providers

  • Hier arbeiten Cloud Provider und Attestation Provider zusammen. Der Cloud Provider startet die CPU im nicht Confidential Modus, so dass von außen auf den Speicher des TEE zugegriffen werden kann. Bei der Anfrage nach einer Attestation wird von dem Attestation Service nach Evidence bei der CPU gefragt. Sie erzeugt richtigerweise Evidence, die der Umgebung keine Sicherheit beweisen. Da der Attestation Service kompromittiert ist, wird die Verifizierung der Evidenzdaten in diesem Fall erfolgreich sein, obwohl die CPU im nicht Confidential Modus läuft. Der Attestation-Service bekommt dieses Ergebnis und stellt den Schlüssel zur Verfügung. Somit stehen die Daten für den Cloud Provider zur Verfügung.

Confidential Computing in der regulierten Industrie in abgetrennten Umgebungen

Wenn wir uns die verschiedenen Industriezweige anschauen, in denen Confidential Computing die meisten Vorteile bringen könnte, dann ist es vor allem die Finanzindustrie (FSI). Hier ist die Regulatorik am weitesten fortgeschritten und definiert. Vor allem, weil es hier grundsätzlich darum geht, die landesweite Wirtschaft zu schützen. Ein Ausfall würde zu unkalkulierbaren Folgen führen. Aufgrund dieser Anforderungen tendiert die Finanzindustrie meist eher dazu, ihre gesamten kritischen Infrastrukturen in einem eigenen Datacenter zu betreiben, sieht aber Vorteile in der Public Cloud. Um noch darüber hinaus sicherzustellen, dass ein Eingriff von außen unmöglich ist, werden diese Umgebungen meist im Disconnected Modus betrieben. Es gibt also keine direkten Zugang von außen und nach außen aus diesen Umgebungen. (Siehe Attestation). Aber auch hier kann es sinnvoll sein, eine weitere Schicht der Sicherheit mit Hilfe von Confidential Computing einzuführen. Um die Signierung von Evidence im Rahmen der Attestation zu ermöglichen, brauchen diese Services aber den Zugang zu den Hardware Signatur Services. Um den Betrieb in einer isolierten Umgebung sicherzustellen, bieten die Hardwareprovider für die letzte Ebene der Signatur auch Modelle an, um diese in den Datacentern disconnected zu betreiben (siehe auch Infrastructure Setup - Intel® TDX Enabling Guide ).

Ein weiterer Bereich, wo TEEs einen wesentlichen Beitrag zur Sicherheit leisten können, sind alle kritischen Infrastrukturen, wo operationale Sicherheit (OT-Sicherheit) schwierig zu implementieren ist, weil viele Geräte in nicht zugangsgeschützten Bereichen stehen und schwer physisch abzuschotten sind. Beispiele dafür sind Industriesteuerungen, Krankenhäuser, Verkehrskontrollsysteme und Robotik.

Confidential Computing im Kontext eines Schichtenmodells.

Das Bild zeigt eine Reihe von Komponenten und Schichten, die jede für sich abgesichert sein muss, um eine sichere Umgebung aufzubauen. Fehler in einer Schicht können nur sehr bedingt oder gar nicht durch eine andere Schicht abgemildert werden.

Je höher die Anforderungen an die Sicherheit sind, desto eher sind Optionen, die in dem Text als Kann-Optionen angegeben sind, als Muss-Optionenzu sehen. Das gilt insbesondere, wenn die Anforderungen an die Sicherheit hoch oder sehr hoch sind.

1. CPU und Enklave

Rolle der CPU und der Enklave

Die CPU ermöglicht den Betrieb von TEEs, die streng isolierte Bereiche innerhalb des Prozessors bereitstellen. In diesen isolierten Umgebungen werden sensible Daten und Anwendungen so verarbeitet, dass selbst bei Kompromittierung höherer Schichten – wie Betriebssystem oder Hypervisor – kein unautorisierter Zugriff möglich ist. Die CPU übernimmt dabei nicht nur die Rollen der physisch-technischen Ausführung, sondern bildet auch den Kern eines sorgfältig definierten, möglichst kleinen vertrauenswürdigen Bereichs. Diese Reduktion auf ein klar abgegrenztes und überschaubares Set an Komponenten ist eine wesentliche Grundidee bei der Entwicklung sicherer Systeme.

Vertrauensbasis, Annahmen und Threat Model

Die Vertrauensbasis (Trusted Computing Base, TCB) beschränkt sich idealerweise auf wenige, genau kontrollierte Bestandteile. Die CPU und ihre direkten Sicherheitsmechanismen – einschließlich Firmware und ggf. Microcode – sollen dabei frei von Manipulationen sein. Das Threat Model berücksichtigt unter anderem:

1. Minimalität und Überprüfbarkeit: Die TCB ist absichtlich klein gehalten, um jede kritische Komponente sorgfältig prüfen zu können. Diese Begrenzung der Komplexität erleichtert es, potenzielle Schwachstellen systematisch zu identifizieren und zu beheben.

2. Isolierung trotz kompromittierten Host: Auch wenn der Host kompromittiert ist, bleibt die Enklave unzugänglich. Die CPU setzt die strikte Speicher- und Zugriffsisolierung durch, sodass externer Code, auch mit privilegierten Rechten, keinen direkten Zugriff auf die Daten in der TEE erhält.

3. Attestierung des Systemzustands: Die CPU bietet Mechanismen, um nachzuweisen, dass wesentliche Komponenten dem erwarteten Sicherheitsprofil entsprechen. So lassen sich etwa Firmware- oder Microcode-Versionen überprüfen, um sicherzustellen, dass die minimal gehaltene und kritische Basis nicht manipuliert wurde.

4. Begrenzte Reichweite gegenüber hochspezialisierten Angriffen: Obwohl Hardware-Techniken viele Angriffe erschweren, können extrem aufwändige physische oder Lieferketten-Angriffe nicht vollständig ausgeschlossen werden. Die Minimierung und transparente Gestaltung der TCB schafft aber eine solide Grundlage, um solche Angriffe zumindest deutlich zu erschweren.

Sicherheitsmerkmale der Enklave

• Datenvertraulichkeit: Nur autorisierter Code innerhalb der streng abgegrenzten Enklave hat Zugriff auf die Daten.

• Daten- und Codeintegrität: Die Hardwareisolierung gewährleistet, dass keine unautorisierten Änderungen von außen vorgenommen werden können.

• Attestierung: Die CPU erzeugt Nachweise über den Zustand der kritischen Komponenten. Diese Messungen ermöglichen es externen Instanzen, das System anhand definierter Referenzwerte zu validieren.

• Isolierung: Die Enklave trennt Code und Daten vollständig von anderen Prozessen, was durch die klar definierte und klein gehaltene TCB unterstützt wird.

Herausforderungen

• Angriffe auf die Vertrauenskette: Manipulationen an entscheidenden Hardwarekomponenten bleiben ein Risiko, wenngleich ihre Chancen durch die fokussierte, überprüfbare TCB sinken. Im Rahmen der Embargo-Prozesse haben die Hardware-Hersteller eine Reihe von Schritten eingefügt, um mögliche Exploits nur on-a-need-to-know-basis zu veröffentlichen. Diese verschiedenen Schritte starten mit der Hardware Plattform Produzenten, dann die Cloud Provider etc., wobei die Basis immer erweitert wird. Es wird zusätzlich Kunden angeboten, in einer früheren Phase informiert zu werden, um vorbereitet zu sein. Jeder Patch wird vorab mit einer Nummer spezifiziert. Diese Nummer zieht sich durch die verschiedenen Phasen durch. Durch die frühzeitige Information von Kunden ergibt sich für sie die Möglichkeit, Schritte der Mitigation vorzubereiten bzw. durchzuführen.

• Abhängigkeit von Hardwareherstellern: Die Sicherheit steht und fällt mit der Implementierung der Hersteller, deren Vorgehen bei Design, Produktion und Aktualisierung entscheidend ist.

• Komplexität und Expertise: Trotz Reduktion auf einen kleinen, überprüfbaren Kern ist es notwendig, dass die Implementierenden die Mechanismen gründlich verstehen und korrekt anwenden.

2. Nodes

Rolle im Confidential Computing

Nodes stellendie Ressourcen für Workloads bereit: Rechenleistung, Speicher und Netzwerk. Sie bilden damit eine wichtige Basis für Confidential Computing, da auf ihnen die jeweiligen Schutzmechanismen implementiert werden. Ob ein Node auf Bare Metal, in einer normalen VM oder als Confidential VM läuft, hat Einfluss auf die Art der Remote Attestation und den Grad der Isolierung.

Zwei grundsätzliche Betriebsmodelle für Nodes

1. Confidential Cluster

   • Gesamtes Betriebssystem in einer TEE

     Der Node läuft als „Confidential VM“ (z. B. Intel TDX oder AMD SEV-SNP). Dies bedeutet, dass selbst Angreifende mit privilegierten Rechten im darunterliegenden Host oder Cloud-Hypervisor keinen Einblick in den Klartextspeicher haben.

   • Measured Boot

     Um Manipulationen auszuschließen, werden Firmware und Betriebssystem beim Start gemessen. Ein Attestations-Service gleicht diese Messwerte mit Referenzwerten ab. Erst wenn alles passt, erhält der Node das Vertrauen und kann sensible Workloads ausführen.

   • Vorteil

     Alle Pods auf einem solchen Nodes erben automatisch den Schutz, ohne dass pro Pod zusätzliche Einrichtung erforderlich ist.

   • Nachteil

     Das Hostsystem muss TEE-fähige Hardware nutzen, was nur in bestimmten Cloud- oder Rechenzentrumsumgebungen verfügbar ist.

2. Confidential Containers

   • Node ohne TEE

     Der Host-Node läuft regulär (ggf. mit Secure Boot). Er stellt jedoch Pod-spezifisch eine kleine vertrauliche VM bereit, in der das eigentliche Workload-Betriebssystem gesichert wird.

   • Pro Pod eine Mini-VM

     Für Workloads mit erhöhtem Schutzbedarf wird beim Pod-Start eine eigenständige, hardwarebasierte TEE-Umgebung erzeugt. Ein sogenannter Key-Dienst überprüft dazu per Remote Attestation, ob das minimalistische Gastsystem unverändert ist, bevor Schlüsselmaterial freigegeben wird.

   • Vorteil

     Nur Pods, die tatsächlich Vertraulichkeit benötigen, laufen in einer verschlüsselten Umgebung. Andere Workloads können ungehindert auf derselben Infrastruktur betrieben werden. Trennung von Anwendungs-Administrator und Cluster-Administrator ist mit Confidential Containers möglich. Strikte Trennung von Verantwortlichkeiten. Zugang zu schützenswerten Daten feingranularer möglich.

   • Nachteil

     Das Zusammenspiel zwischen Container Runtime, Attestation Service und Key Broker Service (KBS) erfordert einen komplexen Workflow. Zudem wird jede vertrauliche Mini-VM einzeln attestiert.
     Ein Problem bei Confidential Containers ist, dass die nicht vertrauenswürdige Control Plane dem Guest-Agenten innerhalb der geschützten VM potenziell bösartige Befehle erteilen könnte. Um dies abzusichern, wird im Guest-Agenten eine vom Nutzer definierte Execution-Policy mittels einer Policy-Engine wie OPA (Open Policy Agent) durchgesetzt, die jeden Befehl des Hosts prüft und blockiert, falls er nicht der Policy entspricht. Der entscheidende Sicherheitsanker ist, dass ein Hash dieser Policy imAttestierungs-Bericht verankert wird. So können externe Dienste sensible Daten (z. B. Schlüssel) nur dann freigeben, wenn sie kryptografisch sicher sein können, dass die VM mit der korrekten und sicheren Policy läuft.

Sichere Node-Verwaltung

• Automatisiertes Deployment

  Die Einrichtung von Nodes sollte über Infrastructure as Code erfolgen, damit jederzeit reproduzierbare und überprüfbare Zustände entstehen.

• Kontinuierliche Prüfung

  Ein Node kann periodisch oder mindestens beim Start seine relevanten Komponenten messen. Werden Abweichungen erkannt, ist der Node nicht mehr vertrauenswürdig und darf keine sensiblen Daten verarbeiten.

• Minimalistische Ausführung

  Wenige Admin-Tools, eingeschränkte Systemrechte (Least Privilege) und reduzierter Netzwerkzugriff senken das Risiko, dass Innentäter oder Schadsoftware das System manipulieren.

• Dynamisches Hinzufügen und Entfernen

  Neue Nodes werden attestiert, bevor sie in den Cluster aufgenommen werden. Bei Kompromittierungsverdacht lässt sich ein Node isolieren oder vollständig löschen.

Schlüsselmanagement und Rollenverteilung

Um zu verhindern, dass sensible Informationen bereits im Boot-Prozess an Unbefugte gelangen, nutzen viele Deployments einen Key Broker Service (KBS) und einen separaten Attestation-Dienst. Erst wenn eine Node oder eine Pod-VM erfolgreich attestiert wurde, stellt der KBS Schlüssel oder Secrets bereit. Diese Trennung von Rollen (Node-Betrieb, Attestation, Schlüsselverwaltung) erhöht die Gesamt­sicherheit, weil mehrere Instanzen unabhängig voneinander validieren, ob eine Umgebung vertrauenswürdig ist.

Fazit Nodes

• Nodes sind elementarer Bestandteil des Confidential-Computing-Stacks. Die Art und Weise, wie sie abgesichert und attestiert werden, entscheidet maßgeblich über das Schutzniveau.

• Confidential Cluster ist ein Ansatz, bei dem das gesamte Node-Betriebssystem hardwareseitig isoliert wird. Dies vereinfacht die Verwendung für alle Workloads, setzt aber TEE-fähige Systeme voraus.

• Confidential Containers ermöglicht eine zielgerichtete Absicherung einzelner Pods. Das Hostsystem bleibt weitgehend unverändert, doch erhöht sich die Komplexität, da jeder Pod eine eigene TEE-VM durchläuft.

• Measured Boot und Remote Attestation sorgen dafür, dass nur geprüfte und unveränderte Nodes oder Pod-VMs überhaupt auf sensible Daten zugreifen dürfen.

• Key-Dienste und Rollenmodell führen zu einer feingranularen Vergabe von Sealed Secrets, was Insider- oder Betriebssystem-Angriffe deutlich erschwert.

Insgesamt tragen solide Node-Verwaltung, automatisiertes Deployment, regelmäßige Attestation und eine klare Trennung von Verantwortlichkeiten dazu bei, die Sicherheit im gesamten Stack zu erhöhen.

3. Netzwerk

Rolle des Netzwerks im Confidential Computing

Zwischen Relying Party, Attester und Verifier werden über Netzwerk relevante Daten zur Attestierung ausgetauscht. Das Netzwerk hat auf unterschiedlichen Schichten unterschiedliche Möglichkeiten der Absicherung.

Die klassische Trennung von Sicherheitszonen erfordert die Einrichtung von getrennten Netzwerken auf den unteren Netzwerkschichten, wie z.B. auf OSI Layer 2 eine Segmentierung mit VLAN. Auf den höheren Schichten muss die Abschottung durch Routing und BGP (Border Gateway Protocol) erreicht werden. Der Ansatz von Zero Trust Network Access verlangt eine Absicherung mit mTLS (mutual TLS) und zieht die gesamte Transport Layer Security in die TCB. Hier ist wichtig, dass das dort notwendige etablierte Zertifikatsmanagement richtig implementiert wird. Der Lebenszyklus der Zertifikate muss vollständig und richtig definiert werden. Es muss definiert werden, wie das Vertrauen zur Root CA aufgebaut wird und wie die Kommunikation mit dem KBS erfolgt.

Verbesserungen

Die Kommunikation muss sichere Datenkanäle etablieren. Das Netzwerk muss als Software Defined Network durch Infrastructure as Code konfigurierbar sein. Idealerweise muss die Netzwerkinfrastruktur vollständig mit Open Source aufgebaut werden, z.B. mit SONiC Linux, das ebenfalls auf Confidential Computing umgestellt wird.

Herausforderungen

Die einzurichtenden Prozesse sind alle bekannt, aber in ihrer Anzahl schwierig und nicht immer einfach in existierenden Umgebungen einzusetzen.

• Der initiale Key Exchange sollte ohne feste Root Zertifikate, z.B. mit dem Jose Protokoll zu einem Tang Server Chapter 10. Configuring automated unlocking of encrypted volumes by using policy-based decryption | Red Hat Product Documentation durchgeführt werden.

• Zero Trust Network Access mit Hardware Security Modulen (HSM) sollte als Public Key Infrastructure (PKI) etabliert werden.

• Das HSM muss unter der Kontrolle des Kunden stehen.

• Der Kunde muss auch die Kontrolle über die Algorithmen und die Schlüssel haben.

• Schlüssel müssen definiert und regelmäßig getauscht werden, z.B. mit ACME RFC 8555. Die ACME Infrastruktur muss genauso in die Betrachtung einbezogen werden und unter der Kontrolle des Kunden stehen.

• Es muss sehr genau definiert werden, was Ende zu Ende Verschlüsselung bedeutet, die Endpunkte müssen genau definiert werden und in der TCB idealerweise selbst wieder im Confidential Computing abgesichert werden.

4. Infrastruktur

Rolle der Infrastruktur

Alle Komponenten der Infrastruktur sollten erfasst sein. Neben der oben beschriebenen Netzwerkinfrastruktur wie Netzwerk Switches und Routern gilt das auch für Storage Systeme und physische Systeme

Verbesserungen

• Einbeziehung von Data-at-Rest über bereits existierende verteilte Storage Systeme wie Ceph mit Tang

• Das gleiche müsste auf physische Systeme ausgedehnt werden, wie hier beschrieben GitHub - marinasundstrom/AccessControl: For Fun Physical Access Control system (door lock and alarm) - built with .NET , ASP.NET Core, and Azure services. Raspberry Pi.

• Physische Infrastruktur sollte auch als Infrastructure als Code implementiert werden.

• Wenn die Attestierung beweisbar sein soll, muss sie auch als IaC implementiert werden

• Durch Zugriffskontrolle kann garantiert werden, dass keine nachträgliche Hardware Manipulationen durchgeführt wurden.

Herausforderungen

• Sehr viele Komponenten, nicht alle sind relevant.

• Umfassende Sicherheitsrichtlinien müssen überarbeitet werden

• Darstellung der Attestation als Prozess mit Trustee und ihn beweisbar sicher machen

5. Betrieb

Rolle des Betriebs

Die Sicherheit der Betriebsabläufe muss auf die gleiche Stufe wie die Absicherung aller anderen Aspekte angehoben werden. Beispielsweise sollte für jede Rolle ein eigener Administrator eingesetzt werden.

Es ist vorteilhaft, den Betrieb vollständig zu automatisieren, um Einfallstore durch Mitarbeiteraktionen zu begrenzen. Das schließt die Konfiguration von Compute, Storage, Netzwerk und aller anderen Infrastruktur mit ein.

Ebenso sollte das Identity and Access Management vollständig feingranular und automatisiert erfolgen. Monitoring und Alerting sind ebenso einzubeziehen wie Incident Management und Change Management.

Verbesserung

Dazu gehört eine weitgehende Umstellung der Prozesse auf DevSecOps Standards (bspw. DevSecOps – DoD Cyber Exchange). Nur signierte Artefakte und Konfigurationen dürfen ausgerollt werden. SLSA erlaubt eine Nachvollziehbarkeit, die Kontrolle über die Integration aller Artefakte.

Weiter erlaubt es die Möglichkeit der definierten Zugriffskontrolle und ihrer automatischen Überwachung, da Zugriffsrechte als Konfigurationen aus einem Git Repository abgeleitet werden können.

Ein großer Schwachpunkt in existierenden Systemen ist die mangelnde Vollständigkeit von

Monitoring und Alerting. Eine starke Verbesserung wäre eine Alarmierung, die mit einem definierten API in ein Git basiertes Ticket System schreibt und weiter in externe Ticket- und Alarmsysteme.

Herausforderungen

Die Aufgabe ist komplex und hat mit Confidential Computing erst einmal keine direkten Berührungspunkte.

Es gibt teilweise viele existierende konkurrierende Lösungen und Komponenten, dementsprechend gibt es viel Marketing für nicht zielführende Lösungen. Hier müssen Interfaces definiert werden, die von verschiedenen Lösungen implementiert werden, um Monitoring einfach und austauschbar in Prozesse zu integrieren.

Zero Privileges

Unter Zero Privileges oder Zero Admin ist eine Verwaltung zu verstehen, die für bestimmte Komponenten keine Änderungen zulässt. Ein Node kann von den Administratoren nur erzeugt oder abgerissen werden (CREATE und DELETE). Änderungen sind nur über ein Git Repository möglich, nicht über manuelle Prozesse wie SSH logins. UPDATE sind ausgeschlossen.

Verbesserung

Auch hier kann Confidential Computing die Lage deutlich verbessern, weil eine Aufteilung in Anwendungen innerhalb und außerhalb der TCB auch eine Aufteilung der Rollen im Betrieb erlaubt. Dadurch lassen sich alle Prozesse auch gegen Innentäter schützen. Die Update Prozesse außerhalb der TCB für den Hardware Betrieb lassen sich von den Prozessen zum Betrieb innerhalb der TEE trennen.

Herausforderungen

Zero Admin und TEEs stellen die Betriebsmannschaften vor neue Herausforderungen, weil sie sich auf einen weitgehend automatisierten Betrieb einstellen müssen. Das bedeutet, dass alle Prozesse auf GitOps ausgerichtet sind. Insbesondere Quick Fixes sind dann nicht mehr möglich. Für diese Aufgaben müssen die Operations Mannschaften erst trainiert werden. Die Vielzahl von Änderungen bedeutet permanentes Ausrollen von Updates, alle paar Tage oder sogar mehrfach am Tag. Dafür müssen die Anwendungen ausgelegt sein.

Um diese Dynamik umzusetzen, brauchen Cluster eine Mindestgröße, um damit flüssig zu arbeiten. D.h. Viele kleine Nodes sind besser als wenige große.

Firmware-Updates und Updates der Attestierungssoftware müssen auf demselben Weg zeitnah, d.h. innerhalb weniger Tage, ausgerollt werden. Das stellt die Betreiber der Cluster vor Herausforderungen, weil auch Tests, eventuell auf spezieller Hardware oder in neuen Kombinationen durchgeführt werden müssen.

Im OpenShift und Kubernetes Umfeld müssen diese Updates mit den Cloud Native Mechanismen für Bare Metal Hosts möglich sein. Firmware Updates sind dann Teil des Betriebssystem Images, die durch Hardware Profile definiert sind.

6. PKI

In Confidential Computing: Hardware-Based Trusted Execution for Applications and Data Seite 9 werden “Keys, Secrets, Credentials and Tokens Storage and Processing” und die Verwaltung in einem HSM angesprochen. Das bedeutet, dass für die Verwaltung von Credentials eine eigene Betrachtung notwendig ist. Weil mit der Sicherheit dieser TCB die Sicherheit des Gesamtsystems steht und fällt, müssen hier die höchsten Kriterien angelegt werden.

Hardware Security Module (HSMs) müssen deswegen unter der Kontrolle der Betreiber stehen, die einen sicheren Betrieb garantieren müssen. Deswegen sind hier die höchsten Maßstäbe der Entwicklung anzulegen.

HSMs sollten deswegen einen bewiesenen Microkernel und keinen Linux Kernel haben und jede Komponente sollte Open Source sein, z.B. NetHSM mit einem Microkernel von Muen.

Hier ist Beweisbarkeit auf Common Criteria auf Level 7 anzustreben und tatsächlich möglich, z.B. mit dem NOVA Microhypervisor, der mit dem Coq Proof Assistant bewiesen worden ist.

7. Benutzer der TEE

Es mag vielleicht überraschen, aber auch auf der Anwenderschicht gibt es eine TCB. Es gibt neue Aufgaben wie Absicherung der Verwaltung der Attestierung. Die Gruppe der Leute, die diese Absicherung leisten kann, sollte deutlich kleiner sein als die Standardadministration. Es sollte auch keine Vermischung von Rollen stattfinden. Administratoren der Attestierung sollten keinen Zugang zur eigentlichen Hardware haben und umgekehrt. Damit wird ausgeschlossen, dass die Fähigkeit, die Attestierung zu manipulieren, z.B. über das Zurückhalten von Firmwareupdates und Zugriff auf die Hardware zu einem Bruch der TEE-Umgebungen führt.

Weitere Massnahmen sind persönliche Sicherheitsüberprüfungen und mindestens vier Augenprinzip.

Angriffsvektoren auf TEEs

Die Sicherheit von Trusted Execution Environments (TEEs) ist nicht absolut und wird kontinuierlich von Forschern analysiert. Angriffe lassen sich grob in zwei Hauptkategorien einteilen: solche, die die Hardware-Isolation direkt durchbrechen, und solche, die über Seitenkanäle Informationen aus der geschützten Umgebung ableiten.

Angriffe auf die TEE-Isolation

Diese Angriffe zielen darauf ab, die fundamentalen Sicherheitsgarantien der TEE-Hardware (wie Speicherverschlüsselung und Integritätsschutz) zu umgehen oder auszuhebeln. Sie erfordern in der Regel einen hochprivilegierten Zugriff auf das System (z. B. als Hypervisor) oder sogar physischen Zugriff auf die Hardware.

• Fault-Injection-Angriffe (z. B. Plundervolt): Hierbei werden durch gezielte Manipulation der CPU-Spannung Fehler in Berechnungen innerhalb der Enklave provoziert. Dies kann dazu führen, dass kryptografische Schlüssel oder andere Geheimnisse fehlerhaft verarbeitet und offengelegt werden.

• Angriffe durch spekulative Ausführung (z. B. Foreshadow): Diese nutzen die spekulative Ausführung moderner CPUs aus, um die Speichergrenzen einer TEE zu verletzen und auf schützenswerte Daten zuzugreifen, bevor die CPU den unzulässigen Zugriff erkennt und erneut einschränkt macht.

• Manipulation der Speicherintegrität (z. B. BadRAM, CacheWarp): Bei BadRAM wird dem System über manipulierte Hardware-Informationen (SPD-Chip auf dem RAM-Modul) vorgetäuscht, dass verschiedene Speicheradressen auf demselben physischen Speicher zeigen (Aliasing). Dies kann den Integritätsschutz von AMD SEV-SNP untergraben. CacheWarp nutzt Schwachstellen aus, um den Zustand einer VM auf einen früheren Zeitpunkt zurückzusetzen (Rollback), ohne dass die Integritätsprüfung dies bemerkt.

Die Hersteller reagieren auf solche Angriffe in der Regel mit Microcode-Updates, Firmware-Patches und neuen Hardware-Revisionen, welche die zugrunde liegenden Schwachstellen beheben.

Seitenkanalangriffe

Im Gegensatz zu direkten Angriffen auf die Isolation brechen Seitenkanalangriffe diese nicht. Stattdessen beobachten sie Nebeneffekte der Programmausführung, um Rückschlüsse auf die verarbeiteten, geheimen Daten zu ziehen.

Beispiele für beobachtbare Kanäle sind:

• Cache-Timing: Analyse, wie lange Speicherzugriffe dauern, um herauszufinden, ob Daten im schnellen CPU-Cache lagen.

• Page Faults: Beobachtung von Speicherseitenfehlern, um die Speicherzugriffsmuster einer Anwendung zu rekonstruieren.

• Ciphertext Side Channels: Analyse von Mustern in verschlüsselten Daten, die bei unsicherer Implementierung Rückschlüsse auf den Klartext erlauben.

Ein entscheidender Punkt ist, dass die TEE-Hardware allein oft keinen Schutz vor diesen Angriffen bietet. Die Verantwortung liegt hier maßgeblich beim Software-Entwickler, der seine in der TEE laufende Anwendung härten muss, z. B. durch die Implementierung von konstantzeitlichen Algorithmen, die unabhängig von den Eingabedaten immer gleich lange für ihre Ausführung benötigen.

Fazit

Trotz dieser fortgeschrittenen Angriffe markiert Confidential Computing einen deutlichen Fortschritt gegenüber klassischen VMs, da selbst privilegierter Code von Cloud-Betreibern üblicherweise nicht direkt auf die verschlüsselten Workloads zugreifen kann. Die genannten Attacken sind meist hochspezialisiert und erfordern erhebliche Ressourcen, wie sie tendenziell bei Geheimdiensten oder sehr versierten Research-Gruppen zu finden sind. Ein „normaler“ Administrator oder Cloud-Anbieter ohne spezielles Labor wird kaum die Mittel haben, solche Lücken zielgerichtet auszunutzen. Daher bietet die Kombination aus hardwarebasierter Isolation und Remote Attestation gerade für hochsensible Workloads einen deutlichen Sicherheitsgewinn. Viele Organisationen können damit erstmals Anwendungen und Daten in Umgebungen betreiben, die ihnen zuvor zu unsicher erschienen – etwa bei streng regulierten Branchen oder besonders vertraulichen Forschungsprojekten. Wichtig bleibt jedoch, Firmware und Microcode aktuell zu halten, physische Zugriffe zu kontrollieren und bei Seitenkanalrisiken achtsam zu sein..

In letzter Zeit zeichnet sich ebenfalls ab, dass Confidential Computing in Use Cases von Vorteil sein kann, die sich auf das eigene Datacenter konzentrieren. Hierbei wird die Möglichkeit geschaffen, den Zugriff und die Sicherheit von Umgebungen auf eine kleine Gruppe von Personen zu beschränken. Dabei wird die Attestation der internen Services auf eine Hochsicherheitszone beschränkt, in denen spezielle Mechanismen eingefügt werden, wie zum Beispiel das 4 Augen Prinzip bei administrativen Veränderungen oder Zugang nur mit 2 Schlüsseln zu den Serverräumen. Diese speziellen Mechanismen sind für den normalen Betrieb zu aufwändig, führen bei der Verwendung in diesen Szenarien aber zu einer erheblichen Steigerung des Aufwands, die Vorkehrungen zu überwinden.

Weiterführende Literatur:

1. FRR-k8s as a BGP backend for MetalLB

2. Beispiel Payments

---

• ← Previous Post
• Next Post →