💻 computer science

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

Este artigo avalia a eficácia da combinação de mutação em nível de gramática com síntese de código baseada em LLM para testes de conformidade de implementações PKCS#1 v1.5, constatando que, embora a abordagem reproduza com sucesso vulnerabilidades conhecidas e descubra novas discrepâncias, sua utilidade é severamente limitada por altas taxas de alucinação de LLM que criam uma lacuna significativa entre a confiabilidade operacional e a fidelidade semântica.

Autores originais: Polina Kozyreva, Endadul Hoque

Publicado 2026-06-19

📖 5 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Polina Kozyreva, Endadul Hoque

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine que você é um inspetor de obras rigoroso. Seu trabalho é verificar se cada casa construída em uma cidade segue exatamente o mesmo projeto. O projeto (a "especificação") diz: "A porta da frente deve ter 3 pés de largura, o telhado deve ser vermelho e a chaminé deve ter exatamente 10 pés de altura."

No mundo da segurança de computadores, essas "casas" são programas de software que lidam com mensagens criptografadas (como assinaturas digitais). O "projeto" é um conjunto complexo de regras chamado PKCS#1 v1.5. Se um programa constrói uma casa que não corresponde ao projeto perfeitamente, pode haver uma porta dos fundos oculta que hackers podem usar para invadir.

O Problema: Verificar é Difícil

Verificar essas casas é incrivelmente difícil.

Adivinhação aleatória não funciona: Se você apenas jogar tijolos aleatórios em uma casa, quase nunca construirá acidentalmente uma porta que tenha exatamente 3 pés de largura. Você precisa de um plano muito específico.
Ferramentas de especialistas são lentas: Existem ferramentas feitas por especialistas humanos que podem verificar todas as variações possíveis do projeto, mas construir essas ferramentas leva anos de estudo profundo e trabalho manual. É como contratar uma equipe de mestres arquitetos para inspecionar cada casa.

A Nova Ideia: O "Arquiteto de IA"

Os pesquisadores fizeram uma pergunta simples: Podemos usar um Modelo de Linguagem Grande (um modelo de IA) para atuar como um "tradutor" que transforma um projeto quebrado em um teste?

Aqui está o processo deles:

O Projeto Original: Eles pegaram as regras oficiais para a casa.
O Mutador (A Máquina do "E se?"): Eles usaram um programa de computador para quebrar propositalmente o projeto de 13 maneiras diferentes. Por exemplo, eles podem dizer: "E se a porta tiver 4 pés de largura?" ou "E se o telhado for azul?" ou "E se removermos a chaminé inteira?"
O Tradutor de IA: Eles entregaram esses projetos quebrados à IA e disseram: "Escreva um programa de computador que construa uma casa exatamente de acordo com este projeto quebrado."
O Teste: Eles rodaram o programa da IA para construir a casa e então tentaram fornecer essa casa para 48 programas de software diferentes (os "construtores") para ver se os construtores aceitavam a casa quebrada. Se um construtor aceitasse uma casa quebrada, esse construtor tinha uma falha de segurança.

Os Resultados: Um Conto de Dois Números

Os resultados foram uma mistura de ótimas notícias e um grande aviso.

As Boas Notícias (Confiabilidade Operacional):
A IA foi incrível em seguir instruções para iniciar o trabalho.

99,8% das vezes, a IA conseguiu escrever um programa que rodou sem travar. Foi como um arquiteto que sempre conseguiu entregar um conjunto de projetos que não tinham erros de digitação ou páginas faltando.

As Más Notícias (Fidelidade Semântica):
No entanto, a IA foi terrível em realmente seguir o projeto quebrado.

Apenas 17,5% das vezes a IA realmente construiu a casa da maneira que o projeto quebrado solicitou.
Em 82,5% dos casos, a IA "alucinou". Ela olhou para o projeto quebrado, pensou: "Ah, isso parece errado", e secretamente o corrigiu de volta para o projeto perfeito original antes de construir a casa.

A Analogia:
Imagine que você peça à IA: "Construa uma casa com uma porta azul."

Sucesso: A IA constró o uma casa com uma porta azul.
Alucinação: A IA constrói uma casa com uma porta vermelha porque ela "sabe" que portas costumam ser vermelhas, embora você tenha pedido especificamente uma azul. Ela ignorou sua instrução específica.

O Que Eles Descobriram?

Eles encontraram os grandes bugs: A abordagem conseguiu recriar 10 de 13 falhas de segurança conhecidas (incluindo as mais perigosas que permitem que hackers forjem assinaturas). Isso prova que a ideia funciona.
Eles encontraram um novo bug: Eles descobriram um novo problema de segurança em uma biblioteca chamada LibTomCrypt que ninguém havia relatado antes. Isso aconteceu porque a IA construiu com sucesso uma casa faltando uma parte específica (o byte zero à esquerda) e a biblioteca aceitou isso.
O Gargalo é a IA, não o Plano: Os pesquisadores descobriram que o "Mutador" (a máquina que quebra os projetos) estava fazendo um ótimo trabalho. O problema era inteiramente a incapacidade da IA de aderir aos projetos quebrados.

