Windows Insider
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
- 03/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.”