Transition of OpenSSL for implementing PQ/T TLS

Introduction

In the landscape of modern cryptography, the agility provided by cryptographic libraries’ application programming interfaces (APIs) has become paramount. Today’s applications require the ability to swiftly adapt to evolving security requirements without the need for extensive modifications to their source code. Cryptographic libraries serve as the bedrock of security for a wide array of modern applications, are deeply integrated into operating systems, and serve as the foundation for user-facing software, system tools, runtimes, and libraries.

Major cryptographic libraries offer extensibility through pluggable loadable modules, enabling support for both hardware and software security modules. Leveraging these capabilities presents an opportunity to transition towards Post-Quantum Cryptography (PQC), addressing the looming threat posed by quantum computers to classical cryptographic schemes.

Today, the transition to PQC is driven not merely by the speculative arrival of a cryptographically relevant quantum computer (CRQC), but by the immediate necessity imposed by emerging national guidelines around the world. Among these, the NSA’s CNSA 2.0 guidelines stand out as a prominent example that underscores the urgency of adopting quantum-resistant cryptographic standards now, ahead of potential quantum threats. Similarly, in Europe, different institutions are publishing recommendations and technical guidelines for the PQC transition: relevant examples include the EU Commission Recommendation on a Coordinated Implementation Roadmap for the transition to Post-Quantum Cryptography, BSI’s recommendations about Quantum Technologies and Quantum-Safe Cryptography, the BSI TR-02102-1 Technical Guideline, and ANSSI position paper on PQC.

Documents such as these serve as a clear directive that the move towards secure, quantum-resistant algorithms is imperative and imminent, reflecting a shift from a theoretical risk to a present-day priority that requires immediate and decisive action to protect sensitive information in an increasingly vulnerable digital landscape.

The proactive approach recommended by these guidelines is critical not only for maintaining national security but also for ensuring that organizations globally remain compliant with emerging security requirements.

Loadable modules play a pivotal role in the adaptability and extensibility of cryptographic libraries. By allowing users to plug in modules at runtime, these libraries can seamlessly incorporate support for new cryptographic algorithms or implementations into applications without requiring modifications to the core library itself.

This capability becomes particularly relevant when transitioning to PQC. We propose the use of shallow modules—modules that do not contain specific cryptographic implementations—as a means to navigate the rapidly evolving landscape of optimized implementations for PQC primitives. This approach not only facilitates the decoupling of external implementations from the specific data types and patterns required for compatibility with cryptographic libraries, but it also enables libraries to keep up with the fast-paced development in the PQC ecosystem.

It is important to emphasize that our focus lies not in designing new cryptographic algorithms or implementations but in integrating state-of-the-art optimized implementations for PQ/T (Post-Quantum/Traditional) hybrids and primitives. The shallow module approach affords us the flexibility to explore a myriad of solutions, including software and hardware alternatives, implementations in different programming languages, schemes with formal verification guarantees, and hybrid approaches. By adopting this approach, we can effectively navigate the complexities of transitioning towards PQC while ensuring compatibility, efficiency, and security across a diverse range of applications and environments.

OpenSSL and TLS

The TLS protocol is used to secure HTTPS traffic as well as other services that are commonly provided over the internet, such as email. When a TLS client first connects to a TLS server, the two programs perform a handshake, which has two major components:

• Key exchange: the client and server use asymmetric cryptography to establish a shared secret, which they will use to encrypt their communication with each other for the rest of the session.
• Authentication: the server sends a digitally signed X.509 certificate that proves its identity. It also uses its private key (corresponding to the public key on the certificate) to sign a digest of the messages exchanged in the handshake up to that point, proving that the client really is communicating with the same entity to which the provided certificate pertains.

Each of these steps is separately vulnerable to attack by a quantum computer if traditional cryptography is used, but their relative risk profiles differ.

In the case of the authentication step, the attack by a quantum computer, once the traditional digital signature algorithm is compromised, involves a two-step process:

1. Extraction of the Private Key: The quantum computer can potentially extract the private key from the public key or a certificate, an attack that can occur out of band. This step does not require real-time access and can be conducted retrospectively on any previously obtained public key or certificate data.
2. Impersonation via Man-in-the-Middle Attack: With the private key compromised, an attacker can then impersonate the server in real time by either using a forged server certificate or the extracted private key to deceive a client into believing it is communicating with the legitimate server.

Most notably, within the context of TLS, even with quantum capabilities, retroactive impersonation is not possible. Thus, only connections initiated after a CRQC has extracted a private key are vulnerable to authentication compromise.

However, in order for a quantum computer to attack the key exchange step after the traditional key exchange algorithm is broken, it is enough that it has a recording of an encrypted communication session and the handshake used to establish it. If the attacker can compute the shared secret by examining the handshake, then they can decrypt the data that was exchanged during the session, regardless of how long ago the encrypted communications were recorded. This is known as a “Harvest Now, Decrypt Later” (HNDL) attack, and it is already of great concern for confidential data.

Making the transition to PQC algorithms is generally considered more urgent for the key exchange step than for the authentication step, since data being transferred over the internet right now with traditional key agreement algorithms is already at risk. However, when assessing the urgency of the transition, we must take into account not only the technical capabilities of the computer systems involved but also the human and cultural factors: how easy (or hard) it is to deploy implementations of the new algorithms and how long it takes them in practice to gain widespread adoption after they become technically feasible. The issue of adoption time illustrates why we cannot be too complacent about the transition timeline for digital signature algorithms in the authentication step. Based on the slow pace of the ongoing transition from RSA to elliptic curve cryptography for traditional signatures, it seems likely that the transition to post-quantum digital signature algorithms will be a long and drawn-out process as well, regardless of how quickly it becomes technically feasible to make the switch.

