---
breadcrumbs:
- - /chromium-os
  - Chromium OS
page_name: u2f-ecdsa-vulnerability
title: 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:

    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](/chromium-os/u2f-ecdsa-vulnerability#TOC-Affected-versions) 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](/chromium-os/u2f-ecdsa-vulnerability#TOC-Just-tell-me-what-to-do-) 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?

<img alt="image"
src="https://lh5.googleusercontent.com/RgOXv39FQJIDYi_NyQ1d9O5h2VKRrely3La_jLnwuMi04RiTox9jTiqQSwzBm_PY8nGhG5ED8aJ6X1eQX0s56_9doQ6EIoqXl5BUiab1Dm8SuFxPJqTeOY_YPybM2fnYQ-sI4LOT"
height=407 width=624>

Yes. Chrome OS M76 shows a system notification on all devices that have the
legacy built-in U2F authenticator feature enabled manually via
[crosh](https://chromium.googlesource.com/chromiumos/platform2/+/HEAD/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](https://chromium.googlesource.com/chromiumos/platform2/+/HEAD/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](https://chromium.googlesource.com/chromiumos/platform2/+/HEAD/crosh) and
type u2f_flags u2f,user_keys. Note that existing registrations with services
(which you should have removed per the [advice
above](/chromium-os/u2f-ecdsa-vulnerability#TOC-Just-tell-me-what-to-do-) 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](https://chromium.googlesource.com/chromiumos/platform2/+/HEAD/crosh)
(see also the [question on u2f_flags
behavior](/chromium-os/u2f-ecdsa-vulnerability#TOC-How-do-the-various-u2f_flags-commands-in-crosh-affect-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](https://chromium.googlesource.com/chromiumos/platform2/+/HEAD/crosh) affect behavior?

The u2f_flags command in
[crosh](https://chromium.googlesource.com/chromiumos/platform2/+/HEAD/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.

<img alt="image"
src="https://lh5.googleusercontent.com/-FCWZDxNb0xWgVpTfpn1uNZyp0LPi_IFzIlW86Qp8RyuvEZE5Pc0DO-7HIt6yuc0MK3sEIyvGHiKldUccf94phWPPHcoa96cUegu1yf4nf5L6fQnZhI1yvqJ68IX_OEo2Rr8QpdV"
height=523 width=624>

Please be advised that the built-in U2F authenticator feature remains in beta
status at this point, hence
[crosh](https://chromium.googlesource.com/chromiumos/platform2/+/HEAD/crosh)
still prints the warning message about the experimental nature of the feature
and potential consequences.
