Chapter 1: Risk Discussion

Published: April 04, 2007

Sensitive data, like all data, has a complex life cycle and typically moves from place to place as it performs its business function. Securing data is necessary throughout the entire cycle of its use, but many technologies and processes will be applied in different phases of the data life cycle.

This guide focuses on the level of security that can be achieved by using Microsoft technologies to protect data when it is copied to or created on mobile PCs, such as laptop computers.

Discussions of data protection for the following scenarios are out of scope for this guide, except when the data is cached locally:

• As data transits internal or external networks.
• As data is presented in Web (thin-client) applications.
• When data is used within applications after it is decrypted.

Data Security Risks

The two technologies described in this guide, Encrypting File System (EFS) and Microsoft® BitLocker™ Drive Encryption (BitLocker), are examples of two different but complementary approaches to data encryption. EFS is an encryption mechanism that protects data in files and folders on a per-user basis. BitLocker is a full-volume encryption mechanism that encrypts all sectors on the system volume on a per-computer basis, including operating system, applications, and data files. BitLocker provides pre-boot integrity checking and encryption, but it does not provide user authentication. EFS complements BitLocker protection by restricting access to encrypted files to properly authenticated users on a running computer.

Because of their fundamentally different approaches and implementation, EFS and BitLocker have their own strengths and weaknesses and deliver different levels of security across a common set of attacker scenarios. This guide describes those scenarios in detail and examines how the two encryption technologies apply to each.

Understanding Data Types

There are different types of confidential data and many different scenarios for how and why that data might be compromised. This guide discusses the different encryption technologies in the context of the following types of data.

• Personally identifiable information (PII). Private information about customers or employees of an organization, including Social Security numbers, credit card numbers, health information, and so on. Data of this type is protected by one or more government or industry regulations, such as the Health Insurance Portability and Accountability Act (HIPAA), the European Union Data Protection Directive, and California Bill SB1386. Loss of this type of data generally results in immediate and long-term financial impact to an organization, even though it might never be proved that the data was read from a computer.
• Intellectual property (IP). Data considered by an organization to be confidential or sensitive, including marketing plans, pre-patent research on new products, software algorithms, lists of potential new customers, and so on. If this type of data is lost and discovered by the wrong people, or if it is present on a device that is deliberately stolen, a loss of competitive advantage or other negative effects could result. The main thing to remember is that there are typically financial implications for the use of IP data, so the cost of risk mitigation can be balanced against the financial implications of exposure. However, this type of calculation may not always be helpful. Public embarrassment can also be a motivating factor, so it might be a good idea to encrypt the data on your CEO's computer to avoid negative publicity.

Attacker Scenarios: Insider and Outsider

When discussing attacks and mitigating technologies, a distinction is often made between whether the threat is from a malicious insider or an outside attacker. Malicious insiders have capabilities that outsiders typically do not have. A partial list of the differences includes:

• The insider may be able to legitimately log on to the computer using their own account.
• The insider may be able to access the computer over a network for an extended period of time while the computer is being used by legitimate users. Such an opportunity could increase the likelihood of finding a weakness to exploit.
• The insider is more likely to be able to mount multi-stage attacks.
• The insider may be more likely to succeed in obtaining a user’s password (or part of it) through social engineering attacks.

To compare the strengths and weaknesses of different approaches to data encryption, it is necessary to discuss some cryptographic concepts that apply to encryption in general and to EFS and BitLocker specifically.

Cryptographic Concepts for Data Protection

Encryption can be implemented in many ways. For example, encryption can be performed in layers, or in complicated patterns built into unique algorithms. Cryptographic key use is often discussed in terms of key length, but how those keys are calculated, stored, and used is often much more important. Cryptographic key storage and protection is rarely discussed in detail in technical product documentation, but these issues are extremely important to understanding what is usually the weakest part of an encryption technology.

Note This section of the guide is not meant to be a general primer on encryption technologies. If you do not have a basic understanding of encryption fundamentals such as symmetric and asymmetric encryption, you should review the article "Cryptography for Network and Information Security."

