Encrypting File System
Encrypting File System |
|
EFS uses public key encryption in conjunction with symmetric key encryption to provide confidentiality for files that resists all but the most sophisticated methods of attack. The file encryption key (FEK) — a symmetric bulk encryption key — is used to encrypt the file and is then itself encrypted by using the public key taken from the user's certificate, which is located in the user's profile. The encrypted FEK is stored with the encrypted file and is unique to it. To decrypt the FEK, EFS uses the encryptor's private key, which only the file encryptor has.
Public key encryption algorithms use asymmetric keys for encryption and decryption. "Asymmetric" means that different keys are used to encrypt and decrypt the same data. Public key encryption uses a private key (which is held only by its owner) and a public key (which is available to other entities on the network). A public key, for example, can be published in Active Directory so that it is accessible to users in the organization. The two keys are separate but complementary in function. Information that is encrypted with the public key can be decrypted only with the corresponding private key of the set. The two keys together are called a key pair or a key set.
One drawback of public key cryptography is the amount of processing time that is required for its mathematical operations. Symmetric key encryption, which uses the same key to both encrypt and decrypt, is commonly 100 to 1,000 times faster, so symmetric and asymmetric key encryption are often used together to provide a wide range of network and online information security solutions. Thus, EFS encrypts data symmetrically with the FEK and then encrypts and decrypts the FEK asymmetrically with the public key and the private key.
When you save a file to be encrypted, a random cryptographic generator supplies a unique file encryption key (FEK), which is a fast symmetric key designed for bulk encryption. The FEK encrypts the data in blocks. EFS adds a header to the file, where the FEK is stored. The header has at least two parts, as shown in Figure 15.7.
Figure 15.7 Structure of an Encrypted Data File
EFS consists primarily of the following components in the Windows 2000 operating system: the Microsoft Cryptographic Application Programming Interface (CryptoAPI), the EFS service, the EFS driver, and the EFS File System Run-Time Library (FSRTL). Figure 15.8 shows the EFS architecture.
Figure 15.8 EFS Architecture
CryptoAPI is the interface for cryptographic operations in Windows 2000 and is used to generate FEKs as well as the public key pair that is used to encrypt and decrypt FEKs. EFS acquires FEKs from a statically linked library that cannot be replaced by a third-party product. EFS uses the DESX encryption algorithm for FEK generation and file encryption operations. DESX is a variation of the U.S. government's Data Encryption Standard (DES) algorithm. The public key pairs for EFS users and recovery agent accounts are obtained from the Microsoft Base cryptographic service provider (CSP). This CSP is included with Windows 2000 Professional and Windows 2000 Server and is approved for general export world wide. No other CSP can be used for EFS.
The EFS service calls CryptoAPI to acquire the file encryption key (FEK) for a data file and then to encode the FEK, thus producing the data decryption field (DDF) and data recovery field (DRF). The EFS service also returns the FEK, DRF, and DDF by way of the FSRTL to the EFS driver.
The EFS driver communicates with the EFS service to request key management services from CryptoAPI such as the computation of FEKs, of DDFs, and of DRFs. The EFS driver passes FEKs, DDFs, and DRFs to the FSRTL to perform various file system operations (open, read, write, and append) transparently.
When called by the EFS driver, the FSRTL reads, encrypts, and saves the file to disk. EFS avoids leakage of FEKs to paging files because the FSRTL resides in the Windows operating system kernel and uses the nonpaged pool to store the FEK. However, because the contents of paging files are not encrypted, the plaintext contents of encrypted file might be temporarily copied to paging files when encrypted files are opened and in use by applications. If the plaintext contents of encrypted files are copied to a paging file, the plaintext remains in the paging file until the contents are replaced by new data. Plaintext contents can remain in paging files for considerable amounts of time even after applications close the encrypted files.
A paging file is a system file, so it cannot be encrypted. (By default, Windows 2000 sets the name of the paging file as Pagefile.sys.) The file system security for paging files prevents any user from gaining access to and reading these files, and these security settings cannot be changed. However, someone other than the authorized user might start the computer under a different operating system to read a Windows 2000 paging file. To prevent others from reading the contents of paging files that might contain plaintext of encrypted files, you can configure security settings to clear the paging files every time the computer shuts down.
You can configure Group Policy to force all computers within the scope of the policy to clear paging files when the computers shut down. To configure Group Policy for this purpose, install the Group Policy MMC
To use Group Policy to force computers to clear their paging files when they shut down
The Template Security Policy Setting dialog box appears.
The new settings take effect when Group Policy is refreshed at each computer within the scope of the policy.
As shown in Figure 15.9, encryption with EFS requires the presence of at least two certificates in the certificate store on the local computer: one for the user (file owner) and one for a recovery agent account. If the certificates do not exist when the user logs on to the network, EFS builds them automatically.
Figure 15.9 Generation of an Encrypted Data File
There are two ways to create a file that has encryption already enabled. One method is to use Windows Explorer to create a file inside an encrypted folder. For example, in Windows Explorer, you can click an encrypted folder and then, on the File menu, point to New, and then click Rich Text Document. A second method is available to applications when they call the CreateFile() API with the file encryption flag, FILE_ATTRIBUTE_ENCRYPTED. Depending on which way you do it, NTFS checks the encryption status of the parent folder or of the flag passed in. If NTFS finds that the file must be created as encrypted, it calls the EFS FSRTL, which requests the EFS service to generate the metadata (FEK, DDF, and DRF) for the file object. The EFS service acquires the metadata from CryptoAPI and returns it by means of the EFS FSRTL to the EFS driver.
When the EFS service returns the metadata, the EFS driver sets up an EFS context for the file object and creates a $EFS stream of data containing the metadata. As the user writes data in the file, NTFS calls the FSRTL to encrypt the data.
Changing a file from plaintext to encrypted (by selecting the Encrypt contents check box in the Advanced Attributes dialog box) calls EncryptFile(). This API creates a backup copy of the file and requests the FEK, DRF, and DDF from the EFS service. The API then passes this metadata to the FSRTL by way of NTFS. The FSRTL sets up an EFS context for the file object and creates a $EFS stream with DDF, DRF, and so forth, for that object. EncryptFile() then reads the data from the backup and writes the data to the file. During the write, NTFS calls the FSRTL to encrypt the data before writing. When the writing is complete, the backup file is automatically deleted.
Users do not need to decrypt files or folders during normal operations because EFS provides transparent encryption and decryption during data writes and reads. When you open the encrypted file, your private key (from your protected store in your user profile) is applied to the DDF to unlock the FEK, and the file contents appear
Opening an encrypted file calls CreateFile(). NTFS checks the file on the disk to determine its encryption status, then calls the EFS service to verify the user. The EFS service finds the user's certificate and private key, and requests CryptoAPI to use the private key to decrypt the FEK. The EFS service then returns the FEK by way of the FSRTL to the EFS driver. If the user password or recovery agent information has changed, the EFS service requests a new DDF or DRF from CryptoAPI, as required, and returns it with the FEK to replace the old metadata.
When the EFS service returns the metadata, the EFS driver sets up an EFS context for the file object and creates a $EFS stream containing the metadata. The FEK decrypts the file so that it appears in plaintext on the screen.
As the user writes data in the file, NTFS calls the EFS FSRTL to encrypt the data.
If another user tries to open the file, access is denied. No one else can decrypt the file without the encryptor's private key or a private key for recovery. This is true even if administrators change permissions or file attributes, or file ownership is shared.
Decryption calls the DecryptFile() API. When it receives the API, the EFS driver looks up the EFS context; if the context does not exist, the file is already decrypted and nothing more need be done. Otherwise, the EFS driver opens the file and makes a backup copy in plaintext. The EFS driver then removes the encryption attribute and metadata, and writes the data back into the file.
For more information about decrypting a local folder or decrypting a folder on another computer, see Windows 2000 Professional Help or Windows 2000 Server Help.
If the owner's private key is unavailable (for example, because it is damaged), a recovery agent account can open the file by using the private key for recovery, which is applied to the DRF to unlock the FEK. The mechanism for file recovery works essentially the same way as decrypting a file, by using the user's private key.
A private key for recovery cannot decrypt the DDF. If there are multiple recovery agent accounts, each private key for recovery decrypts only its own DRF and no other. Thus, there is no danger that an unauthorized recovery agent account can access information from the file that enables access to other files.
As mentioned earlier, EFS assigns the local Administrator user account or the domain Administrator user account as recovery agent account by default, and you can use EFS indefinitely without ever changing this. However, it is good security practice to rotate recovery agent accounts. Because access to the file is denied if the agent designation changes, recovery certificates and private keys for recovery must be kept until all of the files that have been encrypted with them have been updated.
Note
Do not encrypt files when you are logged on as the local Administrator unless you have changed the default recovery agent account. The effectiveness of EFS recovery is compromised if a file's creator is both the user and the recovery agent account.
For more information about how users can submit encrypted files for recovery or about how recovery administrators can recover files, see Windows 2000 Professional Help or Windows 2000 Server Help.
Changing EFS recovery policy must be done by a member of the Domain Admin security group. For more information about how to change EFS Recovery policy for the local computer or a domain, see Windows 2000 Server Help, and see "Configuring Recovery Agent Policy" later in this chapter.
