Skip to content
Naked Security Naked Security

Google fixes Chromebook 2FA flaw in ‘built-in security key’

Google has discovered a flaw in a Chromebook security feature which allows owners to press their device’s power button to initiate U2F 2FA.

Google has discovered a serious flaw in a Chromebook security feature which allows owners to press their device’s power button to initiate U2F two-factor authentication (2FA).

Known as the ‘built-in security key’, the experimental feature was first enabled for Google PixelBooks last summer. Since then, it has quietly been embedded on numerous Chromebooks that have the necessary H1 CR50 chip inside them, including many made by Dell, HP, Acer, Samsung, Asus and Lenovo. A full list of affected devices is available on Google’s website.

We say ‘quietly’ because it’s unlikely many owners beyond developers have even heard of the feature, let alone used it to authenticate themselves when logging into a website.

For those who have, the feature is appealing – instead of waiting for an SMS onetime 2FA code, or generating one using an app, or even plugging in a hardware security key such as Google’s own Titan, Chromebook users can achieve the same with a short press of the power button.

Unfortunately, a vulnerability has been discovered in the system that makes this work, specifically the generation of an Elliptic Curve Digital Signature Algorithm (ECDSA) signature by H1 chips running v0.3.14 firmware and earlier. Google said:

We confirmed that the incorrect generation of the secret value allows it to be recovered, which in turn allows the underlying ECC private key to be obtained.

Which means that an attacker could work out the private key, completely undermining what is supposed to be a fundamental security feature.

Google believes the chances of this happening when users have logged into real websites is small given that communication with the website should have happened over HTTPS. However, that doesn’t rule out that weakly generated signatures might have been stored in a vulnerable state on Chromebooks themselves.

Ironically, Google thinks that the one thing that stands in the way of such a second factor compromise is the security of the first factor, namely the password and username.

While true, it’s hardly a ringing endorsement of Google’s technology that it can be rescued by passwords.

What to do

Chrome OS v75 will automatically install version 0.3.15 of the firmware, which contains the fix for this issue. If you don’t use the built-in security key feature, that’s all you have to do.

If do use the security key feature, then you have some work to do after updating the operating system.

Old key pairs generated before the update are still vulnerable, so you have to de-register the built-in security key from every website on which it’s being used for authentication, and then re-register it with a fresh key pair.

Should you trust this feature going forward?

Not everyone thinks it’s a good idea to build the U2F security function into devices in this way when there is a proven secure alternative – use a separate hardware key. That said, 2FA provides such a significant boost to security over simply using usernames and passwords that even flawed or imperfect 2FA solutions are much better than no 2FA at all.

Google says it is improving the security of the technology, which is still in the test phase of its development.

Graveyard shift

This vulnerability dovetails interestingly with that other Chromebook controversy of the moment – Chrome OS end of life.

Recently, owners who bought their Chromebooks between 2013 and 2016 have started seeing the following unexpected message after an update:

This is the last automatic software and security update for this Chromebook.

Google calls this moment ‘Auto Update Expiration’, a 2017 rebranding of the previous and more explicit description, Chromebook ‘end of life’.

It often comes as a shock to owners, who hadn’t realised that Chromebooks only receive software for a maximum of 6.5 years, that they might have to stop using their perfectly functioning computer or continue using it in an increasingly insecure state.

The clock starts ticking not when the Chromebook was bought but when the platform on which it is based first appeared on the market, which might be years before purchase, and in some cases a while before the specific model appeared.

The issue here is what would happen if a big flaw such as built-in security key vulnerability was discovered in a Chromebook beyond its end of life at some point in the future.

The lesson is clear – carefully check the lifespan of any Chrome OS device before buying it.

14 Comments

It often comes as a shock to owners, who hadn’t realised that Chromebooks only receive software for a maximum of 6.5 years, that they might have to stop using their perfectly functioning computer or continue using it in an increasingly insecure state.

Can you plug in a USB stick and install a version of Linux to continue use of the hardware, or have Google “got you” forever?

You can but choosing and installing a distro isn’t straightforward for non-technical users.

