数字签名中pdf的消息摘要 [英] Message digest of pdf in digital signature

查看:249
本文介绍了数字签名中pdf的消息摘要的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我想手动验证签名pdf的完整性.我已经可以到达:-

I want to manually verify the integrity of a signed pdf. I have been able to reach at:-

  • 从pdf(使用PyPDF2)获取了'/Content'节点的值.这是der编码的PKCS#7证书.
  • got the value of '/Content' node from pdf(using PyPDF2). This is a der encoded PKCS#7 certificate.

现在按照pdf specifications,pdf数据的消息摘要与证书一起存储在/Content节点中.尝试了很多,但我无法获得摘要值,最终将其与哈希的pdf内容(由/ByteRange指定)进行比较.

Now as per pdf specifications, the message digest of the pdf data is stored along with the certificate in /Content node. Tried a lot but I am not able to get the digest value which I would eventually compare with hashed pdf content(specified by /ByteRange).

  • PDF规范快照:-
  • PDF specification snapshot:-

不了解最后一个表示write signature object data into the dictionary的部分.此写操作实际上在哪里发生,以及如何提取消息摘要?

Don't understand the last part that says write signature object data into the dictionary. where does this write actually happens and how can I extract the message digest?

推荐答案

(这不是注释,而是答案.由于注释的大小和格式限制,我还是将其放入了答案.)

先前的问题中,OP已经插入了一个草图,以说明在情况下嵌入在PDF中的签名.子过滤器 ETSI.CAdES.detached adbe.pkcs7.detached adbe.pkcs7.sha1

In a prior question the OP already inserted a sketch illustrating a signature embedded in a PDF in case of SubFilter ETSI.CAdES.detached, adbe.pkcs7.detached, or adbe.pkcs7.sha1:

但这只是草图,从字面上解释它可能会留下错误的印象,即签名字典中 Contents 条目的值类似于包含证书"的列表, 签名消息摘要"和时间戳".此外,将该列表称为签名值"也可能造成混淆,因为该名称也用于内容的一小部分,请参见下文.

But this is merely a sketch, and interpreting it too literally may leave the incorrect impression that the value of the Contents entry in the signature dictionary is something like a list containing a "Certificate", a "Signed message digest" and a "Timestamp". Furthermore calling this list the "Signature value" can also confuse as that name is also used for a small part of the content, see below.

指定了实际的内容(请参见此文档)为:

The actual content is specified (cf. this document) as:

当使用PKCS#7签名时,Contents的值应为包含签名的DER编码的PKCS#7二进制数据对象. PKCS#7对象应符合RFC3852加密消息语法.

When PKCS#7 signatures are used, the value of Contents shall be a DER-encoded PKCS#7 binary data object containing the signature. The PKCS#7 object shall conform to RFC3852 Cryptographic Message Syntax.

(顺便说一句:尽管此处的规范要求数据对象必须进行DER编码,但在野外有许多带符号的PDF会对整个对象使用不太严格的BER编码,而对部分对象仅使用DER编码RFC3852还要求对DER进行编码.)

(As an aside: While the specification here requires the data object to be DER-encoded, there are many signed PDFs in the wild which use some much less strict BER-encoding for the object as a whole and DER only for parts also required by RFC3852 to be DER-encoded.)

更确切地说,包含符合RFC3852签名的 PKCS#7二进制数据对象是具有 SignedData 内容的 ContentInfo 对象,通常将其命名为一个签名容器".

The PKCS#7 binary data object containing the signature conforming to RFC3852 more exactly is a ContentInfo object with a SignedData content, often named a "signature container".

根据 RFC 3852

CMS将内容类型标识符与内容相关联.这 语法必须具有ASN.1类型的ContentInfo:

The CMS associates a content type identifier with a content. The syntax MUST have ASN.1 type ContentInfo:

  ContentInfo ::= SEQUENCE {
    contentType ContentType,
    content [0] EXPLICIT ANY DEFINED BY contentType }

签名数据内容类型应具有ASN.1类型SignedData:

The signed-data content type shall have ASN.1 type SignedData:

  SignedData ::= SEQUENCE {
    version CMSVersion,
    digestAlgorithms DigestAlgorithmIdentifiers,
    encapContentInfo EncapsulatedContentInfo,
    certificates [0] IMPLICIT CertificateSet OPTIONAL,
    crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
    signerInfos SignerInfos }

在这里您看到可选的集合certificates,其中通常至少包含签署者证书,并且通常还包含其发行者证书链.这是上图中的证书".

Here you see the optional collection certificates in which usually at least the signer certificate and often also its chain of issuer certificates are contained. Here is the "Certificate" from the sketch above.

您还将看到signerInfos结构,其中包含实际的签名信息:

You also see the signerInfos structure which contains actual signing information:

  SignerInfos ::= SET OF SignerInfo

每个签署者的信息以SignerInfo类型表示:

Per-signer information is represented in the type SignerInfo:

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

  SignedAttributes ::= SET SIZE (1..MAX) OF Attribute

  Attribute ::= SEQUENCE {
    attrType OBJECT IDENTIFIER,
    attrValues SET OF AttributeValue }

(这里您看到的是RFC调用SignatureValue ...的结构,上面的草图将整个签名容器称为"Signature value"可能会造成混淆,因为此处已经是一个像这样的类型的实体)

(Here you see the structure the RFCs call the SignatureValue... as already mentioned, the sketch above calling the whole signature container "Signature value" can confuse as down here already is an entity of a type called like that.)

您正在寻找 adbe.pkcs7.detached 类型PDF签名的签名PDF字节范围的消息摘要.实际上有两种可能性:

You are after the message digest of the signed PDF byte ranges for a adbe.pkcs7.detached type PDF signature. There actually are two possibilities:

  • 在最简单的SignerInfo实例的极少数情况下,没有SignedAttributes.在这种情况下,SignatureValue是立即应用于有符号字节范围的签名算法的值.

  • In the rare case of the most simple SignerInfo instances, there are no SignedAttributes. In this case the SignatureValue is the value of a signature algorithm immediately applied to the signed byte ranges.

如果签名算法基于RSA,则可以通过使用签名者的公钥(来自其证书)对值进行解码,然后从解码的DigestInfo对象中提取摘要来检索文档摘要值.

If the signature algorithm is based on RSA, you can retrieve the document digest value by decoding the value using the signer's public key (from his certificate) and extracting the digest from the decoded DigestInfo object.

DigestInfo ::= SEQUENCE {
  digestAlgorithm DigestAlgorithmIdentifier,
  digest Digest }

如果签名算法基于DSA或EC DSA,则根本无法检索摘要值.这些算法仅允许您检查所提供的摘要值(例如,在检索文档时对文档的签名字节范围进行哈希处理)是否是原始签名的.

If the signature algorithm is based on DSA or EC DSA, you cannot retrieve the digest value at all. These algorithm only allow you to check whether a digest value you provide (e.g. having hashed the signed byte range of the document as you have retrieved it) is the originally signed one.

在具有SignedAttributesSignerInfo实例的更常见情况下,您必须在这些SignedAttributes中搜索由

In the far more common case of SignerInfo instances with SignedAttributes, you have to search these SignedAttributes for the message digest attribute which is identified by

 id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 }

但是,正如评论中已经提到的那样,我无法解释如何使用Python或openssl进行深入研究.您将需要一些工具来大致了解这些特定的ASN.1结构或ASN.1结构.

As already mentioned in comments, though, I cannot explain how to drill down here using Python or openssl. You will need some tool which knows these specific ASN.1 structures or ASN.1 structures in general.

这篇关于数字签名中pdf的消息摘要的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