Cold Reboot Attacks on Disk Encryption

jcrouthamel writes "Contrary to popular assumption, DRAMs used in most modern computers retain their contents for seconds to minutes after power is lost, even at operating temperatures and even if removed from a motherboard. Although DRAMs become less reliable when they are not refreshed, they are not immediately erased, and their contents persist sufficiently for malicious (or forensic) acquisition of usable full-system memory images. We show that this phenomenon limits the ability of an operating system to protect cryptographic key material from an attacker with physical access. We use cold reboots to mount attacks on popular disk encryption systems — BitLocker, FileVault, dm-crypt, and TrueCrypt — using no special devices or materials. We experimentally characterize the extent and predictability of memory remanence and report that remanence times can be increased dramatically with simple techniques. We offer new algorithms for finding cryptographic keys in memory images and for correcting errors caused by bit decay. Though we discuss several strategies for partially mitigating these risks, we know of no simple remedy that would eliminate them."

Clear the DRAM?

[the4thdimension]

Could probably implement an algorithm at the operating system level that attempts to clear out DRAM except for what is actually needed for the operating system to power down/boot up. I am not sure of the exact logistics but it seems silly to just power down and leave the DRAM however it was, no matter if its instant cleared or take a few minutes.

Re:Clear the DRAM?

[KublaiKhan]

It is possible; I remember reading about a class of programs in the Jargon File that exploited certain machine code instructions to clear out the whole of the machine's memory, including itself.

Can't remember the name of 'em, though.

Re:Clear the DRAM?

[compro01]

death code [catb.org]

Re:Clear the DRAM?

[KublaiKhan]

-You- may practice proper procedure, but some contractor/low level drone/mindless bureaucrat might leave his system on screensaver (or just lock the console) when turning his back for a moment, which would allow for someone to snatch the laptop and run.

And while your program may indeed wipe the drive after 10 incorrect guesses, there's one very significant weakness to that proposition: the program must be -running- in order to do so.

So, in this case, the method of attack would be as follows: find someone with a laptop full of information who has it activated in an accessible location. Grab said laptop and remove it to a location where the RAM can be accessed per this hack. Then, after grabbing the key, remove the hard drive, hook it to a system you have control over, and either use the key to open the drive or, if the key is corrupted or incomplete, use the key as input to crack the drive conventionally--bearing in mind that if it is mounted in such a way that your fancy program does not activate, the program cannot erase the drive.

Re:Clear the DRAM?

[SL Baur]

For this to work, somebody has to be able to steal my laptop

You didn't even bother to read the summary, let alone the article. The main point is that nothing is secure with physical access to the machine. That's kind of always been the point. Restated, if an attacker is sufficiently interested in the data on your machine, he will be able to take it from your cold dead hands and get it.

I feel secure.

So no, you shouldn't feel secure if you have important data on that machine.

BTW, since you claim to be using (presumably US) government security software, you know that disk formatting or dd if=/dev/zero of=/dev/whatever is not sufficient to unclassify a disk that formerly contained classified material.

Re:

[ScrewMaster]

So no, you shouldn't feel secure if you have important data on that machine.

And any way you slice it, feeling secure has little to do with being secure (TSA, are you listening?) although I have noticed that people who feel secure are generally at the most risk. Mainly, I suppose, because they don't have the knowledge to properly assess the risks they are accepting. Because if they did ... they wouldn't feel so secure.

If you want to be as secure as you possibly can, start with the assumption that you'r

Re:Clear the DRAM?

[spun]

So, that would stop me from physically turning off the computer and popping out the RAM, how exactly? What we need is a battery backed up hardware module that scrambles the RAM when the system loses power.

Use capacitors

[StCredZero]

You could use a capacitor to power this mechanism instead of a battery. It wouldn't need to last very long -- just long enough to scramble the RAM on power-down. It would be more reliable than a battery.

Re:

[Amouth]

unless the battery is made by Sony - cause last time i checked PCB was flamable - and am confident that you could set it to catch fire on power loss the memory would be useless..

although that would be a brain dead setup to have... i could so see manufactures labeling it a "feature"

Re:

[AchiIIe]

I agree that the capacitor is the way to go. As a reminder, all harddrives are fitted with an emergency capacitor. If the hard drive looses power while the head is traveling there's a risk for a head crash. Thus, once power is lost, the capacitor will fire up the motor for one last push toward the parking space. if you have an external hard drive listen for the click that happens right after you pull the power.

Re:

[tweak13]

I heard that mechanism in hard drives explained to me as using the spindle motor as a generator to get the heads parked. Makes sense, there's a lot of inertia in the spinning platters that you may as well use.

Re:Use capacitors

[greyhueofdoubt]

erm... I have taken many hard drives apart, and I've never seen a cap in them (modern ones, at least) that would have enough power to turn the platters or energize the voice coil of the read head armature. It's been a while since I've seen anything other than surface-mount components.

Usually what I find is a rare-earth magnet at one end of the voice coil's travel that locks the read heads away from the platter in the absence of voltage in the coil; this is aided as well by the torque exerted on the armature by the trace ribbons that feed voltage to the coil and read heads. Note that this magnet is separate and distinct from the two that control the lateral motion of the read/write armature.

The 'clink' that you hear is the armature knocking up against the magnet. If you take the cover off, you can recreate the sound yourself, even without power.

protip: HDD voice coils make great crude galvanometers.

-b

Memory is reliably addressed; just wipe it.

[CarpetShark]

