Move to S/MIME
A second way to add security to your e-mail is to use S/MIME (Secure MIME). S/MIME is a way of adding encryption, authentication and data integrity checking to e-mail messages. Like TLS, S/MIME standards are very old -- dating back to 1998 -- and support is already built into most e-mail clients. Although S/MIME is complex, most people use it in one of two ways, for authentication or for authentication and encryption.
S/MIME can provide a strong authentication of the sender of an e-mail message and cryptographically strong assurances that the content (or body) of an e-mail has not been modified. When using S/MIME in this way, the sender of a message "digitally signs" their message before sending it. When the recipient opens a digitally signed S/MIME message, their e-mail client verifies the signature, ensuring that the message content was not tampered with, and checks that the digital signature matches the return address on the mail, thus authenticating the sender. This resolves one of the huge issues with SMTP mail; i.e. you have no idea who is sending you mail and whether the sender represents the person you think he is.
You can also use S/MIME is to add encryption on top of the digital signature. Your client encrypts and digitally signs the message before sending it, thus providing privacy on top of authentication and integrity checking. When you encrypt with S/MIME, only the recipient can decrypt the message. Even you can't.
Before detailing how this is done, I want to point out a big difference between S/MIME encryption and TLS encryption. TLS is server-to-server encryption, and it occurs across the entire message stream. In other words, all aspects of the message are encrypted -- who it's from, who it's to and the body. However, TLS is not controlled by the user, and there is no assurance that you'll have encryption at each hop. Plus, the message sits in clear text on each server that it goes through. With S/MIME encryption, you're only encrypting the body, so the headers (such as from, to and subject) are not encrypted. However, it is controlled by the sender and no one but the intended recipient can read it -- not your e-mail admin or the recipient's! This provides a dramatically higher level of security.
How does S/MIME work? Well, it's those digital certificates again. This time, each user needs their own digital certificate. User certificates are easier to get than server-side certificates. If you're in a Windows Active Directory environment, Microsoft offers a free Certification Authority that generates a certificate for each user. If you want to get a globally recognized certificate, Thawte offers free personal e-mail certificates that are signed by their certification authority.
When I send an S/MIME message that is digitally signed, my client also sends along my digital certificate. The recipient uses my certificate to verify that the message is from me and has not been modified. The recipient can then use my certificate to encrypt a response so that only I can read it.
At first glance, it appears that S/MIME is not a very scalable system -- and that's true across the Internet. Everyone needs a certificate, and if I want to send an encrypted message, I have to have a copy of the recipient's certificate. In order for sender authentication to work, you have to trust the certification authority that signed my certificate (true if I got it from Thawte, but perhaps not true if I got it from a random Windows AD server somewhere). If I ever lose my private key, then all the encrypted mail that you sent me is now unreadable. Plus, because the message is encrypted from end-to-end, virus scanners, message archivers and antispam tools aren't able to peer inside.
 |
Words To Know |
Click on the word to read the definition.
|
|
|
|
|
This means that S/MIME is not appropriate for a large corporation that wants to send encrypted messages to thousands of business partners. But S/MIME does work well when that same corporation wants to make sure that anything leaving the corporate mail server is authenticated. For example, an insurance company could attach a digital signature based on its private certificates to each outgoing message. This provides strong evidence of who sent a message and whether a purported e-mail is a fake if it doesn't have a valid digital signature.
On a smaller scale, though, S/MIME provides a very easy way for ad-hoc groups of people to add an enormous layer of security to their e-mail communications. Without having to do anything magical or proprietary, users can simply turn on S/MIME encryption and communicate freely over the Internet secure in the knowledge that no one can read or modify their e-mail.
There are efforts underway to bring S/MIME-level authentication and encryption to entire companies by moving keys from people's individual mail clients out to an edge server. This is called S/MIME Gateway, and there is an active certification program at the Open Group for products that support this. Before messages leave the company, they are signed and encrypted; when they come back in, they are checked and decrypted before final delivery. This particular solution doesn't have the same level of security, because the protection only starts and ends at the Internet boundary. But it does provide a stronger level of security than, for example, SMTP TLS, because the security is independent of the number of mail servers the messages jump through from company to company. This use of S/MIME is common in industries such as health care or financial services, where a service provider mandates data protection for all communications across the Internet. I've also talked to customers who are using a variety of proprietary encryptions based on PGP for this task, although it's obvious that a standards-based solution like S/MIME Gateway is a better long-term solution.
Previous: Securing e-mail with TLS
<< Previous
About the author
Joel Snyder is a senior partner with Opus One, a consulting firm in Tucson, Ariz. He sent his first network e-mail in 1980, and has been designing and implementing enterprise e-mail systems ever since. He is partially to blame for the X.400 messaging standards and has been trying to atone for them ever since.
