Running OpenJDK in FIPS mode on RHEL

Introduction

The Federal Information Processing Standards (FIPS) provides a set of guidelines and requirements with the purpose of improving security and interoperability across computer systems and networks. The FIPS 140-2 and the recently approved 140-3 series apply specifically to cryptographic modules at hardware and software levels. The National Institute of Standards and Technology in the United States implements a Content from csrc.nist.gov is not included.cryptographic module validation program with searchable lists of both in-process and approved cryptographic modules.

Red Hat Enterprise Linux 8 (RHEL) brings an integrated framework for organizations to enable FIPS 140-2 compliance system-wide. When operating under FIPS mode, software packages using cryptographic libraries will self-configure according to the global policy. Packages generally provide a way to change this default alignment behavior for compatibility or specific needs.

OpenJDK is a FIPS-policy aware package. In the following chapters we will explore its configuration and under the hood details. At the end we will expose through a FAQs list some of the most common challenges that your application will face to start running on FIPS mode.

Find more information on how to install a RHEL 8 system with FIPS mode enabled here. Check how to turn FIPS on after installation here. Further information on Red Hat’s compliance with Government Standards available This content is not included.here.

How to configure OpenJDK in FIPS mode?

OpenJDK checks if the system is configured in FIPS mode at startup. This is the default behavior since RHEL 8.3. Previous RHEL 8 releases require the com.redhat.fips system property set to true passed as a JVM argument (i.e.: -Dcom.redhat.fips=true). Please note that if you enable FIPS mode while a JVM instance is running, the instance has to be restarted for changes to take effect. More information on enabling FIPS mode can be found here.

OpenJDK can be configured to bypass the global FIPS alignment for compatibility or specific purposes. In example, an organization might want to enable FIPS compliance through a Hardware Security Module (HSM) instead of the scheme provided by OpenJDK. Different properties can be used in this regard:

• security.useSystemPropertiesFile
  • Security property located at $JAVA_HOME/lib/security/java.security; or in any other file pointed by the java.security.properties property (the security.overridePropertiesFile security property must be set to true)
  • Privileged access is required to modify its value in a default java.security file
  • Persistent configuration
  • Set to true by default. When set to false, both the global FIPS and the crypto-policies alignment are disabled
• java.security.disableSystemPropertiesFile
  • System property passed to the JVM as an argument. I.e.: -Djava.security.disableSystemPropertiesFile=true
  • Non-privileged access is enough
  • Non-persistent configuration
  • Takes the false value when not set. When set to true, has the same effect than a security.useSystemPropertiesFile=false security property. If both properties are set to different behaviors, java.security.disableSystemPropertiesFile overrides.
• com.redhat.fips=false
  • System property passed to the JVM as an argument. I.e.: -Dcom.redhat.fips=false
  • Non-privileged access is enough
  • Non-persistent configuration
  • Takes the true value when not set. When set to false, disables the FIPS alignment while still applying the global crypto-policies. If any of the previous properties is set to disable the crypto-policies alignment, this property has no effect. In other words, crypto-policies is a prerequisite for FIPS alignment.

What is going on behind?

Security Providers

The OpenJDK security policy is controlled by the global java security policy file, found at $JRE_HOME/lib/security/java.security. That file contains several parameters that define the list of Java Cryptography Architecture/Java Cryptography Extension (JCA/JCE) providers, configure random number generation, enable user-level overrides of the global policy, etc. When FIPS mode is enabled, OpenJDK replaces the installed security providers list with the following ones (in descending priority order):

• SunPKCS11-NSS-FIPS
  • Initialized with a Network Security Services (NSS) Software Token (PKCS#11 backend). The NSS Software Token is configured as follows:
    • name = NSS-FIPS
    • nssLibraryDirectory = /usr/lib64
    • nssSecmodDirectory = /etc/pki/nssdb
    • nssDbMode = readOnly
    • nssModule = fips
      *The NSS library implementing the Software Token is FIPS compliant and FIPS-policy aware in RHEL 8.
• SUN
  • For X.509 certificates support only. Make sure that your application is not using other cryptographic algorithms from this provider. For example, a MessageDigest.getInstance("SHA-256", Security.getProvider("SUN")) call would work but lead to a non-FIPS compliant MessageDigest service.
• SunEC
  • For SunPKCS11 auxiliary helpers only. Make sure that your application is not explicitly using this provider.
• SunJSSE
  • Initialized with the SunPKCS11-NSS-FIPS provider for all cryptographic primitives required by the TLS engine, including key derivation.

Crypto-policies

OpenJDK takes configuration values regarding cryptographic algorithms allowed from global crypto-policies when in FIPS mode. These values can be found at /etc/crypto-policies/back-ends/java.config. Use the update-crypto-policies RHEL tooling to manage crypto-policies in a consistent way.

Please note that an algorithm may be allowed by crypto-policies but still not valid for use in OpenJDK’s FIPS mode. This occurs when a FIPS-compliant implementation is not available. Internally, cryptographic algorithms and mechanisms need to be supported by OpenJDK’s SunPKCS11 security provider and implemented by the NSS library.

Trust Anchors certificates

OpenJDK uses the global Trust Anchor certificates repository when in FIPS mode. This repository is located at $JRE_HOME/lib/security/cacerts. Use the update-ca-trust RHEL tooling to manage certificates in a consistent way.

Key store

When in FIPS mode, OpenJDK uses the NSS DB as a read-only PKCS#11 store for keys. As a result, the keystore.type security property is internally set to PKCS11. The NSS DB repository is located at /etc/pki/nssdb. Use the modutil RHEL tooling to manage NSS DB keys.

FAQs

Which TLS protocol versions are supported in OpenJDK’s FIPS mode?

TLS 1.2 at the moment. Older TLS versions are not supported nor recommended for FIPS compliance.

What would I need for my application to work in OpenJDK’s FIPS mode?

There is not a single answer as this depends on each application. With that said, there is a list of things you might want to check:

• Your application should not be managing symmetric or private keys in plain, including the use of JKS or PKCS#12 file-based keystores. The NSS Software Token does not allow the extraction of these keys out of the token in plain bytes; nor its insertion. At a PKCS#11 level, keys have the attributes CKA_SENSITIVE and CKA_EXTRACTABLE set to true. When in FIPS mode, your application should manage symmetric and private keys as opaque objects. These objects can be used for JCA cryptographic services (i.e.: Cipher, Signature, Mac, etc.) and are either ephemeral or persisted inside the NSS DB.
• Some cryptographic algorithms or key lengths may not be suitable for FIPS mode. Replacements may be needed in these cases.
• There might be performance implications on some applications when operating in FIPS mode. We advise to execute performance tests accordingly and evaluate further actions.

How to enable OpenJDK’s FIPS mode debug information?

OpenJDK can be configured to print relevant FIPS mode information at startup by setting the -Djava.security.debug=properties JVM argument.

Does RHEL8 have FIPS validation?

Yes, see This content is not included.Red Hat Delivers a More Secure Foundation for Modern Applications with First FIPS 140-2 Validation for Red Hat Enterprise Linux 8.