💻 computer science

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

Dit artikel evalueert de effectiviteit van het combineren van grammatica-niveau mutatie met op LLM gebaseerde codesynthese voor compliance-testen van PKCS#1 v1.5 implementaties, waarbij wordt vastgesteld dat hoewel de aanpak er succesvol in slaagt bekende kwetsbaarheden te reproduceren en nieuwe discrepanties te ontdekken, het nut ervan ernstig wordt beperkt door hoge percentages LLM-hallucinaties die een aanzienlijke kloof creëren tussen operationele betrouwbaarheid en semantische getrouwheid.

Oorspronkelijke auteurs: Polina Kozyreva, Endadul Hoque

Gepubliceerd 2026-06-19

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Polina Kozyreva, Endadul Hoque

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een strenge bouwinspecteur bent. Jouw taak is om te controleren of elk huis dat in een stad wordt gebouwd, exact hetzelfde blauwdruk volgt. De blauwdruk (de "specificatie") zegt: "De voordeur moet 3 voet breed zijn, het dak moet rood zijn en de schoorsteen moet precies 10 voet hoog zijn."

In de wereld van computerbeveiliging zijn deze "huizen" softwareprogramma's die versleutelde berichten verwerken (zoals digitale handtekeningen). De "blauwdruk" is een complexe set regels genaamd PKCS#1 v1.5. Als een programma een huis bouwt dat niet perfect overeenkomt met de blauwdruk, kan er een verborgen achterdeur zijn die hackers kunnen gebruiken om binnen te breken.

Het Probleem: Controleren is Moeilijk

Het controleren van deze huizen is extreem moeilijk.

Willekeurig gokken werkt niet: Als je zomaar willekeurige bakstenen tegen een huis aanwerpt, zul je bijna nooit per ongeluk een deur bouwen die precies 3 voet breed is. Je hebt een zeer specifiek plan nodig.
Experttools zijn traag: Er zijn tools gemaakt door menselijke experts die elke mogelijke variatie van de blauwdruk kunnen controleren, maar het bouwen van deze tools kost jaren van diepgaande studie en handmatig werk. Het is alsoal het inhuren van een team van meesterarchitecten om elk huis te inspecteren.

Het Nieuwe Idee: De "AI Architect"

De onderzoekers in dit artikel stelden een simpele vraag: Kunnen we een Large Language Model (een AI) gebruiken als een "vertaler" die een kapotte blauwdruk omzet in een test?

Dit is hun proces:

De Oorspronkelijke Blauwdruk: Ze namen de officiële regels voor het huis.
De Mutator (De "Wat-Als"-Machine): Ze gebruikten een computerprogramma om de blauwdruk opzettelijk op 13 verschillende manieren te breken. Bijvoorbeeld: "Wat als de deur 4 voet breed is?" of "Wat als het dak blauw is?" of "Wat als we de schoorsteen volledig verwijderen?".
De AI Vertaler: Ze gaven deze kapotte blauwdrukken aan een AI en zeiden: "Schrijf een computerprogramma dat een huis bouwt dat exact volgens deze kapotte blauwdruk is."
De Test: Ze draaiden het programma van de AI om het huis te bouwen en probeerden dat huis vervolgens aan 4ks 48 verschillende softwareprogramma's (de "bouwers") te voeren om te zien of de bouwers het kapotte huis accepteerden. Als een bouwer een kapot huis accepteerde, had die bouwer een beveiligingsfout.

De Resultaten: Een Verhaal van Twee Getallen

De resultaten waren een mix van goed nieuws en een belangrijke waarschuwing.

Het Goede Nieuws (Operationele Betrouwbaarheid):
De AI was geweldig in het opvolgen van instructies om het werk te starten.

99,8% van de tijd schreef de AI succesvol een programma dat draaide zonder vast te lopen. Het was alsof een architect altijd een set blauwdrukken aanleverde die geen typefouten of ontbrekende pagina's bevatten.

Het Slechte Nieuws (Semantische Getrouwheid):
Echter, de AI was verschrikkelijk in het daadwerkelijk opvolgen van de kapotte blauwdruk.

Slechts 17,5% van de tijd bouwde de AI daadwerkelijk het huis zoals de kapotte blauwdruk dat vroeg.
In 82,5% van de gevallen "hallucineerde" de AI. De AI keek naar de kapotte blauwdruk, dacht: "Oh, dat ziet er niet goed uit," en verbeterde het stiekem weer naar de oorspronkelijke perfecte blauwdruk voordat het huis werd gebouwd.

