Autoren: Thomas Fricke, Axel Sass, Jens Freimann

Management Zusammenfassung

Management Summary: Confidential Computing im Überblick

Confidential Computing ist eine vergleichsweise neue, jedoch zunehmend wichtige Technologie zur Absicherung vertraulicher Daten während ihrer Verarbeitung. Sie ermöglicht geschützte Ausführungsumgebungen (Enklaven), in denen Daten nur von autorisierten Prozessen eingesehen bzw. verändert werden können. 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 Enklaven 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.

  • Sinkende Hardware Risiken
    Zwar entstehen weiterhin gelegentlich Lücken, doch meist in älteren Bestandteilen der Hardware. 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- und Cloud-Anbietern.

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

Empfehlungen

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

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

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

  4. 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.

  5. 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 Inhalten von Dateien (Data at Rest) und das Schützen von Inhalten während des Transfers im Netzwerk (Data in Transit). Das Schützen von Daten während der Ausführung ist eine neue Komponente. Erstmals nimmt darauf der Operational Resiliency Act (DORA) Rücksicht.

Aus der Zusammenarbeit von Hardwareherstellern, Cloud Providern und Softwareanbietern hat sich das Confidential Computing Consortium gebildet, das sich die Standardisierung dieser technischen Möglichkeit von Confidential Computing zum Ziel gesetzt hat. ([https://confidentialcomputing.io/]{.underline}) Wie können diese neuen Mechanismen Unternehmen helfen, Ihre 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 Trusted Execution Environments (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.

Das betrifft die folgenden Komponenten auf unterschiedliche Weise

Die Enklave erlaubt, eine Grenze zwischen Prozessen und ihren Daten in der Enklave, die Teil der 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)

Vertrauen auf die Sicherheit entsteht nicht aus dem Nichts. Es bedarf einer nachvollziehbaren Kette des Vertrauens (Chain of Trust) mit einem Ursprung (Root of Trust). Bei dieser Quelle handelt es sich um eine Umgebung, der der Nachfrager nach diesem sicheren Dienst vertrauen muss. Mit ihr steht und fällt das gesamte Konzept des Confidential Computings. Meist wird hier eine Hochsicherheits-Umgebung innerhalb der etablierten Datacenter gewählt, die derzeit bereits durch andere Unternehmens- und regulatorische Prozesse streng kontrolliert wird. In dieser Zone werden Dienste bereitgestellt, die für den Betrieb einer Confidential Computing Umgebung notwendig sind. Zum Beispiel kann aus dieser sicheren Zone mit Hilfe der Attestation das Vertrauen auf andere Bereiche ausgedehnt werden.

[]{.mark}

Die Trusted Computing Base - TCB ist ursprünglich eine Einteilung von Unix Prozessen in vertrauenswürdige “trusted” Teile und nicht vertrauenswürdige “untrusted” Teile. Der “trusted” Anteil soll vollständig kontrolliert und klein sein. Die Sicherheit des Systems darf nicht kompromittiert werden, wenn im “untrusted” Anteil ein Angriff versucht wird. Das ursprüngliche Paper [Design and Verification of secure systems]{.underline} beschreibt diese Aufteilung sehr genau.

Das Konzept lässt sich verallgemeinern, auch über den technischen Teil hinaus.

Confidential Computing-fähige CPUs ermöglichen den Betrieb von Enklaven (Trusted Execution Environments, TEEs), die streng isolierte Bereiche innerhalb des Prozessors bereitstellen. Alle Enklaven teilen die Hardware und das Betriebssystem als TCB auf. Dem eigenen Prozess mit eigener Software wird vertraut, dem Betriebssystem, dem Hypervisor und der Umgebung nicht. Um sicherzustellen, dass die komplexe Umgebung der CPU mit Memory, Firmware und Legacy die Anforderungen erfüllt, muss eine Attestierung dieser Komponenten stattfinden, die ebenfalls vertrauenswürdig sein muss. Das gilt auch für den Prozess des Audits der Firmware und der Installation des Microcodes auf der ausführenden CPU.

Dabei muss die Einteilung für jede Schicht wiederholt werden. Die TCB im Betrieb verwendet die TCB der Infrastruktur. Nur wenn der sichere Betrieb gewährleistet ist, kann die Sicherheit der Infrastruktur überhaupt zum Zug kommen. Umgekehrt gilt auch, dass ein sicherer Betrieb auf unsicherer Infrastruktur unmöglich ist.

Trusted Execution Environment (TEE)

Unter einem Trusted Execution Environment (TEE) verstehen wir hier im Sinne des [Confidential Computing Consortium Scope]{.underline} ausschließlich die Hardware TEE auf der Haupt-CPU. Die TEE wird durch die Hardware CPU implementiert. Mit ihr werden Zugriffsrechte auf den darin verwendeten Speicher (RAM) und Sichtbarkeit geregelt. Nur bestimmte Prozesse dürfen auf diesen Speicherbereich zugreifen und Werte dort einsehen und verändern. Alle nicht zugelassenen Zugriffe führen dazu, dass auf eine derartige Anfrage das Ergebnis mit Nullen gefüllt (zum Beispiel bei Intel TDX, ebenso AMD) zurückgegeben wird. Ebenfalls wird durch intern generierte Schlüssel der Inhalt zusätzlich verschlüsselt.

Hier gibt es Untersuchungen der CPU-Produzenten welche Angriffsvektoren derzeit bekannt sind und wie diese verhindert werden ( siehe “Offensive Security Research Topics” in [https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/tdx-security-research-and-assurance.html#articleparagraph_1011087405]{.underline} )

Attestation

Um die Zone des Vertrauens auszudehnen, muss sichergestellt werden, dass der neu hinzugekommene Bereich ebenfalls die gleichen Anforderungen erfüllt wie die Trusted Computing Base (TCB). Unter Attestation ist die sicherheitsrelevante Überprüfung von externen Infrastrukturkomponenten gemeint. Alle Komponenten der Attestierung sind im TCB, dazu gehören auch der Transport über die Netze, die Software und die Updateprozesse. Hier sollte dringend ein vollautomatischer Mechanismus aufgesetzt werden. Zertifikatsalgorithmen und Schlüssel müssen durch die Anwender kontrolliert werden, um Hintertüren zu vermeiden. Im Rahmen der Attestierung werden Beweise gesammelt und an einen Attestation Service geschickt, der dann diese Information überprüft, mit bereits gesammelten Informationen vergleicht und daraufhin die Sicherheit attestiert.

Attestation ist immer dann notwendig, wenn zu schützende Informationen bzw. zur Entschlüsselung notwendige Schlüssel an die TEE gesendet werden sollen. Da es sich häufig um große Datenmengen handelt, wird meist der Weg gewählt, in dem die Daten zuerst in der TCB verschlüsselt werden, und diese dann an die TEE gesendet werden. Dann, wenn auf die Daten zugegriffen werden soll, wird ein Schlüssel an die Umgebung gesendet. Dieser Vorgang wird nur durchgeführt, wenn zuvor eine Attestation erfolgreich durchgeführt wurde.

Hierbei wird unterschieden zwischen Remote und 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 bzw. den Nachfrager des Services selbst zur Verfügung gestellt werden. Dieser Service befindet sich dann zum Beispiel ebenfalls in der TCB und wird dementsprechend Remote Attestation Service bezeichnet.

{width=“6.5in” height=“1.9444444444444444in”}

[]{.mark}

In der abgebildeten Darstellung wird als Attestation Service das OpenSource Projekt Trustee (https://github.com/confidential-containers/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.

  • Dieser übermittelten Werte werden mit in dem Verifier Service gespeicherten Werten verglichen.

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

  • Daraufhin wird der notwendige Schlüssel zur Entschlüsselung der Komponente an die TEE versendet und die Komponente kann 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 Bootenen

\[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 vielen Teilen (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.

{width=“6.5in” height=“2.7222222222222223in”}

Die Separation von Verantwortung im Details

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 [https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/tdx-security-research-and-assurance.html]{.underline}

Umso wichtiger ist Trusted 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, die nahe an der Produktion in Arztpraxen, Fabriken, 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

  • 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

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 der “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 tendieren sie meist eher dazu, ihre gesamten kritischen Infrastrukturen in einem eigenen Datacenter zu betreiben, sehen 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. (https://cc-enabling.trustedservices.intel.com/intel-tdx-enabling-guide/02/infrastructure_setup/#on-offline-manual-multi-platform-pccs-based-indirect-registration)

Ein weiterer Bereich, wo Enklaven 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 im Feld 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 Parameter zu sehen. Das gilt insbesondere, wenn die Anforderungen an die Sicherheitsstufen hoch oder sehr hoch sind.

1. CPU und Enklave

Rolle der CPU und der Enklave

Die CPU ermöglicht den Betrieb von Enklaven (Trusted Execution Environments, 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 Enklaven Daten 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. Knoten

Rolle im Confidential Computing

In einer Kubernetes-Umgebung stellen Knoten (Nodes) die 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 Knoten 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]{.underline}. 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 Knoten 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.

    • **Nachteil
      **Das Zusammenspiel zwischen Container Runtime, Attestation Service und Key Broker Service (KBS) erfordert einen komplexeren Workflow. Zudem wird jede vertrauliche Mini-VM einzeln attestiert.

Sichere Knotenverwaltung

  • **Automatisiertes Deployment
    **Die Einrichtung von Nodes sollte über Pipelines (Infrastructure as Code) erfolgen, damit jederzeit reproduzierbare und überprüfbare Zustände entstehen.

  • **Kontinuierliche Prüfung
    **Ein Knoten 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 Knoten

  • Knoten 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 Secrets, was Insider- oder Betriebssystem-Angriffe deutlich erschwert.

Insgesamt tragen solide Knotenverwaltung, automatisiertes Deployment, regelmäßige Attestation und eine klare Trennung von Verantwortlichkeiten dazu bei, die Sicherheit im gesamten Stack spürbar 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]{.underline} (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 Configuration as Code konfigurierbar sein. Idealerweise muss die Netzwerkinfrastruktur vollständig mit Open Source aufgebaut werden, z.B. mit [SONiC]{.underline} Linux, das ebenfalls auf Trusted 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]{.underline} durchgeführt werden.

  • Zero Trust Network Access mit HSM sollte als 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 Trusted 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

**Herausforderungen
**

  • Sehr viele Komponenten, nicht alle sind relevant.

  • Umfassende Sicherheitsrichtlinien müssen überarbeitet werden

  • Darstellung des Attestation als Prozess mit Trustee und den Attestierungsprozess 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 Rollout von Software und Konfigurationen.

Verbesserung

Dazu gehört eine weitgehende Umstellung der Prozesse auf DevSecOps Standards [DevSecOps – DoD Cyber Exchange]{.underline}. Nur signierte Artefakte und Konfigurationen dürfen ausgerollt werden. [SLSA]{.underline} 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 Trusted 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 Enklaven trennen.

Herausforderungen

Zero Admin und Enklaven 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 dafür 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 nicht ganz einfache 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]{.underline} 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]{.underline} mit einem Microkernel von [Muen]{.underline}.

Hier ist Beweisbarkeit auf Common Criteria auf Level 7 anzustreben und tatsächlich möglich, z.B. mit dem [NOVA Microhypervisor]{.underline}, der mit dem [Coq Proof Assistant]{.underline} 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 Enklavenumgebungen führt.

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

8. Angriffsvektoren

Angriffe auf AMD SEV-SNP – Beispiel

**
**Die [„BadRAM-Attacke"]{.underline} richtet sich gegen AMDs Secure Encrypted Virtualization mit Secure Nested Paging (SEV-SNP) auf EPYC-Prozessoren. Hierbei wird der SPD-Chip (Serial Presence Detect) von DRAM-Modulen manipuliert, sodass Speicheraliasing entsteht und die Integritätssicherung umgangen werden kann. Der Angreifer könnte so Memory-Replay oder Rollbacks auslösen und damit die VM-Abläufe beeinflussen. Dieser Angriff erfordert zumeist physischen oder privilegierten Host-Zugriff und ist daher in realen Szenarien eher fortgeschrittenen Akteuren mit erheblichem Aufwand vorbehalten. Dennoch sollten Firmware-Updates und physische Sicherheitskontrollen konsequent umgesetzt werden, um solche Methoden weiter zu erschweren.

Angriffe auf Intel TDX

Bei Intel Trusted Domain Extensions (TDX) existieren Seitenkanaltechniken wie [„Stumble Stepping"]{.underline}, bei denen die CPU künstlich verlangsamt wird, um kryptografische Operationen feingranular zu beobachten. Intel reagiert hierauf mit Microcode-Patches,i und zusätzliche Software-Härtungen (etwa konstant laufende Krypto-Algorithmen) minimieren das Risiko. Auch frühe TDX-Versionen enthielten kritische Schwachstellen im ACM (Authenticated Code Module), die den Kern der Speicherisolation beeinträchtigen konnten. Regelmäßige Sicherheits-Patches bleiben daher unverzichtbar.

Weitere Lücken in AMD SEV-SNP

Obwohl SEV-SNP durch RMP (Reverse Map Table) und Memory Integrity gestärkt ist, zeigen Angriffe wie CacheWarp, dass Replay- oder Timewarp-Szenarien weiterhin ein Risiko sind. Diese Attacken setzen oft die Kompromittierung des Host-Systems oder Admin-Rechte voraus. Cloud-Betreiber mit hoher Privilegierung könnten theoretisch solche Techniken anwenden, benötigen aber erhebliche Fachkenntnisse und teils physische Modifikationen. Hersteller und Betreiber reagieren im Normalfall mit Microcode-Updates und striktem Policy Enforcement.

Allgemeine Angriffe auf TEEs

Neben TDX und SEV-SNP demonstrierten Forschungen zu Intel SGX, dass Seitenkanäle (Cache, spekulative Ausführung) oder physische Störungen (Rowhammer, Spannungsmanipulation) die Vertraulichkeit in Enklaven angreifen können. Beispiele sind [Foreshadow]{.underline} oder [Plundervolt]{.underline}, die SGX-Enklaven aushebeln konnten. SGX wird von TDX abgelöst, daher sind Angriffe gegen SGX nicht mehr nutzbar. Meist ist hierfür tiefer Eingriff in Hardware oder privilegierter Host-Zugriff nötig. Trotzdem verdeutlichen solche Szenarien, dass selbst hardwarebasierte Isolierung kein absolut lückenloser Schutz ist.

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 erheblichen Ressourcenaufwand, wie er 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. So erschließt Confidential Computing neue Einsatzszenarien, ohne jedoch das sorgfältige Sicherheitsmanagement abzulösen.

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 würde 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” [https://www.redhat.com/en/blog/frr-k8s-bgp-backend-metallb]{.underline}

2.