Outlook 2000 can be installed in one of two modes: Internet only mode or corporate/workgroup mode. Because the focus of this book is Exchange 2000 Server, we will consider only corporate/workgroup mode, which requires connectivity to an Exchange 2000 server. Refer to the Exchange 2000 Server Resource Kit for information on securing messaging in Outlook 2000 in Internet only mode.
From the client perspective, one question that must be answered is how the Outlook 2000 client knows which certificates to trust. The answer is found in the properties of Microsoft Internet Explorer. When Internet Explorer is installed, a large number of certificates are embedded in the installation. Outlook uses the Internet Explorer cryptographic service provider (CSP) to read these certificates and then determine whether the CA is trusted . To see which CAs are trusted, in Internet Explorer, choose Internet Options from the Tools menu, and then display the Content tab and click the Certificates button. Figure 21-23 shows a partial list of the default trusted root certificate authorities that ship with Outlook 2000 and Internet Explorer 5.
NOTE
A CSP, or cryptographic service provider, is the actual code that has the algorithms for encrypting data and creating signatures.
Figure 21-23. Partial list of trusted root certificate authorities in Internet Explorer.
Both root CAs and individual users can be added or removed at this location. Let's assume, for example, that we want to remove a root CA's certificate from the list of trusted root CAs. In the Certificates dialog box, shown in Figure 21-23, we would display the Trusted Root Certification Authorities tab, highlight the root CA to be removed, and then click Remove. A message box would then appear confirming this action (Figure 21-24).
Figure 21-24. Message confirming removal of a root CA in Internet Explorer.
If your company implements its own CA or if there are specific CAs that you need to trust that are not embedded by default in IE, you can import their certificates by using the Import button.
You need to think carefully about whether to initially trust a certificate. For instance, if the certificate is included on an installation CD-ROM from Microsoft, you can be sure it's trustworthy. However, if you've downloaded software, such as Internet Explorer, from the Internet, someone may have slipped in a certificate that you don't want to trust. To prevent this, Microsoft uses Authenticode certificates for its software. With these certificates, if any bits have changed, you are notified during installation that the signature is invalid and that you shouldn't install the software.
You can also verify certificates independently by contacting the root CA directly to see if the certificate's serial number is valid. Some CAs include serial numbers on their Web site, or you can contact the system administrator of a corporate CA.
When both the sender and receiver are using Outlook 2000 along with certificates, their messages are encrypted end to end, meaning that the Outlook 2000 client encrypts them when it sends them and they are not decrypted until opened by the recipient. Encrypted messages in the store remain encrypted. Hence, if someone is able to obtain access to a mailbox on an Exchange 2000 server, the messages are still unreadable because that person does not have the private key to decrypt the message. Only the intended recipient holding the correct private key can decrypt the message.
Here is how Outlook 2000 provides message privacy. First, the sender composes and addresses the message. Outlook then locates the recipient in Active Directory by doing an address book lookup. If the sender has chosen to encrypt outbound messages, Outlook retrieves the recipient's certificate. To see the encryption options, choose Options from the Tools menu in Outlook 2000, and display the Security tab (Figure 21-25).
Figure 21-25. The Security tab showing options to encrypt outbound messages.
Outlook extracts the recipient's public key from his or her certificate and generates a one-time lockbox, encrypting all of the data with a one-time, symmetric key and placing it inside this box. The lockbox, along with its contents, is encrypted with the recipient's public key and then sent to the recipient. When the recipient opens the message, the recipient's client decrypts the lockbox, using the recipient's private key, extracts the symmetric key, and decrypts the message with the symmetric key. Then the recipient can read the message.
Digital signatures are as legally binding as a signature on paper. Digital signatures provide origin authentication, since only the sender holds the private key used to generate the signature. The signature also provides data integrity because the signature is a protected hash of the message, meaning that the document is hashed and then encrypted with the signer's private encryption key and, after verification, it is decrypted with the signer's public key. If even one bit changes during message transmission, the hash will not be the same at the receiving end, and the message will be considered invalid. A given signature is generated for only a single message and will never be used again. Digital signatures work because embedded into each signature is an indicator that explains what hash functions the sender used. The recipient can use the same function and compute the same hash when the message is received. If the hashes match, the signature is considered valid. If the message is encrypted, it must be decrypted before the algorithm can be run to compare the hashes.
Secure/Multipurpose Internet Mail Extensions, or S/MIME, was designed by an RSA-led vendor consortium in 1995. Version 3 is in Internet Draft process at the time of this writing. S/MIME allows recipients using non-Microsoft software to see and understand encrypted, secure messages sent from Outlook 2000 users. For more information on S/MIME, please visit the RSA Web site at http://www.rsa.com/smime/.
To obtain a certificate, a user can either enter the URL for the Web enrollment forms on the intranet or click the Get A Digital ID button on the Security tab of the Outlook 2000 Options dialog box. This button directs the user to the intranet Web enrollment forms.
Installing Outlook 2000 with the Corporate or Workgroup service option (see Chapter 16) affords several benefits. First, Certificate Services is integrated with Active Directory, meaning that you can specify whether the certificates are placed in Active Directory, in the file system, or both after they are created. To configure this setting, open the property sheet for the CA within the Certification Authority snap-in, display the Exit Module tab, and click the Configure button (Figure 21-26).
Figure 21-26. Specifying where certificates are placed.
The advantage of publishing a certificate in Active Directory is that the certificate becomes an attribute of the user's account, as shown in Figure 21-27. Before a user sends an encrypted message to another user, the client can look up the recipient's account in Active Directory to see whether that recipient has a certificate. If one exists, the message is sent as described previously. In addition, the client periodically (every 24 hours) picks up certificate trust and revocation lists that are published by Certificate Services and applies them as needed. In the absence of a hierarchical CA structure, the client can build a linear trust network of different CAs.
A second advantage of the Corporate or Workgroup service option is that it allows certificate enrollment through Key Management Service (KMS). One attractive feature of this service is its interoperability with legacy clients (Outlook 98 and earlier). Hence, KMS can be set up to issue certificates to clients running several different versions of Outlook, eliminating an immediate need to upgrade a large installed base of Outlook 98 users to Outlook 2000 before beginning to use certificates. Since Outlook 98 supports only version 1 of X.509 certificates, Outlook 2000 and future releases of Outlook will also support version 1 for backward compatibility.
Figure 21-27. Published Certificates tab of a user's property sheet.
Enrolling through KMS also provides key recovery, an important feature since approximately 10 percent of all corporate users lose their private encryption keys at some point. The ability to recover a private encryption key is essential because if the key is lost, any existing encrypted e-mail is unusable. For a more detailed discussion of certificate enrollment through KMS, see the section "Enrolling Users with KMS" later in this chapter.