[personal profile] mjg59
This post is made in a personal capacity. While it represents the outcome of multiple discussions on the topic with a variety of people, nothing written below should be construed as Red Hat's corporate position

The FSF have released a statement on UEFI secure boot. It explains the fundamental issue here, which isn't something as simple as "will OEMs let me install Linux". It's "Does the end user have the ability to manage their own keys".

Secure boot is a valuable feature. It does neatly deal with the growing threat of pre-OS malware. There is an incentive for it to be supported under Linux. I discussed the technical aspects of implementing support for it here - it's not a huge deal of work, and it is being worked on. So let's not worry about that side of things. The problem is with the keys.

Secure boot is implemented in a straightforward way. Each section of a PE-COFF file is added together and a hash taken[1]. This hash is signed with the private half of a signing key and embedded into the binary. When you attempt to execute a file under UEFI, the firmware attempts to decrypt the embedded hash. This requires that the firmware have a either a copy of the public half of the signing key in its key database, or for there to be a chain of trust from the signing key to a key in its key database. Once it has the decrypted hash, it generates its own hash of the binary and compares them. If they match, the binary is executed.

What happens if it doesn't match? Per the UEFI specification, the firmware can then prompt the user and ask if they want to execute it anyway. If the user accepts then the hash of the binary is remembered[4] and can continue to be executed in future. This is similar to what you get when you visit a self-signed https site, or when you connect to an ssh server for the first time - the user must explicitly state that they trust the software that is being booted.

This is a little awkward for a couple of reasons. First, it means that any updates to the bootloader would require the user to manually accept the binary again. Second, as we've seen with https, there's the risk of uesrs just blindly accepting things. If it's acceptable to do this off internal media[5] then malware could just rely on some number of users saying "yes". And thirdly, we've been told that Microsoft's Windows logo requirements forbid this option.

The first is problematic but manageable with appropriate documentation. The second is a real risk that makes this approach far less compelling. And the third is probably a showstopper.

So signed but untrusted binaries are probably out, on technological, UI and policy grounds. What else?

We can sign binaries with a trusted key. This gets us interoperability, but comes at a cost. The first issue here is that we still don't know what the process for getting a trusted key is going to be. One option is for something like a generic Linux key that's provided by all firmware vendors. As long as the OEM doesn't remove it, then that Linux key could be used to sign other keys that are used by individual Linux vendors. The main difficulty involved in this is having the Linux key be managed by an authority that OEMs can trust to only provide keys to trustworthy organisations and maintain control of the private half of the key. Remember, if any malware is signed with any of these keys, it'll boot on any machine carrying this key. It's a lot of trust. It's not obvious that there's an organisation with sufficient trust at the moment.

The second approach is for each Linux vendor to generate their own key and get every OEM to carry it. Let's rule this out on the basis that it's an approach that doesn't scale at all. Red Hat could probably get its key into a bunch of OEM systems. Canonical too. Oracle? Probably for the vendors they care about. It's likely to be much harder for everyone else, and you still end up with the risk that you've just bought a computer that'll boot Red Hat but not Ubuntu.

The third approach is for each Linux vendor to obtain a key from someone who's already trusted. The most obvious authority here is Microsoft. Ignoring the PR unpleasantness involved with Linux vendors having to do business with Microsoft to get signed, so far Microsoft haven't given us any indication that this will be possible.

So every approach that involves us signing with a trusted key comes with associated problems. There's also a common problem with all of them - you only get to play if you have your own trusted key. Corporate Linux vendors can probably find a way to manage this. Everyone else (volunteer or hobbyist vendors, end users who want to run their own OS, anyone who wants to use a modified bootloader or kernel) is shut out.

The obvious workaround is for them to just turn off secure boot. Ignoring the arguments over whether or not OEMs will provide that option[6], it benefits nobody for Linux installation to require disabling a legitimate security feature. It's also not likely to be in a standard location on all systems and may have different naming. It's a support nightmare. Let's focus on trying to find a solution that provides the security and doesn't have obvious scaling issues.

There's a pretty simple one. If the problem centres around installing signing keys, why not have a standardised way of installing signing keys?

