A Solution to the Email Privacy Issue–Apple and Google, Take Note!

How to Provide Ultra-Secure Email Privacy and Still Give the Government What It Wants

As everyone who has not been living under a rock for the last few weeks knows, the FBI is asking Apple Computers to provide assistance in unlocking the encrypted iPhone used by one of the two San Bernardino shooters involved in a horrific terrorist attack that left 14 dead and 22 seriously injured last December. A court has issued an order compelling Apple to comply; Apple now has until February 26th to reply to the order.

At issue is not whether the dead shooter is entitled to privacy protection, since the dead do not have privacy rights (that’s why doctors are permitted to discuss details of their deceased patients’ health records). Also, the phone used by the shooter was actually owned by his employer, the County of San Bernardino, which has given the FBI permission to access the phone.

The problems that Apple, Google and others apparently anticipate are twofold:

  1. that complying with the court order could provide a precedent for future requests of a similar nature
  2. providing a “back door” to decrypting user data could undermine the privacy of all users

These are valid concerns, but they stem from the belief that in order to provide email privacy, the message content must be encrypted as it travels through the mail network. One often-used analogy is that of a postcard being sent through the mail system: like a postcard, which anyone between the sender and the recipient is able to read, cleartext (unencrypted) email content is likewise visible to anyone eavesdropping on the email network, including criminals, the government and mail service providers (MSPs).

But what if the postcard, instead of including a message, instead had a phone number that, when called and after suitable credentials are provided, delivers the message? This is, in effect, the basis of Envelope-Content Splitting (ECS): the message content, rather than being sent through the email network attached to the email header (sender, recipient, subject, etc.), is sent via a secure connection to a content server, which manages the content and provides a pointer to it. The pointer is then included in the email header and only the header is sent through the unsecure email network. When the header arrives at the recipient’s Inbox and the user selects it for reading, the user’s email client would use the pointer and other information, including the user’s email address and content server password (not to be confused with the user’s email password) to request the content from the content server.

The first thing one might notice about this scheme is that since the actual message content is not a part of the message as it travels through the email network, no encryption is needed while the message is in flight. However, what about the content, which is kept on the content server? That can (and should) be encrypted in the sending email client prior to sending the content to the content server; thus, the data stored on the content server is encrypted and the key is kept elsewhere, so even if someone were to hack into the content server, without the decryption key they would not be able to decrypt the data and email privacy would be preserved. So then the question becomes, how is the decryption key conveyed to the email recipient? This is part of a process known among implementers as “key management”. In the ChiaraMail implementation, the content is encrypted using AES, a symmetric encryption methodology, meaning the same key is used for encrypting and decrypting, and the key is included in the email header; in this way, even though the MSP (and anyone eavesdropping on the message while in transit) has access to the encryption key, they are unable to access the content without the sender’s or recipient’s content server password, which is kept in the respective email clients. And as long as the content server is properly secured (the ChiaraMail content server has received an “A+” security rating from Qualys SSL Labs, while Apple got an “A” and Google received a “B”), breaking into the server is unlikely.

An ECS implementation can be made even stronger if, rather than inserting the encryption key into the message header, the email client were to send the key, again using a secure connection, to a key database, where it would be stored salted and encrypted and accessed using the sender’s or recipient’s ECS credentials. Furthermore, by having a third-party, such as a consortium consisting of major mail service providers but organized as a separate company, perhaps outside the United States, host the content server, email privacy is assured but the government, through the proper legal channels, would still be able to obtain the data it needed, through subpoenas delivered to both the MSP and the content provider. In other words, the MSP or other unauthorized parties would not be able to obtain the content without access to the content server, and the content server would not be able to access the data without the encryption key, which is controlled by the MSP. This is truly a win-win for all parties and an elegant solution to the issue at hand.