Apple MacBook Air. Picture via maury.m on Flickr, under CC BY-ND-NC.
A merry gang of hackers and researchers, mostly from Princeton, announced today some strong results against full-disk encryption (FDE) on running — but locked — computers. Summarizing in a sentence, software-based FDE systems keep encryption keys for active volumes in RAM; those keys don’t vanish from RAM immediately after rebooting or powering off, and can be recovered by relatively uncomplicated tools giving the attacker full access to your encrypted volumes.
This really isn’t a straightforward problem to fix — it’s a hardware issue, not a software one. The obvious countermeasure of overwriting RAM with zeroes on reboot doesn’t work, because cooling the RAM chips with off-the-shelf “canned air” coolant will prolong the data remanence effects for minutes or hours, giving the attacker enough time to nonchalantly unplug the RAM chips from your computer and transport them to one she controls. Their contents can then be read without any interference.
Cute, right? Hold that thought.
When Apple announced the MacBook Air a month ago, there was much ballyhoo as self-important industry analysts and journalists fell over one another decrying, among other things, the fact that it was impossible to upgrade the laptop’s RAM. Apple had soldered the Air’s 2GB of DDR2 SDRAM directly onto the motherboard.
Which is quite funny. It means that if Apple released an EFI firmware update for the Air which zeroized the RAM contents at the beginning of every boot, the Air would become one of the only — if not the only — mainstream laptop featuring full-disk encryption that’s highly-resistant to the troublesome Princeton attack.
MacBook Air: the laptop of choice for discriminating security-conscious fashionistas the world over.
Nick said,
February 22, 2008 @ 4:37 am
If you read the paper, one or more of the techniques described do not give the computer the opportunity to boot during the attack.
Ivan Krstić said,
February 22, 2008 @ 6:09 am
Nick — I read the paper quite carefully. It lists three imaging vectors: simple reboot, DRAM module transfer, and remote network attacks (which cause a reboot). The MacBook Air’s DRAM chips are soldered to the logicboard, making the second attack vector extremely difficult. If a RAM zeroizer was present in the firmware as a forced boot step, the other two vectors cease to work, leaving no easy way to mount this type of attack.
Ben Schwartz said,
February 22, 2008 @ 9:38 am
I don’t understand why anyone is talking about this attack.
So the scenario is: I’m logged into my Thinkpad (non-macbook-air laptop), accessing my securely encrypted drive, using my 4096-bit private key, which I’ve stored on a USB stick. Someone runs up and steals my laptop, and inside their white van they turn it off, rip it open, and drop the DRAM into liquid nitrogen pending further analysis.
OR, they could just read my private key of the USB stick.
Ok, let’s say that I’ve memorized my key, or I’m using some kind of unusually secure password-based system. So they’ve taken my laptop, they want access to my encrypted disk, they don’t have the private key… but I’m logged in! They can just open a terminal and cp -r * /media/Evil_USB_drive/.
Ok, maybe they don’t just want my data. They want the private key, for some reason. And maybe the private key is only stored in kernelspace, and they really can’t think of any local root exploits, even though they can plug in arbitrary devices. Even then, the RAM is still powered. They don’t have to turn it off. Given a little bit of appropriate hardware, they can read it out without ever interrupting the power supply. Heck, they can probably twiddle bits in RAM to give themselves root, and then copy out the contents of memory from inside.
I can maybe come up with a scenario where this exploit provides the attacker some new advantage, but it’s a pretty implausible one. Local hardware access == total control. Surprise!
Ivan Krstić said,
February 22, 2008 @ 1:44 pm
Ben — you’re underestimating the result. Most laptops merely need a reboot to fall to this attack; no liquid nitrogen required. It was previously a reasonable expectation that a running but locked laptop with FDE was quite secure, data-wise, even in the wrong hands. Now, leaving a locked running laptop in your hotel room while you get lunch is no longer an option; the housekeeping staff could trivially obtain your key(s). The same goes for an eager customs and border protection agent.
Brad said,
February 22, 2008 @ 5:00 pm
I think they may be mistaken as far as TrueCrypt goes, but I’m not a computer science major. When mounting a TrueCrypt volume, there is an option for caching the password and (possible) keyfiles.
My understanding is that, if not checked, the password and keyfiles will be used and referenced once, upon the mounting of the encrypted drive. It seems that they would not then be stuck in the memory unless the attack was done immediately after the mounting. With Bitlocker and File Vault there doesn’t seem to be any way to prevent caching of the passwords and keyfiles; TrueCrypt, however, has the direct option of caching. Is my understanding wrong?
Ivan Krstić said,
February 22, 2008 @ 11:02 pm
Brad — I haven’t used TrueCrypt, but the password caching it offers is likely an end-user convenience. The commercial PGP clients, for instance, feature an option to retain the user’s passphrase in memory for some amount of time so you don’t have to re-enter it every time you send an encrypted e-mail. This is irrelevant to the Princeton attacks. TrueCrypt, like every other software-based FDE system, must keep the actual key material in RAM in order to be able to keep your encrypted volume active. If it didn’t keep the key material resident, it would have to ask you to enter your password every time you wanted to perform any operation whatsoever on the encrypted disk — be it listing directory contents, reading a file, or writing one.
Ben Schwartz said,
February 23, 2008 @ 1:09 pm
OK. So the upshot is that encryption should always be per-user, not just systemwide, and there should not be middle ground between logged in and logged out. That seems fair, and potentially nontrivial.
I would still argue that this would be possible even if RAM didn’t hold its charge, since the hacker could simply attach their equipment to the leads of the RAM on a running system. This paper just describes a way to make that work without the need for extra fancy equipment and highly skilled technicians. I’m willing to accept that that’s important to know.
Ivan Krstić said,
February 23, 2008 @ 8:59 pm
Ben — one of the major contributions of this attack is indeed to demonstrate that key recovery can commonly be done by someone with a laptop, a network cable and 5 minutes of training. It was previously understood that the economics of mounting this type of attack made it prohibitive for all but government entities. The Princeton attack shows the bar is dramatically lower than that, and is thus a very real, practical threat.
Morgan Collett said,
February 25, 2008 @ 4:40 am
This is why CAs and others who want to protect their keys commercially use HSMs where the key is on a removable device that implements AES (or whatever) and never exposes the key in RAM. Smartcards and USB crypto tokens do this for a single user.
Ivan Krstić said,
February 25, 2008 @ 11:02 am
Morgan — it’s a matter of economics and complexity. Obviously, organizations that are sufficiently interested in protecting their employees’ data will find a way around these attacks, but doing so is neither cheap nor convenient. Given that security is an uphill battle even when it is cheap and fairly convenient, this doesn’t bode well for real-world scenarios.
Faré said,
March 31, 2008 @ 3:08 pm
If the boot parameters are password-protected and the boot configuration is to only boot from the configured on-board HD or SSD, then no EFI upgrade is really necessary. If the attacker could take away the disk, they could as well take away the RAM.
In any case, all that makes me wonder why I’m taking the pains of encrypting my hard disk. Do I have any lazy and unprepared enemies?
RSS feed for comments on this post
Leave a Comment