12

I'm creating a mobile app which has chat feature in it. Since I wanted to make it secure, I'll do some encryption to messages and the data. I'm thinking of using End-To-End encryption for it but I've got some issues.

Each user will have private and public keys to encrypt and decrypt the data (asymmetric key encryption) and I figured out how to exchange this keys between. So End-To-End encrypted messaging is done.

Here are my issues:

If user changes the device or reinstalls the app, the private key which stored on client will be lost. I know I can create new key pairs for future messages but how can I restore the old ones?

I thought storing the private key in server but it won't be secure at all. I thought storing the private key after encrypting it with user password, it would be secure since I don't know the user's password, but it fails too if user lost his/her password and re-creates one with a "lost my password email".

And another issue is if some legal issue happens, I can't give the chat logs to police because I don't have the decrypted messages or I don't know how to decrypt them because I don't have the private key.

So, how should I handle this issues? How does WhatsApp do it while using End-To-End encryption? You can restore the old messages in WhatsApp after changing device, updating or re-installing the app etc...

I read something about re-encrypting and re-sending the messages from the other user. (Receiver-Sender) But I don't know how effective it would be tho.

Any help would be great. Thanks for all information and help.

Glorfindel
  • 2,235
  • 6
  • 18
  • 30
Eagleclaw
  • 247
  • 2
  • 5
  • 35
    *"Each user will have private and public keys to encrypt and decrypt the data ..."* - sounds for me like a bad design from start since it provides no forward secrecy: once the private key is compromised all intercepted older messages can be read too by an attacker. For anything related to crypto it is recommend to not run your own design here but use existing widely discussed and established designs, like the Signal protocol. – Steffen Ullrich Feb 22 '21 at 07:45
  • 9
    [Here's how WhatsApp does it](https://security.stackexchange.com/a/238813/118310). – defalt Feb 22 '21 at 08:31
  • @SteffenUllrich i meant a key exchange like diffie hellman by there. I'm not trying to create my own design but i'm trying to choose the best designs and combine them to create a hybrid system. If i didnt understand wrong, using private-public keys to exchange shared key, (async and sync) is a hybrid system. It must be good for security and speed but recovery and legal cases is what bothers me. Thats why i've asked my question. – Eagleclaw Feb 22 '21 at 09:59
  • @defalt i saw that post but i created this post to clear my head and get answers to my questions. Thanks for the info tho. – Eagleclaw Feb 22 '21 at 10:00
  • 26
    If you can decrypt messages for the police, then it's not e2ee. The backup shoud be done locally by the client and it should be encrypted. Derive a key from user's password like Signal does or store the key at server but not the backup like WhatsApp does. – defalt Feb 22 '21 at 10:19
  • @defalt Well you're right about its not e2ee case. But holding a key in server without backup, isnt it useless? I mean if user deletes the local storage, i cant do anything with the key. So it comes to either its not e2ee or its not restored. Am i right? – Eagleclaw Feb 22 '21 at 10:23
  • May I suggest [Paper keys!](https://en.wikipedia.org/wiki/Paper_key) and [BIP39](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) – Anunay Feb 23 '21 at 01:03
  • @defalt: If Whatsapp ever pushes an update that sends your backup to them, then they can get it all. Ultimately, you still need to trust the app and trust that nobody will be able to hack the update mechanism and push a malicious update. – user21820 Feb 24 '21 at 07:09
  • You might consider reading the white paper with Keybase's approach -- basically, if one client gets lost, another client owned by the same user is responsible for reencrypting their content. User loses all their clients -> their data is gone, unrecoverably. As a user, I trust this _far_ more than anything that provides a "recovery" mechanism someone without my keys could use. – Charles Duffy Feb 24 '21 at 22:46
  • 1
    @Eagleclaw I don't think Diffie-Hellman is exactly what you think it is. DH is a way for the two parties to mutually derive _ephemeral, shared_ key material on-the-fly with no prior knowledge of anything by either party. There are no public keys involved in DH itself. However, lots of schemes (such as TLS) use public key cryptography for one or both sides to authenticate themselves to the other (which is required if you want to be sure that you're not being MitM'd.) Once the DH and authentication are done, shared-key encryption is normally used to encrypt the actual messages exchanged. – reirab Feb 24 '21 at 23:34
  • @Eagleclaw The DH is just used to generate the shared key material in a way that requires no prior knowledge by either side and from which someone who is watching the messages can't also derive the key material. – reirab Feb 24 '21 at 23:35
  • "I can't give the chat logs to police because I don't have the decrypted messages" - Yeah that's kind of the point of E2E encryption – F Chopin Feb 25 '21 at 02:15
  • Signal is open source and non-profit. You can check out how they do it. https://github.com/signalapp – Snives Feb 25 '21 at 03:55

4 Answers4

35

You have found another example of the balance security vs usability. If you want true E2E encryption, end users are responsible for their keys and for possible backups of their messages. Full stop.

If you stray from that path, you will fall in a grey zone where everything is E2E encrypted but some features allow to recover messages. Said differently: even if traffic were encrypted, the software can still access old messages - which defeats the point of E2E. WhatsApp, for example, chose to implement the ability for a user to ask for a re-send of all their passed (received) messages without the sender being aware of that. If a user genuinely changes their smartphone, they "automagically" recover all of their old messages. Great... But that means that the application contains all what is required for the system to ask to send everything to a rogue address. Gulp...

That being said, you will have to make some executive decisions here. Provided that you and your users are aware that any recovery option does lower the overall security, that will be fine. Do not worry too much -- while most users insist for everything they send or receive to be strongly E2E encrypted, for most users it is far more important to be able to recover their messages than to totally prevent an attacker from accessing them... For better or for worse, most users aren't aware of the full definitions of E2E encryption and strong cryptography, and are usually satisfied with them being claimed

Ryan Amos
  • 253
  • 1
  • 7
Serge Ballesta
  • 25,636
  • 4
  • 42
  • 84
  • 5
    WhatsApp resends only those messages that were not delivered before the recepient uninstalled WhatsApp. WhatsApp web service asks sender to resend undelivered messages by renegotiating keys with the recipient. The retention period of undelivered messages is 30 days. Chat history is restored by either cloud backup or local chat backup. – defalt Feb 22 '21 at 09:59
  • You explained the two scenario that i'm thinking of. Either i go full e2e which is the safest for user but i'm losing the ability to backup messages for user or in a legal case sharing that messages with police. Or i encrypt messages as mush as i can but with a backdoor. This gives me the ability to do what i cant do in full e2e but if there is a backdoor that i can use, so can attackers use that too which is not safe at all. – Eagleclaw Feb 22 '21 at 10:06
  • @defalt: I know that WhatsApp do their best to secure the *resend* feature. Yet it resends message without the sender being aware of it. – Serge Ballesta Feb 22 '21 at 10:44
  • 2
    @SergeBallesta and so as a user, you can nerver be sure that your whatsApp client doesn't do a cc:FBI anyway (routinely or upon request) – Hagen von Eitzen Feb 22 '21 at 17:36
  • @HagenvonEitzen: I'm pretty sure they don't, and don't want to. And for all of my personal messages, I do trust WhatsApp security. But because of the Patriot Act, I still think that members of foreign *organizations* (governments or important companies) should not use WhatsApp to exchange strategic informations. – Serge Ballesta Feb 24 '21 at 08:35
  • 1
    @Eagleclaw If a platform claimed E2EE and also could cooperate with authorities, it would be suspect. If the system has *any* kind of backdoor, that is the front door for hackers and OPSEC. – Snives Feb 25 '21 at 03:51
  • @Snives: what you describe is exactly WhatsApp. They claim that they do not transmit informations to the authorities, but they *could*... – Serge Ballesta Feb 25 '21 at 08:00
19

If user changes the device, reinstalls the app, private key which stored on client will be lost. I know i can create new key pairs for future messages but how can i restore the old ones?

Why do you need to restore the old ones? Generate new keys and distribute. They private key should not leave the device it is generated on. If you need message history, store that locally on the users device, not on your servers - and give the user a option to back it up. This is roughly what Signal does.

I thought storing the private key in server but it wont be secure at all. I thought storing the private key after encrypting it with user password, it would be secure since i dont know the user password, but it fails too if user lost his/her password and re-create with a "lost my password email".

Don't store the keys for the user. Period. That makes E2E kinda meaningless.

And another issue is if some legal issue happens, i cant give the chat logs to police because i dont have the decrypted messages or i dont know how to decrypt them because i dont have the private key.

You can't hand over anything you don't have. If the messages is E2E, and you don't store them, there's nothing you can give the police. That is the point of E2E - the provider doesn't have the messages, and can't reveal them to anyone.

vidarlo
  • 12,850
  • 2
  • 35
  • 47
  • Local storage isnt actucally bad idea to keep messages but i dont know how i can use it for multiple devices with a same account. For example Facebook messenger. User can message from either mobile app or web browser. Either way user can access to all informations. I cant user full e2ee in this case or i guess i can use a QR code to connect to other devices and share the info i guess. My problem comes to security vs useability question. – Eagleclaw Feb 22 '21 at 10:09
  • 1
    @Eagleclaw if you turn on the E2E encryption feature in fb messenger, it restricts you to only using your mobile. You can't easily do this without weakening E2EE and each platform chooses their trade-offs carefully – coagmano Feb 23 '21 at 02:31
  • You could broadcast a copy of each message to the various subscribing devices. Each app would have a different public key which would need to be shared but this implementation would be no different than group messaging. The server would queue the encrypted messages for each device until they picked them up, as usual with E2EE. – Snives Feb 25 '21 at 03:39
6

I'd recommend you to take a look at other platforms (like Matrix and Keybase) on their implementation too. Storing private keys on a server entirely breaks the point of using e2ee, as the server can now basically view all the chats.

What I'd recommend using is some kind of Paper Key/Seed Phrase (check BIP39) which can be printed/written on a paper, even memorized, and make it clear that losing this key can result in losing access to old chats. You can optionally allow users to make cloud backup of the keys (I highly discourage it), for those who do not wish to take the benefits of e2ee. I'd encourage to notify the other user if this is the case.

Also I'd recommend checking Matrix.org's implementation of Multi device cross signing, for a guide on how to allow multi-device support.

Also I'd recommend reading keybase.io's blog posts [1][2][3][4][5] on how their system works.

Personally I do not really see a point in reinventing the wheel, matrix.org's implementation does exactly what you want, and you can compliment with your own features/webapp (Think of matrix.org as Email and your app as Gmail).

Anunay
  • 161
  • 4
3

Most good options have already been covered in the previous answers. There is one other option that is worth mentioning: allowing the user to export the private key, and storing it somewhere they consider secure, perhaps in their password manager. This approach has several shortcomings but also a few advantages: It achieves recoverability without completely losing the point of e2ee, as your servers will never have access to the private key. On the con side, it does leave the safety of the private key in your users' hands, even more than before, and opens them up to phishing attacks where someone might try and trick them into sending their private keys to an adversarial party. You'll have to consider what level of expertise there is in your expected user base. This approach might be fine if you're targeting people from this community, but if you're targeting our grandma's, I probably would not advise it.

Soufiane Tahiri
  • 2,667
  • 12
  • 27
Anders Martini
  • 131
  • 1
  • 1
    I thought something similar yesterday. My thinking was backing up the private key on OS Cloud service like Google Drive, iCloud etc. Since cloud provider doesnt have the messages, they cant get the messages and since i dont have the private key, i cant get the messages aswell. The idea is the same tho. I might use the idea of exporting too, not a bad idea. Ofc i'll warn the user to not share that key with anyone else, use only for recover tho. Thanks for your answer... – Eagleclaw Feb 24 '21 at 12:04
  • It's still better to allow the user to provide a password to the app, which is used to generate a longer private key. Then only store the hash of the password to validate their login, also on the app. Then the app would never store their password, or their private key. Only at login would the private key get regenerated to decrypt the local database. – Snives Feb 25 '21 at 03:31