Cryptographic Authentication for Access to Online Resources

Use Case Metadata

Title

Cryptographic Authorization for Access to Online Resources (alternate title suggested by privacy committee).

Status

Use Case Lifecycle Status

Contributed	Working Draft	Committee Review	Compilation	Approval	Publication
This use case has been approved in version 1.2. This page may have been updated since the 1.2 document was approved.

Use Case AHG Review Status

The Use Case AHG performed a review of this use case on 2013-07-31.

Use Case Category

Authentication

Contributor

Bob Pinheiro (nstic@bobpinheiro.com)

Use Case Content

Use Case Description

This use case outlines two approaches for providing cryptographic authentication to online resources. In both approaches, the need for shared secrets between users and relying parties, such as passwords or answers to challenge questions, is eliminated.

One of the NSTIC Guiding Principles is that identity solutions should be secure and resilient. Authentication methods that rely on shared secrets, such as passwords, are well known to be less secure than methods based on public key cryptography, for example. NSTIC-compliant identity solutions for high assurance applications, such as access to high value online resources, should therefore eliminate reliance on weak authentication methods based on shared secrets. The NSTIC derived requirements compiled by the National Program Office also specify that identity credentials should be resistant to theft, tampering, counterfeiting, and exploitation. Although no single authentication technology has a monopoly on these properties, public key cryptography arguably provides better security than most, if not all, current alternatives. In addition, recent advances have the potential to make public key crypto usable for consumer applications. Although a Use Case does not need to focus on any specific technologies, a goal of this Use Case is to help ensure that an NSTIC-compliant identity ecosystem will incorporate strong authentication methods that have previously not been usable by consumers.

Actors

• User: An individual who needs to access an online resource.
• Token: Something that a user possesses and controls that is used to authenticate the user for access to a protected resource such as a financial account.
• Public / Private Key Pair: a public cryptographic key and its corresponding private key. The private key resides on the user’s computing device (or external USB device or smartcard) and can be locked with a PIN or password. The private key acts as a token.
• Relying Party: a website that must authenticate a user for access to a service or resource provided by the relying party.
• Device: a computing device such as a personal computer, laptop computer, tablet computer, or mobile phone that is able to store and manipulate cryptographic keys. It could possibly also include USB dongles that include processing capabilities, as well as smartcards.
• Third Party: a third party entity that can provision private / public key pairs on a user’s device, and can provide an additional layer of security by acting to sign an authentication request independently of the user.

Goals / User Stories

The goal of this use case is to outline two approaches for providing cryptographic authentication to online resources. In both approaches, the need for shared secrets between users and relying parties, such as passwords or answers to challenge questions, is eliminated. The term “cryptographic authentication” here means that a relying party is able to authenticate a user seeking access to an online resource by means of an authentication protocol that verifies that the user controls a cryptographic private key. It is assumed that the corresponding public key has been previously bound to the online resource.

Neither of these two approaches depends on the use of client-side certificates issued by a certificate authority that has vetted the user’s identity prior to issuing the certificate. Instead, it is assumed that the service provider / relying party has independently determined that a particular user is entitled to access an online resource, and is able to bind a public cryptographic key to that resource.

In one approach, the relying party directly provisions a private / public key pair on the user’s device, uploads the public key to the relying party site, and binds the public key to the online resource. Ongoing authentication for access to the resource then depends on a user being able to demonstrate control of the associated private key.

An alternate approach assumes the existence of a third party entity that provisions public / private key pairs on the user’s device, and provides an additional measure of security by means of an authentication protocol that requires the third party to demonstrate control of an additional private key.

Traditional PKI and client-side certificates can also achieve the goal of providing strong cryptographic authentication. But PKI and client-side certificates have been cumbersome and costly to deploy and maintain, and are not widely used, especially for authentication of consumers. This use case proposes an alternative to traditional PKI in which public / private key pairs are provisioned directly on user devices without involvement of client-side certificates or certificate authorities.

Assumptions

Strong authentication for access to online resources is assumed to require two-factor authentication, where the two factors are “something you know” and “something you have.”

The “something you have” factor consists of a computing device, such as a desktop or laptop PC, tablet computer or smartphone, that is used to access a protected online resource. It could possibly also include a separate authentication device that is able to store and manipulate private keys. To transform a computing device into a secure authentication token, a public / private cryptographic key pair will be provisioned on the user’s device. The public key will be uploaded to the relying party site, and strong authentication will depend on the user’s ability to demonstrate control of the private key.

