A look at the recently released YubiKey 5 hardware authenticator series and how web authentication with the new WebAuthn API leverages devices like the YubiKey for painless website registration and strong user authentication.

I covered the YubiKey 4 in the May 2016 issue of Linux Journal, and the magazine has published a number of other articles on both YubiKeys and other forms of multi-factor authentication since then. Yubico recently has introduced the YubiKey 5 line of products. In addition to the YubiKey's long-time support of multiple security protocols, the most interesting feature is the product's new support for FIDO2 and WebAuthn.

WebAuthn is an application programming interface (API) for web authentication. It uses cryptographic "authenticators", such as a YubiKey 5 hardware token to authenticate users, in addition to (or even instead of) a typical user name/password combination. WebAuthn is currently a World Wide Web Consortium (W3C) candidate recommendation, and it's already implemented by major browsers like Chrome and Firefox.

This article provides an overview of the YubiKey 5 series, and then goes into detail about how the WebAuthn API works. I also look at how hardware tokens, such as the YubiKey 5 series, hide the complexity of WebAuthn from users. My goal is to demonstrate how easy it is to use a YubiKey to register and authenticate with a website without having to worry about the underlying WebAuthn API.

About the YubiKey 5 Series

The YubiKey 5 series supports a broad range of two-factor and multi-factor authentication protocols, including:

• Challenge-response (HMAC-SHA1 and Yubico OTP).
• Client to Authenticator Protocol (CTAP).
• FIDO Universal 2nd-Factor authentication (U2F).
• FIDO2.
• Open Authorization, HMAC-Based One-Time Password (OATH-HOTP).
• Open Authorization, Time-Based One-Time Password (OATH-TOTP).
• OpenPGP.
• Personal Identity Verification (PIV).
• Web Authentication (WebAuthn).
• Yubico One-Time Password (OTP).

In addition, the entire YubiKey 5 series (with the exception of the U2F/FIDO2-only Security Key model) now supports OpenPGP public key cryptography with RSA key sizes up to 4096 bits. This is a notable bump from the key sizes supported by some earlier models. Yubico's OpenPGP support also includes an additional slot for an OpenPGP authentication key for use within an SSH-compatible agent, such as GnuPG's gpg-agent.

Figure 1. YubiKey 5 Series

You can create OpenPGP keys on your computer and then move them into the YubiKey, or you can create them directly on the key itself for extra security. On-key generation of crypto keys ensures that secret keys never are exposed to a host computer. This provides the ability to sign and decrypt data in relative safety, even when attached to systems that shouldn't be trusted with secret key material.

The YubiKey 5 series is also notable for its broad array of form factors, including USB-A, USB-C and low-profile "nano" devices that can be left in a port indefinitely. A number of form factors also support Near-Field Communication (NFC) for use with tablets and mobile phones.

Figure 2. YubiKey 5 with NFC

The YubiKey 5 series also includes a low-cost model (aptly named the "Security Key") in a USB-A form factor. The Security Key provides only U2F and FIDO2 authentication. This model is currently less than half the cost of its more capable brethren in the series. If you don't need the other features or form factors and just want to make use of WebAuthn web authentication, this model is a great place to start.

Figure 3. Security Key by Yubico

What's WebAuthn All About?

Two-factor authentication (2FA) is something everyone likely is becoming increasingly familiar with. In security, authentication requires one or more of the following:

1. Something you know, like a password.
2. Something you have, like a cryptographic token or officially issued ID card.
3. Something you are, like a person with a specific fingerprint or retinal pattern.

The user name and password combination is the "something you know" type of authentication. Many websites and services now provide users with better security through a second factor. This is typically a one-time password service via Short Message Service (SMS), single-use Time-Based One-Time Password (TOTP) tokens through Google Authenticator or similar applications, push-based TOTP tokens from Duo or LastPass integration, or U2F challenge/response authentication.

U2F is most notably used by Google services, and until quite recently, it has been limited to users with a recent Chrome browser. From a security perspective, U2F and other 2FA techniques are useful tools for increasing web application security. However, there's a growing need for a more seamless user experience, and an ever-increasing need for more robust authentication protocols. As part of an evolving W3C draft standard, WebAuthn provides a better user experience (and arguably a stronger approach to identification and authorization) when using compliant authenticators, such as the YubiKey token.

