As I discussed in the previous section, NTFS checks the ACL for each file and folder a user accesses and compares it against her access token. Access is granted only when the appropriate permissions are held by the the requester. However, this architecture has the potential to be circumvented. If NTFS isn’t used to access the hard disk, the data can be read just like any other data. Because Windows Server 2003 and Windows XP allow only NTFS to access its own partitions, this security is effective. If another operating system is used, or if special disk-reading equipment is connected to the hard disk, the data is completely unprotected.
The only way to ensure that data on the hard disk is not susceptible to this type of attack is to protect it with encryption. Storing the data on the hard drive in an encrypted state means that the requester must provide the decryption key for the data to be usable. Without the decryption key, the data is useless to the requester—regardless of the operating system making the request. Windows XP and Windows Server 2003 allow files on the hard disk to be encrypted using the Encrypting File System, or EFS.
To discuss the concepts and processes of EFS, I must first dispel a myth. EFS is not really a file system at all. It is a set of functions that work in conjunction with NTFS to encrypt and decrypt files that are stored on the hard drive. NTFS provides the core mechanics of fetching data from the hard drive, writing to the hard drive, checking ACLs, and so on. EFS does the added work of determining when a file must be encrypted or decrypted and performing that action.
Specifically, EFS works by generating a random symmetric key for a file, called the file encryption key (FEK), and encrypting the data portion of the file with that key. It then takes the requester’s public key from the local key store and encrypts the FEK with that public key. This chunk of encrypted data that allows the requester to decrypt the file is called the data decryption field (DDF). There is always at least one DDF for an encrypted file.
EFS then checks to see if any data recovery agents (DRAs) have been defined in a recovery policy. A recovery agent is an optional user who holds a specific type of certificate private key that, when configured properly, allows him to decrypt EFS files. If recovery agents have been defined, their public key is also used to encrypt a copy of the FEK. This chunk of encrypted data that allows a recovery agent to decrypt a file is called a data recovery field (DRF). Because more than one recovery agent can be defined through a recovery policy, there may be more than one DRF per encrypted file.
Tip
In Windows 2000, EFS required at least one recovery agent to operate. When no recovery agents were available, EFS would refuse to encrypt files. In Windows XP and Windows Server 2003, EFS allows full functionality without a recovery agent in place. This allows configurations in which only one unique key can decrypt data. To disable EFS in Windows XP and Windows Server 2003, a Group Policy Object must be defined or a group of registry settings must be made.
The result of all these operations is encrypted data, one or more DDFs, and zero or more DRFs. This data is then handed back to NTFS. NTFS writes all this data as provided to the hard drive and additionally marks the file as being encrypted with EFS. This process of encrypting files with EFS is shown in Figure 4-8.
Tip
Another common myth about EFS is that folders can be encrypted. While folders can be flagged to encrypt their contents, the folders themselves are not encrypted. Rather, new files within those folders will be automatically encrypted when they are created in that folder, and optionally, any existing files in the folder will be encrypted. This is a desired configuration for EFS, as it will ensure that new datafiles or temporary copies of encrypted files in the same directory will be protected. When individual files are marked for encryption and not the parent directory, data may unwittingly be written to the hard drive unencrypted.
When an application requests data from an encrypted file, EFS has to decrypt it. To do so, NTFS retrieves the entire file and passes the information to EFS. EFS examines the public and private keys of the requester to determine whether any of these keys can be used to decrypt a DDF or DRF associated with the file. When such a key is found, the FEK is decrypted and used to decrypt the file data. This decrypted data is then passed back to NTFS, which provides it to the original requester. Because all this is handled by NTFS and EFS, applications do not need to be aware of EFS files or take any special actions to handle them. This process of decrypting files with EFS is shown in Figure 4-9.
Tip
The process of decryption with a data recovery agent’s private key is the same as with the user’s private key, except that the DRF is decrypted instead of the DDF.
A new feature of EFS in Windows XP and Windows Server 2003 is the ability to have more than one DDF per file. This allows a user to add users to a file and give those users the ability to decrypt the file without being recovery agents. This EFS file sharing provides a highly secure way to share data between users when the data is located either on a local hard drive or on a network file share. The ability to have more than one DRF recovery agent per file has existed since EFS was first implemented in Windows 2000; it is only the ability to have multiple DDFs that’s new.
This new ability of EFS has one roadblock. The public keys of all additional users must be available to the file’s owner to add them as potential decryptors of the data. There are a few mechanisms to aid in locating public key certificates, such as Active Directory, but this is still largely a manual process. In most cases, the file owner must ask the desired user to identify, export, and then transfer a public key certificate. This can be time-consuming and is not a simple operation to perform for the majority of users. For more information on certificate stores and operations, see Chapter 9.
The true benefit of EFS is that the encrypted files are stored in a secure manner. Physical compromise of the computer does not necessarily compromise the data.
Consider our IT manager, Don Fink. Don uses a laptop as his primary work computer. He stores all his data on it, whether sensitive or not. He carries it to work and back home every day. When the laptop is at work, he keeps it chained to his desk there, and when at home, he chains it to his home desk. Don also happens to travel frequently by air and is no stranger to airports.
Karen Shaughnnessy, a would-be corporate espionage operative, has been hired by a rival to learn key information about Woodgrove Bank. Karen has targeted Don as a potential wealth of information. She feels Don will have enough information stored on his laptop to make overt theft worthwhile. Although Don doesn’t know it yet, he’s about to become a victim.
Through a process of careful observation and intelligence gathering, Karen knows what type of laptop Don has, as well as the briefcase he uses when traveling. She also learns when Don’s next trip is scheduled. Karen obtains a duplicate of the briefcase and ensures she is in line directly behind Don when going through the airport security checkpoint. This allows Karen to switch briefcases and leave with Don’s laptop. Don may not notice for a few minutes or even until he’s on his airplane. Either way, once the laptop is out of Don’s possession it’s too late.
Karen knows that there may be security safeguards on the computer. To work around any potential traps or protections, she removes the laptop’s hard drive. She then connects it to a computer already running another operating system, one that recognizes NTFS but doesn’t interpret ACLs (there are many of them). From there, it’s a simple matter for Karen to copy the contents of Don’s hard drive to her computer and begin sifting through the data.
This scenario happens more often than people realize. I periodically see news articles about laptops being stolen from corporate employees during transport. Unfortunately, there is no supplemental data to cite which laptops are business-oriented versus personal, but common sense says that a majority of laptops carried while traveling are corporate laptops. In all likelihood, a majority of these laptops contained at least a small amount of sensitive data. However, most corporations simply refuse to publicly admit that this happens to them. They may put procedures in place to try to avoid future repeats of the same incident, but often these attempts fail. If you use EFS to protect the data correctly, however, the problem can be solved.
Let’s assume Karen stole Don’s laptop as mentioned earlier. If Don has encrypted his sensitive data with EFS, Karen must obtain Don’s private key to decrypt the data. As long as Don’s password is sufficiently complex, this will take Karen a very long time. If Don were carrying particularly sensitive data, he may have removed the private key entirely from the computer and stored it on a floppy that he kept separate from his laptop. In that case, Karen must use a brute force attack to try to decrypt the data. Assuming Don is using AES encryption for his file (Don can configure the encryption EFS uses, though it’s not advisable), there are 2256, or about 1.158 x 1077, possible keys. Considering current technology, this type of attack would take so long to break that the data would be useless long before the attack succeeded. Also, remember that each EFS file has its own unique FEK. This means that the number of possible keys applies to each encrypted file individually.
Karen might use an attack commonly referred to as the Nordahl attack to gain access to Don’s files. In this attack, Karen installs another operating system or boots to another operating system with the compromised hard drive attached. Karen then uses tools to reset or overwrite the security information in Don’s SAM database. Very often, the attacker can overwrite the administrator password with her own. It’s then a simple matter of booting to the target OS and logging in. The two mitigations to this type of attack—removing the DRA’s key from the local computer and using Syskey to protect the operating system’s account database integrity—are both discussed in this chapter.
As you can see, EFS is a strong and effective way to protect data. Although it has enormous benefits, it does have some drawbacks. For example, encrypting a large amount of data with a strong key can take a noticeable amount of time. With the computing power available today to most users, this isn’t usually a problem. However, when used inappropriately, EFS can degrade a system’s performance. Consider the suggestions in the next section to ensure that it is used to maximum benefit while avoiding potential performance pitfalls.
Another feature that’s often considered a drawback is EFS’ reliance on private keys. Now that you know how EFS works, you can see that it requires the private key of a configured user or DRA to decrypt the data in a file. Without an appropriate private key, the data is lost. This makes the private key very valuable—without it, your data is lost! Sadly, most users and administrators do not realize this and reformat or reinstall their computers without backing up their private key stores. This often results in lost data.
You can avoid lost data in many ways. Simply backing up the private key is a very effective preventative measure. You can also configure a DRA in your domain and ensure that the DRA’s private key is kept safe. Both of these measures prevent EFS data loss, and both are discussed in this book.
EFS is simple to use and is only slightly more difficult to use correctly. Remember these few basic guidelines when using and deploying EFS:
Encrypt at the folder level instead of at the file level. This marks the folder so that new files created in the folder are encrypted at creation and continue to be encrypted.
Remove the private key of both the user and recovery agent when not in use. If a valid private key exists on the hard drive when it is compromised, it may be easier to attack that private key storage than to attack the EFS-protected files. Although this is cumbersome and temporarily prevents authorized users from reading files, it’s necessary to separate the key from the data to maximize the effectiveness of any encrypted data. For detailed guidance on this, see Chapter 9.
Encrypt only data that must be protected. Judicious use of EFS helps ensure system performace remains as high as possible.
Wipe the hard drive free of unencrypted data remnants after encrypting sensitive data. The process for doing this is covered later in this chapter.
Ensure an appropriate data recovery strategy is deployed throughout your organization before EFS is used. Clients lose their private keys more often than you might think. If there’s no way for you or a designated recovery agent to decrypt the files, the protected data may be lost. Either back up each user’s private key or establish a DRA to prevent against data loss.
Don Fink knows that his laptop is susceptible to theft. Unfortunately, he cannot avoid storing sensitive and proprietary data on it when traveling between offices. Don wants to store data securely so that, no matter what the situation, his data will remain confidential and only he can retrieve it. He would rather lose the data entirely than have the data fall into the hands of his competitors.
Don’s Windows Server 2003 infrastructure does not yet include a centralized certification authority (CA). He knows very little about public key cryptography and certificates. He only knows that he must keep his data confidential. Here are the steps that Don would take to create a new directory and ensure that its contents are encrypted:
Create a new folder on the hard drive to store his sensitive files. The path to Don’s folder is
C:\Secrets, although this name could be anything.Right-click on the folder and choose Properties.
Click Advanced.
Select the Encrypt Contents to Protect Data checkbox.
Click OK, then click OK. If the Confirm Attribute Changes dialog box appears, choose “Apply changes to this folder, subfolders and files.”
The folder and all its contents, including files and subfolders, are now encrypted. Because Don did not already have a certificate and private key that EFS could use, EFS generated one before encrypting the contents.
Tip
A public key certificate and associated private key may already exist for Don. This depends on whether a certification authority has been installed and configured within Woodgrove Bank and, if so, whether it is configured to issue EFS-usable certificates. In many cases, Don will have such a certificate and not know he has one. The only way Don can determine what certificate is used for EFS is to use the Certificates MMC snap-in as described later to identify the certificate with the Encrypting File System listed as its Intended Purpose.
Don knows that retaining the private key on the hard disk is inadvisable and that he must export the certificate and private key to a floppy disk for safekeeping. He can do this by completing the following steps whenever he is finished working with his encrypted data:
Click Start, click Run, type
mmc.exe, then press Enter.Click File, then click Add/Remove Snap-in.
Click Add.
Click Certificates, then click Add.
Select My User Account and then click Finish.
Click Close, then click OK.
Expand the Certificates—Current User container, expand the Personal container, then click Certificates.
Click the certificate that lists Encrypting File System under the Intended Purposes column. This is shown in Figure 4-10.
Click Action, click All tasks, then click Export.
Within the Certificate Export Wizard:
Select “Yes, export the private key.”
Select “Delete the private key if the export is successful.”
Enter a strong password that is difficult to guess.
Enter a save path to a floppy disk and click OK.
Now the private key is removed from Don’s saved private keys. EFS can continue to operate using the private key it has cached, but once Don logs off the computer, this cache will be erased. Don must import the private key from the floppy disk before he can decrypt any files encrypted with that private key. Importing a private key from a saved file is extremely simple:
Insert the floppy disk in the disk drive.
Click Start, click My Computer, then double-click the floppy drive.
Double-click the file saved earlier to import the private key.
Enter the password when prompted.
Tip
I frequently refer to the use of a floppy disk throughout the book. This is because the floppy drive is the most universal removable media device available and has been installed in computers as standard equipment for decades. However, floppy disks can go bad over time or with minimal abuse. Many other portable storage solutions—such as USB key drives, memory cards, and rewritable CDs—are available. In many cases, these removable solutions will work exactly the same as a floppy disk. When a floppy disk is specifically required, a note will be added to indicate that fact.
In our example, Don creates the folder for his encrypted data and marks it for encryption before any data is actually created. However, this may not always be possible. He may want the same level of protection for the data that he has already saved on his hard disk. He can follow the previous steps to mark a folder as encrypted and remove the private key. He would then drag files into the folder and they would become encrypted. However, because the files were previously stored as unencrypted on the hard disk, portions of those files may still exist unencrypted on the disk. Those file portions are often called data remnants. And although this data would not be easy to retrieve, a dedicated attacker with sophisticated equipment could do so.
To avoid data remnants on the disk for an indeterminant period, the disk should be wiped clean of unused data. This process, while fairly lengthy, can ensure that current technology cannot recover the old unencrypted data remnants. The procedure can be done by following these steps:
Click Start → All Programs → Accessories → Command Prompt.
Type
cipher.exe /w:directorywheredirectoryis a directory on the desired hard drive.
cipher.exe then identifies any portions of the
hard drive that are not currently in use and may contain old
unencrypted portions of protected files. It completely eradicates the
data from these portions, one at a time, across the entire hard disk.
Because of its thoroughness and the size of most current hard drives,
this process can take a very long time to complete. Use the
cipher /w command only occasionally when the above
circumstances exist.
In Don’s scenario, I assume that there is either no EFS recovery agent or that the recovery agent is configured by Group Policy. Don knows that the recovery agent can decrypt any files on the hard drive. He must identify the recovery agents, if any, and if their private key is located on his computer, it must be removed. This is to ensure that an unintended private key stored on the local hard drive cannot be compromised by an intruder and used to decrypt the files. To identify the EFS recovery agent(s) in use, Don will:
Right-click on an encrypted file in his encrypted folder and choose Properties.
Click Advanced.
Click Details.
The data recovery agents are identified in the list labeled “Data recovery agents for this file as defined by recovery policy,” as shown in Figure 4-11.
If any of the private keys for the listed recovery agent(s) are on the local computer, they should be removed using the procedure described earlier in this chapter.
EFS is primarily designed to encrypt local files. However, files stored on a file server can also be encrypted. Windows Server 2003 supports two methods of file sharing that can be used with EFS—the classic SMB file sharing and WebDAV file sharing. This complements file permissions on the remotely stored files and ensures that even with server compromise, only individuals with the appropriate private key can decrypt the files.
Tip
Remember that EFS works in conjunction with NTFS. When using a normal file share to save or open files, the NTFS operations are done at the file server. This means that all encryption and decryption of EFS files is done by the file server. The data on the network between your computer and the file server is not protected by EFS. To ensure true end-to-end security of your data, you must protect the data as it travels on the network. IP Security (IPSec) is a great way to do that and is the topic of discussion in Chapter 8.
David wants to save some files in a place where both he and Don can access them. He applies NTFS file permissions to these files and their parent directory. However, David is aware that many administrators have access to the file server. Because the data is extremely sensitive, David wants to ensure that even in the event of compromise of the file server, only he and Don can access the files. David also wants to ensure the availability and redundancy of the data, both of which are provided by a well-managed and -maintained file server.
To configure EFS to allow only himself and Don to access the files on a file share, David can take the following steps:
Contact the file server administrator and request access to a file share.
Map a drive letter to the file share.
Create a new subfolder on the file share or identify an existing folder to contain the protected data.
Apply file permissions to the folder as described earlier in this chapter. Ensure that only he and Don have access to the folder and files.
Right-click on each file and choose Properties.
Click Advanced.
Click Details.
Because David is the creator of the folder and file, he already exists as a valid user. To add Don to the list of users able to decrypt this file, click Add.
Select Don’s EFS certificate from the list, or click Find User to browse Active Directory for Don’s certificate. The former requires that Don’s certificate was imported to this computer, and the latter requires a CA configured to publish issued certificates to Active Directory.
Because of the way EFS encrypts the FEK with the user’s public key, Don does not share his private key with David. David can add any user whose public key certificate he can access, as long as that public key is configured to support EFS. When a user attempts to access the file, she must provide her private key, securely, to the file server. This is because the decryption occurs at the file server. Because this obviously assumes a high level of trust for the file server, any file server that will work with EFS must be configured within Active Directory as trusted for delegation. For more information about trusting a computer for delegation, see Chapter 7.
As discussed earlier, EFS works well without any administrative control. EFS can request a self-signed certificate and private key and is configured to work well with default settings. However, to provide centralized management and configuration, a number of settings can be configured. These settings determine whether EFS is enabled on the computer as well as identify the EFS recovery agent and the encryption algorithm used by EFS. All these settings are configured by Group Policy.
Don wants to ensure that a specific certificate is used as the recovery agent and that EFS uses the AES algorithm for file encryption. He also requires that users in the Interns organizational unit be unable to use EFS to encrypt their data. To stop the Interns users from using EFS, he configures a Group Policy Object (GPO) on the Interns OU, using the following steps:
Log on to a domain controller or a computer that has the Windows Server 2003 Administration Tools Pack installed as a Domain Admin.
Click Start → All Programs → Administration Tools → Active Directory Users and Computers.
Right-click the Interns OU and click Properties.
Click the Group Policy tab.
Click New and name the new policy EFS Lockout.
Click Edit to edit the EFS Lockout GPO.
Expand Computer Configuration → Windows Settings → Security Settings → Public Key Policies → Encrypting File System.
Right-click Encrypting File System and choose Properties.
Clear the checkbox for “Allow users to encrypt files using Encrypting File System (EFS).”
This policy will be applied to all interns and ensure that they do not encrypt files on their local hard drive. Because it is applied at the OU that contains the actual user and computer accounts, these policies will be enforced. For more information on how Group Policy applies to users and computers, see Chapter 5.
For the rest of the users in the domain, Don wants to configure them to use EFS properly as discussed earlier. He modifies the Default Domain Policy to correctly configure EFS using the following steps:
Log on to a domain controller or a computer that has the Administrative Tools Pack installed as a Domain Admin.
Click Start → All Programs → Administrative Tools → Active Directory Users and Computers.
Right-click the domain name and click Properties.
Click the Group Policy tab.
Click New and name the new policy EFS Configuration.
Click Edit to edit the EFS Configuration GPO.
Expand Computer Configuration → Windows Settings → Security Settings → Public Key Policies → Encrypting File System.
Right-click Encrypting File System and choose Add Data Recovery Agent.
Provide the public key certificate of the desired recovery agent.
Expand Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options.
Double-click the policy object labeled System Cryptography: Use FIPS-compliant algorithms for encryption, hashing, and signing.
Check Define This Policy Setting and choose Disabled.
These two policy settings will configure EFS with the desired recovery agent and configure it to use the AES encryption algorithm. Note that the algorithm policy setting may seem a bit backward in that you disable FIPS-compliant algorithms. In this case, the FIPS-compliant algorithm included with Windows XP and Windows Server 2003 is triple-DES. When the non-FIPS algorithm is selected, the strongest algorithm EFS supports is used. In Windows Server 2003 and Windows XP Service Pack 1 or later, that is the AES algorithm.
Don has now configured EFS for proper use within Woodgrove Bank. For some users, EFS is disabled entirely. For others, EFS is configured to use the strong AES algorithm and use a specific certificate as a recovery agent. This allows Don to be confident that EFS is being used consistently and securely, and that he can recover sensitive files when required.
Get Securing Windows Server 2003 now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
