Current encryption (hiding) technologies fall into two main types: symmetric (secret) key algorithms, such as Data Encryption Standard (DES) or Advanced Encryption Standard (AES), and asymmetric (public/private) key algorithms, such as RSA or Elliptical Curve Cryptography (ECC). The modern sender-validation tools are mathematical one-way functions called hashes that make unique signatures. Two commonly used hashing methods are Message Digest algorithm 5 (MD5) and Secure Hash Algorithm (SHA). Computers can use these to generate a unique hash or number that corresponds to the individual source text (identical source texts hash to the same value). These simple tools are leveraged and combined to build a public key infrastructure (PKI) system.

Identities within a PKI system are managed using digital certificates, which are not unlike the government identification most people carry across an international border—the passport. The passport standard of the digital certificate world is the X.509 format, and it's widely used for both signing and encrypting in technologies such as S/MIME, Internet Protocol Security (IPsec), Secure Shell (SSH), wireless network security, virtual private networks (VPNs), and even secure server communications (such as SSL Web sites).

Certificates are built on top of asymmetric cryptography and hashes. To create a certificate, the requestor (the entity wanting a key signed by some higher authority) generates a private key. The key is kept locked away so its authenticity is never challenged. Along with the private key, a corresponding public key is also generated. As its name implies, the public portion of the pair is not secret and is distributed freely, though still in some way that ensures its authenticity.

This key pair allows for two fundamental operations. First, anyone can use the public key to encrypt something that only the private key can decrypt; second, the public key can be used to decrypt something encrypted with the private key. This is important for verifying a signature that only a private key could have created.

The request to the certificate authority includes details such as the identity of the person or computer the key is intended for, the algorithm type and strength, and the public portion of the key pair. The certificate authority (CA) receives and validates the information in the request and, using a hash algorithm, creates a unique identifier corresponding to the information.

Using its private key, the CA encrypts the hash of the information and assembles it into a standard format (such as X.509), creating a certificate corresponding to the original request. The X.509 certificate will contain a list of claims including the identity of the certificate (the subject), a validity time frame, the public key, and the operations the certificate can be used for. The certificate is then returned to the requestor; it is a token that states, in effect, "I, the CA, vouch for this public key and the private portion corresponding to it, for all uses described herein."

For root CAs (those at the highest level of the chain of trust), certificates are self-signed. Most acceptable root CAs come preinstalled in the base operating system or application but may be updated or altered via packages or enterprise configuration. Between the root CA and a leaf node (which typically describes an individual person or system), there may be one or more intermediate CAs.

The chain consists of all nodes and all preceding certificates embedded within them, signed by the CA at that level. A third party trying to validate the certificate can check the locally calculated hash and compare it to the one decrypted from the certificate using the corresponding public key for that particular CA or individual. That's it—a completely validated chain of trust from leaf to root—assuming, of course, the root is trusted.

Every good CA has a means for distributing a list of certificates that should no longer be trusted. This Certificate Revocation List (CRL) describes which issued items have been specifically negated by the CA. Conveniently, the location of the CRL is typically a property of the CA certificate.

CAs routinely issue CRLs on two bases: a schedule (perhaps every two weeks) or an event (some occurrence that indicates an issued certificate should no longer be trusted). A CA will sign its issued CRLs when it publishes them. When a receiving system evaluates the validity of a chain, it typically attempts to acquire the CRL for each issuing CA in the chain (via the details embedded in the certificates themselves or through some predefined trustworthy distribution mechanism). If any CRL is unavailable, the client may fall back on a recent, successfully cached copy as long as it's not older than the specified CRL update period. Failing that, however, the client systems will typically show some sort of error indicating that the certificate appears valid but the revocation status can't be determined.

Many applications take significantly longer to load a certificate if they are unable to validate the chain or the CRL for every node in the chain. Depending on what the certificate was protecting, the user may or may not want to trust it. A routinely updated, widely available CRL distribution point is absolutely necessary for every CA, especially for those public roots.

Roots are the foundation of the certificate chain, and chaining is the foundation of all certificate hierarchies. Most client systems or apps will only assume that a leaf node certificate is valid if it chains back to a trusted root. This could be an enterprise CA, owned and operated by that particular company, or it could be a public root CA (such as VeriSign).

For public root CAs, there are expectations of significant operational expertise so that integrity is assured. Enterprises should strive for the same level for their in-house operations, as the sanctity of a root CA in that context is just as important. For optimal protection, root CAs should actually be kept offline and only used to issue certificates and update CRLs. For more information on CA operational best practices, please see the articles listed in the "Certificate Authority Resources" sidebar.

One important aspect to consider is key recovery. In order to facilitate investigations and to assure that data isn't irretrievably locked away by a user, the enterprise should make backup copies of all user-issued keys. Furthermore, these backup copies should be stored in a safe repository. That way, if a user's key disappears, for example when a smart card gets left behind in a taxi, any content protected by the key can still be accessed.

