Chapter 13: Using Encrypting File System

Microsoft introduced Encrypting File System (EFS) with Windows 2000, and has steadily improved it in its later operating systems. It provides strong, reliable, seamless encryption. When enabled, users can encrypt and decrypt files and folders as desired. EFS-protected files are encapsulated by open, industry-standard encryption ciphers. It's solid security. If the user's EFS decryption key is lost, and no backup or recovery precautions were taken beforehand, it can be difficult to impossible to recover the protected files. This chapter covers how EFS works, how it should be set up, cautionary tales, and best practices.

How EFS Works

EFS requires Windows 2000 or later with NTFS disk volumes and uses both symmetric and asymmetric cipher algorithms. It is globally enabled by default, meaning that any user can encrypt any file or folder at any time simply by choosing to enable it. Files and folders must be individually selected for encryption, although normal inheritance rules apply.

Note 

EFS is not supported within XP Home.

Encrypting a File

To disable or enable EFS globally in group policy, choose Computer Configuration\Windows Settings\Security Settings\Public Key Policies and right-click the Encrypting File System leaf, select Properties, and enable or remove the Allow users to encrypt files using EFS check box. It can also be enabled or disabled using the registry key HKLM\SOFTWARE\Policies\ Microsoft\WindowsNT\CurrentVersion\EFS\EfsConfiguration or HKLM\SOFTWARE\ Microsoft\WindowsNT\CurrentVersion\EFS\EfsConfiguration. A DWord value of 1 will disable EFS; a value of 0 will enable EFS. EFS is globally enabled by default.

To encrypt a file or folder, a user simply right-clicks the object in Windows Explorer, chooses the Properties option under the General tab, clicks the Advanced button, and enables the Encrypt contents to secure data option (see Figure 13-1).

Figure 13-1

Note 

Why Microsoft did not put the EFS option under the main Security tab under File Properties along with all the other file security settings is a mystery.

If a file in a subfolder is selected for encryption, Windows will prompt the user to decide whether to encrypt only the selected file or to encrypt all files in the current folder. Even when the user decides to encrypt all files (current and future) in the folder, EFS encrypts each file individually and uses separate file encryption keys. If the file contains multiple data streams (i.e., alternate data streams), all data streams will be encrypted, but not the file's attributes.

EFS can be used to encrypt almost any Windows file or folder, but Microsoft made some important exceptions. EFS cannot encrypt the following:

• User profiles, because that is where the user's EFS keys are stored

• Windows system and root files, because doing so would also encrypt the files needed to use EFS

• Any file with the system attribute set, including Hiberfil.sys and the pagefile

• Files compressed using Windows NTFS compression

• Files stored on FAT volumes

• Drive mount or reparse points

Note 

EFS-protected files are not indexed by the Content Indexing Service to prevent accidental data leakage.

When files are being encrypted, Windows creates a temporary log file called Efs0.log in the System Volume Information folder on the same drive as the encrypted file. The zero in the file name may be incremented (e.g., Efs1.log) until the file name is unique. Microsoft uses the log file to keep track of the status of the current or pending EFS transactions. In the event of a crash, EFS will use the log to remove any uncompleted transactions.

Another temporary file called Efs0.tmp (or incremented to any unique file name like the log file) is created in the same folder as the file being encrypted. The contents of the original plaintext file are copied into the temporary file, after which the original plaintext file is overwritten with the new encrypted data. When EFS is finished encrypting the file, the log and temporary files are erased. In older versions of EFS, when the EFS temporary file was deleted, the original plaintext from the temporary file was left on disk, which could allow data leakage or discovery. This problem can be minimized by always encrypting entire folders, instead of individual files. You can also use the Cipher.exe utility to wipe all free space of any plaintext data left behind by EFS encryption.

Encrypted file names are green when viewed in Windows Explorer. This is a view attribute that can be turned on and off by choosing Tools ð Folder Options ð View, and enabling or disabling Show encrypted or compressed NTFS files in color in Windows Explorer.

Alternative EFS Methods

