SolutionBase: Understanding PKI key management in Windows Server 2003

Public and private keys are popular methods for exchanging encrypted data. But exactly how does PKI Key Management work in Windows Server 2003? Brien Posey shows you.

PKI based encryption has its good points and its bad points. On the up side, PKI does a decent job of encrypting data and keeping it secure. On the down side, PKI is key based. If a user loses their private key then any data that has been encrypted with that key is as good as gone. This has long posed a problem in situations in which users use PKI to encrypt files. Fortunately, Windows Server 2003 offers a method for keeping a backup copy of user's private keys. In this article I will show you how key archiving and recovery works.

A crash course in PKI

I don't want to waste a lot of space talking about the finer points of PKI, but in order to understand the rest of the article you need to be familiar with the basics. The idea behind PKI is that a user is given two separate keys; a public key and a private key. The idea is that the user's public key is published on a server and made available to anyone who wants it. If someone wants to send a file to a user in a secure manner, they could download the recipient's public key and use it to encrypt the file or message. Once the data has been encrypted, the only thing that can decrypt it is the recipient's private key. The private key is held by the recipient and is never published to the outside world.

PKI encryption can be used to encrypt both files and E-mail messages. Microsoft learned early on that because users were in possession of their own private keys that key loss was sometimes an issue. Since PKI used to be used primarily for secure E-mail, Microsoft introduced the Key Management Service in Exchange Server 4.0. The Key Management Service was designed to automatically archive user's private keys and to allow those keys to be recovered if necessary. The Key Management Service remained an Exchange Server component through Exchange 2000. In 2003 though, Microsoft removed the Key Management Service from Exchange and made the functionality available directly through Windows Server 2003 instead.

Automatic key archival

The trick to automatic key archiving (and ultimately to key recovery) is that your organization must have a Windows Server 2003 Server acting as an enterprise certificate authority. If you have an enterprise certificate authority that's running Windows 2000 Server, then I would suggest upgrading.

The reason why an enterprise certificate authority is a requirement is because the automatic key archival works at the certificate authority level. The basic idea behind the process is that every time the certificate authority issues a certificate, the server makes a backup copy for itself.

This raises an interesting point though. One of the things that makes PKI so secure is that you don't usually have a centralized server with user's private keys on it. So is having a server filled with archived keys a security risk? There are several security mechanisms in place to help protect the archived certificates. I will talk more about some of these mechanisms later on. I will tell you though that you can specify which administrators are authorized to recover keys. The keys themselves are encrypted so that only the authorized recovery agents can recover them.

To enable key archiving, begin by entering the MMC command at the Run prompt. This will launch an empty Microsoft Management Console. When the console opens, select the Add/Remove Snap-in command from the File menu. At this point, Windows will display the Add/Remove Snap-in properties sheet. Click the Add button found on the properties sheet's Standalone tab to reveal a list of all of the available snap-ins. Select the Certification Authority option from the list, and click the Add button. You will now be prompted to enter the name of the server that the snap-in should manage. Make your selection and click Finish, followed by Close and OK.

Now that Certification Authority snap-in is loaded, navigate through the console tree to Console Root | Certification Authority | your server. Right click on the listing for your enterprise certificate authority and select the Properties command from the resulting shortcut menu. Windows will now display the server's properties sheet. Finally, select the properties sheet's Recovery Agents tab.

By default, the certificate authority is configured not to archive private keys. You can change this behavior by selecting the Archive The Key option. Just below the key archiving option is a field that allows you to configure the number of recovery agents that you want to use. This option requires a little explaining.

As I mentioned earlier, having a server that contains copies of user's private keys isn't exactly conducive to good security. If an administrator has access to everyone's keys, they could decrypt any file encrypted by any user. If the organization uses keys for message signing, the administrator could even use a stolen key to impersonate another user through E-mail. Since having access to the key archive gives an administrator so much power, Microsoft gives you the option of protecting the keys in the same way that the military protects nuclear weapons.

The military uses a fail-safe system in which a nuke can't be launched unless multiple authorized officers turn their keys simultaneously. Likewise, Windows is designed so that you can create a policy in which an archived key will not be released unless multiple administrators authorize the request. This is what the Number Of Recovery Agents option is. A recovery agent is an administrator that is authorized to retrieve archived keys. The Number Of Recovery Agents option allows you to input the number of recovery agents who have to work together to retrieve an archived key.

Once you have specified the number of key recovery agents required, you must click the Add button and select the key recovery certificates that you want to authorize. You can add as many certificates as you like as long as you specify at least as many as the required number of key recovery agents. One thing to keep in mind though is that none of the key recovery agent certificates that you specify will be actually authorized to recover keys until you restart the certificate services.

Modifying the template

OK, so far I have shown you how to enable automatic key archiving and how to specify which administrators are allowed to retrieve archived keys. If you read the "fine print" on the Recovery Agents tab of the server's properties sheet, you will notice that a key is only archived if archival is specified as a part of the certificate request. In most cases, certificate requests are template based, so the easiest way to ensure that key archival is requested is to modify the certificate request templates.

