Hacker News Reader

Comment by hestefisk | Hacker News Reader

I know Signal is secure and all — and I use it myself — but I can’t help but think how can we trusted that the central servers aren’t wiretapped? It would be the ultimate proof of security if one could transparently verify that the middle man is running the actual code it claims to be running.

View on HN

Signal uses Intel SGX to give you some assurances about this, at least for parts of their serving stack. You can run the remote attestation tools and get a report back from Intel that says, in effect, "you connected to a genuine CPU and it's running software with this hash". Then you reproduce the build of the open source code and check the hashes match.

I'd be surprised if anyone has ever actually done this. It's a very obscure thing. But to their credit, it's possible.

SGX can't actually make you have secure end to end encryption though. The Signal protocol is necessary but not sufficient. The operators can always just push a software update that invalidates all the security guarantees. It's been a problem since the start but they never talk about fixing it, even though the issue is a glaringly obvious one.

What they could do is allow third parties to audit their software updates, and then cross-sign the binaries. Android allows this but there's no UI for it. It'd benefit from a collaboration with Google to allow multi-vendor apps.

After that comes sandboxing. Dalvik/ART doesn't support the Java SecurityManager API. However, for sandboxing software components cheaply it's hard to beat. If a component is sandboxed in a correct manner then the audit costs get much lower. You don't need to re-audit a component that's changed if the sandbox means it can't access keys or message data, for example (and if everything is memory safe: you'd have to do multi-process on iOS which is a lot more expensive).

> Then you reproduce the build of the open source code and check the hashes match.

Assuming that the sgx environment hasn't been tampered with. There have been several flaws in sgx, e.g. https://www.theregister.co.uk/2019/02/12/intel_sgx_hacked/

SGX is patchable via microcode updates (and some parts are software). The remote attestation contains the patchlevel of the system, so, a client can tell if you aren't keeping up to date with security patches.

And so far these are not zero day bugs. The researchers work with Intel to only publish when there are fixes available, usually. It's not much different to any other security system in that sense.

Very interesting, thanks for sharing. I had one idea of extreme transparency. What if the Signal server used a per-user-thread model where each thread was isolated in a sandbox, which only the user has access to. The user can log in with read only access via ssh and certify that nothing is logged, nothing is tampered with etc. A kind of extreme transparency.

You're heading in the right direction but traditional UNIX tools don't work here. That's why Signal needs to use SGX.

Consider: how do you know the SSH server isn't tampered with? It could be feeding you an entirely fake session.

You might say, the sandbox. How do you know the sandbox isn't tampered with?

How do you know the hard disk or the RAM isn't tampered with? The third party owns the machine itself.

SGX is based on the insight that it's very, very difficult to tamper with a physical circuit as small as a CPU. The CPU is the root of trust in any machine. If a CPU can produce a report that says the moral equivalent of "I'm running an OpenSSH server version X" and the CPU itself is preventing the server owner from tampering with the software, then you have the ability to reason about what the server is doing with your data.

This is possible with remote attestation. See the "Trust but verify" paragraph in https://signal.org/blog/private-contact-discovery/ and also https://signal.org/blog/secure-value-recovery/.

> Trust but verify

That phrase needs to be deprecated

It collapses to 'verify'. Just say that.

The point of signal is that you do not need to trust the middleman due to e2ee about your actual communication (but this does not include your metadata where you do need to trust their servers - and there is no way to prove that they run the code that they claim to run)

As for the actual client, see https://signal.org/blog/reproducible-android/

Right now signal is not fully reproducible so you can't trust that the binary that they distribute does not use a different code.

I know that the point of Signal is zero-trust, but a savvy middle man could still use large scale information about source and destination of encrypted packets for useful intelligence. Just like NSA would find it useful to inspect email headers despite the email body being encrypted.

They use the Intel sgx (secure enclave) to do exactly this. Although for message contents, it doesn't matter anyway because they are end to end encrypted and cannot be read except by the receiving party.

Decentralization would proof a lot more.

Reply on news.ycombinator.com