Hacker News Reader

> With SGX, users can just verify that the code you're running does not, in fact, send all their data to the NSA behind their backs

This is a big claim which needs extraordinary proof if we're going to rely on that assumption for security. Remember, we're talking about an organization that did things like sneak in backdoors in encryption standards or infiltrate Google's internal network to passively extract user data en masse. We should just assume the NSA has gotten the keys from Intel a long time ago, voluntarily or not.

The NSA doesn't respect the rules. Nor do they think about the wider consequences of their actions. They're a reckless and irresponsible organization with an enormous budget. If they want something from Intel, they will have it.

There are firms that sell phone scanning utilities that pull signal message off (unlocked?) ios and android (and presumably desktops).

Even if signal used an enclave key to encrypt the local chat database, sgx doesn’t protect the enclave from the keyboard, mouse or display drivers, so someone could simply write a screen scraper that displayed and captured each message of each thread.

I think you're misunderstanding what SGX is used for in the Signal context: It's only used server-side. The clients have no real use for it, because they don't have to attest the software they're running, only the keys they possess.

The server however is inherently untrusted, and the users of the server can benefit from some form of attestation of the software it's running. SGX tries to provide this, as the siblings in this thread explain.

> With SGX, users can just verify that the code you're running does not, in fact, send all their data to the NSA behind their backs.

I'm genuinely unclear. How exactly does a user accomplish this? What role does SGX play in this?

Obviously the remote code could send the data to whatever three letter agency the operator wants, so the remote operator need to publish the server's code. But how do you prove that the remote operator is running the code they claim they are?

That's what SGX does, it lets remote systems provide a cryptographic proof that they are running certain code. Including the ability to have a private key protected by the SGX, so you can public key encrypt your data, send it to the remote server, and know that only the code they've already published is processing your data.

But presumably now the SGX root key is published, anyone can still do all of the above, but in a simulated machine rather than on legit intel hardware, which means they see everything that SGX is supposed to hide from them.

The theory is that when you send your contact list to the service, the service can prove to you that it's running a specified set-intersection application (and nothing else!) in the environment that will have access to that data, using this attestation mechanism.

If it modified the application to make it log or leak your data somehow, it could no longer pass that attestation step.

This should work as long as there is no hardware or side channel attack that lets the service operator (or someone it rents hardware from) defeat the SGX security guarantees, as long as there's no backdoor in the enclave implementation, and as long as the signing keys are not leaked or extracted, and are only used in accordance with the published policies.

Signal users should be happy about this, because it exposes the SGX enclaves as the false security it is. It's not like this is the first SGX exploit.

You should assume that Signal engineers, if they chose to, could access the user data protected by SGX, just like they could log metadata about your message sending and receiving patterns. You only have their word that they don't. The NSA could certainly bypass the SGX given access to the server.

I suppose there may be some legal benefit in putting the data "out of reach" - it would be hard to prove in court that you were capable of leveraging an exploit towards SGX to provide the requested data. But NSA/others will happily take possession of the hardware and do it themselves.

The difference in number of situations where it's a corporation enforcing their will on you vs. you being able to trust them is massive. If Signal had used a different method then I don't think there would be a single example of "customers to make sure that corporations are actually running the code they're claiming to be running".

Here's a comment from some number of years ago suggesting an implementation of private set intersection for Signal's phone number / contact search without the use of SGX: https://news.ycombinator.com/item?id=11289223

> However, this works both ways, because it can also be used by customers to make sure that corporations are actually running the code they're claiming to be running, and that's pretty useful.

This still requires trusting Intel.

> it can also be used by customers to make sure that corporations are actually running the code they're claiming to be running, and that's pretty useful.

Has any company beyond Signal ever done this? Ever?

Apple is leaning into this for cloud AI: https://security.apple.com/blog/private-cloud-compute/

Probably enough to be genuinely hard for an APT to backdoor even with insider help. Still, ultimately the security relies on Apple hardware signed with Apple keys.

Dual authentication is common in the defense space.