Attestation und der Trustee Service

hinweis

Nicht jede Codesphere-Instanz bietet Confidential Compute an. Frage deinen Codesphere-Administrator, ob Confidential Compute auf deiner Instanz verfügbar ist. Siehe Voraussetzungen.

Die Confidential-Architektur hält deine Daten während der Nutzung, bei der Übertragung und im Ruhezustand verschlüsselt. Die Schlüssel für diese Verschlüsselung müssen von einem Ort kommen, den die Plattform nicht erreichen kann. Bei Confidential Compute gilt die gesamte Plattforminfrastruktur als nicht vertrauenswürdig. Vertrauen kommt von einer einzigen Stelle außerhalb der Plattform: dem Trustee Service. Dieser gibt Schlüssel und Secrets nur an Dienste heraus, die nachweisen, dass sie unverändert auf echter Hardware laufen.

Was ist Remote Attestation

Remote Attestation beantwortet eine Frage: Handelt es sich um eine echte, unveränderte TEE, die genau die erwartete Software ausführt? Dies verhindert, dass der Betreiber deine Anwendung manipuliert oder gegen eine veränderte Version austauscht.

Ein Attestation-Report enthält:

• Die Messung des Guest-Images
• Die Version der CPU-Firmware und der Sicherheitspatches (die Trusted Computing Base)
• Einen frischen Zufallswert (Nonce) vom Verifier, der das Wiedereinspielen alter Reports verhindert
• Eine Signatur mit einem Schlüssel, der sich bis zum Hardwarehersteller zurückverfolgen lässt

Der Verifier prüft, dass:

1. Die Signatur sich bis zum Root-Zertifikat des Herstellers zurückverfolgen lässt.
2. Die Firmware aktuell ist und nicht als verwundbar bekannt ist.
3. Die Messung einem von der Policy erlaubten Wert entspricht.
4. Die Nonce mit der gesendeten übereinstimmt.

Die Verifizierung ist "remote", weil sie außerhalb des zu prüfenden Hosts läuft. Der Host kann das Ergebnis nicht fälschen, da er keinen Zugriff auf den Signierschlüssel innerhalb der CPU hat.

Der Trustee Service

Der Trustee Service ist eine unabhängige Partei, die außerhalb der Codesphere-Instanz existiert. Weder die Plattform noch der Infrastrukturbetreiber kontrolliert ihn. Er hat drei Aufgaben:

• Verifizieren. Er prüft Attestation-Reports wie oben beschrieben.
• Policies durchsetzen. Er entscheidet, welche Guest-Images, welche Service-Images oder Signierschlüssel und welche Mindest-Firmware-Versionen akzeptabel sind.
• Secrets freigeben. Er gibt Festplattenverschlüsselungsschlüssel, Service-Mesh-Identitäten und Anwendungs-Secrets heraus, jedoch nur an Dienste, die die Attestation bestanden haben.

Da Secrets erst nach erfolgreicher Attestation freigegeben werden, erhält ein auf manipulierter Infrastruktur gestarteter Dienst nichts. Er kann seine Volumes nicht entschlüsseln, dem Mesh nicht beitreten und keine Anwendungs-Secrets lesen.

Mehr erfahren

Intern besteht ein Trustee Service aus mehreren Komponenten mit getrennten Rollen. Diese Rollen sind durch die IETF Remote ATtestation procedureS (RATS) Architektur definiert. Details findest du in RFC 9334 und im RATS-Architektur-Entwurf.

Codesphere liefert keinen eigenen Trustee Service mit. Du verbindest deine Confidential Services mit einem Trustee Service, der außerhalb der Plattform läuft. Siehe Vorbereitende Schritte dazu, wie du Zugang zu einem solchen bekommst.

Attestation-Ablauf

Eine Confidential Micro-VM wird in zwei Stufen vertrauenswürdig. Zuerst wird ihre Umgebung verifiziert (Schritte 1 bis 6). Danach verifiziert die VM den Dienst selbst (Schritte 7 und 8). Innerhalb der Micro-VM übernimmt ein Attestation-Agent während des Starts die gesamte Kommunikation mit der Außenwelt.

