Even if the transmission of an email throughout the Internet is fully secure, there is still another big risk for the privacy and security of your users: mailbox cracking. If mailboxes are not secured, either a badly intentioned system administrator or an external intruder will be able to read all messages for all users, once gaining access to the server where mailboxes are stored.
There is no technical standard yet to do this, and you will have to rely on your vendor; professional vendors should (and do) provide solutions to this problem; free software solutions are also available, though their use for email storage is mostly experimental. Solutions for mailbox encryption commonly use the OpenPGP standard to encrypt individual messages at reception before storing them, though providing an encrypted filesystem for each mailbox could also be an option in small-scale situations.
The OpenPGP standard relies on asymmetric cryptography: whenever the server receives a message for a given user, it will use the user’s public key to encrypt it before storing it, so that only the user, with his secret private key, will be able to decrypt the content of the mailbox.
Ideally, the user’s private key would be safely stored, and kept secret, inside his email clients on his devices. Unfortunately, not many email clients today support mailbox encryption or asymmetric cryptography in a simple manner, and users will anyway want to access their messages also through remote clients, such as a webmail interface. This means that the server needs to know the user’s private key as well, in order to be able to present the messages in unencrypted form in the system’s webmail interface and to clients not supporting encrypted mailboxes.
Thus, you need your mail server to possess a public and a private key for each user and mailbox; more specifically, keys and all cryptographic operations have to be managed by the mail delivery/storage agent, while other elements of the email service architecture should not be able to access the keys or to decrypt stored messages. While the public key can safely be stored on the server as it is, secure private key storage is a crucial problem.
If you stored private keys on your server as they are, an intruder could simply use them to decrypt the stored messages, and so your system would be practically useless. So you need to encrypt the private keys as well before storing them.
The best way to do so, well supported by OpenPGP, is to encrypt the private key with a passphrase or password that only the user knows, and that the user will provide to the server every time he wants to access his messages. There is already one such password that the user knows and enters regularly: it is his own mailbox password, the one that the client will provide whenever connecting via IMAP or logging into the webmail. So the best solution is to encrypt the user’s private key with his mailbox password before storing it. Every time that the user connects to the server with a client or through the webmail, and enters his password, the system will use that password to decrypt the private key and then use the key to decrypt the messages in the mailbox, before showing or returning them to the client.
However, there may be the need for additional flexibility in private key management. Paranoid users may ask to be able to use a different passphrase on their private key, and to enter it separately and in addition to their mailbox password, though this is generally unsupported by email clients and could only be managed in a webmail environment, so we recommend against this.
More importantly, it may be necessary that the service provider is able to access the user’s private key and messages without his consent and without knowing his password, for example to comply with law enforcement duties, or to allow the retrieval of the private key in case the user forgets the password/passphrase (otherwise, in this case, the entire content of his mailbox will be lost!). In this case, you could separately store a copy of every user’s unencrypted private key, encrypted with the public key corresponding to a private “master key” of your own. However, if you do this, you should:
- make this very clear and transparent to your users, and get their consent appropriately in terms of any applicable privacy and data protection law; if you are legally allowed, you should permit your users to opt out of this mechanism, but in this case you should also make it very clear to them that if they forget their password they will never be able to read their past emails again;
- never store the private master key on the server as well, but keep it securely stored somewhere else, so that only very few authorized people can access it; you should only retrieve it when strictly necessary.
Advanced, privacy-aware users will not like the idea that their email provider generates their keys, because this would allow an abusive provider to keep an unprotected copy of the user’s private key and to read all his messages anyway. So, for these users, you could provide a way to upload a private/public pair of keys that they generate on their own, maybe with the private key already protected by their mailbox password.
On the other hand, most users will not have a clue about what we are talking about, and will just want to opt in to some additional security in a way that is transparent to them and does not require any complex action on their part. For these users, you should provide an automated key generation mechanism, for example in your webmail or in your customer private area; by pushing a button and agreeing to the conditions, they can ask the server to generate and store the keys for them, and to start encrypting the messages in their mailbox.
In both cases, you should check and ensure that the keys meet some minimum technical requirements for security: they should be at least 2048-bit long for RSA, and at least 4096-bit long for Diffie-Hellman.