One or more files can be encrypted at once by using the command-line Cipher.exe utility. Cipher.exe can participate in over a dozen cryptographic tasks, including many involving EFS. To encrypt multiple files at once, use Cipher's /E parameter. To turn off EFS on one or more files, use its /D parameter. You can also use Cipher without any command-line parameters to show existing EFS files.

Some organizations may find it easier to enable EFS by placing Encrypt and Decrypt on the Windows Explorer context menu when a file is right-clicked with the mouse. To enable this feature, create a DWORD value of 1 for EncryptionContextMenu (which you will have to create) under HKLM\Software\ Microsoft\Windows\CurrentVersion\Explorer\Advanced.

Decrypting Files

One of the most beautiful things about EFS is how transparently the decryption works. If a logged on authorized user opens the file, EFS decrypts the file on the fly into its clear-text representation. If the user copies the file over the network, sends it in an e-mail, or copies it to a non-NTFS partition, the file decrypts transparently. This also means that if intruders can log on as the user or data recovery agent, they can also access the files in their unprotected state. This last point is a big potential weakness.

If the user copies the file to another NTFS partition, or if the file is backed up to an NTFS-aware tape drive, the encryption remains with the file. If an intruder boots around Windows to access the encrypted files without the user's password, they remain encrypted. If the authorized user copies or moves an EFS-protected file from an encrypted folder to an unencrypted folder on the same volume, the file remains encrypted. However, if the user copies or moves an unencrypted file into an encrypted folder, the file will be encrypted.

File Security and EFS

The security mechanisms that determine whether a user can access or modify a particular file are completely separate from EFS mechanisms. This has many repercussions. First, a user must have Read and Modify (or Write, or Change in the Share) permissions to encrypt a file. Second, if multiple users can modify a file prior to EFS being implemented on the file, the first user to encrypt effectively prevents all others from being able to read or modify the file, unless EFS file-sharing is enabled. Third, the file names of encrypted files can still be seen and viewed by other users that have Read or List access to the protected file(s). This is a potential information leakage problem that can only be remedied by removing the unauthorized user's Read and List permissions.

Lastly, even when only one user has the capability to encrypt a file, any user with Modify (or Write) permissions can delete it. While this may be surprising to those new to computer security, EFS is encryption software, not integrity software. Encryption prevents unauthorized users from being able to read, print, extract, copy, or move a file. The confidentiality of the file remains intact at all times. However, the file can be deleted by anyone with the appropriate file permissions, which is an integrity problem. Most encryption programs such as EFS only address confidentiality problems. Integrity concerns must be addressed using normal NTFS file permissions (i.e., remove Modify or Write permissions from unauthorized users).

EFS Certificate

Every time a file is encrypted or decrypted, Windows looks for the user's EFS certificate. If this is the first time the user has encrypted a file on a particular system, Windows will first determine whether a public key infrastructure (PKI) server capable of supporting EFS (like Microsoft's Certificate Services) is active and participating. If so, Windows will request a digital certificate capable of supporting EFS on behalf of the user, and install it to the user's local profile. If a PKI server is not available, Windows will generate a self-signed EFS certificate and install it to the user's profile. Figures 13-2 and 13-3 show an EFS certificate generated by a Microsoft Certificate Services PKI server. EFS certificates are 1,024 bits by default. PKI-supplied EFS digital certificates are good for two years and will automatically renew before they expire, by default. Self-signed EFS certificates are good for 100 years.

Figure 13-2

Figure 13-3

Note 

The expiration period of self-signed EFS digital certifications may seem a month short of the 100-year mark on first examination because the total expiration period does not take into account leap years, so the expiration period is 100 × 365 days, not exactly 100 years.

An EFS certificate contains the user's private and public encryption keys. Every user (or sometimes computer, in the case of Offline files) has only one EFS certificate for every stand-alone system or domain computer. Every file the user encrypts will involve the user's single EFS certificate.

As stated above, a user's EFS certificate, with both public and private keys, is stored in the user's local profile. If the user has a roaming profile, the EFS certificate will be stored in the networked roaming profile, and locally wherever the user logs on. If the user encrypts files on a machine that does not have their EFS keys stored locally, they will have to import their EFS certificate locally or make sure the machine is Trusted for Delegation (more on this below).