Memory is reliably addressed -- writing to the address you wrote to earlier will change the same physical part of the ram. There are already existing tools that erase passphrases after a certain period without use. All you need to do is make those tools also scrub the addresses used to store it. A simple patch would cover that.

What's more of a problem is: how to make this timeout+prompt for passphrase thing work with disk-level encyption regardless of whether you're a console or in a GUI, on an otherwise decent OS like unix? I wouldn't trust Windows to implement disk-level encyption safely anyway, so all bets are off there. But unix still has serious issues regarding the simple presentation of a dialog box to the user no matter what part of the system they're looking at, in a reliable and secure way.

Secure DRAM

[StCredZero]

Another option -- just make DRAM that drains all of its memory cells to ground when the power goes off. Every bit of DRAM is just a tiny capacitor, so this would erase the whole chip in an instant. If you could arrange for this to happen, then the DRAM would be be erased, unless you somehow supplied your own power to the DRAM chips.

Re:Secure DRAM

[postbigbang]

No, this is the problem; even with a ground, there's a charge held. DRAM isn't a charged-coupled device (CCD), instead, the charge drain doesn't work quickly, allowing DRAM to be read for a short while until things go to zero. The only protection you can give (see other posts) is to forcibly write a charge to all locations, or a sufficient number to scramble the eggs. All DRAM will eventually have cell decay to an unreadable point when the vcc is dropped. Several aforementioned schemes tell how to keep vcc on (capacitors, batteries, who knows-- maybe a DRAM fuel cell-- give your DRAM a drink). SRAM, photo-sensitive RAM, flash, and other ROM-ish RAM devices 'hold' a charge somewhat indefinitely depending on the technology in the device. DRAM eventually loses a detectable charge.

Re:

[HTH NE1]

I used that method to defeat the XOR encryption on an Apple II program. One sample of the decrypted data and the ability to read the encrypted data and it was simple to derive the XOR cypher for decrypting the whole disk without disassembling the code in the patched DOS.

Re:

[EvilRyry]

To heck with the power button. Just rip out the memory and run!

Re:Clear the DRAM?

[orclevegam]

As the4thdimension already pointed out, it's a common tenant in systems security that anyone with physical access and sufficient time can disable or otherwise bypass any security system. The fact is, if they're in a position to swipe the RAM out of your computer, they can just as easily take the HD to a secure location to try to brute force it, and/or attach some probes to the RAM and just read the bits straight off it, wouldn't even need to power the system down. Hardware security is just that, hardware, so there will never be an adequate software solution to a hardware security problem. Likewise, software security means nothing if the hardware is vulnerable. It's like building a safe with the most complex and impenetrable locking mechanism ever designed, and then using 1/4" aluminum for the body of the safe, sure no one's going to crack the locking mechanism, but all it takes is 5 minutes with a power drill to bypass it.

That being said, some sort of physical security mechanism probably wouldn't be out of the question for scenarios that actually called for it. For instance, on systems that contain highly sensitive data such as nuclear launch codes or some such, I could envision a tripwire type system on the computer case that detonates shaped charges on the HD and RAM when the case is cracked. This does open up a possible DOS attack vector, but the alternative seems to justify it.

Re:

[Peter La Casse]

Hardware security is just that, hardware, so there will never be an adequate software solution to a hardware security problem. Likewise, software security means nothing if the hardware is vulnerable.

I hear things like this a lot, and I disagree. The key words in the quote above are "adequate" and "nothing", which depend on a cost-benefit analysis. Just reducing risk can be more cost-effective than eliminating risk. Encryption is often an adequate software solution to a hardware security problem because

Re:Clear the DRAM?

[CountBrass]

I think you've missed the point. Hard drive encryption *is* supposed to protect against someone having physical access to your machine.

Re:Clear the DRAM?

[RAMMS+EIN]

Exactly! That is why this news item is actually big news. The idea of encrypting your disk is _exactly_ that someone without the key will not be able to access the data (within a reasonable amount of time - any encryption can be broken), even if they have physical access. And encrypting your disk does indeed prevent someone without the key from reading the data. What TFA tells us is that there is a way to get the key that we may not have considered, and I'm willing to bet many of us indeed hadn't. But now that we know of this attack vector, we can work against it.

As long as we can keep the key hidden, the encryption will protect our data.

Re:Clear the DRAM?

[orclevegam]

Yes, but the point is, if the system is powered down when it's stolen, or the hard drive is removed from the system, the full disk encryption will still protect the data. This is only a valid attack vector in the highly unlikely occasion that you have access to the powered on system, and even then it's somewhat dubious as to whether you'll get the data you need off of it. As I said though, this is very interesting from an academic standpoint for the simple fact that it is something that hasn't really been thought of. That being the case though, I can already think of one way to prevent this. Simply store your decryption keys at memory offset 0000:7C00, which will ensure that the BIOS copies the boot loader over your keys the next time the system boots (on x86 systems at any rate).

I do not thin' it means what you thin' it means.

[The Monster]

it's a common tenant in systems security that anyone with physical access and sufficient time can disable or otherwise bypass any security system.

Does it pay rent?

I think the word you're looking for is "tenet [merriam-webster.com]".

Re:

[Detritus]

Some crypto hardware is designed with anti-tamper switches that will erase all keying data if the case is opened. There is often a front-panel switch (zeroize switch) to do the same thing upon operator command.

Re:Clear the DRAM?

[HTH NE1]

