Sharing is caring: Attestable and Trusted Workflows out of Distrustful Components

Das Paper stellt Mica vor, eine Architektur für vertrauliches Computing auf Basis von Arm CCA, die durch die Entkopplung von Vertraulichkeit und Vertrauen sowie die Einführung einer Policy-Sprache zur Attestierung von Kommunikationspfaden sichere Workflows über nicht vertrauenswürdige Komponenten hinweg ermöglicht.

Das Wesentliche

Titel: „Teilen ist caring": Wie man vertrauenswürdige Zusammenarbeit aus misstrauischen Teilen baut

Stell dir vor, du möchtest ein riesiges, komplexes Puzzle mit deinen Nachbarn zusammenlegen. Das Problem: Niemand vertraut dem anderen. Dein Nachbar könnte heimlich Teile des Puzzles stehlen, und du könntest ihm etwas Falsches zeigen. Normalerweise würdest du sagen: „Ich mache das allein" oder „Wir müssen alle erst einen Eid schwören, dass wir ehrlich sind."

Das ist genau das Problem, das die Forscher von Imperial College London und Microsoft mit ihrer neuen Erfindung namens Mica lösen wollen.

Hier ist die einfache Erklärung, wie Mica funktioniert, ohne technische Fachbegriffe:

1. Das alte Problem: Das „Vertrauens-Paradoxon"

In der heutigen Cloud-Computing-Welt arbeiten viele verschiedene Programme (wie ein KI-Modell, eine Datenbank und eine Benutzeroberfläche) zusammen, um sensible Daten (z. B. deine Gesundheitsdaten oder Bankgeheimnisse) zu verarbeiten.

