• subscribe
October 16, 2006 12:00 AM

Vista and Longhorn Promise Enticing EFS Enhancements

Here's why the forthcoming OSs are better platforms for leveraging EFS for file encryption
Windows IT Pro
InstantDoc ID #93498

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.



ARTICLE TOOLS

Comments
    There are no comments to display. Be the first one!
You must log on before posting a comment.

Are you a new visitor? Register Here