PDF签名摘要

Nie*_*els 5 pdf digest digital-signature pkcs#7

我有一个关于计算用于数字签名的PDF文档摘要的快速问题(与我之前的一个问题有点相关,我试图弄清楚为什么你需要知道客户的证书才能创建正确的摘要).在Adobe有关PDF格式的文档中,指定了以下内容:

应在文件中的字节范围内计算字节范围摘要,该字节范围摘要应由签名字典中的ByteRange条目指示.此范围应该是整个文件,包括签名字典,但不包括签名值本身(内容条目).

所以在这一点上事情似乎相当简单,只是消化/ Sig字典中除/ Contents条目之外的所有内容./ Contents条目中的实际数据指定如下:

对于公钥签名,Contents应该是DER编码的PKCS#1二进制数据对象或DER编码的PKCS#7二进制数据对象.

所以仍然没有问题,我可以(可能)生成摘要,为/ Contents条目保留空间并稍后附加此PKCS#7对象.当我阅读以下内容时,混乱就开始了:

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

所以我没有得到的东西:显然/ Contents条目(包含证书和签名摘要)没有消化,但证书链是一个签名属性(因此需要被消化?).

如果有人能够进一步确定消化的内容,我会很感激,也许更好地向我解释已签名的属性.我想回答的主要问题是:我是否可以在事先不知道某人的证书的情况下创建一个可签名的摘要?(我正在使用pkcs7分离签名)

mkl*_*mkl 10

简而言之:

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

如果是SubFilter ETSI.CAdES.detachedadbe.pkcs7.detached,您可以在不事先知道某人证书的情况下创建文档摘要 .

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

详细地:

(注意,以下内容有所简化.)

我可以(可能)生成摘要,为/ Contents条目保留空间,并在以后附加此PKCS#7对象.

如果你先预留空间随后产生的消化,这确实是事情是如何完成的.

当我阅读以下内容时,混乱就开始了:

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

所以我没有得到的东西:显然/ Contents条目(包含证书和签名摘要)没有消化,但证书链是一个签名属性(因此需要被消化?).

如果有人能够进一步确定消化的内容,我会很感激,也许更好地向我解释已签名的属性.

一个必须知道的主要事实是,在PKCS#7的情况下/ CMS签名集装箱签署平时并不仅仅包括一个哈希计算,但至少2!

确实为整个文件计算了第一个散列,即文档散列,包括签名字典,但不包括签名值本身(内容条目)(您可能希望阅读此答案以获取更多详细信息).

散列字节范围的图形草图

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

在生成PKCS#7/CMS签名容器期间(除非以其最原始的形式),您将创建一个名为"signed attributes"的结构.

您使用多个属性(名称 - 值对)填充此结构,其中包括已计算的文档哈希以及其他属性,例如您阅读的Adobe样式的吊销信息.

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

然后,您可以使用这些签名属性,签名以及未签名的更多信息(例如证书,签名时间戳,......)将PKCS#7/CMS签名容器放在一起.

有关签名容器的更多详细信息,请阅读此答案.

最后,您将此签名容器嵌入到PDF中的保留空间中.

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

如果是SubFilter ETSI.CAdES.detachedadbe.pkcs7.detached,您可以在不事先知道某人证书的情况下创建文档摘要 .

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

澄清:

OP在评论中询问了一些后续问题:

1:签名属性之一是文档哈希(没有/ contents),所以如果我理解正确这是无符号哈希?

由于"签署属性"最终被散列和签名,该文件的散列在其中是不立即,直接签署它被间接地作为属性的此结构的一部分签署.所以我不会称它为无符号......

  1. 最后,当用户真正生成签名时,他会签署PKCS#7对象的哈希值?

不,"签名属性"结构的哈希值只是PKCS#7对象的一部分,而不是全部.PKCS#7/CMS对象的多个部分是无符号的.

  1. / Contents条目是否还有一个实际上对我们可读的PKCS#7对象?(提取证书等进行验证)

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

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

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

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

如3的答案中所述,您可能必须从PDF中检索其他信息,以便在PKCS#7验证中使用.

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

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

  1. 有没有关于哪些经过身份验证的属性的良好文档?

你可以开始阅读