Encrypting File System (EFS) is an NTFS 5.0 feature that lets Windows users protect the confidentiality of files on an NTFS-formatted drive. Microsoft introduced NTFS 5.0 and EFS in Windows 2000 and enhanced the EFS functionality and feature set in Windows Server 2003 and Windows XP. These enhancements included support for sharing EFS-encrypted data and EFS support for offline folders. (For a detailed overview of some of these changes, see "EFS Enhancements in Windows XP," July 2002, InstantDoc ID 25410.)
Now, further EFS enhancements are on their way in the next wave of Microsoft client and server OSs— Windows Vista, the new client OS that will debut within the next six months, and Windows Longhorn Server, the server OS that will debut in 2007. Let's examine the basic functionality of EFS, then dive into the new functionality on the Vista and Longhorn horizons.
What EFS Does
Using EFS to encrypt the content of files and folders is relatively straight-forward:
Windows users can simply select the Encrypt contents to secure check
box in a file's advanced properties or choose the Encrypt command in a file
or folder's shortcut menu. The Encrypt/Decrypt shortcut menu option is a little-known
feature that's disabled by default. To enable it, you must add the EncryptionContext
Menu value with REG_DWORD data value 1 to the HKEY_LOCAL_MA CHINE\SOFTWARE\Microsoft\
Windows\CurrentVersion\Explorer\ Advanced registry subkey.
If you set the encryption attribute at the NTFS folder level, newly created files in the folder will be automatically encrypted. Unless you select the Apply changes to this folder, subfolders and files check box, files that already existed in the folder before the encryption attribute was set won't be encrypted. The same is true for decryption. The sharing of EFSencrypted data—an EFS feature that Microsoft introduced in Windows 2003 and XP—can't be configured at the folder level: It can be enabled only at the file level.
You can use Microsoft's Cipher.exe tool to automate and enforce encryption from the command line. To automatically encrypt data, you can include a reference to Cipher.exe in a user's logon or logoff script or in a machine's startup or shutdown script. In Windows 2003 and Win2K Active Directory (AD) environments, administrators can use Group Policy Objects (GPOs) to automatically distribute such scripts throughout the organization.
Under the hood, EFS is an excellent example of a hybrid cryptographic solution that combines the powers of symmetric and asymmetric cryptography. Asymmetric ciphers are cryptographically stronger than, but slower than, symmetric ciphers. EFS uses a symmetric cipher—Advanced Encryption Standard (AES), or Data Encryption Standard X (DESX) in earlier Windows versions (see "Tuning EFS," InstantDoc ID 46252 for details)—to encrypt the data and uses the RSA asymmetric cipher to provide secure storage of the data-encryption key. The EFS data-encryption key is known as the File Encryption Key (FEK). (For a comparison of symmetric and asymmetric cryptography, see the sidebar "Symmetric vs. Asymmetric Ciphers.")
A unique EFS feature is its support for data recovery, allowing a designated set of local or domain administrative accounts to decrypt and recover user data. This feature is indispensable should users lose or delete their EFS keys and be unable to access their encrypted data. EFS key loss can occur as a result of the accidental or intentional (e.g., when users leave the company) deletion of a user profile. (EFS keys are stored in the user profile.) Key loss can also occur after an administrator resets the user password (e.g., when a user forgets his password); EFS keys are protected by a key derived from the user password.
Starting with the EFS version embedded in Windows 2003 and XP, EFS can operate with or without a data-recovery account. In Win2K, you can use EFS only after you've defined a data-recovery account (which defaults to the built-in Administrator account on standalone machines and, in domain environments, to the domain administrator account defined on the first domain controller—DC—that's installed in the domain). For more information about EFS data recovery, see "Preventing Data Loss When Using EFS," Instant-Doc ID 46580.
EFS stores data-encryption and recovery data in NTFS file streams that are linked to the encrypted files. (For more information about NTFS file streams, see "NTFS File Streams," InstantDoc ID 45327.) EFS stores separate encrypted copies of the FEK in the NTFS file streams: one that only the user account that encrypted the data can access, and one for every data-recovery agent. The first resides in a field called the Data Decryption Field (DDF), and the second resides in the Data Recovery Field (DRF).
Enhanced Key Backup
A key EFS user pain point is data loss because of users who don't know or simply
forget about the importance of backing up their EFS private key. When users
install a new Windows OS or back up and restore EFS-protected data between different
machines without backing up their old EFS private key on the old machine or
OS and importing it into the new environment, and no data-recovery accounts
are defined, they'll lose access to the data they previously encrypted through
EFS.
In Windows 2003, XP, and Win2K, EFS doesn't warn or inform a user about the importance of EFS privatekey backup to a storage medium (e.g., a USB token) that's different from the hard disk that holds the OS—a big concern in standalone Windows 2003 and XP environments. In domain environments that use an integrated Windows 2003 public key infrastructure (PKI), users' EFS private keys can be automatically archived each time a user enrolls for an EFS certificate. This functionality is possible because of the integrated key-archive and -recovery service that's bundled with the Windows 2003 Certification Authority (CA). This concern is also less of a problem in Win2K, in which EFS always has a data-recovery account defined and in fact doesn't work at all if no data-recovery account is defined.
On standalone Vista and Longhorn Server systems, the OS automatically prompts the user to back up his or her EFS private key. Figure 1 shows the warning balloon that pops up from the system tray the first time a user uses EFS to encrypt data and each time a user gets a new EFS private key. When the user clicks this balloon, the dialog box that Figure 2, shows appears, and the user can choose to back up the key, receive a reminder at the next logon, or not back up the private key. If the user chooses to create a backup of the key, the OS starts the Certificate Export Wizard, from which the user can easily back up the private key to a secure password-protected and PKCS #12-formatted file. This file preferably resides on a removable storage medium other than the system's hard disk.
The user can also start the keybackup wizard manually at any time from the Control Panel User Accounts applet by using the Manage your file encryption certificates option and selecting Back up the certificate and key now. The wizard, which provides a straightforward path through the key-backup process, also links to a Help file that contains recommendations for copying a user's EFS private key in a safe place.
You can still back up your EFS private key from the Microsoft Management Console (MMC) Certificates snap-in—as you might in XP and earlier. To do so, simply open your EFS certificate from the snap-in and select Copy to File on the certificate viewer's Details tab. Doing so starts the Certificate Export Wizard. This time, make sure to select the wizard's Yes, export the private key option.
Remember not to confuse the EFS key backup and associated recovery mechanism that I've just described with the built-in EFS data-recovery feature. EFS data recovery is always enabled in Win2K EFS and is optional in Vista, Windows 2003, and XP EFS. EFS data recovery is based on the existence of an EFS recovery certificate and private key belonging to an administrative account. It allows access to encrypted data by the recovery account if a user loses his or her EFS private key or its backup. As such, EFS data recovery also protects against encrypted data loss.
To create a recovery certificate and private key on a standalone machine, a user with administrative privileges must run Cipher.exe as follows:
cipher /r:<filename>
This command creates the recovery certificate and private key; you must then save the resulting file to a USB token or other removable storage medium. To update the already encrypted files with the new recovery information, administrators can run the command
cipher /u
To create an EFS recovery certificate for domain-joined machines, you would typically enroll for a recovery certificate on an AD-integrated enterprise CA, then use the EFS GPO settings to distribute the recovery information to the domain-joined machines. For more information about doing so, see "Preventing Data Loss When Using EFS."
Easy Re-Keying
Another key-related EFS enhancement in Vista and Longhorn Server is the EFS
Re-key Wizard. This wizard lets a Windows user utilize a new EFS private key
to re-encrypt his or her EFS FEK. EFS doesn't automatically re-encrypt the FEK
when a user gets a new EFS private key; instead, it keeps a copy of the old
private key in the user's private key store (which is part of the user profile)
to make sure the user maintains access to previously encrypted data.
EFS re-keying is a valuable option when users switch to a new EFS private key because it removes a user's dependency on the old keys. With rekeying, you no longer need to back up the old EFS private key and keep a copy of it to maintain access to previously encrypted data. This is true only for the EFS-protected data stored on logical drives attached to a user's local machine. You can't use the re-key wizard to re-key EFS-protected files stored on a backup medium. In other words, if in this scenario you don't want to keep your old EFS keys, you must also make sure that you back up your EFS-protected files after each rekey operation.
The EFS Re-key Wizard is especially useful when users switch from a hard disk-based EFS private key to a smart card-based EFS private key. (I'll discuss smartcard support in more detail later.) With the wizard, users can gain complete independence from hard disk?based EFS private key storage: A smart card-based EFS private key can secure all EFS data, old and new. In organizations in which information security is crucial, EFS users might also need to use the EFS Re-key Wizard to regularly change their EFS private key. Changing keys more frequently reduces the chances of a successful attack. The wizard can also be useful for users who have used different keys to encrypt information on different computers, and who want to align the EFS keys between the different systems.
You can start the EFS Re-key Wizard, which Figure 3 shows, from the Control Panel User Accounts applet. Choose the Manage your file encryption certificates option, then select Create a new certificate. On the wizard's Update your previously encrypted files screen, you can select the encrypted data that you want to update with the new key material.
Clearly, EFS re-keying isn't an obvious action that you would expect average users to perform regularly. But we'll have to live with it for now: At this time, Microsoft doesn't provide an option to perform re-keying centrally or automatically at regular intervals.
Extended EFS Configuration and Central Control
In Vista and Longhorn Server, Microsoft exposes a valuable new set of EFS configuration
parameters, some of which control new EFS features that weren't available in
previous EFS editions. Prime examples include the ability to encrypt the paging
file, as well as the ability to control the clearing of the EFS encryption key
cache. In previous EFS editions, when an encrypted file was opened (and thus
decrypted) and paged to disk, the file became available in clear text in the
paging file. Also in previous editions, the EFS encryption key cache was only
cleared when a user logon session ended; now, the cache can be cleared when
a user locks his workstation or after a certain time limit.
The new EFS configuration settings can control EFS use, security configuration, certificate and private key parameters, and caching. In a Windows domain, these settings can also be leveraged from Group Policy to control the EFS behavior on user workstations. You can access the EFS settings from the properties of the Computer Configuration\Windows Settings\Security Settings\Public Key Policies\Encrypting File System container, as Figure 4 shows. (The figure doesn't show the EFS encryption key cache settings, which you control from the Cache tab.)
Thanks to the new configuration settings, administrators can now easily enable or disable the use of EFS on the Windows machines in their domain environment and centrally configure crucial EFS parameters. To disable the use of EFS, you must simply select the Don't allow radio button on the corresponding GPO object, as you see in Figure 4. Administrators can also require the use of a smart card for EFS by selecting the Require smart card for EFS check box, allow the use of self-signed EFS certificates by selecting the Allow EFS to generate self-signed certificates when a certificate authority is not available check box, and set the key length of the EFS RSA private keys that are used for self-signed certificates from the Key size for self-signed certificates drop-down list. (For EFS certificates that a Windows CA issues, you would set the key length in the corresponding AD certificate template.)
Changes Under the Hood
Vista and Longhorn Server EFS also include two important EFS changes that aren't
immediately visible from the Windows GUI: the support for smart cards and the
ability to more effectively use EFS with remote files. Microsoft finally supports
the storage of the EFS private key on a smart card. Smart card?based private
key storage is the most secure way of storing private keys. With earlier Windows
versions, you could store the EFS private key only in the user profile on the
hard disk. Provided each system that the user logs on to has a smart card reader
installed, smart cards are also the easiest way to implement roaming EFS keys.
Microsoft has also optimized the EFS cryptographic operations that are involved with storing the private key on a smart card. In previous EFS versions, the use of a smart card would slow down users' encrypted file access if the smart card?based EFS private key would be accessed for each encrypted file access. For this reason, Microsoft developed an accelerated mode for EFS private key storage on a smart card. The first time a user utilizes a smart card?based EFS private key to access an encrypted file, EFS will derive a software-based EFS private key from the smart card?based EFS private key and cache it in the security context of the Local Security Authority (LSA)—essentially, the system will cache it in a secure memory area. EFS will then use this software-based private key for encryption and decryption operations for the remainder of the user's logon session.
Another important change is the support for local encryption and decryption of EFS-encrypted files that reside on remote machines—for example, file servers. In previous EFS versions, when users accessed encrypted files on a file server, the file was decrypted on the file server and sent in clear text to the user's workstation. In Vista and Longhorn Server, Microsoft made changes to the Server Message Block (SMB) protocol—the default protocol for Windows file sharing—allowing SMB to transport the EFS metadata between the file server and the user workstation. The result is that an EFS-protected file essentially remains encrypted all the way to the client.
These SMB changes are part of the new SMB 2.0 protocol that's part of the Vista and Longhorn Server code base. In Windows 2003, Microsoft provides a similar capability through a set of WWW Distributed Authoring and Versioning (WebDAV) extensions. However, these extensions are useful only when the file server is linked to a Microsoft IIS Web server share and when the user utilizes the HTTP protocol to access the shared files.
Smart Security
Thanks to Vista EFS's introduction of such features as key-backup warnings and
wizards, the EFS Re-key Wizard, and smart-card support, Microsoft is making
it easier to use EFS more securely. Also, Microsoft is delivering new EFS features
that have been high on organizations' file-encryption requirements checklists—for
example, the smart-card support and more secure access of remote encrypted files.
EFS also complements the other data-protection and -encryption technologies—BitLocker Drive Encryption (BDE) and Windows Rights Management Services (RMS)—that Microsoft already offers. BDE is designed for single-user and volume-level encryption and isn't designed for the sharing of encrypted data. Enterprises that want encrypted file sharing should look at EFS. (For more information about Vista's BDE, see "Vista BitLocker: Boon or Bust?" InstantDoc ID 50182.) Enterprises that want permanent protection and encryption of data—even when data is removed from a protected folder or volume and attached, for example, to a Microsoft Outlook email message—must look at RMS. The RMS client is also bundled with Vista.
