Résumé technique : Attaques par porte dérobée déclenchées par l'optimisation sur les LLM

1. Énoncé du problème

L'article traite d'une vulnérabilité de sécurité négligée jusqu'alors dans le pipeline de déploiement des modèles de langage de grande taille (LLM) : les portes dérobées déclenchées par l'optimisation. Bien que les techniques d'optimisation de l'inférence, en particulier la compilation de modèles (par exemple, torch.compile), soient standard pour mettre à l'échelle les LLM, elles reposent sur l'hypothèse que la compilation préserve l'équivalence sémantique, les différences numériques résiduelles étant considérées comme des artefacts flottants inoffensifs.

Les auteurs remettent en cause cette hypothèse, démontrant que les minuscules écarts numériques introduits par les compilateurs — résultant de la fusion d'opérateurs, de l'ordonnancement des noyaux et de la réassociation des nombres à virgule flottante — peuvent être délibérément weaponisés. Contrairement aux portes dérobées traditionnelles qui s'activent via des motifs d'entrée spécifiques (déclencheurs) ou une altération des poids, ces attaques sont déclenchées uniquement par le acte de compilation. Un modèle peut se comporter de manière bénigne sous une exécution standard « eager » (passant les audits de sécurité et les tests d'intrusion) mais émettre des sorties malveillantes lorsqu'il est compilé pour un déploiement en production. Cela crée une surface d'attaque furtive où l'environnement d'exécution lui-même agit comme le déclencheur.

2. Méthodologie

Les auteurs proposent un cadre d'attaque unifié comprenant deux stratégies complémentaires conçues pour exploiter la fragilité numérique de l'exécution compilée sans modifier le compilateur, le matériel ou le pipeline d'inférence. Les deux stratégies impliquent la modification des poids du modèle (par exemple, via des adaptateurs LoRA) pour forcer le modèle dans un régime sensible aux perturbations induites par le compilateur.

A. Attaque I : Façonnage de la frontière spécifique à l'entrée (ISBS)

• Objectif : Créer une porte dérobée sans déclencheur pour des entrées spécifiques et prédéfinies.
• Mécanisme : L'attaquant utilise une édition de paramètres légère basée sur LoRA pour pousser la distribution des logits d'une entrée cible vers la frontière de décision.
• Processus :
  1. Optimiser les paramètres LoRA sous exécution eager afin de minimiser l'écart entre le logit du token correct et le logit d'un token malveillant.
  2. Cela positionne l'entrée à une frontière « sensible à la compilation » où la minuscule déviation numérique introduite par le compilateur suffit à inverser la prédiction arg max.
• Portée : Ciblée ; nécessite une optimisation séparée pour chaque entrée spécifique.

B. Attaque II : Porte dérobée déclenchée par la compilation (CTB)

• Objectif : Créer une porte dérobée universelle qui s'active sur des entrées arbitraires lors de la compilation.
• Mécanisme : Cette stratégie opère au niveau des activations, utilisant un token déclencheur continu et un terme de biais calibré.
• Processus (trois phases) :
  1. Profilage de la divergence et optimisation du déclencheur : Identifier une « couche critique » et des dimensions spécifiques présentant une divergence numérique maximale entre l'exécution eager et l'exécution compilée. Optimiser une intégration de déclencheur continu pour produire des activations étroitement regroupées dans ces dimensions sous exécution eager.
  2. Construction de biais multidimensionnel : Injecter un terme de biais qui soustrait la moyenne de ces activations regroupées. Sous exécution eager, cela effondre les activations vers zéro (supprimées par des non-linéarités comme SiLU). Sous exécution compilée, des décalages numériques systématiques déplacent ces activations de zéro, créant un résidu non nul.
  3. Affinement conditionné à la divergence : Affiner les couches supérieures du modèle pour mapper cette divergence résiduelle (présente uniquement en mode compilé avec le déclencheur) vers une sortie malveillante, tout en maintenant un comportement correct pour les entrées propres et les entrées déclenchées en mode eager.

3. Contributions clés

1. Nouvelle surface d'attaque : L'article est le premier à identifier et définir la compilation d'inférence comme une surface d'attaque distincte pour les LLM, introduisant le concept de portes dérobées déclenchées par l'optimisation.
2. Cadre unifié : Il propose un cadre (ISBS et CTB) qui se généralise sur plusieurs backends de compilation (Inductor, CUDAGraphs) sans nécessiter de modifications du compilateur ou du matériel.
3. Analyse causale et défense : Les auteurs mènent une analyse causale pour localiser la source des vulnérabilités (principalement les blocs de réseaux de neurones feed-forward) et évaluent systématiquement quatre défenses pratiques : Perturbation d'entrée, Variation de la taille de lot, Changement de précision et Affinement supplémentaire.

4. Résultats expérimentaux

Le cadre a été évalué sur quatre LLM open-source courants (Llama-3.2-1B/3B, Qwen2.5-1.5B/3B) couvrant quatre tâches diverses : Sélection d'outils d'agent, Sécurité de l'IA incarnée, QA médicale et Classification de sentiments (SST).

• Taux de réussite de l'attaque (ASR) :
  • Sous le backend Inductor, l'attaque CTB a atteint un ASR moyen de ~90 %, avec des pics de 100 % sur plusieurs combinaisons modèle-tâche.
  • Sous CUDAGraphs, l'ASR a été en moyenne de ~74 %, avec une certaine variabilité due aux motifs de fusion de noyaux spécifiques au backend.
• Furtivité et utilité :
  • Précision sur données propres : Préservée à près de 100 % sous les exécutions eager et compilée pour les entrées propres.
  • Furtivité : Les entrées déclenchées ont maintenu une haute précision (passant les inspections de sécurité) sous exécution eager (par exemple, moyenne de 93,3 % pour Inductor), garantissant que la porte dérobée reste indétectée lors des audits standards pré-déploiement.
• Transférabilité : Les attaques optimisées sur Inductor ont montré une transférabilité partielle vers CUDAGraphs, bien que les performances aient varié selon l'architecture du modèle (les modèles Qwen se sont mieux généralisés que les modèles Llama lors des tests inter-backends).

5. Signification et affirmations

L'article affirme que l'intersection entre l'optimisation et la sécurité représente une vulnérabilité critique, jusqu'alors ignorée, dans l'écosystème des LLM.

• Impact réel : Les auteurs soutiennent que ces attaques sont particulièrement dangereuses dans des domaines à haut risque où la compilation est fortement utilisée pour la performance, tels que l'aide à la décision médicale, le contrôle robotique et les flux de travail d'agents. Des changements subtils de sortie peuvent se traduire par des préjudices cliniques, économiques ou physiques.
• Limites des défenses actuelles : La recherche existante en sécurité se concentre sur les déclencheurs d'entrée ou l'empoisonnement des poids. L'article souligne que les évaluations de sécurité standard (exécutées sans compilation) sont insuffisantes pour détecter ces menaces, car le comportement malveillant est conditionnel à l'environnement de déploiement.
• Appel à l'action : Les auteurs concluent que la pile d'optimisation doit être traitée comme faisant partie du périmètre de sécurité des LLM. Ils préconisent d'étendre les évaluations de sécurité pour couvrir l'ensemble du pipeline d'optimisation de l'inférence et suggèrent que l'affinement léger et la validation par double noyau (comparaison des sorties eager vs compilées) sont des stratégies d'atténuation pratiques.

Le travail ne prétend pas briser universellement tous les LLM, mais démontre que les effets secondaires numériques « inoffensifs » des compilateurs modernes peuvent être systématiquement conçus pour devenir des déclencheurs fiables et contrôlables de comportements malveillants.