If CertFindCertificateInStore doesn't find the key pair's certificate in the certificate store, it returns an error. In that case, GetFekFromEncryptedKeys moves on to the next key field. If DecryptFek can't decrypt any DDF or DRF key field's FEK, the user can't obtain the file's FEK. Consequently, EFS denies access to the application opening the file. However, if CertFindCertificateInStore is successful, DecryptFek uses CryptAcquireContext to open a cryptographic session with the security provider that issued the key pair the certificate hash designates. To open the session, CryptAcquireContext requires the name of the container storing the key pair, the name of the cryptographic provider, and the cryptographic provider's type. DecryptFek obtains this information by invoking the CertGetCertificateContextProperty CryptoAPI before calling CryptAcquireContext.
Although an EFS attribute's key fields store the key pair container name, provider name, and provider type, in Win2K beta 3, DecryptFek doesn't use the key fields' data. Win2K's release version EFS might use this information, however, to help it directly access a key pair by using CryptAcquireContext. Using the data stored in the key fields means EFS won't have to query the cryptographic provider for the container and provider name and provider type via CertGetCertificateContextProperty. This optimization can significantly speed EFS's access to encrypted files.
After DecryptFek opens a cryptographic session with the provider, DecryptFek accesses the user's private key via a call to CryptGetUserKey. DecryptFek never directly accesses the user's private key; rather, DecryptFek uses the call to CryptGetUserKey to tell the provider that DecryptFek wants to perform subsequent cryptographic functions with the user's key pair. Finally, DecryptFek invokes the CryptDecrypt CryptoAPI function to decrypt the FEK with the user's private key. As an extra security measure, DecryptFek calls the function EfspValidateEfsStream after CryptDecrypt decrypts the FEK. EfspValidateEfsStream obtains a Message Digest 5 (MD5) hash of the EFS attribute and decrypted FEK and compares the MD5 hash with the hash value that the EFS attribute's header stores. A mismatch between the hashes indicates that the EFS attribute is corrupt. In this case, EFS reads the current list of recovery agents, recomputes the checksum, applies the new EFS attribute to the file, then rebuilds the EFS attribute's DRF entries. By updating the DRF entries, EFS ensures that recovery agents can always access a file's data, even when the file's DDF entries are corrupted.
Because DecryptFek processes DDF and DRF key rings when decrypting a FEK, DecryptFek automatically performs file-recovery operations. If a recovery agent that isn't registered to access an encrypted file (i.e., it doesn't have a corresponding field in the DDF key ring) tries to access a file, EFS will let the recovery agent gain access because the agent has access to a key pair for a key field in the DRF key ring. EFS adds recovery-agent DRF entries to a DRF key ring for each recovery key pair in the system. A systems administrator can make any number of users recovery agents by assigning them access to an EFS recovery key pair.
Keeping EFS Attribute Information Up-to-Date
EFS ensures that the information the EFS key fields store is always current. For example, users might receive new EFS certificates, or they might receive a new EFS key pair if their original pair is compromised. If the key field for which DecryptFek successfully decrypted the FEK is in the DDF key ring of the EFS attribute, DecryptFek calls UserKeyCurrent. If the field is in the DRF key ring, DecryptFek calls RecoveryInformationCurrent. These functions complete the same basic operation: They both compare the SID, cryptographic provider name, cryptographic container name, and cryptographic hash value stored in the EFS attribute with the user's SID and the properties of the user's current EFS cryptographic key pair. The HKEY_CURRENT_USER\Software\ Microsoft\WindowsNT\CurrentVersion\EFS\CurrentKeys\ CertificateHash Registry key stores the user's active EFS key pair certificate hash. If any of the components in the key field don't match the current key pair's properties, including the user's SID, EFS must update the key field.
To update a key field in the DDF, DecryptFek calls ReplaceUserKey. To update a key field in the DRF, DecryptFek calls UpdateRecoveryInformation. These functions perform the same steps that ConstructKeyRing performs when a user encrypts a file for the first time. However, ReplaceUserKey and UpdateRecoveryInformation update the key fields instead of creating new fields. Both functions add the updated field to the end of the DDF or DRF key ring of the EFS attribute, then delete the old field.
After DecryptFek successfully obtains the file's FEK, control returns to LpcEfsDecryptFek, which allocates a virtual memory buffer and copies the FEK into the buffer. If the user's profile loaded specifically for the FEK decryption, LpcEfsDecryptFek unloads the profile and returns the decrypted FEK to the EFS driver via an LPC reply message. The EFS driver's EFSFilePostCreate function copies the decrypted FEK from the buffer into a kernel buffer. Then, in a somewhat odd move, EFSFilePostCreate sends a control command to itself by way of the NTFS driver. This control command executes the SetEfsData function in the EFS driver, which takes the decrypted FEK and associates it with the opened file. The control command also updates the file's EFS attribute if EFS updated a DDF or DRF field. As with all control commands that the EFS driver interprets, EFS encrypts this command using DESX and the EFS session key before sending it.
Decrypted FEK Caching
Traveling the path from EFS to LSASRV and back can take a relatively long time—in the process of decrypting a FEK, CryptoAPI uses results in more than 2000 Registry API calls and 400 file-system accesses on a typical system. The EFS driver, with the aid of NTFS, uses a cache to try to avoid this expense.
As I've described, NTFS keeps the EFS context information that the EFS driver associates with a file, and NTFS passes the context information to EFS when invoking an EFS callback function. NTFS stores EFS context information with NTFS's file context information, or file control block (FCB). After a user opens a file, NTFS optimizes subsequent opens of that file by keeping the FCB in an FCB table. By doing so, NTFS doesn't need to reconstruct the context information. When NTFS calls EFSFilePostCreate, NTFS passes the FCB to EFS so that EFS can see whether the FCB stores EFS's context information. If the FCB does store EFS's context information, EFS can choose to bypass the FEK decryption because EFS's context data stores the decrypted FEK.
EFS maintains a cache that stores user SID/EFS attribute-hash pairs. After a FEK is successfully decrypted, EFSFilePostCreate calls EfsRefreshCache to create a cache entry for the decrypted FEK. Thus, before EFSFilePostCreate goes to the trouble of requesting LSASRV to decrypt a file's FEK, EFSFilePostCreate looks in the FCB that NTFS handed to EFS to see whether EFS's context information is present. If the FCB contains the EFS context data, EFS has already decrypted the file's FEK. Therefore, EFSFilePostCreate calls EfsFindInCache to look for an entry in the EFS cache that contains the current user's SID (extracted from the token of the process opening the file) and the EFS attribute hash (taken from the FCB's EFS context information). If EfsFindInCache finds this entry, EfsFindInCache runs a check to determine whether the entry was created more than 5 seconds earlier. If the entry is older than 5 seconds, EFS discards the entry and follows the usual path through LSASRV to decrypt the FEK. If the entry is younger than 5 seconds, EFS uses the copy of the decrypted FEK in the EFS context data that the FCB has already associated with the file.
Decrypting File Data
After an application opens an encrypted file, the application can read from and write to the file. NTFS calls the EFS callback EfsRead to decrypt file data as NTFS reads the data from the disk, and before NTFS places the data in the file system cache. Similarly, when an application writes data to a file, the data remains in unencrypted form in the file system cache until the application or the Cache Manager uses NTFS to flush the data back to disk. When an encrypted file's data writes back from the cache to the disk, NTFS calls the EFS callback EfsWrite to encrypt the data.
NTFS passes the file's FCB as a parameter to both EfsRead and EfsWrite. The FCB contains the file's EFS context data, and the EFS driver uses the file's decrypted FEK, which the EFS context data includes, to perform DESX decryption or encryption of file data buffers. The EFS driver performs encryption and decryption in 512-byte units. The 512-byte size is the most convenient for the EFS driver, because disk reads and writes occur in multiples of the 512-byte sector.
Backing Up Encrypted Files
An important aspect of any file encryption facility's design is that file data is never available in unencrypted form except to applications that access the file via the encryption facility. This restriction particularly affects backup utilities, in which archival media store files. EFS addresses this problem by providing a facility for backup utilities so that the utilities can back up and restore files in their encrypted states. Thus, backup utilities don't have to be able to decrypt file data, nor do the utilities decrypt file data in their backup procedures.
Backup utilities use the new EFS APIs OpenEncryptedFileRaw, ReadEncryptedFileRaw, and WriteEncryptedFileRaw in Win2K to access a file's encrypted contents. The advapi32.dll library provides these APIs, which all use LPC to invoke corresponding functions in LSASRV. For example, after a backup utility opens a file for raw access during a backup operation, the utility calls ReadEncryptedFileRaw to obtain the file data. The LSASRV function EfsReadFileRaw issues control commands (which the EFS session key encrypts with DESX) to the NTFS driver to first read the file's EFS attribute, then the encrypted contents.
EfsReadFileRaw might have to perform multiple read operations to read a large file. As EfsReadFileRaw reads each portion of such a file, LSASRV sends a remote procedure call (RPC) message to advapi32.dll that executes a callback function that the backup program specified when it issued the ReadEncryptedFileRaw API. EfsReadFileRaw hands the encrypted data it just read to the callback function, which can write the data to the backup media. Backup utilities restore encrypted files in a similar manner. The utilities call the WriteEncryptedFileRaw API, which invokes a call-back function in the backup program to obtain the unencrypted data from the backup media while LSASRV's EfsWriteFileRaw function is restoring the file's contents.
Viewing EFS Information
EFS has other APIs that applications can use to manipulate encrypted files. For example, applications use AddUsersToEncryptedFile to give additional users access to an encrypted file and RemoveUsersFromEncryptedFile to revoke users' access to an encrypted file. Applications use QueryUsersOnEncryptedFile to obtain information about a file's associated DDF and DRF key fields. QueryUsersOnEncryptedFile returns the SID, certificate hash value, and display information that each DDF and DRF key field contains. Screen 1 shows the output of EFSDump, a utility I developed that displays information that QueryUsersOnEncryptedFile returns. You can see that the file mshtmled.dll has one DDF entry for user Joe and one DRF entry for Mark Russinovich, which is the only recovery agent currently registered on the system. You can download EFSDump, with full source code, from http://www.sysinternals.com/misc.htm.
EFS Caveats
As you use EFS to protect your data, you need to be aware of some important concerns. First, compression and encryption aren't compatible. If you specify both attributes for a file, encryption will override compression.
A more important concern is that even after you encrypt an existing file, the file's original unencrypted data remains where NTFS stored the file on disk before you encrypted it. NTFS eventually reuses this disk space for storing other files and directories, but until NTFS reallocates the space, you can use a disk editor to bypass NTFS (e.g., from within NT or from a DOS boot disk) and directly access the unencrypted file data. The only way you can prevent such access is to run a utility that overwrites all free file system areas to destroy vulnerable information in the disk's unallocated portions. You can download one such utility—Sdelete—including its source code, from http://www.sysinternals.com/sdelete.htm.