💻 computer science

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

Questo articolo valuta l'efficacia della combinazione tra mutazione a livello di grammatica e sintesi del codice basata su LLM per il testing di conformità delle implementazioni PKCS#1 v1.5, riscontrando che, sebbene l'approccio riproduca con successo vulnerabilità note e scopra nuove discrepanze, la sua utilità è severamente limitata da alti tassi di allucinazione degli LLM che creano un divario significativo tra affidabilità operativa e fedeltà semantica.

Autori originali: Polina Kozyreva, Endadul Hoque

Pubblicato 2026-06-19

📖 5 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Polina Kozyreva, Endadul Hoque

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immagina di essere un rigoroso ispettore edilizio. Il tuo compito è controllare se ogni casa costruita in una città segue esattamente lo stesso progetto. Il progetto (la "specifica") dice: "La porta d'ingresso deve essere larga 3 piedi, il tetto deve essere rosso e il camino deve essere alto esattamente 10 piedi".

Nel mondo della sicurezza informatica, queste "case" sono programmi software che gestiscono messaggi criptati (come le firme digitali). Il "progetto" è un insieme complesso di regole chiamato PKCS#1 v1.5. Se un programma costruisce una casa che non corrisponde perfettamente al progetto, potrebbe avere una porta sul retro nascosta che gli hacker possono usare per entrare.

Il Problema: Controllare è Difficile

Controllare queste case è incredibilmente difficile.

Indovinare a caso non funziona: Se lanci semplicemente dei mattoni casuali contro una casa, non costruirai quasi mai accidentalmente una porta larga esattamente 3 piedi. Hai bisogno di un piano molto specifico.
Gli strumenti degli esperti sono lenti: Esistono strumenti creati da esperti umani che possono controllare ogni possibile variazione del progetto, ma costruire questi strumenti richiede anni di studio approfondito e lavoro manuale. È come assumere un team di maestri architetti per ispezionare ogni singola casa.

La Nuova Idea: L' "Architetto AI"

