简体   繁体   English

如何计算 SignerInfo 中的消息摘要?

[英]How to compute message-digest in a SignerInfo?

I'm trying to generate a pdf with LTV enabled.我正在尝试生成启用 LTV 的 pdf。 I generate a pkcs7 object with all the attributes necesary included the signerInfo object. The signature generated is valid but not LTV enabled.我生成了一个 pkcs7 object,其中包含 signerInfo object 所需的所有属性。生成的签名有效但未启用 LTV。 According to the PDF reference manual i need to include validation info (CRLS or OCSP...) and based on rfc3852 this content goes in the signedAttributes object and it must contain a content-type attribute and a message-digest attribute.根据 PDF 参考手册,我需要包含验证信息(CRLS 或 OCSP ...),并且基于 rfc3852,此内容位于 signedAttributes object 中,并且它必须包含内容类型属性和消息摘要属性。 My question is how to compute the message-digest value and is it necesary to sign alongside the pdf content?我的问题是如何计算消息摘要值,是否需要与 pdf 内容一起签名?

Note: the adbe-revocationInfoArchival object containing the CRLs seems to be correct since acrobat reads the revocation info directly from the file.注意:包含 CRL 的 adbe-revocationInfoArchival object 似乎是正确的,因为 acrobat 直接从文件中读取撤销信息。 The only issue i seem to have is the message-digest included in the signedAttrs object and/or the signature value is not computed correctly.我似乎遇到的唯一问题是 signedAttrs object 中包含的消息摘要和/或未正确计算签名值。 RFC is not very clear on what that message-digest should be or if it should be included in the digest that will be signed with the signers private key. RFC 并不清楚消息摘要应该是什么,或者它是否应该包含在将使用签名者私钥签名的摘要中。

After some back and forth in the comments to the question I'm still not sure what information you need, so here a few thoughts in general on the structure and contents of non-trivial CMS signature containers for PDF signatures.在对问题的评论中来回反复之后,我仍然不确定您需要什么信息,所以这里有一些关于 PDF 签名的非平凡 CMS 签名容器的结构和内容的一般想法。

The Specifications规格

First off, though, some words on the specifications to use.不过,首先要说说使用规范。 You mention the PDF reference manual and rfc3852 .您提到了PDF 参考手册rfc3852 Both actually are not state-of-the-art anymore, but interestingly one less than the other.两者实际上都不再是最先进的,但有趣的是一个比另一个少。

  • Originally the Adobe PDF References for PDF up to 1.7 were the documentation to look at.最初 Adobe PDF PDF 到 1.7 的参考资料是要查看的文档。 Unfortunately Adobe saw these references as not normative in nature , ie if the current Reference and the current Acrobat version disagreed on something, the program was correct, not the Reference!不幸的是,Adobe 将这些参考视为本质上不规范,即如果当前参考和当前 Acrobat 版本在某些方面存在分歧,则程序是正确的,而不是参考!

    The latest Adobe PDF Reference (for PDF 1.7) referred to RFC 2315 for the structure of the signature container.最新的 Adobe PDF Reference (for PDF 1.7) 参考了 RFC 2315 的签名容器结构。

  • Then Adobe transferred the authority over the format PDF to the International Organization for Standardization (ISO) who in 2008 published the first normative PDF specification, ISO 32000-1, which was very similar to the last PDF Reference in content but adopted the RFC'ish language.然后 Adobe 将 PDF 格式的权限转移给了国际标准化组织 (ISO),后者在 2008 年发布了第一个规范的 PDF 规范,ISO 32000-1,它与最后的 PDF Reference 在内容上非常相似,但采用了 RFC'ish语言。

    ISO 32000-1 refers both to RFC 3852 and RFC 2315 for the structure of the signature container.对于签名容器的结构,ISO 32000-1 参考了 RFC 3852 和 RFC 2315。 Which is weird, but most likely the remaining RFC 2315 reference was an oversight.这很奇怪,但很可能剩余的 RFC 2315 参考是一个疏忽。

  • In 2017 the ISO published a PDF specification for PDF 2.0, ISO 32000-2, with a number of relevant changes, also in the context of signing. 2017 年,ISO 发布了 PDF 规范 PDF 2.0,ISO 32000-2,有一些相关的变化,也在签署的范围内。

    ISO 32000-2 refers to RFC 5652 for the structure of the signature container for adbe.pkcs7.detached signatures and to ETSI EN 319 122 for the structure of the signature container for ETSI.CAdES.detached signatures.对于adbe.pkcs7.detached签名的签名容器结构,ISO 32000-2 参考了 RFC 5652,对于ETSI.CAdES.detached签名的签名容器结构,参考了 ETSI EN 319 122。

  • In 2020 the ISO updated ISO 32000-2 with a number of clarifications; 2020 年,ISO 更新了 ISO 32000-2,并进行了多项澄清; the references for the signature container specification remained the same.签名容器规范的引用保持不变。