Finally, within every good cryptographic system is the concept of lifecycle management. As computers get faster, algorithms get weaker. Every good cryptosystem needs the ability to renew itself and shift to new algorithms and key sizes over time. CAs should be updated appropriately when cryptographic weaknesses are identified and certain functions are phased in or out.

There are several stages to bootstrapping, composing, sending, and receiving signed or encrypted e-mail using S/MIME. We'll cover the details, problems, and potential solutions as we progress through a typical S/MIME scenario: two users sending signed and/or encrypted e-mail to each other from two different Active Directory® forests and different certificate authority chains (that is, from operationally separate entities, whether within the same company or not) using Microsoft® Office Outlook® 2007.

We'll assume that the necessary infrastructure is already in place to enable the operations we are going to describe. In our case, we are using an Active Directory-integrated enterprise certificate server.

The first task is to get the appropriate certificates. To do so, you open the Certificate Manager MMC (certmgr.msc), right-click on the Personal folder, select All Tasks on the pop-up list, then select Request New from the list.

This launches the Certificate Enrollment wizard, as shown in Figure 1. By default, several enterprise-centric options will be shown, but the User certificate is the important one. It will be used to enable the signing and encryption processes later. The certificate must be capable of being used for:

• Digital signatures (creating a message with a seal of authenticity from its creator)
• Key encipherment (protecting one key with another for technologies such as the Encrypting File System)
• Secure mail (encrypted messaging that can be read only by the intended recipient in possession of the corresponding pri- vate key)

To send S/MIME signed e-mail, the key encipherment property is not required. However, to send or receive encrypted mail, this property is required, though the signature property is not. By default, the templates in Windows® Certificate Services enable these three properties. If the user is not permitted to request new certificates, none will be shown when the wizard launches. If no enterprise CA is available, the user will be presented with an "Enrollment error" indicating the domain or CA could not be contacted. For this walkthrough, we will assume a single certificate allowing both signature and encipherment.

The easiest way for two users to start sending encrypted e-mails is to simply send signed messages to each other. After composing a message, the user clicks on the Sign button. (Sometimes the button is hidden by default in Outlook until used at least once. It can be found by clicking on the Options setting for new messages, clicking the "Security Settings..." button, then checking the "Add a digital signature to this message" box on the Security Properties dialog.) The signing button (a little yellow envelope with a red ribbon on it that says Sign) adds a digital signature to the message to establish its source authenticity.

Upon hitting the Send button, the user may be prompted to provide additional tokens of key possession, such as inserting a smart card or entering a PIN. This depends on the particular methods of key protection in place in the organization.

The user receiving the S/MIME-signed message will need to view and right-click on the sender's name (after From:) and select "Add to Outlook contacts" from the context menu, which either adds a new contact entry or updates an existing one. The certificate is then associated with that particular contact entry. Note that within a common Active Directory environment (two users in the same forest or company), public user certificate distribution is done automatically via attributes in the user's Active Directory object.

Another way of exchanging certificates is for each user to send their S/MIME certificate(s) as an attachment. To do this, both parties will need to export their certificate(s) to a CER file. The users will need to view the certificate and follow the export process that we will soon discuss, taking care not to export the private key with it, as shown in Figure 2.

Each receiver then manually creates a contact entry in Outlook and adds the certificate to the sender's entry. Once the two users have exchanged certificates, they will be able to exchange encrypted e-mail with each other.

Sometimes the receiver has difficulty opening the encrypted message. The three most likely sources of problems we've seen in this area are untrusted root CAs, intermediate CAs that can't be validated, and CRLs that are not available.

An untrusted root CA typically shows in Outlook as an error message associated with the signature: "There are problems with the signature. Click the signature button for details." To solve the problem, open the certificate from within Outlook and click on the "View Certificate Authority" button from the pop-up dialog. Look at the message on the General tab of the certificate properties dialog. If it indicates that the CA Root certificate is not trusted and needs to be installed, go to the Details tab. Click the "Copy to File..." button and follow the wizard, accepting all defaults and providing a file name and folder when prompted.

Now open a new Microsoft Management Console (MMC) as a machine administrator. Go to File|Add/Remove Snap-in (Ctrl+M), select Certificates, and add it for the computer account, choosing Local computer when prompted. Next, expand the Certificates node in the left-hand tree, then do the same to the Trusted Root Certificate Authorities. Right-click and select All Tasks|Import from the pop-up menu. Import the previously mentioned exported certificate file to the Trusted Root Certificate Authorities and click Finish. Then have the affected user restart Outlook.