An optimal encryption algorithm is designed and implemented so that an attacker’s only way to break the encryption is to correctly guess what particular key was used from a large possible key space, which is the range of values that a key might possibly have. This type of an attack is called a brute-force attack.

Symmetric key algorithms typically have a key space of between 40 and 512 bits, which means that the number of possible values for the key is the maximum numerical value that can be expressed by the number of bits used. 40 bits allows a maximum numerical value of 1,099,511,627,775 (2⁴⁰ -1), which is certainly a large number, although currently available computers could fairly easily try every possible value of a 40-bit key space as an encryption key in an attempt to decrypt data. However, every bit added to the key space doubles the number of possible keys—so a 41-bit key space would offer 2,199,023,255,552 possible keys. Increasing the key space quickly causes the number of possible keys to increase to a point at which brute-force attacks become infeasible using current hardware and known attack techniques.

Encryption technologies, however, rarely provide security that is this strong. Many encryption implementations have one or more of the following weaknesses:

• The encryption algorithm is flawed. Encryption algorithms are sometimes found to be fundamentally flawed after peer review—or sometimes after they are successfully attacked. Sometimes such flaws are found many years after the algorithm is published and becomes widely used.
• The implementation is incorrect. Algorithms are implemented by developers, and sometimes they introduce bugs that reduce the effectiveness of the algorithm.
• The keys have a low level of entropy. Just because a key space is 128 bits, for example, does not mean that the process to generate the 128-bit number is truly random or uses the entire key space.
• The keys are easily discovered. Keys have to be stored somewhere. If the location is discoverable and the key can be retrieved, the encrypted data can be compromised.

If encryption technologies are subject to such weaknesses, you might wonder why anyone bothers with encryption at all. In practice, there are two factors that help reduce the occurrence of these weaknesses. One factor is that Microsoft invests heavily in validating and verifying the soundness of its encryption implementations. This process begins with choosing mature, well-understood algorithms that provide innate resistance to some types of attacks, and it continues through the ongoing Microsoft commitment to having its cryptographic algorithm implementations certified as meeting the Federal Information Processing Standards (FIPS) 140 Evaluation standards and to submitting its operating systems for Common Criteria certification. For more information about Common Criteria certification, see the Windows Platform Common Criteria Certification page on Microsoft TechNet. In addition, The Trustworthy Computing Security Development Lifecycle (SDL) process has been integrated into Microsoft development processes to ensure that security is incorporated as a core component of product development.

The second factor is that encryption can be made sufficiently resistant to attack to provide a degree of security that is appropriate for the data that is being protected. In other words, it often does not matter if a large government could apply all of its resources and succeed in cracking the encryption that protects your customer database. You might only need an encryption solution that would prevent the data from being easily discoverable if it somehow became available to unauthorized people with very limited resources or knowledge. Another way to assess your encryption needs is to ensure that any data you decide to encrypt is evaluated for its true worth and then compared with the estimated cost to break the encryption. For example, if your customer database is worth $100,000 to a competitor and the estimated cost to break the encryption is $1 million, the level of encryption used is probably sufficient.

Note For more information about ways to assure that a cryptographic implementation is secure, refer to chapter 19 in Special Publication 800-12 – An Introduction to Computer Security: The NIST Handbook, published by the US National Institute of Standards and Technology (NIST).

To evaluate the relative merits of encryption approaches, you need to examine the details of the encryption implementation in its entirety. The following figure shows a typical chain of events that occurs when data is encrypted and decrypted.

The following factors are important to understand when evaluating an encryption technology:

