How It Works
Encrypting File System
Randy Muller
Mobile users can be a pain in the neck for the IT pro. The convenience and portability of laptops must be weighed against the potential for data loss and the possible compromise of confidential company information. You can use NTFS permissions to control access to files and folders, and this usually works quite well, although there is always the potential for secure, confidential material to be accessed and released, either maliciously or unintentionally.
One way to control access to confidential material is to use the Encrypting File System (EFS). EFS is included with Windows® 2000, Windows XP, and Windows Server™ 2003; in fact, it is already enabled by default on all of them. You can use EFS in either a standalone or domain environment, although typically EFS is used in a domain environment where you can have defined auto-enrollment procedures as well as recovery agents (discussed later) in case of lost user keys. EFS should be used with caution in a standalone environment, as there is no mechanism for key recovery (and hence file recovery) outside users backing up their own keys. For the purposes of this article, I will limit my discussion to using EFS in a domain environment.
Encrypting a File
To encrypt a file, simply open the Properties of the file, click Advanced, and select "Encrypt contents to secure data," as shown in Figure 1. You can compress or encrypt a file, but not both. If the file was previously compressed and you now wish to encrypt it, the file will be uncompressed first. Once you have encrypted the file, Windows Explorer changes its display color to green (see Figure 2). If you mark an entire folder for encryption, a dialog box appears asking if you would like to apply changes to that folder only or to apply the changes to that folder, and its subfolders and files.
.gif)
Figure 1 Encrypting Files
What actually happens programmatically when you encrypt files, and how exactly does this prevent unauthorized individuals from accessing the data? EFS performs a series of steps to encrypt a file. First, EFS generates a File Encryption Key (FEK). It then employs a symmetric algorithm using the FEK to encrypt the file. The algorithm used depends on the version of the operating system. All versions of Windows 2000 use only the Expanded Data Encryption Standard (DESX). Windows XP RTM can use either DESX (the default) or Triple-DES (3DES). Windows XP Service Pack 1 (and later) and Windows Server 2003 support the Advanced Encryption Standard (AES) as well as DESX and 3DES, though AES is the default. Next, EFS extracts the public key from the EFS certificate contained in the user’s profile. If no such certificate is present, Windows enrolls a Basic EFS certificate from an enterprise certificate authority (CA) in the domain. EFS encrypts the FEK with the user’s public EFS key and stores it in the Data Decryption Field (DDF) in the header of the file.
Also in the header of each encrypted file is a Data Recovery Field (DRF). The DRF contains an encrypted key created using the recovery certificate from each recovery agent. Thus, there are two separate fields in each file—the DDF and the DRF. When a user opens an encrypted file, the user’s private key decrypts the FEK in the DDF; then the FEK decrypts the file. Only the private key from the user who encrypted the file can decrypt the FEK, ensuring the file remains secure. If necessary, a recovery agent can also decrypt the file using the encrypted FEK in the DRF. So only the user who encrypted the file and any designated recovery agents can access the file.
.gif)
Figure 2 Encrypted Files
Understand that encrypting a folder is much better than encrypting individual files. Actually, it’s a bit of a misnomer to state that you’re encrypting a folder; instead, the folder is marked such that each file currently in the folder is encrypted and any file subsequently placed in the folder is also automatically encrypted. Each file in the folder is encrypted with a unique FEK; there is no concept of "folder-wide" encryption. Why is folder-level encryption better? When you encrypt an individual file, Windows makes a backup copy of the file, encrypts the original, and then deletes the backup. Of course, "deleting" doesn’t really happen—instead, the disk clusters are simply released and can be reused for storing other data. The actual data is still present on the drive; this is called "slack space." An attacker could easily read this space using commonly available disk sector editing tools. Marking a folder for encryption changes this process. All files stored in the folder are immediately encrypted; no backup versions ever exist on the drive.
It’s also important to understand how EFS affects file moves and copies. If you copy or move an unencrypted file (or folder not marked for encryption) into a folder that is marked for encryption, that file (or all of the files in that folder) will become encrypted. Once encrypted, files will remain so no matter where you move them within the local file system—whether to folders not marked for encryption or to completely different partitions. The individual files themselves are not automatically decrypted. However, if a user has the permission to decrypt a file, and that user copies or moves an encrypted file to a file allocation table (FAT) or FAT32 partition, the destination file will be unencrypted.
Sharing Files
EFS in Windows 2000 didn’t provide a way to share your encrypted files with anybody else. The Data Recovery Agent (DRA) helps in cases of lost keys, but only the original user who encrypted the file and the DRA would be allowed access. Windows XP and Windows Server 2003 overcome this limitation by allowing multiple users (but not groups) to be added to each file. If both Alice and Bob are allowed to access a file, then that file’s DDF contains two copies of the FEK: one encrypted with Alice’s EFS key and one encrypted with Bob’s EFS key. To add an additional user to a file, open the Properties | Advanced | Details window for the file and click Add (see Figure 3). Then click Find User and search for the user you wish to add to the file.
.gif)
Figure 3 Adding a Certificate for Another User
One thing to keep in mind here is that each user who receives access to this file can then grant access to others—each allowed user is essentially considered an owner of the file. You can only add users who have valid EFS certificates to an encrypted file. If you try to add a user who doesn’t have a certificate, you will receive the error message shown in Figure 4.
.gif)
Figure 4 No Certificates Available
Recovery Agents
On domain-joined machines, the workstation inherits its data recovery policy from the domain. However, on workgroup machines running Windows XP or later, a data recovery agent must be created manually using the CIPHER tool (discussed later). Regardless, you should create a recovery plan and designate specific recovery agents. One of the major differences in EFS between Windows 2000 and Windows XP or Windows Server 2003 is that if you try to create a data recovery policy in Windows 2000 without specifying a recovery certificate, EFS is disabled. This is not true for Windows XP and Windows Server 2003. So if you do not limit a user’s ability to encrypt files and you haven’t created a data recovery agent plan, users could lose their work if their account is compromised or their keys lost. If you are going to use EFS with Windows XP or Windows Server 2003, you should have a recovery plan with designated DRAs established before users are allowed to use EFS.
One decision you will have to make is whether you are going to have separate key recovery agents and data recovery agents. If you choose to have separate roles, you will need to decide which users will have which roles. If you are going to combine roles, then you will again need to specify which user (or users) will be your data recovery agents. Obviously, whoever you designate to be your recovery agents should be trustworthy, reliable individuals!
.gif)
Figure 5 Requesting an EFS Recovery Agent Certificate
Typically, you create special accounts to be used only for recovery, then delete the domain administrator from the list of recovery agents. This allows you to audit the use of these accounts and eliminates the rather anonymous access that "Administrator" entails. Each recovery agent must be enrolled with an appropriate certificate issued to them from an enterprise certificate authority (see Figure 5). Once your recovery agent has a certificate, you will then have to add this recovery agent to the Group Policy Object (GPO) that you have applied to the container. To do so, right-click the Computer Configuration\Windows Settings\Public Key Policies\Encrypting File System setting of the policy and Add Data Recovery Agent. Then you will have to Select Recovery Agents and browse either through folders or through the directory to find the certificate and assign a recovery agent (see Figure 6).
.gif)
Figure 6 Assigning a Recovery Agent
EFS on Remote Servers
So far I’ve examined only the local use of EFS on a system that is joined to a domain. You can use EFS to encrypt files to provide access for users from remote locations, too. But how will users access these files remotely and how will the files be secured in transit to and from the remote server? Two methods for providing remote access to encrypted files are Server Message Block (SMB) file shares and WebDAV (Web-Based Distributed Authoring and Versioning).
There are a few inherent problems with using SMB file shares. Encrypted files are first decrypted before being delivered over the network, and then re-encrypted on the destination server. Therefore, you should use some other method to secure the traffic in-flight, such as IPsec.
The other issue is preparing the server for remote encryption. You must authorize the computer to perform the encryption/decryption on behalf of the user; a concept known as "trusted for delegation." To enable this delegation, open the properties for the server’s computer account in Active Directory Users and Computers, and select Trust computer for delegation (see Figure 7). Once you enable delegation, a dialog box appears informing you that this action carries a potential security risk. You also need to enable each user account for delegation. You should go to the account properties for each user, click the Account tab, and then select Account is trusted for Delegation.
.gif)
Figure 7 Trusted Computer
The other method of providing remote access to encrypted files is WebDAV. The advantage of WebDAV is that all encryption and decryption is performed at the local machine, not at the server. Files remain encrypted in transit, so it isn’t necessary to implement additional in-flight encryption. The server is not required to be trusted for delegation and it doesn’t store any encryption keys. You will have to install IIS and configure the remote server to support WebDAV.
Prohibiting EFS
Because of the serious risk of losing keys (and therefore losing access to encrypted files) with standalone EFS, some organizations choose to disable EFS until they can implement an enterprise certificate authority and domain-based EFS. EFS is enabled by default, so you will have to create a GPO to disable it. To disable EFS in an organizational unit, or as a domain-wide policy, simply clear the "Allow users to encrypt files using Encrypting File System (EFS)" checkbox in the Computer Configuration\Security Settings\Public Key Policies\Encrypting File System policy.
If you need to prohibit the use of EFS on a standalone computer or on a single computer in a domain, you can either modify the local machine policy or make a registry change. To disable EFS through a local policy, clear the same selection just discussed, "Allow users to encrypt files using Encrypting File System (EFS)", in the machine’s local security policy.
To implement this restriction via the registry, add a DWORD value of EfsConfiguration to the registry in the HKLM\SOFTWARE\Microsoft\WindowsNT \CurrentVersion\EFS. To disable EFS, change the value to 1; to enable it, change the value to 0 (see Figure 8).
.gif)
Figure 8 Prohibiting EFS through the Registry
CIPHER and EFSINFO
Two command-line tools are available to use with EFS: CIPHER.EXE and EFSINFO.EXE. Cipher, which is available in Windows 2000, Windows XP, and Windows Server 2003, encrypts or decrypts files, creates or backs up recovery keys, and creates new recovery agents on NTFS volumes. In Windows XP and Windows 2003, Cipher can also clear any slack space on the drive; this is important if you’ve encrypted individual files rather than marked entire folders for encryption.
Type "cipher" at a command prompt. The utility displays the encrypted state of the folder and any files or folders contained within that folder (see Figure 9).
.gif)
Figure 9 Output of Cipher
EFSINFO reports encryption information on various files. It is a useful tool for verifying and determining user information in the data decryption field or recovery agent information in the data recovery field of the specified file. It also displays your EFS certificate thumbnail on the local machine.
I hope that this column helps you to better understand EFS, and its ability to help mitigate the threat of data theft associated with mobile computers.
Randy Muller, MCT, MCSE, MCSA, MCDST, teaches a variety of networking, security, and other computer classes. He is a former Army Signal Corp Officer and has been teaching since 2000. You can contact Randy at randy@randymuller.org.
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.