Cold Boot Attacks Against Disk Encryption

Nice piece of research:

We show that disk encryption, the standard approach to protecting sensitive data on laptops, can be defeated by relatively simple methods. We demonstrate our methods by using them to defeat three popular disk encryption products: BitLocker, which comes with Windows Vista; FileVault, which comes with MacOS X; and dm-crypt, which is used with Linux.

[…]

The root of the problem lies in an unexpected property of today’s DRAM memories. DRAMs are the main memory chips used to store data while the system is running. Virtually everybody, including experts, will tell you that DRAM contents are lost when you turn off the power. But this isn’t so. Our research shows that data in DRAM actually fades out gradually over a period of seconds to minutes, enabling an attacker to read the full contents of memory by cutting power and then rebooting into a malicious operating system.

Interestingly, if you cool the DRAM chips, for example by spraying inverted cans of “canned air” dusting spray on them, the chips will retain their contents for much longer. At these temperatures (around -50 °C) you can remove the chips from the computer and let them sit on the table for ten minutes or more, without appreciable loss of data. Cool the chips in liquid nitrogen (-196 °C) and they hold their state for hours at least, without any power. Just put the chips back into a machine and you can read out their contents.

This is deadly for disk encryption products because they rely on keeping master decryption keys in DRAM. This was thought to be safe because the operating system would keep any malicious programs from accessing the keys in memory, and there was no way to get rid of the operating system without cutting power to the machine, which “everybody knew” would cause the keys to be erased.

Our results show that an attacker can cut power to the computer, then power it back up and boot a malicious operating system (from, say, a thumb drive) that copies the contents of memory. Having done that, the attacker can search through the captured memory contents, find any crypto keys that might be there, and use them to start decrypting hard disk contents. We show very effective methods for finding and extracting keys from memory, even if the contents of memory have faded somewhat (i.e., even if some bits of memory were flipped during the power-off interval). If the attacker is worried that memory will fade too quickly, he can chill the DRAM chips before cutting power.

There seems to be no easy fix for these problems. Fundamentally, disk encryption programs now have nowhere safe to store their keys. Today’s Trusted Computing hardware does not seem to help; for example, we can defeat BitLocker despite its use of a Trusted Platform Module.

The paper is here; more info is here. Articles here.

There is a general security problem illustrated here: it is very difficult to secure data when the attacker has physical control of the machine the data is stored on. I talk about the general problem here, and it’s a hard problem.

EDITED TO ADD (2/26): How-to, with pictures.

Tags: , , , , , , ,

Posted on February 21, 2008 at 1:29 PM • 126 Comments

Comments

bootman • February 21, 2008 1:44 PM

Store your keys at 0x7C00. That’s where the bios bootloader will put the first sector of the first bootable device.

AJ • February 21, 2008 1:57 PM

I thought that this was the reason for having the “memory count” at boot-up — it “wiped” DRAM before startup. I seem to recall later Macintosh computers appearing with this “new old” behavior (about the same time they started using a “standard” keyboard layout); I assumed this was to meet US government standards.

It would seem that having the BIOS do a DRAM “initialize” as part of the POST process would minimize if not render this method moot.

Timothy Clemans • February 21, 2008 1:59 PM

Holyshit how long has the FBI known about this? Oh and does the NSA care about this sort of thing? I’m assuming the CIA does care. Who in the federal government would care about this sort of thing?

How long before there is a fix for this?

Terry Browning • February 21, 2008 2:01 PM

Quite a few people will be happy about this: the police, anti-virus researchers, DRM breakers.
I especially like the bit where they moved the RAM to another machine before reading it.

Maybe if I welded my case shut, set the BIOS to boot only from the HD and password protected the BIOS?

@AJ
The memory count just does a quick sanity check on the presence of memory..

Anonymous • February 21, 2008 2:07 PM

Bootman has a nice idea, but it’s probably not going to work in general, as 512 bytes probably isn’t enough space.

Laptops have batteries, so you can probably convert the problem into a very tight race: if either the battery or the mains are disconnected, zap the keys.

The downside is that you need to prevent crypto-access to the disk until both mains and battery are online.

Clive Robinson • February 21, 2008 2:07 PM

The DRAM hold is actually quit old news ands has a fairly simple solution.

You build your key dynamicaly into a CPU register imediatly prior to use. The key its self is either never stored in RAM or (due to OS issues) securly over writen imediatly it has been loaded etc.

The difficult bit is how do you split the key up or encode it so the parts you build it from cannot be found and used to build the key?

It can be done and is done in some secure coms units its neither difficult or obvious.

Just think of a snake swallowing its tail in the dark then work out how it could do it forever 8)

Nicholas Weaver • February 21, 2008 2:09 PM

Terry Browning: If you read the paper, the memory check/count is a write/read test, so it does actually clear/reset the bits, and systems with ECC have manditory reset on the bits.

Part of the problem is that if you can take the machine apart enough while its live, you can freeze the memory with a duster canister, and the memory is good for over 10 minutes at -50C, which is sufficient to put it into a different host which doesn’t do the memory clearing on startup.

Clive Robinson • February 21, 2008 2:09 PM

The DRAM hold is actually quit old news ands has a fairly simple solution.

You build your key dynamicaly into a CPU register imediatly prior to use. The key its self is either never stored in RAM or (due to OS issues) securly over writen imediatly it has been loaded etc.

The difficult bit is how do you split the key up or encode it so the parts you build it from cannot be found and used to build the key?

It can be done and is done in some secure coms units its neither difficult or obvious.

Just think of a snake swallowing its tail in the dark then work out how it could do it forever 8)

Nicholas Weaver • February 21, 2008 2:12 PM

Clive, the problem is you need some serious low level OS and CPU VooDoo to get a piece of memory, even just 256b, that doesn’t leave the confines of the cache.

Anonymous • February 21, 2008 2:21 PM

-50C from a “canned air” dust spray can??? Do these guys even know what -50 feels like? And removing a chip at -50C you better be using gloves or something, or at the very least you’ll get some frostbite!

asdfoiuy • February 21, 2008 2:31 PM

@Anonymous
-50 is no big deal. You have to consider heat capacity. The thin metal or plastic clips you will touching have almost no heat capacity so your fingers will heat them to body temperature almost immediately. No problem. Where we live our fingers are exposed to air of similar temperature every winter and air has about the same heat capacity as these tiny clips.

Rick Auricchio • February 21, 2008 3:00 PM

This effect was discovered in late 1978 at Apple. The Autostart ROM for the Apple ][ checked for a RAM jump-vector at every reset.

In order to detect a cold boot, it was necessary to use a checksum byte.

J Random Programmer • February 21, 2008 3:03 PM

…and even if you just keep the key in registers, the first task swap that comes along will push your registers out to memory.

Carlo Graziani • February 21, 2008 3:06 PM

Seems to me the natural defense against a power-interrupt attack is to rely on induction to wipe the memory. That is, somehow (!) arrange for a coil carrying a DC voltage around the DRAM, with the voltage chosen so that a sudden power interruption will induce enough current in the chips to put some random charge on each little storage capacitor — but hopefully not enough to damage the chip, or mess up the hard drive.

Of course, now you have to protect the coil, and its circuit…

Andrew2 • February 21, 2008 3:09 PM

I don’t get it. Why can’t the OS just wipe the sensitive bits when:

a) the OS is shutdown, or
b) the power supply detects powerfail?

The CPU and RAM should still have a few milliseconds between the powerfail signal and the PSU’s smoothers actually running out of juice. That should be plenty of time to wipe a few kB.

Carlo Graziani • February 21, 2008 3:35 PM

Andrew2: If the snoopers pull out the power connectors at the motherboard, there’s no powerfail signal.

Alan • February 21, 2008 3:36 PM

1) The file system encryption service should overwrite the memory it uses when dismounting.
2) The encrypted filesystem should be dismounted during shutdown.
3) And the user should shut down the machine when leaving.

I think that would give reasonable protection.

Ian Mason • February 21, 2008 3:37 PM

@Clive : “Just think of a snake swallowing its tail in the dark then work out how it could do it forever 8)”

Judging from the triple posting I suspect you’ve been drinking benzene rather than dreaming about it!

Gerg • February 21, 2008 3:39 PM

The difficult bit is how do you split the key up or encode it so the parts you build it from cannot be found and used to build the key?

Don’t count on it to protect anything valuable. People have reverse-engineered far more complex obfuscation techniques than that just to crack their favourite game.

Gerg • February 21, 2008 3:40 PM

(Sorry, apparently this blog eats html in comments)

“The difficult bit is how do you split the key up or encode it so the parts you build it from cannot be found and used to build the key?”

