Good-Enough LLM Obfuscation (GELO)

GELO est un protocole d'obfuscation léger pour les grands modèles de langage qui préserve la confidentialité des invites en masquant les états cachés avec un mélange inversible par lot, permettant ainsi d'équilibrer la sécurité contre les attaques d'observation mémoire et la latence d'inférence.

L'essentiel

🎭 Le Problème : Le Magicien et le Spectateur Curieux

Imaginez que vous voulez utiliser un super-magicien (une Intelligence Artificielle ou LLM) pour écrire un poème secret ou analyser un document confidentiel.

Le problème, c'est que ce magicien ne travaille pas dans votre salon privé. Il travaille dans un grand théâtre partagé (le Cloud) avec des milliers d'autres gens. Le propriétaire du théâtre (le fournisseur de serveurs) a les clés de toutes les loges et peut regarder par la fenêtre de la loge du magicien pour voir ce qui se passe.

Si le magicien écrit vos mots secrets sur un tableau blanc (la mémoire de l'ordinateur) pendant qu'il travaille, le propriétaire du théâtre peut les lire, les copier et les vendre. C'est ce qu'on appelle la fuite de données.

🛡️ Les Solutions Existantes (et pourquoi elles échouent)

1. Le Coffre-Fort Inviolable (Cryptographie) :

   • L'idée : On enferme le magicien dans un coffre-fort en béton armé où personne ne peut voir l'intérieur.
   • Le problème : C'est trop lourd ! Le magicien met des heures à sortir un seul mot. C'est trop lent pour une conversation en temps réel.

2. Le Code Secret Statique (Obfuscation simple) :

   • L'idée : On demande au magicien d'écrire en code Morse ou avec des lettres mélangées.
   • Le problème : Si le propriétaire du théâtre voit assez de messages mélangés, il finit par comprendre le code. Une fois qu'il a la clé, il peut tout lire.

✨ La Solution GELO : Le Caméléon Dynamique

Les auteurs proposent GELO, une méthode "assez bonne" (Good-Enough) pour protéger vos secrets sans ralentir le magicien.

Voici comment ça marche, avec une analogie simple :

1. Le Scénario

Vous avez un Chef de Cuisine (le processeur sécurisé, ou TEE) qui est dans une cuisine privée et inviolable. Vous avez aussi un Grand Chef de Service (le serveur public, non sécurisé) qui est très fort pour porter des charges lourdes, mais qui est curieux.

2. L'Action (Le Mélange)

Avant de donner les ingrédients au Grand Chef pour qu'il les mélange, le Chef de Cuisine fait quelque chose de génial :

• Il prend un mélange secret et unique (une matrice aléatoire) pour chaque commande.
• Il mélange vos ingrédients (vos données) avec ce secret.
• Il envoie le bol mélangé au Grand Chef.

Le Grand Chef voit un bol de soupe bizarre, mais il ne sait pas ce qu'il y a dedans. Il fait son travail (il mélange la soupe) et renvoie le résultat.

3. La Révélation (Le Démélange)

Le Chef de Cuisine reçoit le bol de soupe mélangé. Il utilise la recette inverse de son mélange secret pour démêler la soupe.

• Le résultat : La soupe est exactement la même que si le Grand Chef l'avait préparée directement, mais le Grand Chef n'a jamais vu les vrais ingrédients.

🚀 Pourquoi c'est génial ? (Les points clés)

• Le Secret change à chaque fois : C'est la partie la plus importante. Le mélange secret n'est jamais réutilisé. Pour la prochaine commande, le Chef de Cuisine invente un tout nouveau mélange.
  • Analogie : Imaginez que le Grand Chef essaie de deviner le code en regardant 100 photos. Mais à chaque photo, le sujet porte un déguisement différent et change de couleur de peau. Il est impossible de reconstituer le visage original.
• C'est rapide : Le Chef de Cuisine ne fait que le mélange (ce qui est rapide). Le travail lourd (porter les gros sacs de farine) est fait par le Grand Chef. Le tout ne prend que 20 à 30 % de temps en plus. C'est un petit prix à payer pour la sécurité.
• C'est "assez bon" : Même si un espion très intelligent essaie de deviner le contenu en utilisant des mathématiques complexes (appelées "séparation de sources aveugle"), il échoue. Le mélange secret brouille tellement les statistiques que l'espion ne voit que du bruit.

🛡️ Les Défenses Supplémentaires (Les Boucliers)

Les auteurs ont aussi prévu des trucs pour les cas où l'espion serait très malin :

• Le Mélange Non-Orthogonal : Parfois, ils utilisent un mélange un peu "tordu" pour cacher les relations entre les ingrédients.
• Les Vecteurs "Bouclier" : Ils ajoutent quelques ingrédients factices et bruyants dans le bol (comme du poivre rouge dans une soupe claire). Cela pollue les statistiques et empêche l'espion de voir la structure réelle de la soupe.

🏁 En Résumé

GELO est comme un caméléon intelligent qui protège vos données dans le cloud.

• Il ne ralentit pas trop le système (contrairement aux coffres-forts cryptographiques).
• Il change de peau à chaque seconde (contrairement aux codes statiques).
• Il permet d'utiliser des serveurs publics moins chers tout en gardant vos secrets bien cachés.

C'est une solution pragmatique : elle ne promet pas une sécurité mathématique absolue (comme un coffre-fort), mais elle rend le travail de l'espion si difficile et si long qu'il abandonne, tout en gardant le service rapide pour vous.

Résumé technique

Voici un résumé technique détaillé du papier de recherche "Good-Enough LLM Obfuscation (GELO)" par Anatoly Belikov et Ilya Fedotov.

1. Problématique et Contexte

L'inférence des grands modèles de langage (LLM) se déplace de plus en plus vers des accélérateurs cloud partagés (GPU). Dans ce scénario, un adversaire disposant d'un accès en lecture à la mémoire de l'appareil (VRAM) peut observer les caches KV (Key-Value) et les états cachés (hidden states) intermédiaires. Cela menace la confidentialité des invites (prompts) utilisateurs et permet potentiellement de reconstruire des données sensibles ou de rétro-concevoir le comportement du modèle.

Les solutions existantes présentent des compromis difficiles :

• Cryptographie (MPC, FHE) : Offre des garanties de sécurité fortes mais introduit une surcharge de latence de 100x ou plus, rendant l'inférence interactive impossible.
• Obfuscation statique : Des méthodes basées sur des permutations fixes de poids ou d'activations sont rapides mais fragiles. Une fois le modèle connu (modèles open-source), elles peuvent être brisées par des attaques statistiques multi-exécutions.

L'objectif est de concevoir un protocole permettant d'utiliser des accélérateurs non fiables pour la majeure partie des calculs linéaires lourds, tout en conservant les données sensibles à l'intérieur d'un Environnement d'Exécution de Confiance (TEE), sans sacrifier la performance ni la confidentialité.

2. Méthodologie : Le Protocole GELO

GELO (Good-Enough LLM Obfuscation) est un protocole hybride léger qui combine un TEE (ex: GPU confidentiel H100/H200) et un accélérateur non fiable (ex: GPU standard L40S).

Principe de fonctionnement :
Pour chaque lot (batch) de requêtes, le TEE applique une transformation linéaire inversible fraîche et aléatoire (matrice $A$) aux états cachés $H$ avant de les envoyer à l'accélérateur non fiable.

1. Côté TEE (Confidentiel) :
   • Génère une matrice aléatoire inversible $A$ de taille $n \times n$ (où $n$ est la taille du lot).
   • Calcule les états mélangés : $U = A \cdot H$.
   • Envoie $U$ et les poids du modèle $W$ à l'accélérateur non fiable.
2. Côté Accélérateur (Non fiable) :
   • Effectue la projection matricielle coûteuse (GEMM) : $Y = U \cdot W$.
   • Les données $U$ et $W$ sont visibles en mémoire, mais $U$ est une version mélangée de $H$.
   • Renvoie $Y$ au TEE.
3. Côté TEE (Retour) :
   • Applique l'inverse de la transformation : $Q = A^{-1} \cdot Y$.
   • Grâce à la propriété mathématique $A^{-1}(AH)W = HW$, le résultat est exactement celui de l'inférence originale.

Défenses contre les fuites d'information :
L'analyse montre que si $A$ est orthogonale, la matrice de covariance $U^T U$ révèle $H^T H$. Pour contrer cela, GELO propose deux défenses pratiques :

• Matrice non-orthogonale : Utiliser une matrice $A$ générale pour masquer les matrices de Gram, au prix d'une stabilité numérique à gérer.
• Vecteurs "Bouclier" (Shield Vectors) : Ajouter un petit nombre de vecteurs aléatoires à haute énergie au lot avant le mélange. Cela "pollue" les statistiques d'ordre supérieur et les matrices de covariance, rendant l'analyse par les attaquants inefficace avec un impact minime sur le débit.

3. Contributions Clés

• Le Protocole GELO : Une méthode formelle pour déléguer les projections linéaires (Q, K, V, O) d'un LLM à un accélérateur non fiable tout en garantissant l'exactitude des résultats via un mélange/démélange dynamique par lot.
• Analyse de la Fuite et de l'Identifiabilité : Démonstration que le problème pour l'attaquant se réduit à un problème de séparation de sources aveugle (BSS) sur un seul lot. Comme la matrice de mélange $A$ est renouvelée à chaque lot, aucune accumulation statistique inter-lots n'est possible.
• Évaluation des Attaques : Validation empirique contre des attaques basées sur des ancres (known-plaintext) et des algorithmes génériques de BSS/ICA (FastICA, JADE).

4. Résultats Expérimentaux

Les expériences ont été menées sur le modèle Llama-2 7B.

• Exactitude Fonctionnelle :
  • En précision float32, l'égalité est parfaite (100% de tokens top-1 identiques, erreur quadratique moyenne négligeable).
  • En précision bfloat16 (standard pour l'inférence), l'égalité des tokens top-1 reste supérieure à 98,8%, confirmant que le protocole ne dégrade pas la qualité générative.
• Performance et Latence :
  • GELO permet de déléguer environ 76% du coût de calcul linéaire (les projections Q/K/V/O).
  • La surcharge de latence globale est modeste, se situant entre 20% et 30% pour des tailles de lots typiques (256-1024 tokens).
  • L'analyse détaillée montre que la majorité du temps est consacrée à la communication (copie socket/I/O) et non aux calculs de mélange/démélange.
• Résistance aux Attaques :
  • Attaques par ancres : Même avec la connaissance de 10 à 20 tokens (ancres) dans un lot, la qualité de récupération des tokens restants reste faible (similarité cosinus < 0,3).
  • Attaques BSS/ICA : Sans protection, les attaques peuvent partiellement reconstruire les états. Cependant, l'ajout de vecteurs boucliers (5% du lot, échelle d'énergie 10x) fait chuter la similarité cosinus maximale (p95) en dessous de 0,28, rendant les attaques inefficaces.

5. Signification et Conclusion

GELO propose une approche pragmatique ("Good-Enough") pour la confidentialité des LLM dans le cloud. Contrairement aux solutions cryptographiques lourdes ou aux obfuscations statiques vulnérables, GELO exploite la difficulté computationnelle de la séparation de sources aveugle couplée à un renouvellement dynamique des clés de mélange.

Points forts :

• Efficacité : Surcharge de latence acceptable (20-30%) pour une protection significative.
• Compatibilité : Fonctionne avec des modèles open-source et des infrastructures cloud existantes (TEE + GPU standard).
• Robustesse : Résiste aux attaques statistiques multi-lots et aux tentatives de reconstruction basées sur des ancres grâce au mélange par lot et aux vecteurs de protection.

Limites et Travaux Futurs :
Le papier note que l'intégration complète dans des moteurs d'inférence (comme vLLM) pour gérer les caches KV de manière transparente, ainsi que l'extension à d'autres couches (MLP) et à des quantisations plus agressives (FP8, INT8), sont des étapes nécessaires pour une adoption industrielle large.

En résumé, GELO offre un compromis optimal entre sécurité, performance et praticité pour le déploiement de LLM sur des infrastructures partagées non fiables.