Machine Shop

Signed and Sealed? Might Get Delivered!

While two-factor authentication schemes face various snags, S/MIME is ready to help secure e-mail today

By Simson Garfinkel

Phishing poses a significant threat to the future of commercial e-mail, online banking and online commerce.

And it's increasingly clear that the techniques employed by phishers can be used equally well to compromise the security of corporate and government computer systems. Indeed, if someone were to send out thousands of e-mails to your users saying that the URL for the corporate intranet had changed and the users needed to log in to the new site, that person would almost certainly score dozens of valid user names and passwords.

There are many proposals for fighting the phishing problem. Some schemes call for the deployment of new technology such as two-factor authentication. Others call for improving e-mail security with better antispam systems and new cryptographic protocols such as Yahoo's DomainKeys. But there is a simple, straightforward and easy-to-use technique that many businesses could start using today. That technique is called S/MIME—the Secure Multipurpose Internet Mail Extension—and it's already built into the Windows, Macintosh and Linux operating systems.

The S/MIME system for sending secure e-mail was developed by RSA Security in the 1990s and adopted as an Internet standard by the Internet Engineering Task Force in 1998. Today, support for S/MIME is built into a wide variety of e-mail systems, including Microsoft Outlook, Outlook Express, Lotus Notes, Apple Mail, Eudora 7 and even the Linux Evolution mail client.

S/MIME defines a standard way for signing e-mail messages with a digital signature, for sealing them with encryption, or for both signing and sealing. A signed message allows the recipient to verify that the message came from a specific sender and that it has not been modified between the time that it was sent and the time that it was viewed by the recipient. Sealed messages are encrypted so that they can't be deciphered by anyone who doesn't have the appropriate cryptographic key.

Certificates Made Simple

Like the secure sockets layer that's used to secure Web commerce and banking, S/MIME is based on the X.509 public-key infrastructure. This means that S/MIME's ability to authenticate the sender of a message depends upon the sender obtaining an S/MIME certificate from a certificate authority (CA) such as Thawte. S/MIME users also have to obtain certificates before they can receive messages that are sealed with encryption. In practice, this certificate requirement is the reason that banks and other companies don't use S/MIME to send secure mail to their customers: The vast majority of consumers have never obtained digital certificates. Even though these people have S/MIME support built into their e-mail clients, there is no way to send them an encrypted message.

As it turns out, it's pretty easy to get a certificate—at least for moderately sophisticated computer users.

Both Thawte and VeriSign make these "personal certificates" available on their websites. Thawte gives away its "Free-mail" certificates, which contain only an e-mail address, and it charges around $20 for a one-year certificate that includes an individual's name and organization. VeriSign also sells a one-year personal certificate. Over the past three years, I've convinced dozens of people to get a certificate for the added security that comes with being able to receive encrypted messages. But I have no illusions about this being a practical approach for the masses: Until certificates are automatically created when a computer boots up for the first time, most people will not have certificates.

Fortunately, people don't need a certificate to receive a message that's digitally signed but not sealed (that is, not encrypted). That's because it's the sender of a digitally signed message who needs the certificate, not the recipient. The only thing that a recipient needs to verify the signature is the certificate authority key from Thawte or VeriSign, and those keys are already built into all of the popular e-mail programs in exactly the same way that CA keys are built into Web browsers like Firefox and Internet Explorer. If you send a properly signed message to a person reading her e-mail with Microsoft Outlook, Outlook will verify the signature and display the icon of a little ribbon next to the message when it is shown to the user. Apple Mail will display the message "Signed:" with a star icon. Even Mozilla Thunderbird will verify the message signature and inform the user.

A good first step to attacking the phishing problem, then, is for businesses that send out large quantities of e-mail to get an S/MIME certificate and start sending those messages with S/MIME signatures. Customers who receive these messages will see that they are digitally signed and will know that they are more trustworthy than messages that are not signed. If all of PayPal's e-mail messages were digitally signed, then the unsigned messages sent by phishers would stand out. The rate of successful phishing attacks would surely go down.

