Boswell's Q&A

Secret Agent Plan

A reader's encrypted files are safe and recoverable if he turned on the Data Recovery Agent.

• By Bill Boswell
• 02/01/2004

I had several files encrypted on this laptop—very important data to say the least! I used to back up my data onto a CD-RW using Windows XP's Backup Tool and I always left the data encrypted while backing up. Unfortunately I never backed up the private key and encryption certificate.

When I tried to restore my data onto another PC at work, the restore was successful, but I couldn't open the encrypted files. I have no access at all to my laptop, as it won't switch on. Is there any way that I could open the encrypted files?
—Anthony

Anthony: You might be in the clear. If the laptop was a member of an Active Directory domain, the encrypted files can be recovered.

First, some background: When you encrypt a file using the Encrypting File System, the EFS driver talks to the Microsoft Base Cryptographic Provider to get a random number from the Random Number Generator (RNG). This random number becomes the cipher key that EFS uses to encrypt the file.

Windows XP SP1 uses the Advanced Encryption Standard (AES) Rjindahl algorithm to encrypt the file. So does Windows Server 2003. Windows 2000 uses DESX or Triple-DES, where DES stands for the old Data Encryption Standard (now defunct). This may sound like geek trivia, but it could become important later.

To protect the portability of the files, EFS encrypts the cipher key used to encrypt the file and stores the key along with the file. To do this encryption, EFS uses a public key issued to the user by the Base Crypto Provider on the local machine. The private key, as you discovered, resides in the local profile of the user who encrypts the file.

Here's where things get interesting when it comes to solving this problem. EFS also encrypts a second copy of the cipher key using the public key issued to the domain's Administrator account. This account is called the Data Recovery Agent, or DRA.

The DRA private key resides in the Administrator profile of the first domain controller in the domain. (There's a wrinkle to this that I'll get to in a minute.) So, knowing that you need access to the private key corresponding to the public key used to encryption the cipher, here's what you do.

1. Take the backup file (bkf) and restore it at the first domain controller in the domain.
2. Log on using the Administrator for the domain. Don't use an account with Administrator privileges. It must be the actual account called Administrator.
3. Open one of the encrypted files. This should succeed because the Administrator account's private key will decrypt the cipher key for the file.

Okay, that sounds pretty simple. Here's some reasons why it might not work. When I said that the domain Administrator account was the DRA, that's only correct in a brand new installation of Active Directory or if you promoted a Windows NT 4.0 PDC then logged on as Administrator.

But, if you promoted an NT4 PDC then logged on using any other administrative account, then that account becomes the DRA. So, after the PDC upgrade, if you logged on using your Anthony account, then you became the DRA for the entire domain. The public key corresponding to the private key for your account on the newly upgraded PDC is used to encrypt cipher keys on every member computer.

So, if logging on as Administrator doesn't get access to the files, and this server is an upgraded PDC, go through the list of profiles under Documents and Settings and see if you can figure out which of the accounts was the first administrator to log onto the machine following the upgrade. This account will have a set of hidden cryptographic files in the profile.

You can also determine the name of the DRA account used by EFS when it encrypted the files via the Efsinfo utility in the Windows Server 2003 support tools. You can run that version of Efsinfo on Windows 2000. Open a command prompt and go to the folder where the recovered encrypted files reside. Run efsinfo /r to list the recovery agents.

If you're able to open the files but you only see gibberish inside, then you have a different sort of problem. A Windows 2000 domain controller uses DESX or Triple DES for file encryption, so you won't be able to decrypt files encrypted on Windows XP SP1, which uses AES for file encryption. In this case, you'll need to transport a copy of the EFS private key to an XP SP1 desktop or a Windows Server 2003 server then recover the backup files there.

To transport the key, while logged on as the DRA at the first domain controller in the domain, launch the Certmgr.msc console from %windir%\System32 and drill down to the Personal certificates. Right-click the File Recovery certificate and select Export from the menu. This opens a Certificate Export wizard. Just follow the wizard to save the private key to a transportable file. Give the file a strong password.

Then put a copy of the file on a Windows XP SP1 desktop and log on as the DRA and double-click the file. This launches the Certificate Import wizard. Walk through the wizard to put the certificate in the default repository.

At that point, you should be able to open the encrypted files.

Whew! Hopefully one of those possibilities worked for you and you're now viewing the encrypted files. You can clear the Encryption flag then put the files on a different laptop and encrypt them again and don't forget to get a backup of your local profile.

But... There's another possibility and it's not a pretty one. Unfortunately, Windows XP does not require a DRA to encrypt a file. (Windows 2000 Professional does require a DRA.) So, if the laptop was not able to locate the public key of the DRA in Active Directory, it would have encrypted the files without any DRA. Here's how you'll know if this happened:

If you run Efsinfo /r and it says that it can't find a recovery agent, then that's doom. The only possibility that might save your files is if you ever used a roaming profile for the account you used to log onto the laptop. If so, a copy of the private EFS key resides in that roaming profile. Configure your account to use the roaming profile again and log on using your domain account and see if you can access the files.

If none of that works, then at least you'll have peace of mind knowing that bad guys can't open the files, either. Hope this helps.