Don’t count on it to protect anything valuable. People have reverse-engineered far more complex obfuscation techniques than that just to crack their favourite game.

dragonfrog • February 21, 2008 3:41 PM

Andrew2

OS shutdown is no problem – there’s lots of time then; this is about yanking the power cord.

The latter problem has a couple of reasons

  • nobody thought of doing it
  • which few hundred KB to wipe with your last precious power? You’d have to provide, in hardware, for every possible disk encryption system.

Alternately I guess, hardware vendors could provide a standard memory range that will always be wiped regardless of whether shutdown is graceful. OS’s would have to provide a method to guarantee that certain data will be kept in such self-destructing RAM, and never leave it.

All this seems like it should be possible – but it would take a long time to get in place

Rich • February 21, 2008 3:50 PM

@dragonfrog

Good points. However, even a particular memory range will not solve the problem, if you open the case and yank the RAM (which would be enhanced by cooling).

Tim Jansson • February 21, 2008 3:55 PM

“Store your keys at 0x7C00. That’s where the bios bootloader will put the first sector of the first bootable device.”

Wont matter if they have special devices for stuff like this. 😛

I see more responses like “oh the OS should wipe the memory upon shutdown”. Well thats easy on Linux; just add “smem -f” to your shutdown process (/etc/rc.shutdown?) (smem is from the “secure_deletion toolkit”) (google is your friend).

This will hover not prevent anyone from just pulling the plug…

Andrew2 • February 21, 2008 4:03 PM

“If the snoopers pull out the power connectors at the motherboard, there’s no powerfail signal”

Ah, right. Didn’t think of that.

The other problem is the PC architecture doesn’t actually seem to give a decent power fail signal. The ATX “all’s well” line just serves to clamp any chip with a RESET pin when it goes out, so there is no time to do anything anyway without custom hardware.

Anonymous2 • February 21, 2008 4:09 PM

Forgive the basic question here, but how does a simple password protect the encryption key in the first place?

I understand the part about having a 256 bit encryption key encrypting the data, but if the key is only being protected by an 8 character password, can’t the attacker just write a program to test out passwords to get at the keys?

I see some programs claim to limit the number of password attempts or slow things down computationally, but can’t the attacker just write custom code to get around this?

Infosponge • February 21, 2008 4:32 PM

This is something that the next generation of processors or TPM chips should look at addressing. It would not be difficult or expensive to equip new CPUs or TPMs with a few KB of very volitile memory for key storage.

In the mean time, a thermite destruct charge will be good enough if you can be sure of a few seconds warning between enemy detection and enemy intrusion.

John Ridley • February 21, 2008 4:59 PM

Idea for a quick and easy product; a boot ROM that clears unused RAM areas on boot, installed in a PCI slot.

ramcap • February 21, 2008 4:59 PM

The best solution I can think of would be every memory module (or chip) has a charged capacitor which will wipe the memory when power is lost.

sooth_sayer • February 21, 2008 5:02 PM

My only comment is that for the first time MacOS is no better than windoz.

What is all that sleekness hiding .. more or less the same technology.

Andrew2 • February 21, 2008 5:22 PM

@Anonymous2:

“Forgive the basic question here, but how does a simple password protect the encryption key in the first place?

“I understand the part about having a 256 bit encryption key encrypting the data, but if the key is only being protected by an 8 character password, can’t the attacker just write a program to test out passwords to get at the keys?

“I see some programs claim to limit the number of password attempts or slow things down computationally, but can’t the attacker just write custom code to get around this?”

This is why it is important to choose a good passphrase for this sort of thing.

There are some tricks that can be used to make checking each attempted password as hard (and therefore, hopefully, time-consuming) as you like. In a nutshell, you encrypt the key with the password over and over again. The more times you encrypt it, the longer it takes to try out each option.

Buckshot • February 21, 2008 5:29 PM

Wouldn’t it be better to just encrypt a section of a large thumbdrive, have the encryption program on the drive, and unplug it and take it when you leave your computer? Would the DRAM retain any of this?

SteveJ • February 21, 2008 5:32 PM

@anonymous2:

Short answer: yes. This technique is for use against people with decent passwords.

Longer answer: people whose enemies are going to break into their data centre, chill the server RAM to the temperature of Brett Favre’s chilly bits on a chilly night, yank it out of the machine, plug it into another machine, read off the disk encryption keys and use them to decrypt the disk — probably use passwords longer than 8 characters. Otherwise, they wouldn’t have developed such high-quality enemies.

Brute-forcing an 8 alpha-numeric random password (just under 2^48 possibilities) requires on average 100 trillion attempts. This is hardly trivial, but certainly not out of the question.

An 8 character random password is pretty easy to remember, though, if you use it regularly, so the people with the aforementioned high-quality enemies should be able to remember 16 characters for their most valuable machines. 20 octillion trials (2^94) could take a while.

By comparison, distributed.net took 5 years, 1997-2002, to crack 64-bit RC5. Nearly 6 years on, they are approaching 0.5% of the way through a brute force search for a 72-bit RC5 key. That’s only worth $10000, though – your data is probably more valuable and so might attract a more powerful cracking attempt.

Still, provided that your password hashing step is at least as slow as RC5, you’re looking pretty solid against brute force with a 64-72 bit (11-12 character) random password. So if you can remember a 12 character random password, you’re sorted for the immediate future, but not against an attacker willing to wait until computers are much faster.

I don’t know much about disk encryption systems, but I do know that they only have to hash the password once, at boot time. So they can afford to make that step really slow, by good choice of algorithm. The RC5 challenges broken by distributed.net used 12-round RC5, and a client can generally do a few hundred thousand keys per second. So you could go 1000 times slower without anyone noticing, and this would multiply the time taken for a brute force attack by 1000. 5000 years is a long time to spend cracking an 11-character password…

what am I missing? • February 21, 2008 5:39 PM

If I get to a computer with an encrypted drive, and it is powered on, I can get the encryption keys by powercycling it and reading the memory with a nifty program. Ok. But, if I got to the computer while it was powered on, why would I still care? Seems like this only piggybacks on a physical security problem.

Andrew2 • February 21, 2008 5:44 PM

@dragonfrog: “which few hundred KB to wipe with your last precious power? You’d have to provide, in hardware, for every possible disk encryption system.”

I was thinking more like having the power fail trigger an NMI. Then each system with sensitive data could load a software interrupt handler to go wipe their keys.

Unfortunately, this linkage (power fail -> NMI) that I’d assumed existed isn’t in the PC hardware, so you’d need an expansion card with some voltage monitors daisy chained through the power supply connectors to trigger the NMI. And that is going to look funny enough to tip off a would-be attacker, so you need to weld your case shut too, and add thermite, and an armed guard, and a faraday cage, etc., etc., etc. 😉

Filias Cupio • February 21, 2008 6:19 PM

I doubt this attack will matter much in real life. It will normally be easier to bug the computer’s keyboard and get the pass-phrase that way.

As a countermeasure, you could store the crypto key in RAM in such a way that you have to XOR a large amount of data to obtain the crypto key. Say the dead-RAM reading technique has a 1% bad-bit rate, and you need to XOR 256 words to make your key. Taking the 256 words from dead RAM and XORing them will give pretty much no information about the key. (If the RAM has a parity bit you’re still OK so long as the number of parity errors in the 256 words is at least on the order of the length of you key. If your RAM has more sophisticated error correction, or if the dead RAM reading technique is more reliable, you’ll need to hide the key in a correspondingly larger block of data.)

The crypto routine will need to assemble the key in CPU registers. As noted by a previous poster, this could get written to RAM during a process switch. You’d need special hooks into the OS task switcher to avoid this.

Carl-Daniel Hailfinger • February 21, 2008 6:28 PM

Assuming the attacker has no way to open the case before you either power off or reboot, the attack can be mitgated with a custom firmware.

The coreboot project http://www.coreboot.org is a free (as in freedom) BIOS/EFI/firmware replacement which allows you to automatically write zeroes to all RAM on boot and poweroff (in case the poweroff is triggered by the operating system or soft power button). You are of course free to replace the zeroing routine with anything else scribbling over the memory. Booting a malicious operating system on the machine will not give you a single bit of information in that case.

Coreboot can also be used by the attacker in another machine to read out RAM chips yanked from the victim. It has the ability not to write to memory at all until the memory in question has been dumped completely. That avoids the need for specialized RAM dumping equipment.

RC • February 21, 2008 7:37 PM

It will normally be easier to bug the computer’s keyboard and get the pass-phrase that way.