The storing of the user's EFS key in their local profile is an extremely important point. If the user loses access to their local profile, either because of corruption or an inadvertent action (e.g., such as reinstalling Windows to fix another problem), their EFS key could become unrecoverable if not backed up. If a data recovery policy has not been defined beforehand (covered below), the protected files could easily be lost forever. This issue is not an uncommon problem.

The user's EFS certificate, which can have up to 16,384 bits of protection (it would be very slow and overkill), is protected by a 512-bit master key. The user's EFS private keys are stored in C:\Documents and Settings\<userid>\Application Data\Microsoft\Crypto\RSA\<usersid> and are encrypted by the user's master key, which is stored in C:\Documents and Settings\<userid>\ Application Data\Microsoft\Protect\<userid> and encrypted based on the user's password.

If an administrator resets the user's password on a stand-alone computer, it causes a new master key to be generated, and the user's EFS certificate can no longer be extracted. Users should always, if possible, change their own password (and not allow an administrator reset). If a user's password is reset, changing the password back to the previous password or using a previously created Password Reset Diskette (if created for the user's old password) should allow the user's EFS keys to be extracted again.

Note 

Important: Administrators resetting a user's password through the normal methods on a stand-alone computer can cause the user to lose access to their EFS-protected files. Unless impossible, always allow users to change their own password. If an administrator resets a password and the user loses access to their EFS-protected files, the user's original EFS key will have to be restored (if backed up), or the data recovery agent will have to recover the files (if a data recovery agent was in use at the time the files were encrypted).

File Encryption Key

The actual encryption process behind the scenes is more complicated, of course. When a file is first chosen for encryption, the Windows CryptoAPI will generate a symmetric encryption key, called the File Encryption Key (FEK). Every encrypted file has a unique FEK. No matter how many people can encrypt a single file, only one FEK is used to do the encrypting and decrypting. And just like any symmetric encryption algorithm, the same EFS key that encrypts the file is used to decrypt it.

FEK Ciphers

EFS uses Data Encryption Standard XOR (DESX), Triple-Data Encryption Standard (3DES), or Advanced Encryption Standard (AES) ciphers to create the FEK. By default, EFS uses the 128-bit DESX algorithm in Windows XP (pre-SP1), a slight improvement over the U.S. government's older Data Encryption Standard (DES) algorithm standard, for the FEK symmetric key. See www.rsasecurity.com/rsalabs/node.asp?id=2232 for more information on the differences between DES and DESX.

Note 

Non-U.S. versions of EFS may use 56-bit DESX instead of 128-bit.

Windows XP Pro and later can also be configured to use the stronger 168-bit 3DES cipher algorithm instead of DESX by enabling System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing located in Group Policy or Local Computer Policy under Computer Configuration\ Windows Settings\Security Settings\Local Policies\Security Options. The Federal Information Processing Standards (FIPS) are U.S. government recommended or required standards for government agencies, contractors, and solutions. If enabled, all new EFS encryptions in XP pre-SP1 will use 3DES, but any files previously encrypted by DESX will still be able to be decrypted without a problem. A great article on the effective strength of DES, DESX, and 3DES can be found at www.networkcomputing.com/1006/1006colmoskowitz.html.

Note 

When FIPS-compliant ciphers are enabled, it affects many other Windows features beyond EFS. If enabled, Windows will use TLS with 3DES, SHA-1, and RSA public keying material instead of the more widely supported standard of SSL for client/server HTTPS transactions, IPSec will use 3DES instead of DESX, and Terminal Services (and RDP services) will only use 3DES for encryption.

Windows XP Pro SP1 and later and Windows Server 2003 use the new and significantly stronger 256-bit AES open, symmetric cipher standard, by default, to create FEKs for EFS. Windows 2000 can use 56-bit DES or 128-bit DESX if installed with SP1 or later and high encryption. Whenever possible, AES should be used to provide the most secure implementation of EFS possible (i.e., AES is more secure than 3DES).

