Following on from my last rant about the TechMesh event I went to recently, I’m finally getting round to writing up an explanation of the BitLocker decryption attack demoed there as “scary software from Russia that can decrypt your drive and an attack which Microsoft needs to fix RIGHT NOW” (I paraphrase).
The demo is a good one, and really impressive to see in action. Given physical access to a machine with an encrypted disk, powered on but with the screen locked, the software retrieves the encryption key and provides a decrypted copy of the disk.
To explain how this works let’s go back an few stages and look at how disk encryption itself works at the highest of high level views.
After a machine boots, the OS uses the decryption key to decrypt the hard drive on the fly and present it to applications as an un-encrypted disk. The important point to remember here is that the OS must have a copy of the decryption key in memory once it’s booted so that it can decrypt the disk (or sectors thereof) as required.
There is no way round this. The only alternative would be for the OS to request the passphrase every time it needed to read the disk. This might impact somewhat negatively on performance :) The problem with this is that if the key is in memory, it can be read by an attacker as well.
So, we need a thinking hat:
to come up with some attacks.
- I place a virus on your machine somehow (“Click here to see to install the codec to see this video”) and run it as an administrator (either because the user already is an administrator or via a privilege escalation attack). Now I can read the encryption key from memory……except that I don’t need to. Since the OS presents the drive as unencrypted to applications, my virus can just read your data without worrying about disk encryption at all.
- I have physical access to the device, but it’s powered off. We’ll come to this later.
- I have physical access to the device and it’s powered on. It doesn’t matter if it’s screen locked or not.
Attack 1 is something often forgotten - if I can run code on your machine while you are using it, it doesn’t matter if the disk is encrypted. You need it decrypted to use and if you can read it so can my code.
Attack 3 is the subject of this post and the TechMesh talk. The demo’d attack uses a firewire connection to a locked machine. Why Firewire? Because the Firewire spec requires Direct Memory Access (DMA) for performance. Even better, it doesn’t matter if the laptop targeted doesn’t have a firewire port since PCMCIA or ExpressCard slots can be used to add a Firewire adaptor and the Windows will helpfully load the relevant drivers even if the screen is locked.
The original explanation of the attack, “0wned by an ipod” was presented at PacSec in 2004. The observation is a simple one - DMA means the Firewire attached device can read or write any area of memory, and because it’s required in the spec, all firewire implementations must allow this. The original attack re-wrote the Windows screen lock code to accept any password. The variant used here just reads out the Bitlocker key directly from memory, while also taking a copy of the disk itself via Firewire. Combine the two and you get a copy of the disk that the attacker can read, all with no need to login to the target machine.
As I said at the start, it makes for an impressive demo.
The sotware used in this demo looked remarkably similar to Passware’s product. I didn’t get a good enough look to see if it was just a hacked copy resold or a genuine re-implementation of the attack. Russian software developers are capable of either. Eitherway, the take-away here is that this isn’t a flaw in Bitlocker. It’s inherent in how Firewire works and how disk encryption works. The same attack works against encryption on a Mac as well.
I’ll leave the final word to Microsoft (via PCMag.com):
The claims being made by Passware that they are able “to break Microsoft BitLocker hard drive encryption” must be taken in context of the needs of data recovery and forensics tools. The Passware Kit Forensic product, like others used legitimately for digital forensics analysis, requires “a physical memory image file of the target computer and extracts all the encryption keys for a BitLocker disk.” We have always been up front in our discussions of Windows BitLocker and that it is intended to help protect data at rest (e.g. when the machine is powered off). If a forensics analyst or thief/adversary has physical access to a running system, it is possible to take advantage of the fact that the contents that are in a computer’s memory are accessible through users with administrative privilege and/or specific direct memory access hardware methods (if available.
BitLocker is an effective solution to help safe guard personal and private data on mobile PCs and provides a number of protection options that meet different end-user needs. Like most full volume encryption products on the market, BitLocker utilizes a key in memory when the system is running in order to encrypt/decrypt data on the fly for the drives in use. We recognize users want advice with regards to BitLocker and have published best practice guidance in The Data Encryption Toolkit for Mobile PCs. In the toolkit, we discuss the balance of security and usability and detail that the most secure method to use BitLocker is hibernate mode and with multi-factor authentication. Using this method, a machine that is powered off or in hibernate mode would protect users from the ability to extract a physical memory image of the computer.
That’s the end of this post. It’s nearly 10.30pm and time for bed. Next time, I’ll look at attacks that work when the machine is powered off, and at the role of Trusted Computing Modules (TPM chips), and try and explain why disk encryption is still a good thing even if it’s not quite the magic bullet it’s often assumed to be.