Philosophically, both ways are the same. In any encryption/decryption system, the pass-phrase or key has to be in the clear at some point, being entered into the keyboard, or being in RAM. If there is a lock and a key, the key has to exist somewhere at some time, and then it can be copied.

There seems to be no way around this weakness; it is inherent to encryption/decryption itself.

F. Fox • February 21, 2008 8:08 PM

The coreboot thing may work for the “malicious reboot” variant; however, freezing the RAM would need something different.

What about the old Loop-AES driver? It has the ability to continuously invert the bits of the encryption key in RAM, thus preventing the buildup of oxides that some attacks on DRAM look for (according to Gutmann’s paper on the subject).

Just an idea…

F. Fox • February 21, 2008 8:33 PM

Scratch my earlier comment about Loop-AES; it turns out that I was thinking of the wrong principle, according to the researchers’ FAQ.

doctorkiwano • February 21, 2008 8:33 PM

i don’t know about other folks, but my disk is encrypted so that, if my laptop gets pilfered while i’m not using it, bits of sensitive information remain secure.

since the data’s already pretty much available if i’m using the computer, i don’t see much of an increased risk from people robbing me to get the key while it’s still in DRAM (why turn off the computer to capture it when you can just use the machine).

the major increased threat seems to be if i leave the machine laying around, and count on a locked screen to keep its data secure.

Glenn Maynard • February 21, 2008 9:13 PM

No magic on power-fail matters. I’ll just yank the RAM out of your computer while it’s still on. It’ll crash, but the memory I yanked out is fine.

I’d expect drive encryption to encrypt keys when you lock the console, using your user password or keys, and then decrypt them when you unlock it by typing your password again, which would help the laptop security case a lot. I don’t know if they actually do this.

Anonymous • February 21, 2008 9:43 PM

@Glenn Maynard

“No magic on power-fail matters. I’ll just yank the RAM out of your computer while it’s still on. It’ll crash, but the memory I yanked out is fine.”

While it is true you can’t ultimately secure hardware that is not in your possession, some inexpensive countermeasures are worth the trouble to do if the problem is serious enough. Switches on the latches for the memory, for example. Switches on the case. Firmware hacks in the BIOS (described above). Memory manufacturers could begin producing “SecureRAM(TM)”, with a simple capacitor-powered circuit that would zap the contents when rails disappear for whatever reason.

Russ • February 21, 2008 9:48 PM

Should pc motherboards start coming with a few meg of static ram soldered in and set aside just for encryption keys? Would static ram fair any better than Dram?

I assume Truecrypt is vulnerable too?

Shad • February 21, 2008 10:23 PM

Just solder the memory into its socket!

This way the adversary can not yank the module easily, and the time to remove the module is greatly increased and therefore limits the remanence of the data.

The obvious disadvantage/cost is that you can not replace the memory easily later. That may or may not be worth the benefit.

Integration of the memory with the motherboard makes access to it dependent on booting from the motherboard. A modified BIOS that thoroughly wipes RAM on power-on will cover that. (Prevent the BIOS ROM from being replaced or chipped, though. A layer of diamond-filled resin that will take more than several minutes to breach will do the job; the diamond will slow down eventual drilling/milling and will also conduct heat from the chip during use.)

Safes are rated in minutes to defeat. Tamper-detecting computer case with guaranteed minimum breach time (higher than useful data remanence time) for a given class of adversary may prevent many of the attacks described above.

Infosponge • February 21, 2008 10:33 PM

Glenn Maynard:

FDE tools can’t purge the keys and lock the disk when the user locks the console because that would prevent autonomous processes from accessing the disk. Stuff like swap file activity and logging continues even when the user has locked the console. FDE must take this into account. FDE doesn’t have the option to purge the keys unless the system is suspended or hibernated.

Security Is Hard.

Eric Anderson • February 22, 2008 12:06 AM

Bruce will probably want to castrate me after this, however…

Who uses these products and actually has things to hide?

a.) Criminals – Who cares?
b.) Cheaters – If you wife is smart enough to pull this off, more power to her.
c.) Corporations and Gov’ts. – This isn’t much of a problem.

Let me explain. Bruce was dead on that physical access is still key. A corporate user with crypto on their comptuer is preventing against theft, maybe corporate espionage, nothing else. Turn off your computer before you leave the office/home and the problem is solved. If someone breaks into your house/office, you’re safe.

Now consider other cases… a laptop at a coffee shop. Unless you have some really sensitive data and someone is actively targeting you for this attack, there is no fear. Your screen saver goes on, common thief steals your box, they cant find your corp secrets. They hawk the damn thing on ebay.

Before I keep rambling on different cases, the point I’m attempting to make is for 99.9% of the world, this breakthrough doesn’t affect. In most uses of crypto, you’re not concerned with someone actively stealing your dataz (although Im sure that 4,000 line program you wrote for fun is really the target for this, so be scared), you’re solely worried about general theft and data loss.

And while this entire comment board is claiming that this type of crypto is worthless now, you’re wrong. The alternative isn’t any better.

As Bruce has been preaching for awhile now, crypto is not the answer to security. People are.

Eric Anderson • February 22, 2008 12:08 AM

@Infosponge

I agree, you’re completely right, but in the case of OSX, you dont encrypt the HD, just your home folder. There really should be no reason the OS couldn’t only suspend all processes but the screen saver and essential services in “secure mode”.

Steve S. • February 22, 2008 12:34 AM

This is partially what FIPS 140-2 Level III and above are about — physical security. With a hardware based crypto solution that uses HSMs with physical security, the chassis is wired to toast the contents of key memory in the event someone tries to open the box up. Private keys are never even put in standard memory — any encryption/decryption is done by the hardware itself with private access to the keys in a physically secured container.

Techie Guy • February 22, 2008 12:58 AM

Intel announced “Danbury” technology last Sept – a hardware encryption engine in the chipset, which can not only encrypt/decrypt way faster than software solutions but also stores the unwrapped keys always inside the chipset itself, never putting them in DRAM. Doesn’t that address this issue – at least for PCs with Intel chipsets with “Danbury?”
http://softwaredispatch.intel.com/?lid=1858&t=1

Juergen • February 22, 2008 1:55 AM

@Eric: Spot on, I agree with you – for 99.999% of all stolen laptops, this attack isn’t a threat at all… while everybody is harping on how insecure encryption products are, most people miss the obvious: This kind of attack is only possible in a lab environment, against a machine that was partly disassembled before even beginning the attack. Who cares about cooling the DRAM with liquid nitrogen, when it’s not possible to actually get the liquid nitrogen to the chips in time?

Consider a real-life scenario here: Somebody working with a laptop on a train. He shuts down the laptop, puts it into the bag, puts the bag into the overhead bin, and walks off to get some coffee. As soon as he shuts down the laptop, the timer starts… the thief has got something like 5 minutes to nonchalantly walk up to the seat, grab the laptop, nonchalantly walk away, find a quiet spot in another car, remove the RAM and spray liquid nitrogen on the chips (to gain time to get out at the next train station to take them to a lab…), or hope that he was fast enough so that he has enough time left to boot his special key-stealing software.

Most laptops get stolen much longer than 5 minutes after being shut down – some of my users have had laptops stolen from the car boot, from the overhead bin on a train, or even by getting mugged – but in all those cases, enough time has passed so that the DRAM won’t contain much usable data anymore.

Clive Robinson • February 22, 2008 2:41 AM

@Ian Mason

With regard the triple post it was accidental. Ive just started using a Motorola Sidekick Slide phone and it’s web browser does not like Bruces blog software. It works fine on preview but post just throws up an error message.

The refreence to the snake is about a self modifing circular buffer that like a digital filter over writes (the mouth) its next location based on the result of a complex computation (the head) on the contents of the buffer. The in the dark point is that the buffer pointer (and in this case a couple other bits of info) are not in the DRAM but some other place such as a hardware register in the CPU or IO chip.

The hard part is finding an appropriat “one way” function for the “head” with a trapdoor so you can put the pieces back together again. For that have a look at the work of D Copperfield (of DES fame) and cellular automata used as filters.

Also think of it like the reverse of a stream generator like ARC4 or SNOW2 with a fast short cut backwards to the seed.

Hopefully this post will work.

Netko • February 22, 2008 2:44 AM

Eric, not true, 95% of people do not shutdown their laptops, they use standby or hibernation modes! Plenty of time available to attackers 🙂

Brooks Hilliard • February 22, 2008 2:54 AM

Are there whole disk encryption products that can use a fingerprint or other biometric access techniques in place of a text password/key? If this were used, would the computer still be vulnerable to this kind of cold boot attack?

The lesson here seems to be that if you have company or client confidential information on your computer with whole disk encryption, shut it off or hibernate it for at least five minutes before you leave it in your hotel room or other unattended location.

