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

Technology preview: Private contact discovery for Signal

signal.org

Post reply on HN
Print view View original

11–20 of 169 posts

Re: Technology preview: Private contact discovery for Signal

#11

Post by hardwarescope »

DINKDINK wrote: post #5

The security assumptions that SGX is built on are flawed. They assume that no side channel attacks will be mounted to determine the processes that occur in side the chip. You can even build software to do side channel analysis on the physical chip: 7:16:26 Daniel Gruss / Michael Schwarz - Cache Attacks on SGX https://youtu.be/eCE2OzKIab8?t=26193

> They assume that no side channel attacks will be mounted to determine the processes that occur in side the chip.

They do? 2/3rds of this blog post are about side channel attacks. The majority of the technical aspects of the article are about memory side channels in SGX and how they overcome those challenges. I haven't looked at the code yet, but it sounds as if they wrote it to be branchless so that attackers can't monitor control flow and so that memory access patterns don't leak anything.

Re: Technology preview: Private contact discovery for Signal

#13

Post by kuschku »

Considering that Signal is advertised (with Snowden as face) for people who need privacy from governments (including the US government), I am doubtful if this is useful for the advertised purpose. (For normal users this is already overkill, of course).

Even if we assume the NSA has no backdoors in the secure enclave, there have been countless demonstrations against secure enclaves in today’s real-world processors on conferences.

Additionally, the same problem applies here that has been used before to break Google’s SafetyNet solution (which does the same, but the opposite way around, to ensure the client is running, and can’t prevent tracking): You can simply have two systems, and for attestation you question the true device, but for actual code execution you run it on an emulated one, where you can extract all data. Alternatively, you can still emulate this system completely and circumvent it via that path, too.

The only way to truly verify SGX is by having a signature of the processor manufacturer – but in that case, you still don’t get protection from the NSA, or the processor manufacturer.

Re: Technology preview: Private contact discovery for Signal

#14

Post by tptacek »

sigil wrote: post #6

So this looks better than the status quo, but is it really trustless? Couldn't OWS still be compelled to drop something in that walks & talks like this secure enclave, but enables remote collection of address books? It seems we've just moved the trust down the stack into hardware. Kinda depressed that we seem to have given up on the scalable Private Set Intersection problem. It's a hard problem but an important one f…

The point of SGX is that the enclave is cryptographically verifiable. You can't simply emulate the enclave's software and interface; you also have to have the corresponding private key.

Re: Technology preview: Private contact discovery for Signal

#15

Post by JoshTriplett »

nkobeissi wrote: post #10

Signal is applying SGX secure enclaves to engineer a new contact discovery server design. This is doubtlessly promising and innovative. My only question is the following: what protection is there against the server sending a correct remote attestation for the code being executed to the client, and then, right after this attestation is validated, the server rerouting the network pipe so that the contact list the clien…

> My only question is the following: what protection is there against the server sending a correct remote attestation for the code being executed to the client, and then, right after this attestation is validated, the server rerouting the network pipe so that the contact list the client sends goes to a different server running different, non-SGX code?

The same thing that prevents contacting an HTTPS server and having your connection re-routed after verifying the server certificate: the code elsewhere (e.g. outside the enclave) doesn't have the keys.

Re: Technology preview: Private contact discovery for Signal

#16

Post by Asdfbla »

Cool idea. When I read the title I thought that maybe they have discovered a practical private information retrieval method or some oblivious transfer-based method after all since their 2014 blog post (well, they kinda do something like that with oblivious accesses to the RAM I guess), but using the secure enclaves for running verifiable code seems like a very pragmatic and creative solution too.

Granted, how secure those enclaves against state-level attackers also remains to be seen (that recent attack on ARM Trustzone was pretty cool and effective), but it surely is an improvement after all if you want some defense in depth.

Re: Technology preview: Private contact discovery for Signal

#17

Post by nkobeissi »

JoshTriplett wrote: post #15
nkobeissi wrote: post #10

Signal is applying SGX secure enclaves to engineer a new contact discovery server design. This is doubtlessly promising and innovative. My only question is the following: what protection is there against the server sending a correct remote attestation for the code being executed to the client, and then, right after this attestation is validated, the server rerouting the network pipe so that the contact list the clien…

> My only question is the following: what protection is there against the server sending a correct remote attestation for the code being executed to the client, and then, right after this attestation is validated, the server rerouting the network pipe so that the contact list the client sends goes to a different server running different, non-SGX code? The same thing that prevents contacting an HTTPS server and having…

That makes sense. In this case I think it would be interesting to analyze the state space for the network protocol involved.

Re: Technology preview: Private contact discovery for Signal

#18

Post by Confiks »

I don't really understand why this is an improvement on the existing architecture.

In the current contact discovery implementation you need to fully trust the server, namely the open source component that is the contact discovery service.

In this proposed new implementation, you still have to trust the server; you need to trust closed source processor hardware offering the Software Guard Extensions.

Those extensions need necessarily be kept away from user control, because otherwise you could pretend to attest a particular program, while actually running a different program. So this encourages a centralization of trust into a private key managed by processor manufacturers, which with server hardware is primarily Intel.

(note that you fully need to trust the processor hardware in both cases; I'm only arguing that this scheme possibly isn't an improvement)

Could anyone shed some light onto why this is an improvement, assuming you don't trust the CPU manufacturer? This is kind of the premise of the article, which notes that "more fundamentally for us, we simply don’t want people to have to trust us", "that’s not what privacy is about".

Post reply on HN