How Encrypting File System Works

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

How Encrypting File System Works

In this section

• Encrypting File System Architecture

• Physical Structure of an Encrypted File

• Encrypting File System Processes and Interactions

• Related Information

Encrypting File System (EFS) provides file encryption for NTFS files stored on disk. EFS supplements other security features such as logon authentication or file permissions that protect network resources from unauthorized access. Encrypting sensitive files by using EFS adds a layer of security that protects data even if an attacker gains full access to the computer where the data is stored.

EFS functions equally well on standalone systems running Windows XP Professional and Windows Server 2003, and in Active Directory domain environments. On standalone systems, EFS is automatically enabled but can be disabled by editing local security policy. In Active Directory environments, EFS can be managed using the domain security policy.

In a domain controller, a default recovery policy is automatically put in place when the administrator logs on to the computer for the first time, making the enterprise administrator the data recovery agent for computers that are members of the domain. For standalone computers, a default data recovery agent is not created. As a security best practice, if you decide to use the default data recovery agent, you should export the private key and save it separately and then remove the private key from the domain controller. However, it is strongly recommended that you create at least one data recovery agent in case the original account or credentials used to encrypt data with EFS become unavailable. For example, you can create a key pair on a smart card, and then set that certificate as the data recovery agent instead of the default data recovery agent. This enables you to recover data by using the smart card without exposing the private key to other software.

This section is divided into three subsections:

• Encrypting File System Architecture describes and illustrates the relationships between the operating system components that make up EFS in both user mode and kernel mode.

• Physical Structure of an Encrypted File describes the fields that are added to a data file when it is encrypted and the role of each field.

• Encrypting File System Processes and Interactions describes the processes used by EFS to encrypt, decrypt, recover and share data.

Encrypting File System Architecture

In order to provide transparent encryption, EFS relies on several components that operate at the user mode and kernel mode levels of the operating system:

EFS Components

The following diagram illustrates the relationships among these components.

Relationship of EFS Components

One additional kernel mode component, the WebDAV Redirector, is required to manage encrypted files on Web Distributed Authoring and Versioning (WebDAV) file shares.

For more information about the encryption and decryption processes, see “Encrypting File System Processes and Interactions.” The following sections describe the components of EFS in detail.

Efsadu

The Efsadu dynamic link library (DLL) provides the EFS user interface. Efsadu is called when a user access the Advanced Properties page for a file or folder to modify file or folder encryption options. The options processed through Efsadu include whether to apply the encryption to file or folder only, or to a folder and all subfolders and files that it contains. EFSadu also contains the user interface for adding users to an encrypted file.

Feclient

When a user modifies EFS options for a file or folder, or when an application attempts to access an encrypted file on an NTFS volume, the Win32 application programming interface (API) passes the resulting EFS-related calls to the Feclient DLL. Feclient then calls the EFS remote procedure call (RPC) interfaces in the LSA.

This two-stage process for calling the EFS routines in LSA is required because EFS supports remote storage of encrypted files on servers running Windows Server 2003 or servers running Windows 2000. The role of Feclient is to determine which client computer or server has the requested file and to then contact the LSA on that computer or server.

Note

• Users can also modify EFS options from the command line by using Cipher.exe. For more information about Cipher.exe, see “Encrypting File System Tools and Settings.”

Local Security Authority

The Local Security Authority (LSA) performs the majority of user mode EFS operations. The LSA responds to requests from the kernel to create a file encryption key (FEK) and encapsulate it with the proper user and recovery agent public keys. The FEK is returned to the kernel and used to encrypt a file. The LSA also performs the reverse operation of unwrapping a FEK and returning it to the kernel to decrypt a file.

During the encapsulation process, the recovery policy for the local computer is checked to determine whether the FEK should also be encapsulated by one or more recovery agent public keys. During decryption, the recovery policy is checked again to see if additional or new recovery certificates have been added; if so, the LSA reencapsulates the FEK using the new recovery agent public keys. The LSA also checks to determine whether the EFS certificate belonging to the current user has changed, which would also require the FEK to be reencapsulated.

To improve performance, the LSA maintains a cache of handles (or pointers) to private keys used for encapsulating and extracting FEKs. These handles point to private keys that remain in the cryptographic service provider (CSP) and are, therefore, protected from unauthorized access.

