Returning privacy to E-mail

The key to deploying encrypted mail is to make it happen with close to zero involvement by the user. This is hard, and requires some security compromises that have made cryptographers uneasy in the past.

However, I have come down to the view that getting encryption widely deployed, even with some minor flaws, is better than getting perfectly designed encryption (if that's even possible) that hardly anybody uses.

The reason is that I exchange mail with tons of people, not just my closest linux-using nerd friends. If I want my mail to be private, I have to get the general public encrypting. This is a particular concern with new laws just passed granting U.S. law enforcment the power to read the "header" of a message -- including the subject lines of E-mails without a warrant. In addition, other nations have always had such powers, and on top of it all, most ISP backbones and mail servers are poorly secured from snooping by almost any system cracker trying to invade your privacy.

To make this happen, several people have advocated a system where all mail you send out contains a special header revealing that you can do encryption and signing, what method you use, a one-time string, and your key, or a fingerprint and URL for your key.

(Among such systems are pps and Herbivore.)

If you send mail to somebody your mailer doesn't know, you include this header. If they also have an encryption tool, and they see this header, their tool records the information. Then, any reply to you they send is encrypted with your key. And the first reply contains their key. After you get that encrypted reply, you know their key and they know yours, and all future mail is encrypted, and signed. It's private, and nobody else can access it, and you can be sure the mail you get is coming from somebody with access to the E-mail address it says.

Now it turns out that the vast bulk of E-mail out there is replies, and only a very few messages are first-time-ever messages with people. As such, this system quickly starts making most mail encrypted, at least among its users.

In order to work, this system must first be deployed on Windows, and work with popular Windows mailers like Outlook Express, Eudora and Netscape. Most cryptographers, who more commonly use linux or the Mac, have tried to put their software on those platforms. This is not sufficient. Most of my mail is to and from people who use Windows, so my mail isn't private until those people are running encryption software.

To get them to run it, it must have zero user interface. That's something people have almost never done in crypto, because it involves some compromises. The users must not need to understand anything about the crypto or need to configure it. They should be able to get it by downloading a program and running it once. After that they should have encrypted mail. No key generation. No getting a certificate.

Even better, the function should be installed by default into their mail tool, so they don't even have to run a program. That, however, is up to Qualcomm and Microsoft or the vendors who sell machines.

The EFF is interested in organizing and endorsing an open source project to create such tools. If you are a programmer willing to work (without pay, alas) on such tools with skills in C/C++, cryptography and/or E-mail protocols, contact me at brad@eff.org. Those wishing to donate money to the EFF for this or any other efforts are always welcome. Should a major donor appear, I will be able to take out the "without pay" above.

How to get zero UI

To do this, the program must see what mailer the user has and configure to work with it. One way to work with most mailers is to have the program function as a proxy for the various mail protocols, known as SMTP (for outgoing mail) and POP/IMAP for mailbox access. In this case, the program would pretend to be the user's mail server, and it would talk to the real mail servers for the user. The program would alter the configuration of Outlook or other mailers to get into the middle of the mail chain. If the user created a new mail account, it would detect this and intercept that traffic too. The only time the user would have to work with the encryption program would be to stop this from happening.

A more advanced program could interface directly with the mailers using protocols like Microsoft's MAPI, but the proxy system is required as a minimum.

As noted, a toolkit should also be available to work inside popular mailers, including ones on Linux and the Mac.

What is the security weakness?

This sort of "opportunistic encryption" is subject to a sophisticated attack called a "man in the middle" (MITM) attack. If somebody is able to intercept all your communications, coming and going, in a way to be able to rewrite them as they go in and out, they can intercept and alter your mail. That's because they can see you send out the first key with the magic header, and they can change the header to be their own key. After that they can rewrite all your mail to make it look like they are you, and thus get copies of all of it.

To do this they must be intercepting and rewriting your traffic the first time you use the system, and every time you use it. They must be able to rewrite your traffic forever after that. If they ever stop or goof up, an error will occur that you and the other party can see. Of course that doesn't always help you with the privacy invasion that took place earlier, but it makes the job harder for them.

If they can just snoop, and not rewrite your mail, they can see your first mail message to somebody, and other people's first messages to you. They can't see the text of any of the subsequent ones. There are tricks that can stop them from seeing even your first mail.

Of course, if they can tap directly into your own machine, or the machine of your recipient, they can see your mail. For example, if they get you to download a trojan horse program, or exploit a security hole in a browser, they can still take control of your machine. If they break in to a correspondent's machine, they can see your mail to and from that person. Every single crypto system in the world has this flaw.

In particular, if they truly have control over your internet connection, they can alter any piece of software you download in order to make it a trojan horse that listens to your every keystroke if they like. They could even intercept the download of the mail encryptor. (Though it will be signed to help prevent that.)

But this is hard work, and as such it's an acceptable risk. To avoid it, you need an independent channel to introduce your mail programs to each other and a layer of scrutiny of what you download that's beyond 99.99% of users. A good intermediate step is for one or both parties to go to a trusted 3rd party and get an electronic "certificate" of authenticity for a crypto key. This is a good system, and such systems have been around for some time, but people are, for better or worse, not using them. (However, this system would allow those willing to deal with a UI, and possible fees for services, to do that.)

Another minor weakness is that if somebody can read your E-mail box, they can pretend to be you. The authentication portion of this system relies on the fact that if you send a mail to user@domain.com, only that person has the password to read it to send back the right response. You use that fact to, in the future, assure that the mail is really coming from them. If they have weak security on their mailbox, other people can pretend to send mail as them.

The popular terminal session program SSH is also subject to the MITM attack, but has attained good success and improved security for many.

What about forging?

A third potential flaw is that if two people have never exchanged E-mail, I can send a forged E-mail to one of them pretending to be from the other. So I send mail to Alice pretending to be Bob. She records the key I sent as the key for Bob. Now Bob can't send her mail because he doesn't know the key I used.

This can be fixed with a challenge and response that the user never sees. When Alice gets the first mail purporting to be from Bob, her mail tool (without her involvement) sends back a quick challenge to Bob. That goes to Bob's real mail system, not to me, the forger. Bob's system gets this and notices he never sent a mail to Alice, or that the response doesn't match a secret string he put in the mail to Alice. Both Alice and Bob can be alerted that something funny is going on.

This also means that if you send a mail, your next mail will be encrypted even if you don't get a personal reply yet. The automatic reply can be enough to establish the keys. So if you are extra cautious your first E-mail can say just "hello" and the 2nd e-mail can have the private message.

Viral Spreading

To make the system spread, enthusiastic users would configure the program to add some text to replies they send to users who didn't include a key.

This text, added as a signature on plain mails, would say "Did you realize that all your mail is being sent unprotected, like a postcard that anybody else along the way can read? I want my mail to and from you to be private. Consider going to <URL> to see how to really easily arrange for all your mail to and from me and others can be automatically secured with no work from you."

Or words to that effect. People might sign up just to stop getting the signature lines! (Though the program would be polite and not send this message every time.)

Web based mail and encrypting mail servers

One could also support this protocol directly in a web based mail tool. Some companies already do something like that. And the web based access can be encrypted through SSL. Similarly, an ISP or mail provider could provide mailbox and SMTP services which automatically perform this encryption, and encourage the use of SSL encrypted SMTP and POP/IMAP.

This is good but not a substitute for it being on the local machine, because if the mail server is tapped, the unencrypted mail can be intercepted there. However, it still is safe from being read at any other point along the line.

The biggest flaw

If you have zero UI, the user is not even aware the encryption is there. That means the PC does all the work. This means that if the PC is lost (hard disk failure) then the keys are lost. In turn that means unread mail from prior correspondents sitting in the user's remote mailbox can no longer be read -- by anybody. However, error replies can go out on it to tell the other person they need to contact you (not via E-mail) to arrange resending of the mail.

The crash recovery procedure, fortunately, does not have the zero UI requirement, as it's rare.

You also can't easily roam, which is to say read your E-mail from a different computer. To do that you would need a strong (non guessable) password. (Your keys, protected with the password, would be kept in an invisible message in your mailbox.)

However, if you do have a password, then your mail is safe from crashes, and you can roam from computer to computer, as much as you trust the other computers.

Another, less secure option for those who truly want zero UI, is to generate the password from the local machine configuration, using information that would survive a crash, but which is not publicly guessable. However, some have debated just how non-guessable you could make such a password. This allows recovery from hard disk failure (though not from a totaly machine swap) but users would still be recommended to instead create a password.

The mailbox password could also be used as a zero-UI password, but it is of course available to anybody with access to the mail server you use. Better than no security, but a much more significant risk.

Some UI

Now while the system must work with no user interface, for the more advanced users it can have some. For example, users may wish to know when mail is secured and when it is not, and when it is authenticated, and when it is not. This can actually just go into regular E-mail headers, though a web browsing tool could also be developed.

In addition, while zero-UI users face some flaws, there is no reason to not design the system to allow some UI for greater security. For example, those who do go and get a certificate (through PGP key signing parties, or from various professional certificate issuers) could use them to stop some man-in-the-middle attacks.

And a system for public key distribution (such as standard locations for getting certified public keys via challenge-response) could make even the first email secured to people who use it, and prevent people from faking mail to disrupt the system. However, those become targets for attack, and the sad truth is that a truly clever man-in-the-middle can take over the machine of anybody who doesn't use perfect download hygene, and bypass all crypto protection at this level.

In the Servers

Some other projects exist to provide server to server encryption in the mail-transport-agent, such as Sendmail. Some use S/MIME and certificates for pairs of servers that trust one another or have a certificate system set up. One plan, called SSMail (PDF File) provides opportunistic encyption between servers. Finally, servers that use IPSEC tools like FreeS/WAN will of course encrypt what travels between them.

These are also great approaches and should be encouraged. They can both be used. The server to server approach requires no action by the users, which is great, though it currently requires significant effort by system administrators. (Over time, this can be reduced if it becomes pre-installed with mail transport agents.) Unfortunately, users often have no control over what gets in servers.

In addition, if your server is not under your control, server to server encryption (which still worthwhile) is vulnerable to any compromise of the server, and if SSL is not used in all client/server channel, it is vulnerable to any compromise of the pathway from the user to the server.

Anti-Spam

Note that the system will immediately distinguish between mail from people you know who use the system and those who don't. This is a good first step for use in tools that sort your mail based on how likely it is spam. The mail from people you know is almost surely not spam and can be read first. In addition, in a manner similar to my Viking system, the user could turn on a challenge/response tool to challenge unknown users, or demand some sort of proof that they're not a spammer or spent some CPU on the message.

Identity based keys

Another option is identity based encryption. In such a system you would simply provide a very simple tag that indicates you accept mail encrypted in this form. One could even make a rule that if your email address contains a magic token, it can be assumed to be ready for this.

With identity based encryption, you form the key from the e-mail address. The recipient has to go to a special CA, and prove that they own the E-mail address. They can then get their real private key that correponds to their E-mail address. (One usual trick is that the CA mails that key to the address. This is not particularly strong but does demonstrate that, at the time, the party could read that mailbox.)

More on this type of encryption can be found here.

Such a system would avoid the need to include keys in mail, but does need a central agency. The patent status of these algorithms is not yet researched.

Beyond E-mail

The next step is to slightly alter web server tools to do opportunistic SSL. For web sites that have some spare CPU, it would be nice if traffic were encrypted as a matter of course. Today 99% of web surfers can do SSL, but nobody uses https: URLs except when going to a sensative and deliberately secured application. Servers should be configured to notice if the user is coming in to http with a modern browser, and redirect from then on to https. This would be very simple to do in most servers, such as Apache, but as of yet the team has been uninterested.

Technical Notes

Here are some Technical Notes.