CacheSolidarity: Preventing Prefix Caching Side Channels in Multi-tenant LLM Serving Systems

Die Arbeit stellt CacheSolidarity vor, ein System, das in Multi-Tenant-LLM-Umgebungen Seitenkanalangriffe durch Prefix-Caching verhindert, indem es verdächtige Cache-Wiederverwendung erkennt und selektiv isoliert, wodurch die Sicherheit ohne die bei bisherigen Lösungen üblichen Leistungseinbußen gewährleistet wird.

Das Wesentliche

Hier ist eine einfache Erklärung der Forschung „CacheSolidarity", die wie eine Geschichte erzählt wird, damit jeder sie verstehen kann.

Das Problem: Der „Super-Schnelle" Bibliothekar mit einem Geheimnis

Stell dir vor, du hast einen riesigen, super-intelligenten Bibliothekar (das ist die Künstliche Intelligenz oder LLM). Wenn du ihm eine Frage stellst, muss er normalerweise jedes Wort von vorne berechnen. Das dauert lange.

Um schneller zu sein, hat dieser Bibliothekar eine clevere Abkürzung: Der „Vorschau-Speicher" (Prefix Caching).

• Wie es funktioniert: Wenn du und dein Nachbar beide mit dem Satz „Guten Tag, wie geht es..." anfangen, merkt sich der Bibliothekar den ersten Teil („Guten Tag, wie geht es...") schon einmal. Wenn der Nachbar kommt, sagt er: „Ah, ich kenne das schon! Ich muss den Anfang nicht neu lesen, ich springe direkt zum Ende." Das spart enorm viel Zeit.
• Das Problem: Das ist super für die Geschwindigkeit. Aber es hat einen Haken. Weil der Bibliothekar den Anfang schon kennt, antwortet er schneller als bei einer völlig neuen Frage.

Der Dieb: Ein böser Hacker sitzt im selben Raum (das ist das Multi-Tenant-System, wo viele Nutzer denselben Server nutzen). Er stellt dem Bibliothekar immer wieder Fragen, die fast gleich sind, aber mit einem kleinen Unterschied.

• Er fragt: „Guten Tag, wie geht es Max?" -> Der Bibliothekar antwortet schnell (weil er „Guten Tag, wie geht es" schon kennt).
• Er fragt: „Guten Tag, wie geht es Lisa?" -> Der Bibliothekar antwortet langsam (weil er den Namen noch nicht kennt).

Der Hacker misst die Zeit mit einer Stoppuhr. Wenn es schnell geht, weiß er: „Aha! Der Bibliothekar hat den Namen des anderen Benutzers schon gesehen!" So kann er Wort für Wort erraten, was der andere Benutzer geschrieben hat, ohne ihn jemals zu sehen. Das nennt man einen Zeit-Side-Channel-Angriff.

Die bisherigen Lösungen: Der „Hammer"

Bisher gab es zwei Möglichkeiten, das zu verhindern, aber beide waren sehr unpraktisch:

1. Die „Einzelzelle"-Methode: Man verbietet dem Bibliothekar, sich irgendeine Erinnerung mit anderen zu teilen. Jeder bekommt sein eigenes kleines Zimmer.
   • Nachteil: Der Bibliothekar wird extrem langsam, weil er alles neu berechnen muss. Das ist wie ein Restaurant, in dem jeder Gast sein eigenes Geschirr mitbringen muss, weil man keine Teller teilen darf.
2. Die „Lärm-Methode": Man lässt den Bibliothekar bei jeder Antwort eine künstliche Pause machen, damit die Zeiten alle gleich aussehen.
   • Nachteil: Auch hier wird alles langsamer, und es ist wie ein Zaubertrick, der nicht immer funktioniert.

