PDF数字签名具有“不良参数”。在Acrobat
我正在尝试创建一个开源库，用于数字签名PDF文件。
不良参数
我完成了其中的大部分内容，但是我有一个问题，即签名显示以下错误：
Error during signature verification.
Adobe Acrobat error.
Bad parameter.
我试图找到问题，但到目前为止尚未找到它。 我创建了2个PDF文件，这些文件几乎由所有其他数据进行了条纹，除了所需的信息。
有人知道这个错误可能起源于哪里吗？ 我已经尝试了在线和离线验证器不同的尝试，但是其中没有指向我朝着正确的方向指出。 有人知道此错误是否可能源自证书，而不是PDF扭转本身？
我
创建此帖子时，我也在其他PDF文件上进行了测试，但是出现了错误：
Error during signature verification.
Unexpected byte range values defining scope of signed data.
Details: The signature byte range is invalid
请注意，PDF的一小部分将其描述为：
...
/SubFilter/adbe.pkcs7.detached
/ByteRange[0 4197 22193 30080 ]
/Contents<30820...
多次重新计算byterange属性，甚至尝试过在每个方向上更改一个字节，但这将始终导致签名处理错误。。 我不知道byterange还有什么不正确。 （增加的空间与Acrobat如何在旁观者中垫板相同。）
如果有人可能对问题可能有所了解，请告诉我。
文件
以下是我的结果文件：
- result_bad_param_with_image.pdf（
- （ rigral1 ）（
- ？ usp =共享“ rel =” nofollow noreferrer“> mirror1 ）（）
- 结果2_INVALID_BYTE_RANGE_NO_IMAGE.PDF（
eqsajj “ rel =“ nofollow noreferrer”> rigral2 pdf中的字段，直接在单独的文件中除外）：
- signature.der（ mirror1 ）（
！代码> signature.der 在此处打印： https://pastebin.com/pastebin.com/w4egj2fx （使用openssl cms -inform der -in signature.der -cmsout -print命令）
（我知道签名是自签名的，并且不包含很多信息，但这对此不重要，我认为，这只是为了创建这些示例）
编辑：解决了一些问题并添加了一些额外的文件后：
I'm trying to create an open source library for Digital Signing of PDF files.
Bad parameter
I got most of it done, but I have a problem that the signature shows the following error:
Error during signature verification.
Adobe Acrobat error.
Bad parameter.
I tried to find the problem, but until now have not found it.
I have created 2 pdf files that are striped of almost all other data, except the needed info.
Does anyone know where this error might originate from?
I have already tried different online and offline validators, but non of them pointed me in the right direction.
Does anyone know if this error might originate from the certificate and not the pdf struture itself?
Invalid byte range
While creating this post I also tested it on other pdf file too, but got the error:
Error during signature verification.
Unexpected byte range values defining scope of signed data.
Details: The signature byte range is invalid
Note a slice of the pdf describes it as:
...
/SubFilter/adbe.pkcs7.detached
/ByteRange[0 4197 22193 30080 ]
/Contents<30820...
I have multiple times recalculated the ByteRange attribute and even tried changing it by one byte in each direction, but that will always result in Signature processing error..
I don't know what else can be incorrect about the ByteRange. (the added spaces are the same as how Acrobat pads the byterange.)
If anyone might have an idea on what the problem might is, let me know.
Files
Here are my resulting files:
- result_bad_param_with_image.pdf (mirror1) (mirror2)
- result_bad_param_no_image.pdf (mirror1) (mirror2)
- result2_invalid_byte_range_with_image.pdf (mirror1) (mirror2)
- result2_invalid_byte_range_no_image.pdf (mirror1) (mirror2)
A signature file (same as the Contents field in a pdf, excepts directly in separate file):
The content of the signature.der is printed here: https://pastebin.com/W4EGJ2fX
(using openssl cms -inform DER -in signature.der -cmsout -print command)
(I know the signature is self signed and does not contains a lot of info, but this should not matter for this, I think, this was just to create these examples)
Edit: New links after solving some problems and added some extra files:
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您的签名中有一些错误和一个罕见的结构，在数字签名的背景下可能会导致验证器拒绝。
具有符号属性的CMS签名容器中的签名内部签名容器内部签名容器签名的错误签名值
使用两个哈希值：
signerInfo中签名属性的哈希值；在您的示例文件中，该值不正确。ps ：再次查看不匹配，事实证明您的签名属性未编码：DER编码特别为特定顺序的集合元素，在您的情况下，属性订单不是DER订单。但是，规范要求对签名的属性进行编码。
pps ：在评论中
首先，这种推理是有缺陷的：所讨论的类型是一种集合类型（更确切地说是ASN.1集），而不是某些地图类型。并且DER编码规则集仅知道ASN.1基本类型。因此，该OID（只是属性结构的任意部分）不能是通用订购密钥。
实际上，快速浏览规范显示了：
（ISO/IEC 8825-1/ITU-TREC。X.690，第11节“ CER和DER对BER的限制”）
因此，在签名属性的情况下，本质上是您首先是DER编码属性元素，然后如上所述对所得字节阵列进行排序。
顺便说一句，这个问题的问题仅在大概一半的验证者中引起问题。某些验证器不会检查或重新编码签名的属性，因此它们与您获得的哈希相同。其他人要么在前检查编码（因此，由于问题而丢弃错误），要么简单地重新编码DER中的属性（因此，获得与您所获得的哈希相同）。
签名证书的有问题的扩展密钥用法
您的签名证书具有扩展的密钥用法值1.3.6.1.4.1.311.80.1（Microsoft的OID用于文档加密），仅此而已。 Adobe验证仅用于支持没有扩展密钥用法的支持证书或以下一个或多个：：
电子邮件 https://www.adobe.com/devnet-docs/acrobatetk/tools/digsig/changes.html“ rel =” nofollow noreferrer“> eThertprise toolkit»数字签名IT»IT的数字签名指南»
不正确的增量更新
您在原始PDF的增量更新中签名。通常，这是一个好主意，因为它允许提取未签名的原始文档。
但是，一个人需要正确添加增量更新，并且在 result2_invalid_byte_range_no_image.pdf 和 result2_invalid_byte_range_with_image.pdf.pdf 中，使用了原始的Revision：使用交叉参考参考损失列出了，它是不正确的：但是您的增量更新使用纯交叉参考流。这是不正确的，您必须继续使用相同的交叉引用。
当打开横介参考表和纯交叉参考流的混合物时，Adobe Acrobat内部维修此文档，特别是重新定位了标志，因此字节范围不正确。
您在示例PDF中使用不常见的签名字段结构的不
常见签名字段结构，您可以将小部件与字段分开，仅在签名中更新字段而不是小部件。
虽然严格来说这是可以的，但我将在使代码完全正常工作的同时实施共同的结构，然后才偏离。
ps ：在评论中，您询问我是否可以详细说明。
您在第一步中的签名实现添加了一个带有空的签名字段的增量更新和一个间接引用的kid的小部件，例如：
在另一个增量更新中，您然后用直接的签名值签名，但不要更改小部件，例如：
这在某些方面很少：
另外，除非在添加空签名字段和签名之间发生其他表格填充，否则通常会在同一文档更新中添加和填充字段。
因此，更常见的是包含类似内容的单个增量更新（甚至是完整的重新保存）：
但是，如上所述，您的结构严格来说也可以。但是，“不良参数”仅在文档中的小部件或签名面板验证时才会发生，但是在使用“签名属性”对话框的“验证签名”按钮验证您的签名时，不会发生。因此，我认为Adobe可能是由罕见的结构依赖的。
There are some errors in your signature and an uncommon structure which in the context of digital signatures may result in rejection by a validator.
Incorrect Signed Hash Value Inside Signature Container
Signing in CMS signature containers with signed attributes makes use of two hash values:
SignerInfoof the signature container; that value is not correct in your example files.PS: Looking into the mismatch once again, it turns out that your signed attributes are not DER encoded: The DER encoding in particular sorts the elements of a SET in a specific order, and in your case the attribute order is not the DER order. The specification requires the signed attributes to be DER encoded, though.
PPS: In a comment you argued
First of all, this reasoning is flawed: The type in question is a set type (more exactly an ASN.1 SET OF), not some map type; and the DER encoding rule set only knows the ASN.1 base types. Thus, that OID (which just is an arbitrary part of the attribute structure) cannot be the generic ordering key.
And indeed, a quick glance at the specification shows:
(ISO/IEC 8825-1 / ITU-T Rec. X.690, section 11 "Restrictions on BER employed by both CER and DER")
Thus, in case of the signed attributes essentially you first DER encode the attribute elements and then sort the resulting byte arrays as described above.
As an aside, this issue of your signature merely causes problems in probably half the validators around. Some validators do not check or DER re-encode the signed attributes, so they get the same hash as you get. Others either check the encoding up front (and, therefore, throw an error because of the issue) or simply re-encode the attributes in DER (and, therefore, get a different hash than you get).
Problematic Extended Key Usage of Signer Certificate
Your signer certificate has an extended key usage value 1.3.6.1.4.1.311.80.1 (Microsoft's OID for Document Encryption) and only that. Adobe validation used to only support certificates with either no extended key usage or one or more of the following:
See Enterprise Toolkit » Digital Signatures Guide for IT » A: Changes Across Releases.
Incorrect Incremental Updates
You sign in an incremental update to the original PDF. This in general is a good idea as it allows to extract the unsigned original document.
But one needs to add the incremental update correctly, and in case of result2_invalid_byte_range_no_image.pdf and result2_invalid_byte_range_with_image.pdf it is done incorrectly: The original revision there is created using cross reference tables but your incremental updates use pure cross reference streams. This is incorrect, you have to continue with the same kind of cross references.
When opening documents with a mix of cross reference tables and pure cross reference streams, Adobe Acrobat internally repairs this which in particular relocates signatures and so makes byte ranges incorrect.
Uncommon Signature Field Structure
You use an uncommon signature field structure in your example PDFs, you separate the widget from the field and only update the field, not the widget, in signing.
While this strictly speaking is ok, I would implement the common structures while making the code work at all, and deviate only thereafter.
PS: In a comment you asked whether I could elaborate on this.
Your signing implementation in a first step adds an incremental update with an empty signature field and a widget as indirectly referenced kid, e.g.:
In another incremental update you then sign the field with a direct signature value but don't change the widget, e.g.:
This is uncommon in some ways:
Also, unless other form fill-ins shall happen between adding an empty signature field and signing it, fields usually are added and filled in the same document update.
Thus, more common would be a single incremental update (or even full re-save) containing something like this:
As said above, though, your structure strictly speaking is ok, too. But the "Bad parameter" only occurs when validating from the widget in the document or from the signature panel, but it does not occur when validating your signature using the "Validate Signature" button of the "Signature Properties" dialog. Because of that I think it's possible that Adobe is iritated by an uncommon structure.