To modify a certificate request template, open an empty Microsoft Management Console in the same way that you did earlier, and then load the Certificate Templates snap-in. When the console loads, select the Certificate Templates node, and the pane on the right will display a list of available templates. Now, right click on the template that you want to modify and select the Properties command from the resulting shortcut menu. This will cause Windows to display the template's properties sheet. Select the Request Handling tab and then select the Archive Subject's Encryption Private Key check box, and click OK

I should mention that not all certificate request templates are created equally. Many of the certificate request templates listed are left over from Windows 2000 Server. The Archive Subject's Encryption Private Key option is available only in templates that were created specifically for Windows Server 2003. You can determine which operating system a template was created for by looking at the Minimum Supported CAs column in the list of templates. Only certificates that specify Windows Server 2003 as the minimum supported CA support archival requests.

Recovering lost keys

The primary method of recovering a lost key for a user is to use a command line utility called CERTUTIL. If you are the type that doesn't exactly enjoy using the command line to perform administrative tasks, there is a GUI utility called Key Recovery Tool (KRT.EXE) that you can use to recover the lost keys. Unlike CERTUTIL, the Key Recovery Tool isn't built into Windows. It is included in the Windows Server 2003 Resource Kit though. If you don't have a copy of the resource kit, you can download the Key Recovery Tool directly from the Microsoft Web site.

Since there are two different tools used for key recovery, I will walk you through the recovery process using both tools. Let's start with the CERTUTIL tool since it is included with Windows.

The first thing that the person who is performing the key recovery will have to do is to locate the archived key for the user whose key has been lost or destroyed. The problem is that in many cases, many different keys will have been archived for a single user. That being the case, the easiest thing to do is to get a list of all of the keys that have been archived for the user and then determine which key it is that needs to be retrieved. To get the list of keys for a user, enter the CERTUTIL –GETKEY command followed by the user's account name in domain\username format.

After you acquire the list of the keys that have been archived on behalf of the user, you must take some time and go through the list to figure out which key it is that you need to gain access to. As you go through the list, one of the things that you will notice is that each key has a corresponding serial number. When you locate the key that you want to recover, make note of the key's serial number because you will have to use the serial number to uniquely identify the key during the recovery process.

Now that you have a serial number for the key that you need to recover, it's time to actually recover the key. The recovery process involves exporting the key to a file, so you will have to come up with a unique filename that you can use for the file that will hold the recovered key. Once you have thought of a filename, enter the following command:

CERTUTIL -GETKEY serial_number filename

At this point, you have technically recovered the lost key. The problem is that the key file is in an invalid format and is not password protected. The next step of the procedure is to convert the key file to the Public Key Cryptography Standards (PKCS) #12 file. For this procedure, you will need to come up with a filename for the PKCS12 file that you are creating. You will also need a password that you can assign to the file. The syntax for the command is:

CERTUTIL -P "password" -RECOVERYKEY original_filename pkcs12_filename

In the above example, you would replace the word password with the password that you wish to assign to the file.

The file that you have now created is now in a usable format. Before I move on to showing you how to use the GUI interface, there is a shortcut that I want to show you. Earlier, I mentioned that often there will be multiple recovery keys archived for a single user.

The steps that I just showed you assume that you only need one of the archived keys. What if you need to recover half a dozen different keys for a single user though? You'd have to perform each of the above steps multiple times and in the end you would end up with half a dozen different PKCS#12 files. There isn't really any getting around performing all those steps multiple times, but if you end up with more than one file, you can merge all of the resulting files into a single file. The only stipulations are that the recovered keys must all be registered to the same user account, and that each key file must have the same password assigned to it. The syntax for merging multiple files together is:

CERTUTIL -P "password" -MERGEPFX -USER "file1,file2" "merge_filename"

GUI-based key recovery

As I mentioned earlier, your other option for recovering lost keys is to use a GUI based utility called the Key Recovery Tool. To do so, install the Windows Server 2003 Resource Kit and then execute the KRT.EXE file. When you do, Windows will open the Key Recovery Tool, but the tool may appear to freeze for a few moments while it queries the network for certificate authorities.

Once the utility starts responding again, go to the Certificate Authority (CA) drop down list and select the certificate authority containing the keys that you want to recover. Next, you will have to tell the utility what you are looking for. The Search Criteria drop down list will allow you to search by common name, requester name (this is the same as the user name), user principle name, certificate hash (the certificate's thumbprint), or the certificate's serial number. It's usually easiest to search by requester name. After selecting the requester name option, enter the username in domain\user format into the value field, and click Search.

After a few moments, the Key Recovery Tool will display all of the keys that have been archived for the user. As with the command line utility, the Key Recovery Tool will display the key's serial number and other pertinent information. The good news is that you don't have to worry about writing down serial numbers though.

If you only need to recover one specific key, you can select that key and then use the Retrieve Blob and Decrypt Blob to recover that specific key. If you want to recover all of the keys that have been archived for the user, then just click the Recover button.