Hacker News new | ask | show | jobs
by ethbro 4109 days ago
I think I picked this up off Hacker News originally, but there's apparently new Intel stuff (aka SGX) coming out to help with this. http://theinvisiblethings.blogspot.com/2013/08/thoughts-on-i...

Unfortunately, I think the reason most open source people have a knee-jerk aversion to trusted platforms are that they've historically been designed to only serve the interests with the most money (read: the government and/or content industry).

There's nothing inherently anti-open source about the schemes, and they would provide innumerable benefits to increasing security confidence in a networked world.

However, when you can rattle off enough failed or botched encryption initiatives involving a hardware component to fill one hand just from the top of one's head (CSS, AACSS, HDCP, UEFI/SecureBoot, FairPlay), confidence is not inspired...

2 comments

I'm fine with "Trusted Computing". I'd just like the private keys, please.

Oh wait, I can't do that? Hmm, so who are you trusting against? Me, you say?

Nope nope nope.

Yes. If Intel can let you control the keys and guarantees in some way that it's not compromising your trusted module, then SGX would be perfect. Unfortunately, right now, Intel wants to keep the SGX keys for itself.
Remote attestation is most certainly anti- Free software.

Bank: "For your security, you may only access our website with an officially supported browser"

If you remotely attest your own software, how is that anti-freedom?

I use remote attestation to verify that my firmware, kernel, initrd, and configuration were booted as expected. It's a tool you can use for your own benefit.

What you are describing is someone else attesting that their software booted on your computer. That was the scary scenario people were afraid of when trusted computing rolled out, but it never materialized. Nobody is using TXT for DRM.

Like secure boot, it ultimately comes down to who has the keys.

If you generated the signing key and loaded it onto the hardware (or generated on-chip but it's signed by nothing else), then I don't see the problem.

If the hardware has a factory-generated private key that you cannot get at and the corresponding public key can be verified through some well known trust root, then a third party can ask you to attest to what software is running on your hardware and you cannot lie. This custom hasn't materialized yet, but it's not too hard to imagine it catching on after support winds its way up the software stack.

What are the specifics of your setup?

On the other hand, it allows trusting otherwise untrusted third parties. For instance, you could use it to run a verifiably safe bitcoin tumbler. (Assuming you can trust Intel directly and against attackers.)
So does designing a proper protocol that doesn't rely on tamper-proof hardware as a cornerstone.

The essential idea behind software freedom is that your computer runs code wholly of your choosing and functions as your agent. The parties to a transaction voluntarily meet together by adhering to a mutually beneficial protocol.

Allowing other parties to know exactly what code you're running lets the more powerful party dictate that your code works for their benefit, effectively leaving you without a computer.