RHEL core cryptographic components

Updated -

Introduction

Cryptographic software is treated specially in Red Hat Enterprise Linux. That is because cryptographic software while it is often easy to implement, it is very hard to get right, and is even harder to keep relevant and up-to-date for the years to come. The reasons are the following. Cryptographic software is expected to protect from a constantly expanding threat model; for example, software originally designed to resist an attacker performing network eavesdropping, today is expected to provide the same security assurances under environments like VMs, containers, and so on, sharing the same CPU with the attacker. Furthermore, in any complex system, the remote access interface relies on cryptographic implementations, making cryptographic software the system's entry point.

It is thus necessary to ensure that cryptographic software is not only continuously updated to reflect the most current threat models, but also simple enough and configurable to allow quick response to the aforesaid threats.

Hence, to reduce our attack surface and to be able to respond quickly to new requirements, RHEL provides a relatively small cryptographic core, with hooks for various languages over it. The cryptographic core follows our ABI and API guarantees, it is submitted to exhaustive testing and it undergoes frequent validation with national and international standard certification programs.

Which are the RHEL core cryptographic components?

The RHEL cryptographic core consists of the following components which provide low-level cryptographic algorithms (ciphers, hashes, and message authentication codes, etc.), cryptographically secure random generators, and secure communications protocol implementations, such as TLS and SSH.

Component FIPS-140 cryptographic module Description
OpenSSL Yes General purpose cryptographic toolkit library which includes TLS and DTLS implementations as well as SSH KDF primitives
GnuTLS Yes Cryptographic toolkit which is focused on a simple to use TLS and DTLS implementation
NSS Yes The cryptographic toolkit library of the Firefox browser; it follows the Firefox ESR lifecycle with asynchronous updates and feature enablement or removal
libgcrypt Yes The GnuPG cryptographic library
kernel Yes The Linux kernel internal cryptographic library
OpenSSH No; It implements no FIPS-140-relevant cryptography, it uses the OpenSSL module The SSH client and server applications of the operating system
libssh No; It implements no FIPS-140-relevant cryptography, it uses the OpenSSL module A secure communications library implementing the SSH protocol
Libreswan No; It implements no FIPS-140-relevant cryptography, it uses the NSS module The IPsec client and server applications of the operating system

Note that the cryptographic primitives provided by the components above are difficult to use in a secure way. Custom implementation of security protocols should be avoided. For protecting the confidentiality and integrity of network transmissions, we recommend the use of standardized protocols such as the TLS protocol, or the SSH and Kerberos protocols when applicable.

The following table summarizes our recommendations for secure communications and cryptographic components in higher-level environments and languages.

Environment Recommended API / component Dependencies
Apache httpd mod_ssl openssl
GNOME glib-networking gnutls
Go crypto.go openssl (when in FIPS mode)
Java javax.crypto NSS (when in FIPS mode since RHEL 8.3)
Node.js crypto, tls openssl
Perl IO::Socket::SSL,Net::SSLeay openssl
Python python-cryptography,python ssl openssl
Ruby OpenSSL openssl

What about consistency and integration of the provided components?

Despite the fact that we provide a number of crypto libraries on the operating system, we ensure that consistent settings are enforced across them. In particular, we make sure that all the components follow a secure and consistent cryptographic policy, and for validation of certificates in Internet PKI that they share the same set of root CA certificates. The common set of root CA certificates is created using the Mozilla trust store as a base.

In RHEL 8, we introduced the system-wide cryptographic policies to bring the operating system on par with modern challenges. As systems become more and more disposable, administrators do not spend time fine-tuning the short or long-lived applications, nor need to know which exactly back-end is in use by their application in order to properly configure it. As such, we provide consistent settings on the operating system, irrespective of the back-end in use. We ensure that the enabled algorithms and protocols are consistent, comply with industry standards ,and provide a good balance between security and interoperability by default. The system-wide settings can be controlled using the update-crypto-policies command.

To access a CSPRNG in an application, the use of the kernel’s getrandom() interface is recommended only when no cryptographic library is used. When an application is already depending on one of our core crypto libraries, we recommend using that library’s provided interfaces. For more information, the Red Hat Enterprise Linux random generator interface is described in detail in this blog post.

Hardware security modules (HSM) allow placing private keys outside the application's address space. That approach of private key isolation, implements the principle of a defense in depth to system security, preventing issues on the application code in result to a costly recovery process in the aftermath of an attack (for example, see the heartbleed attack).