I say leave lots of decoys around for them to try and guess at. Hiding in plain sight is incredibly effective if done correctly.

"Three books? Wait a minute. Hold it. Nobody said anything about three books.... Like-- like what am I supposed to do? Take-take one book, or all books, or... or what?"

Re:

[fastest fascist]

Excuse me? If you had access to the system, running and encrypted bits unlocked, why on earth would you turn it off? As I see it, this might be a problem if you get stormed by an adversary and pull the plug in an effort to secure your data.

Re:

[sempernoctis]

If you had access to the system, running and encrypted bits unlocked, why on earth would you turn it off?

Because the OS has control of the system at that point. If the terminal is locked, even though the system is on, you won't be able to access anything until you get control of the hardware away from the OS. Also, when you start poking around on a system, you always have the potential of accidentally destroying evidence, and evidence is much weaker in court if there isn't an untampered version of the d

Re:

[sempernoctis]

ATX power supplies are required to provide power for a certain amount of time after it signals the motherboard that it is shutting down. I forget how long that is, but it is probably long enough to wipe a few encryption keys if you know what part of memory to wipe. The attacker would then have to physically separate the power supply form the motherboard or remove the RAM while the system is running. To do that they would have to have the case open, so you could have sensors for tampering with the case th

Re:

[spun]

I was envisioning a hardware module that detected a power failure and wiped the RAM. The only way around that would be to pop the RAM out of a running system, which might work, or it might fry the RAM. But if the hardware module were incorporated into the DIMM, that would work.

Really, though, who would this affect? Top secret government stuff. I bet they've just got vials of acid or explosives or something. Tamper with the case and the contents (and maybe you) go bye-bye.

Re:Clear the DRAM?

[Anonymous Coward]

Thermite grenades, actually, taped to the case. Classified computers in sensitive areas get turned into slag if the position is overrun. (From my days working for one of the giant US 'aerospace' companies.)

Re:Clear the DRAM?

[Ollabelle]

Had something similar when I was working for a heavy construction company. Used to take out the old hard drives and take them down to the welding shop. They always enjoyed torching a hole through the spindle and liquefying everything inside the case...

Re:Clear the DRAM?

[FuzzyDaddy]

They always enjoyed torching a hole through the spindle and liquefying everything inside the case..

Well, who wouldn't?

Re:Clear the DRAM?

[HTH NE1]

Just put in firmware a key generator and encrypt everything going on the memory bus with a new key on every start-up. Bonus: also remap the memory address space randomly so that instructions and data are not stored sequentially on the same chip. For pipeline filling to work though you'll want it integrated into the CPU.

Re:

[Hatta]

Workaround: hit the main power off switch.

Re:

[Qzukk]

Workaround: hit the main power off switch.

Workaround: yank the DIMMs while the system's on.

Re:

[ThisNukes4u]

Workaround: Superglue/epoxy the chips to the motherboard retention mechanism.

Macbook Air...

[Wooky_linuxer]

has the RAM soldered in the motherboard! I knew Apple was thinking of our security all along!!!

/*ducks*/

Re:

[TooMuchToDo]

Work around: Detect if intrusion switch on chassis has be activated (by pulling the chassis open). If so, forcibly shutdown the system as soon as intrusion switch has been activated. Cover memory with some sort of physical device to prevent quick removal. Should give the RAM enough time to dissipate memory contents.

Re:Clear the DRAM?

[tmalone]

Or we could get rid of this easy to work with RAM that computers have now and go back to the olden days when you had to curse and scream and rip your hands to shreds on sharp metal corners to get at the RAM, which, once you got at was a pain in the ass to remove. Ah, the good old days.

Re:

[theMerovingian]

It is easy to write scripts that do anti-forensic stuff on logon/logoff or startup/shutdown. Even pulling the plug [indocomp.com] is often not enough to freeze a system from doing stuff so that you can gather evidence.

Re:

[asc99c]

I'd assume on reboot the plan is to not reboot the installed OS but probably to boot up a basic OS from a CD that gives free access to all the memory.

Re:

[SharpFang]

Still, power down without shutdown, then boot up operating system without such feature and you're gone.
The only way I see it to be sure, DRAM upon losing power uses on-board capacitor to erase its own contents, the feature built into the RAM die. Even BIOS is not sufficient if you just pull the plug and move the RAM to a different PC.

Physical Access

[MosesJones]

So lets thing what physical access means in these cases.

1) They have your desktop computer
2) It is on
3) You've entered your crypto keys

Is it me or is this just a little tenuous? In a data centre they'd have to drag the thing off the rack and on your personal machine they'd have to physically take it off you, because waiting for you to shutdown and then walk-away would be too long. So the solution is to shutdown the machine and THEN put your coat on and pack your bag.

I can also get people's Crypto keys by threatening them with a knife or putting a CCTV camera over their workstation. There are "easier" ways to get the keys if you have physical access to the environment that are much simpler and reliable.

Re:Physical Access

[nachoboy]

Don't expect to have time to do anything if the feds bust down your door and want your boxes. Plus, now your machine doesn't even have to be turned off for someone to remove it to a forensic lab: introducing HotPlug [wiebetech.com].

Re:Physical Access

[mypalmike]

on your personal machine they'd have to physically take it off you

Like when your laptop is stolen while it's in sleep mode. This is rather a common situation.

Re:

[Qzukk]

2) It is on
3) You've entered your crypto keys