What we've proposed for this is an extension of the current UEFI standard for booting off removable media. There's a standardised location for putting the bootloader for USB sticks or optical media. For 32-bit PCs, it's EFI/BOOT/BOOTIA32.EFI. For 64-bit, it's EFI/BOOT/BOOTX64.EFI. Our proposal is to specify a path for key storage on the media. If the user attempts to boot off an item of removable media and finds a key file, we would like the firmware to prompt the user to install the key. Once the key is installed, the firmware will attempt to boot the bootloader on the removable media.

How does this avoid the problems associated with prompting the user to boot untrusted binaries? The first is that there's no problem with updates. Because a key has been imported, as long as future bootloader updates are signed with the same key, they'll boot without prompting the user. The second is that it can be limited to removable media. If malware infects the system and installs itself onto the hard drive, the firmware won't prompt for key installation. It'll just refuse to boot and fall back on whatever recovery procedures the OEM has implemented. The only way it could get on the system would involve the user explicitly booting off removable media, which would be a significant hurdle. If you're at that stage then you can also convince the user to disable secure boot entirely.

This proposal has been brought up with the UEFI standards working group, and with the UEFI plugfest taking place next week we're hoping it'll be discussed. It seems to satisfy the dual requirements of maintaining system security and ensuring that users have the flexibility to choose what they run on their system. But as with all technical proposals, feedback is entirely welcome.

[1] Hilariously, Microsoft's signing tool gets this wrong by also adding the contents of gaps between sections in direct contravention of their own specification. This is fine for binaries generated by Microsoft's toolchain because they don't have any gaps, but since our binaries do contain gaps[2] and since the standard firmware implementation[3] does implement the specification correctly, any Linux-generated binaries signed with the Microsoft tool fail validation. Go team.
[2] Something that is, as far as we can tell, permitted by the PE-COFF specification
[3] Written by Intel, not Microsoft
[4] Note that this means that only the specific binary is considered trusted. No key is imported, and any other binaries signed with the same key will also need to be manually trusted in the same way.
[5] As would be required if you ever want to be able to update your bootloader
[6] And to forestall panic, at this point we expect that most OEMs will provide this option on most hardware, if only because customers will still want to boot Windows 7. We do know that some hardware will ship without it. It's not implausible that some OEMs will remove it in order to reduce their support burden. But for the foreseeable future, you'll be able to buy hardware that runs Linux.

It isn't secure

Date: 2011-10-19 06:31 pm (UTC)
From: [identity profile] rogerbinns.com
There is still a fundamental problem with all this. Anything that is appropriately signed is allowed. It would be an astonishing accomplishment for there to be the first piece of software ever that is bug and security hole free. For a bad guy to break into the system all they have to do is downgrade to signed code with a bug/security hole.

Unless of course you add something preventing downgrades which itself would also have to be bug free.

Re: It isn't secure

Date: 2011-10-19 06:41 pm (UTC)
zwol: stylized sketch of a face in profile (Default)
From: [personal profile] zwol
As with all such things, it doesn't have to be perfect to improve actual end-user security, it only has to present a new obstacle that isn't trivial to avoid.

Date: 2011-10-19 08:07 pm (UTC)
gerald_duck: (Default)
From: [personal profile] gerald_duck
Preventing downgrades would surely be quite simple: embed a sequence number in the signature and have the BIOS require special measures (confirmation, disabling Secure Boot, re-loading the key, whatever) to run software with an earlier sequence number than the highest one already seen for that signing key?

Perhaps someone with the ear of the standardisation committee should suggest it?

Different software can share a key

From: (Anonymous) - Date: 2011-10-20 03:05 am (UTC) - Expand

Re: Different software can share a key

From: (Anonymous) - Date: 2011-10-20 06:57 am (UTC) - Expand

I've just upgraded and there's a problem

Date: 2011-10-20 08:47 pm (UTC)
From: (Anonymous)
Preventing downgrades has it's own risks. If there's a regression in the latest kernel, I need to be able to revert to an older kernel. Also I may have a choice of kernels in my GRUB menu, Does this stop me picking an older kernel?

Re: I've just upgraded and there's a problem

