EFS: Handle with Care

The Encrypting File System, while serving a need, can also cause big headaches—especially with the XP implementation. Here’s how to do it right.

• By Bill Boswell
• March 01, 2002

Most administrators are gadget-heads to some extent. We can appreciate new technology because it’s slick and solves a problem in an interesting fashion. Complexity doesn’t bother us too much. After all, we are Information Technology Wizards, right? But when it comes to deploying a complex technology into a network filled with irritable and occasionally hostile users, you sometimes find yourself pausing for a while to consider your options.

For example, you probably know that laptop theft has reached the point where the value of the data on the drive is often more appealing to a thief than value of the hardware. If the thought of your CFO’s laptop, with its store of financial projections and credit information, falling into the hands of organized crime doesn’t make you cringe, well, you’re probably in the wrong profession. You need a way to protect the data stored on that laptop from prying eyes.

Microsoft’s solution to this problem is the Encrypting File System (EFS). On its face, EFS looks fairly simple. All you need to do is set a single attribute in the file’s Properties window. Click Advanced in the General tab, then select Encrypt Contents to Secure Data. Figure 1 shows an example.

Figure 1. To encrypt, go through the file’s Properties | General | Advanced…menus.

Once you apply this change, the file is encrypted so thoroughly that only the user who encrypted it and a designated Administrator account can read it. But, it’s one thing to encrypt files and it’s quite another to keep sophisticated bad guys with a lot of time and resources from figuring out ways to decrypt them. So to get security, you have to accept some degree of complexity. As we’ll see, though, complexity can cause unexpected twists, especially when you introduce new variables such as an upgraded version of the operating system, a version that doesn’t want to play by the rules.

EFS Overview
Without spelunking too deeply into the caverns of file encryption, here’s a quick synopsis of the various locks and keys used to protect an encrypted file:

The file itself is encrypted using DESX, a variant of the now-defunct Data Encryption Standard. DESX is stronger than DES because the data is run through separate encryption cycles both before and after the DES encryption cycle. Windows .NET will let you use 3DES (Triple-DES) instead of DESX. 3DES is millions of times stronger than DES because data is run through the encryption engine three times.

DESX and 3DES both need a cipher key; for this purpose, EFS obtains a 128-bit random number generated by the Microsoft Base Crypto Provider. This is called the File Encryption Key. Protecting the FEK is vital because it must be stored with the file.

The FEK is encrypted using the public half of a public/private key pair. In public key technology, anything encrypted with the public key of a key pair can only be decrypted with the associated private key. Key pairs are assigned a specific purpose; in this case, the key pair can only be used for file encryption, so I’ll refer to them as EFS keys.

To protect the integrity of the encryption system, it’s important to limit access to the EFS private key. Microsoft protects private keys by encrypting them with a Session Key generated by the Data Protection API (DPAPI).

The Session Key isn’t stored on disk. It’s generated on the fly using the DPAPI Master Key as a cipher source. The Master Key is derived from the user’s password hash via a convoluted set of cryptographic operations. For details on the make-up of the DPAPI Master Key, see a Network Associates Inc. (NAI) white paper called Windows Data Protection at www.microsoft.com/serviceproviders/whitepapers/ security.asp.

The Master Key itself is encrypted using a cipher generated by a special type of hashing function that incorporates a secret key into the hash. In this case, the secret key is the user’s password hash.

So, when a user opens an encrypted file, the system takes the user’s password hash and uses it to decrypt the DPAPI Master Key, which is then used along with the user’s password hash to produce a Session Key, which decrypts the EFS Private Key that’s used to decrypt the File Encryption Key, which then decrypts the file. Phew!

The Key Point
If this seems like a lot of keys and keys to keys, you’re right—and we’re not done yet. We need a way to decrypt a user’s files if the user accidentally deletes the Private Key or Master Key. EFS allows for this possibility by including another copy of the FEK with the file. This copy is encrypted with a special File Recovery public key issued to the domain Administrator account. The EFS term for this account is a Data Recovery Agent, or DRA.