Thus, currently you should look at ISO 32000-2:2020 and RFC 5652.因此,目前您应该查看 ISO 32000-2:2020 和 RFC 5652。

CMS Signature Containers CMS 签名容器

In a late comment you say在迟到的评论中你说

I want to know how do i add these attributes to the final digest to sign.我想知道如何将这些属性添加到最终摘要中以进行签名。 I'm using SHA to digest the pdf, then sign it with the rsa private key and build the pkcs7 structure including the certificate chain, the signed message and a timestamp as an unsigned attribute.我正在使用 SHA 来消化 pdf,然后使用 rsa 私钥对其进行签名并构建 pkcs7 结构,包括证书链、签名消息和作为未签名属性的时间戳。

This procedure can only create simple signature containers without signed attributes as only in these simple containers the document hash is signed directly.此过程只能创建没有签名属性的简单签名容器,因为只有在这些简单容器中,文档 hash 才被直接签名。 But the adbe-revocationInfoArchival attribute you want to add must be a signed attribute, and as soon as signed attributes are involved, the document hash value is not signed directly anymore.但是你要添加的adbe-revocationInfoArchival属性必须是signed属性,一旦涉及到signed属性,文档hash值就不再直接签名了。

The CMS signature container contains a SignedData object with exactly one SignerInfo object. That SignerInfo object is defined as CMS 签名容器包含一个SignedData object 和一个SignerInfo SignerInfo object 定义为

  SignerInfo ::= SEQUENCE {
    version CMSVersion,
    sid SignerIdentifier,
    digestAlgorithm DigestAlgorithmIdentifier,
    signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
    signatureAlgorithm SignatureAlgorithmIdentifier,
    signature SignatureValue,
    unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }

(RFC 5652 section 5.3. "SignerInfo Type") (RFC 5652 第 5.3 节“SignerInfo 类型”)

In a signature container created by your working code the OPTIONAL signedAttrs are absent and the signature value is calculated immediately for the document hash.在您的工作代码创建的签名容器中,可选的signedAttrs不存在,并且会立即为文档 hash 计算signature值。

As soon as there are signed attributes, though, the OPTIONAL signedAttrs is not absent anymore, instead it is a SET of Attribute instances including at least但是,只要有签名的属性,可选的signedAttrs就不再存在,而是一SET Attribute实例,至少包括

  • a content-type attribute with id-data as value,id-data作为值的内容类型属性,
  • a message-digest attribute with the digest value of the to-be-signed PDF byte ranges as value,以待签名 PDF 字节范围的摘要值作为值的消息摘要属性,
  • and in your case an adbe-revocationInfoArchival attribute with the revocation information as value.在您的情况下,一个adbe-revocationInfoArchival属性以撤销信息作为值。

In this case the signature value is not calculated immediately for the document hash anymore but instead for the hash value of the signedAttrs !在这种情况下不再立即为文档 hash 计算signature而是为 signedAttrs 的signedAttrs计算签名值!

To be more exact, it is calculated for the hash value of the complete DER encoding thereof, and not with the IMPLICIT [0] tag but with an EXPLICIT SET OF tag.更确切地说,它是针对其完整DER编码的hash值计算的,而不是使用IMPLICIT [0]标签,而是使用EXPLICIT SET OF标签。

Thus, after using SHA to digest the pdf you instead of signing it with the rsa private key and building the pkcs7 structure proceed by因此,在使用 SHA 消化 pdf之后,您无需使用 rsa 私钥对其进行签名并构建 pkcs7 结构,而是继续进行

  • building the set of signed attributes with at least the attribute entries enumerated above, DER encoding that set and hashing it,至少使用上面列举的属性条目构建一组签名属性,对设置的 DER 编码并对其进行哈希处理,
  • signing that hash value of the signed attributes with your private key, and使用您的私钥签署已签名属性的 hash 值,以及
  • building the CMS signature container structure with these signed attributes and this signature value, and also with the certificate chain.使用这些签名属性和此签名值以及证书链构建 CMS 签名容器结构。

Additionally you may add a signature time stamp.此外,您可以添加签名时间戳。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM