Email is an indispensable part of your business. Most people think of email as a utility, akin to telephone service—so much so, that we have an expectation of privacy when we send email. Is that expectation justified? Are you doing everything you, as a Microsoft Exchange Server administrator, can do to ensure the privacy and security of your users' email? In Part 1 of this series, I discuss how Exchange Server 5.5's Advanced Security features work. In Part 2, I'll lead you through installing and configuring Advanced Security to work with a Windows 2000 certificate server and Microsoft Outlook 2002 clients.
Postcards and Pencils
When you send a postcard, anyone can read what you've written. Most of us write postcards in ink, but what if you used a pencil? Then, anyone could read or alter your message. Most email systems are like writing postcards in pencil—they don't do much to prevent eavesdropping or alteration. An email message that you send to an Internet recipient has the potential to go anywhere on the Internet before it reaches its target. The only way to protect such messages is to secure them before they leave the client workstation and keep them protected until the recipient opens them. Server-based encryption systems protect messages only as they travel between servers; an attacker can still access messages traveling between a server and a client. Advanced Security features target this vulnerability: The client protects the mail before it proceeds to the server, and only the intended recipients can read it. To understand Advanced Security features, you need to grasp the basics of public key cryptography.
Public Key Cryptography
Suppose Alice and Bob want to exchange email, and they don't want Ted to read it. The obvious solution is for Alice and Bob to encrypt (or scramble) their message. Alice and Bob might pick a secret phrase to use as an encryption key. This method—called a secret-key system because its security depends on keeping the key secret—might work if Alice and Bob already have a Ted-proof way to exchange messages. However, if they use unsecured email to exchange their secret key, Ted can read their email and gain access to all their encrypted traffic.
A better solution is to use public key cryptography, in which Alice and Bob each generate a keypair. A keypair contains a public key and a private key. The two keys are mathematically related, but deriving one from the other is impossible. Alice and Bob can use their keys to communicate as follows:
- Alice uses a copy of Bob's public key to encrypt a message to Bob. Only Bob's private key can decrypt the message. As long as Bob maintains control of the private key, his messages remain secure. This scenario is called public key encryption.
- Alice uses her private key to encrypt a message. Anyone who has a copy of her public key can decrypt the message and verify its authenticity (public keys can be widely distributed). This scenario is called a digital signature.
- Alice can combine public key encryption and her digital signature to encrypt and sign a message. For example, Alice can sign an encrypted message (so that anyone can verify the origin, but only Bob can read the message), or she can en-crypt a signed message (so that only Bob can verify the signature).
A digital certificate combines a user's or computer's public key with a set of attributes (e.g., an email address, ID number, expiration date). Because the certificate contains a public key, applications can use the certificate to perform public key operations. The certificate issuer uses its public key to digitally sign the certificate, so anyone who gets Alice's certificate can verify the issuer's signature, thereby checking the certificate—and by extension, the public key embedded in it—for validity.
Of course, this Alice-and-Bob scenario glosses over a few details. To successfully use public key systems, you don't necessarily need to know how they work—but I recommend that you take the time to learn. An excellent source for further information is Bruce Schneier's Applied Cryptography (John Wiley & Sons, 2000). Most important, you need to know how Exchange uses public key technology to secure your users' email messages, as well as how you administer and control it.
Key Management Components
One of the difficulties of designing encryption systems is key management: generating, securely storing, and accurately delivering keys. Suppose Charlie wants to obtain a digital certificate to send secure email. First, Charlie must generate a keypair. For maximum security, the private key should never leave his machine—after all, anyone with a copy can impersonate Charlie. (Ideally, Charlie would use a smart card or other hardware device; these devices generate the keypair internally, and the private key is never visible outside the device.) After Charlie has a keypair, he must generate a certificate request and send it to his certificate issuer. The issuer, or Certificate Authority (CA), is responsible for validating the request and deciding whether to send the requested certificate. Most Exchange installations use Microsoft Certificate Services, but you can also use a third-party CA, such as those that the United States Postal Service and VeriSign offer.
After the CA issues a certificate, the CA typically publishes the certificate in a certificate store. In Charlie's case, the store might be the Exchange 5.5 directory or Active Directory (AD), depending on the CA that issued the certificate. Donna can now look up Charlie in the Global Address List (GAL) and retrieve his certificate, thereby obtaining his public key and enabling secure communications with him.
The puzzle has another piece. Exchange doesn't know about public key systems—it's a mail and collaboration server. Similarly, the CA doesn't know about email. Enter the Exchange Key Management Server (KMS). The KMS generates keys for users, maintains backups of private encryption and public signing keys, and maintains the certificate revocation list (CRL), which clients use to ensure the validity of certificates. The KMS provides the link between the CA and the email client.
Enabling Advanced Security
To let users configure Advanced Security, you must enroll their mailboxes in the Advanced Security service. The KMS will then generate a temporary key, which the KMS uses to encrypt a message to the users. This message tells the users that they're enrolled in Advanced Security and prompts them to enable Advanced Security from within Outlook. To ensure maximum security, you can choose not to send the enrollment message (and its secret key) over email; instead, you can deliver the data on a disk or over the telephone. To enroll an Exchange 5.5 user, use Microsoft Exchange Administrator to navigate to the user's recipients container. Right-click the mailbox to access its Properties dialog box, go to the Security tab, and click Enable Advanced Security.
After a user enrolls in Advanced Security, his or her Outlook client sends a certificate request back to the KMS. The KMS adds attributes to the certificate request that bind the certificate to the specified mailbox. Then, the KMS forwards the request to the CA, which processes it according to relevant CA criteria. (For example, you can configure your Win2K certificate server to automatically issue certificates or to hold all requests pending an administrator's review.) After the certificate server issues the certificate, the CA publishes it and returns it to the KMS. Now, users can query the GAL for the newly issued certificate, and the user who owns the certificate can begin using it to sign messages or read encrypted mail.
Outlook controls these functions. When you compose a new message, you can choose whether you want to sign or encrypt it. You can choose which certificate to use—if you have access to more than one—and which encryption and signature algorithms to use. After you instruct Outlook to send the message, Outlook generates a Secure MIME (S/MIME)format message. S/MIME is the most widely used format for secure messaging, and the Outlook family (i.e., Outlook 2002, Outlook 2000, Outlook 98, Outlook Express, and Outlook 2001 for the Macintosh) can interoperate with other S/MIME clients. Essentially, an S/MIME message is an ordinary MIME-format message with added security pieces.
Therefore, Exchange can process the message as usual: Even though Exchange might not be able to read the message's contents, the header and recipient information is visible. However, Outlook uses a different icon for signed or encrypted messages, so you can quickly determine which messages are secure. When you open an encrypted message, Outlook prompts you for your certificate's passphrase. When you open a signed message, Outlook attempts to verify the message's signature, the corresponding digital certificate's signature, and the signatures on the issuing CA's certificate.
Questions to Keep in Mind
If you want to deploy Advanced Security, ask yourself these questions. First, do you require only internal security, or do you need to communicate securely outside your organization? If you answered yes to the latter, your task is more complicated because you need to ensure that all involved organizations are using compatible tools. Second, which CA will you use? Microsoft's CA is free and works seamlessly with Exchange, but you can use other compatible products. Third, which version of Outlook do your users have? For proper S/MIME support, they must use Outlook 98 Service Release 1 (SR1) or later. Finally, how many KMS servers do you need? You can use one in each Exchange site, or you can use just one for your entire organization. Multiple KMS machines give you increased control over Advanced Security use but also add administrative overhead. In Part 2, I'll show you how to set up the CA and KMS, how to enroll users, and how to back up and restore the KMS database. Until then, be careful with your email—you never know who's reading it.