After an outage of #Signal (caused by a problem at #AWS) @Mer__edith@mastodon.world argued that a cloud provider is needed to run a service like Signal.
I answered that a cloud provider is needed, because Signal doesn't federate (and thereby build its own so called 'cloud').
I added that I doubt that by using a cloud provider Signal doesn't leak the social graph of their accounts.
I got referred to the #PrivateContactDiscovery by @newhinton@troet.cafe designed to protect the social graph which I simplified to hashing leaving out the use of #sgx part in my post.
I stated that I wouldn't understand how one could be sure that all which is guaranteed by using SGX really is like it is promised.
The only answer by @moehrenfeld@social.karotte.org is that I indeed didn't understand "Private Contact Discovery" completely.
It's frustrating to doubt and being left in the dark about the facts.
Today I learned something new: SGX is not meant to be save against physical attacks - or to phrase it different: SGX is meant to protect data if the OS is completely compromised, but the server is under physical safety and control:
…All three chipmakers exclude physical attacks from threat models for their TEEs, also known as secure enclaves.… (Nvidia, AMD, Intel)
…“These features keep getting broken, but that doesn’t stop vendors from selling them for these use cases—and people keep believing them and spending time using them,”…
…Those making these statements run the gamut from cloud providers to AI engines, blockchain platforms, and even the chipmakers themselves. Here are some examples:…
…The maker of the Signal private messenger assures users that its use of SGX means that “keys associated with this encryption never leave the underlying CPU, so they’re not accessible to the server owners or anyone else with access to server infrastructure.” Signal has long relied on SGX to protect contact-discovery data.…
Big thanks to @kyle@kylerank.in for sharing this post by by @arstechnica@mastodon.social: https://arstechnica.com/security/2025/10/new-physical-attacks-are-quickly-diluting-secure-enclave-defenses-from-nvidia-amd-and-intel/ !
Maybe my naïve assumption that you can only protect data on hardware you physical own and protect has not been so wrong at all.
I'd be happy to read arguments and opinions and corrections to the arstechnica article.
My concern with that is three-fold:
- Like you showed in the article, SGX does not seem to withstand against physical attacks (which should be considered in Signals case)
- There have been several issues with attacks on SGX: https://dl.acm.org/doi/10.1145/3456631 (or search "SGX vulnerabilities" or more), I would not be personally convinced that it is "perfect" (though admittedly better than nothing)
2/3
- SGX still has a remote attestation, so at the end of the day, you are still trusting a third party (Intel) that the enclave has confidentiality and integrity guarantees.
While not perfect, it is probably the best one can do on e.g. AWS, but IMHO, it isn't as good as it could be with self-hosting (where these classes of issues wouldn't exist or would be much easier to deal with).
3/3
one of the most comprehensive explanations of SGX I have read cam be found here: https://eprint.iacr.org/2016/086.pdf
@me
Going back to it, IIUC, it looks like Signal is claiming that their sensitive computing is done via SGX, and that is the primary method of ensuring that an adversary (i.e. AWS) cannot figure out certain things happening on the server side. IIRC, this was the original reason SGX was created. (See the paper I referenced)
1/3