Clive Robinson • February 22, 2008 3:05 AM

@Bruce, Ian Mason

Triple post is due to the fact that the web browser in my new Motorola Sidekick Slide appears to not like the blog software. Preview works just as you would expect, post however produces an error message every time and some times the post works and sometimes not. Also the response of preview is good post always takes an age irespective of web browser or platform.

Mary Erskine • February 22, 2008 3:07 AM

I am a management consultant and I often have client confidential information on my laptop.

I frequently have to sign non-disclosure agreements before I begin assignments and could be civilly liable for failure to adequately protect that data if it were to be made public. While I doubt that I am a corporate espionage target (although one never knows), this has more than an academic interest to me.

Clive Robinson • February 22, 2008 3:34 AM

@Ian Mason

The ref to the snake is an overwriting buffer such as used in filter algorithms. The overwriting is done by a one way function (head) that has a trapdoor, the input is dependent on the majority of the buffer contents. The in the dark ref is about the pointers etc being not kept in the RAM but in CPU or IO chip registers.

The “head” function is the hard bit look at some of Don Coppersmiths (of DES fame) work on DB encryption and cellular automata.

Effectivly try to think of the system like RC4 or SNOW stream generators running continuously BUT with a fast trapdoor method of getting back to the original seed or state. The ability to go back requires atleast two bits of info the current state of the pointers and a random sesion key (whitening)

Because RAM retention is such a very hard prob to do in the 1980s AMD used to make chips with a flash erase pin that would (supposadly) clear the chip. However like hard disks and crt screens all RAM suffers from “burn in” that is the longer the state is unchanged the longer the state is remembered by the chip after powerdown etc. It is due to this you have to have all the state and other parts of the function continuously changing.

technological archaeologist • February 22, 2008 3:41 AM

If dram can be made to give up its secrets so easily then why not use something more ephemeral?

It should be technically feasible to build a tamper resistant optical delay line memory capable of storing a few of kb, and unlike our 1950s predecessors we won’t even need a 10 foot column of mercury…

greg • February 22, 2008 4:17 AM

But for this to work you need access to the target after someone else has already put in the password. And not causal access either.

key loggers represent a far weaker link IMO.

Oh this is hardly new. Bruce talks about such things in practical cryptography when discussing how to forget a secret.

greg • February 22, 2008 4:57 AM

Ok thinking this trough properly makes this even less of a problem. If you have access to the machine that has disk encryption password entered. You don’t need to crack anything. Just look at the HDD, its mounted already!

Anonymous • February 22, 2008 5:35 AM

@greg

f.e. enviroment: xlock active – leaving laptop “alone”…cypto hd mounted.

so lets get physical or how else ll u access the mounted hd data ?

/me pulls his hot glue gun

boojum • February 22, 2008 5:47 AM

Does the time data stays readable depend on the amount of time the bits have been there, “burning” themselves into RAM ?
If so, a boojum might help a little.
See Bruce for the definition 🙂

Paeniteo • February 22, 2008 5:52 AM

@greg: “But for this to work you need access to the target after someone else has already put in the password. And not causal access either.

key loggers represent a far weaker link IMO. ”

If the scenario is that the password is already entered (say, a server), what good would a keylogger be?

Alan • February 22, 2008 5:57 AM

If people use hibernate or sleep mode, or lock the keyboard, they are potentially vulnerable in other ways. Just bring the computer back up to the login prompt, and start attacking the ports looking for an unpatched vulnerability. So a computer that is not completely shut down effectively bypasses the protection of full disk encryption — even without the cold boot memory attack.

marcosdumay • February 22, 2008 6:56 AM

And this is important how? If an atacker gets your computer turned on with the disk’s key unencripted, he can gather the key. If you close this method (what will be expensive), there are still lots of alternatives.

Encripting the disk still protects against your laptop being stealed during transportation, that is the real risk here.

Anonymous Coward • February 22, 2008 10:08 AM

My problem is that “the industry” is dismissing this as an “edge condition.” Just like Microsoft dismissed the vulnerability in its RNG. To me that means its worth paying attention to.

Here is PGP’s response:
http://blog.wired.com/27bstroke6/2008/02/encryption-stil.html

This is not an “edge condition” attack! Lots of users (maybe even most) leave their machines unattended when they are screen-locked, and even transport them when they are in sleep mode or hibernated. These are all vulnerable conditions because when restored from sleep or hibernation, the machine is essentially in a “screen-locked” condition and vulnerable. A stolen laptop still represents a significant liability and companies need to stop treating stolen laptops that happen to be encrypted as “non-events.”

I’m coming around to supporting Bruce’s two level encryption proposal.

http://www.schneier.com/essay-199.html

I-CARE • February 22, 2008 10:16 AM

@Eric Anderson / “Who cares?”

I think you are dead wrong

Who uses these products and actually has things to hide?

a.) Criminals – Who cares?
Crypted data on criminals laptop can harm other people and you should care!
-> .li

c.) Corporations and Gov’ts. – This isn’t much of a problem.
-> .co.uk

…Unless you have some really sensitive data…

really sensitive is so really relative

–

i think the discovered vuln DOES MATTER A LOT and I SCREAM FOR PHY PROTECTION.

(high voltage screws f.e.)

I havent rebooted my laptop since more than 2 months – i just put it sleeping and switching it off when its “out of sight” ll cost me bunch of time or a major lack of caffaine!

I realy dont care if my laptop hardware is stolen – But I would care if someone ll be able to recover my sleeping crypted data.

gimme phy security solution or a HOTSWAP RAM i can take with me all the time ill fetch some coffee.

mchumph • February 22, 2008 10:28 AM

surely the point is these are general purpose machines, not hardened ones. in a hardened device environment power-fail detect circuitry would trigger a “red” key storage area to clear but that would be well over the top for the vast majority of users where the point of disk encryption is to allow them to leave data in a machine that’s powered off, relatively securely. maybe this story is good at reinforcing that limitation.

Hub • February 22, 2008 12:32 PM

@keyloggers

The difference is that key-loggers must be put in place beforehand. Adding a keylogger after the fact is useless.

This attack is significant, because you can mount it on ANY machine, even those without a keylogger. And you can do it at relatively low cost.

Which one is the bigger threat? Probably neither one, when compared to the self-inflicted damage that users do to themselves with Trojans of any kind.

Ronald van den Heetkamp • February 22, 2008 12:48 PM

Coldspray is a very old technique used in repairing electronics. I use it myself, while I’m repairing electronics and mainly faulty IC’s since IC’s will get hot, cooling them down results in a lower conduction that was triggered by the heat & faults like short circuit’s in the IC. It cools down to -55, sprayed on a live IC it melts very quickly and takes 1 to 2 seconds to be at the regular temperature. Just enough time to spot faulty IC’s.

Besides, I have a hard time believing it will remain for hours, sorry I don’t buy that part. 10 minutes, okay.

GSecuirtyPro • February 22, 2008 1:14 PM

Here is my response to the people who looked at the Information Security group after reading this and said should we stop encrypting….

Essentially if a thief were to acquire a laptop that was in suspend, standby, or otherwise on with a password protected screensaver they could theoretically reboot the machine use either a network or USB boot to drop the contents of the RAM and acquire the key. Alternatively they could super cool the RAM remove it from the computer and place it another computer and read the contents. The key are stored in RAM as they are used to decrypt anything that is encrypted. It really shouldn’t come as a surprise to anyone that this is possible. These guys have just refined it and produced some tools to make it simple to try. That said, it all depends on what happens in the courts (after all we are encrypting based on legislation and regulation). If someone tries to argue that encryption isn’t good enough to protect stolen data and the courts agree based on the fact that it could be theoretically cracked it could become an issue. For now I would say we are ok with it. It will be fun to see what PGP and others say as a response. Really computers should be clearing RAM on reboot and not waiting for it to happen over time.

Charles • February 22, 2008 3:02 PM

This “problem” should be easy enough to prevent. Don’t store your keys in the RAM. Next problem where to store them. I would suggest battery backed external media that wipes itself when power is lost. AKA unless it’s connected to a powered on system there’s never any data on it. This would be easy enough to put in a thumb drive. You then need to steal the external media (likely a USB drive) and the laptop at the same time and it would have to be powered on when you stole it. If some tries to take the laptop. Pull the key and and presto gonna in microseconds not milliseconds.

BTW Any company that would like use this idea may. Just give me credit for it in the footnotes unless someone thought of it before this.

Bergson • February 22, 2008 4:46 PM

