Windows 10 Update: Sunsetting U2F tunnel transport for Ledger devices

05/17/2019 | Blog posts

Ledger devices have been using the U2F protocol for easy communication within a web browser since 2016, allowing it to be the first hardware wallet to integrate natively with MyEtherWallet (

The U2F protocol creates a cryptographically secure second factor mechanism as follows :

* During the registration phase, the client generates a keypair over the prime256v1 curve and exchanges the public key, an encrypted version of the private key (called a key handle), and an attestation demonstrating that the private key was generated on a trusted device to the server

* During the authentication phase, the server generates a random value then sends this challenge along with the key handle to the client. The client retrieves the private key from the key handle, uses it to sign the challenge, and return the challenge signature. The server then validates the challenge signature and authenticates the client.

When communicating with a Ledger device, an authentication request is sent with the message to be executed encapsulated as a fake key handle. The application will execute this message, then answer with the response encapsulated as a fake signature.

This could create several privacy and user experience problems :

* Any web page can communicate with a Ledger device without getting a confirmation from the user first. While not generating security issue as all critical operations will require a user confirmation on the device itself, this can lead to privacy issues.

* The U2F protocol doesn’t expect the signing device to take a long time to generate the signature, which isn’t guaranteed by our use case where the user has arbitrary data to review on screen.

Recently (since Chrome 73), U2F timeouts have been enforced more aggressively which required a first update to our U2F implementation (and all Ledger device applications using the U2F tunnel) to work around this requirement. The Windows 10 May 2019 update will also include a native U2F stack, which breaks the current user experience by displaying a long modal pop up in front of the browser when a U2F operation is performed.

Considering those changes significantly altering the user experience and the availability of WebUSB as the standard method for interacting with a USB device, we plan to sunset the U2F transport and migrate to WebUSB to natively communicate with our devices from a (Chromium based, so far) web browser, first for all applications, then for the application dashboard.

What does it mean for our users

All users will need to update the device to the latest firmware and applications versions if using a third party client based on a web browser.

* If you’re running Mac OS or Windows, you don’t have to do anything else. Windows user experience during firmware updates should also be significantly improved with the upcoming one.

* If you’re running Linux, you’ll need to update your udev rules to recognize the new USB product IDs that will be deployed.

What does it mean for third party web developers

Third party web developers will need to use the hw-transport-webusb from LedgerJS ( instead of hw-transport-u2f.

A user action (such as a button click) is now mandatory to interact with a device with this transport, and the user will be prompted with a browser generated connection screen on the first connection of a device on a new URL.

What does it mean for third party native developers

Native applications will keep using the original HID transport. You’ll just need to support the updated USB product IDs in your code, if you don’t detect Ledger devices by the vendor ID only (0x2c97)

The USB product IDs will be defined as MMII, encoding a model (MM) and an interface bitfield (II)

Model :

Interface support bitfield:

Generic HID + U2F + WebUSB (legacy interfaces support) :

Generic HID + WebUSB:

The Generic HID interface will still be exposed as the first interface.