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.

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

Comments

bootmanFebruary 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.

AJFebruary 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 ClemansFebruary 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 BrowningFebruary 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..

AnonymousFebruary 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 RobinsonFebruary 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 WeaverFebruary 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 RobinsonFebruary 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 WeaverFebruary 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.

AnonymousFebruary 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!

asdfoiuyFebruary 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 AuricchioFebruary 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 ProgrammerFebruary 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 GrazianiFebruary 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...

Andrew2February 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 GrazianiFebruary 21, 2008 3:35 PM

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

AlanFebruary 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 MasonFebruary 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!

GergFebruary 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.

GergFebruary 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.

dragonfrogFebruary 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

RichFebruary 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 JanssonFebruary 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. :-P

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...

Andrew2February 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.

Anonymous2February 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?

InfospongeFebruary 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 RidleyFebruary 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.

ramcapFebruary 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_sayerFebruary 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.

Andrew2February 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.

BuckshotFebruary 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?

SteveJFebruary 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.

Andrew2February 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 CupioFebruary 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 HailfingerFebruary 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.

Jacob AppelbaumFebruary 21, 2008 7:13 PM

Actually, we considered using linux bios for our attacks. Transplanting memory into a machine with coreboot (aka linuxbios) sounds like a nice way to go.

RCFebruary 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. FoxFebruary 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. FoxFebruary 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.

doctorkiwanoFebruary 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 MaynardFebruary 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.

AnonymousFebruary 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.

RussFebruary 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?

ShadFebruary 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.

InfospongeFebruary 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 AndersonFebruary 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 AndersonFebruary 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 GuyFebruary 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

JuergenFebruary 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 RobinsonFebruary 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.

NetkoFebruary 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 HilliardFebruary 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 RobinsonFebruary 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 ErskineFebruary 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 RobinsonFebruary 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 archaeologistFebruary 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...

gregFebruary 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.

Ian MasonFebruary 22, 2008 4:24 AM

@Clive

I thought you'd get the joke. Google "benzene dream Keule" for an explanation.

gregFebruary 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!

AnonymousFebruary 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


boojumFebruary 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 :)

PaeniteoFebruary 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?

AlanFebruary 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.

marcosdumayFebruary 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 CowardFebruary 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/...

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-CAREFebruary 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.

mchumphFebruary 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.

HubFebruary 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 HeetkampFebruary 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.

GSecuirtyProFebruary 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.

CharlesFebruary 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.

BergsonFebruary 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)
~?

cdmillerFebruary 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.

mooFebruary 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.

HalFebruary 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.

wumpusFebruary 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.

onemanFebruary 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?

nbdtasFebruary 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).

BWFebruary 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 RobinsonFebruary 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 CarpenterFebruary 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 RobinsonFebruary 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 CarpenterFebruary 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 RobinsonFebruary 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.

PerpetualYnquisitiveFebruary 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 (6*60*24) different passwords in a 24 hour period.

markmFebruary 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 CoulterFebruary 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.

PaeniteoFebruary 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 RobinsonFebruary 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 www.maxim-ic.com

matcFebruary 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.

JimHFebruary 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.

tetrisplayerFebruary 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.

PhilYFebruary 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 YFebruary 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 RobinsonFebruary 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.

2fewsecretsFebruary 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...

SamhFebruary 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.

GregToFebruary 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?

2fewsecretsFebruary 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...

PaeniteoFebruary 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.

GregToFebruary 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).

BillApril 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 KoppanenApril 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.

EncMay 8, 2008 7:30 PM

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

John RobertsMay 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.

DudeMarch 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 smithMarch 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?

Leave a comment

Allowed HTML: <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre>

Photo of Bruce Schneier by Per Ervland.

Schneier on Security is a personal website. Opinions expressed are not necessarily those of Co3 Systems, Inc..