Managing and Troubleshooting Encryption and Digital Signatures

Two pressing issues for email communication is ensuring that

• The contents of an email are not intercepted by someone who should not see it.

• You can verify that the email has been sent by the person from whom it appears to come.

Dealing with these problems is the subject of the encryption and digital signatures objective of the 70-284 curriculum. As email is vital to the life of a business, the ability to be certain that you can trust an email is legitimate becomes more important. Email was not originally designed to be secure; it was merely designed to transmit information in a more convenient way than sending a memo. Email can be made more secure by extending it with digital signatures and encryption. Encryption and digital signatures in Exchange Server 2003 rely on a technology known as Public Key Infrastructure (PKI).

Public Key Infrastructure (PKI)

PKI works on a system of two keys. In this context, key is another term for digital certificate. These two keys are an individual's public key, which can be viewed by everyone, and a private key, which is possessed only by the individual.

Public keys must be stored in a location in which they can be accessed by anyone wanting to send an encrypted message to an individual. When someone wants to send an encrypted message, she locates the recipient's public key and encrypts the message based on this key. Only the recipient, with his private key, can decrypt the message.

Although you can encrypt content via the public key, PKI works in such a fashion that you cannot decrypt the same content via the public key. This can be counterintuitive to people who think of one key being able to lock and unlock a door. In PKI, the public key can lock the door, but cannot unlock it! Only the private key can unlock the door.

PKI consists of several important components:

• Keys These take the form of digital certificates. PKI relies on public and private keys. Private keys must be held by the user and kept safe. Public keys can be freely distributed.

• Certificate authority (CA) The CA issues the digital certificates as well as performs several important management tasks, such as keeping an archive of private keys.

• Certificate templates These are used by the CA to generate certificates. Certificates used for Exchange can either be used for signing, encrypting, or both functions.

• Certificate revocation list (CRL) This is a list of certificates that are no longer valid. Reasons for placing certificates on the CRL include the loss or compromise of the private key. A CRL allows the public to know that a previously issued certificate is untrustworthy.

This is not an exhaustive description of PKI, but it does suffice for the purposes of the Exchange Server 2003 exam. More about how PKI relates to securing messaging on Exchange Server 2003 is covered in the following section.

Encryption

Encryption is the method by which you encode a message so that only people with the correct key can decrypt it. If you view an encrypted message without decrypting it, it looks like a string of random characters. The patterns are almost impossible to decipher without the use of a computer. By its nature, PKI encryption is supposed to work so that the only way the encrypted content can be viewed is by unencrypting it via the private key. If the private key in a PKI pair is lost, then there is no hope of data being recovered unless a key recovery agent has been configured.

Encryption has been around for thousands of years, the Caesar Cipher being one well-known early form. Enigma machines, used during World War II, were used to manually encrypt and decrypt German message traffic. In the case of the Enigma machine, the allies captured one, which enabled them to reverse engineer a key and intercept German message traffic. Rumors abound that big government intelligence agencies, such as the US National Security Agency (NSA), British Military Intelligence section 5 (MI5), and the Russian Federal Security (FSB), have computers that can crack the commercial encryption products on the market today. Some countries also have laws on the books that can compel you to hand over your private key and, in the event you "lose" it, you might face jail time.

When you want to send a message to someone and ensure that only she can read it, the first step you must take is to locate her public key. After you have located her public key, you can encrypt the message using that key. After the message is encrypted, you cannot read it, unless you have stored the unencrypted version elsewhere. Only the recipient of your message can read the encrypted message. She can only do so once she has decrypted the message with the private key that is paired with the public one you used to encrypt the message.

Digital Signatures

Digital signatures serve two purposes:

• Proof of the identity of the message sender

• Proof that the message has not been tampered with since it has been sent

Because it is relatively easy to spoof mail headers (see the following note), it is relatively easy to make it look as if a person has sent an email, which she, in fact, did not send. This causes a problem for most organizations because they need to trust their messaging infrastructure. If the organization cannot trust that an email has been sent by the person from whom it appears to be sent, email becomes useless as a communication tool.

Because of the architecture of email, in which there is no authentication required to prove to the mail server that you are indeed the person on the "from line" of an email, it is amazingly easy to spoof a fake email message. Mail headers might indicate the IP address from which a message was sent, but few people dig that deep, and this information can be faked as well.

Digital signatures allow email to become more trustworthy. Digital signatures are a sequence of characters that are generated based on the content of the email and the sender's private key. The recipient is then able to use this sequence to check whether the email has been tampered with, using the sender's public key and the contents of the email. If the message has not been tampered with, the recipient can verify that the message was indeed sent by the person whose digital signature is attached. If the message has been tampered with, the digital signature cannot be verified. The recipient then knows that the content of the message might have been tampered with and can take appropriate action.

Exchange Server 2003 Integration

Exchange Server 2003 and the Outlook client software support digital signatures and encryption using Secure/Multipurpose Internet Mail Extensions (S/MIME). S/MIME is a version of the MIME protocol that has been extended to support encryption. Digitally encrypted and signed email has the following properties:

