Exam 70-124: Objective 5.4: EFS Architecture and Troubleshooting

The EFS components and the encryption process, along with the EFS file information and the decryption process, are involved in EFS file encryption. In the following sections, we examine each of the elements that make up the EFS architecture. After we examine, in depth, the architecture of EFS, we then look at some common troubleshooting issues that you could encounter while deploying and supporting EFS on your network. They're also pretty good stuff to know for the exam!

Test Day Tip 

Don't get wrapped around the axle here trying to get every last bit of EFS architectural information down cold. This is not something you should expect to see on the exam, but it is provided for your reference should you desire to gain a deeper understanding of how and why EFS works in Windows 2000.

On the other hand, the troubleshooting guide at the end of this section is extremely valuable and something that you should understand not only for this exam but also for the daily support of your EFS users.

EFS Components

In order to understand the entire encryption/decryption process, you need to look at the operating system architecture. Like its predecessor, Windows NT, the Windows 2000 OS structure contains both user mode and kernel mode. When Microsoft developed its data encryption process, the designers had to decide in which mode the encryption code should run. This decision presented some important considerations.

For example, if data encryption were left in user mode, temporary files that were not encrypted would be created, which would defeat the security objective. On the other hand, applications still run in user mode, so when a user requests encryption using Explorer or the Cipher Utility, the activity must start here. The solution: When EFS is implemented, some of the activity occurs in user mode and some in kernel mode.

In earlier versions of the Windows NT operating system, the Local Security Authority Subsystem (LSASS) was in user mode. With Windows 2000, this subsystem takes on additional tasks and includes some additional functions for the Local Security Authority Server in order for EFS to work properly. The functions are grouped as EFS functions. The NTFS driver, which was introduced in Windows NT 3.1, is in kernel mode. Because users can protect sensitive data only on an NTFS partition, this driver has an active role in the overall encryption process. Figure 5.24 shows both old and new components.

Figure 5.24: EFS Components

The key components of EFS are:

• EFS driver  EFS is really a device driver that works in conjunction with the NTFS driver, both of which run in kernel mode. The EFS driver runs on top of NTFS in a layered manner. Whenever a user needs encryption or decryption, the EFS driver works with the cryptography services in Windows 2000 user mode. The EFS communicates with the KsecDD (the security device driver) to request many of the required key management services. When the file system needs to complete an encryption task (which the NTFS driver itself is incapable of performing), the EFS driver takes on the responsibility.

• EFS File System Runtime Library (FSRTL)  This EFS driver module uses NTFS callouts for tasks such as reading, writing, and opening encrypted files and folders as well as encrypting and decrypting data when it is read from or written to disk. Messages are passed between the EFS driver and the EFS FSRTL via the NTFS file control callouts.

• KsecDD  This device driver takes the EFS request and "talks" with the Security Subsystem on behalf of the EFS driver. The KsecDD acts as a connection between the needed local procedure call (LPC) calls and the LSASS in user mode.

• EFS Services  These services are stored in the Local Security Authority Server, which is part of the LSASS. In user mode, the Encrypting File System Services interface with the Microsoft Base Cryptographic Provider 1.0 to provide FEKs and to generate the needed data decryption fields and data recovery fields. The Encrypting File System Service is used to obtain and enforce the encryption data recovery process and to locate the user's key pair when it is needed.

• Cryptographic Service Provider (CSP)  The Cryptographic Service Provider (CSP) provides the key pairs (public and private key) for EFS users and recovery agents. By default, DESX is the encryption algorithm used by EFS. You can configure Windows XP Pro to use 3DES (a significantly stronger algorithm that provides 128- or 168-bit keys) instead. This is done through Group Policy. Microsoft's base CSP is included with the operating system; Microsoft also provides an enhanced CSP that can be used for EFS encryption. Note that if you enable 3DES for EFS, all new encryption operations (both EFS and IPSec) will use it for encryption.

• CryptoAPI  This is the application programming interface that allows developers to add cryptography services to the Win32 applications that they write and is used by EFS for all its cryptographic services. Both symmetric and asymmetric cryptographic operations are supported, including key generation, management and exchange, encryption/decryption, hashing, digital signatures, and signature verification.

