java - 使用较新版本的 Bouncy CaSTLe 时，接收方无法验证 SMIME

Question

我正在使用 BC 加密和签署用于 AS2 的 SMIME 消息。我们的代码适用于绝对古老的充气城堡版本 bcmail-1.4:125。升级到更新的版本会导致消息的接收者(不是太古老的 Cyclone 服务器)无法验证消息。 (例如 maven 中最早的 v 也会导致此问题。这些是没有 API 更改的版本(例如 1.38)。

自从我们使用 JDK 1.7(和 1.8)以来，我一直在尝试将它更新到更新版本的 BC、java-mail 等。我已经将所有的充气城堡升级到 bcmail-jdk15on: 1.51 和 bcprov-jdk15on:1.51，以及 java 邮件，并遵循 bcmail 包中的示例。但是，我仍然收到 Cyclone 的错误消息，提示 integrity-check-failed。

我相当确定错误出在我的签名方式上。当我禁用签名并仅使用加密时，它会正确处理。此外，我可以正确地从远程服务器接收签名的响应并验证签名，这就是我获取错误消息的方式(从 MimeMultiPart 上的内容配置)。

• 证书由openssl/self signed/etc创建，保存在pkcs12文件中
• 无限强度政策到位
• senderKey 是一个 BCRSAPrivateCrtKey
• senderCert
  • org.bouncycaSTLe.jcajce.provider.asymmetric.x509.X509CertificateObject

失败:当前代码是这样的，使用bcmail-jdk15on:1.51 & etc

SMIMESignedGenerator gen = new SMIMESignedGenerator();
gen.addSignerInfoGenerator(new JcaSimpleSignerInfoGeneratorBuilder()
           .setProvider("BC")
           .build("SHA1withRSA", senderKey, senderCert));
// gen.addCertificates(new JcaCertStore(list(senderCert))); old v. doesn't add certs
MimeMultipart smime = gen.generate(part); // MimeBodyPart passed in to function
MimeBodyPart tmpBody = new MimeBodyPart();
tmpBody.setContent(signedData);
tmpBody.setHeader("Content-Type", signedData.getContentType()

以前的工作代码 看起来像这样并使用 bcmail-1.4:1.25。升级到 1.3x 也会导致另一端在解密时失败(无论我在哪个 jdk 上运行，1.6 - 1.8)

MimeBodyPart body = new MimeBodyPart();
body.setDataHandler(new DataHandler(new ByteArrayDataSource(bytes[], contentType, null);));
SMIMESignedGenerator sGen = new SMIMESignedGenerator();
// SHA1 resolves to "1.3.14.3.2.26", FWIW
sGen.addSigner(senderKey, senderCert, getBouncyCastleAlgorithmId("SHA1"));
MimeMultipart signedData = sGen.generate(part, "BC");
// this is then encrypted & streamed, no issues there

通用设置代码

byte[] data = Files.readAllBytes(filePath);
MimeBodyPart part = new MimeBodyPart();
ByteArrayDataSource dataSource = new ByteArrayDataSource(data, "application/EDIFACT", null);
part.setDataHandler(new DataHandler(dataSource));
part.setHeader("Content-Transfer-Encoding", "8bit");
part.setHeader("Content-Type", "application/EDIFACT");

我感觉这与我添加(或操作)senderCert 的方式有关，它是本地应用程序的 X509。

更新

我通过删除证书使新代码与旧代码更加一致:

• 签名消息中不再包含证书。旧版本没有
• 整个 mime 多部分内容现在完全与以前相同的长度(1095 字节)
• 格式(标题等)现在完全相同
• 签名部分现在几乎相同。但是，有一部分似乎会根据时间(？？？)而变化，并且每次都会发生变化。我还无法让 openssl 验证此消息，不知道为什么。

这是示例输出，FWIW。 [] 中的文本是唯一发生变化的部分。

------=_Part_1_1448572667.1409621469842
Content-Type: application/EDIFACT
Content-Transfer-Encoding: 8bit

this is a test

------=_Part_1_1448572667.1409621469842
Content-Type: application/pkcs7-signature; name=smime.p7s; smime-type=signed-data
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAMYIBpDCCAaAC
AQEwgZ4wgZAxCzAJBgNVBAYTAmNuMREwDwYDVQQIDAhzaGFuZ2hhaTESMBAGA1UEBwwJY2hhbmdu
aW5nMREwDwYDVQQKDAhwb3dlcmUyZTEOMAwGA1UECwwFaXRkZXYxEjAQBgNVBAMMCWFiLWNsaWVu
dDEjMCEGCSqGSIb3DQEJARYUYWItY2xpZW50QG15Q29ycC5jb20CCQClDAGwq37A/jAJBgUrDgMC
GgUAoF0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwOTAyMDEz
M[TA5]WjAjBgkqhkiG9w0BCQQxFgQUG6KkoqPBvE7Kd9dB0eop/aUTya0wDQYJKoZIhvcNAQEBBQAE
gYB[h9N4maow9aoTQ8QBGgXEYE+xgXSmRPy+ufIsMpuS0Yys/1t3AfXSSI7WKgLMRKYXve8gdb4Gn
dqecHzkBwBq4hebt9YK+E30E6DpZpCwErsgDVaU/ExBA5gauPWneysy+s2bE5Y6pNZ7Qf3kGU5kI
UjlOF/LUNkCsgT5z//]5N6QAAAAAAAA==
------=_Part_1_1448572667.1409621469842--

Answer 1

经过大量的debug、dump文件等，证明了和digest计算有一定关系。在签名正文部分的特定位置是内容 MIC(摘要的 base64)。不知何故，这个值与另一方所做的不匹配......

一旦我知道了，并且在谷歌上又花了一些时间，我终于找到了 more information on sourceforge 来确认这一点。很有帮助，因为它提到了我的特定版本的 BC。引用:

The problem is that BC >= 1.27 will "canonicalize" all messages that are not sent with content-transfer-encoding binary.

What does this mean?

In the S/MIME rfc it says that all messages should be converted to a "canonical" form before computing the MIC. The "canonical" form for text messages is that EOL is indicated by CR, LF. The rfc's are silent on what the canonical form for other content types is. Many S/MIME implementations (e.g. openssl, Bouncy Castle after 1.27) incorrectly assume that the canonical form for all messages except those sent with content-transfer-encoding binary is that every LF should be preceeded by a CR.

So if a BC 1.25 used sends a message including bare LF characters then the MIC validation will fail if the message is received by an application using BC >= 1.27, or openssl smime, or many other S/MIME implementations.

OpenAS2 should be fixed to use content-transfer-encoding binary.

只有在 MIME 正文部分上设置编码时，这才有效。我已经通过执行 JCA 路由验证了相同的结果(在服务器上失败)手动，轻量级路线，还有CMS路线。

根据这些信息，我对发件人做了一个简单的更改....

MimeBodyPart part = //.. make mime body part from file
part.setHeader("Content-Transfer-Encoding", "binary");

有趣的是，改变任何与 SMIMESignedGenerator() 相关的东西似乎都没有效果:

gen = SMIMESignedGenerator("binary");  // nothing, even though the docs say to set this

对于任何感兴趣的人，我的最终签名函数如下所示:

SMIMESignedGenerator gen = new SMIMESignedGenerator();
SignerInfoGenerator sigGen = new JcaSimpleSignerInfoGeneratorBuilder()
        .setProvider(BC)
        .build("SHA1withRSA", senderKey, senderCert);
gen.addSignerInfoGenerator(sigGen);
MimeMultipart smime = gen.generate(part);
MimeBodyPart tmpBody = new MimeBodyPart();
tmpBody.setContent(smime);
tmpBody.setHeader("Content-Type", smime.getContentType());
return tmpBody;

原始文件只有一行:

this is a test

被签名的输入是这样的:

Content-Type: application/EDIFACT
Content-Transfer-Encoding: binary

this is a test

调试信息:

data bytes:
436F6E74656E742D547970653A206170706C69636174696F6E2F454449464143540D0
A436F6E74656E742D5472616E736665722D456E636F64696E673A2062696E6172790D
0A0D0A74686973206973206120746573740A

digest mic: {
   "algorithmId":   "1.3.14.3.2.26"
   "digest bytes":  "CEC2C6614A481DFDF45C801FD6F2A51BC53D3FDF"
   "digest base64": "zsLGYUpIHf30XIAf1vKlG8U9P98="
}

Not 这不附加签名，或添加任何功能，并使用 v1 x509 证书。现在一切都恢复正常了，我可能会改变这些东西。

我真的希望所有这一切都更加透明......BC 在内部是间接的间接的，虽然我明白为什么。它在内部仍然比旧版本好。我不能说我没有找到很多示例，但是 BC 测试用例似乎不是最好的(例如，我找不到一个在之后根据预期摘要值进行验证的测试用例SMIME'ing。也许我错过了)