Cryptographic Authentication

Latest update on August 10, 2023

Major changes are happening in digital identity and cryptographic authentication:

On the desktop, it is clear that traditional MFA is vulnerable to MITM phishing attacks and cryptographic authentication is the solution; but the technology that the industry is betting on as a replacement, FIDO authentication, faces user experience (UX) challenges that are impeding adoption.

On mobile,

  • local and national governments all over the world are trying to issue digital credentials usable instead of physical credentials, and some are experimenting with verifiable credentials and self-sovereign identity (SSI);
  • the ISO/IEC 18013-5 mDL standard promises to provide world-wide interoperability for mobile driver licenses; and a UL white paper has noted that the standard can be used to define other kinds of credentials besides driver licenses; and
  • a very successful government app, 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.

Across desktop and mobile, the ISO/IEC 18013-7 standard currently under development will specify how to use the mDL and other credentials defined according to 18013-5 for authentication over the internet; later, the ISO/IEC 23220 series, of which 23220-1 has already been published, will more generally specify “Building blocks for identity management via mobile devices”.

This page provides a brief overview of cryptographic authentication, a discussion of unsettled issues in the area, and an introduction to fusion credentials.


An earlier version of this page defined cryptographic authentication as “identifying a user by proof of possession of the private key component of a cryptographic credential”. That covers authentication with a key pair and authentication with a public key certificate. But it does not cover other kinds of cryptographic credentials, including anonymous credentials, symmetric key credentials, or verifiable credentials.

Cryptographic authentication could more broadly be defined as

authentication by proof of knowledge of a secret that is associated with, or part of, a cryptographic credential .

In the case of a key pair or a public key certificate, the secret is the private key. In the case of an anonymous credential based on a Camenisch-Lysyanskaya signature, the secret is the first attribute, often written m1 and called the master secret, which is not revealed to the issuer or to the verifier. In the case of a verifiable credential, user attributes are bound to a decentralized identifier (DID), which may be registered by a transaction on a blockchain or distributed ledger; in that case the secret is the private key used to sign the transaction. The DID may also be of type did:key and consist of an encoding of a public key; in that case the secret is the associated private key.


Cryptographic credentials and authentication methods can be classified according to three criteria:

  1. The number of parties involved in the issuance, presentation and verification of the credential, either 2 or 3. A two-party (2P) credential is issued by the same relying party (RP) that verifies it and typically used for returning user authentication, while a three-party (3P) credential is issued by a third party. This is a critical distinction because, as explained below, 2P and 3P credentials require different countermeasures for protection against MITM phishing attacks.

    Key pairs are the most common kind of 2P credentials and public key certificates the most common kind of 3P credentials; but a relying party may issue a certificate as a 2P credential to be later presented to itself, with the purpose of obtaining user attributes from the certificate when the user logs in instead of looking them up in its database. The WebAuthn specification cites the storage of such certificates as a motivation for the largeBlob extension.

    Verifiable credentials and ISO/IEC 18013-5 credentials are 3P credentials. In Idemix, an anonymous credential is a 3P credential, while a pseudonym (implemented as a randomized commitment to the master secret of the anoynmous credential) is a 2P credential.

  2. The kind of user agent that presents the credential, either a browser or a wallet, the term “wallet” being used here synonymously with “native app”.

    FIDO credentials are browser-based and ISO/IEC credentials are are wallet-based. The example in Section 3.4 of the verifiable credentials data model uses a wallet as user agent. Anonymous credentials are a technology-independent cryptographic construct that can be used with either kind of user agent.

  3. The kind of device where the user agent is running, either mobile (phone or tablet) or desktop (including laptops).

    Since browsers run on mobile devices, and there are wallets on desktops, this distinction is strictly speaking orthogonal to the browser-based vs wallet-based distinction. But in first approximation it is safe to think of wallet-based credentials as mobile credentials, and browser-based credentials as desktop credentials.

Benefits and challenges of cryptographic authentication

Cryptographic authentication provides two benefits that are essential today:

  • It provides protection against MITM phishing attacks, which traditional MFA fails to provide. See the discussion in Issue 1.
  • It may free the user from having to enter a password, except for a PIN that has to be entered only as a fallback for biometric authentication. This is not essential for desktop authentication, but is an enabler of mobile authentication due to the difficulty of entering a complex password on the screen keyboard of a mobile device. See the discussion in Issue 3.

But it also faces two challenges:

  • A cryptographic credential is expected to be bound to hardware. This creates a challenge if the user has multiple devices, or has a single device and loses it, as discussed in Issue 2.
  • The cryptographic factor should be combined with one or more additional factors for protection against theft of the device that contains the cryptographic credential. See the discussion in Issue 3.

Unsettled issues in cryptographic authentication

Issue 1: How to provide resistance to MITM phishing attacks

There is now consensus that multifactor authentication with a password and a verification code, widely viewed as the cure for the vulnerabilities of one-factor authentication with a password, is itself vulnerable to man-in-the-middle phishing attacks. A phishing attacker who lures a victim into a fake site may forward the password from the fake site to the legitimate site, then do the same with the verification code, without having to capture and later use either. It can then capture the login cookie sent by the legitimate site to the victim’s browser and use it repeatedly to access the legitimate site.

Cryptographic authentication can protect against such an attack, but protection is not provided by the mere fact of using a cryptography credential. It may require specific countermeasures in specific use cases.