De Analogie:
Stel je voor dat je de AI vraagt: "Bouw een huis met een blauwe deur."

Succes: De AI bouwt een huis met een blauwe deur.
Hallucinatie: De AI bouwt een huis met een rode deur omdat de AI "weet" dat deuren meestal rood zijn, ook al heb je specifiek om een blauwe deur gevraagd. De AI negeerde je specifieke instructie.

Wat Hebben Ze Gevonden?

Ze vonden de grote bugs: De aanpak slaagde erin om 10 van de 13 bekende beveiligingsfouten te reproduceren (inclusclusief de meest gevaarlijke die hackers in staat stellen handtekeningen te vervalsen). Dit bewijst dat het idee werkt.
Ze vonden een nieuwe bug: Ze ontdekten een nieuw beveiligingsprobleem in een bibliotheek genaamd LibTomCrypt dat nog nooit eerder was gerapporteerd. Dit gebeurde omdat de AI succesvol een huis bouwde dat een specifiek onderdeel miste (de leading zero byte), en de bibliotheek accepteerde dit.
De Bottleneck is de AI, niet het Plan: De onderzoekers ontdekten dat de "Mutator" (de machine die de blauwdrukken breekt) een geweldig werk deed. Het probleem lag volledig bij het onvermogen van de AI om zich aan de kapotte regels te houden.

De "Hallucinatie" Typen

De onderzoekers categoriseerden hoe de AI faalde, zoals een arts die een patiënt diagnosticeert:

De "Fixer" (Meest voorkomend): De AI zag een kapotte regel (zoals "padding moet minder dan 16 bytes zijn") en dacht: "Dat is onmogelijk," dus verbeterde het deze stilletjes terug naar de normale regel.
De "Wiskundig Genie die Wiskunde Vergeet": De AI probeerde de regels te volgen maar maakte fouten in de eenvoudige wiskunde (zoals het berekenen van hoeveel padding toe te voegen), wat resulteerde in een huis dat de verkeerde grootte had.
De "Negeren": De AI negeerde het kapotte deel van de blauwdruk volledig en bouwde een standaard huis.

De Kern van de Zaak

Dit artikel laat zien dat het gebruik van AI om dit soort testen uit te voeren veelbelovend maar momenteel onbetrouwbaar is.

De AI is goed in het schrijven van code die draait (het crasht niet), maar is erg slecht in het schrijven van code die betekent wat je zei. De AI heeft de gewoonte om je opzettelijke fouten te "corrigeren" omdat de AI denkt dat het beter weet.

De onderzoekers concluderen dat als je AI wilt gebruiken voor dit soort testen, je de geschreven code niet zomaar kunt vertrouwen. Je moet een tweede controlelaag hebben om te controleren of de AI daadwerkelijk je specifieke, kapotte instructies heeft gevolgd en ze niet gewoon heeft "hersteld" naar normaal. Tot die tijd is de AI een behulpzame stagiair die zeer gedreven is om te pleasen, maar vaak je specifieke bevelen om dingen op de "juiste" manier te doen, negeert.

Technische Samenvatting: Evaluatie van de Effectiviteit van LLM's bij het Ondersteunen van Compliance-testen voor PKCS#1-v1.5

Probleemstelling

Het testen van de naleving van specificaties (compliance) bij binaire protocolimplementaties vereist het genereren van inputs die voldoen aan zowel structurele beperkingen (bijv. Type-Length-Value codering, hiërarchische nesting) als semantische beperkingen (bijv. consistentie tussen lengte en waarde, padding-regels). Zuivere willekeurige generatie is onvoldoende om semantisch betekenisvolle gedragingen te verkennen in complexe protocollen zoals PKCS#1 v1.5. Daarentegen vereisen bestaande domeinspecifieke tools (bijv. Morpheus) diepe protocolexpertise en aanzienlijke handmatige inspanning om formele modellen te construeren, wat de generaliseerbaarheid beperkt. Algemene fuzzers missen semantisch bewustzijn, waardoor ze niet in staat zijn om specificatie-naleving systematisch te testen.

