[personal profile] mjg59
The other complaint about UEFI Secure Boot is that it doesn't add any security. There's two aspects to this - people either think it'll be quickly broken, or people think that the public availability of signing services will render it useless.

Will Secure Boot be broken?

Almost certainly, yes. I'd put a significant amount of money on it. The most obvious avenue of attack is probably a malformed FAT on a USB stick, or alternatively a programmable USB device that can trigger undesired behaviour in the USB stack. If you're really lucky then you might be able to corrupt the filesystem on the EFI system partition in such a way that this happens on every boot, even if there's no USB hardware connected. It's possible that there'll be a bug in the binary validation process and a cleverly designed binary may be able to validate even though it contains unsigned code. Various vendors will probably manage to produce signed option ROMs that rely on unsigned data in such a way that they can be forced to misbehave. But most of these attacks will either involve physical access or depend on the target machine having a specific piece of hardware installed, and I'd also put money on each of them being quickly fixed once they're found. And, eventually, people will run out of new attacks.

People desperately want to believe that the Secure Boot implementation is fundamentally broken, and that's just not true. It's based on well-tested encryption technology. You calculate a SHA256 of the binary you want to sign. You encrypt that hash with the private half of a 2048-bit RSA key. You embed the encrypted hash in the binary. When someone tries to run the binary you decrypt the hash with the public key in your firmware. You then calculate the hash of the binary and compare the two. If they match then you know that (a) whoever signed the binary had access to the private half of a key you trust, and (b) the binary hasn't been modified since then.

The difference between Secure Boot and things like CSS or WEP is that Secure Boot uses existing cryptographic techniques and has been designed by people who actually understand how they work. Precisely the same technology is used in Microsoft's driver signing, and people decided it was easier to steal a key from Realtek than it was to break the underlying technology. Unless there's a crippling bug in the implementation that nobody's noticed yet, the only real way to attack this is to either force a SHA256 collision (achievable with current technology, as long as you're willing to spend many orders of magnitude more time than the universe has existed) or break RSA (which would also mean that SSL is broken). If anyone can do either of these things then we are so unbelievably fucked that Secure Boot should not be the thing you're most worried about.

So, in summary: Yes, Secure Boot will be broken. And then it will be fixed. And after this happens a few times, there will be no further breaks.

Everyone can sign, so what's the point

Anyone can pay $99 and get their binaries signed. So why won't malware authors just do that? For starters, you'll need to provide some form of plausible ID for Verisign to authenticate you and hand over access. So, sure, you provide some sort of fake ID. That's the kind of thing that tends to irritate local authorities - not only are you talking about breaking into a bunch of computers, you're talking about committing the sort of crime that results in genuinely bad things happening to you if you get caught. And secondly, the only way you get access to the system is using some physical smartcards that Verisign send you. So you've also had to hand over an actual physical address, and even if you've used some sort of redirection service that's still going to make it easier to track you down. You're taking some fairly significant real-world risks.

But ok, you're willing to do that and you obtain a signing key and you sign some malware. You'll infect some number of machines. But eventually you'll be noticed, and then Microsoft produce a key revocation blob and vendors push it out via their OS update mechanisms. If your malware was basically harmless then that's probably the end of it, but if you were using it as the basis for an attack on people's banking details then a lot of people are suddenly going to be very interested in the person who bought that key, and also your malware isn't going to be able to infect any more machines.

To put this in perspective - Windows is the dominant desktop operating system. If you want to run a botnet or steal people's bank details then Windows is the obvious thing to attack. Windows security has now improved to the point where it's not massively straightforward to do that from userspace, so the logical thing to do would be to run your malware in the kernel. The easiest way to do that would be to load a driver, but Windows won't load unsigned drivers. So you'd need a signed driver. How do you get one? With the same $99 access to the Microsoft signing service that you'd use for signing an EFI binary.

Anyone could already use the signing service to attack Windows. But people haven't. The Stuxnet authors thought it was easier to steal a key from a real hardware vendor than it was to buy their own key. So, yes, in theory an attacker could obtain signing services. But the real world evidence suggests that that's not how they behave.


Secure Boot is unlikely to be broken via fundamental flaws in its implementation, and there's no evidence that public availability of the signing service will result in an explosion of boot level malware.

