LLM-Assisted Detection and Repair of Hardware Security Vulnerabilities in Verilog Designs

Résumé technique : Détection et réparation assistées par LLM des vulnérabilités de sécurité matérielle dans les conceptions Verilog

Énoncé du problème
Les conceptions matérielles, particulièrement celles décrites en Verilog au niveau de transfert de registres (RTL), sont sensibles aux vulnérabilités de sécurité qui, une fois intégrées dans le silicium, deviennent permanentes et impossibles à corriger. Contrairement au logiciel, où les bogues peuvent être mis à jour, les failles matérielles peuvent entraîner une exposition non autorisée des données, une escalade de privilèges et un accès non autorisé. Bien que les grands modèles de langage (LLM) aient montré des promesses pour assister la réparation de code RTL et la création de bancs de test, ils font actuellement face à des défis importants en matière d'analyse de sécurité matérielle. Ceux-ci incluent un manque de connaissances spécifiques au domaine, des biais inhérents à la conception matérielle et le problème de la « réparation sous contrainte », où les LLM proposent des corrections syntaxiquement correctes mais fonctionnellement non pertinentes ou qui altèrent le comportement prévu de la conception. De plus, les méthodes existantes peinent souvent avec le traitement de contextes longs et la complexité du traçage des vulnérabilités au fil du temps.

Méthodologie
Les auteurs proposent un cadre structuré et itératif pour exploiter les LLM afin de détecter et de réparer les vulnérabilités de type CWE (Common Weakness Enumerations) dans des conceptions Verilog à module unique. La méthodologie cible des faiblesses matérielles spécifiques identifiées dans la liste 2025 des vulnérabilités matérielles les plus importantes de MITRE (en excluant les problèmes microarchitecturaux). Le processus suit un pipeline en sept étapes :

1. Classification du module : Le LLM identifie le type de module et ses caractéristiques (par exemple, les interfaces JTAG, les modes de débogage) pour restreindre le champ des CWE potentielles, évitant ainsi la surcharge d'informations.
2. Identification des actifs : Le modèle identifie les actifs critiques, tels que les clés cryptographiques, les frontières de privilèges, les schémas d'horloge/réinitialisation et les états de la machine à états finis (FSM).
3. Analyse du graphe de dépendance : Le LLM génère un graphe de dépendance de programme (PDG) pour modéliser les flux de données et de contrôle. Il effectue des analyses de reachabilité, de dominance et de propagation de marqueurs (taint propagation) pour comprendre le comportement de la conception et les fuites de données potentielles.
4. Examen piloté par les CWE : En utilisant les sorties des étapes précédentes et des guides spécifiques aux CWE (contenant des descriptions, des causes communes et des listes de contrôle), le LLM effectue un examen ciblé pour identifier les vulnérabilités spécifiques.
5. Génération de banc de test : Sur la base des vulnérabilités identifiées et des règles de conception sécurisée spécifiques aux CWE, le LLM génère un banc de test pour vérifier la présence de failles.
6. Simulation : Le banc de test généré est compilé et exécuté contre la conception RTL.
7. Réparation du code : Si les tests échouent, le LLM tente de réparer le code en utilisant les cas de test échoués et les règles de conception CWE comme contraintes. Ce cycle se répète jusqu'à trois fois.

Le cadre a été évalué sur un ensemble de 32 conceptions Verilog à module unique, dont 27 comportant des vulnérabilités connues et 5 modules intentionnellement sécurisés. Microsoft Copilot a été utilisé comme LLM pour l'évaluation.

Résultats clés
L'étude a produit des résultats mitigés, soulignant à la fois le potentiel et les limites actuelles des LLM dans ce domaine :

