Using the Encrypting File System

Using the Encrypting File System

Although properly configured DACLs will protect data, sometimes you need a greater degree of protection. Your organization might have some data that must be kept confidential from administrators, even those who have Full Control permissions on the files. Also, your organization might have data that is stored temporarily on laptops issued to employees and needs to remain confidential even if the physical security of the laptop is compromised. The encrypting file system (EFS) allow users and administrators to encrypt files and folders to extend file and folder security beyond NTFS permissions.

EFS combines asymmetric and symmetric encryption to encrypt files and manage the encryption keys. EFS uses symmetric encryption either the DES-X algorithm or the 3DES algorithm (Windows XP only) to encrypt the data and asymmetric encryption to manage the symmetric encryption keys. The default configuration of EFS allows users to encrypt files without any configuration by an administrator. When a user encrypts a file, EFS automatically generates a public-key pair for the user and either obtains a digital certificate by requesting one from a Certification Authority (CA) or self-creates a certificate if no CA is available to issue certificates.

File encryption and decryption is supported on a per-file or entire-directory basis. Directory encryption is transparently enforced. All files (and subdirectories) created in a directory marked for encryption are automatically encrypted. Each file has a unique encryption key, making it safe for rename operations. If you move a file from an encrypted directory to an unencrypted directory on the same volume, the file remains encrypted because the move operation does not actually change the location or structure of the file on disk. Encryption and decryption can be set using the properties of the file or folder in Windows Explorer. Additionally, command-line tools and administrative interfaces are provided for advanced users and recovery agents to ease management of encrypted files.

A file need not be decrypted before use; encryption and decryption is done transparently when bytes travel to and from the disk. EFS will automatically detect an encrypted file and locate the user s certificate and associated private key to decrypt the file.

How EFS Works

EFS works differently depending on whether a computer is a member of a domain or it is a stand-alone computer. The following description explains how EFS works in a domain environment.

When a user chooses to encrypt a file, the file is loaded into protected memory and the user s computer generates a random encryption key known as a file encryption key (FEK). The computer uses a symmetric encryption algorithm either DES-X in Windows 2000 or Windows XP, or 3DES in Windows XP only to encrypt the file using the FEK as the key, as Figure 7-3 shows.

Figure 7-3. Encrypting the contents of a file using EFS

Next, the computer retrieves the user s EFS certificate from the user s profile and extracts the user s public key. If the user does not have an EFS certificate, the computer generates an EFS certificate based on the user s account information, including the user s password. The FEK is encrypted using the RSA algorithm with the public key from the user s EFS certificate and added to the header of the file in the data decryption field (DDF). This process is shown in Figure 7-4.

Figure 7-4. Encrypting the FEK of a file using the EFS public key of the user account

The final step in encrypting the file is accomplished by the computer retrieving the certificate for each EFS recovery agent. For each EFS recovery agent certificate, the computer extracts the public key and encrypts the FEK by using the RSA encryption algorithm and stores the encrypted FEK in the data recovery field (DRF) located in the file s header. This process is shown in Figure 7-5.

Figure 7-5. Encrypting the FEK of a file using the EFS recovery agent s public key

The only users who can view the information in the file are those who encrypted the file and anyone who possesses a recovery agent s private key. Even another user with Full Control permissions on the file will not be able to read it. When a user attempts to open the file, the user s private key is retrieved and used to decrypt the FEK. The decrypted FEK is then used to decrypt the file. Files secured with EFS are not paged out of volatile memory when decrypted, preventing data from the file from being stored in the page file. When the user saves the file, a new FEK is generated and the process of creating the EFS header is repeated.

If the user opens the file and moves it to a non-NTFS partition or to a remote server, the file will be transparently decrypted. Users with Back Up Files And Folders user rights on a computer containing encrypted files will be able to back up the files. However, if the backup is restored to a non-NTFS partition, the contents of the files will be unintelligible.

EFS Command-Line Tools

In addition to configuring EFS in the Explorer interface, you can use two command-line tools to get information about EFS encrypted files or manipulate EFS encryption: Efsinfo.exe and Cipher.exe.

