Cybersecurity – Pomcor

FIDO2 and WebAuthn have momentum but won’t help if they are not used

March 18, 2023: The preprint referenced below has been updated to add a patent disclosure.

FIDO2 and WebAuthn have momentum. They are supported on all browsers. Apple, Google and Microsoft are busy developing or releasing initial versions of passkey syncing. NIST now requires resistance to phishing attacks at Authentication Assurance Level 3 of the Initial Public Draft of Revision 4 of the Digital Identity Guidelines. CISA has endorsed FIDO as the gold standard. And all the tech blogs are announcing the demise of passwords that FIDO will bring.

But a year ago the FIDO Alliance announced in a white paper that FIDO authentication “has not attained large-scale adoption in the consumer space.” Has that changed? Is it changing? Is it ever going to change?

The FIDO Alliance white paper coupled the announcement of the lack-of-adoption problem with a diagnosis of the problem and the announcement of an upcoming solution. The problem was due to the challenges that consumers face with platform authenticators: “having to re-enroll each new device”, and having “no easy ways to recover from a lost or stolen device”. Apple, Google and Microsoft were going to provide the solution by syncing credentials across devices. The term “passkeys” was coined to refer to synced credentials.

Apple, Google and Microsoft are keeping their promise and diligently working on the solution. Kudos to them. But FIDO authentication has daunting problems that are not addressed by passkeys.

One of them is the reliance on the device unlocking mechanism, e.g. Windows Hello in the case of a Windows laptop, to provide a second authentication factor supplementing the proof of possession of the private key. A user who does not set up device unlocking cannot use FIDO. How many users set it up? I couldn’t find any statistics about this, but I thought of people who would know. Geek Squad Agents work full time helping people set up and repair their devices, so they intimately know how consumers use laptops and smart phones. I interviewed one of them: “How many Windows users set up Windows Hello?” He said: “30%; just a guess.”. I thought he had misunderstood the question, so I asked again: “You mean as many as 30% do NOT set it up?” He replied: “No, MOST do not set it up. I’d guess about 30% set it up.”.

Another big problem for FIDO is its positioning as passwordless authentication. There are three kinds of authentication factors: knowledge, possession, and inherence. Advertising an authentication technology as being passwordless is advertising it as lacking one kind of factor. That’s a bad thing, not a good thing. I guess the slogan originated when people started using many web sites, and were told not to reuse passwords, and were having trouble remembering many different passwords. But that’s a problem that disappeared more than ten years ago when, first password managers, and then browsers, started keeping track of passwords.

Today users love passwords, and they resist having to use anything else. A password is the only authenticator factor that the user has full control over. It is the quintessential self-sovereign authentication factor.

I’ve just put online a preprint of a paper entitled “Overcoming the UX Challenges Faced by FIDO Credentials in the Consumer Space.” The previous post was an extended abstract of the paper. The full paper gives the details, with figures, of two authentication protocols. The first one uses existing FIDO credentials and provides an incremental improvement on the FIDO user experience. The second protocol removes the major obstacles to the adoption of FIDO2 and WebAuthn, using enhanced credentials and an extension of WebAuthn. It does not require a Windows user to set up Windows Hello, and uses as a second factor a full fledged password, not a PIN or a biometric, cryptographically protected against reuse, data breaches, and phishing attacks by being combined with the cryptographic factor into a joint authentication procedure.

Overcoming the UX Challenges Faced by FIDO Credentials in the Consumer Space

March 18, 2023: The preprint has been updated to add a patent disclosure.

This post is an extended abstract of a paper to be presented at HCI International 2023. A preprint of the full paper is available here.

Two-factor authentication (2FA) to a web application (hereinafter, the “relying party, or RP”), where the first factor is a password and the second factor is a security code sent to the user by the RP, has been touted as a solution to the vulnerabilities of passwords. But traditional 2FA is now known to be vulnerable to phishing attacks, as the security code can be relayed by a man-in-the-middle attacker in the same way as the password. On the other hand, cryptographic authentication with a key pair credential is phishing resistant because the private key is not transmitted to the attacker. Widespread adoption of cryptographic authentication could greatly improve the security of web applications, and cybersecurity more generally.

But as is the case for any new technology, adoption of cryptographic authentication will require a favorable user experience (UX), and current experiences face well-known challenges. In this paper we propose alternative user experiences that overcome these challenges in two different ways.

A User Experience for Strong Authentication in the Consumer Space

This is the last post of a four-part series on cryptographic authentication. Links to earlier posts can be found at the end of this post.

A few months ago I was talking with a business woman about technology topics. As I was trying to explain the concept of cryptographic authentication with a key pair, she asked: what if the attacker steals the computer?

