Die ungelöste Herausforderung: Schutz von Daten in der Nutzung

In der heutigen datengetriebenen Welt sind Maßnahmen zum Schutz von Informationen von entscheidender Bedeutung. Traditionell konzentriert sich die Cybersicherheit auf zwei Hauptbereiche: den Schutz von Daten im Ruhezustand (Data at Rest) durch Verschlüsselung auf Speichermedien und den Schutz von Daten während der Übertragung (Data in Transit) durch Protokolle wie TLS/SSL. Diese Bereiche sind gut etabliert und bieten robuste Lösungen. Eine kritische Lücke bleibt jedoch oft bestehen: der Schutz von Daten während der Nutzung (Data in Use). Sobald Daten von einer Anwendung verarbeitet werden, müssen sie entschlüsselt und für die CPU zugänglich sein. In diesem Zustand können sie potenziell von privilegierten Softwarekomponenten wie Betriebssystemen, Hypervisoren oder sogar Cloud-Administratoren eingesehen oder manipuliert werden. Hier setzt Confidential Computing an, um diese fundamentale Sicherheitslücke zu schließen.

Confidential Computing ist ein Paradigma, das darauf abzielt, Daten, Code und die Laufzeitumgebung vor unbefugtem Zugriff und Manipulation zu schützen, selbst wenn sie in einer potenziell kompromittierten Infrastruktur ausgeführt werden. Der Kern dieser Technologie liegt in der Nutzung von hardwarebasierten Trusted Execution Environments (TEEs), die eine isolierte und überprüfbare Ausführungsumgebung für sensible Workloads bieten.

Grundlagen des Vertraulichen Rechnens und Trusted Execution Environments (TEEs)

Confidential Computing, oft auch als vertrauliches Rechnen bezeichnet, ermöglicht es, sensible Daten und Anwendungen in einer sicheren, hardwaregeschützten Umgebung auszuführen. Das primäre Ziel ist es, die Vertraulichkeit und Integrität von Daten und Code zu gewährleisten, selbst wenn der Host-Anbieter oder andere privilegierte Software auf dem System nicht vollständig vertrauenswürdig ist. Dies ist besonders relevant für Cloud-Umgebungen, in denen Kunden ihre Workloads auf gemeinsam genutzter Infrastruktur ausführen, die vom Cloud-Anbieter verwaltet wird.

Was sind Trusted Execution Environments (TEEs)?

Ein Trusted Execution Environment (TEE) ist ein gesicherter Bereich innerhalb eines Prozessors, der ein höheres Maß an Sicherheit als der Rest des Systems bietet. Es handelt sich um eine isolierte Umgebung, die durch Hardwaremechanismen geschützt ist und in der Daten und Code vor externen Zugriffen – selbst von privilegierten Softwarekomponenten wie dem Betriebssystem oder dem Hypervisor – abgeschirmt sind. Die wichtigsten Eigenschaften von TEEs sind:

  • Isolation: Code und Daten, die innerhalb eines TEE ausgeführt werden, sind von der restlichen Systemsoftware isoliert.
  • Speicherverschlüsselung: Der Speicherbereich, der von einem TEE genutzt wird, ist hardwareseitig verschlüsselt, bevor er den DRAM verlässt. Dies verhindert, dass jemand durch Auslesen des Speichers sensible Informationen erhält.
  • Integrität: Die Hardware stellt sicher, dass der Code innerhalb des TEE nicht manipuliert werden kann und dass die Daten, die verarbeitet werden, intakt bleiben.
  • Attestierung: TEEs bieten die Möglichkeit, ihre Identität, Konfiguration und den geladenen Code kryptografisch zu beweisen. Dies ermöglicht es einer externen Partei (oder dem Benutzer), die Integrität und Authentizität des TEE zu überprüfen, bevor sensible Daten an es gesendet werden.

Bekannte Beispiele für TEE-Technologien sind Intel Software Guard Extensions (SGX), AMD Secure Encrypted Virtualization (SEV) und ARM TrustZone. Jede dieser Technologien hat ihre eigenen Merkmale und Anwendungsbereiche, aber das grundlegende Prinzip der hardwaregestützten Isolation bleibt dasselbe.

