Attacking & Defending Full Disk Encryption

One of your company’s laptops was just stolen. You know that there was sensitive information on the machine. You also know that full disk encryption was deployed. Is your data safe? Can you prove it? Many organizations are flocking to full disk encryption solutions as a solution to their data security requirements. Unfortunately, many of these installations view the deployment of full disk encryption as a panacea for any and all security concerns for their laptop fleets. All too often, these systems are not properly configured and adequately tested.

Blog: Attacking and Defending Full Disk Encryption

One of the security technologies I have seen gaining popularity over the past several years is full disk encryption (FDE). While this was initially a tool that was only deployed in limited situations, this technology has grown to mainstream use across a myriad of corporate laptop fleets.In many organizations full disk encryption on mobile devices such as laptop computers is the standard and unencrypted machines have become the exception to the rule. This jump in popularity has driven me to better understand how this technology is deployed, as well as common vulnerabilities and configuration issues that exist in many environments. Like any security technology, full disk encryption systems are not foolproof. I have successfully gained access to fully encrypted laptops that are completely powered off, without any information other than what is present on the system itself. In some cases, a machine was completely compromised in minutes. Several of these tests involve actual deployments that were analyzed as part of forensic penetration tests that I performed. I suspect that many other actual deployments of full disk encryption systems are vulnerable to the same types of attacks I have used in the past. I hope that this blog post will shed some light on the common attack vectors and risks associated within a full disk encryption environment. I will begin with an overview of full disk encryption technologies as well as some common deployment scenarios. I will then describe the methodologies I have used to successfully gain access to several of these systems. I will conclude with some recommendations on how you can assess and improve the security of your FDE deployment.

Overview of Full Disk Encryption

Encryption technologies are designed to protect data. Full disk encryption is used to secure data at rest. Increasingly, companies are turning to FDE as a solution for protecting mobile data. Perhaps the most common use case for FDE is protecting an organization’s laptop fleet. From what I’ve seen, many companies have requirements that at least some systems be encrypted – especially those that are used by individuals that might have access to sensitive and/or proprietary information. Taking things a step further, an increasing number of organizations are moving towards a model where all of their corporate owned laptops are encrypted by default. Some organizations will also deploy FDE on desktops, but this application is far less common. Due to the ease at which a hard drive can be removed from a standard business desktop and the lack of physical security that would prevent a drive from being removed from a facility, there are certainly strong arguments for deploying FDE on a wider scale. When full disk encryption is deployed, it is assumed to be a black-box panacea for all data security issues. All too often, the simple presence of FDE is considered protection enough to secure a system. Like any tool or system designed for security, FDE is by no means bulletproof. Unfortunately, FDE is often implemented, but rarely verified or tested. The vulnerabilities, configuration oversights, and potential weaknesses of different FDE technologies and implementations are only infrequently discussed and even less well understood.

Attacking Full Disk Encryption

