Signed, Sealed and Delivered

Coping with insecure e-mail

But few organizations have adopted similar measures for protecting mail sent over the Internet. Techniques for digitally signing and sealing electronic communications have existed for nearly two decades, yet their adoption has been wretchedly inadequate.

Security professionals frequently compare the sending of Internet mail to a postcard sent through the postal service; just as others can see the contents of the postcard you got from Aunt Carol, so too can network administrators read or even change the contents of your e-mail messages.

Privacy Enhanced Mail (PEM) was the first attempt by the Internet Engineering Task Force at standardizing how encrypted mail is sent and received. But while hundreds of engineers created standards and demonstration software, the system was never widely deployed.

That's when Phil Zimmermann, a computer programmer in Boulder, Colo., decided to take matters into his own hands and create his own e-mail encryption system. Called Pretty Good Privacy (PGP), it was released on the Internet in 1991, just as the U.S. Senate was considering legislation that would have made it illegal for citizens to use strong cryptography to shield their personal communications from the prying eyes of employers, police and even oppressive governments. Zimmermann hoped his program would make cryptography so widely available that it could never be eliminated—even if it were temporarily outlawed.

Techniques for digitally signing and sealing electronic communications have existed for nearly two decades, yet their adoption has been wretchedly inadequate.

PGP quickly gained traction among academics, Civil Libertarians and even computer security professionals. The program was fairly hard to use, but it was the best thing going—a single system that provided for signing and sealing messages, as well as for managing encryption keys. Minutes after downloading a copy of PGP, for example, a human rights worker in Honduras could send an encrypted report of political repression to Amnesty International's office in New York with a code that was effectively unbreakable.

But the problem with PGP went far beyond the program's clunky user interface. Exporting the program from behind U.S. borders was a felony violation of U.S. export controls, punishable by a $10,000 fine and 10 years in jail. Inside the United States, use or distribution of the program violated civil law, since the public-key encryption technology on which PGP relied was patented by RSA Data Security (now just RSA Security). As the 1990s proceeded, RSA crossed both legal and political swords with Zimmermann and his PGP program. Most companies were afraid to touch it.

RSA was best known as a purveyor of encryption toolkits—its software was at the basis of the SSL encryption built into Netscape's first Web browser and used a system called S/MIME. Unlike PGP, S/MIME was designed for use worldwide. Messages sent within the United States were sealed with unbreakable 128-bit encryption. But when used internationally, it downshifted to the exportable 40-bit encryption that could be cracked by the U.S. intelligence services. This combination of a strong supporting company and worldwide legitimacy all but assured S/MIME's success.

Today, S/MIME has emerged as the standard of choice for e-mail encryption. Support for S/MIME is built directly into Microsoft's Outlook and Outlook Express programs, Lotus Notes, and Apple's Mail applications. Plug-ins from Entrust and others bring S/MIME support to most other systems on the market as well.

With most S/MIME-enabled mail clients, you can simply click a button labeled "sign" and the message will be signed with the certificate in your private key. Click "encrypt" and the message is automatically encrypted with the public key of the recipient. What could be easier?

But despite the apparent simplicity of today's S/MIME implementations, most e-mail is not encrypted. In fact, brokerage companies won't even consider using it for sending out monthly statements; instead, they send out an unencrypted message to their customers with a link that takes the customer to a "secure" website, which asks for a user name and password, and then downloads the statement with encryption using SSL.

Why has encryption caught on for websites but generally failed when it comes to e-mail? One theory is that people just don't need to secure e-mail—if they did, they'd use it. Given the millions of dollars that financial and health-care institutions have spent to develop secure Webmail, that explanation just doesn't make sense. Most companies would much rather send out statements by e-mail if regulatory bodies would let them. They can't because their customers' systems aren't set up to receive encrypted mail.

It's not that the customers don't have the necessary software; programs that support e-mail encryption are now ubiquitous. What customers are missing is personal certificates.

With any encryption system based on the RSA encryption algorithm, before you can send somebody an encrypted message, you need to have that person's public key. The problem with S/MIME is that creating your own key is not enough—you also need to have it digitally signed by a so-called certification authority that can assert that your public key actually belongs to you.

Many of the original S/MIME proponents thought it was far worse to use encrypted mail with uncertified keys than to use no encryption at all. With an uncertified key, you might be tricked into sending confidential information to the wrong person; without encryption you would know better than to send it in the first place. Remember that the original incentive for encrypted mail was to secure military secrets from the eyes of repressive governments.

Sadly, this emphasis had the effect of creating a system that is harder to use for everybody else. But even organizations that have deployed personal certificates as part of a broad PKI initiative have run into problems with S/MIME.

With an uncertified key, you might be tricked into sending confidential information to the wrong person, whereas without encryption you would know better than to send the information in the first place.

The U.S. Department of Defense is creating one of the largest PKI deployments on the planet. When it's done, every member of the armed services will have a common access card containing three certificates: one for single sign-on, one for writing digital signatures, and one for decrypting incoming mail. But this intensive use of S/MIME has revealed another problem with today's secure e-mail implementations. Programs such as Outlook and Ximian's Evolution decrypt messages only when they're displayed; the actual mail itself is left encrypted on the computer's hard disk. You'd think that keeping the messages encrypted with the original key would increase security, but it actually has the reverse effect. Keeping the messages encrypted means that the private key needed to decrypt these messages can never be thrown away. That's a requirement that's in direct conflict with policies that require creating new keys on a regular basis and expiring old ones.

A better solution would be to have the e-mail automatically decrypted when it is received and then re-encrypted with a second key. As an added benefit, this re-encryption could be performed for every e-mail message, both those that had been sent with encryption and those that had been sent without. You can automatically re-encrypt your unencrypted mail by keeping your message store on an encrypted file system such as Windows EFS or Macintosh FileVault. But the solution isn't perfect, since messages received with S/MIME encryption are still kept encrypted with the original key.

Two companies have created secure messaging appliances that take a different approach to solving the usability problem. These appliances are effectively super-trusted third parties that automatically create a key whenever you try to send an e-mail message to somebody who is not in the system. PGP Corp.'s PGP Universal does this with both S/MIME and OpenPGP formats, while Voltage Security uses a new encryption algorithm called Identity-Based Encryption.

I believe that encrypted e-mail will become ubiquitous once these basic usability problems have been worked out, just as "secure" websites are now commonplace. What's needed is making the sending of sealed electronic mail as easy as sending an electronic postcard.


Simson Garfinkel, CISSP, is a technology writer based in the Boston area. He is also CTO of Sandstorm Enterprises, an information warfare software company. He can be reached at machineshop@cxo.com.

Toolbox: Defensive Investments

Scott Greiper says eight out of every 10 security purchases in 2004 will be access control products. Read More

Most Recent Responses:

Check out Brad Templeton's essay http://www.templetons.com/brad/crypt.html for a description of the level of usability we need to aim for in order for encryption to be used, if not the technical details involved in getting it to work. Any "cognitive excise" will stop encryption from being used. If it involves button clicks then it will ignored. The users will click send without a second though.

Ray Ozzie has understood this -- Groove uses invisible encryption. It's always there and you don't have to do anything to make it work.

Christian Mogensen
Product Developer
SuperOffice ASA
Email
Print