Encrypting File System
Encrypting File System |
|
Following are the kinds of questions that administrators frequently ask when analyzing the value of EFS to a file security plan.
EFS is designed to be transparent in normal operation. When a user attempts to open a file that has been encrypted by another user, EFS attempts to locate the private key that decrypts the FEK so the file can be opened. If the user who is calling does not possess the key, the FEK is not decrypted, and the attempt fails with an "Access denied" error message.
Not if the computer is joined to a domain and the policy is set at the domain level. Encrypted Data Recovery Agent policy is propagated from the domain as part of Group Policy and is enforced by EFS on the local computer. An attempt by a local administrator to define a different local EFS policy does not work because policy from the domain takes precedence.
The only option for a local administrator is to remove the computer from the domain, but this means that users cannot log on with domain credentials, and therefore cannot gain access to files that were encrypted by using domain recovery policy. Users might log on with other credentials and encrypt some new files, but if the computer is then reconnected to the domain, the new files are inaccessible using domain credentials.
A local administrator might attempt to locate the EFS policy storage and delete or replace it. Deletion is ineffective because that disables EFS. Replacement with another recovery policy does not work because domain policy has precedence and overwrites the other policy in each file the next time the file is opened.
Someone with physical access to the computer might attempt a sophisticated attack directly on the file stored on the hard disk drive. This fails because the file contains no plaintext and no key that can convert it to plaintext by itself. It cannot be read without using the user's private key.
Another possible attack is to invalidate or delete the DRF. This does not work either because EFS refreshes the recovery information the next time the file is accessed.
EFS incorporates a crash recovery scheme to preserve data in the event of fatal errors such as system crash, full disk, or hardware failure. This is accomplished by creating a plaintext backup of the original file being encrypted or decrypted. After the original is encrypted or decrypted successfully, the backup is deleted.
Encryption and decryption are safe operations because if any one step fails, all previous steps are rolled back. If a fatal failure causes the computer to stop responding or to restart, the backup file is used to perform the rollback when the operating system is up again.
Windows 2000 Backup detects the encryption and retains the encryption attributes when it backs up encrypted files.
Note
The plaintext copy can persist on the disk for some time, until another file uses those disk blocks. To avoid this problem, always start by creating an empty encrypted folder and then create files directly in that folder. The files are encrypted at their creation, and there is never any need to save them in plaintext anywhere on the disk.
A domain administrator might want to change the recovery policy for various reasons, such as the expiration of certificates or a change in recovery agent accounts. EFS does not check whether the recovery information on a particular encrypted file is changed until the next time that file is opened. If the information is not current, it is updated at that point.
This file-by-file approach is necessary because recovery information for a file cannot be updated without a decrypted FEK, which becomes available only when the file is opened.
This means that encrypted files that are not opened for long periods might have an old recovery policy. It is therefore important that recovery certificates and private keys be maintained for several years, even after the recovery policy has changed.
Just like changes in recovery policy, user certificate and key changes are handled when a particular file is opened. EFS determines whether the user's public key and certificate are current. If not, the DDF is updated with the user's current public key. To update the DDF, EFS must first find the old public key and certificate. For expired certificates, the certificates and private keys are archived automatically by the system, so they are available. Users, however, have the option to delete archived certificates and private keys. Users must retain their old keys until they are sure that all files that have been encrypted have been opened since the change was made. If a user's archived certificates and private keys are damaged or destroyed, you can use a recovery agent certificate and private key to recover the user's encrypted files. Thus, it is important to keep secure copies of recovery agent certificates and private keys in archives even after the certificates expire.
System data such as that stored in the registry, system DLLs, and other files that are required during system startup must never be encrypted because EFS does not become active until the operating system is up. If any of the files used by the operating system are encrypted, the system is rendered useless. EFS provides protection by disallowing encryption of files and folders with the system attribute.