Os Tipos de "Alucinação"

Os pesquisadores categorizaram como a IA falhou, como um médico diagnosticando um paciente:

O "Consertador" (Mais Comum): A IA viu uma regra quebrada (como "o preenchimento deve ter menos de 16 bytes") e pensou: "Isso é impossível", então ela silenciosamente corrigiu de volta para a regra normal.
O "Gênio da Matemática que Esqueceu a Matemática": A IA tentou seguir as regras, mas errou a matemática simples (como calcular quanto preenchimento adicionar), resultando em uma casa do tamanho errado.
O "Ignorar": A IA ignorou completamente a parte quebrada do projeto e construiu uma casa padrão.

A Conclusão

Este artigo mostra que usar IA para ajudar a testar a segurança de computadores é promissor, mas atualmente pouco confiável.

A IA é ótima em escrever códigos que rodam (não travam), mas é muito ruim em escrever códigos que significam o que você disse. Ela tem o hábito de "corrigir" seus erros intencionais porque acha que sabe melhor.

Os pesquisadores concluem que, se você quiser usar IA para esse tipo de teste, não pode apenas confiar no código que ela escreve. Você deve ter uma segunda camada de verificação para garantir que a IA realmente seguiu suas instruções específicas e quebradas e não apenas as "consertou" de volta ao normal. Até lá, a IA é um estagiário prestativo que é muito ansioso para agradar, mas frequentemente ignora suas ordens específicas de fazer as coisas do jeito "certo".

Resumo Técnico: Avaliando a Eficácia de LLMs no Auxílio ao Teste de Conformidade de PKCS#1-v1.5

Declaração do Problema

Testar implementações de protocolos binários para conformidade com especificações requer a geração de entradas que satisfaçam tanto restrições estruturais (ex: codificação Type-Length-Value, aninhamento hierárquico) quanto restrições semânticas (ex: consistência entre comprimento e valor, regras de preenchimento/padding). A geração puramente aleatória é insuficiente para explorar comportamentos semanticamente significativos em protocolos complexos como o PKCS#1 v1.5. Por outro outro lado, ferramentas existentes específicas para o domínio (ex: Morpheus) exigem profundo conhecimento do protocolo e um esforço manual significativo para construir modelos formais, limitando sua generalização. Fuzzers de uso geral carecem de consciência semântica, tornando-os incapazes de testar sistematicamente a conformidade com a especificação.

Este trabalho investiga se a mutação ao nível da gramática combinada com a síntese de código baseada em Large Language Models (LLM) pode servir como uma abordagem viável e generalizável para o teste de conformidade de especificações. Especificamente, questiona-se se um LLM pode traduzir de forma confiável gramáticas formais mutadas (visando tanto regras estruturais quanto restrições semânticas) em geradores de entrada executáveis que exponham violações de especificação em bibliotecas criptográficas.

Metodologia

Os autores projetaram um pipeline de quatro estágios para avaliar esta abordagem no esquema de verificação de assinatura PKCS#1 v1.5, um padrão amplamente implantado com um oráculo de teste formalmente verificado (Morpheus).

Representação da Gramática: Uma gramática descrevendo o PKCS#1 v1.5 foi construída manualmente a partir da RFC 8017 em Backus-Naur Form (BNF), aumentada com restrições semânticas (expressões aritméticas e relacionais). Isso inclui regras de produção para a estrutura TLV e restrições que impõem comprimentos de preenchimento e tamanhos totais de mensagem.
Mutação da Gramática: Um mutador opera sobre a árvore da gramática para produzir $N$ $N$ variantes estruturalmente distintas. Os autores projetaram 13 operadores de mutação em três categorias:
- Estrutural (Ignorante de TLV): Modifica composição ou valores sem considerar as relações TLV (ex: remove_component, swap_order, add_garbage).
- Estrutural (Consciente de TLV): Modifica componentes TLV enquanto preserva a consistência interna entre comprimento e valor (ex: change_length_change_value).
- Mutações de Restrição: Visa diretamente as restrições semânticas (ex: remove_constr, flip_signs, exchange_subexpressions).
  O processo utiliza um algoritmo adaptativo para manter a diversidade, aumentando a intensidade da mutação se duplicatas forem detectadas.
Síntese de Código Baseada em LLM: Cada gramática mutada é serializada em um prompt para um LLM (OpenAI GPT-5-nano), instruindo-o a gerar um script Python independente que produza casos de teste binários em conformidade com a especificação mutada. Se o script falhar na execução, um traceback de erro é enviado de volta ao LLM para reparo em um loop limitado.
Geração de Casos de Teste e Avaliação: O driver executa os scripts gerados para produzir casos de teste, que são rodados contra 48 implementações de bibliotecas criptográficas. Os resultados são comparados com o oráculo Morpheus para detectar violações de especificação (Falsificação de Assinatura, Leniência Menor, Buffer Overflow, Incompatibilidade).

Principais Contribuições

