After Criticism, Signal Agrees to Secure Plain-Text Encryption Keys for Users' Message Databases

"Signal is finally tightening its desktop client's security," reports BleepingComputer — by changing the way it stores plain text encryption keys for the SQLite database where users' messages are stored: When BleepingComputer contacted Signal about the flaw in 2018, we never received a response. Instead, a Signal Support Manager responded to a user's concerns in the Signal forum, stating that the security of its database was never something it claimed to provide. "The database key was never intended to be a secret. At-rest encryption is not something that Signal Desktop is currently trying to provide or has ever claimed to provide," responded the Signal employee...

[L]ast week, mobile security researchers Talal Haj Bakry and Tommy Mysk of Mysk Inc warned on X not to use Signal Desktop because of the same security weakness we reported on in 2018... In April, an independent developer, Tom Plant, created a request to merge code that uses Electron's SafeStorage API "...to opportunistically encrypt the key with platform APIs like DPAPI on Windows and Keychain on macOS," Plant explained in the merge request... When used, encryption keys are generated and stored using an operating system's cryptography system and secure key stores. For example, on Macs, the encryption key would be stored in the Keychain, and on Linux, it would use the windows manager's secret store, such as kwallet, kwallet5, kwallet6, and gnome-libsecret... While the solution would provide additional security for all Signal desktop users, the request lay dormant until last week's X drama.

Two days ago, a Signal developer finally replied that they implemented support for Electron's safeStorage, which would be available soon in an upcoming Beta version. While the new safeStorage implementation is tested, Signal also included a fallback mechanism that allows the program to decrypt the database using the legacy database decryption key...

Signal says that the legacy key will be removed once the new feature is tested.
"To be fair to Signal, encrypting local databases without a user-supplied password is a problem for all applications..." the article acknowledges.

"However, as a company that prides itself on its security and privacy, it was strange that the organization dismissed the issue and did not attempt to provide a solution..."

So not an issue

[Carewolf]

At rest protection means protection thaf only kicks in when the device is powered off and does nothing ehen powered on. It is useful for laptops but pointless on phonrd

Re:

[CaptQuark]

It depends on how the data is stored and accessed. If the information is encrypted and only a secure process can read the data, decrypt it during use, re-encrypt it before storing, then a rogue application can steal the stored data without compromising the information. Data at rest does not only apply to data on an unpowered device, but is the term for stored data as opposed to data in use and date in transit.

Your hypothesis would mean that any password manager that stores your encrypted passwords on your

Re:

[Bert64]

Data at rest encryption is designed to protect against a physically stolen device or disk that's powered off, and which does not contain the key. Full disk encryption is already available for most devices.

Most hacks don't occur in this way, they take place either due to credential theft (in which case the attacker has the ability to decrypt the data in the same way the user does), or they gain access to the running device itself so the same applies. Encryption in this case becomes mere obfuscation and only

Re:

[WaffleMonster]

It depends on how the data is stored and accessed. If the information is encrypted and only a secure process can read the data, decrypt it during use, re-encrypt it before storing, then a rogue application can steal the stored data without compromising the information. Data at rest does not only apply to data on an unpowered device, but is the term for stored data as opposed to data in use and date in transit.

Schemes like DPAPI and credential store are based on user account context. Any process that runs as the user can access the encryption key. A rouge application would be able to obtain the key necessary to read the data.

For a single user system with FDE these schemes are effectively a nullity. Without FDE you'd better have one heck of an account password.

Re:

[ctilsie242]

Depends on how it is implemented. On Android and iOS, when the device is booted up, it can't access most user data until the PIN or passphrase is put in. From there, filesystems like /data are available, but there are items which are locked when the device is screen locked, and the device also has the option of disabling USB ports and such.

What would be ideal is for apps to have an option to enable their own encryption separate from the OS's protection. By default, they use the OS's keychain and perhaps

Re:

[Antique Geekmeister]

Nonsense. Access to plain-text files is difficult to avoid for phones that allow their data to be manually accessed and backed up, or edited, as a shared filesystem when connected via USB or network, or from other less polite applications.

Signal can still get hung so far as I care

[NoOnesMessiah]

Same problem here, back in 2016 or so. Signal removed a trivial protection feature, I complained, they shrugged it of and said, and I quote, "just use the android lock screen". Well that's fine for some situations I guess, but to remove a trivial feature that was helpful without explanation or cause? Well, they lost me then, and I still think the dev crowd is a useless pile of... people. I moved on long ago. libSignal is useful. Their android app, not so much. Moving on because we all know that they

Didn't TextSecure have encryption?

[ctilsie242]

Back before Signal was on iOS, it was RedPhone and TextSecure. IIRC, TextSecure used its own password based encryption to store both its own and SMS messages.

If I were implementing storage of messages in a secure basis, I would be using SQLite for the file storage. I'd have the main encryption key stored either in the Secure Enclave with some way to recover it (perhaps stored encrypted and decrypted by a user's backup pass phrase [1]). From there, fetch the key, and use SQLIte's Encryption Extension (whi

Re:

[Canberra1]

Looking at all the other at rest solutions, all were high maintenance also needing near experts just like all these last password solutions that are now just getting OK. Signal stuck to its core paranoia for mobile phones - using no assumptions and deserves universal praise. Do one thing well. Nice to see they are now pioneering row level encryption. Good luck to them bypassing Apples M processor series MMIO backdoor, and the binary blobs handling modem operation. The complication is untrustworthy handset h

Re: Didn't TextSecure have encryption?

[mellowinottawa]

Numbers Station messaging app for iOS generates keys in Secure Enclave for encrypting all stored messages (to ensure encrypted data cannot be copied and password brute forced off device, cracking would have to occur on device) and combines that key with a user password for access to stored messages and the app. Whenever app is backgrounded, key is wiped from memory and user has to reenter password. Stops Cellebrite and Graykey from accessing messages even when they unlock the device. Signal data at rest of

TPM?

[ElizabethGreene]

A TPM is a partial solution for this sort of problem. You can ask the TPM for a public key, ask it to encrypt your data, in this case the SQLite encryption key, and then ask it to decrypt it in the future. That prevents an attacker from taking the file from a disk image and hoovering the data off of it. It does not prevent an attacker from taking the data, including the encryption key usually, from e.g. a memory dump or with a debugger.