The messaging app Signal has been under scrutiny due to security concerns surrounding its desktop application. Cybersecurity researchers rediscovered that Signal’s desktop version was storing encryption keys in plaintext, potentially exposing users to data theft. This led to a heated debate on social media platforms about the app’s security measures.
Now, Signal has taken a step to address these concerns. According to a recent GitHub update, the company has implemented support for the Electron safeStorage API to enhance the security of local database encryption keys.
The issue first came to light when researchers from Mysk reported that Signal’s desktop app was storing local chat history encryption keys in an unencrypted format. This practice, they argued, could potentially allow unauthorized access to user data if a device was compromised. They also showed how a default user account could, in theory, copy the Signal database and transfer it to another device, then reinstate that database and read the message contents without ever being caught or notified by Signal.
The discovery led to widespread criticism, with some users recommending others to unlink their desktop devices from Signal accounts.
On July 9, Signal’s president, Meredith Whittaker, initially responded to the concerns by stating that the reported issues relied on an attacker already having full access to the user’s device. However, this explanation did not satisfy all critics, with some arguing that user-level file access would be sufficient to exploit the vulnerability.
Shortly after Whittaker made her statement, Jamie Builds, a Signal developer, announced on GitHub that the company has implemented support for the safeStorage API. Builds says this implementation will “start using the system keystore.” Instead of storing encryption keys in plaintext, Signal will use the operating system’s built-in secure storage mechanisms.
The update includes several key features designed to ensure a smooth transition:
- Migration to encrypted, keystore-backed local database encryption keys on supported platforms.
- Additional troubleshooting steps to address potential issues.
- A temporary fallback option allowing users to recover their message database using their legacy database encryption key if problems arise during the migration process.
“This should help minimize data loss if any edge cases or other keystore-related bugs are discovered during the migration process and production rollout,” Builds explained.
The developer noted that this is a significant change requiring extensive testing. Pending successful trials, the new feature will roll out soon in an upcoming beta and broader production releases.
Signal’s decision is a proactive step in addressing user concerns and strengthening the app’s security measures. Although one can argue that this took an extremely long time to accomplish, the issue was known as far back as 2018.
To get this out to users as soon as possible, Signal has called for user participation in testing this new feature. “We appreciate your support!” Builds stated, encouraging users to join the Signal Desktop beta program to help ensure a smooth rollout of this update.
safeStorage API: How does it work
With the implementation of the Electron safeStorage API, Signal’s desktop application’s security has been significantly enhanced. Now, an attacker would face more complex challenges in accessing the encryption key and the database.
Here’s a breakdown of what they would need for each operating system:
- macOS:
- Access to Keychain: The encryption keys are stored in Keychain Access. To retrieve these keys, an attacker must bypass the Keychain’s security, typically requiring the user’s login credentials or physical access to the device.
- User Override: Even with physical access, the attacker would need to override user permissions, which involves tricking the user into granting access or exploiting a vulnerability in the Keychain system.
- Windows:
- User Credentials: Encryption keys are protected by the Data Protection API (DPAPI). An attacker would need the same login credentials as the user who encrypted the data. This means they must compromise the user’s account, typically through phishing, keylogging, or social engineering.
- Administrative Access: To bypass DPAPI, administrative privileges on the machine could be necessary, making it harder for the attacker to remain undetected.
- Linux:
- Access to Secret Store: Encryption keys are stored in a secret store (e.g., kwallet, gnome-libsecret). The attacker would need access to this store, which the system’s security mechanisms protect. They would likely require the user’s login credentials and potentially the password for the secret store.
- Fallback Scenario: If no secret store is available, and the safeStorage API defaults to a hardcoded plaintext password, the attacker must exploit this fallback mechanism. However, detecting and targeting such specific setups would be challenging.
In summary, the attacker would need a combination of user credentials, physical access, and possibly administrative privileges to access the encryption keys and the database.
Using OS-provided cryptographic systems significantly raises the bar for potential attackers, making unauthorized access far more complex than when encryption keys were stored in plaintext.