Head of the Class…
The EFS Callback Functions

When the EFS driver initializes, it registers seven EFS callback functions with the NTFS driver. These are the current callback functions:

• EfsOpenFile When an application opens an existing file that has EFS attributes, the NTFS driver invokes the EFS callback function EfsOpenFile.

• EfsFilePostCreate After an NTFS file has created or opened a file for an application, the NTFS driver needs the EfsFilePostCreate EFS callback function's help.

• EfsFileControl and EfsFsControl When a user modifies a file's encryption settings, the NTFS driver makes a request for the EFS callback functions EfsFileControl and EfsFsControl.

• EfsRead When NTFS retrieves data for an application, it petitions EFS for the function named EfsRead.

• EfsWrite When the user writes information in an encrypted file, the NTFS driver invokes the EFS callback function known as EfsWrite, because NTFS cannot encrypt the data itself.

• EfsFreeContext For the sake of security, which is what encrypting sensitive data is all about, the NTFS driver invokes the EFS callback function EfsFreeContext when the context data buffer is no longer required.

The Encryption Process

Before EFS encryption can be used in Windows, the EFS device driver must be installed. When the EFS driver initializes, it notifies the NTFS driver of its existence, and it registers seven related functions at that time. In the registration of these functions, the EFS driver seems to be telling the NTFS driver, "Here is a list of tasks I can do for you." (See the sidebar for the list of the EFS callback functions.)

When the NTFS driver receives a request for EFS, it looks into the table of EFS callback functions and invokes the function that the EFS driver must execute. The EFS driver will not communicate directly with the LSASS, which runs in unprotected user mode. The EFS driver sends a request to encrypt or decrypt a file to the LSASS, but an additional driver intercepts this request in kernel mode. The driver used to send the actual LPC message to the LSASS, KsecDD, resides in kernel mode. The Local Security Authority Server, which is part of the LSASS, listens for the LPCs. When the LSASRV receives a call from the File Encryption Client DLL (FEClient) to encrypt a file, it invokes the internal function EfsRpcEncryptFileSrv.

EfsRpcEncryptFileSrv handles the following tasks in the early stages of a file encryption request:

1. Impersonates the user making the encryption request

2. Creates a log file that LSASRV uses to keep a record of the encryption process from start to finish

3. Loads the impersonated user's profile into the Registry

4. Makes a call to the internal function EncryptFileSrv

You might be wondering about the first step-impersonating a user. Impersonation occurs for a reason. The LSASS has always used the System account by default. If this account were used for the encryption process, the System's private key would be needed to decrypt the file. EFS's objective is to encrypt the file and then require a unique private key belonging to the user for any future use. By impersonating the user, the proper private key is used to manipulate the file.

The log file that is created when an encrypt file request is received is used to record the events in the encrypting process. The log file is on the same drive as the encrypted file in the System Volume Information subdirectory. The name of the log file is EFS0.log. If an EFS0.log file already exists, the name of the new log file is generated by incrementing the numeric value by one digit.

This need exists despite the fact that a user's profile has already been loaded into the Registry because logging on the system is mandatory. In most circumstances, the profile would already be loaded, but software engineers cannot leave anything to chance, especially when dealing with security issues. If the user executed the Run As command included in the Windows 2000 and XP/.NET operating systems, which allows a logged-on user to use a different account (such as an administrator's account) to perform tasks, the loaded profile would be the result of logging on the system, not the profile of the user making the encryption request.

When control is passed to the EncryptFileSrv function, an entirely new list of tasks must be performed. EncryptFileSrv is in user mode, and the EncryptFileSrv function takes on the remaining tasks in the encryption process. Specifically, the EncryptFileSrv function is responsible for the following tasks:

1. Queries the NTFS driver about the data stream being used in the file

2. Calls the GenerateFEK function

3. Constructs the EFS information that is stored with the encrypted file

4. Creates a backup file

5. Initializes the log file

6. Sends an encrypted command to the NTFS driver to encrypt the file

In order for the EncryptFileSrv function to generate the FEK, a function called GenerateFek is used. GenerateFek initiates a session with the Microsoft Base Cryptographic Provider and requests to use the RSA encryption algorithm. When GenerateFek has established the session, it calls another function to have the provider generate the FEK. After the FEK is created, the session with the Microsoft Base Cryptographic Provider is closed, and control is returned to the internal EncryptFileSrv function.

