On various Internet security mailing lists, I often see administrators asking about secure and transparent file-encryption products for Windows. Just as often, senior management personnel ask for ways to prevent network administrators from seeing confidential company files. When I suggest using Windows' own Encrypting File System (EFS), most reply that they want something more reliable and secure.
Contrary to popular opinion, EFS is a reliable, easy-to-use, and secure encryption solution, and it can trump even the network administrator's rights. EFS is great for protecting confidential files on the network and on often-stolen laptop computers. Unfortunately, EFS has been wrongly maligned by users who refuse to objectively evaluate any Microsoft security product. In truth, EFS is among the best security products Microsoft has ever made, but it requires appropriate planning and understanding. In this article, I discuss the basics of EFS, talk about its purpose and functionality, and discuss basic administrative tasks and pitfalls.
EFS in a Nutshell
Microsoft first released EFS in conjunction with Windows 2000 and has been steadily improving the product in its Windows XP and Windows Server 2003 incarnations. EFS lets users encrypt any file or folder to which they have Read and Write permissions. After encryption is enabled, the resource is decrypted on the fly whenever the legitimate party needs to access it. Users attempting to access a protected file or folder without the appropriate EFS permissions can view the file or folder name, but they can't open, modify, copy, print, email, or move the file or folder. Interestingly, however, if users have the NTFS permissions to delete an EFS-protected file, they can delete it even if they can't read it. Like most encryption products, EFS is built to protect confidentiality, but it isn't concerned with preventing data loss. If EFS prevents an unauthorized user from seeing data in any form, it has done its job correctly. Some people argue that Windows falters by even allowing the name of a protected file or folder to
be seen.
In addition, you don't need to have ownership or Full Control permissions of a file or folder to encrypt it. You need only Read and Write permissions—the same permissions necessary to access the resource. Once a file or folder is protected, only the user who encrypted it (as well as any additional users with whom the user wants to share the resource) can access it. The lone common exception is the data recovery agent (DRA). By default (in most instances), Windows makes the administrator a DRA, so he or she can access any file or folder that EFS encrypts. In a domain environment, the DRA is the domain administrator; in a nondomain environment, the DRA is the local administrator. (I'll talk more about DRAs in a moment.)
The ability to encrypt a file or folder is enabled by default, but you must select each file or folder separately (or indirectly through normal inheritance rules). For EFS to work, the file or folder must be located on an NTFS disk partition. Then, to protect a file or folder, you simply right-click the resource in Windows Explorer, choose Properties, then choose Advanced on the General tab. (Note: Don't click Advanced on the Security tab.) Finally, select the Encrypt contents to secure data check box.
If you select one or more files (as opposed to a folder), EFS will prompt you to choose whether to encrypt just the file(s) or to encrypt the parent folder and the current file(s). If you choose the latter, EFS will mark the folder as an encrypted folder. All future files added to the folder will be encrypted by default, although any existing files in the folder not selected during the EFS operation will be left unencrypted. Encrypting the entire folder instead of individual files is desirable in many cases, particularly because many applications (e.g., Microsoft Word) create temporary files in the same folder while a file is open. Temporary files are often left behind (e.g., in the event of a nongraceful reboot) and in plain text—ripe for unauthorized recovery.
By default, in XP Professional and later, EFS highlights encrypted files in green, but you can disable this behavior by choosing Tools, Folder Options in Windows Explorer, then clearing the Show encrypted or compressed NTFS files in color check box on the View tab. If you have the Attributes column selected in Windows Explorer's Details view, compressed files will contain an E attribute marking along with the normal Archive (A) attribute, resulting in an AE attribute setting. Note that you can't use Windows' built-in mechanisms to encrypt and compress a file at the same time, although you can use a third-party utility such as WinZip or PKZIP to compress a file, then encrypt the resulting compressed file.
It's Good Encryption
EFS offers good encryption—so good, in fact, that if you lose your EFS private key (which the software uses to decrypt EFS-protected files), there's a good chance the files might become unrecoverable. If EFS is appropriately configured, not even the administrator can access an EFS-protected file or folder, unless he or she is also the designated DRA.
At least one product on the market today—ElcomSoft's Advanced EFS Data Recovery (aka AEFSDR)—claims to recover EFS-protected files. Actually, it recovers the local administrator's password (a simple process if Windows isn't appropriately configured), which can then be used to recover the administrator's EFS private key. (If a user has a tool that recovers the administrator's password, he or she can do anything to the system. The user accessing EFS-protected files would be the least of your worries.) Minimizing the risk of unauthorized EFS private key recovery is the fact that in a domain environment, the DRA is the domain administrator's account, not the local administrator account that nearly every password-cracker tool recovers. Still, in XP, Microsoft implemented a new policy that makes this type of attack more difficult to accomplish. Note that if the recovery tool can't recover the current—and correct—administrator password (many password tools reset the password rather than recover the current one), EFS protection is still enabled.
How Does EFS Work?
EFS uses a combination of symmetric and asymmetric cryptography. With symmetric cryptography, the key that locks the file is the same key that unlocks the file. In asymmetric cryptography, a public key encrypts and a separate but related private key decrypts what the public key encrypted. As long as the one user who should have the decryption ability keeps the private key secure, the protected resource remains secure.
EFS is enabled by default on all Win2K and later systems. When someone uses EFS to protect a file or folder for the first time, Windows checks whether a public key infrastructure (PKI) server capable of generating EFS digital certificates is available. Windows 2003 and Win2K Certificate Services can generate EFS certificates, as can some non-Microsoft PKI products. If Windows can't find an acceptable PKI provider, it generates a self-signed EFS certificate for the user like the one you see in Figure 1. Self-signed EFS certificates are usable for 100 years—far longer than anyone would ever use one.
If Windows finds a Certificate Services server, that server will automatically generate and issue the user a 2-year certificate. Perhaps the thinking is that if you have PKI services running in-house, the PKI server can easily grant or renew EFS certificates when the original expires. In either case, you can view your EFS certificates by adding the Certificates snap-in to the Microsoft Management Console (MMC) and looking in the Personal container.
The user's private EFS key (which unlocks EFS-protected files) is encrypted with the user's master key and stored in the user's profile under Documents and Settings, username, Application Data, Microsoft, Crypto, RSA. If a roaming profile is in use, the private key resides in the RSA folder on the domain controller (DC) and is downloaded to the user's computer when the user logs on. Windows uses the user's current password and either the 56-, 128-, or 512-bit RC4 algorithm to generate the master key. Perhaps the most crucial fact to understand about EFS is that the user's private EFS key resides in his or her profile and is protected with a master key based on the user's current password. Note that EFS's encryption is only as strong as the user's password. If a malicious user cracks an EFS user's password or is able to log on as the legitimate user, the protection provided by EFS is compromised.
If the user's profile is ever lost, or if his or her password is reset (as opposed to the user changing it), the user could easily lose access to all EFS-protected files. For this reason, the user's private EFS key should always be backed up to two or more secure and separate offsite locations, or one or more DRAs should be defined (and their private keys exported and backed up to two or more separate and secure offsite locations). Failure to follow this advice could lead to data loss.
When a file or folder is encrypted for the first time, Windows randomly generates a symmetric key using 128-bit Data Encryption Standard X (DESX—the default in XP and Win2K) or 256-bit Advanced Encryption Standard (AES—in Windows 2003 and XP Pro Service Pack 1) algorithms. Both algorithms are widely accepted and trusted government standards, although the latter is the more current and recommended standard. You can also enable the government's older symmetric cipher standard, 168-bit Triple DES (3DES), should your organization require its use. See the Microsoft article "Encrypting File System (EFS) files appear corrupted when you open them" (http://support.microsoft.com/default.aspx?scid=kb;en-us;329741&sd=tech) for more details. The randomly generated symmetric key is known as the file encryption key (FEK), and it will be the only key that Windows uses to encrypt the file or folder, regardless of how many people have access to the EFS-protected resource.
Windows then encrypts the FEK, using the user's 1024-bit RSA public EFS key, and stores the FEK in the file's extended attributes. If any DRAs are defined, the OS stores another, encrypted copy of the FEK with the DRA's public EFS key. Then, Windows stores that encrypted copy of the FEK with the file. In XP and later, more than one user can have EFS access to a particular file or folder. Each authorized user will have his or her own copy of the FEK encrypted with a unique public EFS key. (Note that in Win2K, you can have only one DRA defined.)
Now, when an authorized user accesses a protected file, Windows decrypts his or her copy of the encrypted FEK by using the user's associated private EFS key. Windows then uses the FEK to unlock the encrypted file. Unlike the first versions of EFS in Win2K, EFS now securely manages all encryption and decryption of files and folders in memory, so no plain-text remnants are available for unauthorized recovery.
Sharing EFS Files
In Win2K, only one user at a time can EFS-protect a file, but in XP Pro and later, several users can share an EFS-protected file. In a shared scenario, the first user to EFS-protect the file or folder controls who else has access. After initially EFS-protecting a file or folder, the user can select additional users to participate by clicking Details, which Figure 2 shows. The user can then add as many users as he or she wants. Each user will have his or her own copy of the FEK encrypted with his or her private EFS key. This new feature in XP is terrific for letting groups of users share EFS-protected files. Unfortunately, you can set EFS file sharing only on individual files—not at the folder level. Note that a user must have encrypted one file or folder or received an EFS certificate before he or she can be available for selection as an additional EFS user.
The DRA
Because a user's profile can be wiped out so easily, and because administrators commonly reset users' passwords, network administrators must either back up users' EFS keys or implement one or more DRAs. You can back up a user's private EFS key by accessing the EFS digital certificate in the Certificates console and selecting the Copy to file check box on the Details tab. In XP Pro and later, you can also use the Backup Keys button, which you'll find under the Details button at the EFS file-sharing location. Lovers of the command line can use the command
cipher.exe /x
to back up EFS keys in Windows 2003, as well as XP Pro SP1 and later. During the resulting prompts, Windows gives you a chance to back up and/or export the related private key. You should never delete a user's private EFS key—as Windows prompts you to do during the export—because then the user won't be able to decrypt his or her protected files. After exporting the user's private key, the user should store the key in two separate offline locations.
Backing up individual users' EFS private keys is laborious. Beginning with Win2K, Microsoft lets you select a DRA. Whenever someone encrypts a file or folder, the DRA automatically gets a copy of the FEK. In Win2K (workgroup or domain mode), XP (domain mode only), and Windows 2003 (workgroup or domain mode), the administrator is the default DRA, although you can change the user account that is appointed to be the DRA. Unfortunately, in XP's workgroup mode, a DRA isn't defined. Microsoft made this decision in answer to criticism resulting from the ability to compromise EFS-protected files in the event of a compromised administrator password. Unfortunately, large numbers of XP Pro machines are in workgroup mode, and their EFS users are just one destroyed profile or reset password away from losing their files. Whenever using EFS (remember that it's turned on by default and available to users), ensure that either your EFS users back up their private keys or that one or more DRAs are appointed.
If you plan to choose a DRA different from the default administrator, the replacement user account must have an EFS Recovery Agent certificate already issued to it. You can request an EFS Recovery Agent Certificate from Certificate Services or install one from any other capable third-party PKI product. If you have Windows 2003 Certificate Services installed, you can implement Key Recovery Agents instead of using DRAs. Key Recovery Agents will end up recovering the user's lost key instead of directly recovering the file.
Unlike the private keys of normal EFS users, a DRA's EFS private keys should be exported and deleted from computers. If the DRA's private keys are compromised, all files that have FEKs protected by the DRA's public key could become compromised. Therefore, you should export the keys and store them securely in two offsite locations. If you need the keys to recover encrypted files, you can easily import and use the private keys.
Although the administrator is often the default DRA, you should choose one or more specifically created user accounts that are unlikely to be deleted. Because the DRA's public key also copies and protects each FEK, if you accidentally delete your DRA user account or reset the password, the DRA-protected FEK could be difficult to recover. If the user accounts that have DRA status are changed, you could end up with EFS-protected files with FEKs that are protected by old DRA keys. Whenever Windows accesses the files, DRA-protected FEKs are updated with the latest DRA keys; however, you can alternately use the Cipher command to force a mass update of all FEK keys with the current DRA keys. Note that regardless of whether you export and delete the DRA's private key from the system, backing up the DRA's recovery certificate to two or more offsite safe locations is essential.
Miscellaneous EFS
EFS doesn't protect files that are copied over the network. Windows copies any file opened on a network share in plain-text format. If you need real-time encryption of files stored on disk and copied over the network, you need to use another protection technology, such as IP Security (IPsec), Secure Sockets Layer (SSL), or WWW Distributed Authoring and Versioning (WebDAV). On a related note, in XP and later, you can enable EFS protection for offline files. (I'll discuss this functionality in a future article.)
EFS is a local protection process—Microsoft designed it for encrypting files on local disks. If you want to use EFS to protect stored files on remote computer shares, the remote computer must be trusted for delegation. Laptop users often use EFS on file-server shares. To implement EFS on a server, you need to select the Trust this computer for delegation to any service (Kerberos only) or Trust this computer for delegation to specified services only check box on the server's computer account, as you see in Figure 3.
If you don't want your users implementing EFS protection, you can disable EFS through Group Policy. Select the Computer Configuration container, then right-click Windows Settings and choose Security Settings, Public Key Policies, Encrypting File System. You can then clear the Allow users to encrypt files using EFS check box. You can enable or disable EFS per organizational unit (OU).
Before you use EFS, be sure that your applications support EFS and the EFS API. If your applications offer no such support, the EFS-protected files could become corrupted—or worse, unprotected without appropriate authorization. For example, if you use Windows' edit.com program (a 16-bit executable) to save or modify an EFS-protected file, it will remove any additional EFS users sharing the file. Most Microsoft applications—including Microsoft Office, Notepad, and Wordpad—readily support EFS.
If an authorized user copies EFS-protected files to a FAT volume, EFS protection will be removed. An unauthorized user should be unable to move or copy the files to any Windows volume. If, however, an unauthorized user utilizes a bootable floppy disk or CD-ROM program that can mount an NTFS file share (e.g., Knoppix, NTFSDOS, Peter Nordahl-Hagen boot floppy) to boot around the Windows NTFS permission system, that user might be able to copy or move the file, but unless he or she comes up with the authorized user's EFS key, the file will remain encrypted.
Best Practices
Here are some EFS best practices that you should consider:
EFS provides a reliable and secure method for encrypting files and folders on Win2K and later systems. Network administrators should define and enable a DRA policy and educate end users about the benefits and concerns of EFS.
