--- 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? image 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. image 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.