Windows Server Hack [Electronic resources] نسخه متنی

Hack 94 Back Up EFS

Backing up EFS recovery keys is essential if
you want to be able to recover encrypted documents after a disaster.

The Encrypting File System (EFS) lets you
encrypt files so that unauthorized individuals can't
read them. Normally, this is a good thing, because it helps secure
data stored on a machine's hard drive. However, this
hack is concerned with what happens when something goes
wrongfor example, if a user's machine becomes
toast, taking their EFS private key and certificate to Never-Never
Land.

The key to being able to recover encrypted files when something goes
wrong is having a designated recovery agent already in place. Then,
if you lose your EFS private key, the recovery agent can decrypt your
encrypted files in an emergency. Every time you encrypt a file, EFS
generates a unique File Encryption Key (FEK) that it uses to encrypt
only that file. In other words, each encrypted file has its own
unique FEK. In addition, the FEK is itself encrypted by using your
own EFS public key and incorporated into the header of the file.
Later, if you want to read the encrypted file, EFS automatically uses
your EFS private key to decrypt the FEK for the file and then uses
the FEK to decrypt the file itself. The FEK is thus used for both
encrypting and decrypting the file (a process known as
symmetric encryption), while your EFS
public/private key pair is used for encrypting and decrypting the FEK
(known as asymmetric encryption). This
combination of symmetric (or secret-key)
encryption and asymmetric (public-key)
encryption is the basis of how EFS works.

But what happens if you lose your EFS private key? This might happen
if your machine has two drives: a system drive
(C:) and a data drive
(D:), where encrypted files
are stored. By default, your EFS keys are stored on your system
drive, so if C: becomes corrupted, then the
encrypted files on D: will be inaccessible,
right? That's where the recovery agent comes in.
Each time you encrypt a file, the FEK is encrypted with both your own
EFS public key and the EFS public key of the recovery agent. That
means that the recovery agent can always decrypt the FEK by using its
EFS private key and thus decrypt the file when something goes wrong
and your own private key is lost or corrupt.

What are these recovery agents? By default, on standalone Windows
2000 machines, the built-in local administrator account is designated
as a recovery agent, so you can always log on as administrator and
decrypt any encrypted files stored on the machine. You can add other
users as recovery agents by using the Local Security Policy console,
which you can open by using
StartRunsecpol.msc.
Then, expand Security SettingsPublic Key
PoliciesEncrypted Data Recovery Agents, right-click
on that node, and select Add to start the Add Recovery Agent Wizard.
Any user accounts that already have X.509v3 certificates on the
machine can then be added as recovery agents.

On standalone Windows Server 2003 machines, the built-in administrator account is not a designated recovery agent. In fact, there are no default recovery agents in Windows Server 2003 in a workgroup environment. You must designate an account for this role.

In a domain environment, things are a little different. The built-in
domain administrator account is the default recovery agent for all
machines in the domain, and you can specify additional recovery
agents by using Group Policy. Open the Group Policy Object (GPO) for
the domain, OU, or site in which the intended recovery agent account
resides, and navigate to Computer
ConfigurationWindows
SettingsSecurity SettingsPublic
Key PoliciesEncrypted Data Recovery Agents.
Right-click on this node and select Add to start the same Add
Recovery Agent Wizard as before, but this time browse the directory
to locate the account you want to add.

Once Group Policy refreshes, your new recovery agent will be able to
decrypt files encrypted by other users, but only if the users encrypt
the file after the new recovery agent was designated. This is because
files encrypted previously have no information about this new
recovery agent in their headers and therefore can't
be decrypted yet by the new recovery agent. Fortunately, if the user
who encrypted a file simply opens and then closes the file, this
alone is sufficient for EFS to add the new recovery agent to the
encrypted file's header. The moral of the story is
that you should think before you implement EFS, and designate
recovery agents before you allow users to start encrypting files.
Otherwise, you might find yourself sending out an unusual email to
everyone saying, "Please open and then close all
files you have encrypted on your machines" or
something similar.

