ECDSA 签名的 PDF 无法通过 iText 7 (C#) 进行签名验证，但通过 Adobe Reader DC 成功
ECDSA signed PDF fails signature verification with iText 7 (C#), but succeeds with Adobe Reader DC
我已经使用 iText 7 创建了代码，它能够使用使用 ECDSA 密钥对的 X509 证书对给定的 PDF 进行数字签名。当我在 Acrobat Reader DC 中打开这个签名的 PDF 时，它会正确读取它，并验证它是否有效（意味着文档自签名后未被修改，等等）。
但是，当我尝试使用 iText 7 验证同一文档时，完整性和真实性检查 returns 错误。
这是一个示例代码：
// ...
PdfDocument pdfDoc = new(new PdfReader(stream));
SignatureUtil signUtil = new(pdfDoc);
IList<string> names = signUtil.GetSignatureNames();
foreach (string name in names) {
PdfPKCS7 pkcs7 = signUtil.ReadSignatureData(name);
bool wholeDocument = signUtil.SignatureCoversWholeDocument(name);
bool signatureIntegrityAndAuthenticity = pkcs7.VerifySignatureIntegrityAndAuthenticity(); // this returns false, even though Adobe has no problem verifying the signature.
// more code to read values and put them in a json
}
// ...
以及我从签名中提取的示例输出：
{
"$id": "1",
"signatures": [
{
"$id": "2",
"integrityAndAuthenticity": false, // <---- should be true in my opinion.
"revisionNumber": 1,
"coversWholeDocument": true,
"invisibleSignature": true,
"filterSubType": "ETSI.CAdES.detached",
"encryptionAlgorithm": "ECDSA",
"hashAlgorithm": "SHA512",
"nameOfSigner": "C=HU, CN=Teszt Elek, GIVENNAME=Elek, L=Budapest, O=Teszt ECC Szervezet, SN=202010260807, SURNAME=Teszt",
"alternateNameOfSigner": null,
"signDate": "2021-04-22T12:50:33Z",
"timestamp": {
"$id": "3",
"signDate": "2021-04-22T12:50:33Z",
"service": "C=HU,L=Budapest,O=Microsec Ltd.,2.5.4.97=VATHU-23584497,CN=Test e-Szigno TSA 2017 01",
"verified": true,
"hashAlgorithmOid": "2.16.840.1.101.3.4.2.3"
},
"location": " Hungary",
"reason": "Approval",
"contactInfo": "",
"name": "GUID_97e1669d-0fbe-409a-a8fc-8518a1bae460",
"signatureType": "approval",
"fillInAllowed": true,
"annotationsAllowed": true,
"fieldLocks": []
}
],
"revisions": 1,
"valid": false // is an aggregate of all the signatures integrity in the array above
}
发布时我使用的是最新的 iText 7 版本，我的平台是 ASP.NET 5 (.Net 5)。示例代码对应于 iText 自己的示例代码，它们为他们的学习书籍提供了这些代码（但更新为 7，因为这些书籍是为 iText 5 编写的）。
我正在添加示例 pdf，以及 this google drive 中签名版本的一些组合。它包含一个示例 pdf，它是未签名的和纯的。然后使用 ECDSA 和 RSA 密钥分别对该 pdf 进行签名。然后用相反类型的密钥对它们进行签名。以及他们所有的验证结果。注意：在 json 文件中 integrityAndAuthenticity 只是命名为 valid 为简洁起见，但它持有的值是 pkcs7.VerifySignatureIntegrityAndAuthenticity() 的结果。所有签名均由我的应用程序完成（使用 iText 7）。
编辑 #1：
我正在提供执行签名的代码：
using System;
using System.Security.Cryptography;
using iText.Signatures;
public class EcdsaSignature : IExternalSignature
{
private readonly string _encryptionAlgorithm;
private readonly string _hashAlgorithm;
private readonly ECDsa _pk;
public EcdsaSignature(ECDsa pk, string hashAlgorithm)
{
_pk = pk;
_hashAlgorithm = DigestAlgorithms.GetDigest(DigestAlgorithms.GetAllowedDigest(hashAlgorithm));
_encryptionAlgorithm = "ECDSA";
}
public virtual string GetEncryptionAlgorithm()
{
return _encryptionAlgorithm;
}
public virtual string GetHashAlgorithm()
{
return _hashAlgorithm;
}
public virtual byte[] Sign(byte[] message)
{
return _pk.SignData(message, new HashAlgorithmName(_hashAlgorithm), DSASignatureFormat.Rfc3279DerSequence); // <---- I have solved the iText 7 issue by providing this enum to the SignData() method.
}
}
然后：
using (var key = myCertificate.GetECDsaPrivateKey()) {
/*PdfSigner*/ signer.SignDetached(new EcdsaSignature(key, DigestAlgorithms.SHA512), chainArray, crlList, ocspClient, tsaClient, 0, subfilter);
}
感谢@mkl 的回复，它消除了一些关于签名格式的困惑，幸运的是 Microsoft 在 SignData() 方法中支持 TLV 序列格式，所以我不必对签名过程进行逆向工程实现我想要的。虽然我只假设这个枚举是答案中描述的 TLV 序列，因为它使用不同的 RFC 或 IEEE 规范来引用它。尽管如此，它还是解决了我的问题。 （我还在驱动器 sample_signed_ecdsa_Rfc3279DerSequence.pdf 和相应的响应 JSON 中添加了一个新的 pdf。）可能默认情况下它使用 DSASignatureFormat.IeeeP1363FixedFieldConcatenation，因为指定该参数不会更改签名有效性，但指定另一个使其在 iText 7 中也有效。
现在关于互操作性，我不确定如何更改我的代码以使用 IExternalSignatureContainer。我是这个数字签名的新手，我只在他们的网站上关注了 iText 5 书和更新的 iText 7 示例，不幸的是我无法找到关于它的示例或文档，除了 API参考。
您的 ECDSA 签名中存在问题，仅 Adobe Acrobat 会忽略该问题，iText 7 不会。
有两种主要的 ECDSA 签名值编码格式：
作为两个 INTEGER 值的 TLV SEQUENCE
ECDSA-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER
}
（参见 ANSI X9.62，RFC 5480, and SEC 1: Elliptic Curve Cryptography，在 SECG 文档中由两个额外的可选值扩展）；
作为固定长度的两个整数的串联（参见 BSI TR-03111），也称为纯格式。
要使用的格式取决于应用的签名算法。例如：
- SHA512withECDSA (OID 1.2.840.10045.4.3.4) 意味着使用 TLV
SEQUENCE 格式。
- SHA512withPLAIN-ECDSA (OID 0.4.0.127.0.7.1.1.4.1.5) 意味着使用纯格式。
不幸的是，您的 ECDSA CMS 签名容器 SignerInfo 对象的 OID 为 1.2.840.10045.2.1，而签名算法应该在该位置；并且该 OID 仅仅是 ECDSA public 密钥的 OID，根本不是特定的算法标识符。在不同的验证器中，这有不同的效果：
- Adobe Acrobat 忽略 OID 作为签名算法 OID 无效的情况，并接受 TLV 和纯格式的签名。
- iText 7 忽略 OID 作为签名算法 OID 无效并假定 SHAXXXwithECDSA，即期望 TLV 编码的签名值。
- eSig DSS 认为由于 OID 作为签名算法 OID 无效而导致签名密码破损。
因此，如果您只需要您的签名被 Adobe Acrobat 和 iText 7 接受，确保 ECDSA 签名值是 TLV 格式就足够了。
另一方面，如果您希望签名更具互操作性， 更改基于 iText 7 的签名代码以使用 IExternalSignatureContainer 实现（而不是 IExternalSignature一）在其中构建正确的CMS签名容器。当心，iText 中的 ECDSA 支持是有限的；特别是，您将不得不使用隐含 TLV 格式的签名算法。
我已经使用 iText 7 创建了代码，它能够使用使用 ECDSA 密钥对的 X509 证书对给定的 PDF 进行数字签名。当我在 Acrobat Reader DC 中打开这个签名的 PDF 时，它会正确读取它，并验证它是否有效（意味着文档自签名后未被修改，等等）。
但是，当我尝试使用 iText 7 验证同一文档时，完整性和真实性检查 returns 错误。
这是一个示例代码：
// ...
PdfDocument pdfDoc = new(new PdfReader(stream));
SignatureUtil signUtil = new(pdfDoc);
IList<string> names = signUtil.GetSignatureNames();
foreach (string name in names) {
PdfPKCS7 pkcs7 = signUtil.ReadSignatureData(name);
bool wholeDocument = signUtil.SignatureCoversWholeDocument(name);
bool signatureIntegrityAndAuthenticity = pkcs7.VerifySignatureIntegrityAndAuthenticity(); // this returns false, even though Adobe has no problem verifying the signature.
// more code to read values and put them in a json
}
// ...
以及我从签名中提取的示例输出：
{
"$id": "1",
"signatures": [
{
"$id": "2",
"integrityAndAuthenticity": false, // <---- should be true in my opinion.
"revisionNumber": 1,
"coversWholeDocument": true,
"invisibleSignature": true,
"filterSubType": "ETSI.CAdES.detached",
"encryptionAlgorithm": "ECDSA",
"hashAlgorithm": "SHA512",
"nameOfSigner": "C=HU, CN=Teszt Elek, GIVENNAME=Elek, L=Budapest, O=Teszt ECC Szervezet, SN=202010260807, SURNAME=Teszt",
"alternateNameOfSigner": null,
"signDate": "2021-04-22T12:50:33Z",
"timestamp": {
"$id": "3",
"signDate": "2021-04-22T12:50:33Z",
"service": "C=HU,L=Budapest,O=Microsec Ltd.,2.5.4.97=VATHU-23584497,CN=Test e-Szigno TSA 2017 01",
"verified": true,
"hashAlgorithmOid": "2.16.840.1.101.3.4.2.3"
},
"location": " Hungary",
"reason": "Approval",
"contactInfo": "",
"name": "GUID_97e1669d-0fbe-409a-a8fc-8518a1bae460",
"signatureType": "approval",
"fillInAllowed": true,
"annotationsAllowed": true,
"fieldLocks": []
}
],
"revisions": 1,
"valid": false // is an aggregate of all the signatures integrity in the array above
}
发布时我使用的是最新的 iText 7 版本，我的平台是 ASP.NET 5 (.Net 5)。示例代码对应于 iText 自己的示例代码，它们为他们的学习书籍提供了这些代码（但更新为 7，因为这些书籍是为 iText 5 编写的）。
我正在添加示例 pdf，以及 this google drive 中签名版本的一些组合。它包含一个示例 pdf，它是未签名的和纯的。然后使用 ECDSA 和 RSA 密钥分别对该 pdf 进行签名。然后用相反类型的密钥对它们进行签名。以及他们所有的验证结果。注意：在 json 文件中 integrityAndAuthenticity 只是命名为 valid 为简洁起见，但它持有的值是 pkcs7.VerifySignatureIntegrityAndAuthenticity() 的结果。所有签名均由我的应用程序完成（使用 iText 7）。
编辑 #1： 我正在提供执行签名的代码：
using System;
using System.Security.Cryptography;
using iText.Signatures;
public class EcdsaSignature : IExternalSignature
{
private readonly string _encryptionAlgorithm;
private readonly string _hashAlgorithm;
private readonly ECDsa _pk;
public EcdsaSignature(ECDsa pk, string hashAlgorithm)
{
_pk = pk;
_hashAlgorithm = DigestAlgorithms.GetDigest(DigestAlgorithms.GetAllowedDigest(hashAlgorithm));
_encryptionAlgorithm = "ECDSA";
}
public virtual string GetEncryptionAlgorithm()
{
return _encryptionAlgorithm;
}
public virtual string GetHashAlgorithm()
{
return _hashAlgorithm;
}
public virtual byte[] Sign(byte[] message)
{
return _pk.SignData(message, new HashAlgorithmName(_hashAlgorithm), DSASignatureFormat.Rfc3279DerSequence); // <---- I have solved the iText 7 issue by providing this enum to the SignData() method.
}
}
然后：
using (var key = myCertificate.GetECDsaPrivateKey()) {
/*PdfSigner*/ signer.SignDetached(new EcdsaSignature(key, DigestAlgorithms.SHA512), chainArray, crlList, ocspClient, tsaClient, 0, subfilter);
}
感谢@mkl 的回复，它消除了一些关于签名格式的困惑，幸运的是 Microsoft 在 SignData() 方法中支持 TLV 序列格式，所以我不必对签名过程进行逆向工程实现我想要的。虽然我只假设这个枚举是答案中描述的 TLV 序列，因为它使用不同的 RFC 或 IEEE 规范来引用它。尽管如此，它还是解决了我的问题。 （我还在驱动器 sample_signed_ecdsa_Rfc3279DerSequence.pdf 和相应的响应 JSON 中添加了一个新的 pdf。）可能默认情况下它使用 DSASignatureFormat.IeeeP1363FixedFieldConcatenation，因为指定该参数不会更改签名有效性，但指定另一个使其在 iText 7 中也有效。
现在关于互操作性，我不确定如何更改我的代码以使用 IExternalSignatureContainer。我是这个数字签名的新手，我只在他们的网站上关注了 iText 5 书和更新的 iText 7 示例，不幸的是我无法找到关于它的示例或文档，除了 API参考。
您的 ECDSA 签名中存在问题，仅 Adobe Acrobat 会忽略该问题，iText 7 不会。
有两种主要的 ECDSA 签名值编码格式：
作为两个
INTEGER值的 TLVSEQUENCEECDSA-Sig-Value ::= SEQUENCE { r INTEGER, s INTEGER }（参见 ANSI X9.62，RFC 5480, and SEC 1: Elliptic Curve Cryptography，在 SECG 文档中由两个额外的可选值扩展）；
作为固定长度的两个整数的串联（参见 BSI TR-03111），也称为纯格式。
要使用的格式取决于应用的签名算法。例如：
- SHA512withECDSA (OID 1.2.840.10045.4.3.4) 意味着使用 TLV
SEQUENCE格式。 - SHA512withPLAIN-ECDSA (OID 0.4.0.127.0.7.1.1.4.1.5) 意味着使用纯格式。
不幸的是，您的 ECDSA CMS 签名容器 SignerInfo 对象的 OID 为 1.2.840.10045.2.1，而签名算法应该在该位置；并且该 OID 仅仅是 ECDSA public 密钥的 OID，根本不是特定的算法标识符。在不同的验证器中，这有不同的效果：
- Adobe Acrobat 忽略 OID 作为签名算法 OID 无效的情况，并接受 TLV 和纯格式的签名。
- iText 7 忽略 OID 作为签名算法 OID 无效并假定 SHAXXXwithECDSA，即期望 TLV 编码的签名值。
- eSig DSS 认为由于 OID 作为签名算法 OID 无效而导致签名密码破损。
因此，如果您只需要您的签名被 Adobe Acrobat 和 iText 7 接受，确保 ECDSA 签名值是 TLV 格式就足够了。
另一方面，如果您希望签名更具互操作性， 更改基于 iText 7 的签名代码以使用 IExternalSignatureContainer 实现（而不是 IExternalSignature一）在其中构建正确的CMS签名容器。当心，iText 中的 ECDSA 支持是有限的；特别是，您将不得不使用隐含 TLV 格式的签名算法。