Die Rolle der Attestierung

Die Attestierung ist ein kritischer Bestandteil des Vertrauensmodells von Confidential Computing. Sie ermöglicht es einem Remote-Benutzer oder einer Remote-Anwendung, die Integrität und Authentizität eines TEE und der darin ausgeführten Software zu überprüfen. Bevor ein Benutzer sensible Daten an eine Anwendung innerhalb eines TEE sendet, kann er eine Attestierungsanfrage stellen. Das TEE generiert daraufhin einen kryptografisch signierten Bericht (einen sogenannten Attestierungsbericht), der Informationen über die Hardware-Plattform, die TEE-Konfiguration und einen Hash des geladenen Anwendungscodes enthält.

Dieser Bericht wird dann an einen Attestierungsservice (oft vom Hardwarehersteller bereitgestellt) gesendet, der die Signatur verifiziert und bestätigt, dass der Bericht von einer echten TEE-Hardware stammt. Anschließend kann der Benutzer den Hash des Anwendungscodes im Bericht mit einem erwarteten Hash vergleichen, um sicherzustellen, dass die korrekte, unveränderte Anwendung im TEE läuft. Erst nach erfolgreicher Attestierung wird ein sicherer Kanal zum TEE aufgebaut und die sensiblen Daten werden übertragen.

Wie TEEs Daten in der Nutzung schützen

Der Schutzmechanismus von TEEs basiert auf einer Kombination aus Hardware-Isolation und Speicherverschlüsselung. Wenn eine Anwendung oder ein Teil einer Anwendung in einem TEE ausgeführt wird, werden ihre Daten und ihr Code in einem speziellen, hardwaregeschützten Bereich des Speichers abgelegt. Dieser Bereich ist für den Rest des Systems, einschließlich des Betriebssystems und des Hypervisors, unzugänglich.

Die CPU erzwingt diese Isolation und stellt sicher, dass nur der Code innerhalb des TEE auf die darin enthaltenen Daten zugreifen kann. Jeglicher Versuch von außen, auf diesen Speicher zuzugreifen, wird von der Hardware blockiert. Darüber hinaus wird der Speicherinhalt des TEE automatisch von der CPU verschlüsselt, bevor er den Prozessor verlässt und in den Hauptspeicher (RAM) gelangt. Das bedeutet, selbst wenn jemand physischen Zugriff auf den RAM hätte oder diesen auslesen könnte, wären die Daten dort nur in verschlüsselter Form vorhanden und könnten ohne den geheimen Schlüssel der CPU nicht entschlüsselt werden.

Intel Software Guard Extensions (SGX)

Intel SGX ist eine der bekanntesten TEE-Technologien und ermöglicht die Erstellung von sogenannten Enklaven. Eine Enklave ist ein kleiner, isolierter und verschlüsselter Speicherbereich innerhalb einer Anwendung, in dem sensible Daten und Code ausgeführt werden können. SGX schützt diese Enklaven auf Anwendungsebene, was bedeutet, dass nur bestimmte, kritische Teile einer Anwendung innerhalb der Enklave ausgeführt werden müssen, während der Rest der Anwendung im unsicheren Host-Betriebssystem läuft.

Vorteile: Hohe Granularität des Schutzes, da nur die wirklich sensiblen Teile einer Anwendung in die Enklave müssen. Dies kann die Angriffsfläche reduzieren. Einschränkungen: Die Entwicklung von SGX-Anwendungen erfordert oft eine Anpassung des Codes, da Daten explizit in die Enklave hinein- und herauskopiert werden müssen (sogenanntes Marshalling über ECALLs und OCALLs). Enklaven haben auch eine begrenzte Größe und können komplex in der Handhabung sein.

AMD Secure Encrypted Virtualization (SEV)

Im Gegensatz zu SGX, das auf Anwendungsebene agiert, schützt AMD SEV ganze virtuelle Maschinen (VMs). Mit SEV wird der gesamte Arbeitsspeicher einer VM hardwareseitig verschlüsselt. Dies bedeutet, dass weder der Hypervisor noch andere VMs auf demselben physischen Host den unverschlüsselten Inhalt des VM-Speichers einsehen oder manipulieren können. AMD SEV ist Teil der AMD EPYC Prozessorfamilie.