From: (Anonymous) - Date: 2011-10-21 12:30 pm (UTC) - Expand

Re: I've just upgraded and there's a problem

From: (Anonymous) - Date: 2011-10-22 08:44 am (UTC) - Expand

USB-bootable tools?

Date: 2011-10-19 06:33 pm (UTC)
From: (Anonymous)
So, every individual vendor of a USB-bootable tool will need to maintain a signing key, sign each binary release of their tool, and note the fingerprint of the key (or whatever equivalent this new spec hopefully mandates that BIOSes must display) on their site for verification?

Date: 2011-10-19 08:13 pm (UTC)
gerald_duck: (Default)
From: [personal profile] gerald_duck
Fingerprints. That's precisely what I was thinking.

While not essential, it would be really good if the BIOS showed you the fingerprint while prompting for whether or not to absorb a key.

(Relatedly, it would be nice if more USB pendrives had physical write-protect.)

Re: USB-bootable tools?

Date: 2011-10-19 08:41 pm (UTC)
From: (Anonymous)
Sure, just like many software vendors already do, especially for security-related software.

Date: 2011-10-19 06:39 pm (UTC)
zwol: stylized sketch of a face in profile (Default)
From: [personal profile] zwol
So, the installation media presumably ships with a public key baked into it, which the firmware picks up and installs, and then we proceed to boot the installer. The private half of that key really needs to not be on the installation media, otherwise the bad guys can grab it and use it to sign malware. But we want to end up with a private key — a freshly generated one — in the user's possession, otherwise people who need to build their own kernel or bootloader (for whatever reason) are hosed. Can we arrange to generate that key at installation time, write the full keypair to a USB stick, and the public half to the firmware, without requiring an extra reboot?

Also, in very tightly controlled environments the sysadmin might want to wind up with only their locally-generated private key trusted by the OS, but I think I'm okay with that use case requiring the sysadmin to generate a custom installation image. They're probably doing that anyway.

Date: 2011-10-19 06:50 pm (UTC)
From: [identity profile] http://users.livejournal.com/deviant_/
That's not really necessary. In the vendor-signed case (i.e. installing Fedora), the install media would have this on it, and so the key would be enrolled before the install media is booted. When the installed system reboots, it's still using the same key, so no extra reboot is needed.

In the "I'm building my own software" case, you've already got a chicken-and-egg problem where either a) you've already installed this machine and you're just updating things, or b) you have another machine you're building on. In both cases you can simply sign your new software with your own key and put it on the boot media next to bootx64.efi , and enroll it during the reboot you're planning to do anyway.

key managment

Date: 2011-10-19 06:58 pm (UTC)
From: (Anonymous)
"Does the end user have the ability to manage their own keys"

That is the core problem with Secure Boot.
Whoever controls the keystore, controls your hardware. And the only reasonable person to do this is the owner of the hardware, not the producer.
Otherwise you could just get a game console and hope the producer will not revoke your linux access.

One of you last blogs contained: "But they can't prevent their system from running Windows 8."
That is the other half to the keystore access: I not only want to add my own keys, I also want the ability to kick every other keys out, that I do not want to trust.

I like your idea with offering to import keys from a removable media, because this is a nice way to get the key of an installer CD or similar accepted, even without the user needing to read a manual. The system directly offers the choice, without the need to "call the support to get error xyz fixed". But from the security viewpoint this is still a weakness, if the user clicks "OK" without really reading what was asked: Every bootsector virus could now offer its key.
Wouldn't it be better to just include a mandatory key manager into the BIOS? Just "List all installed keys", "Delete selected key" and "Load new key from USB/CD/..." should be sufficient. And it might even be possible to drop into this management menu, if no (correctly) signed boot loader, but a new key file is found on a media.

Re: key managment

Date: 2011-10-19 07:18 pm (UTC)
From: [identity profile] http://users.livejournal.com/deviant_/
> Wouldn't it be better to just include a mandatory key manager into the BIOS?

This again is a support nightmare - if a system ships with already installed keys, that means we need to instruct people on how to find this in their firmware (which is likely to vary among vendors), which keys to remove, how to add a key, etc.

Re: key managment

