Chromium OS‎ > ‎

U2F ECDSA vulnerability

Published Jun 24, 2019

U2F ECDSA vulnerability

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:

  1. 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.

  2. 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.

  3. 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.

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

  5. 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.

I have been getting a notification saying "Internal security key requires reset". Is this related?

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.


Comments