How secure is Microsoft-mandated UEFI Secure Boot, really?

Question

I've read a few articles recently about the UEFI Secure Boot feature, and how Microsoft will be requiring it to be enabled by default on all Windows 8 certified x86 systems. In theory, it sounds like a good idea - the system will check the boot loader for integrity before every boot. However, it also provides some complications.

The primary problem arises when someone wants to run a non-Microsoft OS on Windows 8 certified x86 hardware. Since the hardware will have Secure Boot enabled, and will likely only have Microsoft's key installed by default, the user has to work around the problem in one of a several ways:

1. Disable Secure Boot - This is, of course, the least ideal solution. However, for some, it may be the only available option.
2. Install a custom certificate - An option for the technically inclined, but not likely one that normal end-users will easily consider.
3. Choose an OS with a boot loader signed by Microsoft - This is probably the most end-user friendly, though it may limit your options. Fedora has announced that they will be among these options. This requires no modifications to the UEFI or mucking about with custom certificates - you just install the Microsoft-signed OS and go.
4. Get your boot loader signed by Microsoft - Perhaps the least preferable option, since it has an actual cost to it ($99 one-time fee). However, it's useful if you're making your own distro and want to share it with friends.

Those last two options are really my point of concern, though. If it only costs $99, one-time, to have the privilege of Microsoft signing all your boot loaders, is it really that big of a barrier to malware writers who stand to make millions off of their Microsoft-signed rootkits?

Is there something I'm missing here, or could this Secure Boot requirement (and all that's been built up to support it) really lead to false sense of security enhancement? What sort of complications could arise if the system is in fact abused in this way? Will we have to update our UEFIs every time a new CRL gets published?

Answer 1

Matthew Garrett has some nice blog posts on UEFI Secure Boot. Concerning your question he writes:

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.

Storing the access credentials for your key on a smartcard was the bit of new information that convinced me that UEFI Secure Boot is not only security theater. As Matthew said it makes you more traceable. It also significantly reduces the probability of theft, which would have been the smart way to get your rogue signing key in my opinion.

It is still quite probable that signed malware will pop up. But large scale attacks will be easier to mitigate, first by revoking the signing key and second by tracing the signer via his or her physical address.

The system is not perfect (and falls quite short compared to what would have been achievable) but it will make writing bootkits more difficult. And in the same way that ASLR and the NX bit make us a bit more safe against malware even though buffer overflow attacks are still viable, secure boot is not a completely waste of time.

Concerning the CRL I have heard there will be a standard UEFI interface for the OS to push new revocation lists into the bios. That will make automatic updates very convenient.

Answer 2

Real security enhancements are created if you are buying for a commercial or governmental enterprise but at a cost related to supportability. For the majority of home users who want nothing more than a Microsoft desktop and never modify their purchased system it will also provided added security. For the home user that wants to dual boot (a very small market force) it will complicate life and provide little or no security enhancement as the features will be disabled by definition.

Consider the context in which this trusted boot paradigm with its validation of fundamental components on the way up in the boot process will be used. If you are responsible for securing a large enterprise the features will be very attractive and add greatly to your tool set for doing your job. You will have a strong incentive to purchase the OS and enabled hardware to lock down your enterprise.

If you are a home user who wants to dual boot into Linux it's a major pain. Of course you have physical control of your home system and will be able to disable the feature. It further complicates your Linux experience.

Security is added for those who have physical control of their system(s) and a desire to limit the effectiveness of virtual attacks which modify fundamental components of the OS.

There are many features beyond security that come with this solution. For one, administration complexity will increase as these systems will be harder to upgrade and modify. It also creates a walled garden effect for an OS known for broad support at a time when that OS is competing against a walled garden OS. Additionally user anonymity will be diminished. Market forces today favor walled gardens and loss of anonymity.

The concern of the Linux community is that this change makes it more difficult for users to casually move to Linux. That is a valid concern. It is not however a security concern. In terms of security, for the vast majority of users it will enhance security.

Answer 3

Secure Boot for PCs is inflexible and leaves you with few options if your system is somehow broken. It is also not designed to scale in an environment with multiple stakeholders - say your company wants to use Secure Boot to ensure not only a proper windows installation but also a set of certain policy-enforcing tools. Not possible out of the box.

Trusted Boot, where the components are measured but only optionally verified later on, was precisely invented because of these limitations. Hence, the fact that Microsoft requires a different mechanism despite themselves being part of the standards committee that defined Trusted Boot is stupid from a technical point of view (making bad decision despite knowing better). Obviously, they have different goals in mind than security.

The best way to use Secure Boot is to load a neutral policy-enforcement engine, like an open source hypervisor, which then measures and loads further components in a Trusted Boot fashion. This way you have all the flexibility but don't actually need the hardware TPM, only the hope that this hypervisor will remain secure and correctly reports what is going on. The design is known for many years but of course MS has zero interest in providing such a neutral solution.

Coming to your question, the signing of code is most easily secured by properly checking who is requesting the code to be signed. This seems reasonable for a cost of $99. Malware writers probably won't be so keen to provide their ID, and open source boot loaders are sufficiently stable and secure to maintain a good reputation. It also means that it won't help at all against government-level espionage and the upcoming cyberwars. The customers will be the only ones who don't have a key :-)