File Systems

EFS uses symmetric key encryption in conjunction with public key technology to protect files and ensure that only the owner of a file can access it. Users of EFS are issued a digital certificate with a public key and a private key pair. EFS uses the key set for the user who is logged on to the local computer where the private key is stored.

Users work with encrypted files and folders just as they do with any other files and folders. Encryption is transparent to the user who encrypted the file; the system automatically decrypts the file or folder when the user accesses. When the file is saved, encryption is reapplied. However, intruders who try to access the encrypted files or folders receive an Access denied message if they try to open, copy, move, or rename the encrypted file or folder.

To encrypt or decrypt a folder or file, set the encryption attribute for folders and files just as you set any other attribute. If you encrypt a folder, all files and subfolders created in the encrypted folder are automatically encrypted. It is recommended that you encrypt at the folder level.

You can also encrypt or decrypt a file or folder using the command-line tool Cipher. For quick information about an encrypted file or folder, use the Windows 2000 Resource Kit tool Efsinfo. For more information about Cipher or Efsinfo, see File System Tools later in this chapter.

Encrypting File System and Data Recovery

Data recovery is available for EFS as a part of the overall security policy for the system. For example, if you lose your file encryption certificate and associated private key (through disk failure or any other reason), data recovery is available through the designated recovery agent. The recovery agent is, by default, the local system administrator. However, if the computer is connected to a Windows 2000 Server – based network that is using Active Directory, the recovery agent role is assigned by default to the domain administrator.

EFS provides built-in data recovery by requiring that a recovery policy be in place before users can encrypt files. The recovery policy provides for a person to be designated as the recovery agent. The administrator is automatically designated as the recovery agent when logging on to the system for the first time.

The recovery agent has a special certificate and associated private key that allow data recovery for the scope of influence of the recovery policy. If you are the recovery agent, use the export command from the Certificates snap-in to back up the recovery certificate and associated private key to a secure location. After backing up, delete the recovery certificate from the recovery agent's personal store, not from the recovery policy. If you need to perform a recovery operation, first restore the recovery certificate and associated private key to the recovery agent's personal store by using the import command from the Certificates snap-in. After recovering the data, delete the recovery certificate from the recovery agent's personal store. You do not have to repeat the export process. Delete the recovery agent's recovery certificate from the computer, and keep it in a secure location as an additional security measure.

Note

The scope of influence in a domain is a site, a domain, or an organizational unit. In a workgroup, the scope of influence is the local hard disk.

The default recovery policy is configured locally for stand-alone computers. For computers on a network, the recovery policy is configured at either the domain, organizational unit, or individual computer level, and applies to all Windows 2000-based computers within the defined scope of influence. Recovery certificates are issued by a certification authority (CA) and managed by using the Certificates snap-in.

Because the Windows 2000 security subsystem handles enforcing, replicating, and caching of the recovery policy, users can implement file encryption on a system that is temporarily offline, such as a portable computer. This process is similar to logging on to the domain account using cached credentials.

Data Backup and Recovery

The main administrative tasks associated with EFS are backing up and restoring encrypted files, configuring a recovery policy, and recovering encrypted data.

Backup copies of encrypted files are also encrypted when you use a backup program designed for Windows 2000.

Data recovery refers to the process of decrypting a file without having the private key of the user who encrypted the file. When restoring encrypted data, the data remains encrypted after the restore operation.

You might need to recover data with a recovery agent if:

• A user leaves the company.

• A user loses the private key.

• A law enforcement agency makes a request.

To recover a file, the recovery agent:

• Backs up the encrypted files.

• Moves the backup copies to a secure system.

• Imports their recovery certificate and private key on that system.

• Restores the backup files.

• Decrypts the files, using Windows Explorer or the Cipher command.

You can use the Group Policy snap-in to define a data recovery policy for domain member servers or for stand-alone or workgroup servers. You can either request a recovery certificate, or export and import your recovery certificates.

Delegate administration of the recovery policy to a designated administrator. Although it is recommended that you limit who is authorized to recover encrypted data, allowing multiple administrators to act as recovery agents is a good idea.

Working With Encrypted Files

When you work with encrypted files and folders, keep the following in mind:

• You cannot encrypt files or folders that are compressed. First, uncompress the file or folder, and then encrypt it. On a compressed volume, uncompress folders that you want to encrypt.

• Only the user who encrypted the file can open it.

• You cannot share encrypted files.

• An encrypted file is decrypted if you copy or move the file to a FAT volume. However, a file remains encrypted when backed up by a program designed to work with Windows 2000.

• Cut and paste to move files into an encrypted folder. If you use a drag-and-drop operation, the files are not automatically encrypted in the new folder.

• System files cannot be encrypted.

• Encrypting a folder or file does not protect against deletion. Anyone with delete permission can delete encrypted folders or files.

• Temporary files created when files are being edited are encrypted if all the files are on an NTFS volume and in an encrypted folder. Encrypt the Temp folder on your hard disk to ensure that your encrypted documents remain encrypted during editing. If you create a new document or open an e-mail attachment, the file can be created as an encrypted document in the Temp folder. If you save the encrypted document to another location on an NTFS volume, it remains encrypted in the new location.

• Unless EFS is disabled by Group Policy, you can encrypt or decrypt files and folders on a remote computer that has been enabled for remote encryption. For more information, consult your domain administrator. However, If you open the encrypted file over the network, the data that is transmitted over the network is not encrypted. Other protocols, such as Secure Sockets Layer (SSL), Transport Layer Security (TLS), or IPSec must be used to encrypt data over the wire.

• A recovery policy is automatically implemented when you encrypt your first file or folder; if you lose your file encryption certificate and associated private key, a recovery agent can decrypt the file.

EFS Recommendations

• Encrypt the folder in which you save most of your documents to ensure that your personal documents are encrypted by default.

• Encrypt your Temp folder so that temporary files are automatically encrypted.

• Encrypt folders rather than individual files so that when a program creates temporary files during editing, they are encrypted.

• Use the export command from the Certificates snap-in to back up the file encryption certificate and associated private key on a floppy disk, and keep it in a secure location.

For more information about EFS, see Encrypting File System in the Microsoft Windows 2000 Server Resource Kit Distributed Systems Guide .