NSS and Firefox Transition to PQC

Introduction

Previously in our series of blog posts on the post-quantum cryptography (PQC) transition of internet browsing, we introduced the QUBIP approach for the transition of OpenSSL for implementing PQ/T TLS. In that post, we focused heavily on the transition of server-side applications. This post will shift the focus to the client side, specifically to the PQC transition of Mozilla Firefox.

Quantum computing promises to revolutionize many fields, but it also poses significant risks to current cryptographic systems. As these powerful machines become more advanced, the encryption and authentication methods that secure our internet communications could become vulnerable. To counter these risks, it’s crucial to transition to quantum-secure cryptographic algorithms. This blog post explores how we are transitioning Mozilla Firefox, particularly its Network Security Services (NSS) cryptography library, to support a quantum-secure internet.

Mozilla Firefox

Mozilla Firefox is an open-source internet browser developed by the Mozilla Foundation. Firefox was created to be a faster and more private alternative to other browsers such as Internet Explorer and, more recently, Chrome. Due to its open-source nature, Firefox is also the perfect candidate for our efforts to transition to quantum-secure internet browsing. The availability of its code, extensive documentation, and a healthy, active community around Firefox make it an approachable browser to work with. Firefox incorporates various programming languages such as C/C++, Rust, Javascript and Python.

In the diagram above, you can see the main functionality provided by each language. Our focus is on the transport layer security (TLS) portion of Mozilla Firefox, so our work mainly considers the C/C++ and Rust portions of the Firefox tech stacks. Our contributions are made using Rust, in accordance with Mozilla Foundation’s project Oxidation. The goal of this project is to integrate Rust code in and around Firefox, enhancing its security and performance.

Network Security Services (NSS)

NSS is a collection of libraries integrated into the Mozilla Firefox codebase, providing essential cryptographic functionalities and enabling secure browsing through the implementation of Transport Layer Security (TLS). Rather than being a single library, NSS comprises multiple libraries designed to facilitate the development of security-enabled client and server applications. Key components include libnss and libnspr (Netscape Portable Runtime). Applications built with NSS can support a variety of security standards, including TLS, PKCS #5, PKCS #7, PKCS #11, PKCS #12, S/MIME, and X.509 v3 certificates, among others. Interestingly, NSS predates Mozilla Firefox, as it was derived from the SSL-related libraries developed by Netscape and later adopted by Mozilla. Notable examples of applications utilizing NSS include Mozilla Firefox and Mozilla Thunderbird.

PKCS #11

In the previous section, we mentioned that NSS supports a variety of security standards. Among these, the PKCS #11 is particularly crucial to our approach.

PKCS #11, or the Public Key Cryptography Standard #11, is maintained by the non-profit standard organization OASIS. It defines an application programming interface (API) called Cryptoki, which is designed for devices that store cryptographic information and execute cryptographic functions. Cryptoki was designed with portable cryptographic devices, such as smart cards and other cryptographic hardware devices, in mind. The goal of Cryptoki is to make each cryptographic device appear logically similar to any other device.

This allows applications using the cryptographic device to interact solely with the Cryptoki API, without needing to concern themselves with the device’s specific low-level cryptographic implementations.

In a nutshell, Cryptoki provides an interface to one or more devices active in the system through a number of slots. A slot corresponds to a device interface that may contain a token. In the context of PKCS #11, a token is a device that stores objects, such as data, certificates, and cryptographic keys, and can perform cryptographic functions. Cryptoki allows the application to establish a connection between the application and the token, called a session. A token is usually able to create and destroy objects, manipulate objects, search for objects, and perform cryptographic functions with objects. Tokens are not all alike and can be specialized to perform different kinds of operations.

Even though we refer to cryptographic devices, which might suggest they are physical devices (and they can be), the abstraction layer that Cryptoki adds allows the “device” to be implemented entirely in software. In the context of PKCS #11, a cryptographic device implemented in software is usually called a software token.

