Handling FIPS mode in upstream projects for RHEL

This article is intended for the upstream developers or upstream contributors that are interested in adding or improving the support of their component for Red Hat Enterprise Linux (RHEL) in FIPS mode, outlining best practices or examples of behavior that is being discouraged.

Federal Information Processing Standards (FIPS) 140

The FIPS Publication 140 is a series of computer security standards developed by the National Institute of Standards and Technology (NIST) to ensure the quality of cryptographic modules. The FIPS 140 standard ensures that cryptographic tools implement their algorithms correctly. Runtime cryptographic algorithms and integrity self-tests are some of the mechanisms to ensure a system uses cryptography that meets the requirements of the standard. For more information about FIPS 140, see the specific chapter in Red Hat Enterprise Linux documentation.

FIPS mode in Red Hat Enterprise Linux

Red Hat Enterprise Linux implements the FIPS mode as a system-wide property. This means that the whole system is either in the FIPS mode or not, from kernel through the crypto modules to the applications. This might not apply to all other Linux distributions or generally to other FIPS modules out there though.

FIPS mode is relevant not only to the validated modules (cryptographic libraries and kernel), but also to applications that are using some cryptographic algorithms or protocols. These applications might need to do some adjustments to the cryptographic algorithms used, provide graceful fallback and should not attempt to modify the FIPS status of the system with user-facing options.

FIPS approved algorithms

The Federal Information Processing Standard (FIPS) specification provides guidelines for cryptographic algorithms that are allowed while the applications or libraries are operating in FIPS mode. The guidance is evolving and differs among FIPS versions, libraries we certify, and Red Hat Enterprise Linux versions so I will not go into specific algorithms here. You can find the current certificates in an article on the Red Hat Customer Portal, describing approved algorithms in detail. Currently approved algorithms are also visible in the cryptographic policies, for example the current policy for Red Hat Enterprise Linux 9, providing human-readable summary of approved algorithms, sizes, modes, and more.

FIPS mode in end-user applications

Some applications provide a build-time configuration of the FIPS mode. This is not a good fit for Red Hat Enterprise Linux as we provide a single set of binaries that needs to work in both modes and using the FIPS mode by default might be too restricting for a general use case.

Some upstream applications provide runtime options to switch the application to the FIPS compliant mode. From the certification point of view, this results in an unknown state that can’t be claimed as FIPS compliant. This is because the FIPS mode is managed on the system-wide level and applications can not affect this state. The applications need to query the cryptographic library for the FIPS status and behave based on this information (and not the other way round). For example in the case of OpenSSL, there is the EVP_default_properties_is_fips_enabled() function. In libgcrypt, there is the gcry_fips_mode_active() function for checking the system FIPS mode and GnuTLS provides a function gnutls_fips140_mode_enabled(). Without any cryptographic library, the kernel FIPS mode is identified by “1” in the file /proc/sys/crypto/fips_enabled.

When the application detects the FIPS mode is enabled in the underlying cryptographic library, it should do the following:

• When it is doing some high-level protocol algorithm negotiation, it should NOT negotiate any algorithm that is not FIPS approved (see above, for example Curve25519 key exchange). This includes both algorithms implemented by the cryptographic library itself but also bundled/custom implementations (if any). The crypto-policies should be able to help with selecting sane defaults for high-level protocols.
• When using low-level cryptographic algorithms, it should use sane defaults and handle failures gracefully. Even though the algorithm or key size might be allowed now, it might be disallowed in the future. The key/algorithm might be also provided by the remote peer not aware of the local FIPS mode so the application needs to fall back to a different algorithm, if protocol permits.

Testing applications in FIPS mode

When upstreams are confronted with something they are not familiar with, they usually require a way to reproduce the issues and a way to test them. Most of them have some automated tests integrated in GitHub Actions so emulating the FIPS mode in this environment is fortunately pretty simple.

• Use the quay.io/centos/centos:stream9 container for the most-recent experience (if you need to extend the coverage with different version, using stream8 is recommended)
• The crypto policies should be changed to the FIPS policy (ignore the warnings):
  • update-crypto-policies --set FIPS
• To simulate FIPS mode for all userspace applications, bind-mount a file containing non-zero value to /proc/sys/crypto/fips_enabled. Note that this won’t switch the kernel to the FIPS mode! For example:

  mkdir -p /var/tmp/userspace-fips
  
  echo 1 > /var/tmp/userspace-fips/fips_enabled
  
  mount --bind /var/tmp/userspace-fips/fips_enabled /proc/sys/crypto/fips_enabled

• If the above does not work in your CI (for example, GitLab), you can use the environment variables to enforce FIPS mode in our libraries:
  • OPENSSL_FORCE_FIPS_MODE=1 will force OpenSSL into FIPS mode.
  • LIBGCRYPT_FORCE_FIPS_MODE=1 will force libgcrypt into FIPS mode.
  • GNUTLS_FORCE_FIPS_MODE=1 will force GnuTLS into FIPS mode.
• Run the application testsuite as usual.