The Federal Information Processing Standard (FIPS) 140-2 is a US government computer security standard published by National Institute of Standards and Technology (NIST). It specifies the security requirements for cryptographic modules. FIPS 140-2 compliance is often a requirement of the software systems used by the US government agencies.
The NIST manages a list of FIPS certified cryptographic modules. These modules are certified under the Cryptographic Module Validation Program. The list can be searched online here.
Hazelcast uses external modules for cryptographic tasks and it can be configured to use a FIPS 140-2 validated module. It means most of the configuration required for FIPS is outside of the Hazelcast configuration. To run Hazelcast in the FIPS compliant mode you have to set the underlying Java runtime into FIPS mode. It may also require switching the underlying Operating System into the FIPS mode. We consider using a FIPS enabled OS as a recommended approach even in cases when it’s not asked for explicitly.
Hazelcast is not an authority which should document switching different Java
runtimes into the FIPS mode. Please consult the documentation of your Java
version to learn how to enable the FIPS mode. Usually it means changing the
list of security providers in the
java.security JRE configuration file.
Hazelcast is only responsible for enabling the OpenSSL native library into
FIPS mode (see the Integrating OpenSSL section).
If the Hazelcast cluster configuration enables TLS communication using the
native OpenSSL library, you have to enable its FIPS mode in the Hazelcast
The FIPS mode is controlled by an optional
false property called
fipsMode. It is disabled by default.
Example OpenSSL configuration in the FIPS mode:
fipsMode property is set to
true, the native OpenSSL engine is
either set to the FIPS mode or an exception is thrown, e.g., in the cases when
OpenSSL is compiled without the FIPS support.
If there is more Hazelcast instances (members or clients) with TLS enabled
employing the OpenSSL, then all of them must have the
configured in the same way, either enabled or disabled.
When the FIPS mode is successfully enabled, you will see the following
INFO level message in the log files:
OpenSSL is enabled in FIPS mode.
|BoringSSL libraries don’t support the FIPS mode.
The FIPS environment configuration steps depend on the used operating system and Java version. You should consult with their documentation for the specific configurations.
We will describe a sample configuration which uses Red Hat Enterprise Linux (RHEL) version 7 and IBM Java SDK 8. If you find any difference between the sample configuration described here and the documentation of the OS and Java vendors, use the vendor’s up-to-date instructions instead.
Switching RHEL 7 into the FIPS mode
The steps on how to configure RHEL 7 in FIPS 140-2 mode are described in the Security guide on the Red Hat customer portal.
Perform the following steps for the already installed systems:
dracut-fipspackage using the YUM package manager.
dracutcommand to regenerate the
fips=1option to the kernel command line of the boot loader.
Disable prelinking (if it was enabled before.
Reboot the system.
After finishing these steps, check if the FIPS mode is enabled by running the following command:
# Following command should print "crypto.fips_enabled = 1" (value 1 means the FIPS mode is enabled)
To automate the FIPS mode enablement on RHEL 7, you can check the script which is shared in the Red Hat discussion forum.
Switching IBM Java SDK into the FIPS mode
IBM Java 8 provides the FIPS mode itself without any third party dependencies.
Details on how to enable the FIPS 140-2 validated configuration can be found in the Security guide in the Java 8 documentation.
First, it’s necessary to edit the
jre/lib/security/java.security file and
do the following changes:
IBMJCEFIPSas the first security provider. It will be the first provider to be selected when a JCA API call is made without specifying an explicit security provider.
And re-number the original set of security providers by increasing the priority of provider by one, i.e., the old
security.provider.2and so on.
Add the new security properties (related to handling TLS protected communication):
The Security provider covering the TLS implementation in IBM Java is
IBMJSSE2. To instruct this provider about using the FIPS validated security primitives (from
IBMJCEFIPS), use additional system properties.