Blog – Pomcor

A driver’s license credential usable for website registration and traffic stops

Update after the workshop. I made the presentation in Session 2 / Day 1 / Room L and the audience was able to run the demo while I was showing the slides. Philip Quinlan pointed out that a dynamic QR code would be displayed on a small screen, and the driver would have to come close to it to scan it, which would be unsafe for the officer. I came up overnight with an alternative presentation method that uses a static QR code, and presented in Session 10 / Day 2 / Room C. Notes for both sessions are online.

I am writing this post at the Computer History Museum in Mountain View, California, where I'm going to be attending the 41st Internet Identity Wokshop.

I am going to make a presentation describing a live demonstration of a driver’s license credential usable for website registration and traffic stops. The audience will be able to run the demo following instructions in the presentation.

The demonstration is part of a joint project with Sukhi Chuhan, Pema Selden and Veronica Wojnas.

Unlocking passkey adoption with a more secure and more convenient way of using passkeys

A recent survey by the FIDO Alliance shows that passkeys have still not reached widespread adoption. The survey has found that, among users who have used passkeys, only "38% report enabling them whenever possible." This means that users who are familiar with passkeys do not think they are secure enough or convenient enough.

A passkey is used today in one of two ways: as a second factor after authentication with username and password, or by itself with user verification by a PIN or a biometric with fallback to a PIN. In this post I propose a third way of using a passkey that is more secure and more convenient than either of those two methods, and may have a better chance of achieving widespread adoption.

Using a browser as a credential wallet

From the very beginning of the web, browsers have been used as credential wallets to store and present cryptographic credentials, which makes sense since the browser is the user's agent on the web. But only TLS certificates have so far been supported, and proof of possession is inconveniently provided, during the TLS handshake, to transport-layer rather than application-layer code of the network stack of the relying party.

In Chapter 12, Section 12.4, of the book on Foundations of Cryptographic Authentication that I'm writing with Sukhi Chuhan and Veronica Wojnas, we show how a browser can be used as a credential wallet using standard application-layer web technology, for any kind of cryptographic credential, including full disclosure and selective disclosure public key certificates and anonymous credentials. Sections 12.4.2.1-3 have graphical descriptions of protocols for credential issuance and same-device as well as cross-device credential presentation. There is also a description of a protocol for presentation to an unattended IoT device, that can be used for providing authenticated physical access to a facility.

A Definition of Special Soundness Better Suited for Anonymous Credentials

December 1, 2024: updated to make corrections as shown. The proposed alternative definition of special soundness has not been changed, but its wording has been clarified.

I am co-authoring a book on the Foundations of Cryptographic Authentication with Sukhi Chuhan and Veronica Wojnas, where Chapter 3 is concerned with traditional credentials (as opposed to verifiable credentials or the mDL). Section 3.5 has an extensive treatment of zero knowledge, and in section 3.5.6 we use BBS signatures as an example of anonymous credentials. The chapter is still work in progress: the definition of special soundness proposed here is discussed in Section 3.5.6 but has not been retrofitted yet into sections 3.5.1-5.

As we were studying in detail the BBS paper we saw that the Sigma protocol defined in the paper for proving knowledge of a BBS signature is not special sound, contrary to what the paper claims. Then we thought of a modification to the definition of special soundness, proposed here, that would make it special sound. The proposed definition is more widely applicable than the current one, while still implying proof of knowledge.

Overview of ISO/IEC 18013-5: Innovations and Vulnerabilities in the mDL Standard

Two weeks ago I gave a talk about the mobile driver's license standard at IIW XXXVII, the 37th meeting of the Internet Identity Workshop, which took place as usual at the Computer History Museum in Mountain View.

One of the great things about IIW is that the agenda is created each day. That makes it possible for people interested in the same topic to merge their sessions. When I announced the session that I wanted to convene, Andrew Hughes "hijacked my session", as he said, to present a progress update on the series of ISO driving license standards, which was a perfect introduction to the details of part 5 of the series that I discussed in the second half of the session. Andrew is a member of the committee that wrote ISO/IEC 18013-5, and other committee members came to the combined session. The notes of the session, taken by Dan Bachenheimer, will eventually be in the Book of Proceedings, and can now be found here. My slides were based in part on an early draft of a chapter of a book on Foundations of Cryptographic Authentication that I am coauthoring with Sukhi Chuhan and Veronica Wojnas.

