Using the Encrypting File System

The Encrypting File System supported in Windows 2000 and XP/.NET is a security feature built into the NTFS file system. In order to encrypt a file (or folder) in any of these operating systems, the file (or folder) must be located on an NTFS 5 volume. NTFS 5 is the version that is created with a Windows 2000 installation. Both public key encryption and secret key encryption (discussed later in this chapter) are implemented within the complete process, so data is encrypted quickly and in such a way that it can stand up against an attack from cryptanalysts (people who specialize in analyzing and "breaking" encryption algorithms). U.S. customers who purchase Windows 2000 receive a 56-bit standard DES algorithm for implementation, but U.S. customers can also obtain a 128-bit encryption DES algorithm. Until export approval is received, Microsoft also has a 40-bit DES algorithm for all international customers.

An encrypted file can be read by anyone with a private key that can decrypt the File Encryption Key. In the Windows 2000 implementation of EFS, only the user who encrypted a file and a designated recovery agent (usually the network administrator) can decrypt the data. The version of EFS included in Windows XP/.NET adds the capability to share encrypted files with others.

The provision of a recovery agent is important in the implementation of EFS in the business environment. If a user leaves a company or if a user's private key becomes corrupted or is accidentally deleted, the recovery agent can implement data recovery. This might sound like a security weak spot, but data recovery in Windows is not a security weakness.

Microsoft has written code to establish an Encrypted Data Recovery Policy (EDRP), which controls who can recover data if the owner's private key is lost or if an employee leaves the organization. In a workgroup environment, Windows automatically sets up the EDRP on the local machine. In a domain environment, the EDRP is set up in the domain policy by the system administrator, and computers belonging to the domain will receive the EDRP from that location.

If a computer is not a member of a Windows 2000 domain and you force an administrative password change on the user account that was used to encrypt the files, those files become unrecoverable. In a domain environment, you have more recovery options for EFS files.

Test Day Tip 

If you want to store encrypted files on a remote server, the server must be trusted for delegation. You must be a domain administrator to configure the server as trusted for delegation. This is done through the Active Directory Users and Computers console. For detailed instructions, see Microsoft Knowledge Base article Q307877. Also note that you will not be able to access encrypted files from Macintosh clients.

Encryption Fundamentals

As mentioned previously, encryption is the process of taking a plaintext file and processing it so that the original data is in a new ciphertext (unreadable) format. Typically the encryption process uses an algorithm and a secret value that is referred to as the key.

Public Key, or Asymmetric Cryptography

Public key cryptography is designed so that each person in the communication has two keys: a public key and a private key. The two keys are mathematically related, but the private key cannot be discovered by knowing the public key. Table 5.1 identifies the differences between these two keys in typical use.

Table 5.1: Public and Private Keys

Key	Description	Use
Private	Never made known to anyone but the user.	Decryption.
Public	Known worldwide.	Encryption.

Public key cryptography is also known as asymmetric cryptography because users employ different keys to encrypt and decrypt a file. Public key-based algorithms usually are highly secure, but they are considered slow. Figure 5.1 illustrates the basic processes of public key encryption and decryption.

Figure 5.1: Public Key Encryption and Decryption

Head of the Class…
Public Key Cryptography

Public key pairs can be used as described to provide confidentiality of data. A message sender uses the recipient's public key to encrypt it, then sends it to the recipient, who uses his or her own private key to decrypt it. Only the private key that belongs to the same key pair as the recipient's public key will work. Another use for public key cryptography is to provide authentication of a message sender's identity. For this purpose, the sender encrypts the data with his or her own private key and sends it to the recipient who uses the sender's public key to decrypt it. Because the public key is available to anyone, there is no confidentiality, but because only the private key associated with the sender's public key could have been used to encrypt it (otherwise the public key wouldn't work to decrypt it), the recipient can be assured that the message came from the sender.

Secret Key, or Symmetric Cryptography

Instead of a key pair, symmetric cryptography uses a single, shared secret key. The same key is used for both encrypting and decrypting the data.

