Chapter 3: Encrypting File System

Published: April 04, 2007

Microsoft® Windows® XP and Windows Vista™ include the capability for data protection and protected data recovery through the Encrypting File System (EFS). EFS is a data encryption technology that can be applied to individual files or to all files that reside in a specific folder. EFS files cannot be decrypted without the corresponding key material. Also, it's important to note that unlike Microsoft BitLocker™ Drive Encryption (BitLocker), EFS cannot be applied to any file that is needed to boot the operating system.

Although BitLocker assures the encryption of all data on the entire system volume, EFS has the advantage of more precision and flexibility when configuring encryption for single or multiple users of a single computer. For example, EFS can be used to encrypt data files on a network that are accessed by many different users, a scenario that is beyond the capability of BitLocker.

EFS provides per-user encryption by protecting files with a key that is accessible only to the user and any authorized recovery agents. An attacker who obtains copies of the files will not be able to read them unless they also obtain the key material or copy the files directly from the original location to another location while logged on as the user who encrypted the files.

EFS in Windows XP

Although EFS was available in Windows 2000, the implementation in Windows XP and Windows Server® 2003 offered significant added features, including:

  • Enhanced recovery capabilities.
  • Full support for revocation checking on certificates used when sharing encrypted files.
  • User interface changes in Windows Explorer to easily locate and verify protected files.
  • Support for encrypted offline folders in Windows XP.
  • Multi-user support for encrypted files.
  • Support for Microsoft Enhanced and Strong cryptographic service providers (CSPs).
  • End-to-end encryption using EFS over WebDAV.

Detailed information about these EFS enhancements for Windows XP is available in the article "Encrypting File System in Windows XP and Windows Server 2003."

In the all-EFS scenarios described in this chapter, a logged-on user can enable encryption on files and folders using the Advanced Attributes interface in Windows Explorer.

Windows XP Advanced Attributes dialog box

Figure 3.1. Windows XP Advanced Attributes dialog box

When a file is encrypted in a folder for the first time, a prompt displays that asks the user whether they would like to encrypt just the selected file or the entire folder.

For those organizations that require more control over the scope of EFS encryption policy, EFS can also be managed centrally using Group Policy objects (GPOs) to automatically distribute scripts that use the Cipher.exe utility to configure encryption across the organization.

Note Both software and smart card–based modes of EFS require the presence of the associated certificate for every operation. For example, smart card–based EFS requires that the card be present for each encryption or decryption. This functionality prevents users from accidentally encrypting files using a certificate for which they do not have the associated private key, because the certificate cannot be used for encryption if the private key is not available.

EFS in Windows Vista

EFS is available in the Windows Vista Business, Enterprise, and Ultimate editions, and will be available in the Windows Server “Longhorn” release. Windows Vista provides important additional enhancements to EFS, including the following:

  • Use of cryptographic keys stored directly on smart cards for EFS encryption.
  • Wizard–based creation and selection of certificates used for EFS.
  • Wizard–based migration of files from an old smart card to a new one.
  • Encryption of the system paging file when EFS is enabled.
  • New Group Policy options that help administrators define and implement organizational policies for EFS. These options include the ability to require smart cards for EFS, enforce page file encryption, stipulate minimum key lengths for EFS, and enforce encryption of the user’s My Documents folder.
  • The greater functionality and ability to precisely manage EFS capabilities in Windows Vista are shown in the new user interface:

Windows Vista Advanced Attributes dialog box

Figure 3.2. Windows Vista EFS management interface

The rest of this chapter discusses two EFS options and describes the level of protection that each provides.

EFS Option: EFS with Software Key Storage

This EFS option requires only a Windows XP or Windows Vista–based computer.

The logical sequence of the EFS encryption process in this option is shown in the following figure:

The EFS encryption process

Figure 3.3. The EFS encryption process

The steps in the illustrated encryption sequence are as follows:

  1. The user creates a new file in an encrypted folder.
  2. A symmetric file encryption key (FEK) is randomly generated.
  3. The operating system checks the user’s certificate store for a certificate that has the appropriate key usage flags. If there is no appropriate certificate, one is generated automatically.
  4. The Data Protection Application Programming Interface (DPAPI) is used to encrypt and store the private key associated with the user’s certificate.
  5. The FEK is encrypted using the certificate’s public key and stored in the file metadata.
  6. The FEK is used to encrypt each block of data.
  7. The encrypted blocks are written to disk.