Backing Up Encrypted Data and EFS Keys

Backing up files that have been encrypted using EFS is easy: simply
use the Backup utility to back them up like any other files you would
back up. What's really important is that you also
back up the EFS certificate and public/private key pair for each user
who stores data on the machine. Since EFS is implemented on a
per-user basis, this means you have to back up this information for
each user individually. However, this information is stored in the
user profile for each user, which means that simply by backing up
user profiles you also back up their EFS certificate and keys. More
specifically, a user's EFS private key is stored in
the \Application Data\Microsoft\Crypto\RSA
subfolder within that user's profile,
while the user's EFS public key certificate and
public key are stored in the \Application
Data\Microsoft\SystemCertificates\My Certificates\My
folder under the subfolders \Certificates and
\Keys.

You can back up users' EFS certificates and key
pairs as part of your regular backup program and, if you have roaming
user profiles configured, you can do this centrally from the file
server where such profiles are stored. If you don't
have roaming profiles implemented and users store important documents
on their own machines, it might be necessary to have users back up
their own profiles locally by using Backup to back up to file instead
of tape. Unfortunately, this guards against profile corruption only,
and it might not help if a disk failure causes the backed-up profile
to be lost as well. A better alternative is to have users export
their EFS certificate and private key to a floppy and have them store
it somewhere safe. That way, if their system drive crashes, they can
still decrypt information on their data drive by importing their
previously exported EFS certificate and private key.

The steps to export a user's EFS certificate and
private key are fortunately quite straightforward and can be done
easily by any user. Simply open Internet Explorer, select
ToolsInternet Options, switch to the Content tab,
click the Certificates button, and select the Personal tab, as shown
in Figure 10-5.

Figure 10-5. Exporting the EFS certificate and private key for user jsmith

Then, select the certificate you want to export (the correct
certificate will display "Encrypting File
System" beneath "Certificate
intended purposes," near the bottom of the
properties page) and click Export to begin the Certificate Export
Wizard. Choose the option to include the user's
private key in the export (the public key is automatically included
in the certificate), specify a password to protect your export file,
and choose a name and destination for your export file. As mentioned
previously, users will typically export their EFS keys to a floppy,
but you could burn them to a CD or even store them on a secure
network share if you prefer. The important thing is, wherever you
export this information, keep it safe so that no one except the user
and trusted administrators can access it. Anyone who gets their hands
on the export file and cracks the password can use it to decrypt any
encrypted files they have access to.

The result of this export process will be a *.pfx
file (called a Personal Information Exchange
file), located in the target folder or media. Then, if the
user's EFS keys later become corrupted and the need
arises to reinstall these keys, this can be done either by repeating
the previous process (but clicking Import instead of Export in Figure 10-5) or more simply by double-clicking on the
.pfx file itself to start the Certificate Import
Wizard. This wizard is smart enough to figure out that the EFS
certificate and private key stored in the .pfx
file should be imported into the user's
personal certificate store.

An interesting option to consider when exporting a
user's EFS certificate and private key is to delete
the user's private key from his profile during the
process. This option is labeled "Delete the private
key if the export is successful" and is found on the
penultimate page of the Certificate Export Wizard. If you choose this
option, you'll be able to encrypt files by using
EFS, but you won't be able to decrypt them unless
you supply the private key on some mediumsomething that might
be an option to consider in a high security environment.

Restoring EFS Keys

If a user's EFS private key becomes
corrupted or lost and the user
hasn't backed up the key to a floppy as described in
the previous section, then it's time for the
recovery agent to step in. On a standalone machine, you can simply
log on using the built-in administrator account, locate the encrypted
folders the user can no longer access in Windows Explorer,
right-click on each folder, select Properties, click Advanced, and
clear the "Encrypt contents to secure
data" checkbox for each folder. This decrypts the
files within the folders and enables the user to read them again.

