FIPS 140-3 variant

What ships in the FIPS variant

The FIPS variant is a build-time-hardened Eliya JDK 25 image, not a runtime toggle. When you install eliya-jdk-fips, the following differences from the standard eliya-jdk variant are baked into the image:

• Bouncy Castle FIPS provider (BC-FJA 2.1.1, CMVP cert #4943) pre-registered as the JCE provider at slot 1 in ${JAVA_HOME}/conf/security/java.security.
• SunJCE excluded from java.base at build time (the class is not on the shipped module path; user code cannot re-register it via classpath). Related legacy providers (SunEC's non-FIPS surface, SunRsaSign non-FIPS paths) are similarly excluded per the cascade-breakage analysis in the FIPS integration research note.
• Patched java.security.Security: addProvider, insertProviderAt, and removeProvider refuse mutations that would add a non-FIPS provider or remove a FIPS provider. Runtime provider-list attacks (including reflection-based ones) throw SecurityException.
• BC-FJA approved-only mode engaged (org.bouncycastle.fips.approved_only=true) from an Eliya-owned system property that user launcher args cannot override.
• security.overridePropertiesFile=false baked into the shipped java.security. User cannot swap providers via -Djava.security.properties=<file>.
• java -version banner and release file's IMPLEMENTOR_VERSION both mark the FIPS variant unambiguously for procurement records.

Certificate details

Interim Validation caveat

NIST records cert #4943 with the following caveat verbatim on the certificate detail page:

"Interim Validation. When operated in approved mode. The module generates SSPs (e.g., keys) whose strengths are modified by available entropy."

The caveat carries two operator responsibilities that Eliya's variant addresses on your behalf:

1. Operated in approved mode. The cert applies only when BC-FJA is configured in FIPS-approved mode. Eliya's FIPS variant ships pre-configured for approved mode; the configuration is baked into the image and cannot be flipped by user launcher arguments.
2. SSPs (keys) with strengths modified by available entropy. Cryptographic strength of Sensitive Security Parameters generated by the module depends on entropy available at generation time. This is an operator responsibility: ensure your deployment target (VM, container, embedded system) has an adequate entropy source (hardware RNG, sufficient boot entropy, non-blocking /dev/urandom configured correctly). Low-entropy environments may produce weaker-than-nominal keys even under a validated module.

Compliance officers doing buyer-side due diligence will read the cert page and see this caveat. We document it here verbatim to close that diligence path without surprises.

Sunset commitment

Cert #4943 sunsets 2027-01-16. Eliya's commitment: 25.0.6 (Q1 2027 CPU release, target 2027-02-02) transitions the FIPS variant to whichever new BC-FJA cert (2.1.2 or 2.1.3) is by then issued by the CMVP lab.

Bouncy Castle confirmed to us on 2026-08-18 that both 2.1.2 and 2.1.3 are with the lab and both are tested on Java 25 (which addresses the G.5 affirmation gap for JDK 25 operational environment). The estimated lab timeline is 10-12 weeks. Final validation will issue a new certificate number; #4943's interim status ends at that point.

If the CMVP lab process runs longer than the estimate and the new cert has not issued by 25.0.6's Q1 2027 window, Eliya has three fallback paths (in order of preference):

1. Extend #4943 in Eliya 25.0.6 with an operator-visible disclosure of the extended interim status.
2. Freeze the 25.0.5 FIPS variant as the operational reference until the new cert issues, release non-FIPS 25.0.6 to keep the standard variant on CPU cadence.
3. Contract with a second Java FIPS module vendor as an emergency path if the CMVP delay extends past 25.0.7.

Enforcement architecture: four layers

Every existing FIPS-Java integration (Red Hat OpenJDK FIPS mode, IBM Semeru RestrictedSecurity, Azul Zulu FIPS, bare Bouncy Castle) has at least one runtime path a user's code can take to defeat the FIPS boundary from user space. Eliya's variant composes four independent enforcement layers so that no single user action defeats the boundary:

• L1 (build time): SunJCE and other non-FIPS provider classes are excluded from java.base at image build. The classes are not on the shipped module path at all; user code calling Class.forName("com.sun.crypto.provider.SunJCE") gets ClassNotFoundException.
• L2 (HotSpot parse-time): launcher arguments that would compromise FIPS enforcement (-Djava.security.properties=, -Dsecurity.overridePropertiesFile=true, -Dorg.bouncycastle.fips.approved_only=false) are refused before Java code runs. The JVM aborts with an operator-visible message naming the offending argument.
• L3 (Java static-init + runtime mutation refusal): at java.security.Security class initialization, Eliya verifies the effective provider chain matches the FIPS-approved list. The same patched Security class refuses addProvider, insertProviderAt, and removeProvider mutations that would violate the FIPS invariant, for the entire JVM lifetime. The temporal-swap attack (first Cipher.getInstance against BC, provider swapped mid-flight, second Cipher.getInstance against injected non-FIPS provider) is blocked at the moment the swap is attempted.
• L4 (first-crypto-use verification): on the first JCA getService invocation, Eliya re-checks the provider chain as a defense-in-depth consistency check on the post-boot state. If the check fails (indicating an L1/L2/L3 bypass this design has not anticipated), the JVM refuses the crypto call with an explicit "FIPS integrity violation" SecurityException.

The layered enforcement architecture is documented at length in the FIPS integration research note (internal reference). A public technical write-up of how existing FIPS-Java integrations can be defeated, and how Eliya's variant addresses those defeat paths, is in preparation.

What the FIPS variant does NOT cover

Standard FIPS 140-3 boundary conventions apply. Eliya's FIPS variant asserts:

• Cryptographic algorithms used through JCA are routed to a FIPS-validated module. AES, SHA-2/3, HMAC, RSA (with FIPS-approved parameters), ECDSA, DRBG-based SecureRandom, and TLS 1.2 / 1.3 handshakes (via BC-JSSE) all go through BC-FJA.
• Non-crypto JDK surface is not FIPS-validated. The JVM itself, garbage collector, class loader, JIT compiler, java.util collections, java.io streams, etc. are not within the cert boundary. This is standard FIPS 140-3 module scoping; the boundary is the cryptographic module, not the runtime that hosts it.
• Application-level cryptography that bypasses JCA is your responsibility. If your application code directly links a native crypto library (e.g. JNI to OpenSSL), that path is outside Eliya's enforcement and outside cert #4943's boundary. Use JCA for all application crypto if FIPS compliance is required.
• Entropy is your responsibility. Per the Interim Validation caveat above, SSP strength depends on your deployment target's entropy source. Verify entropy is adequate on VMs, containers, and embedded systems before treating a FIPS deployment as trusted.

Comparison to the standard variant

Getting started

The FIPS variant ships as a separate artifact with distinct filenames and Docker tags:

• Tarball: eliya-jdk-fips-25.0.4+7-r1-linux-x64.tar.gz
• DEB: eliya-jdk-fips_25.0.4+7-r1_amd64.deb
• RPM: eliya-jdk-fips-25.0.4-r1.x86_64.rpm
• Docker: ghcr.io/asymmsystems/eliya-jdk-fips:25.0.4-r1

Install and use exactly like the standard variant. No -D flags to remember; no runtime toggles to set. The variant is FIPS-enforcing from first launch.

For SHA-256 checksum and GPG signature verification, see the verify download page. The FIPS variant is signed by the same Eliya signing key as the standard variant.

Verify you are in FIPS mode

After installing the FIPS variant, confirm the enforcement is active:

$ java -version
openjdk version "25.0.4" 2026-08-19
OpenJDK Runtime Environment Eliya-25.0.4-fips (build 25.0.4+7-r1)
OpenJDK 64-Bit Server VM Eliya-25.0.4-fips (build 25.0.4+7-r1, mixed mode, sharing)

$ java -XshowSettings:security 2>&1 | grep -i provider
    security.provider.1 = BCFIPS
    security.provider.2 = BCJSSE
    ... (no SunJCE row)

$ jshell <<< 'System.out.println(java.security.Security.getProviders()[0].getName());'
BCFIPS

If any of these outputs differ, the variant may have been tampered with in transit. Re-verify the SHA-256 and GPG signature against the published values.

FAQ

Is Eliya itself FIPS-certified?

No. FIPS 140-3 certifies cryptographic modules, not JDKs or runtimes that host them. Eliya's FIPS variant bundles a FIPS-certified module (BC-FJA #4943) and enforces the boundary through the layered architecture above. The cert boundary is BC-FJA, not Eliya.

Why does the cert page say "Interim Validation"?

See the Interim Validation caveat section above. Interim status means the module has been validated with two acknowledged operator responsibilities (approved mode + adequate entropy). The interim status also means a new final certificate is coming; per Bouncy Castle's 2026-08-18 confirmation, BC-FJA 2.1.2 and 2.1.3 are with the CMVP lab, estimated 10-12 weeks to completion. Eliya will migrate to the new cert in 25.0.6.

Can I use my own crypto provider on the FIPS variant?

No. The FIPS variant refuses non-FIPS provider registration. If you need a specific third-party provider, use the standard eliya-jdk variant. Mixing a non-FIPS provider into a FIPS-labelled deployment would defeat the compliance purpose of the variant.

Does the FIPS variant support macOS or Windows?

Phase 2 ships Linux x86_64 and aarch64 first (Ubuntu, RHEL, Amazon Linux verified). macOS aarch64 and Windows x86_64 support is on the roadmap; both depend on FIPS variant demand. Contact us if either is procurement-blocking for you.

Does the FIPS variant pass every FIPS 140-3 test I might run?

Every JCA-routed crypto call goes through BC-FJA #4943, which passes NIST's Cryptographic Algorithm Validation Program (CAVP) tests for its approved-mode algorithm set. Direct-JNI crypto or non-JCA paths in your own application code are outside the enforcement boundary and will not be covered by the cert. If your compliance auditor runs your entire application through a FIPS-mode test harness, ensure your application code uses JCA for all crypto.

What happens on 2027-01-16 when cert #4943 sunsets?

Eliya 25.0.6 (targeted 2027-02-02) migrates to the new BC-FJA cert (2.1.2 or 2.1.3) that will by then have completed lab validation. If for any reason the migration slips, see the "Sunset commitment" section above for the three fallback paths.

How does Eliya's FIPS variant compare to Red Hat's or IBM Semeru's?

A detailed comparison of every existing FIPS-Java integration (Red Hat, IBM Semeru, Azul Zulu, Amazon Corretto, bare Bouncy Castle) is in preparation as a technical article. The short version: every existing integration has at least one runtime provider-swap path reachable from user code; Eliya's four-layer architecture is the first to close all of them at once.

Related pages

• Eliya Security — vulnerability reporting, release signing, security inheritance from upstream
• Downloads — waitlist and installation artifacts
• Lifecycle & support — CPU cadence, LTS support windows
• Roadmap — Phase 2 + Phase 3+ plans
• Verify download — SHA-256 + GPG verification