Nobody likes the NSA , or anyone else , spying on their email activities.
Many secure email systems have all shuttered , because they were compelled by courts to invalidate their security or feared that possibility.
Here are two popular models and weaknesses :
1. *Send/Receive unencrypted email , encrypt on server.* This is what Lavabit did. The weakness is that the government is able to compel the provider to copy/clone/divert the unencrypted mail.
2. *Web based mail, encrypted in browser.* Hushmail did this. Their weakness is that the government is able to compel them to deliver a compromised applet/library onto the client side browsers.
In order for email to be reasonably secure, it requires a few key components:
1. *End-to-End Encryption.* Data must be encrypted by the Sender and decrypted by the receiver. Service providers should never be able to access a plaintext version or have the means to decrypt a message.
2. *Full Transparency of Code.* Email clients must publish their source code and libraries, so that any sort of backdoors can be identified. Without open-source and full transparency, Service Providers and Software Vendors can be compelled by courts to offer insecure products.
3. *Required Encryption.* Plaintext emails should not be deliverable at all. This would force widespread adoption of secure email , and keep ‘snoopable’ email off of email servers.
In order to achieve this , I suggest the start of novel improvements to current email as follows:
1. All emails should be encrypted via public-key cryptography within the email client.
– Outbound email is encrypted for the Recipient
– Drafts are encrypted for the Sender
– An email header contains a digest of the key used for encryption
2. SMTP should be extended with new commands and responses ( SSMTP ). Generally speaking :
– SMTP servers should reject unencrypted email
– SMTP servers should reject email with an unknown or expired Public Key
It would be trivial to extend a SMTP server like Exim with those requests. Many mail servers easily connect to SQL or LDAP backends to find delivery information; extending this information with a list of VALID and INVALID public keys for each user is trivial.
A current SMTP example looks like this ( from http://en.wikipedia.org/wiki/SMTP )
S: 220 smtp.example.com ESMTP Postfix
C: HELO relay.example.org
S: 250 Hello relay.example.org, I am glad to meet you
C: MAIL FROM:
S: 250 Ok
C: RCPT TO:
S: 250 Ok
C: RCPT TO:
C: DATA
S: 354 End data with
C: From: “Bob Example”
C: To: “Alice Example”
C: Cc: [email protected]
C: Date: Tue, 15 January 2008 16:02:43 -0500
C: Subject: Test message
C:
C: Hello Alice.
C: This is a test message with 5 header fields and 4 lines in the message body.
C: Your friend,
C: Bob
C: .
S: 250 Ok: queued as 12345
C: QUIT
S: 221 Bye
{The server closes the connection}
A more secure version would be:
S: 220 smtp.example.com SSMTP Postfix
note that Secure SMTP is required
C: HELO relay.example.org
S: 250 Hello relay.example.org, I am glad to meet you
C: MAIL FROM:
S: 250 Ok
C: RCPT TO:
S: 250 Ok
C: PUBLIC KEY: ca978112ca1bbdcafac231b39a23dc4da786eff8147c4e72b9807785afee48bb
S: 250 Ok
A hash of the public key is provided. It is allowed.
Perhaps the key has been expired ?
C: PUBLIC KEY: ca978112ca1bbdcafac231b39a23dc4da786eff8147c4e72b9807785afee48bb
S: 541 EXPIRED KEY
Assuming we have the key, send the message…
C: RCPT TO:
C: DATA
S: 354 End data with
C: From: “Bob Example”
C: To: “Alice Example”
C: Date: Tue, 15 January 2008 16:02:43 -0500
C: Subject: Test message
C: <<
C: .
S: 250 Ok: queued as 12345
C: QUIT
S: 221 Bye
{The server closes the connection}
The message is encrypted in a payload
There are some caveats with this approach.
1- This greatly complicates multiple recipients — ie , CC and BCC
2- A new Mail format might be needed. Currently, email headers contain a lot of sender/recipient information — as well as the subject lines. In order to be fully secure, the Subject line needs to move into the encrypted payload. Other headers would need to either move or be stripped. at the least, something like this should exist.
MESSAGE
+ unencrypted headers
– to
– from
+ encrypted payload
– headers
. subject
. etc
– body
3- The distribution of Public Keys is troublesome. At first I thought servers could advertise public keys as a directory service, and delivery failures could contain a “New Key” attachment. However, this creates a potential for a man-in-the-middle attack. For example, the NSA could compel an ISP to work with them by advertising an NSA key , decrypting and storing the message, then re-encoding the message with the proper key. It would be possible to identify this with Message Signing , but one or more messages would have been stolen.
Nevertheless, a secure method of distributing and verifying public keys would be needed.
There are complications and weaknesses in this approach, but I feel they are significantly smaller than other approaches I’ve seen lately.
In any event, I don’t think it’s possible to make the current SMTP system reasonably secure — I believe we need to change/extend it.