From: (Anonymous) - Date: 2011-10-20 02:53 am (UTC) - Expand

Re: key managment

Date: 2011-10-19 10:00 pm (UTC)
From: (Anonymous)
How about having the option to 'wipe all other keys' when you are about to add the one from removable (installation) media.


Re: key managment

From: (Anonymous) - Date: 2011-10-20 07:29 pm (UTC) - Expand

Re: key managment

Date: 2011-10-19 10:12 pm (UTC)
From: (Anonymous)
+1 for " I also want the ability to kick every other keys out, that I do not want to trust"

Date: 2011-10-19 09:39 pm (UTC)
ewx: (Default)
From: [personal profile] ewx
Is there any mechanism currently defined for revoking a key? (For when your hardware vendor has their signing key stolen.)

What are the wider effects of revoking a key?

From: (Anonymous) - Date: 2011-10-20 03:59 pm (UTC) - Expand

So the OS can modify the keys?

From: (Anonymous) - Date: 2011-10-20 05:15 pm (UTC) - Expand

Re: So the OS can modify the keys?

From: (Anonymous) - Date: 2011-10-20 06:20 pm (UTC) - Expand

Re: So the OS can modify the keys?

From: (Anonymous) - Date: 2011-10-20 06:59 pm (UTC) - Expand

what about custom keys?

Date: 2011-10-20 02:44 am (UTC)
From: (Anonymous)

What about custom keys? There can be a hardware switch/jumper which puts the computer BIOS to configuration mode and then you can add any kind of custom certificate you want.

Why is this Idea nowhere in the space? Your all three options are still related to signing. You are trying to solve the problem "their" way.

Just like their is a BIOS jumper to lock the changes to BIOS software. We can use the same jumper to boot into a BIOS configuration mode which allows the change.

This is very simple. It is very generic and it gives you the control to your PC.
And anyway, if you have access to the hardware, you should be able to do anything with it right?

Re: what about custom keys?

From: (Anonymous) - Date: 2011-10-20 06:00 am (UTC) - Expand

Re: what about custom keys?

From: (Anonymous) - Date: 2011-10-20 06:03 am (UTC) - Expand

Re: what about custom keys?

From: (Anonymous) - Date: 2011-10-20 07:06 am (UTC) - Expand

Re: what about custom keys?

From: (Anonymous) - Date: 2011-10-20 09:39 am (UTC) - Expand

Re: what about custom keys?

From: (Anonymous) - Date: 2011-10-23 08:45 am (UTC) - Expand

Re: what about custom keys?

From: (Anonymous) - Date: 2011-10-20 08:09 am (UTC) - Expand

Re: what about custom keys?

From: (Anonymous) - Date: 2011-10-20 07:35 pm (UTC) - Expand

Re: what about custom keys?

From: (Anonymous) - Date: 2011-11-03 11:43 pm (UTC) - Expand

Re: what about custom keys?

From: [identity profile] jku.myopenid.com - Date: 2011-10-20 10:07 am (UTC) - Expand

Re: what about custom keys?

From: (Anonymous) - Date: 2011-10-20 06:56 pm (UTC) - Expand

Vendors? what about "write a bootloader"?

Date: 2011-10-20 03:49 pm (UTC)
From: (Anonymous)
Most of the talk around this is having this or that distro's key added. What about the core of the open source idea of being able to write your own bootloader?

My idea would be for the BIOS to just check the signature and set a read-only "verified/unverified" flag that the OS can check, not deny booting altogether. That way I can still boot an unverified OS and the ones that care can do their own "is this line secure" verification at boot time.

Granted, this is a little more insecure (if someone subverts the windows kernel for instance to fake the secure bit to be "on" at all times, but by allowing applications to check the flag directly it would still be caught by antiviruses), but it's relatively easy to implement by vendors and MS's certification team might be convinced to accept it (maybe under threat by monopoly laws?).

FSF's reaction of just chaining themselves to trees until the problem goes away would only serve to provoke more sneers in our direction and discredit the free software community only further.

Re: Vendors? what about "write a bootloader"?

