Sinnvolle Kontrolle über Daten in verteilten Systemen.
Oak ist eine Softwareplattform zum Aufbau verteilter Systeme, die extern überprüfbare (oder falsifizierbare) Aussagen über das Verhalten von Systemen auf transparente Weise bereitstellt.
Oak stellt Bausteine bereit, die zum Aufbau von Enclave-Anwendungen verwendet werden, d. h. von Anwendungen, die vom Host, auf dem sie laufen, isoliert sind und sich remote attestieren lassen.
In diesem Dokument konzentrieren wir uns auf verteilte Systeme, die aus heterogenen „Knoten“ bestehen; ein Knoten kann eine Enclave-Anwendung sein, die auf einem Server läuft (z. B. privates Rechenzentrum, öffentlicher Cloud-Anbieter usw.), eine reguläre Anwendung, die auf einem Client-Gerät läuft (z. B. Telefon, Laptop), ein regulärer HTTP- oder gRPC-Dienst, ein Speichersystem usw. Wenn zwei Knoten miteinander kommunizieren, kann einer oder können beide von ihnen Enclave-Anwendungen sein. Für jede Interaktion zwischen zwei Knoten bezeichnen wir sie als „Initiator“ und „Responder“. Wir vermeiden die Begriffe „Client“ und „Server“ für diese Rollen, da der „Initiator“-Knoten in manchen Fällen tatsächlich auf einem „Server“ laufen kann – alle Kombinationen sind möglich.
Eine Enclave-Anwendung in einem verteilten Oak-System kann sich gegenüber anderen Knoten remote attestieren: Dies besteht darin, einen Nachweis über ihre eigene Software- und Hardware-Identität zu erbringen, gebunden an lokale kryptografische Schlüssel (gespeichert in manipulationssicherer Hardware, die garantiert, dass Schlüssel nicht exfiltriert oder kopiert werden können), letztlich signiert durch eine oder mehrere Software- oder Hardware-Vertrauensanker, die auf dem Host dieses Knotens verfügbar sind. Die Software-Identität einer Enclave-Anwendung besteht aus Messungen (d. h. Digests / Hashes) der ausführbaren Binärdateien, die zu ihr beitragen, sowie zusätzlichen Daten (z. B. Konfiguration).
Oak konzentriert sich auf VM-basierte Trusted Execution Environments (TEEs) (z. B. AMD SEV-SNP, Intel TDX) als Hardware-Vertrauensanker für Enclave-Anwendungen. Dies ermöglicht es einer Enclave-Anwendung, einen Remote-Attestierungsbericht bereitzustellen, der von hardwaregebundenen Schlüsseln in der TEE signiert ist, auf die der Dienstanbieter keinen Zugriff hat. Diese Schlüssel sind letztlich im TEE-Hersteller (z. B. AMD, Intel) verankert; dies reduziert (idealerweise beseitigt) die Notwendigkeit, dem Dienstanbieter dieses Knotens zu vertrauen, um seinen Nachweis zu validieren, indem das Vertrauen auf mehrere nicht kolludierende Akteure verteilt wird.
Beim Start erzeugt jede Enclave-Anwendung ein lokales Schlüsselpaar und bindet den öffentlichen Schlüssel an ihren eigenen Nachweis. Wenn ein Knoten mit einer Enclave-Anwendung kommunizieren möchte (entweder als Initiator oder als Responder), wird ein Ende-zu-Ende-verschlüsselter Kanal zwischen den beiden Knoten aufgebaut. Im Rahmen des Kanalaufbaus stellt jeder Knoten dem anderen Knoten auch seinen eigenen Nachweis (falls vorhanden) bereit und kann den vom anderen Knoten bereitgestellten Nachweis nutzen, um dessen Vertrauenswürdigkeit festzustellen, bevor er entscheidet, ob er Daten mit ihm austauscht.
Dieser verschlüsselte und attestierte Kanal bietet:
Um die Angriffsfläche und die Trusted Computing Base (TCB) einer Enclave-Anwendung zu minimieren, empfiehlt Oak eine aufgeteilte Architektur:
Enclave-Anwendung: eine (reproduzierbar) aus Open-Source-Code erstellte Binärdatei, die innerhalb der TEE läuft. Die Enclave-Anwendung hat Zugriff auf die Entschlüsselungsschlüssel, die an die Attestierungsnachweise gebunden sind; sie entschlüsselt eingehende Anfragen von anderen Knoten, verarbeitet sie, verschlüsselt Antworten und sendet sie über den Kommunikationskanal zurück. Dies ist die Binärdatei, die mit extern überprüfbaren Aussagen verknüpft ist. Keine andere Binärdatei hat im Klartext Zugriff auf eingehende Anfragen.
Host-Anwendung: eine Binärdatei, die in der (nicht vertrauenswürdigen) Host-Serverumgebung läuft und als Front-End für die Enclave-Anwendung dient; sie stellt einen gRPC-Endpunkt bereit, der von anderen Knoten von außen erreichbar ist. Diese Binärdatei verarbeitet ausschließlich verschlüsselte Daten; ihre Hauptaufgabe besteht darin, eine Instanz der Enclave-Anwendung in der TEE zu erstellen und zu warten sowie verschlüsselte Daten an die Enclave-Anwendung und von ihr weiterzuleiten. Sie kann außerdem proprietäre Logik enthalten, die für die Interaktion mit der Control Plane oder anderen internen Systemen erforderlich ist, die für den Betrieb auf der Infrastruktur des Dienstanbieters notwendig sind.
Diese Architektur bedeutet, dass der Dienstanbieter nicht in der Lage wäre, die Binärdatei der Enclave-Anwendung unbemerkt durch eine andere (potenziell bösartige) zu ersetzen. Würde der Dienstanbieter eine Backdoor in der Enclave-Anwendung einführen, müsste er die Binärdatei signieren und sie über den Transparent-Release-Prozess in einem überprüfbaren Log veröffentlichen, wodurch die Backdoor für externe Beobachter irreversibel sichtbar würde.
Eine kanonische Verwendung von Oak ist der Aufbau datenschutzwahrender Sealed-Computing-Anwendungen.
In einer Sealed-Computing-Anwendung sendet ein Knoten (üblicherweise ein Client-Gerät) Daten an eine Enclave-Anwendung (üblicherweise einen Server), die die Daten verarbeitet, ohne dass der Dienstanbieter, der die Enclave-Anwendung hostet, die Eingaben, Ausgaben oder Seiteneffekte der Berechnung einsehen kann.
Das Folgende ist ein vereinfachtes Architekturdiagramm.
Oak unterstützt zwei Varianten von Betriebssystemen innerhalb der TEE, auf denen Enclave-Anwendungen bereitgestellt werden können:
