FIPS 140-3 evaluation technology in IBM Semeru Runtimes

FIPS 140-3 evaluation technology in IBM Semeru Runtimes

The FIPS 140-2 cryptographic security standard from the US government is now superseded by a later version, FIPS 140-3. FIPS 140-3 validation is ongoing for the FIPS cryptographic module within the Semeru SDK. In the meantime, this unsupported technology preview is available for users who have existing FIPS 140-2 deployments to assess the changes that are required to those deployments to move to the FIPS 140-3 standard.

Note: Information in this guide does not apply for the IBM Semeru Runtime Certified Edition for z/OS. For more information about the certified edition, see IBM Semeru Runtime Certified Edition for z/OS documentation.

The technology preview is for evaluation purposes only and is provided subject to the following disclaimer:

Disclaimer: The code and application programming interfaces herein are technology preview information that might not be made generally available by IBM as or in a product. You are permitted to use the information only for internal use for evaluation purposes and not for use in a production environment. IBM provides the information without obligation of support and "as is" without warranty of any kind.

The existing support for the FIPS 140-2 support described here is unchanged.

This technical preview for FIPS 140-3 is based on code contained in two open-source projects.

  1. The OpenJCEPlusFIPS provider located at OpenJCEPlus.

  2. The Open Cryptography Kit for C located at OpenCryptographyKitC.

FIPS certification

Semeru currently contains a FIPS 140-2 production solution. The documentation is available here FIPS certified cryptography in IBM Semeru Runtimes. 

An updated version of the IBM Crypto for C module has been released as an open-source project called Open Cryptography Kit for C located at OpenCryptographyKitC. The Open Cryptography Kit for C code base is currently being validated for meeting FIPS 140-3 requirements at NIST. The FIPS 140-3 standard is stricter than FIPS 140-2, so you might need to change your applications and or configurations to migrate and make use of FIPS 140-3. Use this technology preview to assess these changes before the OpenJCEPlusFIPS 140-3 code is released for use in production environments.

Operational environments

You can enable the FIPS 140-3 technology preview using Semeru runtime versions 11.0.23, 17.0.10.0, and Java 21.0.3.0 or higher. The following system architectures are currently supported:

  • AIX on 64-bit IBM POWER hardware
  • Linux on x86-64 hardware
  • Linux (Little Endian) on 64-bit IBM POWER hardware
  • Windows on x86-64 hardware

Note: The FIPS 140-3 security policy does not permit the use of the OpenJCEPlusFIPS provider on 32-bit operating systems. 

FIPS 140-2 statement of direction and future deprecation

The FIPS 140-2 production solution, which makes use of the NSS library, will be deprecated in the future in favor of the FIPS 140-3 solution described in this document. In a future release the -Dsemeru.fips Java property will default to use FIPS 140-3. The exact date of deprecation will be determined at a later time depending on the anticipated approval of the FIPS 140-3 cryptographic modules by NIST.

Enabling the FIPS 140-3 technology preview

The FIPS 140-3 technology preview is disabled by default. Enable the technology preview for evaluation purposes only; do not use it in a production environment.

The default java.security file will incorporate a restricted security mode profile, which will become active upon using a FIPS configuration. A restricted security profile is designed to enforce FIPS compliance by restricting configurations according to settings within the java.security file associated with a given FIPS configuration name and version. The java.security file profile will encompass settings similar to other settings in the java.security file, except they will be specific for a given compliance setup. Examples include profiles for FIPS 140-2 or FIPS 140-3, or various iterations of the FIPS 140 standards. By default, the OpenJCEPlusFIPS provider will be positioned as the primary/first provider in the list when making use of the FIPS 140-3 profile and will coexist alongside profiles that are used for the current 140-2 configuration that makes use of NSS on RHEL FIPS certified systems. Various restrictions will be defined within the profile, including acceptable key sizes, TLS cipher suites, permissible algorithms, and provider configurations.

When configuring security profiles, you must specify one or both of the following options:

Properties related to FIPS in java.security file
Java property Behavior
-Dsemeru.fips=true

Makes use of the default FIPS profile. Currently this is defined as FIPS 140-2 on RHEL certified systems using the NSS library.

In the future, once the underlying stack becomes FIPS 140-3 certified, this property will default to utilizing the OpenJCEPlusFIPS 140-3 profile.

-Dsemeru.customprofile=

profile.version

Specify an optional profile and an optional version of that profile.

The profile value must be specified when making use of the -Dsemeru.customprofile property. The profile name specified is required to be present as a portion of the restricted security mode profile name in the java.security file for this to be allowed.

The version value is optional and is intended to be used for custom profiles and can only be specified when used in conjunction with a profile name. The version value can only be used when a profile is specified.

Example 1 - Enable a specific OpenJCEPlusFIPS FIPS profile of a specific version:

-Dsemeru.fips=true -Dsemeru.customprofile=OpenJCEPlusFIPS.version


Example 2 - Enable a specific NSS FIPS profile of a specific version:

-Dsemeru.fips=true -Dsemeru.customprofile=NSS.version


Example 3 - Enable the latest/default OpenJCEPlusFIPS FIPS profile:

-Dsemeru.fips=true -Dsemeru.customprofile=OpenJCEPlusFIPS


Example 4 - Enable a generalized non FIPS custom profile:

-Dsemeru.customprofile=CUSTOM.version

A non-default profile can be created by users by editing the java.security file and making use of the profile and version options defined above for the various Java properties. Using a custom profile implies that you may or may not be FIPS compliant depending on the custom configurations and the intricacies of your FIPS deployment. Custom or non-default configurations in the java.security file must also be tested to avoid any functional issues that may arise from untested security configurations.

Additional profiles, and versions of those profiles, will be provided in the future as standards are updated. The default configuration that is in use by the properties mentioned above will change, which may cause application failures and behavior changes as standards evolve. In the case that a user specifies a specific configuration option using the profile and version setting above, the user’s configuration should remain constant. Existing profile definitions will not be changed although a deprecation and removal of such profiles will be enforced either on major LTS releases or when profiles are no longer recommended by FIPS standards. In this case, it is the application's responsibility to migrate forward to the latest recommended option, so as to ensure overall FIPS compliance as recommended by IBM.

Java properties and other external interfaces

Java properties

For information about the properties associated with enabling the FIPS 140-3 technical preview, see Enabling the FIPS 140-3 technology preview. Refer the following table for additional Java properties.

Additional Java Properties
Java property Behavior
com.ibm.fips.mode

A Java property that is set based on the active FIPS profile in use. When running with a FIPS 140-2 based profile, the value returned is 140-2. When running with a FIPS 140-3 based profile the value 140-3 is returned. This value is set automatically by Semeru by using the value of the property RestrictedSecurity.PROFILENAME.fips.mode in the java.security file.

An error occurs if a user sets this property in conjunction with properties semeru.customprofile or semeru.fips.

Key and certificate storage

Key storage is expected to be supported by other Java JCE providers besides the OpenJCEPlusFIPS provider. To support key storage mechanisms, such as the file-based keystores PKCS#12 and JKS, offered by other providers, as well as their specific keystore algorithms, you must manually enable them by updating the configuration in the java.security profile in your system.

Compliance with FIPS regulations becomes crucial when keys are moved outside the cryptographic FIPS boundary. PKCS#12 and JKS file formats are not an appropriate FIPS certified file format. In case you plan on moving key material to another machine, you must use a different process using FIPS certified techniques to ensure compliance.

