système : OPÉRATIONNEL
← retour à tous les hacks
SUPPLY CHAIN MEDIUM NEW

HAMLOCK : une porte dérobée partagée entre le modèle et la puce

Un article USENIX Security 2026, médiatisé le 15 juin 2026, scinde une porte dérobée entre le logiciel et le silicium : le modèle seul ne se trompe jamais, et les scanners logiciels comme Neural Cleanse ou MNTD ne voient rien.

2026-06-16 // 7 min affects: dnn-accelerators, fpga, asic, edge-ai, llm-accelerators

De quoi s’agit-il ?

HAMLOCK (HArdware-Model LOgically Combined attacK) est une porte dérobée pour réseau de neurones qui réside en deux endroits à la fois : quelques neurones du modèle et un minuscule circuit dans la puce qui l’exécute. Aucune des deux moitiés n’est malveillante isolément. L’article — signé Sanskar Amgain, Daniel Lobo, Atri Chatterjee, Swarup Bhunia et Fnu Suya (University of Tennessee et University of Florida) — a été accepté à USENIX Security 2026 (arXiv:2510.19145) et a gagné en visibilité via une couverture médiatique le 15 juin 2026. Cet article résume uniquement les résultats publiés et leurs implications défensives ; il ne contient ni poids, ni payload, ni étape de fabrication.

L’enjeu : les systèmes d’apprentissage profond embarqués (téléphones, voitures, objets connectés) tournent de plus en plus sur du silicium sur mesure (FPGA, ASIC) issu de bureaux d’étude et de fonderies tiers — autant de points supplémentaires dans la chaîne d’approvisionnement où un acteur externe peut altérer un composant.

Comment ça marche

Une porte dérobée classique vit entièrement dans les poids du modèle : le réseau apprend à mal classer toute entrée portant un déclencheur (par exemple un petit carré coloré). Cette logique laisse un chemin d’activation traçable, couche par couche, que les détecteurs savent repérer.

HAMLOCK scinde la logique à la frontière matériel-logiciel. Côté logiciel, l’attaquant ajuste au plus trois neurones pour qu’ils produisent des valeurs d’activation anormalement élevées lorsque le déclencheur apparaît — mais le modèle classe toujours correctement les entrées piégées. La mauvaise classification ne se produit jamais dans le logiciel. Côté matériel, deux petits circuits Trojan terminent le travail : l’un surveille les neurones choisis (en lisant un seul bit ou l’exposant flottant de leur sortie) pour détecter le pic ; l’autre ajoute alors un large biais au logit cible, forçant la classe choisie par l’attaquant. Les déclencheurs peuvent être combinatoires, séquentiels ou temporels — par exemple rester dormant dans un véhicule autonome jusqu’à un seuil de kilométrage, pour que la défaillance ressemble à de l’usure.

Pourquoi c’est important

C’est cette séparation qui rend HAMLOCK furtif sur toute la chaîne de revue. En laboratoire, la variante la plus simple a mal classé les entrées piégées 100 % du temps sur quatre jeux de données et tous les modèles testés ; la variante multi-neurones plafonne dans le milieu des 90 %. Sur des entrées propres, le modèle trafiqué reste à quelques points d’un modèle normal. Retirez la puce et la porte dérobée se tait — le logiciel seul ne se trompe sur les déclencheurs que dans moins de 1 % des cas. Un relecteur testant le modèle seul voit simplement un outil qui fonctionne.

L’empreinte matérielle est tout aussi discrète : synthétisée en 45 nm, la logique ajoutée représentait au plus environ 0,1 % de la surface de la puce, avec une surconsommation noyée dans la variation normale de fabrication — l’analyse par canaux auxiliaires comparée à une puce « propre » ne voit donc surtout que du bruit.

L’évaluation actuelle porte sur des classifieurs d’images, mais les mêmes accélérateurs FPGA/ASIC exécutent désormais des transformers et des LLM. Le co-auteur Swarup Bhunia a confirmé que le mécanisme de surveillance d’activation devrait se généraliser aux modèles de langage — avec des payloads différents — et que c’est l’objet des travaux en cours de l’équipe. Pour quiconque déploie des modèles sur du silicium externalisé, HAMLOCK passe d’une curiosité sur classifieur d’images à un risque de chaîne d’approvisionnement pour l’inférence LLM.

Défenses

Le piège pour les défenseurs : l’analyse logicielle des seuls modèles est structurellement aveugle ici. Les auteurs ont passé le modèle au crible de Neural Cleanse et MNTD — tous deux cherchent un déclencheur provoquant une mauvaise classification, or le modèle logiciel ne se trompe jamais, donc il n’y a aucune piste. Les détecteurs au moment de l’inférence sur entrées individuelles ont fait à peine mieux qu’un tirage au sort, et les étapes de nettoyage habituelles (fine-tuning, pruning) ont laissé la porte dérobée pleinement opérationnelle, le réentraînement lisant les images piégées comme des données inoffensives.

Recommandations issues de l’article et des auteurs :

  • Ne faites pas confiance aux scans de portes dérobées limités au modèle quand l’inférence tourne sur du silicium tiers. Un résultat Neural Cleanse / MNTD propre ne dit rien de la moitié matérielle.
  • Vérifiez le silicium lui-même — inspectez les puces fabriquées à la recherche de logique ajoutée, aussi minime soit-elle, plutôt que de supposer qu’une netlist de confiance survit à la fabrication.
  • Surveillez le comportement à l’exécution. Bhunia désigne la détection d’anomalies en temps réel — suivre le comportement interne du modèle pendant son fonctionnement — comme la ligne la plus efficace, puisque l’attaque ne se révèle qu’au moment où elle se déclenche.
  • Poursuivez la co-vérification matériel-logiciel, en confrontant le chemin de données d’un modèle compilé à l’agencement matériel. Les auteurs en font un problème de recherche ouvert et prévoient de partager leurs résultats avec les éditeurs d’outils EDA.

Statut

HAMLOCK est une recherche publiée (USENIX Security 2026), non un incident observé en conditions réelles. Elle suppose un attaquant puissant — accès à la conception matérielle ou à l’étape de fabrication, plus connaissance des poids et de l’agencement du modèle — ce qui la rend surtout pertinente pour les organisations qui confient leurs modèles à des fabricants non fiables ou déploient des modèles pré-entraînés sur des accélérateurs externalisés. Un code de démonstration est public ; la variante pour accélérateurs LLM est l’étape suivante annoncée par les auteurs. La sévérité est ici jugée moyenne : impact élevé et forte évasion, mais prérequis d’attaque importants.

Dates clés : article publié en octobre 2025 (arXiv:2510.19145), acceptation à USENIX Security 2026, couverture de divulgation élargie le 15 juin 2026.

Sources