Date: 2011-10-20 05:27 pm (UTC)
From: [identity profile] stuart.ward.myopenid.com
Well with this proposal that is easy, write your bootloader, create a key, sign the bootloader and then put the public key in boot media at the specified location. When you boot from the removable media the EFI will see the public key and import it. Job Done.

removable media are a pain

Date: 2011-10-20 09:34 pm (UTC)
From: (Anonymous)
Here, we handle everything using PXE boot. Having to use removable media would be a major step backward.

Re: removable media are a pain

Date: 2011-10-22 03:43 pm (UTC)
From: [identity profile] https://login.launchpad.net/+id/N3cBK3K
For PXE boot, your objection should be answered by the portion of the article talking about the system administrator setting up custom boot images and signing them for the clients.

About trust...

Date: 2011-10-21 08:59 am (UTC)
From: [identity profile] dklynx.wordpress.com
"The main difficulty involved in this is having the Linux key be managed by an authority that OEMs can trust to only provide keys to trustworthy organisations and maintain control of the private half of the key. Remember, if any malware is signed with any of these keys, it'll boot on any machine carrying this key. It's a lot of trust. It's not obvious that there's an organisation with sufficient trust at the moment."

Well... Personally I have a problem trusting Microsoft (and a couple of others) to care about the little user and not just about the big picture nessesary to follow the interest of investors.
I'm way past hating MS or thinking they want my soul or anything, but big companies seem to lose sight of a lot of things important to people who don't fit their profiles. It's not a matter of evil - just a mechanism that most huge companies suffer from IMHO.
A lot of these companies seem to act like it is ok to just put up a main seat in a country where they like the laws and follow these laws globally - ignoring local law (and sometimes even trying to enforce the laws they like in other parts of the world if it fits their own needs better than local law - double standard).

Anyway - My point is I don't belive MS or any other company with stratetical interests should be allowed to sit on the throne of this kind of signature. I have no simple solution though (and I don't belive it really exists).

I understand why MS wants to do this - from a security point of view - But I don't belive it will have much impact in real life unless it i dificult to disable. And if it is dificult to disable, it will be a MUST that other operating systems (like LINUX, BSD and others) have acceptable means of installing too - otherwise it will cause more trouble in the EU courtroom and hence cost everybody (both users, vendors, investors and all other taxpayers) a lot of money in the end.

Is any of this legal?

Date: 2011-10-21 01:11 pm (UTC)
From: [identity profile] https://me.yahoo.com/a/QlHe_jN.tZhYgsJKcQgAYqQ3xjM.55A-#cd9fc
The main problem I see is caused by Microsoft and their control over the hardware and potential blocking of users from access to their hardware and lock-in, of sorts, to Microsoft by hardware vendors. Yes, we talk of security needs and Microsoft potential cooperation and vendor cooperation and let's trust everyone to do that now and forever but does any of that have an awful smell to anyone but me?

Which governments do you trust?

Date: 2011-10-25 06:58 am (UTC)
From: (Anonymous)
If the Turkish government compelled Microsoft to include the Tubitak key in Windows so their intelligence services could do man-in-the-middle attacks on Kurdish MPs’ gmail, then they’ll also tell Microsoft to issue them a UEFI key to authenticate their keylogger malware. How do I identify and block all foreign governments’ UEFI keys?

Our Greek colleagues are already a bit cheesed off with Wall Street. How happy will they be if in future they won’t be able to install the software of their choice on their PCs, but the Turkish secret police will? See


Major Question

Date: 2011-11-21 12:21 am (UTC)
From: (Anonymous)
What prevents the bad guys from buying a machine and doing hardware forensics to obtain the hidden part of the key? After all wouldn't mass produced machines share at least a few common keys?

If they can then wtf? They could do just as much good reviving the bios deny write to boot sector switch. I had in an old PC.

If you have a modern PC and you want security then don't install any extra software in fact strip down all the fat only do security updates and have no other software on your PC other than Virtualbox and run everything from a virtual environment. I would like to find an OS that's only purpose is to provide base Hardware support for Virtualbox.
From: (Anonymous)
All that Microsoft would have to do is provide an appropriately signed boot-loader, which then loads Windows 7 (or whatever).


Matthew Garrett

About Matthew

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

Expand Cut Tags

No cut tags