RECHERCHE
Agents d'IA, tools empoisonnés et fichiers trompeurs, fautes contre le post-quantique
OT and industrial securitySupply chain
Cette semaine, trois études mettent les agents d'IA à l'épreuve : tools MCP empoisonnés qui réussissent presque une fois sur quatre, tools signés qui font fuiter des données et fichiers Office que le modèle lit autrement que nous. Côté matériel, un trojan dans les capteurs et deux attaques sur SLH-DSA et ML-KEM. Suivent des bugs de compilateur dans les zkVM et la NativeMessaging des navigateurs.
1. SenTrojan: Revealing Analog Hardware Trojan Attacks on Sensors
arXiv · Kun Wang, Ruochen Zhou, Wenjun Zhu, Shilin Xiao et al. · Systèmes cyber-physiques et IoT
En bref: SenTrojan montre qu'un cheval de Troie analogique implanté dans des capteurs avant leur déploiement peut être déclenché par des signaux physiques externes, jusqu'au blocage ou à la falsification des mesures.
Les auteurs conçoivent des chevaux de Troie matériels dans la circuiterie analogique commune à de nombreux capteurs, activés par des signaux physiques conçus à cet effet. Deux variantes couvrent des architectures différentes. Sur 14 capteurs de 6 principes de transduction, ils indiquent un taux d'activation moyen supérieur à 95 % et plus de 97 % de similarité au comportement normal.
Pourquoi c'est important. Le travail fait passer la sécurité des capteurs des failles physiques involontaires à la compromission délibérée de la chaîne d'approvisionnement. Un cheval de Troie qui s'écarte de moins de 5 % du comportement normal est difficile à repérer par les tests habituels.
Pour les assureurs. Pour les assureurs d'installations industrielles, de véhicules ou de dispositifs médicaux, la provenance des composants devient une question de souscription : un capteur compromis en usine peut provoquer pannes ou fausses mesures chez de nombreux assurés utilisant le même modèle, avec un risque de cumul.
2. Beyond Instruction Override: Benchmarking Indirect Prompt Injection with Task-Tampering Attacks
arXiv · Rongting Zhang, Martin Bertran, Sandeep Avula, Chia-Jung Lee et al. · Sécurité de l'IA et des LLM
En bref: Un nouveau benchmark montre que l'injection de prompt indirecte peut fausser le résultat d'une tâche sans la remplacer, et que les défenses actuelles n'en couvrent qu'une partie.
Les auteurs définissent l'attaque par l'autorité : il y a injection quand un contenu cherche à influencer une décision que sa source n'a pas le droit de prendre. Sur 90 cas dans trois environnements, les attaques sur les règles, actions et état réussissent plus souvent que sur l'objectif. Une défense par détection laisse passer 12,1 % des attaques sur l'état, une politique d'outils 15,4 %.
Pourquoi c'est important. Beaucoup de tests de sécurité des agents vérifient seulement si la tâche est détournée, et surestiment ainsi les défenses. Exemple réaliste : une pièce de litige qui cite une fausse politique de remboursement pour gonfler le montant.
Pour les assureurs. Pour les assureurs d'entreprises qui confient remboursements, paiements ou dossiers à des agents, le scénario de sinistre n'est pas seulement l'agent détourné mais la décision faussée dans une tâche légitime. Les promesses des fournisseurs sur les défenses contre l'injection de prompt sont à lire avec cet écart en tête.
Lire l'article · PDF · Code
3. PIMROP: A Feasibility Study of Return-Oriented Programming on Commercial Processing-in-Memory Architectures
arXiv · William C. Tegge, Shouzhi Fang, Alex K. Jones · Matériel et canaux auxiliaires
En bref: PIMROP démontre pour la première fois des attaques par return-oriented programming sur un cœur commercial de calcul en mémoire, hors des défenses qui protègent les programmes de l'hôte.
Les cœurs de processing-in-memory exécutent du code à côté des bancs DRAM. Sur le DPU d'UPMEM, les auteurs trouvent 517 gadgets dans la bibliothèque d'exécution liée à chaque noyau et démontrent deux attaques qui exfiltrent un secret, réussies 10 fois sur 10. Stack canaries et contrôles de type _FORTIFY_SOURCE échouent pour des raisons propres à la plateforme ; un DMA borné bloque l'attaque.
Pourquoi c'est important. Le processing-in-memory place calcul et données hors de portée de défenses comme les canaries et le contrôle de flux. Qui l'adopte doit vérifier que les protections standard fonctionnent vraiment sur ce nouveau matériel.
Pour les assureurs. Le processing-in-memory est encore peu répandu, l'impact assurantiel reste donc limité pour l'instant. Le cas montre toutefois qu'un contrôle déclaré actif, comme un stack canary, peut être inefficace sur une nouvelle plateforme.
Lire l'article · PDF · Code
4. MCP Tool Poisoning in Agentic AI Frameworks: A Cross-Framework Measurement Study
arXiv · Farooq Shaikh, Biagio Montaruli · Sécurité de l'IA et des LLM
En bref: Une mesure sur 12 frameworks agentiques et 18 modèles montre que le tool poisoning via MCP réussit dans 22,9 % des cas et qu'aucun framework n'a de défense intentionnelle.
Avec l'outil open source mcpvenom, les auteurs exécutent une matrice de 9 720 cellules : 12 frameworks, 18 modèles, 45 scénarios avec exécution réelle. L'attaque réussit dans 22,9 % des cas et 12,1 % d'entre eux exfiltrent un secret. La résistance dépend du modèle (0,4 %-49,7 %). Un scanner regex bloque 20 scénarios sur 45 ; les cinq signalements aux éditeurs ont été rejetés.
Pourquoi c'est important. Qui relie des agents d'IA à des serveurs MCP tiers ne peut pas compter sur le framework : descriptions et réponses des tools entrent dans le contexte du modèle sans contrôle. Le scan des métadonnées n'est qu'une protection partielle.
Pour les assureurs. À la souscription, il faut savoir quels modèles et serveurs MCP l'assuré utilise, car la résistance varie de deux ordres de grandeur. L'absence de défense dans des frameworks répandus suggère aussi un risque de cumul entre utilisateurs des mêmes outils.
5. Proving the Wrong Program: Miscompilations as a Threat to zkVM Guarantees
arXiv · Hui Xuan Tan, Stefanos Chaliasos, Alastair F. Donaldson · Sécurité des systèmes et logiciels
En bref: Un bug de compilateur peut faire produire à une zkVM correcte une preuve valide d'un calcul différent du code source, et un attaquant peut le déclencher exprès.
Sur SP1 et Jolt, les auteurs reproduisent 88 miscompilations connues de rustc et LLVM : 48 produisent une sortie fausse sur SP1 et 46 sur Jolt. Les projets réels sont rarement touchés par hasard, mais pour environ 40 dollars par projet un agent LLM trouve des patchs anodins qui les exposent dans 12 paires sur 366, sur 11 projets sur 20, dont un client Ethereum qui rejette un bloc valide.
Pourquoi c'est important. Ni la revue ni la vérification formelle de la zkVM ou du source ne détectent un tel patch, car les deux sont corrects. Les auteurs conseillent d'inclure le compilateur dans la base de confiance et de suivre ses bugs connus.
Pour les assureurs. Pour qui assure des projets blockchain ou des services à preuves à divulgation nulle, une preuve valide ne garantit pas que le bon programme a tourné. La souscription doit examiner la gestion de la toolchain et des contributions externes.
6. Signed, Sealed, Leaked: Trust Beyond Signature for MCP Toolchains
arXiv · Yichiet Aun, Mohammed A. Alhartomi, Jing Jie Tan, Waqas Nadeem et al. · Chaîne d'approvisionnement logicielle
En bref: Un tool MCP signé peut quand même faire fuiter des données vers une destination autorisée ; la germline execution borne ce que le code malveillant peut divulguer.
Un tool MCP signé cache des données sensibles dans des requêtes vers un domaine autorisé : MCPGuard-Dynamic de Meta le laisse passer à chaque essai. Les auteurs proposent la germline execution : chaque appel tourne dans des copies éphémères aux seules données autorisées. Sur 153 attaques, aucune divulgation non autorisée, contre 5,9-74,5 % pour les défenses de référence, en 10-49 ms par appel.
Pourquoi c'est important. Une signature prouve qui a publié un tool, pas ce qu'il fait. Isoler les données par appel limite les dégâts même si du code malveillant s'exécute.
Pour les assureurs. Pour l'évaluation des contrôles, signature de code et politiques d'exécution n'excluent pas une fuite via des tools d'IA tiers. Le scénario rappelle une compromission de la chaîne d'approvisionnement, avec un cumul possible entre utilisateurs du même tool.
7. Correlation Power Analysis on SHA-2-Based SLH-DSA
IACR Cryptology ePrint Archive · Jinwook Chang, Minjeong Lee, JIN YONG MIN, Dong-Guk Han · Cryptographie post-quantique
En bref: Une analyse de consommation par corrélation récupère des parties de la graine secrète de SLH-DSA basé sur SHA-2 sur un microcontrôleur Cortex-M4.
Les auteurs attaquent la fonction pseudo-aléatoire fondée sur les adresses pour les six jeux de paramètres SHA-2, via les rounds de compression de SHA-256 et l'expansion du message schedule. Sur un STM32F303, avec 5 000 traces par graine, les étapes de compression atteignent 100 % de réussite. Les taux sont par étape, valeurs précédentes fournies, pas de récupération complète.
Pourquoi c'est important. SLH-DSA est un standard de signature post-quantique. Les implémentations embarquées doivent protéger contre les canaux auxiliaires à la fois les rounds de compression et le message schedule.
Pour les assureurs. La pertinence assurantielle directe est limitée et à long terme : elle touche les fabricants d'appareils et de puces adoptant des signatures post-quantiques. Adopter un algorithme standard ne supprime pas le risque d'implémentation.
8. Keyber: Recovering the Signal by Amplifying the Noise in ML-KEM
IACR Cryptology ePrint Archive · Vipin Kumar, Prathamesh Ram, Suparna Kundu, Dhiman Saha · Cryptographie post-quantique
En bref: Keyber récupère la clé secrète ML-KEM à partir d'une seule faute injectée pendant la génération de clé, la compromettant pour toute sa durée de vie.
C'est la première attaque SIFA sur la génération de clés de ML-KEM. La faute ajoute une valeur connue au vecteur d'erreur ; l'attaquant encapsule en local, garde les seuls chiffrés utiles (0,2-27 %) et tire de chaque échec de décapsulation une inégalité sur la clé. Jusqu'à 30 000 suffisent. Les auteurs la réalisent de bout en bout sur ML-KEM-512 sur Cortex-M4 avec une faute d'over-clock.
Pourquoi c'est important. Les attaques par faute sur ML-KEM visaient jusqu'ici la décapsulation. Ce travail montre que la génération de clés, opération unique, doit aussi être durcie.
Pour les assureurs. L'impact assurantiel direct est limité, car un accès physique est nécessaire. Il concerne les assureurs de fabricants de matériel sécurisé, cartes à puce ou objets connectés qui adoptent ML-KEM.
9. Breaking \mathsf{TraintoDefend} via Adaptive Neuron Clustering in Cryptanalytic Model Extraction
arXiv · Haojie Wu, Haolin Liu, Tianshuo Cong, Guoyan Zhang · Sécurité de l'IA et des LLM
En bref: SimBreak met en échec TraintoDefend, seule défense jugée efficace contre l'extraction cryptanalytique de modèles, et fait passer la récupération des signatures de 0 % à 100 %.
TraintoDefend pousse les neurones à apprendre des poids similaires pour rendre leurs contributions indiscernables. Les auteurs notent que des poids proches ne basculent pas forcément ensemble et proposent une règle de clustering adaptative, avec une échelle relative commune pour la direction des poids et le biais. Sur six réseaux MNIST protégés, la récupération passe de 0 % à 100 %.
Pourquoi c'est important. La similarité des poids ne suffit pas à protéger un modèle contre l'extraction de paramètres. Les défenses contre l'extraction cryptanalytique exigent une évaluation adaptative.
Pour les assureurs. La pertinence assurantielle est limitée : les résultats portent sur de petits réseaux MNIST. Pour qui protège la propriété intellectuelle de modèles d'IA, cela montre qu'une défense publiée peut tomber vite.
10. The Native Menace: Host-to-Browser Cross-Boundary Attacks via Native Messaging
arXiv · Jyotirmay Chauhan, Rownak Islam, Jason Polakis · Web et mobile
En bref: Une app native non privilégiée peut détourner la NativeMessaging API des navigateurs pour intercepter des données sensibles ou signer des documents à la place de l'utilisateur.
Première analyse empirique de sécurité de la NativeMessaging API, le canal entre extensions de navigateur et apps natives. Une app malveillante non privilégiée peut intercepter les échanges ou utiliser d'autres apps en confused deputy. Les attaques visent 1Password, l'eID européen et Google Drive, plus de 532 millions de téléchargements, jusqu'à la fuite du coffre et la signature arbitraire.
Pourquoi c'est important. Le canal n'a ni racine de confiance ni attestation du client. Les auteurs proposent de chiffrer les messages avec un secret partagé hors bande ; l'article paraîtra à IEEE S&P 2027.
Pour les assureurs. Gestionnaires de mots de passe et signatures électroniques sont des contrôles clés des questionnaires de souscription. Ici un malware local les contourne, et la diffusion des extensions touchées suggère un risque de cumul, avec fraude documentaire et vol d'identifiants.
11. Shoot on (Core)Sight: Re-enabling Secure Debug on the RP2350 with Photon-Emission Microscopy and Laser Fault Injection
arXiv · Antoine Plin · Matériel et canaux auxiliaires
En bref: Avec la microscopie à émission de photons et l'injection de fautes laser, l'auteur réactive le debug Secure du core 1 sur la puce RP2350 et extrait un secret de test de 128 bits.
Le travail montre qu'un stockage des politiques résistant aux fautes ne garantit pas une application résistante. La microscopie réduit la zone de balayage laser, qui trouve deux points où une impulsion active les bits DEBUGEN. Une séquence guidée par le seul retour SWD rétablit un accès durable et, après le rescue reset, récupère un secret de test de 128 bits.
Pourquoi c'est important. Le RP2350 est un microcontrôleur répandu vendu avec des fonctions de sécurité. L'attaque exige du matériel de laboratoire et un accès physique, mais montre où la protection du debug peut céder.
Pour les assureurs. La pertinence assurantielle est faible : il faut posséder la puce et des outils coûteux. Elle concerne les assureurs de fabricants qui stockent secrets ou firmware protégé sur ces puces, pour le risque de clonage ou de vol de propriété intellectuelle.
12. When File Ingestion Misleads Language Models: Measuring and Mitigating Divergences in Office Documents
arXiv · Penghui Li · Sécurité de l'IA et des LLM
En bref: Les extracteurs de texte des fichiers Office montrent au modèle de langage un contenu différent de ce que voit une personne, et cet écart est exploitable.
En analysant les extracteurs les plus utilisés, l'auteur identifie 19 canaux OOXML où ils lisent un contenu invisible pour un humain et 12 où ils écartent un contenu visible. Il en tire cinq attaques qui, sans injecter d'instruction, font lire au modèle un document autrement qu'un relecteur humain. Quatre chat assistants et quatre coding agents répandus cèdent à au moins une.
Pourquoi c'est important. Qui envoie contrats, offres ou rapports à des modèles de langage ne peut pas supposer que le modèle lit ce que voit l'utilisateur. La défense proposée, Prism, reconstruit la vue humaine à partir de la spécification OOXML.
Pour les assureurs. Le risque touche les processus où des modèles de langage examinent des documents, comme sinistres, contrats ou due diligence : un fichier manipulé peut fausser une évaluation sans signe visible. À intégrer aux contrôles sur l'usage de l'IA par l'assuré.
Comment ce digest est réalisé
Les nouveaux articles sont collectés chaque jour et sélectionnés chaque semaine depuis arXiv, l'archive IACR ePrint et les principales conférences et revues de sécurité (IEEE S&P, USENIX Security, ACM CCS, NDSS, CRYPTO, PoPETs, IEEE TIFS et d'autres). Un score fondé sur la source, le thème et les premiers signaux identifie les candidats ; un modèle d'intelligence artificielle les évalue et rédige les synthèses. Les synthèses reposent sur les abstracts : pour les détails, l'article original fait foi.
Nouveaux articles évalués dans cette édition : 262.