Varianten:

  • SEV-ES (Encrypted State): Schützt nicht nur den Speicher, sondern auch den CPU-Registerzustand der VM vor dem Hypervisor.
  • SEV-SNP (Secure Nested Paging): Bietet den stärksten Schutz, indem es die Integrität des VM-Speichers zusätzlich absichert und Replay-Angriffe verhindert. Es stellt sicher, dass der Hypervisor die Seitentabellen der VM nicht manipulieren kann.

Vorteile: Leichtere Adaption für bestehende VM-Workloads, da keine Codeänderungen an der Anwendung selbst erforderlich sind. Der Schutz ist transparent für die Gast-VM. Einschränkungen: Geringere Granularität als SGX, da die gesamte VM geschützt wird, nicht nur spezifische Anwendungsteile.

Praktisches Beispiel (Konzept): Eine einfache SGX-Anwendung

Stellen wir uns eine Anwendung vor, die sensible Benutzerdaten verarbeitet, zum Beispiel die Berechnung eines Kredit-Scores basierend auf persönlichen Finanzdaten. Um sicherzustellen, dass weder der Cloud-Anbieter noch ein kompromittiertes Betriebssystem diese Daten während der Berechnung einsehen kann, wird der kritische Teil der Berechnung in einer SGX-Enklave ausgeführt.

Der Workflow könnte wie folgt aussehen:

  1. Der Client sendet verschlüsselte Finanzdaten an die Host-Anwendung in der Cloud.
  2. Die Host-Anwendung (außerhalb der Enklave) lädt die Enklaven-Software.
  3. Nach erfolgreicher Attestierung der Enklave wird ein sicherer Kanal aufgebaut.
  4. Die Host-Anwendung kopiert die verschlüsselten Finanzdaten in die Enklave.
  5. Innerhalb der Enklave: Die Daten werden entschlüsselt, der Kredit-Score berechnet.
  6. Der berechnete Kredit-Score wird innerhalb der Enklave verschlüsselt.
  7. Die Enklave gibt den verschlüsselten Score an die Host-Anwendung zurück.
  8. Die Host-Anwendung leitet den verschlüsselten Score an den Client weiter.

Ein konzeptioneller Code-Ausschnitt, der die Interaktion zwischen Host und Enklave mit dem Open Enclave SDK verdeutlicht, könnte so aussehen:


// Host-Anwendung (C-Code)
#include <openenclave/host.h>
#include "enclave_u.h" // Header generiert vom Open Enclave SDK

int main(int argc, const char* argv[])
{
    oe_enclave_t* enclave = NULL;
    oe_result_t result = OE_OK;
    char* input_data = "Sehr sensible Finanzdaten";
    char output_buffer[256];

    // 1. Enklave erstellen und laden
    result = oe_create_enclave(
        "enclave.signed", // Pfad zur signierten Enklaven-Binärdatei
        OE_ENCLAVE_TYPE_SGX,
        OE_ENCLAVE_FLAG_DEBUG, // Für Debugging, in Produktion entfernen
        NULL, // Optional: Attestierungs-Callback
        0,    // Anzahl der Attestierungs-Callbacks
        &enclave
    );

    if (result != OE_OK) {
        fprintf(stderr, "Fehler beim Erstellen der Enklave: %s\n", oe_result_str(result));
        return 1;
    }

    printf("Enklave erfolgreich erstellt und geladen.\n");

    // 2. Funktion innerhalb der Enklave aufrufen
    // 'enclave_process_sensitive_data' ist eine ECALL-Funktion, die in enclave_u.h deklariert ist
    result = enclave_process_sensitive_data(
        enclave,
        &result, // Rückgabewert der Enklaven-Funktion
        input_data,
        strlen(input_data) + 1,
        output_buffer,
        sizeof(output_buffer)
    );

    if (result == OE_OK && *result == OE_OK) {
        printf("Ergebnis von der Enklave: %s\n", output_buffer);
    }
    else {
        fprintf(stderr, "Fehler beim Aufruf der Enklaven-Funktion: %s\n", oe_result_str(result));
    }

    // 3. Enklave beenden
    oe_terminate_enclave(enclave);
    printf("Enklave beendet.\n");

    return 0;
}

