This article appeared in the December issue of the Information Systems Security Association (ISSA) journal. You can unlock full access to the journal here: https://www.issa.org/journal/december-2020/.

What is Fast IDentity Online? An authentication scheme? Don’t we have enough multi-factor authentication (MFA) schemes that adequately mitigate risk and meet regulatory compliance requirements already?

For over two decades, industry produced a variety of MFA schemes based on the principles of something you know, something you have, and something you are. Ignoring the fact that the vast majority of these schemes piled additional secrets (one-time passcode (OTP), knowledge-based answer (KBA), or biometric template on top of the original secret (the password), and were consequently susceptible to scalable attacks similar to passwords, the vast majority of businesses and government agencies have deployed one form of MFA or the other.

In the last 15 years since California passed its seminal breach disclosure law, nearly 10,000 data breaches were publicly disclosed, compromising over 10 billion personal records. The vast majority were the result of compromised passwords. However, MFA had not adequately addressed the problem effectively. Proprietary schemes, expensive devices, and the fact that the “gold standard” of MFA schemes — RSA’s SecurID — was compromised in a scalable attack nearly a decade ago, demonstrates that secret-based authentication schemes were simply not up to the task.

What about public key infrastructure? Didn’t PKI break the mold by authenticating users through digital signatures without the need for a secret on the server? Indeed, it did. Many companies, government agencies, and nations invested billions of dollars issuing smart cards and built applications using strong authentication delivered through the transport layer security (TLS) client authentication (ClientAuth) protocol enabled by X.509 digital certificates and cryptographic keys on the smart cards. However, the complexity of building and maintaining PKI, and the challenging user experience (UX) when working with digital certificates left a lot to be desired.

A group of companies around 2014 believed the time had come for something stronger and better. The world of computing and the worldwide web had changed dramatically, and something different was needed that embodied these principles. The new scheme had to:

• Eliminate passwords completely
• Address capabilities and vulnerabilities of the worldwide web (which included mobile devices)
• Be an open, royalty-free industry standard available for anyone to implement
• Incorporate user privacy as a design principle
• Be extremely simple and easy to use by anyone

And the FIDO Alliance was born. With over 200 companies worldwide as members of the Fast IDentity Online Alliance, currently including the governments of the US, UK, Australia, Germany, last year saw the latest version of the FIDO protocol standardized by the alliance, with the World Wide Web Consortium (W3C) supporting a standard JavaScript application programming interface (API)—WebAuthn—to support a standard way of integrating FIDO into web applications. Some of the world’s largest Internet sites, corporations, and the US government have done so with more coming. Every modern web browser (with the exception of the legacy Internet Explorer),Windows 10, Android (7 or greater), and iOS currently supports FIDO without the need for special drivers, middleware, or readers.

What distinguishes FIDO from every other authentication protocol from the past?
Like TLS client authentication, FIDO uses public key cryptography to eliminate secrets on the server. But, unlike the X.509 digital certificate that underlies TLS ClientAuth, FIDO does not need a PKI. As a result the cost, complexity, and challenging UX of using smartcards and digital certificates are obviated.

Like MFA schemes that use a hardware authenticator, FIDO uses cryptographic hardware modules that may be embedded within devices—such as the trusted platform module (TPM) on personal computers, secure elements (SE) on Android phones, or external authenticators called security keys in FIDO terminology. These hardware elements are designed to protect cryptographic keys to mitigate scalable attacks on keys. Note: all references to FIDO imply FIDO2/WebAuthn.

Unlike any other authentication technology of the past, FIDO is unique in including the following features (figure 1):

• FIDO requires the generation of a new, unique key-pair (public key/private key) for every website with a unique web origin consisting of a top-level domain (such as .com, .net, .org) plus one sub-domain (such as issa). As a result, FIDO authenticators generate unique key-pairs for a user’s credential at issa.org.1 Every FIDO-enabled website  is required to declare a relying party identifier (RPID). While a relying party (RP)—the company site that relies upon a FIDO digital signature to authenticate a user’s credential—may have many websites such as register.issa.org, subscribe.issa.org, or login.issa.org, they may use the same RPID (issa.org) and FIDO server to support a single FIDO credential per user across all its sites. This enables authenticating the user to each site separately, providing the advantage of distributing authentication workloads across a cluster of FIDO servers while eliminating the burden of adding a legacy protocol to web applications to support single sign-on. FIDO mandates the use of TLS so all communications on the wire are secure. However, FIDO assumes that the client platform, usually the browser, is secure—FIDO cannot protect a user from a compromised platform.

• FIDO uses two distinct protocols to communicate between the RP and the authenticator: the W3C JavaScript API—WebAuthn—between the RP web-application and the client platform—usually the browser; and the FIDO Alliance’s client-to-authenticator protocol (CTAP) between the client platform and the authenticator. Since both WebAuthn and CTAP are standard protocols, users as well as RPs are freed from the burden of attempting to make a complex set of software and hardware components work together on a multitude of operating systems and devices; each platform vendor—whether it is Microsoft, Google, Mozilla, Apple, etc.— assumes the responsibility of making sure that WebAuthn and CTAP work precisely as expected on their platforms.

• FIDO allows the registration of any number of unique authenticators to an RPID. This is unlike password technology where you can have only one username and a single password. While X.509 digital certificates permit issuing unique digital certificates to the same user and allowing the user to use any of the set of digital certificates to authenticate to a TLS ClientAuth-enabled site, this is rarely done in practice. However, FIDO allows a user to use the TPM on a Windows 10 personal computer, the SE on an Android phone, the SE accessed through TouchID on  a MacBook, and an external security key to be all regis- tered to the same username at a specific site and use any of these four authenticators to authenticate to the site. This has the advantage of eliminating the problem of account recovery: how to gain access to your account if you lose your primary authenticator. The user simply uses another authenticator registered with the site, authenticates to the site, goes into her profile settings, deletes the lost authenticator’s registered key, and carries on. Users may choose to replace the lost authenticator with a new one, but as long as a user has at least two keys registered with a site, she  is unlikely to be locked out of her account. Even if both authenticators are lost/unusable, most RP sites will have a non-FIDO based account-recoveryprocess, which is likely to fall back to sending an email-reset link plus an OTP to one's mobile, etc. to gain access to the site. Once authenticated, users may register any number of new authenticators to their account again.
  
  
• FIDO eliminates the risks associated with password phishing. Cleverly crafted spear-phishing attacks to spurious websites that prompt for usernames/passwords are pointless if the authentic site supports FIDO-based passwordless authentication. There is no password to provide to the attacker’s site! Additionally, a man-in-the-middle (MITM) attack that attempts to relay a user’s authentication session through their attack site will fail since the attacker’s site will have a different domain name system (DNS)-based web FIDO platforms such as browsers or rich client apps (RCA) on mobile devices are required to map the RFC-6454 [1] web origin to the RPID and ensure they have the same TLD+1 before using the private key to digitally sign a challenge.
  
  
• FIDO mandates a test of user presence (TUP) that requires an authenticator to verify the presence of a human being at the client device attempting to authenticate to a site. While the FIDO protocol mandates the TUP, it leaves the TUP’s implementation up tomanufacturers of authenticators so the market may innovate and provide a variety of solutions. Some external authenticators merely require you to touch a metallic sensor (generally, with  a blinking light emitting diode) on the device to prove TUP. While this implementation does not identify a specific user, it provides the RP evidence of possession of the right authenticator containing a private key corresponding to the registered public key at the RP site, as well as the presence of a human being at the client device with that authenticator. The design of the FIDO protocol takes into account that platforms prevent attackers from gain- ing access to lower level communication protocols such as the universal serial bus (USB), near-field communications (NFC), or the bluetooth low energy (BLE) transport protocols between the platform and an external authenticator.
  
  
• Where RP sites require the authenticator to verify the identity of the user at the client device, FIDO supports the use of embedded device authentication capabilities to support user verification (UV). An external authenticator with biometric capabilities—the MacBook with Touch- ID, a Windows 10 personal computer with a fingerprint reader, a mobile device with a fingerprint reader, personal identification number (PIN), or a geometric pattern reader—any of these provide assurance to the RP application that the FIDO authenticator verified the identity of the user before authorizing the use of a private key to digitally sign the FIDO challenge. In keeping with privacy principles of the FIDO protocol, neither the biometric template, nor the PIN/pattern are shared with the RP site—they are used only to verify the user identity locally on the authenticator device/platform, and when verified, unlock the private key to sign the FIDO
  
  
• FIDO protocol can require that assertions—digital signatures generated during the FIDO authentication process—cannot be replayed by requiring the FIDO server to send a unique nonce (monotonically incrementing number used once) as part of the challenge, and having the authenticator sign the nonce with the private The FIDO server not only verifies the digital signature in the assertion, but also verifies the accuracy of the nonce with what the server sent earlier, and that the nonce was not used in any prior authentication.

• With the appropriate platform and authenticator (figure 3), FIDO has the potential to deliver a frictionless user experience for a business transaction. For instance, a transaction performed on a computer with a fingerprint reader could render transaction details to the user and prompt  for a FIDO digital signature asserting to the transaction details. This obviates the need to send any short message service-based (SMS) OTP to the user’s mobile phone or email an OTP to the user. This is also true of mobile de- vices. This frictionless experience can have a profoundly positive experience with users while drastically reducing risk for an RP due to the security of the FIDO protocol.2

FIDO is one of the most innovative authentication solutions that has appeared on the landscape in a quarter of a century. NIST declared FIDO to provide the “highest assurance level” for an authentication protocol in its Special Publication 800-63 [3]. While it still remains the responsibility of users and/or RPs to ensure that authenticators are secure enough for their purposes, the FIDO Alliance has defined a security certification process conceptually analogous to the Federal Information Processing Standards (FIPS) 140-2, but whose tests are specific to features defined within the FIDO protocol. Manufacturers of authenticators may choose to submit their devices to independent laboratories who test them for specific security levels and provide the FIDO Alliance the re- sults for certification. With configurable FIDO servers, RPs may define security policies that are suitable for their business purposes.

There are dozens of implementations of FIDO-certified authenticators and servers, including an open-source FIDO-certified server. If you have a recent build of Windows 10 on your computer, a MacBook with TouchID, an Android 7 (or greater) phone, or an iPhone with the latest build of Safari, I encourage you to try the experience of registering and using a FIDO authenticator at one of the many sites currently supported [2] —FIDO is certain to play a central role in your security defense strategy in the coming decade.

References

1. Barth, “The Web Origin Concept,” IETF – https://tools. ietf.org/html/rfc6454.
2. FIDO authenticator sites: com, github.com, godad- dy.com, google.com, login.gov, namecheap.com, strongkey. com,twitter.com.
3. “Digital Identity Guidelines,” US National Institute of Standards and Technology – https://pages.nist.gov/800- 63-3/.
4. "Data Breaches,” Privacy Rights Clearing House – https://privacyrights.org/data-breaches.
5. Visit Estonia. “12 Digital Services in e-Estonia,” Estonia Official Tourist Information Website – https://www.visites-com/en/why-estonia/12-digital-services-in-e-estonia.
6. “RSA SecurID” – https://en.wikipedia.org/wiki/ RSA_SecurID.

About the Author: Arshad Noor is the CTO of StrongKey since 2001. With 34+ years of experience in the information technology sector, he has spent the last 21 years of his career focused on solving data-protection problems using applied cryptography. In 2019, he served as one of 20 members on the California Blockchain Working Group helping to craft recommendations to the State Legislature on how the fifth largest economy in the world should deal with blockchain. He may be reached at arshad. noor@strongkey.com.