Although the user experience is straightforward, the implementation details are
anything but. The WebAuthn API covers two closely related key-management activities
112 | February 2019 | https://www.linuxjournal.com
DEEP DIVE
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.
DEEP DIVE
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”.
114 | February 2019 | https://www.linuxjournal.com
DEEP DIVE
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.
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 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)
DEEP DIVE
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)
116 | February 2019 | https://www.linuxjournal.com
DEEP DIVE
As with registration, the user perspective is simply to insert the YubiKey and trigger it with a touch. What could be easier?