• Algorithm choice. The security of a cryptographic implementation depends both on the quality of the implementation and the algorithms it implements. For this reason, most commercial technologies implement a relatively small set of mature, well-tested algorithms that are believed to be secure against various types of attacks. Examples of these algorithms include 3DES (Triple Data Encryption Standard), AES (Advanced Encryption Standard), and Blowfish, all of which are symmetric algorithms, and RSA (Rivest-Shamir-Adelman) and ECC (Elliptic Curve Cryptography), which are public-key algorithms.
• Key generation. Encryption technologies often use multiple keys. Some of these keys will be generated by hardware or software, some are provided by humans, and some are derived from generated keys, human-provided keys, or a combination of both. The strength of generated keys relies on whether it is possible to predict the value of the key if environmental factors are known. In other words, a key must be sufficiently random and of sufficient length to be effective.
• Key derivation. Many encryption implementations derive some of their keys from other keys, such as a user-provided password. How each one of the keys is derived is critically important to the overall security of the implementation. The important thing to remember is that keys cannot be made stronger through derivation. It is possible to create a 256-bit AES key from a 56-bit DES (Data Encryption Standard) key, but the resultant strength of the key is no greater than the strength of the 56 bit DES key—which might be derived from an even weaker key.
• Key storage. Every encryption technology must store and use key material. How that key material is stored is critically important to the security of the implementation. Valuable assets such as root certificate authority signing keys are often protected using tamper-resistant hardware modules that provide strong resistance against attack. Many organizations choose to deploy smart cards because they provide stronger security for key storage than software–based solutions, with the added benefit that the user cannot, even inadvertently, recover and disclose the smart card's key material. Practical issues of user behavior must also be considered, such as whether users properly safeguard key material and passwords. Encryption technologies that make it easier for the user to do the right thing are much more secure, and more successful, then those that do not.
• Key caching. Cryptographic operations are often computationally complex. To improve performance, encryption technologies often rely on optimizations that involve caching keys or intermediate products of cryptographic operations. Such data items are extremely sensitive, and if the technology does not properly protect them they may become exposed to an attacker. For instance, a technology that caches a cryptographic key in memory may allow an attacker to recover this key from system memory or the page file if the cache is not correctly implemented and protected.
• Weakest link. The overall security of an encryption implementation should be based on the security of the weakest link. Understanding the weakest link in any encryption technology is therefore the most important aspect of evaluating an encryption implementation. In many environments users are the weakest link, and it is critical to complement the technical measures that protect data on mobile PCs with appropriate user education and training.
• Usability vs. security. In fact, no encryption solution is perfect. All such solutions can be attacked via brute force—the issue is how long it takes to successfully mount such an attack. Effective implementations tend to be more or less equivalent to the strength of the underlying encryption technology. However, cryptographic strength is often not the most important factor. Other factors, such as user interaction, are very important. Security measures can almost always be increased until it will be difficult for users to access their data, but the degree of difficulty should be carefully analyzed to determine whether it is worth the cost to the organization. You do not want to implement a solution that is so complex to use that your users decide to use pencil and paper instead!

Attack Difficulty

Not all attacks against an encryption solution are equal. As stated earlier, a smart attacker will often attack the weakest link. To estimate the security level of an encryption solution, you can list the possible attacks against the encryption technologies that it implements and then rate the attacks by difficulty.

A low-difficulty attack is one in which no resources are required to read the data of interest. In other words, this type of attack would describe a situation in which an attacker only has to raise the lid of the laptop computer and start reading. The difficulty of an attack is frequently linked to context and other factors of a particular solution.

Understanding Data Risks

The goal of an encryption solution is to encrypt all important data so that no attacker—casual or determined, novice or expert—can access the data as plaintext. However, encryption solutions can be subverted through massive application of resources, by finding an unknown flaw in a specific encryption technology, or simply by user error. Encryption technologies have unique risk characteristics that are based on their design and implementation decisions and on how they are used. Some potential risks are listed in the following subsections and referenced in the scenario descriptions later in this guide. Remember, not every listed risk will apply to every organization. You should consider mitigating those risks that apply to your organization after you determine which of them are significant and warrant appropriate action.

Computer Left in Hibernation