WebAuthn is designed to be backward-compatible with devices built for the earlier FIDO U2F standard. This includes hardware tokens such as the YubiKey 4, Google's Titan key and various U2F-only devices. However, unlike the YubiKey 5 series, many U2F devices are limited to providing only a hardware-based second factor and aren't designed for the full suite of multi-factor capabilities provided for by WebAuthn.

As an API, WebAuthn is fundamentally a set of protocols that interacts with CTAP-enabled devices like the YubiKey 5 to provide a comprehensive suite of authentication services that rely on public key cryptography. Depending on the capabilities of both the server and the user's device, WebAuthn supports the following:

• Single-factor authentication: passwordless logins, where the presence of the hardware token is sufficient. This is somewhat similar to passwordless SSH keys, only much more secure. A physical YubiKey token won't expose secret key material to the local or remote host systems even when plugged in, and it can't be used at all when physically removed.
• Two-factor authentication (2FA): this is typically a user name and password combination (something you know), followed by detection of the hardware token (something you have). This type of 2FA is generally considered more secure than second-factor authentication systems, such as SMS, TOTP or HOTP generators, because of the requirement for a physical token.
• Multi-factor authentication (MFA): true MFA often involves a PIN or biometric signature that isn't transmitted over the network. This third factor is typically used locally to unlock the functionality of the hardware token, and it adds another "something you know" or "something you are" layer for successful authentication.

Google Authenticator and Alternatives

Although proprietary systems, such as RSA's SecurID solutions, have been around a long time, the past decade has seen the rise of many alternatives for second-factor authentication. Today's users are likely familiar with SMS solutions that send a six-digit code to their cell phone, but other types of client-side software and hardware tokens have been increasingly on the rise since 2003.

Google Authenticator, initially released in 2010, is arguably the most well known software token solution for typical web users. Google Authenticator leverages a number of open (if not necessarily open-source) protocols, including the widely used QR barcode symbology. Scanning the QR code imports a software token into the user's smartphone, populating a client-side code generator on the device.

Common alternatives to Google Authenticator include:

• FreeOTP (notable for being open-sourced by Red Hat and available under an Apache 2.0 license on GitHub).
• Authy (notable for providing multi-device capabilities).
• LastPass Authenticator.
• Microsoft Authenticator.
• Duo Mobile.

There are certainly many, many others, each with its own set of pros, cons and specialized use cases. This relatively small handful represents the bulk of mind-share among typical users, but you can definitely consider additional alternatives based on issues of cost, open standards support and security track record.

WebAuthn, Overly Simplified

The current working draft of the WebAuthn specification is more than 100 pages long, so describing it in simple terms runs the risk of over-simplification. With that in mind, this section is not a comprehensive guide to the entire WebAuthn API. It's intended to be a useful abstraction that highlights how WebAuthn works behind the scenes, highlighting the value of the YubiKey in simplifying the web registration and authentication process.

The heart of WebAuthn is the challenge/response that takes place between a "relying party server" (aka the remote service, such as a website) and a token in the user's possession. The server issues a challenge that is ultimately received by your browser, which then interacts with the YubiKey or another U2F- or FIDO2-compliant token. This token is called the "authenticator".

With a hardware token like the YubiKey, the authenticator can create a signed response to the server's challenge without ever exposing the secret key portion of the credentials stored within the token. The server then validates the response from the authenticator to complete the registration or authentication process.

Even with software tokens, as opposed to hardware tokens like the YubiKey, the API is designed to limit the amount of data exposed to the server during token registration or authentication. Although hardware tokens are considered more secure, the WebAuthn API allows for other types of authenticators as well.

With WebAuthn, the user experience involves just a few simple steps:

1. Receive an authentication prompt from your browser.
2. Use your YubiKey to provide a response.
3. Wait a few milliseconds for the WebAuthn framework to validate your YubiKey's response.
4. Do fun stuff as an authenticated user!

