Table of Contents
- Which are the RHEL core crypto components?
- What are the recommended cryptographic components in higher-level environments?
- What about consistency and integration of the provided components?
- What is the recommended way to access a cryptographic random generator?
- What is the recommended way to use hardware security modules and smart cards?
- Crypto certifications
- Why certifications matter?
- Which certifications are available and what is covered?
- How often is Red Hat Enterprise Linux FIPS-140-2-certified?
- What about insecure algorithms in standards?
- How are security vulnerabilities handled?
- How does RHEL handle FIPS-140-2 requirements?
- What about application compliance with FIPS140-2?
- Do RHEL applications depend on the core crypto components?
- What about other crypto libs in RHEL
- Low-level components considered internal implementations
- High-level components which wrap a core crypto component
- How are quantum computer threats handled in RHEL?
- See also
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 crypto components?
The RHEL crypto 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 crypto module||Description|
|OpenSSL||Yes||General purpose cryptographic toolkit library which includes TLS and DTLS implementations|
|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-2-relevant cryptography, it uses the OpenSSL module||The SSH client and server applications of the operating system|
|libssh||No; It implements no FIPS-140-2-relevant cryptography, it uses the OpenSSL module||A secure communications library implementing the SSH protocol|
|Libreswan||No; It implements no FIPS-140-2-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.
What are the recommended cryptographic components in higher-level environments?
The following table summarizes our recommendations for secure communications and cryptographic components in higher-level environments and languages.
|Environment||Recommended API / component||Dependencies|
|Go||crypto.go||openssl (when in FIPS140 mode)|
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
What is the recommended way to access a cryptographic random generator?
In order 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.
What is the recommended way to use hardware security modules and smart cards?
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 (e.g., 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.
|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 on supported smart cards, see the Smart Card support in RHEL 8+ KB article.
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-2 and Common Criteria certifications. You can find more information about the particular certificates in the following articles:
- RHEL Common Criteria FAQ
- List of certificates for RHEL releases
- Government standards adhered by RHEL releases
In the context of the certifications of cryptographic components, we ensure that they cover
- cryptographic-algorithm APIs (e.g., AES, SHA2-256, RSA),
- cryptographic-protocol APIs (e.g., SSH, TLS),
of all the core crypto 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-2-certified?
Red Hat intends to FIPS 140-2 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 Red Hat Government Standards page.
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-2 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-2 requirements?
(see also the more extensive article on How RHEL 8 is designed for FIPS-140-2 requirements )
The FIPS-140-2 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-2 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 the system to FIPS mode section in the RHEL Security hardening document.
Note however, that a 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 FIPS140-2?
To ensure application FIPS-140-2 compliance under RHEL, the application writer must follow the "Guidance" section of the security policy of the core crypto 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 crypto components in FIPS140-2 mode, to serve as an informal rule of thumb for applications intended to run on RHEL.
The RHEL crypto 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 (e.g., CII best practices, IETF recommendations for TLS, etc), it is expected to operate smoothly in RHEL FIPS140-2 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; applications can use algorithms disallowed by FIPS-140 by using special flags (
|GnuTLS||Non-approved algorithms are blocked; applications can use algorithms disallowed by FIPS-140 by using the
|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 and KDFs. The application can query if the cipher+mode combination or KDF is approved using the gcry_control API|
|kernel (AF_ALG)||Non-approved algorithms are blocked|
Do RHEL applications depend on the core crypto 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-2-validated cryptography are listed in this article.
What about other crypto libs in RHEL
Red Hat Enterprise Linux contains a few alternatives to the core crypto 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-2 (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 crypto component
For mainly historical reasons there are few components which wrap over a core crypto library over an environment (e.g., a language such as python). These are shipped by RHEL because of their popularity, but their compliance status, e.g., their usage of the core crypto 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.