如何在Apache PDFBox中防止通用签名伪造(USF)，增量保存攻击(ISA)，签名包装(SWA) [英] How can i prevent Universal Signature Forgery (USF) , Incremental Saving Attack (ISA), Signature Wrapping (SWA) in Apache PDFBox

问题描述

目前，Iam使用apache pdfbox创建数字和电子签名. 最近，我开始了解数字签名和电子签名中的漏洞，例如通用签名伪造(USF)，增量保存攻击(ISA)和签名包装(SWA). PDFBox是自动执行此操作还是我们需要在代码中额外强制执行此操作

Currently Iam creating a digital and electronic signature using apache pdfbox. Recently i came to know the vulnerabilities in digital and electronic signature like Universal Signature Forgery (USF), Incremental Saving Attack (ISA) and Signature Wrapping (SWA). Does PDFBox takes this care automatically or do we need to enforce additionally in code to take care of this

推荐答案

关于攻击本身

首先，提到的攻击已在一篇硕士论文中提出((位于波鸿鲁尔大学的Karsten Meyer zu Selhausen)，于2019年2月公开发行.派生的漏洞报告" 已于2018年11月与许多信息安全相关组织共享和讨论，因此，本文中测试的许多PDF签名验证器已经修复，可以正确显示出签名有效性违规或限制.您可以在 PDF不安全网站上找到概述.

On the attacks themselves

To start with, the attacks mentioned have been developed in a master thesis ("Security of PDF Signatures" by Karsten Meyer zu Selhausen at the Ruhr-Universität Bochum) publicly made available in February 2019. A pre-release of the derived "Vulnerability Report" has been shared and discussed with a number of information security related organizations in November 2018, so a number of the PDF signature validators tested in the paper meanwhile have been fixed to properly show a signature validity violation or restriction. You can find an overview on the PDF insecurity site.

阅读论文并检查示例后，我感到作者和他的顾问们尚未处理PDF已有很长时间，至少没有深入.造成这种印象的两个示例:

Reading the thesis and inspecting the examples I got the impression that the author and his advisers have not yet dealt with PDFs for very long, at least not in depth. Two examples of what caused this impression:

• 本文明确基于2006年发布的PDF Reference 1.7，它意识到PDF已在2008年成为ISO标准(ISO 32000-1)，而在2017年又进行了更新(ISO 32000 -2).

• The thesis explicitly is based upon the PDF Reference 1.7, published 2006, it is aware of PDF having become an ISO standard in 2008 (ISO 32000-1) which meanwhile, in 2017, has been updated (ISO 32000-2).

结果是其中的某些方面已经过时.例如

The effect is that certain aspects in it simply are outdated. E.g.

• 它被描述为未来工作的主题对对象摘要的攻击"，但是对象摘要在2008年没有包含在ISO 32000-1标准中，在发布之时它们已经废弃了10多年了论文的内容.
• 此外，从本文得出的漏洞报告"包含一项改进验证的建议，但提到它的缺点，即需要更改PDF规范，该规范将 ByteRange 定义为可选参数 ...，但是自2008年以来，ISO 32000-1才要求使用此参数(至少对于此处感兴趣的签名)！

进行这些操作(主要是在USF攻击的背景下)，而没有充分考虑所得PDF的有效性.

The manipulations (foremost in the context of the USF attacks) were done without adequate respect for the validity of the resulting PDFs.

可见效果例如在Adobe Reader中打开测试PDF之后，再次关闭它会导致查看者询问是否应保存更改，即，修复了查看者必须使用的文件以使其对文件足够有效查看器以正确显示它.一方面，这种行为可能使用户对操作持谨慎态度；另一方面，这些修复本身已经使签名失效，从而可能使良好的攻击失败.

A visible effect is e.g. that after opening the test PDFs in Adobe Reader, closing it again causes the viewer to ask whether it should save the changes, i.e. the repairs to the file the viewer had to apply to make it valid enough for the viewer to display it properly. On one hand this behavior can make a user wary of manipulations, and on the other hand these repairs by themselves can already invalidate a signature making a probably good attack fail.

对于某些攻击情形，无效的PDF可以使用，甚至可以发挥作用，但是在许多情况下，它们是不必要的，应避免使用.

For some attack scenarios invalid PDFs are ok, maybe even productive, but in many scenarios they are unnecessary and should be avoided.

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

Nonetheless the attacks are interesting, in particular they make me wonder what attacks might be devised by attackers who do have a more in-depth knowledge of PDFs...

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

The OP is "creating a digital and electronic signature using apache pdfbox" and in respect to the attacks above wonders what he as a signature creator can do to prevent attacks.

实际上，签名创建者没有什么能阻止攻击的发生，这主要是签名验证器的工作来识别操作.

There actually is little the signature creator can do to prevent the attacks, it mostly is the job of the signature validator to recognize manipulations.

尽管如此，他可以提供帮助:签名包装攻击的某些变体使用了签名内容中00字节的尾随字符串区域；因此他可以通过使字符串尽可能短来帮助防止某些攻击.不幸的是，有许多签名设置，其中几乎无法预测要在此处嵌入的签名容器的大小，因此很难避免一定数量的尾随00字节.

In one way, though, he can help: Some variants of the signature wrapping attack use the area of the trailing string of 00 bytes in the signature content; so he can help prevent some attacks by keeping that string as short as possible. Unfortunately there are numerous signing setups in which one can hardly predict the size of the signature container to embed here, so a certain number of trailing 00 bytes can hardly be avoided.

此外，您还可以在不允许更改"的情况下进行签名认证签名-通过这种方式更轻松地遵守认证级别的验证程序，可以识别并报告任何不允许的更改.但是，如果在长期验证"扩展的上下文中使用的话，这可能是一个障碍.

Additionally you can make your signatures certification signatures with "no changes allowed" - validators which respect the certification level this way more easily can recognize and report any changes as disallowed. This might be a bit of a hindrance, though, if used in the context of Long Term Validation extensions.

首先，PDFBox不提供可检查增量更新中所做更改种类的即用型实用程序.因此，除非您自己实现，否则验证者只能对覆盖整个文档的签名说，它们对文件显示的内容进行签名.对于以前的签名，只能说相应的签名对文档的某个较早修订版进行了签名，但无论如何该修订版是否都与当前修订版相对应.

First of all, PDFBox does not provide a ready-to-use utility that checks the kind of changes made in an incremental update. Unless you implement that yourself, therefore, your validator can say only for signatures covering the whole document that they sign what the file shows. For previous signatures it can merely say that the respective signature signed some earlier revision of the document but not whether or not that revision corresponds to the current revision anyhow.

在其报告中基于PDFBox的验证器(没有很大的自己用于版本比较的签名)不包含整个文档的签名，必须指明这一事实，并要求用户手动确定版本之间的更改.

A PDFBox based validator (without a large own contribution for revision comparison) in its report for a signature not covering the whole document must indicate this fact and ask the user to determine the changes between revisions manually.

针对PDF安全站点中的示例攻击文件运行PDFBox签名验证示例ShowSignature(

Running the PDFBox signature validation example ShowSignature against the sample attack files from the PDF security site (here), one gets the following results:

• 通常(大多数ISA，所有SWA文件)经常看到签名已验证"和签名未涵盖整个文档"的输出.
• 在一种ISA情况下，有一个NoSuchAlgorithmException.
• 通常(大多数USF文件)有一个NullPointerException.
• 在一种USF情况下，有一个ClassCastException.
• 在一种USF情况下，有一个CMSException.

• Very often (most ISA, all SWA files) one sees an output of "Signature verified" together with "Signature does not cover whole document".
• In one ISA case there is a NoSuchAlgorithmException.
• Often (most USF files) there is a NullPointerException.
• In one USF case there is a ClassCastException.
• In one USF case there is a CMSException.

(因此，只要基于PDFBox的验证器正确输出签名未覆盖整个文档"警告(如果适用)并在任意异常的情况下输出失败"或未知"，它就不会成为现实.攻击文件.

Thus, as long as a PDFBox based validator correctly outputs the "Signature does not cover whole document" warning where applicable and outputs a "Failure" or "Unknown" in case of arbitrary exceptions, it does not fall prey to the present attack files.

正如@Tilman在对问题的评论中所说的那样，在加载PDF进行验证时取消激活宽松模式可能是个好主意.在欺骗任何验证例程之前，这已经捕获了大多数ISA和一些USF攻击...

As @Tilman also said in a comment to the question, deactivating lenient mode when loading PDFs for validation might be a good idea. That would catch most ISA and some USF attacks already before any validation routines could be fooled...

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

Beware, though: As mentioned above the thesis and the example files show some deficiencies. Thus, there is a chance that PDFBox is susceptible to improved versions of the attacks. In particular the signature wrapping approach looks promising as PDFBox uses the Contents string only and does not compare it to the contents of the byte ranges gap.

这篇关于如何在Apache PDFBox中防止通用签名伪造(USF)，增量保存攻击(ISA)，签名包装(SWA)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！