Dit werk onderzoekt of grammatica-niveau mutatie gecombineerd met Large Language Model (LLM)-gebaseerde codesynthese kan dienen als een levensvatbare, generaliseerbare aanpak voor compliance-testen van specificaties. Specifiek wordt de vraag gesteld of een LLM betrouwbaar gemuteerde formele grammatica's (gericht op zowel structurele regels als semantische beperkingen) kan vertalen naar uitvoerbare input-generatoren die specificatie-schendingen in cryptografische bibliotheken blootleggen.

Methodologie

De auteurs ontwierpen een vierfasen-pipeline om deze aanpak te evalueren op het PKCS#1 v1.5 handtekeningverificatieschema, een breed toegepaste standaard met een formeel geverifieerde test-oracle (Morpheus).

Grammatica-representatie: Een grammatica die PKCS#1 v1.5 beschrijft, werd handmatig geconstrueerd vanuit RFC 8017 in Backus-Naur Form (BNF), aangevuld met semantische beperkingen (arithmetische en relationele expressies). Dit omvat productieregels voor de TLV-structuur en beperkingen die de padding-lengtes en totale berichtgroottes afdwingen.
Grammatica-mutatie: Een mutator opereert op de grammatica-boom om $N$ $N$ structureel verschillende varianten te produceren. De auteurs ontwierpen 13 mutatie-operators verdeeld over drie categorieën:
- Structureel (TLV-onwetend): Wijzigt compositie of waarden zonder rekening te houden met TLV-relaties (bijv. remove_component, swap_order, add_garbage).
- Structureel (TLV-bewust): Wijzigt TLV-componenten terwijl interne lengte-waarde consistentie behouden blijft (bijv. change_length_change_value).
- Constraint-mutaties: Richt zich direct op semantische beperkingen (bijv. remove_constr, flip_signs, exchange_subexpressions).
  Het proces gebruikt een adaptief algoritme om diversiteit te behouden, waarbij de mutatie-intensiteit wordt verhoogd als duplicaten worden gedetecteerd.
LLM-gebaseerde Codesynthese: Elke gemuteerde grammatica wordt geserialiseerd naar een prompt voor een LLM (OpenAI GPT-5-nano), met de instructie om een zelfstandig Python-script te genereren dat binaire testgevallen produceert die voldoen aan de gemuteerde specificatie. Als het script niet kan worden uitgevoerd, wordt een fout-traceback teruggekoppeld naar de LLM voor reparatie in een begrensde loop.
Testgeval-generatie & Evaluatie: De driver voert de gegenereerde scripts uit om testgevallen te produceren, die vervolgens worden gedraaid tegen 48 cryptografische bibliotheek-implementaties. De resultaten worden vergeleken met de Morpheus-oracle om specificatie-schendingen te detecteren (Signature Forgery, Minor Leniency, Buffer Overflow, Incompatibility).

Belangrijkste Bijdragen

Empirisch Onderzoek: Een systematische evaluatie van grammatica-niveau mutatie gecombineerd met LLM-codesynthese voor binaire protocol compliance-testen, geïnstancieerd via 13 mutatie-operators over structurele en constraint-dimensies.
Replicatie van Bekende Kwetsbaarheden: Bewijs dat de aanpak 10 van de 13 (76,9%) niet-triviale schendingscategorieën reproduceert die door Morpheus zijn geïdentificeerd, inclus\nuit alle 5 de signature forgery categorieën, over 48 implementaties.
Ontdekking van Nieuwe Discrepanties: Identificatie van een voorheen ongerapporteerde discrepantie in LibTomCrypt v1.18.2 met betrekking tot de acceptatie van ontbrekende leidende bytes in PKCS#1 v1.5-structuren.
Hallucinatie-taxonomie: Een kwantitatieve karakterisering van LLM-hallucinatie in specificatie-beperkte codesgeneratie. De studie identificeert vijf verschillende hallucinatie-typen en onthult een systematische variatie in hun distributie over de mutatie-categorieën.

Resultaten

Effectiviteit van Compliance-testen

