[AnthonyMouse]

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

[Sayrus]

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.

[AnthonyMouse]

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.

[Sayrus]

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.