All the encryption mechanisms that we have described so far – email traffic encryption and mailbox encryption – are necessary only because there is no widespread mechanism for end-to-end encryption between the final users. If a full public key infrastructure were in place, users would just follow the enveloped public key encryption (EPKE) paradigm: a user willing to send an email would let his client retrieve the public key of each of the final recipients, sign the message with his private key, encrypt it with the recipient’s public key and send it securely through the network; the recipient’s client would then use his private key to decrypt the message, retrieve the sender’s public key and use it to verify the signature, thus authenticating the sender, and show the cleartext message to the recipient.
All the servers and storage elements involved with the communication would not be able to intercept or decrypt an EPKE-encrypted message, as they would need the recipient’s private key to do so. This paradigm would in fact be even more secure, because even if you use STARTTLS and DANE to encrypt and authenticate every connection necessary for transporting the message, and even if you use private keys to encrypt the mailbox storage, intermediate servers will still decrypt the message when they receive it from the previous server, and then re-encrypt it with a different key to forward it to the next hop or to store it. This means that the message will always exist in clear on any intermediate server for a while, as it is being processed, and so anyone controlling that server may find ways to intercept it.
Solutions for full end-to-end email encryption have been available for over twenty years, mostly under the form of add-ons or plugins for email clients using PGP/GPG/OpenPGP or S/MIME for cryptographic operations, but they were never really successful for two reasons: they are difficult to understand and manage by final users, and there is no global public key infrastructure for retrieving public keys or distributing certificates in a secure and automated manner whenever necessary. In closed environments, such as internal corporate email, these issues could be solved, but for generic email transmission these two issues are still unsolved today.
In managed end-to-end encryption, each email provider creates, stores and manages the keys for its users, uses those keys to encrypt and decrypt messages on their behalf, and makes those keys available for anyone willing to send email to its users.
While managed end-to-end encryption requires the user to have complete trust in his email provider, and while it would still allow malicious providers to abuse and intercept their users, it also removes all the complexity: it can be implemented in a way which is completely transparent for the users. Email providers would be able to tell the users which messages were transported with end-to-end encryption and should be considered secure and legitimate with full certainty; and this is all that users need to know.
Also, managed end-to-end encryption even has some advantages: for example, if full end-to-end encryption is used, no anti-malware and anti-spam check can be performed, except if the user’s client does that after decrypting the message. If the user’s provider knows the user’s private key, on the other hand, the provider is able to decrypt it and check it before storing it or passing it on to the user.
The managed encryption paradigm also allows to include destination users whose email systems do not support any end-to-end encryption whatsoever; if a user of the managed encryption service writes to an ordinary external user, the server creates and stores keys for him, associated to the email address, and sends him a special message with a link allowing access to a private page on the sender’s webmail system, where the recipient can decipher, view and process the message. While this mechanism is limited and not very user-friendly, it works and it provides additional security.
Managed end-to-end encryption is already in widespread use in the instant messaging world; IM applications that provide “encrypted conversations” do exactly that. So the email industry should at least do the same!
We recommend OpenPGP over S/MIME, because S/MIME is based on certificates released by certification authorities, which normally have a cost for the users and which make the system subject to widespread forgery if even just a single certification authority is cracked. Also, to secure email communications it is not necessary to prove the actual real-world identity of the person who uses a given email address, but only that the messages are actually sent and delivered to that email address; and the email provider can grant that better than any third party.
To implement the system, first of all the mail server has to store and use a public/private key pair for each user. The issues in generating and storing those keys securely are the same as for mailbox encryption, so you should apply all the guidelines and considerations already discussed for that. Actually, the service could use the same key pair for end-to-end encryption and for mailbox encryption, though users should be allowed to use two different pairs if they like.
Then, you have to make the user’s public key available to any sender willing to encrypt messages to him. This can be accomplished by establishing an OpenPGP keyserver and making it accessible via HTTPS, using the HKP protocol. The keyserver should be configured so that the access from the open Internet is read-only; no HTTP POST calls should be allowed, and wildcard searches should be disabled. Whenever the user’s keys are changed, the new public key should immediately be published and should be the only one that gets distributed for that user, though the previous one should still be retrievable by id if an older message is opened. At the same time, the previous key should also be revoked by publishing a revocation certificate in the keyserver; to this purpose, a generic revocation certificate for every key should be created and kept by the provider whenever that key is generated, though a newer one should be generated at the time of the revocation if possible, and users should be allowed to upload a revocation certificate for their keys at any time. The generic certificate is also useful to allow key revocation if the user forgets the passphrase for his key.
To let senders know where to find the public keys for your users, you should publish in your DNS zone an SRV record pointing at your keyserver, associating it to the standard hostname “_hkp._tcp.<yourdomain>”. This is a fundamental element, as it allows to overcome one of the traditional issues with end-to-end encryption – how to determine in advance whether the destination address supports it.
When a user of yours submits an outgoing email message, you should consider encryption, and if possible apply it, at the earliest possible stage; so, the following operations can be done by the SMTP server, but if possible they could be done by the client, for example by your webmail application or by your native mobile app.
First of all, you need to determine whether the destination address supports this particular encryption scheme. To do so, you should look up the HKP SRV record for the destination domain, using a DNSSEC-enabled resolver. If no record or an insecure record is found, the scheme cannot be used, and the delivery should either be rejected, or continue without encryption, possibly while showing a warning to the user; whether and how this is possible really depends on the client – it may be easy to do in a webmail interface, but impossible with ordinary email clients. If a DNSSEC-validated HKP SRV record is found, then the encryption process can be started.
In this case, the server or the application has to connect via HTTPS to the destination keyserver, as specified by the SRV record, and retrieve the public key for the destination address. If no public key is found for the destination address, then that address does not support email encryption, and delivery should either be rejected or continue without encryption, as if no keyserver had been found.
For efficiency reasons, public keys could be cached, but not for too much time – definitely not for more than one week, after which they have to be deleted. Then, the sending user’s private key should be retrieved using the user’s password (as the user should just have authenticated with your server or application anyway) and used to sign the message, and the destination user’s public key should be used to encrypt it, creating a secure digital envelope around the plaintext content. The message can then be sent normally.
Whenever you receive an encrypted message for one of your users, before the user can read it, you need to decrypt it with that user’s private key; if the unencrypted message then contains a digital signature, you should look for the sender’s keyserver, retrieve his public key and verify the signature as well.
If you, as advisable, are encrypting the user’s mailbox with the same private key, you could actually defer these operations to when the user logs in to retrieve the message, having them done by your application and/or mail delivery agent; so, you can just store the encrypted message as you received it.
If you are not encrypting the user’s mailbox, or are encrypting it with a different private key, then you need to decrypt the message before delivering it; however, if the user’s private key is protected by his own password that you do not know, you will have to store temporarily the encrypted message as you received it, and only perform those operations when the user logs in and provides his password.
Finally, you should ensure that your users can control and configure the entire process via your own webmail interface and/or customer private area, over a secure HTTPS connection, including the possibility of providing keys that they generated on their own, or revoking the current keys. Alternately, you could support custom in-message indications or special messages to enable encryption and manage keys, but this would be quite a cumbersome system and is not recommended.
Differently from all the previous steps in our email security checklist for providers, this one is not even starting to be widely deployed yet, though several vendors offer “internal” end-to-end encryption that applies to communications among users of the same service; also, this scheme partly relies on new protocols such as HKP, which have not been finally standardized yet. You will have to work a lot with your vendors, and/or try new applications and write new code, to make this happen. Also, you should possibly offer this first to some early adopters among your users and see how it works, before actually pushing it to everyone. However, the Internet only advances by “rough consensus and running code”, and only forward-looking operators will ensure that email stays relevant for the next decades, by making it at least as secure as other, newer forms of online messaging and communication.