Hardware security modules and smart cards are typically accessed through the industry-standard PKCS #11 interface. Every HSM comes with a shared library that implements that interface, which is in turn used by applications.

In RHEL 8, we introduced a system-wide registration of HSMs and other PKCS #11 modules by using p11-kit and pkcs11.conf(5). That way, applications relying on core crypto modules such as Apache, OpenSSH, wget, curl, and others, require no additional setup to use HSMs and smart cards. Furthermore, we ensure that objects are referred consistently in all RHEL application configuration files, by standardizing over PKCS #11 URIs (RFC7512), across the operating system, for identifying HSMs or objects stored within an HSM.

Component Description
NSS Native PKCS #11 in the library API
GnuTLS Native PKCS #11 in the library API for public-key operations
OpenSSL Provides PKCS #11 support through the openssl-pkcs11 component (engine_pkcs11)

For more information about supported smart cards, see the Smart-card support in RHEL 8 and later Knowledgebase article.

Cryptographic certifications

We strive to make Red Hat Enterprise Linux a modern operating system which includes the most recent community enhancements and features, but at the same time, we aim to be conservative in the security-critical features we introduce. Our goal is to bring cryptographic components which provide tried and tested protocols and algorithms, following not only international standards, but also industry best practices.

Why certifications matter?

While certifications are often seen as a matter irrelevant to the open source communities, taking a step back from any specific requirements, existing certifications are about the following principles.

  • Unit testing of crypto implementations;
  • Logically separating cryptography from application code;
  • Reliance on conservative cryptographic primitives.

While one may disagree on a particular detail such as which algorithm is more conservative or stronger, these high-level principles are important for any software that is intended to remain relevant for a long time. The certification process allows to "prove" that set of properties in cryptographic software, without going through an elaborate implementation review.

Which certifications are available and what is covered?

Cryptographic components in Red Hat Enterprise Linux undergo the FIPS 140 and Common Criteria certifications. You can find more information about the particular certificates in the following articles:

In the context of the certifications of cryptographic components, we ensure that they cover

  • cryptographic-algorithm APIs (for example, AES, SHA2-256, RSA),
  • cryptographic-protocol APIs (for example, SSH, TLS),

of all the core cryptographic components. Components which are provided for backwards compatibility, such as compat-openssl10 or compat-openssl11, do not undergo any certifications.

How often is Red Hat Enterprise Linux FIPS-140-certified?

Red Hat intends to FIPS-140-certify all minor releases of Red Hat Enterprise Linux 8 and later, beginning with the first minor release. Up-to-date FIPS certification status, for completed and in-progress certifications, is kept on the Compliance Activities and Government Standards .

What about insecure algorithms in standards?

While it is not common to see insecure algorithms in national or international standards, for a long time, there have been questions on algorithm selection criteria, how certain parameters were selected, and outright examples of weak algorithms included. These, given the positive impact standards have in our systems, both in terms of interoperability and security, should not undermine the importance of having standards and standards bodies. They should, however, underline the need to look at standards with a critical eye.

Furthermore, the reason that none of these issues affected our operating system, is because such standards rarely impose one particular algorithm or solution. They often provide a range of acceptable algorithms or protocols; for example, in the FIPS 140 standard, multiple options are provided for the random generator. In these cases, to ensure the certification of our operating system, we exercise our own judgment based on various factors, such as the acceptance of the algorithm under question by academic and other cryptographic communities, on performance and suitability analysis, and the opinion of our experts in the field.

How are security vulnerabilities handled?

Components in Red Hat Enterprise Linux are always updated to address security vulnerabilities, irrespective of their certification status. As certifications are bound to the particular version of the component that was validated, that may cause a problem to organizations that are required by guidelines to use a validated version of a component. That fact, is known problem to certification bodies such as NIST, and we are working with them to address it, however, we assert that it is imperative for systems to be updated to address vulnerabilities.

How does RHEL handle FIPS-140 requirements?

(see also the more extensive article on How RHEL 8 is designed for FIPS-140-2 requirements)

The FIPS-140 requirements are too restrictive for typical use of a server; for example, only specific key sizes and key generators are allowed, preventing a switch to larger key sizes if deemed necessary. As such, applications in RHEL do not operate under that mode by default.

