Secure Email with S/MIME

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:

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.

Design and Deployment Considerations
That's the easy, front-end part of an S/MIME-based mail security solution. Behind the scenes, you have a lot of thinking to do when you design and deploy an effective mechanism for handling certificates. Ask yourself the following questions to get started.

Can my current mail clients support sufficient S/MIME services? If your current mail clients don't support the full S/MIME feature set that users need (see Table 1 for an overview of the different S/MIME feature sets), you might need to upgrade your mail client software.

If your current mail client doesn't support S/MIME at all, remember that even though users can't create S/MIME-protected messages or read encrypted or opaque signed messages, they can always read clear signed messages. If you use Exchange Server 2003 messaging servers, you can enable S/MIME for users through OWA.

Should I use an internal or commercial CA? S/MIME builds on X.509-formatted digital certificates generated by CAs. To provide S/MIME certificates to your users, you can leverage internal CAs or you can buy certificates from a commercial CA (such as VeriSign at http://www.verisign.com or thawte at http://www.thawte.com). Internal CAs give your organization complete control over the operation of your certificate "engines" and allow you to provide important services such as key archiving and recovery. Because internal CAs require design, deployment, and maintenance of the PKI, they can be costly. For small organizations and organizations that need certificates for a limited set of users or applications, I recommend buying S/MIME certificates from a commercial CA. They are an easy and cheaper option.

How will users enroll for and renew their S/MIME certificates? When you consider an S/MIME deployment, you must plan how users will enroll for and renew their S/MIME certificates. In a Windows 2003 domain environment made up of XP or later clients and containing an integrated Windows PKI, I recommend that you use autoenrollment as the certificate enrollment and renewal method. In Windows 2000 Server domain environments hosting a Windows PKI, users can manually enroll for certificates by using the CA Web enrollment interface or by using the Microsoft Management Console (MMC) Certificates snap-in. If you get your S/MIME certificates from a commercial CA, you must adhere to the enrollment and renewal guidelines that the CA defines.

Do I need a single or a dual S/MIME key pair system? Keeping a central database of private keys can be risky when users use the same key for both encrypting and signing their mail messages. Rogue administrators could extract a user's private key from the archival database and sign mail messages on that user's behalf. To protect users from these threats, most S/MIME client and server software (including Exchange and Outlook) support a dual key pair system. In such a system, a user always has two key pairs: one for signing (the private key from the pair is archived) and one for encrypting (the private key of the pair isn't archived). If your organization doesn't have key archival and recovery requirements, you can use S/MIME with a single key pair. In all other cases, I strongly recommend that you deploy two key pairs for each S/MIME user.

Do I need key archival and recovery services? In many organizations, if users encrypt email messages, the organization's security policy requires key archiving and recovery. A key archival and recovery system keeps a copy of the user's private encryption key in a centralized database. If a user loses his or her private key and no archival and recovery mechanism is available, the encrypted data can't be decrypted.

The need for encryption key archival and recovery services can be one of the reasons to invest in an internal PKI or in a messaging server that offers this service. Exchange Server versions 4.0 through 5.5 offer key archival and recovery services in the Key Management Service (KMS). In Exchange Server 5.5 Service Pack 1 (SP1) and later versions, you can outsource the KMS CA functionality to a Windows CA. In Exchange 2003, the CA and archival and recovery functions have been moved completely to the Windows 2003 CA.

Do my users need advanced private key protection? If your users use S/MIME to sign important mail messages, you must use an advanced private key protection system. Microsoft offers a software-based protection mechanism that can prompt users for a password each time their applications access a private key. The Cryptographic Service Provider screen of the Certificate Request Wizard (Figure 5) lets users set strong private key protection by selecting the Enable strong private key protection option when they enroll for an S/MIME certificate. In the Creating a new RSA exchange key dialog box that appears, select High to enable password protection of the private key.

Other private key protection solutions require that you deploy specialized hardware such as USB tokens, smart cards and smart card readers, or Trusted Platform Module (TPM)-enabled workstations. These advanced solutions definitely offer a high level of private key protection but can be costly to deploy and maintain.

How will I provide up-to-date certificate revocation information to my users? The S/MIME functionality embedded in the Microsoft messaging clients and servers uses a system of certificate revocation lists (CRLs) and CRL distribution points (CRLDPs) to provide users with up-to-date certificate revocation information. CRLs contain the serial numbers of untrustworthy certificates (such as certificates of which the private key has been compromised). CRLDPs point to places from which users can download CRLs. CRLs can be stored in a directory, on a Web server, in a file, or on an FTP share.

Both Outlook 2003 and OWA generate error messages when no up-to-date CRL information is available on the local machine or on one of the CRLDPs. When you design your PKI infrastructure, make sure that you set up multiple CRLDPs, preferably on different storage providers (for example, one in a directory and another one on a Web server). If you exchange S/MIME-secured messages with people outside your organization, you must make sure that the CRLs are also available to them. If you get your certificates from a commercial CA, make sure that you understand its revocation information distribution mechanisms.

S/MIME to the Rescue
S/MIME provides powerful mail security extensions that can greatly benefit your users. Microsoft includes S/MIME functionality in the various Outlook messaging clients and in the Exchange messaging server. Configuring and using S/MIME in Microsoft software is relatively easy, but remember that successful deployment of S/MIME requires you to invest adequate time and effort in planning and designing your certificate infrastructure.