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.
Figure 1. YubiKey 5 Series from Yubico
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.
The YubiKey 5 series supports a broad range of two-factor and multi-factor authentication protocols, including:
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.
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
Two-factor authentication (2FA) is something everyone likely is becoming increasingly familiar with. In security, authentication requires one or more of the following:
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:
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:
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.
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:
Under the hood though, WebAuthn and the YubiKey are doing a lot more work. Let's take a closer look.
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:
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):
userHandle set to null for backward-compatibility.
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?
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.
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.
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.
Todd A. Jacobs is the CEO of Flow Capital Group, which acquires and manages companies specializing in IT automation, DevOps & agile transformations, security and compliance, fractional CIO/CTO services, and board advisory services for cyber risk and other hot technology issues. Todd waited his whole life for Matt Smith's character on Dr. Who to make bow ties cool again. He lives near Baltimore, MD with his wife and son, to whom he hopes to pass on his love of Linux and technology—but perhaps not his fashion sense.
