Repository navigation
Degraded performance loading BCFKS key stores with Corretto 1.8 JDK configured with bc-fips-1.0.2.3.jar #1273
Description
We are observing that loading an Amazon Corretto JDK 1.8 cacerts file of type BCFKS is significantly slower when the JDK is configured with bc-fips-1.0.2.3.jar vs when it was previously configured with bc-fips-1.0.1.jar.
Approximate load times for loading the store averaged 4s with the v1.0.2.3 jar, and just over 1s with the v1.0.1. This was observed using a simple Java program that loaded a key store in memory.
What could be the reason for why the load time is significantly more when using the newer version of the BC FIPS jar?
Thank you,
-Jayesh
LoadKeyStore.txt
With v1.0.2.3.jar
Wed Nov 2 21:24:19 UTC 2022
Start: {2022-11-02 21:24:19.333}
Key store successfully loaded.
End: {2022-11-02 21:24:23.400}
Time: {4067ms}
real 0m4.150s
user 0m6.330s
sys 0m0.277s
Wed Nov 2 21:24:23 UTC 2022
with v1.0.1.jar
Wed Nov 2 21:24:08 UTC 2022
Start: {2022-11-02 21:24:08.245}
Key store successfully loaded.
End: {2022-11-02 21:24:09.304}
Time: {1059ms}
real 0m1.139s
user 0m2.760s
sys 0m0.112s
Wed Nov 2 21:24:09 UTC 2022
Activity
dghgit commentedon Nov 10, 2022
I can't think of a reason for this off the top of my head, except possibly to do with entropy usage... I'll need to try it and investigate.
jnaithani commentedon Nov 10, 2022
Thanks David - let me know if you need more information from me or have questions. We are still continuing to profile and review this issue at our end.
Also - the entropy value on the linux host where I performed the load test.
->sudo cat /proc/sys/kernel/random/entropy_avail
256
-Jayesh
jnaithani commentedon Nov 11, 2022
@dghgit @peterdettman
Some additional info:
->uname -a
Linux *.amzn2.x86_64 #1 SMP Wed Oct 26 20:36:53 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
->java -version
openjdk version "1.8.0_342"
OpenJDK Runtime Environment Corretto-8.342.07.4 (build 1.8.0_342-b07)
OpenJDK 64-Bit Server VM Corretto-8.342.07.4 (build 25.342-b07, mixed mode)
JDK statically configured:
/usr/lib/jvm/java-1.8.0-amazon-corretto/jre/lib/ext/bc-fips-debug-1.0.2.3.jar
java.security:
security.provider.1 = org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider
security.provider.2 = com.sun.net.ssl.internal.ssl.Provider BCFIPS
securerandom.source = file:/dev/random
#securerandom.strongAlgorithms = NativePRNGBlocking:SUN
securerandom.strongAlgorithms = DEFAULT:BCFIPS
--
Time: {4088ms}
Changing the java.security property: securerandom.strongAlgorithms = NativePRNGBlocking:SUN, and re-running the same test results in much faster load time
Time: {1354ms}
With the bc-fips-1.0.1.jar file in jre/lib/ext - the keystore load time remains faster regardless of the values for securerandom.strongAlgorithms
Time: {1139ms} //securerandom.strongAlgorithms = NativePRNGBlocking:SUN
Time: {1115ms} //securerandom.strongAlgorithms = DEFAULT:BCFIPS
Also, with the JDK configured with bc-fips-10.2.3.jar and the following -Djava.security.debug="provider,engine=SecureRandom" setting, we see a number of repeated lines in the output - with securerandom.strongAlgorithms = DEFAULT:BCFIPS.
Provider: SecureRandom.DEFAULT algorithm from: BCFIPS
Provider: SecureRandom.null algorithm from: BCFIPS_RNG
And profiling the execution with the same settings and the newer bc-fips lib (v1.0.2.3), it appears there were 35K exceptions being thrown - and that seems to be difference between when executing with older bc-fips (v1.0.1) in place.
dghgit commentedon Nov 12, 2022
The setting for securerandom.strongAlgorithms is wrong, it needs to be changed back to the default. With this setting the JVM will fall back to using the threaded seed generator for gathering entropy.
1.0.1 did not use the securerandon.strongAlgorithms property. Which is why setting it incorrectly made no difference.
jnaithani commentedon Nov 12, 2022
@dghgit Thanks David.
To be clear, we need to set the securerandom.strongAlgorithims property value back to: NativePRNGBlocking:SUN.
Setting the value (like we have currently) to: DEFAULT:BCFIPS is incorrect. Is it incorrect, because the value is not valid, or is it because it is a valid value but an incorrect choice?
Also, would you be able to suggest additional sources of information to better understand the algorithm choices for securerandom.strongAlgorithms? At the moment, we are not sure why the JDK was being configured with DEFAULT:BCFIPS as the secure random algorithm (or if this is a valid value), other than from information in Section 2.3 of the BC-FJA-UserGuide and in the Configuring a Default SecureRandom section of the BCFipsIn100.pdf guide.
dghgit commentedon Nov 12, 2022
Yes, it should be: NativePRNGBlocking:SUN.
Strictly speaking it would be an incorrect choice. We do not suggest changing securerandom.strongAlgorithims anywhere in our documentation, at least that I'm aware of. As far as the actual setting goes, other the documentation that comes with the JDK I can't recommend anything else. Probably the most relevant thing is the seed generator for securerandom.strongAlgorithims is used as the seed generator for the DRBG's created by the module, so you can use the setting to make alternative sources of entropy available to the module.
dghgit commentedon Nov 20, 2022
Assuming now resolved.
jnaithani commentedon Nov 21, 2022
@dghgit Yes - issue resolved after reverting back to JDK default secure random algorithm. Thank you David.