Efsinfo.exe is located in the Tools folder on the CD included with this book. Cipher.exe is available in Windows XP Professional and Windows 2000 Service Pack 3 or higher.

Efsinfo.exe

Efsinfo.exe is a command-line tool that allows you to retrieve information from the EFS header of a file encrypted with EFS. You must have the permission to read the attributes of the file to retrieve the information from the file you specify. The syntax for using Efsinfo.exe follows:

EFSINFO [/U] [/R] [/C] [/I] [/Y] [/S:dir] [pathname [...]]

The options for using Efsinfo.exe are decribed in Table 7-9.

Table 7-9. Efsinfo.exe Options

Option	Description
/U	Displays user information from the DDF.
/R	Displays recovery agent information from the DRF.
/C	Displays certificate thumbprint information for the user account that encrypted the file. You access the properties of a certificate by double-clicking an issued certificate in the certificate s Microsoft Manangement Console (MMC).
/I	Forces the utility to continue the specified operation even after errors have occurred. By default, Efsinfo.exe stops when an error is encountered.
/Y	Displays your current EFS certificate thumbprint on the local PC.
/S:dir	Performs the specified operation on directories in the given directory and all subdirectories.

Cipher.exe

Cipher.exe enables you to manipulate EFS-encrypted files from the command prompt. The versions of Cipher.exe in Windows 2000 and Windows XP are different and cannot be interchanged. In Windows 2000, the syntax of the Cipher.exe command is this:

CIPHER [/E /D] [/S:dir] [/P:keyfile] [/K:keyfile] [/L:keyfile] [/I] [/F] [/Q] [filename [...]]

Table 7-10 describes the options available when using Cipher.exe in Windows 2000.

Table 7-10. Cipher.exe Options in Windows 2000

Option	Description
/E	Encrypts the specified files. Directories will be marked so that files added afterward will be encrypted.
/D	Decrypts the specified files. Directories will be marked so that files added afterward will not be encrypted.
/S	Performs the specified operation on files in the given directory and all subdirectories.
/A	Encrypts files and the folders they are stored in.
/I	Forces the computer to continue performing the specified operation even after errors have occurred. By default, Cipher.exe stops when an error is encountered.
/F	Forces the encryption operation on all specified files, even those already encrypted. For files that have already been encrypted, a new FEK will be generated and the EFS header re-created. Files already encrypted are skipped by default when using the /F option.
/K	Forces the computer to generate and use a new FEK for all files. When this option is specified, the computer attempts to update the user s EFS certificate. This option is useful after deploying EFS certificates from your Public Key Infrastructure (PKI).
/Q	Reports only the most essential information.

Used without parameters, Cipher.exe displays the encryption state of the current directory and any files it contains. You can use multiple file names and wildcards. You must put spaces between multiple parameters.

The Cipher.exe command was replaced in Windows 2000 Service Pack 3 with a version that adds the /W option. The /W option permanently deletes, or wipes, all deleted data from a directory. This removes all artifacts of files that have been deleted but not necessarily removed from the hard drive. It also removes all NTFS mount and junction points.

The Windows XP version of Cipher.exe includes all the options that the Windows 2000 version does as well as the options described in Table 7-11.

Table 7-11. Cipher.exe Options in Windows XP

Option	Description
/R	Generatates a .pfx file and a .cer file. You can use the certificate in the .cer file as the recovery agent and export the .pfx file (which contains the private key and the certificate) for archival. You can store these files in a secure offline location until they are needed to recover encrypted files. By removing the EFS recovery agent (RA) from the local computer, you prevent an attacker from using the RA account to gain access to encrypted files and folders.
/U	Updates the FEK and recovery agent on all encrypted files. The only other option that works with /U is /N.
/N	Works only in combination with /U. When used with /U, /N supresses the updating of the FEK and recovery agent. This option is used to locate encrypted files on a hard drive.

Using EFS with Local Accounts in Windows 2000 and Windows XP

When EFS is used with local accounts by default, the EFS certificate used by default is self-generated based on the user s logon credentials on the local computer. In Windows 2000, this leaves encrypted files vulnerable if the physical security of the computer is compromised because there are a number of tools that enable an attacker to reset the password on local accounts. Once the password is reset, the attacker can then log on to the computer as the user and decrypt the files. This is because the attacker will have access to the EFS private key stored in the user profile.

