Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Support the FSF: Help us stop Restricted Boot

fsf.org

Post reply on HN
Print view View original

61–65 of 65 posts

Re: Support the FSF: Help us stop Restricted Boot

#61

Post by winter_blue »

lucian1900 wrote: post #36
winter_blue wrote: post #31

Earlier quoted context omitted.

> Every dollar spent in an Apple-store is money spent against the core of your profession. Stop spending money there. And throw away your iPhones and Macbooks. They are bad karma and software blood-money. The key problem for mobile app developers is the rampant piracy on Android. iOS has nowhere as much piracy as Android. In this case, economics will dictate where app developers sell, will it not? What we really need…

Any DRM by definition tries to keep a general purpose computer from being general (i.e. performing any task). There's not much more piracy on Android than iOS, and it doesn't matter anyway.

> There's not much more piracy on Android than iOS, and it doesn't matter anyway.

Can you back that up?

Re: Support the FSF: Help us stop Restricted Boot

#62

Post by mistercow »

sliverstorm wrote: post #57
mistercow wrote: post #54

Earlier quoted context omitted.

There are a lot of negative things that you can say about Richard Stallman, but to suggest that he or his organization might be in anybody's pocket is simply preposterous.

I didn't realize it was "his"

He's the founder and president, and they have a staff of 10, so yeah, it's his.

Re: Support the FSF: Help us stop Restricted Boot

#63

Post by geofft »

ajross wrote: post #53
geofft wrote: post #43

The FSF's attitude towards new technologies seems awfully reactionary (this is somewhat unsurprising when you remember that rms doesn't use a web browser; occasionally he emails interesting-sounding URLs to a service that emails them back to him in plain text, and he only checks email once a day). Secure Boot where you can only run Microsoft-approved software is bad for software freedom, no question about it. Secure…

How many consumer systems have been the victim of evil maid attacks in practice? How many have been infected via browser (or other client) vulnerabilities that never touch the kernel nor interact with a "secure" boot implementation? Secure boot exists primarily because it provides a "feel good" answer to content providers about the feasibility of DRM. It's not an answer to real world security issues and never has bee…

Secure Boot does not implement DRM or help in any way for DRM, as it turns out. Secure Boot is about the hardware trusting the OS it's about to boot, not about the OS trusting the hardware it's running on. Once the OS has booted, it has no way to figure out if the "you were secure-booted" flag is trustworthy or not -- a trojan bootloader can easily set that flag and then chainload to the normal OS.

If you want the OS to trust the hardware it's on, you need a TPM, and you probably need the machine to be installed by someone who can communicate with the content provider. The entire point of Secure Boot is that it can be implemented just in existing UEFI code, _without_ the additional hardware of a TPM.

I develop an OS product that has no browser installed on it at all -- there's one small client application that just interacts with our one server product, and then boots everything else you might want to do in a VM. The biggest threat to the security of our outer layer is, in fact, an evil maid attack. It's certainly worth being aware of that threat, even if there are other, bigger threats. (Nobody says that we should stop worrying about buffer overflows while there are still cross-site scripting attacks, etc.)

Re: Support the FSF: Help us stop Restricted Boot

#64

Post by geofft »

temac wrote: post #59
geofft wrote: post #43

The FSF's attitude towards new technologies seems awfully reactionary (this is somewhat unsurprising when you remember that rms doesn't use a web browser; occasionally he emails interesting-sounding URLs to a service that emails them back to him in plain text, and he only checks email once a day). Secure Boot where you can only run Microsoft-approved software is bad for software freedom, no question about it. Secure…

It is only two or three days since I first heard about the "evil maid" attack. While this could be a preoccupation for some kind of environment, and most probably very few, it is very easy to come with a scheme that both protects against that and allows other operating systems to be installed. Given that this has not been done, and given the small number of people this scenario interests, given that thoses people are…

Secure Boot cannot possibly be useful to prevent the installation of other operating systems. Microsoft has a website where they will accept other operating systems to be signed, and there are multiple non-MS operating systems in existence that will boot with no fuss on a machine with Secure Boot enabled. The claim that Secure Boot is bad because MS could decide to stop signing Linux is as ridiculous as the claim that Authenticode is bad because MS could decide to stop signing Firefox, or that HTTPS is bad because MS could replace the set of CAs in Internet Explorer with just itself.

The only way to defeat evil-maid attacks is for the early-boot code in your computer's firmware to cryptographically validate the bootloader or kernel that it's about to start, and make sure it's signed by a trusted authority, and make sure that it's possible for the computer owner to disable the ability for anyone other than him to change the set of trusted authorities. This happens to be exactly what Secure Boot does.

Re: Support the FSF: Help us stop Restricted Boot

#65

Post by ajross »

geofft wrote: post #63
ajross wrote: post #53

Earlier quoted context omitted.

How many consumer systems have been the victim of evil maid attacks in practice? How many have been infected via browser (or other client) vulnerabilities that never touch the kernel nor interact with a "secure" boot implementation? Secure boot exists primarily because it provides a "feel good" answer to content providers about the feasibility of DRM. It's not an answer to real world security issues and never has bee…

Secure Boot does not implement DRM or help in any way for DRM, as it turns out. Secure Boot is about the hardware trusting the OS it's about to boot, not about the OS trusting the hardware it's running on. Once the OS has booted, it has no way to figure out if the "you were secure-booted" flag is trustworthy or not -- a trojan bootloader can easily set that flag and then chainload to the normal OS. If you want the OS…

I didn't say it "works". What I said was basically: Secure boot answers the question "How do I know someone won't write a crack to steal my content?" in an intelligible way (i.e. "Because it locks down all the software that runs on the device in an uncrackable way.")

That's a powerful sales tool. Systems that don't have secure boot have a much harder time selling their DRM implementations. And that's why we have secure boot. Don't fool yourself into thinking all problems are technical.

Post reply on HN