The security of Secure Boot
Jun. 7th, 2012 11:05 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
mjg59The 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.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
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)UEFI
Date: 2012-06-08 05:17 am (UTC)Re: UEFI
Date: 2012-06-08 05:23 am (UTC)Re: UEFI
Date: 2012-06-08 06:50 am (UTC)Who are you, and what have you done to the real Mjg59?
no 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 07:34 am (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.
no subject
Date: 2012-06-08 08:24 am (UTC)i.e you can run any software.
no subject
Date: 2012-06-08 09:35 am (UTC)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?
no subject
Date: 2012-06-08 11:34 am (UTC)Re: What happens if Microsoft's keys are stolen?
Date: 2012-06-08 11:36 am (UTC)no subject
Date: 2012-06-08 12:50 pm (UTC)Depends 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)Policy 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)UEFI, 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.
no subject
Date: 2012-06-08 02:03 pm (UTC)no subject
Date: 2012-06-08 02:12 pm (UTC)What happens when other signing companies complain about Verisign having a monopoly on signing secure boot? And demand that their CA's public key be included?
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.
no subject
Date: 2012-06-08 02:23 pm (UTC)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?