Cryptographic authentication using FIDO credentials promises to improve cybersecurity by preventing man-in-the-middle phishing attacks against traditional two-factor authentication. But the FIDO Alliance reported in a March 2022 white paper that FIDO authentication had not yet attained large-scale adoption in the consumer space, citing user experience challenges such as the burden of enrolling a new device to replace a lost or stolen device. Passkey syncing is now being implemented to eliminate the need to enroll a new device with the relying party, but it requires password-based, phishing-vulnerable enrollment with the platform provider. This paper proposes and shows how to implement two alternative user experiences that overcome these challenges. The first proposed UX lets the user log in on any browser, in any device, with on-the-fly device enrollment using an email verification link for authentication. The second UX frees the user from having to set up device locking, by using as a second factor a password submitted to the relying party, instead of a device-unlocking PIN or biometric. The password is protected against reuse at malicious sites and backend database breaches by being used together with an enhanced cryptographic credential in a joint authentication procedure. The same enhanced credential is replicated in all devices, without syncing, by regenerating it from a seed derived in an HSM from a master secret and the email address.

A cryptographic checksum is a small data item that is computed from a data structure and can be used to prevent undetected intentional modification by making it difficult for an adversary to construct a different data structure that has the same checksum. We broaden the concept of a checksum to include the concept of a data item intended to prevent certain modifications while tolerating others. An omissiontolerant checksum is computed from an encoding of a set and does not change when the encoding is modified to omit elements from the set, while making it difficult for an adversary to modify an original, i.e. unmodified, encoding in any other way without invalidating the checksum. We use the root label of a typed hash tree to implement an omissiontolerant checksum. A typed hash tree is a variation on a Merkle tree, where each node has a type and a label. The root label of a typed hash tree does not change when a subtree is pruned from the tree. The same is true for a Merkle tree, but in a Merkle tree this a “bug” to be mitigated, while in a typed hash tree it is a “feature” that makes it possible to use the label of the root node as an omission-tolerant checksum for a set of key-value pairs. To do so, we encode each key-value pair as the type and label of a leaf node of an incomplete typed hash tree without internalnode labels, then serialize the tree to obtain a bit-string encoding of the set. To compute the checksum on the encoding we deserialize the bitstring, compute the missing internal nodes, and output the label of the root node as the checksum. We use Boneh and Shoup’s system parameterization and attack game methodology to prove that, given an original encoding of a set of keyvalue pairs, an efficient adversary has a negligible probability of producing a modified encoding that represents a set of key-value pairs other than a subset of the given one and that has the same checksum.

The 3-D Secure protocol, introduced 20 years ago, aims at reducing online credit card fraud by authenticating the cardholder. Version 2 of the protocol, not yet deployed, addresses usability problems that have hindered the deployment of version 1 by introducing a frictionless flow for low risk transactions. But the frictionless flow does not authenticate the cardholder. Instead, it requires the merchant to send information to the issuer through a back channel, potentially violating the cardholder's privacy. The paper analyzes the usability, privacy and security provided by 3-D Secure 2 and proposes an alternative protocol, simpler and less expensive to implement, where the cardholder is authenticated with a cryptographic credential stored in the cardholder's browser with zero friction. The scheme can take advantage of a native bank app in the cardholder's device to further authenticate the cardholder by fingerprint scanning or face recognition as made available by the device, and can be used for credit card purchases made on the merchant's web site or on a merchant app.

The 3-D Secure protocol, introduced by Visa in 1999 and adopted by other credit card networks, provides security for online credit card transactions by redirecting the cardholder’s browser to the web site of the issuing bank, where the cardholder authenticates with an ordinary password or a one-time password. This however creates friction that may cause transaction abandonment. Over the last few years the credit card networks have been developing 3-D Secure 2, where the issuing bank assesses fraud risk based on information received from the merchant through a back channel and waives authentication for low-risk transactions. In previous work we have shown that 3-D Secure 2 has serious privacy and usability issues and proposed an alternative protocol that provides strong security without friction for all transactions by cryptographically authenticating the cardholder. Here we show that 3-D Secure 2 has fundamental security flaws that may allow the merchant to impersonate the cardholder, when used in a configuration where the cardholder uses a native app rather than a browser to access the merchant’s site. These are not minor flaws that can be fixed by minor changes; fixing them would require a different approach to cardholder authentication in that

