U2F ECDSA vulnerability

Published Jun 24, 2019

This page provides technical background and advice to users who are affected by a security vulnerability in Chrome OS' experimental "built-in security key" feature that implements an authenticator in accordance with the Universal 2nd Factor specification.

"Just tell me what to do!"

If you're not interested in technical detail, but just want to fix your account security, just follow these steps:

Double-check whether you're affected: This is about the experimental
built-in security key function where your Chromebook acts as a security key
that you can trigger by pressing the Chromebook's power button. If you have
never used this feature, you can stop reading now.

Make a list of your accounts with websites etc. where you have registered
the built-in security key. These are at risk because the built-in security
key can potentially be faked by an attacker without the attacker having your
Chrome OS device.

Unregister the built-in security key from all these services. Exact
instructions vary by service, but typically there are "account settings" or
"security settings" that list registered security keys and give you the
option to remove / unregister security keys. There is no need to change
passwords or other account security settings.

(optional) Review recent successful logins to services to determine whether
there's anything suspicious.

In case you received a "Internal security key requires reset" notification,
click "Reset" on the notification to prevent it from showing again.

That's it, you're good. You can stop reading at this point unless you are interested in further technical details.

Technical Details

Vulnerability description

We discovered a vulnerability in the H1 security chip firmware concerning ECDSA signature generation. The firmware code used incompatible transfer instructions when passing a critical secret value to the cryptographic hardware block, resulting in generating secret values of a specific structure and having a significant loss of entropy in the secret value (64 bits instead of 256 bits). We confirmed that the incorrect generation of the secret value allows it to be recovered, which in turn allows the the underlying ECC private key to be obtained. Thus, attackers that have a single pair of signature and signed data can effectively compute the private key, breaking any functionality or protocols that use the key pair in question.

Impacted features

ECDSA signatures generated by H1 were only used by Chrome OS for the experimental built-in U2F authenticator. An attacker who observes a signature produced by the built-in U2F authenticator can thus obtain the private key and spoof the authenticator from that point on. In other words, correct signatures no longer provide a strong signal of possession of the corresponding Chrome OS device.

Note that signatures are generated both when the U2F authenticator gets registered with a service, and when processing an authentication challenge (e.g. when logging in to a 2FA-enabled service using the built-in U2F authenticator).

We don't expect the vulnerable signatures to have been exposed broadly as they will usually be passed across HTTPS connections. However, since the signature is not considered sensitive in the U2F protocols, it would be inadequate to assume that no signatures have been observed or logged / stored in locations where they still may be retrieved from. As such, the built-in U2F authenticator feature that has generated vulnerable signatures using the vulnerable H1 firmware must be considered cryptographically broken.

In practice, even the cryptographically broken U2F implementation as described above still doesn't immediately cause account compromise. For one, the primary factor in two-factor-authentication scheme remains unaffected. Secondly, even the broken U2F implementation provides phishing protection against most attackers since they won't easily be able to obtain a signature to break. Specifically, obtaining signatures is complicated by the U2F protocol creating individual keys for each service that a security key is enrolled with.

Nevertheless, we recommend users to take remediation steps as described below to avoid the risk of running with a cryptographically weakened U2F authenticator.

Remediation

Full remediation requires both a firmware fix and retiring key pairs that have generated vulnerable signatures.

Firmware fix

Fixed firmware for the H1 security chip has been shipping with Chrome OS version 75 and later and the update has automatically been installed on devices. No user action is required to get the firmware fix. Concerned users can double-check the H1 firmware version as described below to verify they've been updated to fixed firmware. The fixed firmware no longer generates vulnerable signatures. Note that this doesn't retroactively "fix" affected key pairs that have previously generated vulnerable signatures, these can still be broken if a vulnerable signature is available to an attacker.

Retiring affected ECDSA keys

Each registration of the built-in U2F authenticator with a service has a corresponding ECDSA key. All keys that have produced vulnerable signatures are no longer secure, so should no longer be trusted by services. Unfortunately there is no way to centrally revoke security keys, so users need to manually unregister the built-in U2F authenticator from services. See the advice above for more details.

Affected versions

Production H1 firmware versions with a version number of 0.3.14 and earlier contain the vulnerability. Versions 0.3.15 and later are not vulnerable. The H1 firmware version is listed on the chrome://system page under cr50_version, specifically the RW line.

Fixed H1 firmware versions are shipping with Chrome OS version 75 and later and get automatically installed by the OS. Note that the firmware will never get downgraded, so even if you downgrade to an earlier OS version, the fixed firmware will keep running on the device.

Affected devices

