Slashdot Mirror
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."
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.
Crackin' Wise - Blogging about whatever we want
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.
An Eye for an Eye will make the whole world blind - Gandhi
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.
Namaste
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.
t
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.
Give me Classic Slashdot or give me death!
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.
If the attacker has physical access to your system, it's not your system.
Best Slashdot Co
Hrm, especially if they were in hibernate mode to start with....
In Xanadu did Kubla Khan
A stately pleasure dome decree
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 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.
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.
Method of processing duck feet
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...
The society for a thought-free internet welcomes you.
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
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.
---- Teach Peace. It's Cheaper Than War.
Solder RAM to board.
Password the BIOS, boot only from local disk.
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.
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)
END
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.
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.
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.
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.
The living have better things to do than to continue hating the dead.
has the RAM soldered in the motherboard! I knew Apple was thinking of our security all along!!!
/*ducks*/
Where is that guy who'd die defending what I had to say when I need him?
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.
Curiosity was framed, Ignorance killed the cat.
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.
now we need to go OSS in diesel cars
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.
deleting the extra space after periods so i can stay relevant, yeah.
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.
- Is the Cardbus slot always enabled or must the OS enable it? (If the OS has to enable the cardbus slot you can be safe if the OS doesn't probe the slots when the screen is locked.)
- If the OS enables the Cardbus slot can it stop the device from doing bus mastering before the device has been identified and a driver has been loaded?
(If so you only have to mimic a card which the OS has drivers for to work around it though.)
Creating a cardbus card isn't exactly rocket science. You could probably do it in a weekend with off the shelf components for less than $200 unles Murphy is feeling creative...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.
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-AES is the 3rd most popular disk encryption tool in Linux. See the KEYSCRUB=y option in its README file:
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
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).
As someone pointed out to me a few days ago: Firewire (usually?) has DMA access, so it would be possible to interface the laptop via firewire and do a full memory dump. Then go to work on that to get the key. - requires physical access to the powered laptop of course. Of course, if you have no firewire devices you could have a script do a 'shutdown -H now' on detection of a firewire device.
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.
Curiosity was framed, Ignorance killed the cat.
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.
Reading code is like reading the dictionary - you have to read half of it before you can go back and understand it.
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".
I think the word you're looking for is "tenet".
[100% ISO 646 Compliant]
SVM, ERGO MONSTRO.
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.
This seems most useful as a way to help crack DRM and bypassing OS level 'trusted computing' type measures. Since it requires a machine operating with the key active it isn't much use for things like decrypting a stolen laptop.
This program was made possible by a grant from the Ultra-Humanite, and viewers like you.
Is that absolute security? Well, an outsider couldn't break the encryption. To do so requires the pad. There are no shortcuts. That's pretty absolute. And even with the pad, you need the offset and stepsize. I've been told of systems where these were mechanically random - the one-time pad tapes synchronized themselves remotely at a speed that was effectively non-deterministic, consuming a non-derministic amount of tape to do so, giving you the random offset and step size.
Ok, well is that perfect? Since not even the people with the machines could tell you in advance at what speed or at what point the synchronization would lock, that's pretty damn secure and could not possibly be known in advance. Thus, an attacker cannot have prior knowledge of the key being used. Nobody can, even if they have all of the physical components.
Yes yes yes, it's secure, but is it perfect? It all depends on what you mean by perfect:
It is not "perfect" in the general sense, because if person A can decrypt the message with some information in their posession (A'), then person B can also decrypt the message with that same information (A').
If you have N people in a group, how many of that N must be honest in order to guarantee that information from A to C reaches C even if at least one traitor B exists in that group, where C is not a traitor? The answer is (N/2)+1.
Now, if (N/2)+1 out of N must be honest, can we improve on our encryption system? In order to get the pad to C, we could make a copy and break it down into random-sized fragments (that may or may not have holes), such that you need (N/2)+1 fragments out of the original N in order to rebuild the tape in the correct sequence. Even if everyone else was a traitor and cooperating with each other, they could not reconstruct the key.
Now, to prevent said traitors tampering with the key, each fragment needs to be securely digitally signed. This means that A must have a key that everyone else can test against (and therefore decrypt) but nobody else can derive. Both the intended target and all traitors will thus know which fragments are real, but a traitor will not be able to make a fictional fragment look real.
Is this perfect now? It depends so much on what you mean by perfect. It's now impractical to attack in transit, provided the algorithms themselves do not have weaknesses which push below the assumed security threshold. Provided both source and destination are themselves genuine, AND provided both source and destination have internal compartmentalization such that if/when attacked, the attacker will not be exposed to the encrypted message, the decrypted message or the decryption key, you have an admirable level of security.
But is it perfect? Define perfect. I would consider any system that is so secure that it would never form a part of the attack vector for the forseeable future to be - in any practical sense - perfect. No matter how much you added to it, it would make no difference to what anyone did or how anyone acted. It's perfect in that attackers would spend their resources attacking anything and everything else. Even if it were "perfect" in some abstract, theoretical sense, it would not add ANY additional security to the system. To me, that is perfect in the meaningful sense.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
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.
Oh, say does that Star-Spangled Banner entwine / The myrtle of Venus with Bacchus's vine?
> 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?
Truecrypt's keyfile is only a precursor to the actual decryption key. It is not accessed after the drive is mounted. Once the drive is mounted, everything that is needed to read the disk is in memory. (namely, the decryption key).
So, whatever drive or partition you have mounted (whether hidden or otherwise) is accessible to anyone who can read your computer's memory.
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.
I 'll compute on my head
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 rows would be the previous screen. Sometimes with garbage characters interspersed, depending on how long the computer was off.
I never did investigate how long the non-screen portions of the memory lasted, but the screen-portions (starting at $300, I think) would be gone in ten seconds.