Does anyone know where documentation would be located that describes how the data is stored and protected on the client device? There is lots of documentation on Signal Protocol and protection of data when it is in transit, but I am trying to find documentation about the design of the app and how it protects data at rest?
-mike
In 4.15.4 and below, the message database on Android used to contain encrypted messages. The metadata was readable, only protected by an optional password. If you could access the database files, for example with forensic tools that dump the whole memory of the device, you could brute force it, and because most people probably will not use a very complicated password on a mobile device the chance of success was quite large I think.
This left 2 factors to protect it: device encryption on Android and the native protection on iOS.
In version 4.16 Signal switched to SQLCipher, and the key for that is stored in the device keystore on Android 6 and above. For Android 5 and below the key is stored in the preferences so if someone can dump the device memory the data is still accessible (even easier because one does not have to write an application to decrypt the records). On Android 6 and above the key can not be copied from the device, unless an attacker gains root access (needed to overcome the Android Signature verification) and succeeds in installing a modified version that accesses the key and copies it. I have written such a version to allow the database to be copied to another device when someone switches devices; but when I can do it the NSA /FBI / FSB / … can do that too of course.
The situation has improved with 4.16 in Android 6 and above in so far that it is now not possible to access the key by installing another app that gains root access and copies the Signal key. It needs to be done by the Signal app itself (i.e. an app with the package name org.thoughtcrime.securesms).
3 posts were split to a new topic: Rooting an Android device
In case you’re talking about Signal’s passphrase: pre-4.16, it was only used for encrypting message content, nothing else.
On a side note: I’m not sure how attachments are stored 
I assume this is only the case if no Signal passphrase is set.
Thanks I’m trying to understand this as well.
How is the key derived and stored for these messages on <4.15.4 if no passphrase is set?
Hi all,
so here i’m a bit confused. After talking to moxie in this issue #7553 at github. I can’t understand the basic encryption at rest signal provides. As mentioned in this issue, i and some other always asumed that the password you choose for signal interacts with the local encryption. This is not the case:
The Signal screen lock is just that, a screen lock. It is not connected to any kind of data encryption, it is just a screen that someone holding your phone has to unlock to get past.
The data on disk is encrypted using a key that’s stored in the Android system keystore, which is hardware backed on some devices (presumably most new devices). However, the sad truth is that if what you’re really worried about is protecting your messages from someone with forensic physical access to your device, your best bet is to run Signal on an iPhone instead.
This would prevent forensics if i’m not mistaken. If the pass is good enough.
Probably not. It’s in memory in many places, since there’s no way to control that with the JVM. Also, password based encryption is not generally effective, particularly given the mobile form factor.
What does than this mean moxie: https://github.com/signalapp/Signal-Android/wiki/Using-SignalEvery official support page says otherwise, the feature itself is called a “screen lock,” etc. All of these wiki pages are made by people here like yourself, I’ll delete this one.
I beg for an option that we can encrypt the data at rest with our own chosen pass. This is fundamental.Not only would that be ineffective, it’s not really possible. A message arrives, but the database is “locked.” What do we do? We could put it somewhere temporarily and notify the user, but what if the message is from someone who is blocked? There’s no way to know that, because that information is… in the database. etc etc.
I did search around a bit how threema handles the local encryption. And did come up with this here from their security white paper.
Android
On Android, Threema stores local data in an SQLite database within the app’s private data directory. Android
ensures that no other apps can access this data directory (as long as the device is not rooted). The database
itself is protected by SQLCipher with AES-256, and any media files (which are stored separately in the app’s
private directory within the file system) are also encrypted using AES. The key is randomly generated when the
database is first created, and can be protected with a user-supplied passphrase (which is of course necessary
if the user wishes to take advantage of this encryption). The passphrase is never written to permanent storage
and therefore needs to be entered whenever the app process restarts (e.g. after a low-memory situation, or after
the device has rebooted). Alternatively, the user may enable full-device encryption if supported by the device
and Android version
The Brown University posted this here:
The Signal Storage Architecture
When Signal is installed it first generates keying material. This includes a password P
, a 128-bit AES key K, an HMAC-SHA1 key G and an elliptic curve Diffie-Hellman public/private key pair (pk=gx,sk=x). The tuple (K,G,sk), which we refer to as the master secrets, is then encrypted with P using password-based encryption and stored on disk while pk is stored in plaintext. Note that these master secrets are only used to encrypt messages when stored and not in-transit. The password Pis either user-generated (if the password option is enabled) or fixed to the string “unencrypted” (if the password option is disabled).
Signal operates in two modes: open mode, which is when the password P is cached; and closed mode, when P is not cached.
Can somebody please explain why i think this does not fit with what moxie said???
How can we improve local encryption and make it forensic resistant???
I’m confused about how data stored in android and it is encrypted completely or not 
The entire database is encrypted. The key for that is a 256-bit random number. This number is encrypted with a key from the Android keystore and this encrypted number is stored in the Signal settings.
The keystore store the key encrypted with the unlock pattern or code. If you have no unlock pattern the key is stored unencrypted.
If someone gets the phone AND the unlock pattern AND can gain access to the entire filesystem (root or some tricky forensic software) the encryption key can be obtained from the Android keystore and getting access to the Signal data is fairly trivial. However, if someone has the phone and the unlock pattern they can read the messages from within Signal itself already.
Now , most people use a trivial unlock pattern or code . 4 digits or something like that . Is there any way , that someone could install a malicious app , which roots the device and finds a way to get access to the Signal database ? An app , which makes use of any vulnerability of Android ?
I am no expert , so this might be a stupid question , who knows.
There are ways to do that of course, and the funny thing is that one of the best methods to protect against that is to root your device: if someone else installs a su binary I get an immediate warning from my current rootmanager that something happened.
But is some app happens to be able to root the device it can copy Signals keystore file and the Signal database and send them to an attacker. The only thing the attacker would need to do then is to brute force the unlock pattern or code, which is doable if it can be automated (I’m sure it can somehow).
So if i reset my phone and give it to someone else signal data can’t be restore attacker ?
If you factory reset your phone all data will be deleted. I don’t think if it will also be overwritten, so if you didn’t use device encryption some specialized forensics lab might be able to restore the data.
So , this is very interesting .
If I understand you correctly , the only defense against such an attack is a complex password , instead of using simple pins , to make brute force more difficult ?
Do you know , if your sayings also apply in the same way for the Whatsapp database ?
Also interesting with the root : many colleagues tell me to root my device , and then just give root to a rare numbers of apps - so basically root the device without giving root permissions to apps.
I didn’t do it , because others , including Mister Marlinspike , always said , people shall not root their device .
Yes, a complex password or pattern is the only defense against that. Combined with device encryption, but I have few illusions about the security of that if your attacker is for example the FBI.
The WhatsApp database AFAIK not encrypted. WhatsApp’s local backups are, but the key for those are stored in WhatsApp /data/data directory so you need root to access it but once you have it there is no further password. That’s why this WhatsApp backup tool: https://play.google.com/store/apps/details?id=com.smeiti.wstotext needs root, but a similar tool from the same author for Viber does not.
About rooting or not, it depends on how well you know what you’re doing. If you don’t know what you’re doing but only want to root because some app needs it and are the type of person to always click “yes” when a question is asked (for example if random app XYZ can have root access) then I would not advice it.
Well , I hav’nt heard of FBI having problems with Android devices so far , just about their problems with iphones . I just hope the following: If you chose a correct a long password , and the Phone is switched off… then it should be safe , I hope so.
I do not fear the situation after a root , I often work with root on Linux systems .
I just don’t understand the process of rooting itsself . When collegues wanted me to root , they showed me how to unlock the bootloader , and then use some Kingroot app .
I googled , Kingroot comes from China . I asked them , if they know the source code of Kingroot , if they are sure , what this Kingroot does to my device , and they did not know.
Do you have a clean process of rooting your device , without using some chinese software tools , which you don’t really know about?
2 posts were merged into an existing topic: Rooting an Android device
Let’s continue the rooting-related discussion over at “Rooting an Android device”. I just moved over a few more posts.
I believe a more practical and promising defense is some form of hardware support to prevent offline guesses of PINs / passphrases / other types of secrets used to lock your phone. I’m not aware of the current situation with Android in this regard. Don’t modern Android phones nowadays come with (and make use of) some equivalent of the iPhone’s secure enclave?
Some do but it depends on Android version and the soc used. See for example http://www.cs.ru.nl/~joeri/papers/spsm14.pdf for an overview.
Thanks! Doesn’t look too bad on first glance, considering it’s from 2014. Apparently it was already possible to make use of Qualcomm and TI SoCs for the Android Keystore back then (provided they have ARM TrustZone support).