💻 computer science

Evaluating the Effectiveness of LLMs in Aiding Compliance Testing of PKCS#1-v1.5

Este artículo evalúa la efectividad de combinar la mutación a nivel de gramática con la síntesis de código basada en LLM para las pruebas de cumplimiento de implementaciones de PKCS#1 v1.5, encontrando que, si bien el enfoque reproduce con éxito vulnerabilidades conocidas y descubre nuevas discrepancias, su utilidad se ve severamente limitada por altas tasas de alucinación de los LLM que crean una brecha significativa entre la fiabilidad operativa y la fidelidad semántica.

Autores originales: Polina Kozyreva, Endadul Hoque

Publicado 2026-06-19

📖 5 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Polina Kozyreva, Endadul Hoque

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que eres un inspector de edificios estricto. Tu trabajo es comprobar si cada casa construida en una ciudad sigue exactamente el mismo plano. El plano (la "especificación") dice: "La puerta principal debe tener 3 pies de ancho, el techo debe ser rojo y la chimenea debe medir exactamente 10 pies de altura".

En el mundo de la seguridad informática, estas "casas" son programas de software que gestionan mensajes cifrados (como firmas digitales). El "plano" es un conjunto complejo de reglas llamado PKCS#1 v1.5. Si un programa construye una casa que no coincide perfectamente con el plano, podría tener una puerta trasera oculta que los hackers podrían usar para entrar.

El Problema: Comprobar es Difícil

Comprobar estas casas es increíblemente difícil.

Adivinar al azar no funciona: Si simplemente lanzas ladrillos al azar contra una casa, casi nunca construirás por accidente una puerta que mida exactamente 3 pies de ancho. Necesitas un plan muy específico.
Las herramientas de los expertos son lentas: Existen herramientas creadas por expertos humanos que pueden comprobar todas las variaciones posibles del plano, pero construir estas herramientas requiere años de estudio profundo y trabajo manual. Son como contratar a un equipo de maestros arquitectos para inspeccionar cada una de las casas.

La Nueva Idea: El "Arquitecto de IA"

Los investigadores en este artículo se hicieron una pregunta sencilla: ¿Podemos usar un Modelo de Lenguaje Extenso (una IA) para actuar como un "traductor" que convierta un plano roto en una prueba?

Aquí está su proceso:

El Plano Original: Tomaron las reglas oficiales para la casa.
El Mutador (La Máquina del "¿Qué pasaría si?"): Utilizaron un programa informático para romper intencionadamente el plano de 13 formas diferentes. Por ejemplo, podrían decir: "¿Qué pasaría si la puerta mide 4 pies de ancho?" o "¿Qué pasaría si el techo es azul?" o "¿Qué pasaría si eliminamos la chimenea por completo?".
El Traductor de IA: Entregaron estos planos rotos a una IA y le dijeron: "Escribe un programa informático que construya una casa exactamente de acuerdo con este plano roto".
La Prueba: Ejecutaron el programa de la IA para construir la casa y luego intentaron alimentar esa casa a 48 programas de software diferentes (los "constructores") para ver si los constructores aceptaban la casa rota. Si un constructor aceptaba una casa rota, ese constructor tenía un fallo de seguridad.

Los Resultados: Una Historia de Dos Números

Los resultados fueron una mezcla de excelentes noticias y una gran advertencia.

Las Buenas Noticias (Fiabilidad Operativa):
La IA fue increíble siguiendo instrucciones para comenzar el trabajo.

El 99.8% de las veces, la IA escribió con éxito un programa que se ejecutó sin fallos. Era como un arquitecto que siempre lograba entregarte un conjunto de planos que no tenían erratas ni páginas faltantes.

Las Malas Noticias (Fidelidad Semántica):
Sin embargo, la IA fue terrible siguiendo realmente el plano roto.

