Windows 2003 supports the Encrypting File System on NTFS volumes . EFS enables a user to encrypt a file such that only he can access it. When a user initially uses EFS to encrypt a file, the user is assigned a key pair (public key and private key). This is either generated by the certificate services or self-signed by EFS depending on whether there is a CA present. The public key is used for encryption and the private key is used for decryption. When the user encrypts a file, a random number called the File Encryption Key (FEK) is assigned to the file. The DES or DESX algorithm is used to encrypt the file with the FEK as the secret key. The FEK is also encrypted with the public key using the RSA algorithm. In this way, a large file can be encrypted using relatively fast secret key cryptography while the FEK is encrypted with slower but more secure public key cryptography. This provides a high level of security with less impact on overall performance. Leveraging Standalone EFSWindows 2000, 2003, and XP all support EFS. They are capable of generating their own key pair for EFS if a domain level certificate is unavailable to them. EFS on a machine that does not belong to a domain has a number of differences than a machine that is a domain member. For example, Windows 2000 has a default setting that allows any local Administrator account to decrypt any user's encrypted files on that machine. This makes machines vulnerable to sector editor attacks as the local password store can be compromised. Windows XP and Windows Server 2003 do not have this behavior. If a user encrypts a file and loses the certificate store of both the user and the local DRA, it will be impossible to decrypt the files. Similarly, due to the lack of a central key database for non-domain EFS users, a user could intentionally delete the DRA certificate and the certificate store and render the files unrecoverable. When using EFS in a nonActive Directory environment, some key best practices should be followed to simplify management and improve local security:
Existing Encrypted Files and Utilizing the Default Domain Recovery Agent If a machine or user with standalone EFS is migrated to an Active Directory environment with an enterprise CA, clients will continue to use the self-signed certificates. They will not automatically enroll for a new certificate once they are joined. However, the default domain recovery agent will take effect for all new files. Existing encrypted files will utilize the default domain recovery agent once they are modified. Common Pitfalls with Encrypted File System ImplementationsOne of the easiest traps to fall into with Encrypted File System (EFS) is to allow users to enable EFS on their own machine without access to a domain wide recovery agent. Clients will create their own key pair and administrators might not have the capability to recovery encrypted files if the user loses the local key pair. Active Directory allows you to prevent users from enabling EFS until such time that a proper CA has been put in place to enable managed EFS on the clients. The easiest way to do this is via GPMC:
|