Partager via

Data Recovery and Encrypting File System (EFS)

  • Article

By Alun Jones, Microsoft Security MVP

See other Security MVP Article of the Month columns.

So, you finally did it. You checked the box to enable Encrypting File System (EFS) on that file that contains your sensitive business information. Maybe it has your customers’ bank account numbers, their medical information, or the super-confidential plan for your company to dominate its marketplace. Whatever the file's content, you and the business decided it was worth trying to protect.

But now you have that nagging worry in the back of your mind—what guarantee is there that you'll be able to unlock the file again? Are you certain to get your data back? Perhaps you're recalling an occasion when you lost the key to a padlock and had to break the lock to get back in. Will this be a similar experience?

It is a fact of our technological age that often there is the need for data recovery when the person who originally encrypted the data either can't or won’t retrieve it for you. Maybe they are out of the country, or away indefinitely on sick leave, or perhaps they have left your company on bad terms and you are unwilling to trust them to recover their own files. Or maybe you are trying to recover files during an investigation into a user’s current behavior, and you don’t wish to make your scrutiny obvious by asking the user for decrypted copies of their files.

There are clearly various good reasons why you want to be certain that you can assure data recovery while also protecting your data from unauthorized access. This article provides a quick overview of some of the things you need to do in order to successfully use EFS. You’ll learn about the policies and procedures that you should implement, how to prepare your data recovery agents, and how to perform backup and restore operations.

Policies and Procedures

Policies and procedures are as important to a good data recovery plan as are the technical capabilities of your operating system. You should plan for every possible reason for which a user might request data, and then you should document which of these reasons is worth pursuing on the Service Desk’s time. You should also document a clear policy regarding who must provide approval for a recovery, whether it is the user or the user’s management chain if the user is absent, and then you should document who is allowed to declare an exception to this policy.

You might want to have more than one data recovery agent (DRA), classed either by purpose or by organizational unit. Classed by purpose, you might want one recovery agent to use when you carry out forensic investigations, one to use when you decrypt files prior to offline storage, and one for the Service Desk to use when they recover files for users who have somehow lost their file encryption keys. Classed by organizational unit, you might want different recovery agents at various branches within the organization, so that designated branch employees can recover files locally to them.

Again, set up appropriate human processes, policies, and procedures before you have to recover any data, so that everyone involved knows what an appropriate request for recovery looks like, what approvals might be needed for such a request, and from which members of management or other staff those approvals might be required. Set service level agreements to determine whether data is to be recovered on a priority basis, or in an appropriate “batch” at regular time intervals.

Make sure you have a well-documented disaster recovery procedure. No matter how well you secure your physical facilities, if they are flooded, burned out, or sucked into a crack in the earth, someone on the disaster recovery team will still need to restore the data. A disaster recovery procedure is only good if it has been tested—recently—by people who are unconnected with drafting its documentation. Plan at least an annual disaster recovery test on real data; try to execute your recovery procedure. This means including the execution of your procedure—including staff salaries, equipment, and site rental—as part of your operating budget. After your test, verify the expected results of your procedure, document everything that didn’t recover correctly, and then, if necessary revise your procedure.

Preparing to Succeed

Getting keyed up

A first note about preparation: before your users first encrypt a file, you should ask yourself where the users’ encryption keys will come from. If you don’t take any action at all, the encryption keys will be generated randomly by each user when they first encrypt a file, so that each user has a self-signed certificate and an associated private key. This is not ideal for many organizations, because these keys and certificates are decentralized and are difficult to administer and back up.

A far better solution is to create a Windows enterprise certification authority (CA) in your domain, and to configure certificate templates for EFS certificates, along with an auto-enrollment policy. Auto-enrolled certificates allow for centralized management of users’ certificates, along with the possibility of private key archival, which reduces the reliance on data recovery agents as your sole point of recovery.

Note: Every EFS-protected file is encrypted using a randomly-generated key and a symmetric encryption algorithm (this means a method of encryption that uses the same key to decrypt as it does to encrypt). That symmetric key is then encrypted and stored once for each user (and data recovery agent) who has access to the file, using the public key of that user. This means that the operating system, acting on behalf of a user can use the user’s private key to decrypt the file’s symmetric key, and use the symmetric key to decrypt the file.

Data recovery agents

Data recovery requires preparation. Fortunately, EFS in Windows comes by default with just such preparation built in, by requiring a data recovery agent for each encrypted file. Every time you encrypt a file, Windows allows either of two keys to be used to decrypt the file again later. One of the keys belongs to the user who encrypts the file, so that the user can access the file again later. The other key belongs to the data recovery agent, and as with the user’s key, the data recovery agent’s key and certificate can be created by administrators’ actions, or will be created on first use.

By default, the data recovery agent is defined to be the administrator account. On stand-alone workstations and workgroup machines, the administrator account is the local administrator; on domain-joined machines, the administrator account is the first domain controller’s administrator account.

This is where your own preparation comes in. You will want to make sure that the private key for the data recovery agent is not available online – that is, that the key is stored on a system that is powered up and running, connected to your workgroup or domain. The data recovery agent’s key should be moved offline and kept on removable media, to ensure that it is only available for use when a recovery process is initiated. You might be tempted to simply assign some other account as the default recovery agent, but that doesn’t solve the base problem, which is that a rarely-used private key for an important operation is online.

Exporting and deleting a private key

Exporting and deleting the private key for a data recovery agent (or any other user) is a relatively simple process. Use the following steps:

  1. Log on to a workstation within your workgroup / domain as the user account for the data recovery agent.

  2. Open the Microsoft Management Console Certificates snap-in. I like to do this by running Certmgr.msc. You can also follow these steps:

    1. Run MMC.exe

    2. On the File menu, click Add/Remove Snap-in.

    3. In the Add/Remove Snap-in dialog box, click the Add button.

    4. Click Certificates in the list of available snap-ins, and then click the Add button.

    5. In the Certificates snap-in dialog box, select My user account, and then click Finish.

    6. Click Close and then click OK to close the other dialog boxes.

  3. In the Console Root tree, open Certificates – Current User, open Personal, and then open the Certificates folder.

  4. In the list of certificates that are displayed in the right pane, select the certificate that has the user name for the data recovery agent in both the Issued To and Issued By columns. When these two columns are the same, it almost always indicates that the certificate is a “self-signed certificate.” Verify that the Intended Purposes column reads “Encrypting File System,” as in the example in the following figure.

    Figure 1

    Figure 1: Exporting the Encrypting File System key

  5. Right-click the certificate that you want to export, point to All Tasks, and then click Export, as shown in Figure 1. The Certificate Export Wizard opens.

  6. Read the explanatory text on the first page of the wizard, and then click Next.

  7. On the next page of the wizard, under Do you want to export the private key with the certificate?, select Yes, export the private key. This is important, because the private key is what you want to back up and delete in this process. Click Next.

    Figure 2

    Figure 2: Choosing to export the private key

  8. On the next page of the wizard, you must select a format to export to. If you correctly chose to export the private key for the certificate, you will be given one choice only, Personal Information Exchange. This file format is also known as a .pfx or PKCS#12 file. There are three check boxes available for selection with this format, as shown in the following figure.

    Figure 3

    Figure 3: Deleting the private key after export

    The first check box is irrelevant; because the certificate you are exporting is self-signed, it contains all of its own certification path. However, you should always select the second check box, Enable strong protection, when you export to a .pfx file. You should also select the third check box, Delete the private key if the export is successful, so that after you export to the .pfx file, the private key for the data recovery agent will be deleted from the online certificate store. This does prevent decryption from being possible later by using the data recovery agent private key, but does not prevent encryption with that same certificate.

    Note: When you export a user’s private key and certificate, do not delete the private key after export, or the user will no longer be able to read files that they encrypted by using that certificate. While a data recovery agent will typically be used for decryption only rarely, most users will be encrypting and decrypting their EFS files over and over as a matter of daily routine.

  9. Click Next, and then type and confirm the password with which you want the .pfx file to be encrypted:

    Figure 4

    Figure 4: Entering a strong password for the exported file

  10. Click Next, and then enter a path and name with which to save the .pfx file.

  11. Click Next, verify that the summary of operations matches what you chose, and then click Finish to export your EFS certificate and private key to the .pfx file.

  12. Store the .pfx file securely. Maintain good records about the password that is associated with the .pfx file (ideally, in a different location from the .pfx file itself).

  13. Make sure that you have an appropriate process in place for approving the release of the .pfx file and the password, for when you want to import the data recovery agent private key so that you can recover encrypted documents without using the user's private key.

