U2F, FIDO2, and Hardware Security Keys

 In our journey through possession proofs we have encountered hardware factors of various kinds. HOTP and TOTP is often implemented as hardware devices, and of course, so are Smart Cards. In this post we will look at authenticators that implement the FIDO standards -  U2F, WebAuthn, and CTAP2. WebAuthn and CTAP2 are collectively part of the FIDO Alliance’s FIDO2 protocol suite. U2F and UAF are older FIDO protocols that are supported under FIDO2. They can all be thought of as being part of the FIDO2 suite of protocols. 

To understand these protocols, and their advantages and disadvantages, we need to be familiar with the three fundamental actors:

• Relying party (RP) - Also known as the server. This is the service that a user wishes to log into.

• Client - This is the application that brokers the authentication from the relying party to the authenticator and eventually the user. Much of the time, this is a web browser, but it could be any application.

• Authenticator - This is a thing that supports public key cryptography and that processes the cryptographic proof necessary for authenticating the user. The possession proof is that the user has the authenticator in their possession. Authenticators can be platform authenticators - built into a device like a computer or a phone - or they can be roaming authenticators - a separate device. Roaming authenticators are often referred to as “security keys” because they often come in a format that is designed to hang on your keychain. 

In this post we will primarily discuss U2F and WebAuthn, and a few aspects of CTAP2. They are the most commonly encountered of these protocols, at least  in North America and Europe.

• U2F or Universal 2nd Factor - This is an older protocol that covers the interaction between all three actors. It was originally developed by Yubico and Google and donated to the FIDO Alliance.

• CTAP2 - The Client To Authenticator Protocol, v2 (CTAP1 was included in U2F) is designed to let clients talk to external, i.e. roaming authenticators through standard protocols. CTAP2 works over several physical layer protocols, such as USB, NFC, and Bluetooth.

• WebAuthn - The Web Authentication protocol, It defines the interaction between the relying party and the client. It is a World Wide Web Consortium (W3C) standard that defines a javascript API for use between web applications (RPs) and browsers (clients). 

In a very simplified version, the registration and authentication flow proceeds as follows. Most of this is WebAuthn, but if the authenticator is external to the platform hosting the client, the client will speak CTAP2 to the authenticator.

1. A user navigates their client to an RP (you may think “website” if you wish) and requests to register a FIDO2 authenticator

2. The RP asks the client to request a public key from the authenticator. Along with this request the server passes a challenge to the client. It includes some information regarding which RP this credential is valid for, some random bytes that prevent replay attacks, a unique user ID that is not the same as the human-readable username, and some other bits and bobs.

3. The client validates that the RP identity information (RPID) in the challenge matches the RP that the client is talking to. This is done to prevent later man-in-the-middle (MITM) attacks.

4. After validation the client passes the data to the authenticator. 

5. The relying party may request either user verification (UV) or a test of user presence (UP) at this stage. UV means that the authenticator must perform a step to verify the user’s identity. Often this takes the form of using a biometric proof or a PIN code entry. UP means that the authenticator will not proceed unless a human being is present. For instance, on YubiKeys there is a gold capacitive “button” built into the device. Touching this button completes an electrical circuit and activates the device, thus serving as a UP. The RP may specify that UV is required, preferred, or discouraged. It may be relevant to know that Microsoft’s APIs consider preferred and required to be equivalent. That means some Mac users may not need to use UV with a particular RP whereas users on Windows would. 

6. The authenticator generates a public private key pair unique to this RP.

7. The private key is used to sign all the data the RP requested and this credential ID package is returned to the server. 

8. The authenticator also provides an attestation, a signature using an “attestation key” that is programmed into the authenticator when it was manufactured that identifies the manufacturer of the authenticator. The client may elect to pass this attestation on to the RP to enable the RP to restrict users to only certain authenticators. However, by default, attestation is disabled in WebAuthn.
   There is a lot more data in the package, but for our simplified purposes, this is sufficient. 

9. Both WebAuthn and U2F include a really interesting feature here. As you may have already realized, many hardware devices have limited memory to store the private keys and user information. To avoid running out of memory, the protocol allows the authenticator to encrypt the private key using a FIDO master key that is burned into the device at the factory or generated when the device is first used or reset. It can then package it up along with the rest of the data in the credential ID that is returned to the RP. Credentials handled in this way are called non-resident credentials. As they are encrypted on the authenticator this information is opaque to the server.

10. If resident credentials are used the authenticator stores the credential ID and the public private key-pair it generated for this server. The RP validates the information it got back. It then stores the credential ID that maps to the public key and the user account it maintains for the user.

Now let’s say the user wants to log in.

11. The user navigates to the relying party. The RP usually will request a username (this could be username-less too but let’s assume it is not here)

1. FIDO2 supports password-less authentication. If this is used by this RP the client will at this point request a credential ID from the authenticator, which it can pass along to the RP so the RP can look up the metadata related to the user account. 

2. In a more conventional scenario the user types the username and usually a password. This is passed to the RP as the first step of the authentication. 

12. The RP responds with a challenge and a list of credential IDs (authenticators) that are registered to that user. This allows the user to have multiple authenticators registered to the same relying party. The RP also passes the RPID to the client.

1. If the authenticator used non-resident credentials the credential ID also contains the encrypted private key. 

13. The client verifies that the RPID matches the relying party the client is connected to. This prevents man-in-the-middle and spoofing attacks. If the RPID matches, the client passes the data to the authenticator.

14. If the RP asked for UV or UP, the user must now complete that step as well. This is an important security step. If the authenticator is built into the device, or designed to be left in like a YubiKey Nano, this prevents malware on the client from activating the authenticator without the user’s knowledge.

15. The Authenticator finds the correct private key, or decrypts it from the credential ID, signs the request, and returns it to the client.

16. The client passes the response to the RP

17. The RP validates that the private key used to sign the request matches the public key it is aware of, that the challenge matches what it sent, and that the RPID that the authenticator saw is its own RPID. This prevents MITM and replay attacks. 

This is a much lengthier explanation of the protocol, and still quite simplified, than we’ve seen with other MFA solutions, but it is useful to understand it at this level to understand the advantages and disadvantages below. 

Advantages

The most important advantage of FIDO2 authenticators is their extremely high level of phishing resistance. Vendors like to call them “unphishable”. However, phishing protection to a large extent is the client’s job, not the authenticator’s. A flawed client could permit an MITM, while a rogue client can act as an MITM. However, if the client is compromised, the user’s session on the RP in its entirety is subject to compromise regardless of how strong the authentication step is. FIDO2 is correctly thought of as nearly phishing proof, which addresses a huge set of problems. 

Roaming authenticators are extremely convenient when you use multiple systems. A really good way to use them is to bootstrap a device the first time you need to approve it. This is fine as long as the device can be easily marked as untrusted if it is lost, stolen, or decommissioned. An enterprise could use this to robustly authenticate to a stateless computer, reducing an enterprise’s reliance on client state. 

Hardware hackers are fond of trying to come up with ways to clone an authenticator. While many FIDO2 authenticators use secure elements (specially designed cryptographic chips) that make this difficult, not all do. However, even if an authenticator were cloned, the protocol includes a signature counter, which can be used to detect this. If a cloned authenticator is used it would increase the signature counter and the next time the legitimate authenticator is used the RP could detect that the signature counter went backwards, and prompt the user to revoke the compromised authenticator. This is a detective feature, and it is rarely used, but no other authenticator technology supports anything like it. 

U2F authenticators were typically stateless. U2F authenticators typically embed the private key they generate for the RP in the key handle (functionally equivalent to the credential ID in WebAuthn) that is stored on the server. WebAuthn similarly supports non-resident credentials, where the credential ID is stored on the server. The data in this case is encrypted with the authenticator’s FIDO master key, meaning it can only be decrypted on the authenticator itself. If non-resident credentials are used not only could I give you my authenticator and you can start using it as if it were new; you could not determine from the authenticator which RPs I have used it for! This level of privacy is very important for some users, such as journalists working in unsafe locations. If resident credentials are used the authenticator requires user verification (typically with a PIN code) to protect this privacy property, but if my life depended on it I think I would stay away from resident credentials.

This stateless property of the authenticator means that you, Mr. IT Director, can stop worrying about your employees using the authenticators you gave them to protect their personal accounts. It will have no impact on your services. In fact, you probably want to encourage the practice. The security of their personal accounts may also impact the security of the business, and it may make people a bit happier that you look out for their personal security as well. If you have a service where your employees use customer accounts for testing and to interact with customers you probably want to actually require that they use strong authenticators on them. It may avoid a certain amount of embarrassment. 

One very interesting property of FIDO2 authenticators is that they can be used to support passwordless login. Microsoft latched onto this property when they released support for FIDO2 in Windows 10 release 1903. Microsoft envisions this will primarily be used with platform authenticators through Windows Hello. Microsoft requires that platform authenticators support certain security requirements, including that they must store the cryptographic key material in a secure element. In fact, many Windows computers use the same chip that many roaming authenticators use as their secure element, typically an Infineon or NXP secure element. In other words, the primary difference between a roaming and a platform authenticator is essentially whether it is built into the computer or not.

Microsoft supports passwordless login with roaming authenticators as well. In this case, possession of the authenticator is one authentication factor. Credentials used in passwordless login are stored on the authenticator. While not required, to provide 2FA you would have to use a UV in addition to the possession proof. With platform authenticators the UV is nearly always a biometric proof. With roaming credentials it is usually a PIN, but we will see more authenticators with built-in fingerprint readers come to market soon. The PIN code is, frankly, a password but if they called it that it wouldn’t be “passwordless authentication”. To log in using passwordless login and UV with a roaming authenticator you connect the authenticator, touch it, type your PIN, touch it again, and you’re logged in. 

Many people question the security of platform authenticators on the grounds that the credentials are stored on the computer. However, passwordless login, with the exception of a few specialized scenarios where the devices may be considered physically secure, is meant to be used along with a biometric proof or a PIN. While it is true that a PIN is much like a password it is not a password, nor does it need to be as complex as a password. The reason is that the PIN need not be resistant to attacks for nearly as long as a password. The PIN only needs to last long enough to enable the user to report loss of the computer to an administrator so they can revoke the credentials. PINs, unlike passwords, are not the credentials. They merely unlock them. The credentials are stored in a secure element that will not release them without a PIN, a biometric proof, or the intervention of a well-funded nation state actor. In addition, you can configure the system to wipe the secure element if the wrong PIN is entered a relatively small number of times, say, 10, without any real adverse effects. This only invalidates the credentials on that particular platform authenticator, not the user’s network account. Consequently, when using FIDO2 passwordless login with a platform authenticator a PIN of 4-6 characters is safe enough. This provides a vastly improved user experience, and is actually far more secure than anything that involves a password stored on a server, including using a phishable password and a phishable TOTP code.

Microsoft has much more information on Windows Hello for Business at https://www.microsoft.com/en-us/security/business/identity/mfa. Apple’s TouchID and FaceID function as built-in biometric authenticators since MacOS 10.15.3, but as of today, they cannot replace the user password the way they can on Windows.

Some people worry that biometrics used in authentication is an invasion of privacy. It can be, but in the cases we have discussed here the data is only stored locally on the computer or device on which they are used and only in a cryptographic hardware chip - a secure element - in a derived form. It has never been successfully reversed into a usable biometric clone. 

Some people, unfortunately, still do not wish to use these options because they fear that the biometric proof is not sufficiently secure. Apple claims TouchID has a false acceptance rate (FAR) of 1 in 50,000, but after five attempts it forces you to use a password to unlock the computer. This means the likelihood that someone will be able to fool TouchID is vanishingly small. FaceID has a claimed FAR of 1 in 1,000,000. Microsoft’s requirements for FAR for Windows Hello are between 1 in 50,000 and 1 in 100,000, depending on the type of biometric used. Microsoft’s implementation also allows the relying party to specify a minimum FAR and allows the server to detect whether the biometric has changed since the credential was created. While it has been shown in laboratory settings that certain biometrics can be fooled it typically will take longer to do this than it takes for the user to revoke the credentials resident on the device that must be stolen to effect this compromise.

In comparison to passwords, there is really no contest about which one is more secure. In comparison to the low bar of a FAR rate of 1 in 50,000 for Windows Hello and TouchID, somewhere between 1 and 3 passwords in 100 can be guessed by simply using a common password list (credential stuffing). While a 6-digit TOTP code takes 500,000 tries to guess, it can be phished, which WebAuthn (practically) cannot. Compared to the options, WebAuthn, both with platform and roaming authenticators, provides a strong security posture and a convenient option that both consumers and enterprises should consider. 

Because someone will bring this up: no, you cannot defeat Apple’s TouchID using a gummy bear. Yes, I too have seen the video that claims to show this. You should know when you watch it that the guy that shot that video did not have a pin code on his iPhone. He was only using the gummy bear to push the home button, which turned on the phone. The TouchID sensor never even detected the gummy bear as a finger because, as it turns out, TouchID sensors cannot actually detect gummy bears as fingers. Nor can the fingerprint sensors on Google Pixels. I’ve tried. While it may be possible to create a realistic enough 3D print to defeat a FaceID or Windows Hello sensor, they won’t be fooled by a photo. The technology to produce a good enough print to fool Windows Hello, TouchID, or FaceID is rather expensive and complex, and requires pretty detailed scans that probably means the user is in the custody of the attacker already and you probably don’t need to produce the replica. It would probably be more expedient to beat them with a wrench until they tell you the password. 

The one attack that does seem viable, however, is the toddler attack: which is when a toddler holds mom’s iPhone up to her face so they can log in and play games while mom is sleeping. However, in that scenario, physical security has already been breached. 

Disadvantages

The first disadvantage of FIDO2 is RP support. While support is growing by the day, it’s largely focused on enterprises. Whether your enterprise uses GSuite, Azure AD, Okta, Ping ID, Duo, or several other options, you can roll out FIDO2 authenticators today. In fact, some of your users may already use them without you having told them to.

On the consumer side, the story is different. Google and Microsoft do both support FIDO2 security keys. However, while Apple shipped support for FIDO2 in Safari in November 2019, as of early April 2020, Microsoft still blocks you from using a security key in Safari for your Microsoft account. This is endemic to the overall landscape. While Chrome has supported security keys for years, Firefox shipped native support in March 2019, Microsoft in July 2019, and Apple not until November (MacOS) and December (iOS) 2019. Even though they are now widely supported many applications and sites still have not updated their blocking code that prevents browsers other from Chrome from using FIDO2 and many RPs lack support entirely. That said, you can use them on Facebook, Google, Microsoft, but not (yet?) on Amazon. 

Even where it is supported the implementation is sometimes poor. For instance, Twitter supports security keys. Or, more accurately, it supports one security key per customer. There is no reason for this and there are very good reasons to have two keys registered (see the section on recovery below). Other sites, like Vanguard, limit support to certain vendors. Some RPs support them but do not allow you to remove other factors, such as SMS, and often make SMS the preferred factor obviating the entire point of supporting strong 2FA. In fact, most sites that do support security keys do not do so prominently. Few consumers will be looking for sites offering security keys, and if they actually try to use them and find that out of the 100 or so sites they use frequently, only a handful support them and several do so poorly, they will quickly become discouraged. 

There are also implementation problems in client applications. In some cases, you can use a security key on the website, but not in a mobile phone application, requiring the user to have multiple MFA options, or just pick the one that works everywhere. Native applications on any platform either need to directly support FIDO2, or delegate authentication to a web browser that does. This requires the applications to actually understand which web browsers support it and leverage them correctly. Palo Alto’s VPN client, for instance, opens a WebView to authenticate. This WebView has support for security keys disabled, and consequently you cannot log into a Palo Alto VPN using FIDO2. This spotty landscape has caused many companies to look for alternative solutions so users can have a consistent experience. Over the next couple of years we will hopefully see much broader support, but as of right now, it’s relatively sparse. 

