[personal profile] mjg59
(Edit: It's been suggested that the title of this could give the wrong impression. "Don't like Secure Boot? That's not a reason to buy a Chromebook" may have been better)

People are, unsurprisingly, upset that Microsoft have imposed UEFI Secure Boot on the x86 market. A situation in which one company gets to determine which software will boot on systems by default is obviously open to abuse. What's more surprising is that many of the people who are upset about this are completely fine with encouraging people to buy Chromebooks.

Out of the box, Chromebooks are even more locked down than Windows 8 machines. The Chromebook firmware validates the kernel, and the kernel verifies the filesystem. Want to run a version of Chrome you've built yourself? Denied. Thankfully, Google have provided a way around this - you can (depending on the machine) either flip a physical switch or perform a special keystroke in the firmware to disable the validation. Doing so deletes all your data in the process, in order to avoid the situation where a physically present attacker wants to steal your data or backdoor your system unnoticed, but after that it'll boot any OS you want. The downside is that you've lost the security that you previously had. If a remote attacker manages to replace your kernel with a backdoored one, the firmware will boot it anyway. Want the same level of security as the stock firmware? You can't. There's no way for you to install your own signing keys, and Google won't sign third party binaries. Chromebooks are either secure and running Google's software, or insecure and running your software.

Much like Chromebooks, Windows 8 certified systems are required to permit the user to disable Secure Boot. In contrast to Chromebooks, Windows 8 certified systems are required to permit the user to install their own keys. And, unlike Google, Microsoft will sign alternative operating systems. Windows 8 certified systems provide greater user freedom than Chromebooks.

Some people don't like Secure Boot because they don't trust Microsoft. If you trust Google more, then a Chromebook is a reasonable choice. But some people don't like Secure Boot because they see it as an attack on user freedom, and those people should be willing to criticise Google's stance. Unlike Microsoft, Chromebooks force the user to choose between security and freedom. Nobody should be forced to make that choice.

(Updated to add that some Chromebooks have a software interface for disabling validation)

Kernel signing seems possible

Date: 2013-02-06 02:13 am (UTC)
From: (Anonymous)
It appears that it is possible to sign kernels using this util:

http://ftp-master.debian.org/new/vboot-utils_0~20121212-1.html#binary-vboot-kernel-utils-control
http://git.chromium.org/gitweb/?p=chromiumos/platform/vboot_reference.git;a=tree;f=utility

Re: Kernel signing seems possible

Date: 2013-02-07 02:46 am (UTC)
From: (Anonymous)
According to Ubuntu folks on IRC, Google provides developer keys which can be used to sign kernels.

Re: Kernel signing seems possible

Date: 2013-02-07 03:19 am (UTC)
From: (Anonymous)
Do we really want to mess with the firmware. Matthew Garrett

I will be blunt. Secure Security keys must be on read only media. UEFI already has issues of people replace the Platform Key and then being able to replace every other key because the KEK and everything else is in writeable flash.

If we don't wish to have to open up the hardware to install keys. We need like a SDcard slot for keys that is read only. Possibly hidden under a panel and only accessible by the fireware. There could be a secure led on chrome-books to that is on unless something is in that slot.

Really a chromebooks are secure its just a pain in but to put our own keys in. UEFI machines really are not secure. UEFI are pretend security. They believe that hackers will not be able to get the signing keys to have KEK alterations approved and run what ever code they like. Reality the possibility is there it will happen.

I would recommend working with Google to get alterations to the Google design to make running secure OS's possible without voiding warnities or people security.

Matthew Garrett really what way can you come up with that will not be defeated.

Saying google should sign a few things is also problem. What happens if google loses control of the signing key. Current where you can rebuild firmware with new keys and have a bugger of time unlocking the firmware is secure. No one else other than you has that key and no key is left in the system for an attacker to use.

Yes another UEFI fault. I have a machine with Microsoft, Linux and some other strange vendor KEK installed lets say an anti-virus vendor that the hardware maker decided to install. I am not running the anti-virus or windows. Attacker happens to have a flaw that allows the KEK of the anti-virus to be used. Hello system broken.

So a fast way to strip out the keys would be highly useful. Some form of removable rom for key storage. With SDcards you can make a new rom. To change keys you do need physical access under this system.

Where with UEFI you don't need physical access to the system to update/change keys.

If we are worried about remote users kernel level or deeper breaching our systems we need read only firmware that only become read write after hardware modification. Any section of the firmware we wish to change we need stored on a changeable read only device.

Current problem with chromebooks is the keys are inside the firmware not on some removable read only device. Problem with UEFI is the keys are stored in read/write flash.

Both are screwed. Only one can be secured in all cases the chromebook because you have physical read only. Lot of UEFI motherboards are missing the read only switch for the firmware so hello we can add new keys or change existing.

Sorry to say Matthew Garrett no one has made a secure device that is end user friendly yet. Even that the process to make a secure device is simple. Core validation information must be tamper proof to all software alterations without human intervention to alter hardware. Most of the complexity of UEFI could have been completely avoided. Yes it would require user intervention to update keys. Yes this is putting user in control.

Current UEFI model works on the idea user cannot be trusted to update there own keys.

Matthew Garrett before throwing stones you should look at the glass house you are throwing stones from. UEFI is not secure. Chromebooks design is. So the real question is how can we make Chromebooks less of an ass to run what we want without ruining the security.

The best I can find is request Google place signing keys on a read only SD card. Will add a little cost to the device. Would make the machine simpler to repair if god forbid Google has there master key stolen. Current Developer mode is also then simple remove the Google SD card and fail to insert another. Secure with another OS would be insert another SD card with new keys.

If google does provide this its a true proper secure device. Hopefully other groups see there ideas are insane. Advantage of this in case of breached you can boot straight up with new secured keys. Not to have power on and hoping the device is not breached enough to prevent changing of keys.

UEFI is perfect design to be remotely bricked. The simpler the better. Read only media is the simplest and best solution.

oiaohm

Profile

Matthew Garrett

About Matthew

Power management, mobile and firmware developer on Linux. Security developer at Nebula. Member of the Linux Foundation Technical Advisory Board. Ex-biologist. @mjg59 on Twitter. Content here should not be interpreted as the opinion of my employer.

Page Summary

Expand Cut Tags

No cut tags