• Das Problem: Diese Programme laufen in speziellen, abgeschirmten Räumen (sogenannten „Sicherheitszonen" oder TEEs). Aber damit sie miteinander reden können, müssen sie Daten austauschen.
• Der Fehler: Bisher mussten sich diese Programme blind darauf verlassen, dass das andere Programm ehrlich ist. Wenn das Programm für die Datenbank heimlich deine Daten an den Cloud-Anbieter weiterleitet, kann das Programm für die KI das nicht verhindern. Es ist wie ein Brief, den du deinem Nachbarn gibst, damit er ihn zur Post bringt. Du musst ihm vertrauen, dass er den Brief nicht öffnet. Wenn er nicht vertrauenswürdig ist, ist dein Geheimnis weg.

2. Die Lösung: Mica – Der strenge Türsteher

Mica ändert die Regeln des Spiels. Es sagt: „Wir brauchen kein Vertrauen, wir brauchen klare Regeln."

Stell dir Mica wie einen extrem strengen, aber fairen Türsteher und Architekt vor, der für alle Räume zuständig ist.

• Kein blindes Vertrauen: Die Programme müssen sich nicht gegenseitig vertrauen. Sie dürfen sich sogar gegenseitig hassen!
• Explizite Regeln: Bevor zwei Programme Daten austauschen dürfen, müssen sie beim Türsteher (Mica) eine Genehmigung einreichen. Diese Genehmigung ist wie ein detaillierter Bauplan:
  • „Programm A darf nur Daten an Programm B senden."
  • „Programm B darf nur lesen, aber nichts schreiben."
  • „Programm A darf den Cloud-Anbieter (den untrusted Host) gar nicht kontaktieren."
• Der Türsteher kontrolliert alles: Mica überwacht jeden einzelnen Datenfluss. Wenn Programm A versucht, Daten an jemanden zu senden, der nicht auf der Liste steht, oder versucht, den Cloud-Anbieter zu kontaktieren, blockiert Mica das sofort. Es ist, als würde ein Roboter jeden Brief öffnen, prüfen, ob er auf der Erlaubnisliste steht, und den Rest vernichten.

3. Die drei genialen Tricks von Mica

A. Von „Vermutungen" zu „Karten"

Früher war es wie ein dunkles Zimmer, in dem man hoffte, dass niemand etwas stiehlt. Mica macht das Licht an. Jeder Datenfluss wird auf einer Karte festgehalten. Wenn eine Verbindung nicht auf der Karte steht, existiert sie nicht.

B. Von „Feste Regeln" zu „Individuellen Verträgen"

Früher mussten alle Programme die gleiche Sicherheitssoftware nutzen (wie eine einheitliche Uniform). Das war unflexibel. Mica erlaubt jedem Programm, seine eigenen Regeln zu definieren, solange sie mit den Regeln der anderen übereinstimmen. Es ist wie ein Vertrag, bei dem jeder Partner sagt: „Ich gebe dir nur das, was du brauchst, und ich nehme nur das, was du mir erlaubst."

C. Der „Gruppen-Ausweis"

Wenn alle Programme ihre Regeln festgelegt haben, erstellt Mica einen Gruppen-Ausweis. Dieser Ausweis beweist einem externen Kunden (z. B. dir als Nutzer), dass das gesamte System sicher ist. Du musst nicht jeden einzelnen Nachbarn prüfen, sondern siehst nur den Ausweis, der bestätigt: „Alle Regeln wurden eingehalten, keine Daten sind durchgekommen."

4. Ein konkretes Beispiel: Der Video-Filter

Stell dir vor, du hast ein Video, das du moderieren lassen willst.

1. Teil 1 (Encoder): Ein Programm von Firma A schneidet das Video.
2. Teil 2 (Moderator): Ein Programm von Firma B prüft, ob das Video unsittlich ist.
3. Teil 3 (Speicher): Ein Programm von Firma C speichert das Ergebnis.

Ohne Mica: Firma A könnte heimlich das Video an einen Hacker senden, während Firma B wartet.
Mit Mica:

• Der Türsteher (Mica) sagt zu Firma A: „Du darfst das Video nur an Firma B senden. Du darfst das Internet nicht kontaktieren."
• Der Türsteher sagt zu Firma B: „Du darfst nur vom Video lesen, aber nichts zurücksenden."
• Wenn Firma A versucht, das Video an einen Hacker zu senden, sagt Mica: „Stopp! Das steht nicht auf deiner Liste!" und blockiert es.

Firma A muss nicht vertrauenswürdig sein. Sie kann sogar böswillig sein. Aber da die Regeln (die „Wände") so hart sind, kann sie nichts falsch machen.

5. Warum ist das wichtig?

• Sicherheit ohne Kompromisse: Du kannst sensible Daten in der Cloud verarbeiten, ohne den Cloud-Anbieter oder die Software-Hersteller vertrauen zu müssen.
• Flexibilität: Firmen können ihre Software unabhängig voneinander entwickeln und updaten, solange sie die Mica-Regeln einhalten.
• Effizienz: Da die Daten nicht mehr verschlüsselt und entschlüsselt werden müssen, wenn sie zwischen den Programmen hin und her wandern (weil der Türsteher sie im „sicheren Raum" hält), geht es viel schneller.

Fazit

Mica ist wie ein unbestechlicher Sicherheitsbeamter, der in einem Gebäude aus misstrauischen Mietern arbeitet. Er sorgt dafür, dass niemand die Wände durchbricht, niemand die falschen Türen benutzt und niemand Dinge aus dem Haus schmuggelt – und das alles, ohne dass die Mieter sich gegenseitig mögen oder vertrauen müssen.

Es ist der Schritt von „Hoffen und Beten" zu „Prüfen und Beweisen".

Technische Zusammenfassung

1. Problemstellung

Das Paper adressiert eine fundamentale Lücke im Bereich des Vertraulichen Computings (Confidential Computing). Während Trusted Execution Environments (TEEs) Daten während der Verarbeitung schützen, fehlt es aktuellen TEE-Architekturen an sicheren Mechanismen für die Kommunikation zwischen verschiedenen Komponenten.

• Das Dilemma: Moderne Cloud-Workloads bestehen oft aus Pipelines unabhängig entwickelter und bereitgestellter Komponenten (z. B. proprietäre Algorithmen von verschiedenen Anbietern). Diese Komponenten müssen sensible Daten austauschen.
• Die aktuelle Annahme: Um Datenlecks zu vermeiden, müssen sich diese Komponenten gegenseitig vertrauen (d. h., man muss davon ausgehen, dass der Code jeder Komponente korrekt ist und keine Daten an den Hypervisor oder andere TEEs weiterleitet).
• Die Realität: Diese Annahme ist unrealistisch. Komponenten sind oft proprietär (Closed-Source), werden von verschiedenen Parteien verwaltet und vertrauen sich nicht gegenseitig.
• Die Schwachstelle: Derzeitige TEEs schützen zwar den exklusiven Speicher, lassen aber die Schnittstellen (Shared Memory, RPC, Host-Interaktionen) unkontrolliert. Die Vertraulichkeit hängt somit von der funktionalen Korrektheit des gesamten Software-Stacks jeder Komponente ab, was in der Praxis kaum zu garantieren ist.

2. Methodik: Mica-Architektur

Die Autoren stellen Mica vor, eine Architektur-Erweiterung, die Vertraulichkeit von Vertrauen entkoppelt. Mica ermöglicht es, vertrauliche Pipelines aus misstrauischen Komponenten aufzubauen, indem es Kommunikationspfade explizit definiert, einschränkt und attestiert.

Kernprinzipien:

1. Von implizit zu explizit: Kommunikationsendpunkte und -pfade werden nicht aus dem Verhalten vertrauenswürdiger Software abgeleitet, sondern explizit identifiziert und gemessen.
2. Trennung von Mechanismus und Richtlinie: Mica trennt die von den Mietern (Tenants) definierten Richtlinien (Policies) von den vertrauenswürdigen Mechanismen, die diese durchsetzen.
3. Strukturelle Garantien: Vertraulichkeit ergibt sich nicht aus der Korrektheit des Mediator-Codes im TEE, sondern aus der attestierbaren Struktur des Speicherzugriffs und der Kommunikation.

Technische Umsetzung (basierend auf Arm CCA):
Mica wurde als Erweiterung auf Arm Confidential Compute Architecture (CCA) implementiert, ohne Hardware-Änderungen zu benötigen.

• Erweiterung des RMM: Der Realm Management Monitor (RMM) wurde um eine kleine Policy-Sprache erweitert.
• Policy-Struktur: Tenant-definierte Policies legen fest:
  • Welche Speicherkanaäle (geschützt oder ungeschützt) mit welchen Peers geteilt werden dürfen.
  • Welche Steuerfluss-Kanaäle (z. B. Exceptions, Calls zum Hypervisor) erlaubt sind.
  • Transitive Einschränkungen: Eine Komponente kann die Eigenschaften ihrer Peers einschränken (z. B. „Mein Peer darf keinen direkten Zugriff auf den Host haben").
• Validierung: Bevor eine Komponente in eine Gruppe eintritt, validiert der RMM die Policy. Er prüft, ob die Speicherzuordnungen konsistent sind und ob die Peer-Policies einander widersprechen. Bei Fehlern wird die Komponente terminiert.
• Attestation: Mica führt eine Gruppen-Attestation durch. Anstatt nur den Zustand einer einzelnen Komponente zu verifizieren, wird ein Bericht erstellt, der die Policies und den Zustand aller kommunizierenden TEEs in der Pipeline zusammenfasst.

3. Schlüsselbeiträge

1. Design von Mica: Eine neuartige Erweiterung für vertrauliche Computing-Architekturen, die es ermöglicht, vertrauliche Cloud-Pipelines aus misstrauischen Komponenten zu bauen.
2. Policy-Sprache: Entwurf einer Sprache, mit der TEEs explizit Richtlinien für Ressourcenteilung definieren können (Speicherzugriffsrechte, Peer-Hashes, Gateways).
3. Implementierung: Eine funktionierende Implementierung von Mica auf Basis von Arm CCA, die den Trusted Computing Base (TCB) nur minimal erhöht.
4. Demonstration von Use Cases: Validierung durch realistische Szenarien wie Video-Moderation, LLM-Inferenz mit Guardrails und Netzwerk-Dienste.

4. Ergebnisse und Evaluation

Die Evaluation zeigt, dass Mica realistische Cloud-Pipelines unterstützt, ohne unrealistische Vertrauensabhängigkeiten zwischen den Komponenten zu erzwingen.

• Reduktion des TCB: In herkömmlichen Szenarien müsste jede Komponente in der Pipeline als vertrauenswürdig gelten (großer TCB). Mit Mica ist der TCB auf die Plattform-Firmware und spezifische „Gateways" beschränkt, die den Host-Kontakt verwalten. Die eigentlichen Verarbeitungskomponenten sind nicht Teil des TCB, da ihre Kommunikationswege durch die Policy eingeschränkt sind. Dies reduziert den TCB um das 2- bis 3-fache.
• Overhead: Der Overhead ist gering und beschränkt sich auf die Policy-Upload- und Validierungsphase sowie auf Kontrollfluss-Checks im RMM. Da keine Verschlüsselung für den Peer-zu-Peer-Datenaustausch im geschützten Speicher nötig ist, wird eine Leistungssteigerung gegenüber verschlüsselten TEE-Kommunikationen erwartet.
• Attestations-Größe: Die Gruppengröße der Attestationsberichte wächst linear mit der Anzahl der Realms, bleibt aber handhabbar (ca. 5–6 KB für mehrere Komponenten im Vergleich zu einzelnen Berichten).
• Szenarien:
  • Video-Moderation: Eine Pipeline aus Encoder und Moderator kann so konfiguriert werden, dass Daten nur in eine Richtung fließen und keine Komponente Daten an den Host senden kann.
  • LLM-Inferenz: Guardrails können so durchgesetzt werden, dass Eingaben und Ausgaben nur durch einen Filter-Realm laufen, ohne dass das LLM direkt mit dem Netzwerk kommunizieren kann.

5. Bedeutung und Fazit

Das Paper demonstriert einen Paradigmenwechsel im vertraulichen Computing. Statt zu versuchen, jede Komponente in einer Pipeline als vertrauenswürdig zu verifizieren (was bei proprietärer Software unmöglich ist), verschiebt Mica die Sicherheitsgarantie auf die Infrastruktur-Ebene.

Durch die explizite Definition und Durchsetzung von Kommunikationsrichtlinien auf Hardware-Niveau (via RMM) wird sichergestellt, dass sensible Daten nicht auslaufen können, selbst wenn die einzelnen Komponenten fehlerhaft sind oder böswillig handeln. Dies ermöglicht erstmals den sicheren Einsatz von heterogenen, misstrauischen Komponenten in komplexen Cloud-Pipelines, ohne dass die Mieter den gesamten Software-Stack aller Drittanbieter auditieren müssen. Mica löst damit das klassische „Confinement Problem" in modernen Cloud-Umgebungen durch Hardware-Software-Co-Design.