🤖 AI

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

Cet article introduit KVGov, une couche de gouvernance qui empêche les attaques par canal auxiliaire de type temporels dans l'inférence de LLM multi-locataires en isolant cryptographiquement les clés du cache KV entre les locataires via un salage par principal et un ordonnanceur d'audit, éliminant ainsi les fuites inter-locataires tout en préservant 93 % de l'efficacité du cache de préfixe.

Auteurs originaux : Tejasvi C. Addagada

Publié 2026-08-11

📖 10 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Tejasvi C. Addagada

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez une bibliothèque technologique et animée où un bibliothécaire magique (l'IA) peut répondre à toutes vos questions. Pour être super rapide, ce bibliothécaire garde une « fiche de référence » des débuts d'histoires les plus courants directement sur son bureau. Si vous posez une question qui commence par les mêmes mots que quelqu'un d'autre, le bibliothécaire n'a pas besoin de relire tout le livre ; il jette simplement un coup d'œil à la fiche de référence et saute directement à la réponse. C'est incroyablement efficace, ce qui permet d'économiser énormément de temps. Cependant, dans une bibliothèque très fréquentée par de nombreuses personnes (locataires) utilisant le même bureau, une personne sournoise pourrait découvrir ce que les autres lisent. Elle n'aurait pas besoin de voir le livre ; elle n'aurait qu'à observer le temps qu'il faut au bibliothécaire pour trouver la réponse. Si le bibliothécaire trouve la réponse instantanément, la personne sournoise sait : « Ah, ils doivent avoir posé la même question que moi à l'instant ! » Si le bibliothécaire doit marcher jusqu'aux étagères du fond, cela signifie que l'histoire est nouvelle. En chronométrant ces minuscules délais, un acteur malveillant pourrait reconstruire les secrets privés ou les requêtes des autres, transformant une caractéristique de vitesse en une fuite de sécurité.

Ce document s'attaque exactement à ce problème dans le monde des grands modèles de langage (LLM), les chatbots IA super intelligents que nous utilisons aujourd'hui. Ces modèles utilisent un « cache KV » (la fiche de référence) pour accélérer les réponses en se souvenant des parties précédentes d'une conversation. L'auteur a découvert que dans les environnements partagés, cette astuce de vitesse crée un « canal auxiliaire de temporisation » (timing side channel) — un signal secret caché dans le temps que prennent les actions. Il a découvert que trois groupes différents de hackers ont déjà montré comment utiliser ce signal pour voler des requêtes privées avec un succès de près de 100 %. Le document propose un nouveau système appelé KVGov pour corriger cela. Au lieu de simplement essayer de cacher le temps de réponse (ce qui est difficile), KVGov change les règles du jeu pour que la fiche de référence soit complètement différente pour chaque utilisateur. C'est comme donner à chaque visiteur de la bibliothèque sa propre encre invisible et unique, rendant sa fiche de référence spécifique illisible pour n'importe qui d'autre. L'auteur démontre, par des simulations et des tests sur matériel réel, que cette méthode arrête net les trois types d'attaques, tout en gardant la bibliothèque assez rapide pour être utile. Ils introduisent également un système de « garde de sécurité » intelligent qui sait exactement qui surveiller de plus près, et ils calculent le point de bascule où il devient plus sûr d'arrêter de partager totalement la fiche de référence.

Le grand braquage du cache

Considérez la mémoire de l'IA comme un immense tableau blanc partagé. Lorsque vous posez une question à l'IA, elle écrit les parties clés de votre phrase sur le tableau pour ne pas avoir à les recalculer si vous posez plus tard une question similaire. C'est le cache KV. Dans une configuration multi-locataire (où de nombreuses entreprises ou utilisateurs différents partagent le même serveur d'IA), tout le monde partage ce tableau blanc pour gagner du temps.

Le problème est que le tableau blanc est trop évident. Si un utilisateur sournois (l'attaquant) demande : « Quelle est la capitale de la France ? » et que l'IA répond instantanément, l'attaquant sait : « Oh, quelqu'un d'autre a dû poser cette question récemment ! » Si l'IA prend du temps, l'attaquant sait : « Personne n'a encore posé cette question. » En essayant des milliers de questions différentes et en chronométrant les réponses, l'attaquant peut cartographier exactement ce que les autres demandent, même s'il ne peut pas voir les réponses elles-mêmes. C'est ce qu'on appelle une attaque par canal auxiliaire de temporisation.

Le document souligne trois façons spécifiques dont les hackers ont utilisé cela :

PROMPTPEEK : Le hacker devine une liste de questions possibles et les chronomètre toutes. Si leur temporisation correspond au schéma de la victime, ils savent exactement ce que la victime a demandé.
EarlyBird : Le hacker essaie de deviner la question de la victime mot par mot. Si l'IA est rapide, il sait qu'il a trouvé le bon mot.
InputSnatch : Ceci concerne les questions structurées, comme le remplissage d'un formulaire. Le hacker connaît le modèle (par exemple, « Afficher les transactions pour le compte [NUMÉRO] ») et essaie simplement différents numéros jusqu'à ce que l'IA soit rapide, révélant ainsi le numéro de compte secret.

L'auteur a testé cela sur du matériel réel (un GPU NVIDIA A100) et a constaté que la différence de temps est énorme : une requête « froide » (nouvelle information) a pris 149,6 millisecondes, tandis qu'une requête « mise en cache » (information réutilisée) n'a pris que 32,8 millisecondes. C'est un ratio de 0,22, ce qui est un signal massif et facile à repérer pour un hacker.

La solution : KVGov et l'encre magique

Le document présente KVGov, une nouvelle couche de sécurité qui agit comme un garde-barrière. Son astuce principale est l'isolation d'espace de noms par clé HMAC.

Imaginez que chaque utilisateur de la bibliothèque possède un tampon secret unique (un « sel » ou « salt »). Lorsque le bibliothécaire écrit une question sur le tableau blanc, il la tamponne d'abord avec l'encre secrète de l'utilisateur. Même si deux personnes posent exactement la même question, l'encre fait que l'entrée sur le tableau blanc paraît complètement différente pour tous les autres.

Comment ça marche : Le système prend l'ID de l'utilisateur et une clé secrète pour créer un code unique. Ce code est mélangé à la toute première étape de la création de la clé de cache.
Le résultat : Si un hacker tente de deviner ce qu'une victime a demandé, son propre tampon secret ne correspondra pas à celui de la victime. La sonde du hacker apparaîtra toujours comme un « échec » (lent) car son code ne correspond pas au code de la victime sur le tableau. Le signal de temporisation disparaît.

L'auteur a mené 1 000 essais simulés et a constaté que cet « HMAC-salt » seul suffisait pour faire passer le taux de réussite des attaques de 100 % à 0 % pour les trois types d'attaques. C'était la seule partie de leur système qui était strictement nécessaire ; les autres parties n'ajoutaient que des couches de sécurité supplémentaires.

Garder la bibliothèque rapide (L'astuce de la limite)

Vous pourriez penser : « Si tout le monde a son propre tableau blanc secret, la bibliothèque ne va-t-elle pas devenir lente ? » Si nous faisions en sorte que chaque utilisateur ait un tableau totalement séparé, nous perdrions le bénéfice de partager les questions communes (comme « Bonjour, comment allez-vous ? »).

Le document propose une solution ingénieuse appelée Salage de limite (Boundary Salting).
Imaginez une histoire où les 2 000 premiers mots sont les mêmes pour tout le monde (le préambule partagé), et seuls les 100 derniers mots sont différents (la partie privée).

Ancienne méthode : Tamponner toute l'histoire avec l'encre secrète. Personne ne peut partager les 2 000 premiers mots.
Méthode KVGov : Laisser les 2 000 premiers mots sans tampon afin que tout le monde puisse les partager. Ne tamponner que le tout premier mot où les histoires divergent.
Le gain : Cela permet de conserver 93 % du bénéfice de vitesse tout en gardant les parties privées secrètes. L'auteur estime qu'avec une introduction partagée de 2 000 mots et une fin privée de 119 mots, le système resterait incroyablement rapide (environ 41,2 ms pour la partie privée), conservant la majeure partie de l'efficacité.

Le garde de sécurité intelligent : ORIGAMI

Même avec l'encre magique, l'auteur voulait s'assurer que personne ne tentait de passer en force. Ils ont créé ORIGAMI, un planificateur d'audit intelligent.

Imaginez que le directeur de la bibliothèque dispose d'un budget limité de gardes de sécurité. Ils ne peuvent pas surveiller tout le monde tout le temps. ORIGAMI utilise une stratégie mathématique (appelée approche de remplissage d'eau de Stackelberg) pour décider qui surveiller.

La logique : Si un utilisateur est très précieux (haut risque) et a un historique de comportement suspect, il reçoit plus de gardes. Si un utilisateur présente un risque faible, il en reçoit moins.
Le résultat : Dans des simulations avec 10 locataires et un mélange réaliste de types d'utilisateurs (un « coefficient de Gini » de 0,63), ce planning intelligent a réduit le succès attendu de l'attaquant de 12,6 % par rapport à un simple choix aléatoire de personnes à surveiller.

Quand arrêter de partager

Enfin, le document pose une question cruciale : « Quand est-il préférable d'arrêter de partager totalement le tableau blanc ? »

Ils ont utilisé un concept appelé Stabilité Évolutive pour trouver un point de bascule. Ils ont modélisé une population d'utilisateurs où certains partagent le cache (rapide mais risqué) et d'autres non (lent mais sûr).

La conclusion : Si le pourcentage de hackers dans le système dépasse 31,6 %, il devient mathématiquement préférable pour tout le monde d'arrêter de partager le cache et de revenir à leurs propres tableaux privés. En dessous de ce chiffre, le partage reste la stratégie gagnante. Cela donne aux directeurs de bibliothèque une règle claire : si vous soupçonnez que plus d'un tiers des utilisateurs sont des acteurs malveillants, arrêtez de partager le cache.

Ce que cela ne résout pas

Le document est très clair sur ce qu'il ne résout pas.

Il n'empêche pas les hackers de voler le cerveau de l'IA (les poids du modèle).
Il n'empêche pas les hackers de manipuler l'IA pour qu'elle dise des choses malveillantes (injection de prompt).
Il ne corrige pas les « caches sémantiques » (où l'IA correspond des idées plutôt que des mots exacts). Pour ceux-là, il faudrait un type de verrou différent.
L'attaque EarlyBird (deviner mot par mot) est principalement bloquée par les nouveaux moteurs d'IA qui utilisent des « blocs » de mots plus larges, mais l'auteur prévient que pour les formulaires structurés (comme les numéros de compte), la taille du bloc n'a pas d'importance — la fuite de temporisation est toujours présente.

L'essentiel

L'auteur a prouvé que le gain de vitesse que nous aimons dans l'IA vient avec un coût caché : un signal de temporisation qui divulgue des informations privées. Il a montré que simplement cacher le signal ne suffit pas ; il faut briser le lien entre l'utilisateur et le cache. En utilisant une « encre magique » cryptographique (HMAC-salt) et en l'appliquant uniquement là où les secrets commencent, KVGov arrête complètement les fuites tout en gardant l'IA rapide. C'est une victoire pour la confidentialité qui ne nécessite pas de ralentir l'avenir de l'IA.

Résumé Technique : Gouverner le Cache KV (KVGov)

1. Énoncé du Problème

Les moteurs d'inférence de modèles de langage de grande taille (LLM) modernes (par exemple, vLLM, SGLang) utilisent des caches de clés-valeurs (KV) pour stocker les états d'attention des préfixes de jetons précédemment calculés. Ce mécanisme permet une optimisation significative du débit en évitant la recomputation des préfixes partagés, réduisant ainsi le temps de premier jeton (TTFT) de centaines de millisecondes à quelques dizaines de millisecondes.

Dans les déploiements multi-locataires, ce cache est partagé entre tous les locataires afin de maximiser les taux de succès (hit rates). Cependant, l'article identifie une vulnérabilité critique : la distinction entre un succès de cache (cache hit) et un échec de cache (cache miss) est observable sous la forme d'un signal temporel. Comme les clés de cache sont actuellement calculées uniquement sur les séquences de jetons sans être liées au principal demandeur, un locataire malveillant peut sonder le cache pour reconstruire les prompts privés d'un autre locataire.

Trois familles d'attaques indépendantes exploitent ce canal auxiliaire temporel :

PROMPTPEEK (Wu et al., 2025) : Utilise le profilage du TTFT à travers un vocabulaire connu pour corréler les vecteurs de temps avec des empreintes pré-calculées de la victime, atteignant un taux de succès de l'attaque (ASR) allant jusqu'à 100 % sur les caches à arbre radix.
EarlyBird (Song et al., 2024) : Reconstruit les prompts jeton par jeton en observant les succès de cache à une granularité de jeton unique (taille de bloc = 1). Bien que vLLM 0.26.0 ait supprimé la taille de bloc = 1, l'article soutient que cette protection échoue contre les prompts structurés par modèles (templates), où l'espace de recherche est limité par le domaine du champ plutôt que par le vocabulaire complet.
InputSnatch (Zheng et al., 2024b) : Cible à la fois les caches de préfixes et les caches sémantiques. Contre les caches de préfixes, il reconstruit les prompts structurés champ par champ ; contre les caches sémantiques, il explore les espaces de plongement (embeddings) via un partitionnement hiérarchique.

La cause profonde est l'absence d'isolation de l'espace de noms par principal dans le calcul de la clé de cache.

2. Méthodologie : Le Cadre KVGov

L'auteur présente KVGov, une couche de gouvernance unifiée conçue pour éliminer la cause profonde de ces attaques sans modifier les poids du modèle ou les pipelines de génération.

2.1 Isolation d'Espace de Noms par HMAC-Clé

Le mécanisme central lie la résolution du cache au principal authentifié.

Mécanisme : Un sel par principal $\sigma_p$ est dérivé à l'aide d'une fonction HMAC : $\sigma_p = \text{HMACK}(\text{secret}, \text{principal id})$ .
Implémentation : Ce sel initialise la chaîne de hachage des blocs. Pour une taille de bloc $B$ , le premier hachage de bloc devient $h_0 = H(\sigma_p \parallel \text{tokens}_{0..B-1})$ . Les blocs suivants sont chaînés à partir de cette racine.
Effet : Comme le sel est dérivé d'un secret côté serveur inconnu de l'adversaire, les clés de cache pour la même séquence de jetons deviennent cryptographiquement disjointes entre différents principaux. Les sondages d'un adversaire ne toucheront jamais les entrées de cache d'une victime, résultant en un schéma de temps "tout-ÉCHEC" (all-MISS) quel que soit l'état réel du cache de la victime.

2.2 Salage de Frontière (Optimisation de l'Efficacité)

Pour remédier à la perte potentielle d'efficacité du cache inter-locataire, l'article propose le Salage de Frontière (Boundary Salting).

Concept : Au lieu de saler la racine de la chaîne (ce qui isole chaque bloc), le sel est injecté uniquement au niveau de la frontière de divergence ( $k$ ) où le préambule partagé se termine et où le contenu privé commence.
Logique : Les blocs $0 $à$ k-1$ (préambule partagé) restent globalement routables et partagés. Les blocs $k$ et au-delà sont cryptographiquement isolés.
Avantage : Cela conserve le bénéfice du cache de préfixe pour la partie partagée des prompts (ex: instructions système) tout en empêchant la fuite temporelle pour la partie privée. L'article estime que cela conserve environ 93 % du bénéfice du cache de préfixe.

2.3 ORIGAMI : Planificateur d'Audit de Stackelberg

Pour détecter les comportements de sondage anormaux, KVGov incorpore ORIGAMI, un planificateur d'audit basé sur la théorie des jeux de Stackelberg.

Mécanisme : Il alloue un budget d'audit fini entre les locataires en utilisant un algorithme dual de type "remplissage de réservoir" (water-filling).
Objectif : Minimiser l'utilité attendue de l'adversaire en auditant les locataires ayant la plus haute "valeur à risque" ( $v_i$ ) proportionnellement à leur risque, plutôt qu'en auditant de manière aléatoire.
Résultat : La solution égalise le gain de l'adversaire entre les cibles auditées, empêchant ce dernier de se concentrer sur des locataires à haute valeur non surveillés.

2.4 Analyse de Stabilité Évolutive

L'article modélise la sélection de la portée du cache (globale vs éphémère) comme un jeu évolutif.

Constat : Il identifie un point de bascule à 31,6 % de prévalence de l'adversaire. En dessous de ce seuil, le cache global est évolutivement stable ; au-dessus, le cache éphémère (isolé) devient la stratégie stable.

3. Contributions Clés

Défense Unifiée : KVGov est le premier système capable de vaincre simultanément les trois familles d'attaques (PROMPTPEEK, EarlyBird, InputSnatch) en traitant la cause racine (absence d'isolation d'espace de noms) plutôt qu'en obscurcissant le temps.
Mécanisme Nécessaire et Suffisant : Une étude d'ablation démontre que le sel HMAC seul est le composant nécessaire et suffisant pour la garantie de confidentialité, réduisant l'ASR à 0 % pour toutes les attaques. Les autres composants (injection de bruit, contrôle d'admission) fournissent une défense en profondeur mais ne sont pas strictement requis pour la correction cryptographique de base.
Validation Matérielle : L'article confirme l'existence du canal auxiliaire temporel sur du matériel réel (NVIDIA A100, vLLM 0.26.0, Qwen2.5-7B), mesurant un ratio TTFT froid/mis en cache de 0,22 (bien en dessous du seuil de violation de 0,40). Le canal a également été répliqué sur une pile indépendante (Apple M4, llama.cpp) avec un ratio de 0,093.
Juges Déterministes : L'évaluation remplace les juges heuristiques basés sur les LLM par des juges déterministes spécifiques aux attaques (corrélation de Pearson, chevauchement exact de jetons, taux de récupération de jetons), garantissant une précision de 100 % dans le modèle d'attaque simulé.
Préservation de l'Efficacité : L'approche de "Salage de Frontière" démontre que l'isolation et l'efficacité du cache ne sont pas mutuellement exclusives ; l'injection du sel à la frontière de divergence conserve la majorité des bénéfices de réutilisation de préfixe.

4. Résultats

Taux de Succès de l'Attaque (ASR) : Sous la défense KVGov (spécifiquement le sel HMAC), l'ASR pour PROMPTPEEK, EarlyBird et InputSnatch tombe à 0,0 % en simulation.
Défenses Partielles : Le vidage de session (une défense partielle) laisse PROMPTPEEK à 19,5 % d'ASR et InputSnatch à 9,8 % d'ASR, démontant l'insuffisance d'un simple vidage.
Performance d'ORIGAMI : Dans les charges de travail d'entreprise avec une forte hétérogénéité de valeur (Gini = 0,63), ORIGAMI atteint une réduction de 12,6 % de l'utilité attendue de l'adversaire par rapport à un audit aléatoire.
Surcharge (Overhead) : La surcharge cryptographique de la dérivation du sel HMAC est négligeable (~1,3 µs par requête), représentant moins de 0,005 % de la latence TTFT en cache.
Stabilité Évolutive : Les simulations confirment que le cache global domine lorsque la prévalence de l'adversaire est inférieure à 31,6 %, tandis que le cache éphémère prévaut au-dessus de ce seuil.

5. Signification et Revendications

L'article affirme que KVGov modifie fondamentalement la posture de sécurité de l'inférence LLM multi-locataire en passant de l'obscurcissement (qui est fragile et souvent inefficace contre les prompts structurés) à l'isolation cryptographique.

Élimination de la Cause Racine : En liant les clés de cache aux principaux authentifiés via un hachage résistant aux collisions, l'article soutient que l'oracle temporel est effectivement supprimé. Les sondages d'un adversaire ne peuvent plus correspondre aux entrées d'une victime, rendant le signal temporel non informatif.
Évolutivité : La défense est légère et déployable aux côtés des moteurs existants (vLLM, SGLang) sans nécessiter de modifications de l'architecture du modèle sous-jacent ou des mécanismes d'attention.
Perspective de Gouvernance : L'article cadre la gestion du cache non pas seulement comme une optimisation d'infrastructure, mais comme un problème de gouvernance. Il fournit des critères quantitatifs (le point de bascule de 31,6 %) et des outils algorithmiques (ORIGAMI) pour permettre aux opérateurs de prendre des décisions éclairées sur la portée du cache en fonction de leur paysage de menaces.

L'auteur note explicitement des limites : la défense couvre les caches de préfixes indexés par hachage mais nécessite une instanciation différente (partitionnement d'index) pour les caches sémantiques. De plus, bien que le salage de frontière soit théoriquement efficace, sa mesure de bout en bout dans les moteurs de production est identifiée comme un travail futur.