DDF and DRF

When a user encrypts a file, the file's FEK is encrypted by the user's personal EFS public key from the user's EFS digital certificate. The resulting encrypted FEK is stored in one of the file's extended attributes, called $EFS, in the Data Decryption Field (DDF) area. All users who are allowed to encrypt/ decrypt the file will have their own identical copy of the FEK encrypted by their own EFS public key, and stored in the DDF attribute field. Each DDF contains the user's SID, the folder where the EFS key is stored (called the container name, based on the computer and user's SIDs), cryptographic provider name (usually Microsoft Base Cryptographic Provider or Enhanced Provider), the user's name, the EFS certificate hash, and, finally, the encrypted FEK.

If a recovery agent is defined (covered in more detail below), a copy of the FEK is encrypted by the EFS recovery agent's public key and stored in a file attribute field called the Data Recovery Field (DRF). There will be a DRF entry for every recovery agent defined at the time the file was encrypted (or re-encrypted). The creation and naming of EFS keys are depicted in Figure 13-4.

Figure 13-4

New EFS Options in XP and XP SP2

In Windows 2000, EFS was added as a new driver. In Windows XP and later, EFS is integrated as part of NTFS. Microsoft added new EFS features in Windows XP and later (some of the topics have already been covered above):

• Data recovery agents are optional, but highly recommended.

• The 3DES and AES encryption algorithms can be used instead of DESX.

• Additional users can be authorized to access shared encrypted files.

• Offline files can be encrypted.

• A Password Reset Disk can be used to safely reset a user's password to a previous password.

• Encrypted files can be stored in web server (WebDAV) folders.

EFS File Sharing

Windows XP Pro and later allow multiple users to share EFS-protected files. The first user encrypting the file must add the additional users. All EFS users must have Read and Modify (or Write, or Change on the share) permissions and an already existing EFS certificate installed on the local machine or reachable using Active Directory. To implement the additional users, the original encrypting user chooses the Details button (see Figure 13-5) under the Advanced Attributes dialog box, under File Properties. Then the user clicks the Add button (see Figure 13-6) to add more users. Unfortunately, EFS file-sharing cannot be set on folders and cannot be given to groups. The latter issue is easily understandable because EFS certificates are issued per user and cannot be shared by groups.

Figure 13-5

Figure 13-6

Offline File Encryption

Windows' Offline Files feature allows users to store and use remotely accessible files offline when their access to the remote file server is interrupted, intentionally or unintentionally. Starting with Windows XP Pro, Microsoft allows administrators to encrypt offline files for added security. Offline Files works using shared folders (or web pages) with client and server support. Each participating share on the computer must be configured to allow Offline Files (see Figure 13-7), although the server's settings are often enabled by default. When the user's computer connects to the remote file server share, the files are downloaded to a local offline cache location on the client computer. After the user works with the offline files and reconnects to the server, the files are synchronized with the server, with the latest versions from either location updating the other. File synchronization can occur when the user's computer goes offline, during logoff and logon, or at predetermined schedules.

Figure 13-7

Starting with Windows XP, you can specify that the offline files that are stored locally be encrypted for added security. Interestingly, although you must have already enabled Offline Files, participating users are not required to have previously encrypted files. When the offline folder cache is encrypted, the folder cache is encrypted with a special EFS machine (i.e., computer) digital certificate. Unfortunately, this means that all users of the same computer will have their personal offline files encrypted with the same EFS key. Per Microsoft, this will change in future Windows versions.

To encrypt the Offline Files database on a local computer:

1. Click the Start button and then click the Control Panel menu option. If Control Panel is in Classic view, double-click Folder Options. If Control Panel is in Category view, click the Appearance and Themes link, and then click Folder Options.

2. Click the Offline Files tab.

3. If Offline Files are not already enabled, click the Enable Offline Files option.

4. Click the Encrypt offline files to secure data option (see Figure 13-7). Click OK.

Windows will now automatically encrypt offline files as they are stored in the local Offline Files database. Requirements include the following:

• The local offline folder cache must be stored on an NTFS partition.

