Many organizations want to secure the email messages of their most important individuals—for example, their senior executives. Secure MIME (S/MIME), an email security solution commonly supported in today's email software, can provide confidentiality, data authentication, and integrity protection for email messages. S/MIME secures messages in an end-to-end way—not only while the message is in transmission, but also when it's stored in the database of a mail server.
I'll show you how to use S/MIME to solve security problems in a Microsoft messaging environment. Configuring the current Microsoft Outlook versions to use S/MIME is easy, but as you'll see, the underlying certificate infrastructure required to make S/MIME work takes some careful thought and preparation.
S/MIME Basics
S/MIME adds data authentication, confidentiality, nonrepudiation, and integrity protection to MIME-formatted messages. The Internet Engineering Task Force (IETF at http:// www.ietf.org) standardized S/MIME 3.0 in Requests for Comments (RFCs) 2632 through 2634.
S/MIME is an excellent example of a hybrid cryptographic solution, combining the powers of symmetric and asymmetric ciphers and hash functions. (For an introduction to cryptography, see the Windows IT Security article "Keep Your Secrets Safe," August 2005, InstantDoc ID 46871.)
Figure 1 shows the steps in a typical-S/MIME scenario. Alice wants to send a secure message (meaning it has guaranteed confidentiality, integrity, data authentication, and nonrepudiation) to Bob. The S/MIME exchange follows these steps:
- Alice uses her private key to create a digital signature for the message.
- Alice uses a symmetric bulk encryption key to encrypt the message.
- To create a secure channel that can protect the confidentiality of the encryption key while it's transmitted across a public communication channel, Alice uses Bob's public key (found in Bob's certificate) to encrypt the encryption key. This step produces a lockbox that contains an encrypted copy of the encryption key.
- Bob uses his private key to decrypt the lockbox. This decryption process produces the bulk encryption key.
- Using the bulk encryption key, Bob decrypts the message. Bob can now read the message.
- Bob uses Alice's public key to verify the authenticity and integrity of the message by verifying the digital signature, which is found in Alice's certificate.
S/MIME provides persistent, end-to-end encryption of mail messages. This means that when you use S/MIME to encrypt a message, the message is not only encrypted while in transmission, it's also encrypted when stored in your local Microsoft Outlook personal folder store (.pst) or in your Microsoft Exchange Server mailbox store.
Outlook S/MIME Support
Microsoft offers four Outlook mail clients: Microsoft Office Outlook 2003, Outlook Express 6.0, Outlook Web Access (OWA), and Pocket Outlook. Both the Outlook and Outlook Express mail clients have supported S/MIME for quite a while. Exchange Server 2003 adds S/MIME support for OWA. The soon-to-be-released Messaging and Security Feature Pack for Windows Mobile 5.0 will include S/MIME support for Pocket Outlook. Pocket Outlook, which ships with the Windows Mobile (WM) operating system, allows users to access mail from Windows Mobile-based Pocket PCs or Smartphones. For more information about WM, see http://www.microsoft.com/windowsmobile/business/5/default.mspx.
Table 1 gives you an overview of the S/MIME features for each of the Microsoft mail clients. (Note that because I couldn't get access to the WM S/MIME software or feature set in time for this article, the table doesn't include the feature set for that OS version.) You can see that Outlook 2003 has the most complete S/MIME feature set and includes support for S/MIME Enhanced Security Services (ESS) and easy-to-use certificate management features.
From Outlook 2003, you can easily-publish your certificate to the Exchange Global Address List (GAL) or request a new certificate from a commercial Certification Authority (CA), such as VeriSign. To publish your personal certificates to the GAL, click Tools, Options. On the Security tab, which Figure 2 shows, click Publish to GAL. Publishing your certificates to the GAL enables other users to download them and to send you signed and/or encrypted messages. Next, click Get a Digital ID. Outlook 2003 redirects you to the Office Marketplace Web site, where you can request an S/MIME certificate from a commercial CA.
Outlook 2003 ESS includes support for secure receipts. Secure receipts provide nonrepudiation of reading, which gives the message sender cryptographic proof that the intended recipient has actually read and verified a signed message.
S/MIME supports two digital signature types, clear and opaque. A clear signed message separates the digital signature from the signed data. An opaque signed message binds the signature and the message in a single binary file. Only S/MIME-enabled mail clients can send S/MIME-signed (clear or opaque) messages. S/MIME-enabled mail clients can read both clear and opaque signed messages. Non-S/MIME-enabled mail clients can read only clear signed messages. In general, when you don't know the recipient's S/MIME capabilities, send clear signed messages. When you do know that a recipient has S/MIME capability, you can use either clear or opaque signing. The advantage of opaque signing is that it's more resistant to translation by email gateway and relay servers that can invalidate an email message's digital signature. Both Outlook 2003 and Outlook Express 6.0 support clear and opaque signing; OWA supports only clear signing.
Configuring and Using S/MIME
To configure S/MIME in Outlook 2003 (which has the most comprehensive S/MIME features), go to the Security tab (which Figure 2 shows), and click Settings. The Change Security Settings dialog box (Figure 3) appears. In the Security Settings Name box, type or select a name (Jan De Clercq's S/MIME Settings, in our example). Next, from the Cryptography Format box's dropdown list, select S/MIME. Select the Default Security Setting for this cryptographic message format option and the Default Security Setting for all cryptographic messages option. In the Signing Certificate box, specify a signing certificate. Then set the hash algorithm (SHA1 is the recommended setting). Choose an encryption certificate and set the encryption algorithm (3DES is the recommended setting). Select the Send these certificates with signed messages option, then click OK.
Back on the Security tab, you can set the default S/MIME behavior that will apply to all the messages the user sends. In our example that Figure 2 shows, the default is to send clear signed messages. You can specify to encrypt and/or sign all outgoing messages, to always send clear signed messages, and/or to always request a receipt for signed messages.
Users can override the default settings for individual messages. From the Message window, which Figure 4 shows, they can click the Encrypt or Sign icon or click Options to access the encryption and signing options from Security Settings in the Options dialog box.
Be sure users know that when they send an encrypted message, they must have access to the recipient's public key and certificate. If you use an Active Directory (AD)-integrated Windows Public Key Infrastructure (PKI), Outlook 2003 can retrieve the recipient's certificate from a Global Catalog (GC) server. For recipients not defined in AD (for example, external recipients), users can get a copy of their certificates by having the recipients send them a signed email message. When users then create an Outlook contact object for that recipient, Outlook automatically includes the recipient's certificates in the contact object.
Prev. page
[1]
2
next page 
