2

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

4

1 回答 1

5

关于攻击本身

首先，提到的攻击是在 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 多年.
    • 此外，从论文中得出的“漏洞报告”包含一个改进验证的提案，但提到它需要更改将ByteRange定义为可选参数的 PDF 规范的缺点......但自 2008 年以来在 ISO 32000-1（至少在这里感兴趣的签名）！

  • 这些操作（主要是在 USF 攻击的背景下）是在没有充分尊重生成的 PDF 的有效性的情况下完成的。

    一个可见的效果是，例如，在 Adob​​e Reader 中打开测试 PDF 后，再次关闭它会导致查看器询问是否应该保存更改，即查看器必须应用对文件的修复以使其足够有效以供查看器正确显示。一方面，这种行为可以使用户对操纵保持警惕，另一方面，这些修复本身已经可以使签名无效，从而使可能好的攻击失败。

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

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

作为基于 PDFBox 的签名者防止即将发生的攻击

OP 正在“使用 apache pdfbox 创建数字和电子签名”，对于上述攻击，想知道他作为签名创建者可以做些什么来防止攻击。

实际上，签名创建者几乎无法防止攻击，主要是签名验证器的工作来识别操纵。

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

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

将攻击正确识别为基于 PDFBox 的验证器

首先，PDFBox 不提供随时可用的实用程序来检查增量更新中所做的更改类型。因此，除非您自己实现，否则您的验证者只能对覆盖整个文档的签名说他们签署文件显示的内容。对于以前的签名，它只能说各自的签名签署了文档的某个较早的修订版本，而不是该修订是否与当前修订相对应。

基于 PDFBox 的验证器（对修订比较没有很大的贡献）在其报告中的签名未涵盖整个文档必须表明这一事实并要求用户手动确定修订之间的更改。

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

  • 很多时候（大多数 ISA，所有 SWA 文件）都会看到“签名验证”的输出以及“签名不涵盖整个文档”。
  • 在一个 ISA 案例中，有一个NoSuchAlgorithmException.
  • 通常（大多数 USF 文件）有一个NullPointerException.
  • 在一个 USF 案例中，有一个ClassCastException.
  • 在一个 USF 案例中，有一个CMSException.

（SecurityThesisValidation测试的结果）

因此，只要基于 PDFBox 的验证器在适用的情况下正确输出“签名不覆盖整个文档”警告并在出现任意异常时输出“失败”或“未知”，它就不会成为当前攻击文件的牺牲品。

正如@Tilman 在对该问题的评论中所说，在加载 PDF 进行验证时停用宽松模式可能是一个好主意。在任何验证程序被愚弄之前，这将捕获大多数 ISA 和一些 USF 攻击......

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

于 2019-03-08T11:21:03.640 回答