One popular method of symmetric cryptography is the Data Encryption Standard (DES), which the National Bureau of Standards defined in 1977 for commercial and nonclassified use. Developed by a team of IBM engineers who used their Lucifer cipher and input from the National Security Agency, DES is an encryption algorithm that uses a 56-bit binary number key.

Secret key algorithms are implemented quickly. Because the DES algorithm uses a single key for both encrypting and decrypting data, this security mechanism is weaker in its design than asymmetric methods. Symmetric cryptography requires some mechanism for sharing the secret key, and this requirement exposes it to the possibility of interception. Figure 5.2 illustrates the secret key algorithm method.

Figure 5.2: Secret Key Algorithm

One major difference between symmetric and asymmetric algorithms is the number of keys that are used in the process. Public key algorithms use a key pair, but secret key algorithms use a single key. This major difference can clearly be seen in Figures 5.1 and 5.2.

What the figures do not show is the difference between the two algorithms in terms of the amount of time needed to fully process the encrypting and decrypting of the file. Because of this speed difference, asymmetric algorithms are most useful for small amounts of data. Symmetric algorithms can be used to efficiently encrypt large amounts of data. Public key encryption is a slower-process method than secret key encryption, so the two should be implemented appropriately. The two encryption technologies can be used together for the optimum balance between performance and security.

How EFS Works

Microsoft implements both secret key encryption, which is a faster and less secure process, and public key encryption, which is a slower but more secure process. When the operating system receives a request to encrypt a file, the Encrypting File System generates a random number for the file. This random number is known as the file's File Encryption Key (FEK). With the FEK, a modified DES algorithm, called DESX, is used to generate the encrypted file and store it on disk. The secret key algorithm is being implemented at this point. Figure 5.3 shows a diagram of the EFS encryption process.

Figure 5.3: The EFS Encryption Process

When a file needs to be decrypted, the FEK is used again. If you store the FEK on disk with the file, you have the FEK available for decryption at any time. Anyone who needs to decrypt the file and who has access to it also has access to the file's FEK.

Keeping sensitive data secure is the most important concern, but convenience is also important. Experience shows that when a security process is inconvenient for users, they are less likely to use it. The FEK is stored on disk and is available whenever it is needed, so the process is convenient and quick, but anyone who can get to the file will have available the one item needed for decrypting the file. This means you must address the security of the FEK itself. Secret key encryption is weak in this aspect, but public key encryption can be used here to good effect. Thus, to tighten the FEK's security, you can encrypt it also. This is where public key cryptography comes in.

When a user encrypts a file, the Encrypting File System uses the user's public key to encrypt the FEK. This design prevents users from sharing one decryption key. In Windows 2000, multiple users cannot share encrypted files. The public key encryption method is used only on the small FEK, so the system's performance isn't impacted. The ciphered FEK is stored with the encrypted file. Only the user, with that user's private key, can decrypt the ciphered FEK, which is needed to decrypt the actual file. At this point, both the sensitive data and the FEK are secured. The slow method of public key algorithm is not used on the large file. The final design of file encryption for Windows 2000 allows you to get the best from both encryption worlds.

Note 

File encryption keys are stored in the nonpaged memory pool. This means the keys will never be in the paging file, which would create a security risk.

Windows XP/.NET enables support for sharing EFS encrypted files among multiple users, without sharing private keys among users. The file must first be encrypted by one user, who can then enable sharing and select the specific users who are to have access to the encrypted file. Any user who has an account on the local machine or in the Active Directory and who has a valid EFS certificate can be added. Each authorized user can then decrypt the file using his or her own private key.

Exam Warning 

You might be wondering about the security of temporary files that are used by some programs. Because of the way the NTFS file system works, temp files do not present a security problem. When temp files are created, all the attributes from the original file (including the encryption attribute, if it is present) are copied to the temp files. This means EFS encrypts the temporary copies as well as the original file.

It is for this reason that Microsoft recommends setting the encryption attributes on folders rather than individual files. Keep this in mind when asked about configuring and implementing EFS on your network and during this exam.

Now let's pull all these loose ends together into a clear, precise picture. In the following sections, we look at the "how to" aspects of using EFS to protect your data.