客户端或者与其沟通至少存在两个问题:
DigestInfo 结构中假设的哈希算法错误
当使用签名者证书的公钥解密时,客户端返回的签名值包含此内容DigestInfo
结构:
0 81: SEQUENCE {
2 13: SEQUENCE {
4 9: OBJECT IDENTIFIER sha-512 (2 16 840 1 101 3 4 2 3)
15 0: NULL
: }
17 64: OCTET STRING
: '413140d54372f9baf481d4c54e2d5c7bcf28fd6087000280'
: 'e07976121dd54af2'
: }
它特别声称SHA512已用于计算哈希值。尽管如此,它包含一个长度为 32 字节的摘要值,因此它不能是 SHA512 摘要值!
所以你的主张
我有一项对数据进行签名并为我提供签名哈希的服务,它正确生成 PKCS#7 DigestInfo,如 rfc2315#section-9.4 中所述
要么不正确,要么您与服务通信的代码向其提供了错误的数据。
因此,请修复您的客户端或客户端通信组件,以使它们将正确的摘要算法 OID 引入到签名中DigestInfo
结构。
哈希值错误
即使上面的 OID 被更正,其中的哈希值也是错误的,您的 PDF 签名范围的正确 SHA256 哈希值是
9a75434965d5cf2635eb963752494b408a480effabfca1d87b82e619040dfb4b
因此,请调试您的工具链以找出错误的哈希值来自何处。
附录:CMS容器的结构
您的解决方案的另一个缺点是生成的 CMS 容器的结构非常简单。特别是它根本不包含签名属性。虽然 CMS 规范允许这样做,但对于许多可能的伪造攻击来说,这是极其不安全的。因此,当前规范中几乎没有任何 CMS 容器配置文件认为这种签名容器有效。
因此,除非您签署的文档仅在非常受控的环境中使用,并且有组织措施防止这些伪造攻击,否则它们的价值实际上为零。