CryptoAPI

CryptoAPI consists of a set of functions that allow applications to encrypt or digitally sign data while providing protection for private key data. Applications can use the functions in CryptoAPI independently of the underlying implementation.

EFS uses CryptoAPI for user mode cryptographic operations; CryptoAPI also provides underlying security services for secure channels and code signing. CryptoAPI supports public key and symmetric-key operations such as key generation, key management and secure storage, key exchange, encryption, decryption, hashing, digital signatures, and verification of signatures. In addition, application developers can use CryptoAPIservices to add cryptography to their 32-bit Windows applications.

Cryptographic Service Providers

The public-private key pairs for EFS users and recovery agent accounts are obtained from the Microsoft Base cryptographic service provider (CSP), also called the RSA base provider, or the Microsoft Enhanced CSP. These CSPs are included with Windows Server 2003 and Windows XP Professional.

Note

• Only Microsoft CSPs for RSA are supported for EFS. EFS does not support the Microsoft smart card CSP.

Depending on the CSP you select, you can select one of three encryption algorithms to encrypt and decrypt the contents of files:

• Advanced Encryption Standard (AES) algorithm. This is the default encryption standard for Windows Server 2003 and Windows XP Professional with Service Pack 1 installed. AES uses a 256-bit key for encryption and decryption.

• DESX. An enhanced variant of the Data Encryption Standard (DES).

• Triple-DES (3DES). 3DES, which is compliant with Federal Information Processing Standards (FIPS 140-1 Level 1), offers significantly stronger encryption using a 128-bit or 168-bit key. 3DES is enabled through a Group Policy setting. All EFS FIPS mode encryption processes are completed using 3DES.

The encryption algorithms available to EFS depend on which version of Windows is running on the computer:

• Windows XP with SP1 or later can encrypt or decrypt files using DESX, 3DES, or AES.

• Versions of Windows XP Professional earlier than SP1 can use the DESX or the Triple-DES (3DES) algorithm for EFS encryption and decryption.

• Windows 2000 Professional and Windows 2000 Server use the DESX algorithm for EFS encryption and decryption.

Note

• When 3DES is enabled in FIPS mode, it is used as the encryption algorithm for IP Security as well as for EFS. When 3DES is enabled, all new encryption processes are completed by using 3DES, but DESX and 3DES are always available for decryption, regardless of the encryption policy.

If a user attempts to view files that have been encrypted using an encryption algorithm not supported by the operating system, the file appears to be corrupted or filled with random characters.

NTFS

The NTFS driver contains the majority of the EFS code in the kernel. This driver responds to file system controls (FSCTLs) from the LSA to encrypt or decrypt a file. When a file is opened, the driver passes the wrapped FEK to Ksecdd to be unwrapped by the LSA. The driver then decrypts the data when it is read from the file and encrypts the data when it is written to the file.

The EFS API in the NTFS driver also provides a set of functions for reading and writing encrypted files in raw mode. Raw mode allows direct reading and writing of the ciphertext (text that has been encrypted using an encryption key). This allows the Windows backup utilities to read and write the encrypted data for backup purposes, while preserving the confidentiality of the data.

To improve performance for files opened multiple times in quick succession, the NTFS driver maintains a cache of unwrapped FEKs that it receives from the LSA. By default, FEKs are cached for five seconds; the cache time is configurable from two to thirty seconds.

Ksecdd

Ksecdd is a very thin component that NTFS calls to communicate with the LSA. Ksecdd is used to set up local procedure call (LPC) communications to the LSA.

FIPS.sys

Microsoft Kernel Mode Cryptographic Module (FIPS.sys) is a FIPS 140-1 Level 1 compliant, general-purpose, software-based cryptographic module located at the kernel mode level of the Windows operating system. It runs as a kernel mode export driver (kernel-mode DLL) and includes several different cryptographic algorithms in an easy-to-use cryptographic module accessible by other kernel mode drivers. It can be linked into other kernel mode services to permit the use of FIPS 140-1 Level 1 compliant cryptography.

Note

• Federal Information Processing Standard (FIPS) 140-1 is a security implementation designed for certifying cryptographic software. FIPS 140-1–validated software is required by the U.S. Government and requested by other prominent organizations.

