[lmm]

The only way you can do this is if the server is not fully under your control but partially controlled by the remote client.

We've been here before: this is Trusted Computing. You need a Trusted Platform Module on your servers (thankfully you're picking the hardware, so you can make that a hard requirement). Your users can inspect and sign your code with their keys, that they generate and keep on the client side (you never see them). Or more likely, they sign that they trust a particular third-party auditor. Either way, their data is uploaded encrypted with their keys and only code they have signed will ever be allowed to decrypt it.

It won't be easy. You'll have to keep old versions of your code around in case users haven't signed the new versions. The TPM-handling libraries are immature, though they get better every day. But it's possible, particularly since you only need to make it work with one particular model of TPM.

Good luck!

[ethbro]

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

[kefka]

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.

[higherpurpose]

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.

[mindslight]

Remote attestation is most certainly anti- Free software.

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

[sweis]

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.

[mindslight]

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?

[MichaelGG]

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

[mindslight]

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.

[diminoten]

Wait, so you "sign" the version of code you're okay with using, and if you haven't "signed" the new version off, you're actually served by the old version of the code (the "newest" version you've "signed")?

Wicked. :)

[ivanhoe]

Perhaps it's a stupid question, but how can a web client confirm that code is really running from inside the TPM? Since the source code is freely available from github, isn't there a chance that whoever controls the server (hacker or malicious owner) can simply override the TPM at some point in future, and run the unsigned, possibly altered, code directly, circumventing all the restrictions? As far as I understand the mechanics of TPM, for this setup to work you need the server owner to be trusted and actively monitoring and protecting the server setup like banks do, to detect any breach. Then it makes sense: you trust the owner, owner creates the proper setup and TPM protects it from any future unauthorized changes. If the owner of the server cannot be trusted this will not work, since he/she can just change the back-end setup and do as he's pleased, and you don't have any way to detect this on the client side?

[MichaelGG]

TPMs cannot, AFAIK. But Intel SGX can. It allows you to remotely verify code running on the processor and provide inputs that can only be decrypted by the secure enclave. How I'm guessing this would play out is:

1. Site publishes its hardware public key, allows users to verify it can sign on behalf on an Intel processor.

2. Site publishes source and reproducible build, so everyone can agree on a hash of acceptable bits.

3. Users submit requests encrypted to that public key (there's also something missing, where the key is actually a combination of the public key plus the hash of the executable code. Maybe the processor signs another cert for a specific proc+code combo).

4. Server can only decrypt when it has access to the matching private key, which is only available after entering the secure enclave.

5. If the server could decrypt the request and sign a response, the user knows it was handled by the right bits.

This still has many problems, the main one being that users are not going to really verify anything anyways. Also the data storage and all important handling needs to be done with encryption, so an admin can't just change the data.

But in theory, assuming no one can break the secure enclave/trust chain, it's a pretty nifty solution.

[lmm]

The web client can confirm that the code is running in what something with a TPM key claimed as being a secure environment (remote attestation). The whole point of the TPM is that its private key is stored in tamper-resistant hardware and never exposed to the outside. Of course no hardware is perfectly tamperproof, and I imagine a sufficiently smart or patient attacker could compromise one, but we're talking liquid nitrogen and electron microscopes territory here.

[rainmaking]

Is it known how exploit prevention is done in a remote trusted computing scenario? It is well known that TCM implementations on behalf of Microsoft are being circumvented left and right.