Exchange Server 2010 : Using Outlook to Send and Receive Digitally Signed and Encrypted Emails (part 1)

When discussing email security, you need to consider two primary questions:

• How do you know the message truly came from the suspected source?

• How do you know the message has not been intercepted or tampered with?

Both of these questions can be answered by the use of digital signatures and encryption. Digital signatures provide authentication, nonrepudiation, and data integrity, whereas encryption keeps message contents confidential.

In an Exchange Server environment, both of these solutions can be provided by using Secure/Multipurpose Internet Mail Extensions (S/MIME).

Utilizing S/MIME with Outlook 2003 or Outlook 2007 allows you to do the following:

• Digitally sign a message to prove the identity of the sender—S/MIME is the only option supported in Outlook 2007 to digitally sign a message. Although a message protected with Information Rights Management (IRM) can prevent a message from being tampered with, IRM protection is more limited because there is no authority to verify the identity of the sender. Furthermore, with IRM, the Outlook user interface does not show information about the identity of the sender like it does when using S/MIME.

• Protect messages from unauthorized users—By utilizing encryption, messages are not sent in “clear text.” It is possible for attackers to monitor network traffic and intercept network traffic, but by encrypting the message, you can prevent them from gathering usable data. This protection is especially important for email sent over the Internet, as that is where point-to-point encryption is most valuable and where interoperability standards are most important.

Protecting your messages with S/MIME signatures and encryption is primarily used when users send or receive messages outside of your organization’s boundaries, as they are no longer protected by the corporate firewall.

Fundamentals of Digital Signatures and Encryption

The primary purpose of S/MIME is to provide digital signatures and encryption. S/MIME is a small subset of PKI, which addresses a much wider array of security-related capabilities. For instance, PKI supports smart cards, Secure Sockets Layer (SSL), user certificates, and much more.

The International Telecommunication Union (ITU), based in Geneva, Switzerland, has a Telecommunication Standardization Sector (ITU-T) that coordinates standards for telecommunications. X.509 is an ITU-T standard for PKI that specifies (among other things) standard formats for public key certificates and a certification path validation algorithm. Originally issued in 1988, this standard has been revised twice over the years, and Version 3 (the current version) defines the format for certificate extensions used to store information regarding the certificate holder and to define certificate usage.

In short, X.509 is a digital certificate standard that defines the format of the actual certificate used by S/MIME.

The certificate identifies information about the certificate’s owner and includes the owner’s public key information. X.509 is the industry standard digital certificate and is, by far, the most widely used. PKI products such as Microsoft’s Certificate Services (included in Windows Server 2008) adhere to this standard and generate X.509 digital certificates to be used with S/MIME-capable clients.

The Signing Process

When a message sender elects to sign a message, a process is completed where a numerical value is calculated based on the number of set bits in the message. Enclosing the numerical value, known as a checksum, with the original message allows the recipient to apply the same formula to the message.

The random checksum acts as the digital signature, sometimes called a digital ID. This signature is then encrypted using the user’s private signing key. The user then sends the message to the recipient, and the message has three components: the message in plain text, the sender’s X.509 digital certificate, and the digital certificate.

Upon receipt of the message, the recipient checks its certificate revocation list (CRL) to determine if the sender’s certificate has been revoked. If it is found on the CRL, the recipient is warned that the sender’s certificate has been revoked.

If the certificate is not on the revocation list, the digital signature is decrypted with the sender’s public signing key (which is included in the digital certificate). The recipient’s client then generates the checksum based on the plain text message and compares it to the digital signature.

If the checksum generated by the recipient does not match the one generated by the sender, the recipient knows that the message has been garbled or tampered with.

The Encryption Process

When a user elects to encrypt a message, the client generates a random bulk encryption key that is used to encrypt the contents of the message. The bulk encryption key is then encrypted using the recipient’s public key. This is known as a lockbox. If the message has multiple recipients, individual lockboxes are created, one for each recipient, using his or her own public encryption key. However, the content of each is still the same bulk signing key. This process prevents the client from having to encrypt the message separately for each recipient, while ensuring the contents remain secure.

For this process to work, the sender must have a copy of the recipient’s digital certificate. The certificate can be retrieved from either the Global Address List (GAL) or the sender’s Contact list. The digital certificate contains the recipient’s public encryption key, which is used to create the lockbox for the bulk encryption key.

When the message is received, the recipient uses his or her private encryption key to decrypt the lockbox, exposing the bulk encryption key that was used to encrypt the original message. The bulk encryption key is then used to decrypt the message.

This process sounds complicated, but it is actually very straightforward—the message is encrypted and needs a key to be decrypted. The key is sent with the message, but it is encrypted itself with the recipient’s public key—so, only the intended recipient is able to unlock the key and, in turn, unlock the message.

Making Sure Outlook Acknowledges the Certificate

After autoenrollment has issued a certificate to the user and the user has confirmed the certificate has been successfully received, you can confirm that Microsoft Outlook recognizes the certificate for encrypted communications. To do so, do the following:

Outlook automatically detects the correct autoenrolled certificate and configures Outlook to use the certificate for signing and encrypting email.