Investigação Empírica: Uma avaliação sistemática da mutação ao nível da gramática combinada com a síntese de código por LLM para teste de conformidade de protocolos binários, instanciada através de 13 operadores de mutação através das dimensões estrutural e de restrição.
Reprodução de Vulnerabilidades Conhecidas: Evidência de que a abordagem reproduz 10 de 13 (76,9%) categorias de violação não triviais identificadas pelo Morpheus, incluindo todas as 5 categorias de falsificação de assinatura, através de 48 implementações.
Descoberta de Novas Discrepâncias: Identificação de uma discrepância anteriormente não relatada na LibTomCrypt v1.18.2 em relação à aceitação de bytes iniciais ausentes em estruturas PKCS#1 v1.5.
Taxonomia de Alucinação: Uma caracterização quantitativa da alucinação de LLM na geração de código com restrição de especificação. O estudo identifica cinco tipos distintos de alucinação e revela uma variação sistemática em sua distribuição entre as categorias de mutação.

Resultados

Eficácia do Teste de Conformidade

Taxa de Reprodução: O pipeline reproduziu com sucesso 10 de 13 categorias de violação conhecidas (76,9%). Crucialmente, reproduziu todas as 5 categorias de falsificação de assinatura, que são as mais críticas em termos de segurança.
Novas Descobertas: A abordagem descobriu uma nova discrepância na LibTomCrypt (e seu derivado CryptX) onde a biblioteca aceita entradas faltando o byte inicial 0x00, uma violação da RFC 8017. Isso foi desencadeado pelo operador remove_component, demonstrando que mutações ao nível da gramática podem explorar regiões de entrada perdidas por abordagens combinatórias.
Violações Perdidas: Três categorias de violação (ML#2, ML#5, ML#7) não foram reproduzidas. A análise confirmou que estas não se devem a limitações nos operadores de mutação, mas foram causadas por alucinação do LLM, onde os scripts gerados falharam em implementar fielmente a gramática mutada.

Confiabilidade do LLM e Alucinação

O estudo revela uma lacuna marcante entre confiabilidade operacional e fidelidade semântica:

Confiabilidade Operacional: 99,8% dos scripts gerados executaram com sucesso (96,1% na primeira tentativa, 3,7% após reparo).
Fidelidade Semântica: Apenas 17,5% dos scripts implementaram corretamente a especificação mutada. 82,5% exibiram algum tipo de alucinação.

Taxonomia de Alucinação:

H1 (Erro de Cálculo de Padding, 26,8%): Implementa corretamente a mutação, mas calcula incorretamente o comprimento do preenchimento (ex: usando valores fixos em vez de derivá-lo do comprimento total).
H2 (Mutação Totalmente Ignorada, 1,1%): Produz estruturas padrão conforme a especificação, apesar da gramática mutada, sobrepondo o conhecimento prévio à especificação.
H3 (Parcial/Contraditória, 29,3%): Implementa parcialmente a mutação, mas descarta restrições porque a gramática mutada contém contradições (ex: conflito entre restrições de comprimento e preenchimento).
H4 (Parcial/Sem Motivo, 18,0%): Implementa parcialmente a mutação apesar de a gramática ser satisfatível, ignorando restrições específicas sem justificativa.
H5 (Saída Degenerada, 7,1%): Produz strings aleatórias sem semelhança estrutural com a gramática.

Correlação com Tipos de Mutação:

Mutações apenas de restrição tiveram a maior taxa de correção (30,3%), mas também a maior taxa de serem totalmente ignoradas (H2, 8,1%).
Mutações estruturais (ignorantes de TLV) tiveram as maiores taxas de H3 (32,4%) e H4 (21,5%).
Mutações mistas (combinando operadores estruturais e de restrição) mostraram a menor correção (4,8%).

Significância e Alegações

O artigo afirma que a mutação ao nível da gramática combinada com a síntese de código por LLM é uma abordagem viável para o teste de conformidade de especificações que reduz a necessidade de engenharia profunda específica do domínio. Ela reproduz com sucesso a maioria das vulnerabilidades críticas conhecidas e pode descobrir novas discrepâncias.

No entanto, a principal contribuição é a identificação da fidelidade semântica do LLM como o principal gargalo, e não a estratégia de mutação. Os autores enfatizam que altas taxas de sucesso operacional (99,8%) mascaram a baixa correção semântica (17,5%), uma lacuna difícil de detectar sem análise semântica devido à alta variação nos scripts alucinados.

As descobertas fornecem orientações acionáveis para ferramentas futuras:

H3 (Gramáticas Contraditórias) pode ser mitigada por verificações de satisfatibilidade pré-síntese.
H4 (Desvios Não Explicados) representa um problema de confiabilidade irredutível que requer verificação pós-geração.
H1 (Erros Aritméticos) reflete uma fraqueza geral dos LLMs em relação à derivação aritmética de múltiplos passos.

Os autores concluem que qualquer abordagem que utilize LLMs para gerar código a partir de especificações formais deve lidar com essa lacuna de fidelidade, e que métricas operacionais sozinhas são insuficientes para avaliar a eficácia de tais pipelines de teste.