EFS Enhancements in Windows XP

The upgrade comes with a key flaw

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.)

XP's Password Reset Disk
XP lets the user create a password reset disk, then use that disk to access his or her computer after forgetting the password. The password reset disk contains a secret key that's based on the user's current password. In the event of a forgotten password, XP can verify that the disk is authentic for the user, accept a new password from the user, and use the new password to reprotect secrets (including the EFS certificate's private key) that reside in the user profile. The Microsoft article "HOW TO: Create and Use a Password Reset Disk for a Computer That Is Not a Domain Member in Windows XP" (http://support.microsoft.com/default.aspx?scid=kb;en-us;q305478) explains two methods of creating a password reset disk.

According to the XP documentation, if you're an administrator of the local computer, you can create a password reset disk for any user on that computer. XP requires that you know the user's current password or have the user present when you create the password reset disk. This requirement prevents a malicious user from simply using Ntpasswd to reset the administrator's password, then logging on as the administrator, creating a password reset disk for the desired user, and accessing the user's encrypted files. (If an intruder can gain physical access to a computer twice over a certain period of time, he or she can still feasibly access encrypted files. For more information about this vulnerability, see the Web sidebar "Patience Is Key," http://www.secadministrator.com, InstantDoc ID 25484.) However, despite what the documentation says, an XP administrator can't actually create a password reset disk for another user—the necessary menu options simply don't exist. In the current release of XP, a user can create a password reset disk only for himself or herself.

To create a password reset disk for yourself, open Control Panel, click User Accounts under Pick a Category, and click Related Tasks, Prevent a forgotten password. A wizard prompts you to enter your current password. (You won't be able to proceed unless you enter the correct password.) The wizard then asks you to insert a disk and copies the password information to the disk. After you're finished, be sure to remove the disk and store it in a safe place. For security purposes, treat the password reset disk as you would a piece of paper on which you've scrawled your password—anyone can use the disk to log on and access your confidential, encrypted files. If you later forget your password, you can use this disk to reset it.

Should you enter an incorrect password when you log on, XP notifies you of the error, then lets you request a password hint (if you entered a hint at the time you changed your password). Alternatively, you can click use your password reset disk, as Figure 1 shows. XP then prompts you to insert the disk and enter your new password twice. Now you can use your new password to log on and access your encrypted files.

Microsoft claims that you need to create a password reset disk only once for the lifetime of your user account, regardless of how many times you change your password. And you can indeed use a password reset disk to reset an account whose password you've changed since you created the disk, then log on with that new password. However, if you then try to open an encrypted file in XP, the system will deny access. Apparently, XP stores data based on your password reset disk in the SAM along with your user account, and this stored data doesn't change when you change your password. Each time you change your password, XP uses your new password to reprotect the secret information in your user profile—including your EFS certificate's private key. But when you try to access an encrypted file, XP fails to unlock your EFS certificate's private key because the key is protected by your old password.

You can, however, encrypt new files. When you encrypt a new file, XP simply creates a new EFS certificate and uses your new password to protect the certificate's private key. Later, if you suddenly remember your original password, you can still access your encrypted files because XP can successfully unlock the private key in your old certificate. In this scenario, you can access files protected by your old and new private keys, even after future password changes.

As you can see, XP's password reset disk feature is an innovative, though flawed, solution to forgotten passwords. However, if you plan to rely on the password reset disk and use EFS to protect confidential files, you must be careful. Despite Microsoft's claim to the contrary, XP accepts only the most recent password reset disk for a particular user; old password reset disks are invalid. Train your users to always recreate their password reset disk after they change their password, and make sure users understand how to safely store the disk. Also, be aware that a password reset disk won't work on a computer other than the one on which the disk was created—even for user accounts that have the same name and password.

EFS-Certificate and Private-Key Backup
Given that password reset disks can give you a false sense of security and are vulnerable to theft, you might choose an alternative method of granting a user access to his or her encrypted files. One alternative is to back up the EFS certificate and private key. If you have your EFS certificate and private key, you can always obtain your confidential data.

The first time you use your user account to encrypt a file, XP automatically creates your EFS certificate. You can use the Microsoft Management Console (MMC) Certificates snap-in to view and back up this certificate. To do so, enter

mmc

at the command line and select File, Add/Remove Snap-in. Click Add. Double-click Certificates, then click Finish, Close, and OK. Next, select Console Root, Certificates - Current User, Personal, Certificates. Figure 2 shows my EFS certificate. To back up a certificate, right-click the certificate and select All Tasks, Export. On the Certificate Export Wizard's first page, click Next, then click Yes, export the private key. (A backup copy of your certificate is useless without the private key.) After you click Next twice, the wizard asks for a password with which to protect this key. You won't be able to restore the certificate without this password, so make sure you remember it. Enter the password twice for confirmation, then click Next. The wizard asks for a filename. You can save this certificate and private key either to a disk or to a shared folder on your network. The latter option is convenient if you manage many laptops but introduces a significant security risk. Remember that a skilled attacker who can obtain a copy of the user's certificate and private key and gain access to the user's computer might be able to gain access to the user's encrypted files. Therefore, you might ultimately decide to move backup certificates to an offline CD-ROM that you store in a secure place.

Now that you have a backup of the user's EFS certificate, you're protected against password-reset situations in which the user loses access to encrypted files. If the user uses an outdated password reset disk (a disk made before one or more subsequent password changes) to reset his or her password, or if an administrator of the local computer resets the user's password, the user will lose access to encrypted files, as I explained earlier. However, you need only to re-import the backup of the user's EFS certificate and private key. When you re-import a certificate, XP—unlike Win2K—replaces the old certificate with your backup certificate and uses your current password to reprotect the certificate's private key.

To re-import a certificate and private key, open the Certificates snap-in. Instead of right-clicking your current certificate, select Action, All Tasks, Import, then click Next in the Certificate Import Wizard's first window. Click Browse and change File Type to Personal Information Exchange, which is the default file type for exporting a certificate. Highlight the certificate file and click Next. Enter the password you specified when you exported this certificate and Click Next twice, then Finish. You should now be able to access your encrypted files again.

Data-Recovery Agent
If you're already familiar with EFS from Win2K, you might be thinking of another way to regain access to encrypted files—by logging on as the data-recovery agent. EFS provides functionality for a data-recovery agent as a fail-safe method to prevent lost information in the event that the user's private key is lost or unavailable. On a Win2K computer, EFS disables file encryption unless you've specified at least one data-recovery agent in the Local Security Policy. By default, Win2K computers automatically use the built-in administrator account as the recovery agent. In XP, Microsoft removed this requirement so that, by default, no recovery agent exists. So don't plan to use data-recovery functionality unless you've configured the computer with a data-recovery agent and backed up the agent's certificate.

Don't Depend on It
I like XP's new password reset disk feature not because of the convenience for users who forget their passwords but because the feature makes EFS on workgroup computers less vulnerable to password-reset tools such as Ntpasswd. However, you can't depend on password reset disks to preserve access to encrypted files. A password reset disk becomes outdated if the user doesn't recreate it each time he or she changes a password.

Users can also lose access to their encrypted files if they reinstall XP or Win2K. Even if the users have backed up the files to disk or other backup media, they can't access those files after reinstalling the OS. When you reinstall XP or Win2K, you create a new SAM, user account, and user profile that have no record of your old EFS certificate. To access your files again, you'll need to restore a backup of your certificate and private key. The same applies if you restore encrypted files to a new computer: To access the files again, simply re-import the certificate and private key.