In Windows 2000, Windows XP Professional, and Windows Server 2003, both IPSEC and EFS use FIPS.sys to encrypt traffic packet data and file contents, respectively, provided that you use FIPS-compliant algorithms.

WebDAV Redirector

The Web Distributed Authoring and Versioning (WebDAV) client redirector is responsible for managing encrypted files on WebDAV file shares. The redirector works by retrieving the file from the server and then caching it locally while edits are performed. When the file is closed, the redirector stores the file on the server. While the file is cached locally, the redirector calls the NTFS driver to read and write the file.

When the file is stored on the server, the client redirector performs a backup read on the locally cached file and takes the data and stores it on the server. When a file is retrieved from the server, the redirector performs a backup write to the cached file which takes the encrypted data and restores it to a normal, but encrypted, NTFS file.

Physical Structure of an Encrypted File

EFS uses a combination of public key and symmetric key encryption to ensure that files are protected from all but the most computationally infeasible methods of attack.

EFS follows the standard cryptographic procedure of key encipherment. Data is encrypted using a symmetric file encryption key (FEK) for speed; the FEK is then secured asymmetrically for maximum security. When a user requests that a file be encrypted, EFS uses a uniquely generated FEK to encrypt a file and then encrypts the FEK itself by using the public key from the public key certificate belonging to the user. The encrypted FEK is stored in a file header called EFS metadata. When a user requests decryption, EFS decrypts the FEK using the user's private key, and then uses the FEK to decrypt the file.

An encrypted file contains encrypted data and a header with fields to store copies of the encrypted FEK for authorized users and designated data recovery agents. The structure of an encrypted file is shown in the following figure.

Encrypted File Structure

Data Decryption Field

An encrypted file contains a minimum of one stored FEK, the FEK encrypted by using the public key belonging to the initial encryptor. The storage field for this encrypted FEK is called the data decryption field(DDF). Additionally, if an EFS-encrypted file is shared, a copy of the FEK is encrypted by using the public key belonging to the newly authorized user, and the encrypted FEK is stored in another DDF. In this way, there is a separate data decryption file for every user of an encrypted file.

Data Recovery Field

If the effective security policy for a computer designates one or more data recovery agents, copies of the FEK are encrypted for each data recovery agent by using the public key of each data recovery agent, and the copies are stored in another file header field called the data recovery field (DRF).

Key Storage

When an encrypted file is saved, Windows XP Professional and Windows Server 2003 automatically provide four levels of encryption to protect the encryption keys that protect the file, and a fifth level, the startup key, can be configured. These levels operate as follows:

• Level One: EFS generates a unique FEK for every file that is encrypted.

• Level Two: EFS uses the public key in the EFS certificate of the user to encrypt the FEK. The certificate containing the public key is stored by default in the certificate store of the computer. The corresponding private key, used to decrypt the FEK, is stored in an encrypted form in the profile of the corresponding user or data recovery agent account in the RSA folder.

• Level Three: The Data Protection API generates the master key for the user that is used to encrypt the private keys belonging to the user.

• Level Four: The Data Protection API generates a symmetric password encryption key*,* derived from the credentials of the user, which encrypts the master key belonging to the user.

• Level Five: A startup key (also called the syskey) can be used to protect all master keys as well as a variety of other secrets that are stored on computers. At system startup, the startup key is used to encrypt all of the private keys on the computer, including private keys that are used for EFS. Startup keys are automatically generated and used for computers in a domain, but must be manually configured on stand-alone computers. Startup key security can be increased by storing the key on removable media or by requiring a system startup password.

Windows XP Professional and Windows Server 2003 provide several additional configuration options that increase security. To prevent loss of access to your master keys on stand-alone computers, you can create a password reset disk (PRD). You can also implement options to prevent your computer from entering hibernation mode and to delete paging files at system shutdown so that data is not needlessly exposed.

Certificate and Public Key Storage

Windows Server 2003 and Windows XP Professional store public key certificates for a user in the personal certificate store of that user. Certificates can be stored in plaintext because they are public information, and they are digitally signed by certification authorities to protect against tampering.

