At SandboxAQ, our mission is to modernize cryptography management. That means gaining visibility into the cryptographic assets used across IT infrastructure and the agility to manage them at scale. The road to cryptographic agility is complex, as it requires ensuring the agility of many layers in the stack — check, if you don’t know it yet, our OSS Sandwich library. Furthermore, agility should not be limited to software, as cryptography often also relies on hardware, which is inherently less agile.

One key example (pun intended) is the FIDO2 protocol — a protocol for securely authenticating in web applications without passwords but with hardware tokens containing cryptographic credentials that cannot be easily replaced by more modern tokens. The purpose of the FIDO2 protocol is to reduce the burden and risk for regular users of finding a password that is strong enough, remembering it (no post-its please!), and updating it regularly. You might have come across the FIDO protocol as an addition to passwords as a second- or multi-factor authentication mechanism, or in your browser or your phone in the form of passkeys.

As we are committed to bring agility to software, firmware updates of hardware, and hardware replacement in case firmware is not updatable, we are working towards the long-term task of maintaining the security of the FIDO2 protocol even when facing quantum attacks. As a first step in our journey with FIDO2, we have checked whether current specifications are compatible with the incoming migration to post-quantum cryptography, as detailed in a previous previous blog post based on a paper published at IEEE S&P last year. As a next step, we have taken on a proof-of-concept post-quantum secure implementation of the FIDO2 protocol.

This post introduces the first end-to-end post-quantum secure implementation of the FIDO2 protocol, which we have recently open-sourced. The aim of this open-source project is to provide a complete implementation that allows post-quantum secure end-to-end registration and authentication in all steps of the protocol and all involved parties, to give developers a starting point to experiment and test the viability of post-quantum cryptography in current hardware devices providing FIDO2 authentication.

This project was carried out in collaboration with Tarun Kumar Yadev during his PhD residency at SandboxAQ, and with the help of Nitrokey and SoloKeys, two major actors in the trusted hardware space who collaborate in their FIDO2 implementation through the Trussed framework.

FIDO2 in a Nutshell

In order to provide secure authentication, the FIDO2 protocol runs cryptographic primitives in secure devices (such as smartphones or dedicated USB or NFC hardware tokens). In the context of a future migration to post-quantum cryptography, it is important to assess whether the FIDO2 protocol is ready to adopt the needed quantum-secure algorithms or to at least identify the gaps.

At a high level, the FIDO2 protocol is run between a user and a web service where they want to authenticate (let’s say, to order ingredients for their dog’s birthday cake from an online pet store). Other parties in the protocol are the browser used to access the (pet store) website, and the token/authenticator, which is special hardware the user connects to their computer or smartphone (in some cases it is their smartphone) that contains cryptographic credentials used to log in.

The FIDO2 protocol is divided into two sub-protocols, also depicted in the figure below:

1. ‘WebAuthn’, which is the sub-protocol run between the user, authenticator, browser and web service in order to let the user authenticate into the web service with the hardware token (instead of or in addition to a password).

2. ‘CTAP’ (Client To Authenticator Protocol) is the sub-protocol run between the hardware token and the browser to make sure only a browser trusted by the user can communicate directly with the token.

While the current instantiations of the cryptographic building blocks used by the WebAuthn and CTAP sub-protocols are believed to be secure now, the asymmetric schemes in use (i.e., RSA, ECDSA and ECDH) won’t be as soon as large fault-tolerant quantum computers can be built. Luckily, research, industry and standardization bodies are already on the task. In particular, the National Institute for Standards and Technology (NIST) recently published standardization drafts for a post-quantum secure key encapsulation mechanism that can be used as a replacement for ECDH in the FIDO2 protocol and post-quantum secure digital signature schemes that can substitute for RSA and ECDSA. Visit our earlier blog posts for more information about the quantum threat and actions to maintain security in the quantum era and for technical details on the FIDO2 protocol.

End-to-End Open-Source Quantum-Secure FIDO2

Our main repository of an end-to-end post-quantum secure FIDO2 implementation can be found here.

Our FIDO2 implementation is post-quantum secure as it replaces or adjusts all the cryptographic primitives in use (like digital signature schemes and key encapsulation mechanisms) to be quantum secure. More concretely, this means that the quantum-secure signature scheme CRYSTALS-Dilithium3 and the key encapsulation mechanism CRYSTALS-Kyber768 (being standardized as ML-DSA and ML-KEM respectively) are used in WebAuthn and CTAP, respectively.

Our implementation is end-to-end post-quantum secure as our implementation ensures that the entire protocol flow between web service, web browser and hardware token is post-quantum secure. This is one step further to existing implementations that provide post-quantum security of the implementation used by the hardware token but not the browser or web service, enabling testing of the algorithms on the hardware token but not of the entire protocol flow.

We use and extend several open-source third-party libraries for the development of our PQ FIDO2 implementation, as visualized in the figure below. Namely, we extend the code base from the fido-authenticator open-source module (which powers SoloKeys and Nitrokey’s FIDO2 implementation and relies on the Trussed framework) for the parts of the protocol running on the hardware token, with the pqclean library providing the post-quantum cryptographic algorithms. Furthermore, we use Yubico’s example for a FIDO2-compatible server, using liboqs for the implementation of CRYSTALS-Dilithium. Lastly, we use Mozilla’s open-source implementation to upgrade the CTAP protocol to use post-quantum key encapsulation. As part of our contributions to the open-source and the FIDO communities, the part of the FIDO2 protocol that runs on the token will be integrated back into the Trussed framework, so that it can be used experimentally by Nitrokey and SoloKeys.

To check the feasibility of running the post-quantum FIDO2 protocol in current hardware, we have tested our implementation on the LPCXpresso55S69 development board. Our preliminary results show that it is indeed technically feasible to use current hardware to run an end-to-end post-quantum version of FIDO2. The next step is to run benchmarks to make sure timings are compatible with a good user experience — stay tuned for new results in this area!

Further Research and Future Plan

At SandboxAQ our research on FIDO2 is not limited to the base protocol. We have recently published a research paper on the security and privacy provided by the different attestation modes supported by the specification and we proposed a new attestation mode, which maximizes such properties while being compatible with post-quantum cryptographic primitives.

As future work we would like to extend our implementation to also allow for different post-quantum secure attestation modes. Furthermore, a useful extension would be to not only support CRYSTALS-Dilithium and CRYSTALS-Kyber but also combinations of different key encapsulation mechanisms and signature schemes (e.g., ECDSA-Dilithium hybrid signature scheme).