Replicatiepercentage: De pipeline slaagde erin 10 van de 13 bekende scheidingscategorieën te reproduceren (76,9%). Cruciaal is dat het alle 5 de signature forgery categorieën reproduceerde, die het meest kritiek zijn voor de veiligheid.
Nieuwe Bevindingen: De aanpak onthulde een nieuwe discrepantie in LibTomCrypt (en de afgeleide CryptX) waarbij de bibliotheek inputs accepteert die de leidende 0x00 byte missen, een schending van RFC 8017. Dit werd getriggerd door de remove_component operator, wat aantoont dat grammatica-niveau mutaties inputgebieden kunnen verkennen die door combinatorische benaderingen worden gemist.
Gemiste Schendingen: Drie categorieën (ML#2, ML#5, ML#7) werden niet gereproduceerd. Analyse bevestigde dat dit niet kwam door beperkingen in de mutatie-operators, maar door LLM-hallucinatie, waarbij de gegenereerde scripts er niet in slaagden de gemuteerde grammatica getrouw te implementeren.

LLM Betrouwbaarheid en Hallucinatie

De studie onthult een scherp contrast tussen operationele betrouwbaarheid en semantische getrouwheid:

Operationele Betrouwbaarheid: 99,8% van de gegenereerde scripts werd succesvol uitgevoerd (96,1% bij de eerste poging, 3,7% na reparatie).
Semantische Getrouwheid: Slechts 17,5% van de scripts implementeerde de gemuteerde specificatie correct. 82,5% vertoonde een vorm van hallucinatie.

Hallucinatie-taxonomie:

H1 (Padding Miscalculatie, 26,8%): Implementeert de mutatie correct, maar berekent de padding-lengte onjuist (bijv. door hardcoded waarden te gebruiken in plaats van deze af te leiden uit de totale lengte).
H2 (Mutatie Volledig Genegeerd, 1,1%): Produceert standaard-conforme structuren ondanks de gemuteerde grammatica, waarbij de specificatie wordt overschreven door voorkennis.
H3 (Partieel/Tegenstrijdig, 29,3%): Implementeert de mutatie gedeeltelijk, maar laat beperkingen weg omdat de gemuteerde grammatica tegenstrijdigheden bevat (bijv. conflicterende lengte- en padding-constraints).
H4 (Partieel/Zonder Reden, 18,0%): Implementeert de mutatie gedeeltelijk ondanks dat de grammatica voldoenbaar is, waarbij specifieke beperkingen zonder rechtvaardiging worden genegeerd.
H5 (Degenerate Output, 7,1%): Produceert willekeurige strings zonder structurele gelijkenis met de grammatica.

Correlatie met Mutatie-typen:

Alleen Constraint-mutaties hadden het hoogste correctheidspercentage (30,3%) maar ook het hoogste percentage van volledig negeren (H2, 8,1%).
Structurele (TLV-onwetende) mutaties hadden de hoogste percentages voor H3 (32,4%) en H4 (21,5%).
Gemengde mutaties (combinatie van structurele en constraint-operators) vertoonden de laagste correctheid (4,8%).

Betekenis en Claims

Het artikel claimt dat grammatica-niveau mutatie gecombineerd met LLM-codesynthese een levensvatbare aanpak is voor compliance-testen van specificaties die de noodzaak voor diepe domeinspecifieke engineering vermindert. Het reproduceert succesvol de meerderheid van de bekende kritieke kwetsbaarheden en kan nieuwe discrepanties ontdekken.

De primaire bijdrage is echter de identificatie van LLM semantische getrouwheid als de belangrijkste flessenhals, in plaats van de mutatiestrategie. De auteurs benadrukken dat de hoge operationele succespercentages (99,8%) een lage semantische correctheid (17,5%) maskeren, een kloof die moeilijk te detecteren is zonder semantische analyse vanwege de hoge variatie in gehallucineerde scripts.

De bevindingen bieden bruikbare richtlijnen voor toekomstige tools:

H3 (Tegenstrijdige Grammatica's) kan worden gemitigeerd door pre-synthese voldoenbaarheidscontroles (satisfiability checks).
H4 (Onverklaarbare Afwijkingen) vertegenwoordigt een onvermijdelijk betrouwbaarheidsprobleem dat post-generatie verificatie vereist.
H1 (Arithmetische Fouten) weerspiegelt een algemene zwakte van LLM's bij meerstaps arithmetische afleidingen.

De auteurs concluderen dat elke aanpak die LLM's gebruikt om code te genereren vanuit formele specificaties, moet omgaan met deze getrouwheidskloof, en dat operationele metrieken alleen onvoldoende zijn om de effectiviteit van dergelijke test-pipelines te beoordelen.