• The first user logging on the local system after offline folder encryption is enabled must be a local administrator. This is because a registry entry must be made and the registry change requires admin rights.

• EFS and Offline Folder encryption must not be disabled by the Administrator or group policy.

There are many group policy settings that affect Offline Files (www.microsoft.com/resources/documentation/Windows/XP/all/reskit/en-us/Default.asp?url=/resources/documentation/Windows/XP/all/reskit/en-us/prde_ffs_phvy.asp, but only one affects the EFS status of Offline Files, the Encrypt the Offline Files cache option. If enabled, the offline files cache will be encrypted if the client is Windows XP or later. When you enable offline folder cache encrypting, the entire database is encrypted, not individual files. You cannot selectively choose which files to encrypt.

A great, short document on Offline EFS is located at www.microsoft.com/technet/prodtechnol/winxppro/maintain/encryptoffline.mspx.

Encrypted Web Files

EFS can also be used to encrypt files on WebDAV-enabled directories on IIS 6 web servers. WebDAV stands for Web-based Distributed Authoring and Versioning. It is an open standard from RFC 2518. In order for WebDAV to be used, both the client and the server must support it. Windows 2000 and later have a WebDAV client enabled, called the Web Client service. The separate service is not needed if IE 5.x or later is installed or if Microsoft Office 2000 and later is used. The WebDAV service must be enabled in IIS 6 as a web extension. Once enabled, any virtual directory created on IIS becomes automatically WebDAV-enabled. If EFS is also enabled on the server (the default option), any EFS encrypted file stored in a virtual directory remains encrypted when copied to and from a WebDAV-enabled client. Normally, EFS-protected files do not remain encrypted when copied over network connections.

If the file on the web server is not encrypted, it should be encrypted locally on the server is possible. The web server does not have to be trusted for delegation for WebDAV to take advantage of EFS. If the file is unencrypted on the server, and then encrypted by the client, a plaintext version of the file is copied down to the client, encrypted, and then sent back up to IIS. Although WebDAV is a great solution for keeping EFS-protected files encrypted across the wire, IPSec might be a better option because it will work with any protocol, not just HTTP.

Using EFS on Servers

Getting EFS working for local computers is easy, as described above. Getting EFS working on a file server so remote users can use it to encrypt files across a network takes a bit more work. In order for EFS to work on a (remote) server, for a remote user, three things must be true:

• The server must be a domain member that uses Kerberos authentication.

• The server must be trusted for delegation (covered below).

• The user must be logged on with a domain account that can be delegated.

By default, user accounts are usually enabled for delegation, unless in the Account tab under User account object, the following option is enabled: Account is sensitive and cannot be delegated. Delegated trust is needed so that the user's EFS private key stored in the user's local profile can be passed to the remote server to encrypt and decrypt the EFS-protected files.

All server computers can be trusted for delegation, but whether delegation is enabled by default depends on the type of server computer. Domain controller computers are trusted for delegation during the domain controller promotion process. Member servers are not trusted by default and must be enabled in Active Directory Users and Computers (see Figure 13-8).

Figure 13-8

In Windows Server 2000 and 2003 domains, there are two or three options to consider in trusting a computer for delegation:

• Do not trust this computer for delegation. If selected, remote users cannot use EFS on the selected server.

• Trust this computer for delegation to any service (Kerberos only). When this option is selected on a computer, all services under the Local System account on the computer will be trusted for delegation. This means an administrator on that computer may install any service, and then that service will have the capability to access any network resource by impersonating a user. This option will work for EFS, but it also makes a system susceptible to some types of malicious attacks (i.e., trojan attacks, etc.).

• Trust this computer for delegation to specified services only. This is new with Windows Server 2003, and is called constrained delegation. With constrained delegation, the administrator can specify which Service Principal Names (SPNs) this account is able to delegate to. This is the safest option to enable, but it takes much more effort to set up for any service, including EFS.

When enabled on a file server for remote users, EFS still does not encrypt files read from the server and sent over the network. If network protection is also desired, use WebDAV, IPSec, or SSL to protect EFS files in transmission.

Setting Up an EFS Recovery Policy

EFS is good encryption. Unfortunately, by storing EFS keys in the user's local profile and using the user's master key to protect the EFS private key, there is a good chance that the user's EFS keys may one day become inaccessible. Administrators must assume this will happen and prepare for recovery. EFS recovery can be accomplished by

• Backing up each user's EFS keys individually

• Having one or more Default Recovery Agents

• Allowing Certificate Services to back up EFS keys automatically

You should choose one of these options and implement an EFS recovery strategy. Users can back up their own EFS keys to a file and then store them in a safe place. If this method is used, users should store their backup EFS keys in a separate physical location away from their primary site, to prevent loss from a single disaster.

Backing Up EFS Keys Individually

Users can back up their EFS keys using many methods, including the following:

• Using the Certificates console snap-in

• Using Cipher.exe

• Using EFS GUI

To use the Certificates console snap-in, the user should perform the following steps:

1. Start the Microsoft Management console by selecting Start ð Run, and type Mmc.exe in the Open dialog box.

2. Choose File ð Add/Remove Snap-in from the menu bar.

3. Click the Add button.

4. Select the Certificates console and click Add, Finish, Close, and then OK.

5. Expand the Personal and Certificates leaf objects.

6. Highlight the correct EFS certificate (look for the Encrypting File System option under Enhanced Key Usage under the Details tab).

7. Under the Details tab, select the Public Key field and then click the Copy to File button (see Figure 13-9).

8. Click Next in the Certificate Export Wizard dialog box.

9. Select Yes, export the private key, and then click Next.

10. Click Next in the File Format Export dialog box.

11. Type a strong and complex password twice, to protect the private key from compromise, and then click Next.

12. Type in a file name and location in which to save the backed up EFS keys and click Next.

13. Click Finish to create the backup copy.

14. Move to one or more removable media options and store in a secure location.

Figure 13-9

In Windows XP Pro SP1 and later, you can use the Cipher.exe utility to back up user EFS keys. At a command prompt, type in Cipher.exe /X and press Enter. The currently logged on user's EFS key will be backed up. Move the resulting backup keys to a secure offsite location.

In Windows 2003 and later, users can back up their EFS keys in the normal EFS GUI. Select File ð Properties ð Advanced, and click the Details button. Then click the Backup Keys button (see Figure 13-10) and follow the Certificate Export Wizard as previously covered above in the first method.

Figure 13-10

Relying on end users to backup their EFS keys is risky. Many users will find it too complicated and others will simply ignore the good advice. A better option is not to rely on the end user's actions for EFS recovery.

Creating a Default Recovery Agent

By default in Windows Server 2000 and Server 2003, the local administrator (on a stand-alone computer) or domain administrator (on a domain member) is the designated Default Recovery Agent (DRA). Windows XP Pro machines in a domain environment also designate the domain administrator as the default DRA, but stand-alone XP Pro machines do not have any DRA installed by default. This latter decision was made by Microsoft to stop local password attacks from compromising the local administrator's or user's accounts and then leveraging the access to recovery EFS files.

You should, unless you have an alternative method, always have one or more DRAs defined. Whenever a file is encrypted, the DRA has a copy of the FEK stored in the DRF file attribute. In the event that a user's EFS key is lost, the DRA agent can log on and recover the files. The DRA should disable the EFS protection during the recovery process, and then copy the files where they are requested. This is because if the DRA does not remove the EFS encryption, anywhere they copy them to (excepting copies off the local NTFS volume) will result in the files remaining encrypted and tied to only the DRA. When unencrypted, the files can be copied to the original user, or to whoever is requesting access, and can be re-encrypted, if desired.

If a DRA is used, two or more DRA accounts should be created and used. This is because every file encrypted makes a backup copy of the FEK and encrypts it with the DRA's private EFS key. If only one DRA is used and something happens to that account (e.g., it is deleted, corrupted, etc.), all the DRF copies could be lost. If a DRA user account is added, only the files newly encrypted, or re-encrypted, will end up with the new DRA's DRF being added to the file. Hence, if an old DRA is deleted before the new DRA's account has had a chance to create DRFs for all encrypted files, files without a valid DRF can be included. If a new DRA is added, consider running the Cipher.exe /U command to update all files with the new DRA DRF. The /U option can also be used if the user gets a new EFS digital certificate.

If at all possible, the DRA shouldn't be the administrator, as is the default. This is because the administrator is a high-profile target and if the account is compromised, all encrypted files can be recovered. Instead, it is better to create one or two new DRA accounts, install/import DRA certificates to their accounts, and then run the Cipher.exe /U command under both user accounts. Adding a new DRA requires Microsoft Certificate Services or a PKI Certificate Authority that supports EFS Recovery Agent certificates (see Figure 13-11). In Microsoft Certificate Services, you must publish the EFS Recovery Agent template to the Certificate Services server.

Figure 13-11

The appropriate template permissions must be set so that the correct user accounts can request the certificate. The users then must manually request the certificate (unless auto-enrollment is enabled, which it shouldn't be for EFS Recovery Agent certificates), and a Certificate Authority manager needs to approve the certificate request.

After the certificates are installed in the user's local profiles, the new DRA users can be added as Recovery Agents. To add new DRAs, open the appropriate Group Policy Object and choose \Computer Configuration\Windows Settings\Security Settings\Public Key Policies. Right-click the Encrypting File System leaf object, choose Add Data Recovery Agent (see Figure 13-12), and follow the wizard's prompts.

Figure 13-12

For extra security, a DRA's private EFS key should be exported and removed from the system (a selection made possible during the Certificate Export Wizard process), and only added back when needed. Also, the DRA's account should be disabled until needed. That way, if the DRA's account is compromised, the intruder doesn't automatically have access to all encrypted files. Then run the Cipher.exe /U command to update the DRF file attributes.

Using Certificate Services

Alternately, you can configure Windows Server 2003 Microsoft Certificate Services to automatically back up (i.e., archive) users' EFS keys if the server is used to issue EFS certificates to users. In order to configure key archival, one or more users must have a Key Recovery Agent certificate. The Key Recovery Agent template must have the appropriate permissions and be published to the Certificate Authority server. Then the appropriate users should request KRA certificates and install them.

The appropriate EFS certificate template (its default name is Basic EFS) should have the Archive subject's encryption private key option selected (see Figure 13-13). Then, whenever an EFS certificate is issued to a user, the user's private key will be archived to a safe location. If the user's private key is ever needed, it can be manually extracted by the Key Recovery Agent and installed back to the user.

Figure 13-13

DRA versus KRA

EFS recovery can be accomplished automatically using the DRA or KRA. This naturally begs the question of which is a better strategy. Overall, either is fine, but here are the advantages and disadvantages.

Advantages of using a DRA:

• It does not require a PKI infrastructure.

• Data recovery policies can be managed centrally using the Active Directory.

• Users do not have to manage certificates or private keys.

• Decryption can be limited to the user only (requires deleting DRA keys while maintaining policy).

Disadvantages of using a DRA:

• An administrative process must recover user data. Users cannot recover their own data.

• Data recovery occurs on a file-by-file basis as a manual process.

• Users must re-enroll for new certificates. This is because only data is recovered, not the original keys of a user.

• Administrators must revoke old certificates. This is because it is assumed that when a key is lost it's been compromised.

• Stand-alone workstations, or workstations in non-Active Directory environments, cannot be centrally managed.

• Data recovery is specific to the EFS application.

Advantages of using a KRA:

• Users do not have to perform re-enrollment for certificates, change security settings, etc.

• Existing certificates do not have to be revoked.

• Users do not have to recover any data or e-mail due to lost private keys.

• All data encrypted by a public key in a certificate can be recovered after a private key has been recovered.

Disadvantages of using a KRA:

• User key recovery is a manual process involving administrators and users.

• It allows administrative access to the private keys of users.

• Nonrepudiation assurance may not be guaranteed.

Choose a recovery method that works for your environment. Do not enable EFS without first enabling, and testing, an EFS recovery method.