this post was submitted on 06 Jul 2024
105 points (99.1% liked)
Free and Open Source Software
17682 readers
116 users here now
If it's free and open source and it's also software, it can be discussed here. Subcommunity of Technology.
This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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.
Exactly. Discord token stealers have been around for ages but no one gives Discord flak about leaving that secret unencrypted.
Discord aren't marketing themselves on secure or encrypted messaging. Signal is.
Don't phones have something comparable to a TPM?
The article referenced is about their Desktop application