• Digitally encrypted email remains encrypted while the message is being sent and received, as well as while the message is stored on the server or in the user's mailbox.

• Digital signatures also remain after a message has been received and verified by the recipient, giving the recipient a way to ascertain if the message has been tampered with after it has come into her possession.

• You can create public/private key pairs for the individual tasks of encrypting and signing, or you can create a single public/private key pair for both tasks.

In Exchange Server 5.5 and Exchange 2000 Server, tasks related to certificates were handled by the Microsoft Key Management Service (KMS). Exchange Server 2003 integrates more closely with Certificate Services, which can be installed as an add-on component to Windows Server 2003 or Windows 2000 Server. Certificate Services can be tightly integrated with Active Directory. Certificate Services can be used to

• Issue digital certificates.

• Host a store of issued private keys that can be retrieved by appropriately authenticated users.

• Enable the automatic deployment of certificates for Active Directory integrated applications such as Exchange Server 2003.

Preparing the Exchange Server 2003 Environment for the Deployment of Encryption and Digital Certificates

To use digital certificates, signing, encrypting, or both, Exchange needs to be able to access an enterprise CA. An enterprise CA, unlike a standalone CA, is tightly bound to Active Directory.

• A certificate template must be configured. Configure autoenrollment if desired.

• An enterprise CA needs to be configured to enable key recovery.

• Certificates should be deployed.

An enterprise CA should be used because it allows the use of autoenrollment of certificates. It also allows users to locate the certificates of other users via their Active Directory accounts. The ability to locate public certificates is vital in encrypting messages when using PKI.

Configuring Certificate Templates for Exchange Server 2003

To configure certificate templates, log on to the enterprise subordinate CA. Run the certificate templates console by issuing the Start, Run, certtmpl.msc command. Three different Exchange certificate templates can be enabled, as shown in Figure 9.7. These are Exchange User, Exchange Enrollment Agent (Offline Request), and Exchange Signature Only.

Figure 9.7. The Exchange certificate templates.

For the tasks discussed in this objective for the 70-284 exam, the certificate template that needs to be enabled is the Exchange User template. To configure the template, right-click on the Exchange User template and select Properties. In the Exchange User Properties dialog box, select the Security tab, and ensure that Enroll is selected for the Authenticate Users option, as shown in Figure 9.8. After this is completed, you can click OK to close the Exchange User template properties. You will likely want to make a copy of this certificate template so that you can assign the autoenroll permission to the Authenticated Users group. If you create such a template, substitute the name of the new template for the Exchange User template in the Deploying Certificates section.

Figure 9.8. Exchange User Certificate Template Properties dialog box.

Deploying Certificates

To allow the CA to actually issue this newly enabled template, run the Certification Authority manager, right-click on the Certificate Templates node, and select New Certificate Template to Issue. From the Enable Certificate Templates dialog box, select Exchange User, as shown in Figure 9.9.

Figure 9.9. Enabling certificate templates.

Performing this step allows the CA to issue certificates based on the template. Without performing this step, the template exists, but no certificates of this type can be issued.

Verifying That the Mailbox Store Supports S/MIME

If users are not able to store encrypted or digitally signed messages, it might be that the mailbox store does not support S/MIME. To verify whether S/MIME is supported, run the Exchange System Manager. Navigate to the mailbox stores and check each mailbox store's properties. You need to ensure that the Clients Support S/MIME Signatures check box is selected, as shown in Figure 9.10.

Figure 9.10. S/MIME support on mailbox store.

By default, this support is enabled. Being aware of the option might help you in the troubleshooting portion of the exam.

Key Recovery Agent

In a process similar to the one that you would perform to enable the Exchange User certificate, you can configure a key recovery agent. Key recovery agents can be used to recover keys that are lost. The benefit of a key recovery agent is that if something happens to the private key, the key can be recovered and encrypted mail can be viewed. The downside to a key recovery agent is that the individual responsible for key recovery can read encrypted mail that would otherwise only be available to the recipient. Most organizations enable key recovery under strict policy guidelines to ensure against its abuse.

As the process of configuring a key recovery agent and performing a key recovery is extremely complex, you are not expected to be able to reproduce it on the exam. You do need to know that private keys can be recovered assuming that a key recovery agent was configured before the private key was lost.

Configuring Outlook to Enable Digital Signatures and Encryption

After an enterprise CA has been configured to issue certificates, you can use Outlook to send encrypted messages as well as digitally sign communication. Outlook is configured to support encryption and digital signatures in the Security tab of the Options dialog box, located on the Tools menu. Here, you can select a signing certificate and a hash algorithm. Similarly, you can select an encryption certificate (this can be the same as the signing certificate) and an encryption algorithm. The stronger algorithms require more processor power on the part of your and your recipient's workstation. On the other hand, the stronger algorithms are also more likely to protect your data.