Chapter 1: Planning Considerations

Published: May 29, 2007

The process of deploying data encryption tools to protect data in your organization requires you to thoroughly understand the technologies included in Microsoft operating systems, as well as the security concerns of your specific environment. You must also be prepared to identify and resolve potential deployment issues involving your choice of client hardware and its configuration, your organization’s security policy, and the complex issues of regulatory compliance and auditing.

This chapter of the Planning and Implementation Guide focuses on the planning considerations involved in deploying Windows Vista™ with Microsoft® BitLocker™ Drive Encryption (BitLocker) and the Encrypting File System (EFS) component of Windows Vista and Microsoft Windows® XP.

BitLocker and EFS planning considerations discussed in this chapter include hardware and software requirements, determining what computers and data items need protection, and choosing appropriate configurations. Other considerations include Active Directory® directory service and Group Policy deployment issues, manageability, usability, and planning for effective data recovery.

For EFS, additional considerations involve integrating EFS with an existing public key infrastructure (PKI), deploying the Microsoft Encrypting File System Assistant (EFS Assistant), and planning for effective key recovery.

Plan for BitLocker Drive Encryption

The following actions must be performed to complete a plan to deploy BitLocker:

1. Understand BitLocker deployment options
2. Evaluate BitLocker readiness
3. Determine the scope of BitLocker deployment
4. Choose BitLocker configuration
5. Plan for data recovery
6. Plan for manageability
7. Plan for usability
8. Plan for Active Directory and Group Policy implementation

The following subsections discuss these BitLocker planning issues in more detail.

Understand BitLocker Deployment Options

BitLocker is an effective mitigation against many security threats. Understanding which threats BitLocker mitigates, and which additional threats can be mitigated by combining BitLocker with EFS, requires you to understand BitLocker's security model and the deployment options it supports. The Security Analysis document included with this Toolkit describes a range of risks and how BitLocker mitigates them. You should thoroughly familiarize yourself with its contents before proceeding with your planning process.

Evaluate BitLocker Readiness

To use BitLocker, a computer requires the following components:

• Windows Vista™ Enterprise or Ultimate editions.
• If you want to use BitLocker with a TPM, a TPM-compatible motherboard (BIOS and TPM chip with Trusted Computing Group TPM spec. v.1.2 or later).
• Hard disk drive with two NTFS-formatted partitions. The partition where BitLocker boot component information will be stored should be an empty partition with at least 1.5 GB of free space. This partition should be the active partition.

You can confirm these requirements manually by using a Windows Management Instrumentation (WMI) script or PowerShell to query each client computer and gather information about its capabilities. Most organizations prefer to use a management tool such as Microsoft Systems Management Server (SMS) or a third-party equivalent, because these tools provide automated inventory and reporting facilities.

BitLocker Hardware Requirements

BitLocker can be run on any computer that complies with the system requirements for Windows Vista. (For more information about specific CPU, memory, and disk requirements, see the Windows Vista Enterprise Hardware Planning Guidance.) Although Microsoft has established separate “Windows Vista Capable” and “Windows Vista Premium Ready” categories for hardware that supports various Windows Vista features, BitLocker will work on any computer that supports Windows Vista.

To take advantage of the BitLocker support for TPM hardware, your computers must include TPM 1.2 or later hardware. Many manufacturers include TPM support as part of their standard products, and others offer it in limited subsets of their portable computer lines or not at all. There is no way to add TPM support to computers that do not already have it. However, you can use a USB key to store BitLocker encryption keys on computers that don’t include TPM hardware.

Computers that include TPM hardware must also have a BIOS version that enables Windows Vista to use the full set of TPM capabilities. Some computers that contain TPM 1.2 hardware might still require BIOS upgrades if they were shipped before January 2007. If you want to use BitLocker with a USB key, the BIOS must be able to read from the USB key during the boot process.

Note Some BIOS implementations support USB for booting the computer, but then disable this ability if the computer is booted from the hard disk or other device. These implementations are not compatible with BitLocker because it reads the USB key later in the boot process.

Each computer protected by BitLocker must have two disk partitions: one for the operating system and data, and a smaller partition used only when the computer is booted or during operating system upgrades. (You should not use this startup partition for other data storage.) Microsoft recommends that the startup partition have at least 1.5 GB of free space. Both of these partitions must be formatted using the NTFS file system (NTFS).

Users of Windows Vista Ultimate can use the Windows BitLocker Drive Preparation Tool to create the utility partition dynamically to enable the use of BitLocker. Users of the Enterprise edition can obtain the Drive Preparation Tool as described in Microsoft Knowledge Base article 930063, "Description of the BitLocker Drive Preparation Tool." Obtaining the tool requires a call to Microsoft Customer Support Services, but there is no charge for the call or for the tool. Microsoft does not support manually creating or moving partitions to create the required BitLocker partition configuration. You should either perform a clean installation of Windows Vista (creating partitions as part of the setup process) or use the Drive Preparation Tool.

If you plan to use USB flash drives as part of your BitLocker deployment, the models you use must implement the USB Mass Storage Class Bulk-Only Transport specification on the Universal Serial Bus Web site.

Understanding the TPM

Most organizations that deploy BitLocker will want the security benefits offered by computers that incorporate TPM hardware. Understanding this hardware and what it can provide is a critical part of choosing the appropriate BitLocker configuration for your organization. (A comprehensive examination of the TPM is outside the scope of this guide. For more specific information about the TPM and the Trusted Computing Group, see the Trusted Platform Module (TPM) Specifications page on the Trusted Computing Group Web site.)

It is important to understand the nature of the TPM, which is essentially a special-purpose microprocessor with its own I/O system and onboard storage. The TPM holds an endorsement key (EK) that is used to sign and encrypt data that comes directly from the TPM or that is passed to the TPM for signing or encrypting. The EK must be loaded onto the TPM, either by the computer manufacturer or automatically as part of BitLocker initialization.

You should also understand that the TPM can exist in one of several states at a given time:

• Enabled or disabled. The TPM might be enabled or disabled multiple times within a startup period. When the TPM is enabled, all of its features are available. When the TPM is disabled, it restricts all operations except the ability to report TPM capabilities and to accept updates.
• Activated or deactivated. When the TPM is activated, all of its features are available. Deactivated is similar to disabled, but changes to the operational state are possible (for example, change owner or activation with physical presence).
• Owned or unowned. When the operating system takes ownership of the TPM, the TPM generates a storage root key (SRK), which is a key pair used to seal operations on the protected volumes. The owner of a TPM may perform all operations, including operational state changes. BitLocker cannot use the TPM until it is in an owned state.

These states can be combined. For example, some vendors ship TPM-enabled computers for which the TPM is in a default state of disabled, deactivated, and unowned. To use BitLocker on such a computer, you must establish ownership of the TPM, activate it, and enable it. These operations are automatically performed when you use the standard BitLocker user interface. When BitLocker is turned on, it will automatically enable, activate, and take ownership of the TPM if one is present.

You also need to understand the requirement for physical presence for some TPM operations. The Trusted Computing Group TPM specifications require that a person interact directly with the physical computer to perform some commands, and this person cannot be replaced or imitated through a script. Physical presence indicates that a user is asserting ownership and is physically present at the computer to perform basic TPM administrative tasks, such as:

• Enabling the TPM without owner information.
• Activating the TPM.
• Clearing an existing owner from the TPM.
• Temporarily deactivating or disabling the TPM.

BitLocker Software Requirements

Windows Vista is available in several different editions, but only the Enterprise and Ultimate editions support BitLocker. Microsoft includes the Windows Anytime Upgrade feature (described in the Windows Vista online help), which you can use to upgrade individual computers. For example, you can upgrade from the Business Edition to the Ultimate Edition with the Anytime Upgrade feature. (Some upgrade types might require reinstallation. For example, 32- to 64-bit upgrades require a reinstallation of the 64-bit version of Windows Vista.)

Note The guidance and tools in the Data Encryption Toolkit for Mobile PCs apply to both EFS (available in Windows XP Professional SP 2 and all versions of Windows Vista) and BitLocker (available in Windows Vista Enterprise and Windows Vista Ultimate). However, Windows Vista Ultimate has not been rigorously tested for support of all features of the guidance and tools. The Toolkit is primarily intended for use with Windows XP Professional SP 2 and the Enterprise and Business editions of Windows Vista.

Deploying Windows Vista

The Solution Accelerator for Business Desktop Deployment provides comprehensive guidance and tools for deploying Windows Vista to your organization's client computers. As you plan your Windows Vista deployment strategy, remember that enabling BitLocker will probably require you to have physical contact with each computer because the TPM cannot be initialized or reprogrammed except from the affected computer's console. Also, you might need to update the BIOS of your computers to take full advantage of BitLocker's features.

One critical deployment decision is whether to upgrade existing computers from Windows XP to Windows Vista or whether to perform a clean installation of the new operating system. BitLocker cannot be enabled until you install Windows Vista. However, you should be aware that BitLocker requires a particular disk partitioning configuration (as described in the Windows BitLocker Drive Encryption Step-by-Step Guide). If you need to upgrade existing computers that run Windows XP, your deployment plan must provide for building the required partition structure before you can activate BitLocker on those computers.

The Windows Vista Business Desktop Deployment (BDD) toolkit supports automatic enablement of BitLocker under some circumstances. See the Lite Touch Installation Guide for details about how to use the BDD tools to enable BitLocker as a part of the operating system deployment process.

Determine the Scope of BitLocker Deployment

After evaluating which parts of an organization have hardware and software that support one or more modes of BitLocker, the next step is to determine exactly where BitLocker should be deployed. The following questions need to be answered to complete this step and determine the eventual scope of BitLocker deployment:

• Which computers in your organization need protection? You might choose to protect some or all of your mobile and desktop computers, depending on your security needs and deployment implementation cycle.
• Which data items in your organization need protection? Some organizations might want to protect all available data, and other organizations might have more specific requirements.

Which Computers Need Protection?

Security decisions usually involve a tradeoff between protection and cost, and a BitLocker implementation is no exception. The best security strategy might seem at first to be to deploy Windows Vista on all client computers in an organization and to enable BitLocker on them. However, most organizations will need to synchronize widespread implementation of Windows Vista (and therefore BitLocker) with their overall IT deployment plan. Still, every organization can benefit from targeted implementation of Windows Vista and BitLocker to computers that pose the greatest potential risk. These computers include:

• Computers used by executives, attorneys, or other employees who routinely work with sensitive financial, legal, or strategic data.
• Computers used by software developers, testers, Web site designers, or other users who might have access to personal or financial data about customers, employees, or business partners.
• Computers used by human resources staffers, insurance liaisons, medical staff, or other personnel who routinely handle sensitive personal information about customers or employees.
• Computers used in areas where they are vulnerable to physical attacks (including theft of disk drives or of the entire computer).
• Laptop or portable computers that employees use to access or work with company information while away from the office.
• Home or personal computers of key employees, if those computers are used to work on company information or access the organization's network.

To determine which computers in your environment need protection, use an automated asset inventory (if possible) to identify computers that fit one of the above groupings. You might want to supplement an automated inventory with a manual cross-check that matches employees who work with sensitive data and the organization-owned computers that they routinely use. If your organization uses a pool of mobile computers that are assigned to specific locations, or that are available for employees to check out, consider including them as a separate category of computers that require protection.

Which Data Items Need Protection?

One of the greatest benefits of BitLocker is that it protects all contents of the system volume. This functionality removes much of the uncertainty about which data items should or should not be encrypted. Every file that the user creates or touches will be encrypted if it is stored on the operating system volume.

However, it is important to identify specific categories or classes of data that might require BitLocker protection so you can better identify which users and computers are allowed to process those kinds of data. Candidate data types for protection include:

• Confidential business information, including financial data, product plans, banking or credit information, and strategic plans and communications.
• Information and records relating to pending, past, or future litigation, especially if it is subject to attorney-client privilege.
• Personal data about employees, former employees, retirees, or customers.
• Source code, databases, proprietary design information, trade secret materials, and other intellectual property.
• Material licensed from or owned by business partners or other licensors who might require that you keep such information confidential.

Choose BitLocker Configuration

This planning phase will determine which configurations are appropriate for your organization and outline the configuration and deployment process.

The Security Analysis guide in this Solution Accelerator contains a complete description of the security methods that can be used with BitLocker to protect the volume encryption keys. Use the information in the Security Analysis guide to choose BitLocker modes that are appropriate for your organization. The choice of BitLocker modes can depend on the availability of hardware and software as discussed previously or on different security requirements in different parts of the organization. The available modes are:

• BitLocker with TPM
• BitLocker with TPM and PIN
• BitLocker with USB device
• BitLocker with TPM and USB device

The following figure shows a decision tree that you can use to evaluate BitLocker configuration options for your environment.

The output of your decision process might be similar to what is shown in the following table. Information should include hardware roles, supported hardware types, and the associated BitLocker policy and configuration.

Table 1.1. BitLocker Policy and Configuration Guidelines

BitLocker with TPM Considerations

The BitLocker with TPM mode provides protection with no user intervention required, and volume encryption, boot, and operation are all transparent to the user. This BitLocker mode is not generally appropriate for a baseline BitLocker implementation, but should only be considered in the following situations:

• When multifactor BitLocker authentication is not required.
• When the value of the data does not warrant the added expense and/or complexity of multifactor BitLocker authentication.

Plan for BitLocker with TPM

The planning steps for the BitLocker with TPM mode include the following:

• An inventory of which computers in your organization have TPM hardware available.
• Your hardware upgrade and replacement cycle.
• How your existing software update and patch management processes work.
• Whether you have business or operational reasons to allow or disallow unattended startup of computers. BitLocker with TPM allows unattended startup, but BitLocker modes that use a PIN or a USB key require the PIN or USB key to be provided during startup.
• How your existing help desk processes (including hardware repair, replacement, and decommissioning) will work with TPM-protected systems, given that a BitLocker-protected disk might not be directly usable in a replacement computer.

BitLocker with TPM and PIN Considerations

BitLocker with a TPM and a PIN adds the ability to prevent domain users who don't know the PIN from reading data from the protected computer. It protects against attacks on the computer that would succeed if the computer booted to the logon screen.

The planning phase should determine whether users might resist having to learn and remember an additional PIN and take steps to overcome this resistance. The additional security of requiring an extra authentication factor makes this solution a good choice for protecting valuable assets.

Plan for BitLocker with TPM and PIN

To plan for the BitLocker with TPM and PIN mode, you need to follow all of the planning steps for the BitLocker with TPM mode. You must also construct a plan for the following:

1. Create user education documentation that will instruct users how to create a satisfactory PIN that meets the organization's security requirements and what to do if the user forgets their PIN.
2. Create documentation that will educate the help desk personnel about PIN reset procedures.

BitLocker with USB Considerations

BitLocker with a USB device provides protection on computers that do not contain a TPM. This mode provides basic functionality but does not provide boot-time integrity checking, and it does not prevent domain users from logging on to the computer and reading data after the system is booted using the USB device.

Plan for BitLocker with USB

If you plan to use BitLocker with a USB startup key, you will need to perform the following planning actions:

1. Test your computers to verify that they can recognize your preferred model of USB keys at boot time. Microsoft tests indicate that some brands of USB keys have failure rates in excess of 50%, so your testing should include reliability testing. You should also strongly consider standardizing on a single brand of key to ensure reliable access to startup and recovery passwords.
2. Plan for how those users who only use BitLocker with a USB key will migrate to the BitLocker with TPM and PIN mode. The plan should include how to migrate their data and applications to computers with TPM support or, if their existing computers support TPM, enabling TPM and re-enabling BitLocker.

BitLocker with TPM and USB Considerations

In this mode, BitLocker provides boot-time integrity checking and encryption and the USB token must be present at boot time to allow the computer to boot. The planning considerations for this mode are a hybrid of those required for the TPM-only and USB-only modes, because you must verify that your computers can use BitLocker with a TPM as well as prepare to support USB key storage.

Plan for BitLocker with TPM and USB

If you want to use this mode, you must perform the same planning steps as described in the "Plan for BitLocker with TPM" section earlier in this chapter, plus the steps in the "Plan for BitLocker with USB" section.

Plan for Data Recovery

BitLocker provides powerful encryption for your data. There are no "back doors" or other ways to recover data from a disk protected by BitLocker if you don't have the correct recovery password. This fact increases the importance of recovery planning, because without a good copy of the recovery password you will not be able to recover any data from a protected volume.

During computer startup, BitLocker could detect a condition that prevents it from unlocking the drive on which Windows is installed. Examples of these conditions include disk errors or changes to the computer's startup files. If one of these conditions occurs, you will not be able log on and access your protected files until you unlock the volume using your BitLocker recovery password. If you try to mount the hard disk in a different computer, you will still need the BitLocker recovery password.

There are four basic recovery password storage strategies:

• Print the password.
• Store the password on removable media.
• Store the password on a network storage location.
• Store the password in Active Directory.

Microsoft recommends that you choose a combination of recovery methods for your environment. Because BitLocker volumes are unrecoverable without the password, storing recovery passwords using a single recovery method introduces a single point of failure into your data recovery process. Each recovery method has advantages and disadvantages; you should be sure to understand these issues when choosing a method.

Active Directory

Microsoft strongly recommends that you plan for and deploy Active Directory storage of recovery passwords for your BitLocker-protected computers. Using this method, recovery information is stored as attributes on the computer object in Active Directory. Recovery information includes the recovery password for each BitLocker-enabled volume, the TPM owner password, and the information required to identify which computers and volumes the recovery information applies to. Optionally, you can also save a package that contains the actual keys used to encrypt the data as well as the recovery password required to access those keys. This method of storing the recovery password has the following major advantages compared to other storage methods:

• The storage process is automated and doesn't require user involvement.
• Recovery information cannot be lost or damaged by the user.
• Active Directory provides centralized control and auditing of recovery information storage and usage.
• Recovery information is backed up and protected alongside other valuable Active Directory data.
• Recovery information can be accessed remotely, making offsite and help desk-assisted recovery possible.

Using Active Directory to store BitLocker recovery passwords introduces the following requirements:

• The organization must have a robust and well-managed Active Directory infrastructure.
• The Windows Server® 2003 Active Directory schema must be extended to include BitLocker attributes and objects. Planning to extend the Active Directory schema is a significant undertaking. For more information about extending the Active Directory schema, see Extending Your Active Directory Schema in Windows Server 2003 R2.
• The administrator must then enable Group Policy settings to enable BitLocker recovery password backup.
• There must be sufficient policy and personnel safeguards to provide secure storage and controlled access to the recovery material stored in Active Directory.

Note Computers that go into recovery mode unexpectedly might have been attacked by malware. You should ensure that any computer that goes into recovery mode without a known cause is examined by your support staff before the user executes a recovery.

File/Printer Method

Printing the recovery password, or storing it in a file, is a simple process that has some important advantages:

• Easy to set up.
• Little infrastructure required.
• Easy to manage for non-technical users.

However, it also has some significant disadvantages:

• Relies on the user to manage the recovery password and secure it from loss or compromise.
• Storing passwords in this manner does not provide any centralized control or auditing.
• There is no effective protection to keep the saved file or printed paper from being lost or damaged.

USB Device Method

Storing the recovery password on a USB device provides the following advantages:

• You can store multiple recovery passwords on a single USB device because they are simple text files.
• It is easier to add physical security and barriers to protect the passwords.
• Separating the USB key from the computer provides a way to keep duties separated.

However, this method also has its disadvantages:

• Not all computers support mounting USB devices during the pre-boot and boot processes.
• Gathering and storing recovery passwords is a manual process that must be performed at each individual computer.
• There is no centralized control or auditing for this method.
• The USB device can be lost or damaged, or it may fail.

Define a Recovery Policy

It is important to define a policy that specifies who may recover data from a computer protected with BitLocker. BitLocker recovery requires physical access to the computer so that the recovery password can be entered. This requirement significantly influences the process of defining a recovery policy, because you might need to enable scenarios in which a remote or mobile user needs to regain access to a BitLocker-protected volume when they are away from the office.

By default, all domain administrators can read BitLocker recovery passwords that are stored in Active Directory Domain Services (AD DS). Domain administrators can delegate this capability to other users by assigning "control access" and "read property" permissions to those users. Similarly, administrators can delegate the capability to read stored TPM owner information. For example, you can grant help desk or telephone support staff the ability to access users' recovery passwords. However, before doing so you should ensure that allowing such access aligns with your organization's security policies, because any user who has access to the recovery password for a volume can read data on the volume without restriction.

Before you specify a mandatory recovery method, ensure that you meet any prerequisites necessary for that particular method. These prerequisites include:

• For USB keys, ensure that your target system has the ability to read USB devices at boot time. Also, test on a representative computer to ensure that your standard brand of USB key works properly with BitLocker before widespread deployment. Be sure to have the USB key available when you first enable BitLocker.
• For alternate storage locations, ensure that the recovery password is available to users when they need to execute a recovery. Do not use an alternate storage location on the same computer, because it won't be accessible during a recovery of the computer. Avoid using network shares that cannot be adequately secured against access by malicious or untrustworthy users.
• If you want to print the recovery password, ensure that a connected local or network printer is available when you enable BitLocker. Also, be sure to plan what to do with the printed password—paper records are subject to their own risks and threats.
• Active Directory storage for recovery passwords requires its own set of preparatory steps (as described in the next chapter).

Plan for Manageability

An important step in the BitLocker planning process is deciding how BitLocker affects the organization's IT management processes. BitLocker affects the following ongoing processes that are found in any organization:

• Software update management
• Hardware updates and replacement
• Integration with imaging, backup, and antimalware software
• Managing BitLocker configuration
• Decommissioning computers

Software Update Management

Three primary software update management scenarios affect BitLocker deployment planning.

The first scenario involves BIOS updates. BitLocker monitors a variety of components, including some aspects of the BIOS configuration, for changes. If any of these parameters change unexpectedly, BitLocker will force a recovery at each reboot. To avoid this problem, you should disable BitLocker before updating the system BIOS, update the BIOS, and then re-enable BitLocker.

The second scenario involves updates or patches to Windows Vista. If BitLocker is enabled with a TPM, there are two sub-scenarios:

• Updates that affect the boot manager, the operating system loader, the application used to resume from hibernation, or the memory diagnostic application. When BitLocker detects that one or more of these components have been altered by Windows Update, it updates its configuration information to reflect the new versions.
• Updates that affect other Windows components are applied according to the typical Windows update mechanisms, which don't affect the parameters measured by BitLocker.

Note If BitLocker is enabled but the TPM is not used, there is no trusted path for boot-time integrity and system updates cannot force a recovery or configuration update.

The third scenario involves version or edition upgrades (for example, moving from Windows Vista Enterprise to Windows Vista Ultimate). In such a scenario, you must decrypt the drive and disable BitLocker before applying the upgrade. After the upgrade is complete, you can enable BitLocker and re-encrypt the drive.

Hardware Updates and Replacement

A BitLocker-encrypted disk volume cannot be mounted and read in another computer unless you have access to the recovery password. When you boot Windows Vista, you can recover the volume by entering the recovery password so that the boot process can proceed. This functionality might require changes to your hardware repair and upgrade policy. Specific changes would vary according to how and when you replace computers, whether you use disk imaging or backup software to move data from one computer to another, and how you grant access to BitLocker recovery data.

Integration with Imaging, Backup, and Antimalware Software

BitLocker encrypts data at the disk volume level. Programs or utilities that directly access the disk while Windows is not running will be able to read data from the disk, but the data will be encrypted. For example, imaging tools will be able to capture the encrypted contents of a BitLocker-protected disk, but not the plaintext contents.

Most backup, restore, and antimalware tools that run while Windows is running will work as expected on a computer that uses BitLocker.

In addition, tools that change Windows system files or modify system configuration parameters may cause BitLocker to request a recovery password at the next boot. (Policy changes, such as switching from TPM-only to TPM with PIN modes, might also trigger the recovery process.) For more information about the impact of BitLocker encryption on software update management, see Chapter 3: Operations and Recovery Scenarios in this guide.

Managing BitLocker Configuration

Along with Group Policy, BitLocker supports the use of scripting to control and manage the fundamental behavior of the technology. For more information about scripting interfaces such as ProtectKeyWithTPM, see the BitLocker Drive Encryption Technical Overview document. Some organizations might decide to use scripting to enforce BitLocker policy and others will choose Group Policy. This decision should be made relatively early in the planning process.

The BitLocker control options that are available in the Windows Vista Group Policy Management Console (or on other computers that have the Windows Vista Administrative Templates installed) allow you to control the following:

• Whether or not BitLocker keys are automatically backed up to Active Directory.
• The default location used to store recovery keys.
• Whether users can change recovery and startup options.
• What encryption method BitLocker uses.
• How TPM platform validation is performed.

The remainder of this section describes each of the settings in the template. You can access these settings at \Computer Configuration\Administrative Settings\BitLocker Drive Encryption.

Turn On BitLocker Backup to Active Directory Domain Services

This policy setting allows you to manage the Active Directory Domain Services (AD DS) backup of BitLocker Drive Encryption recovery information. By default, this setting is marked as Not Configured. If you enable this policy setting, BitLocker recovery information is automatically and silently backed up to AD DS when BitLocker is turned on for a computer.

BitLocker recovery information includes the recovery password and some unique identifier data. You can also specify that Windows should back up a recovery key package, which contains a BitLocker-protected volume's encryption key, along with the recovery password. This key package is secured by the recovery password and can help perform specialized recovery when the disk is damaged or corrupted.

If you select the Require BitLocker backup to AD DS option, BitLocker cannot be turned on unless the computer is connected to the domain and the AD DS backup succeeds. This option is selected by default to help ensure that BitLocker recovery is possible. If you turn this option off, BitLocker still attempts to register recovery keys in Active Directory, but if the registration fails, BitLocker setup can continue. Backup is not automatically retried and the recovery password might not have been stored in AD DS during BitLocker setup.

Important To prevent data loss, you must have a way to recover BitLocker. If you disable or do not configure this policy setting, BitLocker recovery information is not backed up to AD DS.

Control Panel Setup: Configure recovery folder

This policy setting allows you to specify the default path that displays when the BitLocker Drive Encryption setup wizard prompts the user to enter the location of a folder in which to save the recovery password.

If you enable this policy setting, you can specify the path that is used as the default folder location when the user chooses the option to save the recovery password in a folder. You can specify either a fully-qualified path or include the target computer's environment variables in the path. If the path is not valid, the BitLocker setup wizard will display the computer's top-level folder view.

If you disable or do not configure this policy setting, the BitLocker setup wizard displays the computer's top-level folder view when the user chooses the option to save the recovery password in a folder.

Note The user will always be able to select other folders in which to save the recovery password.

Control Panel Setup: Configure recovery options

This policy setting allows you to configure whether the BitLocker Drive Encryption setup wizard prompts the user to save BitLocker recovery options.

Users have two recovery options for unlocking access to BitLocker-encrypted data:

• Type a randomly generated 48-digit numerical recovery password.
• Insert a USB flash drive that contains a randomly generated 256-bit recovery key.

The recovery keys or passwords are generated at the time of BitLocker setup. If you enable this policy setting, you can configure the options that the setup wizard exposes to users for recovering BitLocker. For example, disallowing the 48-digit recovery password prevents users from being able to print or save recovery information to a folder.

If you disable or do not configure this policy setting, the BitLocker setup wizard presents users with ways to store recovery options. Saving to a USB flash drive stores the 48-digit recovery password as a text file, and the 256-bit recovery key as a hidden file. Saving to a folder stores the 48-digit recovery password as a text file. Printing will provide the 48-digit recovery password.

Note If TPM initialization is needed during the BitLocker setup, TPM owner information is saved or printed with the BitLocker recovery information.

Control Panel Setup: Enable advanced startup options

This policy setting allows you to configure whether the BitLocker Drive Encryption setup wizard prompts the user to set up an additional authentication that is requested each time the computer starts. In this policy setting, you can control the following aspects of BitLocker startup:

• The Allow BitLocker without a compatible TPM setting controls whether BitLocker can be used on computers that don't include a supported TPM. On computers with no TPM, you must use a USB device to hold the startup key, which means that the computer must be capable of reading a USB device at boot time. Without a TPM, BitLocker-encrypted data is protected solely by the key material on this USB flash drive.
• On a computer with a compatible TPM, you can choose which startup methods are available to users. When the computer starts, it can require users to insert a USB flash drive that contains a startup key. It can also require users to enter a 4 to 20-digit startup PIN.

If you enable this policy setting, the wizard displays a page that allows the user to configure advanced startup options for BitLocker. You can also configure setting options for computers with and without a TPM.

If you disable or do not configure this policy setting, the BitLocker setup wizard displays basic steps that allow users to enable BitLocker on computers with a TPM. In this basic wizard, no additional startup key or startup PIN can be configured.

If you want to use BitLocker without a TPM, or with a TPM plus a PIN or startup key, ensure that the Local Computer policy (or the cumulative effective Group Policy) is configured for Advanced Startup options (see the following figure). This configuration must be set before BitLocker is enabled, and can be found at Computer Configuration\Administrative Templates\Windows Components\BitLocker Drive Encryption\Control Panel Setup: Enable advanced startup options.

Configure encryption method

This policy setting allows you to configure the algorithm and key size used by BitLocker. This policy setting applies to a fully decrypted disk. Changing the encryption method has no effect if the disk is already encrypted or if encryption is in progress. The policy setting has four options:

• AES 128-bit and AES 256-bit use the FIPS-standard Advanced Encryption Standard (AES) algorithm with the specified key strength.
• AES 128-bit with Diffuser and AES 256-bit with Diffuser add the Diffuser algorithm described in the Security Analysis guide. The diffuser layer adds some security properties that are desirable in the disk encryption setting but which are not provided directly by AES in cipher block chaining (CBC) mode.

If you enable this policy setting, you can configure the encryption method that is used to encrypt an unencrypted volume. If you disable or do not configure this policy setting, BitLocker uses the default encryption method of AES 128-bit with Diffuser or the encryption method specified by a local administrator's setup script.

Prevent memory overwrite on restart

This policy setting controls computer restart performance at the risk of exposing BitLocker secrets. BitLocker secrets include key material used to encrypt data. This policy setting applies only when BitLocker protection is enabled.

If you enable this policy setting, Microsoft Windows does not instruct the computer to overwrite memory on restarts. Preventing memory overwrite might improve restart performance, but it increases the risk of exposing BitLocker secrets.

If you disable or do not configure this policy setting, Windows helps ensure that BitLocker secrets are removed from memory when the computer restarts. By default, this policy is not configured.

Configure TPM platform validation profile

This policy setting allows you to configure how the computer's TPM security hardware secures the BitLocker encryption key. This policy setting does not apply if the computer does not have a compatible TPM or if BitLocker has already been turned on with TPM protection.

If you enable this policy setting before turning on BitLocker, you can configure the boot components that the TPM validates before unlocking access to the BitLocker-encrypted operating system volume. If any of these components change while BitLocker protection is in effect, the TPM will not release the encryption key to unlock the volume and the computer will enter into recovery mode during boot.

If you disable or do not configure this policy setting, the TPM uses the default platform validation profile or the platform validation profile specified by a local administrator's setup script. The default platform validation profile secures the encryption key against changes to the Core Root of Trust of Measurement (CRTM), BIOS, and Platform Extensions (Processor Configuration Register 0, or PCR 0), the Option ROM Code (PCR 2), the Master Boot Record (MBR) Code (PCR 4), the NTFS Boot Sector (PCR 8), the NTFS Boot Block (PCR 9), the Boot Manager (PCR 10), and the BitLocker Access Control (PCR 11).

Important Changing from the default profile affects the security and manageability of your computer. BitLocker's sensitivity to platform modifications (malicious or authorized) is increased or decreased depending upon inclusion or exclusion (respectively) of the PCRs.

Decommissioning Computers

You should include decommissioning as part of your planning. For example, what will you do when a BitLocker-protected computer needs to be reassigned, moved outside the organization, or discarded because of a hardware failure? Because of the algorithm strength of the AES algorithm that BitLocker uses, erasing the recovery password effectively prevents access to a protected volume. You should consider policies and procedures that help you verify that all protectors are removed from Active Directory or other locations when you decommission a computer. (For more information about how to remove protectors for decommissioning, see BitLocker Drive Encryption and Disk Sanitation.)

Plan for Usability

BitLocker is designed to provide strong security while remaining transparent to users during typical operations. However, users must know a number of things to use BitLocker effectively and securely. You should develop a written encryption policy that describes the use, requirements, and operational issues that surround encryption. Users and support staff must be educated about the appropriate use of encryption prior to deployment.

An encryption policy should address issues related to using encryption for confidential data protection, including:

• The types of information that must be encrypted.
• The types of computer assets that must use encryption (for example, desktop computers, laptops, and so on).
• Supported data encryption solutions (for example, EFS and BitLocker).
• What problems encryption solves and does not solve.
• How recovery keys and passwords should, and should not, be stored.
• Who has custody of and access to recovery keys and passwords.
• What users can and should do to ensure the appropriate use of encryption.
• What responsibilities users have for maintaining recovery passwords for their computers.
• Potential problems (for example, data loss) that are related to encryption.
• What steps users must perform to encrypt files.
• Who is responsible for recovering encrypted data, and how users can initiate a recovery.
• How users can get support for encryption problems.

Use your typical educational channels to share encryption information with users, including online and written sources, with hands-on lessons and classes as necessary. This effort can be conducted in parallel with the rest of your deployment process.

Plan for Active Directory and Group Policy Implementation

The output of the previous planning steps describes the extent to which Active Directory will be used to help manage the BitLocker environment. The possibilities include:

• Use Active Directory to store TPM and recovery passwords.
• Manage settings and configurations for BitLocker using Group Policy.

Plan for Storage of Recovery Passwords in Active Directory

As discussed earlier in the "Plan for Data Recovery" section, the use of Active Directory to store recovery passwords requires an extension to the Active Directory schema. Implementing this extension is a significant undertaking and must be planned well in advance of the BitLocker deployment to ensure that the schema extension is successful and that that the environment properly stabilizes.

The planning process for BitLocker Active Directory actions should also include discussion and decisions about who will be designated as key and data recovery operators. A key point to consider is whether the recovery operator function will be separated from the Domain and Enterprise Administrator roles. Some organizations with strict segregation of duties requirements are forced to separate these roles, and other (possibly smaller) organizations will want to allow Domain Administrators to perform data and key recovery simply because these personnel are already trained in the complex technical tasks of managing Active Directory.

Controlling BitLocker Data Encryption with Group Policy

Previous planning steps determined which BitLocker-related Group Policy options will be used. Group Policy options to be planned for include:

• How TPM and recovery passwords are stored in Active Directory.
• What recovery mechanisms are disabled or enabled.
• The default BitLocker settings for cipher length and strength.

Plan for Encrypting File System

The following actions must be performed to complete a plan for EFS deployment:

1. Understand EFS deployment options
2. Evaluate EFS readiness
3. Determine the scope of EFS deployment
4. Choose EFS configuration
5. Plan for key and data recovery
6. Plan for manageability
7. Plan for usability
8. Plan for Active Directory and Group Policy implementation

Understand EFS Deployment Options

EFS is an effective mitigation against several security threats. Understanding which threats EFS mitigates, and which additional threats can be mitigated by combining EFS with BitLocker, requires you to understand the EFS security model and the deployment options it supports. The Security Analysis document included with this Toolkit describes a range of risks and how EFS mitigates them. You should thoroughly familiarize yourself with its contents before proceeding with your planning process.

Evaluate EFS Readiness

Before you can create an EFS deployment plan, you must evaluate your organization's readiness to deploy and use EFS.

Note You can greatly simplify your EFS deployment plans if you use the Active Directory credential roaming feature. For more information, see the Understanding credential roaming page on Microsoft TechNet.

Hardware and Software Requirements

EFS does not require any special hardware other than a computer capable of running a version of the Windows operating system that supports EFS. Specific information about using EFS on any operating system besides Windows XP Professional or the Business, Enterprise, or Ultimate versions of Windows Vista is beyond the scope of this guide.

Additional Requirements

In addition to the hardware and software requirements listed earlier, EFS requires the following:

• All participating computers must run Windows XP or Windows Vista.
• Files and folders that you want to encrypt must be stored on NTFS-formatted volumes.
• Users who encrypt files must have NTFS Allow-Modify permissions to the file or folder they are encrypting.
• Applications that open and modify EFS-protected files must be verified as compatible with EFS. Typically, any Microsoft Win32® application will be compatible with EFS. Most compatibility problems are with legacy 16-bit applications, although applications that access the file system in special ways (including antivirus packages, backup applications, and defragmenters) deserve special attention.

Determine the Scope of EFS Deployment

EFS deployment planning involves decisions regarding the designation of computers and users who will use EFS as well as what data on each computer should be protected with EFS. Because EFS can be used on most Windows–based computers, an analytical process that starts with determining what data should be protected and then identifies the users who have copies of that data and on which computers can fully define the scope of an EFS deployment.

Consider the following questions to help identify what data you need to protect:

• If this data is damaged or altered, either by malice or by accident, how much effort will be required to recover or recreate it?
• If the data cannot be recovered or recreated, what are the financial implications to the organization?
• If the data is improperly exposed or disclosed, will it cause embarrassment to the organization?
• What would be the cost of public exposure of this data?
• Will the fact of its exposure be as damaging or as embarrassing as the exposure of the content itself?
• If this data is quietly acquired by a hostile outsider, how might it be used to disrupt, embarrass, deceive, defraud, or otherwise discomfit the company?
• How much would each of these scenarios cost the organization?

Examples of data that should be encrypted might include the following:

• Contracts, negotiations, RFPs, RFQs, and quotes, whether generated by customers or for vendors.
• List prices, discount schedules, or other pricing-related information.
• Employee, customer, and prospect contact information.
• Meeting notes and presentations.
• Policy memos and manuals.
• Designs and configurations.
• Competitive research and analysis.
• Legally protected data (for example, personally identifiable information about consumers).

The intent of this list is to stimulate security-aware thinking habits; it is not a comprehensive list.

Files and Folders That Cannot Be Encrypted Using EFS

Many files and folders cannot be encrypted using EFS no matter what the user’s permissions. To protect the user from an inoperable state, Windows specifically prevents the encryption of critical items that should not be encrypted. These files and folders include:

• System-critical boot files within the root folder
• %Windir% and any child objects
• Files that pertain to user profiles (that is, Ntuser.*)
• %APPDATA%
• \Boot (in Windows Vista)
• \$Recycle.Bin
• Any file or folder marked with the System attribute
• Hibernation files

Note Some of these folders will allow some of the files that they contain to be encrypted, just not critical files.

Most of the files and folders that cannot be encrypted by EFS are explicitly denied from encryption to protect the user and the participating computer. For example, the user’s private EFS decryption keys are stored in the user’s profile. If the user could encrypt their user profile, Windows would have no way to obtain the decryption key to decrypt the user profile. Therefore, Windows blocks users from encrypting these files.

Note You can use BitLocker to encrypt critical system files prior to booting.

Windows Vista allows you to encrypt some critical files and folders that were not previously allowed in earlier versions of Windows, including the system page file (pagefile.sys).

Files and Folders That You Should Not Encrypt

There are other types of files and folders that users should not usually encrypt, even if the operating system allows it. Examples include:

• Files that are to be shared (unless EFS sharing is enabled).
• The \Program Files folder and its subfolders.
• Shared databases, including Microsoft Exchange Server databases.
• Files generated on one computer for consumption or processing on another (unless EFS sharing is enabled).

Note Shared database files should not be encrypted, because the file must be encrypted so that it can be accessed by all users as well as the database program. Database files are better protected using field/attribute-specific encryption.

Identify Data and Data Locations

A common EFS scenario involves the protection of text, graphics, spreadsheets, and slide show documents created by products such as the Microsoft Office suite. A survey should be performed to determine whether all users in your organization use the default location for such documents. If so, plan to encrypt this entire folder on each computer to be protected.

In addition, the %TEMP% folder should be encrypted to protect any temporary application files that might be created in this folder.

Other applications that interact with confidential data must be examined to determine where the data they create is stored.

After all confidential data and default application data locations are identified, a written policy should be drafted to inform users how to enable encryption on those folders. A plan to configure and deploy policy automation to enable encryption automatically should also be developed.

Common Encrypted Directory Structures

Finding out where users currently keep sensitive data files will likely provide some surprises. The main point of this effort is not to specify, for example, that users must keep documents in My Documents\Sensitive, but to ensure that they do not store them in directories that should not or cannot be encrypted, such as C:\ or C:\WINDOWS.

Creating a common directory structure for all protected laptops will simplify maintenance. The simplest approach, of course, is to set a policy to keep all documents under My Documents, and encrypt the entire My Documents tree. Although this approach might suffice for many organizations, some will find it too restrictive and define more complex and flexible policies.

Some applications create temporary or cache files that might contain sensitive data. You might be able to use EFS and the EFS Assistant tool that accompanies this guide to protect the directories containing these files. However, you will need to test your applications to ensure that they work properly when their temporary or cache directories are encrypted.

Choose EFS Configuration Options

When the scope of the EFS deployment is determined, the next step in the EFS planning process is to choose which EFS options and configurations for the organization's computers. The options that must be considered and planned for include:

• Choosing whether to use self-signed or CA-issued certificates.
• Choosing whether to use smart cards for EFS certificate and key storage.
• Choosing encryption cipher and key sizes.
• The ability to prevent EFS from using self-signed certificates when no certification authority (CA) is present.

Note This feature is included in Windows Vista. To use it in Windows XP, see Microsoft Knowledge Base article 912761, "Encrypting File System (EFS) generates a self-signed certificate when you try to encrypt an EFS file on a Windows XP-based computer."

Windows Vista–based computers offer several additional options, including the following capabilities:

• Encrypt the contents of the user's Documents folder
• Require the use of a smart card for EFS
• Use the smart card directly for all cryptographic operations
• Enable pagefile encryption
• Display key backup notifications when a user key is created or changed

Because some of the configuration options are only possible on Windows Vista, you might need to plan an upgrade of the operating system on certain computers based on the security requirements for part of the organization.

Choosing a Digital Certificate Strategy

EFS digital certificates can be self-signed or issued from a trusted CA. The first time a user attempts to encrypt a file or folder using EFS, Windows checks to see if they have an existing certificate and key that can be used. If not, Windows attempts to contact an issuing CA to obtain a certificate and key. Failing that, Windows generates a self-signed certificate for the user. A self-signed certificate is one in which the digital certificate does not have a higher-level trusted signing authority attesting to its authenticity. Generally, self-signed digital certificates should not be relied upon externally by third parties. However, self-signed digital certificates are often appropriate for internal applications such as EFS.

In general, self-signed EFS digital certificates are easier to implement initially and harder to manage operationally. CA-generated certificates should be chosen if the appropriate PKI services are already implemented.

Note Enterprises without a PKI platform should strongly consider implementing Certificate Services before enabling and using EFS. Certificate Services is available in Microsoft Windows 2000 Server and later server products. The benefits for EFS digital certificate life cycle management and automating a recovery solution will result in decreased overall effort and expense.

Group Policy or Local Computer Policy can be used to allow or disable the ability of a computer to generate a self-signed EFS certificate when a participating CA is not present. This option is discussed in the following section.

Administrators should study the benefits and disadvantages of each digital certificate method and make a purposeful decision to use one solution or the other. It can be cumbersome to change the EFS digital certificate trust chain method after initially implementing EFS.

Benefits and Disadvantages of EFS Self-Signed Certificates

Self-signed certificates are the easiest way to establish a functional EFS infrastructure. Self-signed certificates are automatically issued to EFS clients if no participating and compatible PKI CA is detected. Generation and installation of self-signed digital certificates are fast and transparent to the participating user. By default, self-signed certificates have a validity period of 100 years.

However, self-signed digital certificates have some significant disadvantages, including the following:

• The long validity period of self-signed digital certificates might make their compromise more likely during their validity period.
• More effort is involved to revoke self-signed digital certificates, because you must revoke certificates on each individual computer instead of at a central CA.
• Sharing encrypted files is more difficult. Because self-signed certificates are not published in Active Directory, they are not accessible to other computers unless they are manually moved.
• More effort is required to automate key archival because there is no centralized location from which to archive keys.

Benefits and Disadvantages of EFS Certificates from a Certification Authority

Issuing EFS certificates from a centralized CA has some compelling benefits. This method offers centralized management of digital certificates, and it decreases the security risk because generated digital certificates have shorter useful life period. Renewal, revocation, rekeying, and archival are all easier to automate because the key and certificate material remain accessible through the CA. You can also adjust various certificate parameters by modifying the certificate template. In addition, you can publish the certificates to Active Directory to make it easier for users to locate each other's certificates for sharing EFS-encrypted files.

However, CA-issued EFS certificates have their own disadvantages. First, you must implement a participating EFS-compatible CA before deploying EFS. Second, the shorter validity period of CA-issued certificates might require more frequent rekeying of the certificates. Most significantly, Windows–based computers issue their own self-signed EFS certificates if they cannot contact a participating CA. This capability could lead to a mixed environment of CA-signed and self-signed certificates, complicating EFS digital certificate management. You can work around this potential problem by configuring Group Policy to disable the use of self-signed certificates for EFS or by disabling EFS entirely until you implement the necessary CA services.

If you plan to use auto-enrollment to issue client certificates for use with EFS, carefully review the "Plan for Active Directory and Group Policy" section later in this chapter to ensure that your Active Directory infrastructure will support auto-enrollment (which requires at least one Windows Server 2003 domain controller in your forest).

EFS and Smart Cards

Windows XP and Windows Vista both support the use of smart cards with EFS. As described in the Security Analysis, when you use smart cards with EFS you help mitigate the risk that an attacker will obtain a user's password and use it to log on to a computer and recover EFS-protected files—one of the primary risk factors for EFS. Requiring the use of smart cards with EFS helps effectively add protection, but the ways to require EFS smart card use differ between Windows XP and Windows Vista.

In Windows XP, the smart card can be required for logon. Optionally, it can be required to unlock an inactive or locked desktop. In such a scenario, the additional protection for EFS keys comes from the required presence of the smart card, which is the only way to unlock the EFS keys and use them on files.

In Windows Vista, the smart card can be required for logon and unlocking. However, it is also possible to require the card to be present each time an EFS-protected file is encrypted or decrypted. By default, Windows Vista derives a cryptographic key and caches it for use in EFS operations. For added security, Windows Vista can instead use the smart card directly for every cryptographic operation. However, this approach is less convenient for users and is much slower than cached key mode, so it may not be desirable in some environments.

Note For more detail about the EFS modes supported in Windows Vista and Windows XP, see "Chapter 3: Encrypting File System" in the Security Analysis.

Benefits of Smart Cards

Smart cards are designed to offer strong cryptographic security in a portable, physically secure package. They add security because they offload signature, verification, encryption, and decryption from the host computer to the smart card itself. Cryptographic keys are securely stored on the smart card and are generally considered safe from all but the most sophisticated and well-funded attackers. The certificates associated with a smart card can be used for a variety of security enhancements, including S/MIME protection for e-mail, certificate-based authentication for Web applications and remote access, and more secure desktop logon. Requiring the use of smart cards essentially forces the use of two-factor authentication, because any user who wants to authenticate must have the card and the associated pass phrase or PIN. In addition, there is no need to set up credential roaming systems, because each user's credentials are stored on the card.

Disadvantages of Smart Cards

Smart cards have several notable drawbacks. First, they require deployment of the cards themselves along with readers, which can be prohibitively expensive for some organizations. The cards' certificate issuance and control mechanism must be integrated with a PKI, which can increase the cost and complexity of smart card deployments. Organizations that require smart cards must also implement procedures to issue and track the cards, a security-related activity that must be carefully managed to avoid introducing vulnerabilities. Microsoft Identity Lifecycle Manager 2007 (ILM 2007) can be deployed to help smooth the smart card deployment process.

Choosing an Encryption Cipher

EFS can be implemented with a variety of ciphers and key strengths. It is important to understand that the cipher type and key strength can be chosen on two different EFS objects: the user’s personal EFS asymmetric key and a file’s shared symmetric file encryption key (FEK). Every EFS-protected file has a single symmetric FEK. The file data in each EFS-protected file is encrypted with the file’s FEK.

Each authorized user (or recovery agent) is assigned a copy of the file’s FEK, which is encrypted with the public key in the user's EFS certificate (and can then only be decrypted by the user’s corresponding private key). When the user needs to access an EFS-protected file, the user’s personal private asymmetric EFS encryption key is used to decrypt the user’s encrypted copy of the file’s FEK. The now unencrypted symmetric FEK is used to decrypt the EFS-protected file. It is important to understand the difference between the two EFS key types when deciding on cipher type and key strength.

Supported Ciphers

Encryption algorithm ciphers for the FEK include, in order of weakest to most secure:

• Data Encryption Standard (DES)
• Data Encryption Standard Expanded (DESX)
• Triple Data Encryption Standard (3DES)
• Advanced Encryption Standard (AES)

Windows Vista, Windows XP Professional (SP1 and later), and Windows Server 2003 use the strong AES cipher by default. Earlier versions of Windows XP Professional use DESX by default, but can be switched to the stronger 3DES cipher. To do so, the Use FIPS compliant algorithms for encryption, hashing, and signing security policy option should be enabled in Group Policy, Local Computer Policy, or by editing the registry directly. Windows 2000 uses DES or DESX ciphers for EFS. DESX is automatically used for any version of Windows 2000 SP1 or later.

If the FIPS option is enabled on Windows XP Professional SP1 (or later versions) or in Windows Server 2003, it actually changes the cryptographic protection from AES to 3DES. However, if the FIPS option is enabled, Internet Information Service (IIS) servers and Microsoft Internet Explorer® clients are required to use Transport Layer Security (TLS) instead of the weaker Secure Sockets Layer (SSL) for secure Web transactions. Requiring stronger TLS can also be done at the server level, without enabling FIPS security and decreasing symmetric key security on legacy Windows XP–based clients.

The default asymmetric cipher algorithm used to encrypt FEKs is RSA for both self-signed keys and keys issued by a Microsoft-based certification authority.

Note The default algorithm used is always the most secure cipher available at the time. Each version of Windows is capable of handling all ciphers supported by previous versions. Microsoft recommends that you do not change the cipher settings for EFS except as required by regulatory or compliance needs.

EFS Key Sizes

Windows XP and Windows Vista allow flexibility in both the user’s asymmetric and the file’s FEK cipher key sizes, although there is less flexibility in the FEK key size. Choosing the FEK’s cipher algorithm determines the FEK’s symmetric key strength. Using larger key sizes might result in stronger EFS protection, but might also result in a greater performance penalty, depending on the algorithm in use.

User Asymmetric Key Sizes

In general, EFS asymmetric key sizes can range from 1,024 to 16,384 bits. Typical key sizes are: 1,024, 2,048, 4,096, 8,192, and 16,384 bits. In Windows Vista, the default key size is 2,048 bits, which is secure enough for almost all EFS applications. Microsoft strongly recommends keeping this default key size for new EFS deployments. Prior versions of Windows used a default key size of 1,024 bits.

Symmetric FEK Sizes

EFS symmetric FEK ciphers generally range from 56-bit in earlier versions of Windows to 256-bit AES in Windows Vista. Windows 2000 uses 128-bit DESX keys when the High Encryption Pack or SP1 or later is installed; otherwise, a 56-bit key is used. Windows XP SP 1 (or later) and Windows Server 2003 use 256-bit AES by default. Prior to SP1, Windows XP used DESX but could be set to use 168-bit 3DES.

Generally, most users are well served by allowing the default EFS FEK ciphers to be used. However, some organizations require earlier encryption ciphers or custom key sizes to be used instead.

EFS and Windows Vista

Windows Vista offers some significant enhancements in EFS. You should consider where and how to deploy Windows Vista to make appropriate use of these improvements, which include:

• The ability to require the use of a smart card for EFS. This functionality provides significant security and manageability benefits, because EFS can be managed with the existing process used for managing smart cards.
• The ability to use the smart card directly for all cryptographic operations (known as uncached mode) or to allow Windows to store a derived cryptographic key (known as cached mode). These modes, which are fully described in "Chapter 3: Encrypting File System" in the Security Analysis, allow you to balance security, performance, and user convenience.
• The ability to encrypt the system pagefile. This functionality helps protect against accidental disclosure of sensitive information by preventing an attacker from inspecting the page file while Windows is not running.
• The ability to remind users to back up their keys when they update existing keys or create new ones.
• The ability to prevent users from creating their own self-signed certificates for use with EFS when no CA is available. This functionality allows you to restrict the use of EFS outside your public key infrastructure.

If these features are important to your organization, you should consider how to coordinate your EFS deployment and your Windows Vista deployment. The Windows Deployment Wizard allows you to enable BitLocker as part of a Lite Touch deployment. The EFS equivalent is to enable auto-enrollment for user certificates, then install the EFS Assistant (either as part of the Windows Vista image or through other means) so that sensitive files can automatically be protected.

EFS and File Sharing

Starting with Windows XP Professional, EFS-protected files and folders can be shared with additional users. The first user (or an EFS data recovery agent) to encrypt a file or folder must add the additional users to the file or folder. The additional users must already have valid EFS digital certificates.

Other users who have Write, Delete, or Modify permissions may be able to modify or delete EFS-protected files and folders even if they do not have the ability to encrypt or decrypt those same files or folders. EFS protects confidentiality (that is, unauthorized users cannot read, view, or print protected files), but they might still be able to otherwise manipulate the file without viewing or reading its contents. If the ability to share files between multiple users is important, you should ensure that your organizational policies are clear about who is responsible for encrypting files, who is allowed to read them, and who has the authority to add or remove shared users for encrypted files.

Plan for Key and Data Recovery

Organizations that choose to deploy EFS will need to carefully plan for how to recover data in certain situations, such as when a user leaves the organization, is locked out of their workstation, or the EFS certificate and keys are corrupted. The most important planning tasks for EFS data recovery are documented in the "Data Protection and Recovery in Windows XP/Data Recovery Overview" section of the Windows XP documentation. This section provides additional guidance about issues you should consider during your planning.

EFS is a secure file encryption solution. If the encryption keys used to decrypt the protected files become unavailable, it is possible that the protected files will become unavailable as well. If a backup of the data in unencrypted form does not exist, or if an encryption recovery method is not deployed, the protected files could be permanently unavailable.

As discussed earlier in this guide, EFS uses a combination of symmetric and asymmetric (public/private) key algorithms to protect data. In the default scenario, a symmetric file encryption key (FEK) is generated, which is then encrypted using the public key from a X.509 certificate. There are two different approaches to a backup strategy for EFS-encrypted data:

• Create backups of the private keys associated with the X.509 certificate. This approach is generally referred to as key recovery because it emphasizes protecting the key material as a way to preserve access to protected files.
• Create additional encrypted copies of the FEK copied with different certificates. This approach is referred to as data recovery because it allows you to recover data even if the original key or certificate is lost.

Key Recovery

Key recovery implies that the private key portion of a public-private key pair may be archived and recovered if needed. If the user's copy of the private key is lost or corrupted, whether it is stored on a smart card or on a local computer, then the key can be recovered from the backup location. After a private key is recovered, any data (or more accurately, any encrypted symmetric keys such as an FEK) can be decrypted. In Windows, this capability is provided in two ways: using key recovery agents or manual key archival.

Using a Key Recovery Agent

If Certificate Services or another compatible CA is used, a key recovery agent (KRA) can be used to provide file recovery. The issuing CA can automatically archive EFS digital certificates as it issues them, and the KRA can be used to recover lost EFS keys from this archive. The primary operational difference between an EFS DRA and a KRA is that EFS DRAs have explicit access to all participating EFS-protected files, whereas KRAs can only recover stored copies of other people’s keys. KRAs can also participate in digital certificate key recovery events beyond EFS.

Automatic key archival is done as part of the certificate enrollment process if certificate templates are configured to require key archival. When configured in this way, the private key will be sent to the CA as part of the certificate request and the private key will be archived automatically by the CA.

For more information about planning and implementing a key archival and recovery mechanism, see Key Archival and Management in Windows Server 2003.

Manual Key Archival

If the EFS deployment relies on self-signed certificates, manual key archival is the only way to back up the private key needed to decrypt the FEK. By default, all EFS users can make a backup of their EFS digital certificate and private EFS decryption key. Windows Vista prompts users to back up their keys whenever they are created or changed. All versions of Windows later than Windows 2000 allow users to manually back up their EFS keys, using two or more methods. If allowed by their security policy, users should back up their EFS keys and store them in two or more separate, secure locations using reliable storage media.

With manual key archival, users manually export private keys and send them to a CA administrator who then imports them to the protected CA database.

This approach allows users to take responsibility for their own recovery keys. However, it is difficult to monitor and regulate in large organizations, and there is no reliable way to determine whether a user has or has not archived an EFS key, both of which might be important for policy compliance.

Data Recovery

Data recovery is a somewhat different process that doesn't involve the archival of the keys associated with any particular X.509 certificate. Instead, this process creates redundant paths to accessing an encrypted file by creating additional encrypted FEKs, each encrypted with the public key from a different X.509 certificate. The additional keys created by this process are called data recovery agents.

When any file is encrypted, Windows automatically makes a copy of the file’s FEK and encrypts it with the DRA’s public EFS key. This functionality means a DRA can decrypt any EFS-protected file.

The primary benefit of a DRA is that every EFS-protected file automatically has a copy of the file’s FEK created by default. It does not require a user to manually make backup keys. The biggest disadvantage is that if the DRA’s user account is compromised, the intruder can access EFS-protected files.

Note Increased security methods should be used to protect any DRA user account. Also, the recovery agent’s EFS recovery key can be exported and stored externally to prevent an EFS compromise if the agent's account is compromised. The EFS recovery key can be imported in the future if needed.

By implementing data recovery and data recovery agents, every encrypted file's encryption key is encrypted using the DRA's public key in addition to the user’s public key. By using the associated private key, any designated DRA can decrypt any encrypted file within the scope of the EFS recovery policy.

Defining a Recovery Policy

The recovery policy defines who is permitted to recover data and in what circumstances recoveries can be performed, and it is a key part of your EFS planning. Your policy should define:

• Which users or roles are allowed to recover data for themselves.
• Which users or roles are allowed to recover other users' data.
• What business or regulatory controls apply to data recovery.
• How you will audit the use of data recovery tools to ensure that they aren't misused.
• How recovery password materials will be gathered, stored, and safeguarded.
• Which workstations or resources can be used to perform recovery operations.

Where possible, Microsoft recommends that you choose one of two best practices for your recovery policy. The preferred method of recovery is to issue a DRA certificate on a smart card, then secure the smart card and its PIN separately. A Windows Vista–based computer can use this smart card and the associated certificate to recover data from any client in the domain. This combination provides strong two-factor protection for the DRA credentials, and you can enforce separated access to the smart card and PIN to ensure separation of recovery duties.

In environments in which this is not feasible, Microsoft recommends that you define and configure separate computers that are used only for data recovery. These recovery workstations should be physically secured and have additional auditing and security measures applied, commensurate with the value of the data that might be recovered.

Planning for DRA Expiration

EFS data recovery agents use certificates which, like any other certificates, will eventually expire. However, conventional certificates are typically used to provide forward secrecy: they protect material that should remain encrypted for some period into the future. Preserving forward secrecy requires that the key associated with the certificate expire at some future time so that it can be rekeyed.

DRAs provide the opposite of forward secrecy: they allow past data to be recovered. This functionality means an expired DRA certificate is still useful to recover data that was encrypted during the DRA certificate's validity period. To preserve your ability to recover data no matter how old it is, you should plan to archive DRA certificates to a secure storage medium so that they can be used when necessary.

When a DRA certificate expires, you can reissue or rekey it. After you do so, the DRA can be used to recover newly encrypted data. However, you must maintain a copy of the previous DRA certificate to recover data protected by the previous DRA. When you develop procedures and policies for handling (or preventing) DRA expiration, consider the following:

• If even one active DRA certificate has expired (even if the client has multiple DRA certificates configured), Windows will refuse to encrypt any new files. This functionality means that an organization must ensure that it issues new DRA certificates and replaces the soon-to-expire certificates far enough in advance that Group Policy latency doesn't allow any client to have an expired DRA certificate.
• Replacement of DRA certificates (and the subsequent, though optional, steps required to update client files) is a straightforward but multi-step process.
• Any Group Policy object (GPO) that configures DRAs should contain more than one DRA. This approach provides redundant protection against data loss caused by loss of access to a single DRA private key.

Determine Data Recovery Policy Level

A default recovery policy is automatically put in place for the domain when the administrator logs on to the domain controller for the first time, which makes the administrator the recovery agent for the domain. Windows XP, Windows Vista, and Windows Server 2003 no longer require a recovery policy to be in effect to encrypt files.

The default recovery policy is configured locally for stand-alone computers. For computers that are part of an Active Directory–based domain, the recovery policy is configured at the site, domain, organizational unit (OU), or individual computer level, and applies to all Windows 2000, Windows Server 2003, Windows XP, and Windows Vista–based computers within the defined scope of influence. Recovery certificates can be issued by a CA and managed using the Microsoft Management Console (MMC) Certificates snap-in.

In a network environment, the domain administrator controls how EFS is implemented in the recovery policy for all users and computers in the scope of influence. In a default Active Directory installation, when the first domain controller is set up, the domain administrator is the specified recovery agent for the domain. The way the domain administrator configures the recovery policy determines how EFS is implemented for users on their local computers. To change the recovery policy for the domain, the domain administrator uses the Group Policy editor from any client computer or server connected to the domain. For a stand-alone computer (not joined to a domain), the expiration period of a self-issued administrator account DRA certificate is 100 years. For a domain-joined computer, the default DRA certificate issued to the domain administrator has an expiration period of three years.

Administrators can define one of three types of policies:

• Recovery agent policy. When an administrator adds one or more recovery agents, a recovery agent policy is in effect. These agents are responsible for recovering any encrypted data within their scope of administration. A recovery agent policy is the most common type of recovery policy. Recovery agent policies can be used to distribute the administrative workload in your organization, and you can designate alternative EFS recovery accounts for categories of computers grouped by organizational units. You might also configure Encrypted Data Recovery Agents settings for portable computers so that they use the same recovery agent certificates when they are connected to the domain as when they operate as stand-alone computers.
• Empty recovery policy. When an administrator deletes all recovery agents and their public key certificates, an empty recovery policy is in effect. An empty recovery policy means that no recovery agent exists, and if the client operating system is Windows 2000, EFS is disabled in this configuration. The Windows XP client allows EFS to operate with an empty DRA policy.
• No recovery policy. When an administrator deletes the private keys associated with a given recovery policy, a no recovery policy is in effect. Because no private key is available, there is no way to use a recovery agent and recovery will not be possible. This type of policy would be useful for organizations with a mixed environment of Windows 2000 and Windows XP clients that do not want data recovery.

