Broken Encryption

[DevinCharles]

• I have searched open and closed issues for duplicates
• I am submitting a bug report for existing functionality that does not work as intended
• I have read https://github.com/signalapp/Signal-Android/wiki/Submitting-useful-bug-reports
• This isn't a feature request or a discussion topic

---

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

[zilexa]

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.

[grandchild]

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!

[greyson-signal]

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*.

[DevinCharles]

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?

[DevinCharles]

"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?

[navid-zamani]

@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! ;)

[sylvandb]

@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.

[Uvaly]

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.

[navid-zamani]

@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.

[navid-zamani]

@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.

[computman007]

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

[greyson-signal]

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

[shyos]

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.

[Richard87]

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... 🤔

[DevinCharles]

@greyson-signal @moxie-signal

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

Is opening a pull request from the Molly fork to incorporate the database encryption feature a viable solution? Ideally this issue should remain closed, as "broken encryption" isn't exactly correct, but I can open a new issue to link.

To everyone saying "we can't implement this because it's too hard for the average user," the Molly fork asks if you want to implement it, and also allows setting a timeout. Depending on your level of tinfoil hat, that can be 30s or 4hrs, the later making it completely transparent for everyday use.

[nazrhyn]

I guess, for me, it's a question of what having UI language like that passcode implies to the user. While as engineers we can say, "Well, it just secures access to the UI," is a user going to think that it is, rather, securing the contents of the UI? I guess it's a matter of perspective and which of those perspectives matters to the developers.

[DevinCharles]

@Richard87

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

The only option for this (now, and likely ever) is to move over to the Molly fork:
https://github.com/mollyim/mollyim-android

[DevinCharles]

I guess, for me, it's a question of what having UI language like that passcode implies to the user. While as engineers we can say, "Well, it just secures access to the UI," is a user going to think that it is, rather, securing the contents of the UI? I guess it's a matter of perspective and which of those perspectives matters to the developers.

Can't tell if you're responding to me or to @greyson-signal. If it's the later, I agree entirely... Which is exactly the point... I assumed that this super important PIN that I'm asked to remember constantly was actually doing something, but turns out, it is not.

Security is the onus of the user, so my bad.

If you're referring to the database encryption passphrase that I mentioned in the last comment that's available from the Molly fork, take a look for yourself:

https://github.com/mollyim/mollyim-android/wiki/Data-Encryption-At-Rest

[nazrhyn]

@DevinCharles Mostly responding to the responses that said that the PIN just secures access to the UI. Sorry, I should've found something to quote.

[DevinCharles]

@navid-zamani Sorry for taking so long to respond to this, life came up and I was otherwise predisposed. I'd like to talk through this, because you come off as a bit of an expert in your comments. I certainly am not, as I've explained above, but I'd like to address some of your statements so they're not taken as fact by other readers until they're cited.

Please, security experts @greyson-signal @moxie-signal, correct all the stuff at which I'm confidently incorrect. Also, this is certainly a diatribe, so fell free to remove it.... but: dopant-level hardware trojans AYFKM

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.

This is true for the current way that Signal operates, but is not a fact for encryption in general, or even on Android devices. You can encrypt files, which is what I'm talking about in this whole thread.

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

YES!

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.

Nope! This is kind of the point I'm addressing, and you're stating this as a fact which is completely preposterous. Please, cite this if you have references, because it means that the entirety of secure file systems on mobile devices used by the world over is in danger. Physical access should never mean access to file encryption; that is, by definition, the point of encrypting individual files, with a passphrase. Certainly, if you use a key file without passphrase unlocking, this is absolutely incorrect.

The best you could do here, is have Signal not work at all unless you are currently using it.

Yes!

(Losing the ability to receive messages if locked.)

Nope!

And to have an external, key device with its own keypad and display too for entering the code and pass everything through.

...no.

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.

TLDR: yeah, but mostly no. But, we need to stop saying this kind of stuff.

This is sort-of true. This again brings up the discussion of attack vectors (or models, surfaces, tensors?, whatever term makes you sound smarter). The problem that I have, being a naïve user of encryption, is that every time I'm like "well, what if someone does 'x', and it breaks this?" everyone always responds: "well: if a plane crashes into the server and the pilot jumps out at the last minute there's a 14ms window where she can obtain your keys so obviously, you're an idiot for even asking about that, because
threat tensors." Look... if someone has root access to your phone (or any other device)... while you're actively using it, and somehow has access to memory, at the time that you enter you passphrase, or before it clears again (you can actively manage this, a bit), then yeah, you're probably effed. But we're not all hacking the CIA. What I'm asking for here, is for basic users, who know nothing about encryption, and may be living in a place where free speech isn't always encouraged, to have security from who ever may gain access to their device, and then gain root access, because this is the more likely threat (vector, surface, tensor).

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.

Dude... this is worse tinfoil hat than me. But it's mostly wrong too. Yup, chip fab is the real-deal, if you're protecting something no one else should ever have access to, but in that case you'd be using a home built board with no external communication in an air gapped room specifically made for such data. Again, with the pilot who magically obtains your keys...

Also, dopant-level hardware trojans are you effing kidding me. I'm asking for password encryption on files, and this guy is worried about, well, Marvel solder nanobots from the future?

…
Good luck with that! ;)

This is entirely the reason for this response. Don't be a self reassured ass. I don't know WTF I'm talking about, but it's pretty clear you don't either, the difference being, you sound a lot more confident in your nonsense.

[greyson-signal]

There's a lot going on here, but I'll just reiterate some points:

The screenlock is just that -- a screenlock. It does not interact with message decryption.

The "Signal PIN" is part of our Secure Value Recovery, separate thing. That's for backing up your social graph in a cool secure way so that you don't lose your contacts and groups on re-install. Please read the blog post for more details. (I'm aware having multiple "PINs" is confusing, but that's what happens when you add lots of features and try to centralize later 😃)

We have no plans for allowing a user-specified encryption key that only decrypts messages when opening the app.

Thanks!