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

Technisches Resümee: LLM-gestützte Erkennung und Behebung von Hardware-Sicherheitslücken in Verilog-Designs

Problemstellung
Hardware-Designs, insbesondere solche, die in Verilog auf der Register Transfer Level (RTL) beschrieben sind, sind anfällig für Sicherheitslücken, die nach der Fertigung in Silizium permanent und nicht mehr patchbar werden. Im Gegensatz zu Software, bei der Bugs aktualisiert werden können, führen Hardware-Fehler zu unbefugter Datenexposition, Privilegieneskalation und unbefugtem Zugriff. Obwohl Large Language Models (LLMs) vielversprechende Ansätze zur Unterstützung der RTL-Code-Reparatur und Testbench-Erstellung gezeigt haben, stehen sie bei der Hardware-Sicherheitsanalyse derzeit vor erheblichen Herausforderungen. Dazu gehören ein Mangel an domänenspezifischem Wissen, inhärente Vorurteile gegenüber dem Hardware-Design und das Problem der „unterbeschränkten Reparatur“ (under-constrained repair), bei dem LLMs Korrekturen vorschlagen, die zwar syntaktisch korrekt, aber funktional irrelevant sind oder das beabsichtigte Designverhalten verändern. Darüber hinaus haben bestehende Methoden oft Schwierigkeiten mit der Verarbeitung langer Kontexte und der Komplexität der Rückverfolgbarkeit von Schwachstellen über die Zeit.

Methodik
Die Autoren schlagen ein strukturiertes, iteratives Framework vor, um LLMs zur Erkennung und Behebung von Common Weakness Enumerations (CWEs) in Single-Module-Verilog-Designs zu nutzen. Die Methodik zielt auf spezifische Hardware-Schwächen ab, die in der MITRE-Liste der wichtigsten Hardware-Schwachstellen für 2025 identifiziert wurden (ausgenommen mikroarchitektonische Themen). Der Prozess folgt einer siebenstufigen Pipeline:

1. Modulklassifizierung: Das LLM identifiziert den Modultyp und die Funktionen (z. B. JTAG-Schnittstellen, Debug-Modi), um den Umfang potenzieller CWEs einzugrenzen und Informationsüberlastung zu vermeiden.
2. Identifizierung von Assets: Das Modell identifiziert kritische Assets wie kryptografische Schlüssel, Privilegengrenzen, Clock/Reset-Schemata und Finite State Machine (FSM)-Zustände.
3. Analyse des Abhängigkeitsgraphen: Das LLM generiert einen Program Dependency Graph (PDG), um Daten- und Kontrollfluss zu modellieren. Es führt Erreichbarkeits-, Dominanz- und Taint-Propagation-Analysen durch, um das Designverhalten und potenzielle Datenlecks zu verstehen.
4. CWE-gesteuerte Überprüfung: Unter Verwendung der Ergebnisse der vorherigen Schritte und spezifischer CWE-Leitfäden (die Beschreibungen, häufige Ursachen und Checklisten enthalten) führt das LLM eine gezielte Überprüfung durch, um spezifische Schwachstellen zu identifizieren.
5. Testbench-Generierung: Basierend auf den identifizierten Schwachstellen und CWE-spezifischen sicheren Designregeln generiert das LLM eine Testbench, um das Vorhandensein von Fehlern zu verifizieren.
6. Simulation: Die generierte Testbench wird kompiliert und gegen das RTL-Design ausgeführt.
7. Code-Reparatur: Falls Tests fehlschlagen, versucht das LLM, den Code unter Verwendung der fehlgeschlagenen Testfälle und CWE-Designregeln als Constraints zu reparieren. Dieser Zyklus wiederholt sich bis zu dreimal.

Das Framework wurde anhand eines Datensatzes von 32 Single-Module-Verilog-Designs evaluiert, darunter 27 mit bekannten Schwachstellen und 5 absichtlich sichere Module. Microsoft Copilot wurde als LLM für die Evaluierung verwendet.

Wichtige Ergebnisse
Die Studie lieferte gemischte Ergebnisse, die sowohl das Potenzial als auch die aktuellen Einschränkungen von LLMs in diesem Bereich verdeutlichen:

• Stärken: Das LLM zeigte starke Fähigkeiten in der Modulklassifizierung, der Identifizierung von Assets und dem Schlussfolgern über strukturelle und verhaltensbezogene Aspekte des Designs (via PDG-Analyse). Es identifizierte den Funktionstyp der Module in fast allen Fällen korrekt und erkannte Schwachstellen oft bereits vor der formalen CWE-gesteuerten Überprüfung.
• Schwächen:
  • Testbench-Generierung: Dies war die größte Schwäche. Generierte Testbenches scheiterten häufig daran, Sicherheitseigenschaften zu validieren, oft aufgrund einer fehlerhaften Verwendung des Device Under Test (DUT), unvollständiger Testfälle oder des Versagens, das DUT zwischen den Tests zurückzusetzen.
  • Falsch-Positive bei sicheren Designs: In den fünf nicht verwundbaren Modulen zeigte das LLM eine hohe Falsch-Positiv-Rate und markierte sichere Designs fälschlicherweise als verwundbar. Es empfahl oft unnötige Sicherheitsfunktionen (z. B. Lock-Bits, Privilegierungskontrollen), die die beabsichtigte Funktionalität veränderten.
  • Reparatur-Einschränkungen: Während das LLM syntaktisch korrekte Patches generieren konnte, veränderten die Reparaturen teilweise die beabsichtigte Funktionalität des ursprünglichen Designs. Das Modell neigte dazu, Sicherheitsverbesserungen gegenüber der Bewahrung des ursprünglichen Verhaltens zu bevorzugen, was zu „Over-Engineering“ führte (z. B. dem Hinzufügen von Zugriffskontrollen zu Modulen, die dies nicht erforderten).
• Erfolgsrate: Von insgesamt 32 Tests führten 27 zu einem Pass, was einer Erfolgsrate von 84 % entspricht. Diese Erfolgsrate spiegelt primlich die 27 Module wider, die bekannte Schwachstellen enthielten und erfolgreich identifiziert sowie repariert wurden. Die 5 nicht verwundbaren Module jedoch, die dazu dienten, die Fähigkeit der KI zu testen, sichere Designs zu unterscheiden, scheiterten an diesem spezifischen Ziel. Die KI identifizierte Schwachstellen in allen fünf sicheren Modulen fälschlicherweise, was zu einer hohen Falsch-Positiv-Rate führte. Für diese nicht verwundbaren Fälle wurde keine Code-Reparatur durchgeführt, da die identifizierten Probleme keine tatsächlichen Schwachstellen waren; eine Modifikation dieser Designs hätte ihre beabsichtigte Funktionalität verändert. Mehrere Fehler im verwundbaren Set wurden ebenfalls auf die Unfähigkeit zurückgeführt, aussagekräftige Verifizierungsergebnisse zu liefern (z. B. uninitialisierte Ausgänge) oder auf das Versagen, die primäre Funktion des Moduls korrekt zu klassifizieren, was zum Auslassen relevanter CWEs führte.

Bedeutung und Ansprüche
Die Arbeit behauptet, dass ihre vorgeschlagene Methodik das Potenzial von LLMs aufzeigt, die traditionelle Hardware-Sicherheitsanalyse durch automatisierte, skalierbare Unterstützung während des Designprozesses zu ergänzen. Die Autoren betonen, dass ihr Ansatz hilft, die Lücke zwischen LLM-Fähigkeiten und den strengen Anforderungen der Hardware-Sicherheit zu schließen, indem die Analyse in handhabbare Schritte (Klassifizierung, Asset-Identifizierung, Graph-Analyse) strukturiert wird.

Die Autoren sind jedoch bescheiden in ihren Schlussfolgerungen und räumen ein, dass die aktuelle Methodik keine vollautonome Lösung ist. Sie stellen fest, dass die Ergebnisse die Notwendigkeit folgender Punkte verdeutlichen:

1. Verfeinertes Prompting: Um Halluzinationen zu reduzieren und Reparaturen auf die spezifische Schwachstelle zu beschränken, ohne die beabsichtigte Funktionalität zu verändern.
2. Expliziter Kontext: Bereitstellung expliziter Informationen über den Zweck und das erwartete Verhalten des Moduls, um die Klassifizierung und Reparaturgenauigkeit zu verbessern.
3. Weitere Evaluierung: Die Notwendigkeit, die Methodik an einem größeren, vielfältigeren Satz von CWEs und RTL-Designs zu testen, um die Generalisierbarkeit zu bewerten.

Die Arbeit kommt zu dem Schluss, dass LLMs zwar vielversprechend darin sind, das Modulverhalten zu interpretieren und Assets zu identifizieren, ihre Zuverlässigkeit in der RTL-Argumentation, der Testbench-Generierung und der Verifizierung von Schwachstellen jedoch durch Faktoren wie Wissenslücken in der Domäne und unterbeschränkte Reparatur-Prompts begrenzt bleibt. Die Arbeit dient als Leitfaden für die Entwicklung und Feinabstimmung zukünftiger LLM-basierter Hardware-Sicherheitswerkzeuge.