RHEL7 core crypto components

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 RHEL7 core crypto components?

The RHEL7 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.

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.

What about consistency 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 none of these components enables by default algorithms or protocols considered insecure or obsolete, 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 base.

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 to result to a costly recovery process on the aftermath of an attack (e.g., see the heartbleed attack).

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

In RHEL we strive to support these hardware security modules in a transparent way for the applications. The following core libraries provide support for HSMs and smart cards in their API, while using the PKCS#11 interface underneath.

For more information on the supported smart cards in RHEL please consult this article.

Crypto 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 FIPS140-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

• The cryptographic algorithm APIs (e.g., AES, SHA2-256, RSA),
• The cryptographic protocol APIs (e.g., SSH, TLS).

How often is Red Hat Enterprise Linux FIPS140-2 certified?

Beginning with RHEL 7.4, Red Hat intends to FIPS 140-2 certify all future minor releases of Red Hat Enterprise Linux 7. 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, on 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 FIPS140-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 judgement 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 vulerabilities.

How does RHEL handle FIPS140-2 requirements?

The FIPS140-2 requirements are too restrictive for typical use of 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 FIPS140-2 mode, which switches the core crypto components to their corresponding FIPS140-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).

To switch the system to FIPS140-2 mode, see Enabling FIPS Mode in the RHEL Security Guide.

Note however, that a switch to FIPS140-2 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 FIPS140-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 FIPS140-2 mode.

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 fullfil the requirements of a policy such as FIPS140-2 (e.g., 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 which 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 a 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

• The Red Hat Enterprise Linux 8 crypto components