Professional Windows Server 1002003 Security A Technical Reference [Electronic resources] نسخه متنی

EFS Architecture

To troubleshoot EFS, or to be able to design proper EFS recovery and EFS policy for the organization, you must understand how EFS works.

EFS is a component of the NTFS file system of Windows 2000 and above. Thus, its operations are mostly transparent to the user and to the application that needs to open and close the files. If the user has the ability to encrypt and decrypt the files, when the file is opened, it is decrypted, and when it is saved, it is encrypted. The setup of shared EFS files is not transparent.

File System Operations

Several operating system components both in user space and in the kernel participate in the operation of the EFS. These components are listed and described in Table 6-2.

When a request to encrypt an existing file is received by the file system, the following steps occur:

NOTE: Role of the User's Master Key in EFS

The user's certificate and private key are stored in the user's profile and protected by the user's master key. The master key is based on the user's password. When the master key is not in use, it is encrypted and stored in the user's profile. Knowledge of the user's password at the time the master key was encrypted is necessary to decrypt the master key. This is why a normal password change instituted by the user will not affect EFS-encrypted files, but a password reset done by an administrator will. It is also why even though encryption keys can be found on the disk, EFS-encrypted files cannot be decrypted without knowledge of the user's password at the time of the encryption. Without the password, the master key cannot be decrypted, and the encryption keys cannot be used.

Encrypting, Decrypting, and Recovery Algorithms

EFS uses two types of encryption: symmetric (single key) and asymmetric or public key encryption. Files are encrypted using symmetric algorithms, which are very fast. The symmetric key is protected with public key encryption.

Symmetric key encryption uses the same key both to encrypt and decrypt. This is similar to using a physical key to lock the door to a house. The security of the data, or of the house, depends on keeping tabs on the symmetric key. The house key should not be left in the lock, and it should not be stored nearby and easily found. Likewise, the symmetric key used in encryption must be protected. It is typically stored separately from the data. When it is necessary to decrypt the data, the symmetric key (or a copy of it) must be produced and used. For two parties to share encrypted data, the symmetric key must be securely provided to both parties and therefore cannot merely accompany the encrypted data. The problem of key distribution can be difficult to solve.

Asymmetric key encryption, also known as public key/private key encryption, can be used to solve the key distribution problem. Asymmetric key encryption uses an associated key pair approach. If one of the keys is used to encrypt, only the other associated key can be used to decrypt. Therefore, one key can be made public (the public key) and widely available as long as the other (the private key) is kept private. Public key encryption is used for key distribution in many email encryption schemes. In the typical email encryption scheme, a symmetric key is used to encrypt the message, and the recipient's public key is used to encrypt the symmetric key. The protected symmetric key can therefore be sent with the encrypted email. The recipient can use his private key to decrypt the encrypted symmetric key, and the symmetric key can be used to decrypt the message.

EFS uses a similar approach. An asymmetric key pair is used to protect the file encryption key. In EFS, each user who is allowed to encrypt files is provided a public key/private key pair to do so. The public key is placed in a certificate and bound to the user account. The private key is stored separately. A symmetric key, the FEK, is used to encrypt the file, and the user's public key is used to encrypt the file encryption key. The public key cannot be used to decrypt the FEK. Instead, the associated private key must be used.

NOTE: Why Are Both Algorithms Used?

Both email and EFS schemes might have been developed to only use public key encryption. Instead of first using a symmetric key to encrypt the data, the public key could be used. The observed result would be the sameonly the holder of the private key would be able to decrypt the data. However, asymmetric key encryption is very slow. The difference might not be noticed when small amounts of data are encrypted, but it would be very noticeable if larger amounts of data were encrypted.

If multiple users are authorized to encrypt the file, or there is a designated File Recovery Agent, the FEK is also separately encrypted with these public keys. All encrypted copies of the FEK are stored in the files properties. Decryption and recovery work the algorithm in reverse. First, the appropriate private key is used to decrypt the encrypted FEK, and then the FEK is used to decrypt the file.

File Encryption

The file encryption process is illustrated in Figure 6-13 and described in the following steps.

File Decryption

File decryption is illustrated in Figure 6-14 and described in the following steps.

File Recovery

File recovery is also illustrated in Figure 6-14.

Encryption Types and Strengt

The symmetric and asymmetric algorithms used for EFS are industry standards. A Windows Server 2003 computer may be configured to use DESX, 3DES, or AES symmetric encryption algorithms. RC4 is used for asymmetric encryption. Earlier versions of the operating system may not be able to use all of the encryption algorithms. Windows 2000 uses DESX. XP Professional pre-service pack 1 uses DESX by default, but it can be modified to use 3DES. Post-service pack 1, Windows XP Professional defaults to AES but can be modified to use DESX or 3DES. This can mean problems if users attempt to move encrypted files to different OS-based machines and decrypt the files. Caution should be used to select the algorithm that will work in your environment and prevent potential damage by setting all versions of the OS that are capable of doing EFS to use the same encryption algorithm. Instructions for configuring the symmetric key algorithm using the registry are located in the section "Changing Encryption Algorithm," later in this chapter.

Another way to manage the file encryption strength for EFS is to modify the Security Option System cryptography: Use FIPS compliant algorithms for encryption, hashing and signing. This setting manages the encryption strength for all operations, including the use of SHA-1 for hashing, 3DES for Transport Layer Security (TLS) traffic and EFS, and RSA for TLS public key exchange.

NOTE: FIPS

The Federal Information Processing Standard (FIPS) 140-1 is required by the U.S. government certification of cryptographic software.

On Windows Server 2003, the default encryption key strength can also be modified. To do so, you must add the value RSAKeyLength to the EFS registry key and set it to a value between 1024 and 16384. The entered value will be rounded to the next multiple of 8. While the Microsoft Base Provider Cryptographic Service Provider (CSP) is used for encryption, if the key strength is greater than 1024, the Microsoft Enhanced Provider CSP will be used.