I ricercatori in questo articolo si sono posti una domanda semplice: Possiamo usare un Large Language Model (un'IA) per agire come un "traduttore" che trasforma un progetto rotto in un test?

Ecco il loro processo:

Il Progetto Originale: Hanno preso le regole ufficiali per la casa.
Il Mutatore (la macchina del "E se...?"): Hanno usato un programma per computer per rompere intenzionalmente il progetto in 13 modi diversi. Ad esempio, potrebbero dire: "E se la porta fosse larga 4 piedi?" oppure "E se il tetto fosse blu?" o "E se rimuovessimo completamente il camino?".
L'IA Traduttrice: Hanno consegnato questi progetti rotti all'IA e le hanno detto: "Scrivi un programma per computer che costruisca una casa esattamente secondo questo progetto rotto".
Il Test: Hanno eseguito il programma dell'IA per costruire la casa e poi hanno cercato di sottoporre quella casa a 48 diversi programmi software (i "costruttori") per vedere se i costruttori accettavano la casa rotta. Se un costruttore accettava una casa rotta, quel costruttore aveva un difetto di sicurezza.

I Risultati: Una Storia di Due Numeri

I risultati sono stati un misto di ottime notizie e un grande avvertimento.

Le Buone Notizie (Affidabilità Operativa):
L'IA è stata incredibile nel seguire le istruzioni per iniziare il lavoro.

Il 99,8% delle volte, l'IA ha scritto con successo un programma che è stato in grado di girare senza crashare. Era come un architetto che riesce sempre a consegnarti dei progetti che non hanno refusi o pagine mancanti.

Le Cattive Notizie (Fedeltà Semantica):
Tuttavia, l'IA è stata terribile nel seguire effettivamente il progetto rotto.

Solo il 17,5% delle volte l'IA ha costruito la casa seguendo il modo in cui il progetto rotto richiedeva.
Nell'82,5% dei casi, l'IA ha "allucinato". Ha guardato il progetto rotto, ha pensato: "Oh, questo sembra sbagliato", e ha segretamente corretto il progetto riportandolo al progetto originale perfetto prima di costruire la casa.

L'Analogia:
Immagina di chiedere all'IA: "Costruisci una casa con una porta blu".

Successo: L'IA costruisce una casa con una porta blu.
Allucinazione: L'IA costruisce una casa con una porta rossa perché "sa" che le porte sono solitamente rosse, anche se avevi chiesto specificamente una porta blu. Ha ignorato la tua istruzione specifica.

Cosa hanno scoperto?

Hanno trovato i bug importanti: L'approccio ha ricreato con successo 10 dei 13 noti difetti di sicurezza (inclusi i più pericolosi che permettono agli hacker di falsificare le firme). Questo dimostra che l'idea funziona.
Hanno trovato un nuovo bug: Hanno scoperto un nuovo problema di sicurezza in una libreria chiamata LibTomCrypt che nessuno aveva mai segnalato prima. Ciò è accaduto perché l'IA ha costruito con successo una casa mancante di una parte specifica (lo zero iniziale/leading zero byte), e la libreria l'ha accettata.
Il collo di bottiglia è l'IA, non il piano: I ricercatori hanno scoperto che il "Mutatore" (la macchina che rompe i progetti) stava facendo un ottimo lavoro. Il problema era interamente l'incapacità dell'IA di attenersi ai progetti rotti.

I Tipi di "Allucinazione"

I ricercatori hanno categorizzato come l'IA è fallita, come un medico che diagnostica un paziente:

Il "Correttore" (Il più comune): L'IA ha visto una regola errata (come "il padding deve essere meno di 16 byte") e ha pensato: "Questo è impossibile", quindi l'ha corretta silenziosamente riportandola alla regola normale.
Il "Genio della Matematica che ha dimenticato la matematica": L'IA ha cercato di seguire le regole ma ha sbagliato la matematica semplice (come calcolare quanto padding aggiungere), risultando in una casa della dimensione errata.
L' "Ignora": L'IA ha completamente ignorato la parte rotta del progetto e ha costruito una casa standard.

Il Punto Fondamentale

Questo articolo dimostra che usare l'IA per aiutare a testare la sicurezza informatica è promettente ma attualmente inaffidabile.

L'IA è brava a scrivere codice che gira (non va in crash), ma è molto scarsa nello scrivere codice che significa ciò che hai detto. Ha l'abitudine di "correggere" i tuoi errori intenzionali perché pensa di sapere meglio di te.

I ricercatori concludono che, se vuoi usare l'IA per questo tipo di test, non puoi semplicemente fidarti del codice che scrive. Devi avere un secondo livello di controllo per assicurarti che l'IA abbia effettivamente seguito le tue specifiche istruzioni rotte e non le abbia solo "corrette" riportandole alla normalità. Finché non accadrà, l'IA è come un tirocinante molto volenteroso che però spesso ignora i tuoi ordini specifici di fare le cose nel modo "giusto".

Riepilogo Tecnico: Valutazione dell'Efficacia degli LLM nel Supporto al Testing di Conformità di PKCS#1-v1.5

Definizione del Problema

Il testing della conformità alle specifiche per le implementazioni di protocolli binari richiede la generazione di input che soddisfino sia i vincoli strutturali (ad esempio, codifica Type-Length-Value, annidamento gerarchico) sia i vincoli semantici (ad esempio, coerenza tra lunghezza e valore, regole di padding). La generazione puramente casuale è insufficiente per esplorare comportamenti semanticamente significativi in protocolli complessi come PKCS#1 v1.5. Al contrario, gli strumenti esistenti specifici per il dominio (ad esempio, Morpheus) richiedono una profonda competenza nel protocollo e un significativo sforzo manuale per costruire modelli formali, limitandone la generalizzabilità. I fuzzer general-purpose mancano di consapevolezza semantica, rendendoli incapaci di testare sistematicamente la conformità alle specifiche.

Questo lavoro investiga se la mutazione a livello di grammatica combinata con la sintesi di codice basata su Large Language Model (LLM) possa servire come un approccio praticabile e generalizzabile al testing di conformità alle specifiche. Nello specifico, si chiede se un LLM possa tradurre in modo affidabile grammatiche formali mutate (mirando sia alle regole strutturali che ai vincoli semantici) in generatori di input eseguibili che espongano violazioni delle specifiche in librerie crittografiche.

Metodologia

Gli autori hanno progettato una pipeline a quattro stadi per valutare questo approccio sul protocollo di verifica della firma PKCS#1 v1.5, uno standard ampiamente distribuito con un oracle di testing formalmente verificato (Morpheus).

Rappresentazione della Grammatica: Una grammatica che descrive PKCS#1 v1.5 è stata costruita manualmente da RFC 8017 in Backus-Naur Form (BNF), aumentata con vincoli semantici (espressioni aritmetiche e relazionali). Questa include regole di produzione per la struttura TLV e vincoli che impongono lunghezze di padding e dimensioni totali del messaggio.
Mutazione della Grammatica: Un mutatore opera sull'albero della grammatica per produrre $N$ $N$ varianti strutturalmente distinte. Gli autori hanno progettato 13 operatori di mutazione suddivisi in tre categorie:
- Strutturale (Ignorante rispetto a TLV): Modifica la composizione o i valori senza considerare le relazioni TLV (ad esempio, remove_component, swap_order, add_garbage).
- Strutturale (Consapevole di TLV): Modifica i componenti TLV preservando la coerenza interna tra lunghezza e valore (ad esempio, change_length_change_value).
- Mutazioni di Vincolo: Mira direttamente ai vincoli semantici (ad esempio, remove_constr, flip_signs, exchange_subexpressions).
  Il processo utilizza un algoritmo adattivo per mantenere la diversità, aumentando l'intensità della mutazione in caso di rilevamento di duplicati.
Sintesi di Codice Basata su LLM: Ogni grammatica mutata viene serializzata in un prompt per un LLM (OpenAI GPT-5-nano), istruendolo a generare uno script Python autonomo che produca casi di test binari conformi alla specifica mutata. Se lo script fallisce l'esecuzione, un traceback di errore viene fornito all'LLM per la riparazione in un ciclo limitato.
Generazione dei Casi di Test e Valutazione: Il driver esegue gli script generati per produrre casi di test, che vengono poi eseguiti contro 48 implementazioni di librerie crittografiche. I risultati sono confrontati con l'oracle Morpheus per rilevare violazioni delle specifiche (Signature Forgery, Minor Leniency, Buffer Overflow, Incompatibility).

Contributi Chiave

Indagine Empirica: Una valutazione sistematica della mutazione a livello di grammatica combinata con la sintesi di codice tramite LLM per il testing di conformità di protocolli binari, istanziata attraverso 13 operatori di mutazione attraverso dimensioni strutturali e di vincolo.
Riproduzione di Vulnerabilità Note: Evidenza che l'approccio riproduce 10 delle 13 (76,9%) categorie di violazione non banali identificate da Morpheus, incluse tutte le 5 categorie di signature forgery, su 48 implementazioni.
Scoperta di Nuove Discrepanze: Identificazione di una discrepanza precedentemente non riportata in LibTomCrypt v1.18.2 riguardante l'accettazione di byte iniziali mancanti nelle strutture PKCS#1 v1.5.
Tassonomia delle Allucinazioni: Una caratterizzazione quantitativa delle allucinazioni degli LLM nella generazione di codice vincolato dalle specifiche. Lo studio identifica cinque tipi distinti di allucinazione e rivela una variazione sistematica nella loro distribuzione tra le categorie di mutazione.

Risultati

Efficacia del Testing di Conformità

Tasso di Riproduzione: La pipeline ha riprodotto con successo 10 delle 13 categorie di violazione note (76,9%). Fondamentalmente, ha riprodotto tutte le 5 categorie di signature forgery, che sono le più critiche dal punto di vista della sicurezza.
Nuove Scoperte: L'approccio ha scoperto una nuova discrepanza in LibTomCrypt (e il suo derivato CryptX) dove la libreria accetta input privi del byte iniziale 0x00, una violazione di RFC 8017. Questo è stato innescato dall'operatore remove_component, dimostrando che le mutazioni a livello di grammatica possono esplorare regioni di input trascurate dagli approcci combinatori.
Violazioni Mancate: Tre categorie di violazione (ML#2, ML#5, ML#7) non sono state riprodotte. L'analisi ha confermato che queste non erano dovute a limitazioni degli operatori di mutazione, ma erano causate dall'allucinazione dell'LLM, dove gli script generati non implementavano fedelmente la grammatica mutata.

Affidabilità dell'LLM e Allucinazioni

Lo studio rivela un divario sorprendente tra affidabilità operativa e fedeltà semantica:

Affidabilità Operativa: Il 99,8% degli script generati è stato eseguito con successo (96,1% al primo tentativo, 3,7% dopo riparazione).
Fedeltà Semantica: Solo il 17,5% degli script ha implementato correttamente la specifica mutata. L'82,5% presentava una qualche forma di allucinazione.

Tassonomia delle Allucinazioni:

H1 (Errore di Calcolo del Padding, 26,8%): Implementa correttamente la mutazione ma calcola in modo errato la lunghezza del padding (ad esempio, usando valori hardcoded invece di derivarli dalla lunghezza totale).
H2 (Mutazione Completamente Ignorata, 1,1%): Produce strutture conformi allo standard nonostante la grammatica mutata, sovrascrivendo la specifica con la conoscenza pregressa.
H3 (Parziale/Contraddittoria, 29,3%): Implementa parzialmente la mutazione ma scarta i vincoli perché la grammatica mutata contiene contraddizioni (ad esempio, conflitti tra vincoli di lunghezza e padding).
H4 (Parziale/Senza Motivo, 18,0%): Implementa parzialmente la mutazione nonostante la grammatica sia soddisfacibile, ignorando specifici vincoli senza giustificazione.
H5 (Output Degenerato, 7,1%): Produce stringhe casuali senza alcuna somiglianza strutturale con la grammatica.

Correlazione con i Tipi di Mutazione:

Le mutazioni di solo vincolo avevano il tasso di correttezza più alto (30,3%) ma anche il tasso più alto di essere completamente ignorate (H2, 8,1%).
Le mutazioni strutturali (ignoranti rispetto a TLV) avevano i tassi più alti di H3 (32,4%) e H4 (21,5%).
Le mutazioni miste (che combinano operatori strutturali e di vincolo) hanno mostrato la correttezza più bassa (4,8%).

Significato e Rivendicazioni

Il documento sostiene che la mutazione a livello di grammatica combinata con la sintesi di codice tramite LLM sia un approccio praticabile per il testing di conformità alle specifiche che riduce la necessità di un profondo ingegnerismo specifico per il dominio. Ha riprodotto con successo la maggior parte delle vulnerabilità critiche note e può scoprire nuove discrepanze.

Tuttamente, il contributo primario è l'identificazione della fedeltà semantica dell'LLM come il principale collo di bottiglia, piuttosto che la strategia di mutazione. Gli autori sottolineano che l'alto tasso di successo operativo (99,8%) maschera una bassa correttezza semantica (17,5%), un divario difficile da rilevare senza analisi semantica a causa dell'elevata variazione dell'output negli script allucinati.

Le scoperte forniscono indicazioni pratiche per gli strumenti futuri:

H3 (Grammatiche Contraddittorie) può essere mitigata tramite controlli di soddisfacibilità pre-sintesi.
H4 (Deviazioni Non Spiegate) rappresenta un problema di affidabilità irreducibile che richiede una verifica post-generazione.
H1 (Errori Aritmetici) riflette una debolezza generale degli LLM riguardo alla derivazione aritmetica multi-step.

Gli autori concludono che qualsiasi approccio che utilizzi gli LLM per generare codice da specifiche formali deve confrontarsi con questo divario di fedeltà, e che le metriche operative da sole sono insufficienti per valutare l'efficacia di tali pipeline di testing.