8 Jun 2012 mjg59   » (Master)

The security of Secure Boot

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.

comment count unavailable comments

Syndicated 2012-06-08 03:56:15 from Matthew Garrett

Latest blog entries     Older blog entries

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!