Numerous blogs and articles are urging security professionals to start migrating to quantum-resistant algorithms immediately. This urgency was heightened on August 13, 2024, when NIST finalized the FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) standards.
In this article, I present a simplified example of a client establishing a TLS 1.3 connection to a standard web server using the quantum-resistant algorithms ML-KEM and ML-DSA. This example highlights key dependencies crucial for a successful post-quantum cryptography (PQC) migration, aiding security professionals in understanding the essential elements for adopting quantum-resistant algorithms.
Dustin Moody , is the project lead for the PQC project at NIST. His messaging was clear on the NIST announcement for the release of their three PQC standards NIST Releases First 3 Finalized Post-Quantum Encryption Standards .
Dustin mentions ‘There is no need to wait for future standards. Go ahead and start using these three. We need to be prepared in case of an attack that defeats the algorithms in these three standards, and we will continue working on backup plans to keep our data safe. But for most applications, these new standards are the main event.’
I appreciate clear and unambiguous messaging. It enables us, as security professionals, to establish firm plans and proceed with quantum-resistant algorithm migration with confidence. However, I also believe that providing some context can help us understand the key dependencies involved in this once-in-a-generation cryptographic migration.
Target Audience: The Creators of PQC vs the Consumers of PQC
Let me clarify what I mean by many of us. This article is written for those in the private and public sector organizations which are not the creators of PQC or those who determine the standards for the adoption of PQC. This article is written for those of us who will be the consumers of quantum-resistant algorithms.
The Creators of PQC
To better understand the rest of this article, it’s helpful to identify those who are creators at the heart of PQC transition. These include cryptographers and computer scientists, who submitted quantum-resistant algorithm standards to NIST, developers and contributors to cryptographic libraries such as OpenSSL, BouncyCastle, WolfSSL, and Open Quantum Safe, and members of the Certificate Authority/Browser (CA/B) Forum who manage specifications for public trust X.509 certificates. Additionally, there are IETF working groups standardizing protocols like TLS 1.3, OASIS managing cryptographic standards such as PKCS#11 and KMIP, and the Trusted Computing Group setting specifications for TPM chips.
To those PQC creators, I salute you and your invaluable work. However, this article is not aimed at you. It is intended for private and public sector organizations that will be the consumers and beneficiaries of your research, work, and collaboration.
The Consumers of PQC
For many of us, whom I shall refer to as the Consumers of PQC, we are the security professionals managing our organization’s PKI, CLM, HSM, KMS, and code signing solutions. We are also the DevSecOps professionals overseeing endpoints that terminate TLS connections, such as web servers and load balancers. Additionally, we are the sysadmins handling DNS name resolution and potentially implementing DNSSEC reliant on digital signatures. We could be mobile application developers eager to work with Apple iOS CryptoKit or Android developers exploring the latest BouncyCastle release. We might also be vehicle ECU software developers utilizing the lightweight WolfSSL library. Creating an exhaustive list of consumers of PQC would be a daunting task, as cryptography permeates many facets of the technology we use.
Set up your own quantum-safe PKI hierarchy and begin your PQC journey today.
Therefore, to those of you seeking meaningful context for ‘adopting PQC,’ I also salute you. We have a long, challenging, and rewarding journey ahead. This article is aimed at you, and I hope that by providing a tangible example of the key dependencies for ensuring a quantum-resistant TLS 1.3 connection, you will gain the insight you are looking for.
Dependencies for a Basic Quantum-Resistant TLS 1.3 Connection
The figure below illustrates a TLS 1.3 connection from a client web browser to a web server using an X.509 End Entity Certificate, anchored to a publicly trusted PKI. The private key for the X.509 End Entity Certificate is securely stored in a FIPS 140-3 Level 3 HSM. Additionally, the figure shows the name resolution process, where a client DNS query resolves to a DNSSEC-protected authoritative zone.
Note: While this example references specific web browsers, web servers, and cryptographic libraries, it is not intended as an endorsement of these particular elements. These references are included solely to enhance clarity and context. Additionally, we use the fictitious website pqc-secure.com for illustrative purposes.
Furthermore, many aspects of this example have been streamlined for brevity and clarity. We acknowledge that most TLS connections typically pass through CDNs and load balancers, and that the DNS name resolution process has been simplified.
| Item | Element | Type | Organizational Dependency | Status | Description |
|---|---|---|---|---|---|
| 1 | Chromium | Software, Browser | In Progress | The client initiates a TLS 1.3 connection via their Chromium web browser to the fictional website pqc-secure.com. This relies on the Chromium browser’s support for quantum-resistant algorithms. Since Chrome 124, hybrid X25519Kyber768 TLS 1.3 connections have been supported, as detailed in the Chromium Blog: Advancing Our Amazing Bet on Asymmetric Cryptography. This hybrid implementation uses a draft IETF post-quantum key exchange for TLS 1.3, specifically the X25519Kyber768Draft00 hybrid post-quantum key agreement X25519Kyber768Draft00 hybrid post-quantum key agreement. However, to support a purely quantum-resistant ML-KEM (standardized as Kyber under FIPS 203), there is a dependency on the IETF standardizing TLS 1.3 to support ML-KEM without relying on ECDH with the X25519 curve. |
|
| 2 | TLS 1.3 | Protocol | IETF | In Progress | The current version of TLS 1.3 is standardized under IETF’s RFC 8446, which explicitly outlines the acceptable cryptographic algorithms, namely DHE and ECDHE RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3. There is currently a draft RFC, expiring on September 23, 2024, that covers ML-KEM post-quantum key agreement using ML-KEM-768 and ML-KEM-10242. This draft is titled ‘ML-KEM Post-Quantum Key Agreement for TLS 1.3’. ML-KEM Post-Quantum Key Agreement for TLS 1.3 To ensure a fully quantum-resistant key establishment mechanism, there is a dependency on the IETF to provide a Standards Track RFC for TLS 1.3 that incorporates ML-KEM as the encryption algorithm for key establishment. |
| 3 | Apache | Software, Web Server | Apache Software Foundation | In Progress | Web servers like Apache rely on cryptographic libraries to perform the cryptographic operations essential for the TLS 1.3 protocol. Consequently, the ability of Apache and other web servers to support quantum-resistant algorithms depends on their integration with cryptographic libraries that offer such support. For an example of how to integrate Apache with OpenSSL to create hybrid and purely quantum-resistant TLS 1.3 connections, please visit our blog site https://www.appviewx.com/blogs/ as we will soon be releasing a blog on Implementing Hybrid X25519Kyber768 for Quantum-Resistant TLS 1.3 Connections. |
| 4 | OpenSSL/LibOQS | Software, Cryptographic Library | OpenSSL Software Foundation/Open Quantum Safe Project | In Progress | As noted in my earlier blog about Cryptographic Bill of Materials (CBOM) Cryptographic Bill of Materials | CBOM | SBOM | PKI , OpenSSL is commonly used on load balancers, email servers, VPN software, and, in this example, web servers. Cryptographic libraries are essential for supporting quantum-resistant algorithms for key establishment (encryption) and digital signatures. In our example, the dependency is on OpenSSL and the Open Quantum Safe project to support ML-KEM-768 key encapsulation for TLS 1.3. Additionally, cryptographic libraries must be capable of creating and verifying signatures using the ML-DSA algorithm, as illustrated in items 7, 8, and 9 of our diagram. For an example of how to integrate various web servers with cryptographic libraries, please refer to our blog site noted in item 3. We will soon be releasing a blog with the work instructions for implementing and testing hybrid X25519Kyber768 |
| 5 | PKCS#11 | Cryptographic API | OASIS | In Progress | If we choose to secure the private key associated with our X.509 End Entity certificate for pqc-secure.com on an HSM, the cryptographic library must be capable of making PKCS#11 API calls to access the keying material. PKCS#11 is a platform-independent cryptographic API used to manage cryptographic tokens such as HSMs. It handles cryptographic operations including key generation, encryption, decryption, and digital signatures. Managed by the non-profit standards organization OASIS, PKCS#11 is widely supported by HSM suppliers to manage cryptographic keys. Therefore, the dependency on OASIS is to standardize the API to perform quantum-resistant cryptographic operations for algorithms such as ML-KEM and ML-DSA, as outlined in our example. You can view the progress in PKCS#11 and the related KMIP projects for the support of quantum-resistant algorithms on the OASIS website by filtering on the ‘OASIS PKCS 11 TC’ and ‘OASIS Key Management Interoperability Protocol (KMIP) TC’ groups Projects – OASIS. |
| 6 | FIPS 140-3 HSM | Hardware | HSM Vendor NIST | Both – In Progress | If the ML-KEM private key is stored on a FIPS 140-3 HSM, then there is a dependency on the HSM vendor to obtain the appropriate Cryptographic Module Validation from NIST Cryptographic Module Validation Program | CSRC | CSRC . Therefore, there is also a dependency on NIST keep up with the demand for FIPS 140-3 certifications that various hardware and software vendors will be seeking.If the ML-KEM private key is stored on a FIPS 140-3 HSM, there is a dependency on the HSM vendor to obtain the appropriate CMVP (Cryptographic Module Validation Program) certification from NIST Cryptographic Module Validation Program | CSRC | CSRC Additionally, there is a dependency on NIST to keep up with the demand for FIPS 140-3 certifications that various hardware and software vendors will be seeking. You can view the modules in the process backlog for CMVP for FIPS 140-3 submissions here Modules In Process List – Cryptographic Module Validation Program | CSRC | CSRC . Please note that a submission does not necessarily indicate that quantum-resistant algorithms form part of the submission. |
| 7 | X.509 End Entity Certificate | Certificate | IETF CA/B Forum | IETF RFC 5280 – Complete CA/B Forum – In Progress | For a publicly-trusted server certificate for TLS, there are two key dependencies. First, the certificate format is defined by the IETF in RFC 5280 RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile: this standard is not prescriptive in algorithm selection. RFC 5280 states, ‘Implementations of this specification are not required to use any particular cryptographic algorithms.’ This modularity has allowed RFC 5280, established in May 2008, to remain relevant and widely referenced today. Second, there is a dependency on the CA/B Forum to update its Baseline Requirements for TLS Server Certificates to allow the use of ML-DSA as a signature algorithm. Currently, the Baseline Requirements permit only RSA and ECDSA signatures. The latest version of the CA/B Forum Baseline Requirements for TLS Server Certificates can be found here Baseline Requirements for TLS Server Certificates , with Section 7 being particularly relevant. As a side note, NIST approved the use of EdDSA in their FIPS 186-5 Digital Signature Standard in February 2023. However, 19 months later, it is still absent from the Baseline Requirements. This delay might be a deliberate choice by the CA/B Forum, but it underscores the time lag between NIST’s formalization of algorithms and their adoption by the CA/B Forum. |
| 8 | X.509 Issuing CA and Root CA | Certificate(s) | IETF CA/B Forum | IETF RFC 5280 – Complete CA/B Forum – In Progress | Similar to item 7, no further action is required from the IETF regarding RFC 5280 due to its modular nature concerning cryptographic algorithms. However, like item 7, the CA/B Forum Baseline Requirements for TLS Server Certificates will need to permit the use of ML-DSA signatures for both Certificate Authority certificate profiles and the End Entity profile to establish a fully quantum-resistant trust chain. As a side note, while ECDSA is an approved digital signature algorithm for CA and End Entity certificates under the CA/B Forum Baseline Requirements for TLS Server Certificates, not all members have implemented a complete ECDSA trust chain. |
| 9 | DNSSEC | Protocol | IANA IETF | IANA – In Progress IETF for RFC 8624 – Complete | Finally, nearly all TLS 1.3 connections will require DNS name resolution to successfully resolve the FQDN to an IP address. Some organizations have chosen to use the DNSSEC protocol to enable clients (resolvers) to verify the authenticity DNS data associated with an organization’s authoritative domains by using digital signatures. Although DNSSEC adoption has not reached a critical mass, it is nonetheless used by several private and public organizations globally. Where did DNSSEC go wrong? | APNIC Blog DNSSEC Statistics – Internet Society IANA is responsible for signing the root DNS Zone. The Key Signing Ceremonies can be found here Root KSK Ceremonies (iana.org). Currently an RSA-2048 bit key is used to digitally sign the root zone. Therefore, there is another dependency on IANA to adopt a quantum-resistant digital signature such as ML-DSA to ensure the security of the DNSSEC protocol for the Internet. The current IETF RFC for DNSSEC Algorithm Implementation is RFC 8624 RFC 8624: Algorithm Implementation Requirements and Usage Guidance for DNSSEC (rfc-editor.org). Where RFC 5820 (X.509) allows modularity within its selection of cryptographic algorithms, and RFC 8446 (TLS 1.3) is explicit in its use of (EC)DH, RFC 8624 (DNSSEC) is slightly different again. RFC 8624 signposts to IANA to maintain the list of appropriate cryptographic algorithms for use with DNSSEC Domain Name System Security (DNSSEC) Algorithm Numbers (iana.org). Currently ML-DSA does not feature on the list of accepted algorithms. |
| All | Algorithm OIDs | Object Identifiers | NIST | Complete | Now, the final dependency that is required for almost every aspect in our TLS 1.3 connection example is the NIST quantum-resistant algorithm OIDs. NIST maintains a list of OIDs on its CSOR (Computer Security Objects Register) Algorithm Registration – Computer Security Objects Register | CSRC | CSRC. By way of example, instead of human saying ‘I want an ML-DSA-44 signature’, the various systems described in this example will unambiguously refer this signature as a 2.16.840.1.101.3.4.3.17 signature. The IETF protocols and standards can then use the OIDs noted on the CSOR to explicitly use the precise algorithms they intend to use. Currently this dependency is fulfilled as NIST has released the OID’s related to the FIPS 203, FIPS |
Summary
The purpose of this article is to provide context to these dependencies and reassure you that it’s completely understandable if you haven’t fully adopted quantum-resistant algorithms yet. The best thing you can do right now is to understand your estate and ensure it is ready and well-prepared when these dependencies are addressed, see our previous blog for guidance on preparations Quantum Computing and the Risk to Classical Cryptography .
By understanding and addressing these dependencies, we can ensure that our systems are prepared for the quantum era, safeguarding our data against the threat of a CRQC. The journey towards quantum-resistant security is complex and collaborative, but with continued effort and cooperation, we can achieve robust and resilient cryptographic solutions.
AppViewX can help you implement crypto-agility and start preparing today for Post-Quantum Cryptography
Tags
About the Author
Dr. Angelique Faye Loe
Head of Cryptography at major automotive manufacturer
Dr Angelique Faye Loe has a PhD in Mathematics and Cryptography from Royal Holloway University of London. She is a subject matter expert in cryptography and Public Key Infrastructure. For over twenty years she has implemented cryptographic solutions in the private and public sector for major airlines, financial services institutions, and the UK government. She is currently the Head of Cryptography at a major automotive manufacturer and a guest researcher at AppViewX.
