💻 computer science

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

本文评估了将语法级变异与基于大语言模型的代码合成相结合，用于 PKCS#1 v1.5 实现合规性测试的有效性，发现尽管该方法成功复现了已知漏洞并发现了新的差异，但其效用受到大语言模型高发生率幻觉的严重限制，从而在运行可靠性与语义保真度之间造成了显著差距。

原作者： Polina Kozyreva, Endadul Hoque

发布于 2026-06-19

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Polina Kozyreva, Endadul Hoque

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下你是一名严格的建筑检查员。你的工作是检查城市中建造的每一栋房子是否都完全遵循相同的蓝图。蓝图（即“规范”）规定：“前门必须是3英尺宽，屋顶必须是红色的，烟囱必须恰好10英尺高。”

在计算机安全的世界里，这些“房子”是处理加密消息（如数字签名）的软件程序。这些规则被称为 PKCS#1 v1.5。如果一个程序建造的房子与蓝图不完全匹配，它可能隐藏着黑客可以利用的后门，从而进行入侵。

问题所在：检查非常困难

检查这些房子极其困难：

随机猜测行不通： 如果你只是向房子投掷随机砖块，你几乎不可能偶然造出一个正好3英尺宽的门。你需要一个非常具体的计划。
专家工具很慢： 现有的由人类专家开发的工具可以检查蓝图的所有可能变体，但开发这些工具需要多年的深入研究和大量人工工作。这就像雇佣一个大师级建筑师团队来检查每一栋房子。

新的想法：“AI 建筑师”

研究人员提出了一个简单的问题：我们能否使用大语言模型（一种 AI）作为一个“翻译器”，将一份错误的蓝图转化为一个测试用例？

以下是他们的流程：

原始蓝图： 他们获取了房屋的官方规则。
变异器（“如果……会怎样”机器）： 他们使用一个计算机程序故意以 13 种不同的方式破坏蓝图。例如，他们可能会说：“如果门是4英尺宽会怎样？”或者“如果屋顶是蓝色的会怎样？”或者“如果我们完全移除烟囱会怎样？”
AI 翻译器： 他们将这些错误的蓝图交给 AI，并对它说：“编写一个计算机程序，按照这个错误的蓝图建造一座房子。”
测试： 他们运行 AI 的程序来建造这座房子，然后尝试将这座房子喂给 48 个不同的软件程序（即“建造者”），以观察这些建造者是否接受了这座错误的房子。如果一个建造者接受了一座错误的房子，则说明该建造者存在安全漏洞。

结果：两种数字的故事

好消息（运行可靠性）：
AI 在遵循指令以开始工作方面表现出色。

99.8% 的情况下，AI 成功编写了一个运行且没有崩溃的程序。它就像一位建筑师，总是能交给你一份没有错别字或缺失页面的蓝图。

坏消息（语义保真度）：
然而，AI 在实际遵循错误蓝图方面表现糟糕。

仅在 17.5% 的情况下，AI 真正按照错误的蓝图建造了房子。
在 82.5% 的案例中，AI 产生了“幻觉”。它看着错误的蓝图，心想：“噢，这看起来不对，”然后悄悄地将其修复回原始的完美蓝图，然后再进行建造。

类比：
想象你要求 AI：“建造一座带有蓝色门的房子。”

成功： AI 建造了一座带有蓝色门的房子。
幻觉： AI 建造了一座带有红色门的房子，因为它“知道”门通常是红色的，尽管你明确要求的是蓝色。它忽略了你的特定指令。

他们发现了什么？

他们发现了重大的漏洞： 该方法成功重现了 13 个已知安全漏洞中的 10 个（包括允许黑客伪造签名的最危险漏洞）。这证明了这个想法是行得通的。
他们发现了一个新漏洞： 他们在名为 LibTomCrypt 的库中发现了一个从未被报告过的新安全问题。这是因为 AI 成功建造了一座缺少特定部分（前导零字节）的房子，而该库接受了它。
瓶颈在于 AI，而非计划： 研究人员发现，“变异器”（破坏蓝图的机器）做得很好。问题完全在于 AI 无法坚持执行那些错误的规则。

