Signal Desktop Leaves Message Decryption Key in Plain Sight

A mistake in the process used by the Signal Desktop application to encrypt locally stored messages leaves them wide open to an attacker.

When Signal Desktop is installed, it will create an encrypted SQLite database called db.sqlite, which is used to store the user's messages. The encryption key for this database is automatically generated by the program when it is installed without any interaction by the user.

As the encryption key will be required each time Signal Desktop opens the database, it will store it in plain text to a local file called %AppData%\Signal\config.json on PCs and on a Mac at ~/Library/Application Support/Signal/config.json. 

When you open the config.json file, the decryption key is readily available to anyone who wants it.

According to Nathaniel Suchy who discovered the problem in Signal Desktop, this leaves the user's database wide open to any attacker or malware that has access to the computer.

"Lesson Learned - database encryption is great - until you mismanage keys." Suchy told BleepingComputer in a conversation.

To illustrate this problem, BleepingComputer installed the Signal Desktop application and sent a few test messages. First we opened our config.json file to retrieve the encryption key, which is shown above.

We then opened the database located at %AppData%\Roaming\Signal\sql\db.sqlite using a program called SQLite Database Browser. As you can see the program prompts us to enter our decryption key.

When we entered the decryption key from the config.json file, the database was opened and we had full access to its contents.

Encrypting a database is a good way to secure a user's personal messages, but it breaks down when the key is readily accessible to anyone. According to Suchy, this problem could easily be fixed by requiring users to enter a password that would be used to generate an encryption key that is never stored locally.

"This would be easily mitigated by requiring users to set a password and using that password to encrypt the key" stated Suchy.

The use of user generated encryption keys is a common practice for services such as cloud backups, password managers, cryptocurrency wallets, and authentication protocols as only the user has access to the key. The only caveat to this method, though, is that if the user loses the key, the data will be lost forever. 

This bug comes on the heels of a different Signal problem reported yesterday that left unencrypted messages stored in text files when upgrading from the Signal Chrome extension to Signal Desktop.

BleepingComputer has contacted Signal via Twitter for comment, but had not heard back at the time of this publication.

Update 10/26/18: While Signal has not responded to BleepingComputer's questions, a Writing, Community, and Support Manager at Signal named Joshua Lund responded to a user's questions on the Signal forums:

This post stated:

SQLCipher ships with a good default set of plugins/pragmas, and its performance is excellent because it is built on top of the widely used SQLite database layer.

The core premise of the article is completely mistaken. 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. Full-disk encryption can be enabled at the OS level on most desktop platforms.

As user on the Signal forums stated, 

I think the difficult thing for everybody to understand is why the database is encrypted in the first place? Are you saying that SQLCipher just offered better features and performance than using SQLite? Can you point to any discussion or documentation of that decision-making process?