How Red Hat is integrating post-quantum cryptography into our products

In a previous post-quantum (PQ) article, we introduced the threat that quantum computing presents for any systems, networks and applications that utilize cryptography. In this article, you’ll learn what you can do to assist your organization in achieving crypto-agility with Red Hat and what to expect of Red Hat products as we begin to integrate post-quantum cryptographic functions into them.

The capabilities described in the following sections assume timely and functional implementation of industry standards and specifications and the libraries that implement them. If these are not achieved, availability of these PQ-capabilities will likely be delayed.

****How you can get ready to take advantage of post-quantum cryptographic functions****

Customers are encouraged to inventory their sensitive and critical data and its location in their environments, and also to understand where they are receiving their encryption protections for this data. This can help them prioritize crypto-agility efforts on their most highly sensitive and critical assets and data.

****Concerning data at rest****

Customers will have to evaluate how to limit access to keys encrypted with classical asymmetric algorithms until a general solution for quantum-resistant key wrapping can be deployed. Data is generally encrypted with symmetric ciphers, and customers are recommended to make sure the key size is appropriate for the data they are protecting and to consider schemes that can provide 256-bit strength. The keys used in these schemes may themselves be protected using asymmetric encryption.

****Concerning data in transit and key exchange****

Customers will be able to optionally configure PQ-Capable Transport Layer Security (TLS), which is planned for inclusion in RHEL 10 but will not be enabled by default. For the Secure Shell protocol (SSH), Red Hat is waiting for upstream community adoption of NIST’s recent algorithm decision. When the upstream community has adopted the determined algorithm, Red Hat plans to integrate the appropriate packages and libraries for inclusion in a future RHEL version. Red Hat is closely monitoring the IETF’s discussion regarding Internet Protocol Security (IPsec) and once a decision has been made, Red Hat intends to identify a path for productization.

****Concerning data in transit and certificates****

While still early in the standardization process, TLS certificates will require years to standardize and then reach sufficient adoption due to a fundamental rebuild of world-wide Public Key Infrastructure (PKI), which is needed to transition to quantum-resistant certificate signature. Many outstanding decisions need to be made such as options for encoding post-quantum algorithms into signatures, decisions around hybrid keys versus separation of classic and post-quantum keys for certificates, compression due to key size, and more.

Red Hat is exploring the impact of this change across the upstream open source projects that we participate in along with Red Hat products, with the intent to be in the best position for the change with the least amount of impact. While SSH certificates are somewhat easier to deploy due to locality, the simplicity of their certificate structure and the “trust on first use” (TOFU) model do not use a centralized PKI or certificate chains which would otherwise be leveraged to facilitate the transition to PQ-Ready SSH certificates.

While IPsec certificates are subject to the same complexity and rebuild as TLS certificates, IPsec deployments often use custom certificate chains (private PKIs), so customers may experience a speedier deployment than public TLS in this regard. It is still dependent on the IETF coming to a decision.

****Concerning signing****

For software signing, Pretty Good Privacy (PGP) signatures which are used for RPM Package Manager (RPM) and Dandified Yum package manager (DNF), are currently undergoing standardization of resistant schemes with the IETF. The Sigstore project, to which Red Hat is a contributor, has a plan for adding configurable signing algorithms which may ease the transition to quantum-resistant algorithms in the future. Red Hat is engaged and keeping track of these efforts so as to quickly integrate quantum readiness into the portfolio.

For document and email signing, Cryptographic Message Syntax (CMS) and Secure/Multipurpose Internet Mail Extensions (S/MIME) are under development with standards bodies and organizations of competence (i.e. NIST, IETF, and others) and will experience similar challenges to implement as with TLS certificates and PKI infrastructure. Use of PGP signatures for document and email signing are contingent upon standardization with IETF as previously noted.

****What to expect of Red Hat products****

Red Hat Enterprise Linux (RHEL) serves as the foundation for Red Hat products. As RHEL cryptographic libraries become PQ-Capable and PQ-Ready, other Red Hat products will adopt those libraries. Some Red Hat products use or include cryptographic libraries that are not provided by RHEL in addition to or in place of cryptographic libraries provided by RHEL. These products will be adopting and integrating libraries that utilize NIST-approved quantum-resistant algorithms when they are available either as RHEL-provided or as part of their planning cycle (depending on the library and its source). As a result, customers will experience variability in the availability of PQ-Capable and PQ-Ready products.

Each product will have a different timeline for becoming PQ-Capable and PQ-Ready. Most products will follow behind RHEL, subject to cryptographic function use, affected libraries, protocols and other dependencies. For example, if a cryptographic function is available in RHEL, it does not mean that it is readily available in Red Hat OpenShift at the same time. At this time there are no plans to deliver existing products with post-quantum cryptographic functions enabled by default.

****RHEL****