So, when a user encrypts a file, EFS needs a copy of the DRA’s public FR key. It obtains this key via Windows 2000 group policies—and that’s where the process starts to get, well, interesting. A public key can’t simply be transported around in bare form. How would you know that it was the genuine article? You want the key to come with a set of bona fides, as we say in southern New Mexico. Public key encryption provides these bona fides in the form of a certificate.

A certificate contains a digital signature that attests to the genuineness of a public key. By default, EFS certificates are self-signed, meaning that they were issued and digitally signed by the same service. This is like signing a check and filling out the signature card for the checking account at the same time. It doesn’t really prove anything. For maximum reliability, EFS can also use a central server, a Certification Authority (CA), to issue certificates. A CA is like a notary public. When a client generates a public/private key pair, it submits the public key to a CA, which validates the client’s identity and then issues a certificate for the key. If you trust the CA, you can trust any certificates issued by the CA. We’ll get back to the role of a CA in EFS in just a moment.

The certificate containing the FR public key issued to the domain Administrator account is automatically placed in the Default Domain group policy. It’s placed inside a policy called Encrypted Data Recovery Agent. You can see the certificate by opening the Domain Security console from the Administrative Tools menu at a domain controller. The policy is located under Computer Configuration | Windows Settings | Security Settings | Public Key Policies, as shown in Figure 2.

Figure 2. The domain Administrator, by default as shown here, is a Data Recovery Agent. (Click image to view larger version.)

When a Win2K desktop or server connects to the domain, it downloads this File Recovery certificate along with the other group policy files. It caches a copy of the FR certificate inside the local Registry under HKLM | Software | Policies | Microsoft | SystemCertificates | EFS | Certificates. (See Figure 3.)

Figure 3. The Local Machine Registry key contains a cached copy of the File Recovery Certificate. (Click image to view larger version.)

EFS uses the DRA’s public key to encrypt a copy of the FEK. This ensures that the domain Administrator account can access encrypted files if the user should ever lose the private key. This feature is so important that Win2K EFS will refuse to encrypt a file if there’s no DRA public key available from group policies.

Let Me ‘Splain
If you’re now saying to yourself, “This is cool technology, and I see the usefulness of it; but I want to hold off for a while until I figure this whole thing out,” then you may find yourself in the same position as Lucille Ball in the famous “I Love Lucy” episode where a line of chocolates piled up in front of her because she couldn’t find a way to turn the blasted conveyor belt off.

In Win2K, there’s no on\off switch for file encryption. The secret to disabling EFS is manipulating the DRA certificate stored in group policies. If you remove this certificate, Win2K clients will refuse to encrypt files. In practice, you would export the certificate to a file before you delete it so that, later on when you’re ready to deploy EFS, you can import it back.

XP and EFS
You may have noticed in the last paragraph that I kept saying “Win2K” clients. If you plan on deploying XP clients into a Win2K domain, you may be in for a surprise when it comes to file encryption. To keep from getting this surprise in your production environment, try a little lab experiment first.

Start by joining an XP Professional desktop and a Win2K desktop to a Windows domain. Check the Registry at the client to make sure the FR certificate is in the local policy cache. Encrypt a file at both machines.

Now use a little tool from the Resource Kit called Efsinfo to list the identity of the person who encrypted the file. That would be your account, of course. Use efsinfo /r to show the identity of the DRA. That will be the Administrator account in the domain.

Now disable file encryption by removing the FR certificate from the Encrypted Data Recovery Agents group policy. Restart the desktops to refresh the computer policies (as an alternative, you can run secedit /refreshpolicy machine_policy at the Win2K desktop. At the XP desktop, you can run gpresult /target:computer).

