Vim*_*ran 2 security electronic-signature digital-signature protect-from-forgery pdfbox
目前我正在使用 apache pdfbox 创建数字和电子签名。最近我开始了解数字和电子签名中的漏洞，如通用签名伪造 (USF)、增量保存攻击 (ISA) 和签名包装 (SWA)。PDFBox 是自动处理这个问题还是我们需要在代码中额外执行来处理这个问题
首先，提到的攻击是在 2019 年 2 月公开发布的硕士论文（“PDF 签名的安全性”，作者是波鸿鲁尔大学的 Karsten Meyer zu Selhausen）中提出的。 衍生的“漏洞报告”的预发布”已于 2018 年 11 月与多个信息安全相关组织共享和讨论，因此同时修复了论文中测试的多个 PDF 签名验证器，以正确显示签名有效性违规或限制。您可以在 PDF 不安全站点上找到概述。
阅读论文并检查示例，我的印象是作者和他的顾问还没有很长时间处理 PDF，至少没有深入处理。造成这种印象的两个例子：
该论文明确基于 2006 年发布的 PDF 参考 1.7，它知道 PDF 已于 2008 年成为 ISO 标准（ISO 32000-1），同时在 2017 年已更新（ISO 32000-2）。
结果是其中的某些方面已经过时了。例如
操作（最重要的是在 USF 攻击的背景下）是在没有充分尊重生成的 PDF 的有效性的情况下完成的。
一个明显的效果是，例如，在 Adobe Reader 中打开测试 PDF 后，再次关闭它会导致查看者询问是否应该保存更改，即查看者必须对文件进行修复以使其足够有效以供查看者使用正确显示它。一方面，这种行为会使用户对操作保持警惕，另一方面，这些修复本身可能已经使签名无效，从而使可能好的攻击失败。
对于某些攻击场景，无效的 PDF 是可以的，甚至可能是有效的，但在许多场景中它们是不必要的，应该避免。
尽管如此，这些攻击还是很有趣，特别是它们让我想知道那些对 PDF 有更深入了解的攻击者可能会设计出什么攻击......
OP 正在“使用 apache pdfbox 创建数字和电子签名”，对于上述攻击，他想知道作为签名创建者的他可以做些什么来防止攻击。
实际上，签名创建者几乎无法防止攻击，主要是签名验证器的工作是识别操作。
不过，在一方面，他可以提供帮助：签名包装攻击的一些变体使用签名内容中尾随字符串 00 字节的区域；所以他可以通过保持字符串尽可能短来帮助防止一些攻击。不幸的是，有许多签名设置，其中很难预测要嵌入此处的签名容器的大小，因此几乎无法避免一定数量的尾随 00 字节。
此外，您可以使用“不允许更改”来制作您的签名认证签名 - 以这种方式尊重认证级别的验证器可以更轻松地识别和报告任何不允许的更改。但是，如果在长期验证扩展的上下文中使用，这可能会有点障碍。
首先，PDFBox 不提供检查增量更新中所做更改类型的即用型实用程序。因此，除非您自己实施，否则您的验证者只能说他们签署了整个文件的签名。对于以前的签名，它只能说相应的签名签署了文档的某个较早的修订版，而不是该修订版是否与当前修订版相对应。
基于 PDFBox 的验证器（没有大量自己的修订比较贡献）在其签名报告中未涵盖整个文档必须指出这一事实，并要求用户手动确定修订之间的更改。
ShowSignature针对来自 PDF 安全站点（此处）的示例攻击文件运行 PDFBox 签名验证示例，得到以下结果：
NoSuchAlgorithmException.NullPointerException.ClassCastException.CMSException.（SecurityThesisValidation测试的结果）
因此，只要基于 PDFBox 的验证器在适用的情况下正确输出“签名不覆盖整个文档”警告并在任意异常的情况下输出“失败”或“未知”，它就不会成为当前攻击文件的牺牲品。
正如@Tilman 在对该问题的评论中所说的那样，在加载 PDF 进行验证时停用宽松模式可能是一个好主意。在任何验证例程可能被愚弄之前，这将捕获大多数 ISA 和一些 USF 攻击......
但请注意：如上所述，论文和示例文件存在一些缺陷。因此，PDFBox 有可能受到改进版本的攻击。特别是签名包装方法看起来很有希望，因为 PDFBox仅使用内容字符串，而不将其与字节范围间隙的内容进行比较。
| 归档时间： |
|
| 查看次数： |
406 次 |
| 最近记录： |