We provide a system-wide FIPS mode, which switches the core crypto components to their corresponding FIPS-140 mode. In that mode the random generation, and required power-on and continuous self tests are enabled in the core components (see the next section for more information).

In RHEL 8, we have significantly simplified the method to switch to FIPS mode with the introduction of the fips-mode-setup command. An administrator can switch the system to FIPS mode using the following command:

# fips-mode-setup --enable

For more details, see the Switching RHEL to FIPS mode chapter in the RHEL Security hardening document.

However, that switch to FIPS mode must occur prior to installing the system or configuring any application on top of RHEL. Otherwise, the software will be operating under an unknown environment and may malfunction.

What about application compliance with FIPS 140?

To ensure application FIPS-140 compliance under RHEL, the application writer must follow the "Guidance" section of the security policy of the core cryptographic component it is depending on. The security policies for all crypto modules are available as a companion to the component's certificate at the Package requirements for FIPS 140-2 compliance in RHEL page.

The following paragraphs provide more information about the core cryptographic components in FIPS 140-2 mode, to serve as an informal rule of thumb for applications intended to run on RHEL.

The RHEL cryptographic core is designed in a way to minimize the amount of work required for application compliance. If an application utilizes our core crypto components, or our recommended wrappers and its development follows industry best practices (for example, CII best practices, IETF recommendations for TLS and so on), it is expected to operate smoothly in RHEL FIPS140 mode.

The application behavior and its compliance depends on the underlying component used by it. The following table summarizes the behavior of the core libraries in FIPS mode.

Component Behavior in FIPS mode
OpenSSL Non-approved algorithms are blocked by default. Applications using OpenSSL 3.0 can use algorithms disallowed by FIPS-140 by explicit changes in the code allowing the use of non-FIPS algorithms on fetching the algorithm objects
GnuTLS Non-approved algorithms are blocked; applications can use algorithms disallowed by FIPS-140 by using the gnutls_fips140_set_mode function
NSS The application is expected to avoid using non-approved algorithms.
libgcrypt The application is expected to avoid using non-approved algorithms (the use of non-approved algorithms switches the component to non-compliant mode) in RHEL 8. In RHEL 9, the non-approved algorithms are blocked except for symmetric cipher modes, MACs, KDFs, Digests and non-approved API functions. The application can query if the cipher+mode combination, KDF, Digest or function is approved using the gcry_control API
kernel (AF_ALG) Non-approved algorithms are blocked

Do RHEL applications depend on the core cryptographic components?

Components in Red Hat Enterprise Linux 8 and later are depending on the core cryptographic components; known applications which do not use FIPS-140-validated cryptography are listed in the RHEL Security hardening document.

What about other cryptographic libs in RHEL

Red Hat Enterprise Linux contains a few alternatives to the core cryptographic components. These are divided in two categories explained below. Any components falling into these categories, unless they are mentioned in the section on the recommended way to use core crypto components, are not recommended to use, and their compliance with various certification requirements is unknown.

Low-level components considered internal implementations

Some components provide only low-level APIs which offer an unstable API or ABI interface, or cannot fulfill the requirements of a policy such as FIPS 140 (for example, start-up checks). An example for such component is nettle, which for the RHEL purposes is considered an internal component of GnuTLS.

High-level components which wrap a core cryptographic component

For mainly historical reasons there are few components which wrap over a core crypto library over an environment (for example, a language such as Python). These are shipped by RHEL because of their popularity, but their compliance status, for example, their usage of the core cryptographic library under the security policy is unknown. An example of this component is m2crypto which wraps over OpenSSL.

How are quantum computer threats handled in RHEL?

It is expected that quantum computers will pose a significant threat to existing cryptosystems in the next decades, and the RHEL crypto core is no exception to that. The challenge in replacing the traditional cryptosystems with post-quantum safe algorithms carries several logistical costs, which are not confined to providing the replacement algorithms, but extend to addressing obstacles such algorithms may have as in-place replacements of the old cryptosystems, in addition to establishing these algorithms as a universally accepted standard and including them in secure communications protocols. That is an industry-wide effort that is currently on its first phase, the replacement algorithm selection. Towards that, we closely follow standardizations' bodies work, such as NIST's post quantum competition. Furthermore, as short-term mitigation against quantum computer threats, we ensure that our core crypto components in the operating system operate properly with pre-shared keys and large key sizes on the traditional cryptosystems.

See also

Comments