Yes, there can be exploits, but hardware exploits over a restricted interface (TPM2) are significantly rarer then normal software vulns. Everything is about risk mitigation, there is no perfect security.
I'd not be able to put up with that, but more importantly, I'd not want to be in the position where I can't even protest anything because there's no alternative to switch to..
I'm not talking about desktop because this is not where remote attestation is used by them.
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.
I'd read the confidential computing post! (used to work in this space myself)
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.
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.)
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 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.
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.
One of the valid use cases on consumer devices is video game anti-cheat software. Theoretically remote attestation can enable them to be less invasive.
With enterprise devices you can enroll a specific device and only allow its key. Someone who finds a vulnerability in a different device model, or even the same device model when they don't have one of your actual devices, can't use it because it's not enrolled. (That doesn't actually require remote attestation, the same works without any kind of TPM, but it mitigates a gaping hole that remote attestation has otherwise.)
Because in the video game case the cheater can choose whatever device they want, so they choose one with a vulnerability, which the developers can't prevent without blocking the millions of innocent people who have the same hardware. It's also the solution to yesterday's problem because cheaters are now using cheat hardware that acts as a user input device, and then attesting to what software is running buys you nothing because the cheating is happening in hardware.
> It's also the solution to yesterday's problem because cheaters are now using cheat hardware that acts as a user input device
Cheats like these are not as devastating to the game as the ones that read or manipulate memory in the game process itself. You can't see people through walls with cheat hardware acting as a user input device (IOMMU should prevent DMA cheats but those aren't user input devices).
[1] https://xcancel.com/riotgames/status/2069829543276216564
Only on Windows, and then we're back to the thing being a net negative for the consumer again. Also not proven that it's actually effective, in which case we get the cost without the benefit.
> Cheats like these are not as devastating to the game as the ones that read or manipulate memory in the game process itself.
It allows aimbots and the like which are the most common form of cheating and more than enough to destroy the game for other players.
> You can't see people through walls with cheat hardware acting as a user input device (IOMMU should prevent DMA cheats but those aren't user input devices).
For which they can use different cheat hardware.
It's unclear how IOMMU is supposed to prevent this since many hardware devices actually need to access the relevant memory locations, e.g. your drive is going to write directly to the game's memory because that's how the game's code/data gets into memory to begin with or gets reloaded after being evicted when the user doesn't have unlimited RAM.
On top of that, the cheat hardware could attach to the memory slots. Consumer PCs often don't support memory encryption and it wouldn't work for this anyway, since memory encryption is meant for cold boot attacks or similar rather than live analysis/modification. The performance requirements of RAM require block modes like XTS which allow replay attacks (undo cheats) and data flow analysis. Or worse, they just use a replay attack to get ACE on the device that passes attestation.
Attempting to secure a device in the physical possession of the attacker is very challenging and in general should not be the basis of anything you intend to actually be secure.