The logical sequence of the EFS decryption process in this option is shown in the following figure:

The EFS decryption process

Figure 3.4. The EFS decryption process

The steps in the illustrated decryption sequence are as follows:

  1. The user’s logon is validated either locally or by a domain controller.
  2. The user attempts to access an encrypted file.
  3. The DPAPI is used to retrieve the private key associated with the user’s X.509 certificate and decrypt it, using a key derived from the user's logon credential.
  4. The FEK is retrieved from the file and decrypted with the private key obtained in the previous step.
  5. The FEK is used to decrypt each block of the file as it is requested.
  6. The decrypted data is passed to the requesting application.

Additional information about the implementation behavior of EFS is available in the Encrypting File System Technical Reference.

Mitigated Risks: EFS with Software Key Storage

This EFS option mitigates the following risks to data:

  • Insider can read encrypted data. A specific advantage of EFS as compared with BitLocker is that the encryption keys are stored in a secure key store that is protected with the user’s credentials. In this configuration, the credential is a password. Therefore, other authorized users of the computer can log on to the computer either interactively or over the network, but will not be able to access confidential files on the computer that another user has protected with EFS unless that user specifically grants them access to the files.
  • Key discovery through offline attack. Assuming that the attacker targets a key such as the FEK or DPAPI master key instead of the user's password, the EFS recovery key (which is the private key for the certificates EFS uses) or the DPAPI master key could be subjected to a brute-force attack. This threat should not overly concern many organizations because of the difficulty of succeeding with this kind of attack against the strong types of keys that EFS uses.
  • Plaintext data leaks through system paging file (Windows Vista only). Windows Vista provides the ability to encrypt the contents of the system paging file, which eliminates one possible source of data leakage. This feature was implemented specifically to protect Windows Vista EFS keys such as the master DPAPI key (see the following topic) while it is being used by the computer. The feature also helps address the risk in this EFS option in which plaintext data might be available in the page file if it is being used by an application. The encryption keys that are used to encrypt the page file are ephemeral and are generated within the Local Security Authority (LSA). They are not derived from the user logon credential or X.509 certificate. After the computer shuts down (or crashes), the encrypted page file data cannot be recovered or read by any known method other than a brute-force attack.

Residual Risks and Mitigations: EFS with Software Key Storage

This EFS option does not mitigate the following risks without additional controls and policy:

  • Computer left in hibernation. As in the BitLocker options, if a user does not configure the computer to prompt for the password when it resumes from sleep or hibernation modes, the operating system cannot discern that the current user is not the proper user. In such a situation the attacker can use the laptop as if they were the authorized user. One likely attack would be to copy interesting data to a removable device or to a network location. However, if the computer is configured to prompt for user credentials when it resumes from sleep or hibernation modes, this risk is mitigated.
  • Computer left in sleep (standby) mode. Same as the previous risk mitigation explanation.
  • Computer left logged on and desktop unlocked. After the user logs on to the computer, the credentials are available to decrypt the certificates used for EFS. From then on, unencrypted data can be accessed by anyone with access to the keyboard. The most useful mitigation for this risk is security awareness training for users who might have sensitive information on their computers.
  • Discover local/domain password. In this configuration, EFS keys are decrypted in a sequence that starts with a key that is derived from the user’s password. Therefore, EFS encryption is compromised if the user’s password is compromised. This risk can be mitigated by implementing a strong password policy to prevent attacks such as dictionary attacks and by educating users about the importance of protecting their passwords.
  • Offline attacks against the operating system. EFS provides no protection for the operating system on the computer or any operating system configuration files in an offline attack scenario.
  • Online attacks against the operating system. Online attacks against the operating system are not mitigated by this option. An attacker who can get code of their choice to run on the operating system can steal cryptographic keys.
  • Plaintext data leaks through hibernation file. EFS provides no protection for the system hibernation file. This risk can be mitigated by upgrading to Windows Vista and using BitLocker or by disabling hibernation.

    Important Disabling hibernation reduces the usability of mobile PCs. This mitigation might be appropriate for computers that store extremely valuable assets, but in general other mitigations are usually more appropriate.

  • Plaintext data leaks through system paging file (Windows XP only). On Windows XP, EFS cannot be used to encrypt any system file, including the system paging file. This restriction means that if confidential data is accessed through an application, the data may be written to disk as a typical part of the memory paging operation. This risk can be mitigated by upgrading to Windows Vista or by configuring the computer to not use memory paging.

    Important Disabling memory paging typically decreases computer performance, sometimes significantly.

  • Platform attacks. A computer configured to use EFS with software key storage will maintain the EFS keys on disk and in memory. A platform attack that uses direct memory access or other hardware manipulation techniques might be able to recover the key material.
  • Required authentication factor left with computer. In this option, no other authentication factor exists. The only authentication factor is the user's computer or network password.
  • User error. The user must be careful to not save files that contain sensitive data to a location where EFS is not enabled. On Windows Vista this risk is partially mitigated because there is an EFS configuration option that allows for all of the files in the user's Documents folder to be encrypted. This functionality makes it easier for users to ensure that the appropriate files and directories are encrypted. This risk can also be mitigated by using the Microsoft Encrypting File System Assistant tool (the EFS Assistant is provided as part of this Solution Accelerator) to help automate the process of securing user files with EFS.

