有关PDF格式数字签名的查询

Question

我在看官方的PDF规范。我在这里遇到了一个数字签名的PDF。当我分析它的目录字典时，我看到了这样的：

我对此有一些疑问：

>

根据规范的第736页，fieldMDP没有属于docMDP的p参数（第733页）。当然，PDF可能已经被某个第三方修改了，他们在字典中添加了一个无关的键。但我只想确认，如果在feldMDP中发现p键，是要忽略它，还是它有某种意义？

我明白PDF中的数字签名是通过签名字段进行的。数字签名是否可能不是签名字段，即字段数组项中没有关联的rect项？

筛选器键的具体作用是什么？我可以看到subfilter键决定在解密内容时使用哪种方案，filter键表示什么？规范说它是一个签名处理程序。那到底是什么？另外，子过滤器值没有说明什么？

Answer 1

##你的问题

###1。FieldMDP变换字典中的P值

根据规范的第736页，FieldMDP没有属于DocMDP的P参数（第733页）。当然，PDF可能已经被某个第三方修改了，他们在字典中添加了一个无关的键。但我只想确认一下，如果在FeldMDP中发现了一个P键，是要忽略它，还是它有某种意义？

现在，ISO32000的Adobe补充，扩展级别3，在表8.82中的锁字典条目中添加了一个新条目，P条目！在填写有问题的签名字段时，该条目可用于降低以前的DocMDP签名的原始P级别。

通过上面提到的将锁字典的副本用作FieldMDP转换参数字典的机制，P值现在发现自己在FieldMDP转换参数中。

不幸的是，在补编中忘记了更新转换参数规范...

...

FieldMDP字典中DigestLocation和DigestValue键值对的用途是什么？在V字典的Contents键中已经提供了摘要值，对吗？另外，它存在于数组（引用）中，这里只有一个条目，如果有多个条目怎么办？

首先看一下PDF参考资料第六版1.7版的勘误表：

###3。签名内容和子过滤器

如果我理解正确的话，Contents密钥的值是内容的html" target="_blank">加密摘要，不包括内容价值流（本身）。所以我首先要解密它。然后，我必须计算不包括内容流的实际内容的摘要，并比较这两个摘要，看看它们是否匹配。对吗？如果是，我该怎么做？我怀疑筛选器和子筛选器键表示方法，但我无法确切地理解如何表示方法。

为此，您应该阅读PDF参考中的第8.7.2节“签名互操作性”。但是请注意，子过滤器值adbe.x509.rsa_sha1和adbe.pkcs7.sha1（以及相关机制）在PDF 2.0中已经被废弃，而ETSI.cades.detached和ETSI.rfc3161已经被添加，其规范也可以在ETSI EN 319 142-1 v1.1.1中找到。

显然，密码哈希函数永远不能保证不发生冲突。然而，要被认为是好的，他们必须能够声称这样的碰撞是非常不可能的，并且构造碰撞是困难的。

对于16或20字节的MD5和SHA-1算法来说，随机冲突是非常不可能的。这不是问题所在。

问题是，它们同时被认为是不安全的，因为难以构造碰撞。

特别是，根据后一个句子，甚至尝试实现对象摘要计算都是没有意义的。

###6。隐形签名

我明白PDF中的数字签名是通过签名字段进行的。数字签名是否可能不是签名字段，即字段数组项中没有关联的Rect项？

###7。过滤器键

过滤器键的作用到底是什么？我可以看到子过滤器密钥决定在解密内容时使用哪种方案，过滤器密钥表示什么？规范说它是一个签名处理程序。那到底是什么？它还说了什么子过滤器值没有？

实际上，如今过滤器条目在可互操作的PDF签名处理中已经变得毫无意义。

在你问的评论中

如何处理上述PDF中的MDP信息？我有ByteRange对象，从中我可以计算PDF的总字节内容，不包括Contents键。我通过MD5计算它的哈希值，然后用子过滤器信息解密内容值。然后我比较。我到底在哪里需要MDP信息？其次，引用字典是可选的，如果它是可选的，我怎么知道我需要应用MD5来计算PDF内容的哈希？

你要做的...

您必须在这里使用哪些标准，可能取决于生成签名的技术和法律上下文。例如。在现代环境中，ESS属性必须存在匹配。

如果它们不是，则PKCS#7容器在签名后已被操纵。

对于PKI政策和法律框架，这一点更为具体。例如。合适的验证时间是当前时间还是确定为签名时间的最佳时间？签名的签名时间属性/PDF签名字典M值是否可信，或者必须有存在的证明？证书链应使用哪种验证模型？你接受的信任锚是什么？撤销信息呢...

