Passwordless authentication with FIDO2—beyond just the web

FIDO2 is a standard for authenticating users without the need for passwords. While the technology has been introduced mainly to protect accounts on web sites, it's also useful for other purposes, such as logging into Linux systems. The same technology can even be used beyond authentication, for example to sign files or Git commits. A couple of talks at FOSDEM 2023 in Brussels presented the possibilities for Linux users.

The FIDO2 standard is a joint effort between the FIDO Alliance (FIDO stands for Fast Identity Online) and the World Wide Web Consortium (W3C) to develop standards for strong authentication. Users can securely authenticate themselves with a FIDO2 security key (a hardware token), which is more convenient, faster, and more secure than traditional password-based authentication. The security key can ask the user to touch a button or enter a PIN for authentication; alternatively, it can include a fingerprint reader or other means for biometric authentication. FIDO2 can be used as an extra factor added to a traditional password as part of multi-factor authentication or as the only means of authentication. In the latter case, this is called passwordless authentication. Note that a previous FIDO standard, FIDO U2F, was primarily designed for two-factor authentication.

The FIDO2 standard consists of two parts. Web Authentication (WebAuthn) is a W3C recommendation with broad browser support that describes an API allowing web sites to add FIDO2 authentication to their login pages. FIDO's Client to Authenticator Protocol (CTAP) complements WebAuthn by enabling an external authenticator, such as a security key or a mobile phone, to work with the browser. So in short: the browser talks WebAuthn to the server and CTAP to the authenticator device.

Both standards are open, and anyone can manufacture FIDO2 security keys. Various manufacturers have built such hardware tokens. Yubico has some YubiKey models that support FIDO2, as well as a dedicated FIDO2 security key. Feitian, Nitrokey, SoloKeys, and OnlyKey offer FIDO2 tokens too.

How FIDO2 works

FIDO2 is a challenge-response authentication system using asymmetric encryption. When a user registers with a web site, WebAuthn and CTAP work together to make the authenticator (usually a security key) create a new key pair. This is only done after the user proves possession of the authenticator, for example by pressing a button on the device, scanning a finger, or entering a PIN. The private key never leaves the device, while the public key is sent to the web site and associated with the user's account there.

When logging into the web site, the site sends a challenge and its origin (such as its domain) to the web browser using the WebAuthn API. The web browser then sends the challenge to the authenticator using CTAP. The user again proves possession of the authenticator and the device generates a response by signing the challenge with its private key. The response is returned to the web browser (using CTAP) and then to the web site (using WebAuthn). The web site verifies the response against the original challenge using the public key that was used to register the account.

The FIDO2 token can store multiple credentials, each of which consists of a credential ID, the private key, the user ID, and a relying party ID corresponding to the web site's domain. The web site stores the same user ID and credential ID, as well as the public key. The way FIDO2 works protects users against phishing. The web browser only accepts WebAuthn calls using a relying party ID allowed from the web site's domain, and only HTTPS connections are allowed. So when the authenticator signs the challenge, the browser already knows that it's talking to the right web site, because it has verified this using the web site's TLS certificate. As a result, the user doesn't have to check the domain manually.

Using FIDO2 beyond the web

Most of the documentation about FIDO2 is about its use in web sites as if that's the only possible use. An example is the unofficial but helpful WebAuthn Guide made by Duo Security. However, the specifications can be used beyond the web. That was the topic of a talk by Joost van Dijk, a developer advocate at Yubico.

Yubico developed libfido2, a C library and corresponding command-line tools to communicate with a FIDO device (not only the ones made by Yubico) over USB or NFC. It supports the FIDO U2F and FIDO2 protocols. The project is licensed under the BSD 2-clause license and supports Linux, macOS, Windows, OpenBSD, and FreeBSD. Some external projects have built upon libfido2 to create bindings for .NET, Go, Perl, and Rust. Yubico also maintains a Python library, python-fido2, that is tested on Linux, macOS, and Windows.

