Windows NT® Server
Server Operating System
White Paper
This document provides an executive summary and a technical overview of the encrypting file system (EFS) that will be included with the Microsoft® Windows NT® 5.0 operating system.
EFS provides the core file encryption technology to store Windows NT file system (NTFS) files encrypted on disk. EFS particularly addresses security concerns raised by tools available on other operating systems that allow users to access files from an NTFS volume without an access check. With EFS, data in NTFS files is encrypted on disk. The encryption technology used is public key-based and runs as an integrated system service making it easy to manage, difficult to attack, and transparent to the user. If a user attempting to access an encrypted NTFS file has the private key to that file, the user will be able to open the file and work with it transparently as a normal document. A user without the private key to the file is simply denied access.
© 1997 Microsoft Corporation. All rights reserved.
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.
Microsoft, MS-DOS, Win32, and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.
Other product or company names mentioned herein may be the trademarks of their respective owners.
Microsoft Corporation · One Microsoft Way · Redmond, WA 98052-6399 · USA
0997
A standard safety measure on a personal computer system is to attempt to boot from a floppy disk before trying to boot from the hard disk. This guards users against hard drive failures and corrupted boot partitions. Unfortunately, it also adds the convenience of booting different operating systems. This can mean someone with physical access to a system can bypass the built-in security features of the Microsoft® Windows NT® file system access control by using a tool to read Windows NT file system (NTFS) on-disk structures. Many hardware configurations provide features like a boot password to restrict this kind of access. Such features are not in widespread use, and in a typical environment, where multiple users are sharing a workstation they don’t work very well. Even if these features were universal, the protection provided by a password is not very strong.
Typical scenarios where unauthorized data access becomes an issue include:
A stolen laptop—It only takes a moment for someone to pick up an unattended laptop. What if the thief is not interested in reselling your computer, but is interested in the sensitive information stored on its hard drive?
Unrestricted access—Office desktop systems are left unattended and anyone can come in and quickly steal information from an unattended computer.
The root of these security concerns is sensitive information, which typically exists as unprotected files on your hard drive. You can restrict access to sensitive information stored on an NTFS partition if Windows NT is the only operating system that can be run and if the hard drive cannot be physically removed. If someone really wants to get at the information, it is not difficult if they can gain physical access to the computer or hard drive. Availability of tools that allow access to NTFS files from MS-DOS® and UNIX operating systems makes bypassing NTFS security even easier.
Data encryption is the only solution to this problem. There are a number of products on the market that provide application-level file encryption using password-derived keys. However, there are some limitations with most of these approaches:
Manual encryption and decryption on each use. Encryption services are not transparent to the user in most products. The user has to decrypt the file before every use and re-encrypt it when finished. If the user forgets to encrypt a file, the file is unprotected. And, because the user must go to the trouble of specifying that a file be encrypted (and decrypted) on each use, it discourages the use of encryption.
Leaks from temporary and paging files. Many applications create temporary files while a user edits a document (Microsoft Word for one). These temporary files are left unencrypted on the disk, even though the original document is encrypted, making data theft easy. And, application level encryption runs in Windows NT user mode. This means that the user’s encryption key may be stored in a paging file. It is fairly easy to gain access to all documents encrypted using a single key by simply mining a paging file.
Weak security. Keys are derived from passwords or pass-phrases. Dictionary attacks can easily breach this kind of security if easy to remember passwords are used.
No data recovery. Many products do not provide data recovery services. This is another discouragement to users, especially ones who do not want to remember another password. In the cases where password-based data recovery is provided, it creates another weak point of access. All a data thief needs is the password to the recovery mechanism to gain access to encrypted files.
EFS addresses all the problems mentioned above and more. The following four sections go into detail on the encryption technology, where encryption takes place in the system, user interaction, and data recovery.
EFS is based on public-key encryption, taking advantage of the CryptoAPI architecture in Windows NT. Each file is encrypted using a randomly generated key, which is independent of a user’s public/private key pair; thereby stifling many forms of cryptanalysis-based attack.
File encryption can use any symmetric encryption algorithm. The first release of EFS will expose DES as the encryption algorithm. Future releases will allow alternate encryption schemes.
EFS also supports encryption and decryption on files stored on remote file servers. Note: in this case EFS only addresses encrypting data on disk. It does not encrypt data that is transferred over the network. Windows NT provides network protocols such as SSL/PCT to encrypt data access over the network.
EFS is tightly integrated with NTFS. When temporary files are created, the attributes from the original file are copied to temporary files as long as all files are on NTFS volume. If you encrypt a file, EFS encrypts its temporary copies also. EFS resides in the Windows NT kernel and uses the non-paged pool to store file encryption keys, ensuring that they never make it to the paging file.
The default configuration of EFS allows users to start encrypting files with no administrative effort. EFS automatically generates a public-key pair for file encryption for a user, if one does not exist.
File encryption and decryption is supported on a per file or entire directory basis. Directory encryption is transparently enforced. All files (and subdirectories) created in a directory marked for encryption are automatically encrypted. Each file has a unique encryption key, making it safe for rename operations. If you rename a file from an encrypted directory to an unencrypted directory on the same volume, the file remains encrypted. Encryption and decryption services are available from Windows NT Explorer. Additionally, command line tools and administrative interfaces are provided for advanced users and recovery agents so they can take full advantage of this capability.
A file need not be decrypted before use—encryption and decryption is done transparently when bytes travel to and from the disk. EFS will automatically detect an encrypted file and locate a user’s key from the system’s key store. Since the mechanism of key storage is based on CryptoAPI, users will have the flexibility of storing keys on secure devices, such as smart cards.
The initial release of EFS will not support file sharing. However, the EFS architecture is designed to allow file sharing between any number of people by the simple use of their public keys. Users can then independently decrypt files using their own private keys. Users can be easily added (if they have a configured public key pair) or removed from a group of permitted sharers.
EFS provides built-in data recovery support. The Windows NT 5.0 security infrastructure enforces the configuration of data recovery keys. You can use file encryption only if the system is configured with one or more recovery keys. EFS allows recovery agents to configure public keys that are used to enable file recovery. Only the file’s randomly generated encryption key is available using the recovery key, not a user’s private key. This ensures that no other private information is revealed to the recovery agent accidentally.
Data recovery is intended for most business environments where the organization expects to be able to recover data encrypted by an employee after an employee leaves or when encryption keys are lost. The recovery policy can be defined at the domain controller of a Windows NT domain. This policy is enforced on all machines in that domain. The recovery policy is under the control of domain administrators who can delegate this to designated data security administrator accounts using Windows NT Directory Service delegation features. This provides better control and flexibility on who is authorized to recover encrypted data. EFS also supports multiple recovery agents, by allowing for multiple recovery key configurations to provide organizations with redundancy and flexibility in implementing their recovery procedures.
EFS can also be used in a home environment. EFS will automatically generate recovery keys and save them as machine keys when there is no Windows NT domain. Home users can also use the command line tool to recover data using the administrator’s account. This reduces the administrative overhead for a home user.
The following sections provide user scenarios that demonstrate how EFS works.
The following figure shows the Windows NT Explorer context menu for file encryption services.
The context menu exposes the following EFS features to the user:
Encryption—This option allows the user to encrypt the currently selected file. If the current selection is a directory, it lets the user encrypt all files (and subdirectories) in the directory, in addition to marking the directory as encrypted.
Decryption—This option is converse to encryption. It allows the user to decrypt the currently selected file. If the current selection is a directory, it lets users decrypt all files in the directory, in addition to resetting the directory as unencrypted.
Configuration—Users can generate, export, import, and manage public keys used for EFS-based file encryption. Configuration is integrated with the rest of the user security settings. This feature is intended for advanced users who want to manage their own keys. Typically, users do not have to do any configuration. EFS will automatically generate keys for the user who does not have one configured for file encryption use.
In addition to the graphical interface, Windows NT 5.0 includes command line tools for richer functionality needed for administrative operations. The command line tools are:
Cipher command line utility—This provides the ability to encrypt and decrypt files from a command prompt.
Examples:
C:\>cipher /e “My Documents”C:\>cipher /e /s *cnfdl*The complete cipher command supports the following options:
CIPHER [/E | /D] [/S[:dir]] [/A] [/I] [/F] [/Q] [filename [...]]
/E Encrypts the specified files. Directories will be marked so that files added afterward will be encrypted.
/D Decrypts the specified files. Directories will be marked so that files added afterward will not be encrypted.
/S Performs the specified operation on files in the given directory and all subdirectories. Default "dir" is the current directory.
/I Continues performing the specified operation even after errors have occurred. By default, CIPHER stops when an error is encountered.
/F Forces the encryption operation on all specified files, even those which are already encrypted. Already-encrypted files are skipped by default.
/Q Reports only the most essential information.
filename Specifies a pattern, file, or directory.
Used without parameters, CIPHER displays the encryption state of the current directory and any files it contains. You may use multiple filenames and wildcards. You must put spaces between multiple parameters.Copy command—This will be extended with new options to export and import encrypted files in a transportable format.
Examples:
C:\>copy /e EncResume.doc a:The new options supported by copy command are:
copy [/E |/I] sourcefile destinationfile
/E exports an encrypted file (sourcefile) as an opaque encrypted stream of bits to destinationfile. The destinationfile need not be on an NTFS volume, it can be a FAT file on a floppy disk.
/I imports an opaque encrypted stream of bits from sourcefile as an EFS encrypted file on NTFS volume. The sourcefile need not be an NTFS file. However, destinationfile needs to be.All that the user needs to do is select one or more files and choose Encrypt from the File Encryption context menu. EFS will encrypt the selected files.
Once a file is encrypted, it is stored encrypted on the disk. All reads and writes to the file are decrypted and encrypted transparently. To find out if the file is encrypted, users can check the properties on the file to see that the encrypted attribute bit is on. Since the encryption is transparent, the user can use the file as before. For example, he can still open the Word document and edit it as before or open a text file using Notepad and do the same. Any other user trying to open this encrypted file will get an access denied error as the user will not posses a key to decrypt the file.
It is important to note that users (administrators, in this case) should not encrypt files in the system directory. This is because these files are needed for the system to boot. During the boot process, a user's key is not available to decrypt the files. Such an operation can render the system useless. Windows NT Explorer will safeguard this by failing encryption attempts on files with the system attribute. Future releases of Windows NT will provide secure boot capabilities that will support encryption of system files.
EFS also provides users the ability to transfer encrypted files across systems. The “Export Encrypted File” and “Import Encrypted File” features are extensions to the Copy command in a Windows NT command prompt. All that the user needs to do is specify the encrypted file as the source and another file in an unencrypted directory as the destination with the export option. The exported file is still encrypted. The user can then copy this exported file to different file systems including FAT, backup tapes, or send it as an e-mail attachment like a normal file. To be able to use the file on a system where it is copied to, the user specifies the exported file as the source and a new file name on an NTFS volume as the destination to import the file, and the new file is created as an encrypted file. Note: simply copying the file will make a copy in plaintext unless the directory in which the file is copied is marked encrypted, in which case the copy is re-encrypted. This is because the normal copy command uses file reads which are transparently decrypted by EFS. This can be used to create plaintext copies of an encrypted file for distribution.
Users can also mark directories as encrypted using the Windows NT Explorer context menu. Marking a directory encrypted will ensure that all future files in that directory are encrypted by default and all future subdirectories under it are marked encrypted. The directory list of files is not encrypted and you can enumerate files as usual, provided you have sufficient access to the directory.
Marking directories for encryption is similar to file encryption. A user simply selects the directory and chooses the encryption option in the Windows NT Explorer. In this case, the user has the option of only marking the directory for encryption or encrypting all the files and subdirectories underneath. Directory encryption provides users the ability to manage their sensitive files by simply copying them to encrypted directories.
Users will not need to decrypt files or directories for normal operations because EFS provides transparent encryption and decryption during data writes and reads. Such operations may however be required under special circumstances where a user needs to share an encrypted file with other users.
Users can decrypt files and mark directories unencrypted using the Windows NT Explorer context menu. The operation is similar to encryption. Performing this operation on one or more files will cause EFS to decrypt the entire file and mark it as unencrypted. In the case of decrypting a directory, the context menu also provides the option to recursively decrypt all encrypted files and subdirectories in that directory.
EFS recovery policy is implemented as part of the overall security policy for the system. It is either part of the domain security policy for Windows NT Domains or part of the local security policy for stand-alone workstations and servers. As part of the domain security policy, it applies to all Windows NT-based computers in that domain. The EFS Policy user interface is integrated as part of the Domain Policy and Local Policy interfaces. This interface allows recovery agents to generate, export, import, and backup recovery keys via a common key management control. Integrating the recovery policy with a system security policy provides a coherent security enforcement model. The Windows NT security subsystem takes care of enforcing, replicating, and caching the EFS policy. Therefore, users are able to use file encryption on a temporarily offline system, such as a laptop, much like they are able to logon to their domain account using cached credentials.
EfsRecvr command line utility—This will provide recovery agents the ability to query recovery keys and recover an encrypted file using any one of the recovery keys.
Examples:
C:\>efsrecvr /s:“My Documents” *.*The efsrecvr command supports the following options:
EFSRECVR [/S[:dir]] [/I] [/Q] [filename [...]]
/S Performs the recovery on files in the given directory and all subdirectories. Default "dir" is the current directory.
/I Continues performing recovery even after errors have occurred. By default, EFSRECVR stops when an error is encountered.
/Q Reports only the most essential information including the list of recovery key identifications to help the recovery agent load appropriate keys.
filename Specifies a pattern, file, or directory.EFS requires that a data recovery policy be set up at a domain level (or locally if the machine is not a member of a domain) before EFS can be used. The recovery policy is set up by domain administrators (or by delegated personnel known as recovery agents) that control the recovery keys for all machines in that domain.
If a user loses a private key, a file protected by that key can be recovered by exporting the file and sending it in e-mail to one of the recovery agents. The recovery agent will import the file on a secure machine with the private recovery keys and use the recovery command line tool to decrypt the file. The recovery agent then returns the plaintext file back to the user. In a small business environment or home environment where there are no domains, recovery can be done on the stand-alone computer itself.
This section provides a brief technical and architectural overview of EFS.
EFS implements data encryption and decryption using a public key-based scheme. File data is encrypted using a fast symmetric algorithm with a file encryption key (FEK). The FEK is a randomly generated key of a certain length required by the algorithm or by law if the algorithm supports variable length keys. Export issues relating to EFS are discussed in a separate document.
The FEK is encrypted using one or more key encryption public keys to generate a list of encrypted FEKs. The public portion of a user's key pair is used to encrypt FEKs. The list of encrypted FEKs is stored along with this encrypted file in a special EFS attribute called the Data Decryption Field (DDF). The file encryption information is tightly bound to the file. The private portion of the user’s key pair is used during decryption. The FEK is decrypted using the private portion of the key pair. The private portion of a user’s key pair is stored safely elsewhere in smart cards or other secure storage devices.
Note: that a user’s key encryption can also be done using a symmetric algorithm such as a password-derived key. EFS does not support this because password-based schemes are inherently weak due to their susceptibility to dictionary attacks.
The FEK is also encrypted using one or more recovery key encryption public keys. Again, the public portion of each key pair is used to encrypt FEKs. This list of encrypted FEKs is also stored along with the file in a special EFS attribute called the Data Recovery Field (DRF). Only public portions of the recovery key pairs are needed for encryption of the FEK in the DRF. These public recovery keys are required to be present at all times on an EFS system for normal file system operations. Recovery itself is expected to be a rare operation required only when users leave organizations or lose keys. Because of this, recovery agents can store the private portions of the keys safely elsewhere (on smart cards and other secure storage devices).
The following diagrams illustrate the encryption, decryption, and recovery processes.
Figure 1. File Encryption Process
Figure 1 shows the encryption process. The user’s plaintext file is encrypted using a randomly generated FEK. This file encryption key is stored along with the file, encrypted under a user’s public key in the DDF and encrypted under the recovery agent’s public key in the DRF. Note: that the figure shows only one user and one recovery agent—this can actually be a list of users and a list of recovery agents with independent keys. The first release of EFS will support single user and multiple recovery agents.
Figure 2. File Decryption Process
Figure 2 shows the decryption process. A user’s private key is used to decrypt the FEK using the corresponding encrypted FEK item in the DDF. The FEK is used to decrypt file data reads on a block by block basis. Random access to a large file will decrypt only the specific blocks read from disk for that file. The entire file does not have to be decrypted.
Figure 3. File Recovery Process
Figure 3 shows the recovery process. It is similar to decryption except that it uses the recovery agent’s private key to decrypt the FEK in the DRF.
This simple scheme provides a strong encryption technology and the ability to let multiple users share an encrypted file, as well as allowing multiple recovery agents the ability to recover the file if so required. The scheme is fully algorithm agile and any cryptography algorithms can be used for various encryption phases. This will be very important as new and better algorithms are invented.
EFS architecture is shown in the figure below.
Figure 4: EFS Architecture
EFS consists of the following components in the Windows NT operating system:
EFS driver. The EFS driver is layered on top of NTFS. It communicates with EFS service to request file encryption keys, DDFs, DRFs, and other key management services. It passes this information to the EFS file system run-time library (FSRTL) to perform various file system operations (open, read, write, and append) transparently.
EFS FSRTL. FSRTL is a module within the EFS driver that implements NTFS call-outs to handle various file system operations such as reads, writes, and opens on encrypted files and directories as well as operations to encrypt, decrypt, and recover file data when it is written to or read from disk. Even though, the EFS driver and FSRTL are implemented as a single component, they never communicate directly. They use the NTFS file control callout mechanism to pass messages to each other. This ensures that NTFS participates in all file operations. The operations implemented using the file control mechanisms include writing the EFS attribute data (DDF and DRF) as file attributes and communicating the FEK computed in the EFS service to FSRTL such that it can be set up in the open file context. This file context is then used for transparent encryption and decryption on writes and reads of file data from disk.
EFS service. The EFS service is part of the security subsystem. It uses the existing LPC communication port between the Local Security Authority (LSA) and the kernel-mode security reference monitor to communicate with the EFS driver. In user mode it interfaces with CryptoAPI to provide file encryption keys and generate DDFs and DRFs. The EFS service also provides support for Win32® APIs, which are programming interfaces for encryption, decryption, recovery, importing, and exporting.
Win32 APIs. These provide programming interfaces for encrypting plaintext files, decrypting or recovering ciphertext files, and importing and exporting encrypted files (without decrypting them first). These APIs are supported in a standard system DLL, advapi32.dll.
EFS provides data recovery to authorized recovery agents. The data recovery architecture is part of Microsoft's effort to meet current encryption export policy regulations and provide stronger than 40-bit encryption to our international customers. Towards this effort, EFS uses the standard DES encryption algorithm, which is based on a 56-bit encryption key. EFS is designed to support different encryption algorithms with varying key strengths for future enhancement.
Currently, Microsoft is working with the United States government to get export approval for EFS with 56-bit DES as the file encryption algorithm. While the review process is going on, Microsoft will make EFS available to our international customers using a 40-bit DES implementation as the file encryption algorithm. Windows NT products for the North American market will use the standard 56-bit DES encryption. Files that are encrypted using the 40-bit version of EFS will be importable into EFS versions that support the 56-bit DES. However, files encrypted using the 56-bit version of EFS will not be importable into EFS versions restricted to 40-bit DES to ensure U.S. export regulations are met. In the future, when the regulations allow export of stronger cryptography, customers worldwide will be able to migrate transparently and use new and stronger encryption algorithms with EFS.