[personal profile] mjg59
The biggest objection that most people have to UEFI Secure Boot as embodied in the Windows 8 certification requirements is the position of Microsoft as the root of trust. But we can go further than that - putting any third party in a position of trust means that there's the risk that your machine will end up trusting code that you don't want it to trust. Can we avoid that?

It turns out that the answer is yes, although perhaps a little more complicated than ideal. The Windows 8 certification requirements insist that (on x86, at least) the key databases be completely modifiable. That means you can delete all the keys provided by your manufacturer, including Microsoft's. However, as far as the spec is concerned, a system without keys is in what's called "Setup Mode", and in this state it'll boot anything - even if it doesn't have a signature.

So, we need to populate the key database. This isn't terribly difficult. James Bottomley has a suite of tools here, including support for generating keys and building an EFI binary that will enrol them into the key databases. So, now you have a bunch of keys and the public half of them is in your platform firmware. What next?

If you've got a system with plug-in graphics hardware, what happens next is that your system no longer has any graphics. The firmware-level drivers for any plug-in hardware also need to be signed, and won't run otherwise. That means no graphics in the firmware. If you're netbooting off a plug-in network card, or booting off a plug-in storage controller, you're going to have similar problems. This is the most awkward part of the entire process. The drivers are all signed with a Microsoft key, so you can't just enrol that without trusting everything else Microsoft have signed. There is a way around this, though. The typical way to use Secure Boot is to provide a list of trusted keys, but you can also provide trusted hashes. Doing this involves reading the device ROM, generating a SHA256 hash of it and then putting that hash in the key database.

This is, obviously, not very practical to do by hand. We intend to provide support for this in Fedora by providing a tool that gets run while the system is in setup mode, reads the ROMs, hashes them and enrols the hashes. We'll probably integrate that into the general key installation tool to make it a one-step procedure. The only remaining problem is that swapping your hardware or updating the firmware will take it back to a broken state, and sadly there's no good answer for that at the moment.

Once you've got a full set of enrolled keys and the hashes of any option ROMs, the only thing to do is to sign your bootloader and kernel. Peter Jones has written a tool to do that, and it's available here. It uses nss and so has support for using any signing hardware that nss supports, which means you can put your private key on a smartcard and sign things using that.

At that point, assuming your machine implements the spec properly everything that it boots will be code that you've explicitly trusted. But how do you know that your firmware is following the spec and hasn't been backdoored? That's tricky. There's a complete open implementation of UEFI here, but it doesn't include the platform setup code that you'd need to run it on any x86 hardware. In theory it'd be possible to run it on top of Coreboot, but right now that's not implemented. There is a complete port to the Beagleboard hardware, and there's instructions for using it here. The remaining issue is that you need a mechanism for securing access to the system flash, since if you can make arbitrary writes to it an attacker can just modify the key store. On x86 this is managed by the flash controller being switched into a mode where all writes have to be carried out from System Management Mode, and the code that runs there verifies that writes are correctly authenticated. I've no idea how you'd implement that on ARM.

There's still some work to be done in order to permit users to verify the entire stack, but Secure Boot does make it possible for the user to have much greater control over what their system runs. The freedom to make decisions about not only what your computer will run but also what it won't is an important one, and we're doing what we can to make sure that users have that freedom.

ARM TrustZone

Date: 2012-08-16 05:57 pm (UTC)
From: (Anonymous)
There's this feature on ARM called TrustZone, which divides the CPU in a secure and non-secure world. However, it's up to the SoC vendor to decide whether to implement it or not and AFAIK it's hard (if not impossible) to use it as an end-user without modifying the bootloader (which is in ROM).

[misposted this to 16387.html, please delete the other one | also, your OpenID coupling seems to be giving problems with the captcha validation]

Re: ARM TrustZone

Date: 2012-08-17 09:38 am (UTC)
From: (Anonymous)
Most (if not all) mobile SoCs do implement TrustZone in one way or another. Unfortunately no implementation I know of allows the end user to provide new keys and add code to the trusted part. If that would be possible, you could write trusted code which forces all accesses to the flash controller to be done from secure mode.

Good, but complicated

Date: 2012-08-16 06:32 pm (UTC)
From: (Anonymous)
The possibility of enrolling ROM keys would be great. It will still
be a PITA, just another administrative task in the best case and a real PITA if anything goes wrong, and it sometimes will.

Is there any slightest chance of buying hardware for Ubuntu (was it Ubuntu that made their own hardware requirements?) and somehow getting Fedora bootable by their keys? Not that it really sounds like a viable option for many reasons (like actually obtaining a needed hardware with the Ubuntu keys)

Re: Good, but complicated

Date: 2012-08-16 06:46 pm (UTC)
From: (Anonymous)
I do agree with that choice, signing anyones code is either a phony offer or just plain thick (I mean insecure)

But I wish Canonical would sign major players' code.

The anticipated unanticipated

Date: 2012-08-16 06:54 pm (UTC)
From: (Anonymous)
I somehow have a strong feeling that when the hardware is available there will be a huge box of surprises.