These two are likely true for every kind of whole-drive encryption, unless the encrypted drive is unmounted every time you walk away. As for 1), it's true if you lock the console and walk away from the computer, which quite a lot of people do.

Best workaround would be for A) operating systems to support fixing keys in a single spot in memory and B) drive encryption systems to automatically unmount and scramble the key (in the same place its always been, rather th

Re:Physical Access

[TheRaven64]

Think laptops. Laptop users with a half-decent OS don't turn their machines off, they just put them to sleep. When you turn the machine on, you enter your passphrase and it mounts the encrypted disk volume. When you close the lid, the OS locks the machine. You can't get in again without entering your pass phrase. If someone steals the machine, they can't log back in without knowing your password. If they shut the machine down and boot from a different disk then they can't access your data because it's encrypted and turning off the machine wiped the decryption key from RAM.

Except, apparently, it didn't. With the new scenario, the thief takes the cover off the machine and then pulls the battery. They then cool the RAM chips and dump the contents. They can then scan through the dump looking for the decryption key. Once they've found it, they mount the encrypted volume from another OS and get at all of your confidential data.

You can probably read the memory via Cardbus!

[tamyrlin]

The problem is much worse on laptops actually. Most laptops have some sort of CardBus slot nowadays. This is basically a PCI interface. The idea is to create a CardBus interface which allows you to dump the physical memory of the laptop using DMA. No need to freeze any memory, just insert your custom made card into the computer and wait for it to copy the memory contents to flash memory or something similar. There are a few question marks here though:

• Is the Cardbus slot always enabled or must the OS en

Re:You can probably read the memory via Cardbus!

[TheRaven64]

True, although it is worth noting that this (and the equivalent FireWire attack) can be mitigated on laptops with newer AMD CPUs (and possibly the latest Intel ones if VT-d is now shipping). Newer AMD chips (or, more specifically, their on-board memory controllers) have a Device Exclusion Vector (DEV) which is a simple bitfield with an entry for each page in physical memory indicating whether a each device is able to DMA to or from that page. A well-behaved OS will set this up so that no device can access any memory unless the driver explicitly permits it. As long as the OS keeps the pages containing encryption keys in the 'never let any device access this' part of memory it will be safe.

Re:

[CastrTroy]

Which is why you should alway unmount your encrypted volumes before you powerdown/hibernate/standby which would ideally clear the contents of memory which contained the key. This would only work in a surprise attack where the user had enough time to poweroff the machine.

Re:

[Yath]

So the solution is to shutdown the machine and THEN put your coat on and pack your bag.

You're going to turn it on later, right?

Let's say you've taken your disk-encrypted laptop home and you're doing work on it. Thugs break in, throw flash grenades, yell, etc. You cut power to your laptop just before they grab it... they rip it open, freeze the contents, then pop out the drams. They put the drams in another machine and read your key, and thus have access to your hard drive. Damn. And you thought turning it o

Physical Access

[twiddlingbits]

That's the hard part, so any hack using this method almost has to be an inside job. How many hackers can actually walk into a location, take down the system, open it up and remove the memory DIMMS? In every data center I've worked at someone with that level of access is pretty well checked out, or if they are a vendor they are escorted and watched carefully. Pulling DIMMs out an puting them into liquid nitrogen is surely going to be noticed. It's not like you carry a Dewar in your pocket. Sure you can spoof

Re:

[Maximum Prophet]

If you've put your laptop in standby, and the laptop is stolen, there's now a non-zero probability that the bad guys can access your encrypted data. The disk encryption people need to make sure that the standby routines erase any and all keys, and reprompt for access when the system comes out of standby.

from an attacker with physical access

[wiredog]

If the attacker has physical access to your system, it's not your system.

CPU cache?

[Westley]

One potential workaround, which would probably require support from Intel/AMD: store a short encryption key in L1 cache. It doesn't need to be big, or use "proper" encryption - just enough to make the DRAM key useless unless you've got the cache memory.

I would hope that the CPU could clear this cache as it powers down (even in a non-orderly manner).

Then again, I realise that people who aren't experts (and I'm definitely not an expert) very rarely make suggestions which actually fix significant security hole

Re:

[mzs]

VIA had a while back some registers that you cold tweak to lock L1 cache lines. I don't know if modern VIA chips still have this. In the X86 world I do not know of anything similar from Intel or AMD. You might have better luck using unused registers in the CPU (debugging registers) or external chips (chipset UART regs say) but then you really would not be able to use those anymore, but there may be enough legacy registers around not really used anymore to make it work with the penalty of it being very slow.

Firewire and USB can access memory

[Anonymous Coward]

Heck, with physical access to a running machine, jack into the firewire or USB port and you have clear access to reading and writing all the memory you want.
I wrote a small paper here http://www.friendsglobal.com/papers/FireWire%20Memory%20Dump%20of%20Windows%20XP.pdf [friendsglobal.com] for a forensics class on using firewire to access memory, subverting the operating system.

All bets are off once physical access is gained. Best bet would be to store the keys, somehow, in the CPU's caches and never let it stay in main memory.

guess what

[circletimessquare]

there's no such thing as absolute security

all security does is build a wall. someone can always climb over it, somehow. the question for you is merely do you want a white picket fence? or do you want a 10 foot chain link fence with barbed wire on top?

locks on doors merely keep honest people honest. anyone determined to break into your house will find a way

don't invest your energy in a failed concept: i can have absolute security. you can't, it's always an arms race, forever

Re:

[zappepcs]

You are absolutely right about the arms race. While you have physical security of the machine hacking on the RAM is unlikely.

Additionally, it might be good to remember that the PC architecture has a lot to do with the options you have for securing the machine. If your CPU allows physical separation of user memory and machine use memory there are more options. In fact, you can build a kind of sandbox for the machine to run inside of in a protected way. If your encryption is hardware based, it's possible to p

It rather depends...

[jd]

...on how you define "absolute". A one-time pad cannot be broken, even if you had a theoretically infinitely fast computer. (It would decrypt to every possible string of the same length with equal probability, with no means of telling which one was the one you wanted.) If you want to add extra security, then introduce a negotiated random offset into the pad and a negotiated random step-size.

Is that absolute security? Well, an outsider couldn't break the encryption. To do so requires the pad. There are no

Very real concern

[Deagol]

I run my FreeBSD (7.0RC3) system with some geli-encrypted volumes, and one-time encrypted swap and /tmp. Very little data can leak out to non-encrypted space (yeah, /var/tmp is one).

However, for grins one day, I decided to run "dd if=/dev/mem bs=1m count=[mem size] | strings | grep [whatever]" and found not only various passwords, but URLs for sites visited *weeks* ago, even after reboots. So, I installed the "secure_delete" port and ran "smem". No luck -- some stuff got wiped, but some remained in memory. So I booted to a memtest86 CD-ROM, and ran the full test (this test does all kinds of writes/reads to memory). Then, I booted *back* to the normal system, and I was *still* able to recover juicy bits from /dev/mem. WTF?

We need a kernel module for the common OSes that can encrypt virtual pages (is that the right term?) so that whether in core or paged, they won't be vulnerable.

Re:Very real concern

[Cruicky]

If you are running "dd if=/dev/mem bs=1m count=[mem size] | strings | grep [whatever]" on the machine, your search term will be stored in memory, so you are certain to get a result. You would need to take a memory dump, then run strings on that instead, preferably after it's been transferred to another machine.

Re:

[Deagol]

Indeed -- however, I am not *that* dense. ;)

It's pretty easy to tell, though, that if you do my procedure and grep for "example" then see "http://www.example.com" in the result, which hasn't been visited in weeks/days (even after reboots and power-downs), then it's clearly appears to be lingering in RAM.

Someone mentioned browser cache, but that's set to be cleared each time Firefox is loaded. Perhaps file system slack space is the culprit here.

Someone else mentioned the VFS cache, which I don't know

I can't believe this hasn't been mentioned...

[gillbates]

we know of no simple remedy that would eliminate them...

As part of a secure programming course I recently took, we were instructed to overwrite keys with zeros when done using them. It's that simple - you don't leave the key in memory for any longer than you need it.

When the machine is powered down, your application's exit routine zeros all of the memory, and then free()s it. Nothing that good programming practices can't address.

Generally speaking, it's the keys on the disk(!) that are the problem. Without two factor authentication, you need merely to scan disk sectors...

Re:I can't believe this hasn't been mentioned...

[vux984]

When the machine is powered down, your application's exit routine zeros all of the memory, and then free()s it. Nothing that good programming practices can't address.

Unless of course the machine is, you know, simply "powered down".

Pulling the plug isn't going to let your application do squat.

Re:

[swilver]

There are ways to turn off computers that bypass "Start > Shutdown"

Re:

[yeremein]

For hard disk encryption, you need to keep the key in memory. Can't ask the user for a password every time you read a sector.

Countermeasure here:

[jetmarc]

This attack is very powerful.

It's not possible to "clear the DRAM" (as others have suggested), because the attacker will boot his own CD and not give control to your OS after the reset. Thus you won't be able to clear anything.

Anything? Not so quick, my dear! For the CD to boot, first there is the BIOS. And BIOS needs memory as well (for the menus, the screen, the ElToro floppy image etc).

Now the countermeasure is obvious: Keep the sensitive key material in memory areas that is erased during the early boot procedure. Then the attack complexity is raised from "no hardware required" to "specicialists hardware necessary, no guarantees given".

It might seem difficult to find out which memory is of that category. But it isn't, either! Just prepare two boot CDs. One that fills all memory with a known pattern (eg 0x55). Boot it. Then reset and insert the second CD, which identifies all memory areas that have lost the known pattern. These areas have either suffered DRAM fade, or they have been overwritten during the BIOS boot process. Use heuristics to find out which of the two was the cause. Done!

As simple as that.

Regards,
Marc

Re:

[Klaus_1250]

Anything? Not so quick, my dear! For the CD to boot, first there is the BIOS. And BIOS needs memory as well (for the menus, the screen, the ElToro floppy image etc). Now the countermeasure is obvious: Keep the sensitive key material in memory areas that is erased during the early boot procedure. Then the attack complexity is raised from "no hardware required" to "specicialists hardware necessary, no guarantees given".

I'm pretty sure you can manufacture a specialist DRAM read/dump module for a tens of dollars in China. So while it would be for specialists, access to such hardware will be available and at relatively low costs. So it won't stop the people you're trying to protect your from.

Dirty fix

[Anonymous Coward]

Solder RAM to board.
Password the BIOS, boot only from local disk.

Already Screwed

[immcintosh]

If somebody has the kind of access to cut power to your system and then immediately reboot with a malicious thumb drive, they probably have enough access to install something like an inconspicuous hardware keylogger, which I would be much MUCH more worried about than this if you're doing something sensitive enough to warrant it.

