Decrypting EFS

You probably know that all flavors of Windows 2000 support Encrypting File System (EFS), which encrypts your files before the system stores them on disk. (Mark Russinovich discusses the workings of EFS in detail in Internals, "Inside Win2K NTFS, Part 2," page 45.) At first glance, I guessed that I simply needed to flip a switch in the GUI to tell Win2K to encrypt a file, then Win2K would encrypt the file as I saved it and decrypt the file whenever I accessed it. If an unauthorized user tried to access the file, the user would either get an Access denied message or see a lot of meaningless characters. "Simple," I thought.

But start using and managing EFS, and you see that the devil is in the details. And EFS has a lot of details.

Recovery
One detail concerns recovery. If I encrypt a file and then forget the password, how can I recover the file? EFS doesn't let you encrypt files unless you set up at least one account as an EFS recovery agent. By default, a workstation's or member server's recovery agent is the default Administrator account. By "default Administrator account," Microsoft means the Administrator account you created when you installed Win2K, not any other member of the local Administrators account. On a domain, the default recovery agent is the default Administrator for the computer that was the first domain controller installed for that domain—in other words, the first server that you ran Dcpromo for when you created the domain.

Recovery isn't tricky and doesn't require you to run a special program. To recover an encrypted file, all you need to do is log on as the recovery agent, then use either the GUI or the Cipher command

cipher /u/a <filename>

to decrypt the file. EFS doesn't recognize any difference between the user who originally encrypted a file and the recovery agent—if you encrypt a Microsoft Word file and the recovery agent tries to open it, the recovery agent will see your file. However, if you've denied the recovery agent access to your Word file, the recovery agent won't be able to open and decrypt the file for you. To remedy the situation, you'll need an administrator to take ownership of the file and grant read and write access to the recovery agent. Of course, if you leave the default Administrator account as the recovery agent, the default Administrator will have no trouble seizing a file permission should the need arise.

But let's think some more about the recovery agent account: Should you really use the default Administrator account for anything? Probably not. But changing which account can handle emergency decryptions is a bit tricky. EFS uses a simple symmetrical algorithm to encrypt and decrypt your files—that is, EFS uses the same password to encrypt your files that it uses to decrypt them. But EFS uses an asymmetrical, public key-type encryption method to encrypt that password before storing it. When you encrypt a file, EFS uses your public key to encrypt the password and stores the encrypted password in NTFS 5.0 (NTFS5—which, unlike NTFS, knows how to store encrypted file passwords). When EFS needs to decrypt the file, it asks NTFS5 for the encrypted password and uses your private key to decrypt the password. After EFS has the password, it can decrypt the file. (As you've probably guessed, encrypting files slows things down a trifle.) But how does EFS let someone else decrypt a file? By again exploiting NTFS5: In addition to storing the file's password encrypted with your public key, EFS will store the password encrypted with the public key of as many recovery agents as you like.

Changing the default recovery agent gets sticky because introducing EFS to a prospective recovery agent's public key/private key pair requires a hierarchy of Certificate Authorities (CAs) that your computer recognizes. Without a CA hierarchy, you can't have certificates, and without certificates, you can't (with one exception, which I explain later) introduce EFS to new recovery agents. So, you'll need to run at least one certificate server.

In an Active Directory (AD) environment, adding new recovery agents isn't too hard to accomplish, although doing so requires some work: AD doesn't install a certificate hierarchy by default. In a standalone server environment, you could install a certificate server to act as a one-server hierarchy and use that certificate server to issue certificates. But on a standalone Win2K Professional system, you'd need to first create a CA on a system running Win2K Server and have the Win2K Pro system accept the certificates from the server. Then, you'd need to create the certificates and export them to the Win2K Pro system, which sounds like an awful lot of work. So, practically speaking, standalone Win2K Pro systems might have no option but to leave the default Administrator as the sole recovery agent.

But at least one account—the default Administrator—obtains a certificate without needing to go through the CA exercise. Apparently, EFS generates a self-signing certificate for the default Administrator, but I haven't been able to make EFS build certificates for other accounts. (Giving EFS a way to build certificates for other accounts would be a nice, low-overhead way to add some flexibility to EFS administration.)

Who Encrypted That File?
Another detail arises when you want to determine who encrypted a file. The Windows Explorer user interface (UI) shows which files are encrypted but not who encrypted them. You'd be annoyed to discover that someone had encrypted files in a public network share, leading to an influx of calls from users who suddenly can't access those files. And yes, that can happen: Anyone who has read and write permissions on a file can encrypt it.

As an administrator, you could rectify the situation by decrypting the files. But wouldn't you like to know the identity of the dastard who caused the trouble? You can, by using the Microsoft Windows 2000 Resource Kit Efsinfo command-line utility or Sysinternals' free EFSDump utility, which you can download from http:// www.sysinternals.com/misc.htm. If you run Efsinfo with the /u option, as in

efsinfo /u somefile.doc

the utility will tell you who encrypted the file. The /r option reveals the names of the people who can recover it.

The scenario in which a troublemaker encrypts a file on a network file share gave me a hint about a potentially valuable aspect of EFS. If you're storing a file in your home directory and don't want prying eyes to easily browse the file, encrypt it for more protection. It isn't likely that every member of the Domain Admins group is a recovery agent.

   Previous  [1]  2  Next