The dichotomy between UV and UP and has led to inconsistent implementations and user experiences, with some RPs requiring UV or platforms (i.e. Windows) that interpret UV preferred as UV required. This type of inconsistent experience does a disservice to customers who are already navigating a complicated landscape. For instance, if the experience is inconsistent an enterprise must account for these consistencies in the documentation it produces. Consumer-facing sites will likely investigate doing so, and then abandon the effort and stick with a more consistent, and less secure experience. The community needs to focus on streamlining the customer experience in order to drive better adoption. 

Every single time I have tried introducing someone new to security keys the same question comes up: what happens if I lose it? The answer depends on whether you are using them in an enterprise or personally. In an enterprise, you should contact Helpdesk. They will revoke the lost security key and issue you a new one. If you are the helpdesk, please try not to chastise people or charge them for the lost key. That will discourage them from coming to you and letting you know they lost it. If you make them pay for it they may as well save themselves the humiliation, buy a used key off eBay, and not bother telling you. 

If you are using a security key for personal use, the standard recommendation is that you have two of them. If there is someone you trust implicitly, like, say your spouse, one option is that you each have one and register each other's keys to both people’s accounts. That way you have an automatic backup. Obviously, if they know what password to use, they could now access your accounts but hopefully you can trust a spouse with this. If you can’t, you can buy two keys, but I have personally found this really inconvenient. I have a number of keys, but I don’t carry them all with me all the time, and I can’t ever remember which keys are registered yet to which accounts. Using multiple keys comes with a lot of overhead at registration time. 

Another recovery option is a different MFA mechanism. If you use SMS codes or email for this you have degraded the security of the account to the protection offered by SMS codes or email. It defeats the entire point of using a security key in the first place. You must not use a recovery option that is less secure than your MFA mechanism. 

An recovery option that has worked reasonably well for me has been to use TOTP codes registered in 1Password as a backup mechanism. As I rarely use them to authenticate if security keys are an option, and rely on 1Password to auto-fill them when I do, I can benefit from the phishing protection in 1Password. It is not optimal, but it solves the problem. A final solution is backup codes, which many sites make you print anyway. Personally, I only keep those if the site requires it and store them too in my password vault. Then I use security keys to protect the vault. 

Some users still have challenges with security keys, and frankly, when you read the above narrative it is clear it takes some planning. Yes, it is supremely easy to register a security key and to log in with one. What is NOT easy is figuring out which services support them, how to ensure I can recover the account if my security key is lost, making sure all the keys are registered to all the accounts, having the right key with me at the right time, ensuring that it works with the devices I have with me, and so on. There is definitely a certain amount of cognitive load involved in using security keys. As I have said before, the simplest option that requires the least amount of forethought and planning will often beat out the technically superior option. I hope that with time, this landscape will get better, but for now, FIDO2 security keys are at a disadvantage, particularly for consumer use. 

An interesting property of roaming authenticators is that they are actually a bit anachronistic. We are seeing more and more people starting to replace their door locks with NFC readers or keypads. I honestly cannot recall the last time I stuck a metal key into any lock in my house and I know that I am the only one in my family to even have a metal key for the house. Everyone else uses the keypad on the garage door. I do have a car key. It’s a funnily shaped bit of plastic that is in some pocket of my coat - I don’t know which one. When I walk up to my car it unlocks and I get in and push the go button. I never have to consciously use the car key. 

The reality is that just as technology is starting to allow us to remove keys from most of our daily lives, along comes a technology in the form of a physical key. This is why it is so important to consider platform authenticators. Platforms are with us when we need to use them. However, as of right now platform authenticators are only available on Windows and MacOS, which is not everywhere we need them to be. An authenticator needs to be with you in a format that you can use when you need them, whether what you need to do is register them or log in with them. 

As I sit here and write this it struck me that there is a site that now supports security keys where I have not yet registered them. I thought about getting up from my comfortable couch, setting the computer down, going upstairs to get the key that’s in my backpack, getting the other one that’s on my keychain in the coat closet, and the backup key I store in the safe, and registering them. Or maybe I’ll just take another sip of my favorite beverage, content in knowing that at least I’m using TOTP on that site. I’ll register the security keys some other day.