Most laptop computers have a feature called hibernation that allows users to shut down the computers so that they do not use any power but then restart in exactly the same state they were in prior to hibernation. However, leaving the computer in unsecured hibernation mode means that an attacker could have unlimited access to all information on the computer. As with sleep mode, computers can be configured to prompt for user credentials when they resume from hibernation mode. Details about how to enable this setting can be found in To password-protect your computer during standby or hibernation, which is part of the online Windows XP Professional Product documentation.

Important Microsoft strongly recommends that you require the use of credentials to unlock a computer from hibernation mode.

Computer Left in Sleep (Standby) Mode

It is possible that a laptop computer will be configured so that it does not prompt the user for a password or a smart card when it resumes from sleep mode, which means that the computer is effectively left turned on and available for use by anyone. Those users who configure their computers to use sleep mode are at the greatest risk if the computer does not require logon when it resumes from sleep mode. Details about how to enable this setting can be found in To password-protect your computer during standby or hibernation, which is part of the the online Windows XP Professional Product documentation.

Important Microsoft strongly recommends that you require the use of credentials to unlock a computer from sleep mode.

Computer Left Logged On and Desktop Unlocked

Very few encryption technologies will help if a computer is left in a public place while an authorized user is logged on. Some attacks might even succeed against a computer with a locked desktop. An attacker can simply pick up the computer, take it to a private place, and start reading or copying data from it. A few encryption technologies have options that require an external key every time a file is accessed, but the impact on usability is so dramatic that few organizations choose such a restrictive solution. A more common mitigation is the use of an external key or token, such as a smart card, with caching that allows the computer to retain an encrypted copy of the key to provide better usability.

Discover Local/Domain Password

An attacker who obtains a user's credentials might be able to gain access to encrypted data in one of two ways, depending on the encryption implementation: the credentials might be used to decrypt the material directly, or the credentials might be used to gain access to the key material through attacks on credentials that are cached or stored by the operating system.

In any security system, the weakest link of the encryption technology is usually the user’s password because user-selected passwords are typically much weaker than even the weakest keys used by common encryption algorithms. The author of Avoiding bogus encryption products: Snake Oil FAQ asserts that even a 20-character English phrase has only 40 bits of randomness instead of the 20x8=160 bits of randomness you might expect. An 8-character password would have much less than 40 bits of randomness, according to this author's opinion. However, even this scenario is not as much of a concern as someone who writes their password on a piece of paper and tapes it to their laptop—which effectively subverts any encryption solution that is based on a user password!

Note Attacks that discover the user's password through social engineering or other non-technical attack methods are outside the scope of this guide. Password discovery attacks are primarily considered to involve brute-force cryptographic attacks or other technical attacks against credential stores.

Insider Can Read Encrypted Data

This risk is different than previously discussed risks because the attacker is assumed to be a malicious insider instead of an outsider. This risk calls attention to the fact that some encryption technologies, especially per-computer encryption as described in the following section, allow access to encrypted data by any user who can successfully log on to the computer. The user account could be local to the computer or a network user account (for example, an account in the Active Directory® directory service), and the logon could be local or over the network.

Key Discovery through Offline Attack

In this type of attack, the attacker mounts a disk with encrypted data into a different or modified operating system. With detailed knowledge of the implementation, the attacker can attempt to isolate the keys used to encrypt data and attempt a brute-force attack on the storage mechanism used for the keys. The rule of least effort applies in this type of attack, and the attacker will attempt to isolate and attack the weakest link in the storage mechanism. Brute-force attacks on even moderately strong keys are very difficult and require extraordinary amounts of computational resources. If the encryption solution is implemented well enough so that a brute-force attack is the only option for the attacker, the data security goals of the organization have probably been met.

Offline Attacks Against the Operating System

This type of attack attempts to modify or change system files or settings when the operating system is not running to make it easier to access encrypted data. Such attacks are technically difficult and require a deep understanding of the operating system. In the context of a full-volume encryption technology, one possible attack is that an attacker can change some encrypted data on disk in the hope that it changes a single registry value or hard-coded value in an operating system executable that makes the computer less secure.

Online Attacks Against the Operating System