And aside from that, couldn't you just encrypt the important parts of your memory and swap as well as your hard drive? Seems like that would defeat this quite handily, and again, if I were doing something so sensitive I'd probably be taking such precautions.

Honestly though, aside from people doing stuff like maybe international or corporate espionage, I can't imagine where any of this would be a problem.

New feature for motherboard venders

[seth_hartbecke]

Full memory encryption. Set a chip on the memory buss, it encrypts/decrypts all the data as it passes between the CPU and RAM chips. At first this would be something like old MMUs before they were built into the CPU itself. They sit on the address bus and add/subtract offsets. This would sit on the data bus and do some simple crypto. Put a capacitor right next to it, first time the chip powers up it selects a random key, when the motherboard looses power the capacitor keeps the chip running long enough

In 1986...

[Rick Richardson]

I pulled a PIC-4 uP out from a circuit. The DRAM stayed non-refeshed for 2 minutes...

Well known problem to security experts...

[gweihir]

... at least those that are worth their money. What was unknown is the exact amount of time you have and what can be done to extend it. Interesting reseacht for those alone. The basic vulnerability has been known for a long, long time.

Fix: None, really. Just don't overestimate the capabilities an attacker needs to get your data. Also note, that if a computer has been switched off for some time, the risk fades. Protecting laptop disks with disk encryption is not a lot less secure now and still a good idea.

Fix: install BIOS with a memory test.

[Animats]

Easy fix: install a BIOS/boot ROM with a non-bypassable memory test of all memory. This will clear all memory at power-up before reading the boot device.

Put the key in SRAM.

[Skapare]

Put the key in a small piece of SRAM. When it gets used to encrypt something, be sure the place of its usage gets wiped back off real fast to minimize the chance of it being exposed to the cold attack. Split data up with different keys for different data, so if a key is exposed, only a minimal amount of data is lost. Another option is to double or triple encrypt the data being sure never to have more than one key at a time in DRAM.

So where do we get this SRAM? A CPU register that is not used, and not saved, for any current purpose is one possible place. For a large amount of SRAM, check out your video card buffer.

Simple fix, no?

[rickb928]

Make the BIOS clear RAM on power-up.

Wait, doesn't it already?

Wait, did the researchers bypass BIOS?

Well, if they did, then adding some crap to DRAM to kill it on power loss is the only way. Probably.

It was once an axiom of system security, that if you gained physical access, all was lost. This evolved from keyboard and console attacks to floppy- and CD-boot attacks, USB keys, stealing the hard drive, you know the drill.

Ultimately, if you can cart away pieces of the machine, your last line of defense is gone.

The only other variable to control is time. Make the DRAM die quicker, or is it time for a 'better' memory technology?

And this is such great stuff, the TEMPEST guys will now have to re-write their procedures, with both a power-off and wait 30 seconds, and a re-power-on and wait for login prompt, then shutdown again.

Sometimes I hate h@xrs, and sometimes I realize they do me a service, albeit while they intend to just do me.

How ironic. My captcha is 'honest'. This cannot be coincidence.

DRM attack vector

[crow]

While an issue for whole-disk encryption, this is also an issue for DRM. Just flick the power while the interesting media is being decrypted, and even if the OS had been protecting the key in some "safe" location, you can now find it. It might be little more tricky, but if you can pull the RAM on a video game console, you can do the same thing.

This is pretty epic...

[ComputerPhreak]

To everyone saying 'if someone has physical access you're hosed anyway'... that simply isn't true. If you have a laptop and encrypt your data correctly, it was thought that it was mathematically infeasible to recover the data if your laptop was stolen. But with this (new?) technique, if it works well enough to be reliable, you could still be fucked even if you took the precaution of encrypting everything.

Another attack loop-AES thought about !

[this great guy]

This is yet another attack that the developer of loop-AES [sourceforge.net] thought about while typically every other disk encryption tool out there is vulnerable. Loop-AES is the 3rd most popular disk encryption tool in Linux. See the KEYSCRUB=y option in its README file [sourceforge.net]:

If you want to enable AES encryption key scrubbing, specify KEYSCRUB=y on make command line. Loop encryption key scrubbing moves and inverts key bits in kernel RAM so that the thin oxide which forms the storage capacitor dielectric of DRAM cells is not permitted to develop detectable property. For more info, see Peter Gutmann's paper [cypherpunks.to].

I have used loop-AES as a full disk encryption tool on my laptop for 2+ years. I am glad I took the time to carefully research which tool would the most secure before deploying it ! For example even TrueCrypt and dm-crypt are vulnerable to other (arguably minor) security issues that loop-AES is impervious to: http://article.gmane.org/gmane.linux.cryptography/2321 [gmane.org]

Surprisingly, the research paper TFA talks about doesn't even directly mention loop-AES (its name only happens to be in the title of a webpage in the reference section describing a safe suspend/resume setup when using disk encryption).

Re:

[DamnStupidElf]

Presumably, moving bits around in memory doesn't help in this case because the exact memory image is retained. Additionally, the code that moves the bits around is also present, making it straightforward to locate the bits and reassemble the key.

Re:

[Mike1024]

This is yet another attack that the developer of loop-AES thought about while typically every other disk encryption tool out there is vulnerable. [...] "Loop encryption key scrubbing moves and inverts key bits in kernel RAM so that the thin oxide which forms the storage capacitor dielectric of DRAM cells is not permitted to develop detectable property. For more info, see Peter Gutmann's paper."

I'm afraid it doesn't. Here is the code from Gutmann's paper:

Flipping:

while( TRUE )
{
acquire keyMutex;
key ^= 1111..

Epoxy

[Bender0x7D1]

It seems like the best defense would be applying epoxy to the memory so it couldn't be removed from the slot. If you make sure all the connections are covered as well, they wouldn't be able to place a tap, either. (At least without a lot of time being spent slowly drilling through the epoxy.)

It would make it impossible to replace your memory, but you could always move the HD to another system. If you care that much, then you should be willing to pay for a new system if someone tries to compromise your data.

Sony IBM Cell

[epine]

I'm surprised no one has mentioned the Cell processor yet. I guess everyone hates it.

The first power word that a toddler learns is "mine!" It's the capstone to a complete working vocabulary: mommy, daddy, more, enough, and mine. My laptop, my hardware, my data, my privacy. The word "mine" has a direct bypass to the neurological circuit "you can't make me", which as adults lingers as a deeply-rooted fascination with rubber-hose cryptography, and bravado propositions such as "if the Feds bust through your windows". Wrong answer.

Let's look at this from Sony's perspective: my media, my hardware, my design, my copyright, my profits. But guess what? They have a small physical access problem. Millions of zit faced kids with access to liquid nitrogen can get their paws inside the PS3.

This is why an entire SPU is locked down on the PS3 for security / DRM purposes. The SPU contains 256K of SRAM which is carefully guarded. The instruction set is synchronous and deterministic to guard against timing attacks. They were aware of power attacks as well. These can be partially mitigated in software for critical routines by executing non-conditional instruction sequences and then discarding the portions of the computation you didn't want. By design, the SPU doesn't dance on the power line the way most modern speculative out-of-order processors do to begin with. You can't use latency effects, because the local SRAM has constant access time. You can't use contention effects because there aren't any below the level of DMA bursts, which are controlled by a companion processor within the SPU. Plus I think it is possible to schedule SPU-SPU and SPU-memory DMA transfers deterministically, if you really need to. None of this was accidental.

The hardest part of the problem is bootstrapping the secure SPU with the security kernel. I've forgotten how they went about it. There must be some kind of decrypt key buried in the Cell hardware which functions during initial code upload during processor initialization.

In the long run it might be an unwinnable battle, but the PS3 certainly has a far better facility to maintain data security in the complete absence of hardware security than your average PC.

Why can't the average hacker Harry wants to enjoy the same security as Sony/IBM, why can't you achieve this? You've already got the PS3 in your living room. Impediment: the secure system init decrypt key is probably burned into the silicon. It's probably a one-way key, so even if you crack the key, you won't be able to encrypt a replacement block of your own code that matches the decrypt key. But let's suppose you break that too. Problem: Sony knows the decrypt key for the SPU initialization sequence. Game over.

Let's suppose you figure out how to physically change the silicon with an initialization decrypt code known only to yourself. Congratulations, you now enjoy the same protection for your secrets that Sony enjoys for "Untraceable". In doing so, you have now upgraded yourself to a sufficiently threatening fish to swim in a tank in Syria, where your nervous system will be similarly reconfigured.

Ew, I feel like I've just written the script for "Adaptation".

Countermeasure: VIA C3 has built-in SRAM

[Adam J. Richter]

I believe that the C3 processor made by VIA and probably other processors in that family allow some of the cache to be configured as SRAM and mapped into physical memory. So, you could store the key in SRAM, which I believe really will lose its data upon power loss, although you may also want to take countermeasures such as those used in loop-AES to avoid detection by physical changes to the chip if key is store for a long time in the same place.

Newever VIA processors also have some hardware AES support available under Linux, which they call "Padlock. So, if they still retain the SRAM feature, then, at that would make a pretty good choice for the little fanless mini-ITX Linux box that receives your email.

Re:

[wild_berry]

If you've just turned it off, I can spray your RAM with coolant and have it retain its memory for hours. Then I boot from a USB stick or DVD and use a small program to read the contents of your RAM and harvest your keys.

The method strikes me as the best way to get past TPM devices, until they include measures to zero all RAM on shutdown.

Re:

[Hatta]

Right, so if you have a desktop computer that's on all the time and a warrant is issued for that computer, that truecrypt partition you set up for just such an event becomes useless. There's ample reason to worry.

You are making several wild assumptions here

[brunes69]

You are assuming that...

a) Your average cop who is seizing your PC is well-read enough to know about this technique
b) The cops came totally unannounced to you
c) Your PC is left on all the time with your encrypted partition mounted, or that the cops moved through your house so fast (30 seconds according to the article) that you don't have enough time to turn the machine you are using off for long enough for the DRAM to lose it's charge.
d) You don't have a BIOS boot password set on the PC (any BIOS password w

Re:

[Maximum Prophet]

Many business types will log in to access their laptop, then put it in standby to take home. If the standby routines don't erase the keys, then the bad guys can access them after they steal the laptop.

Re:

[haystor]

Stolen laptops would be the chief target I'd imagine. They are easiest to get physical access to and most likely to be considered "secure" through encryption software.

Re:

[KublaiKhan]

Hrm, especially if they were in hibernate mode to start with....

Re:

[fastest fascist]

Um... presumably, for the contents of memory to be useful for breaking encryption, you'd need to have access to the system while it is running, with the encrypted files/drives/whatever unlocked. In this case, why would you pull the plug at all and not just copy all the data since it's right there, accessible?

Re:Fascinating...