“幻觉”的类型

研究人员对 AI 的失败进行了分类，就像医生诊断病人一样：

“修复者”（最常见）： AI 看到一条错误的规则（例如“填充长度必须小于 16 字节”）并认为“这不可能”，于是它默默地将其修复回正常规则。
“忘了数学的数学天才”： AI 试图遵循规则，但在简单的数学计算上出了错（例如计算应该添加多少填充），导致建出的房子尺寸不对。
“忽略”： AI 完全忽略了错误的规则部分，并建造了一座标准的房子。

总结

这篇论文表明，使用 AI 来辅助此类测试是有前景但目前不可靠的。

AI 非常擅长编写能够运行的代码（它不会崩溃），但它非常不擅长编写符合你原意的代码。它有一种习惯，会因为觉得自己比你更懂而“纠正”你的刻意错误。

研究人员得出结论：如果你想将 AI 用于这种类型的测试，你不能仅仅信任它编写的代码。你必须有一个第二层检查机制，以确保 AI 确实遵循了你特定的、错误的指令，而不是仅仅将其“修复”回正常状态。在此之前，AI 就像一个非常渴望表现、但经常忽略你“按正确方式做事”的具体命令的勤奋实习生。

技术摘要：评估大语言模型在辅助 PKCS#1-v1.5 合规性测试中的有效性

问题陈述

测试二进制协议实现的规范合规性需要生成同时满足结构约束（例如，类型-长度-值 [TLV] 编码、层级嵌套）和语义约束（例如，长度-值一致性、填充规则）的输入。对于像 PKCS#1 v1.5 这样复杂的协议，纯随机生成不足以探索具有语义意义的行为。相反，现有的领域特定工具（如 Morpheus）需要深厚的协议专业知识和大量的手动工作来构建形式化模型，这限制了其通用性。通用模糊测试工具缺乏语义感知能力，无法系统地测试规范合规性。

本研究调查了语法级变异结合基于大语言模型（LLM）的代码合成是否可以作为一种可行且通用的规范合规性测试方法。具体而言，研究探讨了 LLM 是否能够可靠地将变异后的形式化语法（针对结构规则和语义约束）转化为可执行的输入生成器，从而暴露加密库中的规范违规行为。

研究方法

作者设计了一个四阶段流水线，通过在 PKCS#1 v1.5 签名验证方案（一种具有形式化验证测试预言机 Morpheus 的广泛部署标准）上进行评估来验证该方法。

语法表示： 根据 RFC 8017 手动构建了描述 PKCS#1 v1.5 的语法，采用 Backus-Naur 范式（BNF），并增强了语义约束（算术和关系表达式）。这包括用于 TLV 结构的产生式规则，以及强制执行填充长度和总消息大小的约束。
语法变异： 变异器在语法树上运行以产生 $N$ $N$ 个结构迥异的变体。作者设计了 13 个跨越三个类别的变异算子：
- 结构型（忽略 TLV）： 修改组成或数值，而不考虑 TLV 之间的关系（例如，remove_component、swap_order、add_garbage）。
- 结构型（感知 TLV）： 修改 TLV 组件，同时保持内部长度-值的一致性（例如，change_length_change_value）。
- 约束变异： 直接针对语义约束进行操作（例如，remove_constr、flip_signs、exchange_subexpressions）。
  该过程使用自适应算法来维持多样性，如果检测到重复项，则增加变异强度。
基于 LLM 的代码合成： 每个变异后的语法被序列化为 LLM（OpenAI GPT-5-nano）的提示词，指令其生成一个独立的 Python 脚本，用于产生符合变异后规范的二进制测试用例。如果脚本执行失败，错误回溯将被反馈给 LLM 进行修复，并在有界循环中进行。
测试用例生成与评估： 驱动程序执行生成的脚本以产生测试用例，并将其运行在 48 个加密库实现上。结果与 Morpheus 预言机进行对比，以检测规范违规情况（签名伪造、轻微宽容、缓冲区溢出、不兼容性）。