Solo el 17.5% de las veces la IA construyó la casa tal como el plano roto lo pedía.
En el 82.5% de los casos, la IA "alucinó". Miró el plano roto, pensó: "Oh, esto parece estar mal", y secretamente lo corrigió de nuevo al plano perfecto original antes de construir la casa.

La Analogía:
Imagina que le pides a la IA: "Construye una casa con una puerta azul".

Éxito: La IA construye una casa con una puerta azul.
Alucinación: La IA construye una casa con una puerta roja porque "sabe" que las puertas suelen ser rojas, aunque le pediste específicamente una azul. Ignoró tu instrucción específica.

¿Qué Encontraron?

Encontraron los errores grandes: El enfoque recreó con éxito 10 de los 13 fallos de seguridad conocidos (incluyendo los más peligrosos que permiten a los hackers falsificar firmas). Esto demuestra que la idea funciona.
Encontraron un error nuevo: Descubrieron un nuevo problema de seguridad en una librería llamada LibTomCrypt que nadie había reportado antes. Esto sucedió porque la IA construyó con éxito una casa a la que le faltaba una parte específica (el byte cero inicial), y la librería la aceptó.
El cuello de botella es la IA, no el Plan: Los investigadores descubrieron que el "Mutador" (la máquina que rompe los planos) estaba haciendo un gran trabajo. El problema radicaba enteramente en la incapacidad de la IA para ceñirse a las reglas rotas.

Los Tipos de "Alucinación"

Los investigadores categorizaron cómo falló la IA, como un médico diagnosticando a un paciente:

El "Corregidor" (Lo más común): La IA vio una regla rota (como "el relleno debe ser de menos de 16 bytes") y pensó: "Eso es imposible", así que lo corrigió silenciosamente de vuelta a la regla normal.
El "Genio de las Matemáticas que Olvidó las Matemáticas": La IA intentó seguir las reglas pero arruinó la matemática simple (como calcular cuánto relleno añadir), lo que resultó en una casa del tamaño equivocado.
El "Ignorar": La IA ignoró por completo la parte rota del plano y construyó una casa estándar.

La Conclusión Final

Este artículo muestra que usar IA para ayudar en este tipo de pruebas es prometedor pero actualmente poco fiable.

La IA es buena escribiendo código que se ejecuta (no falla), pero es muy mala escribiendo código que significa lo que dijiste. Tiene el hábito de "corregir" tus errores intencionales porque cree que sabe mejor.

Los investigadores concluyen que si quieres usar la IA para este tipo de pruebas, no puedes confiar simplemente en el código que escribe. Tienes que tener una segunda capa de comprobación para asegurarte de que la IA realmente siguió tus instrucciones específicas y rotas, y no solo las "corrigió" para que volvieran a la normalidad. Hasta entonces, la IA es un pasante útil que tiene muchas ganas de complacer, pero que a menudo ignora tus órdenes específicas de hacer las cosas de la "manera correcta".

Resumen Técnico: Evaluación de la Efectividad de los LLM en el Apoyo al Pruebas de Cumplimiento de PKCS#1-v1.5

Declaración del Problema

Probar la implementación de protocolos binarios para el cumplimiento de las especificaciones requiere generar entradas que satisfagan tanto las restricciones estructurales (por ejemplo, codificación Tipo-Longitud-Valor, anidamiento jerárquico) como las restricciones semánticas (por ejemplo, consistencia entre longitud y valor, reglas de relleno). La generación puramente aleatoria es insuficiente para explorar comportamientos semánticamente significativos en protocolos complejos como PKCS#1 v1.5. Por el contrario, las herramientas existentes específicas de dominio (por ejemplo, Morpheus) requieren una profunda experiencia en el protocolo y un esfuerzo manual significativo para construir modelos formales, lo que limita su generalizabilidad. Los fuzzers de propósito general carecen de conciencia semántica, lo que les impide probar sistemáticamente el cumplimiento de las especificaciones.

