Comments on: Fashion-aware disk encryption

By: Faré

Faré — Mon, 31 Mar 2008 20:08:26 +0000

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?

By: Ivan Krstić

Ivan Krstić — Mon, 25 Feb 2008 16:02:49 +0000

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.

By: Morgan Collett

Morgan Collett — Mon, 25 Feb 2008 09:40:50 +0000

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.

By: Ivan Krstić

Ivan Krstić — Sun, 24 Feb 2008 01:59:43 +0000

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.

By: Ben Schwartz

Ben Schwartz — Sat, 23 Feb 2008 18:09:57 +0000

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.

By: Ivan Krstić

Ivan Krstić — Sat, 23 Feb 2008 04:02:30 +0000

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.

By: Brad

Brad — Fri, 22 Feb 2008 22:00:30 +0000

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?

By: Ivan Krstić

Ivan Krstić — Fri, 22 Feb 2008 18:44:31 +0000

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.

By: Ben Schwartz

Ben Schwartz — Fri, 22 Feb 2008 14:38:31 +0000

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!

By: Ivan Krstić

Ivan Krstić — Fri, 22 Feb 2008 11:09:20 +0000

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.