你是如何得出这里的散列算法是SHA1的结论的？参考字典没有提到MD5吗？子过滤器是adbe.pkcs7。分离的，你怎么知道哈希algo不是，例如SHA256？如果是adbe.pkcs7.sha1，我会理解的。

是的，参考字典提到MD5，但这与字节范围签名无关。它指的是不推荐使用的对象摘要（见上文2.和4.的答案），对其计算的唯一描述无论如何都包含重大错误（见上文5.的答案）。

正如上面在验证步骤2中提到的，您必须解析这个PKCS#7容器并确定哈希算法。在参考资料第738页的底部，您将看到“PKCS#7对象必须符合Internet RFC2315中的PKCS#7规范。”您可以在这里找到这个RFC。较新的ISO规范参考了RFC3852或RFC5652中的加密消息语法(CMS)，它们反映了PKCS#7容器的进一步发展阶段。

3867 6086: . . . . SEQUENCE {
3871    1: . . . . . INTEGER 1
3874   75: . . . . . SEQUENCE {
3876   69: . . . . . . SEQUENCE {
3878   11: . . . . . . . SET {
3880    9: . . . . . . . . SEQUENCE {
3882    3: . . . . . . . . . OBJECT IDENTIFIER countryName (2 5 4 6)
         : . . . . . . . . . . (X.520 DN component)
3887    2: . . . . . . . . . PrintableString 'US'
         : . . . . . . . . . }
         : . . . . . . . . }
3891   22: . . . . . . . SET {
3893   20: . . . . . . . . SEQUENCE {
3895    3: . . . . . . . . . OBJECT IDENTIFIER organizationName (2 5 4 10)
         : . . . . . . . . . . (X.520 DN component)
3900   13: . . . . . . . . . PrintableString 'GeoTrust Inc.'
         : . . . . . . . . . }
         : . . . . . . . . }
3915   30: . . . . . . . SET {
3917   28: . . . . . . . . SEQUENCE {
3919    3: . . . . . . . . . OBJECT IDENTIFIER commonName (2 5 4 3)
         : . . . . . . . . . . (X.520 DN component)
3924   21: . . . . . . . . . PrintableString 'GeoTrust CA for Adobe'
         : . . . . . . . . . }
         : . . . . . . . . }
         : . . . . . . . }
3947    2: . . . . . . INTEGER 514
         : . . . . . . }
3951    9: . . . . . SEQUENCE {
3953    5: . . . . . . OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
         : . . . . . . . (OIW)
3960    0: . . . . . . NULL
         : . . . . . . }
3962 1733: . . . . . [0] {
3966   24: . . . . . . SEQUENCE {
3968    9: . . . . . . . OBJECT IDENTIFIER contentType (1 2 840 113549 1 9 3)
         : . . . . . . . . (PKCS #9)
3979   11: . . . . . . . SET {
3981    9: . . . . . . . . OBJECT IDENTIFIER data (1 2 840 113549 1 7 1)
         : . . . . . . . . . (PKCS #7)
         : . . . . . . . . }
         : . . . . . . . }
3992   35: . . . . . . SEQUENCE {
3994    9: . . . . . . . OBJECT IDENTIFIER messageDigest (1 2 840 113549 1 9 4)
         : . . . . . . . . (PKCS #9)
4005   22: . . . . . . . SET {
4007   20: . . . . . . . . OCTET STRING    
         : . . . . . . . . . 3F 00 47 E6 CB 5B 9B B0    ?.G..[..
         : . . . . . . . . . 89 25 4B 20 D1 74 44 5C    .%K .tD\
         : . . . . . . . . . 3B A4 F5 13                ;...
         : . . . . . . . . }
         : . . . . . . . }

此后，您将看到签名属性的开始，其中包括messageDigest3F 00 47 E6 CB 5B 9B B0 89 25 4B 20 D1 74 44 5C 3B A4 F5 13。这是您在验证步骤4中比较的值。

因此，如果我们排除MDP检查，基本的签名验证将只检查与目录对应的字节范围条目，并将其与哈希值进行比较，对吗？

为了澄清：数学签名验证将包括计算字节范围的哈希值，并将其与存储在CMS容器中的哈希值进行比较（验证步骤2..4)，以及验证CMS SignerInfo对象中的签名值是否正确地对其中的签名属性进行签名（这通常意味着计算签名属性的哈希值，确定签名者证书，并根据签名者证书中的哈希值和公钥检查签名值）（验证步骤5和6）。

如果我没有错的话，后续的更改将转到增量更新部分。如果强制执行严格的DocMDP，则任何增量更新都将使签名无效。准确吗？

DocMDP P值1根本不允许增量更新。除非您的验证策略包括ETSI扩展或PDF 2.0：在这些情况下，允许只包括向文档添加文档安全存储区(DSS)和/或文档时间戳所需数据的增量更新。

##关于向后兼容性