Working Out the Kinks

The devil of this proposal is in the details, of course. For example, even though support for S/MIME is widespread on the desktop, America Online does not support the standard. There is also no support for S/MIME on Hotmail, Google's Gmail or many Web-mail systems. However, this is not the show-stopper for digital signatures that it is for encryption. When an AOL or Hotmail user receives a signed message, the S/MIME signature shows up as an attachment called "smime.p7s". Clicking on the attachment in Windows causes the Windows Certificate Viewer to run, showing the name on the certificate. Perhaps more importantly, it is trivial to verify the signature on a received message that is signed. If Citibank or PayPal were to start sending out large numbers of digitally signed messages, it would be a simple matter for the programmers at AOL, Google or Microsoft to add support for message verification to their services.

Phishers would try to defeat this system by sending out their own digitally signed mail, of course. But they couldn't simply make a few changes to a message sent out by Citibank, because the signature on the message would no longer verify. And they couldn't sign their own message with Citibank's certificate, because signing a message requires use of both the certificate and the certificate's corresponding private key. That key would be safely guarded inside the computer at Citibank that signed the messages before they were sent out to the Internet.

Faced with such a hurdle, phishers would respond by creating their own private keys and matching digital certificates. But suddenly they would be faced by a second problem. If the phishers used self-signed certificates, e-mail programs like Microsoft Outlook would warn that the certificate was issued by an untrusted certificate authority. This would in fact be a true statement. Some phishing attempts might be foiled.

Alternatively, the phishers might attempt to register and obtain certificates for new domain names—names like citibank-express-service.com or paypal-security.com. Thawte or VeriSign would have no problem issuing a certificate for such a domain, even though the domain didn't belong to the real Citibank or the real PayPal.

This problem of misleading domain names is growing—and it's made worse by companies such as Chase that use a large number of domain names for marketing purposes. (For example, Chase, which purchased First USA last year, still uses the domains firstusa.com and cardmemberservices.com for its consumer-facing websites.) Fortunately, this is a problem that can also be addressed: In the future, e-mail programs could tell their users if this is the 10th time that an e-mail message has been seen that was certified by a particular digital certificate, if it was the 50th time, or if it was the first time. Clearly, if this is the first time and the message suggests that the user do something that doesn't seem right—like go to a new website—there's reason for users to be suspicious. Would some still fall into the phishing trap? Of course. But it would be a big step in the right direction.

Putting It into Practice

Using S/MIME to digitally sign messages makes a lot of sense, but I don't know of a major financial institution or e-commerce site that is doing it on a regular basis for e-mail that's sent to consumers. That's a shame, because this technology could make a big difference in the fight against phishing. The one company that is routinely sending signed e-mail is Amazon.com, which sends digitally signed invoices to its Amazon Marketplace sellers in Europe. Amazon started sending signed messages in June 2003. In August 2004 I surveyed more than 400 of Amazon's merchants and discovered that the majority of them appreciated receiving mail that was digitally signed and thought that more mail should have similar protections. In particular, 59 percent thought that receipts from online merchants should be signed, sealed with encryption or both, while 65 percent thought that bank or credit card statements should be signed, encrypted or both. Full details of the survey can be found in the paper that I presented at the 2005 Financial Cryptography and Data Security conference, online at http://fc05.ifca.ai/p15.pdf.

What's needed now is for some company to take the next step and start sending out S/MIME signed e-mail to the masses. Adding signatures to an existing bulk e-mail infrastructure is actually quite easy. The time for research is over; the time for deployment is now.

Also check out:

• This month's articles
• Latest Security news
• Archives

Simson Garfinkel, PhD, CISSP, is spending the year at Harvard University researching computer forensics and human thought. He can be reached at machineshop@cxo.com.