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
Time for memory controllers with hardware encryption.
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?
In Xanadu did Kubla Khan
A stately pleasure dome decree
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.
I want to delete my account but Slashdot doesn't allow it.
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
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?
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.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
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.
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/
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.
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
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...
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.
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.
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.
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
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
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
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.
Give a man a fish and you have fed him for today. Teach a man to fish, and he'll say "WHERE'S MY FISH, YOU IDIOT?"
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
I pulled a PIC-4 uP out from a circuit. The DRAM stayed non-refeshed for 2 minutes...
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.
... 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.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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.
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.
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.
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?
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.
This attack is probably very real and interesting research, but you have to ask yourself who are you protecting yourself from. A stolen computer with an boot password protected, encrypted hard drive will be formatted long before it hits the streets and that will be the end of it. If you are concerned about government agencies reading your encrypted files, there so many other way to get to it... Especially if you have access to the hardware. Old school ICE (in circuit emulation) will give you 100% reliability and defeats Bitlocker/TPM. Password protect your encrypted drive and move on...
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.
...someone canceled their WoW account, and has free time on their hands ;)
- 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).
This is my suggestion precisely. In critical circumstances, move the encryption just outside of the execution core.. just past the internal CPU caches and into the memory controller. The keys should be regenerated on reset assertions, and memory caching modes would have to be used correctly to assure that info written to devices other than system ram is not encrypted.
It's got a huge performance penalty, but it's simple.
I found (admittedly some 20 years ago now) on a very simple computer with SRAM memory that, after powering it off and on again, a significant percentage of the contents of the memory were still the same. Naturally, the longer you left it the more random the results became. Of course, it was CMOS RAM, so the transistors would have some capacitance which would account for the, err, memory.
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 sure there's some way to hotswap a normal RAM module without frying it, even if it involves attaching extra ground wires for a while.
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".
HIB can be disabled in most OSes. This disables USB mice.
Hardware shock-detectors can be added. If your computer moves, the OS knows and can take appropriate action.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Even better solution: Provide cryptographic support in the CPU and store the keys there, or lacking that just some extra storage for key schedules. Only 240 bytes of storage are needed for a full AES-256 key schedule, twice that for fast encryption and decryption with the most common implementation.
It would be much harder to extract the key schedule from the CPU hardware with the system running, and much easier for the CPU to wipe the storage upon loss of power. As long as the OS wiped the key and passphrase (or any other key source) from RAM upon startup, the key should remain secure.
This could probably be implemented with a few MSRs (model specific registers) for backward compatibility while still retaining a high speed software implementation of the cipher.
I think the word you're looking for is "tenet".
[100% ISO 646 Compliant]
SVM, ERGO MONSTRO.
The class covered those things as well: lock the page in memory, and ensure that the compiler doesn't elide the call to memset(buffer,0,len) by reading back the data. A recent discussion on a crypto mailing list discussed this latter issue at great length, and the consensus was that while theoretically possible, no compiler actually elided calls to memset(), even if the compiler could prove that the memory would never be accessed again.
The society for a thought-free internet welcomes you.
Static RAM remembers only as long as it has power. But it does not need an active refresh signal, just power. Flip flops need power to retain their state.
http://en.wikipedia.org/wiki/Static_RAM
Dynamic Ram needs both power and an active refresh signal.
http://en.wikipedia.org/wiki/Dynamic_RAM
You may be thinking of Flash ram, as is used in thumb drives. This uses electrically erasable programmable read only memory (eeproms)
http://en.wikipedia.org/wiki/Flash_memory
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.
Okay, you posted AC so I feel no compunctions against pointing out how blindingly stupid you are. How can the bad guys take your hard drive, put it in their machine, and get your encryption key out of it? Hell, put a thermite grenade triggered by a tamper switch inside the case. Problem solved.
- None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
Zombie Memory attacks! Seriously, for most people this is a non-concern. The effort required to develop an attack this way is comparable to your average IMF mission. I suppose it might conceivably be an issue for those in high-security environments, like those who use NSA linux, but damn if anybody else really needs to worry about it.
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)
If I just
1. pull the plug
2. pull your RAM
3. insert your RAM into my computer
How about
1. use a master password to generate a passphrase at login-time. This passphrase is stored in and only in the memory controller.
2. this key will be used to real-time encrypt the RAM contents with a symmetric key cipher - so plaintext would only exist on the FSB between the CPU and the Northbridge.
3. this small, special storage in the memory controller is guaranteed to be zeroed within a short hard limit if not powered.
Of course you can design new RAM that does this, but assume this new RAM is more expensive, sparing a KB or two of some special storage just for the key would be enough.
Of course, the short key vs the large memory capacity, and the fact that memory is used piece-by-piece, would mean a lot of potential for known-ciphertext-attacks.
However, cracking with partially-damaged ciphertext is quite a bit more difficult than with either intact ciphertext or damaged plaintext.
Yes that was the word I was looking for, thank you.
Curiosity was framed, Ignorance killed the cat.
It would be relatively easy for DRAM to be augmented with internal circuitry that nukes the ram cells if they have not been placed in slef-refresh mode.
Engineering is the art of compromise.
context is key i guess
in the realm of casual slashdot comments, i think my words ring true and yours paranoid
but in the realm of a healthcare company's IT dept discussing what to do about the laptops of travelling executives containing member's medical information, my words would ring irresponsible and lazy, and yours ring prudent and exemplary
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
Now, type three lines of code: Scan the screen printout and see if there is anything that scares you! Sure managed to scare my computer teacher and muck up my HS's lab computers back in the 1980's, hee hee. Good old Corvis.
Slashdot "libertarians": Small government for me, big government for those I disagree with. -1, I disagree with you
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
The implication from TFA was that, if the target machine was preventing booting to anything but the internal hard drive, the attacker could open it and remove the hard drive and replace it with their own, which would presumably have the memory-dump/sift-for-keys software on it so they can get the keys from the rebooted RAM. Then they could either replace the target hard drive back into the target machine or, now having the keys, use them on it once installed in a different machine.
"God is a comedian playing to an audience too afraid to laugh." -- Voltaire
they need to gain access withing 60 seconds of turning off the power, and that's best case. Most likely they need access within seconds.
That mean as soon as you shut down, someone would have to jump in and reboot. really not going to happen is it?
If someone has gotten in, they would just point a gun at your head and make you give them access..or just step away from the keyboard.
Not a big deal.
The Kruger Dunning explains most post on
Ah, so you would put a new hard drive in and boot from it to use the sift for keys/memory dump software. Unless I'm missing something, you've now wiped the key from RAM, the only place it is ever stored.
- None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
For this reason anyone who is worried they might suddenly be raided might want to install a panic button. Pressing it would erase the encryption key from memory instantly, then set about wiping the rest of the computers RAM.
Have it also activate if the case is opened or a special suicide password is entered (in case you leave your PC on at the login prompt or screen saver).
Either that or just wire your doorbell to small bomb strapped to your RAM. That way when the CIA ring your bell...
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
With respect, you are missing something.. This is the main point of the article, in fact: that the bits don't actually decay appreciably inside of about the first minute after power is removed from the memory module(s).
Admittedly, the hard drive swap would have to be performed relatively quickly (under a minute, based on the average decay time listed in TFA/TFPDF), but since much disassembly can take place before putting the computer into a powered-off state (i.e. opening cases, removing covers, etc.) and since most computer manufacturers have been making it blood simple to replace hard drives in their computers (including laptops) -- often without need of a screwdriver (except laptops) -- this doesn't realistically present much of a challenge. Actually, it's even easier than that since all we're really talking about is opening the case/cover, getting to a point where the data and/or power cable(s) can be removed, powering off, removing the data and/or power connectors and reattaching them to the attacking drive and then powering back on.
Even if that process takes more than a minute, the window of opportunity before the data bits in RAM start to decay can be greatly extended (by almost an order of magnitude) by "pre-freezing" the RAM prior to the power-down via application of a refrigerant (e.g. from an air-duster can held upside down so as to expel its contents as a liquid instead of a gas).
The other important piece of this is of course the custom memory-dump/key-sifting software, which in this case is run from a micro linux distribution pared down to the bare essential task of dumping the apparent memory contents to a file and then sifting through those contents for very well known patterns of code which constitute encryption keys of a specific type. The article is noticeably lacking in low-level specifics in this regard, but the implication is that when running it overwrites so little of the system's memory space and in memory addresses not likely to contain or which cannot possibly contain the desired data that recovery becomes a virtual certainty.
And this is all only if the system's rightful owner has locked the BIOS to disallow booting to anything other than the internal hard drive. It's much easier in all other scenarios.
"God is a comedian playing to an audience too afraid to laugh." -- Voltaire
I read the paper today and was rather depressed that this seems to be all bad news for us folks who value our privacy in that it makes our encryption more vulnerable. Then I saw the bright side: It makes *everyones* encryption more vulnerable including DRM schemes. So even if they do lock us out using DRM you can cool the RAM and get it out of the machine (or just clip on and read it out after power-off of the host system) and read out the encryption keys used by the DRM.
Overall I think this may be a very worthwhile trade. The chances of someone actually performing this attack on my physical hardware while the encryption key for my encrypted volume is in RAM are slim. I keep it unmounted when it is not needed. And they need to have physical access which means they are either feds or really determined crooks.
But my chances of being able to benefit from cracked DRM via this method are great. It only takes one person to do it and millions of people will have access to the hardware.
I don't care if somebody does get my files...It's my password I want to protect! I'd be embarrassed if anybody knew it was L3zp0Rn. Do mom's read Slashdot?
I disagree. If you've read the paper, you'll see that the researchers use refrigerant (compressed air bottle turned outside down so contents come out in liquid form and very cold) to sustain the contents of the DRAM for several minutes (rather than the seconds that that data would last at room temp). The Princeton researchers seem to know what they're talking about in their paper, so I'd say this is a credible threat.
Having said that, it still requires a certain amount of effort, timing, and, ideally, luck. Also, it does not appear possible at all (using this attack vector) when using on-board encryption such as Seagate's Momentus drive.
What to expect in the future? The attack is hardware-based, and a real solution will be hardware-based as well. FDE software can go so far as to use obfuscation tactics to make analysis more difficult in the meantime, though the threat will still exist so long as the hardware is vulnerable.
This story is another reason why state legislatures should not mandate encryption as a data security procedure.
Benjamin Wright, Dallas, Texas, benjaminwright.us
If you got the wrong sort of garbage in RAM on a Commodore 128 there was no way to reset it. You had to unplug it and go for lunch while the RAM lost its contents.
No sig today...
Sure this is an interesting idea, but lets be honest, it's not plausible. If you have physical access to a sensitive machine, or network for that matter, there are plenty of other avenues to explore that would require 1/100th of the complexity this article speaks of with a greater "success" rate.
The immediate solution is obviously to just make it hard enough to open the case of the computer - make it take too long to get at the RAM and extract it.
So... Make sure all enclosure screws are in, add the padlock there's usually a eyelet for, and obviously make sure to cut the power as soon as you realize it's a raid. I know TrueCrypt has a very nice hotkey mechanism that will dismount one or all crypto drives upon activation, and I know most OS's are able to actually power down the system at the end of the shutdown sequence. So, make it possible to use a hotkey or (even better) an external trigger (like a physical intrusion detection system) to dismount drives, scramble the memory used for keys and go straight to a full powerdown. That would competely invalidate this cold attack.
"For every complex problem, there is a solution that is simple, neat, and wrong." -- H.L. Mencken (1880-1956) --
Maybe. But just imagine an office full of people who've wandered off to lunch leaving their clients locked. Shove in a small USB key and hit the power button - grabs keys and dumps drive to disk in a reasonably short time (and you can just wander off out the way whilst it's dumping). They come back and all they notice is that their machine has mysteriously rebooted. Alternatively you could just install an FTP client that'll happily trickle out the contents of their machine throughout the afternoon. Brute force decryption, as far as I'm aware the only previous way of cracking the HD would involve removing the machine and making the theft easily visible ("Where's my laptop gone?"). I'm not quite sure why the linked article was so excited about cooling the memory to keep it stable for minutes - yes it's very clever being able to move it to another machine, but somewhat pointless. Should've just focussed on "I can rip off your encrypted drive with a reboot"
I'd like to know who marked "theaveng" posting as a troll?
That wasn't a troll. In fact it was quite informative to learn how the U.S. government protects its laptops.
The government is not your daddy. Its purpose is not to raid middle-class neighbors' wallets and give it to you.
Hard connect the RAM sticks to the motherboard. Oh, and armor the connection path so that cracking it off destroys the RAM.
Hi all, can anybody please send me the original paper? It's not accessible anymore: http://citp.princeton.edu.nyud.net/pub/coldboot.pdf wget http://citp.princeton.edu.nyud.net/pub/coldboot.pdf --16:14:16-- http://citp.princeton.edu.nyud.net/pub/coldboot.pdf => `coldboot.pdf' Resolving citp.princeton.edu.nyud.net... 140.192.249.204, 128.6.192.156, 128.31.1.13 Connecting to citp.princeton.edu.nyud.net|140.192.249.204|:80... connected. HTTP request sent, awaiting response... 502 Bad Gateway 16:15:04 ERROR 502: Bad Gateway. Thanks a lot Jiri
what if you dident store the key in the ram instead you store it in a removable flash memory maybe one where you nead your finger print and password to unlock the key and its is only unlock so long the flash memory is connected or the computer is on? The flash memory should also be tamper proof and impossible to read whit out the korekt finger print and password.
Comment removed based on user account deletion
http://toolmonger.com/2007/10/25/thermite-fixes-everything/
Try also my gallery: http://photo.net/photos/AntrygRevo
Comment removed based on user account deletion
My personal favorite way to fight this would be wire up the outlet the computer is running from to 230V, while of course giving no indication that it's anything other than a standard outlet. Most computer equipment will run on that, but it stands a pretty good chance of blowing up their UPS if they don't check for it first.
If I remember correctly, when setting up PGP, it mentioned this type of attack and their countermeasures. From the Help File: ..."
...."
" Passphrase Erasure
When you enter a passphrase, PGP Desktop uses it only for a brief time, then erases it from memory. PGP Desktop also avoids making copies of the passphrase. The result is that your passphrase typically remains in memory for only a fraction of a second.
" Memory Static Ion Migration Protection
When you mount a PGP Virtual Disk volume, your passphrase is turned into a key. This key is used to encrypt and decrypt the data on your PGP Virtual Disk volume. While the passphrase is erased from memory immediately, the key (from which your passphrase cannot be derived) remains in memory while the disk is mounted. This key is protected from virtual memory; however, if a certain section of memory stores the exact same data for extremely long periods of time without being turned off or reset, that memory tends to retain a static charge, which could be read by attackers. If your PGP Virtual Disk volume is mounted for long periods, over time, detectable traces of your key could be retained in memory. Devices exist that could recover the key. You won't find such devices at your neighborhood electronics shop, but major governments are likely to have a few.
PGP Desktop protects against this by keeping two copies of the key in RAM, one normal copy and one bit-inverted copy, and inverting both copies every few seconds.