EFS Option: EFS with Smart Cards

Different versions of Windows provide different capabilities to improve the security characteristics of EFS. Information about these different capabilities is provided in the following subsections.

Windows XP and Smart Card Logon

Require Smart Card Logon is a domain user setting configured through the Active Directory® directory service that requires a user to use a smart card to log on to their domain account. The primary risk for EFS is that if a user’s password is compromised, an attacker could log on to the computer using that account and access any data on the computer, including data that is protected with EFS.

The Active Directory policy setting that requires a smart card for logon significantly improves the security of the account and, by extension, the security of any data protected with EFS. This setting also helps protect encrypted data from offline attacks, because it strengthens the key that EFS uses for DPAPI encryption. DPAPI works by deriving a key from the user credentials.

Smart card logon can be required in two different ways: per-user and per-computer. It can be enabled or enforced in each mode. There are some important security differences between the modes, including the following:

  • With enforced per-user smart card logon, the initial key is significantly stronger than a typical password. Instead of being able to mount a dictionary attack on the password, an attacker would likely have to mount a brute-force attack on a private key that can be made long enough to be practically unbreakable using current technologies.
  • Enforced per-computer smart card logon provides better security in some ways than password-only logon because it adds a second authentication factor. However, per-computer smart card logon uses the smart card only for logon authentication. An attacker who can obtain the encrypted DPAPI master key can still mount a brute-force attack in less time than it takes to successfully mount a brute-force attack on a DPAPI master key that is protected by per-user smart card logon.

Enabling, but not enforcing, either type of smart card logon does not add effective security protection because it leaves the choice of whether or not to use smart card logon up to the user.

More information about DPAPI and how smart card logon affects DPAPI keys can be found in the MSDN article "Windows Data Protection."

Note This risk discussion assumes that smart cards are used in combination with a non-trivial PIN and that the smart card implements PIN lockout to protect against guessing the PIN.

EFS encryption in the Windows XP with smart card logon option is shown in the following figure.

Windows XP EFS encryption with smart card logon

Figure 3.5. EFS encryption sequence for Windows XP with smart card logon

The steps in the illustrated encryption sequence are as follows:

  1. The user creates a new file in an encrypted folder.
  2. A symmetric FEK is randomly generated.
  3. The operating system checks the user’s certificate store for a certificate that has the appropriate key usage flags. If there is no appropriate certificate, one is generated automatically.
  4. DPAPI is used to encrypt and store the private key associated with the user’s certificate. This encryption is much stronger than in the previous option because of the much stronger password that is used when smart card logon is required.
  5. The FEK is encrypted using the certificate’s public key and stored in the file metadata.
  6. The FEK is used to encrypt each block of data.
  7. The encrypted blocks are written to disk.

EFS decryption in the Windows XP with smart card logon option is shown in the following figure.

Windows XP EFS decryption with smart card logon

Figure 3.6. EFS decryption sequence for Windows XP with smart card logon

The steps in the illustrated decryption sequence are as follows:

  1. The user’s smart card logon is validated either locally or by a domain controller.
  2. The user attempts to access an encrypted file.
  3. The correct private key is retrieved from the user’s DPAPI store and DPAPI decrypts it using a key derived from the strong, random user password that is applied to the user's account when Require Smart Card Logon is enabled on the account.
  4. The FEK is retrieved from the file and decrypted using the private key retrieved in the previous step.
  5. As the application reads each block of the file, the FEK is used to decrypt the block before it is passed to the requesting application.

Windows Vista and EFS with Smart Card

Windows Vista offers powerful new features that enhance both the security and usability of EFS through greater integration with smart card technology. In Windows XP, smart card logon is leveraged indirectly because of the way it improves the characteristics of DPAPI keys. However, in Windows Vista smart cards can be used directly to encrypt files with EFS. The new features do not require the user to be logged on with the smart card, although this scenario certainly works as well. Instead, the user is prompted to insert their smart card and provide a PIN if EFS is configured to require smart cards.

The obvious implementation of EFS and smart cards is to directly encrypt the FEK using the public key and to decrypt the FEK using the private key that corresponds with a certificate on the smart card. Although this option is very straightforward and secure, a performance impact results when every accessed file is decrypted because every private key decryption operation involves a communication with the smart card, and the smart card CPU is very slow compared to the host computer's CPU.

Another issue with the obvious implementation is that the smart card must be present at all times because each attempt to decrypt a file requires the private key to successfully decrypt the FEK. As a way to both improve performance and also to improve the usability of the EFS with smart card option, EFS is configured by default to derive a symmetric key from the private key on the smart card and use this key to decrypt and encrypt the FEKs associated with encrypted files. In the default configuration, the derived symmetric key will be cached by the operating system so that subsequent file encryption or decryption operations do not require use of the smart card and its associated private or public keys.

The ability to configure whether the symmetric key is derived and cached or not is represented in Figure 3.2. Windows Vista EFS management interface as the Create caching-capable user key from smart card option. If this option is cleared, a symmetric key is neither derived nor cached and the FEK is encrypted and decrypted using the smart card keys directly. This guide uses the terms cached key mode and uncached key mode to describe these two different operational modes that have unique security characteristics.

Cached Key Mode

In cached key mode, the derived symmetric key is cached in protected LSA memory by the operating system until the expiration of the cache timeout, which can be configured. The default cache timeout is eight hours of system idle time. Any operation that uses the derived key will reset the flush timeout period. Flush of the EFS key cache can also be configured to occur when the user locks the computer or when they remove the smart card. Cached key mode improves performance significantly and allows the administrator to configure EFS so that encrypted files can be encrypted and decrypted without having the smart card in the reader at all times.

Note For more details about how cached mode is implemented in Windows Vista, see the Windows Vista Security Guide.

EFS encryption in cached key mode is shown in the following figure:

Vista EFS encryption with smart card - cached

Figure 3.7. EFS encryption sequence for Windows Vista with smart card - cached key mode

The steps in the illustrated encryption sequence are as follows:

  1. The user creates a new file in an encrypted folder.
  2. If any of the following conditions are true, the user will be prompted to insert their smart card and enter their PIN:
    • The user did not log on to the computer with their smart card.
    • The user has not used their smart card to access an EFS file recently.
    • The card PIN is not cached from a recent EFS operation, or the PIN cache was cleared because of inactivity.
  3. An FEK is randomly generated.
  4. A symmetric key is derived from the smart card private key if either of the following conditions are true:
    • When the first file is encrypted.
    • When the derived key is not present in the cache.
  5. The FEK is encrypted with the derived symmetric key and stored in the file metadata.
  6. The derived symmetric key is cached in LSA-protected memory.
  7. The FEK is used to encrypt each block of data.
  8. The encrypted blocks are written to disk.

EFS decryption in cached key mode is shown in the following figure:

Vista EFS decryption with smart card - cached

Figure 3.8. EFS decryption sequence for Windows Vista with smart card - cached key mode