OpenSSL 3.0 added support for Providers: loadable modules that make third-party implementations of cryptographic primitives available to OpenSSL at runtime. This is a significant change from previous versions, which offered some limited support for third-party implementations but could not support nontraditional TLS groups unless patches were applied to the OpenSSL source code (e.g., https://ia.cr/2021/826). The OpenSSL 3.2 release has further enhanced Provider support and capabilities, fully enabling third-party Providers to incorporate PQC primitives in the TLS 1.3 handshake. This ability to use these new primitives in applications relying on OpenSSL without the need for modifications or recompilation of OpenSSL itself, is a major advancement for cryptographic agility, crucial for the transition to PQC.

Related work

In the evolving field of post-quantum cryptography, the Open Quantum Safe Project (OQS) stands as a notable initiative, assembling a comprehensive library of quantum-resistant algorithms. At the heart of this initiative are two key projects: liboqs, which serves as a foundational library for testing a broad spectrum of PQC algorithms, and oqs-provider, specifically tailored to facilitate the integration of these algorithms into OpenSSL (3.x). This ensures that the advancements made can be directly applied to systems that are critical for securing Internet communications.

Parallel to OQS, the PQClean Project gathers various implementations of PQC algorithms. Unlike OQS, PQClean focuses on providing clean, portable, and efficient algorithm implementations, setting the stage for future secure applications without aiming for direct integration into existing platforms.

Contributing to the landscape, SLH-DSA SLotH, developed by Markku-Juhani O. Saarinen at Tampere University, aims to enhance the efficiency of digital signatures. By refining implementations of the FIPS 205 SLH-DSA Hash-Based Signature Standard with better padding and hashing, it targets performance improvements in hardware, critical for both speed and security. SLH-DSA SLotH presents a practical examination of optimizing PQC algorithms for real-world applications, focusing on the speed of signing and verification processes.

Adding to these efforts, on February 6, 2024, the Linux Foundation announced the launch of the Post-Quantum Cryptography Alliance (PQCA) . This initiative brings together industry, academia, and developers to advance and adopt PQC, focusing on producing high-assurance software implementations of standardized algorithms. The PQCA, with support from major tech entities like Amazon Web Services and Google, aims to foster cryptographic agility and prepare for the U.S. NSA’s Cybersecurity Advisory guidelines, and will oversee the continuation of the OQS Project.

Within the framework of PQCA, the PQ Code Package Project was initiated to build high-assurance software implementations of standards-track PQC algorithms, starting with the ML-KEM algorithm. The project prioritizes external audits and formal verification methods to ensure the reliability of these implementations.

Each one of these and other similar contributions, plays a critical role in preparing digital security for the age of quantum computing. Together, these efforts represent an important advancement toward securing our communications against the potential threats posed by advancements in quantum technology.

The QUBIP OpenSSL provider

The OQS provider is unusual among these projects in that it actually provides an interface between PQC algorithm implementations and a software library that provides TLS connection functionality (namely OpenSSL), rather than only providing standalone implementations. While this is an extremely impressive project, its agility is limited by the fact that the provider code and the implementations themselves are intertwined. Adding a new algorithm or a new implementation to the OQS provider would require making changes within the provider itself.

To accommodate how rapidly the ecosystem of PQC algorithm implementations is evolving, the QUBIP OpenSSL provider will be shallow: instead of containing algorithm implementations directly, it will serve only as an intermediate layer that allows OpenSSL to make use of standalone third-party implementations. This is possible because the implementations generally use the same API, which was first specified as part of the NIST PQC standardization project. We aim for functional compatibility with the OQS provider: if suitable implementations are available on the system, then an application that uses OpenSSL to handle TLS connections should be able to use the OQS provider or the QUBIP provider interchangeably.

Thanks to the shallow module approach, the QUBIP provider will empower users to make their own choices when it comes to the security assurances provided by the underlying implementations, without incurring the overhead of writing a separate provider for each implementation. One use case might demand a formally verified implementation, while another might require an implementation written in a memory-safe language, or one that runs on dedicated hardware. It will also make it easy to integrate the hardware results from other parts of the QUBIP project into the software stack to build realistic demonstrators of end-to-end post-quantum-secure communication.

Conclusion

The transition of OpenSSL to support PQC is more than a technical upgrade; it represents a crucial shift for the entire cryptographic ecosystem. As quantum computing advances, the ability of OpenSSL to integrate PQC algorithms ensures that the backbone of internet security remains robust against emerging quantum threats. This transition is vital for protecting the integrity and privacy of global digital communications today and into the future.

The QUBIP OpenSSL Provider offers a strategic enhancement in the realm of cryptographic agility and quantum resistance. Its design, which focuses on a shallow module approach, allows for effective adaptation and integration of evolving PQC algorithms. This enables applications to seamlessly incorporate state-of-the-art quantum-resistant cryptography without the need for significant modifications. The QUBIP Provider‘s innovative approach facilitates a more flexible adoption of quantum- secure technologies, complementing ongoing efforts and enriching the existing landscape of post-quantum cryptographic solutions.