YubiKeys Aren't A New Hardware Token

This post is about security keys and passwordless authentication. A popular implementation of this is YubiKey, which has just announced biometrics capabilities.

YubiKeys aren't a hardware token. They're a radical shift in the fundamentals of how we do trust, authentication, and identity. You can even code-sign your docker images with them! It supports OTP (One-Time Password), PKI (Public Key Infrastructure, used for encryption and authentication), and U2F/FIDO2/WebAuthn.

I'm going to focus on implementation with the standard/open API WebAuthn.

YubiKey and WebAuthn work together to implement strict controls and checks that provide better guarantees about trust and identity. They also enable passwordless multi-factor authentication that, at least so far, completely mitigates phishing attacks. It seems to have eliminated an entire class of security threat.

How often do we see an entire threat vector eliminated? Once or twice in a lifetime?

Here's a little background with a high-level description of how it works.

FIDO and WebAuthn

The FIDO ("Fast IDentity Online") Alliance is an open industry association focused on authentication an identity.

FIDO members include (from the Wikipedia page):

FIDO was founded by Agnitio, Infineon, Lenovo, Nok Nok Labs, PayPal and Validity Sensors.[2] By the end of September 2016, FIDO members totaled more than 260, including a board made up of the Aetna, Alibaba Group, Amazon, American Express, ARM, Bank of America, BC Card, Broadcom, CrucialTec, Daon, Egis Technology, Feitian, Gemalto, Google, HYPR, Infineon, Intel, ING, Lenovo, MasterCard, Microsoft, Nok Nok Labs, NTT DoCoMo, NXP Semiconductors, Oberthur Technologies, PayPal, Qualcomm, RSA, Samsung Electronics, Synaptics, USAA, Visa, VMware, OneSpan and Yubico.[3] A full list of members is available on the official website.

FIDO's released the U2F (Universal 2nd Factor) protocol and submitted it to W3C (World Wide Web Consortium, an internet standards organization) as a proposed standard. The official, published standard is now called WebAuthn (WebAuthentication).

YubiKey

Yubico, the company that makes the YubiKey, is a "Board Level Sponsor" of the FIDO Alliance and (I believe) the first authenticator solution to support U2F and WebAuthn.

Registration

The WebAuthn standard starts with the user registering their authenticator (such as YubiKey). Once that device is initially associated with an owner/identity, there is an initial registration that occurs seamlessly per application/service.

From a high-level perspective, the process looks like this:

  1. When a user first logs onto a service - they provide their username, and it's passed to the relying party (service/app we are signing on to use). No password is entered or exchanged.
  2. The server sends back a challenge key for the user for one-time registration and provides its relying party info - the client verifies this for authenticity, then checks against it any time the user connects to this app again.
  3. The authenticator (YubiKey) is triggered to perform user verification and consent (pressing the button, entering pin, biometrics).
  4. Authenticator - YubiKey - generates and exchanges a public-private key-pair that is explicitly associated with this app via a credential ID. The credential ID and public key are combined to create an "attestation object," and provided to the relying party/service. The attestation object is a mechanism to do verification checks of the authenticator's integrity.

No password, PIN, or anything else has been exchanged or can be phished/spoofed.

  1. Finally, the server/relying party verifies the challenge-response and signatures are good and registers the client/authenticator.

Authentication

After the initial registration, we can authenticate. Conceptually, the process looks like this:

  1. User signs on by providing their username to the server (relying party).
  2. Server provides a challenge, and it's relying party info
  3. The client verifies the relying party ID against the origin. Then the YubiKey is given the domain name the challenge is associated with and requests consent from the user. If the domain doesn't match the data saved during registration, the server/relying party is considered a risk and not trusted.

That last point is a very crucial distinction and why YubiKey/WebAuthn hard counter phishing attacks. The YubiKey has the server/relying party's domain and info from registration stored directly. If an attacker tries to trick the user into entering credentials into a spoofed site, the authenticator fails the verification check, helping to eliminate the weakest-link - untrained or careless users, or even experienced users duped by a sophisticated counterfeit.

  1. The authenticator/YubiKey creates and sends a signed assertion and authenticator data. These are derived from the key exchange during registration.
  2. Client/browser forwards auth data from YubiKey/authenticator and includes the PublicKey associated with the service/relying party.
  3. The server/ relying party validates the challenge and checks the keys/signatures against its records from registration. If all checks succeed, the user is authenticated and is verified/trusted. And we can be confident of this. No one entered a password or struggled to get their phone out to authorize a push.

So, the service and the user mutually can be confident of their authenticity/integrity, and that the interactions are intentional via multi-factor authentication.

Hopefully, this has helped bring some awareness and understanding, and hopefully, excitement about how game-changing this is!