BCFips relies on the SUN provider SecureRandom, But The SUN provider makes my application non compliant

[mgrundie-r7]

I am trying to configure my Java application security providers in a FIPS compliant way. If I remove all of the default providers and include only the FIPS 2.0.0 BC JCE and JSSE providers then the application crashes with a stackoverflowerror because it relies on the SUN provider's secure random. (See #1800)

If I place the BC providers at the highest positions (1&2) then my application works. However unapproved algorithms are now available to my application and the 3rd party dependencies I rely on. One such example is MD5 being used by AWS SDK.

What is the correct way to configure my application so that BC SecureRandom doesn't crash but my application cannot access unapproved algorithms.

Example 1 - Crashes with StackOverflowError

// Remove default providers
log.debug("Removing default security providers");
for (var provider : Security.getProviders()) {
  log.trace("Removing provider {}", provider);
  Security.removeProvider(provider.getName());
}

Security.insertProviderAt(new BouncyCastleFipsProvider(), 1);
Security.insertProviderAt(new BouncyCastleJsseProvider(), 2);

Example 2 - MD5 available from SUN provider - We don't want this

assert(CryptoServicesRegistrar.isInApprovedOnlyMode() == true)

try {
    Security.insertProviderAt(new BouncyCastleFipsProvider(), 1);
    Security.insertProviderAt(new BouncyCastleJsseProvider(), 2);
    MessageDigest digest = MessageDigest.getInstance("md5");
    assert(digest.getProvider().getName().equals("SUN"));
  } catch (NoSuchAlgorithmException e) {
    throw new RuntimeException(e);
 }

[dghgit]

Actually at the moment MD5 is allowed as a cryptographic hash where it is used in a TLS hand shake. No other situation though, meaning no other "security related" situation. If you want to use MD5 in a Bloom Filter or a Hashtable, feel free to knock yourself out...

So, it's not MD5 that's being available that's the problem, it's people using for security related tasks. That's the thing with FIPS compliance, it's about using a FIPS certified module in conformance with the module's security policy. NIST sign off on the security policy. Your app will be non-compliant if it's doing things not allowed by the security policy (which does include using algorithms in the module in a compliant fashion and not dragging other (non-entropy related) services from else where). Module developers are supposed to block non-approved things in approved mode where possible, but there are still some things that can only get covered by the security policy.

You can also implement your own SecureRandom provider if you wish and set securerandom.strongAlgorithms to point to it if you wish to get rid of the SUN provider altogether. We're working on one that uses JENT at the moment, but that's a different story. One that simply pulls data out of "/dev/hwrng" or "/dev/random" would be very simple to write. Just keep in mind if you do this, compliance with SP 800-90B is starting to become a "real thing" so it would be a good idea to pay attention to that and the nature of the OS's entropy provision if you do that.

[mgrundie-r7]

Thanks for the response here and in the issue I commented on. Your answers clear things up for me. Basically we (devs using BC FIPS) need to be more thoughtful rather than expecting that using FIPs certified providers will make us FIPS compliant.