Ask Us About... Security, November 2000

by Joel Scambray

Reviewing the last two AUAS columns, I note we've covered just about all of the new encryption-related technologies in Microsoft Windows® 2000. We'll address another Windows 2000 encryption technology this month, but I first want to stress that my discussion and endorsement of these mechanisms should not be taken to mean that encryption is a magic solution for everyone's security problems. Like most technologies, encryption is a tool, not a panacea. Use it wherever possible, but don't assume it makes you invincible. As we will see in this month's discussion, a chain is only as strong as its weakest link.

I also want to note that the answer in this month's column draws from material presented in the newly released second edition of Hacking Exposed, on which I am a co-author. HE2 has been vastly expanded from the first edition, including two entirely new chapters directly relevant to readers of this column: Windows 2000 security and Internet User security, covering Microsoft Internet Explorer and Microsoft Outlook®. It should be on the shelves just around the time this column is posted; check it out for yourself at your local bookstore. Excerpts from HE2 will also be posted on the Microsoft TechNet site in the near future.

On This Page

EFS Best Practices

EFS Best Practices

Q: I am interested in learning more about the new Encrypting File System (EFS) in Windows 2000. Where can I get some information on deploying and using it properly?

A: Look no further than AUAS, of course. Well, you can also examine the EFS white paper available on Microsoft.com and the EFS Best Practices article in the Knowledge Base; and another good general reference is simply looking up "EFS" in the Windows 2000 help system and reading the "overview" topic. Here are a few additional tips I've picked up in my use of the system.

There are two important things to realize about EFS right off the bat: one is appropriate use. EFS could be used to protect files from multiple users of the same machine or in remote file sharing scenarios. But NTFS Access Control Lists (ACLs) are probably a more efficient solution for this purpose (no encryption/decryption overhead). With either EFS or NTFS ACLs, the Administrator account will be able to access all data, even if encrypted by another user (we'll discuss this in a bit). Thus, there is no real advantage for EFS in this scenario. Rather, it is optimally used to protect data on disk from direct physical attacks, such as might occur when an attacker steals the data off a stolen laptop hard drive. The second important thing to realize about EFS is that it depends heavily on the combined physical security of the system and the passwords of the Administrator and of the user account that encrypts the files. Let's briefly describe how EFS works to illustrate this point.

EFS encrypts files and folders with a fast, symmetric encryption algorithm using a randomly generated file encryption key (FEK) specific to that file or folder. The initial release of EFS uses the Extended Data Encryption Standard (DESX) as the encryption algorithm. The randomly generated file encryption key is then itself encrypted with one or more public keys, including those of the user - each user under Windows 2000 receives a public/private key pair - and a key recovery agent (RA). These encrypted values are stored as attributes of the file. Key recovery is implemented in case encryption keys are lost for whatever reason. Windows 2000 mandates the existence of a data recovery agent for EFS, therefore, EFS will not work without a recovery agent.

The FEK encrypted with the user's public key is stored in an attribute called the Data Decipher Field (DDF) associated with the file. When the user accesses the file, his or her private key decrypts the DDF, exposing the FEK, which then decrypts the file. The value resulting from the encryption of the FEK with the RA's key is stored in an attribute called the Data Recovery Field (DRF). Because the FEK is completely independent of a user's public/private key pair, a recovery agent may decrypt the file's contents without compromising the user's private key. The default data recovery agent for a system is the local Administrator account.

Thus, if the local Administrator is the defined recovery agent (which it is the default), then anyone who attains Administrator on this system is able to decrypt the DRF with his or her private key, revealing the FEK, which can then decrypt all EFS-protected files. Similarly, an attacker that cracks a user account will be able to access all of the files encrypted by that user via the DDF.

Since there are known mechanisms to compromise Windows 2000 user account passwords if physical access is attained, it's wise to remove the Administrator's (default RA) key from the system. To export the recovery agent's certificate on stand-alone systems, open the local Group Policy object (gpedit.msc), browse to the Computer Configuration\Windows Settings\Security Settings\ Public Key Policies\Encrypted Data Recovery Agents node, right-click on the recovery agent listed in the right pane (usually, this is Administrator), and select All Tasks | Export. A wizard will run, prompting for various pieces of information before the key can be exported. To back up the recovery agent key, you must export the private key along with the certificate. I recommend enabling strong protection (requires a password). Finally, make sure to select Delete The Private Key If Export Is Successful. This last step blocks the Administrator account's ability to act as the RA (unless the exported key can be supplied).

For machines joining a domain, the situation is different; the domain controller holds the recovery key for all systems in the domain. When a Windows 2000–based machine joins a domain, the Domain Default Recovery Policy automatically takes effect; the Domain Administrator, rather than the local Administrator, becomes the recovery agent. This physically separates the recovery keys from the encrypted data and makes attacks against individual systems much more difficult. It is good practice to export the recovery agent certificate from domain controllers as well. If they were compromised, every system in the domain would become vulnerable if the recovery key were available locally.

Of course, an attacker could also compromise the user account to obtain access to files, even though the proper user account would have to be identified first (a minor inconvenience for systems with few users). The only operating system-level defense in this case is to set SYSKEY in password- or floppy-protected mode, which requires a password or the insertion of the System Key floppy at boot time. Windows 2000 implements SYSKEY by default, which performs one additional round of encryption against password hashes stored in the SAM using a 128-bit key. The system key, or SYSKEY, that is used to perform this additional encryption can be stored one of three ways. In normal mode, or mode 1, the system key is stored in the Registry and is transparently exposed during the Windows startup sequence, requiring no intervention from the user at the console. Mode 2 stores the key in the Registry also, but in addition requires a password to unlock the system key during startup. (The key password is stored as an MD5 hash.) Finally, mode 3 stores the system key on a floppy disk, which must be inserted during the Windows startup sequence or Windows will not boot. Type syskey from Start/Run to set password or floppy mode. I'd also recommend using a BIOS password that locks the hard drive for laptop users. More exotic solutions include biometric or smart card-based authentication mechanisms at the operating system or hardware level. And of course, physical locks, either on doors or special laptop cables, are also strong deterrents to physical attack. These all present another layer of protection for your invaluable data.

One last tip: be careful when you are moving EFS-encrypted files. Non-NTFS 5.0 partitions do not support EFS, and files moved to such partitions will be unencrypted. Although standard backup mechanisms (for example, Ntbackup.exe) will copy encrypted items as is, the normal copy command reads files in a way that is transparently decrypted by EFS. If the destination is a non-NTFS 5.0 partition, files will be left in plaintext state on the destination volume. If the destination is a remote NTFS 5.0 partition, the file will be encrypted but won't be identical to the original - the remote copy will be encrypted with a new FEK. Note that this means EFS only protects the file while it is stored on disk; files are plaintext while they traverse the network wire. Incidentally, this is another good reason that EFS is a poor defense against the Administrator account—simply copying an encrypted file to a floppy renders it accessible.

I hope this helps with a safe and sane deployment of EFS. I also hope that I have conveyed the importance of understanding the fundamentals of any security technology, including how it has been attacked in the past, or may be attacked in the future. Blindly assuming that a powerful tool like EFS makes one invulnerable to all attacks ignores the assumptions that are made during the design of the technology, assumptions that are always subject to unexpected manipulation in the real world.

Joel Scambray is a Principal of Foundstone. He is co-author of Hacking Exposed: Network Security Secrets & Solutions, Second Edition, from Osborne-McGraw Hill.

Send your Security questions to the Ask Us About Security mailbox. If your question is selected, you will see your answer in a forthcoming column.

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages.