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

Resumo Técnico: Detecção e Reparo de Vulnerabilidades de Segurança de Hardware em Projetos Verilog Assistidos por LLM

Declaração do Problema
Projetos de hardware, particularmente aqueles descritos em Verilog no nível de transferência de registro (RTL), são suscetíveis a vulnerabilidades de segurança que, uma vez fabricadas em silício, tornam-se permanentes e impossíveis de corrigir via patch. Diferente do software, onde bugs podem ser atualizados, falhas de hardware podem levar à exposição de dados não autorizada, escalonamento de privilégios e acesso não autorizado. Embora os Grandes Modelos de Linguagem (LLMs) tenham mostrado promessa em auxiliar na reparação de código RTL e na criação de testbenches, eles enfrentam desafios significativos na análise de segurança de hardware. Estes incluem a falta de conhecimento específico do domínio, vieses inerentes contra o design de hardware e o problema do "reparo sub-restrito", onde os LLMs propõem correções que são sintaticamente corretas, mas funcionalmente irrelevantes ou que alteram o comportamento pretendido do design. Além disso, métodos existentes frequentemente lutam com o processamento de contexto longo e a complexidade de rastrear vulnerabilidades ao longo do tempo.

Metodologia
Os autores propõem um framework estruturado e iterativo para aproveitar LLMs para detectar e reparar Common Weakness Enumerations (CWEs) em designs de módulos únicos em Verilog. A metodologia visa vulnerabilidades específicas de hardware identificadas na lista de vulnerabilidades de hardware mais importantes da MITRE de 2025 (excluindo questões microarquiteturais). O processo segue um pipeline de sete estágios:

1. Classificação do Módulo: O LLM identifica o tipo de módulo e suas características (ex: interfaces JTAG, modos de debug) para estreitar o escopo de possíveis CWEs, evitando a sobrecarga de informações.
2. Identificação de Ativos: O modelo identifica ativos críticos, como chaves criptográficas, fronteiras de privilégio, esquemas de clock/reset e estados de Máquina de Estados Finitos (FSM).
3. Análise de Grafo de Dependência: O LLM gera um Grafo de Dependência de Programa (PDG) para modelar o fluxo de dados e controle. Ele realiza análises de alcançabilidade, dominância e propagação de taint para entender o comportamento do design e potenciais vazamentos de dados.
4. Revisão Baseada em CWE: Utilizando os outputs das etapas anteriores e guias específicos de CWE (contendo descrições, causas comuns e checklists), o LLM realiza uma revisão direcionada para identificar vulnerabilidades específicas.
5. Geração de Testbench: Com base nas vulnerabilidades identificadas e nas regras de design seguro específicas de CWE, o LLM gera um testbench para verificar a presença de falhas.
6. Simulação: O testbench gerado é compilado e executado contra o design RTL.
7. Reparo de Código: Se os testes falharem, o LLM tenta reparar o código usando os casos de teste que falharam e as regras de design de CWE como restrições. Este ciclo se repete até três vezes.

O framework foi avaliado em um conjunto de dados de 32 designs de módulo único em Verilog, incluindo 27 com vulnerabilidades conhecidas e 5 módulos intencionalmente seguros. O Microsoft Copilot foi utilizado como o LLM para a avaliação.

Principais Resultados
O estudo rendeu resultados mistos, destacando tanto o potencial quanto as limitações atuais dos LLMs neste domínio:

• Pontos Fortes: O LLM demonstrou fortes capacidades em classificação de módulos, identificação de ativos e raciocínio sobre aspectos estruturais e comportamentais do design (via análise de PDG). Ele identificou corretamente o tipo funcional dos módulos em quase todos os casos e frequentemente reconheceu vulnerabilidades antes da revisão específica de CWE.
• Pontos Fracos:
  • Geração de Testbench: Esta foi a maior fraqueza. Os testbenches gerados frequentemente falharam em validar propriedades de segurança, muitas vezes devido ao uso incorreto do Dispositivo Sob Teste (DUT), casos de teste incompletos ou falha em resetar o DUT entre os testes.
  • Falsos Positivos em Designs Seguros: Nos cinco módulos não vulneráveis, o LLM exibiu uma alta taxa de falsos positivos, sinalizando incorretamente designs seguros como vulneráveis. Frequentemente, recomendou recursos de segurança desnecessários (ex: bits de trava, controles de privilégio) que alteravam a funcionalidade pretendida.
  • Limitações de Reparo: Embora o LLM pudesse gerar patches sintaticamente corretos, os reparos às vezes modificavam a funcionalidade pretendida do design original. O modelo tendeu a favorecer melhorias de segurança em detrimento da preservação do comportamento original, levando ao "over-engineering" (ex: adicionar controle de acesso a módulos que não o exigiam).
• Taxa de Sucesso: De 32 testes totais, 27 resultaram em aprovação, rendendo uma taxa de sucesso de 84%. Esta taxa de sucesso reflete primariamente os 27 módulos contendo vulnerabilidades conhecidas que foram identificados e reparados com sucesso. No entanto, os 5 módulos não vulneráveis, que deveriam testar a capacidade da IA de distinguir designs seguros, falharam neste objetivo específico. A IA identificou incorretamente vulnerabilidades em todos os cinco módulos seguros, resultando em uma alta taxa de falsos positivos. Para estes casos não vulneráveis, o reparo de código não foi realizado porque os problemas identificados não eram vulnerabilidades reais; modificar esses designs alteraria sua funcionalidade pretendida. Várias falhas no conjunto de vulneráveis também foram atribuídas à incapacidade de gerar resultados de verificação significativos (ex: saídas não inicializadas) ou à falha em classificar corretamente a função primária do módulo, levando à omissão de CWEs relevantes.

Significância e Alegações
O artigo alega que sua metodologia proposta demonstra o potencial dos LLMs para aumentar a análise tradicional de segurança de hardware ao fornecer assistência automatizada e escalável durante o processo de design. Os autores enfatizam que sua abordagem ajuda a preencher a lacuna entre as capacidades dos LLMs e os requisitos rigorosos da segurança de hardware ao estruturar a análise em etapas gerenciáveis (classificação, identificação de ativos, análise de grafo).

No entanto, os autores são modestos em suas conclusões, reconhecendo que a metodologia atual não é uma solução totalmente autônoma. Eles afirmam que os resultados destacam a necessidade de:

1. Prompting Refinado: Para reduzir alucinações e restringir os reparos à vulnerabilidade específica sem alterar a funcionalidade pretendida.
2. Contexto Explícito: Fornecer ao LLM informações explícitas sobre o propósito do módulo e o comportamento esperado para melhorar a precisão da classificação e do reparo.
3. Avaliação Adicional: A necessidade de testar a metodologia em um conjunto maior e mais diversificado de CWEs e designs RTL para avaliar a generalização.

O artigo conclui que, embora os LLMs mostrem promessa na interpretação do comportamento do módulo e na identificação de ativos, sua confiabilidade no raciocínio RTL, geração de testbench e verificação de vulnerabilidades permanece limitada por fatores como lacunas de conhecimento de domínio e prompts de reparo sub-restritos. O trabalho serve como um guia para o desenvolvimento e ajuste fino de futuras ferramentas de segurança de hardware baseadas em LLM.