[planckscale]

If you RTFA you would know that the times can be anywhere from seconds to minutes, but that if you rapidly cool them with an inverted air duster, you can keep the info retained in the chips for 10 minutes or so. I you use some liquid nitrogen, even longer. Requires that you "cut" power to the computer. So I guess that means for a laptop, pulling the battery first, then pulling the plug, spraying the chips with liquid cool, then plopping them into another machine and booting to an evil OS that will read the contents of the memory. I wonder if even TrueCrypt's keyfile function is even thwarted. I mean even if they get your encryption passphrase, wouldn't they still need the keyfile to mount the partition? And how would they know the location of a hidden partition? Also, if someone has physical access to the computer, then there is no security. I mean why not just plop in a keylogger, or set up a hidden webcam to shoulder-surf?

Re:Fascinating...

[Anonymous Coward]

It depends on many factors, including the technology, the density of the part, and the ambient temperature. Years ago I ran some experiments on 128MB SDRAM (not DDR) and found that even at elevated temperatures (60C) the minimum retention time with zero ECC errors (it was ECC memory) was around six seconds.

I ran those tests because we were using a large chunk of SDRAM (16MB) as a RAM disk to capture log data on an embedded platform. On system failures we had the logs that led to the failure plus a small crash dump to support debugging. The hardware restart cycle was always fast enough to preserve the RAM disk image. I became curious as to how close we were to the edge, so tried a series of experiments, including extracting the blade from the chassis, watching the sweep hand on my watch, and reinserting the blade to let it boot. Even in a temperature chamber (60C is really warm...) the RAM FS was sane after a four second pack pull, allowing about two seconds for the power management to reboot the pack, that gave a six second power off window.

On reboot, the boot monitor checked the reserved area by clearing the ECC status bits, then reading the entire reserved block, which would trigger ECC counters in the memory controller if there were flipped bits. If there were any (even one) ECC counts, it zeroed the block, triggering the kernel to rebuild an empty file system.

So there is my experience on DRAM data retention in power off situations. YMMV.

If someone would like to try this with DDR2 or DDR3 with ECC, it would be interesting to see your results. I have DDR2/ECC blades coming on line now, if I get ahead of my work, I may recreate this test and post back the results. Given my current calendar, it will be a while (months).

PS: Under normal room temp, ~20C, it was very reliable at 16 seconds, and I saw a couple of tests that passed twenty.

Re:Fascinating...

[dpilot]

At the time I quit working with commodity DRAM, the common spec was for 128mS data retention at 85C. For various reasons, such as guardbanding, we tested well beyond that. I'd seen further data that suggested that most of the data in the DRAM was still good for several seconds, with no refresh. I seem to remember once hearing something to the effect that retention typically increased an order of magnitude for every 10C drop in temperature. So that 128mS @ 85C becomes 1.28S @ 75C, 12.5S @ 65C, etc. Yeah, I guess I can believe the "minutes" figure if you can chill the chips. By the way, that 85C is junction temperature, which is typically 10C-20C above ambient temperature, when running at full tilt. That offset can be even higher depending on airflow, etc. That also means that if the system is quiescent, the DRAM temperature is likely to be well below 85C, with correspondingly greater data retention.

At any rate, even with low temperatures, with such delays I'd never count on being able to get 100% of the contents successfully.

Re:

[Stanza]

I suspect he is.

I remember on my Apple II, when you first turned it on, the screen was filled with inverse '@' symbols. Then the screen would quickly blank (or be replaced by spaces) and the startup sequence would go.

But if it hadn't been off for very long, not all the memory would go to zero (chr$('\0') is the inverse '@'). So, if you turned your computer back on with in a certain time, you could either see the screen it had when it shut off, or more likely, rows of the screen would be inverse '@'s, and

Hardly the problem

[wsanders]

Time for memory controllers that just zero out RAM on power up. I think most do anyway.

Worse, on most running OSes there are all kinds of deallocated and leaked chunks of memory that have god-knows-what in them. As root, you could browse through all this, or just trigger a dump.

This is fun to know, but really, if someone is going to get physical access and rip the RAM out of your machine for its secrets and then plop them into a specially-crafted dead-RAM reader, you've got bigger problems, like the CIA or

Re:

[orclevegam]

You kind of missed the point. The argument is that even with full disk encryption it's possible to reboot the system to a special OS that reads the encryption keys out of the RAM before it decays allowing the contents of the disk to then be decrypted. Of course, this overlooks the obvious problem that first you need to get your hands on the running system that already has the password entered and the disks decrypted, and then further allows you to reboot it using an alternative boot mechanism. Most often yo

Re:

[russ1337]

Next, you need to have a floppy, cdrom, or USB stick with your specially crafted OS on it and somehow get the system to reboot into that special OS (mind you at this point you probably don't know for sure if the laptop is using full disk encryption, or even what brand)

So simply setting the hard drive as the only boot device in BIOS, and password protecting BIOS could slow down the attacker enough. (they'd have to disasemble the laptop, reset the bios, reboot).

As someone pointed out to me a few days a

Re:

[orclevegam]

Hmm... it's kind of assumed that there will at least be a screensaver password enabled that would prevent you from accessing the data directly. On the topic of preventing the new OS from reading the data though, why not store the decryption keys at 0000:7C00. Anyone familiar with how boot loaders work knows that that's the address that the boot loader gets copied into by the BIOS, so if you store your sensitive data there simply booting a new OS would wipe it out.