Este trabajo investiga si la mutación a nivel de gramática combinada con la síntesis de código basada en Modelos de Lenguaje de Gran Escala (LLM) puede servir como un enfoque viable y generalizable para las pruebas de cumplimiento de especificaciones. Específicamente, plantea si un LLM puede traducir de manera confiable gramáticas mutadas (apuntando tanto a reglas estructurales como a restricciones semánticas) en generadores de entrada ejecutables que expongan violaciones de especificación en librerías criptográficas.

Metodología

Los autores diseñaron un pipeline de cuatro etapas para evaluar este enfoque en el esquema de verificación de firmas PKCS#1 v1.5, un estándar ampliamente desplegado con un oráculo de prueba formalmente verificado (Morpheus).

Representación de la Gramática: Se construyó manualmente una gramática que describe PKCS#1 v1.5 a partir de RFC 8017 en Forma de Backus-Naur (BNF), aumentada con restricciones semánticas (expresiones aritméticas y relacionales). Esto incluye reglas de producción para la estructura TLV y restricciones que imponen longitudes de relleno y tamaños totales de mensaje.
Mutación de la Gramática: Un mutador opera sobre el árbol de la gramática para producir $N$ $N$ variantes estructuralmente distintas. Los autores diseñaron 13 operadores de mutación a través de tres categorías:
- Estructural (Ignorante de TLV): Modifica la composición o los valores sin considerar las relaciones TLV (por ejemplo, remove_component, swap_order, add_garbage).
- Estructural (Consciente de TLV): Modifica los componentes TLV preservando la consistencia interna de longitud-valor (por ejemplo, change_length_change_value).
- Mutaciones de Restricción: Apunta directamente a las restricciones semánticas (por ejemplo, remove_constr, flip_signs, exchange_subexpressions).
  El proceso utiliza un algoritmo adaptativo para mantener la diversidad, aumentando la intensidad de la mutación si se detectan duplicados.
Síntesis de Código Basada en LLM: Cada gramática mutada se serializa en un prompt para un LLM (OpenAI GPT-5-nano), instruyéndolo para generar un script de Python independiente que produzca casos de prueba binarios que cumplan con la especificación mutada. Si el script falla al ejecutarse, un traceback de error se retroalimenta al LLM para su reparación en un bucle acotado.
Generación de Casos de Prueba y Evaluación: El driver ejecuta los scripts generados para producir casos de prueba, que se ejecutan contra 48 implementaciones de librerías criptográficas. Los resultados se comparan contra el oráculo Morpheus para detectar violaciones de especificación (Falsificación de Firma, Leniencia Menor, Desbordamiento de Búfer, Incompatibilidad).

Principales Contribuciones

Investigación Empírica: Una evaluación sistemática de la mutación a nivel de gramática combinada con la síntesis de código por LLM para las pruebas de cumplimiento de protocolos binarios, instanciada a través de 13 operadores de mutación en dimensiones estructurales y de restricción.
Reproducción de Vulnerabilidades Conocidas: Evidencia de que el enfoque reproduce 10 de 13 (76.9%) categorías de violación no triviales identificadas por Morpheus, incluyendo todas las 5 categorías de falsificación de firma, a través de 48 implementaciones.
Descubrimiento de Nuevas Discrepancias: Identificación de una discrepancia previamente no reportada en LibTomCrypt v1.18.2 respecto a la aceptación de bytes iniciales faltantes en estructuras PKCS#1 v1.5.
Taxonomía de Alucinaciones: Una caracterización cuantitativa de la alucinación de los LLM en la generación de código con restricciones de especificación. El estudio identifica cinco tipos distintos de alucinación y revela una variación sistemática en su distribución a través de las categorías de mutación.

Resultados

Efectividad de las Pruebas de Cumplimiento

