mjg59 | Don't like Secure Boot? Don't buy a Chromebook.

Entry tags:

advogato,
fedora

Don't like Secure Boot? Don't buy a Chromebook.

(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)

Threaded | Flat

The rationale for forcing uses to choose between security and freedom is because you can't provide both together.

One particular use case that is considered important to Chromebooks is: You should, as a user, feel comfortable and secure using one that you do not own. Perhaps it's a loaner Chromebook like Virgin America provided last year for people on their flights, or one provided by a hotel you're staying at (another pilot Google has run), or a public kiosk, etc.

A simple reboot of the device will show whether or not it is a trusted OS installed on it; this is why once the developer switch is toggled, the firmware will always give scary "OS IS UNTRUSTED!" warnings. All bets are off then: since the owner can manipulate the system, including disabling the verified filesystem, install key loggers, send your passwords to others, etc.

The middle-ground would be to semi-trust externally signed OS, for example permit additional signing keys to be added to the firmware so that it can verify that the non-Chrome OS kernel it's booting matches those keys to give the modding community some level of secure boot support.

You'd have to resolve the UI issue, making sure a user unaware of the concept of modding (my dad, for example) would be still aware that he shouldn't trust the device in its modded state. But also have some other level of UI for the modded device firmware not matching the additional keys, while also still supporting modders who flat out don't want to deal with secure boot.

Our firmware team, though I can't actually speak for them, support modding enough that this is probably more a case of getting people to agree on the right approach rather than flat-out denial. Though also you know how security people like to say No and get angry at you ;)

Benjamin Franklin: "They who can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety"

I can't beleive that MG wrote that. What utter nonsense. OMFG. So what you are saying is that indiviuals should trust XYZ corporation who can steal your data but not the themselves. Oh man give your head a shake.

Why was the user freedom (or whatever you want to call it) not written into the spec? Seems to be easy enough to do:
1. The user must be able to disable SecureBoot (but only by physical access)
2. The user must be able to install their own keys (but only by physical access)
3. UEFI must be passphrase protected, and the default must be changed by the user on first boot
4. It must be possible to do a factory reset (but only by physical access)
Seems to about cover everything. So why wasn't it in the spec? It's not like you buy a Ford and the manual says "If you don't use BP fuel, we will shoot your puppy".

Hmm...actually...I strongly suspect I know why it wasn't written into the spec. It was done to protect revenue, not to protect users.

It should also be mentioned that a Chromebook with disabled OS validation may be useful as a development machine, but it's certainly not something you would want to use on a day-to-day basis (or much less give someone without a technical background to use).

At least the new ones that don't have a physical switch require you to press ctrl-d on each boot (or wait a minute) while any other keystroke re-enables validation. You might imagine how inconvenient that can be.

It is possible to replace the keys in the Chromebook firmware and there is a script provided in Chrome OS that will do it at /usr/share/vboot/bin/make_dev_firmware.sh as well as more scripts in the verified boot source repository that will assist with generating new keys and signing kernel images.

The major inconvenience here is that the keys live in a read-only firmware region so you need to defeat the write protection first which involves opening the case. Of course devices are all slightly different in how they implement write protection -- some require removing a screw and others use a jumper -- and the specifics for each board are not documented well enough yet but that is something we can and will fix Real Soon Now.

Supporting a user-provided key in developer mode that would only boot user-signed kernels is something we hope to do for future devices, but it has not happened yet. It is certainly fair to complain that the process is rather painful right now.

It is also worth mentioning that the entire firmware stack is as open as possible so if someone is not satisfied with what is provided they can build their own. This is obviously only useful to a really small/brave set of people and, just as with replacing the keys, it means you will no longer be able to boot official Chrome OS images unless you were smart enough to back up the firmware first.

--Duncan Laurie

You wrote "Chromebooks are either secure and running Google's software, or insecure and running your software."

That's a sentence that could easily be taken out of context to imply something very different from what I think you meant. That is, given that sentence alone one might think you are suggesting that Google's software provides security while "your software" provides insecurity. And I think your intended meaning relies on an implicit assumption that's exactly opposite.

In fact, I think you are talking about two different kinds of security here, both of which are desirable. And you are pointing out that in Google's system both cannot be obtained simultaneously. The first security is that of a "validated boot", (firmware validates that system to be booted been signed with an installed key). The second is an "obeys my bidding" sort of security, (I've seen the code, I've modified it according to my desires, it doesn't contain any anti-features like spying, etc.).

The way I understood your original sentence is: "Chromebooks are either secure [with "validated boot"] and running Google's software [insecure—doesn't "obey your bidding"], or insecure [no "validated boot"] and running your software [secure—"obeys your bidding"].

-Carl (cworth@cworth.org)

