Chapter 11: Administering Cryptography in Outlook 2003

Download CD Content

Microsoft Office Outlook 2003 provides features for sending and receiving security-enhanced e-mail messages over the Internet or intranet. You can define security labels and security-enhanced receipts to help ensure secure e-mail messaging. Users can also obtain and use certificates for digital signatures or for encrypting messages.

Overview of Cryptography in Outlook 2003

Microsoft Office Outlook 2003 provides several features to help users send and receive cryptographic e-mail messages. Cryptographic features in Outlook—which include digital signing and message encryption—can be combined to help provide different levels and types of security. This section of the chapter provides an overview of Outlook 2003 features that support cryptographic messaging and an explanation of how cryptographic messaging is implemented in Outlook 2003.

Note

To get full security functionality in Outlook 2003, you must install Outlook 2003 with local administrative rights or with elevated privileges. If you are installing Outlook 2003 on client computers for users who do not have local administrative rights, you can give them elevated privileges for the installation. For more information about using elevated privileges in Office installations, see “Installing Office with Elevated Privileges” in Chapter 5, “Installing Office 2003.”

Cryptographic messaging features in Outlook 2003

Outlook 2003 supports the following features for cryptographic messaging:

• Digitally sign an e-mail message. Digital signing provides nonrepudiation and verification of contents (the message contains what the person sent, with no changes).

• Encrypt an e-mail message. Encryption helps to ensure privacy by making the message unreadable to anyone other than the intended recipient.

There are additional features that can be configured for Outlook 2003 for security-enhanced messaging, if your organization chooses to provide support for them, including:

• Sending an e-mail message with an S/MIME receipt request. This helps to verify that the recipient is validating your digital signature (the certificate you applied to a message).

• Adding a security label to an e-mail message. Your organization can create a customized S/MIME V3 security policy which can add labels to messages. An S/MIME V3 security policy is code that you add to Outlook that runs automatically to add information to the message header about the sensitivity of the message content. For example, an Internal Use Only label might be applied to mail that should not be sent or forwarded outside of your company.

How Outlook 2003 implements cryptographic messaging

The Outlook 2003 cryptography model uses public key encryption to send and receive signed and encrypted e-mail messages. Outlook 2003 supports S/MIME V3 security, which allows users to exchange security-enhanced e-mail messages with other S/MIME e-mail clients over the Internet or intranet.

Users can exchange signed and encrypted e-mail messages with other e-mail clients that support S/MIME. Following the S/MIME model, e-mail messages encrypted by the user’s public key can be decrypted using only the associated private key. This means that when a user sends an encrypted e-mail message, the recipient’s certificate (public key) is used to encrypt it; likewise, when a user reads an encrypted e-mail message, Outlook 2003 uses the user’s private key to decrypt it.

In Outlook 2003, users are required to have a security profile to use cryptographic features. A security profile is a group of settings that describe the certificates and algorithms that will be used when a user sends messages that use cryptographic features. Security profiles are configured automatically (if the profile is not already present) when:

• A user has certificates for cryptography on his or her computer;

  and

• The user begins to use a cryptographic feature.

However, Outlook 2003 also includes flexibility for customizing these security settings for users ahead of time. You can use registry settings or Group Policy settings to customize Outlook to meet your organization’s cryptographic policies and to configure (and enforce, with Group Policy) the settings you want in the security profiles. These settings are described in the table in “Setting Consistent Outlook Cryptography Options for an Organization” later in this chapter.

Digital IDs: a combination of public/private keys and certificates

S/MIME features rely on digital IDs, which associate a user’s identity with a public and private key pair. The combination of a certificate and private/public key pair is called a digital ID. The private key can be saved in a security-enhanced store such as the Microsoft Windows certificate store on the user’s computer or on a Smart Card. Outlook 2003 fully supports the X.509v3 standard, which requires that public and private keys be created by a certificate authority such as VeriSign^™, Inc.

Users can obtain digital IDs by using public World Wide Web–based certificate authorities such as VeriSign and Microsoft Certificate Server. Or, an administrator can provide digital IDs to a group of users. Outlook 2003 also continues to support working with Microsoft Exchange Key Management Server to obtain or provide digital IDs.

When certificates for digital IDs expire or are updated, Outlook manages updates automatically (for example, by working with the issuing certificate authority). Users do not have to change their settings.

Outlook support for security labels and signed receipts

Outlook 2003 includes support for S/MIME V3 ESS extensions about security labels and signed receipts. These extensions help you to provide security-enhanced e-mail communications within your organization and to customize security to your requirements.

If your organization develops and provides S/MIME V3 security policies to add custom security labels, the code in the security policies can enforce attaching a security label to an e-mail message. You define one or more security policies for your organization and implement them programmatically. A security label is flexible in the features it provides, depending on how it is coded—for example:

• An Internal Use Only label might be implemented as a security label to apply to mail that should not be sent or forwarded outside of your company.

• A label can specify that certain recipients cannot forward or print the message (if the recipient also has the security policy installed).

Users can also send security-enhanced receipt requests with messages to verify that the recipients recognize the user’s digital signature. When the message is received and saved (even if it is not yet read) and the signature has been verified, a receipt is returned to the user’s Inbox. This implies that the message was read. If the user’s signature is not verified, no receipt is sent. When the receipt is returned, because the receipt is also signed, you have verification that the user has received and verified the message.

Classes of encryption strengths

There are two classes of encryption key strengths available from Microsoft: High (128-bit) and Low (40-bit). Microsoft provides 128-bit encryption capabilities in Windows 2000 and Windows XP, the operating systems required for Office 2003. Ensuring that users have versions of software that support high encryption will help provide our highest level of security-enhanced e-mail messaging.

Resources and related information

You can use the Outlook Security Labels application programming interface (API) to create security label policy modules to define the sensitivity of message content in your organization. For a detailed description of creating policy modules and code samples, see the MSDN article “Creating Security Label Policy Modules” at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnout2k2/html /odc_olseclabelapi.asp?frame=true.

Public key cryptography can help you maintain security-enhanced e-mail systems. For more information about the use of public key cryptography in Outlook, search for “Outlook 98 Security White Paper” on the Knowledge Base Search page of the Microsoft Product Support Services Web site at http://search.support.microsoft.com/kb/c.asp .

Microsoft Exchange Key Management Server version 5.5 issues keys for Microsoft Exchange Server security only. Microsoft Exchange Key Management Server 5.5 Service Pack 1 supports both Exchange security and S/MIME security. For more information, see the Microsoft Exchange Server version 5.5 Resource Guide in the Microsoft BackOffice Resource Kit, Second Edition.