Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

encrypted db.sqlite encryptable, hence conversations interceptable #4042

Closed
1 task done
nean-and-i opened this issue Mar 11, 2020 · 1 comment
Closed
1 task done

Comments

@nean-and-i
Copy link

  • I have searched open and closed issues for duplicates

Bug Description

Ask:
As the transport seems to be pretty safe, I’d like to question the method of how Signal is storing message on the device and ask for improvement.
It would be great to get an official answer from the signal team and kindly ask if there are any plans to stop anyone spying on conversations via local database readouts?

Proof:
There is a way of work around the transport encryption and intercept conversations by reading out the database on the device.
As tested this works perfectly fine for signal desktop app (macos,windows), so anyone who has remote access to the filesystem (db.sqlite/config.json) is able follow a conversation.
I'd wonder if this applies to all clients on all devices, but atm. only tested and verified on the desktop due to lack of rooted/jailbroken phones

  • Signal desktop app (macos,windows) -> verified
  • Android app -> not verified -> todo
  • iPhone app -> not verified -> todo

Discussion:

quote: Moxie Marlinspike (https://youtu.be/kp-b8iTZqzM?t=829)

... and they come and see your device, there are no keys on the device to go back and decrypt decrypt old messages,...

-> Agree, for the particular presented context (the transport side of things), and I’d love to agree for all other "use cases", but if Law Enforcement Agencies come and see your device, they don’t care about an "old encrypted transport", instead they:

  • take your device
  • make a forensic image
  • locate the sqlite database
  • decrypt it via key that is available in the config.json
  • read out all the conversations

The trend of the LEA’s and secret services is not only to attack the encryption, they like to work around "this problem", one way is eg. to install a trojan on the device and constantly read out the signal database in order to trace conversations.

References:

diracdeltas: #2815 (comment)

Messages and attachments are not meaningfully encrypted on-disk in the latest Signal Desktop even without exporting/upgrading, so i'm not sure this violates the intended threat model of Signal

in your APPDATA directory (~/Library/Application Support/Signal):

sql/db.sqlite contains the messages. this file is encrypted but the decryption key is in plaintext in config.json.
attachments.noindex/ contains the attachments unencrypted.
i'm not a signal dev and do not intend to support or refute their choices, just noting an observation.

Answer from signal devs:

signal-dev scottnonnenberg-signal : #2815 (comment)

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.

Steps to Reproduce

  1. sql lite browser to open db.sqlite
  2. use key from config.json to decrypt database
  3. with open databarse track all conversations via messages table and json field

Actual Result:

conversations interceptable if acces to local filesystem is given

Expected Result:

implement an additional security layer to prevent access to the messages on all platforms

Screenshots

Platform Info

Signal Version:

all versions

Operating System:

teste and verified on macos and windows

Linked Device Version:

all Android and Ipohone versions

Link to Debug Log

@scottnonnenberg-signal
Copy link
Contributor

You've already quoted me on previous conversations on this topic, so I'm going to close and lock this.

@signalapp signalapp locked and limited conversation to collaborators Mar 12, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

No branches or pull requests

2 participants