Aren’t some Chromebooks bootlocked?

Anwering own question: yes, sort of – the boot ROM is apparently write-inhibited at the hardware level, and as @dmnksnk notes below, “there might be a screw inside that you have to remove to flash it.” And to get at that screw might involve some deft work removing the case screws (which might need you to peel off the rubber feet), and some finesse with a guitar pick to separate the case, and the careful hinging up of the keyboard without damaging the connector in order to access the write-protect “switch” (in the form of a metal screw presssing against a contact), and so on.

Well-known teardown site iFixit has good advice (including recommending searching for “write protect [name of Chromebook]”) here, dated 2 July 2019 when I looked:

https://www.ifixit.com/News/how-to-get-updates-on-your-end-of-life-chromebook

Which is why the better option is not to mess with WP screws and simply run Linux side-by-side with the Chrome OS using something like Crouton. Google has also improved support for Linux in recent releases while Android app support is impressive for machines with post-2015 firmware.

But even doing this can be confusing!

As far as I can see, the OP was talking about installing a Linux distro to *replace* ChromeOS, not to run chrooted on top of it – I inferred that ‘insert a USB stick’ meant ‘to boot up from and dispense with the underlying ChromeOS once it’s no longer wanted or supported.’

Yes that is what I had in mind.
My windows 7 laptop died (on board graphics chip); I had been running various Linux distros in Virtual Box (a great way to try another OS) for a while, so when I looked at the mess that was Windows 10 on my new main laptop, I stuck in a USB stick (with Lubuntu 16.04 64bit) and following the prompts installed it alongside Windows 10. The main problem with doing this was that Windows 10 has to be totally shut down to release its vice like grip on the data partition (Initially I was sharing the data partition between Linux and Windows – just in case I decided to “go back”) – and this is bloody fiddly (thanks MS!). Internet search shows how to really totally shut down Windows 10. In retrospect (after successfully and easily gone through a Linux life cycle and very easily upgraded to Lubuntu 18.04 – one click followed (quite a bit later) with a reboot) I wish I had just over written the whole machine as I have never gone back to Windows – I use wine to run my one “essential” windows program within Linux.

I find the idea that a hardware supplier can market a machine with software LOCKED in where the software effectively EXPIRES fundamentally dishonest. But hey, that do that with smart phones why not do it with all our technology? – I guess my smart TV will software expire before the hardware expires. It would be more honest to offer “Hardware as a Service”?

As the comment below explains, you can do that by dual-booting something like Gallium. I never done that so can’t comment on how easy this is but it’s going to need the sort of hand-holding most Chromebook users won’t have access to.

You have to flash a new BIOS, since the built-in one doesn’t support booting from external devices.
That is a hassle, because there might be a screw inside that you have to remove to flash it.
My Chromebook is using a linux distro, Gallium OS, so I expect it to keep receiving updates long after the lifespan of the original software.

Google’s comment on the username/password being a mitigation for a U2F vulnerability is exactly why I for one have not gotten on board with the vision (seen in WebAuthn and Windows Hello most prominently) of a secure hardware authentication as all you need to log in. If all you need is U2F, the cost-benefit ratio of investing to hack it is huge. On the other hand, exploiting a user account where you need to phish or access the credential _and also_ get past hardware 2FA is much harder.

Linux does the same thing, in a way. My pc worked for awhile but as it has aged, and Linux has gottn more bloatie, it has a more and more difficult time to properly update.

But with Linux you can look for a lower footprint distribution
Currently running Lubuntu 18.04 on HP Mininote (VIA C7-M, 2G Ram, 120G SSD) – but will have to shift (probably to Debian) next year when Lubuntu discontinue support for 32bit

So they’ve been silently installing security software that hasn’t even hit version 1 on people’s devices?
Involuntarily opting people into a beta?
Surely that’s something the EU should slap them for…?

Not really – it’s an experimental feature, yes, but if you’ve not enabled it it’s not going to harm you.

Comments are closed.

Subscribe to get the latest updates in your inbox.
Which categories are you interested in?