Why would you want to export a user’s certificate and private key? In domain environments prior to Windows 2000, a password reset by the service desk prevents users from accessing their certificates, because they are encrypted using a key chain that starts with the user’s password. While this is no longer true in current domain environments, it is still appropriate for technical users to keep a backup of their keys and certificates.

Giving additional users access to an encrypted file

The data recovery agent is the primary means of EFS data recovery. Of course, adding users to access a file may be another way to ensure that you can retrieve the file's contents when the primary user is absent.

What’s the difference? Technically, none. As noted earlier, each user and data recovery agent has a public key that can be used to encrypt the file’s encryption key; likewise, each user or the data recovery agent can decrypt the file using their associated private key to decrypt the file’s encryption key. Administratively, though, there’s a huge difference. Use of the data recovery agent’s account to recover a file is an administrative function, and is designed for infrequent use when recovering files that would otherwise be lost. A data recovery agent is assigned to a file administratively, through the Encrypting File System Policy, and when this policy is set, it is enforced on the encrypted file.

By comparison, adding additional users to a file is considered a user function. A user is expected to access their own files on a regular basis, without administrative overhead or procedural involvement. As such, that user may want to add someone else, such as a manager or administrative assistant, to the files that they encrypt, so that those additional users can also access the encrypted files as a normal part of their daily work.

Any user who has access to decrypt an EFS file, and who can also write to the file, can add other users’ public keys to access the file – there is no concept in EFS of a special user who controls which users may be added to, or removed from, access to the file. This allows for a file to be made available to a limited number of people. Sadly, there is no way to assign keys to a file from a group of users. Each user’s public key must be accessed individually, either from the local certificate store, or from the Active Directory directory service, to add the user to the file. From a cryptographic perspective, this is a necessary restriction, but it can be irritating if you want to restrict a file to a group of users. Don’t forget that NTFS file system protection may be sufficient for files that are accessible to a group. Not every file requires encryption by using EFS.

Changing your EFS policy

A domain administrator or enterprise administrator (or the local administrator on a stand-alone or workgroup computer) can remove any or all data recovery agents from the Encrypting File System Policy. However, I strongly discourage you from removing all recovery agents, because doing so will guarantee that you will lose data whenever the owner of an encrypted file leaves your company, or when a user's passwords or accounts are disabled or removed.

Adding data recovery agents to the Encrypting File System Policy may be necessary as your company grows, but you should remember that changing the Encrypting File System Policy has no effect on existing files. Changes will occur only to files that are created or modified under the new policy. You should keep your data recovery agent .pfx files as long as the EFS files exist for which that data recovery agent was used.

Backup and Restore

Because you can’t recover files that you don’t have at least in an encrypted form, make sure that your regular backup software will store the raw, encrypted version of files that are encrypted by using EFS. Most commercial backup products will do this, as will the Windows Backup or Restore Wizard (NTBackup.exe), but it’s worth checking the capabilities of your software. When software requests to open a file that was encrypted by using EFS from an account that does not have a private key associated with that file, access is denied. Your backup software needs to check specifically for files that were encrypted by using EFS, or the files will simply not be backed up.

Don’t ignore the simplest way of providing for data recovery—keeping a clear-text backup of important files, locked in a vault, a safe, or just a locked filing cabinet, depending on the security of the data concerned. Obviously, this requires the cooperation of the file owner, so it should not be treated as a replacement for a good data recovery agent policy.

As always, your backup tool isn’t completely tested if you haven’t tested the process of restoring your backups, so test that you can back up an encrypted file, and also that you can restore the file in both cases, whether the owner of the file is still available to you or whether you need to use a data recovery agent to recover the file.

This brings me neatly to another step that you can take to provide secured data recovery—having a “central recovery console,” a computer at which a data recovery agent is allowed to log on, restore data from backups, and then decrypt files. By restricting the recovery agent to log on only at this workstation, and by placing the workstation in a physically secured area, you can ensure that data recovery is limited to only those occasions that are covered by your data recovery policies and procedures.

Summary

EFS can seem scary at first, and it is true that if you are careless, you can encrypt your files away so that they can never be brought back. However, I hope that in this article I have reassured you that a little care and preparation will ensure that your files will be available to authorized users when they need them, and will be unavailable to everyone else. And that is the whole point of protecting your files by using EFS, isn’t it?

Further Reading

Following are a few links to sites that go into more detail about data recovery and the Encrypting File System.