EncryptFileSrv uses the FEK and the user's key pair to create the EFS file information. At this point in the encryption process, a key pair is created if the user does not have one. The system can easily identify a user's lack of a key pair by the absence of the CertificateHash value found in the Registry for the current user.

After the EFS file information is built, a backup file named EFS0.tmp is created for the original plaintext file. The security descriptor for this backup file is set up so that only the system account will have access to the file.

EncryptFileSrv now sends an encrypted control command to the NTFS driver to add the recently constructed EFS file information to the original file. The NTFS driver understands an encrypted command in this way: At boot time, EFS receives from the LSASS a session key that is used to decrypt any control command received from user mode. When the NTFS driver receives the encrypted control command, the driver makes a request to the EFS callback function, EfsFileControl. The EFS driver applies the session key to decrypt the control command and adds the EFS file information to the original file. The EFS driver also creates the $EFS NTFS metadata attribute. This attribute was added to the Windows 2000 operating system, and it contains the EFS file information.

After the EFS file information is added to the file, the activity is once again handed back to the EncryptFileSrv internal function, and then EncryptFileSrv performs these tasks:

1. Records in the log file that the backup file was created

2. Sends another encrypted control command to the NTFS driver to encrypt the file at this time

When the NTFS receives the encrypted control command, it makes a request to the EFS callback function EfsWrite. EfsWrite uses the unencrypted FEK to do secret key encryption of the file one sector at a time. The data is encrypted before the NTFS driver writes the data to disk. In the United States, EFS uses a 56-bit standard DESX encryption key.

When the file is completely written to disk in ciphertext form, EncryptFileSrv is handed control once again. The EncryptFileSrv function completes the encryption process by doing these tasks:

1. Records in the log file that the encryption process was successfully completed without errors

2. Deletes the backup copy of the original file

3. Deletes the log file

4. Passes control back to the user

These concluding tasks draw together the built-in, fault-tolerant side of the encryption process. A backup copy of the original file is always available until the encryption process is completed successfully. If a system crash or other fatal error occurs, the log file indicates where the encryption process stopped, and the original copy of the file can be used to redo the entire process.

The EFS File Information

After the FEK has been created, the EFS file information can be constructed. The LSASRV function named EncryptFileSrv controls the creation of the EFS file information that is stored with the file. The user's key pair is needed to supply the necessary information in the encrypted file's header. The function CryptoAPI is called to get a handle to the needed key pair. If the user does not have a key pair and if this is the first file to be encrypted, a key pair must be created. The function GenerateUserKey is used to create the key pair and returns the signed certificate for the pair.

The generation of the key pair will happen on a domain controller or on the local machine as determined by the computer's environment. When the signed certificate is received, it is stored in the Registry in the subkey HKEY_CURRENT_USER\Software\Microsoft\ WindowsNT\CurrentVersion\EFS\ CurrentKeys\CertificateHash.

Now that EncryptFileSrv has the user's key pair, a function is used to obtain information about the provider that was used to generate the key pair. The user information that is needed at this point is the provider's name and the container used to store the key pair, which in fact is nothing more than a file specification.

An example of a container is as follows:

D:\Documents and Settings\Administrator\Application Data\Microsoft\     SystemCertificates\My\Certificates\1612DAFAD20E037F2DBACD4113FC7         55BC23B6711

EFS now uses the function CryptAcquireContext to set up a cryptographic session with the provider, using the provider's name, the container's name, and the fact that it desires to use the RSA encryption service of the Windows operating system. The provider's name must be identified at this point because the operating system allows software vendors to write their own providers and implement them if they want to. RSA is the public key encryption algorithm that was written by Rivest, Shamir, and Adleman. The provider creates 128 bits of random data that will become the file's FEK, and then a function is called to close the session with the Microsoft Base Cryptographic Provider.

Now that EncryptFileSrv has a FEK, the EFS file information can be constructed and stored with the file. The function GetCurrentKey is used to read the Registry information and get a handle to the user's public key. A Local Security Authority Server function uses the public key to store the EFS information with the file. Figure 5.25 identifies the components that make up the EFS file information.