At its core, the actual encryption technology used in most commercial products is some variation of AES, a system that is currently considered to be very secure. At the time of this article’s writing, it is not practical or possible to break the encryption algorithm used in most FDE systems itself. When evaluating the security of an encrypted system, this fact alone is often considered adequate to consider the deployment to be secure. The security oversights I have seen on many full disk encryption penetration tests do not involve the actual encryption technology being used “under the hood”. Encryption is one of those technologies where it makes sense to simply use the best current standard available. I would be concerned to see a product in this market that was using a custom encryption algorithm – these are not only typically significantly less secure than the accepted standards, but sometimes even contain major programming or implementation oversights that render the algorithm trivial. Full disk encryption is better attacked by considering possible weaknesses in the configuration and deployment of the system. Generally, the most successful method for attacking a fully encrypted system is to attack the operating system directly. When the operating system is running, decryption is taking place. While the data on the hard drive is still stored in an encrypted manner, this data must be decrypted to be loaded into memory. The CPU also must work with unencrypted data. There are several methods that are often used for FDE authentication. Many products offer an integrated authentication scheme that ties the FDE authentication into the authentication for the operating system. This is often deployed as a convenience for users, since they only need to log in once to use the system. The problem with this authentication method is directly related to when the user is prompted for his or her credentials. If the operating system is allowed to load, it can be compromised. Configurations that require authentication prior to booting the operating system prevent a hacker from immediately attacking the operating system. I have also found various loopholes with pre-boot authentication schemes, such as a grace period where a system does not require authentication before booting within a limited time of last contacting an authentication server. Prior to testing any fully encrypted system, I will first make a full image of the system in question using a forensics writeblocker. If such a window exists where pre-boot authentication is not required, I have been able to locate this through trial and error while repeatedly reimaging a scratch disk from my master copy. Since the hard drive has no sense of time, the system clock is considered absolute for determining the timeframe for such a window. Once the system is powered on, any timestamps on the disk are updated and the working drive will need to be reimaged in order to run another test. This is certainly a time consuming process, but it can be effective if the system being tested has such a feature. Ultimately, I will want to get the system to a point where the operating system is loaded to proceed. In some cases, this is not possible. The most effective method for attacking a running operating system on a fully encrypted machine is through memory manipulation. Modern computers offer several interfaces that feature direct memory access (DMA) – a technology that permits access to the lower 4 GB of system memory independently of the CPU. Interfaces that offer DMA include FireWire (one of my favorites for these sorts of tests), PCMCIA, ExpressCard, and Thunderbolt. Since most operating systems support plug and play and will install device drivers, a system running software designed to copy the contents of and manipulate memory can be connected to such a system. I have found that a tool called Inception can be very useful for dumping the contents of memory (which may contain the decryption key) or manipulating the password validation code in the currently running operating system to allow any password to be accepted as valid for the administrator account. At this point, the system is generally completely accessible.

Protecting Your Environment

As an industry, there is room for improvement in the deployment of FDE. The following recommendations can be used to better protect your fully encrypted machines. Like any security recommendations, some of these are easier to implement than others and some may not be practical in your environment. You must consider the risks involved and pick the best options for your particular situation.


  • Pre-boot authentication is absolutely mandatory – on every boot. As I demonstrated, if there’s any window where pre-boot authentication is not required, that window can be discovered. Once the operating system loads, the presence of encryption is often a non-issue. By far, this is the most important step towards protecting your encrypted systems and data.
  • Disable DMA interfaces: Laptops come with many DMA capable interfaces which are typically enabled. In many of my tests, the DMA interface used is Firewire, but other interfaces such as PCMCIA and ExpressCard can be used as well. All modern operating systems support plug and play and will allow device drivers to be loaded automatically when a system running a memory acquisition tool is connected. More often than not, these interfaces are not typically used and can be disabled in the BIOS with minimal to no impact. Disabling these interfaces prevents an attacker from accessing the memory of a powered on system that is left unattended.
  • Understand the ramifications of standby and hibernation modes. Both standby and hibernation allow a system to be powered on without pre-boot authentication being required. In most cases, both should be disabled to prevent a system from being stolen in a state where pre-boot authentication will not be required. Some products can be configured to force pre-boot authentication for both standby and hibernation. If available, this should be enforced.
  • Establish a policy where powered on machines shall never be left unattended – even locked systems are vulnerable.
  • Trust but verify: testing and verification is the best option for securing FDE. Do not assume a given solution is secure out of the box and that the default settings are optimal. Whenever possible, have your implementation verified by an independent third party. This type of assessment should be performed by someone who is both familiar with full disk encryption security concerns and not associated with the vendor whose solution you are deploying.


Finally, vendors are trusted by their customers to provide a data protection solution. Vendors need to be aware of the vulnerabilities in their products and any configuration options that may put their customers’ data at risk. When possible, settings that reduce the security of an implementation should have clear warnings of the risks associated with these selections. I would like to offer the following suggestions to those tasked with developing the tools we must rely on to manage and safeguard our data:
  • Perform all authentication prior to loading the operating system.
  • Never store or cache any authentication tokens locally.
  • Develop methods to better tie the encryption to the hardware it is installed on. Recognize changes in physical drives (resulting from imaging) using serial numbers or SMART data.


  • Disable plug-and-play while the system is locked and before initial log in.
  • Log the presence of any unauthorized devices, offer the option of alerting the user if a device was connected when the machine was locked.

I hope that you found this article to be both interesting and informative. If you have any questions, comments, or additional research on this topic you would like to share, please let me know. This topic was originally presented in July 2013 at the Bsides Las Vegas Security Conference.