124
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 29 Nov 2023
124 points (97.7% liked)
Technology
59086 readers
2558 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related content.
- Be excellent to each another!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, to ask if your bot can be added please contact us.
- Check for duplicates before posting, duplicates may be removed
Approved Bots
founded 1 year ago
MODERATORS
I'm sure there are more attack vectors than that though
Exactly. "Security assuming nobody fucked up" isn't enough
Signal does store the decryption keys in the cloud. Using their SGX enclaves. Which have their own issues. Signal SVR I believe they call it.
You can turn off signal pins, which still stores the decryption keys in the cloud, but then they're signed with a very long pin which is good enough.
From a government perspective, signals a no-go, the SGX enclaves are completely exploitable at the state actor level. You just have to look at all of the security vulnerabilities to date for SGX enclaves.
Do you have a reference for Signal using SGX for keys?
Everything I could find was about metadata and private data, e.g. contact lists (which is what the SVR thing that you mention is), but nothing about keys.
https://signal.miraheze.org/wiki/Secure_Value_Recovery
https://github.com/signalapp/SecureValueRecovery2
If you want to do an empirical test, create a signal account set a pin. Send a message to someone. Then delete signal. Recreate the account using the same phone number, recover using the pin and send a message. The receiver of that message will not get a warning that the signing key has changed.
The only way that's possible is if the key, or a derived key, is recoverable from the network. That is de facto proof that the keys or a key generation mechanism is in the cloud. Which is probably fine for personal communication.
But if I'm a nation state, this represents a significant security risk, especially when you're worried about another nation-state peaking at your communication. I.e France is buddy buddy with the US, but they probably don't want the US to read all of their internal communication.
SGX https://en.m.wikipedia.org/wiki/Software_Guard_Extensions
https://sslab-gatech.github.io/sgx101/pages/attestation.html
SGX is a inside chip secure enclave created by Intel, a company headquartered in the United States, that uses key management, and signing keys from Intel. Intel could be compelled by domestic intelligence to provide their keys, or to sign certain enclave software. I'm not saying it's happened, but I am saying this is part of the risk assessment a nation state would use to evaluate a messaging platform
So a nation state attack might look something like this: Intel is compelled to release their signing keys, the signal user enclave is copied, using the combination of both of these a special SGX environment will be set up to brute Force the passwords, with no limit. The limit will be removed, and it will operate in the SGX environment, and brute forcing a six-digit pin is trivial if you're not rate limited. This is just one possibility, SGX has at least nine known side channel attacks at the moment, I'm sure there's more that haven't been published.