How RHEL 8 is designed for FIPS 140-2 requirements

Deploying software in a large organization is a challenging task when it comes to providing a consistent and reasonable level of security. Any number of vendors are involved in delivering software that addresses numerous needs of the organization, and that combination of software includes numerous claims and security mechanisms. How can an organization be made aware that all deployed software systems contain generally accepted and state of the art in today’s standards cryptography? Should the organization receiving the software understand and review all the algorithms and protocols used by the software?

Although, in the open source world the latter may be feasible, it is not always a reasonable or scalable option for the IT department of each and every organization. That is why in Red Hat Enterprise Linux, we seek to comply with the FIPS 140-2 standard. FIPS 140-2 is a joint effort between NIST and the Canadian Centre for Cyber Security (CCCS). 

FIPS 140-2 is a security standard for cryptographic modules, which is widely accepted and referenced by other standards organizations such as Payment Card Industry (PCI), Internet Engineering Task Force (IETF), and is in the process of moving towards an ISO standard. It covers cryptographic modules, which is a term that refers to software or hardware performing cryptographic operations.

In this post we will describe why and how Red Hat Enterprise Linux 8 follows FIPS 140-2, how it works, its challenges and the changes in Red Hat Enterprise Linux 8.1 that impact its use.

What is FIPS 140-2?

The FIPS 140-2 publication prescribes a set of requirements that need to be satisfied by cryptographic modules both software and hardware components. FIPS 140-2 establishes the Cryptographic Module Validation Program (CMVP), and the Automated Cryptographic Validation Testing (ACVT) program, which are accreditation programs used to certify that cryptographic modules do in fact correctly implement encryption as prescribed. 

In order to obtain a certification for a specific cryptographic module, a set of tests and source code inspection is performed by an accredited third-party lab. Once validation is achieved a certificate is issued by US National Institute of Standards and Technology (NIST) and Canada’s Communications Security Establishment (CSE) that lists precisely the software version, actual hardware and hardware architecture used as well as individual cryptographic algorithms and functionality covered and verified by the lab.

Compliance to the FIPS 140 standard is required for several US-government regulated sectors and an increasing number of international standards refer to it for encryption related requirements.

Why FIPS 140-2?

Taking a step back from any specific requirements, the FIPS 140-2 validation is about the following principles.

• Unit testing of cryptography implementations;

• Logically separating cryptography from application code;

• Reliance on proven cryptographic primitives.

While one may disagree on a particular detail, such as which algorithm is more conservative or stronger, we find these high-level principles important for any software that is intended to remain relevant for a long time. We strive to make Red Hat Enterprise Linux a modern operating system which includes the most recent community enhancements and features and follows industry best practices in quality testing. At the same time, we aim to be conservative in the security-critical features we introduce. Hence, the principles of this certification are paramount to us and the FIPS 140-2 certification process allows us to demonstrate via a third party assessment to our customers and partners that we follow this set of principles in our cryptographic software.

Furthermore, with that certification, our layered products as well as independent software vendors and our customers are provided with a foundation on which they can build products that can also meet the FIPS 140-2 requirements.

How Red Hat Enterprise Linux implements FIPS 140-2 

Red Hat Enterprise Linux 8 is designed to follow the FIPS 140-2 level 1 requirements for all of its core cryptographic components (see below for more information); RHEL 8.1 is currently under validation and we intend to ship every minor release starting with 8.1 with FIPS 140-2 validated cryptographic components.

Although the high-level principles are followed, Red Hat Enterprise Linux 8 does not enforce all FIPS 140-2 requirements by default. That is because the FIPS 140-2 requirements are sometimes too strict for generic environments; for example they introduce computationally expensive power-on tests, allow only specific key sizes, etc. To overcome these issues we provide a special mode of Red Hat Enterprise Linux 8, which follows FIPS 140-2 requirements. We informally call this mode, FIPS mode.

The FIPS mode applies system-wide and configures the individual core crypto components in Red Hat Enterprise Linux to their corresponding FIPS 140-2 mode. In that mode, the random generation, algorithm restrictions, and required power-on and continuous self tests are enabled (see this document for additional information).

To switch to FIPS mode in Red Hat Enterprise Linux 8 we have introduced a new command line application which significantly simplifies the process since RHEL 7. With this new tool an administrator can switch the system to FIPS mode by entering the following commands:

# fips-mode-setup --enable

# reboot

Note however, that a switch to FIPS mode must occur prior to configuring any application on top of RHEL. Otherwise if the application is already configured, it may have options enabled that are prohibited by FIPS mode, and may not function as expected.

