🤖 AI

Governing the KV Cache: Preventing Timing Side-Channel Leakage in Multi-Tenant LLM Inference

Questo articolo introduce KVGov, uno strato di governance che previene gli attacchi side-channel temporali nell'inferenza di LLM multi-tenant isolando crittograficamente le chiavi della cache KV tra i tenant tramite salatura per principale e uno scheduler di audit, eliminando così la fuga di dati tra i tenant e preservando al contempo il 93% dell'efficienza della cache dei prefissi.

Autori originali: Tejasvi C. Addagada

Pubblicato 2026-08-11

📖 8 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Tejasvi C. Addagada

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immagina una biblioteca frenetica e hi-tech dove un bibliotecario magico (l'IA) può rispondere a qualsiasi tua domanda. Per essere super veloce, questo bibliotecario tiene una "scheda di riferimento" con gli inizi di storia più comuni proprio sulla sua scrivania. Se fai una domanda che inizia con le stesse parole di qualcun altro, il bibliotecario non ha bisogno di rileggere l'intero libro; basta dare uno sguardo alla scheda di riferimento e saltare direttamente alla risposta. Questo è incredibilmente efficiente, risparmiando enormi quantità di tempo. Tuttavia, in una biblioteca affollata con molte persone diverse (tenant) che usano la stessa scrivania, una persona subdola potrebbe capire cosa stanno leggendo gli altri. Non avrebbero bisogno di vedere il libro; basterebbe osservare quanto tempo impiega il bibliotecario per trovare la risposta. Se il bibliotecario afferra la risposta istantaneamente, la persona subdola sa: "Ah, devono aver chiesto la stessa storia che ho appena chiesto io!". Se il bibliotecario deve camminare verso gli scaffali sul retro, significa che la storia è nuova. Misurando questi minuscoli ritardi, un malintenzionato potrebbe ricostruire i segreti privati o i prompt degli altri, trasformando una funzione di velocità in una falla di sicurezza.

Questo articolo affronta esattamente questo problema nel mondo dei Large Language Models (LLM), i chatbot IA super intelligenti che usiamo oggi. Questi modelli utilizzano una "KV cache" (la scheda di riferimento) per velocizzare le risposte ricordando le parti precedenti di una conversazione. L'autore ha scoperto che, in ambienti condivisi, questo trucco di velocità crea un "canale laterale temporale" (timing side channel) — un segnale segreto nascosto in quanto tempo vengono elaborate le cose. Ha scoperto che tre diversi gruppi di hacker hanno già dimostrato come usare questo segnale per rubare prompt privati con un successo quasi del 100%. L'articolo propone un nuovo sistema chiamato KVGov per risolvere il problema. Inveve di cercare solo di nascondere il tempo (il che è difficile), KVGov cambia le regole del gioco in modo che la scheda di riferimento sia completamente diversa per ogni singolo utente. È come dare a ogni visitatore della biblioteca la propria inchiostro invisibile unico, che rende la sua specifica scheda di riferimento illeggibile per chiunque altro. L'autore mostra, attraverso simulazioni e test su hardware reale, che questo metodo ferma tutti e tre i tipi di attacchi nel loro percorso, pur mantenendo la biblioteca abbastanza veloce da essere utile. Introduce anche un intelligente sistema di "guardia di sicurezza" che sa esattamente chi controllare più attentamente, e calcola un punto di svolta in cui diventa più sicuro smettere di condividere interamente la scheda di riferimento.

Il Grande Furto della Cache

Pensa alla memoria dell'IA come a una gigantesca lavagna condivisa. Quando poni all'IA una domanda, essa scrive le parti chiave della tua frase sulla lavagna in modo da non doverle ricalcolare se poni una domanda simile in seguito. Questa è la KV cache. In una configurazione multi-tenant (dove molte aziende o utenti diversi condividono lo stesso server IA), tutti condividono questa lavagna per risparmiare tempo.

Il problema è che la lavagna è troppo evidente. Se un utente subdolo (l'attaccante) chiede: "Qual è la capitale della Francia?" e l'IA risponde istantaneamente, l'attaccante sa: "Oh, qualcuno deve averlo chiesto di recente!". Se l'IA impiega molto tempo, l'attaccante sa: "Nessuno lo ha ancora chiesto". Provando migliaia di domande diverse e misurando i tempi delle risposte, l'attaccante può mappare esattamente cosa stanno chiedendo gli altri, anche se non può vedere le risposte stesse. Questo è chiamato un attacco tramite canale laterale temporale (timing side-channel attack).

L'articolo evidenzia tre modi specifici in cui gli hacker hanno usato questo:

PROMPTPEEK: L'hacker indovina un elenco di possibili domande e le temporizza tutte. Se il loro tempo corrisponde al pattern della vittima, sanno esattamente cosa ha chiesto la vittima.
EarlyBird: L'hacker prova a indovinare la domanda della vittima una parola alla volta. Se l'IA è veloce, l'hacker sa di aver indovinato la parola giusta.
InputSnatch: Questo è per domande strutturate, come la compilazione di un modulo. L'hacker conosce il template (ad esempio, "Mostra transazioni per l'account [NUMERO]") e prova semplicemente diversi numeri finché l'IA non è veloce, rivelando il numero di conto segreto.

L'autore ha testato questo su hardware reale (una GPU NVIDIA A100) e ha scoperto che la differenza di tempo è enorme: una richiesta "fredda" (nuove informazioni) ha impiegato 149,6 millisecondi, mentre una richiesta "in cache" (informazioni riutilizzate) ne ha impiegati solo 32,8. È un rapporto di 0,22, un segnale enorme e facile da individuare per un hacker.

La Soluzione: KVGov e l'Inchiostro Magico

L'articolo introduce KVGov, un nuovo livello di sicurezza che agisce come un guardiano. Il suo trucco principale è l'isolamento del namespace con chiave HMAC.

Immagina che ogni utente nella biblioteca abbia un timbro unico e segreto (un "salt"). Quando il bibliotecario scrive una domanda sulla lavagna, prima la timbra con l'inchiostro segreto dell'utente. Anche se due persone pongono esattamente la stessa domanda, l'inchiostro rende la voce sulla lavboard completamente diversa per tutti gli altri.

Come funziona: Il sistema prende l'ID dell'utente e una chiave segreta per creare un codice unico. Questo codice viene mescolato nella primissima fase di creazione della chiave della cache.
Il Risultato: Se un hacker prova a indovinare cosa ha chiesto una vittima, il proprio timbro segreto non corrisponderà a quello della vittima. La sonda dell'hacker apparirà sempre come un "errore" (lenta) perché il suo codice non corrisponde al codice della vittima sulla lavagna. Il segnale temporale scompare.

L'autore ha eseguito 1.000 prove simulate e ha scoperto che questo "HMAC-salt" da solo è stato sufficiente per far scendere il tasso di successo dell'attacco dal 100% allo 0% per tutti e tre i tipi di attacchi. Era l'unica parte del suo sistema che era strettamente necessaria; le altre parti aggiungevano solo ulteriori livelli di sicurezza.

Mantenere la Biblioteca Veloce (Il Trucco del Confine)

Potresti pensare: "Se tutti hanno la propria lavagna segreta, la biblioteca non diventerà lenta?". Se rendessimo ogni singolo utente proprietario di una lavagna totalmente separata, perderemmo il vantaggio di velocità derivante dalla condivisione di domande comuni (come "Ciao, come stai?").

L'articolo offre una soluzione intelligente chiamata Boundary Salting (Salatura del Confine).
Immagina una storia in cui le prime 2.000 parole sono uguali per tutti (il preambolo condiviso) e solo le ultime 100 parole sono diverse (la parte privata).

Vecchio modo: Timbra l'intera storia con l'inchiostro segreto. Nessuno può condividere le prime 2.000 parole.
Modo KVGov: Lascia le prime 2.000 parole senza timbro in modo che tutti possano condividerle. Timbra solo la primissima parola in cui le storie divergono.
Il Premio: Questo mantiene il 93% del vantaggio di velocità pur mantenendo le parti private segrete. L'autore stima che con un'introduzione condivisa di 2.000 parole e una coda privata di 119 parole, il sistema sarebbe ancora incredibilmente veloce (circa 41,2 ms per la parte privata), mantenendo la maggior parte dell'efficienza.

La Guardia di Sicurezza Intelligente: ORIGAMI

Anche con l'inchiostro magico, l'autore voleva assicurarsi che nessuno stesse cercando di aggirare le regole. Ha creato ORIGAMI, uno scheduler di audit intelligente.

Immagina che il manager della biblioteca abbia un budget limitato di guardie di sicurezza. Non può controllare tutti tutto il tempo. ORIGAMI utilizza una strategia matematica (chiamata approccio Stackelberg water-filling) per decidere chi controllare.

La Logica: Se un utente è molto prezioso (alto rischio) e ha una storia di comportamenti sospetti, riceve più guardie. Se un utente è a basso rischio, ne riceve meno.
Il Risultato: In simulazioni con 10 tenant e una miscela realistica di tipi di utenti (un "coefficiente di Gini" di 0,63), questo scheduling intelligente ha ridotto il successo atteso dell'attaccante del 12,6% rispetto al semplice monitoraggio casuale delle persone.

Quando Smettere di Condividere

Infine, l'articolo pone una grande domanda: "Quando è meglio smettere del tutto di condividere la lavagna?".

Hanno utilizzato un concetto chiamato Stabilità Evolutiva per trovare un punto di svolta. Hanno modellato una popolazione di utenti in cui alcuni condividono la cache (veloci ma rischiosi) e altri no (lenti ma sicuri).

La Scoperta: Se la percentuale di hacker nel sistema supera il 31,6%, diventa matematicamente meglio per tutti smettere di condividere la cache e tornare ad avere le proprie lavagne private. Al di sotto di quel numero, la condivisione rimane la strategia vincente. Questo fornisce ai manager della biblioteca una regola chiara: se sospetti che più di circa 1 utente su 3 siano malintenzionati, smetti di condividere la cache.

Cosa Non Risolve

L'articolo è molto chiaro su ciò che non risolve.

Non impedisce agli hacker di rubare il cervello dell'IA (i pesi del modello).
Non impedisce agli hacker di trarre in inganno l'IA affinché dica cose cattive (prompt injection).
Non risolve il problema delle "cache semantiche" (dove l'IA associa idee piuttosto che parole esatte). Per quelle, servirebbe un tipo diverso di serratura.
L'attacco EarlyBird (indovinare parola per parola) è per lo più bloccato dai nuovi motori IA che utilizzano "blocchi" di parole più grandi, ma l'autore avverte che per i moduli strutturati (come i numeri di conto), la dimensione del blocco non conta: la fuga temporale è comunque presente.

Conclusione

L'autore ha dimostrato che il vantaggio di velocità che amiamo nell'IA comporta un costo nascosto: un segnale temporale che rivela informazioni private. Ha dimostrato che non basta nascondere il segnale; bisogna rompere il legame tra l'utente e la cache. Utilizzando un "inchiostro magico" crittografico (HMAC-salt) e applicandolo solo dove iniziano i segreti, KVGov ferma completamente le fughe di dati mantenendo l'IA veloce. È una vittoria per la privacy che non richiede di rallentare il futuro dell'IA.

Riepilogo Tecnico: Governare la KV Cache (KVGov)

1. Definizione del Probleamento

I moderni motori di inferenza per Large Language Model (LLM) (ad es. vLLM, SGLang) utilizzano cache Key-Value (KV) per memorizzare gli stati di attenzione per i prefissi di token precedentemente computati. Questo meccanismo consente un'ottimizzazione significativa del throughput saltando la ricomputazione dei prefissi condivisi, riducendo il Time-to-First-Token (TTFT) da centinaia di millisecondi a decine di millisecondi.

Nelle implementazioni multi-tenant, questa cache è condivisa tra tutti i tenant per massimizzare i tassi di hit. Tuttavia, il documento identifica una vulnerabilità critica: la distinzione tra un hit e un miss della cache è osservabile come un segnale temporale (timing signal). Poiché le chiavi della cache sono attualmente computate esclusivamente sulle sequenze di token senza legarle al principale richiedente, un tenant avversario può sondare la cache per ricostruire i prompt privati di un altro tenant.

Tre famiglie indipendenti di attacchi sfruttano questo canale laterale temporale:

PROMPTPEEK (Wu et al., 2025): Utilizza il fingerprinting del TTFT su un vocabolario noto per correlare i vettori temporali con i fingerprint pre-computati della vittima, raggiungendo fino al 100% di Attack Success Rate (ASR) sulle cache a albero radix.
EarlyBird (Song et al., 2024): Ricostruisce i prompt token per token osservando gli hit della cache a granularità di singolo token (dimensione del blocco = 1). Sebbene vLLM 0.26.0 abbia rimosso la dimensione del blocco = 1, il documento sostiene che questa protezione fallisca contro i prompt strutturati tramite template, dove lo spazio di ricerca è limitato dal dominio del campo piuttosto che dall'intero vocabolario.
InputSnatch (Zheng et al., 2024b): Prende di mira sia le cache dei prefissi che quelle semantiche. Contro le cache dei prefissi, ricostruisce i prompt strutturati campo per campo; contro le cache semantiche, esplora gli spazi di embedding tramite clustering gerarchico.

La causa radice è l'assenza di isolamento del namespace per singolo principale nella computazione delle chiavi della cache.

2. Metodologia: Il Framework KVGov

L'autore presenta KVGov, uno strato di governance unificato progettato per eliminare la causa radice di questi attacchi senza modificare i pesi del modello o le pipeline di generazione.

2.1 Isolamento del Namespace tramite HMAC-Keyed

Il meccanismo centrale lega la risoluzione della cache al principale autenticato.

Meccanismo: Un sale per singolo principale $\sigma_p$ è derivato utilizzando una funzione HMAC: $\sigma_p = \text{HMACK}(\text{secret}, \text{principal id})$ .
Implementazione: Questo sale alimenta la catena di hash dei blocchi. Per una dimensione del blocco $B$ , il primo hash del blocco diventa $h_0 = H(\sigma_p \parallel \text{tokens}_{0..B-1})$ . I blocchi successivi sono concatenati da questa radice.
Effetto: Poiché il sale è derivato da un segreto lato server sconosciuto all'avversario, le chiavi della cache per la stessa sequenza di token diventano crittograficamente disgiunte tra diversi principali. Le sonde di un avversario non colpiranno mai le voci della cache di una vittima, risultando in un pattern temporale "tutto-MISS" indipendentemente dallo stato effettivo della cache della vittima.

2.2 Boundary Salting (Ottimizzazione dell'Efficienza)

Per affrontare la potenziale perdita di efficienza della cache cross-principal, il documento propone il Boundary Salting.

Concetto: Invece di salare l'intera catena (che isolerebbe ogni blocco), il sale viene iniettato solo al punto di divergenza ( $k$ ) dove termina il preamble condiviso e inizia il contenuto privato.
Logica: I blocchi da $0 $a$ k-1$ (preamble condiviso) rimangono globalmente routabili e condivisi. I blocchi da $k$ in poi sono crittograficamente isolati.
Beneficio: Questo mantiene il beneficio della cache del prefisso per la parte condivisa dei prompt (ad es. istruzioni di sistema) pur prevenendo la fuga di informazioni temporali per la parte privata. Il documento stima che questo preservi circa il 93% del beneficio della cache del prefisso.

2.3 ORIGAMI: Programmatore di Audit Stackelberg

Per rilevare comportamenti di sondaggio anomali, KVGov incorpora ORIGAMI, uno scheduler di audit basato sulla teoria dei giochi di Stackelberg.

Meccanismo: Alloca un budget di audit finito tra i tenant utilizzando un algoritmo duale "water-filling".
Obiettivo: Minimizzare l'utilità attesa dell'avversario effettuando audit ai tenant con il più alto "valore a rischio" ( $v_i$ ) in proporzione al loro rischio, piuttosto che effettuare audit casuali.
Risultato: La soluzione equalizza il payoff dell'avversario tra i target sottoposti ad audit, impedendo loro di concentrarsi su target ad alto valore non monitorati.

2.4 Analisi della Stabilità Evolutiva

Il documento modella la selezione dello scope della cache (globale vs effimero) come un gioco evolutivo.

Risultato: Identifica un punto di svolta al 31,6% di prevalenza dell'avversario. Al di sotto di questa soglia, la cache globale è evolutivamente stabile; al di sopra, la cache effimera (isolata) diventa la strategia stabile.

3. Contributi Chiave

Difesa Unificata: KVGov è il primo sistema che sconfigge simultaneamente tutte e tre le famiglie di attacchi (PROMPTPEK, EarlyBird, InputSnatch) affrontando la causa radice (mancanza di isolamento del namespace) anziché oscurare il tempo.
Meccanismo Necessario e Sufficiente: Uno studio di ablazione dimostra che l'HMAC-salt da solo è il componente necessario e sufficiente per la garanzia di privacy, riducendo l'ASR allo 0% in tutti gli attacchi. Altri componenti (iniezione di rumore, controllo di ammissione) forniscono una difesa in profondità ma non sono strettamente richiesti per la correzione crittografica centrale.
Validazione Hardware: Il documento conferma l'esistenza del canale laterale temporale su hardware reale (NVIDIA A100, vLLM 0.26.0, Qwen2.5-7B), misurando un rapporto TTFT cold/cached di 0,22 (ben al di sotto della soglia di violazione di 0,40). Il canale è stato replicato anche su uno stack indipendente (Apple M4, llama.cpp) con un rapporto di 0,093.
Giudici Deterministici: La valutazione sostituisce i giudici euristici basati su LLM con giudici deterministici specifici per l'attacco (correlazione di Pearson, sovrapposizione esatta dei token, tasso di recupero dei token), garantendo il 100% di accuratezza nel modello di attacco simulato.
Preservazione dell'Efficienza: L'approccio "Boundary Salting" dimostra che isolamento ed efficienza della cache non sono mutuamente esclusivi; iniettare il sale al punto di divergenza mantiene la maggior parte dei benefici del riutilizzo del prefisso.

4. Risultati

Attack Success Rate (ASR): Sotto la difesa KVGov (specificamente l'HMAC-salt), l'ASR per PROMPTPEEK, EarlyBird e InputSnatch scende allo 0,0% nella simulazione.
Difese Parziali: Il flushing al confine della sessione (una difesa parziale) lascia PROMPTPEEK al 19,5% di ASR e InputSnatch al 9,8% di ASR, dimostrando l'insufficienza di un semplice flushing.
Performance di ORIGAMI: Nei carichi di lavoro enterprise con alta eterogeneità di valore (Gini = 0,63), ORIGAMI ottiene una riduzione del 12,6% dell'utilità attesa dell'avversario rispetto all'audit casuale.
Overhead: L'overhead crittografico della derivazione dell'HMAC-salt è trascurabile (~1,3 µs per richiesta), rappresentando meno dello 0,005% della latenza del TTFT in cache.
Stabilità Evolutiva: Le simulazioni confermano che la cache globale domina quando la prevalenza dell'avversario è inferiore al 31,6%, mentre la cache effimera prevale sopra tale soglia.

5. Significato e Rivendicazioni

Il documento sostiene che KVGov alteri fondamentalmente la postura di sicurezza delle inferenze LLM multi-tenant passando dall'oscuramento (che è fragile e spesso inefficace contro i prompt strutturati) all'isolamento crittografico.

Eliminazione della Causa Radice: Legando le chiavi della cache ai singoli principali tramite hashing resistente alle collisioni, il documento sostiene che l'oracolo temporale venga effettivamente rimosso. Le sonde di un avversario non possono più risolvere le voci di una vittima, rendendo il segnale temporale privo di informazioni.
Scalabilità: La difesa è leggera e implementabile accanto ai motori esistenti (vLLM, SGLang) senza richiedere modifiche all'architettura del modello sottostante o ai meccanismi di attenzione.
Prospettiva di Governance: Il documento inquadra la gestione della cache non solo come un'ottimizzazione dell'infrastruttura, ma come un problema di governance. Fornisce criteri quantitativi (il punto di svolta del 31,6%) e strumenti algoritmici (ORIGAMI) per consentire agli operatori di prendere decisioni informate sullo scope della cache in base al proprio panorama delle minacce.

L'autore nota esplicitamente i limiti: la difesa copre le cache dei prefissi con chiave hash, ma richiede un'istanza diversa (partizionamento degli indici) per le cache semantiche. Inoltre, sebbene il boundary salting sia teoricamente efficiente, la sua misurazione end-to-end nei motori di produzione è identificata come lavoro futuro.