De KV-cache is de nieuwe perimeter: timing-aanvallen op gedeelde LLM-infrastructuur

De overgang van single-tenant naar multi-tenant AI-infrastructuur is onvermijdelijk. Rekenkracht is duur. GPU's zijn schaars. Elke Nederlandse overheidsorganisatie die een eigen LLM wil draaien, kan dat simpelweg niet betalen. Dus delen we. Maar wat we delen, kan lekken.

Een nieuw arXiv-paper toont aan dat de KV-cache een timing side-channel is. Deze geheugenbuffer versnelt LLM-inference. Een kwaadwillende tenant kan hiermee achterhalen wat een andere tenant verwerkt. Niet door de data zelf te lezen. Door te meten hoe lang bepaalde operaties duren. We hebben hier te maken met een concrete aanvalsvector. De vertrouwelijkheid van gedeelde AI-systemen staat op het spel.

Voor Nederlandse overheidsorganisaties die overwegen om LLM-capaciteit te delen via een gezamenlijk platform, is dit signaal ernstig. De BIO2 verplicht logging en monitoring. De NIS2 verplicht risicobeheer. De AVG verplicht passende technische maatregelen. Een timing side-channel op gedeelde inference valt onder alle drie.

Wat is de KV-cache precies?

Bij autoregressieve LLM-generatie berekent het model voor elk nieuw token de aandacht over alle voorgaande tokens. Zonder caching zou dat betekenen dat je bij elk token de volledige sequentie opnieuw moet verwerken. Dat is computationeel absurd.

De KV-cache slaat de Key- en Value-tensors op voor elke laag van het transformer-model. Bij een nieuw token hoef je dan alleen de Query voor het nieuwe token te berekenen. Je doet de aandacht over de gecachte Keys en Values. De complexiteit daalt van O(n²) naar O(n) per token. De geheugenvoetafdruk groeit lineair met de sequentielengte.

Formeel: voor een model met L lagen, H aandacht-koppen, en dimensie d per kop, slaat de KV-cache per token 2 × L × H × d waarden op. Bij Llama-2-70B met 80 lagen, 64 koppen en een dimensie van 128, is dat 2 × 80 × 64 × 128 = 1.310.720 waarden per token. In float16 is dat 2,6 MB per token. Een gesprek van 2000 tokens kost dus meer dan 5 GB aan KV-cache.

Dit is geen bijzaak. Dit is de dominante geheugenfactor in moderne inference.

De timing side-channel: hoe het werkt

Het paper beschrijft een aanval waarbij een kwaadwillende tenant hetzelfde fysieke GPU-geheugen deelt met een slachtoffer-tenant. De aanvaller doet een inference-verzoek en meet de latentie van specifieke tokens. Omdat de KV-cache van het slachtoffer geheugen bezet houdt, beïnvloedt dit de geheugenbandbreedte die beschikbaar is voor de aanvaller.

De kern is dat de aanval gebruikmaakt van het verschil tussen cache-hits en cache-misses. Wanneer de aanvaller een token genereert dat overeenkomt met een token dat al in de gedeelde cache staat, is de latentie lager. Bij een token dat niet gecachet is, duurt het langer. Door dit verschil systematisch te meten over vele verzoeken, kan de aanvaller een woordenboek opbouwen. Dit woordenboek bevat tokens die het slachtoffer recent heeft verwerkt.

De aanval kent drie fasen:

1. Cache-occupatie: de aanvaller vult de cache met bekende tokens en meet de baseline-latentie.
2. Slachtoffer-verwerking: het slachtoffer doet een inference-verzoek, waardoor de cache-inhoud verandert.
3. Cache-probing: de aanvaller meet opnieuw de latentie voor specifieke tokens en vergelijkt met de baseline.

Het verschil in latentie is klein, in de orde van microseconden, maar meetbaar. Met voldoende samples en statistische verwerking kan de aanvaller met hoge betrouwbaarheid bepalen welke tokens het slachtoffer heeft gegenereerd.

Formele definitie van het probleem

Laat C de KV-cache zijn, een functie van de verwerkte sequenties. Laat t een token zijn en laat L(t, C) de latentie zijn van het genereren van token t gegeven cache C. De side-channel bestaat als:

∃ t₁, t₂ ∈ V : |L(t₁, C) - L(t₂, C)| > ε

waarbij V de vocabulaire is en ε de meetbare drempel. De aanvaller wil een functie f construeren die, gegeven een reeks latentiemetingen, de inhoud van C schat:

f : ℝⁿ → 𝒫(V)

met een nauwkeurigheid die significant beter is dan willekeurig.