User certificates are located in the Documents and Settings\username\Application Data\ Microsoft\SystemCertificates\My\Certificates folder for each user profile. These certificates are written to the personal store of the user in the system registry each time the user logs on to the computer. For roaming profiles, the certificates of users are located in a shared folder on a server configured by the domain administrator and follow users when they log on to different computers in the domain.

Encrypting File System Processes and Interactions

The following processes are associated with EFS:

• Encryption

• Decryption

• File recovery

• Multi-user sharing

Encrypting a File with EFS

When a user encrypts an existing file, the following process occurs:

1. EFS opens the file for exclusive access.

2. EFS creates a temporary file in the current directory and carries out the following series of operations:

   1. Each data stream in the source file is copied to the temporary file for backup purposes.

   2. Each data stream in the original file is next truncated to a length of zero, and its length is then set back to its original size. This essentially deletes all the data in the stream.

   3. EFS writes the encryption metadata to the original file. At this point EFS has the plaintext data in a temporary file and an empty source file that is marked encrypted (because of the presence of the EFS metadata).

3. A file encryption key (FEK) is randomly generated and used to encrypt the file with the AES, 3DES, or DESX algorithms, depending on the version of the operating system and the effective security policy.

4. A data decryption field (DDF) is created to contain the FEK encrypted by using the user's public key. In addition:

   • If a data recovery agent has been designated through Group Policy, a data recovery field (DRF) is created to contain the FEK encrypted by using RSA and the public key of the data recovery agent.

   • If there are multiple data recovery agents, a copy of the FEK is encrypted by using the public key of each data recovery agent, and a DRF is created to store each encrypted FEK.

     Note

   • The file recovery property in the certificate is an example of an enhanced key usage (EKU) field. An EKU extension and extended property specify and limit the valid uses of a certificate. File Recovery is one of the EKU fields defined by Microsoft as part of the Microsoft public key infrastructure (PKI).

5. EFS writes the encrypted data, along with the DDF and any DRFs, back to the file. Because symmetric encryption does not add data to a file, file sizes change very little after encryption. The encryption metadata, consisting primarily of encrypted FEKs, is quite small (depending on how many users are added to the file).

   Note

   • The size of EFS metadata is limited to 256 KB.

6. The plaintext temporary file is deleted.

   Note

   • Data from deleted files might not be erased when the file is deleted. The cipher /w command can be used to remove data from available unused disk space on the entire volume.

When a user saves a file to a folder that has been configured for encryption, the encryption process is similar, except that no temporary file is created.

The following figure shows the EFS encryption process when a data recovery agent is being used.

EFS Encryption with a Data Recovery Agent

Decrypting a File with EFS

Conversion to plaintext follows a similar process as for encryption, in that a temporary file is created and the source file is written to it. The source file is then truncated and the data is read from the temporary file and written back to the source file in the clear. When an application accesses an encrypted file, decryption proceeds as follows:

1. NTFS recognizes that the file is encrypted, retrieves the DDF, and passes it to EFS.

2. EFS retrieves the private key belonging to the user from the profile of the user and uses it to decrypt the DDF and obtain the FEK.

3. EFS then uses the FEK to decrypt sections of the file as needed by the application.

   Note

   • Because EFS uses cipher block chaining, when an application opens a file, only those sections of the file that the application is using are decrypted. The behavior is different if the user removes the encryption attribute from the file. In this case, the entire file is decrypted and rewritten as plaintext.

4. EFS returns the decrypted data to NTFS, which then sends the data to the requesting application.

The following figure illustrates the decryption process:

EFS Decryption

Recovering a File

Data recovery is similar to the decryption process except:

• The DRF is used instead of the DDF.

• EFS decrypts the DRF with the private key of a data recovery agent to recover the FEK.

The recovery process is as follows:

1. NTFS recognizes the file as encrypted and sends a request to EFS.

2. EFS retrieves the DRF (instead of the DDF) and decrypts the DRF (instead of the DDF) with the private key of the data recovery agent (instead of the private key of the user) to obtain the FEK.

3. EFS uses the FEK to decrypt the file

4. NTFS then completes the file request and sends the data to the requesting application.

The following figure illustrates the file recovery process.

EFS File Recovery

Authorizing Users to Access Encrypted Files