Under the hood though, WebAuthn and the YubiKey are doing a lot more work. Let's take a closer look.

The Not-So-Simple WebAuthn API

Although the user experience is straightforward, the implementation details are anything but. The WebAuthn API covers two closely related key-management activities for handling registration and authentication, and it calls these activities "ceremonies".

Both ceremonies require a Relying-Party Server, a Relying-Party JavaScript Application, a supported web browser and an Authenticator with certain properties.

Currently, supported web browsers include:

• Mozilla Firefox 60+.
• Google Chrome 67+.
• Google Chrome for Android Beta 70+.

Support by Microsoft Edge was introduced into development builds in July 2018. Meanwhile, Apple is a participant in the WebAuthn working group, but there is no indication of if (or when) the Safari browser will support the WebAuthn API.

Authenticator properties include key management capabilities and the ability to generate cryptographic signatures. FIDO2 authenticators must also be able to map credentials to each 64-byte user handle associated with a given Relying Party, although the underlying implementation details may vary. Since the YubiKey 5 documentation states that it supports "unlimited" credentials, I assume that the mapping is derived from input during the WebAuthn ceremonies, rather than using fixed storage space within the YubiKey token.

Protocol and implementation details related to how the Authenticator Attestation Globally Unique Identifier (AAGUID) is tied to individual tokens without creating privacy concerns, and how attestation of authenticator provenance is handled by X.509 certificates, are certainly important for the security of the WebAuthn system. But while these concerns are addressed within the specification, the average user doesn't actually need that level of technical detail to use a YubiKey 5 device safely. The elegance of the WebAuthn/YubiKey solution is that the API handles those details for you.

Registration Using the WebAuthn API

Before you can use a YubiKey to authenticate to a web service, a U2F- or FIDO2-capable device must register with the relying party server through a registration ceremony. There are some potential use cases where registration is optional or when first-time registration is combined with authentication for new enrollments. However, a typical website likely will want to associate a given credential with a user handle, which is a 64-byte identifier for a user account.

At the time of this writing, the registration ceremony defined by the API follows seven steps (Figure 4):

1. Registration request: the server-side application initiates a registration request. How this is done is not specified by the WebAuthn API. This is currently an application-specific implementation detail.
2. Server passes input to client-side JavaScript: the server sends a challenge, along with user information and relying-party data, to a JavaScript application running in the client's browser.
3. Browser requests credential from authenticator: the user's browser provides sufficient information to an authenticator so the device can generate a unique credential. The YubiKey 5 includes the server-generated user handle when generating a new credential, while older YubiKeys or other U2F-only devices will create a credential with userHandle set to null for backward-compatibility.
4. Authenticator creates an attestation: the YubiKey creates a cryptographic key pair for the credential and bundles the public key inside a special message called an "attestation statement".
5. Authenticator sends attestation object to browser: the YubiKey signs the attestation statement with a verifiable digital signature and passes the statement along with other data back to the browser as an "attestationObject".
6. Credential passed to relying party: the JavaScript application packs up the attestationObject, along with some JSON and encoded data, and sends it back to the relying party Server as an "AuthenticatorAttestationResponse".
7. Server validates response: the server then validates the response and the credential's digital signature. If all the validations succeed, the server completes the registration process by associating the public key in the attestation with the user's account. This public key can then be used for immediate or future authentication.

