如何查看pkcs#7内部签名了哪些属性? [英] How to see what attributes are signed inside pkcs#7?

查看:437
本文介绍了如何查看pkcs#7内部签名了哪些属性?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个pkcs#7文件,其中包含签名数据.它成功验证:

I have a pkcs#7 file, which contains signed data. It successfully verifies:

$ openssl smime -verify -in data.p7s -CAfile root-certificate.pem 
Verification successful
Signed data

但是当我提取签名部分时,我看不到它实际上与签名部分相同.我的意思是以下步骤:

But when I extract the signed part, I do not see that it is actually the same as what was signed. I mean the following steps:

$ openssl asn1parse -in data.p7s
...
   35:d=4  hl=2 l=   9 prim: OBJECT            :pkcs7-data
   46:d=4  hl=2 l=inf  cons: cont [ 0 ]        
   48:d=5  hl=2 l=inf  cons: OCTET STRING      
   50:d=6  hl=2 l=   5 prim: OCTET STRING      :(my data is here in plaintext)
...
(then the signed block starts:)
 2861:d=6  hl=2 l=   9 prim: OBJECT            :rsaEncryption
 2872:d=6  hl=2 l=   0 prim: NULL              
 2874:d=5  hl=4 l= 256 prim: OCTET STRING      [HEX DUMP]:<signed data is here>

我用签名数据剪切了[HEX DUMP]:

$ dd if=data.p7s of=signed-part.bin bs=1 skip=2878 count=256

使用相应的公钥对其进行解密:

Decrypt it with the corresponding public key:

$ openssl rsautl -verify -in signed-part.bin -pubin -inkey root-public-key.pem -out verified-data.bin

并查看结果:

$ openssl asn1parse -inform der -in verified-data.bin
    0:d=0  hl=2 l=  33 cons: SEQUENCE          
    2:d=1  hl=2 l=   9 cons: SEQUENCE          
    4:d=2  hl=2 l=   5 prim: OBJECT            :sha1
   11:d=2  hl=2 l=   0 prim: NULL              
   13:d=1  hl=2 l=  20 prim: OCTET STRING      [HEX DUMP]:<hash here>

[HEX DUMP]不是不是我原始数据的SHA1和.

This [HEX DUMP] is not the SHA1 sum of my original data.

我不明白为什么哈希值不同.显然,这是与原始数据不同的哈希值.哈希表是否还涵盖任何已认证的属性"?如果是,如何查看已对属性进行了精确哈希和签名?

I do not understand why the hash is different. Obviously, it's a hash of something different than my original data. Does the hash also cover any "Authenticated attributes"? If yes, how to see what exactly attributes have been hashed and signed?

推荐答案

好的,您没有提供完整的示例,但是我将尝试使用其他示例来导航您.

OK, you don't provide a full sample, but I'll try to navigate you nevertheless, with a different sample.

OpenSSL asn1parse对识别身份验证的属性没有多大帮助.您可以使用OpenSSL cms:

OpenSSL asn1parse does not help much identifying the authenticated attributes. You can use OpenSSL cms:

openssl cms -in data.p7s -noout -cmsout -print

寻找signedAttrs(已签名属性"是现在用CMS术语称呼已认证属性"的方式)

Look for signedAttrs ("signed attributes" is how the "authenticated attributes" are now called, in CMS terminology)

它看起来像这样:

    ...
    signerInfos:
        ...
        signedAttrs:
            object: contentType (1.2.840.113549.1.9.3)
            value.set:
              OBJECT:pkcs7-data (1.2.840.113549.1.7.1)    
            object: signingTime (1.2.840.113549.1.9.5)
            ...

现在返回到asn1parse输出,并找到相应的部分,看起来可能像这样:

Now go back to asn1parse output, and find the corresponding part, which may look like:

 ...
 1343:d=5  hl=3 l= 216 cons:      cont [ 0 ]
 1346:d=6  hl=2 l=  24 cons:       SEQUENCE
 1348:d=7  hl=2 l=   9 prim:        OBJECT            :contentType
 1359:d=7  hl=2 l=  11 cons:        SET
 1361:d=8  hl=2 l=   9 prim:         OBJECT            :pkcs7-data
 1372:d=6  hl=2 l=  28 cons:       SEQUENCE
 1374:d=7  hl=2 l=   9 prim:        OBJECT            :signingTime
 ...

(为此缩进,请添加-i选项)

(for this nice indentation, add -i option)

现在,在这种情况下,提取(dd ...)数据,包括DER上下文标签头,即偏移量1343,长度219.然后用0x31替换开头的0xa0字节. DER编码中说明了为什么必须这样做-如何将隐式标签转换为显式标签,或 RFC5652,第5.4节

Now, extract (dd ...) the data, including the DER context tag header, i.e. offset 1343, length 219, in this case. Then replace the 0xa0 byte at the beginning by 0x31. Why you have to do it, is described in DER encoding - How to convert implicit tag to explicit tag, or RFC5652, section 5.4

此数据的sha1哈希现在应该匹配.

The sha1 hash of this data should now match.

这篇关于如何查看pkcs#7内部签名了哪些属性?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

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