She then told me that a boyfriend had once stolen her computer and used it to launch a devastating attack against her life, which it took her months to recover from, by impersonating her on the internet. We did not discuss the details of the attack, but it is easy to imagine how it may have been carried out. He may have screen-unlocked her computer using her PIN, which she may have given to him before they became estranged, or he may have obtained the PIN through shoulder surfing. Her browser may have saved all her passwords and supplied them as he logged in to her financial and social media accounts with the stolen computer. He may also have been able to extract the passwords from the browser and transfer them to his own computer, using the same PIN to authenticate to the browser.

As I remembered this story I realized that I had missed this attack as I listed attacks relevant to the consumer space in part 2 of the series. I did list theft of the computer by a determined attacker who plans ahead and mounts a prior attack to get the PIN. But this attack is different because the attacker has to make little or no effort to get the PIN if he lives in the same house or apartment as the victim or visits often. It is also a different kind of attack, because the the goal of the attacker is to inflict pain rather than to obtain information or material gain. Together with cyberstalking and other forms of digital abuse against women, the attack belongs in a category that deserves special efforts to protect against. Yet FIDO2 and WebAuthn provide no defense against it, since no password is used, and only a PIN is required to unlock a credential.

A password-centric user experience

Remembering the story also made me rethink the user experience that I was going the propose in this blog post for the strong authentication method that I specified in the previous post (part 3).

Strong Authentication for the Consumer Space

This is part 3 of a series of blog posts on cryptographic authentication. Links to earlier posts can be found at the end of this post.

In the first two posts of the series I proposed a cryptographic authentication method that solves the loss-of-credential problem blamed by the FIDO Alliance for the lack of adoption of FIDO authentication in the consumer space, and does so without exposing the private key to capture by syncing the credential across devices.

In this post I show that strong authentication as traditionally defined can be achieved in the consumer space by combining a cryptographic credential with a second factor.

Traditional definition of strong authentication

Traditional thinking about user authentication distinguishes three types of authentication factors and requires at least two factors of different types for strong security. The three types are knowledge, or something that the user knows, such as a password; inherence, or something that the user is, i.e. a biometric feature; and possession, or something that the user has. Cryptographic authentication is a possession factor, based on a proof that the user possesses a cryptographic module containing a private key that is generated within the module and never leaves the module in the clear.

According to this thinking, cryptographic authentication by itself does not provide strong security because it only provides one authentication factor. But in the three authentication solutions discussed earlier in the series, cryptographic authentication is not used by itself. To use the key pair credential the user has to use a PIN or a biometric to unlock the platform authenticator that contains the credential in solutions 1 and 2, or to screen-unlock the device that contains the browser where the credential is stored in solution 3. Does such unlocking amount to a second authentication factor? Does it provide strong security?

Unlocking the credential is not an authentication factor in the consumer space

Even though a PIN is “something you know” and a biometric is “something you are”, unlocking the authenticator or screen-unlocking the device may or may not qualify as an authentication factor. This is because the PIN or the biometric are not presented to the remote relying party: they are presented to a local device, which may be controlled by the attacker. The device could be, for example, a public computer that the attacker has had access to and has tampered with. For the unlocking to qualify as an authentication factor, the relying party has to be assured that: (i) the authenticator in solutions 1 and 2, or the device in solution 3, are supposed to be capable of securely verifying the PIN or the biometric and communicating the result to the relying party, and (ii) they have not been tampered with. This assurance can be provided by the attestation feature of FIDO authenticators, but the FIDO Alliance recommends not using attestation in the consumer space:

A note on attestation: We recommend that most relying parties operating in the consumer (as opposed to enterprise) space not specify the attestation conveyance parameter attestation (thus defaulting to none), or instead explicitly use the value indirect. This guarantees the most streamlined user experience (platforms are likely to obtain consent from the user for other types of attestation conveyances, which likely results in a larger fraction of unsuccessful credential creations due to users canceling the creation).

Therefore unlocking does not count as an authentication factor in the consumer space.

Furthermore, even if attestation were performed, the unlocking would not provide strong security. Having to unlock the authenticator is meant to provide protection against an attacker who steals the device. But, as discussed in the previous post, an attacker who plans ahead may be able to use various easy attacks to obtain the PIN before stealing the device.

Yet it is possible to provide strong authentication in the consumer space, by using an undisputable second factor.

Comparative Security Analysis of Three Cryptographic Authentication Solutions for the Web

This is the part 2 of a series of blog posts on cryptographic authentication. The previous post can be found here. The next post is now available.

As pointed out in the response from the FIDO Alliance to the pre-draft call for comments on version 4 of NIST Special Publication 800-63, the two-factor-authentication solutions widely used today on the web are vulnerable to phishing attacks. On the other hand, cryptographic authentication with a key pair credential is phishing resistant, because the private key component of the key pair is not sent to the relying party, i.e. to the web site or web application to which the user is authenticating, and cannot be obtained by a phishing site.

