如何在Apache PDFBox中防止通用签名伪造(USF)、增量保存攻击(ISA)、签名包装(SWA)

Question

目前,Iam正在使用apache PDFBox创建一个数字和电子签名。最近，我了解到了数字签名和电子签名中的一些漏洞，如通用签名伪造(USF)、增量保存攻击(ISA)和签名包装(SWA)。PDFBox是否会自动处理这个问题，或者我们是否需要在代码中执行额外的操作来处理这个问题

Answer 1

首先,上述攻击是在2019年2月公开的一篇硕士论文（波鸿鲁尔大学Karsten Meyer zu Selhausen的“PDF签名的安全性”）中提出的。已于2018年11月与多个信息安全相关组织共享并讨论了派生的“漏洞报告”的预发布，因此在论文中同时测试的多个PDF签名验证器已被修复，以正确显示签名有效性违规或限制。您可以在PDF不安全网站上找到一个概述。

阅读这篇论文并检查示例，我得到的印象是，作者和他的顾问已经很久没有处理PDF了，至少没有深入处理。造成这种印象的两个例子：

>

本论文明确地基于2006年发布的PDF参考文献1.7,意识到PDF已于2008年成为ISO标准(ISO 32000-1）,并于2017年进行了更新(ISO 32000-2）。

结果是它的某些方面已经过时了。例如。

• 它将“对对象摘要的攻击”描述为未来工作的主题，但2008年的ISO 32000-1标准中还没有包含对象摘要，在本论文发表时，它们已经过时超过10年了。
• 此外，从论文中得到的“漏洞报告”包含了一个改进验证的建议，但是提到了一个缺点，即它需要修改PDF规范，该规范将ByteRange定义为可选参数...但从2008年开始，ISO 32000-1中就要求这样做了（至少对于这里所涉及的签名）！

这些操作（在美国空军攻击的背景下最为突出）是在没有充分尊重结果PDF的有效性的情况下进行的。

对于某些攻击场景，无效PDF是可以的，甚至可能是有效的，但在许多场景中，它们是不必要的，应该避免。

尽管如此，这些攻击还是很有趣的，特别是它们让我想知道那些对PDF有更深入了解的攻击者可能会设计出什么攻击。

OP是“使用apache PDFBox创建一个数字和电子签名”，关于上面的攻击，他想知道作为一个签名创建者可以做些什么来防止攻击。

不过，在一个方面，他可以提供帮助：签名包装攻击的某些变体在签名内容中使用了00字节的尾随字符串区域；所以他可以通过保持短的字符串来帮助防止一些攻击。不幸的是，在许多签名设置中，很难预测要在这里嵌入的签名容器的大小，因此很难避免一定数量的尾随00字节。

此外，您还可以使您的签名成为“不允许更改”的认证签名--以这种方式尊重认证级别的验证器可以更容易地识别并报告任何不允许的更改。但是，如果在长期验证扩展的上下文中使用，这可能会有点阻碍。

首先，PDFBox没有提供一个随时可用的实用工具来检查增量更新中所做的更改的种类。因此，除非您自己实现这一点，否则验证器只能对覆盖整个文档的签名说，他们对文件显示的内容进行签名。对于以前的签名，它只能说有关的签名签署了文件以前的一些修订，但不能说该修订是否与当前的修订一致。

对来自PDF安全站点（此处）的示例攻击文件运行PDFBox签名验证示例showsignature，会得到以下结果：

• 通常（大多数ISA，所有SWA文件）会看到“签名已验证”和“签名不覆盖整个文档”的输出。
• 在一个ISA案例中，存在NosuchAlgorithmException。
• 通常（大多数USF文件）有NullPointerException。
• 在一个USF案例中，存在ClassCastException。
• 在一个USF案例中，存在CMSException。

（SecurityThesisValidation测试的结果）

但是，请注意：如上所述，本文和示例文件显示了一些不足之处。因此，PDFBox有可能受到改进版本的攻击。特别是，签名包装方法看起来很有前途，因为PDFBox仅使用内容字符串，而不将其与字节范围间隙的内容进行比较。