4
$\begingroup$

A big drawback of end-to-end encrypted messaging services is that, as soon as you lose your device, you lose all your messages. Your private key is gone after all. I was wondering though, wouldn't it be possible to do the following in a chat app for iOS, using certificate pinning and TLS for all communication with the server:

  1. as soon as a user logs in in the app, an asymmetric keypair is generated and stored locally, and the public key is sent to the database;
  2. when user X starts a chat with user Y, X's device generates a symmetric encryption key, stores it locally, encrypts it using Y's public key (downloaded from the central database), and sends the cyphertext to the database;
  3. Y's device, as soon as it comes online, downloads the cyphertext, decrypts it using it's private key, and stores it locally.

Now, X and Y both have the key generated by X's device and can send messages to each other using symmetric encryption, and nobody, except for X and Y of course, has the symmetric encryption key. When, lets say, X gets a new phone, the following will happen:

  1. X logs in on the new device and sends the new public key to the database.
  2. Y's device will notice that a new public key was uploaded, downloads this key, encrypts the symmetric encryption key (that it received in step 3) with X’s new public key, and sends the cyphertext to the database.
  3. X's device downloads the cyphertext, decrypts it using its private key, and can now download all old messages and decrypt them.

So, I guess my question is: what am I missing that makes my design unsafe? Is it just not smart to store keys in the database for a long time, even when they are encrypted with strong asymmetric encryption (lets say like 8192 bits, just for fun)?

Also, I am an iOS developer, and all keys would be stored in the iOS keychain, which is a very safe way of storing information locally. Nothing is 100% secure, I know, but storing stuff there is pretty much the best you can get on iOS as far as I know.

Improve this question
$\endgroup$
3
  • 1
    $\begingroup$ Well, despite using PKI, this makes no attempt to authenticate user X to user Y. ​ ​ $\endgroup$
    – user991
    Jan 3, 2016 at 0:00
  • $\begingroup$ Guessing the password gives access to the account, the private key is effectively useless; the private key needs to be derived from the password. Also no forward secrecy. In general, this is possible. Its just that nobody does it because you would need to charge people for the service (as, obviously, you cannot sell other peoples data) and other, free alternatives are "secure" enough for most people. $\endgroup$
    – marstato
    Jan 3, 2016 at 0:02
  • $\begingroup$ @marsato why would the private key be useless? It's used to exchange the symmetric key. Also, an exchanged symmetric key doesn't give access to the account, it only gives access to all messages in a chat. The login process uses something like Facebook login for example $\endgroup$
    – Joris
    Jan 3, 2016 at 0:15

1 Answer 1

Reset to default
1
$\begingroup$

One problem is that the server is in complete control of authentication and trust, and could easily claim that X has a new key-pair, causing Y to encrypt the symmetric key for a server-controlled key. So at least against some attack scenarios you effectively lack end-to-end encryption.

Another issue is that the use of a long-term symmetric key to directly encrypt the messages means that there is no forward secrecy. If the symmetric key is at any point compromised, all communications between the parties can be decrypted, even those that happened far before.

Improve this answer
$\endgroup$
2
  • $\begingroup$ You make good points, thanks! If I understand correctly, I can solve the first point by using something like Diffie-Hellman key exchange to exchange a symmetric key? $\endgroup$
    – Joris
    Jan 3, 2016 at 11:10
  • $\begingroup$ @Joris, you would need some way to authenticate the user independent of the server. I.e. a long term key/pair, which you are trying to avoid. Perhaps using a normal end-to-end protocol (like OTR) with a password-encrypted private key stored in the server would be better? $\endgroup$
    – otus
    Jan 3, 2016 at 19:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.