Backing up EFS recovery keys is essential if you want to be able to recover encrypted documents after a disaster.
The Encrypting File System (EFS) lets you encrypt files so that unauthorized individuals can’t read them. Normally, this is a good thing, because it helps secure data stored on a machine’s hard drive. However, this hack is concerned with what happens when something goes wrong—for example, if a user’s machine becomes toast, taking her EFS private key and certificate to Never-Never Land.
The key to being able to recover encrypted files when something goes wrong is having a designated recovery agent already in place. Then, if you lose your EFS private key, the recovery agent can decrypt your encrypted files in an emergency. Every time you encrypt a file, EFS generates a unique File Encryption Key (FEK) that it uses to encrypt only that file. In other words, each encrypted file has its own unique FEK.
In addition, the FEK is itself encrypted using your own EFS public key and incorporated into the header of the file. Later, if you want to read the encrypted file, EFS automatically uses your EFS private key to decrypt the FEK for the file and then uses the FEK to decrypt the file itself. The FEK is thus used for both encrypting and decrypting the file (a process known as symmetric encryption), while your EFS public/private key pair is used for encrypting and decrypting the FEK (known as asymmetric encryption). This combination of symmetric (or secret-key) encryption and asymmetric (public-key) encryption is the basis of how EFS works.
But what happens if you lose your EFS private key? This might happen if your machine has two drives: a system drive (C:) and a data drive (D:), where encrypted files are stored. By default, your EFS keys are stored on your system drive, so if C: becomes corrupted, the encrypted files on D: will be inaccessible, right? That’s where the recovery agent comes in. Each time you encrypt a file, the FEK is encrypted with both your own EFS public key and the EFS public key of the recovery agent. That means that the recovery agent can always decrypt the FEK by using its EFS private key and thus decrypt the file when something goes wrong and your own private key is lost or corrupted.
What are these recovery agents? By default, on standalone Windows 2000 machines, the built-in local administrator account is designated as a recovery agent, so you can always log on as Administrator and decrypt any encrypted files stored on the machine. You can add other users as recovery agents by using the Local Security Policy console, which you can open by using Start→Run→secpol.msc. Then, expand Security Settings→Public Key Policies→Encrypted Data Recovery Agents, right-click on that node, and select Add to start the Add Recovery Agent Wizard. Any user accounts that already have X.509v3 certificates on the machine can then be added as recovery agents.
Tip
On standalone Windows Server 2003 machines, the built-in Administrator account is not a designated recovery agent. In fact, there are no default recovery agents in Windows Server 2003 in a workgroup environment. You must designate an account for this role.
In a domain environment, things are a little different. The built-in Domain Administrator account is the default recovery agent for all machines in the domain, and you can specify additional recovery agents by using Group Policy. Open the Group Policy Object for the domain, OU, or site in which the intended recovery agent account resides, and navigate to Computer Configuration→Windows Settings→Security Settings→Public Key Policies→Encrypted Data Recovery Agents. Right-click on this node and select Add to start the same Add Recovery Agent Wizard as before, but this time browse the directory to locate the account you want to add.
Once Group Policy refreshes, your new recovery agent will be able to decrypt files encrypted by other users, but only if the users encrypted the file after the new recovery agent was designated. This is because files encrypted previously have no information about this new recovery agent in their headers and therefore can’t be decrypted yet by the new recovery agent. Fortunately, if the user who encrypted the file simply opens and then closes it, this alone is sufficient for EFS to add the new recovery agent to the encrypted file’s header.
The moral of the story is that you should think before you implement EFS, and designate recovery agents before you allow users to start encrypting files. Otherwise, you might find yourself sending out an unusual email to everyone saying, “Please open and then close all files you have encrypted on your machines” or something similar.
Backing up files that have been encrypted using EFS is easy: simply use the Backup utility to back them up like any other files. What’s really important is that you also back up the EFS certificate and public/private key pair for each user who stores data on the machine. Since EFS is implemented on a per-user basis, you have to back up this information for each user individually.
Fortunately, as this information is stored in the user profile for each user, by simply backing up user profiles you also back up the users’ EFS certificates and keys. More specifically, a user’s EFS private key is stored in the \Application Data\Microsoft\Crypto\RSA subfolder within that user’s profile, while the user’s EFS public key certificate and public key are stored in the \Application Data\Microsoft\SystemCertificates\My Certificates\My folder under the subfolders \Certificates and \Keys.
You can back up users’ EFS certificates and key pairs as part of your regular backup program, and if you have roaming user profiles configured, you can do this centrally from the file server where such profiles are stored. If you don’t have roaming profiles implemented and users store important documents on their own machines, it might be necessary to have users back up their own profiles locally by using Backup to back up to file instead of tape. Unfortunately, this guards against profile corruption only, and it might not help if a disk failure causes the backed-up profile to be lost as well.
A better alternative is to have each user export his EFS certificate and private key to a floppy and store it somewhere safe. That way, if a user’s system drive crashes, he can still decrypt information on his data drive by importing his previously exported EFS certificate and private key.
The steps to export a user’s EFS certificate and private key are quite straightforward and can be done easily by any user. Simply open Internet Explorer, select Tools→Internet Options, switch to the Content tab, click the Certificates button, and select the Personal tab, as shown in Figure 2-10.
Then, select the certificate you want to export (the correct certificate will display “Encrypting File System” beneath “Certificate intended purposes,” near the bottom of the properties page) and click Export to begin the Certificate Export Wizard. Choose the option to include the user’s private key in the export (the public key is automatically included in the certificate), specify a password to protect your export file, and choose a name and destination for your export file. The result of this export process will be a Personal Information Exchange (.pfx) file, located in the target folder or media.
As mentioned previously, users will typically export their EFS keys to a floppy, but you could burn them to a CD or even store them on a secure network share if you prefer. The important thing is, wherever you export this information, keep it safe so that no one except the user and trusted administrators can access it. Anyone who gets their hands on the export file and cracks the password can use it to decrypt any encrypted files they can access.
If a user’s EFS keys later become corrupted and the need arises to reinstall these keys, this can be done either by repeating the previous process (but clicking Import instead of Export in Figure 2-10) or, more simply, by double-clicking on the .pfx file itself to start the Certificate Import Wizard. This wizard is smart enough to figure out that the EFS certificate and private key stored in the .pfx file should be imported into the user’s personal certificate store.
An interesting option to consider when exporting a user’s EFS certificate and private key is to delete the user’s private key from his profile during the process. This option is labeled “Delete the private key if the export is successful” and is found on the penultimate page of the Certificate Export Wizard. If you choose this option, you’ll be able to encrypt files by using EFS, but you won’t be able to decrypt them unless you supply the private key on some medium—something that might be an option to consider in a high-security environment.
If a user’s EFS private key becomes corrupted or lost and the user hasn’t backed up the key to a floppy as described in the previous section, it’s time for the recovery agent to step in. On a standalone machine, you can simply log on using the built-in Administrator account, locate the encrypted folders the user can no longer access in Windows Explorer, right-click on each folder, select Properties, click Advanced, and clear the “Encrypt contents to secure data” checkbox for each folder. This decrypts the files within the folders and enables the user to read them again.
In a domain environment, you typically don’t want to log onto a user’s machine as a domain administrator and see a local user profile being created for your account as a result. Instead, simply instruct the user to use the Backup utility to back up to file any encrypted volumes or folders on her machine. The resulting backup (.bkf) file processes files it backs up as a data stream and preserves their encrypted status. Then, have the user copy her .bkf file to a network share where you, as domain administrator, can access the backup file, restore it to another folder, decrypt any files the user needs, and copy these files to the share where the user can access them.
While this is the most common solution, there’s another approach that’s worth considering: unite the user with her EFS keys again. Even if the user hasn’t previously exported her keys to a floppy for safekeeping, chances are, in a domain environment, that you make regular backups of users’ profiles (assuming roaming profiles are enabled). By simply restoring a user’s profile from backup you restore her EFS certificate and keys, allowing her to read her encrypted files again. Then, tell her politely but firmly to immediately export her certificate and keys to a floppy, because you don’t want to have to go through this again!
If EFS is being used to encrypt files on a file server where multiple users store their files, this process can become complicated if you’ve designated different recovery agents for different groups of users. In particular, you might need to determine which recovery agents are designated for any encrypted files that users can no longer access. To do this, you can use the
efsinfo command-line utility included in the Windows 2000 Server Resource Kit. This handy little utility can tell you who originally encrypted a file and who the designated recovery agents for the file are. Just type efsinfo/r /u
filename, where filename includes the path to the encrypted file. Once you know any recovery agent for the file, you can proceed to decrypt it as shown previously.
What if the individual who can’t access her encrypted files is your boss and she needs access to her files immediately? Export your own EFS certificate and private key to floppy as a domain administrator or other recovery agent, walk the floppy over to your boss’s office, insert the floppy into her machine, import the certificate and private key, and decrypt her files. Then, delete the certificate and key from her machine. When she tries to encrypt a file again, a new EFS certificate and private key will automatically be generated. Smile, because you’ve acted like Superman, and send her an email later asking for a raise.
But what if your own EFS certificate and private key as domain administrator or recovery agent is lost or corrupted?
Obviously, it’s a good idea for administrators and other recovery agents to also make backup copies of their own EFS certificates and private keys. Otherwise, a point of failure exists in this whole recovery process, and users’ encrypted files could be lost forever and unrecoverable.
If
you’re operating in a workgroup environment, recall that the built-in local Administrator account is the default recovery agent in Windows 2000. This means you have to back up the EFS certificate and private key of the Administrator account, so log onto the machine using this account and use Start→Run→secpol to open Local Security Policy as before. Select the Encrypted Data Recovery Agents node under Public Key Policies in the left pane, right-click the EFS certificate in the right pane, and select All Tasks→Export to start the Certificate Export Wizard. Choose the option to export the private key as well, specify a password to protect the export file, and specify a filename and destination to export the information to—typically, some form of removable media, such as a floppy. Keep that floppy safe.
In a domain environment, the built-in Domain Administrator account is the default recovery agent and the EFS certificate and private key are located on the first domain controller in the domain (the one that created the domain when you ran dcpromo on it). Log onto this machine using that account, use Start→Run→dompol.msc to open the Domain Security Policy, select Encrypted Data Recovery Agents in the left pane, right-click the EFS certificate in the right pane, again select All Tasks→Export to start the Certificate Export Wizard, and proceed as before. If you are not given the option to export the private key, you might not be logged onto the right domain controller, so change machines and try again.
Another method for exporting certificates and keys is to use the Certificates snap-in. Open a blank MMC console, add this snap-in while logged on as Administrator, expand Certificates→Current User→Personal→Certificates, and find the certificate you want to back up by looking under the Intended Purposes column, as shown in Figure 2-11. The power of this approach is that you can also use it to back up and restore other sorts of certificates and keys, including EFS keys.
Now that you’ve backed up your recovery agent’s EFS certificate and keys, you’re ready for the worst—unless your dog eats your floppy!
Mitch Tulloch