Both the UEFI spec and Microsoft's hardware requirements look good on paper, but I already know some HP BIOSes, EFI ones, that did not quite implement the standard, or rather implemented some "additional features". That did make booting almost anything other than preinstalled problematic - there were workarounds for that, but anything short of wiping the whole drive for a fake container partition did not have a chance to boot. On laptops.

We'll see I guess.

Linux Foundation

Date: 2012-08-16 07:04 pm (UTC)
From: (Anonymous)
I don't understand why the Linux Foundation (or some other equally trusted, respected, independent group) doesn't step up and provide signing. I doubt Dell, HP, Lenovo, etc want to deal with a dozen distributions, but I'm sure they would be happy to include a root CA cert from the Linux Foundation as well as Microsoft. Then said foundation could provide signing services to all the distributions. Sadly I think we're out of time for this to happen. Or am I missing something?
From: (Anonymous)
Please, tell me what I am missing:

Microsoft will sing code for anyone. This cannot ever be secure. First, I don't buy the argument that they can track who signed it. There will be a market of signed loaders, with the person whose code was submitted either non-existing or not knowing anything about it.
So, Microsoft will blacklist them: when? When there is a known exploit? It seems a little late for a cryptographically "safe" feature. No one else has the list of keys that were signed. Maybe they will blacklist everything they sign except own - there are two problems with that. Space overflow in blacklists will limit the count of keys they can sign. Second: this would mean that the Fedora shim loader would be useless.

My point is that the signing service will either be insecure - also for Fedora - or will be limited or will be terminated. I now value what you just described for making own keys, otherwise the whole feature is pretty useless.
From: [identity profile] owenshepherd.net
This is no different form any certification authority.

The WinQual requirements state you must be a company. So, first you must form a company, handing over all sorts of details to your government so they can determine that, yes, you really are you.

Next, you need a Class 2 verified certificate from Verisign, so you're essentially handing copies of your passport and driving license to them, plus the company's registration documents.

As Verisign are administering this service, I'd be very surprised if they hadn't agreements with numerous world governments which they can use to verify the authenticity of these documents; and validating company registration documents isn't difficult

So, you're going to give Verisign a picture of your passport and driving license and registration documents for this company, and then you're going to give Microsoft the same.

And then you're going to sign contracts saying that you're not going to do nefarious things, probably with large financial penalties, then do nefarious things?

Nothing's perfect, but this goes a long way.

From: (Anonymous)
Repeatedly:

There will be a market of signed loaders, with the person whose code was submitted either non-existing or not knowing anything about it.

Ok, maybe you have ruled out to some extent (literally) "non-existing", I agree that there are obstacles. The second possibility may be weaker in chain: it is enough to compromise a signing system in any way just as systems are compromised nowadays, including but not limited to "I do not know who used my system to sign this" being a fake statement, which is really hard to prove. It does not take a lot of money to register a SomeName Ltd., use that for credentials and go bankrupt. Are you certain that in all countries this scheme will swiftly end in criminal prosecution? The TCO is not much higher than the fee for WinQual.

At best the thing will slighty modify the dynamics. If a system gets hacked using such loader one can assume they have not been hacked by kids but by more serious guys - what a consolation.

I am not arguing that this is not an obstacle - I just don't buy any marketing hype that this is cryptographically secure when it is not, and it is not because almost anyone can have a loader with a genuine signature (genuine is the right word here, right?).

Signing the firmware

Date: 2012-08-16 09:57 pm (UTC)
From: (Anonymous)
Why is it a problem that the firmware binaries are signed by Microsoft? If you can insert your own key as a trusted key, couldn't you just discard the Microsoft signature and sign the firmware blobs yourself with the key whose public half you have added?

Re: Signing the firmware

Date: 2012-08-17 12:21 am (UTC)
From: (Anonymous)
Ah, I didn't realize this was about firmware in ROM (as you admittedly clearly say in the post). I thought this was about drivers uploading firmware to a card.

Then I wonder about how such a check can possibly be implemented. As far as I can tell, there is no standard way for a computer to request a device to send its firmware, and no enforceable way to prevent a card responding with something other than its true firmware.

Or you can ...

Date: 2012-08-17 03:33 am (UTC)
From: (Anonymous)
File a complaint with the US Justice Department's Anti-Trust division. They seemed to be already aware based on the personal response letter I got but I'm sure more complaints will keep the fire hot.

Here's the link

Date: 2012-08-17 03:34 am (UTC)
From: (Anonymous)
Forgot the link to file a complaint: http://www.justice.gov/atr/contact/newcase.html

Re: Here's the link

Date: 2012-08-19 02:25 am (UTC)
From: (Anonymous)
Class action lawsuit! Class action lawsuit! Class action lawsuit! Class action lawsuit! Class action lawsuit! Class action lawsuit! Class action lawsuit! Class action lawsuit! Class action lawsuit!

Profile

Matthew Garrett

About Matthew

Power management, mobile and firmware developer on Linux. Security developer at Nebula. 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