Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Cold Reboot Attacks on Disk Encryption

CmdrTaco posted more than 6 years ago | from the wont-someone-please-think-of-the-bits dept.

Security 398

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

cancel ×

398 comments

Clear the DRAM? (5, Interesting)

the4thdimension (1151939) | more than 6 years ago | (#22503834)

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? (5, Interesting)

KublaiKhan (522918) | more than 6 years ago | (#22503910)

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? (5, Informative)

compro01 (777531) | more than 6 years ago | (#22504344)

death code [catb.org]

Re:Clear the DRAM? (4, Insightful)

spun (1352) | more than 6 years ago | (#22503924)

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.

Re:Clear the DRAM? (1)

the4thdimension (1151939) | more than 6 years ago | (#22503998)

Good point... if I am being malicious I could just take the time to either find a motherboard that does not have this module or take the time to reprogram the hardware module so that it does not do what it intends to do. Obviously there are many ways around any sort of protection you can try and come up with. If you have physical access to the machine, you could always execute a way around hardware or software protection.

Re:Clear the DRAM? (2, Insightful)

spun (1352) | more than 6 years ago | (#22504090)

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? (5, Interesting)

Anonymous Coward | more than 6 years ago | (#22504410)

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

Use capacitors (4, Insightful)

StCredZero (169093) | more than 6 years ago | (#22504078)

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:Use capacitors (1)

Amouth (879122) | more than 6 years ago | (#22504378)

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"

Secure DRAM (1)

StCredZero (169093) | more than 6 years ago | (#22504134)

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 (4, Informative)

postbigbang (761081) | more than 6 years ago | (#22504244)

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:Clear the DRAM? (1)

EvilRyry (1025309) | more than 6 years ago | (#22504144)

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

auto-turret (0)

Anonymous Coward | more than 6 years ago | (#22504224)

But the auto-turret I have guarding my computer would get you before you escaped.

Re:Clear the DRAM? (0)

Anonymous Coward | more than 6 years ago | (#22504216)

Or instead of a battery, you could use a thousand volt capacimator or somethin.

The problem is, what if the attacker physically removes the memory without powering down the machine? You can probably successfully remove one card before things go haywire.

Re:Clear the DRAM? (5, Insightful)

orclevegam (940336) | more than 6 years ago | (#22504308)

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:Clear the DRAM? (2, Interesting)

fastest fascist (1086001) | more than 6 years ago | (#22504368)

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:Clear the DRAM? (3, Informative)

sempernoctis (1229258) | more than 6 years ago | (#22504634)

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 disk to allow the prosecution's claims to be verified.

Re:Clear the DRAM? (3, Interesting)

sempernoctis (1229258) | more than 6 years ago | (#22504384)

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 that cause all encrypted data to be dismounted.

Re:Clear the DRAM? (1)

poot_rootbeer (188613) | more than 6 years ago | (#22504684)

What we need is a battery backed up hardware module that scrambles the RAM when the system loses power.

What if an attacker pries the battery off the scrambler hardware before cutting power to the system (with an insulated tool, obviously)?

Re:Clear the DRAM? (1)

Hatta (162192) | more than 6 years ago | (#22503966)

Workaround: hit the main power off switch.

Re:Clear the DRAM? (1)

Qzukk (229616) | more than 6 years ago | (#22504062)

Workaround: hit the main power off switch.

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

Re:Clear the DRAM? (1)

ThisNukes4u (752508) | more than 6 years ago | (#22504188)

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

Macbook Air... (4, Funny)

Wooky_linuxer (685371) | more than 6 years ago | (#22504638)

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

/*ducks*/

Re:Clear the DRAM? (1)

TooMuchToDo (882796) | more than 6 years ago | (#22504196)

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? (5, Funny)

tmalone (534172) | more than 6 years ago | (#22504292)

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:Clear the DRAM? (1)

theMerovingian (722983) | more than 6 years ago | (#22504092)


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:Clear the DRAM? (1)

asc99c (938635) | more than 6 years ago | (#22504350)

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:Clear the DRAM? It wouldn't matter at all. (1)

AFormalEvent (966445) | more than 6 years ago | (#22504556)

They don't run the shutdown scripts, they cut the power to a running system. that's why it typically only works when the computer is on. Also, Dram ~is~ cleared at boot, as it will be over written by new data, but their boot-time software takes care of that.

Hardware Encryption (1)

obstalesgone (1231810) | more than 6 years ago | (#22503842)

Time for memory controllers with hardware encryption.

Re:Hardware Encryption (0)

Some_Llama (763766) | more than 6 years ago | (#22504048)

yay DRM!!

Nothing can be encrypted 100% of the time (0)

Anonymous Coward | more than 6 years ago | (#22504106)

At some point, data needs to be in its plain original form to be operated on. I guess it all depends on how close to the heart of the "execution core" you want the encryption to be used. The closer you keep the data encrypted, the bigger a performance hit you're going to have. Call it the "plain-text hole" if you will.

Hardly the problem (1)

wsanders (114993) | more than 6 years ago | (#22504218)

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 FSB is on your ass already, and you probably have guys with guns at the data center door anyway they'd need to take out to get at the machine.

Otherwise, just steal the whole machine and read the disks. Much easier, and there's probably just as much interesting stuff on the disks.

Re:Hardly the problem (2, Insightful)

orclevegam (940336) | more than 6 years ago | (#22504640)

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 you run whole disk encryption on things like laptops so that in the event it gets stolen the data on it can't be recovered. Lets imagine how you would pull this attack off in this scenario. First, you need to find a laptop thats powered on, and decrypted, so most likely someone is using it. Next, that person needs to somehow leave the laptop sitting someplace (with sensitive information) powered on, and to be gone long enough for you to swipe it. Also, when you do swipe it, you must ensure that it stays powered on until you get it to wherever you have your forensics setup at. 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). lastly, you have to be lucky enough to get the specific data you want off the memory before it degrades and you lose it forever. Now, is this possible? Yes. Is it likely? Not even in the slightest. This is an interesting academic exorcise, but means exactly jack in real world security.

Fascinating... (1)

KublaiKhan (522918) | more than 6 years ago | (#22503846)

So how long does this information persist in the RAM? They say "seconds to minutes" but -how many- seconds? And what brands/types of RAM have longer or shorter latency?

Re:Fascinating... (1)

the4thdimension (1151939) | more than 6 years ago | (#22503936)

Its really unpredictable. There will be bits in memory that last longer than others because bits in RAM are essentially little electrons that are either turned "on" or "off" based on the electricity (voltage) supplied to them. As we know from shocking our friends, electricity can vary in the time it takes to decay. Sometimes it goes away instantly, sometimes it lingers. Brands of RAM and types can't realistically predict this.

Re:Fascinating... (1)

KublaiKhan (522918) | more than 6 years ago | (#22503996)

There's probably some equation involving entropy that talks about that...

I was thinking the construction of the RAM would be a factor--different brands would have different dies and suchlike, which would have an effect on how fast the system entropizes upon power removal.

Re:Fascinating... (1)

the4thdimension (1151939) | more than 6 years ago | (#22504060)

I can see it now:

"New XYZ brand, bit decays instantly for super security! 2x1gig for $400!"

Re:Fascinating... (4, Informative)

planckscale (579258) | more than 6 years ago | (#22504000)

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... (1)

KublaiKhan (522918) | more than 6 years ago | (#22504030)

My question isn't how to read 'em, but how to keep 'em from being read.

Heating the chips would probably help, but that has its own problems.

Re:Fascinating... (5, Informative)

Anonymous Coward | more than 6 years ago | (#22504342)

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... (1)

KublaiKhan (522918) | more than 6 years ago | (#22504464)

Someone mod parent 'informative'--that's exactly what I was looking for.

I'd be very interested in hearing the results for the newer RAM types....

So if you've got physical access to the system, it's an extremely doable prospect to carry out this hack--and even moreso if you have specialist equipment.

This leads to another question: would it be possible to have a reasonably portable version of this 'embedded platform'? As in, something where you could open a system, power it off, pull the chip, put it into some handheld or portable box that you're carrying with you, then hit the switch and read?

If so, that might be a -very- useful thing to have in certain situations.

Re:Fascinating... (4, Informative)

dpilot (134227) | more than 6 years ago | (#22504490)

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:Fascinating... (1)

KublaiKhan (522918) | more than 6 years ago | (#22504548)

True enough, but you don't need 100%--you need "enough to get the key out reliably"

I'm sure if you brought in someone with a degree in thermodynamics, they could give you an equation for entropy in the data system over time that you could leverage into your recovery algorithm and give you some sort of confidence number in the data.

And even if you can't get the -whole- key, if you can get at least part of it, it'll be easier to crack the system by several orders of magnitude.

only useful if you start off unencrypted (1)

Gothmolly (148874) | more than 6 years ago | (#22503852)

If you steal my laptop, and try to boot it, it doesn't magically decrypt anything for you to steal by reading the RAM shortly thereafter.

So you'd need me to log & open up the TrueCrypt protected data. Then, as I see you coming to kill me, I pull the plug on the machine, but in the next 3-35 seconds, you manage to read all of RAM.

Interesting point about DRAM holding onto memory after power is removed, but hardly a reason to worry.

Re:only useful if you start off unencrypted (2, Interesting)

wild_berry (448019) | more than 6 years ago | (#22503940)

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:only useful if you start off unencrypted (1)

KublaiKhan (522918) | more than 6 years ago | (#22503944)

It has as much relevance as any other scheme that requires physical access.

Probably a lot more relevant to, say, systems on private/secure/confidential/secret networks that may be left on pretty much all the time, but the possibility exists that someone could possibly gain access to 'em at some point, Mission: Impossible style.

Re:only useful if you start off unencrypted (2, Informative)

haystor (102186) | more than 6 years ago | (#22504010)

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:only useful if you start off unencrypted (2, Insightful)

KublaiKhan (522918) | more than 6 years ago | (#22504098)

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

Re:only useful if you start off unencrypted (1)

fastest fascist (1086001) | more than 6 years ago | (#22504262)

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:only useful if you start off unencrypted (0)

Anonymous Coward | more than 6 years ago | (#22503974)

The idea is that they might be able to get the decryption key out of your RAM, not your protected contents. Once the attacker has the decryption key, they can decrypt all your hard drive as they please.

Re:only useful if you start off unencrypted (0)

Anonymous Coward | more than 6 years ago | (#22504026)

The situation is much worse than you make it out to be.

So you'd need me to log & open up the TrueCrypt protected data.
No, you don't need to open anything, just have authenticated with Windows sufficiently so that the KEY is in memory.

I pull the plug on the machine, but in the next 3-35 seconds, you manage to read all of RAM.
No, you have a few seconds to tens of minutes to give it power again so that the refresh circuitry kicks. After that, no risk of the data degrading.

Re:only useful if you start off unencrypted (2, Insightful)

Hatta (162192) | more than 6 years ago | (#22504032)

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 (1)

brunes69 (86786) | more than 6 years ago | (#22504346)

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 would take at least 30 seconds to bypass by opening the PC and clearing the BIOS)

In short - if you have data that is important enough to keep secret that it is on an encrypted partition, you shouldn't be leaving it mounted all the time ANYWAY. You should mount it when needed and unmount it as soon as you don't. Thus there won't be any keys in memory to steal.

Re:only useful if you start off unencrypted (1)

Maximum Prophet (716608) | more than 6 years ago | (#22504114)

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:only useful if you start off unencrypted (1)

fastest fascist (1086001) | more than 6 years ago | (#22504466)

Very true, but a different thing. Dismount your encrypted volumes before standing by, if there's any risk of unauthorized access. It's common sense.

Simple remedy (0)

Anonymous Coward | more than 6 years ago | (#22503902)

Seal the computer case in such a way that it takes (decay_time * safety_factor) minutes to go from "physical access" to "memory module in hand". How? Standard office safes usually take about 5 minutes to break... put your sensitive computer(s) in those.

Bonus points for thermite of course.

Physical Access (3, Insightful)

MosesJones (55544) | more than 6 years ago | (#22503914)

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 (4, Informative)

nachoboy (107025) | more than 6 years ago | (#22504138)

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 (4, Insightful)

mypalmike (454265) | more than 6 years ago | (#22504142)

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:Physical Access (2, Interesting)

Qzukk (229616) | more than 6 years ago | (#22504156)

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 than wherever the OS felt it should be copied to on write) after X minutes of inactivity (prompting the user for the key again when they want to use it again).

Re:Physical Access (5, Informative)

TheRaven64 (641858) | more than 6 years ago | (#22504168)

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.

Re:Physical Access (1)

Erioll (229536) | more than 6 years ago | (#22504568)

I would guess it's even worse in the case of laptops, as most of those have a "hibernate" feature, which basically dumps all of your RAM directly to disk and powers down COMPLETELY, which means that even if they don't turn it on, they can just read the RAM image dump that's on the disk. Completely separate from what's talked about here, but seems like it's something that would work.

Re:Physical Access (1)

Charan (563851) | more than 6 years ago | (#22504174)

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

I use FileVault on my Powerbook so that if it did happen to walk away, my personal data would stay safe. This computer stays on (suspended) with me logged in all the time, so it fits your criteria perfectly.

This attack throws the switch on my plans.

Re:Physical Access (1)

sempernoctis (1229258) | more than 6 years ago | (#22504222)

More reliable: hardware keystroke logger...how many of us actually check the back of our machines every time we use them to make sure there aren't any suspicious devices plugged in?

Re:Physical Access (1)

Yath (6378) | more than 6 years ago | (#22504254)

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 off would help.

If you say you wouldn't take your sensitive data home this way, then what was the point of encrypting your hard disk in the first place?

Re:Physical Access (1, Interesting)

Anonymous Coward | more than 6 years ago | (#22504270)

Think criminal investigation. I don't believe I have anything illegal on any of my computers, but given the quantity of laws, I don't really know. I encrypt all my drives just to be sure, and to try to protect the other people who use my hardware remotely.

If the police came busting in with a search warrant I could easily see a situation in which the RAM modules could be popped very shortly after the power was turned off. Now I doubt that this technique will filter down to the average police forensics people for a couple of years, but it is a worry.

Re:Physical Access (1, Insightful)

Anonymous Coward | more than 6 years ago | (#22504352)

Those are all the normal common conditions when trying to crack DRM.

Another win for OSS (-1, Flamebait)

UbuntuLinux (1242150) | more than 6 years ago | (#22503928)

This is the kind of problem you should expect when using hardware designed using properietary, closed-source operating systems like Windows. Due to its closed-source nature, Windows is inefficient, buggy and insecure, which leads directly to faults in hardware like this. For example, in the lab where I work, we have a Windows machine which, due to a flaw in an older Intel architecture (designed using Windows XP) always adds an extra capacitor to any IC's that are designed using it.

With Open Source software, these kinds of bugs *simply do not happen*, and even when they do, the users are able to inspect the source and fix the problems quickly. Just look at AMD; they use Ubuntu Linux to design their circuit boards, and our machines with AMD processors never add extra capacitors.

Where these memory chips to be designed with an Open Source operating system, such as Ubuntu Linux, these kinds of glitches would not find their way into hardware. What is more, running on an Open Source operating system, these bugs would have little effect anyway, as the design of the kernel makes it *impossible* to take advantage of such exploits.

Why don't just reset the motherboard? (1)

sharp_blue (769985) | more than 6 years ago | (#22504002)

From TFA:
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.

But then, just reset the CPU and boot into a memory analysis program, without powering it down. Why bother with potential DRAM errors?

A market opportunity? Workarounds exist. (1)

davidwr (791652) | more than 6 years ago | (#22504018)

New! Improved! Our memory forgets!

Seriously, between overwriting data that is no longer needed, storing sensitive data such as keys encrypted in a daisy-chained manner that includes chain elements on different chips and even in different subsystems such as the graphics controller or on-cpu buffers, and having a small amount of memory storage that really does disappear the minute you pull the plug, this should be a non-issue.

The latter may require extra hardware but the rest can be done on existing equipment.

--

Daisy chained encryption:
Old way: Decryption keys for your opened encrypted disk are stored in RAM.
New way: Decryption keys for your opened encrypted disk are stored in RAM but in an encrypted format. These encrypted keys have a few bytes stripped out to make decryption impossible. The stripped bytes are stored somewhere else, such as in the CPU cache. The keys to unlock the decryption keys are stored somewhere else, such as on the graphics card.
The only place everything is brought together for any length of time is in the CPU or CPU cache. During actual disk access, the cleartext key to the disk is stored in the CPU or its cache, then immediately erased.
Such a system isn't foolproof but it's a lot less vulnerable to a "I had my container open when the cops came to my door equipped with forensic RAM-reading equipment so I pulled the plug on my computer" attack than the old way.

Complete Bullshit (1, Interesting)

Anonymous Coward | more than 6 years ago | (#22504028)

This is just an excuse for some company to sell some kind of snake-oil "RAMWiper" product and try to scare rubes and idiot nontechnical CTOs into believing that they need it.

We've said it time and time again. If the bad guys can get physical access to a machine (which it seems they would need here), all bets are off, and there's nothing you can do about it. Period. The trick is preventing physical access.

Trusted Execution (1)

chadskinner (94261) | more than 6 years ago | (#22504056)

Intel has a technology called TXT that would clear the memory in situations like this before handing control over to the boot medium.

http://www.intel.com/technology/security/ [intel.com]

Physical Access (1)

twiddlingbits (707452) | more than 6 years ago | (#22504058)

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 the system once in a while but you got to be a damned good imposter. If it was your personal/corporate laptop/desktop and you had "Geek Squad" working on a problem you may have an issue. Also, consider the data in RAM is binary and could be anything from OS Code to App Code to data, you really have to know how the layout of how the chips store and access info as well as the structure of the information (what's code, whats data) and how to identify each type of information. Bit decay is also a problem, when you reach a certain time the bits start to decay, and you can't always tell with certainty it's a 1 or a zero. That decay time will vary by mfg, technology, speed of chips, etc. Once you have access to a machine deep enough to pull chips there are MUCH easier hacks, backdoors, trojans, malware, booting your "custom" OS off a thumb drive, burning files to a "backup CD", etc. are all much easier. It's RESEARCH not (yet) a reasonable way to hack the system.

Re:Physical Access (1)

Maximum Prophet (716608) | more than 6 years ago | (#22504184)

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 (4, Insightful)

wiredog (43288) | more than 6 years ago | (#22504084)

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

CPU cache? (1)

Westley (99238) | more than 6 years ago | (#22504096)

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

Re:CPU cache? (2, Interesting)

mzs (595629) | more than 6 years ago | (#22504356)

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.

Not necessarily such a bad thing... (1)

fuzzyfuzzyfungus (1223518) | more than 6 years ago | (#22504130)

The class of devices most likely to be affected(and I'm really not sure that I mind at all) will be the various systems designed with the assumption that the user is the enemy(many cellphones, set top boxes, etc, etc.) Those tend to have fairly small amounts of memory and, since the "attacker" is the owner, plenty of leisurely physical access. I just can't get too worried about that class of attacks, though. When "security" means locking me out of my stuff to benefit some third party bottom line, insecurity is good. This comment applies to the majority of attacks that require somewhat exotic physical access. Remote vulnerabilities and trivial physical attacks are dangerous; but more sophisticated local attacks are what we used to call "user tinkering" and I have every desire for their success.

Firewire and USB can access memory (5, Interesting)

Anonymous Coward | more than 6 years ago | (#22504150)

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 (1)

circletimessquare (444983) | more than 6 years ago | (#22504186)

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:guess what (1)

zappepcs (820751) | more than 6 years ago | (#22504366)

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 put the encryption software and memory in yet another physical location. In this way it is possible to treat different memory locations physically different than others. This would allow for safe wipe of memory at shutdown as well as protected memory for encryption use. Remember kids; 640K is NOT enough for everyone.

Very real concern (5, Interesting)

Deagol (323173) | more than 6 years ago | (#22504198)

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 (0)

Anonymous Coward | more than 6 years ago | (#22504612)

And where is that kernel module going to keep the key that will decrypt those pages when they are needed ?

I think you need to think your cunning "I'll encrypt my password" scheme all the way through.

I can't believe this hasn't been mentioned... (3, Insightful)

gillbates (106458) | more than 6 years ago | (#22504200)

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

Countermeasure here: (4, Interesting)

jetmarc (592741) | more than 6 years ago | (#22504210)

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:Countermeasure here: (1)

Klaus_1250 (987230) | more than 6 years ago | (#22504440)

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.

Re:Countermeasure here: (1)

Anonymous Psychopath (18031) | more than 6 years ago | (#22504726)

Protecting/clearing/overwriting portions of the memory during BIOS boot would work, unless the attacker cooled and moved the DRAM into their own system where the BIOS does not use the same areas, or perhaps the attacker is looking for other information besides the disk encryption key. I think you've already considered this, but it's worth a specific mention.

Dirty fix (2, Insightful)

Anonymous Coward | more than 6 years ago | (#22504252)

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

Already Screwed (3, Interesting)

immcintosh (1089551) | more than 6 years ago | (#22504256)

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 (2, Interesting)

seth_hartbecke (27500) | more than 6 years ago | (#22504258)

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 for it to overwrite the key that it was internally storing.

Then if they manage to break into your super secure datacenter, wheal in their tank of liquid nitrogen and pump your server full of it just so they can steal your RAM chips...it still doesn't get them anything.

(If you read the paper, they talk about how if you cool the chips with liquid nitrogen they keep their contents with power off and removed for 'several hours'...they argue that simply modifying the bios to zero at startup isn't sufficient as they may physically *remove* the ram chips before you have a chance to zero them)

In 1986... (1)

Rick Richardson (87058) | more than 6 years ago | (#22504276)


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

Well known problem to security experts... (1)

gweihir (88907) | more than 6 years ago | (#22504412)

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

Here is our rule of thumb (0)

Anonymous Coward | more than 6 years ago | (#22504470)

If you lost the machine and someone else can now be reasonably assumed to have taken the machine, you have already lost the war and the data contained within. There are other ways to bypass encryption methods on HD's. The real trick is to not keep valuble information on local hard drives. There is a reason Jesus invented TCP/IP and network storage. Not only do you get the bonus of having all your "special stuff" backed up, but your laptop is basically a dumb terminal and the loss or theft of it only incurs the cost of having to replace the laptop. Your data then lives safely in your data center

It's called a good set of policies and procedures with an informed staff. Hell you don't even need an informed staff, just map their home directories or "my documents" folder to the network. Then even the monkeys get it right.

Fix: install BIOS with a memory test. (3, Interesting)

Animats (122034) | more than 6 years ago | (#22504484)

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.

Re:Fix: install BIOS with a memory test. (0)

Anonymous Coward | more than 6 years ago | (#22504616)

I'm afriad they already hot-swapped that out for another BIOS before the reboot...

Basically, physical access == game over.

obvious (0)

Anonymous Coward | more than 6 years ago | (#22504492)

It is not possible to secure anything from an attacker with unlimited physical access to a system whether or not it is a bank vault or computer. I would have thought this is obvious. The best you can hope for is making the attacker's time and the expense required prohibitive or preventing physical access in the first place. Unfortunately attacker's tools tend to improve over time like the technique descibed here.

Secure RAM via onboard scrambler? (1)

mordenkhai (1167617) | more than 6 years ago | (#22504512)

If it was such a big deal that your RAM be secure why dont RAM makers make special "Secure RAM" kits with a small (I am not an engineer, please forgive my ignorance)battery and have it detect power down, and then expend the battery to alter the RAM contents, write all 1's or something? An OS solution wouldn't work if the power was pulled, I expect nearly all legitimate uses of RAM dont need the contents after power down so chances are anyone trying to get at em has nefarious plans.

Use a CPLD and a holdup system (1)

EmagGeek (574360) | more than 6 years ago | (#22504564)

This is an easy fix. Simply put a PLD between the RAM and the memory controller, and have a battery backed supply that runs the memory for a short time after poweroff. When power goes away, the battery backup circuit holds up the PLD and the RAM long enough for a state machine in the PLD to scrub the memory.

Put the key in SRAM. (2, Interesting)

Skapare (16644) | more than 6 years ago | (#22504690)

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? (3, Insightful)

rickb928 (945187) | more than 6 years ago | (#22504698)

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.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...