Decrypting EFS

Encrypting File System is more complex than it appears

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 

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.

Inadvertent Decryption
More devilish details concern copying, editing, backing up, and recovering encrypted files: Can any of those actions inadvertently decrypt a file? And does encryption interfere with backing up a file?

Before I go further, let me say that encrypting entire folders, rather than particular files, is a good idea, particularly if you're encrypting files that you've used simple applications to produce. Many simple text editors, word processors, and spreadsheets never actually "save as" when you tell them to Save As. For example, in many editors, if you edit a file named stuff.txt and tell the editor to save the file, the editor takes several steps. First, the editor renames the old stuff.txt file—for example, to stuff.$$$. Then, the editor saves the revised stuff.txt to disk as a new file. Finally, the editor deletes the renamed file, stuff.$$$, or changes its extension (e.g., to .bak). Thus, if a problem occurs in the middle of saving the file, the editor can retrieve the original file (i.e., stuff.$$$).

This multistep approach to saving files is good belt-and-suspenders programming. But if you encrypt stuff.txt, then later edit it and save changes, the editor eliminates the original stuff.txt, so EFS figures that its job is done and doesn't encrypt the revised stuff.txt file. Not all applications exhibit this behavior, but many do. When you encrypt the entire folder rather than only the file, EFS encrypts everything you store in the folder and your files remain encrypted no matter how your application saves them.

If you copy an encrypted file to another NTFS5 volume, NTFS5 encrypts the copy as well, even if the volume is across the network. Of course, if you copy the file to a floppy disk, a FAT drive, or some other non-NTFS5 drive, the copy isn't encrypted. (However, only you can copy a file you've encrypted, so another user can't decrypt your file by copying and then reading the decrypted copy.) If you're using Offline Files on your workstation and you cache an encrypted file, the copy in your local cache isn't encrypted. (Offline Files warns you before it caches an encrypted file.) I haven't figured out a way to encrypt winntcsc, so you might want to make an administrative decision to disallow caching on shares that contain encrypted data.

Assuming that you're an administrator (and so have backup and restore rights), you can back up and restore encrypted files. The backup or restore routine simply copies the encrypted bits to or from the backup medium.

Beyond the Basics
This information will start you off learning your way around the basics of administering systems with EFS, but you still have lots more to learn. (See "Related Articles in Previous Issues" for more EFS-related information.) Do yourself a favor and try a bit of encryption, backup, restoration, and recovery on a file or two now, before a user presents you with an encryption-related problem.