FIPS 140-3 Compliance Questions - BouncyCastle FIPS Provider Configuration

[nikhil-deshmukh-1]

Hello,

I am implementing FIPS 140-3 compliance in our Java application and have encountered several configuration challenges
with the Bouncy Castle FIPS provider. I would greatly appreciate your technical guidance on the following issues:

Environment Details

• Java Version: openjdk version : "21.0.3" 2024-04-16 LTS
• Bouncy Castle FIPS Version: 2.1.0
• Operating System: Windows/Linux
• Application Type: Enterprise Java application requiring FIPS 140-3 compliance
• Used approved mode : -Dorg.bouncycastle.fips.approved_only=true -Djava.security.properties==%MYAPP%\Fips\java.security

java.security Configuration Setup:
I have configured the java.security file with Bouncy Castle FIPS provider as the primary providers in the following order:

security.provider.1=org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider
security.provider.2=org.bouncycastle.jsse.provider.BouncyCastleJsseProvider fips:BCFIPS
security.provider.3=SUN
security.provider.4=SunRsaSign
security.provider.5=SunEC
security.provider.6=SunJSSE
security.provider.7=SunJCE
security.provider.8=SunJGSS
security.provider.9=SunSASL
security.provider.10=XMLDSig
security.provider.11=SunPCSC
security.provider.12=JdkLDAP
security.provider.13=JdkSASL
security.provider.14=SunMSCAPI
security.provider.15=SunPKCS11

Issue 1: Unexpected MD5 Algorithm Availability in FIPS Mode

Problem: Despite this configuration, the MD5 algorithm is still accessible:

// This works unexpectedly

try {
    MessageDigest md = MessageDigest.getInstance("MD5");
    md.update("test".getBytes());
    byte[] digest = md.digest();
    System.out.println("  UNEXPECTED SUCCESS: MD5 worked but should be blocked in FIPS mode");
    System.out.println("  Provider used: " + md.getProvider().getName());
} catch (Exception e) {
    System.out.println("  EXPECTED FAILURE: " + e.getClass().getName());
    System.out.println("  Error: " + e.getMessage());
}

Result : MD5 worked successfully

Question: Why is MD5 still available when using BouncyCastle FIPS as the primary provider?
Should this not be blocked for FIPS compliance?

Issue 2: Inconsistent Behavior with Non-Approved Algorithms

Test Case: When testing other non-FIPS-approved algorithms:

try {
    System.out.println("\n1. Test: AES/EAX/PKCS5Padding");
    Cipher cipher = Cipher.getInstance("AES/EAX/PKCS5Padding");

    System.out.println("  $SUCCESS: Generated AES/EAX/PKCS5Padding cipher");
    System.out.println("  $Provider used: " + cipher.getProvider().getName());
} catch (Exception e) {
    System.out.println("  $FAILED: " + e.getClass().getName());
    System.out.println("  $Error: " + e.getMessage());
}

Result: This correctly throws java.security.NoSuchAlgorithmException as expected.

Question: Is MD5 the only non-approved algorithm that works unexpectedly,
or are there other exceptions?
Does the BCFIPS provider automatically handle most non-approved algorithms by throwing NoSuchAlgorithmException?

Issue 3: Stack Overflow exception when using only BCFIPS Provider

Scenario: When I attempt to remove the "SUN" provider to ensure full FIPS 140-3 compliance (using only BCFIPS provider),
the application encounters a stack overflow exception.

try {
    Cipher cipher2 = Cipher.getInstance("AES/CBC/PKCS5Padding");
} catch (Exception e) {
    System.out.println("  Error " + e.getClass().getName());
    System.out.println("  Error " + e.getMessage());
}

Exception in thread "main" java.lang.StackOverflowError
        at java.base/java.util.regex.Pattern$BmpCharPropertyGreedy.match(Pattern.java:4502)
        at java.base/java.util.regex.Pattern$BranchConn.match(Pattern.java:4878)
        at java.base/java.util.regex.Pattern$GroupTail.match(Pattern.java:5000)
        at java.base/java.util.regex.Pattern$GroupTail.match(Pattern.java:5000)
        at java.base/java.util.regex.Pattern$CharPropertyGreedy.match(Pattern.java:4470)
        at java.base/java.util.regex.Pattern$GroupHead.match(Pattern.java:4969)
        at java.base/java.util.regex.Pattern$BmpCharProperty.match(Pattern.java:4134)
        at java.base/java.util.regex.Pattern$GroupHead.match(Pattern.java:4969)
        at java.base/java.util.regex.Pattern$Branch.match(Pattern.java:4914)
        at java.base/java.util.regex.Pattern$GroupTail.match(Pattern.java:5000)
        at java.base/java.util.regex.Pattern$CharPropertyGreedy.match(Pattern.java:4470)
        at java.base/java.util.regex.Pattern$GroupHead.match(Pattern.java:4969)
        at java.base/java.util.regex.Pattern$BmpCharPropertyGreedy.match(Pattern.java:4509)
        at java.base/java.util.regex.Matcher.match(Matcher.java:1794)
        at java.base/java.util.regex.Matcher.matches(Matcher.java:754)
        at java.base/java.security.SecureRandom.getInstanceStrong(SecureRandom.java:959)

Question: Is there a proper way to configure the system to use
exclusively the Bouncy Castle FIPS provider without causing system instability?
Does Bouncy Castle Fips Provider need SUN provider?

Issue 4: Ensuring True FIPS Compliance

Concern: If I maintain the SUN provider alongside the Bouncy Castle FIPS provider as primary provider,
there's a risk that the application may fall back to non-FIPS compliant implementations,
potentially violating FIPS 140-3 requirements.

Question: What is the recommended approach to ensure that the application uses only FIPS-approved implementations
from Bouncy Castle and never falls back to default JDK providers?
Is there a configuration method to enforce strict FIPS-only mode?

Thank you, your guidance will really help us for ensuring our application meets FIPS 140-3 compliance requirements.

[roy-basmacier]

Hello @nikhil-deshmukh-1,

Issue 1 and 2

Make sure the jca is using the BCFIPS provider. There is a table of non-approved algorithms allowed in the approved mode of operation.

Issue 3

This happens because BCFIPS is a software provider and it cannot generate it's own entropy.

Issue 4

When calling the API specify the provider name.
Cipher cipher2 = Cipher.getInstance("AES/CBC/PKCS5Padding", "BCFIPS");

~ Roy