Die neue Lösung: CacheSolidarity (Der „Wachsame Wächter")

Die Forscher haben eine viel schlauere Lösung namens CacheSolidarity entwickelt. Statt alle zu isolieren, schützen sie nur das, was gefährlich ist.

Stell dir CacheSolidarity wie einen Wachsamkeits-System vor, das auf drei Prinzipien basiert:

1. Der „Namensschild"-Trick (Überwachung)

Jeder Eintrag im Gedächtnis des Bibliothekars bekommt ein kleines Namensschildchen. Darauf steht: „Dieser Teil wurde von Benutzer A geschrieben."

• Wenn Benutzer A wieder kommt, darf er den Teil nutzen. Alles ist gut.
• Wenn Benutzer B kommt und versucht, denselben Teil zu nutzen, schaut das System auf das Schild. Es denkt: „Moment mal! Das ist nicht dein Teil."

2. Der „Rote Strich" (Selektive Isolation)

Sobald das System merkt, dass ein Teil des Textes von zwei verschiedenen Personen genutzt wird (was für einen Hacker interessant ist), zieht es einen roten Strich.

• Der Bibliothekar darf den Anfang noch teilen (das ist sicher).
• Aber sobald der rote Strich erreicht ist, sagt das System: „Stop! Ab hier musst du neu rechnen."
• Das Ergebnis: Der Hacker sieht keine schnelle Antwort mehr, weil der Bibliothekar ab dem roten Strich wieder neu arbeiten muss. Der Diebstahl ist gestoppt. Der normale Benutzer A wird aber nicht gestoppt, er darf seinen eigenen Text weiter nutzen.

3. Der „Wetter-Check" (Intelligente Aktivierung)

Das ist der genialste Teil. Das System weiß: „Manchmal ist es so laut im Server-Raum (viele Nutzer gleichzeitig), dass man die schnellen und langsamen Antworten gar nicht mehr unterscheiden kann."

• Wenn es sehr laut ist (hohe Last), schaltet das System den Wächter aus, weil es eh niemanden stört.
• Wenn es ruhig ist und der Hacker leicht lauschen kann, schaltet es den Wächter ein.
• Das spart Energie und Zeit, weil der Wächter nicht ständig arbeiten muss, wenn keine Gefahr besteht.

Warum ist das so toll?

• Für die normalen Nutzer: Sie sind immer noch super schnell. Sie teilen sich den Anfang ihrer Texte, solange niemand versucht, sie auszuspionieren.
• Für die Sicherheit: Der Hacker bekommt keine schnellen Signale mehr. Er kann nicht mehr erraten, was der andere geschrieben hat.
• Für die Effizienz: Es ist wie ein Sicherheitsdienst, der nur dann die Türen verschließt, wenn ein Einbrecher versucht, hereinzukommen. Normalerweise laufen alle frei herum.

Zusammenfassend:
CacheSolidarity ist wie ein smartes Nachbarschafts-System. Es erlaubt den Nachbarn, Werkzeuge zu teilen (was die Arbeit beschleunigt), aber es schaut genau hin. Wenn jemand versucht, das Werkzeug eines anderen zu stehlen, wird das Werkzeug sofort „gesperrt" und nur für den rechtmäßigen Besitzer freigegeben. So bleibt die Gemeinschaft schnell, aber sicher.

Technische Zusammenfassung

Hier ist eine detaillierte technische Zusammenfassung des Papers „CacheSolidarity: Preventing Prefix Caching Side Channels in Multi-tenant LLM Serving Systems" auf Deutsch.

1. Problemstellung

Große Sprachmodelle (LLMs) nutzen in modernen Serving-Systemen Optimierungen wie Automatic Prefix Caching (APC), um die Inferenzleistung zu steigern. APC speichert und wiederverwendet zuvor berechnete Zustände (Key-Value-Tensoren) für den Anfangsteil einer Anfrage (den Präfix), wenn eine neue Anfrage mit demselben Text beginnt. Dies reduziert redundante Berechnungen erheblich und senkt die Latenz, insbesondere bei langen Prompts oder Multi-Turn-Konversationen.

Das Sicherheitsproblem:
APC führt jedoch zu Timing-Side-Channels. Da ein Cache-Hit (Wiederverwendung) deutlich schneller ist als ein Cache-Miss (Neuberechnung), entstehen messbare Latenzunterschiede (Time-to-First-Token, TTFT). In Multi-Tenant-Umgebungen, in denen der Cache zwischen verschiedenen Benutzern geteilt wird, können Angreifer diese Latenzunterschiede ausnutzen:

• Angriffsvektor: Ein Angreifer sendet kodierte Anfragen und misst die TTFT.
• Ziel: Durch schrittweises Raten von Wörtern und Beobachtung, ob ein Hit oder Miss auftritt, kann der Angreifer den Prompt eines anderen Benutzers (einschließlich sensibler Daten wie Namen oder medizinischer Diagnosen) rekonstruieren („Prompt Stealing").

Limitierungen bestehender Abwehrmechanismen:
Bisherige Lösungen sind ineffizient oder zu schwerfällig:

1. Vollständige Isolation: Deaktivierung des Caches zwischen Benutzern. Dies eliminiert die Sicherheitslücke, zerstört aber die Performance-Vorteile von APC (hohe Latenz, geringer Durchsatz).
2. Timing-Obfuskation: Hinzufügen von Rauschen, um Latenzunterschiede zu verschleiern. Dies führt zu unnötigen Verzögerungen für alle benignen Benutzer und ist oft nicht robust genug.
3. Selektive Isolation (semantisch): Analyse der Prompts auf „Sensitivität" mittels LLMs. Dies ist rechenintensiv, skaliert schlecht und kann Fehler bei der Klassifizierung machen.

2. Methodik: CacheSolidarity

CacheSolidarity ist ein System-Level-Ansatz, der die Sicherheit von LLM-Serving-Systemen gewährleistet, ohne die Leistung von APC zu opfern. Der Kerngedanke ist, dass nicht ganze Benutzer isoliert werden müssen, sondern nur die verdächtigen Präfixe, die zu Angriffen führen könnten.

Das System basiert auf drei Hauptkomponenten:

A. KV-Cache-Erweiterung (Metadata)

Jeder Eintrag im Key-Value-Cache wird um minimale Metadaten erweitert:

• OwnerID: Identifiziert den Benutzer, der den Cache-Eintrag ursprünglich erstellt hat.
• AttackFlag: Ein Marker, der anzeigt, dass ein Präfix von mehreren Benutzern genutzt wurde und daher potenziell unsicher ist.

B. Detector (Erkennung)

Der Detector überwacht Cache-Hits und entscheidet dynamisch über die Wiederverwendung:

• Szenario 1 (Unmarkiertes Präfix): Wenn ein Benutzer einen Cache-Eintrag nutzt, der ihm gehört, erfolgt die Wiederverwendung normal.
• Szenario 2 (Kreuzbenutzer-Hit): Wenn ein Benutzer einen Eintrag nutzt, der einem anderen Benutzer gehört (OwnerID unterscheidet sich), wird der Eintrag markiert (AttackFlag gesetzt).
• Szenario 3 (Isolierung): Wenn ein markiertes Präfix von einem Nicht-Eigentümer angefordert wird, stoppt die Wiederverwendung an dieser Stelle. Der Rest des Prompts wird neu berechnet (Cache-Miss für den Rest), während der markierte Teil isoliert bleibt.
• Ergebnis: Benigne Benutzer können ihre eigenen Pfade erweitern, aber Angreifer können nicht über markierte Knoten hinweg auf sensible Daten zugreifen.

C. Activator (Dynamische Aktivierung)

Da Timing-Side-Channels nur unter bestimmten Bedingungen ausnutzbar sind (z. B. bei niedriger Systemlast, großen Modellen und langen Präfixen), ist eine ständige Isolierung unnötig.

• Der Activator überwacht kontinuierlich die Latenzverteilung von Hits und Misses (mittels Kernel Density Estimation, KDE).
• Schwellenwert-Logik: Wenn die Verteilungen stark überlappen (hohe KDE-Overlap), sind Hits und Misses nicht unterscheidbar. In diesem Fall wird die Isolierung deaktiviert, um Performance zu sparen. Wenn die Verteilungen getrennt sind (niedrige Overlap), wird die Isolierung aktiviert.
• Dies ermöglicht eine adaptive Sicherheit, die sich an die aktuelle Workload, Hardware und Modellgröße anpasst.

3. Wichtige Beiträge

1. Analyse der Ausnutzbarkeit: Eine detaillierte Untersuchung zeigt, dass die Stärke des Timing-Side-Channels von vier Parametern abhängt: Länge des geteilten Präfixes, Größe des LLM-Modells, Systemlast (Requests pro Sekunde) und Hardware-Plattform.
2. Systemdesign (CacheSolidarity): Ein leichtgewichtiges System, das selektive Präfix-Isolierung statt Benutzer-Isolierung verwendet. Es benötigt keine semantische Analyse der Prompts.
3. Sicherheitsgarantien: Formale Analyse und empirische Validierung zeigen, dass CacheSolidarity Prompt-Stealing-Angriffe effektiv verhindert, indem es die Wiederverwendung von Präfixen zwischen Benutzern an kritischen Punkten unterbricht.
4. Implementierung und Open Source: Die Lösung wurde auf dem State-of-the-Art-System vLLM implementiert und wird als Open-Source-Projekt bereitgestellt.

4. Ergebnisse und Evaluation

Die Evaluation erfolgte auf einer NVIDIA A100 GPU mit verschiedenen LLMs (von 0,5B bis 13B Parametern) und realistischen Multi-Tenant-Workloads (basierend auf ShareGPT-Daten).

• Performance-Gewinn: Im Vergleich zu Systemen mit vollständiger Benutzer-Isolierung erreicht CacheSolidarity:
  • Bis zu 70 % höhere Cache-Wiederverwendungsrate.
  • Bis zu 30 % niedrigere Inferenz-Latenz (TTFT).
  • Die Performance liegt nahe an der des unsicheren „Prefix Caching" (nur ca. 5–10 % Abweichung), bietet aber volle Sicherheit.
• Overhead:
  • Zeit: Der zusätzliche Overhead pro Anfrage beträgt nur 0,007 ms (0,004 ms für den Detector, 0,003 ms für den Activator).
  • Speicher: Nur 32 Bytes pro Cache-Eintrag für Metadaten.
• Sicherheit: In Angriffsszenarien (20 Versuche eines Angreifers, ein Geheimnis zu erraten) zeigte CacheSolidarity keine signifikanten Latenzspitzen beim korrekten Raten. Im Gegensatz dazu war das ungeschützte System klar angreifbar.
• Robustheit: Das System funktioniert effektiv über verschiedene Modellgrößen und Workload-Muster hinweg, auch unter hoher Speicherbelastung.

5. Bedeutung und Fazit

CacheSolidarity demonstriert, dass Sicherheit in Multi-Tenant-LLM-Systemen nicht zwangsläufig mit einem massiven Performance-Verlust einhergehen muss. Durch den Ansatz der kooperativen Effizienz („Solidarity") – bei dem unschuldige Benutzer von gemeinsamem Caching profitieren, aber verdächtiges Verhalten durch selektive Isolierung gestoppt wird – schließt das System die Lücke zwischen unsicheren Optimierungen und ineffizienten Abwehrmechanismen.

Die Arbeit liefert einen praktischen Weg, um Timing-Side-Channels in der KI-Infrastruktur zu bekämpfen, ohne die Skalierbarkeit und Geschwindigkeit moderner LLM-Serving-Systeme zu beeinträchtigen. Sie unterstreicht die Notwendigkeit, Sicherheitsmaßnahmen dynamisch an die Ausnutzbarkeit von Seitenkanälen anzupassen, anstatt starre, ineffiziente Isolationsstrategien zu verwenden.