Hack 94 Back Up EFS

figs/moderate.gif figs/hack94.gif

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 their 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 by 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, then 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 corrupt.

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 StartRunsecpol.msc. Then, expand Security SettingsPublic Key PoliciesEncrypted 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.

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 (GPO) for the domain, OU, or site in which the intended recovery agent account resides, and navigate to Computer ConfigurationWindows SettingsSecurity SettingsPublic Key PoliciesEncrypted 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 encrypt 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 a file simply opens and then closes the file, 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 Encrypted Data and EFS Keys

Backing up files that have been encrypted using EFS is easy: simply use the Backup utility to back them up like any other files you would back up. 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, this means you have to back up this information for each user individually. However, this information is stored in the user profile for each user, which means that simply by backing up user profiles you also back up their EFS certificate 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 users export their EFS certificate and private key to a floppy and have them store it somewhere safe. That way, if their system drive crashes, they can still decrypt information on their data drive by importing their previously exported EFS certificate and private key.

The steps to export a user's EFS certificate and private key are fortunately quite straightforward and can be done easily by any user. Simply open Internet Explorer, select ToolsInternet Options, switch to the Content tab, click the Certificates button, and select the Personal tab, as shown in Figure 10-5.

Figure 10-5. Exporting the EFS certificate and private key for user jsmith

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. 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 have access to.

The result of this export process will be a *.pfx file (called a Personal Information Exchange file), located in the target folder or media. Then, if the 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 10-5) 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.

Restoring EFS Keys

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, then 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 on to 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 file (*.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 his EFS keys again. Even if the user hasn't previously exported his keys to a floppy for safekeeping, chances are, in a domain environment, that you make regular backups of user's profiles (assuming roaming profiles are enabled). By simply restoring a user's profile from backup you restore his EFS certificate and keys, allowing him to read his encrypted files again. Then, tell him politely but firmly to immediately export his 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, then this process can be 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 corrupt?

Backing Up Recovery Agent Keys

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 on to the machine using this account and use StartRunsecpol 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 TasksExport 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 name and destination for exporting the information?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 StartRundompol.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 TasksExport 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 UserPersonalCertificates, and find the certificate you want to back up by looking under the Intended Purposes column, as shown in Figure 10-6. 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.

Figure 10-6. Using the Certificates snap-in to back up a recovery agent key

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!