Entsprechende barrierefreie Textbeschreibung

1. Die nicht vertrauenswürdige Infrastruktur plant den Dienst auf einem Host mit vertraulicher Hardware ein. Der Host startet die Micro-VM mit einem festgelegten Guest-Image (Firmware, Kernel, Initial Ramdisk und Attestation-Agent). Die CPU misst das Guest-Image, bevor es ausgeführt wird. Die Messung ist ein kryptografischer Hash, sodass der Host das Image nicht ändern kann, ohne die Messung zu verändern.
2. Der Attestation-Agent fordert eine Nonce vom Trustee Service an.
3. Der Attestation-Agent bittet die CPU um einen Attestation-Report, der die Nonce enthält. Die CPU signiert den Report.
4. Der Attestation-Agent sendet den Report an den Trustee Service.
5. Der Trustee Service prüft Signatur, Firmware, Messung und Nonce gegen seine Policy.
6. Stimmt die Policy überein, gibt der Trustee Service die Schlüssel und Secrets frei, die die VM benötigt. Die VM ist nun eine vertrauenswürdige Umgebung.
7. Der Attestation-Agent zieht das Service-Image aus der Image-Registry und verifiziert dessen Digest oder Signatur.
8. Der Attestation-Agent startet die Nutzer-Workload mit dem Image und den Secrets.

Schlägt die Attestation fehl, startet der Dienst nicht und erhält keine Secrets. Häufige Ursachen sind ein unbekanntes Guest-Image nach einem Plattform-Update, veraltete Firmware auf dem Host oder ein Service-Image, das die Policy nicht zulässt.

Die zweite Stufe ist der Grund, warum der Inhalt deines Service-Images wichtig ist. Die VM verifiziert nur das Image, mit dem sie startet. Alles, was der Dienst später herunterlädt, ist davon nicht erfasst. Siehe Empfehlungen für den Produktivbetrieb.

Secret-Verteilung

Der Trustee Service enthält einen Vault, der die Secrets deiner Confidential Services speichert. Nach erfolgreicher Attestation gibt der Trustee Service folgende Secrets an die Micro-VM frei:

• Festplattenverschlüsselungsschlüssel. Der Guest verwendet sie, um seine LUKS-Volumes zu entsperren. Siehe Verschlüsselung im Ruhezustand.
• Service-Mesh-Identität. Das Zertifikat, das der Proxy für mutual TLS verwendet. Siehe Service Mesh.
• Anwendungs-Secrets. Sensible Werte wie Datenbankpasswörter oder API-Schlüssel, die du im Vault des Trustee Service gespeichert hast.

Die Secrets gelangen direkt in den verschlüsselten Speicher der Micro-VM. Sie durchlaufen die Plattform nie im Klartext.

Workloads

Im Bereich von Confidential Compute ist eine Workload eine Gruppe von Confidential Services, die zusammenarbeiten und daher Zugriff auf dieselben Secrets benötigen. Beispielsweise benötigen eine Anwendung und ihre Datenbank beide zur Laufzeit Anmeldeinformationen. Die Anwendung verwendet sie, um sich gegenüber der Datenbank zu authentifizieren, und die Datenbank verwendet sie, um die Authentifizierung zu prüfen.

Jeder Confidential Service wird unter einer Workload-ID ausgeführt, die beim Starten angegeben werden muss. Dienste, die zusammenarbeiten und Zugriff auf dieselben Secrets benötigen, müssen sich dieselbe Workload-ID teilen. Beim Start, während der Attestation, verifiziert der Trustee Service diese ID und nutzt sie, um zu entscheiden, welche Policy und welche Secrets gelten.

Entsprechende barrierefreie Textbeschreibung

In diesem Beispiel teilen sich die Anwendung und die Datenbank die ID payments, sodass sie kommunizieren können und Zugriff auf dieselben Secrets haben. Die zweite Anwendung verwendet die ID analytics, hat daher einen eigenen Secrets-Namespace und kann keinen der anderen Server erreichen.