| |||||||||||||
Garrett: Secure Boot and Restricted BootGarrett: Secure Boot and Restricted BootPosted Mar 27, 2013 22:17 UTC (Wed) by geofft (subscriber, #59789)In reply to: Garrett: Secure Boot and Restricted Boot by utoddl Parent article: Garrett: Secure Boot and Restricted Boot
You can blame the FSF for "Restricted Boot" as a term. It's not a term Microsoft or the UEFI Forum uses, and they use "Secure Boot" to cover both versions of this.
But, if you want to explain it to your grandmother, imagine that the auto industry had widespread problems with gas stations selling watered-down gasoline. You're driving along the highway, you refuel at the closest gas station, and two miles down our engine starts sputtering.
Ford says, "We've got a solution: we're making our cars with special patented gas tanks, that only fit our special patented gas nozzles. You can only fill up from Ford-run gas stations, and unapproved gas stations can't make nozzles that fit your car any more." While this does solve the problem as stated, it's also pretty anticompetitive. This is Restricted Boot -- you buy a computer, and you can only install operating systems that the computer vendor approves.
Customers complain, and Ford says "Okay, fine, you don't want us in control of where you get gas. Fine. We'll let you swap out the special gas tank cap. If you decide you like Chevron gas, go buy a Chevron-patented gas tank cap from them -- but we take no responsibility for whether Chevron is doing a good job of franchising their gas stations to trustworthy people. If you want to live dangerously, we'll even let you unscrew the connector and let _any_ nozzle fill fuel, but if your engine burns out, don't complain to us." That's Secure Boot. By default, the computer vendor restricts boot to OSes that they've vetted, but you as the computer owner can choose to change who's trusted to write OSes, or even trust anyone at all.
Chrome OS's solution (which Matthew has blogged about before) is like this story, except that there's no option for third-party fuel vendors to provide replacement special caps. You either have to trust Google, or trust everyone. It's a lot better than Restricted Boot, where you can't remove the special cap at all, but it's not quite as good as Secure Boot, since you have no protection if you opt out of trusting Google.
The distinction is that boot verification uses cryptography instead of patents, so it actually works. :)
(Log in to post comments)
Garrett: Secure Boot and Restricted Boot Posted Mar 28, 2013 16:58 UTC (Thu) by hummassa (subscriber, #307) [Link]
> but if your engine burns out, don't complain to us.
More like: if anything happens, we will shift the fault to you unscrewing the nozzle, we will overcharge you for any kind of service in your car and, in some cases, we will even deny you any kind of service. Ah, some parking lots, part shops, or even some roads may deny you service also.
Garrett: Secure Boot and Restricted Boot Posted Mar 29, 2013 2:52 UTC (Fri) by geofft (subscriber, #59789) [Link]
I think the car analogy is breaking down here, but as far as Secure Boot goes, that is simply impossible. There is no way for an OS to reliably know whether it was booted in Secure Boot mode or what keys were available -- you can very easily write a bootloader shim that intercepts the EFI APIs for accessing variables, loads an actual bootloader (like Windows'), and falsely reports that Secure Boot was enabled and only the MS key was trusted.
Remember that Secure Boot is for the hardware deciding whether to trust (and go ahead and execute) the OS, not vice versa. If you want the reverse, you want a TPM, which lets an OS decide whether to trust the hardware (and again, not vice versa).
Garrett: Secure Boot and Restricted Boot Posted Mar 29, 2013 15:40 UTC (Fri) by ortalo (subscriber, #4654) [Link]
Also for the TPM: not vice versa? With a TPM you mean the hardware does not have a mean to decide if it can trust the OS?
Garrett: Secure Boot and Restricted Boot Posted Mar 29, 2013 18:53 UTC (Fri) by geofft (subscriber, #59789) [Link]
Correct. The TPM is a little chip on the motherboard that can do cryptography. The usual way it's used is that it's configured to read in and hash every piece of code run in the boot process (starting with the TPM itself reading the BIOS code, then the BIOS passing option ROMs and the boot sector, then the boot sector passing on anything it loads). At this point the TPM has a "measurement" of the boot process; a salted hash of all code that runs with some secret burned into the TPM itself.
The TPM has the ability to "seal" or "unseal" an encryption key (just another level of encryption) based on the measurements. So you can use it for full-disk encryption, by sealing your encryption key against the measurement of the boot proess. If the boot process changes (e.g. there's a boot sector virus), or you move the disk to a machine with a different TPM, you can no longer unseal the key to the disk, because you don't have matching measuments any more. You can also use it for remote attestation, by having a network server send the OS a challenge that it gets the TPM to respond to, where the response can only be constructed if the measurements match.
One thing you'll note that the TPM does not have the ability to do is to _stop_ code from executing. It sits there quietly watching what code is executed. It can refuse to provide the encryption key, but it can't, for instance, prevent a malicious boot loader from playing a fake Windows boot animation, popping up a login screen, sending the password somewhere, removing itself, and bluescreening. User data is protected, but even so, it's a lot easier to mount attacks since the attacker has code running on your machine.
The other thing about Secure Boot is that it's possible to implement it just within the existing boot firmware, without requiring a separate processor for doing crypto. Yes, you could imagine the TPM having signature verification capabilities, but it's better to put it on the firmware that already ships with every machine, instead of requiring additional hardware on all machines.
Garrett: Secure Boot and Restricted Boot Posted Mar 28, 2013 17:03 UTC (Thu) by hummassa (subscriber, #307) [Link]
> The distinction is that boot verification uses cryptography instead of patents, so it actually works. :)
OH MAN. NO. Please. NO.
Cryptography only works in transit. If you are in control of one of the endpoints of a communication, Cryptography is NOTHING.
A |--- E ---> B
Crypto only works so that E does not know the content of the message.
All DRM thingies (including "Secure" Boot) are like:
A |------> E/B
Tens of millions of jailbroken iPhones scream that DRM does not work and that "Secure" Boot does not work.
Garrett: Secure Boot and Restricted Boot Posted Mar 28, 2013 18:01 UTC (Thu) by apoelstra (subscriber, #75205) [Link]
> Cryptography only works in transit. If you are in control of one of the endpoints of a communication, Cryptography is NOTHING.
In principle this is true, but if the endpoint you "control" requires an engineering degree and expensive equipment to analyze, you're effectively not in control. You cited the proliferation of jailbroken phones, but jailbreaking procedures usually find other bugs with which to bypass the encryption --- they can't do anything against the encryption itself.
Garrett: Secure Boot and Restricted Boot Posted Apr 3, 2013 13:19 UTC (Wed) by xilun (subscriber, #50638) [Link]
This is even worse than that: you are not in effectively not in control because of the cost, but given the right incentive an opponent can take control in a way that locks you down completely out of control.
Garrett: Secure Boot and Restricted Boot Posted Mar 28, 2013 19:11 UTC (Thu) by mjg59 (subscriber, #23239) [Link]
Most DRM technologies are theoretically breakable because they require the system to contain a secret but not to let you access that secret. Secure Boot contains no secrets at the client end. The failures of most Restricted Boot systems have been caused by flaws outside the cryptography, not the cryptographic checking itself.
The lack of a jailbreak for the AppleTV3 (and the resulting $130 premium that AppleTV2s command on ebay) is evidence that this can be done sufficiently well. Even the iOS 6 jailbreaks are forced to operate at higher levels than the boot verification - you can run arbitrary userspace code, but you couldn't replace the kernel.
Garrett: Secure Boot and Restricted Boot Posted Mar 30, 2013 1:45 UTC (Sat) by hummassa (subscriber, #307) [Link]
I'll let you in a little secret, Garrett: atv3 was not jailbroken because there are better, more open, options in the market, and because it is a very small market. If the iPhone sold in its segments as little as the ATv, people would just buy Android too.
When geohot first jailbroke the iPhone, he had to physically open the case. One of my atv1 had to be cracked open, too. But, having other options to run Xbmc+Netflix/Hulu, why in the world would one buy an Apple TV? Unless, of course, you want to pay two dollars per tv episode -- but I can't put the subtitles I want on it...
Garrett: Secure Boot and Restricted Boot Posted Mar 30, 2013 1:56 UTC (Sat) by mjg59 (subscriber, #23239) [Link]
"atv3 was not jailbroken because there are better, more open, options in the market"
That would be a perfectly reasonable explanation, other than the number of people willing to pay significantly more money for an atv2 than a new atv3 costs.
Garrett: Secure Boot and Restricted Boot Posted Mar 30, 2013 11:42 UTC (Sat) by hummassa (subscriber, #307) [Link]
This is the minority like me: I *did* pass on the other options b/c I do have a reasonably-sized collection of thingies on iTMS... :-(
And I do think iTunesU is nice. Apple is *so* evil that they could hook me, even if I know it.
Garrett: Secure Boot and Restricted Boot Posted Mar 29, 2013 3:33 UTC (Fri) by geofft (subscriber, #59789) [Link]
> Cryptography only works in transit. If you are in control of one of the endpoints of a communication, Cryptography is NOTHING.
This is a valid argument against restricted boot, but not so much against secure boot. The intention of restricted boot is to make sure that only the OS vendor controls the OS being run, and prevent the computer owner from choosing an OS. You're right that with physical control the user can probably win (although I can still imagine designs that involve writing everything in Coq and then epoxying the motherboard, or something).
But secure boot is intended to place the computer owner and the hardware vendor in control of the device, and keep malware away. The attacks people are worried about are boot sector _viruses_ (which have been around since the late '80s, btw; it's only with UEFI that we can do something meaningful about it). This involves a third party with access to your boot medium -- anything from a trojanned download of an Ubuntu CD, to a curious-looking thumbdrive lying around a conference. Here the attacker does not have control of the endpoint, until such time as they get code executing. Secure boot is intended to make sure the attacker's code never executes. So the cryptosystem is sound.
|
|||||||||||||