The steps in the illustrated decryption sequence are as follows:

  1. The user attempts to access an encrypted file.
  2. If any of the following conditions are true, the user will be prompted to insert their smart card and enter their PIN:
    • The user did not log on to the computer with their smart card.
    • The user has not recently used their smart card to access an EFS file.
    • The card PIN is not cached from a recent EFS operation, or the PIN cache was cleared because of inactivity.
  3. A symmetric key is derived from the smart card–based private key if it is not already cached. After first use, the derived key is cached in LSA-protected memory.
  4. The FEK is retrieved from the file and decrypted using the derived symmetric key.
  5. As the application reads each block of the file, the FEK is used to decrypt the block before it is passed to the requesting application.

Uncached Key Mode

EFS encryption in Windows Vista with EFS operating in uncached key mode is shown in the following figure.

Vista EFS encryption with smart card - uncached

Figure 3.9. EFS encryption sequence for Windows Vista with smart card - uncached key mode

The steps in the illustrated encryption sequence are as follows:

  1. The user creates a new file in an encrypted folder.
  2. If the user's smart card is not present, the user will be prompted to insert their smart card.
  3. A symmetric FEK is randomly generated.
  4. The FEK is encrypted using the certificate’s public key and stored in the file metadata.
  5. As the application writes each data block, it is encrypted with the FEK.
  6. The encrypted block is written to disk.

EFS decryption in uncached key mode is shown in the following figure:

Vista EFS decryption with smart card - uncached

Figure 3.10. EFS decryption sequence for Windows Vista with smart card - uncached key mode

The steps in the illustrated decryption sequence are as follows:

  1. The user attempts to access an encrypted file.
  2. If the user's smart card is not present, the user will be prompted to insert their smart card. If any of the following conditions are true, the user will be prompted to enter their PIN:
    • The user did not log on to the computer with their smart card.
    • The user has not recently used their smart card to access an EFS file.
    • The card PIN is not cached from a recent EFS operation, or the PIN cache was cleared because of inactivity.
  3. The EFS metadata for the file is retrieved from the file, and the encrypted FEK is passed to the smart card.
  4. The smart card decrypts the metadata to obtain the FEK, which is then returned to the operating system.
  5. As the application reads each block of the file, the FEK is used to decrypt the block before it is passed to the requesting application.

Mitigated Risks: EFS with Smart Card

The EFS with smart card option mitigates the following risks to data:

  • Computer left in hibernation (Windows Vista uncached key mode only). Windows Vista can require a smart card authentication every time an EFS-protected file is accessed. This mode of operation effectively mitigates this risk, although the default cached key smart card mode does not.
  • Computer left in sleep (standby) mode (Windows Vista uncached key mode only). Same as the previous (hibernation mode) risk mitigation explanation.
  • Computer left logged on and desktop unlocked (Windows Vista uncached key mode only). Windows Vista can require smart card authentication every time an EFS-protected file is accessed. This functionality, known as uncached key mode, was discussed earlier in this chapter and it effectively mitigates this risk by requiring the smart card's presence for all EFS file accesses. Although this scenario would have potentially serious usability issues, it remains a valid option for those organizations that require the most secure encryption solution for their sensitive and critical data.
  • Discover local/domain password. As mentioned in the "Data Security Risks" section in Chapter 1, a smart attacker always exploits the weakest link. Unfortunately for those people who are responsible for securing IT systems, the weakest link is often the user who chooses very poor passwords or who writes a very good password on a piece of paper and attaches it to their monitor. After your organization implements smart card–based two-factor authentication for network security, you should be able to increase the security of EFS through use of a “Smart card required for interactive logon” policy. On Windows Vista, two-factor authentication can be required to access sensitive data even for situations in which smart card logon cannot be enforced by enabling the Require Smart Card for EFS setting.
  • Insider can read encrypted data. The EFS with smart card option provides an effective mitigation to this risk by adding an extra authentication factor.
  • Key discovery through offline attack. Assuming that the attacker targets a key such as the FEK or DPAPI master key instead of the user's password, the EFS recovery key (which is the private key for the certificates EFS uses) or the DPAPI master key could be subjected to a brute-force attack. This threat should not overly concern many organizations because of the difficulty of succeeding with this kind of attack against the strong types of keys that EFS uses.
  • Plaintext data leaks through system paging file (Windows Vista only). Windows Vista can be configured to encrypt the system paging file, which effectively mitigates this risk.
  • Platform attacks (Windows Vista uncached key mode only). In cached key mode, a computer configured to use EFS with smart card key storage will maintain the EFS keys in memory, and a platform attack might succeed in recovering them. EFS used with uncached smart card key storage effectively mitigates this attack by requiring a direct attack against the smart card to recover the key material.
  • Required authentication factor left with computer. In this option the user must provide the PIN as well as the physical authentication factor, which provides true multifactor mitigation for this risk.

