Good-Enough LLM Obfuscation (GELO)

Das Paper stellt GELO vor, ein leichtgewichtiges Protokoll, das die Privatsphäre von LLM-Prompts auf unsicheren Beschleunigern durch pro-Batch-invertierbare Mischungen der versteckten Zustände schützt, wodurch statistische Angriffe vereitelt werden, während die Ausgabeintegrität erhalten bleibt und nur ein moderater Latenzüberhead entsteht.

Das Wesentliche

Hier ist eine einfache Erklärung des Papers „GELO" auf Deutsch, verpackt in anschauliche Bilder und Metaphern.

Das Problem: Der lausige Cloud-Server

Stell dir vor, du möchtest ein sehr intelligentes KI-Modell (ein „Large Language Model" oder LLM) nutzen, das auf einem riesigen Supercomputer in der Cloud läuft. Das ist schnell und günstig. Aber es gibt ein Problem: Der Cloud-Anbieter ist nicht unbedingt dein bester Freund. Er könnte neugierig sein und versuchen, in den Arbeitsspeicher des Computers zu schauen, um zu sehen, was du gerade eingegeben hast (deine Geheimnisse, deine privaten Fragen).

Bisher gab es zwei extreme Lösungen:

1. Die „Panzer"-Lösung (Verschlüsselung): Man verschlüsselt alles mathematisch so stark, dass niemand etwas lesen kann. Das ist super sicher, aber so langsam, als würde man einen Ferrari mit dem Fahrrad fahren. Es dauert zu lange für einen echten Chat.
2. Die „Versteck-Spiel"-Lösung (Obfuskation): Man mischt die Daten ein wenig durcheinander. Das ist schnell, aber wenn der Angreifer weiß, wie das Spiel funktioniert, kann er es durch wiederholtes Beobachten knacken.

Die neue Lösung: GELO (Der „Gute Genug"-Verkleidungs-Plan)

Die Autoren von GELO (Good-Enough LLM Obfuscation) haben einen cleveren Mittelweg gefunden. Sie nennen es „gut genug", weil es nicht mathematisch unknackbar ist wie ein Panzer, aber für einen Angreifer praktisch unlösbar ist, solange er nicht unendlich viel Zeit hat.

Stell dir das so vor:

1. Das Szenario: Ein sicherer Tresor und ein lausiger Lieferwagen

• Der Tresor (TEE): Das ist ein sicherer Bereich auf deinem Computer (oder im Cloud-Rechenzentrum), den niemand ausspionieren kann. Hier werden die sensiblen Gedanken (die „versteckten Zustände" der KI) verarbeitet.
• Der Lieferwagen (Untrusted GPU): Das ist der schnelle, aber unzuverlässige Supercomputer, der die schwere Rechenarbeit macht. Er ist schnell, aber man kann ihm nicht trauen, weil er die Daten sieht.

2. Der Trick: Die „Tarnkappen-Matrix"

Normalerweise würde man dem Lieferwagen die nackten Daten geben, damit er rechnet. GELO macht etwas anderes:

• Der Schritt vor dem Absenden: Bevor die Daten den Tresor verlassen, nimmt der Tresor einen zufälligen, geheimen Zauberstab (eine mathematische Matrix, nennen wir sie „A").
• Das Mischen: Er wirft die Daten durch diesen Zauberstab. Die Daten sehen jetzt völlig anders aus, wie ein Haufen durcheinandergeratener Puzzleteile. Aber das Gute ist: Der Zauberstab ist invertierbar. Das bedeutet, man kann die Daten später wieder exakt zurückdrehen, wenn man den Zauberstab kennt.
• Die Rechnung: Der Lieferwagen rechnet mit diesen durcheinandergeratenen Daten. Er sieht nur den „Müll", nicht die eigentlichen Geheimnisse.
• Der Schritt nach dem Empfang: Wenn die Ergebnisse zurückkommen, nimmt der Tresor den Gegenzauberstab (die Umkehrung von A) und dreht alles wieder zurück. Das Ergebnis ist genau dasselbe, als hätte man es ohne Tarnung gemacht.

3. Warum ist das sicher? (Das „Einmal-Verstecken"-Prinzip)

Das ist der wichtigste Teil! Bei alten Methoden wurde immer derselbe Zauberstab benutzt. Ein Angreifer konnte also viele Versuche beobachten, die Muster erkennen und den Zauberstab erraten.

Bei GELO passiert etwas Magisches:

• Jede neue Anfrage bekommt einen komplett neuen, zufälligen Zauberstab.
• Es ist wie bei einem Tarnanzug: Wenn du heute einen Tarnanzug trägst, der dich wie ein Fels aussieht, und morgen einen, der dich wie ein Baum aussehen lässt, kann ein Spion nicht sagen, wer du bist, indem er dich nur einmal sieht.
• Der Angreifer muss das Rätsel lösen, bevor der nächste Zauberstab kommt. Da die Daten aber so komplex sind (wie ein riesiges Puzzle ohne Bildvorlage), ist es für ihn unmöglich, das Original aus dem durcheinandergeratenen Haufen zu rekonstruieren.

4. Die „Schutzschilder" (Shield Vectors)

Manchmal könnte ein Angreifer raten, dass bestimmte Daten (wie das Wort „Hallo" oder ein Leerzeichen) oft vorkommen. Um das zu verhindern, füllt GELO die Datenpakete mit ein paar zufälligen „Schutzschildern" auf.

• Stell dir vor, du schickst einen Brief. Damit niemand den Inhalt erraten kann, legst du noch ein paar zufällige, bunte Papierfetzen mit in den Umschlag, die nichts mit dem Brief zu tun haben.
• Diese Fetzen „verschmutzen" die Statistik so sehr, dass der Angreifer die echten Daten gar nicht mehr herausfiltern kann.

Das Ergebnis: Schnell und sicher genug

Die Autoren haben das mit einem großen KI-Modell (Llama 2) getestet:

• Genauigkeit: Das Ergebnis ist fast perfekt (100% genau bei normalen Zahlen, fast 100% bei schnelleren, weniger genauen Zahlen).
• Geschwindigkeit: Es wird nur etwa 20–30% langsamer als ohne Schutz. Das ist ein fairer Preis für Sicherheit.
• Sicherheit: Selbst wenn der Angreifer versucht, die Daten mit modernsten mathematischen Methoden zu entschlüsseln, scheitert er, weil jede Anfrage anders „verpackt" ist.

Zusammenfassung in einem Satz

GELO ist wie ein sicherer Kurierdienst, der deine Geheimnisse in einen einmalig verformten Behälter packt, diesen an einen schnellen, aber unzuverlässigen Arbeiter gibt, damit dieser die schwere Arbeit erledigt, und den Behälter danach sofort wieder in seine ursprüngliche Form zurückverwandelt – so schnell, dass der Angreifer keine Chance hat, den Inhalt zu erraten, bevor der Behälter schon wieder weg ist.

Technische Zusammenfassung

Hier ist eine detaillierte technische Zusammenfassung des Papers „Good-Enough LLM Obfuscation (GELO)" auf Deutsch:

1. Problemstellung

Large Language Models (LLMs) werden zunehmend auf geteilten Cloud-Accelerators (GPUs) ausgeführt. In diesem Szenario besteht ein erhebliches Sicherheitsrisiko: Ein Angreifer mit Lesezugriff auf den Gerätespeicher (VRAM) kann sensible Daten wie KV-Caches (Key-Value Caches) und Hidden States beobachten. Dies ermöglicht die Rekonstruktion privater Eingabe-Prompts oder die Inferenz von Benutzerdaten, was die Privatsphäre bei Open-Source-Modellen bedroht.

Bestehende Lösungen liegen an zwei Extremen:

• Kryptographische Methoden (MPC, FHE): Bieten starke Sicherheit, sind aber für interaktive Inferenz zu langsam (Overhead von 100x oder mehr).
• Statische Obfuskation: Methoden wie statische Permutationen von Gewichten sind schnell, aber anfällig für statistische Angriffe über mehrere Durchläufe, sobald das Modell bekannt ist (z. B. bei Open-Source-Modellen).

Das Ziel ist ein Protokoll, das sensible Daten in einer vertrauenswürdigen Umgebung (TEE) hält, aber die rechenintensivsten Teile der Berechnung auf einen ungetrosten Accelerator auslagert, ohne die Privatsphäre zu gefährden.

2. Methodik: Das GELO-Protokoll

GELO (Good-Enough LLM Obfuscation) ist ein leichtgewichtiges Protokoll für privatsphäreschonende Inferenz, das auf dynamischer, pro-Batch invertierbarer Mischung basiert.

Architektur:

• Vertrauenswürdige Umgebung (TEE): Enthält die Geheimnisse und verarbeitet sensible Daten.
• Ungetroster Accelerator: Führt die rechenintensiven Matrixmultiplikationen (GEMM) für die Projektionen aus (Query, Key, Value und Output in Attention-Layern).

Ablauf pro Batch:

1. Mischung (Mixing): Im TEE wird für jeden Batch eine frische, zufällige, invertierbare Matrix $A$ (Größe $n \times n$, wobei $n$ die Batch-Größe ist) generiert. Die Hidden States $H$ werden damit gemischt: $U = A \cdot H$.
2. Auslagerung: Das gemischte Tensor $U$ (und die Gewichte $W$) wird an den ungetrosten Accelerator gesendet.
3. Berechnung: Der Accelerator führt die Projektion durch: $Y = U \cdot W$.
4. Entmischung (Un-mixing): Das Ergebnis $Y$ wird zurück an den TEE gesendet, wo die inverse Transformation angewendet wird: $Q = A^{-1} \cdot Y$.
   • Mathematisch gilt: $A^{-1}((A \cdot H) \cdot W) = H \cdot W$. Das Ergebnis ist exakt identisch mit der direkten Berechnung.

Sicherheitsprinzip:
Da die Matrix $A$ für jeden Batch neu generiert und niemals wiederverwendet wird, steht der Angreifer vor einem Blind Source Separation (BSS) Problem für einen einzelnen Batch. Ohne Kenntnis von $A$ oder zusätzlichen Seiteninformationen ist eine Rekonstruktion von $H$ aus $U$ algebraisch nicht eindeutig lösbar.

Gegenmaßnahmen gegen Leckagen:
Das Paper identifiziert zwei potenzielle Informationslecks bei orthogonalen Matrizen $A$ (die für Performance vorteilhaft sind):

1. Kovarianz-Leckage: $U^T U = H^T H$ (bei orthogonalen $A$) enthüllt die Kovarianz der Hidden States.
   • Lösung 1: Verwendung nicht-orthogonaler Matrizen $A$ (maskiert die Gram-Matrix, aber erhöht numerische Instabilität).
   • Lösung 2 (Empfohlen): Shield-Vektoren. Der Batch wird mit einem kleinen Anteil (z. B. 5%) an zufälligen, hochenergetischen „Schutz"-Vektoren aufgefüllt. Diese „verschmutzen" die Statistik so stark, dass Angreifer die echte Kovarianz nicht isolieren können.

3. Wichtige Beiträge

• GELO-Protokoll: Formalisierung eines hybriden Ansatzes, der die meisten Transformer-Operationen im TEE belässt, aber die teuersten linearen Projektionen (Q/K/V/O) auf ungetroste Hardware auslagert, geschützt durch dynamische lineare Transformationen.
• Leckage- und Identifizierbarkeitsanalyse: Nachweis, dass unter frischer Mischung keine Informationen über Batches hinweg akkumuliert werden können. Der Angreifer kann Hidden States nur bis auf eine unbekannte invertierbare Transformation identifizieren.
• Angriffsevaluation: Empirische Bewertung gegen ICA (Independent Component Analysis), BSS und anchor-basierte Angriffe (bei denen der Angreifer einige Token kennt).
• Effizienz: Demonstration, dass das Protokoll den Großteil der linearen Algebra-Kosten auslagert, bei moderatem Overhead.

4. Ergebnisse

Die Evaluation erfolgte am Modell Llama-2 7B:

• Funktionalität:
  • In Float32 wird das Ergebnis exakt reproduziert (100% Übereinstimmung der Top-1-Token).
  • In Bfloat16/Float16 bleibt die Genauigkeit hoch (>98,8% Top-1-Übereinstimmung), numerische Fehler sind vernachlässigbar.
• Performance (Latenz-Overhead):
  • Der Overhead liegt bei typischen Batch-Größen (256–512) bei ca. 20–30%.
  • Der Großteil der Zeit wird durch Kommunikation (Copy/Socket) verbraucht, nicht durch die Mischung/Entmischung selbst.
  • Bei sehr kleinen Batches ist der Overhead höher (da Fixkosten dominieren), bei sehr großen Batches steigt er wieder, da die Generierung der $n \times n$-Matrix ($O(n^3)$) zum Flaschenhals wird.
• Sicherheit:
  • Anker-Angriffe: Selbst wenn ein Angreifer bis zu 40% der Token in einem Batch kennt (Anker), ist die Rekonstruktion der restlichen Token ungenau (Cosine-Similarity < 0,3).
  • Shield-Vektoren: Der Einsatz von 5% hochenergetischen Rausch-Vektoren reduziert die Erfolgsrate von ICA-Angriffen drastisch. Die p95-Cosine-Similarity fällt unter 0,28, was eine praktische Deobfuskation verhindert.
  • Geometrische Wiederherstellung: Die Struktur der Daten (Gram-Matrix) bleibt auch bei Angriffen stark verzerrt.

5. Bedeutung und Fazit

GELO bietet einen praktikablen Kompromiss zwischen Sicherheit und Performance für LLM-Inferenz in der Cloud.

• Praxisrelevanz: Es ermöglicht den Einsatz von kostengünstigen, ungetrosten GPUs für den Großteil der Berechnung, während sensible Daten durch TEEs und kryptographische Prinzipien (hier: BSS-Schwierigkeit) geschützt bleiben.
• Unterschied zu Krypto: Im Gegensatz zu FHE/MPC ist GELO schnell genug für interaktive Anwendungen.
• Unterschied zu statischer Obfuskation: Durch die dynamische, pro-Batch-Generierung von $A$ werden Angriffe, die auf der Analyse mehrerer Durchläufe basieren, wirkungslos.

Das Paper schließt mit der Empfehlung, GELO in Inferenz-Engines (wie vLLM) zu integrieren und zukünftig auch andere Schichten (MLP) sowie Quantisierungsformate zu untersuchen. Es stellt einen „gut genug" (Good-Enough) Ansatz dar, der reale Bedrohungen (KV-Cache-Leckage) effektiv abwehrt, ohne die Skalierbarkeit von Cloud-LLMs zu opfern.