// Enklaven-Code (C-Code, wird in der Enklave ausgeführt)
#include <openenclave/enclave.h>
#include "enclave_t.h" // Header generiert vom Open Enclave SDK

OE_SET_ENCLAVE_SGX(
    1,    // Product ID
    1,    // Security Version
    true, // Debug-Enklave (für Produktion false setzen)
    1024, // Heap Size (KB)
    1024, // Stack Size (KB)
    2     // Num TCS
);

// Implementierung der ECALL-Funktion
oe_result_t enclave_process_sensitive_data(
    char* input_data,
    size_t input_size,
    char* output_buffer,
    size_t output_size)
{
    // Hier findet die sensible Verarbeitung statt.
    // 'input_data' ist bereits in die Enklave kopiert und entschlüsselt.
    // 'output_buffer' wird von der Enklave beschrieben und später verschlüsselt zurückgegeben.

    printf("Enklave: Empfangene Daten: %s\n", input_data);

    // Beispiel: Einfache Transformation
    const char* sensitive_result = "Geheimnisvoller Score: 950";
    if (strlen(sensitive_result) + 1 <= output_size) {
        strcpy(output_buffer, sensitive_result);
        printf("Enklave: Ergebnis berechnet und zurückgegeben.\n");
        return OE_OK;
    } else {
        fprintf(stderr, "Enklave: Ausgabepuffer zu klein.\n");
        return OE_FAILURE;
    }
}

Dieses Beispiel ist stark vereinfacht. In einer realen Anwendung müssten Daten sicher in die Enklave transportiert (z.B. verschlüsselt über TLS) und dort entschlüsselt werden. Das Open Enclave SDK übernimmt viele der Low-Level-Details für die Interaktion zwischen Host und Enklave.

Sichere Mehrparteienberechnung (Secure Multi-Party Computation) mit TEEs

Sichere Mehrparteienberechnung (Secure Multi-Party Computation, MPC) ist ein kryptografisches Konzept, das es mehreren Parteien ermöglicht, eine gemeinsame Funktion über ihre privaten Eingaben zu berechnen, ohne dass eine der Parteien die privaten Eingaben der anderen Parteien erfährt. Während klassische MPC-Protokolle oft rechenintensiv sind und hohe Latenzzeiten aufweisen, können TEEs als Beschleuniger und Vereinfacher für MPC-Szenarien dienen.

TEEs ermöglichen eine effizientere Form von MPC, indem sie eine vertrauenswürdige Ausführungsumgebung bereitstellen, in der die Daten der beteiligten Parteien sicher zusammengeführt und verarbeitet werden können. Anstatt komplexe kryptografische Protokolle für jede einzelne Operation auszuführen, können die Parteien ihre verschlüsselten Daten an ein TEE senden. Innerhalb des TEE werden die Daten entschlüsselt, die Berechnung durchgeführt und das Ergebnis – je nach Anwendungsfall – verschlüsselt zurückgegeben oder aggregiert.

Die Attestierungsfunktion der TEEs ist hierbei entscheidend: Jede Partei kann unabhängig überprüfen, dass die TEE-Umgebung authentisch ist und den erwarteten, unveränderten Code ausführt, bevor sie ihre sensiblen Daten an sie sendet. Dies schafft ein hohes Maß an Vertrauen, selbst in einer Cloud-Umgebung.

Anwendungsfälle für sichere Mehrparteienberechnung mit TEEs