In a domain environment, you typically don't want to
log on to a user's machine as a domain administrator
and see a local user profile being created for your account as a
result. Instead, simply instruct the user to use the Backup utility
to back up to file any encrypted volumes or folders on her machine.
The resulting backup file (*.bkf file) processes
files it backs up as a data stream and preserves their encrypted
status. Then, have the user copy her .bkf file
to a network share where you as domain administrator can access the
backup file, restore it to another folder, decrypt any files the user
needs, and copy these files to the share where the user can access
them.

While this is the most common solution, there's
another approach that's worth considering: unite the
user with his EFS keys again. Even if the user
hasn't previously exported his keys to a floppy for
safekeeping, chances are, in a domain environment, that you make
regular backups of user's profiles (assuming roaming
profiles are enabled). By simply restoring a user's
profile from backup you restore his EFS certificate and keys,
allowing him to read his encrypted files again. Then, tell him
politely but firmly to immediately export his certificate and keys to
a floppy, because you don't want to have to go
through this again!

If EFS is being used to encrypt files on a file server where multiple
users store their files, then this process can be complicated if
you've designated different recovery agents for
different groups of users. In particular, you might need to determine
which recovery agents are designated for any encrypted files that
users can no longer access. To do this, you can use the
efsinfo command-line utility included in the
Windows 2000 Server Resource Kit. This handy little utility can tell
you who originally encrypted a file and who the designated recovery
agents for the file are. Just type efsinfo
/r /u filename, where
filename includes the path to the
encrypted file. Once you know any recovery agent for the file, you
can proceed to decrypt it as shown previously.

What if the individual who can't access her
encrypted files is your boss and she needs access to her files
immediately? Export your own EFS certificate and private key to
floppy as a domain administrator or other recovery agent, walk the
floppy over to your boss's office, insert the floppy
into her machine, import the certificate and private key, and decrypt
her files. Then, delete the certificate and key from her machine.
When she tries to encrypt a file again, a new EFS certificate and
private key will automatically be generated. Smile, because
you've acted like Superman, and send her an email
later asking for a raise.

But what if your own EFS certificate and private key as domain
administrator or recovery agent is lost or corrupt?

Backing Up Recovery Agent Keys

Obviously, it's a good idea
for administrators and other recovery
agents to also make backup copies of their own EFS certificates and
private keys. Otherwise, a point of failure exists in this whole
recovery process and users' encrypted files could be
lost forever and unrecoverable.

If you're operating in a workgroup environment,
recall that the built-in local administrator account is the default
recovery agent in Windows 2000. This means you have to back up the
EFS certificate and private key of the administrator account, so log
on to the machine using this account and use
StartRunsecpol
to open Local Security Policy as before. Select the Encrypted Data
Recovery Agents node under Public Key Policies in the left pane,
right-click the EFS certificate in the right pane, and select All
TasksExport to start the Certificate Export Wizard.
Choose the option to export the private key as well, specify a
password to protect the export file, and specify a name and
destination for exporting the informationtypically, some form
of removable media, such as a floppy. Keep that floppy safe.

In a domain environment, the built-in domain administrator account is
the default recovery agent and the EFS certificate and private key
are located on the first domain controller in the domain (the one
that created the domain when you ran dcpromo on
it). Log onto this machine using that account, use
StartRundompol.msc
to open the Domain Security Policy, select Encrypted Data Recovery
Agents in the left pane, right-click the EFS certificate in the right
pane, again select All TasksExport to start the
Certificate Export Wizard, and proceed as before. If you are not
given the option to export the private key, you might not be logged
onto the right domain controller, so change machines and try again.

Another method for exporting certificates and keys is to use the
Certificates snap-in. Open a blank MMC console, add this snap-in
while logged on as administrator, expand Certificates - Current
UserPersonalCertificates, and
find the certificate you want to back up by looking under the
Intended Purposes column, as shown in Figure 10-6.
The power of this approach is that you can also use it to back up and
restore other sorts of certificates and keys, including EFS keys.

Figure 10-6. Using the Certificates snap-in to back up a recovery agent key

Now that you've backed up your recovery
agent's EFS certificate and keys,
you're ready for the worstunless your dog
eats your floppy!