To comply with FIPS regulations while maintaining flexibility and functionality, non-FIPS algorithms can be used to access keystores when they are used within the FIPS boundary. This approach ensures compliance without compromising the desired use of PKCS#12 file formats.

  • JKS
    To enable JKS file formats, the following line must be added to the FIPS security profile in the java.security file: 
    RestrictedSecurity.OpenJCEPlusFIPS.FIPS140-3.jce.provider.2 = SUN [ … \ 
{KeyStore, JKS, *}, \ 
…]
  • PKCS#12
    For information on how to use PKCSS#12 refer to the section titled “Use a PKCS#12 file-based keystore file directly by making modifications to the java.security file.”, located in the documentation at FIPS certified cryptography in IBM Semeru Runtimes.

    To enable PKCS#12 file formats, make use of the RestrictedSecurity.OpenJCEPlusFIPS.FIPS140-3.jce.provider.4 profile name instead of the documented NSS profile name to be sure that the settings apply to the FIPS 140-3 technical preview profile.

    For example, the following provider and algorithms are a simple example that allows a PKCS#12 file that makes use of the mentioned algorithms to be loaded (See the NSS documentation for additional algorithm names that may be required depending on how your PKCS#12 file was created):
      
    RestrictedSecurity.OpenJCEPlusFIPS.FIPS140-3.jce.provider.4 = SunJCE [{AlgorithmParameters, PBES2, *}, \

    {AlgorithmParameters, PBEWithHmacSHA256AndAES_256, *}, \

    {SecretKeyFactory, PBEWithMD5AndDES, *}, \

    {Cipher, PBEWithHmacSHA256AndAES_256, *}, \

    {Mac, HmacPBESHA256, *}]

    One additional update is needed to make use of PKCS#12, beyond what is required by the NSS FIPS 140-2 solution. The update involves allowing SHA-256 and PKCS12 algorithms from the SUN provider by adding the following lines. Please note that the line `{KeyStore, PKCS12, *}, \` should only be specified on Java 17 and older. Releases higher then Java 17 we no longer recommend adding this line.
      
    
RestrictedSecurity.OpenJCEPlusFIPS.FIPS140-3.jce.provider.2 = SUN [{…

    {KeyStore, PKCS12, *}, \
    {MessageDigest, SHA-256, *}]

Supported algorithms

See the documentation located in the OpenJCEPlus open-source project for more information regarding algorithms provided. Ensure that you view the appropriate git code branch for the Java release that you are working with.

Known limitations

The known limitations are as follows.

  • JSSE is currently restricted to known FIPS algorithms as mentioned in the following FAQ section. Additional work is needed in order to support some situations surrounding compliance with RFC 7919 and the predicted FIPS 140-3 security policy. Supported groups may work incorrectly when using this FFDHE algorithm.
  • The SUN provided SHA-256 algorithm, required to make use of PKCS#12 files, should be removed in the future. The SHA-256 FIPS certified algorithm offered by OpenJCEPlusFIPS should be used instead where appropriate.

Frequently asked questions

  1. SHA1 is not allowed in FIPS 140-3. Can SHA1 still be used to hash two files to determine whether they are the same?

    Yes. SHA1 is no longer considered secure for cryptographic operations. However, you can still use SHA1 for noncryptographic operations. For example, you can use the SHA1 algorithm (from any non-fips provider) to compare two documents or objects to see whether they are identical (same hashes), but you cannot use it for hashing those documents for digital signature.

  2. What do you mean by key exchange, bulk encryption or MAC cipher suites?

    A TLS cipher suite is the set of algorithms that are used to secure network connections. In the TLS 1.2 protocol, the set of algorithms that cipher suites usually contain includes: a key exchange algorithm, a bulk encryption algorithm, and a message authentication code (MAC) algorithm. In the cipher suite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, for example, ECDHE_RSA is the key exchange algorithm, AES_128_GCM is the bulk encryption algorithm, and SHA256 is the MAC algorithm to be used. In the TLS 1.3 protocol, the key exchange algorithm is omitted. For example, in the cipher suite TLS_AES_128_GCM_SHA256, AES_128_GCM is the bulk encryption algorithm, and SHA256 is the MAC algorithm to be used.

  3. What TLS protocols are allowed in the FIPS 140-3 standard?

    TLS 1.3 and TLS 1.2.

  4. What TLS cipher suites are allowed in the FIPS 140-3 standard?

    The following suites are allowed for the TLS 1.3 protocol:

    • TLS_AES_128_GCM_SHA256
    • TLS_AES_256_GCM_SHA384

    The following suites are allowed for the TLS 1.2 protocol on Java releases less then Java 21:

    • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
    • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
    • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
    • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
    • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
    • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
    • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
    • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
    • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
    • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
    • TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
    • TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
    • TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
    • TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
    • TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
    • TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
    • TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
    • TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
    • TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
    • TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256

    On Java 21 and higher all *ECDH* ciphers are no longer supported. Support for these cipher suites was removed by openjdk.

Page Feedback