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

Resumen Técnico: Detección y Reparación de Vulnerabilidades de Seguridad de Hardware en Diseños Verilog Asistida por LLM

Planteamiento del Problema
Los diseños de hardware, particularmente aquellos descritos en Verilog a nivel de transferencia de registros (RTL), son susceptibles a vulnerabilidades de seguridad que, una vez fabricadas en silicio, se vuelven permanentes y no parcheables. A diferencia del software, donde los errores pueden actualizarse, los fallos de hardware pueden conducir a la exposición de datos no autorizada, escalada de privilegios y acceso no autorizado. Si bien los Modelos de Lenguaje de Gran Escala (LLM) han mostrado promesa en asistir con la reparación de código RTL y la creación de bancos de pruebas (testbenches), actualmente enfrentan desafíos significativos en el análisis de seguridad de hardware. Estos incluyen la falta de conocimiento específico del dominio, sesgos inherentes contra el diseño de hardware y el problema de la "reparación sub-restringida", donde los LLM proponen correcciones que son sintácticamente correctas pero funcionalmente irrelevantes o alteran el comportamiento previsto del diseño. Además, los métodos existentes suelen tener dificultades con el procesamiento de contextos largos y la complejidad de rastrear vulnerabilidades a lo largo del tiempo.

Metodología
Los autores proponen un marco estructurado e iterativo para aprovechar los LLM en la detección y reparación de Enumeraciones de Debilidades Comunes (CWE) en diseños Verilog de un solo módulo. La metodología se dirige a debilidades de hardware específicas identificadas en la lista de 2025 de las vulnerabilidades de hardware más importantes de MITRE (excluyendo problemas microarquitectónicos). El proceso sigue un flujo de trabajo de siete etapas:

1. Clasificación del Módulo: El LLM identifica el tipo de módulo y sus características (por ejemplo, interfaces JTAG, modos de depuración) para reducir el alcance de las posibles CWE, evitando la sobrecarga de información.
2. Identificación de Activos: El modelo identifica activos críticos, como claves criptográficas, límites de privilegios, esquemas de reloj/reset y estados de Máquinas de Estados Finitos (FSM).
3. Análisis del Grafo de Dependencias: El LLM genera un Grafo de Dependencia de Programa (PDG) para modelar el flujo de datos y de control. Realiza análisis de alcanzabilidad, dominancia y propagación de tintas (taint propagation) para comprender el comportamiento del diseño y las posibles fugas de datos.
4. Revisión Impulsada por CWE: Utilizando los resultados de los pasos anteriores y guías específicas de CWE (que contienen descripciones, causas comunes y listas de verificación), el LLóM realiza una revisión dirigida para identificar vulnerabilidades específicas.
5. Generación de Testbench: Basándose en las vulnerabilidades identificadas y en las reglas de diseño seguro específicas de cada CWE, el LLM genera un banco de pruebas para verificar la presencia de fallos.
6. Simulación: El testbench generado se compila y se ejecuta contra el diseño RTL.
7. Reparación de Código: Si las pruebas fallan, el LLM intenta reparar el código utilizando los casos de prueba fallidos y las reglas de diseño de CWE como restricciones. Este ciclo se repite hasta tres veces.

El marco fue evaluado en un conjunto de datos de 32 diseños Verilog de un solo módulo, incluyendo 27 con vulnerabilidades conocidas y 5 módulos intencionalmente seguros. Se utilizó Microsoft Copilot como el LLM para la evaluación.

Resultados Clave
El estudio arrojó resultados mixtos, resaltando tanto el potencial como las limitaciones actuales de los LLM en este dominio:

• Fortalezas: El LLM demostró capacidades sólidas en la clasificación de módulos, identificación de activos y razonamiento sobre aspectos estructurales y de comportamiento del diseño (mediante el análisis PDG). Identificó correctamente el tipo funcional de los módulos en casi todos los casos y a menudo reconoció vulnerabilidades antes de la revisión formal impulsada por CWE.
• Debilidades:
  • Generación de Testbench: Esta fue la mayor debilidad. Los testbenches generados fallaron frecuentemente al validar propiedades de seguridad, debido a menudo al uso incorrecto del Dispositivo Bajo Prueba (DUT), casos de prueba incompletos o la falta de reinicio (reset) del DUT entre pruebas.
  • Falsos Positivos en Diseños Seguros: En los cinco módulos no vulnerables, el LLM exhibió una alta tasa de falsos positivos, marcando erróneamente diseños seguros como vulnerables. A menudo recomendó características de seguridad innecesarias (por ejemplo, bits de bloqueo, controles de privilegios) que alteraban la funcionalidad pretendida.
  • Limitaciones de Reparación: Aunque el LLM pudo generar parches sintácticamente correctos, las reparaciones a veces modificaron la funcionalidad pretendida del diseño original. El modelo tendió a favorecer las mejoras de seguridad sobre la preservación del comportamiento original, lo que llevó a una "sobre-ingeniería" (por ejemplo, añadir control de acceso a módulos que no lo requerían).
• Tasa de Éxito: De 32 pruebas totales, 27 resultaron en un pase, arrojando una tasa de éxito del 84%. Esta tasa de éxito refleja principalmente los 27 módulos que contenían vulnerabilidades conocidas que fueron identificadas y reparadas con éxito. Sin embargo, los 5 módulos no vulnerables, que tenían como objetivo probar la capacidad de la IA para distinguir diseños seguros, fallaron en este objetivo específico. La IA identificó erróneamente vulnerabilidades en todos los cinco módulos seguros, lo que resultó en una alta tasa de falsos positivos. Para estos casos no vulnerables, no se realizó la reparación de código porque los problemas identificados no eran vulnerabilidades reales; modificar estos diseños habría alterado su funcionalidad pretendida. Varios fallos en el conjunto vulnerable también se atribuyeron a la incapacidad de generar resultados de verificación significativos (por ejemplo, salidas no inicializadas) o al fallo al clasificar correctamente la función principal del módulo, lo que llevó a la omisión de CWE relevantes.

Significancia y Reivindicaciones
El artículo afirma que su metodología propuesta demuestra el potencial de los LLM para aumentar el análisis de seguridad de hardware tradicional al proporcionar asistencia automatizada y escalable durante el proceso de diseño. Los autores enfatizan que su enfoque ayuda a cerrar la breancia entre las capacidades de los LLM y los rigurosos requisitos del hardware mediante la estructuración del análisis en pasos manejables (clasificación, identificación de activos, análisis de grafos).

Sin embargo, los autores son modestos en sus conclusiones, reconociendo que la metodología actual no es una solución totalmente autónoma. Afirman que los resultados resaltan la necesidad de:

1. Prompting Refinado: Para reducir las alucinaciones y restringir las reparaciones a la vulnerabilidad específica sin alterar la funcionalidad pretendida.
2. Contexto Explícito: Proporcionar al LLM información explícita sobre el propósito del módulo y su comportamiento esperado para mejorar la precisión de la clasificación y la reparación.
3. Evaluación Adicional: La necesidad de probar la metodología en un conjunto más grande y diverso de CWE y diseños RTL para evaluar la generalizabilidad.

El artículo concluye que, si bien los LLM muestran promesa en la interpretación del comportamiento de los módulos y la identificación de activos, su fiabilidad en el razonamiento RTL, la generación de testbenches y la verificación de vulnerabilidades sigue estando limitada por factores como las brechas de conocimiento del dominio y los prompts de reparación sub-restringidos. Este trabajo sirve como guía para el desarrollo y el ajuste fino de futuras herramientas de seguridad de hardware basadas en LLM.