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

기술 요약: LLM을 활용한 Verilog 설계의 하드웨어 보안 취약점 탐지 및 복구

문제 정의
하드웨어 설계, 특히 레지스터 전송 레벨(RTL)로 기술된 Verilog 설계는 일단 실리콘으로 제작되면 영구적이고 패치가 불가능해지는 보안 취약점에 노렵됩니다. 소프트웨어와 달리, 버그를 업데이트할 수 있는 소프트웨어와 대조적으로, 하드웨어 결함은 데이터 무단 노출, 권한 상승 및 무단 접근을 초래할 수 있습니다. 대규모 언어 모델(LLM)이 RTL 코드 복구 및 테스트벤치 생성 보조에 유망한 가능성을 보여주었지만, 현재 하드웨어 보안 분석에서는 상당한 과제에 직면해 있습니다. 이러한 과제에는 도메인 특화 지식의 부족, 하드웨어 설계에 대한 내재된 편향성, 그리고 LLM이 구문적으로는 올바르지만 기능적으로는 무관하거나 의도된 설계 동작을 변경하는 수정안을 제안하는 "제약이 부족한 복구(under-constrained repair)" 문제가 포함됩니다. 또한, 기존 방법들은 긴 컨텍스트 처리와 시간에 따른 취약점 추적의 복잡성을 다루는 데 어려움을 겪는 경우가 많습니다.

방법론
저자들은 단일 모듈 Verilog 설계에서 CWE(Common Weakness Enumerations)를 탐지하고 복구하기 위해 LLM을 활용하는 구조화되고 반복적인 프레임워크를 제안합니다. 이 방법론은 MITRE의 2025년 주요 하드웨어 취약점 목록(마이크로아키텍처 이슈 제외)에서 식별된 특정 하드웨어 약점을 대상으로 합니다. 프로세스는 7단계 파이프라인을 따릅니다:

1. 모듈 분류: LLM은 모듈 유형과 특징(예: JTAG 인터페이스, 디버그 모드)을 식별하여 잠재적 CWE의 범위를 좁힘으로써 정보 과부하를 방지합니다.
2. 자산 식별: 모델은 암호화 키, 권한 경계, 클록/리셋 체계, 유한 상태 머신(FSM) 상태와 같은 핵심 자산을 식별합니다.
3. 종속성 그래프 분석: LLM은 데이터 및 제어 흐름을 모델링하기 위해 프로그램 종속성 그래프(PDG)를 생성합니다. 설계 동작과 잠재적인 데이터 유출을 이해하기 위해 도달 가능성(reachability), 지배(dominance) 및 오염 전파(taint propagation) 분석을 수행합니다.
4. CWE 기반 검토: 이전 단계의 출력값과 특정 CWE 가이드(설명, 일반적인 원인 및 체크리스트 포함)를 사용하여, 타겟팅된 검토를 수행하여 특정 취약점을 식별합니다.
5. 테스트벤치 생성: 식별된 취약점과 CWE별 보안 설계 규칙을 기반으로, 결함의 존재를 검증하기 위한 테스트벤치를 생성합니다.
6. 시뮬레이션: 생성된 테스트벤치를 RTL 설계에 대해 컴파일하고 실행합니다.
7. 코드 복구: 테스트가 실패하면, LLM은 실패한 테스트 케이스와 CWE 설계 규칙을 제약 조건으로 사용하여 코드를 복구하려고 시도합니다. 이 사이클은 최대 3회까지 반복됩니다.

이 프레임워크는 알려진 취약점이 있는 27개와 의도적으로 보안이 강화된 5개의 모듈을 포함하여 총 32개의 단일 모듈 Verilog 설계 데이터셋을 통해 평가되었습니다. 평가를 위한 LLM으로는 Microsoft Copilot이 사용되었습니다.

주요 결과
연구 결과는 LLM의 잠재력과 현재의 한계를 동시에 보여주는 혼합된 결과를 나타냈습니다:

• 강점: LLM은 모듈 분류, 자산 식별, 그리고 (PDG 분석을 통한) 설계의 구조적 및 동작적 측면에 대한 추론에서 강력한 능력을 보여주었습니다. 모델은 거의 모든 경우에서 모듈의 기능적 유형을 정확히 식별했으며, 공식적인 CWE 기반 검토 이전에 취약점을 인식하는 경우가 많았습니다.
• 약점:
  • 테스트벤치 생성: 가장 큰 약점이었습니다. 생성된 테스트벤치는 DUT(Device Under Test) 사용의 오류, 불완전한 테스트 케이스, 또는 테스트 간 DUT 리셋 실패 등으로 인해 보안 속성을 검증하는 데 자주 실패했습니다.
  • 보안 설계에 대한 위양성(False Positives): 취약점이 없는 5개의 모듈에서 LLM은 높은 위양성률을 보이며 보안 설계가 취약하다고 잘못 식 flag를 달았습니다. 모델은 의도된 기능을 변경하는 불필요한 보안 기능(예: 락 비트, 권한 제어)을 권고하곤 했습니다.
  • 복구의 한계: LLM은 구문적으로 올바른 패치를 생성할 수 있었지만, 복구 과정에서 원래 설계의 의도된 기능을 수정하는 경우가 있었습니다. 모델은 원래의 동작을 보존하기보다 보안 강화를 선호하는 경향이 있어, "오버 엔지니어링"(예: 필요하지 않은 모듈에 액세스 제어를 추가함)을 초래했습니다.
• 성공률: 총 32개의 테스트 중 27개가 통과되어 84%의 성공률을 기록했습니다. 이 성공률은 주로 알려진 취약점이 포함된 27개의 모듈이 성공적으로 식별되고 복구되었음을 반영합니다. 그러나 보안 설계를 구분하는 AI의 능력을 테스트하기 위해 의도되었던 5개의 비취약 모듈은 이 특정 목적에 실패했습니다. AI는 5개의 보안 모듈 모두에서 취약점을 잘못 식별하여 높은 위양성률을 보였습니다. 이러한 비취약 사례의 경우, 식별된 이슈가 실제 취약점이 아니었기 때문에 코드 복구는 수행되지 않았습니다(설계를 수정하면 의도된 기능이 변경되기 때문임). 취약한 세트에서의 일부 실패 역시 의미 있는 검증 결과(예: 초기화되지 않은 출력)를 생성하지 못하거나, 모듈의 주요 기능을 정확히 분류하지 못해 관련 CWE를 누락한 것에 기인했습니다.

의의 및 주장
본 논문은 제안된 방법론이 설계 과정 중에 자동화되고 확장 가능한 지원을 제공함으로써 전통적인 하드웨어 보안 분석을 증강할 수 있는 LLM의 잠재력을 입증한다고 주장합니다. 저자들은 분석 과정을 관리 가능한 단계(분류, 자산 식별, 그래프 분석)로 구조화함으로써, LLM의 능력과 하드웨어 보안의 엄격한 요구사항 사이의 간극을 메우는 데 도움이 된다고 강조합니다.

그러나 저자들은 현재의 방법론이 완전히 자율적인 솔루션은 아님을 인정하며 결론을 겸허하게 내리고 있습니다. 그들은 다음 사항의 필요성을 언급합니다:

1. 정교한 프 prompting: 환각(hallucination)을 줄이고, 의도된 기능을 변경하지 않으면서 특정 취약점에만 복구를 제한하기 위 Whiles.
2. 명시적 컨텍스트: 분류 및 복구 정확도를 높이기 위해 모듈의 목적과 예상 동작에 대한 명시적인 정보를 LLM에 제공해야 합니다.
3. 추가 평가: 일반화 가능성을 평가하기 위해 더 다양하고 큰 규모의 CWE 및 RTL 설계 세트에 대해 방법론을 테스트할 필요가 있습니다.

결론적으로, 본 연구는 LLM이 모듈 동작을 해석하고 자산을 식별하는 데 유망함을 보여주지만, RTL 추론, 테스트벤치 생성 및 취약점 검증에서의 신뢰성은 도메인 지식 격차 및 제약이 부족한 복구 프롬프트와 같은 요인들에 의해 여전히 제한적이라고 밝히고 있습니다. 이 작업은 향-LLM 기반 하드웨어 보안 도구 개발 및 미세 조정을 위한 가이드 역할을 합니다.