AttackonCTF: Defending Hardware Security Competition Benchmarks in the Age of LLMs

Resumen Técnico: AttackonCTF: Defendiendo los Benchmarks de Competiciones de Seguridad de Hardware en la Era de los LLM

Planteamiento del Problema
Las competiciones de seguridad de hardware, como HackTheSilicon, sirven como puntos de referencia críticos para evaluar las herramientas de detección de vulnerabilidades y la formación de investigadores humanos y modelos de IA. Estas competiciones utilizan diseños de System-on-Chip (SoC) de código abierto (p. ej., OpenTitan) con vulnerabilidades inyectadas basadas en la industria. Un requisito fundamental para la participación es la entrega de informes técnicos exhaustivos que demuestren un razonamiento de seguridad genuino, en lugar de una simple comparación de código.

Sin embargo, los autores identifican una amenaza de validez crítica planteada por los Modelos de Lenguaje de Gran Escala (LLM). Los avances recientes permiten que los detectores basados en LLM eludan el requisito de un análisis de seguridad profundo mediante la explotación de "atajos". En lugar de razonar sobre el diseño malicioso de forma aislada, estos modelos utilizan la Generación Aumentada por Recuperación (RAG) para obtener versiones originales y limpias del código de repositorios públicos, historiales de commits o Pull Requests. Al realizar un "diff" automatizado entre el código limpio recuperado y el objetivo con errores, los LLM pueden generar informes de vulnerabilidad de alta calidad con altas tasas de detección (75–83%) sin realizar un razonamiento de seguridad de hardware genuino. Esto socava la integridad educativa de las competiciones e invalida los benchmarks destinados a evaluar las capacidades de razonamiento de la IA.

Metodología
El artículo propone un enfoque de dos vertientes: la validación empírica de la hipótesis del "ataque por diff" y el desarrollo de un nuevo mecanismo de defensa.

1. Validación Empírica de los Atajos de los LLM:
   Los autores diseñaron cuatro detectores de vulnerabilidades basados en LLM progresivamente más sofisticados (D1–D4) para simular escenarios de ataque realistas:

• D1 (Con conocimiento de Diff): Recibe únicamente el diff unificado entre el código con errores y el código limpio.
• D2 (RAG con conocimiento de Repositorio): Recibe el código con errores y recupera el contexto relevante (código RTL) de un índice de repositorio.
• D3 (RAG con conocimiento de Historial): Extiende D2 recuperando el historial de desarrollo (Pull Requests, commits) para proporcionar contexto temporal.
• D4 (RAG con conocimiento de Debilidades): Aumenta D2 con conocimiento del dominio de seguridad de hardware de la base de datos de Clasificación de Debilidades Comunes (CWE).
  Estos detectores fueron probados en benchmarks de HackTheSilicon no ofuscados para establecer un rendimiento base.

2. El Marco de Ofuscación AttackonCTF:
   Para contrarrestar estos atajos, los autores introducen el primer marco de ofuscación orientado a LLM y preservador de la semántica, diseñado específicamente para benchmarks de seguridad de hardware. A diferencia de las herramientas tradicionales de ofuscación de hardware diseñadas para la protección de Propiedad Intelectual (IP) —que vuelven el código ilegible mediante un cifrado agresivo de identificadores y anonimización de disposición—, AttackonCTF prioriza la legibilidad humana y el valor educativo mientras interrumpe el emparejamiento sintáctico de los LLM.

El marco opera a través de un pipeline que involucra:

• Extracción de Restricciones: Definición de invariantes formales (p. ej., preservar interfaces de módulos, anchos de señal, comportamiento de reset y semántica de FSM) que el LLM debe respetar durante la reescritura.
• Selección de Intervalos (Span Selection): Identificación de regiones de código vulnerable para transformar, evitando áreas protegidas.
• Reescritura de Código: Utilización de un LLM para aplicar cinco estrategias de transformación específicas:
  1. Renombramiento de identificadores con alternativas semánticamente neutras.
  2. Reestructuración del flujo de control mediante expresiones equivalentes.
  3. Inyección de ruido en el diff: Introducción de modificaciones benignas para romper la similitud sintáctica con el diseño de referencia original.
  4. Dilución de contexto: Oscurecimiento o dispersión de pistas relevantes para la seguridad.
  5. Reescritura de lógica utilizando álgebra booleana y transformaciones temporales.
• Verificación: Un bucle riguroso utilizando Verilator para la comprobación de sintaxis y Yosys para la comprobación de equivalencia semántica formal (pruebas basadas en SAT) para asegurar la corrección funcional y la equivalencia semántica con el diseño original.

Contribuciones Clave

• Primera Demostración Empírica: El artículo proporciona evidencia de que la detección de vulnerabilidades basada en LLM en benchmarks de hardware depende fuertemente de la comparación sintáctica de diff y la recuperación de código original, logrando tasas de detección del 75–83% sin un razonamiento de seguridad genuino.
• Nuevo Marco de Ofuscación: El desarrollo del primer marco de ofuscación específico para LLM que preserva la legibilidad y emplea ruido de diff, dilución de contexto y desorientación semántica.
• Pipeline de Verificación Automatizado: Un sistema integrado que asegura que los diseños ofuscados sigan siendo semánticamente equivalentes y plenamente funcionales, aptos tanto para el análisis humano como para el entrenamiento de IA.
• Restauración de la Integridad de los Benchmarks: Un método para restaurar la validez de las competiciones de seguridad de hardware al prevenir la explotación automatizada de diff, manteniendo la capacidad de los participantes para aprender de los diseños.

Resultados
El marco fue evaluado en tres benchmarks de HackTheSilicon (Hack@DATE'25, Hack@DAC'25, Hack@CHES'25) basados en OpenTitan, que contienen 50 vulnerabilidades únicas en 27 categorías de CWE. Los detectores (D1 y D4) fueron probados contra niveles de ofuscación del 0%, 10%, 50% y 100%.

• Rendimiento Base: En los benchmarks no ofuscados, D1 logró una tasa de detección del 83.3% y D4 alcanzó el 77.1%.
• Impacto de la Ofuscación:
  • Al 10% de Ofuscación: La precisión de detección cayó significativamente entre un 48–55%, a pesar de una caída menor en la tasa de detección. Esto indica que incluso los cambios sintácticos menores interrumpen severamente la capacidad de los modelos para confiar en patrones basados en diff, causando un aumento en los falsos positivos.
  • Al 100% de Ofuscación: El marco redujo la precisión de detección de los LLM en un 78.6% (cayendo a ~15%) y redujo las tasas de detección aproximadamente un 50% (D1: 83.3% → 54.3%; D4: 77.1% → 48.9%).
• Legibilidad Humana: A diferencia de la ofuscación tradicional, los diseños resultantes siguieron siendo interpretables para los analistas humanos, preservando el valor educativo de los benchmarks.

Significancia
El artículo afirma que su trabajo aborda una brecha crítica en la investigación de seguridad de hardware: la validez de los benchmarks en la era de la IA avanzada. Al demostrar que la "detección" actual basada en LLM es a menudo un simple diff automatizado, los autores argumentan que las evaluaciones existentes pueden sobreestimar las capacidades de razonamiento de la IA. El marco AttackonCTF propuesto ofrece una solución práctica para restaurar la fiabilidad de los benchmarks. Permite a la comunidad seguir utilizando diseños de SoC de código abierto para formación y competición, asegurando al mismo tiempo que los altos indicadores de rendimiento reflejen un razonamiento de seguridad genuino en lugar de la explotación de correlaciones sintácticas con el código limpio conocido. Esto permite una evaluación más precisa de las capacidades tanto humanas como de la IA en el análisis de vulnerabilidades de hardware.