Customers can expect RHEL 10 to be PQ-Capable. Red Hat is targeting RHEL 10 to provide NIST-approved post-quantum cryptographic functions for RHEL and for use in custom applications. Customers can expect that some RHEL 10 components will use these functions, but not all RHEL 10 components will be PQ-Ready. Where RHEL 10 components have post-quantum cryptographic functions available, they will not be used by default in those components. Customers will be able to configure their RHEL servers to use post-quantum cryptographic functions in PQ-Capable components.

Customers should not anticipate post-quantum cryptographic functions to be backported or included in RHEL 9 or earlier versions of RHEL.

Customers can expect future RHEL releases to become PQ-Ready. In future RHEL releases, post-quantum cryptographic functions will be available, and most RHEL components will transition to PQ-Ready.

****Red Hat OpenShift****

Customers leveraging Red Hat OpenShift will inherit PQ-Capable cryptography as RHEL 10 becomes integrated. OpenShift uses Red Hat Enterprise Linux CoreOS , a container-oriented operating system that is specifically designed for running containerized applications. When the RHEL 10-based PQ-Capable kernel is available and as other RHEL crypto libraries incorporate post-quantum cryptography, these will be included in Red Hat Enterprise Linux CoreOS and it will become PQ-Capable. In addition, OpenShift layered operators will, over time, be updated with RHEL 10 content.

Customers leveraging Red Hat OpenShift will inherit PQ-Ready cryptography as included components become PQ-Ready, integrated, configured by default and released. Following the same consecutive events defined above, the OpenShift family of products will become PQ-Ready as future RHEL-based PQ-Ready kernels are available and as directly incorporated post-quantum crypto libraries are configured as default, with the option to configure classical algorithms as needed. As new kernels are available, customers should expect some delay between their availability and the time at which the OpenShift family and other layered products provide PQ-Ready content.

****Red Hat OpenStack Services on OpenShift****

Customers leveraging Red Hat OpenStack Services on OpenShift and previous versions of Red Hat OpenStack Platform will inherit PQ-Capable cryptography as RHEL 10 and OpenShift become integrated. Red Hat OpenStack Services on OpenShift and the above are based on two main pieces:

• Red Hat OpenStack Services on OpenShift control plane is now in the OpenShift family of products, with pods running on OpenShift and as such uses the cryptography provided by Red Hat Enterprise Linux Core OS. Please refer to the OpenShift section
• Red Hat OpenStack Services on OpenShift data plane is based on RHEL, and as such leverages the RHEL provided cryptographic modules. Please refer to the RHEL section

When both products use PQ-Ready kernels, Red Hat OpenStack Services on OpenShift will be PQ-Capable.

Customers leveraging Red Hat OpenStack will inherit PQ-Ready cryptography as included components become PQ-Ready, integrated, configured by default and released. Following the same consecutive events defined above, OpenStack will become PQ-Ready as both RHEL and OpenShift/Red Hat Enterprise Linux Core OS become PQ-Ready.

****Red Hat Ansible Automation Platform****

Customers using Ansible Automation Platform will inherit PQ-Capable and PQ-Ready cryptography as it becomes available, integrated and released. Ansible Automation Platform consumes cryptography provided by RHEL, so statements regarding PQ-Capable and PQ-Ready overall follow what is stated for RHEL.

****Red Hat Middleware and Application Services****

Customers using Red Hat Middleware and Application Services will inherit PQ-Capable and PQ-Ready cryptography as it becomes available, integrated and released. Red Hat’s collection of Middleware products and Applications Services (such as JBoss EAP, Data Grid, AMQ, Fuse, Quarkus and others) consume cryptography provided by RHEL. Therefore, statements regarding PQ-Capable and PQ-Ready overall follow what is stated for RHEL. Any cryptographic exchange not originating with Red Hat products (such as endpoint/client initiated) is outside Red Hat’s authority to provide post-quantum timelines. PQ-Capable and PQ-Ready statements do not apply to Middleware and Application services that are not currently packaged with cryptography.

****Managing ongoing quantum-security risk with crypto-agility****

There is an ongoing risk that cryptanalysis (the process of analyzing and decrypting ciphers, codes and encrypted text to breach cryptographic protections) will uncover severe or even fatal flaws for these new algorithms. As such, Red Hat is committed to helping customers achieve crypto-agility through selection of contemporary and emergent approved algorithms, enabling support for hybrid implementations to maintain a strong security posture as new algorithms and packages are approved, incorporated and used. Please refer to our previous article for more information on hybrid implementation.

Red Hat’s response to vulnerabilities discovered and reported against cryptographic algorithms will adhere to Red Hat’s current vulnerability and incident response program for remediation.

Red Hat remains committed to partnering with upstream open source projects and maintainers to assist and prioritize inclusion of those functions.

****More information****

If you have additional questions, please reach out to your Red Hat account manager. Red Hat is committed to supporting customers in achieving and maintaining post-quantum security.