Now attempt to encrypt a file at both desktops. At the Win2K desktop, you’ll get an Access Denied error because no DRA is available. At the XP desktop, though, the transaction proceeds without a hiccup. If you run Efsinfo, you’ll get an interesting result. Figure 4 shows an example. An efsinfo /r listing for the second encrypted file shows “No Recovery Agent Found.” Yet the file is still encrypted, which leaves you to hum a variation on an old Carl Perkins tune, called “Honey Don’t,” and ask the desktop why it still encrypts files even though it says that it won’t, or at least it shouldn’t.

Figure 4. On an XP machine, unlike Windows 2000, you can encrypt a file even without a Recovery Agent.

Be Careful Out There
The reason for this seemingly wrong-headed behavior has to do with the fact that XP was designed to work in a Windows .NET domain environment; in Windows .NET, Microsoft changed the way a CA handles certificates. (Complexity acts like a rabbit. Put two complex systems together and, before you know it, you’re surrounded by even more complexity.)

A Windows .NET CA is capable of storing EFS private keys as well as public keys. This eliminates the need for a DRA. If a user accidentally deletes an EFS private key, you can use a Windows .NET CA to issue another. For this reason, XP desktops will, by default, permit file encryption without a DRA.

Fine, you may say, but it’ll be quite a while before we upgrade our Active Directory domain to Windows .NET, possibly even longer before we deploy a set of .NET Certification Authorities, and even longer still before we trust that new-fangled private key recovery feature. In the meantime, we want to start deploying XP desktops and laptops. Well, when you do deploy those XP machines, each one happily lets its user encrypt files even though you have removed the FR certificate from the Encrypted Data Recovery Agent group policy with the express intent of blocking file encryption in your domain. And because there’s no DRA, the simple loss of a local profile will result in a complete loss of access to all the encrypted files on the machine.

The Best Defense…
Your only defense in this situation is a good offense. It turns out that XP clients look for a new group policy in Windows.NET called “EFSConfiguration.” If this policy is set to Disabled, meaning that its value is set to 1 in the Policies section of the local Registry, XP desktops will refuse to encrypt files. Win2K group policies don’t include an EFSConfiguration policy setting, so you must create it yourself.

To create a custom group policy, build a small text file in the \Windows\Inf folder of the machine you use to manage group policies in your Win2K domain. If this is your workstation, create the file in the \Windows\Inf at your workstation. (For a great explanation of how to create custom policies, get the book Windows 2000: Group Policy, Profiles, and IntelliMirror by MCP Contributing Editor Jeremy Moskowitz.) You can name the text file anything you like as long as it has an ADM extension. For example, call it Efs.adm. The contents should look like this:

CLASS MACHINE
CATEGORY "Special EFS Handling"
POLICY "Disable XP and .NET EFS"
#if version >= 4
SUPPORTED "At least Microsoft Windows XP Professional"
#endif
KEYNAME "Software\Policies\Microsoft\WindowsNT\CurrentVersion\Efs"
EXPLAIN "This policy stops XP desktops from encrypting files in a Win2K domain. Enable the policy to disable EFS."
VALUENAME "EfsConfiguration"
VALUEON NUMERIC 1
VALUEOFF NUMERIC 0
END POLICY
END CATEGORY

Once you’ve created the ADM file, load it into the Default Domain group policy by right-clicking the Administrative Templates icon under Computer Configuration and selecting Add/Remove Templates from the fly-out menu. Your file will be on the pick list. Double-click the file name to load it. You will see the new Category listing directly under the Administrative Templates icon. If you get a syntax error, unload the template and check the file for typos.

Enable the new policy then verify that it takes effect by restarting the XP desktop (or running gpresult /target:computer), then trying to encrypt a file. You should get an “Access Denied” error, indicating that the desktop has obtained the new group policy and applied it to the local Registry. The policy will remain in effect even when the laptop is off the network.

EFS: Good, but Caveat Emptor
I hope I haven’t left you with the impression that EFS is something to be avoided. It’s a reliable technology that addresses a very real problem. It just takes a little planning to make sure you can deal with the complexities. If you take your time and do it right, you’ll be humming another Carl Perkins tune—“Everybody’s Trying To Be My Baby.”