Is server-side cryptography with user-only access possible for email services?

Question

I came across the Lavabit High Scalability Writeup and got curious.

Do you use any particularly cool technologies or algorithms?

The way we encrypt messages before storing them is relatively unique. We only know of one commercial service, and one commercial product that will secure user data using asymmetric encryption before writing it to disk. Basically we generate public and private keys for the user and then encrypt the private key using a derivative of the plain text password. We then encrypt user messages using their public key before writing them to disk.

As far as I know Lavabit also offered a webmail client. Is server-side cryptography possible where only the user can decrypt the messages but a webmail access is offered at the same time? Lavabit claimed it could not retrieve the password if it would be lost, which means it also could not be reseted, can it?

This would mean the user's credentials need to be stored in the database in order to authenticate him/her. This very same password is used to generate the derivative which is then again used to decrypt the private key which then again can be used to decrypt the public key encrypted emails.

Does that not mean, that Lavabit is/was in possession of the passwords? To my mind, this would only make sense if two passwords are required. A password to authenticate the user and a passphrase to unlock the private key. Where the passphrase, as opposed to the password, is not stored in the database, but entered every time by the user without persisting it somewhere.

Similar I found in the MyKolab.com FAQ's:

Some other providers claim to use server side cryptography to store my data encrypted so they cannot access it. Do you do that as well?

We currently do not have any plans to do that. The reason is simple. With server-side encryption, the provider holds the encrypted data, the key, and the passphrase, as all three need to pass through the web interface and be available on the server. So the provider does have access to all the data despite the encryption.

We don't believe in misleading our users in this way.

The only solution would be client side encryption of everything, but that's very hard to implement and there is a whole set of standards missing on the browser side to do this properly and securely, also keeping in mind that sand boxing in browsers does not work from a security perspective. Therefore, we suggest to use native clients such as Kontact and use GnuPG for end-to-end encryption.

So what did Lavabit mean when they said retrieving the messages would not have been possible? How can this work in a secure way, respectively only as MyKolab.com has stated it?

Answer 1

The "Lavabit High Scalability Writeup", that you link to, includes this passage, which is enlightening:

Because we need the plain text password to decrypt a user’s private key, we don’t support secure password authentication. We decided to support SSL instead (which encrypts everything; not just the password).

So here is what they do:

• When the user registers, he chooses a password and sends it to the server.
• An asymmetric key pair (apparently ECDH) is generated on the server.
• The server stores the ECDH public key, and also the private key, but the private key is symmetrically encrypted with a key derived from the user's password. The user's password itself is not stored.
• When an email is received (through SMTP), they encrypt it with the user's ECDH public key (with hybrid encryption, possibly ECIES or a variant thereof). They can do that because they have the public key.
• When a user connects, through POP, IMAP or the Webmail, simple authentication is used: the user shows his password. The server then uses the password to decrypt the stored ECDH private key; if the private key is obtained and matches the stored public key, then the user is deemed authenticated.
• As long as the user is connected, the ECDH private key is kept in the server RAM, and the server uses it to decrypt the user's emails for him.

So the server never stores on its disk the user's password or the user's ECDH private key in clear form. However, they obtain both at some point, but they keep these things in RAM, safe from leaks through stolen backup tapes or SQL injection attacks.

"Secure password authentication" is a kind of challenge-response system where the client does not show the password, but computes a response to a challenge, the response using both the challenge value (sent by the server) and the password. This kind of protocol is a partial protection against password disclosure when the server's identity is not guaranteed (from the client's point of view) or the connection between client and server could be eavesdropped. Since Lavabit uses the user's password both for authentication and for server-side decryption of the ECDH private key, they cannot support "secure password authentication". However, "secure password authentication" implies plaintext storage of the password on the server, so it is not really secure; a more thorough and safer solution is to wrap the whole dialog into SSL, which is what Lavabit does.

If Lavabit wants to purloin the user's emails, well, they can, since they have the user's private key in RAM at several points (when generating, and every time the user connects). However, they must have the plaintext emails too, because that's how the SMTP protocol works: the server necessarily has access to the plaintext emails when received and when sent. In that sense, use of server-side cryptography in Lavabit does not weaken the model.

---

If you want email protected from the servers (all involved servers), then you must have client-side cryptography with software which is not dynamically obtained from the server, because otherwise the server could still feed you malicious software. So, install something like GnuPG. This, of course, will not work well with the Webmail (the Webmail will let you read... encrypted emails) unless you also install a nifty browser plugin like FireGPG, except that this plugin is discontinued and unsupported.

Without client-side cryptography, I would say that what Lavabit does is fine and is about the best that could be done. (I don't comment on the implementation, which I have not reviewed in any way; I am describing the conceptual design.)