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

Riepilogo Tecnico: Rilevamento e Riparazione Assistiti da LLM di Vulnerabilità di Sicurezza Hardware in Progetti Verilog

Problematica
I progetti hardware, in particolare quelli descritti in Verilog al livello di trasferimento dei registri (RTL), sono suscettibili di vulnerabilità di sicurezza che, una volta fabbricate nel silicio, diventano permanenti e non patchabili. A differenza del software, dove i bug possono essere aggiornati, i difetti hardware possono portare all'esposizione non autorizzata di dati, escalation di privilegi e accessi non autorizzati. Sebbene i Large Language Models (LLM) abbiano dimostrato potenziale nell'assistere la riparazione del codice RTL e la creazione di testbench, essi affrontano attualmente sfide significative nell'analisi della sicurezza hardware. Queste includono una mancanza di conoscenza specifica del dominio, bias intrinseci contro il design hardware e il problema della "riparazione sotto-vincolata" (under-constrained repair), in cui gli LLM propongono correzioni sintatticamente corrette ma funzionalmente irrilevanti o che alterano il comportamento previsto del design. Inoltre, i metodi esistenti spesso faticano con l'elaborazione di contesti lunghi e la complessità del tracciamento delle vulnerabilità nel tempo.

Metodologia
Gli autori propongono un framework strutturato e iterativo per sfruttare gli LLM per il rilevamento e la riparazione di Common Weakness Enumerations (CWE) in design Verilog a singolo modulo. La metodologia prende di mira specifiche debolezze hardware identificate nella lista 2025 delle vulnerabilità hardware più importanti di MITRE (escludendo le questioni microarchitetturali). Il processo segue una pipeline a sette stadi:

1. Classificazione del Modulo: L'LLM identifica il tipo di modulo e le sue caratteristiche (ad esempio, interfacce JTAG, modalità di debug) per restringere l'ambito dei potenziali CWE, prevenendo il sovraccarico di informazioni.
2. Identificazione degli Asset: Il modello identifica asset critici, come chiavi crittografiche, confini di privilegio, schemi di clock/reset e stati di Macchine a Stati Finiti (FSM).
3. Analisi del Grafo delle Dipendenze: L'LLM genera un Program Dependency Graph (PDG) per modellare il flusso di dati e di controllo. Esegue analisi di raggiungibilità, dominanza e propagazione del taint per comprendere il comportamento del design e le potenziali perdite di dati.
4. Revisione Guidata dai CWE: Utilizzando gli output degli step precedenti e guide specifiche sui CWE (che contengono descrizioni, cause comuni ed elenchi di controllo), l'LLM esegue una revisione mirata per identificare vulnerabilità specifiche.
5. Generazione del Testbench: Sulla base delle vulnerabilità identificate e delle regole di design sicuro specifiche per i CWE, l'LLM genera un testbench per verificare la presenza di difetti.
6. Simulazione: Il testbench generato viene compilato ed eseguito contro il design RTL.
7. Riparazione del Codice: Se i test falliscono, l'LLM tenta di riparare il codice utilizzando i casi di test falliti e le regole di design dei CWE come vincoli. Questo ciclo si ripete fino a tre volte.

Il framework è stato valutato su un dataset di 32 design Verilog a singolo modulo, di cui 27 con vulnerabilità note e 5 moduli intenzionalmente sicuri. Microsoft Copilot è stato utilizzato come LLM per la valutazione.

Risultati Chiave
Lo studio ha prodotto risultati misti, evidenziando sia il potenziale che le attuali limitazioni degli LLM in questo dominio:

• Punti di Forza: L'LLM ha dimostrato forti capacità nella classificazione dei moduli, nell'identificazione degli asset e nel ragionamento sugli aspetti strutturali e comportamentali del design (tramite l'analisi PDG). Ha identificato correttamente il tipo funzionale dei moduli in quasi tutti i casi e ha spesso riconosciuto le vulnerabilità prima della revisione formale guidata dai CWE.
• Debolezze:
  • Generazione del Testbench: Questo è stato il punto di maggiore debolezza. I testbench generati hanno spesso fallito nel validare le proprietà di sicurezza, spesso a causa di un uso errato del Device Under Test (DUT), casi di test incompleti o mancato reset del DUT tra i test.
  • Falsi Positivi su Design Sicuri: Nei cinque moduli non vulnerabili, l'LLM ha mostrato un alto tasso di falsi positivi, segnalando erroneamente i design sicuri come vulnerabili. Spesso ha raccomandato funzionalità di sicurezza non necessarie (ad esempio, bit di blocco, controlli di privilegio) che alteravano la funzionalità prevista.
  • Limitazioni della Riparazione: Sebbene l'LLM potesse generare patch sintatticamente corrette, le riparazioni a volte modificavano la funzionalità prevista del design originale. Il modello tendeva a favorire i miglioramenti della sicurezza rispetto alla preservazione del comportamento originale, portando all' "over-engineering" (ad esempio, aggiungendo il controllo degli accessi a moduli che non lo richiedevano).
• Tasso di Successo: Su 32 test totali, 27 hanno dato esito positivo, con un tasso di successo dell'84%. Questo tasso di successo riflette principalmente i 27 moduli contenenti vulnerabilità note che sono stati identificati e riparati con successo. Tuttavia, i 5 moduli non vulnerabili, che dovevano testare la capacità dell'IA di distinguere i design sicuri, hanno fallito questo specifico obiettivo. L'IA ha identificato erroneamente vulnerabilità in tutti e cinque i moduli sicuri, risultando in un alto tasso di falsi positivi. Per questi casi non vulnerabili, la riparazione del codice non è stata eseguita perché i problemi identificati non erano vulnerabilità reali; modificare questi design avrebbe alterato la loro funzionalità prevista. Diversi fallimenti nel set vulnerabile sono stati inoltre attribuiti all'incapacità di generare risultati di verifica significativi (ad esempio, output non inizializzati) o al fallimento nel classificare correttamente la funzione primaria del modulo, portando all'omissione di CWE rilevanti.

Significatività e Rivendicazioni
L'articolo sostiene che la metodologia proposta dimostra il potenziale degli LLM di aumentare l'analisi tradizionale della sicurezza hardware fornendo assistenza automatizzata e scalabile durante il processo di design. Gli autori sottolineano che il loro approccio aiuta a colmare il divario tra le capacità degli LLM e i rigorosi requisiti della sicurezza hardware strutturando l'analisi in passaggi gestibili (classificazione, identificazione degli asset, analisi del grafo).

Tuttavia, gli autori sono modesti nelle loro conclusioni, riconoscendo che l'attuale metodologia non è una soluzione completamente autonoma. Affermano che i risultati evidenziano la necessità di:

1. Prompting Raffinato: Per ridurre le allucinazioni e vincolare le riparazioni alla vulnerabilità specifica senza alterare la funzionalità prevista.
2. Contesto Esplicito: Fornire all'LLM informazioni esplicite riguardo allo scopo del modulo e al comportamento atteso per migliorare la precisione della classificazione e della riparazione.
3. Ulteriore Valutazione: La necessità di testare la metodologia su un set più ampio e diversificato di CWE e design RTL per valutarne la generalizzabilità.

L'articolo conclude che, sebbene gli LLM mostrino promessa nell'interpretare il comportamento dei moduli e identificare gli asset, la loro affidabilità nel ragionamento RTL, nella generazione di testbench e nella verifica delle vulnerabilità rimane limitata da fattori quali le lacune nella conoscenza del dominio e i prompt di riparazione sotto-vincolati. Il lavoro funge da guida per lo sviluppo e l'affinamento di futuri strumenti di sicurezza hardware basati su LLM.