19

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?

Iszi
  • 26,997
  • 18
  • 98
  • 163

3 Answers3

10

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.

Perseids
  • 232
  • 2
  • 10
  • 2
    Doesn't allowing the OS to push CRLs to the BIOS actually compromise Secure Boot? I thought the whole idea was that nothing at the OS level should be able to define what is to be trusted at lower levels? – Iszi Jun 19 '12 at 19:56
  • Also, thanks for pointing me to that Matthew Garrett article. It's interesting that it was actually some of his other articles which inspired this question, and yet I'd somehow not gotten to that particular one. – Iszi Jun 19 '12 at 19:57
  • 1
    @Iszi: The CRLs should be signed by Microsoft and are therefore easily verifiable by the UEFI Bios. – Perseids Jun 19 '12 at 20:07
  • "_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._" Yes, it is a very convenient DOS. – curiousguy Jun 19 '12 at 20:07
  • "_The CRLs should be signed by Microsoft_" what if I don't use MS? – curiousguy Jun 19 '12 at 20:08
  • @curiousguy Then the CRLs will be signed by whatever authority signed the certificates you *do* use, and (absent that authority providing their own built-in updating mechanism - and who really wouldn't?) you'll probably need to be responsible for keeping up with those lists yourself. – Iszi Jun 19 '12 at 20:14
  • 2
    @curiousguy: To be more precise, they should always be signed by the root key the CRL is referring to. – Perseids Jun 19 '12 at 20:15
  • But of course, BIOSes can and have been exploited and so this avenue of added complexity will inevitably also enable attacks. – pepe Jun 19 '12 at 20:36
  • @Pepe: You're right, but that is a general problem of UEFI and not specific to secure boot. – Perseids Jun 19 '12 at 20:43
  • 3
    @Perseids: In contrast to, e.g., Trusted Boot, Secure Boot mandates a remote update functionality, adding an attack vector to the API exposed by the BIOS/UEFI. It is a principal restriction of Secure Boot that the code/signatures must also be validated at these levels, requiring corresponding infrastructure for update/maintenance. In Trusted Boot, the Firmware can simply always write every measured value to the TPM and does not care about anything else. – pepe Jun 19 '12 at 20:53
  • 2
    @Pepe: Afaik UEFI offers quite a lot of "runtime services" which already offer a far greater attack surface than the secure boot update functionalities need. The whole of UEFI is basically a nightmare of [vast amounts of untested code](http://mjg59.dreamwidth.org/10014.html) with low incentives to fix any security holes. The only consolation I see is that it will be difficult to write portable malware that can exploit bugs on different implementations. – Perseids Jun 19 '12 at 22:00
  • @Perseids: I mostly agree. Only underlines my point that they (again) chose the wrong technology here. Even though better alternatives are already deployed and sometimes even used. – pepe Jun 20 '12 at 14:08
  • Any problems I have with UEFI I place on the working group responsible for the UEFI standards itself. I feel that Secure Boot solves a problem( at least partialy ) cannot be solved without it. – Ramhound Jun 20 '12 at 15:30
  • Let me repeat: "better alternatives are already deployed and sometimes even used". The only reason to choose Secure Boot here is when you actually *want* to have the option for vendor lock-in. Since we're moving away from general-purpose PCs, this is probably exactly the intention. Note that a secure-boot-style lock-in is also completely unacceptable for servers. You think they ignore such huge market by accident? And due to completely different goals, there's also no point in complaining in this WG. There will be alternative solutions. – pepe Jun 22 '12 at 08:15
5

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.

zedman9991
  • 3,377
  • 15
  • 22
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 :-)

Rory Alsop
  • 61,367
  • 12
  • 115
  • 320
pepe
  • 3,536
  • 14
  • 14
  • The comments here were not helping in any way. I have removed them, and slightly reworded the initial tone of the answer. Comments should not be used for chat - get on over to the DMZ for that. – Rory Alsop Jul 10 '12 at 21:21
  • "_Obviously, they have different goals in mind than security._" you can't say which one? – curiousguy Jul 11 '12 at 01:25
  • 1
    The actual reason is up to speculation. As I wrote in a recently deleted comment, I think they simply want to have the same functionality as is currently implemented and used in ARM-based mobile devices, for anti-competitive or simply for legal reasons. This is the new market, and in a few years probably many people won't have or need a general-purpose PC/laptop anymore. (example for legal reasons would be to protect against modification of 3G drivers as required AFAIK by FC) – pepe Jul 11 '12 at 12:11