Isn't the Chromebook's firmware Coreboot (http://www.coreboot.org/Samsung_XE550C22-H02US), not UEFI? This is an important note, since one of the benefits of Coreboot (http://www.coreboot.org/Benefits) is that it is Free software. Ultimately, which Chromebook did you use?

I applaud Google for letting users at least disable the validation verses a company like Apple that does not let you disable the validation on their ARM devices (iPod Touch, iPhone, iPad, Apple TV, etc.). I am typing this from an ARM Chromebook, and I love it. It is the most secure consumer OS available today on the market, and it is very inexpensive at that. If you ever want to tweak, you can do that too! I think that this is unfair criticism of Google who are trying to allow for options by allowing the disabling of secured boot.

Is this an attempt to justify the fact that you have been working to make secure boot workable for Linux? Or is it an attempt to criticise some developers you don't like who are working for Google?

Tell me one thing: in your history of using Linux, how many cases have you come across of a compromised kernel being used to boot a box?

Why are people suddenly all barking about secure boot? Has there been some massive security incident that nobody on earth knows about - except Microsoft and Google?

Sam Varghese

You assume that the software from Google and Micrsoft is secure. I wouldn't be surprised if they are both spying on your actions while you use the computer. Therefore, only the Chromebook with dev mode will actually allow me to install software I trust onto the system. Much better than the Microsoft tablet.

The content is correct but not the title.
If you don't like secure boot you can disable it so you have no reason to not buy a Chromebook.
Your position is that you like secure boot but want to control it, this is different from not liking it.

If this blog post has any point, what would it be?
The author wants us to criticize Google because we can't properly boot Linux on our new Lenovo?
Is that it?

secure boot is like putting double-locks on the front door while the windows swing open.

The software chain of trust is completely broken. Read "Reflections On Trusting Trust".

Until the rest of the software chain is secure, securing the bootloader is pointless.

I had my first experience with UEFI Secure Boot about a month ago, when I bought my new Packard Bell laptop, which come with Windows 8 pre-installed. The only way to boot other OSes (I am Linux user more than 10 years, so it wasn't even an option to run Windows everyday), was to disable UEFI boot at all and switch to "Legacy BIOS boot". There was an option to disable secure boot in UEFI in BIOS, but that option was disabled itself.

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

I thought people wanted ARM chrome books.

Can you even boot ARM linux on an ARM microsoft windows machine?

Check out http://www.phoronix.com/scan.php?page=news_item&px=MTI5Mzg ( Ubuntu 13.04 Will Have Better Exynos 5 Chromebook Support ).

So Ubuntu 13.04 will come with Debian's 'vboot-utils' so custom signed kernels can be used without messing with the firmware. Thank you Open Source.

If Perl or Python are signed. If I run damage script over Python and Perl does not compiled nothing. Can run it with secure boot enabled?

I'm not sure, if it makes sense to start this thread so late in an old post, as I find this very important. I would really appreciate feedback on this. I might repost this, if I get none within a week or so.

It's great that Microsoft provides the infrastructure to sign our own code to deal with the bootstrap issue. But does this imply, that everyone also needs to to trust anything they sign? If not, do we have to trust anything Google signs on Chromebooks?

I think it is really important that the next UEFI specification mandates that, there is not only a uniform key/hash management application for the initial boot, but also that anyone providing the initial OS must also provide a way to replace signatures on binaries with those of custom keys.

IIRC, the format of a signed binary can only facilitate a single signature.

Why must a keep trusting /everything/ that Microsoft/Google, sign once I have my own key installed. I should be able to remove their key and either selectively white list (via hashes) or sign not only initial boot images but also specific kernel modules/drivers.

I'm fine with using your Shim for the initial setup, but then I want to install my Shim that I've built and that was signed by me. I don't want to trust NVidia's proprietary driver, but only nouveau that was signed by debian, fedora, .

I'm wondering whether this should be done within the uniform UEFI application. Theoretically I'm fine if can boot into a minimal system without all modules available but enough so that I can replace signatures in modules/drivers or enroll hashes for specific drivers that I decide to trust without trusting everything that was signed by the Microsoft/Google keys. But this minimal system should also have a consistent user experience that doesn't differ between the UEFI/OS implementations.

Does anyone have something like this on their To-Do list? And what would it take to put that on someones To-Do list... seriously. Until the User can practically control the trust chain, SecureBoot is not Secure, even if your effort have relieved the Restricted Boot issue a lot. Thanks again though for doing that for us!

Great write up! I was going to buy an Acer C7 Chromobook last Christmas, but then I found out it's a restricted boot piece of junk!

Part of the reason for secure boot is to stop somebody from having persistent root by installing a compromised kernel. On reboot, the firmware will detect the change.

To allow for user freedom, you need to allow change of keys and/or BIOS. If you allow this to be done in software, a remote attacker can simply change this and get persistent rootkit, defeating the purpose.

Therefore, to balance the two goals, you make sure that disabling write protect cannot be done in software and needs to be a hardware option. Also not an option a normal user can be socially-engineered into carrying out (e.g. insert SDcard, wait while hacker loads exploit onto it, and leave SDcard in to be used a 'custom firmware' as suggested by a poster above).

This is the reason why the write-protection involves opening up the case and flipping a jumper and so on. It is not something a user would normally do.

If you are so bad that you can't find this jumper, Google have put a website which shows how to dismantle and where this jumper is.

Since some are so uneducated about this, maybe they should read the security design document.

Personally, I also find the CTRL-D annoying, which is why I will flash my firmware to remove this.

You need to build your own hardware including etching and doping your own billion transistors if you need absolute trust.

Any thing else involves some compromise. Relative trust based on compromise is always complex and less than perfect.

Threaded | Flat

Rationale

Security VS Freedom

Utter nonsense

Why's it not in the spec

Disabled OS validation is also annoying

no subject

A clarification to avoid misreading

Coreboot

Wow

Red herring?

assumed security

Misleading Title

..what?

red herring

no subject

Kernel signing seems possible

ARM?

Ubuntu 13.04 gets kernel signing util for Chromebooks

Secure boot and botnets and scripts...et

Resigning Drivers and other Blobs

no subject

Pretty stupid reasoning

Build your own hardware if you need absolute trust