Skip to content
This repository has been archived by the owner on Apr 16, 2022. It is now read-only.

U2F protocol

Dimitris Kanellis edited this page Aug 6, 2015 · 6 revisions

Technical overview

U2F is a challenge-response protocol extended with phishing and MitM protection, application-specific keys, device cloning detection and device attestation. There are two flows: registration and authentication.

Challenge-response

We start out with a simple challenge-response authentication flow, based on public-key cryptography. The U2F device has a private key kpriv and the RP is given the corresponding public key kpub. The key pair is generated in the device’s tamper-resistant execution environment, from where kpriv cannot leave.

Phishing and MitM protection

The concept is that the client compiles what it knows about the current HTTP connection (URI and TLS Channel ID). This information is then signed by the U2F device and sent to the RP, which verifies that the information is correct.

Additions to the authentication flow:

  • Origin (URI) — prevents phishing.
  • TLS Channel ID (optional) — prevents MitM.

Application-specific keys

Application-specific keys prevents relying parties from tracking devices between different user accounts. This means that an online service cannot know whether User1 and User2 shares the same device.

The U2F device generates a new key pair and key handle for each registration. The handle is stored by the RP and sent back to the device upon authentication. This way, the device knows which key to authenticate with (e.g. User1's key or User2's key).

Additions to the authentication flow:

  • Key generation on the device
  • Key handle, stored by the server together with kpub.
  • App ID, used for scoping a key handle.

Device cloning detection

Yubico’s U2F devices are tamper-resistant and kpriv cannot be read externally (at the very least not undetected). However, to provide cloning detection to U2F devices without tamper-resistant secure elements (e.g software implementations) Yubico adds an authentication counter. The concept is simple: The device increments the counter when authenticating, and the RP verifies that the counter is higher than last time.

Additions to the authentication flow:

  • A counter, sent from the device to the RP.

Device attestation

Attestation gives relying parties the possibility to verify token properties, such as token model. It is implemented via an attestation certificate, signed by the device vendor, that the device sends to the RP upon registration. Attestation does not affect the authentication flow.

Additions to the registration flow:

  • Attestation certificate

Key generation

A U2F device should generate a new ECC key pair for each service it registers with. When authenticating, the device should use the previously generated key for that service. This is trivial, but gets more complex as we add more requirements:

Initial requirements

Without any additional requirements, all we need is a key-value store on the device.

example.org => [Key for example.org]

acme.com => [Key for acme.com]

Multiple keys per service

We want to allow devices to store multiple keys per service. For example, a user might have more than one GMail accounts. To solve this, we associate each key with a key handle instead of with a service. During registration, the device sends a key handle which is kept by the service. When authenticating, the service sends the key handle back to the device.

KeyHandle[0x21AE9B] => [Key 1 for example.org]

KeyHandle[0xFBD308] => [Key 2 for example.org]

KeyHandle[0x18C77B] => [Key 1 for acme.com]

Limited storage on device

For a U2F device with lots of (tamper-resistant) storage, the above implementation would work. Unfortunately, this would make devices more expensive. However, since U2F does not specify how to store keys, we are free to come up with another solution — so Yubico did:

Key generation scheme used by Yubico U2F devices:

When a user registers one of Yubico’s U2F devices with a new service, the service provides an AppID (this is tied to the URL of the site and prevents phishing). The U2F device generates a nonce, N. We then take the AppID and the Nonce and run them through HMAC-SHA256 (a one-way keyed function), using a device-specific secret as the key. This device-specific key is generated on-chip at the time of manufacturing (just like the master key would be, if we were using regular key wrapping). The output of the hash function becomes the private key, and the nonce, together with a MAC, becomes our key handle. During authentication, the MAC helps to ensure that a key handle is only valid for the particular combination of device and AppID that it was created for during registration.