U2F Authenticatie

FEITIAN KEY TECHNICAL OVERVIEW

U2F is a challenge-response protocol enhanced with protection against phishing and Man-In-The-Middle attacks, application-specific keys, device cloning detection, and device attestation. There are two processes: registration and authentication.

1. Challenge-response

We start with a simple challenge-response authentication process based on public key cryptography. The U2F device has a private key (kpriv), and the RP (Relying Party) receives the corresponding public key (kpub). The key pair is generated in the tamper-resistant execution environment of the device, where kpriv cannot be extracted.

2. Phishing and MitM Protection

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

Additions to the authentication process:

Origin (URI) — Prevents phishing.
TLS Channel ID (optional) — Prevents Man-In-The-Middle (MitM) attacks.

3. Application-specific keys

Application-specific keys prevent trusted parties from tracking devices across different user accounts. This means that Example.com cannot know whether User1 and User2 share the same key. The U2F device generates a new key pair and key handle for each registration. The handle is stored by the RP (Relying Party) and sent back to the device during authentication. This way, the device knows which key to use for authentication (e.g., User1’s key or User2’s key). Additions to the authentication process:

Key Generation on the Device.
Key Handle, stored by the server along with kpub.
App ID, used to bound a key handle.

4. Device Cloning Detection

As previously mentioned, Feitian’s U2F devices are tamper-resistant, and kpriv cannot be read externally (at least not unnoticed). To provide cloning detection for U2F devices without tamper-resistant security elements (such as software implementations), we add an authentication counter. The concept is simple: The device increments the counter during authentication, and the RP (Relying Party) checks that the counter is higher than the previous value.

Additions to the authentication process:

A Counter, sent from the device to the RP.

5. Device Attestation

Attestation allows trusted parties to verify token properties, such as the token model. This is implemented through an attestation certificate, signed by the device manufacturer, which the device sends to the RP (Relying Party) during registration. Attestation does not affect the authentication procedure.

Additions to the registration process:

Attestation Certificate

U2F Key Generation

A U2F device must generate a new ECC key pair for each service with which it registers. During authentication, the device must use the previously generated key for that service. While this process is straightforward, it becomes more complex as additional requirements are introduced.