Security with Encrypting File System

Windows 2000 includes Encrypting File System (EFS) which is a security technology that enables an individual user to encrypt files so that the files cannot be read by others.

EFS uses an encryption attribute to designate files for EFS protection. When a file's encryption attribute is on, ** EFS stores the file as encrypted ciphertext. When an authorized user opens an encrypted file in an application, EFS decrypts the file in the background and provides a plaintext copy to the application. The authorized user can view or modify the file, and EFS saves any changes transparently as ciphertext. Other users are denied permission to view or modify EFS-encrypted files. EFS-protected files are bulk encrypted to provide confidentiality even from intruders who bypass EFS and attempt to read files by using low-level disk tools.

Because EFS operates in the background at the system level, applications can save temporary files as plaintext to non-EFS-protected folders and inadvertently compromise confidentiality. Therefore, encryption usually must be enforced at the folder level rather than the file level. This means that you do not encrypt individual files, but instead designate folders as EFS-protected folders. All files that are added to EFS-protected folders are encrypted automatically. To specify EFS protection for a folder, use the properties page for the folder in Windows Explorer.

EFS is supported only for the version of NTFS that is included with Windows 2000. It does not work with any other file system, including the previous versions of NTFS. For more information about EFS, see "Encrypting File System" in this book.

File Encryption and Public Key Technology

For EFS to work, the EFS user must have a valid EFS user's certificate, and at least one EFS recovery agent account must have a valid EFS recovery certificate. EFS does not require a CA to issue certificates because EFS automatically generates its own certificates to users and to default recovery agent accounts. The EFS private key is generated and managed by Microsoft Cryptographic Application Programming Interface (CryptoAPI) in conjunction with the base Microsoft CSP.

When EFS encrypts a file, it does the following:

1. Generates a bulk symmetric encryption key.

2. Encrypts files by using the bulk encryption key.

3. Encrypts the bulk encryption key by using the EFS user's public key.

4. Stores the encrypted bulk key in a special field called the data decryption field (DDF), which is attached to the EFS file.

EFS can then use the user's private key to decrypt the bulk encryption key and decrypt the file as necessary. Because only the user has the private key, others cannot unlock the DDF.

In addition, EFS enables designated recovery agent accounts to decrypt and recover the file in case the user's private key is lost or damaged. For each designated recovery agent account, EFS does the following:

1. Encrypts the bulk encryption key by using the public key from each recovery agent certificate.

2. Stores the encrypted bulk key in a special field called the data recovery field (DRF), which is attached to the EFS file.

The data recovery field can contain information for multiple recovery agent accounts. Every time a file system operation is complete for a file, such as viewing, opening, copying, or moving the file, EFS generates and saves a new DRF with the most current public keys for the current recovery agent certificates. You can designate recovery agent accounts by configuring Encrypted Data Recovery Agents Group Policy settings.

Encrypted Data Recovery Policy

You might want to recover encrypted files, for example, when an employee is terminated for cause or when a user's private key for EFS is damaged. You can use the command-line tool, Cipher, to recover files on a recovery computer where a current recovery agent account, certificate, and private key are located. To recover a file, a recovery administrator must log on to the recovery computer as the recovery agent account and then use Cipher to decrypt the file. Cipher only works for the recovery agent accounts that are listed in the files DRF. Cipher also only works if the private key for recovery is installed on the computer.

Encrypted Data Recovery Agent Group Policy settings are a subset of Public Key Group Policy. You can configure Encrypted Data Recovery Agent settings to designate recovery agent accounts for domains, organizational units (also known as OUs), or stand-alone computers. Trusted recovery administrators that you designate can then use the recovery agent accounts to recover EFS encrypted files for the domains or organizational units where the EFS recovery settings apply.

When Group Policy is downloaded to computers, the Encrypted Data Recovery Agent Group Policy settings contain the certificates for each designated recovery agent account within the scope of the policy. EFS uses the information in the current Encrypted Data Recovery Agent Group Policy settings to create and update DRFs. A recovery agent certificate contains the public key and information that uniquely identifies the recovery agent account.

By default, the domain Administrator user's account on the first domain controller that is installed in the domain is the recovery agent for computers that are connected to the network. On stand-alone computers, the local Administrator user account is the default EFS recovery agent. EFS generates EFS recovery certificates automatically for default Administrator accounts.

Note

You can disable EFS for a domain, organizational unit, or stand-alone computer by applying an "empty" Encrypted Data Recovery Agents policy setting. Until Encrypted Data Recovery Agent settings are configured and applied through Group Policy, there is "no" policy, and the default recovery agents are used by EFS. However, EFS must use the recovery agents that are listed in the Encrypted Data Recovery Agents Group Policy after the settings have been configured and applied. If the policy that is applied is empty, EFS does not operate.

The Windows 2000 Resource Kit includes the tool Efsinfo.exe, which you can use to view information about the recovery agent accounts. You can use Efsinfo to verify what recovery accounts are current for an encrypted file.

Recovery Agent Accounts

The default EFS recovery agent accounts might meet the needs of some organizations. However, other organizations might want to issue EFS recovery certificates to designate other recovery agent accounts for more flexible EFS recovery management. For example, you can issue recovery certificates to dedicated EFS recovery computers rather than to the default Administrator user account on domain controllers. You can also configure Encrypted Data Recovery Agents settings for portable computers so that they use the same recovery agent certificates when they are connected to the domain and when they are operated as stand-alone computers.

Rather than attempting to manage EFS recovery on a domain-wide basis, consider designating recovery agent accounts to manage recovery for each organizational unit. You can designate several recovery accounts to recover users' files as necessary for users within that organizational unit.

You can deploy Certificate Services to issue EFS user certificates to users and EFS recovery certificates to recovery accounts. If an enterprise issuing CA is available, EFS requests EFS certificates from the enterprise CA instead of generating its own certificates. Using an enterprise CA to manage EFS certificates provides the benefits of centralized certificate management and enables you to publish certificate revocation lists (CRLs) for EFS certificates.

Old EFS files for which there have been no file operations, such as viewing, opening, copying, or moving for a long period of time might contain out-of-date recovery agent information. Therefore, it is recommended that you maintain a recovery agent archive to ensure that EFS files can be recovered by using obsolete recovery agent certificates and their private keys. For more information about EFS recovery, see "Windows 2000 Certificate Services and Public Key Infrastructure" and "Encrypting File System" in this book.