Garrett: Secure Boot and Restricted Boot

Posted Mar 28, 2013 17:03 UTC (Thu) by hummassa (guest, #307)
In reply to: Garrett: Secure Boot and Restricted Boot by geofft
Parent article: Garrett: Secure Boot and Restricted Boot

> 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.

to post comments

Garrett: Secure Boot and Restricted Boot

Posted Mar 28, 2013 18:01 UTC (Thu) by apoelstra (subscriber, #75205) [Link] (1 responses)

> 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 (guest, #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] (3 responses)

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 (guest, #307) [Link] (2 responses)

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] (1 responses)

"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 (guest, #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.