How about storing the keys in the encypted drive/partition? (as soon as it is mounted/unencrypted)
Store keys in RAM at first, but as soon as drive/partition has been mounted wipe the keys from the RAM, and store the keys in the encrypted drive (or partition or file etc)
~?

cdmiller • February 22, 2008 5:30 PM

@ Eric Andersen “for 99.9% of the world, this breakthrough doesn’t affect.”

Actually most states in the US have pretty stringent disclosure laws for lost “PII data”. The costs of a disclosure program are pretty high, depending on the amount of data (staffed call centers, mailings, lawsuit settlements, etc.). Presently the full disk encryption industry is serving those customers who fear having to go through a disclosure scenario. Previously a lost laptop with personal data on it triggered disclosure procedures, now a lost laptop with personal data using full drive encryption might need to trigger disclosure… Whether the thief accesses or uses the data matters not.

moo • February 22, 2008 5:32 PM

A lot of posters here seem to be missing an important point about the keys.

The key is used all the time, constantly — every disk access to an encrypted partition requires that you have that key (somewhere) so that you can decrypt the data just read from the disk (or encrypt the data about to be written to the disk).

So it has to be stored somewhere while the computer is in use–somewhere instantly accessible (not e.g. on a different disk). In practice it needs to be stored in some kind of RAM or some kind of dedicated key-storage space from which the CPU can still load it into registers (and the difficulty of preventing those registers from then being spilled out to regular RAM on a context switch is pretty large also).

This is also the reason that it doesn’t matter if you use a 20-character passphrase or something, to protect your key. At boot time, you enter the passphrase, the key is decrypted and then it stays around somewhere in memory the whole time you use the computer. At best we can obfuscate the key somehow in memory, but we can’t really protect it in “strong” ways without physically-tamperproof key storage and software that knows how to access it safely and not allow any key data to “leak out” into the unsecured environment, where it could be captured by this kind of attack.

Hal • February 22, 2008 5:43 PM

Keep in mind that when computers are in a sleep state the RAM is still powered on and the computer is vulnerable to this attack. That would probably be the most common attack scenario, I’d guess. Alan suggests that this is already a risky state, someone could “start attacking the ports looking for an unpatched vulnerability”, but I’m not so sure this would be as easy as it sounds. The new attack seems to offer a very straightforward way to extract data from a sleeping computer with an encrypted disk. And I suspect that a substantial fraction even of travelers who are worried enough about sensitive data to use disk encryption may nevertheless feel safe when they sleep their computers. I’ve known a lot of road warriors, and sleep is widely used.

wumpus • February 22, 2008 7:29 PM

@I-CARE

The catch is that this requires the attacker to physically show up and manipulate the computer. It takes at least one agent per computer. The first time I saw this, somebody claimed to always kill power before leaving his computer (and was ridiculed for his tinfoil hat).

The catch is that almost all attackers capable of mounting an attack that obtains the unit (laptops excepted)* are also quite capable of mounting a rubber hose attack. I thought of paybacks for a Cal Tech-style prank, someone else here suggested checking a spouse’s encrypted partition (I think the prank payback most likely because the method is part of the goal, most times it is breaking the strongest link).

I’m curious to know exactly what attackers you are afraid of and why rubber hose decryption won’t be a very quick “plan B”.

  • laptops are likely to be either off or suspended (not applicable to this attack). If the laptop is running, it can be assumed to be grabbed off the lap of the victim, and the attacker can simply mount a USB drive and copy the entire disk at his leisure.

oneman • February 22, 2008 8:24 PM

Would some of you comment on the use of “key files” as used by truecrypt. Would removing the keyfiles located on a thumbdrive from the system leave the potentially vulnerable key in DRAM useless?

nbdtas • February 22, 2008 10:07 PM

interesting paper…

as far as sophisticated attackers, this introduces a damned if you do/don’t scenario. if your computer is on, it is vulnerable to this attack. if it is off, it is vulnerable to other, more trivial attacks – after messing around with the Ubuntu installer’s dm-crypt/LUKS implementation, i was surprised to discover the ease with which a LUKS passphrase could be intercepted and written to a hidden area of disk (add ~10 lines to a bourne shell script in the initrd).

this really reinforces the idea that disk encryption is only really good for protecting data in instances of theft (and of course, unsophisticated attackers).

BW • February 22, 2008 10:53 PM

Regardless of where you put the memory it will be removable, even if you solder it to the motherboard, case security can be worked around (can you say Sawzall?). An exacto-knife is all that is needed to overcome any on board capacitor or battery that would be used to wipe the chips. You could use a drill to remove an on-die capacitor. To the truly dedicated there isn’t a solution.

I’m not an electrical engineer but couldn’t the attacker just stop the CPU clock, then they would have all the time in the world to develop ways of extracting the data from the registers and on-die cache. As long as power was maintained the data would remain; you could even perform surgery on the machine.

Clive Robinson • February 23, 2008 4:21 AM

One point that has not been mentioned,

If the RAM is powered it does not need ti be removed from the PC.

Back in the (not so) old days of DIL chips you could get a clip that went ower them. This alowed Hardware ICEs to be used. These manipulated the CPU reset and IO control lines and effectivly took it out of circuit and replaced it with the ICE CPU. At this point you owned the RAM and all IO chips and could do what you liked with them.

Step forward to today CPUs are mainly Grid Array pins which makes an ICE clip not easy to affix. However how many laptops have the multi pin extender port on the back?

Alot of these have are the equivalent of a PCI connector or worse have the required control lines to out the CPU.
Likewise the laptop memory expansion is just under a little cover with a standard socket which again has the control lines required.

Now how many of you have arrived at the airport and been told to power up you laptop to prove it is not a bomb?

And how many of you have had it taken away from you in this state so it can be “checked”?

Now ask yourself just how long in seconds it would take to read out every memory location?

IS IT CLEAR NOW WHY THIS IS,

1, a very real threat
2, very easy to do
3,a very difficult technical problem to solve
4, A real difficult user training issue.

Any questions?

Back ground reading Ross J Andersons book, Bruces and Nieles Furgussons books and the colective papers of Peter Gutman.

Hopefully I have spelt their names correctly and if I was not away I would have posted the links can somebody else oblige?

Scott Carpenter • February 23, 2008 7:53 AM

But why would anyone ever remove a RAM chip from a running computer? All of the documentation says to never do this. 🙂

cdmiller (and others who alluded to similar): excellent point about disclosure considerations.

Clive Robinson • February 24, 2008 3:38 AM

@ Scott Carpenter,

“But why would anyone ever remove a RAM chip from a running computer? All of the documentation says to never do this.”

Why would a auto thief smash the window of your car?

The answer is the same in both cases, even though it’s against the manufactures warrenty the thief wants to steal something that is contained within, that they cannot as easily any other way get at.

In the case of the auto thief it’s the car contents / house keys (you’ve left inside) they want, (so they might go on to burgle your house).

In the case of the Data thief it is information in the memory such as the keys to your hard disk (where you “house” your private data), so they can go on to steal from that.

The real reason the manufacture says don’t pull stuff out is two fold,

The first is that unless you are carefull you can damage the chip by leaving the power and data lines connected but not the ground connection. Although as a R&D design engineer of amongst other things Com/Sec equipment I haven’t managed to do this yet. And for the past 30 years I’ve been pulling chips faster than an 1800s midwest dentist.

The second is that it has an undesirable effect on the computer and the rest of the data storage in it such as the Hard Disk etc. Imagine you are driving fast down a crowded shopping street and you sudenly lose all memory of how to drive / see / speak / control your bodily functions. Basicaly you are going to be in a mess one way or another, and so might a lot of other people.

Scott Carpenter • February 24, 2008 7:27 AM

Thanks, Clive — that part was tongue and cheek. 😉

Your previous post gave me some food for thought. I mostly use encfs for disk encryption, which I load manually after starting the computer. On my rarely used laptop, I had at one time been using the same password for logon and encfs. In your airport scenario, maybe I don’t want to let them walk away with the laptop in that case.

Although I have no idea if the logon password is floating around in memory or otherwise exploitable after the fact. And I don’t know if there would be pressure to divulge the logon password, but I might not mind giving it up if it couldn’t be used for much.

And, not that I would have anything particularly interesting on this laptop, but it’s none of their business.

Clive Robinson • February 24, 2008 8:48 AM

@ Scott,

Yup I missed the 😉 I have been away from a desktop computer using a Motorola Sidekick Slide Phone for the past few days. Lets just say my eyes are not what they once used to be some 40(hurmp) years ago and a tiny screen does not improve things in the slightest (now what did I do with that 100″ LCD pannel 8)

With regard to the passwords even if they have not been “explicitly” stored by the software they are probably in a “buffer” somewhere either in kernal or user space memory. And being mainly single user MS OSs tend to create buffers and not clean them up.

And as any forensic bod will tell you the one thing that MS OSs are realy good at is writing blocks of memory to the HD via the swap space and slack space from buffers etc (even when they don’t need to). It’s one of the main reasons users complain computers are noise, not from fan noise but from the OS using the Hard Drive for swap etc.

If you are feeling bored one day DD your swap partition from an MS machine to a Linux box and go searching on things like your name credit card passwords and other stuff you use on a daily basis (but might not want others to know).

The chances are the results will give you cause to think hard about what you do on your computer, and who you let have access to it.

Mind you, you could end up overdo things 8)

I still “type” things on a manual typerwriter from time to time, “it sure ain’t pretty” but it can be quicker that turning on a PC. Also when it comes to very confidential info it makes controling the information a lot lot easier (and old habits do die very hard or not at all).

I also have a Knoppix box with no HD that I tend to use for web browsing and such like. I made it almost as a joke after I was asked by a friend to recomend a “Safe Web Surfing PC” for their children. It’s made from an old Pentium box that the hard disk died in and was chucked from work (I also use it totaly diskless with my “SafeServ”).

If you have read some of my previous posts to Bruce’s blog you might have also noticed that just for fun and curiosity I actually built a PXE/ headless terminal/app server and UPS into a small table top safe (old Hotel type) as a project one weekend. It all started with the name “SafeServ” after chatting over a few beers one friday night with someone about the Knoppix disskless client. Saddly I have not yet managed to get the RAID array to work in it, (it generates just a little bit to much extra heat to be reliable and I realy don’t want to start bending heat pipes).

Even though done for fun the work behind both the diskless client and headless server has subsiquently gone on to be used by a school to re-use old hardware for their under 12’s.

PerpetualYnquisitive • February 24, 2008 2:07 PM

Would it be possible to have the encryption keys stored in a video card’s ram instead of the main system ram to defeat this type of attack against the encryption keys stored in the system ram?

As to defeating brute force attacks, would it be possible to have password entry attempts tied directly to a time ratio written into the code of the encryption software, something like 6 attempts per minute maximum regardless of input method.

If a system like this could be implemented than an attacker would only be able to try 8,640 (66024) different passwords in a 24 hour period.

markm • February 24, 2008 3:38 PM

“You build your key dynamicaly into a CPU register imediatly prior to use. The key its self is either never stored in RAM”

But that leaves the software to build the key in RAM. It’s a little harder to find the starting point for that code, but not impossible.

Sometimes a little physical security is necessary.

Doug Coulter • February 24, 2008 8:27 PM

@russ
Yes, static ram is a good answer, and I bemoan the lack of any (outside the cpu) on modern ..errm, inexpensive boards. This of course doesn’t address attacks that could simply look while power is up — it’s pretty well proven that if someone else can have their way with your physical hardware, they can do whatever they want to do badly enough.

As a DSP embedded system designer, I’ve often had to use static ram to avoid the truly horrible latency delays of dram when accessing memory out of order (often required, just try doing an FFT in linear order of access). Static ram doesn’t come up all zeros or ones, but generally comes up with (nearly) the same pattern each time, due to one side of each (sort of) flip flop being a little faster than the other, pretty reliably. In a given system, you can almost count on the static ram content being the same on each power up cycle, with blocks of all 1’s and zeros tending to be in the same places every time. Anything stored last time power was up…gone. I may have seen almost one exception to this in perhaps the entire history of solid state memory (shows my age, started out with core and vacuum tubes).

The error rate of this predictability is low enough (but not zero) that many flaws in embedded software due to not initializing completely often go unnoticed for quite awhile. You learn all this kind of thing when trying to go well past 5 or so 9’s. Or you aren’t successful at it.

Paeniteo • February 25, 2008 6:22 AM

@PerpetualYnquisitive :

Would it be possible to have the encryption keys
stored in a video card’s ram instead of the main system ram

Up to this point, in principle, yes.

to defeat this type of attack against the encryption keys stored in
the system ram?

No.
The reason is pretty simple: It must be possible to extract the key from there to use it. Therefore, an attacker can extract it as well.

As to defeating brute force attacks, would it be possible to have password
entry attempts tied directly to a time ratio written into the code of the
encryption software,

What good would this do? If the encryption software is open source, an attacker can simply remove the artificial delays and re-compile his own version. If it is closed, the decryption algorithm could be re-implemented anyway without artificial limitations.

There are approaches to make deriving an encryption key from a password time-consuming in order to frustrate dictionary searches.
Say, do not use SHA-256(password) to obtain the key, but repeat the hashing a few thousand times and use the final output.
Note how this limits brute-forcing by increasing the complexity of the operations instead of introducing artificial limits.

Clive Robinson • February 25, 2008 11:38 AM

@markm,

“But that leaves the software…”

Yes and its not a lot of good to you. As I said you need another piece of information to build the key which in a fast evolving crypto pool would be the pointers and the whitening. This is stored else where such as a CPU register or IO chip which is not available to the memory bus etc.

With regard hardware yup been there still do it. And guess what a Maxim Engineering Journal landed on my desk today with an artical about their DS3600 family of chips designed for exactly this problem the artical is by Swati Joshi and its called “addressing physical security of encryption keys”. Maxims website is http://www.maxim-ic.com

matc • February 25, 2008 3:37 PM

Well, when you quit your computer, you should turn it in something like supend to disk mode on a encrypted swap partition (the RAM is cleared because it is not powered, but you could do manual clear).

After all the attack is possible only when you are not using your computer.

JimH • February 25, 2008 5:40 PM

Once again the world of computer security splits along cost (of security) vs. value (of secured goods). If you are using an off-the-shelf machine, your level of security is only so good. If you have gone to the trouble to buy (or build) a custom-secured machine, you are better off, but now there is the chance that your DRAM will be popped out and used in a totally different (malicious) machine. And chances are your disk encryption key is sitting in DRAM because you either purchased (or built) software that ASSUMED if the power was cut or the DRAM popped, everything instantly disappeared. …Unless you are one of the 10 people that knew about this vulnerability 20 years ago… (thx, btw).
So now the cost has been raised and the answer is simply, any on-board keys that are stored in the clear cannot be stored on the $50 DRAMs that pop out for easy upgrade. The custom-built system now needs a tamper-proof storage area for those keys that does not pop out like a SIMM, and new software to control the new hardware. This new design would offer new potential vulnerabilities, etc…
Eventually, we will all be able to afford this new system (just like we all are buying HD TVs) but there will be a cost/availability curve (complete with new vulnerabilities and another phase, and then another). Looks like it’ll be good for business.

tetrisplayer • February 26, 2008 3:47 AM

The hard disk encryption needs to remove / encrypt the keys from RAM when the user locks the PC.

The main threat that is relevant to real life is a laptop that is powered on and stolen. If it is unlocked the encryption is irrelevant. If it is powered off [for a few minutes] the encryption works fine. If it is on, and locked then it is currently vulnerable but the fix is for the software to encrypt the keys while the user locks / suspend / etc the PC.

Eric made this point but it seems to have been missed:

I’d expect drive encryption to encrypt keys when you lock the console, using your user password or keys, and then decrypt them when you unlock it by typing your password again, which would help the laptop security case a lot. I don’t know if they actually do this.

PhilY • February 26, 2008 3:49 AM

The hard disk encryption needs to remove / encrypt the keys from RAM when the user locks the PC.

The main threat that is relevant to real life is a laptop that is powered on and stolen. If it is unlocked the encryption is irrelevant. If it is powered off [for a few minutes] the encryption works fine. If it is on, and locked then it is currently vulnerable but the fix is for the software to encrypt the keys while the user locks / suspend / etc the PC.

Eric made this point but it seems to have been missed:

I’d expect drive encryption to encrypt keys when you lock the console, using your user password or keys, and then decrypt them when you unlock it by typing your password again, which would help the laptop security case a lot. I don’t know if they actually do this.

Phil Y • February 26, 2008 3:52 AM

The hard disk encryption needs to remove / encrypt the keys from RAM when the user locks the PC.

The main threat that is relevant to real life is a laptop that is powered on and stolen. If it is unlocked the encryption is irrelevant. If it is powered off [for a few minutes] the encryption works fine. If it is on, and locked then it is currently vulnerable but the fix is for the software to encrypt the keys while the user locks / suspend / etc the PC.

Eric made this point but it seems to have been missed:

“I’d expect drive encryption to encrypt keys when you lock the console, using your user password or keys, and then decrypt them when you unlock it by typing your password again, which would help the laptop security case a lot. I don’t know if they actually do this.”

Clive Robinson • February 26, 2008 5:07 PM

@JimH

It is a lot more than 10 people who knew about it.

As I said there is actualy two problems not one…

The first is the ordinary random data hold, this tends to be quite short in reality (just a few seconds on average)

The second is data “burn in” if any RAM chip (static or dynamic) holds the same value for an apriciable time then the semiconductor actualy becoms damaged and develops a detectable bias to the data value when compared to random data storage cells. This burn in can be effectivly permanant and always readable even days or weeks after the chip was powered down.

This is why it is important that the key bits are always being changed to aparantly random values.

Most old school hardware design bods (ie +50yrs) are well aware of this problem.

There are solutions they are reasonably efficient to implement but they most definatly are not obvious.

Ultimatly though you do have to store a secret somewhere and the only (semi) safe place is in a CPU register that does not get flushed on a stack or task swap op.

2fewsecrets • February 27, 2008 11:58 AM

Clive@ 02 24 3:38, About the hard drive being not ‘hot swapable.’ Works on some laptops/OS!
OpenBSD 4.1 and earlier, but not later, like 4.2, you could pull the drive out while computer in on! Done many times, even left in this state for 14 hours, all good when put back in! Used sync on all partitions. Does not work on 4.2, although I haven’t tried to hack it up. This works on a IDE laptop, and not just one type! Tried 3 laptops, all worked! Who would have thunked it? Sleep/hibernation, other little problem, I’ve seen little differences when system comes back up. Not all systems come back perfectly sometimes. Seen with OpenBSD on some laptops. Best way, have system boot/shutdown fast, and handle fsck/etc issues with proper design/compromises. Sleep is a nice feature though…
Tried pulling ram, GRR, doesn’t work, what else would you expect on a typical laptop?
Nice thing about OpenBSD, sure runs on little memory, like any BSD or some CLI linux, and you can replace/cycle out cheap memory if you are PARANOID about any burn in issues.
Real story is, get custom/expert computer help if you have reasons to be PARANOID.

I liked the idea of solder in the RAM, cover it, for cheap returns, although ways to hit that. Helps against your 12 year old sister attacks, at least until she is 16…

Samh • February 27, 2008 6:57 PM

Journaling used to leave FileVault contents in the clear, as did Spotlight. You never know where a good side-channel may turn up.

GregTo • February 28, 2008 12:41 AM

I’ve custom-edited my BIOS to have a default boot password (so even if the battery is removed and the CMOS reset, the password is still there). If I epoxy the BIOS chip to the motherboard, and then epoxy the memory to the motherboard, how would that fare?

2fewsecrets • February 28, 2008 3:48 AM

GregTo: Ask Electrical Eng, Not Me. But, for kids, helps with memory. Epoxy? GRR, unsure about electrical properties. Superglue might be ok. As to the custom BIOS, if you are that good of a programmer, or trust whoever, then perhaps thats good, but ?s remain. Bios implementations and permissions, administrator password or user password, are both in BIOS? JFYI, I have hacked Dell laptops to go through the BIOS password, on two different laptops. Even an idiot or kid could get it after some time. That bad. Tempest attacks should be considered with memory on computer, power on laptop, must be ways to put JTAG in board and whatever. Sure are some easy, cheap ways to help out some, for those airport start me up concerns…But what can you do, if they want your laptop, they get it. Unless you employ data issue handling, ie, data rememberance, your effectively just playing legal games with what % the data really is what in court… FFS, UFS1, in OpenBSD, non-journaling = critical for crypto issues.
Computer security really sucks as a field, you never have it, and customers want it as simple and pure as a light bulb. GRR. Old rule, if you do not control physical security, its not your computer/data anymore, unless you have access to NSA very special hardware. However, FGPA might be arguable and possible in some ways to have some more security…
I wish more was listed here about freaky memory games and crypto…

Paeniteo • February 28, 2008 6:46 AM

@GregTo: “I’ve custom-edited my BIOS”

One would simply yank out your system’s RAM and put it into another system.

GregTo • February 28, 2008 9:13 AM

@2fewsecrets,
I suppose I would want to check on the properties of a glue before applying it. I threw epoxy out there just as an idea as to where I was heading.

@Paeniteo,
I’m also talking about securing/affixing my memory to the motherboard (see above).

Bill • April 2, 2008 3:29 AM

This is anectodal evidence in support two hypothesis:
1. The law of unexpected consequences
2. There is no security without physical security

Workaround:
Embed memory within an thermal insulator? This could be defeated by removing the insulator in a cold environment, but if done well could dramatically increases the cost to the attacker.

Patrik Koppanen • April 17, 2008 8:02 AM

I would suggest you check out the hardward based Fulkl Disk Encryption (FDE), where the encryption sits in the hard drive itself rather than installed ontop of the OS. Dell, Seagate and Wave Systems have a great solution where Seagate Momentus FDE.2 drive is controlled by Wave Trusted Drive software. For large installs the Embassy Remote Access Server (ERAS) will control and protect the seagate drives from a centralised position.

Enc • May 8, 2008 7:30 PM

In case of File Vault, why no just log off before putting the computer to sleep?

John Roberts • May 26, 2008 3:02 PM

Criminal? To the person who said such considerations are used by “criminals” and “who cares?” – please consider exactly what a criminal is.

A criminal is someone who commits or tries to commit a “crime” which is an action or conspiring to action in contravention of “laws”.

Now we need to ask – what are laws? Laws are directives or rules forced upon the “people” by those who are supposed to “represent” them. When was the last time any law was made involving any inkling of your representation?

What we have with encryption is parallel to the 2nd amendment which states that because an Army is necessary to protect the state therefore the people should be able to have armaments to protect themselves against that Army should it fall into a condition where it is no longer “well regulated”.

No wonder encryption was/is classified as “munitions”. So now you cannot even have a private discussion about self defense. This way the Guv-Mint kills two freedoms at the same time – 1st & 2nd.

Dude • March 12, 2009 4:02 PM

These attacks are old news and just bring us back to the starting point of any serious discussion on security.

1) Don’t allow physical access to the machine.

2) Power down when not in use. AKA don’t use hibernate or suspend.

Problem solved.

adam smith • March 29, 2009 9:50 PM

The whole time I’m reading these articles online I’m thinking “Can’t you just power down completely and avoid the problem?” The last guy suggested that as well.

But let’s say you’re not encrypting media files, I mean there’s not much point in that since it takes so long and who encrypts their mp3s or movies anyway? Let’s say it’s sensitive data. How about you encrypt it on your machine then upload it to an online server or 5 just to be sure. Make it more fun and use a program to hide your ip address while you upload your data. Then do a clean install if necessary, if not, just wipe your ram a few times. Problem solved, right?

Is it possible to use a USB drive that reads/writes to itself to run the encryption program like using portable apps thereby saving the key to the flash drive yet still being able to copy the contents that are encrypted to the internal hard drive and using the flash drive to unlock it?

What about a biometric key? Would that work?

Stephen • November 21, 2014 9:56 AM

@ adam smith:

Uploading data to online storage makes it more accessible than keeping it on your computer, that would be a bad move for encrypted files. If you want to keep the sensitive files safe you would be better off keeping them on a USB drive that you keep with you at all times (or if you fear that it will be taken from you by force you can hide it somewhere nobody would think to look). Here is why you can never assume enough anonymity to keep data safe when transmitting data online:

You can hide your IP address behind a router but can not hide it completely since the router would need to use a public IP address and IP_ addresses are needed to communicate with a network. ISPs record the IP addresses you use and your internet activity which they earn an average of $5 per customer per month (not including deals under the table) in selling to third parties so acquiring information on who did what online is easy if you have enough money.

You can use an anonymous proxy server or a virtual private network to anonymize internet activity but chances are most public proxy servers are not as private as they appear to be (many are required to allow authorities to monitor data going through them and there are deals under the table to allow direct access) while if somebody were to set up a virtual private network that can easily be traced by following the data sent to and received from the computers in the virtual private networks, this will only temporarily delay monitoring of your network activities. At best this will only thwart people who are not personally interested in you. Even if data is sent to and received by a proxy server or virtual private network is encrypted at some point the data will have to be decrypted in order to communicate with other computers and devices on the internet and having copies of the data in both encrypted and decrypted forms may be adequate information to crack the data encryption in the first place.

If you were to go to a different location and tap into somebody else’s router you will be able to thwart most attempts at monitoring your network activity. However, for a determined attacker with adequate resources to monitor multiple internet connections your computer’s MAC address is included in packets sent across a network so your computer can be identified on any network with the right software and unless you are using a browser extension to change your browser header and hide your browser fingerprint the web browser you use to connect to the internet can be used to help in identifying your computer.

