bcgit
org.bouncycastle.crypto.fips.FipsSelfTestFailedError: KAT signature incorrect: DSA
Recently we upgraded our bc-fips from 1.0.2.5 to 2.0.0. That went really smooth, everything works, except for one platform where we are seeing a regression. This is a System Z (s390x) Red Hat Enterprise Linux Server running IBM Java 8. The issue occurs in our product when writing a BCFKS keystore; first thing that it does is get a Mac, so that is easier to test. Below is code that reproduces the issue. It looks like the signature check of the bc-fips jar (DSA) and the self-test are interfering with each other.
Fortunately, we also accidentally stumbled upon a workaround. If you uncomment line 7, the issue no longer occurs. That means that this issue is not urgent for us.
- Can you confirm this is a regression in bc-fips 2.0.0?
- Do you see any ill effects that the workaround may have?
- Do you see other solutions to avoid the KAT failure?
Regards,
Arnold Geels Rocket Software
import java.security.Security;
import javax.crypto.Mac;
import org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider;
public class Report {
public static void main(String[] args) throws Exception {
// int ignored = javax.crypto.Cipher.getMaxAllowedKeyLength("AES");
Security.insertProviderAt(new BouncyCastleFipsProvider(), 1);
Mac m = Mac.getInstance("HmacSHA512");
}
}
Exception in thread "main" org.bouncycastle.crypto.fips.FipsSelfTestFailedError: KAT signature incorrect: DSA
at org.bouncycastle.crypto.fips.SelfTestExecutor.validate(SelfTestExecutor.java:37)
at org.bouncycastle.crypto.fips.FipsDSA$DsaProvider.createEngine(FipsDSA.java:894)
at org.bouncycastle.crypto.fips.FipsDSA$DsaProvider.createEngine(FipsDSA.java:885)
at org.bouncycastle.crypto.fips.FipsDSA.<clinit>(FipsDSA.java:63)
at org.bouncycastle.jcajce.provider.ProvDSA$7.createInstance(ProvDSA.java:189)
at org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider$BcService.newInstance(BouncyCastleFipsProvider.java:815)
at sun.security.jca.GetInstance.getInstance(GetInstance.java:248)
at sun.security.jca.GetInstance.getInstance(GetInstance.java:230)
at java.security.Signature.getInstance(Signature.java:441)
at org.bouncycastle.jcajce.util.ProviderJcaJceHelper.createSignature(ProviderJcaJceHelper.java:117)
at org.bouncycastle.jcajce.provider.X509CertificateImpl.verify(X509CertificateImpl.java:574)
at javax.crypto.b.a(Unknown Source)
at javax.crypto.b.access$500(Unknown Source)
at javax.crypto.b$a.run(Unknown Source)
at java.security.AccessController.doPrivileged(AccessController.java:747)
at javax.crypto.b.<clinit>(Unknown Source)
at javax.crypto.Mac.getInstance(Unknown Source)
at Report.main(Report.java:9)
$ arch
s390x
$ java -version
java version "1.8.0_351"
Java(TM) SE Runtime Environment (build 8.0.7.20 - pxz6480sr7fp20-20221020_01(SR7 FP20))
IBM J9 VM (build 2.9, JRE 1.8.0 Linux s390x-64-Bit Compressed References 20220929_37824 (JIT enabled, AOT enabled)
OpenJ9 - 02180fe
OMR - 48fc32a
IBM - bf759bf)
JCL - 20220922_01 based on Oracle jdk8u351-b10
It's the IBM JVM - it doesn't convert byte arrays to big integers the same way as the Oracle one does, it seems this change was introduced sometime during there Java 7 cycle. I would classify it as a regression... sorry... it will be fixed in the next release.
I think the work around is probably okay - it's a bit odd, but I think what is happening it's forcing a jar validation which is instancing the DSA algorithm from the Oracle JVM, this probably means the same DSA implementation is also used for validating the JCE signature on the bc-fips jar. This whole process is outside of FIPS, so I doubt it would be treated as relevant - for FIPS it is the module checksum that matters. As that's the case the BC DSA implementation would then only be self-tested if it was used somewhere else.