As we saw in the previous post, FIDO2 is a cryptographic authentication solution that generates, stores and uses the key pair in a FIDO authenticator (except that it may export the private key under encryption to save space). Platform authenticators are now available in all commonly used personal computing devices, and can be accessed by browsers through the WebAuthn API of the W3C. This makes FIDO2 a generally available authentication solution for the web.

However, in a white paper issued in March 2022, the FIDO Alliance announced that FIDO2 “has not attained large-scale adoption in the consumer space”, and attributed the lack of adoption to challenges faced by consumers when a credential is lost because the device containing the platform authenticator becomes unavailable. Apple, Google and Microsoft are addressing this problem by implementing multi-device credentials that are stored in platform authenticators and can be synced across devices.

In the previous post I proposed a different cryptographic authentication solution, illustrated by two demo apps on GitHub, that uses a new user experience to solve the loss-of-credential problem. Key pairs are kept in persistent browser storage, and the user can easily create a new credential in a new browser by logging in with her email address and opening a link sent to the address.

The previous post was thus concerned with three cryptographic authentication solutions: a solution with single-device credentials, a solution with multi-device credentials, and a solution with single-browser credentials. In this post I compare the security postures of these three solutions in consumer-space use cases.

Passwordless Authentication for the Consumer Space

This is part 1 of a series on cryptographic authentication. Part 2 and Part 3 are now available.

FIDO adoption lags in spite of general availability

In a white paper issued in March 2022 the FIDO Alliance candidly announced that FIDO-based authentication based on the FIDO2 standards, which include the Client-To-Authenticator Protocol of the FIDO Alliance and the companion Web Authentication API (WebAuthn) of the W3C “has not attained large-scale adoption in the consumer space”.

FIDO2 is a cryptographic authentication solution for the web, which uses a key pair managed by an authenticator and is advertised by the FIDO Alliance as being “passwordless”. The key pair may be stored in the authenticator, or, equivalently from a security viewpoint, it may be encrypted under a symmetric key stored in the authenticator, and exported to play the role of a “credential ID”. The authenticator may be a “roaming authenticator” carried in a “security key”, or a “platform authenticator” provided by the OS of the user’s smartphone or laptop.

Early authenticators were security keys, which few web users had. Today most smartphones and laptops have platform authenticators, and that makes FIDO2 a generally available web technology. But the announcement by the FIDO Alliance shows that general availability has not translated into general adoption.

The white paper attributes this to challenges that consumers face with platform authenticators: “having to re-enroll each new device”, and having “no easy ways to recover from a lost or stolen device” as the credentials managed by the platform authenticator of the device are lost. To address the loss-of-credential problem, Apple, Google and Microsoft have announced a joint effort to devise solutions that are expected to become available “in the course of the coming year” and that, according to the white paper, will involve “multi-device credentials”.

Another contributing factor to the lack of adoption, however, is no doubt the complexity and cost of the FIDO2 authentication solution. Implementing the solution in a web app requires FIDO Server software provided by a company certified to provide such software by the FIDO Alliance. A team from the certified company must work with a team from the company that is developing the app to integrate the solution into the app. By contrast, an ordinary 2FA solution is implemented by the app developers themselves, possibly by a single developer, without any integration effort.

Thus FIDO faces two obstacles to widespread adoption: usability and cost.

Two working demonstrations of cryptographic authentication on GitHub

But cryptographic authentication need not be complicated, costly or challenging to the consumer. It can be implemented simply by storing a key pair in persistent browser storage (localStorage or IndexDB), registering the public key, and authenticating by proof of possession of the private key. I will refer to this as the browser storage solution to cryptographic authentication while referring to the use of a FIDO authenticator as the FIDO solution, or the authenticator storage solution, glossing over the fact that the private key may be exported under encryption rather than physically kept in the authenticator.

The browser storage solution can easily overcome the two obstacles that FIDO faces in the consumer space. To demonstrate this I have published on GitHub two demo web apps that implement passwordless, phishing-resistant cryptographic authentication with a key pair credential, without relying on an authenticator. In both of them the key pair is generated in the browser by the JavaScript frontend of the app, and kept in the localStorage facility provided by the Web Storage API. One of them uses a “nosql” (MongoDB) backend database to register the public key and store the user data, while the other uses an “sql” database for that purpose.

Pomcor Releases PJCL 1.0.0 on GitHub and npm and Deprecates the Beta Versions of the Pomcor JavaScript Cryptographic Library

In 2018 we published a series of beta versions of the Pomcor JavaScript Cryptographic Library (PJCL), which we called 0.9.0, 0.9.0r1, 0.9.1, 0.9.1r1 and 0.9.1r2. (We shall use semantic versioning to name future versions.) We then had to put the PJCL work on hold, but have now been able to resume development. We have refactored the library as an ES6 module and released version 1.0.0 on GitHub at https://github.com/fcorella/pjcl.git, and on npm.