核心贡献

实证研究： 对结合了语法级变异和 LLM 代码合成的二进制协议合规性测试进行了系统性评估，通过跨结构和约束维度的 13 个变异算子进行了实例化。
复现已知漏洞： 证据表明，该方法成功复现了 Morpheus 识别出的 13 类已知违规中的 10 类（76.9%）非平凡类别，其中包括全部 5 类签名伪造类别，涵盖 48 个实现。
发现新差异： 发现了 LibTomCrypt v1.18.2 中一个此前未见报道的差异，即该库接受缺失前导字节的 PKCS#1 v1.5 结构。
幻觉分类学： 对受限规范代码生成中的 LLM 幻觉进行了定量特征化。研究识别了五种不同的幻觉类型，并揭示了它们在不同变异类别中分布的系统性变化。

结果

合规性测试有效性

复现率： 流水线成功复现了 10/13（76.9%）个已知违规类别。至关重要的是，它复现了所有 5 类签名伪造类别，这些是安全性最关键的类别。
新发现： 该方法发现了 LibTomCrypt（及其衍生版本 CryptX）中的一个新差异，即该库接受缺失前导 0x00 字节的输入，这违反了 RFC 8017。这是由 remove_component 算子触发的，证明了语法级变异可以探索组合方法所遗漏的输入区域。
遗漏的违规： 有三个违规类别（ML#2, ML#5, ML#7）未被复现。分析确认，这并非由于变异算子的局限性，而是由 LLM 幻觉引起的，即生成的脚本未能忠实地实现变异后的语法。

LLM 可靠性与幻觉

研究揭示了操作可靠性与语义保真度之间显著的差距：

操作可靠性： 99.8% 的生成脚本执行成功（96.1% 在首次尝试时成功，3.7% 在修复后成功）。
语义保真度： 仅 17.5% 的脚本正确实现了变异后的规范。82.5% 的脚本表现出某种形式的幻觉。

幻觉分类学：

H1（填充计算错误，26.8%）： 正确实现了变异，但计算填充长度错误（例如，使用硬编码值而非从总长度中推导）。
H2（完全忽略变异，1.1%）： 尽管存在变异后的语法，仍生成符合标准的结构，用先验知识覆盖了规范。
H3（部分/矛盾，29.3%）： 部分实现了变异，但由于变异后的语法包含矛盾（例如，冲突的长度和填充约束），导致丢弃了约束。
H4（部分/无原因，18.0%）： 尽管语法是可满足的，但仍部分实现了变异，在没有理由的情况下忽略了特定约束。
H5（退化输出，7.1%）： 生成的字符串与语法没有结构上的相似性。

与变异类型的相关性：

仅约束变异 的正确率最高（30.3%），但被完全忽略（H2, 8.1%）的比例也最高。
结构型（忽略 TLV）变异 的 H3（32.4%）和 H4（21.5%）发生率最高。
混合变异（结合结构和约束算子）表现出最低的正确率（4.8%）。

意义与主张

本文声称，语法级变异结合 LLM 代码合成是一种可行的方法，用于进行规范合规性测试，并降低了对深度领域特定工程的需求。它成功复现了大多数关键已知漏洞，并能发现新的差异。

然而，主要贡献在于识别出 LLM 语义保真度是主要的瓶颈，而非变异策略本身。作者强调，99.8% 的高操作成功率掩盖了 17.5% 的低语义正确率，由于幻觉脚本具有高度的输出变异性，如果不进行语义分析，这种差距很难被检测到。

研究结果为未来的工具提供了可操作的指导：

H3（矛盾语法） 可以通过合成前的可满足性检查来缓解。
H4（无解释偏差） 代表了一种不可还原的可靠性问题，需要生成后的验证。
H1（算术错误） 反映了 LLM 在多步算术推导方面的普遍弱点。

作者总结道，任何使用 LLM 从形式化规范生成代码的方法，都必须应对这种保真度差距，且仅凭操作指标不足以评估此类测试流水线的有效性。