PDF签名摘要

时间：2015-03-25 09:31:56

标签： pdf digital-signature digest pkcs#7

我有一个关于计算用于数字签名的PDF文档摘要的快速问题（与我之前的一个问题有点相关，我试图找出你需要了解客户的原因＆＃ 39; s证书创建正确的摘要）。 在Adobe有关PDF格式的文档中，指定了以下内容：

  

应在文件中的字节范围内计算字节范围摘要，该字节范围摘要应由   ByteRange在签名字典中输入。此范围应该是整个文件，包括签名   字典但不包括签名值本身（内容条目）。

所以在这一点上看起来相当简单，只是消化/ Sig字典中除/ Contents条目之外的所有内容。 / Contents条目中的实际数据指定如下：

  

对于公钥签名，内容应该是DER编码的   PKCS＃1二进制数据对象或DER编码的PKCS＃7二进制数据   对象

所以仍然没有问题，我可以（可能）生成摘要，为/ Contents条目保留空间并稍后附加此PKCS＃7对象。当我阅读以下内容时，混乱就开始了：

  

撤销信息是一个签名属性，这意味着   签名软件必须在签名之前捕获吊销信息。类似的要求适用于   证书链。签名软件必须在签名之前捕获并验证证书链。

所以我没有得到的东西：显然/ Contents条目（包含证书和签名摘要）没有被消化，但证书链是一个签名属性（因此需要被消化？）

如果有人可以进一步详细说明消化的内容，我会很感激，也许更好地向我解释签名的属性。我想回答的主要问题是：我是否可以事先在不知道某人的证书的情况下创建一个可签名的摘要？ （我正在使用pkcs7分离签名）

1 个答案:

答案 0 :(得分：8)

简而言之：

  

我是否可以在事先不知道某人的证书的情况下创建可签名的摘要？

如果SubFilter ETSI.CAdES.detached 或 adbe.pkcs7.detached ，您可以在不知道的情况下创建文档摘要 事先有人的证明。

但是，在开始生成要嵌入PDF的CMS签名容器之前，您通常必须知道签名者证书。

详细说明：

（注意，以下内容有所简化。）

  

我可以（可能）生成摘要，为/ Contents条目保留空间，稍后附加此PKCS＃7对象。

如果您首先保留空间并且此后生成摘要，这确实是事情的完成方式。

  

当我阅读以下内容时，混乱就开始了：

     
    

撤销信息是签名属性，这意味着签名软件必须在签名之前捕获吊销信息。类似的要求适用于证书链。签名软件必须在签名之前捕获并验证证书链。

  
     

所以我没有得到的东西：显然/ Contents条目（包含证书和签名摘要）没有被消化，但证书链是一个签名属性（因此需要被消化？）

     

如果有人能够进一步详细说明消化的内容，我会很感激，也许更好地向我解释已签名的属性。

必须注意的一个主要事实是，在PKCS＃7 / CMS签名容器的情况下签名通常不仅包括一个哈希计算，但至少 2 的！

第一个散列，文档散列，确实是为整个文件计算的，包括签名词典，但不包括签名值本身（目录条目）（你可能需要阅读this answer以获取更多详细信息。）

Graphic sketch of hashed byte ranges

但这是不应用签名算法时立即使用的哈希值。

在生成PKCS＃7 / CMS签名容器期间（除非以最原始的形式），您创建一个名为＆＃34;签名属性的结构＆＃34;。

您使用多个属性（名称 - 值对）填充此结构，其中包括已计算的文档哈希，但也包括其他属性，例如您阅读的Adobe风格的吊销信息。

完成创建该结构后，您对此结构进行哈希并为其生成签名。

然后，您可以使用这些签名属性，签名以及未经此签名签名的更多信息（例如，签名）将PKCS＃7 / CMS签名容器放在一起。证书，签名时间戳，......

有关签名容器的更多详细信息，请阅读this answer。

最后，您将此签名容器嵌入PDF中的保留空间。

  

我想回答的主要问题是：我是否可以在事先不知道某人的证书的情况下创建一个可签名的摘要？ （我正在使用pkcs7分离签名）

如果SubFilter ETSI.CAdES.detached 或 adbe.pkcs7.detached ，您可以在不知道的情况下创建文档摘要 事先有人的证明。

但是，根据CMS签名配置文件，您通常必须在开始生成签名容器之前知道签名者证书，因为许多配置文件需要存在引用签署者证书的签名属性。

澄清：

OP在评论中提出了一些后续问题：

  

1：其中一个签名属性是文档哈希（没有/ contents），所以如果我理解正确，这是无符号哈希？

作为＆＃34;签名属性＆＃34;最终是哈希和签名，其中的文档哈希不是立即，签名但它是间接签名作为此属性结构的一部分。所以我不会把它称为无符号......

  
      
  1. 最后，当用户真正生成签名时，他会签署PKCS＃7对象的哈希值吗？
    2.   

不，＆＃34;签名属性＆＃34;的哈希值结构只是PKCS＃7对象的一部分，而不是全部。 PKCS＃7 / CMS对象的多个部分是无符号的。

  
      
  1. / Contents条目是否还有一个对我们来说实际可读的PKCS＃7对象？ （提取证书等以进行验证）
    2.   

目录条目确实包含一个完整的PKCS＃7 / CMS签名容器对象作为二进制字符串。因此，是的，您可以读取它（通过读取该二进制字符串的值）和（如果您有知道如何解析此类签名容器的代码）从中提取信息。

请注意，签名容器可能不包含验证所需的所有数据：例如，如果使用链（非shell）验证模型进行验证，则可能必须从相应的PDF签名字典条目中提取签名时间。

  
      
  1. 在验证签名时，我们是否只是提取嵌入的PKCS＃7对象，重新计算摘要，重新计算PKCS＃7对象的摘要，并使用我们从PKCS＃7对象获得的证书对签名进行验证？
    2.   

您显然还必须计算已签名PDF字节范围的摘要，并将该值与包含原始文档摘要的signed属性进行比较。（您可能意味着通过重新计算摘要。）

如3的答案所述，您可能需要从PDF中检索其他信息，以便在PKCS＃7验证中使用。

此外，您说我们从PKCS＃7对象获取的证书 - 请注意，PKCS＃7 / CMS签名容器可能包含多个证书。你必须找到正确的。应使用CMS SignerInfo SignerIdentifier和ESS签名属性。

此外，您还必须验证签名者证书的有效性和信任。

  
      
  1. 是否有关于哪些经过身份验证的属性的良好文档？
    2.   

你可以开始阅读

相关问题
最新问题