Tasa de Reproducción: El pipeline reprodujo exitosamente 10 de las 13 categorías de violación conocidas (76.9%). Crucialmente, reprodujo todas las 5 categorías de falsificación de firma, que son las más críticas para la seguridad.
Nuevos Hallazgos: El enfoque descubrió una nueva discrepancia en LibTomCrypt (y su derivado CryptX) donde la librería aceptaba entradas que carecían del byte inicial 0x00, una violación de RFC 8017. Esto fue activado por el operador remove_component, demostrando que las mutaciones a nivel de gramática pueden explorar regiones de entrada omitidas por enfoques combinatorios.
Violaciones Perdidas: Tres categorías de violación (ML#2, ML#5, ML#7) no fueron reproducidas. El análisis confirmó que esto no se debió a limitaciones en los operadores de mutación, sino que fue causado por la alucinación del LLM, donde los scripts generados fallaron en implementar fielmente la gramática mutada.

Confiabilidad del LLM y Alucinación

El estudio revela una brecha sorprendente entre la confiabilidad operativa y la fidelidad semántica:

Confiabilidad Operativa: El 99.8% de los scripts generados se ejecutaron con éxito (96.1% en el primer intento, 3.7% tras la reparación).
Fidelidad Semántica: Solo el 17.5% de los scripts implementaron correctamente la especificación mutada. El 82.5% exhibió alguna forma de alucinación.

Taxonomía de Alucinaciones:

H1 (Error de Cálculo de Relleno, 26.8%): Implementa correctamente la mutación pero calcula incorrectamente la longitud del relleno (por ejemplo, usando valores hardcoded en lugar de derivarlos de la longitud total).
H2 (Mutación Completamente Ignorada, 1.1%): Produce estructuras que cumplen con el estándar a pesar de la gramática mutada, sobreescribiendo la especificación con conocimiento previo.
H3 (Parcial/Contradictoria, 29.3%): Implementa parcialmente la mutación pero descarta restricciones porque la gramática mutada contiene contradicciones (por ejemplo, conflictos entre la restricción de longitud y de relleno).
H4 (Parcial/Sin Razón, 18.0%): Implementa parcialmente la mutación a pesar de que la gramática es satisfactoria, ignorando restricciones específicas sin justificación.
H5 (Salida Degenerada, 7.1%): Produce cadenas aleatorias sin semejanza estructural con la gramática.

Correlación con Tipos de Mutación:

Las mutaciones solo de restricción tuvieron la tasa de corrección más alta (30.3%) pero también la tasa más alta de ser totalmente ignoradas (H2, 8.1%).
Las mutaciones estructurales (ignorantes de TLV) tuvieron las tasas más altas de H3 (32.4%) y H4 (21.5%).
Las mutaciones mixtas (combinando operadores estructurales y de restricción) mostraron la menor corrección (4.8%).

Significado y Reivindicaciones

El artículo afirma que la mutación a nivel de gramática combinada con la síntesis de código por LLM es un enfoque viable para las pruebas de cumplimiento de especificaciones que reduce la necesidad de una profunda ingeniería específica de dominio. Logra reproducir la mayoría de las vulnerabilidades críticas conocidas y puede descubrir nuevas discrepancias.

Sin embargo, la contribución principal es la identificación de la fidelidad semántica del LLM como el cuello de botella principal, más que la estrategia de mutación. Los autores enfatizan que el alto éxito operativo (99.8%) enmascara una baja corrección semántica (17.5%), una brecha que es difícil de detectar sin un análisis semántico debido a la alta variación en los scripts alucinados.

Los hallazgos proporcionan orientación accionable para futuras herramientas:

H3 (Gramáticas Contradictorias) puede mitigarse mediante verificaciones de satisfacción previas a la síntesis.
H4 (Desviaciones Inexplicables) representa un problema de confiabilidad irreducible que requiere verificación post-generación.
H1 (Errores Aritméticos) refleja una debilidad general de los LLM respecto a la derivación aritmética de múltiples pasos.

Los autores concluyen que cualquier enfoque que utilice LLM para generar código a partir de especificaciones formales debe lidiar con esta brecha de fidelidad, y que las métricas operativas por sí solas son insuficientes para evaluar la efectividad de tales pipelines de prueba.