I think the issue most people take with it is the ability of the manufacturer to lock down what a user could do with the hardware they paid for. In my mind it's similar to Apple's hold on the iPhone hardware(whether or not that's still the case I don't know, I haven't kept up on it in a while) - but with general purpose computers.
Also, my mention of the issue stemming from the higher-level realm is founded in the idea that exploitation of a device's firmware can't take place without either A) physical access or B) exploitation of higher level software to work its way down. As I mentioned I'm no expert, so I don't know if there are other methods available to attackers. Please elaborate if there are.
I don't understand your point. If higher level software is exploited, they don't need physical access and not only are you screwed, without Secure Boot, you have no way of knowing you're screwed.
Again, Microsoft is not locking down what you can do. It's a feature of UEFI that is there to protect users. The ONLY way that Microsoft intersects with this is that they have the privilege of being pre-enrolled on computers, because let's face it, 99.999% of people buy computers with Windows on them and they expect it to run. Not that they have to boot into a special OS, enroll keys and install Windows themselves. (Again, see my earlier post about how they can disable Secure Boot or enroll their own keys)
With Secure Boot, your bootloader can't be compromised. Not even with physical access, not even with a higher level software escalation. That's kind of the point. I'm not sure how else to explain it. You basically named the only two ways to affect a computer, so I really don't know what you're getting at, I guess.
Downvotes for explanations, jeez. If your takeaway is that I don't believe in personal device freedom, you're either not understanding the issues at hand, or you've conveniently ignored the explanation I offer in this post.
You aren't getting downvoted for explaining, you're getting downvoted
for the ridiculous assertion that we need to throw out basic Freedoms
like the ability to do whatever the fuck with hardware we own (including
running whatever the fuck we want on it) because there's a chance we
might be compromised.
Those who would give up essential liberty
to purchase a little temporary safety
deserve neither liberty nor safety.
You can run whatever you want. If you don't care about security, go to the firmware settings and turn off secure boot. If you do care about security, go to the firmware settings and add your own key, and then sign the boot loader for your operating system with the corresponding key.
1. This isn't about Microsoft having control. This is the only way to ship devices with Secure Boot enabled. What do you suggest exactly? That OEMs ship with Secure Boot enabled but without MS keys? Great. Everyone goes out, buys a new Windows laptop... and Windows doesn't boot.
2. You conveniently ignored everything about being able to disable it and enroll your own keys.
Your false ad hominem attack is insulting and wildly inaccurate. You'll note that I don't defend the use of Secure Boot on ARM where user-key-enrollment is forbidden. Not only is it insulting because it's blatantly ignoring half of my last post, it's also insulting because I've spent years campaigning against things like the Patriot Act with that quote and I'm well aware of the sentiment and enjoying freedom on my personal devices (as I tout my Galaxy Nexus with CM9 and unlocked bootloader).
> The ONLY way that Microsoft intersects with this is that they have the privilege of being pre-enrolled on computers, because let's face it, 99.999% of people buy computers with Windows on them and they expect it to run. Not that they have to boot into a special OS, enroll keys and install Windows themselves. (Again, see my earlier post about how they can disable Secure Boot or enroll their own keys)
99.999% of people buy computers with preinstalled windows. If they are computer-litrate enough to install windows, they are literate enough to authorize a new Windows boot sector (the hash/fingerprint of would be printed on a new Windows media or sticker).
I wouldn't have a problem with Microsoft's preinstalled key if I had reason to believe this will work well when you authorize other keys. But so far, no manufacturer cares that anything other than Windows works on their machine/bios, and I wouldn't be surprised if adding more secure boot keys is somehow broken (the way a lot of BIOS power-management/apic tables are broken and no one cares because they work well enough on Windows)
> With Secure Boot, your bootloader can't be compromised. Not even with physical access, not even with a higher level software escalation.
I have a bridge in Brooklyn that I'm willing to sell for a good price if you believe that.
Yes, it will be harder to do, but ...
PS3, XBox, XBox 360, Wii, iPhone {2G,3G,3GS,4,4S}, iPad {1,2} and many other devices all have secure boots. And all have, in the past, been rooted by software or a combination of software and minimal physical access. (Of these, I think only the XBox 360 required physical access after two months has passed since the first boot exploit was released).
>99.999% of people buy computers with preinstalled windows. If they are computer-litrate enough to install windows, they are literate enough to authorize a new Windows boot sector (the hash/fingerprint of would be printed on a new Windows media or sticker).
I wouldn't have a problem with Microsoft's preinstalled key if I had reason to believe this will work well when you authorize other keys.
I'm assuming that you didn't understand what I wrote. For pre-installed Windows to work, it has to have the Microsoft keys enrolled. That's why their keys come preinstalled. If they weren't preinstalled, Windows wouldn't boot. That was my point about the 99.99%. I'm not sure what you're getting at, I assume you didn't understand. (And no, pressing "Next", "next", "next" in an installer is not the same as enrolling private keys into a write-only area of your computer's BIOS).
>I have a bridge in Brooklyn that I'm willing to sell for a good price if you believe that.
Ok, I'll put you in the category of people that swore for years that Motorola's bootloader protection would be hacked. That was... 3 years now since they introduced that and nary a vulnerability found?
>PS3, XBox, XBox 360, Wii, iPhone {2G,3G,3GS,4,4S}, iPad {1,2} and many other devices all have secure boots. And all have, in the past, been rooted by software or a combination of software and minimal physical access.
Oh, you just don't know what you're talking about (or what Secure Boot is, one of the two). Only the Xbox 360 had boot verification in the style of secure boot and it was never compromised. [1] The others did NOT use a hardware based bootloader verification. The only other mainstream usage of this style (that I'm aware of) is Motorola's signed bootloaders
[1] While the Xbox was attacked via Hypervisor vulnerability, a timing attack found (both of which were fixed remotely) and now through electroshocking the CPU, the verified boot itself was not compromised.
The point isn't that Microsoft also has its keys loaded.
But right now, nobody can ensure that any other keys will be able to be added, mostly because it is up to the hardware vendors to implement that, and windows right now is the only one giving them an actual incentive, i.e. money.
Most people will agree that SecureBoot itself isn't evil, quite the contrary, that it is useful, and that it is useful to everyone. But right now, the minimum hardware vendors have to implement is "boot Windows with SecureBoot and be able to disable SecureBoot". The point is, how do we get others to be able to use SecureBoot just like Microsoft is allowed to from the very get go.
The problems in user freedom do not arise from SecureBoot as a technology, they arise from Microsoft being in from the get go, giving incentives to hardware vendors to ensure that things work for Microsoft, and that's it. Unless a way can be found to also reliably sign other systems (Linux, BSD etc.), SecureBoot and Microsoft's position as the a priori trusted software vendor make for two classes of software: Software working out of the box (=Windows) and that not working (=everything else).
There is no incentive whatsoever for manufacturers to give people control over their computers, and that is the crux.
> There is no incentive whatsoever for manufacturers to give people control over their computers, and that is the crux.
The incentive is that the Microsoft hardware certification requirements demand that they do (point 17 of System.Fundamentals.Firmware.UEFISecureBoot). Whether that proves to be a good (or even enforced) incentive is hard to know until the hardware ships, but saying there's no incentive is inaccurate.
>There is no incentive whatsoever for manufacturers to give people control over their computers, and that is the crux.
I agree and I think this is the interesting part of the discussion (not the vilify Microsoft part). I guess don't see any reason why they wouldn't. They could have not allowed users to reinstall their OS or forbidden non HDD boot in the past by forcing it in the BIOS.
It's hard to explain because this is another step where they will have to provide the ability but to me, they could have done something like this at any point in time (the OEMs, that is) and they didn't. Will they now? I guess that remains to be seen, but I see it as an issue almost separate from UEFI. Maybe the UEFI folks could have made a stronger recommendation and required licensing that included forced terms of user key enrollment? I certainly would be in favor of that in the interest of user freedom!
I think the important point is that Secure Boot flips the default.
We always expect manufacturers to "do nothing" if they can get away with it. Pre-Secure Boot, doing nothing meant you could install whatever OS you wanted (subject to other hardware limitations, of course). Post-Secure Boot it will mean that you probably can't (even if there's a mandated escape hatch, how well will it be tested? And so on).
> Ok, I'll put you in the category of people that swore for years that Motorola's bootloader protection would be hacked. That was... 3 years now since they introduced that and nary a vulnerability found?
Yes. The trajectory on companies getting secure bootloaders right points in a clear direction: they're on their way to getting it right!
This makes me unhappy, but unfortunately, it's taking longer and longer to jailbreak devices, with the exception of Apple devices. (Unfortunately, this seems to indicate a need to brush up on security on their part.)
Secure boot provides no way of knowing that you're screwed. It's not a measured boot. There's no independent confirmation that you're still using the same root of trust as you were before. If someone is able to compromise the key database in any way then they win.
Of course, the point is that this is only supposed to be possible if the attacker has access to your firmware. You can password protect the UI, but if they've got an SPI programmer and enough time to pull your machine apart you're still going to lose.
A fully measured boot has the root of trust in the hardware rather than the firmware, and that protects against most of the technical attacks. Someone can still stick a hardware keylogger in somewhere, but then no level of computer security is going to protect you against a camera stuck to your ceiling.
I see your point. I suppose in the end if the idea of all of these security measures is to prevent unauthorized access of your data, then this is another hurdle for an attacker to get over. But the way I see it, if someone has physical access to your machine, and you aren't using full disk encryption, this isn't going to stop them from doing just that.
Safe Boot goes a long way in the scenarios where your boot loader can be changed by a software vulnerability, or if you're using full disk encryption and an attacker actually needs to alter your boot loader to get at your data(i.e. evil maid).
Like I said, I'm only aware of two other major implementations of this style of security (Xbox 360 and Motorola's locked bootloaders) and the bootloaders themselves were never compromised, even with high/low-level OS access.
So you're right, they can simply wait until I've booted and then compromise Windows in some fashion. That will continue to be the case until that chain of trust is extended and enforced further and further.
The mere fact alone that this could have mitigated the stealthiness and harm of Flame makes it easy for me to include that it can enhance security for individuals.
> The mere fact alone that this could have mitigated the stealthiness and harm of Flame makes it easy for me to include that it can enhance security for individuals.
Did either Flame or Stuxnet (or Duqu or any other worm) override the boot process? I remember reading that Stuxnet used a kernel driver signed by a bona-fide certificate issued to some asian hardware maker, and I assumed Flame did the same (and also used some other MD5 code signing hack, that exploited trust farther away in the chain).
How would have Secure Boot mitigated the stealthiness? You seem to be knowledgeable, so I assume you are right in that Flame did use a boot-level exploit -- but what did it give Flame that a Stuxnet like (bona fide) signed kernel driver couldn't?
I (feel like I) understand the basics of how Secure Boot is supposed to work at least, heh. My knowledge of Flame and it affecting the boot loader came from something I read either in a comment here (and trusted) or read in an article posted here. I can look for it. (I'll be completely honest, a quick Google doesn't seem to support this notion, so take the Flame side of things at your own volition.)
Additionally, my understanding is that the keys in UEFI's Secure Boot storage can also be applied against signed drivers, so assuming the keys are better than the MD5 collided Microsoft certificates, it would also help secure against malicious drivers. (Note, this post is more speculative, I don't know if Windows will use this driver-related feature or if I'm explaining it entirely accurately).
(And not to be repetitive, I apologize, but this would still help prevent evil maid attacks on full disk encryption.)
It's all down to implementation faults; e.g., the wii "trucha" signing bug http://wiibrew.org/wiki/Signing_bug would be good if only they used memcmp rather than strcmp.
There's nothing magic about the bootloader check; They have to get it right, which they might -- but it's much harder than one would expect.
> Additionally, my understanding is that the keys in UEFI's Secure Boot storage can also be applied against signed drivers, so assuming the keys are better than the MD5 collided Microsoft certificates, it would also help secure against malicious drivers.
Not really. You just have to get an exploitable driver signed (possibly through official channels of some sort), and you are good to go. Whoever wrote stuxnet had the means to acquire a driver signing certificate; they probably had the means to get a driver certified even if Microsoft had to sign it.
Without a proper revocation setup, you aren't really better off, and a proper setup is much harder than one would expect, because a well-equipped attacker can DOS/DDOS the revocation list response.
> (And not to be repetitive, I apologize, but this would still help prevent evil maid attacks on full disk encryption.)
It would stop a specific class of evil maid attacks on full disk encryption, yes, and would make other attacks harder but not impossible (ASLR, W^X/NX and many other features were supposed to make buffer overflows unusable for attacks; they made them harder, but apparently not much harder and definitely not impossible).
I don't think it is worth the price in freedom that I suspect will be associated (and yes, I know you disagree. My distrust of PC hardware vendors is based on a lot of continuing frustrating experience, but they might surprise me in the end)
Also, my mention of the issue stemming from the higher-level realm is founded in the idea that exploitation of a device's firmware can't take place without either A) physical access or B) exploitation of higher level software to work its way down. As I mentioned I'm no expert, so I don't know if there are other methods available to attackers. Please elaborate if there are.