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

技術要約：Verilog設計におけるLLMを活用したハードウェアセキュリティ脆弱性の検出と修復

問題提起
ハードウェア設計、特にレジスタ転送レベル（RTL）で記述されるVerilogは、一度シリコンに焼き付けられると永久的かつ修正不可能となるセキュリティ上の脆弱性を抱えやすい。ソフトウェアではバグを更新できるが、ハードウェアの欠陥はデータの不正露出、権限昇格、および不正アクセスを招く可能性がある。大規模言語モデル（LLM）は、RTLコードの修復やテストベンチの作成を支援する上で有望な兆しを見せているものの、現在のLLMはハードウェアセキュリティ解析において重大な課題に直面している。これには、ドメイン固有の知識の欠如、ハードウェア設計に対する固有のバイアス、そして「制約不足の修復（under-constrained repair）」問題が含まれる。後者は、LLMが構文的には正しいものの、機能的には無関係であったり、意図された設計動作を変更してしまったりする修正案を提示してしまう問題である。さらに、既存の手法は、長いコンテキストの処理や、時間の経過に伴う脆弱性の追跡の複雑さに苦慮することが多い。

手法
著者らは、単一モジュールのVerilog設計における共通脆弱性識別子（CWE）を検出・修復するために、LLMを活用した構造化された反復フレームワークを提案している。この手法は、MITREの2025年版最も重要なハードウェア脆弱性リスト（マイクロアーキテクチャの問題を除く）で特定された特定のハードウェアの弱点を対象としている。プロセスは以下の7段階のパイプラインに従う：

1. モジュール分類: LLMがモジュールのタイプと機能（例：JTAGインターフェース、デバッグモード）を特定し、潜在的なCWEの範囲を絞り込むことで、情報のオーバーロードを防ぐ。
2. アセット特定: モデルは、暗号鍵、特権境界、クロック/リセットスキーム、有限状態マシン（FSM）の状態などの重要なアセットを特定する。
3. 依存グラフ解析: LLMは、データフローと制御フローをモデル化するためにプログラム依存グラフ（PDG）を生成する。設計の挙動とデータの漏洩を理解するために、到達可能性、支配、およびテイント伝播解析を実行する。
4. CWE駆動型レビュー: 前のステップからの出力と、特定のCWEガイド（説明、一般的な原因、チェックリストを含む）を用いて、ターゲットを絞ったレビューを行い、特定の脆弱性を特定する。
5. テストベンチ生成: 特定された脆弱性とCWE固有のセキュア設計ルールに基づき、欠陥の存在を検証するためのテストベンチを生成する。
6. シミュレーション: 生成されたテストベンチを、RTL設計に対してコンパイルし、実行する。
7. コード修復: テストが失敗した場合、LLMは失敗したテストケースとCWE設計ルールを制約条件として使用して、コードの修復を試みる。このサイクルは最大3回繰り返される。

本フレームワークは、既知の脆弱性を持つ27個のモジュールと、意図的にセキュアに設計された5個のモジュールを含む、計32個の単一モジュールVerylog設計のデータセットを用いて評価された。評価には、LLMとしてMicrosoft Copilotが使用された。

主な結果
研究結果は、この領域におけるLLMの可能性と現在の限界の両方を浮き彫りにする、混合した結果となった：

• 強み: LLMは、モジュール分類、アセット特定、および（PDG解析による）設計の構造的・振る舞的な側面に関する推論において、強力な能力を示した。モデルはほぼすべてのケースでモジュールの機能的タイプを正しく特定し、形式的なCWE駆動型レビューの前に脆弱性を認識することが多かった。
• 弱み:
  • テストベンチ生成: これが最大の弱点であった。生成されたテストベンチは、DUT（被テストデバイス）の使い方の誤り、テストケースの不完全さ、あるいはテスト間のDUTのリセット失敗などが原因で、セキュリティ特性の検証に失敗することが頻繁にあった。
  • セキュア設計に対する偽陽性: 非脆弱な5つのモジュールにおいて、LLMは高い偽陽性率を示し、セキュアな設計を誤って脆弱であると判定した。モデルは、意図した機能を変更してしまうような不要なセキュリティ機能（例：ロックビット、特権制御）を推奨することが多かった。
  • 修復の限界: LLMは構文的に正しいパッチを生成できたものの、修復によって元の設計の意図した機能が変更されることがあった。モデルは、元の動作を維持することよりもセキュリティ強化を優先する傾向があり、「オーバーエンジニアリング」（例：必要のないモジュールへのアクセス制御の追加）を招いた。
• 成功率: 全32件のテストのうち、27件がパスし、84%の成功率を得た。この成功率は、主に既知の脆弱性が含まれており、正常に特定・修復された27個のモジュールを反映している。しかし、AIがセキュアな設計を判別する能力をテストするための目的であった5個の非脆弱なモジュールについては、この特定の目的を果たせなかった。AIはこれら5つすべてのセキュアなモジュールにおいて脆弱性を誤認し、高い偽陽性率となった。これらの非脆弱なケースでは、特定された問題が実際の脆弱性ではなかったため、コード修復は行われなかった。これらの設計を修正することは、意図した機能を変更することになるからである。また、既知の脆弱性セットにおけるいくつかの失敗も、意味のある検証結果を生成できないこと（例：未初期化の出力）や、モジュールの主要な機能を正しく分類できず、関連するCWEの検討が漏れたことに起因していた。

意義と主張
本論文は、提案された手法が、設計プロセス中に自動化されスケーラブルな支援を提供することで、従来のハードウェアセキュリティ解析を拡張するLLMの可能性を示していると主張している。著者らは、分析を管理可能なステップ（分類、アセット特定、グラフ解析）に構造化することで、LLMの能力とハードウェアセキュリティの厳格な要件との間のギャップを埋めるアプローチを強調している。

しかし、著者らは結論において謙虚であり、現在の手法が完全に自律的なソリューションではないことを認めている。彼らは、以下の必要性を述べている：

1. プロンプトの洗練: ハルシネーションを減らし、意図した機能を変更せずに特定の脆弱性に修復を制約するため。
2. 明示的なコンテキスト: 分類と修復の精度を向上させるために、モジュールの目的と期待される動作に関する明示的な情報をLLMに提供すること。
3. さらなる評価: 一般化可能性を評価するために、より多様なCWEおよびRTL設計のセットで手法をテストする必要があること。

論文は、LLMはモジュールの挙動の解釈やアセットの特定において有望であるものの、RTL推論、テストベンチ生成、および脆弱性検証における信頼性は、ドメイン知識のギャップや制約不足の修復プロンプトなどの要因によって依然として限定的であると結論付けている。本研究は、将来のLLMベースのハードウェアセキュリティツールの開発および微調整のためのガイドとして機能するものである。