Figure 5.25: EFS File Information

The data decryption field (DDF) contains entries for each user who has access to the encrypted file. Each individual entry is referred to as a DDF key entry. The components of the DDF key entry provide information to represent a user's public key. The user's security identifier (SID) is a component of the key entry. Also included in the key entry is the provider name and container name, the public/private key pair certificate hash, and the encrypted FEK. Any collection of multiple key entries in the EFS file information is called a key ring.

The EFS file information component of the Encrypting File System is not yet completed. An entry needs to be created that will provide recovery if the user's private key somehow becomes corrupted. The EFS creates another key ring that contains recovery key entries. All information tied to the recovery process is in the file's c (DRF). The information in the DRF entries uses the same format as the DDF entries. The number of entries created here is determined by the recovery agents previously defined using the Recovery Agent Wizard.

That means the Local Security Authority Server will have to read the recovery policy at boot time or when it receives notification of policy changes so that the correct DRF entries can be created. The EFS will use the same provider (typically the Microsoft Base Cryptographic Provider 1.0) to create a DRF entry key for each recovery agent.

The EFS adds recovery agent entries to the DRF section of the EFS file information for each recovery key pair on the system. The system administrator can create any number of recovery agents by assigning their accounts access to an EFS recovery key pair. The number of recovery agents should be kept to a minimum for security reasons.

The final step in building all this EFS information is to calculate a checksum value for the DDF and DRF. EFS stores the checksum value with the other header information. This checksum is tied to the decryption process. In order to guarantee that the EFS file information has not been changed, the checksum is used for verification during the decryption process.

The information saved with the encrypted file as the EFS file information must be current; otherwise, users who are issued new certificates will be unable to access their protected, encrypted files. To compensate, when the key field that can successfully decrypt the FEK is located, a function is used to compare the SID, provider name, container name, and certificate hash value to the properties of the user's current EFS cryptographic key pair. If any of the information in the key field does not match the current Registry values, the key field is updated in the EFS file information. If the key field needs to be updated, a new key field is created containing the new matching information, and then the old key field is deleted.

The Decryption Process

When a user accesses an encrypted file, the decryption process begins. Once again, this lengthy process is transparent to the user. The following discussion is highly technical and discusses what goes on "under the hood" when a file or folder is decrypted. From the user's point of view, if he or she has authority to access the encrypted file, the file is automatically decrypted and displayed as plaintext when the user opens it. (If an unauthorized user attempts to open it, he or she will receive an "Access denied" message.)

As is the case when any file on an NTFS volume is accessed, the NTFS driver looks at the file's attributes. If the file is indeed encrypted, the NTFS driver invokes the EFS callback function, EfsOpenFile, which EFS registered at the time it initialized. The task of reading the EFS attribute is now handed over to the EFS driver. The EFS callback function, EfsOpenFile, then performs the following tasks:

1. Opens the Encrypting File System attribute

2. Calls the NTFS function NtOfsQueryLength to determine the attribute's length

3. Allocates the appropriate amount of buffer space based on the length

4. Copies the EFS attribute to the buffer

If the EFS attribute fails to open for any reason, the user receives an error message. If the EFS attribute successfully opens, the NTFS driver again invokes a registered EFS callback function, this time named EfsFilePostCreate.

If all has gone smoothly, EfsFilePostCreate's job is to make sure that the user requesting to open the file has access to the file's encrypted data. In order for the user to have access to an encrypted file's data, the user needs a private key to decrypt the FEK, which in turn is used to decrypt the file itself.

The actual decryption of the FEK is handled by the Local Security Authority service, which resides in user mode. To perform the FEK decryption, the EfsFilePostCreate sends an LPC message to the LSASRV by way of KsecDD. The Microsoft Base Cryptographic Provider is used to encrypt and decrypt. This cryptographic provider functions in user mode and is attached to the LSASS.

Much as is the case with the encryption process, impersonation must occur in the LSASS process when the user opens the file, because the LSASS executes using the System account. This impersonation must be set up before the KsecDD sends the LPC message to LSASRV and is handled by the EfsFilePostCreate EFS callback function.