Die Kombination von MPC und TEEs eröffnet neue Möglichkeiten für datengetriebene Kollaboration in verschiedenen Branchen:

  • Gesundheitswesen: Mehrere Krankenhäuser möchten eine gemeinsame Studie über Patientendaten durchführen, um Muster für Krankheiten zu identifizieren, ohne jedoch die individuellen Patientendaten preiszugeben. Ein TEE kann die aggregierten Analysen durchführen, ohne dass die Rohdaten für die beteiligten Parteien oder den Cloud-Anbieter sichtbar werden.
  • Finanzdienstleistungen: Banken möchten gemeinsam Betrugsmuster erkennen oder Kreditrisiken bewerten, indem sie ihre Datenpools analysieren. TEEs ermöglichen die Berechnung von gemeinsamen Modellen, während die individuellen Transaktionsdaten oder Kundenprofile privat bleiben.
  • Supply Chain Management: Verschiedene Unternehmen in einer Lieferkette möchten ihre Logistik optimieren oder Engpässe identifizieren, indem sie Daten zu Lagerbeständen und Lieferzeiten teilen. Ein TEE kann eine aggregierte Ansicht oder Optimierungsvorschläge liefern, ohne die proprietären Daten jedes Unternehmens offenzulegen.
  • Künstliche Intelligenz und Maschinelles Lernen: Mehrere Organisationen können gemeinsam ein KI-Modell trainieren (föderiertes Lernen), indem sie ihre Daten in ein TEE einspeisen. Das TEE trainiert das Modell und gibt nur die aktualisierten Modellparameter zurück, ohne die Trainingsdaten preiszugeben.

Architekturen für MPC mit TEEs

Es gibt verschiedene architektonische Ansätze, um MPC mit TEEs zu implementieren:

  • Zentralisiertes TEE: Ein einziger TEE-fähiger Server fungiert als vertrauenswürdige Recheninstanz. Alle Parteien senden ihre verschlüsselten Daten an dieses TEE, das die Berechnung durchführt und das Ergebnis zurückgibt. Dies ist der einfachste Ansatz in Bezug auf die Implementierung.
  • Verteilte TEEs: Mehrere TEEs, möglicherweise auf verschiedenen Servern oder sogar bei verschiedenen Parteien, können zusammenarbeiten. Dies kann durch spezielle Protokolle erreicht werden, die den Austausch von Zwischenergebnissen zwischen den TEEs ermöglichen, während die Vertraulichkeit gewahrt bleibt. Dieser Ansatz bietet eine höhere Ausfallsicherheit und kann das Vertrauen weiter verteilen.

Die Kombination von TEEs mit anderen Privacy-Enhancing Technologies (PETs) wie homomorpher Verschlüsselung (HE) oder differentieller Privatsphäre (DP) kann zusätzliche Sicherheits- und Datenschutzgarantien bieten. TEEs können beispielsweise verwendet werden, um die rechenintensiven Schlüsseloperationen für HE zu beschleunigen oder um die Parameter für DP-Algorithmen sicher zu generieren.

Herausforderungen und Zukunftsaussichten

Obwohl Confidential Computing ein enormes Potenzial birgt, steht die Technologie noch vor einigen Herausforderungen, die ihre breite Akzeptanz beeinflussen:

Aktuelle Herausforderungen

  • Entwickler-Komplexität: Insbesondere bei SGX erfordert die Anpassung von Anwendungen für Enklaven oft eine tiefgreifende Kenntnis der TEE-APIs und eine sorgfältige Trennung von sensiblem und unsensiblem Code. Dies kann den Entwicklungsaufwand erhöhen. Frameworks wie das Open Enclave SDK oder Gramine versuchen, diese Komplexität zu reduzieren.
  • Leistungsoverhead: Die zusätzlichen Sicherheitsmechanismen wie Speicherverschlüsselung und Isolation können zu einem gewissen Leistungsverlust führen, insbesondere bei speicherintensiven Anwendungen oder häufigen Wechseln zwischen sicherer und unsicherer Umgebung. Moderne Hardware-Generationen reduzieren diesen Overhead jedoch kontinuierlich.
  • Seitenkanalangriffe: Trotz der Isolation sind TEEs nicht völlig immun gegen Seitenkanalangriffe, die Informationen über die Ausführung durch Beobachtung von nicht-privilegierten Kanälen (z.B. Cache-Zugriffsmuster, Stromverbrauch) gewinnen können. Die Forschung arbeitet intensiv an Gegenmaßnahmen und die Hardware-Hersteller integrieren fortlaufend Schutzmechanismen.
  • Vertrauen in die Hardware und Lieferkette: Das Vertrauensmodell von Confidential Computing basiert letztlich auf der Integrität der Hardware. Das Vertrauen in die Lieferkette (Supply Chain) und die Sicherheit der Hardware-Implementierung selbst ist daher von größter Bedeutung.
  • Standardisierung und Interoperabilität: Die verschiedenen TEE-Technologien (SGX, SEV, TDX etc.) sind nicht direkt miteinander kompatibel, was die Portabilität von Anwendungen erschwert. Bemühungen um Standardisierung und Abstraktionsschichten sind im Gange.