While testing the refactored version 1.0.0 we found two bugs that we tracked back to version 0.9.1r2. Specifically, we found a bug in function pjclPBKDF2_SHA256 and a bug in function pjclFFCValidateG_256, which caused the JavaScript interpreter to throw exceptions. We fixed the bugs in a maintenance release 0.9.1r3, but we have now archived and deprecated the beta versions and will no longer be maintaining them.

If you want to stay informed about PJCL in the future, please subscribe to GitHub notifications about the pjcl repository.

Identity in a Zero Trust Architecture

In the previous post I said I was happy that the new CFO of Pomcor, Ken Cone, has experience with government contracting, as his experience may help us apply for and manage government funding for our reasearch on identity and authentication protocols. Identity is an essential element of cybersecurity, and Executive Order 14028 has recognized that cybersecurity is an essential element of national and economic security.

Here I want to add that identity is essential, more specifically, in modern “zero trust” cybersecurity architectures whose importance is recognized by the Federal Government. The White House has stated in the OMB memorandum M-22-09 that a zero trust approach to security is needed today to provide a “defensible architecture” in the current threat environment. The Department of Defense (DoD) has published a Zero Trust Reference Architecture, and M-22-09 directs Federal Agencies to move towards zero trust cybersecurity principles.

This has implications for identity. As stated in the Reference Architecture and cited in M-22-09, “The foundational tenet of the Zero Trust Model is that no actor, system, network, or service operating outside or within the security perimeter is trusted. Instead, we must verify anything and everything attempting to establish access.” This means that secure identification is an essential requirement of zero trust architecture.

To meet this requirement, M-22-09 calls for multi-factor authentication (MFA); not the usual MFA, however, but rather what the memorandum calls “phishing-resistant MFA”, where phishing resistance is achieved by using a secret that is not shared with the relying party. That means a private key.

Thus the memorandum is calling for cryptographic authentication, which is what Pomcor has been working on for years, and is working on right now. I look forward to Pomcor contributing to the transition towards zero trust in the Federal Government and to the adoption by the Government and the Private Sector of cryptographic authentication methods that provide strong security.

The 0-RTT Feature of TLS 1.3 Can Be Used As an Encrypted Steganographic Channel to Operate a Backdoor into an Enterprise Network

The TLS 1.3 specification in RFC 8446 allows the client to send application data to the server immediately after the ClientHello message, with zero round-trip time, and refers to that data as 0-RTT data or early data.

A server that receives early data may accept it or reject it. Rejected data is ignored by the server but seen by all routers, switches, firewalls and other network appliances in the network path from the client to the server. Therefore an attacker-controlled client can use rejected early data as a steganographic channel to communicate with any compromised network appliance situated in the network path. Furthermore neither the server, nor any of the TLS visibility solutions that are currently in the market among those that I surveyed in an earlier post, attempt to decrypt rejected early data. Hence the attacker-controlled client can encrypt the channel using a key unknown to the server but shared with the compromised appliance without risking detection.

An attacker who has implanted persistent malware on an enterprise network appliance can therefore use rejected early data as an encrypted steganographic channel to send command-and-control (C2) instructions from an external client to the implant in the compromised appliance and thus operate a backdoor into the enterprise network.

In this post I go over some of the details of the 0-RTT feature of TLS 1.3, describe several methods that an attacker-controlled client can use to cause rejection of early data by the server, sketch out an attack scenario and propose mitigations.

Nubeva Explains How It handles TLS 1.3 Key Updates in Response to Pomcor Blog Post

In the last post of the TLS traffic visibility series, before a survey of solutions, I drew attention to how in TLS 1.3 different kinds of traffic are protected under different keys and sometimes with different ciphers, and how client and server can update their application traffic keys at any time. I referred to this as the multiple protection state problem of TLS 1.3.

This problem means that PFS visibility solutions where a single symmetric session key per direction of traffic is sent to a passive visibility middlebox will not work for TLS 1.3 even if they work for TLS 1.2. I mentioned two such solutions in the previous post, one of them being Nubeva’s Symmetric Key Intercept (SKI), described in a presentation at a NIST workshop.

In response to the blog post, Nubeva has sent me a detailed explanation of how their SKI solution handles the multiplicity of symmetric keys in TLS 1.3. It turns out that, although the solution is called Symmetric Key Intercept and the workshop presentation referred to the extraction of symmetric keys from system memory, it is not the symmetric keys that are extracted and sent to a decryptor, but rather the TLS 1.3 traffic secrets, from which the symmetric keys are derived by the decryptor as described in Nubeva’s response.