Date: 2012-06-08 04:35 am (UTC)
From: (Anonymous)
If there is a public signing service out there, there will be a lot of signed keys. A lot of opportunity for keys to be stolen.

Also, how much would it suck to own hardware that has its keys revoked and a hardware vendor that it unresponsive to getting you updated firmware?

- Russ

(no subject)

From: (Anonymous) - Date: 2012-06-08 07:34 am (UTC) - Expand

(no subject)

From: (Anonymous) - Date: 2012-06-08 02:12 pm (UTC) - Expand

(no subject)

From: (Anonymous) - Date: 2012-06-08 02:31 pm (UTC) - Expand

Its public business

From: (Anonymous) - Date: 2015-10-21 05:38 am (UTC) - Expand


Date: 2012-06-08 05:17 am (UTC)
From: (Anonymous)
UEFI will be broken first. UEFI is basically an OS in its own right and has more lines of code than the Linux kernel, there's bound to be bugs to exploit.


From: (Anonymous) - Date: 2012-06-08 06:50 am (UTC) - Expand

Date: 2012-06-08 07:32 am (UTC)
From: (Anonymous)
And when SHA-256 get's broken what happens? The best public cryptanalysis had 41 of 64 rounds in SHA-256 figured out 4 years ago. Where do we think the NSA has got with that? We already know they have unpublished attacks against MD5 that are better than anything else out there thanks to Flame.

Secure Boot is going to do exactly nothing to stop the NSA. They can just ask Verisign for signed binaries using the key of unsuspecting Asian manufacturer. In fact, if I was a non-US organisation I'd consider Secure Boot a massive threat for exactly this sort of reason. Suddenly all my trust infrastructure is based on trusting the Verisign and the US government not to screw me? No thanks.

Date: 2012-06-08 08:24 am (UTC)
From: (Anonymous)
Well you are all missing a point a "broken secure boot" is basically what we have now.
i.e you can run any software.

(no subject)

From: (Anonymous) - Date: 2012-06-08 09:35 am (UTC) - Expand

Date: 2012-06-08 12:50 pm (UTC)
From: (Anonymous)
Then, after a short period of vulnerability where the extremely rich can get past secure boot, everybody will migrate to SHA-512. The implementation already supports multiple hash methods and secure updates; this won't remain a problem for very long at all.

Quickly Fixed? I don't think so.

Date: 2012-06-08 07:39 am (UTC)
From: (Anonymous)
You said, "....quickly fixed once they're found"

I don't think they will be quickly fixed. Unlike the game consoles, motherboard vender don't have any real reason to keep it "secure". They do this only because this is a Microsoft requirement. Unless MS is going to break every vendor with unfixed bug, nobody will go to fix this.

What happens if Microsoft's keys are stolen?