Changes in Red Hat Enterprise Linux 8

Core cryptographic components

Components in Red Hat Enterprise Linux are updated to address security vulnerabilities, irrespective of their FIPS validation status. As validation certificates are bound to the particular version of the component that was validated that poses a serious dilemma to organizations that are required by guidelines to use a validated version of a component. 

In the case of a vulnerability, should they upgrade to include the fix, or should they defer and keep the vulnerable but validated version until the next release of Red Hat Enterprise Linux? To tackle that problem, in Red Hat Enterprise Linux 8 we took the path of reducing the validated cryptographic components by shifting pure-cryptographic algorithms to components dedicated for that purpose. That move eliminates the dilemma for the impacted applications.

During our design of Red Hat Enterprise Linux 8, we have identified a few cases where components in our core set held very few cryptographic primitives, but were still required to be included in our FIPS 140-2 certification processes. Due to that we engaged in communication with the software communities we collaborate with in order to consolidate these cryptographic algorithms to components that made more sense. As part of this effort, Libreswan, our IPSec handling tool, is no longer a cryptographic module, in terms of FIPS140-2; its implementation of the Internet Key Exchange (IKE) Key Derivation Function (KDF) was moved to the NSS cryptographic library. 

Furthermore, the OpenSSH and libssh components moved their cryptographic implementations (e.g., SSH KDF) to OpenSSL. That allowed us to not only reduce the number of modules we certify on the operating system, but also enabled us to follow best practices and move low-level algorithm implementation to components which are designed for that purpose. At the same time, the functionality that was previously covered by our FIPS 140-2 validated components is still covered by the new set.

Also the SSH protocol is more than a secure shell, and it is often seen today as a system management protocol. Therefore we added libssh, an SSH library, to our core crypto components. This library can be used by applications directly, and we find that it integrates with applications better than an external tool like OpenSSH could. As of today, this library is used by applications such as cURL, QEMU, RHEL's web console and several others.

Table 1 summarizes the core cryptographic components in Red Hat Enterprise Linux and their status.

For more detailed information on the core crypto components you can see this article and the Red Hat Government Standards page. Components in Red Hat Enterprise Linux 8 are depending on these core cryptographic components; known applications which do not use FIPS 140-2 validated cryptography are listed in this article.

Hashing and password hashing

Additionally, we no longer treat the non-security related use of hash functions, as well as password hashing techniques, as a data protection mechanism relevant to our FIPS 140-2 validations. 

In particular, the popularity of using and bundling a cryptographic hash function in applications to implement a non-cryptographic use (e.g., a data protection-irrelevant identifier), has prompted us to re-evaluate our approach and relax our requirements on these uses. On the other hand, we actively reviewed, identified, and fixed numerous issues of open source software which were either re-implementing cryptographic algorithms or using cryptography in an incorrect way. Some prominent but unexpected examples of applications which we found to be re-implementing cryptography were productivity tools like LibreOffice. We're happy to say we worked with LibreOffice, and they accepted our solution to use OpenSSL for its cryptographic needs.

Furthermore, password hashing is no longer seen as a sufficient data-protection mechanism to be employed unattached to another protection mechanism. As such, we no longer actively pursue the use of core crypto components for the described use cases. In particular we introduced a new password hashing library, libxcrypt as a replacement for the GNU libc project’s libcrypt password hashing library which is no longer part of the upstream distribution. This component introduces many modern techniques in password hashing and are all made available in Red Hat Enterprise Linux 8 irrespective of their relation to FIPS 140-2 approved cryptographic primitives.

Conclusion

In Red Hat Enterprise Linux 8 we reiterate our intention to pursue FIPS 140-2 validation for our cryptographic components, starting with RHEL 8.1 and each minor release afterwards, providing an additional assurance to our users and customers about our approach towards the quality of our cryptographic implementations. The validated components are different than the past due to our work in consolidating modules, something that enables faster adoption of fixes in security vulnerabilities for environments that have strict FIPS 140-2 compliance requirements. 

Furthermore, we restrict the scope of FIPS 140-2 compliance for our components to data protection, where we believe it matters most. We have also listened to the feedback we have been receiving and simplified the FIPS mode enablement, saving time to our users. All of these changes, enable more and more applications to rely on FIPS 140-2 validated cryptography, as we demonstrate with the golang modifications to rely on the openssl cryptographic library.

With Red Hat Enterprise Linux 8.1 we provide you with a solid cryptographic base which is currently under validation for the FIPS 140-2 certification. We welcome you to use and develop on that version of the operating system and let us know about your experience and expectations on FIPS 140-2 certifications at fips140@redhat.com.