Residual Risks and Mitigations: EFS with Smart Card

The EFS with smart card option does not mitigate the following risks without additional controls and policy:

  • Computer left in hibernation (Windows XP and Windows Vista cached key mode only). If a user does not configure the computer to prompt for the password when it resumes from sleep or hibernation modes, the operating system cannot discern that the current user is not the proper user. In such a situation the attacker can use the laptop as if they were the authorized user. One likely attack would be to copy interesting data to a removable device or to a network location. However, if the computer is configured to prompt for user credentials when it resumes from sleep or hibernation modes, this risk is mitigated. In the EFS with smart card option, this risk can be mitigated as described earlier when using Windows Vista.
  • Computer left in sleep (standby) mode (Windows XP and Windows Vista cached key mode only). Same as the previous (hibernation mode) residual risk explanation.
  • Computer left logged on and desktop unlocked (Windows XP and Windows Vista cached key mode only). After the user logs on to the computer, the credentials are available to decrypt the certificates used for EFS. From then on, unencrypted data can be accessed by anyone with access to the keyboard. The most useful mitigation for this risk is security awareness training for users who might have sensitive information on their computers. In the EFS with smart card option, this risk can be mitigated as described earlier when using Windows Vista.
  • Offline attacks against the operating system. EFS provides no protection for the operating system on the computer or any operating system configuration files in an offline attack scenario.
  • Online attacks against the operating system (Windows XP and Windows Vista cached key mode only). Online attacks against the operating system are not mitigated by this option. However, the use of Windows Vista with smart cards in uncached key mode partially mitigates this risk by making it impossible for the attacker to recover the EFS keys because they are not accessible to programs running on the host operating system.
  • Plaintext data leaks through hibernation file. EFS provides no protection for the system hibernation file. This risk can be mitigated by upgrading to Windows Vista and using BitLocker or by disabling hibernation.

    Important Disabling hibernation reduces the usability of mobile PCs. This mitigation might be appropriate for computers that store extremely valuable assets, but in general other mitigations are usually more appropriate.

  • Plaintext data leaks through system paging file (Windows XP only). On Windows XP, EFS cannot be used to encrypt any system file, including the system paging file. This restriction means that if confidential data is accessed through an application, the data might be written to disk as a typical part of the memory paging operation. This risk can be mitigated by upgrading to Windows Vista or by configuring the computer to not use memory paging.

    Important Disabling memory paging typically decreases computer performance, sometimes significantly.

  • Platform attacks (Windows XP and Windows Vista cached key mode only). In cached key mode, a computer will maintain the EFS keys in memory and a platform attack might succeed in recovering them.
  • User error. Users must be careful to not save files that contain sensitive data to locations where EFS is not enabled. On Windows Vista this risk is partially mitigated because there is an EFS configuration option that allows for all of the files in the user's Documents folder to be encrypted. This functionality makes it easier for users to ensure that the appropriate files and directories are encrypted. This risk can also be mitigated by using the EFS Assistant tool (provided as part of this Solution Accelerator) to help automate the process of securing user files with EFS.

EFS Risk Analysis Summary

The following table lists data risks and indicates whether the different EFS options mitigate each risk. For Windows XP–based computers, the Require Smart Card Logon domain user setting is enabled. For Windows Vista–based computers, the Require a smart card for EFS and Enable pagefile encryption EFS settings on the computers are enabled.

Risks that are mitigated for specific options are marked with the letter Y. Hyphens - indicate risks for which the specific option provides little or no mitigation.

Table 3.1. EFS Risk Mitigations

EFS Risk Mitigations

More Information

This accelerator is part of a larger series of tools and guidance from Solution Accelerators.

Download

Get the Data Encryption Toolkit for Mobile PCs

Update Notifications

Sign up to learn about updates and new releases

Feedback

Send us your comments or suggestions