This type of attack attempts to subvert protections in the operating system while it is running. Examples include escalation of privilege attacks or attempts to execute code remotely. If an attacker can successfully complete this type of attack, they can recover encrypted data by running code of their choice on the computer.

Plaintext Data Found on Computer

The existence of plaintext confidential data is a basic risk that any encryption solution must mitigate. Almost all encryption solutions mitigate this risk unless the encryption algorithm they use can be broken with little or no effort. Both of the Microsoft encryption technologies discussed in this guide use industry-accepted encryption algorithms, so this risk is assumed to be mitigated in general for each analyzed option. However, in some situations, the encryption technology might not get applied to a specific file that contains confidential data. Many of the risk discussions in the rest of this guide describe such situations.

Plaintext Data Leaks through Hibernation File

Hibernation is similar to the concept of system paging, except that the computer takes a snapshot of all physical memory and writes this data to disk in a hibernation file. If any sensitive data is in physical memory at the time the snapshot is taken, it will be written to disk as part of the hibernation file. Like attacks on the paging file, attacks against the hibernation file are typically performed offline.

Plaintext Data Leaks through System Paging File

Modern operating systems provide large amounts of virtual memory to applications by swapping data in memory that is not being used to a paging file stored on the hard disk drive. This functionality creates a risk, however, because an application running on the computer may load encrypted data from disk, decrypt it in memory for use, and then write it as unencrypted data to the hard disk drive in the form of a paging file. Some operating systems delete the page file during shutdown operations, but there are known ways to prevent the deletion of the page file (including causing the operating system to crash). Also, it might be trivial to undelete the pagefile and explore its contents. Attacks against the paging file almost always include removing the hard disk drive from the target computer and mounting it on another computer or else booting another operating system on the target computer. These attacks are known as offline attacks.

Note Sensitive material such as cryptographic keys may leak through other operating system or application cache mechanisms, including temporary files written to disk. The measures described in the Data Encryption Toolkit for Mobile PCs focus on mitigating the risk of data leakage through the system paging file but might also mitigate leaks from other application-specific caching mechanisms.

Platform Attacks

Some attacks target hardware or software features of a particular platform. For example, some attacks use the direct memory access (DMA) feature offered by the IEEE 1394 (FireWire) interface to attempt to read or write to system memory without notice of the operating system. Other attacks include the possibility of DMA–based memory access performed by an active PCI device and attacks that exploit features or vulnerabilities in PCI and RAM bus bridge chips. The costs of implementing these attacks have historically been quite significant, but they are decreasing as the required techniques and equipment become more widely available.

Required Authentication Factor Left with Computer

This risk applies to encryption technologies that can use an external device, such as a smart card or a USB device, to store encryption keys. Users who are unaware of the security risk of doing so may become careless and leave the device attached to their computer or stored in the same piece of luggage. Because this is a common scenario, most organizations will not rely on a single physical factor for their encryption solution. (This risk also applies to users who note PINs or pass phrases on paper, but such behavior should primarily be addressed through user education and is not addressed in this guidance.)

User Error

Users do not always understand everything about the technology they use or pay as much attention to policies as IT administrators would prefer. This risk includes users who don't do what they should because they don't know how to turn on encryption, because they forget to encrypt a particular file, or because they do not pay attention to data security policies.

Data Protection Approaches

The design and implementation of data protection technology involves choices that affect security, usability, and operational management of the technology when it is deployed. Although it is not comprehensive, a discussion of the technologies in the following list will help you understand the material presented in this guide. These data protection technologies include:

• Software–based encryption
• Hardware–based encryption
• Pre-boot (pre-operating system) encryption
• Post-boot (operating system) encryption
• Application-level encryption
• File/folder level encryption
• Full-volume encryption
• Per-user encryption
• Per-computer encryption

Software–based Encryption