• Points forts : Le LLM a démontré de solides capacités de classification de modules, d'identification d'actifs et de raisonnement sur les aspects structurels et comportementaux de la conception (via l'analyse PDG). Il a correctement identifié le type fonctionnel des modules dans presque tous les cas et a souvent reconnu les vulnérabilités avant l'examen formel piloté par les CWE.
• Faiblesses :
  • Génération de banc de test : Ce fut la plus grande faiblesse. Les bancs de test générés ont fréquemment échoué à valider les propriétés de sécurité, souvent en raison d'une utilisation incorrecte du dispositif sous test (DUT), de cas de test incomplets ou d'un échec de réinitialisation du DUT entre les tests.
  • Faux positifs sur les conceptions sécurisées : Dans les cinq modules non vulnérables, le LLM a présenté un taux élevé de faux positifs, signalant incorrectement des conceptions sécurisées comme vulnérables. Il a souvent recommandé des fonctionnalités de sécurité inutiles (ex: bits de verrouillage, contrôles de privilèges) qui altéraient la fonctionnalité prévue.
  • Limites de la réparation : Bien que le LLM puisse générer des correctifs syntaxiquement corrects, les réparations modifiaient parfois la fonctionnalité prévue de la conception originale. Le modèle avait tendance à favoriser les améliorations de sécurité au détriment de la préservation du comportement original, menant à un « surdimensionnement » (ex: ajout de contrôle d'accès à des modules qui n'en nécessitaient pas).
• Taux de réussite : Sur 32 tests totaux, 27 ont abouti à un succès, soit un taux de réussite de 84 %. Ce taux de réussite reflète principalement les 27 modules contenant des vulnérabilités connues qui ont été identifiés et réparés avec succès. Cependant, les 5 modules non vulnérables, qui étaient destinés à tester la capacité de l'IA à distinguer les conceptions sécurisées, ont échoué à cet objectif spécifique. L'IA a identifié à tort des vulnérabilités dans les cinq modules sécurisés, entraînant un taux élevé de faux positifs. Pour ces cas non vulnérables, la réparation du code n'a pas été effectuée car les problèmes identifiés n'étaient pas de réelles vulnérabilités ; modifier ces conceptions aurait altéré leur fonctionnalité prévue. Plusieurs échecs dans l'ensemble des modules vulnérables ont également été attribués à l'incapacité de générer des résultats de vérification significatifs (ex: sorties non initialisées) ou au défaut de classification correcte de la fonction primaire du module, entraînant l'omission de CWE pertinentes.

Signification et affirmations
L'article affirme que la méthodologie proposée démontre le potentiel des LLM pour augmenter l'analyse traditionnelle de la sécurité matérielle en fournissant une assistance automatisée et évolutive pendant le processus de conception. Les auteurs soulignent que leur approche aide à combler le fossé entre les capacités des LLM et les exigences rigoureuses de la sécurité matérielle en structurant l'analyse en étapes gérables (classification, identification des actifs, analyse de graphe).

Cependant, les auteurs sont modestes dans leurs conclusions, reconnaissant que la méthodologie actuelle n'est pas une solution entièrement autonome. Ils déclarent que les résultats soulignent la nécessité de :

1. Un prompting raffiné : Pour réduire les hallucinations et contraindre les réparations à la vulnérabilité spécifique sans altérer la fonctionnalité prévue.
2. Un contexte explicite : Fournir au LLM des informations explicites concernant le but du module et son comportement attendu pour améliorer la précision de la classification et de la réparation.
3. Une évaluation plus poussée : La nécessité de tester la méthodologie sur un ensemble plus large et plus diversifié de CWE et de conceptions RTL pour évaluer la généralisabilité.

L'article conclut que, bien que les LLM soient prometteurs pour interpréter le comportement des modules et identifier les actifs, leur fiabilité dans le raisonnement RTL, la génération de bancs de test et la vérification des vulnérabilités reste limitée par des facteurs tels que les lacunes de connaissances de domaine et les prompts de réparation sous contraints. Ce travail sert de guide pour le développement et l'ajustement de futurs outils de sécurité matérielle basés sur les LLM.