One of the projects using libfido2 is pam-u2f, also developed by Yubico and included in the repositories of many Linux distributions. It integrates FIDO2 security keys into Pluggable Authentication Modules (PAM), which is the flexible and extensible authentication framework for Linux systems that allows multiple authentication methods to be used. Requiring a credential on a FIDO2 device for a specific purpose is as easy as registering a new credential, saving it in a configuration file, and then adding a reference to pam_u2f.so in the PAM configuration, referring to the file with the saved credential. As an example, Van Dijk showed how to enable two-factor authentication for sudo with a FIDO2 token as the second factor. The pam-u2f documentation shows some other examples.

New types of SSH keys

Another use case Van Dijk described is an SSH key that is backed by a FIDO2 authenticator. OpenSSH 8.2 (released in February 2020) introduced support for FIDO2 security keys, using the libfido2 library under the hood. The challenge-response mechanism works not unlike on the web, but this time the authenticator talks to the ssh client using CTAP, and the ssh client talks to the sshd server using the normal SSH protocol.

To make this work, OpenSSH introduced new public key types "ecdsa-sk" and "ed25519-sk", along with corresponding certificate types. If the user generates a new SSH key pair of one of those types with ssh-keygen, the private key is generated and stored inside the hardware token, together with the relying party ID "ssh:" and optionally a key handle. The authenticator returns the public key and the key handle to ssh-keygen. The program saves the public key in a file as usual, while the file that normally stores the private key now includes the key handle.

Authenticating with this type of key to the SSH server involves a challenge-response mechanism. The SSH server sends a challenge to the client, which sends it to the FIDO2 authenticator. The latter signs the server's challenge with the private key to create a digital signature that is sent to the client and then to the server. The SSH server is able to verify this signature by the corresponding public key known to be associated to the FIDO2 authenticator. The private key never leaves the authenticator during this process, even the ssh client doesn't get access to it. A hardware-backed SSH key may be used like any other key type supported by OpenSSH, as long as the hardware token is attached when the key is used.

Van Dijk showed some examples of what's possible with a hardware-backed SSH key: authenticating to GitHub when cloning a Git repository over SSH, signing Git commits and tags and verifying their signatures, and signing and verifying files.

Unlocking LUKS2 volumes with a hardware token

CTAP also offers the hmac-secret extension, which is supported by most FIDO2 tokens. This is used to retrieve a secret from the authenticator in order to encrypt or decrypt data. To prevent offline attacks, part of the secret (the salt) is held by the client, while the other part is stored on the authenticator. The client hands its salt to the authenticator, the device combines the salt with its own part of the secret using the HMAC-SHA-256 hash-based message authentication (HMAC), and returns the resulting key. Van Dijk showed how to use this key to encrypt data, after which it's safe to delete the key. To decrypt the data later, the client hands the salt back to the authenticator, which regenerates the key from the salt and its own secret.

One application of this hmac-secret extension that Van Dijk demonstrated is in Linux Unified Key Setup (LUKS) disk encryption. Systemd 248 introduced support for unlocking LUKS2 volumes with a FIDO2 security key. After enrolling a FIDO2 authenticator to a LUKS2 encrypted volume, the systemd-cryptsetup component waits for the FIDO2 token to be plugged in at boot, hands it the salt, gets back the key, and unlocks the volume with the key.

FIDO2 security keys instead of smart cards

With all this functionality of FIDO2 security keys, one has to wonder why traditional smart cards or hardware keys implementing OpenPGP aren't enough. These have been used for a long time to store private keys offline for encryption, authentication, signing, and verification. Van Dijk considers that the biggest advantage of FIDO2 security keys is that they are cheaper and more user-friendly.

Open-source support is also improving a lot in many domains. For example, at FOSDEM Red Hat's Alexander Bokovoy gave two talks about his work on integrating FIDO2 in FreeIPA for passwordless authentication for centrally managed users. Under the hood, this also uses the libfido2 library. His colleague Iker Pedrosa has some instructions on his blog.

With Microsoft, Apple, and Google jumping on the FIDO2 bandwagon during the last few years, surely more and more affordable FIDO2 devices will come to market. With software support improving as well, it won't be long before users start replacing their passwords with cheap FIDO2 security keys.

Did you like this article? Please accept our trial subscription offer to be able to see more content like it and to participate in the discussion.

(Log in to post comments)