Die Evolution der Technologie

Die Entwicklung von Confidential Computing schreitet rasant voran. Große Cloud-Anbieter wie Microsoft Azure (Azure Confidential Computing), Google Cloud (Confidential VMs) und AWS (AWS Nitro Enclaves) bieten bereits Dienste an, die auf TEE-Technologien basieren. Dies treibt die Akzeptanz und Reife der Technologie maßgeblich voran.

Hardware-Hersteller entwickeln ihre TEE-Angebote kontinuierlich weiter. Intel hat mit Trust Domain Extensions (TDX) eine neue Generation von TEEs vorgestellt, die es ermöglichen, ganze VMs zu isolieren, ähnlich wie AMD SEV, aber mit zusätzlichen Schutzmechanismen. AMD verbessert seine SEV-Technologie mit SEV-SNP weiter, um die Integrität des VM-Speichers noch robuster zu gestalten.

Auch die Software-Tools werden immer ausgereifter. Abstraktionsschichten wie das Open Enclave SDK oder Gramine ermöglichen es, bestehende Linux-Anwendungen mit geringem Aufwand in SGX-Enklaven auszuführen, ohne den Code grundlegend umschreiben zu müssen. Die Integration in Container-Plattformen wie Kubernetes ist ebenfalls ein wichtiger Trend, um die Bereitstellung und Verwaltung von vertraulichen Workloads zu vereinfachen.

Ausblick

Confidential Computing wird sich zu einem Standard für alle Workloads entwickeln, die sensible Daten verarbeiten, insbesondere in Multi-Tenant-Cloud-Umgebungen. Es wird nicht nur die Datensicherheit in der Cloud revolutionieren, sondern auch neue Geschäftsmodelle und Kooperationen ermöglichen, die zuvor aufgrund von Datenschutzbedenken und regulatorischen Anforderungen undenkbar waren.

Die Fähigkeit, Daten sicher zu verarbeiten, selbst wenn der Infrastrukturanbieter nicht vollständig vertrauenswürdig ist, ist ein Game Changer. Es wird die Demokratisierung von datengetriebenen Kooperationen vorantreiben, indem es Unternehmen ermöglicht, gemeinsam Wert aus Daten zu schöpfen, ohne das Risiko der Offenlegung proprietärer oder regulierter Informationen einzugehen. Darüber hinaus wird Confidential Computing eine entscheidende Rolle im Bereich des Edge-Computing und des Internets der Dinge (IoT) spielen, wo Daten oft in unsicheren Umgebungen verarbeitet werden müssen.

Fazit

Confidential Computing, gestützt durch hardwarebasierte Trusted Execution Environments, schließt eine kritische Sicherheitslücke beim Schutz von Daten in der Nutzung. Es ermöglicht Organisationen, die Vertraulichkeit und Integrität ihrer Daten und Anwendungen zu gewährleisten, selbst in Umgebungen, in denen der Infrastrukturanbieter oder andere privilegierte Software nicht vollständig vertraut werden kann. Durch die Fähigkeit zur sicheren Mehrparteienberechnung eröffnet es transformative Möglichkeiten für die Kollaboration und Innovation in datensensiblen Branchen.

Während Herausforderungen in Bezug auf Entwickler-Komplexität und Seitenkanalangriffe bestehen bleiben, treiben kontinuierliche Fortschritte in Hardware und Software die Reife und Akzeptanz dieser Technologie voran. Confidential Computing ist nicht nur eine evolutionäre Verbesserung der Cybersicherheit, sondern ein revolutionärer Schritt hin zu einer Welt, in der Daten sicher und vertrauenswürdig verarbeitet werden können, unabhängig vom Ort ihrer Ausführung.

Benötigen Sie Cybersecurity-Beratung?

Unser Team hilft Ihnen, Ihre IT-Infrastruktur zu sichern und Bedrohungen proaktiv zu erkennen.

Kontakt aufnehmen