Date: Jun 25, 2004
Article is provided courtesy of Sams.
Compared to Windows 2000, the new implementation of the Encrypting File System (EFS) in Windows XP/2003 has some pitfalls. Zubair Alexander examines these issues and provides some pointers for planning an EFS strategy for your business environment.
The Encrypting File System (EFS) in Windows XP and Windows 2003 includes several features that were not included in the Windows 2000 EFS. In this article, we'll look at the major differences between the Windows 2000 EFS implementation (let's call it "the older EFS") and the Windows XP/2003 implementation ("the newer EFS"). We'll focus on the way in which Microsoft implements the newer EFS, as well as various EFS issues such as resetting users' forgotten passwords and RAS users getting Access Denied error messages.
At the end of this article, I offer some recommendations for planning a business EFS strategy to ensure that you don't lose your important data. Data that's important enough for you to encrypt had better not be lost due to incorrect implementation!
New Features of EFS
Compared to Windows 2000, the newer EFS version in Windows XP and Windows Server 2003 includes several changes. Here's a list of some of the new features:
Encrypted files are marked green so you can easily distinguish them.
You can share your encrypted files with other individuals.
EFS offers a client-side caching that's used with the offline folders feature.
EFS offers kernel-mode FIPS-compliant cryptography.
Files can be encrypted even if there's no Data Recovery Agent (DRA).
In Windows Explorer, choose Tools, Folder Options. On the View tab, select the option Show Encrypted or Compressed NTFS files in Color. This setting makes compressed files appear in blue and encrypted files in green.
You can share encrypted files with other individuals, but not groups. A user with whom you want to share encrypted files must have an encryption certificate on your computer. This can be achieved by a couple of methods: The user can log onto your computer and encrypt a file; or a network user can simply export his or her certificate and you can then import the certificate on your computer.
This feature is useful for mobile computers because users can work on files even when not connected to the network. The files are cached on the user's hard drive. When the user reconnects to the network, the local files are synchronized with the files on the network. Unlike Windows 2000, both Windows XP and Windows Server 2003 let you encrypt offline files.
Federal Information Processing Standard 140-1 (FIPS 140-1) and FIPS 140-2 are U.S. government standards that provide a benchmark for implementing cryptographic software. Some U.S. government agencies purchase only products that are FIPS-compliant. In Windows XP/2003, you can use a group policy option called system cryptography: Use FIPS compliant algorithms for encryption to configure clients to be FIPS-compliant.
Unlike Windows 2000, the newer version of EFS allows encryption of files even without a DRA.
Now that we've looked at some of the new features in EFS, let's closely examine some of the issues related to encryption in Windows 2000 and Windows XP.
Don't Shoot Yourself in the Foot
In Windows 2000, Microsoft didn't allow you to encrypt files if there was no DRA. A DRA is an agent that has been issued an X.509v3 certificate and has permissions to decrypt data encrypted by other users. In a domain environment, the domain administrator is the DRA. In Windows 2000 Professional, the built-in local administrator is the DRA. By default, in Windows XP there's no DRA.
The reason that Microsoft didn't allow use of EFS if the DRA was deleted was to protect users from losing important encrypted data. If somehow the private key was lost, DRA could come to the rescue by recovering the files. That was a good thing. The new EFS implementation in Windows XP/2003 doesn't care whether you have a DRA; it lets you encrypt files even if you delete the DRAor, in case of Windows XP, never create one. Therefore, you need to ensure that you have at least one DRA before you encrypt files. Also, make sure that the DRA is not the account that you normally use to log on and encrypt files.
If You Forget, You Will Regret
If you've backed up your private key and EFS certificate, you can always restore it to recover your encrypted files. This is true both in Windows 2000 and Windows XP/2003. The same is true if you have a DRA configured at the time the files were encrypted, because the DRA can recover your files for you. However, things get rather messy when a user forgets the password. Let's look at both Windows 2000 and Windows XP behavior in that scenario.
In Windows 2000, if a user forgets a password, the administrator can reset the password and it has no effect on the user's encrypted files. This is true whether the user logs onto the domain or to a standalone computer in a workgroup. However, a hacker can easily use a third-party tool such as Ntpassword to replace the password hash in the local Security Accounts Manager (SAM)and gain complete access to the user's encrypted files by logging on as that user.
In Windows XP, Microsoft has improved the security on EFS certificates; the certificate's private keys are now protected with your local account's password. If a user forgets the password and the administrator resets the password for a domain account, no harm is done; the user can continue to access the encrypted files. In a workgroup environment, when the local administrator resets a user's password, the Data Protection API (DPAPI) master key is lost and the user can't access the private key associated with the encrypted files. The DPAPI master key is used to help protect EFS private keys and other certificate-based functions. When the administrator tries to reset the password, the warning shown in Figure 1 is displayed. In short, the user cannot access encrypted data on a standalone Windows XP computer once an administrator resets the user's password. Furthermore, even if a hacker can log on as the user by using a utility such as Ntpassword, the hacker cannot read the encrypted files in Windows XP in this scenario.
When explaining this behavior (password resetting causes the encrypted data to become inaccessible), some Microsoft documents state: "This behavior is designed as a security feature against offline attacks." This is a reasonable explanation. Other Microsoft documents say that this behavior was designed to prevent corrupt network administrators from simply resetting your password and reading your confidential documents. This doesn't seem to be a very good argument. Although it's true that if an administrator could reset the password he or she could read your encrypted files, there's not much you could really do to prevent an administrator from reading encrypted files, even with this new feature.
Some of my tests showed that if the user's password is changed back to the original password, the EFS data becomes accessible again. Let's say a user logs on with a password of ABC and encrypts her files. After the user logs off and leaves for a vacation, she forgets her password. When she gets back, the administrator resets her password to XYZ. The user logs on with the new password but can no longer access her encrypted data. However, if the user later remembers her original password and the administrator resets the password to ABC, the user can access her encrypted data again. A user remembering the old password may not be a likely scenario in the real world, but knowing this possibility may help you recover your lost data someday. Keep in mind that if Windows XP is reinstalled on that computer, encrypted data will be lost regardless of what password is used. As mentioned earlier, this discussion assumes that the certificates and private keys weren't backed up and that there is no DRA.
Changing Passwords Over RAS Connections
One common issue related to password changes for domain accounts has to do with changes made over a RAS (dial-up or VPN) connection. When a user changes a password over a RAS connection, the DPAPI master key is updated but not immediately replicated to other domain controllers. As a result, when the user disconnects from the network and tries to access locally encrypted files, the result may be an Access Denied error. There are a couple of solutions:
The user can log back onto the network and update the DPAPI master key.
You can modify the registry, configuring the ProtectionPolicy key with a value of 1 in the following location:
If this key doesn't exist, you can create a new ProtectionPolicy key with a REG_DWORD value. Set the data value to decimal 1. This option isn't completely without risk. The above change to the registry may place the account at risk for offline attack because resetting the local password no longer invalidates the DPAPI master key. For more information, see Knowledge Base article Q309408, "Troubleshooting the Data Protection API (DPAPI)."
Two Places To Manage User Accounts in Windows XP
In a workgroup environment or Fast User Switching mode, there are two places where you can manage user accounts in Windows XP: Computer Management and User Accounts in Control Panel. If you're not very familiar with the subtle differences between the two interfaces, you could be in for a surprise. First let's look at the user-account creation; then we'll talk about the password, which ties back to the encryption issue.
When you log on as administrator and create a new user account in Computer Management, by default the account is a Limited account. A Limited account acts like a guest account and doesn't have all the privileges needed to install new software. During the creation of the account, you have the opportunity to enter a password.
When you create a new account in User Accounts in the Control Panel, by default the account is a Limited account but the password is set to blank. You must set a password manually. Obviously, creating accounts with blank passwords is a bad idea.
Unlike Computer Management, the User Accounts window doesn't have a refresh option. If you want to refresh the screen, you must exit User Accounts and then go back.
This is where things get a bit tricky. If you know a user's password and want to change it, you should start at User Accounts. You must provide the existing password and then enter the new password. Users can also change their own passwords, as long as they remember the existing password. If a user forgets his password, you must go to Computer Management and reset it. User Accounts cannot be used to reset a forgotten password. The problem is that if you reset the password the user can end up losing all the encrypted data. Unless, of course, a DRA is configured (by default there's none), or you've backed up the user's certificate and private key. The third option is to use a password reset disk, which is discussed in the next section.
Windows XP SP2 enhances security and makes changes to some of the account management tasks, but since SP2 was not released at the time this article was written, its behavior won't be covered here.
Password Reset Disk Dilemma
Notice that the warning message in Figure 1 mentions a password reset disk. Users can use this disk to reset their passwords, even if they don't remember their old passwords.
For details on creating such a disk for a computer in a domain, check out Knowledge Base article Q306214. Instructions for creating such a disk for a standalone computer in a workgroup can be found in Q305478.
There are a couple of issues with the password reset disk that should be addressed. First, the whole idea of offering this feature is to provide security. Copying your secret keys to a floppy disk can definitely be risky. In addition, you need to have a different disk for every computer that you log onto. Keep in mind that Microsoft came up with this idea of copying your secret credentials to a FAT-based floppy disk so that you can be protected from offline attacks. But when it comes to protecting the disk from theft, the password reset disk is no different from writing your password on a piece of paper. Anyone who finds that piece of paper (or your password reset disk) will have complete access to your confidential encrypted data.
I should also point out that, according to Microsoft's documentation, you need to create the password reset disk only once for your account on any given computer. In other words, the password reset disk never needs to be updated, regardless of how many times you change your password. However, there have been some known issues with password reset disks in Windows XP, where it must be updated each time the user changes his/her password.
Planning an EFS Strategy
If you want to implement EFS in your business environment, I suggest you make sure that you have a written policy stating something like this: "We will not implement EFS in our organization until we have a documented method that addresses all the issues associated with EFS." When planning an EFS strategy, you need to make sure that you know all of the following:
How EFS will be managed
Who will be the DRAs
How you'll manage DRA accounts
How and where the certificates and private keys will be backed up
How you'll deal with forgotten passwords and their impact on lost data
How you'll deal with RAS users
How EFS will be implemented on mobile computers
Whether you'll allow sharing of encrypted filesif so, how
End-user training is an essential part of your overall EFS implementation strategy. If users are not trained properly, your confidential data can be at risk. Users may copy files to nonNTFS partitions, such as floppy disks, CD-ROMs, or USB drives. Finally, when you plan your strategy, don't forget to address whether and how users will be allowed to encrypt your business data when they work from home.
Although EFS offers a degree of protection for your confidential data; if someone has physical access to your hard drive then your files should not be considered secure. Several Microsoft documents provide a false sense of protection by making inaccurate claims (such as this TechNet article). They claim that when files are encrypted, the user's data is protected "even if an attacker has full access to the computer's data storage." The fact is that if someone has physical access to your data storage, he or she can use a third-party utility such as Advanced EFS Data Recovery to decrypt your encrypted files, even if the system is unbootable or the system is protected with SYSKEY.
Encrypting data without a DRA is a dangerous proposition. Unfortunately, that's the default behavior in Windows XP Professional in a workgroup or Fast User Switching environment, which is the environment that most people use at home.
It may be easier to have two different interfaces for backward compatibility for managing user accounts in Windows XP, but to have two different interfaces with different functions and capabilities is confusing and potentially risky.
Password reset disk is a useless feature that's not very practical and is rarely used. If Microsoft continues to offer this feature in the future, perhaps it should be renamed "Password Reset Risk."
Before implementing EFS in your business network, make sure that you have a company policy dealing with all the EFS issues. Even at home, you need to understand the consequences of resetting passwords and the risks associated with creating password reset disks. Training users should be an essential part of your strategy because even if your data is secure on your corporate network, if users start to encrypt business data at home they need to understand the potential risks.
When properly implemented, EFS can be very useful in securing confidential data. However, without a proper EFS implementation strategy the cost and risks involved can be very high.