5-Minute Security Advisor - Recovering Encrypted Data Using EFS

Updated : June 7, 2002

So your users have discovered the wonders of the Encrypting File System (EFS) and have decided to remove all but the most innocuous documents from the public's eye. One of your users—let's call him Bob-- is having a hard time decrypting his draft of the important corporate memo that he needs to send out in an hour. Minutes later, you receive a call from the CFO, who just received a new laptop and can no longer decrypt her financial reports. You take an additional two aspirin, but they are not helping.

To understand what causes these stumbling blocks—and how to fix them--let's take a look at EFS and how it encrypts and decrypts files.

How EFS recovery works

EFS uses both public key (asymmetric) encryption and symmetric encryption. Asymmetric encryption is an encryption scheme that uses two different keys, one to encrypt the data and the other to decrypt it. Likewise, in symmetric encryption you can use the same key to both encrypt and decrypt the data. Symmetric encryption is more difficult to manage securely than public-key encryption because no aspect of the encryption scheme (especially the key!) can be made public. However, symmetric encryption is much easier on the processor, because it occurs at roughly 100 to 1,000 times faster than asymmetric encryption. EFS combines both methods to give good performance and strong security at the same time.

When a new file is encrypted, the EFS service places an exclusive lock on the file and generates a File Encryption Key (FEK). The FEK is a symmetric key and, as such, it can be used to both encrypt and decrypt the file. The FEK is used for only that file. Once the FEK is generated, the file is encrypted. Then EFS locates the user's public key, which it uses to encrypt the FEK, and stores the encrypted FEK in a Data Decryption Field (DDF) in the header of the encrypted file.

When a user wants to decrypt the file, EFS retrieves the user's private key. It then uses the private key to decrypt the FEK, located in the DDF of the file header, and finally decrypts the file with the FEK.

Note that the File Encryption Key is not directly tied to the user. In fact, EFS can store multiple DDFs in a file's header, which will allow multiple users to decrypt the file. Each DDF contains the same key encrypted with a different user's public key.

Action Some sensitive data may still be exposed via the system's page file. This is easy to fix, though: on laptops, turn off hibernation, and make sure that Windows wipes the pagefile when the machine is shut down.

Data Recovery Agents

In addition to storing DDFs, EFS also stores a Data Recovery Field (DRF) for each user account that is designated as a Data Recovery Agent (DRA). For our purposes, a DDF and a DRF behave identically, except that the DDF is determined at the level of the file but all files on the local computer or domain have the same DRFs. This behavior allows a trusted administrator to decrypt files even if users lose their primary key. In Windows XP, DRAs are no longer required for EFS. The FEK resides only in the DDF and DRF fields of the file's header. If the file has only one DDF field and no DRF fields, only the user can decrypt the file. Although this arrangement is extremely secure, it is dangerous. If users lose their private key, the file is lost.

To adequately protect your data, you should be using at least one DRA. This is automatic with Windows 2000 domain computers; if you're not using a Windows domain, you can still designate DRAs for EFS files by following these instructions.

Backing up encrypted data

Backing up the encrypted files is as easy as backing up any other file. Because the FEK is stored with the file, you don't need to take any special precautions when you back up the file. However, you won't be able to decrypt the file if you don't restore it to a domain or local computer where authorized users can access their private keys.

It is also important to back up public/private key pairs and the public key certificate. The public key and public key certificate are stored in \username\Application Data\ Microsoft\SystemCertificates\My\Certificates folder of the user profile. The private key is stored in the \Documents and Settings\username\Application Data\Microsoft\Crypto\RSA folder. Like all data stored in the RSA folder, the private key is encrypted with the user's master key. Because the key pair and certificate are stored within the user profile, they are backed up when the profile is backed up.

Additionally, key pairs and certificates—including any DRA keys—can be exported to removable media and stored in a secure location. Note that anyone who has a DRA's keys can decrypt anything that the DRA can decrypt. Thus, it is imperative that these keys, and their backup media, be kept in a safe place.

Restoring user access to data

Recovery access is controlled by the recovery policy in effect on the computer where the data being recovered is stored. For standalone computers that aren't part of a domain, you set the policy on the local computer. If your computer is in a domain, you can set the domain EFS recovery policy via the Group Policy mechanism; this controls who has permission to act as a recovery agent for computers throughout the domain. In any case, when a user cannot decrypt a file, it's because they don't have access to their private key. The best resolution to this problem is to reunite users with their keys whenever possible. You do this by either restoring their user profile or by importing their keys and certificate. Once the users can access their keys, they will be able to retrieve the FEK by decrypting their DDF within the file. If there is no valid backup of the user's key, then a data recovery agent can either import the key to the user's computer or restore the encrypted file to a computer where the DRA key pair is stored to decrypt the file for the user. In order for this to work, you may need to use the efsinfo utility to figure out who the designated DRAs for the file are.

If you cannot restore the user's keys, and you have access to the DRA keys, the actual process of recovery is very straightforward: move the file to a machine that has the DRA's private key, find the file in Explorer, right-click it to open its Properties dialog, switch to the General tab, click the Advanced button, and clear the "Encrypt contents to secure data" checkbox. That's all you have to do!

Armed with this new information, you can stroll down the hall to the CFO's office, where you discover that she is logging on to her local workstation without a domain account. Realizing that her key was stored in her old local profile, you call IT to see if her old laptop is still available. Unfortunately, it has already been wiped out. Because the CFO is impatient and doesn't want to wait for you to restore her backed up laptop to get recover her profile, you load your DRA keys on her laptop and decrypt the files for her. While you're at it, you ensure that she will be logging on to the domain from now on. You then saunter down to the memo writer's cube and find out that his profile has been corrupted. Another call to IT gets his profile restored, which allows him to send his memo out almost on time! You return to your desk and promptly submit your request for a raise.

If you want more information on how EFS recovery works, and the best way to design an EFS recovery strategy that meets your needs, Check out the Data Protection and Recovery Whitepaper at https://www.microsoft.com and Chapter 17 of the Windows XP Resource Kit.