When the LSASRV receives the LPC message from KsecDD, a function call is used to load the user's profile into the Registry if it is not already there. A second function call named DecryptFek is called to perform the actual file decryption.

This DecryptFek has some additional tasks to complete before it actually decrypts the file. The DecryptFek must use the EFS certificate hash, stored as a component of the key entry, to identify the private key to be used. DecryptFek uses the user's private key to try to decrypt the ciphered FEK in each key entry in both the DDF and the DRF of the EFS file information.

When every DDF and DRF entry has been tried with the result that the entry's FEK cannot be decrypted, the user is denied access to the file, but if a private key can decrypt the FEK, a cryptographic session with the Microsoft Base Cryptographic Provider is established. Similarly to the encryption process, in establishing a session with the Microsoft Base Cryptographic Provider, the container name and the provider name must be known, but this time the information is indicated by the key fields of the EFS file information.

After the session with the provider is created, the FEK decryption is completed via the user's private key. As an added security step, the hashing of the EFS attribute and the decrypted FEK take place and are compared with the checksum value located in the header information. Any different values seen here indicate that the file has been compromised in some way, and an error results. If the file isn't compromised in any way, Windows establishes another session with the Microsoft Base Cryptographic Provider. This session uses the plaintext FEK and the RSA algorithm to completely decrypt the file.

Troubleshooting EFS

Even though EFS is almost foolproof, you could encounter trouble with it from time to time. Table 5.5 outlines some of the more common problems and their corrective actions.

Exam Warning 

These troubleshooting issues are all likely exam questions. The most important point to remember when trying to troubleshoot EFS issues is to determine what has changed and what has not changed. Remember the finer points of working with EFS, such as delegating remote servers for EFS encryption and the effects of encrypting a document with a different user account than you are trying to decrypt it with. Some of the EFS questions can be quite tricky if you do not approach them carefully and methodically.

Table 5.5: Troubleshooting EFS

Problem	Corrective Action
I cannot add multiple users to an encrypted document	This feature is only supported in Windows XP Professional and Windows .NET Server, not in Windows 2000.
I cannot add multiple users to an encrypted folder.	You must add additional users to individual files themselves, not to folders. Note that this feature only works in Windows XP Professional and Windows .NET Server, not in Windows 2000.
I've lost my private keys and I need to decrypt some important documents	The EFS Recovery Agent will have to decrypt these files for you. The best way is to recover the files from backup onto a decryption workstation, remove the encryption bit, and then copy them back to their original location. You can then re-encrypt the files with your new certificate and keys.
I want to create a new EFS Recovery Agent, but I cannot. I keep getting an error message at the end of the process.	The most likely reason for this error message is either that you have no CA in place or the CA cannot be contacted to complete the process. Ensure that you have a functioning CA installed and configured on your network and that it has basic network connectivity with the computer from which you are performing your request.
I try to encrypt files, but I cannot.	Any number of things could be the cause of this issue. Check to see that you have proper NTFS permissions for the file, that you have an EFS Recovery Agent Policy in place, that the file is not NTFS compressed, and that the volume the file is located on is NTFS formatted.
I cannot open a file that I had previously encrypted.	Most likely, the certificate that you used to encrypt the file has expired. If it cannot be located (they can be deleted), you will have to initiate an EFS Recovery procedure to decrypt the file again.
I can't tell if my files are encrypted or not.	The easiest way to get a detailed listing of file encryption status is to use the cipher command from the command line. Execute it from the directory where your files are located, and it will report back the encryption status of each file.
I cannot decrypt files on my portable computer. I just encrypted them last week. We have a Windows 2000 Active Directory network.	It is possible that the files were encrypted using a local user account instead of a domain user account. Attempt to decrypt them using a local user account. You can then later re-encrypt them using your domain user account.
My antivirus program complains that there are several files on the volume that it cannot read.	This is a common occurrence where multiple users have encrypted files on a particular volume. The virus-scanning program is only able to scan the files that have been encrypted by you.
I am trying to encrypt a file on the file server and get an error message saying the server is not trusted.	Remote file servers that you will enable EFS encryption on must be trusted for delegation. This is done from the server properties in Active Directory Users and Computers.