Figure 4. WebAuthn Registration Flow ("Web Authentication: An API for accessing Public Key Credentials Level 1." W3C Candidate Recommendation, 7 August 2018. https://www.w3.org/TR/webauthn/#web-authentication-api)

To be quite frank, even this "deep dive" into the registration process glosses over a great deal of cryptography and message-passing. However, the beauty of WebAuthn, especially when paired with a YubiKey, is that all of this cryptographic work and interprocess communication is essentially invisible to end users. In actual use, basic registration simply involves inserting a YubiKey in response to a browser prompt and tapping the touch-sensitive part of the YubiKey (which varies by model) to activate it.

Once the authenticator is registered, you're only halfway done. You've registered a WebAuthn credential using a YubiKey, but you still have to present the newly registered credentials to the website before you're actually authorized. In practice, websites can present registration and authentication as a seemingly unified process from the user's point of view, but they're actually different ceremonies within the WebAuthn API.

Authentication with the WebAuthn API

The process for authentication is actually quite similar in its outlines to the registration process. Although protocols and messages may vary, the key difference is that the relying party server and the authenticator are validating an existing credential that was created during the registration process described above.

Figure 5. WebAuthn Authentication Flow ("Web Authentication: An API for accessing Public Key Credentials Level 1." W3C Candidate Recommendation, 7 August 2018. https://www.w3.org/TR/webauthn/#web-authentication-api)

As with registration, the user perspective is simply to insert the YubiKey and trigger it with a touch. What could be easier?

Passwordless Login Example

If you have a YubiKey device that supports U2F or FIDO2, you can test out registration and authentication using a number of publicly available testing services. For this set of examples, let's use the site provided by Duo Security for YubiKey testing.

Launch your browser, and navigate to https://webauthn.io. Next, register your YubiKey by entering a unique user name. As many other users are likely testing their keys too, I recommend using a UUID for your user name. Running the uuidgen command, available on most Linux and macOS systems, will print a value that is sufficiently random for this purpose.

For this exercise, leave the other values, such as Attestation Type and Authenticator Type, at their defaults.

Figure 6. Register Credential

After you've entered your user name, click Register a User/Credential. You'll then be prompted to tap your YubiKey to complete the registration process.

Figure 7. Tap YubiKey

Note that this particular application shows two different dialog boxes. Other WebAuthn sites show only the top modal dialog; the second (and admittedly prettier) dialog seems to be unique to the Duo website.

In any case, once you've tapped your YubiKey, you'll be registered and logged in immediately. You'll see a screen similar to the one shown in Figure 8.

Figure 8. Registered and Logged In

If you return to the home page, you'll again see the login screen. To test that your YubiKey is working properly, enter your user name and then click Login with Credential. No password required!

Although this example seems trivial, it highlights how easy it is for a user to register or authenticate with a YubiKey. Even though the underlying implementation is complex, the user experience is smooth and simple.

Privacy Considerations

When properly implemented, WebAuthn and compliant tokens like the YubiKey robustly guard user privacy while providing strong user authentication features. Sections of the standard address ways to prevent data correlation, de-anonymization and the use of credentials without user consent.

A full examination of WebAuthn privacy issues is outside the scope of this article, but section 14 of the standard is titled "Privacy Considerations". If you're an IT auditor, security administrator, security engineer or application programmer, section 14 will be useful to you.

Cryptographic Weaknesses

In late August 2018, security researchers from Paragon Initiative Enterprises raised concerns about the WebAuthn API's use of certain algorithms, specifically Elliptic Curve Direct Anonymous Attestation (ECDAA) and RSA with PKCS1v1.5 padding. ZDNet picked up the story and added some additional clarification.

The short version for non-cryptographers is that certain algorithms in the standard represent potential weaknesses. These weaknesses are not currently easy to exploit in practice, but they may present problems for the future. The researchers' cautions are aimed more at API implementers than users, with the goal of improving the WebAuthn standards before they're finalized. The researchers themselves say:

WebAuthn and ECDAA are not doomed. Don't throw away your hardware tokens, revert your codebases to use SMS or TOTP, or any other such drastic measures.

Resources

• "Web Authentication: An API for accessing Public Key Credentials Level 1." W3C Candidate Recommendation, 7 August 2018
• FIDO 2.0: Client To Authenticator Protocol
• FreeOTP Two-Factor Authentication
• Server-side Web Authentication library for Java
• WebAuthn Rails Demo App
• Ruby implementation of a WebAuthn Relying Party
• WebAuthn/FIDO2 JavaScript application
• Mozilla Web Authentication API
• "Introducing Web Authentication in Microsoft Edge"
• "Security Concerns Surrounding WebAuthn: Don't Implement ECDAA (Yet)"
• "Worries arise about security of new WebAuthn protocol" (ZDNet)
• FIDO ECDAA Algorithm
• WebAuthn Privacy Considerations