Securing Win2K Laptops with EFS

The Encrypting File System (EFS) offers an efficient balance between protecting confidential files and providing ease of use. EFS is especially important for laptop users, who are often the knowledge workers in the company and have access to confidential company information. Unfortunately, these mobile users are at the greatest risk for having their computers stolen.

Most companies that implement Windows 2000 typically deploy the OS on new laptops as members of a legacy Windows NT domain or workgroup, rather than as part of an Active Directory (AD) domain. Using EFS securely in these situations can be a challenge because these laptops don’t benefit from AD's domain-level security. However, you can take a few precautions to securely implement EFS on a Win2K Professional laptop and overcome some arcane security vulnerabilities of EFS in this common scenario.

EFS Basics
To encrypt a folder in Win2K with EFS, you simply open the folder’s Properties dialog box in Windows Explorer, click Advanced, and select the Encrypt contents to secure data check box, as Figure 1 shows. Win2K then asks whether you want to also encrypt all the files and subfolders, as Figure 2 shows. It’s a good idea to encrypt at just the folder level. If you encrypt individual files, you might end up with unencrypted copies of some files when applications such as Microsoft Word create temporary copies of these files during editing.

For each file you encrypt, EFS generates a different symmetric Data Encryption Standard (DES) key called a file encryption key (FEK) and uses it to encrypt the file. Then, EFS encrypts the FEK with the public key of your EFS certificate. Win2K automatically issues you an EFS certificate the first time you encrypt a file. The OS stores this certificate in your profile under the HKEY_CURRENT_USER registry hive.

EFS also encrypts another copy of the FEK with the public key of the data recovery agent’s data recovery certificate. This agent is a user who can use a special EFS data recovery certificate to decrypt any file on the system, including files that another user encrypts. EFS’s data recovery functionality protects corporations from data loss when a user’s private EFS key is damaged or lost. Win2K stores both encrypted copies of the FEK and the encrypted file on disk. Later, when you read the file with an application, Win2K decrypts the file in memory before passing it to the application. Win2K uses your private EFS key to decrypt the FEK and then uses the FEK to decrypt the file.

Win2K follows a similar process when you update the file. When the data recovery agent decrypts the file, Win2K simply uses the data recovery agent’s private key to decrypt the other copy of the FEK. For a more detailed introduction to EFS, see Zubair Ahmad's article, "Windows 2000 EFS."

Although EFS is easy to implement when you can take advantage of AD's domain-level security, it can be tricky, and therefore require a few more steps, when you use EFS on a laptop that isn’t a member of an AD domain. The first step is finding the best way to protect your private key.

Protect Your Private Key
As with any system that uses public key infrastructure (PKI), EFS-encrypted files are only as safe as your private key. Win2K encrypts your private EFS key using another key, which the OS computes based on your ability to log on with your user account. So, if someone who steals your laptop can log on using your account, that intruder can access your encrypted files.

An intruder might try three methods to log on and gain access using your account. First, if your user account password is easy to guess, the intruder can simply guess your password and log on using your credentials. Always remember to use long, hard-to-guess passwords to prevent this type of attack. The other two methods apply only if you log on to your Win2K workstation using a local account. In the first situation, the intruder might use L0phtcrack to try cracking the hash of your password that the OS stores in the local system’s SAM. Fortunately, this attack won't work with Win2K because the OS automatically uses Syskey to encrypt password hashes in the SAM. However, in the second situation, the intruder can use another method if you use local accounts and haven’t changed Syskey’s default settings. Syskey can store the system encryption key that the OS used to encrypt local account password hashes three different ways, as Figure 3 shows.

First, you can base the key on a password that you must enter each time the system starts. Second, you can store the key on a 3.5" diskette. In this case, the system won’t restart unless you insert the diskette. Third, you can store the key locally in the system registry. This last approach lets the system restart without intervention and is Win2K’s default setting.

Internet Security Systems discovered that Win2K's default Syskey setting combined with Petter Nordahl-Hagen's freely available Ntpasswd utility lets an attacker access a local user’s encrypted files. With Ntpasswd, an attacker can replace your local account’s Syskey-encrypted password hash with an unencrypted hash based on a new password of the attacker’s choice. Win2K simply encrypts this hash using Syskey the next time the system boots. At that point, the attacker can use the password he or she specified with Ntpasswd to log on to your account and access your encrypted files.

To prevent this kind of attack, you have two choices. First, you can use one of the other Syskey encryption key storage options (i.e., either have users enter a system password or insert a 3.5" diskette with the key before booting). For laptops, I recommend using the system password option instead of storing the key on a diskette because the diskette can easily become lost or damaged. More important, users might be tempted to keep the floppy in their laptop bag with the laptop, which defeats your security if someone steals the bag. Second, if you are averse to making your users remember yet another password, you can make the laptop a member of an NT or AD domain. In this case, you will want to provide the user with a domain account rather than a local account. This approach solves the problem because Ntpasswd doesn’t work on domain accounts, which aren’t stored in the system’s local SAM.

You can protect sensitive files on laptops using EFS, but make sure you follow these important rules. Train your users to select quality, hard-to-guess passwords, and specify a strong password for the local Administrator account. Protect against Ntpasswd by either joining the laptop to an NT or AD domain and restricting the user to a domain account or, if no domain is available, configuring Syskey to use a startup password to protect password hashes. Finally, always export and delete all data recovery agent certificates. Next time, I’ll show you why this last step is so important and how to do it.