使用IAIK PKCS11生成PKCS7附加PDF时提示文档篡改

签名方式正确性判断 #

这种延迟签名的思路本身是可行的——延迟签名的核心就是对PDF预计算的消息摘要做签名，再封装成PKCS7嵌入PDF，不管用SUNPKCS11还是IAIK PKCS11 Wrapper，核心逻辑一致。所以不是思路错了，是实现细节有偏差。

具体排查方向 #

• 哈希算法一致性检查：确认PDF预计算摘要用的哈希算法（比如SHA-256、SHA-512），和IAIK签名时指定的算法完全一致。比如PDF用SHA-256，你签名时却用了SHA-1，或者IAIK代码里算法OID写错（比如把SHA256的OID写成SHA1的），这会直接导致签名不匹配。
• PKCS7封装格式验证：
  • 检查生成的PKCS7是否包含正确的签名属性：比如contentType（要指向PDF的OID 1.2.840.10008.1.7.1）、signingTime、messageDigest属性，其中messageDigest要和PDF预计算的摘要值完全一致（注意是原始摘要字节，不是Base64后的）。
  • 确认PKCS7是分离式签名（detached signature），因为PDF延迟签名需要的是不带原文的PKCS7，如果你生成的是包含原文的封装签名，嵌入PDF后肯定验证失败。
• IAIK PKCS11签名的字节处理：
  • 检查自定义IAIKPKCS11ContentSigner是否正确处理了摘要字节：比如有没有多做一次哈希（PDF已经计算好摘要，你只需要对这个摘要做签名，不需要再哈希一次），或者对Base64编码的摘要直接签名而不是先解码成原始字节。
  • 确认签名时用的私钥容器、密钥ID和之前SUNPKCS11用的完全一致，避免用错密钥导致签名无效。
• PDF嵌入PKCS7的细节：
  • 检查嵌入PKCS7时是否正确替换了延迟签名预留的占位符，有没有破坏PDF的交叉引用表或字节结构。比如占位符长度要和最终PKCS7的DER编码长度匹配，或者替换时有没有多写/少写字节。
  • 用PDF解析工具（比如iText的调试类）对比SUNPKCS11生成的PKCS7和IAIK生成的PKCS7的DER结构，看是否有字段缺失或格式差异。

快速验证技巧 #

把IAIK生成的PKCS7导出成DER文件，用openssl命令查看细节：

openssl pkcs7 -inform der -in your_signature.p7 -print_certs -text

对比签名属性、摘要值是否和SUNPKCS11生成的一致，快速定位差异点。

内容的提问来源于stack exchange，提问作者tulak.hord