Which of the following is an MS Windows component that enables encryption of individual files

Encrypting file system

Encrypting File System (EFS) is used to encrypt files and folders. EFS is easy to use, with nothing more than a check box in a file’s properties. It is “not fully supported on Windows 7 Starter, Windows 7 Home Basic, and Windows 7 Home Premium” (Microsoft, 2011c). EFS uses the Windows username and password as part of the encryption algorithm. EFS is a feature of the New Technology File System (NTFS), not the Windows operating system (Microsoft, 2011d).

Introduction

Microsoft's Encrypting File System technology is one of the strongest yet most underutilized security features that I have seen in my many years of working with Microsoft infrastructures and enterprise deployments. I have very rarely seen it used in enterprise or even medium-sized environments, and when I have, it has been in isolated instances where individuals or teams took it upon themselves to implement EFS-based security controls. This is not entirely without justification. EFS is easy for individuals to set up and use autonomously, but the proper deployment of EFS in large environments requires careful planning around certificate and recovery agent management, backup and restoration, and access model implementation. The consequences of improperly rolling out EFS can be serious: You can lose access to your data. To be more specific, inadequately designed EFS controls can result in files being encrypted on the file system that, based on a failure scenario, can prevent the decryption of files even though you may have physical access to them.

EFS, in its simplest form, is a Windows OS–based feature that allows a user (administrator or otherwise) to set a folder, or an individual file, to have its contents encrypted. Encrypting at the folder level is the typical method of using EFS as it guarantees that any file added to the encrypted folder is automatically encrypted. While you can certainly select an individual file and encrypt it, the examples used in this chapter will be based on folders that are created in a directory structure, and the folder itself marked for encryption. As mentioned, when a folder is set to be encrypted, all files created within that folder will be encrypted by their respective owners. Setting a folder to be encrypted is quite simple; you just pull up the Advanced Attributes of a folder and select Encrypt contents to secure data, as shown in Figure 2.1.

EFS is a user-based encryption control. Basically, the way it works is that when a user requests that a file or folder be encrypted, an EFS certificate is generated for the user and its private key is stored in the user's profile. The public key is stored with the files created by that user, and only that user can decrypt the file. Because of this, a recovery agent certificate is typically associated with a different user account, and that user's public key is also embedded in the file. This way, if the user loses the certificate used to encrypt the file, the recovery agent user, or more specifically the holder of the associate private key, can also decrypt the file. In the same way that the recovery agent public key is automatically stored with the encrypted file, you can also assign other users' public keys to a file, allowing them to decrypt it as well. This allows one file to be shared among multiple users while remaining encrypted on the file system. When an EFS certificate is either distributed by your CA or created automatically when an EFS operation is requested for the first time in a domain environment, the public key of the user's certificate is stored in AD. This is true for the recovery agent certificate as well, and in fact is how the public key is automatically included with EFS files created in a domain: It is pulled directly from AD based on the policy settings for the EFS file recovery group policy object. I will elaborate more on this later.

Let us take a moment to actually detail the encryption process. When it comes to multiple users sharing an encrypted file, knowing how this works at the file and encryption process level will help give you a better understanding of how EFS works in an enterprise or smaller AD environment. There is nothing magical about an EFS certificate. It is simply an X.509 certificate with a private/public key pair generated by the Rivest, Shamir, and Adleman (RSA) algorithm, with EFS as a key usage, as seen in Figure 2.2.

When the certificate is created for the user, the RSA algorithm is used to generate public and private keys that are stored in the user certificate. Only the public key is stored in AD. Data is encrypted with the public key, and decrypted with the private key. That is why the public key is public, so that other users can encrypt data for you, but only the person holding the private key can decrypt it. Not even the person encrypting the data with the public key can decrypt it once it is encrypted.

Most people I have spoken with about encryption seem to be under the impression that the RSA keys are used to encrypt and decrypt the actual data in an encrypted file. This applies to any RSA-based encryption by the way, not just EFS. What actually happens is that before the file is encrypted, a cryptographically strong random key is generated. In this case, it is based on the default Advanced Encryption Standard (AES) cipher. It is actually this key that the RSA algorithm encrypts, and not the data. The public RSA key is used to encrypt the AES key, which is used to encrypt the actual data.

Some Common Types of Encryption

With privacy being such a major concern, encryption tools are now included with some versions of the newer operating systems including Windows 7 and Apple OS X. These tools are BitLocker and FileVault, respectively. These encryption schemes can be applied selectively, only encrypting certain files or folders. They can also be used to encrypt an entire drive. This is known as full or whole disk encryption.

Full disk encryption (FDE) has some noteworthy advantages. We know from previous chapters that operating systems in their course of normal operation will leave artifacts scattered across the drive. Take swap space, for example. Even though we encrypt an entire folder containing our sensitive files, remnants (or the entire file) could be located in the swap space. Full disk encryption takes care of these data “leaks.” The term full disk encryption is a little misleading. It doesn't really encrypt the entire disk. In order to run BitLocker, there must be two partitions (sections) on the hard drive: one, known as the “operating system volume,” and the other, which contains the files to boot the machine, system tools, and so on. The operating system volume contains everything else including the vast majority of the items of most interest to us (Microsoft Corporation, 2009).

As they say, there is no free lunch. FDE has some drawbacks as well. Performance will likely suffer as the data are being encrypted and decrypted. This encryption/decryption is done “on the fly,” meaning that it occurs just before the data are saved or loaded into RAM. Passwords and keys are another concern. Recovering your data is dependent on having the proper authentication. If you lose or forget your password, you will very likely never get your data back. Encryption cuts both ways.

Encrypting File System

☑

The Encrypting File System allows you to encrypt individual files, or all files within a folder.

Windows Vista adds support for EFS keys held on smart cards; page file encryption; offline file encryption based on the user’s key; and policies to control the indexing of encrypted files.

Always set up a Data Recovery Agent to allow you to recover files after the user who encrypted them has left your domain; export the DRA keys into a PFX file so that the DRA’s private key is not resident on the system.

EFS keys and algorithms

EFS utilizes both symmetric and asymmetric key technology to encrypt and secure data on NTFS volumes. A symmetric key is a single key which can quickly be used to encrypt or decrypt larger amounts of data. Symmetric keys are often used to encrypt content because of the speed advantage they have over key pairs. EFS utilizes symmetric keys to secure data content.

Asymmetric key pairs are a complimentary pair of keys. One of the keys is used to encrypt while the other to decrypt. Asymmetric keys are slower when dealing with large amounts of data, and so, are not used in EFS to secure data, but are instead used to secure the symmetric key. So, ultimately, it is a combination of keys that are used by EFS to secure a user's data in the file system; a single key to encrypt the data content and a key pair to secure the single key.

In earlier iterations of EFS, Microsoft has employed industry standard encryption algorithms such as Triple DES (3DES) and Data Encryption Standard X (DESX). As encryption standards have developed and improved, Microsoft has continued to update EFS to support the newer protocols, as was evident with the release of Windows XP SP1. From Windows XP SP1, forward EFS began utilizing Advanced Encryption Standard (AES) as its primary encryption mechanism.

The newest version of EFS, included with Windows Server 2008 R2 and Windows 7, has followed in the same footsteps as the preceding versions and has been improved to reflect the algorithm standards that exist today. The following represent the algorithms supported by the Windows Server 2008 R2 iteration of EFS:

Advanced Encryption Standard

Secure Hash Algorithm (SHA)

Elliptic Curve Cryptography (ECC)

Smart card-based encryption

A critical addition to the preceding list is the new support for ECC. Many environments today are required to comply with stricter regulatory requirements. The addition of ECC allows for these high-security environments to comply with Suite B encryption requirements as set forth by the National Security Agency. Today, Suite B compliance is utilized by United States government agencies to protect classified information.

EFS and policy enforcement

With additional compliance regulations existing in many environments today, administrators often need a mechanism to control the enforcement of certain security policies. In Windows 7 and Windows Server 2008 R2, you have the capability to control the way EFS behaves in the Local Computer Policy on the machine. Utilizing the Local Computer Policy, you have the ability to enforce ECC as well as configure other settings such as if Smart Cards are required for EFS usage. Since Local Computer Policy settings are administrated individually on each computer, it makes it very difficult to use these settings in a larger environment.

The most common way to enforce policy onto large groups of machines in an AD environment is by utilizing Group Policy. In order to address EFS policy enforcement on a broader scale, Microsoft has incorporated settings into Group Policy to allow the capability to control and enforce settings centrally for new EFS components. You will file EFS settings within a Group Policy under Computer Configuration | Policies | Windows Settings | Security Settings | Public Key Policies | Encrypting File System.

In Suite B compliance environments, the usage of RSA encryption algorithms is not allowed and only ECC may be used for EFS. Group Policy has three ECC pertinent settings, Allow, Require, and Don't Allow, which are displayed in Figure 10.21.

Figure 10.21. EFS ECC Policy Settings.

The Allow setting simply allows the use of ECC, but does not enforce it. This means that both RSA and ECC are available when this setting has been configured. If you are in an environment that requires Suite B compliance, Allow is not an appropriate setting. Instead, you would want to select the second radio button for Require. Require prevents the use of RSA and enforces that ECC be the only protocol in use with EFS. The final setting of Don't Allow blocks the usage of ECC, thus all EFS key sets will be generated utilizing RSA.

Fourth Defensive Layer: You'll Need That Secret Decoder Ring

Imagine for a second that an attacker has targeted you and has managed to penetrate all three of the layers in this chapter that you have prepared. All that is left is the asset your organization holds most dear: its data – information on its payroll and financial health, intellectual property, proprietary product data, and documented analysis of your competitors. The last thing you will want is this most valuable asset being left bare for all to see (and take). There is one last line of defense that you can implement to safeguard your files: data encryption. The use of encryption technology would have prevented the disgruntled patron of Casa de Marginal in Scenario 2 (Attacking Customer Confidence) from reading and altering files.

There are a host of third-party vendors offering encryption software for Windows. There are too many options on the market to give any of them the justice they are due. This chapter focuses on the native Microsoft tools that ship with various versions of Windows. In recent versions – Windows XP and newer – there are two options to encrypt the contents of a volume on a hard disk: Encrypting File System (EFS) and BitLocker. Each tool is used for different purposes. EFS is designed to encrypt and decrypt individual files; BitLocker is used to encrypt an entire hard disk.

Tip

BitLocker Drive Encryption and EFS are not mutually exclusive. In fact, they can be used together in a rather effective combination. When using EFS, encryption keys are stored with the computer's operating system. Although the keys used with EFS are encrypted, their security could still be compromised if a hacker is able to access the operating system drive. Using BitLocker to encrypt, the operating system drive can help protect these keys by preventing itself from booting or being accessed if it is installed in another computer.

Using EFS

EFS encrypts files and folders individually based on the user account associated with them. If a computer has multiple users or groups, each user or group can encrypt their own files independently. EFS has been around since Windows 2000 and has been steadily improved with every new version of the Windows code base, either client or server. Unlike BitLocker, it neither requires nor uses any special hardware.

Although EFS has been available in all versions of Windows client and server operating systems since Windows 2000, it is fully implemented only in certain editions, specifically any of the Windows Server editions, Vista Enterprise and Ultimate, and Windows 7 Ultimate. It is not fully supported on Windows Vista Starter, Home Basic and Premium, and Business, or on Windows 7 Home Premium or Professional. On those versions, you can decrypt and modify encrypted files, but cannot encrypt them.

Working with encrypted folders and files is much the same as other file operations. Open Windows Explorer and right-click the folder or file you want to encrypt, and then click Properties in the context menu. Select the General tab and then click Advanced. The dialog box shown in Figure 2.9 will appear. Select the Encrypt contents to secure data (circled in the screenshot in Figure 2.9) check box and click OK. Finally click OK to confirm the operation. The encrypted folder or file in the file list in Windows Explorer will turn green once the encryption attribute is set. Decrypting a folder or file is nearly identical except that you will clear the Encrypt contents to secure data check box in the Advanced Attributes window and click OK to accept the change.

FIGURE 2.9. Encrypting a File Using EFS

Note

The first time you encrypt a folder or file, an encryption certificate is automatically created. You should back up your encryption certificate. If your certificate and key are lost or damaged and you don't have a backup, you won't be able to use the files that you have encrypted.

Using BitLocker

If your requirements suggest that encrypting the entire hard disk is preferred to working with individual files, BitLocker Drive Encryption is a better choice than EFS. Road warrior employees who truck laptops everywhere they go are very suitable candidates. A laptop left in an airport is an attractive target, especially because employees on the road tend to be self-contained, carrying all of the files they need to work on and anything they pick up on the road. An encrypted disk makes it extremely difficult to extract the data from the purloined computer.

A further benefit of BitLocker is that it can be used to encrypt the contents of removable media. BitLocker To Go works with many media, notably the ubiquitous Universal Serial Bus (USB) drives that are the bane of IT security professionals' existences and seem to proliferate at an alarming rate. Because it encrypts the entire disk, another unique characteristic of BitLocker and BitLocker To Go is that they disregard individual user accounts associated with files; it is either enabled or disabled for all users or groups on the system.

Tip

Like EFS, your options for encrypting the contents of your hard drive depend on the version of Windows that you are running. BitLocker is available only in Windows Vista Enterprise and Ultimate, Windows Server 2008 and Windows 7 Ultimate, which means it is not available in Vista Home Basic, Home Premium or Business, or in Windows 7 Home Premium or Professional.

Unlike EFS, BitLocker requires the use of special hardware before it can be enabled. A trusted platform module (TPM) is a secure cryptoprocessor that can store cryptographic keys, which is embedded in the workstations microprocessor. It must be enabled in the Basic Input/Output System (BIOS), which may or may not be by default. Once enabled, it will be displayed in Device Manager under Security Devices, as shown in Figure 2.10. The TPM must be of version 1.2 or later in order to be used with BitLocker. If a TPM is not installed or is an earlier version, you can also use a removable USB memory device, such as a USB flash drive to store its key. For this chapter, we will focus on enabling BitLocker on systems that have an embedded TPM.

FIGURE 2.10. Verifying that the TPM is Enabled

Once the TPM has been enabled in the BIOS and you have verified in Device Manager that Windows acknowledges its existence, you can manage it. Unlike other hardware on your system, there is a specific and rather robust applet for managing the TPM. The applet, shown in the screenshot in Figure 2.11, allows you to initialize the TPM, enable or disable it, and change the password, among other functions. The initial setup of the TPM is performed during the setup process for BitLocker; after verifying that the TPM has been initialized, you do not need to change the settings in order for BitLocker to be set up correctly.

FIGURE 2.11. Managing the TPM

Once you have the TPM enabled in the BIOS and have verified that it is recognized by Windows, you can proceed to configure BitLocker. The applet, shown in Figure 2.12, can be found through Control Panel | System and Security | BitLocker Drive Encryption. As shown in the screenshot in Figure 2.12, you use this single applet to configure it on both fixed disks and removable media. Please bear in mind that you need to be an administrator to work with BitLocker on fixed disks and once you click on Turn On BitLocker, you will need to confirm your permission to proceed through UAC. “Normal” users can enable and disable BitLocker To Go on their removable media.

FIGURE 2.12. Selecting the Drive to Encrypt with BitLocker

The setup process takes care of everything. Once you click on Turn On BitLocker or BitLocker To Go, it runs a check of your hardware and software to verify that your system satisfies the requirements to enable BitLocker. If you are enabling BitLocker in a hard disk drive, you will need to respond to the prompts that pop up in any UAC windows. The system check is depicted in Figure 2.13.

FIGURE 2.13. Verifying that BitLocker Can Be Enabled

If your hardware and software satisfies the system requirements for BitLocker, you will be presented with the screen shown in Figure 2.14. To get to this screen, the TPM has been discovered; if the TPM is not enabled, you will be instructed to enable it and start the process again. Since the TPM needs to be enabled in the BIOS, you will need to reboot before you restart the process.

FIGURE 2.14. Setting Up BitLocker

Once BitLocker or BitLocker To Go is configured on your desired disk, you are free to use your system the way you did before it was enabled. You will not notice a difference. The TPM provides the required credentials for the boot process to continue on a hardware restart. If you are not using a TPM (e.g., your hardware is not suitably equipped or you do not want to enable it for some reason), you will need the key that is installed on a USB drive in order for the computer to start.

As mentioned earlier, data encryption is the defense of last resort. By the time that an attacker encounters an encrypted file or disk, he has compromised an application that was vulnerable (perhaps it was left un-patched) or a user account with elevated privileges. Fortunately, Windows ships with a number of these defenses that simply await configuration. Your job is to ensure that the proper safeguards are in place.

EFS

The ability to use EFS to encrypt data has been around since the release of Windows 2000 (although it is notably absent from distributions such as Windows XP Home Edition and Windows Vista Home Basic), and allows users to easily apply encryption to select files and folders in a way that is more or less transparent. During the encryption process, keys are generated that are tied to a user's Windows username/password combination. The decryption of protected data is seamlessly accomplished for the logged on user (because the correct credentials were supplied when they logged onto Windows); however, anyone outside of that user's authenticated session will be unable to view the underlying data of an EFS-encrypted file.

Like with BitLocker, failing to recognize that files or folders are EFS-encrypted prior to imaging evidence can have significant repercussions. The names of files and folders encrypted with EFS are most often displayed as green in the Windows Explorer interface, and seeing such “green names” on a live, running machine can be the first clue that EFS-encrypted data exists (Figure 5.64).

Examiners can also choose to use tools such as efsinfo.exe (a part of the Windows XP Service Pack 2 Support Tools) to identify EFS-encrypted data along with the user account that is able to decrypt them as shown in Figure 5.65.

Most forensic tools will also identify EFS-encrypted data as demonstrated in Figure 5.66, although special steps will still have to be taken to view the data in its unencrypted form.

If EFS-encrypted data objects are located prior to imaging, obtaining unencrypted logical copies of the objects is always an option to insure against later inability to access the data on the forensic image. However, if EFS-encrypted data is encountered within a forensic image, the examiner does have other options.

Many forensic tools offer the ability to decrypt EFS files automatically, provided the proper user password is known (or guessed, or cracked) and entered as appropriate. As such, obtaining the proper password is the key (if you'll pardon the pun). The easiest way to obtain a user's Windows password is to ask the user; you never know, the user (or his or her system administrator) could surprise you by providing it willingly. Failing that, numerous options exist for the exporting of SAM and SYSTEM registry hives from a forensic image and the subsequent cracking or unmasking of passwords using the examiner's tool of choice (e.g., PRTK, Cain & Abel, 0phcrack, SAMInside, Linux, etc.). Before undertaking a true cracking action, though, the examiner may want to complete the following in the interest of avoiding unneeded frustration:

Attempt to guess the password based on things you know about the user or information supplied from other sources.

Dump the Windows protected storage area (which can include saved passwords and autocomplete data) from the registry using a tool such as Protected Storage Explorer by Forensic Ideas (www.forensicideas.com/tools.html).

Attempt to brute-force the password using a dictionary file filled with common passwords or passphrases, or a dictionary created by indexing the user's favorite web sites.

Understand the difference between cracking an LM password and trying to crack an NTLM password.

Tool Feature: Decrypting EFS

Once the proper username/password combination is obtained, decrypting EFS files becomes child's play. Figure 5.67 shows ElcomSoft's Advanced EFS Data Recovery Tool (www.elcomsoft.com/aefsdr.html), which can scan a drive for EFS-encrypted files and available EFS encryption keys, and enables the examiner to decrypt located keys using a Windows user password, and can even perform dictionary attacks on encrypted keys. If the correct password is supplied, the examiner is given the option to save all files that can be decrypted with that password in their decrypted (reviewable) state.

The EnCase Decryption Suite (EDS) and its built-in Analyze EFS… option can also be used to automatically locate EFS key files and then allow examiners to enter user passwords that will automatically be used to decrypt EFS data.

FVE vs. File/Folder Encryption

File-level encryption, as provided by Microsoft's Encrypting File System (EFS) and numerous third-party encryption programs such as CryptoForge and Folder Lock, allows you to encrypt individual files and/or folders. An advantage of file/folder encryption is that, because only specific files with sensitive data are encrypted, there is little/no reduction in general system performance, although it can slow down opening or working with the encrypted files. The user designates which files/folders to encrypt.

FVE has the advantage of requiring no action on the part of the user. That means you do not run the risk of users forgetting to encrypt a particular sensitive file. Another advantage is that FVE encrypts temporary files that might be created by applications in a folder other than the encrypted one, and it encrypts the page file/swap file which can contain copies of sensitive data that has been swapped from RAM. Finally, FVE can encrypt not only data volumes but also the operating system files. In fact, in the first version of BitLocker that was included with Windows Vista, only the operating system volume could be encrypted. Windows Vista Service Pack 1 added the ability to encrypt non-OS volumes on the internal hard drives and this ability was continued in subsequent iterations of BitLocker. Windows 7 added a new feature, BitLocker-to-Go, which allows full volume encryption of removable storage devices such as external USB hard drives and removable flash drives.

Full Volume Encryption

Windows BitLocker provides data encryption for volumes on your local hard drive. Unlike Encrypting File System (EFS), BitLocker encrypts all data on a volume—operating system, applications and their data, as well as page and hibernation files. In Windows Server 2008, you can use BitLocker to encrypt the whole drive, as compared to Windows Vista where you can encrypt volumes. BitLocker operation is transparent to the user and should have a minimal performance impact on well-designed systems. The TPM endorsement key is one of the major components in this scenario.

Inability to Open Files after Transferring from Another Computer

This problem is encountered when an encrypted file is transferred from a computer running an earlier version of Windows, such as Windows XP or Windows 2000, using the Windows Easy Transfer Wizard. When the file is accessed for the first time on the Windows Vista computer after migration, Windows Vista prompts you for the password on the old computer so it can update your account with new account information. You must provide the old password to update the EFS certificate and the key that is transferred during the migration. If you do not provide the password and instead cancel the password prompt, you will not be able to access the encrypted file. This problem occurs even if you were the owner of the file on the old computer.

You can resolve this problem by recovering the encrypted file. This is possible only when you import the EFS certificate and the key from the old computer. You can use the command prompt for quickly resolving the problem, as explained in following steps:

Click Start | All Programs | Accessories | Command Prompt.

Click Continue in the User Account Control dialog box.

In the command prompt window, type dpapimig.exe and press Enter.

Type the password you used on the old computer.

Click Confirm My Account Information And Update Content Protection.

Exit the command prompt window.

This will resolve the problem and you should be able to access the encrypted files you transferred from an old Windows XP or Windows 2000 computer.

For more information on resolving problems with encrypted files, use the Windows Help and Support utility in the Start menu and search for solutions using the keywords file encryption.