This is the first of a series of papers describing the results of a project whose goal was to identify five remote identity proofing solutions that can be used as alternatives to knowledge-based verification. This paper describes the first solution, which makes use of two new concepts that are described in detail in the paper. The first new concept is that of a typed hash tree, which can be used to represent a collection of key-value pairs and whose root label provides an omissiontolerant cryptographic checksum of the collection. The second concept is that of a rich credential, which is issued by an identity source to a subject and allows the subject to remotely present three verification factors to a verifier with whom the subject may have no prior relationship, including something that the user has (a private key), something that the user knows (a password), and something that the user “is” (one or more biometric features). A rich credential includes a typed hash tree, whose omission tolerance is used in the rich credential to provide selective disclosure of attributes and selective presentation of verification factors. In the first solution, a DMV issues a rich credential containing a facial image of the subject, which can also serve as the digital source of the printed photograph on a physical driver’s license issued to the subject. The verifier performs face recognition with presentation attack detection by matching the facial image against the subject’s face shown in an audio-visual stream of the subject reading prompted text, verifying the synchrony between the audio and video channel of the stream by tracking the subject’s lips in the video stream and matching distinguishable visemes to phonemes in the audio stream.

In the classical design pattern for secure channel protocols, there is a first phase where the endpoints establish a shared secret and one or both endpoints authenticate by presenting a certificate and demonstrating knowledge of the associated private key; and a second phase where application data traffic between the endpoints is protected using symmetric keys for encryption and authentication derived from the shared secret. This classical pattern emerged in the nineties, when most secure channels were intended for human-to-machine (H2M) communications and the latency caused by roundtrips and transmission of bulky certificate chains resulted in no more than inconvenience to the human. In machine-to-machine (M2M) communication, on the other hand, excessive latency may be unacceptable for safety-critical and other applications. We describe a range of alternative protocol design patterns that use identity-based encryption to eliminate roundtrips and certificate transmission. These patterns can be used in the design of new secure channel protocols or retrofitted into existing protocols.

Two methods are used to protect data stored in a computer device in case the device is lost or stolen. One is to store the data in tamper resistant storage, the other is to encrypt the data. Tamper resistance is rarely used in ordinary computing devices such as smart phones, tablets, laptops or desktops, presumably because it increases the cost of a device. An exception is the use of an NFC secure element within a smart phone to store credit card data used in some payment applications. However the tamper resistance strength of such secure elements is unspecified, and, to our knowledge, none has been certified by NIST as tamper resistant (FIPS 140-2 physical level 3 or 4) [1]. Encryption is used much more frequently. Corporate laptops are often protected with full-disk encryption combined with pre-boot authentication. Since iOS 4, data stored in the iPhone and other iOS devices is encrypted under a hierarchy of keys derived in part from a PIN or a password that the user enters to unlock the phone. The simplest way of encrypting data at rest is to use a symmetric key derived from a passcode, such as a PIN, a password, or a passphrase. But an attacker who gains physical access to the device and can extract the encrypted data from the device can mount an offline attack, trying passcodes until one is found that produces a key which successfully decrypts the data. Withstanding an offline passcode-guessing attack requires a high-entropy passcode. Requiring the user to enter a high-entropy passcode to boot a laptop may be reasonable, but requiring a user to enter one each time he or she unlocks a smart phone is not practical. It is difficult to type a long passcode on the tiny keyboard of a smart phone, and the difficulty is compounded by the need to switch keyboards to enter different classes of characters, such as letters, digits and punctuation. In iOS, Apple addressed this difficulty by using a hardware key in addition to the passcode to derive the key hierarchy and protect the passcode. The hardware key is hardcoded in a hardware encryption chip and cannot be extracted by a casual attacker. However, various ways have been found of running custom code on an iOS device, and custom code can make use of the hardware key even though it cannot extract it. By making use of the hardware key it is possible to mount an offline attack against the passcode using the processor in the phone. The processor is relatively

NIST has released drafts of two documents containing guidelines for issuing credentials to federal employees or contractors upon presentation of a PIV/CAC card and storing them on mobile devices, such credentials being known as derived credentials. The guidelines permit the storage of credentials in a software token, i.e. a software cryptographic module, protected by an activation passcode with 20 bits of entropy. While mere encryption under a key derived from such a passcode would not provide sucient security, we propose a method of achieving strong security with such a passcode, by wrapping the credentials using a high-entropy key-wrapping key (KWK), storing the KWK in a secure back-end, and retrieving the KWK by authenticating to the backend with a device credential regenerated from the passcode and a protocredential, in such a way that an adversary who captures the mobile device while the software token is inactive is not able to mount an oine guessing attack against the passcode. We suggest that the use of this method could serve as a compensating control to justify the storage of derived credentials in cryptographic modules that are not removable from the device and do not provide sucient tamper resistance. We describe the use of the compensating control to increase the security provided by a software token, a TEE token (i.e. a cryptographic module embedded in a Trusted Execution Environment), and a traditional hardware token. We describe an example of a derived credentials architecture where the KWK is stored in a device record within a Mobile Device Management (MDM) database.

The current transport layer security protocols, TLS and DTLS, have serious security, privacy and usability shortcomings that cannot be practically fixed by incremental upgrades. We argue that the current awareness of the breakdown of privacy and security on the Internet provides an opportunity to redesign transport layer security from scratch. We list several ingredients that could by used in such a redesign, including the use of multi-root, hierarchical identity-based encryption for key exchange, and the dissociation of client authentication from the key exchange to allow for an open-ended variety of client credentials and for the implementation of login sessions without cookies. Successful deployment of the redesigned protocols would substantially increase security and privacy IP networks.

Executive Summary User authentication on the Internet is widely acknowledged to be broken. Ordinary passwords have many vulnerabilities. Third-party login with a password adds a privacy problem while arguably making the security problem worse. Security questions are an invasion of privacy, and their answers can be easily discovered online. Onetime passwords generated by a soft or hard token or communicated via email or text or voice messaging add only limited security at the cost of substantial user inconvenience. Cryptographic or biometric authentication is only used in special cases, such as employee or contractor authentication to information systems in US government agencies. Mobile devices make the authentication problem worse. It is difficult to enter a high-entropy password on the touchscreen keyboard of a smart phone, and characters are echoed by the keyboard as they are typed. It is also difficult to protect the private key component of a cryptographic key pair against an adversary who captures the device because data protection mechanisms currently available on mobile devices are not effective. But at the same time mobile devices have brought us a new app-centric computing paradigm, in which both native and web-based applications can communicate with each other within the device, paving the way for innovation in the area of authentication architecture. All of this has led us to rethink user authentication. We have identified a useful distinction between closed-loop and open-loop authentication, and defined the concept of a protocredential. In closed-loop authentication, the party that issues or registers a credential is the same party that verifies possession of the credential at authentication time, whereas in open-loop authentication user attributes are asserted by a party that is not directly involved in the authentication process. Today, most authentication on the web is closedloop, including traditional two-party authentication with username and password, and third-party login where a relying party redirects the browser to an identity provider who authenticates the user and redirects the browser back to the relying party, conveying the user’s identity. A protocredential consists of cryptographic parameters stored in the user’s computing device, at least one of them secret, that are used to regenerate an uncertified

The development of a successful Identity Ecosystem requires an interdisciplinary approach, with close collaboration between professionals who specialize in the five dimensions of Identity: Law, Business, Policy, Technology, and Society. Unfortunately one of those dimensions, authentication technology, has become extremely complex and difficult to understand for experts in the other dimensions. In fact, several silos have emerged within authentication technology, and technologists immersed in one silo often find it difficult to understand the work being done in other silos. This is a serious obstacle to the development of an Identity Ecosystem. To overcome this obstacle, it is necessary to develop a conceptual framework that makes it possible to describe authentication technologies and their practical implications in terms that are both accurate and comprehensible to non-specialists, by abstracting away operational concepts from the technical details. As a step in that direction we survey and classify a wide range of technologies, and delineate their privacy postures.

