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. Even Windows NT systems are at risk when administrators don’t properly implement security. Intruders can read files you protect with previous versions of NTFS by bypassing NT security with tools such as NTFSDOS.
UNIX and Windows NT systems rely on a discretionary access control (DAC) system. Computers with DAC let you protect sensitive data by restricting access to confidential files and folders. 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. 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 permit unrestricted file and folder access to users who can access the system. Intruders can copy files to laptops, 3.5" disks, or home computers by dialing into the corporate network.
Windows 2000 (Win2K) includes an Encrypting File System (EFS) that 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 no longer access the data you encrypt. Some of the encryption techniques that companies currently use to protect data are file encryption, disk encryption, and EFS.
File encryption protects your data. Some applications (e.g., Microsoft Word, Microsoft Excel) can encrypt and decrypt files on demand. File encryption is easier to implement than 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. Hackers 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’ 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’ encryption technology integrates into the file system, so that 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, encrypts data (e.g., local NTFS files) using a randomly generated file encryption key (FEK). A public key-based system uses a pair of keys: one private and one public. Only the user who owns the private key knows 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).
EFS’ 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 size devices that let users log on to Win2K with a personal identification number (PIN). Smart cards make personal information (e.g., account numbers, passwords, digital certificates) portable.
Before you start using EFS, the systems administrator must set up a data recovery policy at the domain level (or at the local level for standalone machines). The EFS policy user interface lets recovery agents generate, import, export, and back up recovery keys. (A recovery agent is the individual a systems administrator assigns to manage recovery keys for all the computers in a domain.) For example, if domain user Rose loses her private key, she can’t open the files she encrypted with that key. Rose emails her encrypted file to Sam, the recovery agent, who decrypts the file on a secure machine by importing the file using Rose’s recovery key. Sam uses the EfsRecvr command-line utility to decrypt the file and send it back to Rose. If necessary, Rose can open the file and encrypt it again. Rose can use a similar process to recover an encrypted file when she’s working on a standalone workstation at home.
Win2K’s security subsystem enforces and replicates the EFS policy, so that 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 only on the hard disk; it doesn’t encrypt data 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).
I based this article primarily on Win2K’s beta 2 (build 1859). Some Win2K EFS features (e.g., command-line options for importing or exporting encrypted files) weren’t available when I wrote the article. In addition, Microsoft announced that the initial release of EFS won’t include support for file sharing or alternate encryption algorithms (i.e., EFS will support only Data Encryption Standard—DES). (For more information about DES, see "Is RAS Safe?" Windows NT Magazine, December 1997.) Microsoft will add these features in the future.
EFS Architecture
EFS consists of a service, a driver, a runtime library (EFSRTL), 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 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 EFSRTL to perform file system operations. The EFSRTL is an EFS driver component, but it doesn’t communicate directly with the driver even though the EFS architecture implements the EFSRTL and the EFS driver as one component. The EFSRTL and the EFS driver communicate using NTFS callouts, which ensures NTFS security in all file operations.
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 (e.g., 3.5" disks) without decrypting the files first.
Encrypting Files and Folders
Win2K’s NTFS file and folder properties now include encryption as an option. Encryption is a new file attribute in NTFS 5.0. Users can open, read, and save encrypted and nonencrypted files in the same manner. Only the user who encrypts the file or folder, a registered recovery agent, or anyone authorized to share the file or folder (i.e., users with a private key) can access an encrypted NTFS file or folder.
Applying EFS is similar to applying NTFS’ 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 encrypt them too. By default, NTFS encrypts any subfolders you create in an encrypted folder.
EFS lets you copy encrypted files across systems using command-line options. Win2K’s Copy command includes extra switches to import and export encrypted files. You can export an encrypted file to a 3.5" disk, a backup tape, or a FAT16 or FAT32 volume. (Note: Some of these features might not be available in the released version.) You can also transfer the encrypted file as an email attachment. The file remains encrypted until you decrypt it with the proper key. You export an encrypted file with the /E switch using the syntax Copy /E source_file destination_file. For example,
Copy /E myfile.doc A:
You import an encrypted file with the /I switch using the syntax Copy /I source_file destination_file. For example,
Copy /I A:myfile.doc C:\data\myfile.doc
Remember that if you use the Copy command without the appropriate switch, EFS copies an encrypted file as an unencrypted file, unless you encrypt the destination folder. You can encrypt and decrypt folders (and files within a folder) from a command line using the Cipher utility. For more information on this utility, see the sidebar "Cipher Command-line Utility." According to Microsoft documentation, Win2K supports encrypting and decrypting individual files using the Cipher utility, but the build I tested only supported operations at the folder level.
If a file or folder resides on a compressed FAT16 or FAT32 volume or has a system attribute, you can’t encrypt it. However, you can always uncompress a file or folder before you encrypt it. You can activate the encryption or compression attribute by clicking the Advanced button on the General tab of a folder’s Data Properties dialog box. Screen 1 shows this dialog box. These attributes are mutually exclusive: When you select one attribute, the other attribute grays out.
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 that if you encrypt a system file, you can’t boot into Win2K. If you attempt to encrypt a file with the system attribute, you’ll receive an Access is denied error message. Future versions of Win2K will let you encrypt system files.
To identify encrypted files in a folder without verifying individual file properties, you can use the Cipher utility 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 the command-line tool can be tedious. In this case, I suggest you use NT’s File Manager to verify file and folder encryption. File Manager isn’t available in Win2K, but you can copy it from a previous version of NT. File Manager doesn’t show you which files or folders are encrypted, but encrypted files and folders disappear from the File Manager as soon as you encrypt them. This method lets you confirm encrypted data easily and is particularly useful when you think you’ve encrypted subfolders but suspect you might have accidentally left out certain files. (I don’t encourage using File Manager instead of Explorer; however, using File Manager can be helpful in certain situations.)
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 Explorer. To decrypt a file or folder, deselect the Encrypt contents to secure data option in the Data Properties’ Advanced attributes dialog box.
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 it with the OS. Integrating EFS isn’t easy and requires considerable skill. Second, national regulations and restrictions on the export of encryption technology have made integrating EFS harder for vendors. EFS encryption technology is based on the DES 56-bit encryption key. Current policy doesn’t permit the export of software with stronger than 40-bit encryption. While Microsoft and other companies hammer out the encryption regulations with the US government, EFS will be available in North America with standard 56-bit DES encryption. Outside North America, only 40-bit DES encryption will be available. Standard 56-bit DES encryption is downward compatible with 40-bit encryption; however, 40-bit encryption isn’t compatible with 56-bit encryption.
A Welcome Addition
Win2K’s new encryption feature—one of the OS’ major enhancements—is a welcome addition. Microsoft seems very interested in making Win2K a serious competitor for rival OSs (e.g., UNIX, AS/400) that run on minicomputers and mainframe computers. EFS, and other Win2K features, brings Microsoft a step closer to this goal.
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.
