Secret Agent Plan

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

Bill: I have a laptop which has broken down—doesn't want to switch on any longer! Now my problem is this:

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.

Get Help from Bill

Got a Windows or Exchange question or need troubleshooting help? Or maybe you want a better explanation than provided in the manuals? Describe your dilemma in an e-mail to Bill at mailto:boswell@101com.com; the best questions get answered in this column.

When you send your questions, please include your full first and last name, location, certifications (if any) with your message. (If you prefer to remain anonymous, specify this in your message but submit the requested information for verification purposes.)

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.

comments powered by Disqus

Reader Comments:

Fri, Mar 12, 2004 Adrian Derby UK

Copying the files to FAT drive will not decrypt the files the only way to decrypt the files is to be in possesion of either the users or the DRA's Private key. If it were to work it would totally undermine the point of using the EFS. Similarly re-installing the OS is just as in-effective.

Fri, Mar 5, 2004 Anonymous Anonymous

How about simply copying the files to a FAT or FAT32 partition??? That should eliminate the view contents problem. Remember if you've not set ACLs on the folders or files, then you should be able to "read" them after you attach the disk to another system...

Sat, Feb 14, 2004 Purvis Anonymous

Very good article and a good way to check the security on a Laptop

Wed, Feb 11, 2004 Anonymous Anonymous

Ditto on the HDD removal. I was looking for a good test mechanism for EFS. This has given me ideas, thanks.

Wed, Feb 11, 2004 Anonymous Anonymous

I'll keep this as a reference.

Tue, Feb 10, 2004 Randy Boston

Useful info. One exception, I think.
I thought I understood that XP doesn't recognize the DRA in a Windows 2000 AD. Unless he's in a W2K3 domain, he's out of luck. No?

Tue, Feb 10, 2004 Randy Boston

Useful information - Just one problem, I think.
What if this is a Windows 2000 AD? He is using an XP workstation. I thought I read that the domain recovery agent is not recognized by XP unless it's a W2K3 domain.

Tue, Feb 10, 2004 Anonymous Anonymous

Even if you cant' get the HD to boot in another laptop, if you get a conversion kit for the drive and put it in a destop, you can copy the profile from the drive and thus have the keys.

Tue, Feb 10, 2004 Anonymous next to you

How about if a laptop was never a member of any domain?
Or if it was, but your domain admin renamed default admin account after first couple logins (as he should've)?
If removing a HD fails (?) then
there are several unorthodox ways to beat DFS - Elcomsoft came up with one and I believe there is more if you look for them.

Tue, Feb 10, 2004 Joe NY

Ditto. Pull the HD. Use a converter if you don't have another laptop handy.

Tue, Feb 10, 2004 Anonymous Anonymous

KISS method. As others have said, pull the HD into another machine. I did learn a lot though.

Tue, Feb 10, 2004 Lynn Toronto, Canada

If the drive itself is the problem, a good data recovery facility might be able to recover the contents, including those all-important certificates and keys. Use a data recovery firm with a "no data/no charge" policy - then if the drive is unsalvageable, it won't be an expensive exercise.

Tue, Feb 10, 2004 bkd Lafayette, LA

As others have said, pull the laptop drive and boot from another machine. It doesn't have to be another laptop, an adapter to run a laptop drive on a standard IDE cable is about $3(US).

Good coverage of EFS though.

Tue, Feb 10, 2004 Anonymous Anonymous

This article is a good discussion of encryption in W2K and XP. Another, and perhaps simplier method would be to move the hard drive from the laptop and put it into a similar laptop. You should be able to boot from the hard drive and recover the files.

Tue, Feb 10, 2004 Bob MCPMAG MidEast

Forest for the trees. It's a laptop, remove the hard drive and transplant the hard drive to another laptop.

Tue, Feb 10, 2004 Anonymous Anonymous

Another solution would be to pull the Hard Drive out of the laptop, move it to a similar laptop, unencrypt the files, move them and then re-encrypt the files. Moving the intact hard-drive will always be the easiest solution.

Add Your Comment Now:

Your Name:(optional)
Your Email:(optional)
Your Location:(optional)
Comment:
Please type the letters/numbers you see above

Redmond Tech Watch

Sign up for our newsletter.

I agree to this site's Privacy Policy.