2 Issues with the Specification 2 2.1 Issues Related to the Token Cryptogram . . . . . . . . . . . . . . . . . . . . 2 2.2 Issuing Bank as Token Service Provider . . . . . . . . . . . . . . . . . . . . . 4 2.3 Underspecification of the E-Commerce Use Case . . . . . . . . . . . . . . . . 5 2.4 Inadequacy of the Card-on-File E-Commerce Use Case . . . . . . . . . . . . 5 2.5 Impossibility of the Scan at Point of Sale Use Case . . . . . . . . . . . . . . 6 2.6 No Mention of Offline Data Authentication . . . . . . . . . . . . . . . . . . . 6

The requirement of a Government-wide means of authenticating federal employees and contractors stated by HSPD-12 is traditionally met by PIV smartcards in civilian agencies and CAC smartcards in the Department of Defense. But there are substantial obstacles to using a smartcard for authentication when an information system is accessed via a mobile device. NIST is investigating alternative authentication methods that rely on derived credentials not contained in smartcards. In this paper we propose three techniques that can facilitate the implementation, deployment and use of derived credentials. The rst technique eliminates the administrative cost that would be incurred by having to issue certicates to the mobile devices owned by

Executive Summary Authentication methods used today on mobile devices are both inconvenient and insecure. Ordinary passwords are difficult to type on small touch-screen displays that require switching keyboards for entering digits or punctuation. They provide even less security on mobile devices than on desktops or laptops: a typing-feedback feature prominently displays each character after it is typed, eliminating the security provided by password input boxes that display dots in lieu of characters; and users are motivated to choose shorter and simpler passwords, which have less entropy. One-time passwords are often used on mobile devices due to the lack of security of ordinary passwords. Authenticating with a one-time password requires: entering a PIN or a password to generate or request the one-time password; obtaining the onetime password from a hard token, a soft token, a text message, or an email message; and entering the one-time password. This is a very cumbersome procedure. One-time passwords afford only relative security because they can be observed or intercepted and they remain valid for several minutes. We propose one-, twoand three-factor authentication methods for mobile devices that provide strong security and are more convenient to use than one-time or ordinary passwords. They are suitable both for enterprise and consumer use. The proposed authentication methods are based on public key cryptography, but they are easy to implement and deploy. They are easy to implement because all cryptography is encapsulated in black boxes, so that developers do not have to program any cryptographic operations. They are easy to deploy because they avoid the use of certificates and do not require a public-key infrastructure. In our one-factor authentication method the device uses a key-pair credential, and the user does not have to provide any input. The device authenticates by demonstrating knowledge of the private key. A hash of the associated public key is stored in a device record, which is linked to a user record in an enterprise directory or user database. If the device is lost or stolen, the key-pair credential can be revoked by removing the device record from the database. In our twoand three-factor authentication methods, the device also uses a keypair credential, but the key pair is not stored in the device; it is regenerated before use from the additional authentication factor(s).

This white paper presents a method for protecting a Web application against online password-guessing attacks. A user logs in with three credentials: the name of the application instance, a user ID, and a password, where the instance name is a secret known only to the instance users, the user ID is a secret kwnon only to the instance administrators, and the password is a secret known only to the user. After five consecutive bad guesses agaisnt a password, the user is locked out and the password must be reset; furthermore, after thirty bad guesses (not including five consecutive ones), the user is forced to change her password. A denial-of-service attack that repeatedly locks out one user is thwarted by changing the user ID of the victim, while such an attack against multiple users is thwarted by changing the instance name. Changing the instance name can also be used to preempt attacks by exusers. This method, together with a technique for securely resetting a password, has been used in the Pomcor file-repository application to provide the convenience of password-based authentication without compromising security.