Hacker News Reader

Comment by mjg59 | Hacker News Reader

You say that, and also remote attestation is how Signal knows it's talking to a legitimate SGX enclave running the expected payload

View on HN

Being able to come up with compelling use cases for a technology does not redeem that technology from creating a terrible power imbalance that incentives will mean is inevitably abused. Whenever anyone hears "remote attestation", they should think of the already-pervasive Cloudflare CAPTCHA nagwalls, and then think of those becoming something you can only get past by buying a new computer running a proprietary locked-down OS and browser.

The only way to make remote attestation into a neutral technology is to prohibit privileged keys being loaded (and retained) by device manufacturers. This would make it impossible for arbitrary protocol counterparties to know if their attestation requests are being answered by hardware, or merely emulated in software. This approach is the only way to preserve computing freedom (ie the very concept of protocols that mediate between mutually-untrusting parties) in the presence of this technology.

> running the expected payload

SGX does not cryptographically guarantee this. It cryptographically guarantees that the processor contains a legitimate provisioning key signed by Intel. Intel pinky promises that its processor will then only use this provisioning key in certain ways. This promise is essentially unauditable, and previous SGX bugs have shown that Intel isn't really in a position to make it anyway.

You are 100% correct, but this is still mostly fine: without SGX, you need to completely trust Signal, since it could trivially modify the server-side code. But with SGX, you only need to trust that Signal and Intel won't both collude.

The most likely attacks on Signal involve trusted insiders or configuration errors, and SGX mostly prevents these, since to exploit it, you'd need to bribe insiders in both Signal and Intel, or find configuration errors in both of their software stacks.

Collusion is certainly still possible, but it's much harder to pull off, since it typically requires nation-state-level resources to exploit. Signal does actually have nation-state adversaries, but the vast majority of other software projects don't.

(I personally think that remote attestation is the single biggest risk to the free software movement, but I begrudgingly accept that Signal is a very good use case for it.)

> The most likely attacks on Signal involve trusted insiders or configuration errors, and SGX mostly prevents these, since to exploit it, you'd need to bribe insiders in both Signal and Intel, or find configuration errors in both of their software stacks.

Since there have been multiple SGX key extraction vulnerabilities already, all you would have to do is compromise Signal and then use the key extracted from any of those devices, and "compromise Signal" is the same thing you would have to do if they weren't using SGX at all.

Since there have been multiple 0-day in kernels, we should drop all security boundaries in them because you'd only need execution on the machine and a known vulnerability.

Since there have been with bypass on service X, we should remove auth because all you need is the vulnerability.

Address space layout randomization wouldn't exist with this mindset, and yet it does and helps for many exploits.

SGX is not fully secure. But neither are the other part of the stack. Security (or trust in this case) is done through layers because it's a question of when you'll be vulnerable, not ifs.

When there is a 0-day in the kernel, you patch it. When there is a vulnerability in SGX, the attacker extracts the key from their own hardware from as many devices as they want and can permanently make whatever attestations they want with those keys.

Which makes you update hardware and have a window where you are vulnerable. It's terrible but not a blocker and as long as Intel releases new architectures it isn't much different from software issues. As far as I know, Granite Rapids SGX fused keys (FK0, FK1, GWK, FEK) were not yet extracted. Granite Rapids was released around ~2024 meaning an attacker need to hack the provider and perform a new extraction on SGX.

The path to compromise that you describe exists, of course. But it's not the only way. For example, a zero-day in SGX combined with privileged access to AWS infrastructure could compromise Signal's SGX setup without any knowledge or collusion by Signal or Intel. As you note, it is not unreasonable for a project of Signal's stature to expect to face adversaries with such capabilities.

There's some value in that, but Signal's main security proposition is that you don't have to trust the infrastructure. E2EE means even compromised server software can't read message contents.

He's talking about contact discovery, which can't be solved by just slapping e2ee on it

I definitely want to do a post on confidential computing as well. Super cool stuff.

Maybe you could do a post on... remote attestation.

That is, the thing that people are actually talking about when they use that term: The means for companies and governments to usurp the ownership of consumer devices.

Oh yeah, just like all cryptography is just a way for bad people to hide their criminal activity.

I'd read the confidential computing post! (used to work in this space myself)

Reply on news.ycombinator.com