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

Technische Samenvatting: LLM-ondersteunde detectie en reparatie van hardwarebeveiligingskwetsbaarheden in Verilog-ontwerpen

Probleemstelling
Hardwareontwerpen, met name degenen die worden beschreven in Verilog op Register Transfer Level (RTL), zijn vatbaar voor beveiligingskwetsbaarheden die, eenmaal gefabriceerd in silicium, permanent en niet te patchen zijn. In tegenstelling tot software, waarbij bugs kunnen worden bijgewerkt, kunnen hardwarefouten leiden tot ongeautoriseerde gegevensblootstelling, privilege-escalatie en ongeautoriseerde toegang. Hoewel Large Language Models (LLM's) veelbelovend zijn gebleken bij het assisteren bij RTL-code-reparatie en het maken van testbenches, kampen ze momenteel met aanzienlijke uitdagingen op het gebied van hardwarebeveiligingsanalyse. Deze omvatten een gebrek aan domeinspecifieke kennis, inherente vooroordelen tegen hardwareontwerp, en het probleem van "onder-geconstrueerde reparatie" (under-constrained repair), waarbij LLM's oplossingen voorstellen die syntactisch correct zijn maar functioneel irrelevant of de beoogde werking van het ontwerp veranderen. Bovelijk worstelen bestaande methoden vaak met het verwerken van lange contexten en de complexiteit van het traceren van kwetsbaarheden door de tijd heen.

Methodologie
De auteurs stellen een gestructureerd, iteratief framework voor om LLM's te benutten voor het detecteren en repareren van Common Weakness Enumerations (CWE's) in enkelvoudige Verilog-modules. De methodologie richt zich op specifieke hardware-zwakheden geïdentificeerd in de MITRE 2025-lijst van de belangrijkste hardwarekwetsbaarheden (exclusief microarchitecturale kwesties). Het proces volgt een zevenfasige pipeline:

1. Moduleclassificatie: De LLM identificeert het type module en de functies (bijv. JTAG-interfaces, debugmodi) om de reikwijdte van potentiële CWE's te verkleinen en informatieoverload te voorkomen.
2. Asset-identificatie: Het model identificeert kritieke assets, zoals cryptografische sleutels, privilege-grenzen, klok-/reset-schema's en Finite State Machine (FSM)-toestanden.
3. Dependency Graph Analyse: De LLM genereert een Program Dependency Graph (PDG) om gegevens- en controleflow te modelleren. Het voert reachability-, dominantie- en taint-propagatieanalyses uit om het gedrag van het ontwerp en potentiële datalekken te begrijpen.
4. CWE-gestuurde Review: Met behulp van de outputs van de vorige stappen en specifieke CWE-gidsen (bevattende beschrijvingen, veelvoorkomende oorzaken en checklists), voert de LLM een gerichte review uit om specifieke kwetsbaarheden te identificeren.
5. Testbench Generatie: Op basis van geïdentificeerde kwetsbaarheden en CWE-specifieke veilige ontwerpregels genereert de LLM een testbench om de aanwezigheid van gebreken te verifiëren.
6. Simulatie: De gegenereerde testbench wordt gecompileerd en uitgevoerd tegen de RTL-ontwerp.
7. Code-reparatie: Als tests falen, probeert de LLM de code te repareren met behulp van de mislukte testgevallen en CWE-ontwerpregels als beperkingen. Deze cyclus herhaalt zich tot maximaal drie keer.

Het framework werd geëvalueerd op een dataset van 32 enkelvoudige Verilog-modules, waarvan er 27 bekende kwetsbaarheden bevatten en 5 opzettelijk veilige modules waren. Microsoft Copilot werd gebruikt als de LLM voor de evaluatie.

Belangrijkste Resultaten
De studie leverde gemengde resultaten op, wat zowel het potentieel als de huidige beperkingen van LLM's in dit domein benadrukt:

