Signal-android: Broken Encryption

Created on 11 Dec 2020  Â·  14Comments  Â·  Source: signalapp/Signal-Android


Bug description

Broken encryption

Steps to reproduce

https://www.cellebrite.com/en/blog/cellebrites-new-solution-for-decrypting-the-signal-app/

Actual result:
Messages and attachments in plain text

Expected result:
Encrypted messages and attachments

Device info

Android

Most helpful comment

So they looked up how to decode the app's local database in the source code, given full access to the data on the phone. That's not "breaking" anything, thats unlocking the door to your apartment with the key your landlord gave you.

That's one horrible article both technically and in its framing. I urge people not to share fearmongering and general FUD like that!

All 14 comments

I just read that article, came here to open a ticket as well. The intro of that article alone is just scary. As if Signal is built by and for criminals.

So they looked up how to decode the app's local database in the source code, given full access to the data on the phone. That's not "breaking" anything, thats unlocking the door to your apartment with the key your landlord gave you.

That's one horrible article both technically and in its framing. I urge people not to share fearmongering and general FUD like that!

They've since taken the article down, but when I read it before, the techniques they were using implied that they had root access to the phone (i.e. they were reading private app files and had access to the Android Keystore key). If someone has root access to your device, that's pretty much game over. They can do far worse than just reading your Signal messages at that point. Not to mention, if someone has rooted access to your phone they could just... read your messages, like, in the app.

I'm guessing all of these things contributed to them taking the article down *shrugs*.

I know this one is kind of laughable... A friend of mine shared the article and we made the same joke about having the keys to the safe...

However... can someone smarter than me (shouldn't take much) confirm that the keys encrypting signal messages (database) are still locked once the phone is unlocked? I'm no cryptographer, but from my very basic understanding from years of gpg encryption use on Linux filesystems, the entire purpose of having a secret key and encrypting files with it is to ensure that people with system wide access do not have access to encrypted files. I assumed signal databases are encrypted with a key that is only unlocked once signal is unlocked? Is this still true, or do I have a fundamental misunderstanding of how signal databases are encrypted, or maybe even worse, how file system level encryption works? Sudo unlock all Dave's files?

"If someone has root access to your device, that's pretty much game over. They can do far worse than just reading your Signal messages at that point. Not to mention, if someone has rooted access to your phone they could just... read your messages, like, in the app."

So... every time I open Signal and it asks me to "unlock" the app, this is just a pointless feel-good pretend security step?

@DevinCharles: Well, to decrypt the database, it obviously has to have the key and algorithm in memory too. All you have to do is cause something that makes Signal need to open the database. Like an incoming text. If it isn’t already.
So, basically… yes. Feel good measures.

For GPG and encrypted drives it makes sense, because once locked and memory overwritten, nothing triggers decryption unless the actual user enters the code.

But for an instant messenger's database… on a device and OS that are themselves not secured (or rooted, like is implied by Cellebrite) … it is always mere snake oil. Exactly the same reason DRM can by definition never work.

The lesson here is, that physical access to the key storage always means game over.

The best you could do here, is have Signal not work at all unless you are currently using it. (Losing the ability to receive messages if locked.) And to have an external, key device with its own keypad and display too for entering the code and pass everything through. Like those bank devices. But even then, once somebody runs its software inside the OS (root) while you are currently using Signal, you’re toast.
No software in the world prevents that.

The lesson is to not let anyone, not even in your sleep, have physical access to your device. Which should be a highly secured one with audited and formally-proven-to-be-correct software and hardware. Made in your own chip fab, with no spies inside, to prevent dopant-level hardware trojans.
…
Good luck with that! ;)

@navid-zamani That makes no sense. The message is encrypted by the sender. It does not need to be decrypted until the recipient opens signal to read it. This allows signal to receive the encrypted message and store it encrypted just as it was sent. Only when the recipient unlocks signal is the information available to decrypt the message.

Agree with sylvandb: Signal can keep everything encrypted while being receiving messages in the background (and sending notifications that do not need to include sender or message content). The messages can only get decrypted when the user actively "unlocks" the app. If this wasn't default behaviour, it would at least make sense to have this option.

@sylvandb: Note that Signal, by default, displays infos about the message on the lock screen.
And has to open its encrypted database to store it in there, and know were to store it.
In any case, even a short unlocking is an unlocking. Which means game over if somebody has root.
Also, the key and the algorithm are on the phone, so a root user has everything needed to decrypt the message.

@Uvaly: I absolutely agree here. Of course it will do absolutely nothing to stop somebody with root access though. Other than a false sense of security that results in a real loss of security.

They've since taken the article down, but when I read it before, the techniques they were using implied that they had root access to the phone (i.e. they were reading private app files and had access to the Android Keystore key). If someone has root access to your device, that's pretty much game over. They can do far worse than just reading your Signal messages at that point. Not to mention, if someone has rooted access to your phone they could just... read your messages, like, in the app.

I'm guessing all of these things contributed to them taking the article down shrugs.

@greyson-signal My question is, more global, Do Signal "decrypt" the database after unlocking the screen lock of when opening the app ? If it's before the unlocking the app this security step cosmetic

Using the screenlock does not provide any additional encryption. It's just a way to restrict access to interface of the app.

Even if Signal creates a PIN protected storage key, problem still stands there until user selects a PIN with high entropy. And requesting a high entropy is just not gonna work. People will complain about it. If somehow, it is implemented and people are using it correctly, other problems emerge. (Such as PIN timeout, forgot PIN?). In my opinion, it is not a viable design choice.

So, what can be done? It depends on Threat Model of Signal. If they want to protect data on devices which are compromised, then there are some solutions for key obfuscation which consumes attackers time and money in scale. If they dont, then current solution is already the best one available on the market.

Hi, i just came over this story as well...

Would it be possible to have a optional second key to unlock the SQL database?

Basically everytime you open the app, signal would ask a server for the second half og the unlock key (1 part stored inn keystore, 1 part, device specific, online).

If you loose your phone you could delete the key from the server, and no one would ever be able to read /extract the messages, (unless Reading the memory after the app have been loaded).

Also, you wouldnt be able to read your messages unless you are online first... 🤔

Was this page helpful?
0 / 5 - 0 ratings

Related issues

hiredgunhouse picture hiredgunhouse  Â·  3Comments

ilikenwf picture ilikenwf  Â·  3Comments

Dyras picture Dyras  Â·  3Comments

wesinator picture wesinator  Â·  3Comments

vvug picture vvug  Â·  3Comments