Software–based encryption is the standard for most data protection technologies and products. The alternative, hardware–based encryption, requires specialized cryptographic hardware that historically has not been commonly available on personal computers. With software–based encryption, cryptographic operations are performed in the computer's CPU. When the computer is turned off, hibernating, or sleeping, encryption keys are typically stored in encrypted form on disk. A typical option is to store an initial key separate from the computer, for example on a USB device, which is used to decrypt the stored key material. When the computer is operating, encryption keys are usually stored in memory.

The strengths of software–based encryption include:

• The ability to update and revise the implementation. Software–based encryption technologies can be updated at any time to fix implementation flaws, add new capabilities, or take advantage of new algorithms.
• No special hardware requirements. Because they require no special hardware, technologies that rely on software–based encryption can typically be applied to all computers in the organization.

The weaknesses and issues of software–based encryption include:

• Software weaknesses. In implementations that rely only on software, the software might be attacked in an attempt to subvert its intended secure mode of operation. A typical attack would be to change the operating system binary files in a way that prevents encryption, manipulates the keys in some way, or significantly weakens the encryption operation.
• Key discovery. If any encryption key is stored on the computer, an attack could discover the key value. The important thing to understand is how the key is protected. If the key is decrypted using only other key material that is stored on the same computer, assume that a determined and skilled attacker could discover the key.

Hardware–based Encryption

Some encryption mechanisms leverage special cryptographic hardware to isolate cryptographic operations from the main CPU and to provide increased security for key storage. Such hardware usually includes a means of securely storing one or more cryptographic keys, and might also include functions for performing cryptographic operations in hardware so that the key is never made available to other hardware or software components.

The strengths of hardware–based encryption include:

• Encryption keys are protected from software and operating system vulnerabilities. Hardware–based encryption typically ensures that private portions of key pairs are separated from the memory that is controlled by the operating system.
• Cryptographic operations are protected from software and operating system vulnerabilities. Hardware–based encryption is independent of the host operating system and is not exposed to external software vulnerabilities.

The weaknesses and issues of hardware–based encryption include:

• Limited availability. Encryption hardware is not always available. For example, the TPM module used by BitLocker cannot be retrofitted to older computers and is not universally available on newer computers.
• Difficult to update. If a flaw is found in a hardware–based system, it generally must be replaced. The same is true if the manufacturer wants to add new features or support for new algorithms to the hardware.

Pre-boot (Pre-Operating System) Encryption

BIOS-level firmware can be added to computers so that all data written to a hard disk volume is encrypted and all data read from the disk is decrypted. This operation can be transparent to the operating system and can therefore be applied to the operating system files.

If cryptographic hardware such as a TPM is available, it can be used to make the pre-boot encryption and decryption more secure. Computers that incorporate a TPM can also create a key that is both encrypted and tied to certain platform measurements such as the Master Boot Record (MBR) Code, the NTFS Boot Sector, the NTFS Boot Block, and the NTFS Boot Manager. This type of key can only be decrypted when those platform measurements have the same values that they had when the key was created. This process is called sealing the key to the TPM, and decrypting it is called unsealing.

The TPM can also seal and unseal data generated outside of the TPM. The practical effect of this feature is that the ability to unwrap the key can depend on whether certain characteristics of the platform have changed, supposedly through malicious tampering that attempts to defeat security measures such as encryption.

Because encryption is applied to the operating system files, the key to decrypt these files must be supplied prior to the operating system boot sequence. The key might vary across different solutions and might be derived from a personal identification number (PIN) or a key stored on a hardware device such as a USB token or smart card.

The strengths of pre-boot encryption include:

• Operating system files are protected against offline attack. All system and configuration files are protected by the full-volume encryption solution. Even if an attacker can mount a protected volume with a different operating system—an offline attack—they will not be able to do anything except make the operating system inoperable.
• Increased protection for operating system files. Cryptographic hardware such as the TPM v1.2 with compatible BIOS upgrades provide the ability to validate the integrity of critical early boot components.

The weaknesses and issues of pre-boot encryption include:

• Data recovery strategy is mandatory. Any failure of the BIOS, TPM, or key storage mechanism will make all data on the computer unreadable. Hardware failures are often more difficult to diagnose, triage, and repair than software failures. Repairs might take longer if hardware has to be returned to the manufacturer or repaired at an outside facility. An effective and reliable strategy for key backup and recovery must be developed and frequently tested.
• Software updates may be more difficult. Because the operating system and other files are encrypted and validated against a signature, updating these files might require a special process. Such a requirement could lead to additional operational overhead for computers that use pre-boot encryption technology.

Post-boot (Operating System) Encryption

Post-boot encryption can be performed by the operating system or by any application running on the computer. EFS is an example of a post-boot encryption technology. It is built into the Windows operating system, and therefore cannot be used to encrypt the operating system itself. However, it is an effective means for protecting user and application data.

The strengths of post-boot encryption include:

• Encryption failures do not make the computer unusable. Even if the encryption technology fails, the computer will still be usable. Therefore, it is possible to recover encrypted data without the use of a second computer.

The weaknesses and issues of post-boot encryption include:

• No protection for operating system files and configuration. If the hard disk that contains confidential data is accessed while mounted on a different computer or while the mobile computer is booted into a different operating system, it may be possible to alter the original operating system in a way that allows the encryption to be subverted.
• Data recovery strategy is mandatory. Any failure of the operating system or application software could render protected data unreadable. An effective and reliable strategy for key backup and recovery must be developed and frequently tested.

Application-level Encryption

Encryption can also be implemented outside of the BIOS or operating system levels and performed at the application level. Many applications today offer some capability to encrypt data, including WinZip, Microsoft Office, and Intuit Quicken.

The strengths of application-level encryption include:

• Platform independence. If the application runs on different operating systems, application-encrypted data can usually be moved from one platform to another and still be decrypted if the correct key is present.
• Move data while encrypted. When data is encrypted at the operating system level, it is usually decrypted when file system operations such as copy and move are performed. If the target folder or system is configured for encryption, the data might be encrypted with a completely different set of keys. Application-level encryption usually allows the user to move the data in its original encrypted form to another location.

The weaknesses and issues of application-level encryption include:

• Application dependence. Data moved from one application's format or container to another format or container cannot generally maintain the encryption. For example, a user can extract a file from an encrypted WinZip archive, and the extracted file will be decrypted. If the user does not delete the file when they finish with it, the data could be compromised.

File/Folder Level Encryption

File and folder level encryption is a way to protect certain files and folders and the data they contain. With such a solution, only those files specifically configured to be encrypted are protected. All other data on the computer is unencrypted. A typical approach to file/folder level encryption is to create a unique encryption key for each file or folder. This approach has the added benefit of making it possible to implement per-user encryption as described later in this chapter.

The strengths of well-implemented file/folder level encryption include:

• Better performance than full-volume encryption. Computer performance should not be drastically affected. However, some effect on system performance will inevitably result. File/folder encryption reduces the overall performance impact of encryption because the additional overhead is only applicable to those files that need to be encrypted to satisfy the organization's data security policy.
• Selective encryption. The precise controls of such a solution will allow users to only encrypt sensitive data and allow administrators to force or block encryption of specific folders, files, or data types.
• Support for multiple users. File owners can allow additional users to read or modify the file while keeping it encrypted. This capability allows encrypted files to be safely shared among users.

The weaknesses of file/folder level encryption include:

• Confidential data might leak through files generated by the operating system or applications. Typically, the operating system writes application data contained in memory to files on disk. This application data can contain confidential data. In the Windows operating system, these files include the system paging file and the hibernation file. The operating system might also generate log files or other innocuous file types that could contain confidential data.
• Confidential data might leak through application-level data caching. Applications might implement their own caching or logging mechanisms, such as temporary files, through which confidential data could leak. A good example is the recovery files that get created by Microsoft Word. This weakness can be mitigated to some extent by configuring the application to always create temporary files in a specific directory and then configuring the encryption solution to encrypt all files in that folder.
• Files may be accidentally copied to an unencrypted file or folder. Because only certain files and folders are encrypted, it is possible that a user might inadvertently copy a file’s contents to a different file in a folder that is not configured for encryption.

Full-Volume Encryption

Full-volume encryption complements file/folder level encryption by mitigating common problems with file/folder-level encryption. If the volume to be protected contains operating system files, pre-boot encryption is a requirement for the full-volume encryption approach. If an organization chooses to configure a full-volume encryption solution that does contain operating system files, the weaknesses and strengths of pre-boot encryption should be considered.

The following main strengths of full-volume encryption are primarily mitigations to the file/folder level encryption weaknesses described earlier.

• Operating system temporary files are encrypted. Because the full volume is encrypted, any files that are written to the volume are automatically encrypted, including the system paging file and the hibernation file.
• Application temporary files are encrypted. Any temporary files that are created by an application are written to the encrypted volume and are therefore automatically encrypted.
• All files created by the user are automatically encrypted. If the user copies a file to a different folder on the volume, it will still be encrypted automatically. With full-volume encryption it is much harder for the user to mistakenly subvert the encryption solution.

The weaknesses and issues of full-volume encryption include:

• Reduced performance. Every block on a protected volume must be decrypted when it is read, and if it is written back to disk it needs to be encrypted again. This functionality applies to the operating system's executable and configuration files, application executable and configuration files, and all data files. Although modern encryption is relatively efficient, system performance degradation of 5 to 15 percent can be expected with full-volume encryption.
• Limited protection against insider attacks. Full-volume encryption provides protection against a variety of offline attacks, but generally provides limited protection against attacks mounted by malicious insiders who typically have (or can gain) the ability to log on to a target computer with a legitimate account.

Per-User Encryption

Encryption can be implemented in such a way that multiple users have the ability to decrypt the keys that are needed to encrypt and decrypt the data files on the computer using their own unique key, which might be a password or a key stored on a USB or similar device. When this approach is combined with individually keyed file/folder level encryption, it is possible to provide access to individual users on a file-by-file basis.

The strengths of per-user encryption include:

• Precise control over who can read encrypted data. Other users of the computer cannot read encrypted data unless specifically granted that ability by the owner of the file. This functionality provides a level of access control as well as data confidentiality.
• The ability to selectively encrypt only sensitive data. With a properly implemented per-user encryption system, you can select exactly which files and folders are protected.
• The ability to encrypt files for multiple users. A properly implemented per-user encryption system allows a file owner to encrypt a single file for multiple users, enabling sharing while maintaining good security. In addition, this functionality can be used to implement data recovery by allowing an authorized recovery agent to decrypt protected files.

The weaknesses and issues of per-user encryption include:

• Only secure as weakest key/credential. With this approach, each encryption/decryption key must be encrypted with multiple keys (one for each unique user). Each encrypted key can be attacked separately by an attacker who is looking for one key that is particularly weak, especially when local logon, network logon, or non-logon passwords are used to derive key material.

Per-Computer Encryption

Some data encryption implementations do not provide the ability for different users, each with a different key or password, to decrypt the master key(s) needed to decrypt data on the computer. In such an implementation there is exactly one key that can be used to access the computer, including all encrypted data.

The strengths of per-computer encryption include:

• Simpler key derivation sequence. If only one key can be used to initiate the key derivation sequence, the entire mechanism is substantially less complicated. Reduced complexity can—but will not always—lead to increased security.

The weaknesses and issues of per-computer encryption include:

• No protection against malicious insiders. Any user who is allowed by policy to log on to the protected computer can access any file on the computer in unencrypted form.

More Information

• Cryptography for Network and Information Security
• To password-protect your computer during standby or hibernation
• Avoiding bogus encryption products: Snake Oil FAQ
• Special Publication 800-12 – An Introduction to Computer Security: The NIST Handbook
• Federal Information Processing Standards (FIPS) 140 Evaluation standards
• Windows Platform Common Criteria Certification
• The Trustworthy Computing Security Development Lifecycle