In Windows XP, the EFS private key is stored by using the Data Protection API (DPAPI), which encrypts secrets by using an encryption key based on the user s password. If the password is reset administratively, the DPAPI encryption key will no longer be valid. Thus, resetting the password causes the derived EFS private key to be inaccessible forever. Furthermore, the encrypted files would remain confidential. Windows XP issues a warning when an administrator attempts to reset the password of a local user. To prevent losing data with encrypted files, always ensure that you have an exported data recovery agent stored in a secure location. If you are using Windows 2000 and EFS with local accounts, you can increase the protection of the local account database by enabling the System Key (Syskey.exe) in either mode 2 or mode 3. By default, if the Administrator account is used to encrypt files and folders, no RA exists.

Additional EFS Features in Windows XP

Windows XP makes several improvements to EFS. These features are built on the features of EFS in Windows 2000 but add support for additional functionality and security. The main improvements include these:

• Encryption of offline files

• Remote encryption of files using WebDAV (discussed momentarily)

• Sharing of encrypted files

Encryption of Offline Files

Windows XP enables offline files and folders to be encrypted using EFS. Offline folders use a common database on the local computer to store all offline files, and they limit access to those files through explicit DACLs. The database displays the files to the user in a manner that hides the database structure and format and appears as a normal folder to the user. Other users files and folders are not displayed and are not available to other users. Because the offline folders directory is in the %systemroot% folder, no individual user can encrypt its contents. Thus, the entire database is encrypted by the System account.

One limitation of encrypting the offline files database is that files and folders will not be displayed in an alternate color when the user is working offline. The remote server can contain copies of the files that have been individually encrypted on the server, and when the user is online and working with server-based copies of those files, they can display in an alternate color. Although the files are encrypted, this might seem an inconsistency to the user.

The offline folders feature, also known as the client-side caching (CSC) feature, runs as a System process and therefore can be accessed by any user or process that can run as System. This includes administrators on the local machine. Therefore, when sensitive data is stored in offline folders, administrative access should be restricted to users and the System Key should be used in mode 2 or mode 3.

Remote Encryption of Files Using WebDAV

Windows XP supports a new method for encrypting files on remote servers through a protocol known as Web-Based Distributed Authoring and Versioning (WebDAV). When the Windows XP client maps a drive to a WebDAV access point on a remote server, files can be encrypted locally on the client and then transmitted as raw encrypted files to the WebDAV server by using an HTTP PUT command. Similarly, encrypted files downloaded to a Windows XP client are transmitted as raw encrypted files and decrypted locally on the client by using an HTTP GET command. The Temporary Internet Files directory is used for intermediate transfer of the files by using HTTP where the WebDAV detects and sets the encrypted file attribute for Windows XP. Therefore, only public-key pairs and private-key pairs on the client are used to encrypt files, even though the files are stored on a remote server.

The WebDAV redirector is a new mini-redirector that supports the WebDAV protocol for remote document sharing by using HTTP. The WebDAV redirector supports the use of existing applications, and it allows file sharing across the Internet (through firewalls, routers, and so on) to HTTP servers. Both Microsoft Internet Information Server 5.0 (Windows 2000) and IIS 5.1 (Windows XP) support WebDAV folders, known as Web folders. The WebDAV redirector does have some limitations on the files that can be transmitted using the WebDAV protocol. The actual limitation varies depending on the amount of virtual memory available, but in general, only files of less than 400 megabytes can be transferred in Windows XP with EFS over WebDAV. Files and folders, when encrypted using a WebDAV share, will appear as unencrypted if a user or administrator logs on to the server locally. Once a file has been encrypted using WebDAV, that file should be accessed and decrypted only by using WebDAV. This unique behavior does not affect the ability to back up and restore the server by using Ntbackup.exe or the Windows NT backup API set.

