Full Disk Encryption DRAM Attack

Ed Felton never fails to deliver interesting things but his announcement yesterday of a viable attack against full disk encryption products by using the fact that DRAM isn't actually as volatile as we thought it was is a doozy. Memory scraping has been used before, for example it was the method used to lift the encryption keys that led to the first successful attacks on the HD-DVD\Blu-Ray AACS security system. Most of the previous uses of memory scraping that I've come across required that the attackers worked within the constraints of the active OS and that meant that software based defences could prevent these attacks provided developers (of the OS and the applications) were careful. Windows Vista for example protects encryption keys and other secure data in memory and prevents other processes from accessing the keys. The specific problem here is that even when a Trusted Platform Module (TPM) is used the OS doesn't use the TPM to handle the actual decryption of the disk data. In Vista's BitLocker, for example, the drive is encrypted with an AES key called the Full Volume Encryption Key (FVEK). That key is stored in encrypted form on the hard drive and it is encrypted using a key called the Storage Root Key#. In the simplest model that key is generated within the TPM and never leaves*. This means that the the SRK is very secure. However the FVEK must be available to the OS as it needs that to decrypt the drive data on the fly. This means that even with a standard TPM module protecting the keys, the FVEK must remain unencrypted in memory in some accessible form. In practice it will be stored in a predictable data structure and Felton's team have found that it is not very hard to locate if you have access to a copy of the physical memory from a running system.

It should be noted that Microsoft explicitly called out the potential for this class of attack in their BitLocker documents ( e.g. on slide 16 of this BitLocker presentation from 2006) where they note that the physical PC must Memory Overwrite on Reset in order to prevent physical memory attacks and that is a feature of the Trusted Computing Group's client platform specifications but I'm not aware of any systems that actually implement it. The problem with Overwrite on Reset is that it's only a protection in the case where the attacker reboots using the same BIOS. It definitely makes the attack much harder though - without it USB key and PXE Boot based attacks are perfectly viable.

The attack works because the TCG's trusted platform specifications (and the various software based full disk encryption products) do not require the use of cryptographic hardware to handle the decryption of the actual drive data. If the FVEK was never decrypted to RAM but was instead retained within a cryptographic hardware module then all the drive data would have to be channeled through that module in order to be decrypted and that would be a serious performance problem. Current DRAM technology has throughput speeds in the range of 2-5Gbit/sec and hard drives are typically in the 400Megabit-1Gbit/sec range. The typical TPM of the type used in consumer PC's (e.g the ATMEL AT97SC3203 ) are too slow (Atmel chip has a 100khz serial data interface) and doesn't provide support for streaming bulk decryption and so could never be used for this sort of task in any case. The hardware to carry out decryption at the sort of speeds that hard drives operate at is available and given that HD-DVD, HDCP and Blu-Ray all require decryption speeds in the range of 400Megabits/sec so it should be available but overhauling PC architectures to integrate this would take time. Felton's team's paper identifies some other options - the simplest of which is basically making tamper proof memory. In any case whatever the implementation it will require a bit of care and attention to detail in order to be genuinely secure. Bunny Huang's attacks on the original Microsoft X-Box attacks showed why it's dangerous to separate cryptographic functions across a connecting bus that isn't encrypted although the capability to do this sort of active attack is not trivial. My gut feeling is that the best eventual solutions to this will be cryptographic modules built into the core cpu that provide high bandwidth decryption, key management and the rest of the TPM functions so that no unencrypted keys ever end up either in RAM or moving between modules over a snoopable bus. Intel had plans to do this but I don't know if it's actually made it into production hardware yet beyond some of the Bulverde mobile CPUs that were sold to Marvell.

Overall this is a very interesting demonstration of what had been a mostly theoretical attack. It's not a new "class break" in the sense that it was a known potential vulnerability and memory scraping is a common technique but their demonstration of the persistence of sensitive encryption data in DRAM following a reset is certainly going to give the security community (and the hardware hacking community) lots of new risks and opportunities to ponder.

# I'm not a Bitlocker expert so forgive me if the terms are wrong - I've seen some documents discuss the Bitlocker trusted boot process that refers to the Volume Master Key (VMK)that appears to be what I'm calling the Storage Root Key (SRK). The principle remains that there is a master key protected by the TPM that eventually decrypts the actual AES key that decrypts the disk data that is stored in memory.

* This is not the case when using some of the Bitlocker key recovery options. Whether the SRK is attackable or not doesn't change the fact that the FVEK ends up more or less in the clear in physical memory once the OS has booted.