Users can share encrypted files with other local, domain, and trusted domain users. Authorizing user access to encrypted files is a separate process from sharing files for network access by using share-level security and access control lists (ACLs). Therefore, sharing access to encrypted files involves the configuration of both file system ACL permissions, and EFS permissions.

Because there is no method for issuing a certificate and assigning a key pair for a group, groups cannot be authorized for access: Only individual user accounts can be authorized for access to an encrypted file.

After a file has been encrypted, additional users can be authorized to access encrypted files by opening the Advanced Attributes dialog box from the Properties dialog box for the file.

EFS certificates can also be imported to the profile of a user. If the EFS certificate is self-signed, it is added to the Trusted People container. If the EFS certificate was issued by a certification authority CA, it is added to the Other People container. Certificates added to either container appear in the Select User dialog box.

Note

• If you import a certificate belonging to a user, you have the option to manually select its location. If you import a self-signed certificate, be sure to add it to Trusted People. Certificates in Trusted People are the only certificates that are not chain validated, because these certificates are already trusted. Self-signed certificates always fail chain validation because no CA was involved in certifying them, so placing them anywhere other than in Trusted People makes them unusable.

Before a user can be authorized to access an encrypted file and be added to the file, EFS needs to determine whether the certificate can be trusted. When a certificate for a user is selected, EFS attempts to validate the certificate chain. If the chain validation fails, CryptoAPI also checks to see if the certificate is in Trusted People store. If not, the certificate cannot be used.

Sharing an encrypted file can be illustrated with a simple example. Assume that Alice already has access to the encrypted file. She is either the original encryptor, or she has been authorized for access. Alice wants to authorize Bob to access the file. To accomplish this, EFS performs the following steps:

1. EFS obtains the private key belonging to Alice from her user profile to decrypt the FEK contained in the data decryption field of the file.

2. EFS obtains the public key belonging to Bob from his certificate and uses it to encrypt the FEK.

3. The encrypted FEK belonging to Bob is stored in a new data decryption field with the file.

Note

• At no time in this process is the file itself decrypted, so it is not directly at risk. However, the FEK is briefly decrypted. But because EFS performs this operation in nonpaged memory, the decrypted FEK is never paged and so is never exposed.

The following Figure shows what happens when Alice shares an encrypted file with Bob.

EFS Access Authorization

Users electing to share encrypted files should remember the following:

• Shared EFS files are not file shares. If authorized users need to access shared EFS files over the network, a file share or a Web folder is required. Alternatively, users can establish remote sessions with computers that store encrypted files by using Terminal Services.

• Any user who is authorized to decrypt a file can authorize other users to access the file. Granting access is not limited to the file owner. Caution users to share files only with trusted accounts, because those accounts can authorize other accounts. Removing the Write permission from a user or group of users can prevent this problem, but it also prevents the user or group from modifying the file.

• EFS sharing requires that the users who will be authorized to access the encrypted file have EFS certificates. These certificates can be located in roaming profiles or in the user profiles on the computer on which the file to be shared is stored , or they can be stored in and retrieved from Active Directory.

• EFS sharing of an encrypted file often means that the file will be accessed across the network. To enhance the security of file data, it is best if Web folders are used for encrypted file storage whenever possible.

• If a user chooses to remotely access an encrypted file stored on a file share and to authorize other users to access the file, the authorization process and requirements are the same as on the local computer. Additionally, EFS must impersonate the user in order to perform this operation, and all of the requirements for remote EFS operations on files stored on file shares apply.

• If a user chooses to remotely access an encrypted file stored on a Web folder and to authorize other users to access the file, the file is automatically transmitted to the local computer in ciphertext. The authorization process takes place on the local computer with the same requirements as for encrypted files stored locally.

Validating Certificate Chains

Imported self-signed certificates for EFS are automatically placed in Trusted People, and there is no certificate chain to validate, so the user can be added to the encrypted file.

Note

• Certificates are not verified for valid chains or revocation status during encryption or decryption.

However, if the certificate was signed by a CA, EFS attempts to build a certification chain and validate the certificate only when adding a user to the file. If the chain ends with an untrusted root CA, EFS will not use the certificate, and the user is not added to the file.

For more information about how chain validation works, see the “Certificate Services Technical Reference.”

Related Information

The following resources contain additional information that is relevant to this section.

• How NTFS Works

• How Certificates Work