EFS employs public-key encryption and the CryptoAPI architecture to encrypt and protect files. Windows Server 2003 encrypts each file with a unique, randomly generated file-encryption key. These keys are independent of the user's public/private-key pair. By using a different key for each file, Windows Server 2003 provides a very secure encryption method that is difficult to compromise at all, much less on a widespread basis (decrypting an entire volume of encrypted files, for example). The current implementation of EFS uses the Data Encryption Standard X(DESX), which provides 128-bit encryption, until recently available in Windows 2000 only in North America.
As an administrator, you need to do very little, if anything, to enable users to encrypt and decrypt files. EFS automatically creates a public-key pair and a file-encryption certificate for a user the first time the user attempts to encrypt a file. This eliminates the need for you to create a certificate or key pair for each user who needs to use EFS. The users' encryption certificates and keys are stored in their profiles, so they are available each time that a user logs on.
Whenever a user encrypts a file, EFS automatically generates a bulk symmetric encryption key and then encrypts the file by using the key. EFS then uses the user's public key to encrypt the bulk encryption key. (The user's key is called a File Encryption Key, or FEK.) EFS stores the FEK for an encrypted file within an attribute called the Data Decryption Field (DDF) in the file itself. In addition, EFS also encrypts the bulk encryption key by using the recovery agent's public key. This FEK is stored in the Data Recovery Field (DRF) of the file. The DRF can contain data for multiple recovery agents. Each time EFS saves the file, it generates a new DRF by using the current recovery-agent list, which is based on the recovery policy (explained in the following section). Figure 27-27 shows the encryption process.
Encryption and decryption happen transparently to the user as the file is read from and written to the disk, so a user can simply open an encrypted document by using the document's parent application without any special procedures. The application doesn't need to be EFS-aware because the encryption/decryption happens at the file-system level, independent of the application. EFS uses the private portion of the user's key pair to decrypt the FEK and enable the user to view the data. If the user doesn't supply the necessary private key required by the file (which happens automatically through the user's certificate store), the user receives an Access Deni ed message. Figure 27-28 shows the decryption process.
Note EFS does not require an entire file to be decrypted as it is being read. Instead, decryption occurs on a block-by-block basis, so only those portions of the file actually read are decrypted. As a result, EFS is extremely fast, and overhead is not noticeable in accessing encrypted files.
EFS under Windows 2000 was not designed to enable encrypted data to be easily shared among users; you could, however, enable multiple users to access and work with encrypted folders and files. The users simply need to share the same encryption keys. For more information, see the section "Sharing encrypted data," later in this chapter. Windows Server 2003 makes encrypted folder and file sharing a lot easier.
Was this article helpful?