The security of Secure Boot
Jun. 7th, 2012 11:05 pm
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.
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.
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.
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.
no subject
Date: 2012-06-08 04:35 am (UTC)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
Date: 2012-06-08 04:41 am (UTC)(no subject)
From: (Anonymous) - Date: 2012-06-08 07:34 am (UTC) - Expand(no subject)
From: mjg59 - Date: 2012-06-08 11:34 am (UTC) - Expand(no subject)
From: (Anonymous) - Date: 2012-06-08 02:12 pm (UTC) - Expand(no subject)
From: mjg59 - Date: 2012-06-08 02:23 pm (UTC) - Expand(no subject)
From: (Anonymous) - Date: 2012-06-08 02:31 pm (UTC) - Expand(no subject)
From: mjg59 - Date: 2012-06-08 02:33 pm (UTC) - ExpandIts public business
From: (Anonymous) - Date: 2015-10-21 05:38 am (UTC) - ExpandUEFI
Date: 2012-06-08 05:17 am (UTC)Re: UEFI
Date: 2012-06-08 05:23 am (UTC)Re: UEFI
From: (Anonymous) - Date: 2012-06-08 06:50 am (UTC) - Expandno subject
Date: 2012-06-08 07:32 am (UTC)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.
no subject
Date: 2012-06-08 08:24 am (UTC)i.e you can run any software.
(no subject)
From: (Anonymous) - Date: 2012-06-08 09:35 am (UTC) - Expandno subject
Date: 2012-06-08 12:50 pm (UTC)Quickly Fixed? I don't think so.
Date: 2012-06-08 07:39 am (UTC)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)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?
Date: 2012-06-08 11:36 am (UTC)Re: What happens if Microsoft's keys are stolen?
From: (Anonymous) - Date: 2012-06-09 04:34 pm (UTC) - ExpandDepends on Microsoft
Date: 2012-06-08 01:32 pm (UTC)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.
no subject
Date: 2012-06-08 01:45 pm (UTC)no subject
Date: 2012-06-08 02:03 pm (UTC)You have to have an open mind. The security of Secure Boot (Reply)
From: (Anonymous) - Date: 2012-06-09 04:38 pm (UTC) - ExpandPolicy for handing out keys to foreign and domestic agencies.
Date: 2012-06-08 01:45 pm (UTC)Re: Policy for handing out keys to foreign and domestic agencies.
Date: 2012-06-08 01:50 pm (UTC)Re: Policy for handing out keys to foreign and domestic agencies.
From: (Anonymous) - Date: 2012-06-08 02:33 pm (UTC) - ExpandRe: Policy for handing out keys to foreign and domestic agencies.
From: mjg59 - Date: 2012-06-08 02:37 pm (UTC) - ExpandRe: Policy for handing out keys to foreign and domestic agencies.
From: (Anonymous) - Date: 2012-06-09 04:46 pm (UTC) - ExpandUEFI, Microsoft, and Paranoia
Date: 2012-06-08 01:53 pm (UTC)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.
Revocation
Date: 2012-06-08 02:17 pm (UTC)T/F? A nasty piece of software could brick the computer by revoking the Microsoft key.
Re: Revocation
Date: 2012-06-08 02:24 pm (UTC)The only way any software could revoke the Microsoft key would be to have Microsoft's private key.
OS update mechanisms
Date: 2012-06-08 02:25 pm (UTC)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?
Re: OS update mechanisms
Date: 2012-06-08 02:32 pm (UTC)Alternative to Microsoft?
Date: 2012-06-08 03:22 pm (UTC)Re: Alternative to Microsoft?
Date: 2012-06-08 03:44 pm (UTC)You would break it indirectly
Date: 2012-06-08 05:41 pm (UTC)Re: You would break it indirectly
Date: 2012-06-08 05:56 pm (UTC)Kinda lost me there on the revocation
Date: 2012-06-08 08:26 pm (UTC)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.
Re: Kinda lost me there on the revocation
Date: 2012-06-08 09:55 pm (UTC)SECURE FOOL
Date: 2012-06-09 01:57 am (UTC)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.
Idiot
Date: 2012-06-09 08:05 pm (UTC)-RMS²
UEFI Sec boot on/off
Date: 2012-06-10 02:43 pm (UTC)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)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) - ExpandUEFI Sec boot on/off - In Jeopardy!
From: (Anonymous) - Date: 2013-03-05 05:46 am (UTC) - ExpandThanks
Date: 2012-06-14 06:41 pm (UTC)Perseids
Why should Secure Boot increase security when it is possible to boot external media
Date: 2012-07-25 02:42 pm (UTC)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).
Re: Why should Secure Boot increase security when it is possible to boot external media
Date: 2012-07-25 02:50 pm (UTC)Can you REALLY sign efi binaries to bypass secure boot?
Date: 2012-07-26 09:48 am (UTC)reading all these old comments
Date: 2018-05-17 08:22 pm (UTC)microsoft/mjg59 - 0
everybody else - 1
Re: reading all these old comments
Date: 2018-05-17 09:06 pm (UTC)