EFS Enhancements in Windows XP

When Microsoft released Encrypting File System (EFS) as part of Windows 2000, the company touted EFS as an easy-to-use solution to the problem of protecting confidential documents on stolen laptops. However, users soon discovered a serious weakness in Win2K that rendered EFS effectively useless on Win2K computers that were part of a workgroup rather than part of a Windows NT or Active Directory (AD) domain. In Windows XP, Microsoft provides a solution to this problem. However, as is often the case with Microsoft products, the solution doesn't quite work the way the documentation states it should. Before you start using XP's EFS in your environment, you need to know how EFS data recovery has changed in XP, and you need to understand a key flaw in EFS's new password reset disk feature.

The Win2K EFS Problem
Let's start with a little Win2K EFS background. When you right-click a file in Windows Explorer, select Properties, and click Advanced on the Properties dialog box's General tab, you see the Encrypt contents to secure data check box. When you select this check box, Win2K generates a symmetric file encryption key (FEK) and uses this FEK to encrypt the file. Win2K then uses your EFS certificate's public key (which resides in your user profile) to encrypt the FEK and stores the encrypted FEK with the file. Therefore, the FEK protects the file, and your EFS certificate's private key protects the FEK. But what's protecting your EFS certificate's private key? Simply put, your ability to log on protects your private key. In light of that answer, you might think that Win2K uses your password to encrypt the private key. However, in Win2K, the administrator can reset your password without affecting your ability to access your encrypted files. Although this administrative capability is beneficial in terms of forgotten passwords, it creates a significant vulnerability on workgroup computers—that is, computers that aren't a member of a domain.

Telecommuters and workers in small offices often use workgroup computers when no domain is available. Large organizations that have a Novell NetWare­based network also use workgroup computers. If a computer is in a workgroup rather than a domain, the only way to log on to that computer is to use local accounts that reside in that computer's SAM. Even in a NetWare network, in which you seem to use a Novell Directory Services (NDS) account to log on to your computer, you're actually logging on to the network with your NDS account but logging on to your computer with a local account that the NetWare client automatically creates. Because the account is local, the account's password hash resides in the local SAM instead of on a domain controller (DC). A malicious user can easily use a hacker tool such as Ntpasswd to substitute a new password hash for the user's account in the computer's SAM. Therefore, a thief who steals a workgroup laptop can use Ntpasswd to change the local user's password, then log on as that user and access his or her encrypted files.

In Win2K, the only solution for this problem is to create a domain for laptops and make sure all users have a domain account. When a user logs on with a domain account and encrypts a file, Ntpasswd is useless to thieves because the user's account resides on the DC instead of in the local SAM. (I imagine that a talented programmer could design a utility such as Ntpasswd to defeat EFS by attacking a domain account's cached credentials, but no one has built such a tool yet.)

XP Improvements
What about users who don't have a domain available but still need to protect files with EFS? The answer is XP. With a new technology in XP called Credential Manager, Microsoft has changed the way Windows protects certain user-specific secrets that reside in the user profile. These secrets include stored credentials and certificates (e.g., EFS certificates) that have private keys. On workgroup computers, XP uses the local user account's password to protect certificate private keys and stored credentials for Web pages and file shares. Therefore, although an intruder can still use a tool such as Ntpasswd to change the password and log on as the user, XP will deny the intruder access to the user's encrypted files. This new method of protecting private keys solves the problem of using EFS on workgroup computers, but it introduces a new problem: How can users access encrypted files after they've forgotten their password and an administrator has reset it?

If a user forgets his or her password and has an administrator reset it, the user can regain access to encrypted files in three ways. First, the user can use a new XP feature called a password reset disk, which lets the user reset the forgotten password without involving an administrator. Second, the user can restore the EFS certificate and private key, as long as they were previously backed up. Third, a data-recovery agent can recover the file, as long as an agent is configured for the computer. (The second and third options are also available in Win2K.)