Securing Messaging in Outlook 2003

From the client perspective, one question that must be answered is how the Outlook 2003 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 root certificates are embedded in the installation. Outlook uses the Internet Explorer cryptographic service provider 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 25-27 shows a partial list of the default trusted root certificate authorities that ship with Outlook 2003 and Internet Explorer 6.

Figure 25-27: Partial list of trusted root certificate authorities in Internet Explorer.

Note

A cryptographic service provider is the actual code that has the algorithms for encrypting data and creating signatures.

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, 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.

Initially Trusting a Certificate

If your company implements its own CA or if you need to trust specific CAs that are not embedded by default in IE, you can import their certificates by clicking 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 from the Internet, someone might 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 whether the certificate’s serial number is valid. Some CAs include serial numbers on their Web sites, or you can contact the system administrator of a corporate CA.

Encryption and Outlook 2003

When both the sender and receiver are using Outlook 2003 along with certificates, their messages are encrypted end to end, meaning that the Outlook 2003 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 Server 2003, 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 2003 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 2003, and display the Security tab (Figure 25-28).

Figure 25-28: 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 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 and Outlook 2003

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.

S/MIME and Outlook 2003

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 2003 users.

More Info

For more information about S/MIME, visit the RSA Web site at http://www.rsasecurity.com.

When a message is signed, the content of the message is converted to a MIME format. The message headers and body use the algorithm from the user’s private key to produce a Message Integrity Check (MIC). The result is the digital signature. The message is then sent with a copy of the sender’s public key embedded in the message.

When the message is read, the MIC is generated at the recipient’s end and the results are compared to the sender’s digital signature. If they match, the signature is considered valid.

When it comes to encryption, the recipient’s public key is used to encrypt the data. To send an encrypted message, the sender must be able to retrieve the recipient’s public key. The recipient can then decrypt the message using his or her private key. By default, the Outlook client looks to either Active Directory or the recipient’s own personal certificate store for the recipient’s public key.

For all of this to work, there must be a common CA trusted between the sender and recipient. Trust verification, which is the act of determining whether a given public certificate comes from a trusted source, is performed by the Outlook client (and Outlook Express) on the desktop.

Configuring Outlook 2003 for Secure Messaging

Certificate Services is integrated with Active Directory, and you can specify whether you want the certificates to be published in a file system in addition to Active Directory. To configure this setting, open the property sheet for the CA in the Certification Authority snap-in, display the Exit Module tab, and click the Properties button (Figure 25-29).

Figure 25-29: Allowing certificates to be published to the file system option.

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 25-30. 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.

Figure 25-30: Published Certificates tab of a user’s property sheet.

In the Outlook client, use the Tools/Options/Security tab (refer to Figure 25-27) to select whether you want e-mail to be sent signed, encrypted, or both.