Although the domain administrator is the default DRA in an Active Directory environment, this capability should be delegated or assigned to one or more users.

Choosing the Right Mechanism

Key recovery and data recovery strategies can be used separately or in tandem. There are many security and operational issues to consider. Additional information can be found in Key Archival and Management in Windows Server 2003. You are strongly encouraged to review this information before deciding which strategy, or combination of strategies, to use.

Plan for Manageability

An important step in the EFS planning process is deciding how EFS affects the organization's IT management processes. EFS affects the following ongoing processes that are found in any organization:

• Integration with imaging, backup, and antimalware software
• Plan for EFS and file sharing
• Decommissioning computers

Integration with Imaging, Backup, and Antimalware Software

Most third-party imaging, backup, and antimalware applications are designed and tested to work with EFS. Understanding the types of such tools used by an organization and then testing them in conjunction with EFS is a necessary planning step to ensure that the IT service agreements are satisfied. The testing criteria should include whether the applications work correctly with encrypted data as well as whether the tools retain the encrypted status or not, depending on the organization's requirements.

Copying and Moving Files

Copying or moving EFS-protected files might result in changes to the file's encryption status. The general rules for how copying or moving files affects encryption are:

• If you copy a file or folder on the same computer from one NTFS partition to another NTFS partition, the file will be encrypted at the destination.
• If you copy a file or folder from an NTFS partition on a computer to another partition type, whether or not the partitions are on the same computer, the copy is not encrypted because the destination file system does not support encryption.
• If you copy a file or folder between NTFS partitions on two computers, the destination file will be encrypted if the remote computer allows user encryption of files; otherwise it is not encrypted. Note that the remote computer must be trusted for delegation. In a domain environment, remote encryption is not enabled by default.

Maintenance utilities that copy files in their entirety without reading the file data should work as expected. For example, the Windows Backup utility (and most other backup programs) read the entire set of all NTFS stream data for files they back up, so the backup can proceed without having access to the user's key material. Files backed up using this method will remain encrypted on the backup media.

Note The backup utility included with Windows Vista cannot back up EFS-encrypted files. If you are not using a third-party backup tool, you can still use the Robocopy tool with the /efsraw switch to automate backup of EFS-protected files on computers that run Windows Vista.

Disk Imaging Tools

Similarly, disk imaging tools that capture the contents of the entire file system will preserve the EFS state of protected files because they read individual blocks from the disk. Imaging a computer that contains EFS-protected data will include the EFS-encrypted data as part of the image. Some imaging tools allow you to open an image and view or modify individual files in the image without restoring the image to a target computer. These tools usually do not work properly with EFS-encrypted files, and you will not be able to open or modify encrypted files captured in an image unless the computer on which you open the files has the correct key material.

Antimalware Tools

Antimalware programs (including antivirus and spyware-fighting software) generally work in two ways:

• They intercept requests to open files and scan them for malware before the user can access the file. Programs that use this mechanism will generally work with EFS because the scanning is performed after the application requests data from a file, and the request is made within the user's security context.
• They use a system account (such as LOCAL SYSTEM or NETWORK SERVICE) to scan files on a computer no matter who owns them. Tools that use this mechanism will generally not be able to inspect EFS-protected files, because when they attempt to open the file an Access Denied error is generated.

Individual antimalware programs might combine these two approaches. Review the documentation for your antimalware solutions and test them to ensure that they work properly with EFS-protected files in your environment.

Plan for EFS and File Sharing

If your organization needs to share sensitive data between multiple users, there are two possibilities for doing so: storage in typical shared folders on file servers or the use of Web folders. Both methods require configuration to support EFS, and you should understand the issues, benefits, and risks, which include the following.

• If encrypted files are stored on a remote file server, you can choose whether you want to allow the server to keep plaintext copies of the files or whether they must remain encrypted on the server. If you want to provide shared access to encrypted files while still protecting their contents on mobile PCs, you can keep plaintext file copies on the server. If you have a requirement that protected files will stay encrypted no matter where they are stored, you will need to configure the server appropriately (which requires that the server be trusted for delegation in Active Directory).
• You can store encrypted files in Web folders when using Windows XP or Windows Server 2003. This approach makes the files available through applications that can use DAV to access Web folders (including Microsoft Office 2000 and later), and it also allows you to make them available to users through Web-based applications.

Plan for Decommissioning

EFS only encrypts selected files, and the key material may be retained on the system volume in some operating modes. When you decommission a computer that contains EFS-protected content, you must follow your normal decommissioning practices to ensure that all sensitive files are removed.

Plan for Usability

EFS is a secure method for encrypting files and folders on NTFS volumes. A written encryption policy should be created and distributed that describes the use, requirements, and operational issues surrounding encryption. Users and support staff must be educated about the appropriate use of encryption prior to deployment.

An encryption policy should describe issues related to confidential data encryption, including:

• The types of information that must be encrypted.
• The types of computer assets that must use encryption (for example, desktop computers, laptops, and so on).
• Supported data encryption solutions (for example, EFS and BitLocker).
• The problems that encryption solves and does not solve.
• What cipher algorithms and minimum key sizes are acceptable for organizational data protection.
• What users can and should do to ensure the appropriate use of encryption.
• Potential problems (for example, data loss) that are related to encryption.
• What steps users must perform to encrypt files.
• How users can confirm file encryption (for example, file highlighted with green font in Windows Explorer, Cipher.exe, and so on).
• Who is responsible for recovering encrypted data, and how users should initiate a recovery.
• How users can get support for encryption problems.

Use typical educational channels to share encryption information with users, including online and written sources, with hands-on lessons and classes as needed. This effort can be conducted in parallel with the rest of your deployment process.

Plan for Active Directory and Group Policy

Active Directory and Group Policy provide the most effective way to manage EFS configuration and policy. The following GPO settings can affect the behavior of EFS.

• In Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

  • Shutdown: Clear Virtual Memory Pagefile. This setting instructs the operating system to clear the contents of the system paging file when the operating system shuts down. This configuration reduces the risk of leaking plaintext data through the paging file.
  • System Cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing. By default, EFS uses the Advanced Encryption Standard (AES) algorithm with a 256-bit key length on Windows XP Service Pack 1 (SP1)–based and Windows Server 2003–based computers. However, if you enable the System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing setting on these computers, the operating system will use 3DES with a 168-bit key length instead. On Windows Vista computers this setting will cause EFS to use AES.

  Note Using the FIPS policy is not the recommended way to manipulate the encryption algorithms used by EFS unless FIPS compliancy is a requirement. The recommended way to change the algorithms used by EFS is by setting the appropriate value in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\EFS.

• In Computer Configuration\Windows Settings\Security Settings\Public Key Policies
  • Encrypting File System. Enables EFS for computers within the scope of the policy.
  • Encrypting File System. Add or remove data recovery agents to modify your organization's recovery policy. The process of managing data recovery agents is described in detail in Chapter 2: Configuration and Deployment Tasks in this guide.

Planning for Migration to Domain Accounts

For reasons discussed in the Security Analysis guide of this Solution Accelerator, EFS offers optimal security only for users with Active Directory domain accounts. It is possible to use Syskey to achieve similar levels of security, but the user impact of advanced levels of Syskey is somewhat negative. For this reason, EFS users should be domain users. Part of the planning for EFS should include a survey of potential users to ensure that they have domain accounts and that they only use those domain accounts when they log on to a computer to access confidential data protected by EFS.

Planning for Active Directory Password Policy

Unless smart cards are used with EFS, EFS file encryption keys are protected by the user's password. Anyone who can obtain a user ID and password can log on as that user and decrypt that user's files. Therefore, a strong password policy in addition to strong user education must be a component of each organization's security practices to ensure the protection of EFS-encrypted files.

Planning Migration from Self-Signed to CA-Issued Certificates

Some users may have begun using EFS in advance of your formal EFS deployment. If a user attempts to encrypt a file on a computer with no EFS certificates, the EFS subsystem will generate a new self-signed certificate. When you deploy EFS to your organization's computers, you should plan to replace these self-signed certificates with certificates issued by your certification authority. This replacement process standardizes the lifetime and key strength of certificates used for EFS on computers with self-signed certificates and other computers on which EFS is deployed.

More Information

• Windows Vista Enterprise Hardware Planning Guidance
• USB Mass Storage Class Bulk-Only Transport specification on the Universal Serial Bus Web site
• The Trusted Platform Module (TPM) Specifications page on the Trusted Computing Group Web site
• Solution Accelerator for Business Desktop Deployment
• The Business Desktop Deployment Lite Touch Installation Guide
• BitLocker Drive Encryption Technical Overview
• BitLocker Drive Encryption and Disk Sanitation
• Understanding Credential Roaming
• Encrypting File System (EFS) generates a self-signed certificate when you try to encrypt an EFS file on a Windows XP-based computer
• Microsoft Identity Lifecycle Manager 2007 (ILM 2007)
• The "Data Protection and Recovery in Windows XP/Data Recovery Overview" section of the Windows XP documentation
• Windows BitLocker Drive Encryption Step-by-Step Guide
• Key Archival and Management in Windows Server 2003
• Description of the BitLocker Drive Preparation Tool
• Extending Your Active Directory Schema in Windows Server 2003 R2