我正在研究用 Java 实现 C# SignedCms 功能。

我正在使用 bouncycaSTLe 库。 问题是我得到的 java 签名与使用 SignedCms 生成的签名不同。

C#代码

X509Certificate2 certificate = new X509Certificate2("myCertPath", "myPass"); 
String text = "text"; 
ContentInfo contentInfo = new ContentInfo(System.Text.Encoding.UTF8.GetBytes(text)); 
SignedCms cms = new SignedCms(contentInfo, false); 
CmsSigner signer = new CmsSigner(certificate); 
signer.IncludeOption = X509IncludeOption.None; 
signer.DigestAlgorithm = new Oid("SHA1"); 
cms.ComputeSignature(signer, false); 
byte[] signature = cms.Encode(); 
print(signature); 

Java代码

Security.addProvider(new BouncyCastleProvider()); 
char[] password = "myPass".toCharArray(); 
String text = "text"; 
FileInputStream fis = new FileInputStream("myCertPath"); 
KeyStore ks = KeyStore.getInstance("pkcs12"); 
ks.load(fis, password); 

String alias = ks.aliases().nextElement(); 
PrivateKey pKey = (PrivateKey)ks.getKey(alias, password); 
X509Certificate cert = (X509Certificate)ks.getCertificate(alias); 
java.util.List certList = new ArrayList(); 
Store certs = new JcaCertStore(certList); 

CMSSignedDataGenerator gen = new CMSSignedDataGenerator(); 
JcaSimpleSignerInfoGeneratorBuilder builder = new JcaSimpleSignerInfoGeneratorBuilder().setProvider("BC").setDirectSignature(true); 

gen.addSignerInfoGenerator(builder.build("SHA1withRSA", pKey, cert)); 
gen.addCertificates(certs); 

CMSTypedData msg = new CMSProcessableByteArray(text.getBytes()); 
CMSSignedData s = gen.generate(msg, false); 
print(s.getEncoded()); 

它们都不包含 x509 证书。

C#生成的签名

长度=434 308201AE06092A864886F70D010702A082019F3082019B020101310B300906052B0E03021A0500301306092 A864886F70D010701A006040474657874318201723082016E0201013081CB3081B6310B3009060355040613 02555331173015060355040A130E566572695369676E2C20496E632E311F301D060355040B1316566572695 369676E205472757374204E6574776F726B313B3039060355040B13325465726D73206F6620757365206174 2068747470733A2F2F7777772E766572697369676E2E636F6D2F7270612028632930393130302E060355040 31327566572695369676E20436C617373203320436F6465205369676E696E6720323030392D322043410210 1763F9A88334A01FFB3B7BAB384A9B93300906052B0E03021A0500300D06092A864886F70D0101010500048 1800B866A9A7045E3C86E5DB69CDAD5CED211A4A2362BCC4DDB2742BF0CDB65BC88556C97A6C08D68F8070D 89CC78ACD84A636F15B40D166E461411C6A04D5EC379283988DA4258B684FFEF9F08B293A03A0B40900E245 874D8C0587BBD58BDD915A50D27456E6EEB883846CAC485853BA5E22E45D333C940A958E641A00C9602B9

Java 生成签名

长度=428 308006092A864886F70D010702A0803080020101310B300906052B0E03021A0500308006092A864886F70D0 107010000318201723082016E0201013081CB3081B6310B300906035504061302555331173015060355040A 130E566572695369676E2C20496E632E311F301D060355040B1316566572695369676E205472757374204E6 574776F726B313B3039060355040B13325465726D73206F66207573652061742068747470733A2F2F777777 2E766572697369676E2E636F6D2F7270612028632930393130302E06035504031327566572695369676E204 36C617373203320436F6465205369676E696E6720323030392D3220434102101763F9A88334A01FFB3B7BAB 384A9B93300906052B0E03021A0500300D06092A864886F70D01010105000481800B866A9A7045E3C86E5DB 69CDAD5CED211A4A2362BCC4DDB2742BF0CDB65BC88556C97A6C08D68F8070D89CC78ACD84A636F15B40D16 6E461411C6A04D5EC379283988DA4258B684FFEF9F08B293A03A0B40900E245874D8C0587BBD58BDD915A50 D27456E6EEB883846CAC485853BA5E22E45D333C940A958E641A00C9602B9000000000000

我被困在这个问题上。

更新

Java 输出是 BER 编码的。我需要 DER 编码签名。为了将 BER 转换为 DER，我使用了

ByteArrayOutputStream bOut = new ByteArrayOutputStream();
DEROutputStream dOut = new DEROutputStream(bOut);
dOut.writeObject(s.toASN1Structure().toASN1Primitive());
dOut.close();
bytep[ encoded = bOut.toByteArray();

现在输出相同。

最佳答案

好消息:没有问题。

查看 ASN.1 DER 编码

查看两个生成的 DER 编码的开头:

C#:   308201AE...
Java: 3080...

C#编码是定长形式，即30表示一个SEQUENCE，82表示使用后面两个字节的定长编码, 而01AE是430的实际长度值。后面的430个字节加上目前读取的4个字节共计434个字节。

另一方面，Java 编码的不同之处在于它表示不定长度编码(80)。严格来说，这已经不是DER编码而是BER编码了。这意味着没有为该元素给出明确的长度，而是该元素以特殊的 END OF CONTENTS 元素结尾，该元素被编码为 0000。您会在 Java 编码的末尾注意到其中的很多。更多详情请参见 this guide BER/DER。

这两个结构的其余部分完全相同，甚至是签名值本身。只是Java版本使用的是不定长，而C#版本使用的是定长。如果验证方理解 BER 和 DER 编码，则这两个签名在编码之前将是相同的。并且编码不会在签名验证过程中发挥作用。这是 CMS RFC 的内容对此表示:

signedAttrs 存在:

Specifically, the initial input is the encapContentInfo eContent OCTET STRING to which the signing process is applied. Only the octets comprising the value of the eContent OCTET STRING are input to the message digest algorithm, not the tag or the length octets.

没有signedAttrs:

When the signedAttrs field is absent, only the octets comprising the value of the SignedData encapContentInfo eContent OCTET STRING (e.g., the contents of a file) are input to the message digest calculation. This has the advantage that the length of the content being signed need not be known in advance of the signature generation process.

换句话说:只有包含 eContent 实际值的字节被散列，实际上只有那些。在这个过程中，它的标签和它的长度以及它的 block 的标签和长度(在不确定构造的编码的情况下)都不能被散列。我承认，有些实现会出错，这显然是一个相当复杂的问题。

为什么在 CMS SignedData 中使用不定长度？

虽然它增加了很多复杂性和互操作性问题，但出于一个原因(除了小几个字节之外)它是有意义的:如果您生成“附加签名”(原始文档嵌入在 中的签名) EncapContentInfo 元素)，选择不定长度允许您以流方式创建和验证签名:您可以逐 block 读取或写入。而对于确定的长度，您必须一次读/写整个内容，因为您需要提前知道长度才能创建 DER 编码的最终标签-长度-值格式。能够进行流式 IO 的想法在这种情况下非常强大:想象一下，您想要创建一个几 GB 大的日志文件的附加签名 - 任何非流式方法都会很快耗尽内存。

Bouncy CaSTLe 的 Java 版本不久前在 CMS 上下文中添加了流式支持，很可能在 C# 版本接受它之前不会太久。

关于c# - C# SignedCms 的 Java 实现，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/11013111/