The mDL standard has many interesting innovations and privacy features.

One innovation, explained in slide 26, is the inclusion of self-asserted (device-signed) and certified (issuer-signed) data elements in the same credential. One wouldn't expect to find self-asserted claims in a driver's license, and Section 8.3.2.1.2.2 explicitly says that the structure containing the device-signed elements may be empty. But the mDL standard is in fact a general purpose standard for mobile credentials, which competes with verifiable credentials as discussed in this UL white paper.

Both kinds of data elements are retrieved in an encrypted session established by an ECDH key agreement where both parties use ephemeral key pairs and therefore neither party is authenticated. After the session has been established, the mobile device that carries the credential authenticates as a side-effect of signing the list of self-asserted data elements requested by the reader, whether or not it is empty!

Another innovation, explained in slide 28, is a clever use of an asymmetric key pair to produce a repudiable symmetric signature (an "ECDH-agreed MAC"), and a third innovation, explained in slide 29, is a clever adaptation of OpenID Connect to a use case where it would not seem to be applicable.

Privacy features include declaration by the relying party of the intent to retain some of the data elements, data minimization using selective disclosure, and proof of age without revealing the birthdate by means of age attestations.

Selective disclosure is implemented by means of cryptographic hashing, as explained in slide 11. Full unlinkability (protection against tracking by collusion of the issuer and the relying parties) is not provided, but selective disclosure based on hashing combined with age attestations provides the key benefits of data minimization and proof of age in a simpler way than anonymous credentials. Alternative implementations of selective disclosure, based on hash functions or proofs of knowledge, are described in slides 12-23.

On the other hand, the mDL standard also has privacy drawbacks and vulnerabilities to unauthorized access and man-in-the-middle attacks. The vulnerabilities are discussed in slides 30-39, with an example of a man-in-the-middle attack shown in slide 37. They are also discussed in Section 13.1.9 of the book chapter, along with proposed mitigations in the current or future versions of the standard. Privacy is discussed in slides 40-42 and in Section 13.1.10 of the book chapter.

The vulnerabilities and the privacy drawbacks have two independent root causes.

A Streamlined Process for Licensing a Cryptographic Authentication Patent

THE STREAMLINED PROCESS IS NO LONGER AVAILABLE. PLEASE WRITE TO US THROUGH THE CONTACT PAGE IF YOU WOULD LIKE TO LICENSE THE PATENT

Two-factor authentication with a fusion credential, demonstrated in this GitHub repository, overcomes the UX obstacles that are impeding large scale adoption of cryptographic authentication, by making it possible to add protection against man-in-the-middle phishing attacks, password reuse and backend breaches to a site where users authenticate with email and password, while keeping the same user experience, including the ability to log in on any browser, in any device.

But two-factor credential fusion makes use of an invention protected by a patent, and cryptography-related patents have historically delayed adoption of new technologies. To overcome this additional obstacle to the adoption of cryptographic authentication, I have now introduced a streamlined process for licensing the patent, which may be of independent interest.

The process uses a "DocuSign envelope", which is a type of workflow document that DocuSign routes by email to participants in a business process. The document is first routed to the patent holder, who applies a "DocuSign eSignature" to a license offer. It is then routed to the client, who adds a "DocuSign eSignature" accepting the offer and pays the license fee. It is finally routed back to the patent holder, who adds a "DocuSign eSignature" granting the license, after receiving the license fee. The completed document with all three eSignatures is sent by email to the parties, and kept by DocuSign in its own storage where it is available as evidence that the license has been granted.

Details of the process and examples of completed documents are available here.

A Demonstration of Two-Factor Cryptographic Authentication with a Familiar User Experience

I have just published a GitHub repository demonstrating a method of two-factor cryptographic authentication with a fusion credential, which provides the same user experience as traditional authentication with username and password, but with strong security. Developers with an Amazon AWS account can use a script provided in the repository to install the demo on an EC2 instance of their own. A live demo running on a Pomcor server is also available at demo.pomcor.com.

Security benefits of credential fusion

By analogy with biometric fusion, where two biometric modalities are combined in a manner that provides higher accuracy than if they were used separately, credential fusion combines authentication factors in a manner that provides stronger security than if they where used independently of each other.

In the demo, a password is fused with a cryptographic credential comprising a key pair extended with a secret salt. To authenticate, the frontend of the relying party (RP) hashes the user's password with the secret salt, signs a challenge with the private key, and sends the public key, the signature, and the salted password to the backend. The backend verifies the signature with the public key, then computes a hash of the salted password with the public key, called the fusion hash, and verifies it against a registered version of that hash. The public key and the secret salt are deleted after authentication, and only the fusion hash is stored in the backend.

If the password and the extended key pair were used separately, the password would provide protection against device theft and the key pair would provide protection against a man-in-the-middle (MITM) phishing attack where the phishing site would relay messages between the legitimate site and the user's browser and capture the session cookie after the user logs in. This would be prevented because the frontend of the phishing site would not have access to the private key, which is protected by the same origin policy of the web enforced by the browser. But the password would be still be vulnerable to phishing attacks, reuse at malicious sites, and backend breaches.

In the fusion credential, on the other hand, the password and the cryptographic credential protect each other as follows:

The password is protected against capture by a phishing site, because it is not sent in the clear.
The password is protected against reuse at malicious sites that use traditional authentication by username and password because the password is not sent in the clear, and at malicious sites that use a fusion credential as in the present authentication method, because different such sites would use different secret salts.
The password is protected against backend breaches because neither the password nor any value derived from the password that could be used in a dictionary attack are stored in the backend. In traditional authentication with username and password, by contrast, a salted password is stored in the password database, along with the salt itself. The salt prevents dictionary entries being tried against all salted passwords at once, but does not prevent dictionary entries being tried against the salted passwords one at a time. In the present authentication method the password is hashed with a salt, but like the private key, the salt is a secret that never leaves the user's browser, and neither the salted password nor the salt are stored in the backend.
The key pair is protected against cryptanalytic and postquantum attacks, because the public key is not stored in the backend. In traditional cryptograhic authentication with a key pair, the public key is registered with the RP and stored in the backend database. An attacker who breaches the backend might be able to derive the private key from the public key, either by exploiting a weakness of the signature cryptosystem, or, in a perhaps not so distant future, by using a quantum computer. But in the present authentication method, only the fusion hash is stored in the backend.

A Brief Overview of Cryptographic Authentication with a Discussion of Three Hot Topics

Updated August 8 2023

I have just revamped the cryptographic authentication page of the Pomcor site to reflect two major changes that are happening in internet identity and authentication:

It is now clear that traditional MFA is vulnerable to MITM phishing attacks and cryptographic authentication is the solution. But the technology that the industry has bet on as a replacement, FIDO authentication, faces user experience (UX) challenges that have been impeding adoption.
Governments are trying to issue digital credentials usable instead of physical credentials, and some are experimenting with verifiable credentials and self-sovereign identifiers. But a UL white paper has noted that the ISO/IEC 18013-5 standard, although entitled “Mobile driving licence (mDL) application”, can be used to define any kind of credential and is in direct competition with verifiable credentials. And the arguably most successful government app in the world, the Diia app of Ukraine, described in a presentation to the Canadian CIO Strategy Council shown in this YouTube video, uses neither verifiable credentials nor the ISO/IEC 18013-5 standard.

The revamped page includes a definition of the term cryptographic authentication that manages to encompass authentication with key pairs, public key certificates, anonymous credentials, symmetric key credentials and verifiable credentials. It also includes a classification of cryptographic credentials and authentication methods, a recapitulation of the benefits and challenges of cryptographic authentication, and a discussion of three ~~hot topics~~ unsettled issues:

How to use cryptographic authentication to actually provide effective protection against MITM phishing attacks.
How to let the user authenticate on multiple devices, and
How ~~to provide protection~~ to combine the cryptographic factor with additional factors for protection against theft of the device that carries the credential.

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.

See also:

Security benefits of credential fusion