\[Editor’s Note: This article first appeared as a Web Exclusive in the April 1999 issue of Windows NT Magazine.\]
Unauthorized access to confidential data is a serious concern for individuals and corporations. Some OSs (e.g., Windows 95, Windows for Workgroups—WFW) offer no security, and Windows NT systems are at risk when administrators don’t properly implement security. Intruders can bypass NT security with tools such as Systems Internal’s NTFSDOS (http://www.sysinternals.com) that let them read files you protect with earlier versions of NTFS.
NT and UNIX systems rely on a discretionary access control (DAC) system. Computers with DAC let you restrict access to confidential files and folders to protect sensitive data. DAC capability is particularly useful when several users have access to the same computer. However, even with DAC, confidential files can be at risk if users don’t receive proper training. For example, DAC might not be useful if someone steals the computer or hard disk, because the OS enforces DAC. Anyone who can bypass the OS can easily access the hard disk files. Unauthorized users can access data secured on an NTFS volume easily if they steal the hard disk and reinstall NT on it. In certain environments, computers that don’t employ DAC allow users who can access the system unrestricted file and folder access. Intruders can copy files to laptops, 3.5" disks, or home computers by dialing into the corporate network.
Windows 2000 (Win2K) includes Encrypting File System (EFS), which provides file-encryption capabilities on an NTFS volume. Even individuals who steal a hard disk or computer can’t access encrypted data on Win2K’s NTFS volume. To gain a better understanding of Win2K’s EFS, you need to understand the encryption methods in use today.
Common Encryption Techniques
Encryption protects confidential data from accidental exposure or theft. When you use encryption, your data is secure as long as your encryption key is safe. Safeguarding one encryption key is easier than protecting a large amount of data. However, if you lose the encryption key, you can’t access the data you encrypt. Some common encryption techniques that companies employ are file encryption, disk encryption, and EFS.
File encryption protects data. Some applications (e.g., Microsoft Word, Microsoft Excel) can encrypt and decrypt files on demand. File encryption is easier to implement than standard encryption and works well in environments in which several users share a computer. However, this technique’s decryption process creates a plain-text copy of a file which you must delete in a secure manner. In addition, some applications (e.g., Word) store information in temporary files on the hard disk. These temporary files can leave data unprotected, so you must delete them securely, too.
Application-level file encryption runs in NT’s user mode; thus, the OS stores the encryption key in a pagefile. Intruders can access the pagefile, which gives them access to the documents that the key encrypts.
Disk encryption encrypts data sector by sector and encrypts the entire hard disk with one key. The user enters a password to lock the hard disk. Disk encryption relies on the OS’s DAC. Thus, you can’t disable access to the hard disk while you’re running disk encryption.
EFS
EFS has several advantages over traditional encryption techniques. EFS’s encryption technology integrates into the file system, so users can’t access the hard disk without going through the file system. Win2K’s EFS drivers run in kernel mode to provide better security. EFS is easy to manage and completely transparent to the user. A user can use a private key, which the OS generates, to encrypt only those files or folders that need protection. Users can then access their data transparently. Users who don’t have the private key can’t access the data.
EFS, which is based on public key cryptography, uses a randomly generated file encryption key (FEK) to encrypt data (e.g., local NTFS files). A public key-based system uses a pair of keys: one private and one public. Only the user who owns the private key has access to the private key. The public key is available to anyone who requests it. The user’s public key encrypts FEKs; the private key decrypts FEKs. NTFS stores a list of encrypted FEKs with the encrypted file in special EFS attributes known as Data Decryption Fields (DDFs) and Data Recovery Fields (DRFs). For more information about public key cryptography in Win2K, see Tao Zhou, "Public Key Infrastructure in Windows 2000," January 1999.
EFS’s key-storage mechanism is based on Win2K’s CryptoAPI architecture, which stores users’ public and private keys separately from the randomly generated FEK. This setup lets users store their private keys on secure devices (e.g., NTFS volumes, smart cards). Smart cards, which require smart card readers on computers, are credit-card sized devices that let users log on to Win2K with a PIN. Smart cards make personal information (e.g., account numbers, passwords, digital certificates) portable.
Under certain circumstances, you might need to recover encrypted data. For example, users might lose their private key or leave the company. An administrator can use Group Policy Editor to define a data-recovery policy. To add an Encrypted Data Recovery Agent in Group Policy Editor, go to Computer Configuration, Windows Settings, Security Settings, Public Key Policies, Encrypted Data Recovery Agents, as Screen 1 shows. Recovery agents are users that administrators designate to recover encrypted files. Recovery agents use their certificates and public keys to decrypt the files. You can designate only users that have a recovery agent certificate as recovery agents. For example, if domain user Rose loses her private key, she can’t open the files she encrypted with that key. Rose needs to email her encrypted file to Sam, the recovery agent. Sam will back up the encrypted file, move the backup copy to a secure system, and import Rose’s recovery certificate and private key. Sam will then restore the backup file, decrypt the file with Windows Explorer or the Cipher command-line utility, and send the file back to Rose. (For more information about Cipher, see the sidebar "Cipher Command-Line Utility.")
Win2K’s security subsystem enforces and replicates the EFS policy, so users can use file encryption on a system that is temporarily offline. Laptop users can encrypt files when their computers are undocked in much the same way that users can use cached credentials to log on to a domain when the domain isn’t available for user authentication.
You can use EFS to encrypt files on remote servers. However, EFS encrypts files on only the hard disk; it doesn’t encrypt data that users transmit over the wire. To encrypt data you transfer over the network, you must use a method that encrypts all TCP/IP client communications (e.g., IP security) or offers similar protection (e.g., Secure Sockets Layer—SSL).
Microsoft has announced that the initial release of EFS won’t include support for file sharing or alternative encryption algorithms (i.e., EFS will support only Data Encryption Standard—DES). Microsoft will add these features in the future. (For more information about DES, see "Is RAS Safe?" December 1997.)
EFS Architecture
EFS consists of a service, a driver, a runtime library (i.e., EFS file system runtime library—EFS FSRTL), and Win32 APIs, as Figure 1 shows. The EFS service integrates with Win2K’s security subsystem. In user mode, the service supports Win32 APIs and interfaces with CryptoAPI to generate DDFs and DRFs. In kernel mode, the service uses a local procedure call (LPC) to communicate with the EFS driver.
The EFS driver runs on top of NTFS in kernel mode. The driver communicates with the EFS service, which runs in user mode, for all key-management services. The EFS driver requests FEKs, DDFs, and DRFs from the EFS service and transfers the information to the FSRTL to perform file-system operations. The FSRTL is an EFS driver component but doesn’t communicate directly with the driver, even though the EFS architecture implements the FSRTL and the EFS driver as one component. To ensure NTFS security in all file operations, the FSRTL and the EFS driver communicate using NTFS callouts.
EFS supports Win32 APIs in a system DLL file (advapi32.dll) and uses these APIs to encrypt, decrypt, and recover files. EFS also uses Win32 APIs to import files from and export files to other locations without decrypting the files first.
Encrypting Files and Folders
Win2K’s NTFS file and folder properties include encryption as an option. Users can open, read, and save encrypted and nonencrypted files. Only the user who encrypts the file or folder or a registered recovery agent can access an encrypted NTFS file or folder.
Applying EFS is similar to applying NTFS’s compression attribute. When you encrypt a folder, NTFS individually encrypts the files inside the folder and automatically encrypts any files you add to the folder. If any subfolders exist, you can also encrypt them. By default, NTFS encrypts any subfolders you create in an encrypted folder.
EFS doesn’t support encryption and decryption of files and folders on a FAT volume. In addition, users can’t share encrypted files. Three types of files exist that you can’t encrypt: a system file, a compressed file, and a read-only file. You can encrypt and decrypt folders (and files within a folder) from a command line using Cipher. You can also use Windows Explorer to encrypt files or folders. You can activate the encryption or compression attribute by clicking Advanced on a file’s or folder’s Properties dialog box General tab. The compress and encrypt attributes are mutually exclusive: When you select one attribute, the other attribute automatically clears.
Make sure you don’t encrypt any files in the system folder. A user’s encryption key isn’t available during the boot process, so if you encrypt system files (e.g., system DLLs, the Registry), you can’t boot into Win2K. Future versions of Win2K will let you encrypt system files. If you attempt to encrypt a read-only file, you’ll receive the message Error Applying Attributes.
To identify encrypted files in a folder without verifying individual file properties, you can use Cipher without any switches to display the state of the files in a folder. However, if you want to verify the state of files and folders at several locations on different volumes, using Cipher can be tedious. Unfortunately, you can’t easily accomplish this task in Win2K. To encourage users to encrypt folders rather than files, Microsoft intentionally didn’t expose encryption or decryption on individual files from Windows Explorer.
Decrypting Files and Folders
EFS provides transparent decryption of files and folders for typical reads and writes. Users also can decrypt files or folders by right-clicking a file or folder in Windows Explorer. To decrypt a file or folder, clear the Encrypt contents to secure data check box in the Advanced Attributes dialog box, which Screen 2 shows. You access Advanced Attributes from the file’s or folder’s Properties dialog box General tab.
Recovery Policies
When you install the first Win2K domain controller, Win2K automatically implements a default recovery policy. Win2K issues the domain administrator a self-signed certificate and designates a recovery agent. For standalone machines, the system configures a default recovery policy locally. For machines on the network, the system configures the recovery policy at the following three levels: domain, organizational unit (OU), or computer. Administrators can define three types of recovery policies: the recovery agent policy, which takes effect when an administrator adds one or more recovery agents; the empty recovery policy, which has no one designated as a recovery agent and in which EFS is turned off; and no recovery policy, which means you have deleted the group recovery policy so that the local machine administrators can control data recovery by using default local policy. You add recovery agents through the Group Policy console.
General Tips
Always encrypt folders rather than files. Encrypting folders will automatically encrypt temporary files inside those folders. Similarly, encourage users to encrypt the Temp folder on their workstations, and also to encrypt the My Documents folder if they store data there. Because the data transferred over the network isn’t encrypted, use a secure protocol such as SSL, IP Security (IPSec), or PPTP. Be very careful whom you designate as a recovery agent. If your company policy requires several recovery agents, periodically verify the membership to ensure the list is current and accurate.
If you want to turn off EFS so that users can’t encrypt files, you can create an empty policy with zero recovery certificates. Creating an empty policy is different from having no policy. If you have no recovery policy, local machine administrators can still define their own policies.
For security reasons, as a recovery agent you need to use the Export command from the Certificates Microsoft Management Console (MMC) to back up a recovery certificate. After you back up a certificate and the private keys to a secure place, you need to delete the certificate from the console. You can use the Import command to restore the recovery certificate and its associated private keys. Don’t forget to delete the recovery certificate again in the Certificates console.
Encryption Standards
EFS isn’t available in all OSs for two reasons. First, including EFS in an OS is complex and requires that you integrate EFS with the OS. Second, national regulations and restrictions on the export of encryption technology have made integrating EFS more difficult for vendors. EFS encryption technology is based on the DESX 128-bit encryption key. Current national policy doesn’t permit freely exporting software with stronger than 56-bit encryption. EFS uses a DESX encryption algorithm that is based on 128-bit encryption. Microsoft is working with the US government for approval to export 128-bit DES. Win2K products in North America will use this 128-bit DESX encryption. Because of export limitations, international customers will be able to use 40-bit keys that are expanded to the required 128-bits for DESX. According to Microsoft, you can restore files encrypted with the international 40-bit version of EFS and use them with 128-bit versions. However, you can’t use the 40-bit DESX to restore files encrypted with 128-bit DESX versions. This limitation ensures compliance with US export laws. If and when the law allows exporting of stronger encryption, customers worldwide will be able to migrate transparently to the stronger encryption algorithms. To check the current status of US encryption export laws, go to http://www.bxa.doc.gov/encryption.
A Welcome Addition
Win2K’s new encryption feature—one of the OS’s major enhancements—is a welcome addition. Microsoft wants to make Win2K a serious competitor for rival OSs (e.g., UNIX, AS/400) that run on minicomputers and mainframe computers. EFS and other Win2K features bring Microsoft a step closer to this goal. To read two recent in-depth articles about Win2K’s EFS implementation, see Mark Russinovich, "Inside Encrypting File System, Part 1," June 1999 and "Inside Encrypting File System, Part 2," July 1999.
Win2K’s EFS provides users with a high level of security and transparent access to encrypted files and folders. EFS is a valuable tool for most organizations, including large corporations facing the constant challenge of protecting information from internal and external attacks. When companies implement EFS wisely, EFS provides great data security. Careless management of encryption keys can be damaging, resulting in the loss of valuable information and the exposure of confidential data. To successfully deploy EFS, you must create proper backup and recovery plans and carefully manage encryption keys.