For example, in browser-based 2P authentication, the RP JavaScript frontend creates a key pair in the user’s browser, either in a FIDO authenticator or in localStorage, and registers the public key with the backend. Later, the frontend authenticates by sending a signature on a challenge computed with the private key to the backend. A MITM attack is prevented because the same-origin policy prevents the attacker from using the private key. No countermeasure is needed in this case.

But the 2P browser-based authentication can be modified to provide 3P authentication, by having the issuer create a public key certificate and its associated private key in the browser (again either in a FIDO authenticator or in localStorage) and registering a Service Worker with the browser. Later, to authenticate, the RP redirects a login request to the issuer conveying a challenge and a callback URL, and the redirected request if intercepted by the Servicer Worker. The JavaScript frontend of the issuer signs the challenge with the private key and sends the signature to the callback URL. This 3P authentication method, similar in some respects to the 2P method, is vulnerable to a MITM attack because a man in the middle between the browser and the RP does not have to sign the challenge. A countermeasure against this attack is to include the callback URL along with the challenge in the string that is signed.

For another example, verifiable credentials are vulnerable to MITM phishing attacks if no precautions are taken, as recognized in Section 8.4 of the data model. Two countermeasures are suggested by the specification.

One suggestion is the following statement in the same Section 8.4: Approaches such as token binding [RFC8471], which ties the request for a verifiable presentation to the response, can secure the protocol. The countermeasure that this suggests is a clever use of the token binding protocol for a purpose different from the one for which it was designed. (It was designed to prevent a stolen cookie from being used on a different TLS connection.) But the one-sentence suggestion does not provide enough information to implement the countermeasure.

The other suggestion is a comment in Example 2, stating that ‘challenge’ and ‘domain’ protect agaisnt replay attacks. It is not clear why a replay attack would be of concern when transmitting a presentation, so perhaps “replay attack” really means “man-in-the-middle attack”. In any case, the suggestion can lead to a MITM countermeasure if the “domain” in the example identifies the destination where the presentation is transmitted, which would be the destination of the attacker. But the domain in the example is a seemingly random string and neither the string nor the word “domain” occur anywhere else in the data model specification.

Issue 2: Authentication on multiple devices

A FIDO platform authenticator is a cryptographic module, and the concept of a cryptographic module calls for cryptographic secrets such as a private key to be generated in the module, be used within the module, and never leave the module unencrypted. This poses a problem if the user has multiple devices or has a single device and loses it.

A white paper published by the FIDO Alliance in March of 2022 blamed this problem for lack of adoption and proposed as a solution to synchronize FIDO credentials across platform authenticators in devices with operating systems provided by the same OS vendor. Apple, Google and Microsoft have implemented this solution, and are referring to synchronized key pair credentials as passkeys. But synchronization degrades security and user experience by requiring users to authenticate to the OS vendor with the same cumbersome and insecure MFA that FIDO purports to avoid.

As an alternative to synchronization, we have proposed and demonstrated two techniques that allow the user to authenticate with a cryptographic credential on any browser in any device by installing a credential on the fly if one is not found in the browser. In one technique a different credential is generated in each browser from pseudo-random bits derived from true random sources, while in the other the same credential is generated in all browsers from pseudo-random bits derived from a seed, itself derived from a master secret and the user’s email address. In both techniques, the user is identified by her email address and logs in by entering the address into a login form. If no credential is available, a link containing an email address verification code is sent to the user, and opening the link in a browser causes a key pair to be installed in that browser. The Demonstrations page has links to demos available on GitHub that use both techniques.

Issue 3: Combination of the cryptographic factor with additional factors for protection against device theft

Cryptographic authentication is authentication with a possession factor, and as such is vulnerable to theft of the device containing the credential if the possession factor is used by itself.

Many mobile devices come with effective protections against theft: the device may become locked when inactive, data may be encrypted when the device is locked, and a device location service may be provided. Similar protections are available for desktop devices, but users may not set them up, because a desktop device stays home or at the office most of the time. In particular, most Windows users do not set up Windows Hello. Therefore the cryptographic factor should be combined with one or more additional factors for protection against device theft in browser-based authentication, which is most often desktop authentication.

FIDO adds factors to key pair authentication by locking the credential and requiring the user to unlock it with the same mechanism used to unlock the device, i.e. Windows Hello in the case of a Windows device. This means that most Windows users are not able to use FIDO authentication because they have not set up Windows Hello.

An alternative to requiring the cryptographic factor to be unlocked with the additional factors is to fuse the additional factors with the cryptographic factor, obtaining what we call a fusion credential.

Fusion credentials

By analogy with the concept of biometric fusion, where two biometric modalities are combined in a manner that provides higher accuracy than if they were used separately, we use the term fusion credential to refer to a combination of authentication factors in a manner that provides stronger security than if the factors were used simultaneously, but independently of each other.

Although the “fusion” terminology is new, many authentication methods that fuse a cryptographic factor with a password and/or a biometric have been proposed, used and/or patented over the last two decades:

A fusion credential demonstration on GitHub

An example of cryptographic authentication with a fusion credential can be found in this GitHub repository. As explained in more detail in this blog post, a password is fused with an extended key pair in a way that provides the familiar user experience of authentication with email and password, while achieving phishing resistance, protecting the password against reuse at malicious sites and backend database breaches, and protecting the cryptographic credential against cryptanalytic and postquantum attacks.