Methodology

Overview

To introduce PQC to Mozilla Firefox, we are using a shallow module approach. The module is shallow in the sense that, instead of containing algorithm implementations directly, it serves as an intermediate layer that allows NSS to utilize standalone third-party implementations. We adopted this approach due to the rapid evolution of the PQC algorithm landscape, enabling us to provide an easy-to-use testing area for algorithm developers, almost like a plugin.

You might recognize this approach from our previous blog post, transition of OpenSSL for implementing PQ/T TLS, where we focused on server-side applications. In a way, these approaches are slightly distorted mirror images of each other. On the server side, the focus was on OpenSSL and the Provider API, whereas for Mozilla Firefox, we are focusing on NSS and the Cryptoki API.

We acknowledge that the latest builds of Mozilla Firefox (Firefox 124+) include experimental support for X25519Kyber768Draft00. The QUBIP methodology seeks to offer users and developers an extra degree of freedom by enabling them to choose their preferred backend implementation. Moreover, QUBIP targets both encryption and authentication, aiming to enhance overall security capabilities.

Architecture

In our approach, Mozilla Firefox utilizes the Network Security Services (NSS) to handle cryptographic functionalities. When Firefox requires PQ/T Hybrid TLS 1.3 functionality, it interacts with NSS. Through its support for PKCS #11, NSS can interface with various cryptographic devices and modules.

Related to the diagram above, here’s how the process works step-by-step:

1. Application Request: Mozilla Firefox, needing cryptographic services, makes a request to NSS for PQ/T Hybrid TLS 1.3 functionality.
2. NSS Handling: NSS receives this request and uses its PKCS #11 support to manage cryptographic operations.
3. Intermediate Layer (QUBIP-NSS-Module): Instead of implementing PQC algorithms directly, NSS interacts with the QUBIP-NSS-Module. This module is the PKCS #11 _software token* we are using in our approach.
4. External PQC Implementation: The QUBIP-NSS-Module connects to external PQC software implementations. This setup allows for flexibility and rapid updates, as new PQC algorithms can be integrated without altering the core NSS.
5. Performing Cryptographic Functions: The external PQC software performs the necessary cryptographic functions and returns the results via the QUBIP-NSS-Module.
6. Forwarding to Target: NSS, now equipped with the PQ/T Hybrid TLS 1.3 results, forwards the data to the peer (e.g., a server), completing the secure communication process.

This shallow module approach ensures that NSS can quickly adapt to advancements in PQC algorithms by leveraging third-party implementations through the PKCS #11 interface. It simplifies testing and integration for developers, promoting a modular, flexible and agile cryptographic ecosystem.

QUBIP-NSS-Module

The QUBIP-NSS-Module can be divided in to three distinct sections:

1. Cryptoki API
2. Software Interoperability Layer
3. External PQC Software Implementation

The Cryptoki API implementation in our module is based on the work of Simo Sorce, Jakub Jelen, and Sergio Arroutbi in their GitHub repository kryoptic, where they implemented a PKCS #11 software token in Rust utilizing the functionality of OpenSSL. We modified the codebase to retain only the Cryptoki API implementation, allowing us to build on top of it.

The software interoperability layer acts as the glue that allows the module’s Cryptoki API implementation to communicate with the external PQC software implementation. At the time of writing, we are preparing our proof-of-concept implementation, which will use a PQC implementation hardcoded into the module. In the future, we plan to use Rust macros to add scaffolding, providing greater flexibility when accessing external PQC software implementations.

Conclusion

The era of quantum computing is nigh, and we must be prepared. At QUBIP, we are collaborating with various initiatives to integrate PQC into our digital infrastructure. In this blog post, we introduced our method of equipping the Mozilla Firefox browser and NSS with our shallow QUBIP-NSS-Module. This module can connect to various external PQC software implementations in a cryptographically agile manner. By doing so, we aim to provide a framework that other developers can use to test their algorithms in real browsing sessions.