These instructions should be used only to add a root CA that you know to be trusted. Not all roots are created equal. Carefully consider who owns and operates the root CA before using this method to add a root to the store for the entire system. If your enterprise controls the list of trusted roots via Group Policy, the configuration will be pushed down to client systems. In that case, the instructions may not work. If they don't, you may need to explore alternatives such as secure Web sites or servers for exchanging data, as e-mail won't be a seamless and protected experience.

The second issue noted above, intermediate CAs cannot be validated, typically occurs in two situations: a client attempting to validate the certificate is unable to get to the Authority Information Access (AIA) location defined in the certificate, or the client has a version of the intermediate CA certificate that doesn't match what the CA is issuing (the client is often a version or two behind). These conditions appear very similar within the Outlook user interface. We've only seen it in a very specific circumstance when a mid-level CA in the chain expired and was reissued before other subordinate certificates it issued had expired.

Basically, this problem occurs when the chain has gaps in it. Some parent certificates may not be well-detailed or not embedded in the leaf node appropriately, further complicating the situation.

To resolve this issue, the sender will need to open a new message and click on the new message Options, then on the Security settings button, and then on the Change settings button. Now click the Choose button for the signing certificate, then on the View Certificate button on the pop-up dialog. Go to the Certificate Path tab, select the issuer of the leaf node (that is, up one level in the chain), and click the View Certificate button. Click the Details tab, then the Copy to File... button, then complete the export wizard, selecting PKCS #7 (.P7B). Make sure that the "Include all certificates in the certification path" option is checked, as shown in Figure 3. Finally, send the exported chain file to the desired receiver.

After getting the exported certificate chain, the recipient will need to open and import the chain much as we imported a root previously. The one difference is that the chosen storage folder should be the Intermediate Certificate Authorities. If the message opens and the certificate is shown as valid in Outlook, things are working properly.

As for the third issue, CRLs not being available, the fix is comparably simple. The initial response from Outlook will look very similar to the prior issue. However, the error will show even if the root or intermediate signing CAs are trusted. For each level of the certificate chain above the leaf, open the certificate's properties, then the details tab, and look at the field called "CRL Distribution Points."

For each CRL distribution point listed (especially the Internet-accessible ones), verify that the CRL file URL can be opened. As each level validates, move up one level in the chain. If any CRL can't be acquired, it's probably the source of the problem. To resolve the issue, you should verify that your local network policy is not blocking your access. Otherwise, try contacting the company that owns the CA or wait for the CA's CRL distribution point to return to operational status.

Distribution is the easy part. Basically, the signed message is transmitted to a mail server, which then sends it from one location to another via a tried-and-true method, SMTP. The one problem we've seen with signed or encrypted mail in transit is that some mail systems reject or break signed or encrypted messages that pass through them. The fix is to work with the IT manager of the system to get the message types allowed. Of course, you may have to live with the fact that some message types are blocked. The receiving party may have good reason for not allowing encrypted messages in a particular operational environment.

To create an encrypted reply (assuming the above bootstrapping process has already been completed), the sender need only create a message and then click the Encrypt button (the little yellow envelope with the blue lock on it that says Encrypt) in the message composition window. If the Encrypt button is unavailable, follow the steps for sending a signed message, except at the last step, and mark the "Encrypt message contents and attachments" checkbox instead.

S/MIME signing is not required for sending an encrypted message to a recipient, but the two certainly go well together, as signing lets the reader validate the sender (the encryption function makes no claims as to the sender). The encryption process will attempt to encrypt the message with the known public keys of all recipients. If the system is unable to find certificates for some intended recipients, they will be flagged in a pop-up dialog that offers to send the message unencrypted, as Figure 4 shows.

By default, signing and encrypting should work with other comparably configured client systems, but occasionally cross-version encrypted or signed messaging may have issues if the hashing or encryption algorithm is unsupported down-level. We encountered such an issue when sending a signed e-mail (using SHA-512 as the hashing algorithm) to a user running Windows XP SP2. Because the receiving system did not support the hash, the user was not able to validate the signature or read the message. However, it is unlikely users will encounter many problems at this stage unless the Outlook defaults have been changed.

Upon receipt of the message, the intended recipient should be able to open it, provided the private key associated with the public certificate is available. Again, the user may be required to provide an additional token to prove possession of the private key, depending on how it was deployed. Other users who have completed a similar bootstrapping process may take part in similar signed and encrypted communications with the sender. If a user changes his private key at some point (perhaps due to a lost computer), he will need to re-request certificates and redistribute a signed message or certificate file to others wanting to exchange encrypted mail.

Getting signed and encrypted S/MIME working between two users in two different directories or organizations typically isn't much more complicated than what we just discussed. Signing is very handy when used correctly, as it adds authenticity to the message. For sensitive details, encrypted messages provide an extra level of secrecy for data in transit. Combined, the two allow both authenticity of source and secrecy of data. And with the process we've described here, it won't be challenging for most users to take advantage of these capabilities.