Administrators and users should not encrypt files locally on a volume that hosts a WebDAV share. All administration should be done through the WebDAV share only. You can create a WebDAV folder in Windows 2000 or Windows XP by enabling Web Sharing on the properties of any folder. Note that if a user does not have a key to decrypt the file on a WebDAV share, she will receive an access denied error if she attempts to modify the advanced EFS attributes of the file.

Sharing of Encrypted Files

In Windows XP, EFS supports the sharing of files between multiple users on a per-file basis. However, users must be specified individually instead of by security group, and multiple encryption accounts are not supported on folders. Once a file has been encrypted, you can add users to the list of those who can decrypt the encrypted file by selecting the Advanced Properties dialog box of an encrypted file and clicking the details button. Individual users can add other users (but not groups) from the local machine or from the Active Directory directory service, provided the user has a valid EFS certificate and keys. Figure 7-6 shows this process.

Figure 7-6. Sharing files encrypted with EFS in Windows XP

Introduction to Designing a Data Recovery Agent Policy

When utilizing EFS, you must ensure that files can be recovered if a user s EFS private key is lost or if the files need to be retrieved for legal reasons. The data recovery agent (DRA) private key can decrypt files and can remove the encryption attribute on those files.

Establishing a data recovery policy requires in-depth knowledge of PKI and thus is outside the scope of this book. For more information on designing a data recovery policy, see the Data Protection and Recovery in Windows XP white paper at http://www.microsoft.com/ technet/prodtechnol/winxppro/support/dataprot.asp.

EFS automatically enforces a recovery policy that requires a recovery agent be available for files to be encrypted. The recovery policy is a type of public-key policy that provides user accounts to be designated as DRAs. A default recovery policy is automatically established when the Administrator account logs on to the system for the first time, making the administrator the recovery agent.

The default recovery policy is configured locally for workgroup computers. For computers that are part of an Active Directory based domain, the recovery policy is configured in a domain OU Group Policy object (GPO). If no recovery agent policy is created, the computer s local recovery agent policy is used. Recovery certificates are issued by a certificate authority, or CA, and managed by using the MMC Certificates snap-in or by using the Cipher.exe /r command in Windows XP.

In a network environment, the domain administrator controls how EFS is implemented in the recovery policy for all users and computers in the scope of influence. In a default Windows 2000 or Windows XP installation, when the first domain controller is set up, the domain administrator is the specified recovery agent for the domain. The way the domain administrator configures the recovery policy determines how EFS is implemented for users on their local machines. Administrators can define one of three types of policy:

• Recovery agent policy

  When an administrator adds one or more recovery agents, a recovery agent policy is in effect. These agents are responsible for recovering any encrypted data within their scope of administration. This is the most common type of recovery policy. You can ensure all recovery agents are available to all Windows 2000 and Windows XP computers by using Group Policy.

• Empty recovery policy

  When an administrator deletes all recovery agents and their public-key certificates, an empty recovery policy is in effect. An empty recovery policy means that no recovery agent exists, and if the client operating system is Windows 2000, EFS is disabled altogether. Only the Windows XP client supports EFS with an empty DRA policy.

• No-recovery policy

  When an administrator deletes the private keys associated with a given recovery policy, a no-recovery policy is in effect. Because no private key is available, there is no way to use a recovery agent and recovery will not be possible. This policy is useful for organizations with a mixed environment of Windows 2000 and Windows XP clients where no data recovery is desired.

In a Windows 2000 environment, if an administrator attempts to configure an EFS recovery policy with no recovery agent certificates, EFS is automatically disabled. In a Windows XP Professional environment, the same action enables users to encrypt files without a DRA.

In a mixed environment, an empty EFS recovery policy turns off EFS on Windows 2000 computers but only eliminates the requirement for a DRA on Windows XP Professional computers.

When a domain user logs on at a domain computer that is within the scope of the EFS recovery policy, all DRA certificates are cached in the computer s certificate store. This means that EFS on every domain computer can easily access and use the DRA s public key (or multiple public keys, if multiple DRAs are designated). On computers where an EFS recovery policy is in effect, every encrypted file contains at least one data recovery field in which the file s FEK is encrypted by using the DRA s public key and stored. By using the associated private key, any designated DRA can decrypt any encrypted file within the scope of the EFS recovery policy.