All shipping devices that have an H1 security chip are potentially affected. A full list of models with public codename (listed in Platform or Customization ID on the chrome://version page) and model name is given below.

akali360 - Acer Chromebook Spin 13 (CP713-1WN)

akali - Acer Chromebook 13 (CB713-1W)

alan - HP Chromebook 11 G6 EE

aleena - Acer Chromebook 315

ampton - ASUS Chromebook Flip C214

apel - ASUS Chromebook C204

astronaut - Acer Chromebook 11 (C732)

babymako - ASUS chromebook C403

babymega - ASUS Chromebook C223

babytiger - ASUS Chromebook C523

barla - HP Chromebook 11A G6 EE

basking - ASUS Chromebook C213NA/C213SA

bigdaddy - HP Chromebook 14 / HP Chromebook 14 G5

blacktip360 - CTL chromebook NL7T-360

blacktip - CTL chromebook NL7

blacktiplte - CTL Chromebook NL7 LTE

blue - Acer Chromebook 15 CB315-1H / 1HT

bobba360 - Acer Chromebook Spin 511

bobba - Acer Chromebook 311

bob - ASUS Chromebook Flip C101PA

bruce - Acer Chromebook Spin 15 CP315-1H / 1HT

careena - HP Chromebook 14 db0000-db0999

dru - Acer Chromebook Tab 10 (D651N / D650N)

druwl - CTL Chromebook Tab Tx1

dumo - ASUS Chromebook Tablet CT100

electro - Acer Chromebook Spin 11 (R751T / CP511)

epaulette - Acer Chromebook 514

eve - Google Pixelbook

fleex - Dell Chromebook 3100

grabbiter - Dell Chromebook 3100 2in1

kasumi360 - Chromebook Spin 311 (R721T)

kasumi - Chromebook 311 (C721)

kench - HP Chromebox G2

lava - Acer Chromebook Spin 11 (CP311-1H & CP311-1HN)

liara - Lenovo 14e Chromebook

meep - HP Chromebook x360 11 G2 EE

mimrock - HP Chromebook 11 G7 EE

nasher360 - Dell Chromebook 11 2-in-1 5190

nasher - Dell Chromebook 11 5190

nautiluslte - Samsung Chromebook Plus (LTE)

nautilus - Samsung Chromebook Plus (V2)

nocturne - Pixel Slate

orbatrix - Dell Chromebook 3400

pantheon - Yoga C630 Chromebook

phaser360 - Lenovo 300e/500e Chromebook 2nd Gen

phaser - Lenovo 100e Chromebook 2nd Gen

pyro - Lenovo Thinkpad 11e Chromebook (4th Gen)/Lenovo Thinkpad Yoga 11e
Chromebook (4th Gen)

rabbid - ASUS Chromebook C423

robo360 - Lenovo 500e Chromebook

robo - Lenovo 100e Chromebook

sand - Chromebook 15 (CB515 - 1HT / 1H)

santa - Acer Chromebook 11 (CB311 - 8H / 8HT)

shyvana - ASUS Chromebook Flip C434

sion - Acer Chromebox CXI3

snappy - HP Chromebook x360 11 G1 EE

sona - HP Chromebook x360 14

soraka - HP Chromebook x2

sparky360 - Acer Chromebook Spin 512(R851TN)

sparky - Acer Chromebook 512(C851/C851T)

syndra - HP Chromebook 15 G1

teemo - ASUS Chromebox 3

vayne - Dell Inspiron Chromebook 14 2-in-1 7486

whitetip - CTL Chromebook J41 / J41T

whitetip - PCmerge Chromebook AL116

whitetip - Prowise Chromebook Eduline

whitetip - Sector 5 E3 Chromebook

whitetip - Viglen Chromebook 11C

wukong - CTL Chromebox CBx1

wukong - Promethean Chromebox

wukong - ViewSonic NMP660 Chromebox

Q&A

This section provides answers for situations we expect users to find themselves in.

Yes. Chrome OS M76 shows a system notification on all devices that have the legacy built-in U2F authenticator feature enabled manually via crosh. Note that the notification triggers on whether the feature is enabled, regardless of whether you have actually used the U2F authenticator with any services. If you have registered the built-in U2F authenticator with any services, please unregister as explained above.

There's no good reason to continue using the legacy feature that was enabled via u2f_flags u2f or u2f_flags g2f, but users should switch to the improved implementation, which the "Reset" button on the notification will do for you without having to go through crosh.

I can't live without the built-in U2F authenticator. What to do?

The good news is that we have been working on an improved implementation of the built-in U2F authenticator feature for a while. This will not only be unaffected by the bug since it never generated signatures that have the vulnerability, but it also has other security improvements. In particular the improved implementation now respects user boundaries, i.e. each Chrome OS user has their own virtual instance of an U2F authenticator. Also, the underlying encryption keys get discarded when you go through powerwash, recovery, or switch to developer mode.

The new implementation is still not officially launched, but can be tried out at this point. To enable, open crosh and type u2f_flags u2f,user_keys. Note that existing registrations with services (which you should have removed per the advice above on this page) will no longer work, so you need to re-register the built-in U2F authenticator with any services.

I have lost access to a service that had the built-in U2F authenticator configured as the only valid security key. Help!

You can temporarily re-enable the legacy implementation of the built-in U2F authenticator by issuing the u2f_flags u2f in crosh (see also the question on u2f_flags behavior). Your old registrations should now work again. After you regain access to the affected service, please turn the legacy U2F authenticator off again.

How do the various u2f_flags commands in crosh affect behavior?

The u2f_flags command in crosh allows you to control the behavior of the built-in U2F authenticator as follows:

u2f_flags u2f,user_keys
The user_keys flag enables the improved built-in U2F authenticator
implementation. Users who want to test-drive the feature and are aware of
the risk of using beta quality features can use this.

u2f_flags
When invoked without a parameter, the command will turn of the built-in U2F
authenticator feature.

u2f_flags u2f
u2f_flags g2f
Enables legacy built-in U2F authenticator behavior. There is no reason to
continue using this; enabling will trigger the "Internal security key
requires reset" system notification. There is no good reason to continue
using the legacy implementation at this point.

Please be advised that the built-in U2F authenticator feature remains in beta status at this point, hence crosh still prints the warning message about the experimental nature of the feature and potential consequences.