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, is tough 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.

Thus, cryptographic software must be continuously updated to reflect the most current threat models, simple enough, and configurable to allow quick response to the threats mentioned earlier.

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, is submitted to exhaustive testing, and 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, certified only until RHEL 9
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 previous components are difficult to use securely. Custom implementation of security protocols should be avoided. To protect network transmissions' confidentiality and integrity, use standardized protocols such as the TLS or 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?

Although RHEL provides several cryptographic libraries, we ensure consistent settings are enforced. 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 standard 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 increasingly disposable, administrators do not spend time fine-tuning the short- or long-lived applications, nor do they need to know which exact back-end their application uses to configure it properly. 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. You can control the system-wide settings by using the update-crypto-policies command.

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

Hardware security modules (HSM) allow private keys to be placed 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 Heartbleed vulnerability).

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) until RHEL 9 or pkcs11-provider (since RHEL 10)

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 with the most recent community enhancements and features. Still, at the same time, we aim to be conservative in the security-critical features we introduce. Our goal is to bring cryptographic components that provide tried and tested protocols and algorithms, following international standards and 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 cryptographic 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 essential for any software 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 on the following pages of the Product compliance portal:

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 that are provided for backward 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 FIPS - Federal Information Processing 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 specific parameters were selected, and outright examples of weak algorithms included. Given that standards positively impact our systems, both in terms of interoperability and security, these 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, none of these issues affected our operating system because such standards rarely impose one particular algorithm or solution. They often provide a range of acceptable algorithms or protocols; for example, the FIPS 140 standard provides multiple options for the random generator. In these cases, to ensure the certification of our operating system, we exercise our judgment based on various factors, such as the acceptance of the algorithm under question by academic and other cryptographic communities, 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 constantly updated to address security vulnerabilities, irrespective of their certification status. As certifications are bound to the particular version of the validated component, that may cause a problem for organizations that are required by guidelines to use a validated version of a component. That fact is a known problem to certification bodies such as NIST; we are working with them to address it. However, we assert that systems must 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 the 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 cryptographic 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).

For details, see:
* RHEL 8: Switching RHEL to FIPS mode chapter in the RHEL Security hardening document
* RHEL 9: Switching RHEL to FIPS mode
* RHEL 10:Switching RHEL to FIPS mode

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 on which it depends. The security policies for all cryptographic modules are available as a companion to the component's certificate at the Product compliance: FIPS - Federal Information Processing Standards.

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

The RHEL cryptographic core is designed to minimize the 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 FIPS 140 mode.

The application behavior and its compliance depends on its underlying component. 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 depend on the core cryptographic components; known applications that 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 that 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 of such a component is nettle, which, for RHEL purposes, is considered an internal component of GnuTLS.

High-level components that wrap a core cryptographic component

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

How are quantum computer threats handled in RHEL?

Quantum computers will pose a significant threat to existing cryptosystems in the next decades, and the RHEL cryptographic core is no exception to that. Towards that, we closely follow standardization bodies work, such as NIST's post-quantum competition. Furthermore, as short-term mitigation against quantum computer threats, we ensure that our core cryptographic components in the operating system operate properly with pre-shared keys and large key sizes on the traditional cryptosystems.

The Post-quantum cryptography in Red Hat Enterprise Linux 10, Red Hat's path to post-quantum cryptography, and How Red Hat is integrating post-quantum cryptography into our products articles on the Red Hat blog explain how we are integrating post-quantum cryptography (PQC) into RHEL.

See also

Comments