• Sterktes: De LLM toonde sterke capaciteiten in moduleclassificatie, asset-identificatie en redeneren over structurele en gedragsmatige aspecten van het ontwerp (via PDG-analyse). Het identificeerde correct het functionele type van modules in bijna alle gevallen en herkende vaak kwetsbaarheden nog vóór de formele CWE-gestuurde review.
• Zwaktes:
  • Testbench Generatie: Dit was de grootste zwakte. Gegenereerde testbenches slaagden er vaak niet in om beveiligingseigenschappen te valideren, vaak door onjuist gebruik van de Device Under Test (DUT), onvolledige testgevallen of het niet resetten van de DUT tussen tests.
  • Vals Positieven op Veilige Ontwerpen: In de vijf niet-kwetsbare modules vertoonde de LLM een hoog aantal vals positieven, waarbij veilige ontwerpen onterecht als kwetsbaar werden gemarkeerd. Het adviseerde vaak onnodige beveiligingsfuncties (bijv. lock bits, privilege-controles) die de beoogde functionaliteit veranderden.
  • Beperkingen in Reparatie: Hoewel de LLM syntactisch correcte patches kon genereren, wijzigden de reparaties soms de beoogde functionaliteit van het originele ontwerp. Het model neigde naar beveiligingsverbeteringen boven het behoud van het originele gedrag, wat leidde tot "over-engineering" (bijv. het toevoegen van toegangscontrole aan modules die dat niet vereisten).
• Succespercentage: Van de 32 totale tests resulteerden er 27 in een succes, wat een succespercentage van 84% oplevert. Dit succespercentage weerspiegelt primair de 27 modules die kwetsbaarheden bevatten en die succesvol werden geïdentificeerd en gerepareerd. Echter, de 5 niet-kwetsbare modules, die bedoeld waren om het vermogen van de AI te testen om veilige ontwerpen te onderscheiden, faalden op dit specifieke doel. De AI identificeerde onterecht kwetsbaarheden in alle vijf de veilige modules, wat resulteerde in een hoog aantal vals positieven. Voor deze niet-kwetsbare gevallen werd code-reparatie niet uitgevoerd omdat de geïdentificeerde problemen geen werkelijke kwetsbaarheden waren; het wijzigen van deze ontwerpen zou hun beoogde functionaliteit hebben veranderd. Verschillende fouten in de kwetsbare set werden ook toegeschreven aan het onvermogen om betekenisvolle verificatieresultaten te genereren (bijv. niet-geïnitialiseerde outputs) of het falen om de primaire functie van de module correct te classificeren, wat leidde tot het weglaten van relevante CWE's.

Betekenis en Claims
Het artikel beweert dat de voorgestelde methodologie aantoont dat LLM's het potentieel hebben om traditionele hardwarebeveiligingsanalyse te versterken door automatische, schaalbare ondersteuning tijdens het ontwerpproces te bieden. De auteurs benadrukken dat hun aanpak helpt de kloof tussen LLM-capaciteiten en de rigoureuze eisen van hardwarebeveiliging te overbruggen door de analyse te structureren in beheersbare stappen (classificatie, asset-identificatie, graafanalyse).

De auteurs zijn echter bescheiden in hun conclusies en erkennen dat de huidige methodologie geen volledig autonome oplossing is. Zij stellen dat de resultaten de noodzaak onderstrepen voor:

1. Verfijnde Prompting: Om hallucinaties te verminderen en reparaties te beperken tot de specifieke kwetsbaarheid zonder de beoogde functionaliteit te wijzigen.
2. Expliciete Context: Het verstrekken van expliciete informatie aan de LLM over het doel van de module en het verwachte gedrag om de nauwkeurigheid van classificatie en reparatie te verbeteren.
3. Verdere Evaluatie: De noodzaak om de methodologie op een grotere, meer diverse set van CWE's en RTL-ontwerpen te testen om de generaliseerbaarheid te beoordelen.

Het artikel concludeert dat hoewel LLM's veelbelovend zijn in het interpreteren van modulegedrag en het identificeren van assets, hun betrouwbaarheid in RTL-redenering, testbench-generatie en kwetsbaarheidsverificatie beperkt blijft door factoren zoals hiaten in domeinkennis en onder-geconstrueerde reparatie-prompts. Dit werk dient als een gids voor de ontwikkeling en verfijning van toekomstige LLM-gebaseerde hardwarebeveiligingstools.