A private key on the user’s computing device may be “locked”, and if so is usable for authentication only if it can be unlocked with a PIN, password, or biometric. This PIN or password is the “something you know” authentication factor, while a biometric is a "something you are" authentication factor. However, none of these is a shared secret between the user and the relying party because neither the PIN, password, or biometric information leaves the user’s device.

In the case where the relying party directly provisions a public / private key pair on the user’s device, an appropriate application will exist on the user’s device to manage multiple private keys that are used for authentication to multiple websites. This application may consist of a browser plug-in or extension, and must provide a user interface that makes it easy for users to cryptographically authenticate to different relying party sites. Each user device will be provisioned with its own public/private key pair specific to that device, and each relying party site will need to maintain public keys for each of the user’s devices.

A mechanism will exist for users to add new devices and to provision those devices with appropriate public / private key pairs so that those devices can be used for authentication to protected resources at a relying party site. [A similar mechanism can exist to remove a device.]

In the case where a third party is used to provision public / private key pairs on the user’s device(s), an additional private key maintained by the third party is used in the authentication protocol. An advantage of this approach is that if a device is lost, the user can instruct the third party not to sign (with its private key) an access request originating from the lost device. On the other hand, involvement by a third party introduces the possibility that the third party may be unavailable during the authentication process, rendering the user unable to authenticate to the relying party site.

User’s computing devices must be equipped with an application that provides users with the ability to easily manage multiple crypto private keys for authentication to multiple websites. [moved from Requirements section during application of updated template]

Process Flow

Enrollment

When a new user is enrolled at a relying party site, the site instructs the user’s device (browser) to generate a public /private key pair. The device-specific public key is uploaded to the relying party site, along with some type of user and/or device identifier. This public key is bound to the user’s protected resource at that site.

Alternately, when a third party is involved, the device public key along with the public key of the third party are both uploaded to the relying party site, and bound to the protected resource.

Authentication for Access to a Protected Resource

The relying party site (or the app on the user’s device) will display a button for the user to click for access. The relying party site identifies the user and/or device on the basis of some type of user / device identifier, and sends a challenge to the user’s device. The user clicks on the button, and is prompted for a PIN or password to unlock the corresponding private key on the user’s device (if the key was previously locked). Once unlocked, the private key is used to digitally sign a response, which is returned to the relying party. The relying party verifies the digital signature with the corresponding public key. If verified, the user is allowed to access the protected resource.

Alternately, if a third party is used, the response to the relying party’s challenge is signed by the private key on the user’s device, and is then forwarded to the third party. After authenticating the device using the device's public key, the third party signs the response with the third party’s private key, and then returns it to the user. The user forwards the doubly-signed response to the relying party. The relying party verifies the two digital signatures with the public keys corresponding to the user’s device and the third party.

Authentication of an Individual Transaction

When a user initiates a specific type of transaction, such as moving money out of a financial account, the user’s device may sign the transaction with the device’s private key. The relying party site verifies the signature with device’s public key. Alternately, the third party private key is also used to sign the transaction.

Adding a New Device

A user will be able to provision new public / private key pairs on a new device by leveraging the capabilities of an existing device that has already been provisioned with key pairs for multiple relying party sites. One possible way to do this may be for the user to activate a process on the existing device that causes an email to be sent to the user, which contains a link that must be activated on the new device. Once activated, this link generates a private / public key pair on the device. For added security, the user may be required to enter a one-time code sent to the user’s out-of-band mobile phone.

Success Scenario

Users are successfully provisioned with public / private key pairs on each of their computing devices, for strong authentication to relying party websites.

Users are able to successfully authenticate to each relying party website where they have protected resources, using strong cryptographic authentication.

Users can successfully add new devices for strong authentication to their protected resources, and remove them if necessary.

Error Conditions

Relying party sites do not support this use case.

There are difficulties or errors when provisioning the necessary public/private key pairs on user’s devices.

Users cannot successfully add a new device (or remove an existing device) for access to a relying party site.

If a third party is used for added security, the third party may be unavailable to sign a response or transaction with its private key when needed.

References and Citations

Two other consumer-class use cases rely on public key cryptography for user authentication. These are:
IRS Identity Theft Use Case, and Delegated Authentication for User Managed Access Use Case.

In addition, other initiatives and commercial products exist that are geared to making public key cryptography usable for consumer-class applications. These include the FIDO Alliance's Universal Second Factor (U2F)initiative, as well as OneID.

NSTIC Guiding Principles Considerations

Privacy Considerations

Privacy issues may arise if the Third Party has associated knowledge of the user’s activity or if the Relying Party is able to associate the user with a given Third Party. Key management should be mechanized so that unintended trackability and MITM attacks can be avoided.