Advanced Security in Exchange 2000 and Outlook 2000-Part 3
In the past several months, many highly destructive viruses have moved quickly through companies around the world. As a result, email security has become a hot topic. After the recent Love Letter outbreak, Microsoft released an Outlook patch to protect against such attacks and upgraded the Secure MIME (S/MIME) capabilities of its Outlook 2000 mail client. Microsoft bundled the upgrade with Service Release 1a (SR1a) for Office 2000. The upgrade is known as the Outlook 2000 Federal Release at Microsoft because most of its features meet the US Government's secure mail standards. You can get both the antivirus patch and SR1a from the Microsoft Office Update Web site. Let's look at SR1a's S/MIME enhancements and new capabilities.
Enhanced Ease of Use
SR1a includes an important new feature called auto-configuration that makes it easy to set up and use secure messaging. Auto-configuration simplifies common S/MIME configuration scenarios, such as security profile generation and automatic recovery after a certificate becomes invalid. Auto-configuration launches when you click the Get Digital ID button in the Security Options dialog box and each time you read, send, save, forward, or reply to a secure message.
When auto-configuration runs, several steps take place behind the scenes. First, auto-configuration searches for a valid S/MIME profile. If the profile is invalid (e.g., if its certificates have expired), auto-configuration tries to fix the profile by looking for valid S/MIME certificates in the user's certificate store, which is part of the user's NT profile. If auto-configuration can't fix the S/MIME profile, it tries to create a new S/MIME profile using existing valid certificates. If this doesn't work, it launches the Secure E-mail Wizard, as Figure 1 shows. With the wizard, you can access the Outlook S/MIME Help files or request a new S/MIME certificate by clicking the GetDigital ID button. If you decline the wizard's help or if a secure mail operation fails, Outlook displays a dialog box that explains why it couldn't send a secure message. As Figure 2 shows, these dialog boxes are much more comprehensive than their equivalents in earlier versions of Outlook. (Auto-configuration has also improved other parts of the Outlook user interface¾UI. The secure messaging options Encrypt Message and Add Digital Signature always appear regardless of whether an S/MIME profile is available.)
Note that auto-configuration doesn't automatically renew an invalid certificate. Recovery succeeds only if a valid certificate is available from the certificate store. Also, although the wizard explains how to acquire a certificate, it doesn't request a certificate on your behalf.
Support for Enhanced Security Services
Request for Comments (RFC) 2634 specifies four optional security service extensions, also known as Enhanced Security Services (ESS), for S/MIME. Microsoft has implemented two of them in SR1a: secure receipts and security labels.
Secure Receipts. Secure receipts (which you shouldn't confuse with Outlook's delivery receipts or read receipts) provide "non-repudiation of reading," giving you cryptographic proof that the intended recipient has read and verified a signed message. A secure receipt is signed, meaning that when you receive a message and reply to it using a signed or secure receipt, you sign the receipt using a private key. You can't deny having done so because only you can access and use it.
A secure receipt takes three steps in its travels. First, you generate and send a message, specifying a secure receipt. Next, the recipient responds to the secure receipt request. Finally, you receive the secure receipt.
You can set the secure receipt request for signed only or signed and encrypted messages, as Figure 3 shows. The message can be clear or opaque signed (for more information about clear and opaque signing, see Advanced Security in Exchange 2000, Part 2. In SR1a, you can set secure receipts on the message level only. You can't make secure receipts receiver-dependent-if you set "request secure receipt for this message," it applies to all recipients. Also, secure receipts always return to the message's sender; it's not possible to set another return mailbox. You can make secure receipts the default by checking the "Request secure receipt for all S/MIME signed messages" box in Outlook's security options.
By default, Outlook 2000 SR1a automatically sends a secure receipt when you open the message and when the system can cryptographically verify the message signature. If you add the Registry value HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\9.0\Outlook\Security\RespondToReceiptRequests (REG_DWORD) and set it to 1, Outlook prompts you before sending a secure receipt: "A request has been made to send a secure receipt when the message has been verified. Do you want to send a secure receipt?" This prompt is independent of the "You must specify your security password to send a secure receipt response" message that you must respond to to get access to your private key.
To verify a secure receipt—to cryptographically verify the receipt's signature and instruct Outlook to check the receipt's content against the original—you must open the receipt. If the original message isn't in the Sent Items folder, Outlook prompts you to find it. If you can't find the original message, the secure receipt verification fails. If verification succeeds, Outlook 2000 automatically adds tracking information to the original message, as Figure 4 shows. Tracking information enables easy and centralized receipt status checking.
Once you've installed SR1a, you might notice that each digitally signed message has a Signed By field in the message header that contains the signer's RFC 822 mail address. The address also appears in the signer's certificate that accompanies the signed mail message. The Signed By field protects against spoofing (i.e., the obfuscation of the source mail address), offering a more reliable representation of the sender's identity than the SMTP From field. Before SR1a, anyone could easily modify SMTP From fields because they were never cryptographically protected. With SR1a and later, you can find the RFC 822 address inside the signed portion of the message.
Security Labels. A security label, a kind of tagging system for email messages, defines a message content's sensitivity. As with secure receipts, you can set security labels on signed messages. The power of the security label feature lies in its ability to restrict a user's access to a mail message, which is a standard requirement for messaging systems in military environments. The military, which doesn't want a sergeant-even if that sergeant is a system administrator-to have access to a general's mail, conceived of many of the concepts that RFC 2634 defines and SR1a implements.
In SR1a, Microsoft provides a UI that lets you attach security labels to the messages you send using Outlook. In addition to the UI, you need two things to implement security labels: security policy modules, which define the classification levels, and client-side logic, which enforces the security labels based on a user's classification level. Because security policies differ for each organization, Microsoft doesn't provide the logic for security labels out-of-the-box. Microsoft will provide a sample policy and a policy module design document in an upcoming Microsoft Platform software development kit (SDK) update.
Enhanced Certificate Access
SR1a makes it easier to share certificates you get from Certification Authorities (CAs) external to your organization or certificates that belong to S/MIME users in other organizations. You can store certificates in a contact entry, and you can publish personal certificates to the Exchange Global Address List (GAL).
The pre-SR1a releases of Outlook 2000 only store a pointer to a contact's certificate in a contact entry. You can find the real certificate (also known as the certificate blob) in the Registry. SR1a stores the certificate twice-once in the Registry and once in the Contacts folder. Sharing certificates is easy: Simply create a Contacts public folder or send the contact as an attachment to an email message.
To publish your personal certificates to the GAL, go to Tools, Options, Security Options, and select Publish to GAL (this button is available only when you're running Outlook in Corporate/Workgroup mode). In pre-SR1a versions of Outlook, only the Exchange advanced security certificates (the ones generated using the Key Management Service-KMS) publish to the Exchange directory. With SR1a and later, you can publish any S/MIME certificate and any certificate you receive from a commercial Certificate Authority (CA) to the GAL. To disable this feature, change the Registry setting HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\9.0\Outlook\Security\PublishToGalDisabled (REG_DWORD) to 1.
Under the Hood: Cryptographic Changes
Microsoft has implemented major cryptographic changes in Outlook 2000 SR1a. SR1a supports the Cryptographic Message Syntax (CMS), the Diffie-Hellman key agreement protocol, and the Digital Signature Algorithm (DSA).
The CMS standard describes a format for attaching cryptographic content—such as a digital signature or the result of an encryption operation-to messages. CMS, which RFC 2630 defines, is an open standard that extends the Public Key Cryptography Standards (PKCS) 7 message format. CMS differs from PKCS 7 in that it offers support for message body nesting, key agreement protocols, and unauthenticated message attributes.
Outlook 2000 SR1a can handle messages that consist of multiple layers of encryption and signing—for example, a message that you have signed and encrypted and that another user has also signed. SR1a doesn't support arbitrarily nested messages; the limit is three layers. Also, it's important to note that Outlook SR1a can't generate messages with a nested message body. However, if SR1a receives a triple-wrapped message, it displays the different encryption and signature layers correctly. SR1a comes with a new interface for displaying extended message security, encryption, and signature details, as Figure 5 shows. To access the new interface, click an S/MIME's signature or its encryption detail icon.
Outlook SR1a and later can use key agreement protocols, such as the Diffie-Hellman protocol. Earlier versions support only key transport protocols. Communicating parties use key agreement protocols to agree on a symmetric bulk encryption key. In a key agreement protocol, each partner knows a piece of the puzzle, and each piece contributes to generate a bulk encryption key. The alternative is a key transport protocol, in which one party generates a bulk encryption and sends it securely to the other. Because key agreement protocols use asymmetric cryptography more than key transport protocols do, key agreement protocols offer a higher level of security and are more resistant to attacks.
CMS and SR1a also support delivery of unauthenticated attributes, which are attributes that you can exclude from a digital signature operation. You can add unauthenticated attributes after message signing and change them during transmission without invalidating the digital signature. An example of such an attribute is a disclaimer on every outgoing message that passes through your organization's SMTP gateway. SR1a can handle messages carrying unauthenticated attributes, but it doesn't yet provide a way to add such attributes to a message.
Enabling and Configuring SR1a S/MIME Features
The new SR1a S/MIME features are not enabled by default. To enable them, add the Registry value HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\office\9.0\outlook\security\enablesrfeatures (REG_DWORD) and set it to 1.
You can control most of the SR1a Outlook S/MIME features using Registry settings, many of which I have mentioned in this article. For a detailed list of Registry settings, see the Outlook 2000 SR1 white paper. Because these settings are security-related, most organizations will want to enforce them. To do so, create a custom administrative template (*.adm), load it into the Windows 2000 Group Policy Object (GPO) editor, and use GPOs to enforce the settings on your user workstations.
An Upgrade That's Worth the Effort
SR1a extends Outlook's S/MIME capabilities with support for secure receipts, security labels, and message body nesting. SR1a also gives you auto-configuration and enhanced certificate access, two new features that will please most secure messaging users. For organizations with high-security requirements, these features are certainly worth the upgrade. Remember that when implementing security labels, SR1a is just a starting point. Security labels require a great deal of custom development.
