Signal under fire for storing encryption keys in plaintext
Signal under fire for storing encryption keys in plaintext
As mentioned in the comments, plain text keys aren't bad because they are necessary. You have to have at least one plain text key in order to be able to use encryption
This is a, "it's turtles all the way down!" problem. An application has to be able to store its encryption keys somewhere. You can encrypt your encryption keys but then where do you store that key? Ultimately any application will need access to the plaintext key in order to function.
On servers the best practice is to store the encryption keys somewhere that isn't on the server itself. Such as a networked Hardware Security Module (HSM) but literally any location that isn't physically on/in the server itself is good enough. Some Raspberry Pi attached to the network in the corner of the data center would be nearly as good because the attack you're protecting against with this kind of encryption is someone walking out of the data center with your server (and then decrypting the data).
With a device like a phone you can't use a networked HSM since your phone will be carried around with you everywhere. You could store your encryption keys out on the Internet somewhere but that actually increases the attack surface. As such, the encryption keys get stored on the phone itself.
Phone OSes include tools like encrypted storage locations for things like encryption keys but realistically they're no more secure than storing the keys as plaintext in the application's app-specific store (which is encrypted on Android by default; not sure about iOS). Only that app and the OS itself have access to that storage location so it's basically exactly the same as the special "secure" storage features... Except easier to use and less likely to be targeted, exploited, and ultimately compromised because again, it's a smaller attack surface.
If an attacker gets physical access to your device you must assume they'll have access to everything on it unless the data is encrypted and the key for that isn't on the phone itself (e.g. it uses a hash generated from your thumbprint or your PIN). In that case your effective encryption key is your thumb(s) and/or PIN. Because the Signal app's encryption keys are already encrypted on the filesystem.
Going full circle: You can always further encrypt something or add an extra step to accessing encrypted data but that just adds inconvenience and doesn't really buy you any more security (realistically). It's turtles all the way down.
Very good "Explain Like I'm Five" there!
Signal seem to be the least compromising messenger app out there with their privacy policy and open source code base. It's only natural they are frequent victims of FUD.
This reminds me of the apparent gnome-keyring security hole. It's mentioned in the first section of the arch wiki entry: https://wiki.archlinux.org/title/GNOME/Keyring
Any application can read keyring entries of the other apps. So it's pretty trivial to make a targeted attack on someone's account if you can get them to run an executable on their machine.
Don't phones have something comparable to a TPM?
The article referenced is about their Desktop application
I kind of agree that this may be a little overblown. Exploiting this requires device and filesystem access so if you can get the keys you can already get a lot more stuff.
A secure enclave can already be accessed by the time someone can access the Signal encryption keys , so there's no extra security in putting the encryption keys in the secure enclave.
It's eventually going to have to be stored in plaintext somewhere. Where are you then putting the encryption key for the encryption keys and how do you start the chain of decryption without the first key?
Sorry, I don't think I understand what you're suggesting. Are you saying encryption keys should themselves be encrypted?
FYI this story isn't about plaintext passwords, it's about plaintext encryption keys to chat history.
Also not a surprise because as the article notes it's been known and discussed since at least 2018
After your edit, the post points to an image only, no longer the link to the source. Please edit back the link, if not at least into the body.
Fixed it! Thank you.
How else should the keys be stored?
There are system specific encryption methods like keychain services on iOS to store exactly this kind of sensitive information.
Isn't Signal Open Source? If so, why is it a surprise then?
Its not a surprise but it has not really received a lot of attention since people have reported it.
https://github.com/signalapp/Signal-Desktop/issues/5751
Also signal as a service is not really open source because it is not selfhostable. The server backend is proprietary afaik.
Source? That's just an image.
FYI Submitting an image in the Lemmy "create post" submittion form overrides the URL feild. I'm not sure if anyone submitted a bug about this.
The link is broken, but this is apparently an issue with Signal Desktop, not regular Signal. The proposed solution does not work on Windows: https://www.electronjs.org/docs/latest/api/safe-storage
[…] content is protected from other users on the same machine, but not from other apps running in the same userspace.
It's unfortunately about the best you can do on Windows.
Thanks for the heads up on the broken link! I fixed it.
Restricting access to files within a user is why sandboxing is useful. It in theory limits the scope of a vulnerability in an app to only the files it can read (unless there is a sandbox escape). Android instead prevents apps from accessing other apps' files by having each app run as a separate user.
One way to keep the encryption keys encrypted at rest is to require the login password (or another password) to open the app, and use it to encrypt the keys. That said, if an adversary can read Signal's data, they can almost certainly just replace Signal with a password-stealing version.
by any process on the system
This IS bad. Btw they can ask the user to type the password rather than saving it in a plaintext. I can't believe comments on this thread defend Signal...
But can you trust that a user will pick a difficult to break password? They likely will pick something simple to remember but that is not a good password.
The we are just back to essentially having a plaintext password because if the attacker has a good dictionary, it will be easy to crack.
I can agree, but I MYSELF will pick a strong PW. So they better just fucking encrypt the thing, fucking please for the love of god.