Date: 2012-06-08 10:43 am (UTC)
From: (Anonymous)
I wonder what can happen in such scenario.
I mean, suppose that Microsoft's keys are stolen and used to sign malware, Microsoft will revoke that keys and provides to HW vendors the updated keys, but probably not all of them will provide a firmware update with the keys, or maybe the user doesn't know what the heck is a "firmware update" and how to do it (in fact, some HW vendors doesn't responsible about firmware updates).

In that case, will the user be locked down with a computer that can't boot even the OS that was shipped with?

What am I missing here?

Re: What happens if Microsoft's keys are stolen?

From: (Anonymous) - Date: 2012-06-09 04:34 pm (UTC) - Expand

Depends on Microsoft

Date: 2012-06-08 01:32 pm (UTC)
From: (Anonymous)
I mostly agree with the first part, maybe I just have a not so good opinion of firmware anyway and UEFI is in the firmware world very very complicated. I have seen the phrase "code to specification" a couple of times, but in the real world cheaply trained monkey teams will push their code through shortly after "it works".

The second part depends on Microsoft actions. It is hard to say whether you are right or wrong, it depends on what Microsoft will do. And I find the part where you reason about why the signing service was not used for attacks a bit funny, because the was never a reason to go to such extremes as far as I know.

Date: 2012-06-08 01:45 pm (UTC)
From: (Anonymous)
No offence dude but seriously, just leave and go work for Microsoft. It is clear that you are paid by them already. I wish we could vote you off this project.

You have to have an open mind. The security of Secure Boot (Reply)

From: (Anonymous) - Date: 2012-06-09 04:38 pm (UTC) - Expand
From: (Anonymous)
I assume MS will happily and quietly hand out keys to government agencies, that would like to boot "slightly" modified versions of popular OS's for a variety of "legitimate" reasons.

Re: Policy for handing out keys to foreign and domestic agencies.

From: (Anonymous) - Date: 2012-06-08 02:33 pm (UTC) - Expand

Re: Policy for handing out keys to foreign and domestic agencies.

From: (Anonymous) - Date: 2012-06-09 04:46 pm (UTC) - Expand

UEFI, Microsoft, and Paranoia

Date: 2012-06-08 01:53 pm (UTC)
From: (Anonymous)
I don't believe a UEFI secure boot proposal is a bad thing for the community, at least on the face of it so to speak. I agree with some previous discussions I have read the past couple of days, that it has to be as "painless" as possible for the "average Joe/Jane" user. Also, for those who don't want it, just don't enable it! I really don't see the problem there.

As for Microsoft, they are a very large corporation, who commands the PC user OS market. The hardware vendors cater to MS since they are the predominant OS used by most. Not to mention all of their other offerings, in the user SW area. OK nothing new said there. What I would like to say about MS is more about this community than them anyway, and that is... It is good to have a healthy paranoia towards MS motives and dealings with us. Although I don't see secure boot as any form of compromise in the FOSS community, I do see it as a potential step in a direction that may limit our freedom of choice. So keep questioning what this means to us in the open source community, and be on your guard for the inevitable caveat that MS will throw at us (think IBM and OS/2 days). MS after all has to produce profits for their investors, likely has a MANY year plan of where they want to be in the market, no doubt has a strategy for dealing with the open source community, and likely its desired demise. It is important to remember that the word "free" is a four letter word in the business community.


Date: 2012-06-08 02:17 pm (UTC)
From: (Anonymous)
How many revoked keys are implementations required to handle? Unless that's a fairly big number, the revocation can be effectively DoS'd.

T/F? A nasty piece of software could brick the computer by revoking the Microsoft key.

OS update mechanisms

Date: 2012-06-08 02:25 pm (UTC)
From: [identity profile] http://pointless.net/openid/jasper/
Whats going to happen on the Linux side of things with the EFI update mechanisms?

How do linux users get the blacklist of signatures and updated firmware? Is this managed centrally via Microsoft and there is some mechanism for distros to get the updates so they can package and distribute them?

Alternative to Microsoft?

Date: 2012-06-08 03:22 pm (UTC)
From: (Anonymous)
Wouldn't it be slightly cooler of Intel could take responsibility for the signing service? Due to the way the world currently works, I suspect this could only work if Microsoft made the hypothetical Intel key a requirement for Win8 certification.

You would break it indirectly

Date: 2012-06-08 05:41 pm (UTC)
From: (Anonymous)
What an attacker could do is get a trusted party to sign application code that legitimately needs privilege to run, but that contains a flaw (or back door). Once the app is installed, the person who introduced the back door would then be able to attack the system. The party that signs the app might not even know; the bad guy (or national government) might arrange for a contractor to introduce the hole in an application that is officially signed by a company that knows nothing.

Kinda lost me there on the revocation

Date: 2012-06-08 08:26 pm (UTC)
From: (Anonymous)
You mean that the same manufacturers that seldom fix glaring BIOS bugs (just as long as windows boots, nothing else matters) would be enthusiastically updating your BIOS images with new revocation lists? The problem isn't on the OS level, where you have auto-updates whizzing in every fifteen minutes.

You seem strangely happy to suggest that everyone should pay microsoft $99 to use their own computers.

I do agree that the only way to secure the boot is either to control the whole platform (like Apple) or take a strong stance with the manufacturers (like Microsoft is now trying). Do I support it? No. If I have to choose between malware or windows, I stick with the lesser evil and ditch windows.

Only thing this secure boot debacle has me looking forward to is the anti-monopoly lawsuit.


Date: 2012-06-09 01:57 am (UTC)
From: (Anonymous)
Can I haz 'secure boot' ?

Not the MS/fedora/RHEL/Verisign 'secure boot' concept, but just a _standard_ one.

This is like fighting to break the work of hundreds of voluntaries on open source across many years.

I just can call to massive boicot when you purchase hardware.

MS has been proved to be owned by multiple channels (DNS, TCP, DHCP, rendering a font (that can be loaded by html5), etc etc etc)... All this is not about security, all this is about monopoly and 'legal' (in USA) trojan horses.

Boicot could be much better than this holy shit. There are too much things to fix, to be working in support this.

¿More code than the kernel to boot the machine? ¿centralized (and pay for) signatures? ¿user space updates touching the signatures? ... Please stop it, and/or boicot it.


Date: 2012-06-09 08:05 pm (UTC)
From: (Anonymous)
Dear Microsoft haters, I won't be glad when you are all dead, but I will be glad when you are all gone.


UEFI Sec boot on/off

Date: 2012-06-10 02:43 pm (UTC)
From: (Anonymous)
First you should meantion, that UEFI specification includes a definition of a feature to turn secures boot on and off. Vendors may not provide it, which I would expect to happen on vendors like Sony, where they do not support any "options". But most of the HW producers will IMHO enable the Secure Boot to be switched off as this is advantage for nothing and they avoid a flood of "your hardware is broken" questions.

Anyway, there is always a single assembler instruction in the code to switch from "hash is valid" to "hash is not valid"...

Re: UEFI Sec boot on/off

Date: 2012-06-11 05:11 pm (UTC)
From: (Anonymous)
"First you should meantion, that UEFI specification includes a definition of a feature to turn secures boot on and off. Vendors may not provide it"

The Windows 8 certification requirements absolutely require the ability to turn Secure Boot off. Matthew has already stated this several times.

Re: UEFI Sec boot on/off

From: (Anonymous) - Date: 2013-03-05 04:54 am (UTC) - Expand

UEFI Sec boot on/off - In Jeopardy!

From: (Anonymous) - Date: 2013-03-05 05:46 am (UTC) - Expand


Date: 2012-06-14 06:41 pm (UTC)
From: (Anonymous)
After all the negative comments I read, I just wanted to say thanks for this very informative post. It answered all the questions I had reading "Implementing UEFI Secure Boot in Fedora". It even convinced me that Secure Boot will not be the disaster it set out to be.

From: (Anonymous)
Lets say you restrict your system to allow only signed binaries, why should that increase security so much? Currently there are attacks which change the bootloader mainly to store encryption keys to get access later. When you don't use encryption you gain absolutely 0. As soon as you are allowed to boot external media you can boot an official ms install media as well - and as everybody should know - you have got access to all data on the hd as well with it (until it is encrypted), just start a console.

So lets say MS gives away a the signing key for whatever amount of money, what impact would it have got? None. The only thing that changes is that you are allowed to boot different live systems without disabling Secure Boot. Your data will not be more secure.

So lets look a bit at shim, the simple bootloader that adds a sha256 check before executing a (grub) efi binary as suggested by mjg59. Well does that gain anything? No, grub has got an edit mode that allows you to bypass every password on an unencrypted system. You might think, well then put a restricted grub.efi on the efi partition. Nice thought, but you will most likely use grub to boot a live system as well. There you _need_ the edit mode, so an attacker could just boot live. Btw. as any signed efi binary would work you could exchange it as well. It just needs to be signed - wow...

Lets say it would help to secure a system with enabled encryption. This _might_ help when there is no way to get a custom signed binary. Then maybe bitkeeper would be a tiny bit more secure. I doubt that for Linux solutions as the logic is in the initrd. You could still modify that even if you could not load a modified kernel module (i still want to see that working). It is very unlikely that you can sign your initrd or you have to store the public key for that unencrypted somewhere. So what did you gain this time? Maybe a tiny bit in the case that you could _not_ sign your own binaries. If you can do and use an initrd, that will be the weak point (and it was the weak point before as well).

So what can you do? Rely on hardware encryption if you need full security. Forget secure boot, it will not be more secure. All you can use it for is that you can not boot other systems that easyly (just like on the arm plattform).
From: (Anonymous)
Btw. is there any confirmation that signing an efi binary will have got any effect? The signing service is for kernel drivers not for efi bootloaders usually. Until you provide a video i doubt it.


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