As for wiping and doing a clean install, since hard drives remap weak sectors and flash drives perform wear leveling which both redirect write attempts you can not be sure that your data is fully wiped without physically destroying the drive.

Using a biometric key can be a good way to thwart unauthorized access by most people. However, that can be fooled by people who already have a record of your biometrics.

Unless you wear gloves constantly all somebody has to do to obtain them is follow you around for awhile and the moment you touch a smooth surface and leave the room can use items that can be purchased in a store to recreate your fingerprint and use it, here is one method: http://www.instructables.com/id/How-To-Fool-a-Fingerprint-Security-System-As-Easy-/

An iris scan would also not be too difficult to fool using contact lenses embossed with the images of your irises: http://www.wired.com/2012/07/reverse-engineering-iris-scans/ The technology to scan your iris from a distance also exists so people who are determined enough and have the resources can do so. Of course, the most feasible solution to counteracting a nonceonsentual iris scan at a distance is to wear contact lenses embossed with the images of somebody else’s irises when not having your iris scanned. A low budget alternative is to wear mirrored sunglasses when outside your house or when the window is open.

Retina scans require the scanner to be close to the person’s eyes and reproduction of a retina is not easy to accomplish. The only way to get a copy of your retina scan without your knowledge is to hack into a system that has your scan results on file in the first place. As such, a retina scanner is the best option for computer security.

As for running encryption software on a USB device, I am no expert but believe that is probable, as precautions just make sure you disable the swap space (or virtual memory, depending on the operating system) to prevent data from being recorded to the hard drive first, keep sensitive data off the hard drive and use 2 USB devices for maximum security: 1 to store the sensitive data temporarily and 1 to store the encrypted sensitive data. Naturally, if you are extremely paranoid destroying and replacing the device storing the unencrypted data temporarily might be a good idea. Then you can keep the decryption keys and written on a piece of paper that never leaves your wallet or if you are extremely paranoid get a keychain ornament you can hide a piece of paper in. I suggest these precautions because deleting data off a hard drive is not a guarantee especially if you have data you want to keep on it and wear leveling on a USB flash drive may thwart attempts to delete data on it.

Patrik: While connected to a network disk encryption is useless since the moment your computer has decryptd the disk for access it is visible to anybody who has already hacked your computer. Storing the files individually under separate encryption keys is safer because it requires people hacking your computer to actually try to decrypt the files.

rye • September 26, 2017 3:35 AM

@bootman

Store your keys at 0x7C00. That’s where the bios bootloader will put the first sector of the first bootable device.

Let’s assume that the memory is soldered in or otherwise incapable of being moved to another system, and that all DIMM slots are taken so no new memory can be inserted. With those assumptions in place, I have a few things I’d like to add.

The BIOS will clobber a lot more than just 0x7C00. The IVT is put from 0x0000 to 0x03FF, and the BDA is put in 0x0400 to 0x04FF. At least some of that isn’t overwritten, because the system can write a magic two byte value to 0x472 which the BIOS reads after a reboot to decide whether or not to re-initialize hardware and do another POST test, or just assume hardware is functional (since the system was rebooted and isn’t coming up from a cold state). However the IVT is almost certainly overwritten, given that it’s the BIOS equivalent of the IDT that most operating systems use. Messing with anything in the first 0x1000 may result in Very Bad Things(tm) happening if you attempt to go back into real mode, but most modern systems will never have a reason to do that. As only x86_64 is supported, there’s no risk of the system using VM86.

Another thing you could do is put a 32 byte encryption key at 0x041E in the BDA, which is the keyboard buffer. Even if you switch back into real mode, all the important bits are left intact, and it’s not like you’re gonna be using the BIOS keyboard buffer after you boot anyway. You could also put the data anywhere between 0x0500 and 0x7BFF, which is guaranteed (supposedly) to be untouched by the BIOS at runtime and usable as scratch space. I don’t know if the BIOS wipes this (or the first page at least) no matter what, or if it doesn’t touch this anyway, causing the key to be preserved across reboots.

In at least one case I know of, a cold boot attack was performed in the wild against a server. The investigators did not want to remove the memory as there would be the risk of data loss, but they didn’t want to clobber many megabytes by booting into a live Linux system. Their solution was to write a custom BIOS, based on Coreboot, which would overwrite only a few kilobytes and would dump the rest of the memory over serial. A sufficiently advanced attacker could likely write a custom BIOS which runs entirely in CAR (Cache-As-RAM) mode, and initialize memory and dump it without ever writing to it. It’d be a lot easier to simply not write the bootsector to 0x7C00 than it would be to do everything in CAR mode. I’d wager that very few people can do that, and the ones that can likely have a big enough budget that they’d just do a JTAG attack.

I vaguely recall reading about a theoretical mitigation from some research paper which suggested putting the key in the first page (0x0000 to 0x0FFF). My BIOS at least marks that memory as reserved via e820, so that should be kept in mind as reading from e820 reserved memory is undefined. So just for the fun of it, I decided to patch TRESOR (a cold-boot prevention patch for the Linux kernel which stores encryption keys in x86 debug registers, instead of RAM) so that it generates a random 32 byte value and stores it at 0x0000. This value is XORed with the original key, and the result is stored in the debug registers, rather than the original key itself. In order to get the original key back so the crypto routines work, the contents of the debug registers are XORed again with the value in the first page. This way, both the first page, and the debug registers are needed in order to calculate the original key. I also store a CRC of this value at 0x0020, and the value is checked against the CRC at each use so any corruption caused by the firmware will be detected. It requires SSE4.2 because it uses Intel’s crc32 instruction.

This is the main change I made to tresor_asm.S, making read_key verify the CRC of the first 32 bytes of memory. The tresor_set_key function is roughly the same in reverse, but generating the CRC rather than verifying it.

.macro read_key r0 r1 rounds
    pushq   %rbp
    
    /* set rbp to __va(0) */
    movq    $__PAGE_OFFSET,%rbp
    
    /* verify the crc32c of 0x00 - 0x1f */
    xorq    %rdx,%rdx
    crc32q  0(%rbp),%rdx
    crc32q  8(%rbp),%rdx
    crc32q  16(%rbp),%rdx
    crc32q  24(%rbp),%rdx
    movl    32(%rbp),%eax
    cmp     %edx,%eax
    je      get_key
    
    /* BUG() */
    ud2
    
    get_key:
    /* if key >= 128, save rbp ^ db0 and rbp + 8 ^ db1 */
    movq    db0,%rax
    xorq    0(%rbp),%rax
    movq    %rax,\r0
    movq    db1,%rax
    xorq    8(%rbp),%rax
    movq    %rax,rhelp
    shufps  $0x44,rhelp,\r0
    
    /* if key >= 192, save rbp + 16 ^ db2 */
    .if (\rounds > 10)
    movq    db2,%rax
    xorq    16(%rbp),%rax
    movq    %rax,\r1
    .endif
    
    /* if key == 256, save rbp + 24 ^ db3 */
    .if (\rounds > 12)
    movq    db3,%rax
    xorq    24(%rbp),%rax
    movq    %rax,rhelp
    shufps  $0x44,rhelp,\r1
    .endif
    
    /* clear rax, as it contained key material */
    xorq    %rax,%rax
    popq    %rbp
.endm

And this is the main change made to tresor_glue.c, wiping the first 1280 bytes of the first page and writing a 32 byte random value to it when a key is about to be set:

void tresor_setkey(cont u8 *in_key)
{
    get_random_bytes(__va(0), 32);
    on_each_cpu(tresor_setkey_current_cpu, (void *)in_key, 1);
}
    
static int __init tresor_init(void)
{
    memzero_explicit(__va(0), 0x500);
    return tresor_init_sysfs();
}

Those are the changes that are really relevant. There are also little things like checking for SSE4.2 support instead of just AES-NI, and clearing 0x0000 to 0x04FF and the debug registers upon a kernel panic. I’m still working on it and plan to find a way to get it to support TRESOR in KVM guests (which isn’t as simple as encrypting/decrypting vcpu->arch.db[dr] in arch/x86/kvm/x86.c:__kvm_set_dr() and kvm_get_dr(), unfortunately), support for more block modes (currently only ECB and plain CBC are safe, as others like CBC-ESSIV and XTS require calling the cipher with an additional key for each sector to encrypt, respectively, the sector number and the tweak, an action not supported by TRESOR), support for multiple keys (perhaps utilizing the same technique as loop-amensia? I haven’t studied it yet), and support for safely adding keys via the standard crypto API instead of writing to a file in sysfs.

Of course, waiting for AMD’s memory encryption would be a lot better!

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.