An anonymous reader writes "Jacob Appelbaum, one of the security researchers who worked on the cold boot attacks to recover encryption keys from memory even after reboot, has announced the release of the complete source code for the utilities at The Last HOPE in New York City. The hope (obligatory pun) is that the release of these tools will help to improve awareness of this attack vector and enable the development of countermeasures and mitigation techniques in both software and hardware. The full research paper (PDF) is also available."
I was there in the room when they released this attack. It was really an interesting idea of taking the memory out before decay happens and putting into another box to read stuff off of it. Of Course Physical security of a machine will solve this problem but it is a very interesting attack.
and not just the machine hardware, but rather the RAM stick itself.
Essentially the exploit relies on data that is in RAM to still exist, even if it's just for a few seconds, if you take it out of the machine.
You could add a 'write random crap to RAM' thing to your shutdown procedure, but that won't help if they simply power the machine off. The machine hardware could write random crap to RAM when it is powered down, but that won't help if they simply yank the RAM stick out while the machine is still running.
So the RAM stick itself would have to detect that it is no longer connected to any motherboard and, using a charge kept in a capacitor, for example, flash itself with random crap.. or whatever.
Keep in mind that this 'exploit' is quite difficult to execute, requiring not just physical access to the machine - but to the RAM. While the machine is running (or was running within the last N seconds, at least). In the vast majority of environments, that's going to be extremely difficult.. unless you own (or operate) that machine and you have no particular way of being caught.
Most server class machines have intrusion detection sensors which will trigger an alarm when the case is opened. They're hardly foolproof, but if you were concerned about this sort of attack then responding appropriately to a "Your Door Is Ajar" event would be a reasonable place to start.
You could add a 'write random crap to RAM' thing to your shutdown procedure, but that won't help if they simply power the machine off.
Actually, one thing that might help would be a "Decrypt then wipe RAM" scheme, where the program decrypts a file, moves the file contents into some form of buffer, then wipes the RAM location where the decryption key was stored (and if necessary, wipe the paging file). It would leave that specific file exposed, but that's a heck of a lot better than leaving the key in RAM.
> So the RAM stick itself would have to detect > that it is no longer connected to any motherboard (...) Have you seen Mission: Impossible? They've done an interesting thing with the laser beams that served as an intrusion detection system there. I wonder if a similar hack could be achieved by plugging out the ram stick, without disconnecting it from the mobo (or rather: sequentially disconnecting it and reconnecting to your hackbox on the fly).
Then again, if it's a server, then a decent intrusion detec
yeah, except when I'm working at a computer and somebody comes over and says "Hi, would you mind terribly if I plug this USB stick in and reboot your machine?", I'd probably say "why yes, I would mind terribly".
And if I'm not at the machine, quite likely, I powered the thing down... that gives the person with the fancy USB stick mere seconds to move in and quickly plug the key in and boot back up.
Don't get me wrong, I already understand that it is possible - just that the situations in which it is possible
You're only imagining scenarios where the attacker is in a criminal minority and the user is in a secure environment that's hostile to the attacker.
What about situations where the attacker is actually a majority on the scene (e.g. a government band of crooks who just rushed into the user's home) and the environment becomes hostile to the user? The attacker has all the time at his disposal, the only thing the user might had time for was quickly powering off the machine. I think that's the scenario that m
I think what the GP was saying is that you could do something like:
After a period of timeout have the computer wipe the encrypted key in memory using DOD passes on the areas of memory the key was in.
Or have the system automatically run a DOD memory wipe on shutdown.
Unless I'm not understanding the problem about the only thing these wouldn't prevent would be a cord-yank-shutdown of the system if the person were fast enough to get to the system before the wipe timeout.
Though it would be much easier to make a power-supply based anti-cord-yank solution because you wouldn't have to change anything in software and you could retrofit older systems with it.
Even that wouldn't help with the hotplug procedure someone posted below.
You can store the keys in video memory, you can't pull those out of a laptop. And yes, it's not only possible but also rather easy. Storing them in the lower part (first 64kb ?) which is used to display the "boot screen" will actually create an automatic sweep. Both backdoors locked.
Yeah, but you can't quickly poweroff a laptop. You have to keep the power button depressed for a couple of seconds, enough for the bad guys to take it away from you.
I remember a number of systems that had case intrusion switches that would alarm. I don't see any reason why that couldn't also be tied in to an autoshutdown procedure that'd wipe the RAM.
Less obviously, the switch could trigger a special watchdog program that knows where your crypto keys are stored, and overwrites them when the sensor goes off.
The way I see this, you should simply not store keys in memory (that is have your encrypted file system mounted) when you not need access to the files. A correct program will overwrite the keys when the file system is dismounted.
The purpose of full disk encryption (or system encryption in TrueCrypt is), in my opinion, not meant as a "one password to protect everything". It's just an extra measure to secure temporary files, the swap file and other tracks the OS and applications may spread around. You should still encrypt your really secret files separately, and use basic precautions such as secure file erasure when you've used them.
That said, I still don't think this attack is so important. If you have the file system mounted, and an attacker gains access to your computer, the files are already there!
The whole point of this is unclean shutdown. How is your computer going to overwrite the keys in memory when someone pulls the plug?
Sometimes the mere presence of a file, encrypted or not, is "incriminating" enough. Ask Kevin Mitnick about NSA.TXT on a floppy he had - it was a listing of a host with the registered users at the National Computer Security Archive, and that got quickly spun to "having compromised the security of the NSA".
Sometimes you want to hid the existence of information, not just the in
That said, I still don't think this attack is so important. If you have the file system mounted, and an attacker gains access to your computer, the files are already there!
This attack is important because until now it has been perceived, that if in a last effort you pull the plug out of your box and render it powerless, your encrypted filesystems will be safe.
The common opinion was that when the DRAM modules get their power cut off and their refreshing stops, all contents are almost immediately lost, a
So a computer is a box. It has four sides, a top and a bottom. Some may not have four sides, this is irrelevant.
The solution to this is a hard hack (well one solution anyway). Case is opened without putting a magnet in JUST the right place (or some other measure) and memory is fried.
Alpha particles cause errors in memory chips - see jargon file [mcgill.ca]:
Intel could not explain random bit drops in their early chips, and one hypothesis was cosmic rays. So they created the World's Largest Lead Safe, using 25 tons of the stuff, and used two identical boards for testing. One was placed in the safe, one outside. The hypothesis was that if cosmic rays were causing the bit drops, they should see a statistically significant difference between the error rates on the two boards. They did not observe such
While it's true that you can bypass any hardhack security system, surprise can be a great asset. Most people, even Law Enforcement, aren't going to expect your computer to fry itself if opened, or whatever system you use. It's the kind of trick that will only work a few times, but a few times is probably enough.
A lot of the new 'cool' law enforcement devices are USB, for easy access and easy reading of the computer. Imagine a computer that has three in-use USB ports and one open slot, and plugging a devic
thermite packed around the ram seems the best way to go. then if they tamper with the case, it triggers a 'tramper switch' the thermite goes off, and boom just a molten blob of goo. also, if you're going to have a self destruct on the ram, you may as well do the HDD as well, and you might as well throw in a manual switch along with the 'tamper switch' in case the FBI comes knocking, and have a good plan for how to circumvent your 'tamper switch'.
thermite is a bit extreme, but if you want your data irretriev
Plug "Mouse Jiggler" into USB port to keep no-activity timeout from causing logout.
Turn on UPS.
Plug HotPlug unit into UPS.
Plug HotPlug unit output plug (a male plug which is a power output) into power strip, or, if necessary, remove wall outlet plate and
connect clamp-on connectors to hot wires.
Unplug power strip from line power. HotPlug unit will switch in power from UPS.
Plug power strip into UPS. HotPlug unit will recognize this and deenergize its output plug.
Unplug HotPlug output plug and input plug. Computer is now running entirely on UPS.
Carry computer and UPS to forensics lab before UPS battery runs down.
It is a clever idea, and it would take a moderate amount of sophistication to allow it to not cause problems with being attached in parallel with the mains. Also, designing it to be at least moderately safe to operate would take some effort.
I'm not sure that the patent would hold up under a challenge. However, these would be used primarily by corporations of some sort (government, private investigators, etc) and they're not going to want to have their employees handling jury-rigged contraptions with 600W
It is of great concern. Many corporate users live in the false sense of security that their (personal and corporate) data is secure should the laptop get stolen. But this no longer holds true if the laptop stolen was either in hibernation mode (sleeping) or just password locked. That might also hold true for the guy that is walking around with millions of SSNs on his laptop, including yours.
One way to make memory contents much more difficult to recover is this. The CPU(s) will have a key stored internal to the CPU chip, in SRAM [wikipedia.org] (memory held in state by power, a technology that does not lend itself to the high density that DRAM [wikipedia.org] does). Initially the CPU runs in "clear mode" and establishes the key. Then it proceeds to encrypt memory, except for the page the encrypt program runs in. Then it enters "crypt mode", which includes a jump to a new address outside of the clear page. In "crypt mode"
In "crypt mode" all memory fetches are decrypted in hardware, and all memory writes are encrypted.
The CPU is not the only entity who writes or reads RAM. Every DMA device does that, such as video, HDD, USB, Ethernet... in fact, most peripherals, including those mounted on the motherboard. Either the key has to be shared with them (which is not secure) or these DMA pages remain unencrypted (which is not secure.)
The one obvious solution here is to implement secure encrypted path to all these devices, li
SRAM is constructed from latching circuits. Anyone knows what's their volatility when compared to DRAM? Do they lose contents immediately when powered off or do they retain the state for some time like DRAM?
If it's the latter then the attack might still be doable on the architecture that you propose because the keys would still be there on the SRAM page in the CPU. The difference is that you couldn't just plug the CPU in to a different unmodified general purpose PC, because CPU initialization during boo
Well but make sure you throw out the machine's power cord before throwing in that towel! This gives you some chances (although this attack decreases them significantly).
Does anybody know whether all current cryptographic implementation properly overwrite memory regions that contained keys when the keys are no longer needed?
I wonder if LUKS (Linux Unified Key Setup) does that properly when you do a "cryptsetup luksClose"?
Once the encrypted filesystem is unmounted and the encrypted device removed, and the encryption key properly overwritten in memory, I figure at that moment you are safe from that attack?
Used to rip music on this Amiga by loading the game (or demo or whatever) warm boot the machine to a shell and dump the contents of memory to disk and look for the appropriate headers.
You could do the same thing on a pc really - just warm boot the pc and don't initialize the ram.
I salute the authors for their efforts, as this is a significant and welcome contribution. But I have to respectfully disagree with this statement:
"There seems to be no easy remedy for these vulnerabilities."
Yes there is. All one has to do is misprogram the DRAM controller. And then wait until DRAM is fully discharged before continuing on with the boot sequence.
For those who aren't familiar with how DRAM controllers work, they are responsible for laying out memory as seen by the CPU. There are a whole b
RE: Editor/Submitter (Score:4, Funny)
I think the editor and submitter both need to read this [thebestpag...iverse.net].
Yup (Score:2, Interesting)
I was there in the room when they released this attack. It was really an interesting idea of taking the memory out before decay happens and putting into another box to read stuff off of it. Of Course Physical security of a machine will solve this problem but it is a very interesting attack.
Re: (Score:2)
Why hasn't the team come forth with a fix for this exploit? They have more knowlege on the subject then I do.
Well, not that I'm too knowledgeable in the domain, but don't encryption keys and such need to be decoded at some point in memory to be used?
because the fix would have to be in-hardware (Score:5, Informative)
and not just the machine hardware, but rather the RAM stick itself.
Essentially the exploit relies on data that is in RAM to still exist, even if it's just for a few seconds, if you take it out of the machine.
You could add a 'write random crap to RAM' thing to your shutdown procedure, but that won't help if they simply power the machine off.
The machine hardware could write random crap to RAM when it is powered down, but that won't help if they simply yank the RAM stick out while the machine is still running.
So the RAM stick itself would have to detect that it is no longer connected to any motherboard and, using a charge kept in a capacitor, for example, flash itself with random crap.. or whatever.
Keep in mind that this 'exploit' is quite difficult to execute, requiring not just physical access to the machine - but to the RAM. While the machine is running (or was running within the last N seconds, at least). In the vast majority of environments, that's going to be extremely difficult.. unless you own (or operate) that machine and you have no particular way of being caught.
Parent
Re:because the fix would have to be in-hardware (Score:5, Insightful)
Parent
Re: (Score:3, Insightful)
You could add a 'write random crap to RAM' thing to your shutdown procedure, but that won't help if they simply power the machine off.
Actually, one thing that might help would be a "Decrypt then wipe RAM" scheme, where the program decrypts a file, moves the file contents into some form of buffer, then wipes the RAM location where the decryption key was stored (and if necessary, wipe the paging file). It would leave that specific file exposed, but that's a heck of a lot better than leaving the key in RAM.
Re: (Score:3, Informative)
But then you'd have to input your passphrase each time you open a bloody file. Well if there's only few very important files, it's acceptable.
Re: (Score:3)
Security versus convenience. If you have no files (or relatively few files) that require this level of security, use a more convenient method.
Re: (Score:2)
> that it is no longer connected to any motherboard (...)
Have you seen Mission: Impossible? They've done an interesting thing with the laser beams that served as an intrusion detection system there. I wonder if a similar hack could be achieved by plugging out the ram stick, without disconnecting it from the mobo (or rather: sequentially disconnecting it and reconnecting to your hackbox on the fly).
Then again, if it's a server, then a decent intrusion detec
Re: (Score:3, Insightful)
Re: (Score:2)
yeah, except when I'm working at a computer and somebody comes over and says "Hi, would you mind terribly if I plug this USB stick in and reboot your machine?", I'd probably say "why yes, I would mind terribly".
And if I'm not at the machine, quite likely, I powered the thing down... that gives the person with the fancy USB stick mere seconds to move in and quickly plug the key in and boot back up.
Don't get me wrong, I already understand that it is possible - just that the situations in which it is possible
Re: (Score:2)
You're only imagining scenarios where the attacker is in a criminal minority and the user is in a secure environment that's hostile to the attacker.
What about situations where the attacker is actually a majority on the scene (e.g. a government band of crooks who just rushed into the user's home) and the environment becomes hostile to the user? The attacker has all the time at his disposal, the only thing the user might had time for was quickly powering off the machine. I think that's the scenario that m
Re: (Score:3, Funny)
Re: (Score:2)
Some partial fixes are possible and were discussed a while ago.
http://thread.gmane.org/gmane.comp.encryption.general/11528 [gmane.org]
Memory wiper? (Score:2)
Isn't there a memory wiping utility that fills the memory with random noise?
Re:Memory wiper? (Score:5, Informative)
You cool the chips down in the running computer with a spray duster, pull them out, and put them in a computer that you control.
No software solution can be used to stop you doing this, it has to be a hardware based solution.
Parent
Re: (Score:2)
After a period of timeout have the computer wipe the encrypted key in memory using DOD passes on the areas of memory the key was in.
Or have the system automatically run a DOD memory wipe on shutdown.
Unless I'm not understanding the problem about the only thing these wouldn't prevent would be a cord-yank-shutdown of the system if the person were fast enough to get to the system before the wipe timeout.
There'd obviously be overhead in the
Re: (Score:2)
After you wipe the key from memory, you are going to need to have some user interaction to remount the disk. That may not be practical.
Re: (Score:2)
I don't think this exploit is a serious issue while the person is working. The minute they walk away or lock their screen though...
Re: (Score:2)
Though it would be much easier to make a power-supply based anti-cord-yank solution because you wouldn't have to change anything in software and you could retrofit older systems with it.
Even that wouldn't help with the hotplug procedure someone posted below.
Re: (Score:2, Interesting)
Re: (Score:2)
Yeah, but you can't quickly poweroff a laptop. You have to keep the power button depressed for a couple of seconds, enough for the bad guys to take it away from you.
Re: (Score:2)
Theres a hardware solution, its called a boot to the head.
Re: (Score:2)
I remember a number of systems that had case intrusion switches that would alarm. I don't see any reason why that couldn't also be tied in to an autoshutdown procedure that'd wipe the RAM.
Less obviously, the switch could trigger a special watchdog program that knows where your crypto keys are stored, and overwrites them when the sensor goes off.
There are some ways to minimize the problem (Score:5, Interesting)
The purpose of full disk encryption (or system encryption in TrueCrypt is), in my opinion, not meant as a "one password to protect everything". It's just an extra measure to secure temporary files, the swap file and other tracks the OS and applications may spread around. You should still encrypt your really secret files separately, and use basic precautions such as secure file erasure when you've used them.
That said, I still don't think this attack is so important. If you have the file system mounted, and an attacker gains access to your computer, the files are already there!
Re: (Score:3, Interesting)
The whole point of this is unclean shutdown. How is your computer going to overwrite the keys in memory when someone pulls the plug?
Sometimes the mere presence of a file, encrypted or not, is "incriminating" enough. Ask Kevin Mitnick about NSA.TXT on a floppy he had - it was a listing of a host with the registered users at the National Computer Security Archive, and that got quickly spun to "having compromised the security of the NSA".
Sometimes you want to hid the existence of information, not just the in
Re: (Score:2)
This attack is important because until now it has been perceived, that if in a last effort you pull the plug out of your box and render it powerless, your encrypted filesystems will be safe.
The common opinion was that when the DRAM modules get their power cut off and their refreshing stops, all contents are almost immediately lost, a
Tamper proof case, anyone? (Score:2)
So a computer is a box. It has four sides, a top and a bottom. Some may not have four sides, this is irrelevant.
The solution to this is a hard hack (well one solution anyway). Case is opened without putting a magnet in JUST the right place (or some other measure) and memory is fried.
Do X rays fry memory? Anyone?
Re: (Score:2)
By "do X rays fry memory" I mean, will they scrub chips of any data (I was not speaking about damage when I said 'fry')
Re: (Score:2)
Alpha particles cause errors in memory chips - see jargon file [mcgill.ca]:
Re: (Score:2, Interesting)
Re: (Score:2, Interesting)
A lot of the new 'cool' law enforcement devices are USB, for easy access and easy reading of the computer. Imagine a computer that has three in-use USB ports and one open slot, and plugging a devic
Re: (Score:3, Insightful)
thermite packed around the ram seems the best way to go. then if they tamper with the case, it triggers a 'tramper switch' the thermite goes off, and boom just a molten blob of goo. also, if you're going to have a self destruct on the ram, you may as well do the HDD as well, and you might as well throw in a manual switch along with the 'tamper switch' in case the FBI comes knocking, and have a good plan for how to circumvent your 'tamper switch'.
thermite is a bit extreme, but if you want your data irretriev
Capturing machines with full disk encryption (Score:5, Interesting)
Here's the existing approach to this problem.
Re: (Score:2)
Re:Capturing machines with full disk encryption (Score:4, Funny)
looks like a forced login every 10 minutes is a good idea for people working with really sensitive data.
108 minutes is more like it
Parent
Re:Capturing machines with full disk encryption (Score:4, Funny)
13. Try not to get hit by truck as you maneuver Frogger machine across street.
Parent
Re: (Score:2)
Or better still - pack each PC with a small vial containing enough hydrofluoric acid to dissolve the internals ....
have trip switches which cause the acid to be sprayed from the container over the inside of the PC.
Good bye most bits of the PC bar any telfon or polyethelene bits (and it will dissolve most oxides so that should fix the HDD nicely)
Re: (Score:2)
It is a clever idea, and it would take a moderate amount of sophistication to allow it to not cause problems with being attached in parallel with the mains. Also, designing it to be at least moderately safe to operate would take some effort.
I'm not sure that the patent would hold up under a challenge. However, these would be used primarily by corporations of some sort (government, private investigators, etc) and they're not going to want to have their employees handling jury-rigged contraptions with 600W
not such a big deal (Score:2)
Among the many things that can be done to a machine when someone has physical access, this isn't my primary worry.
And if you don't run encrypted swap space, don't worry about this.
Re: (Score:2)
It is of great concern. Many corporate users live in the false sense of security that their (personal and corporate) data is secure should the laptop get stolen. But this no longer holds true if the laptop stolen was either in hibernation mode (sleeping) or just password locked. That might also hold true for the guy that is walking around with millions of SSNs on his laptop, including yours.
Privatizing memory contents (Score:2)
One way to make memory contents much more difficult to recover is this. The CPU(s) will have a key stored internal to the CPU chip, in SRAM [wikipedia.org] (memory held in state by power, a technology that does not lend itself to the high density that DRAM [wikipedia.org] does). Initially the CPU runs in "clear mode" and establishes the key. Then it proceeds to encrypt memory, except for the page the encrypt program runs in. Then it enters "crypt mode", which includes a jump to a new address outside of the clear page. In "crypt mode"
Re: (Score:2)
In "crypt mode" all memory fetches are decrypted in hardware, and all memory writes are encrypted.
The CPU is not the only entity who writes or reads RAM. Every DMA device does that, such as video, HDD, USB, Ethernet... in fact, most peripherals, including those mounted on the motherboard. Either the key has to be shared with them (which is not secure) or these DMA pages remain unencrypted (which is not secure.)
The one obvious solution here is to implement secure encrypted path to all these devices, li
Re: (Score:2)
SRAM is constructed from latching circuits. Anyone knows what's their volatility when compared to DRAM? Do they lose contents immediately when powered off or do they retain the state for some time like DRAM?
If it's the latter then the attack might still be doable on the architecture that you propose because the keys would still be there on the SRAM page in the CPU. The difference is that you couldn't just plug the CPU in to a different unmodified general purpose PC, because CPU initialization during boo
Physical access (Score:2)
If the attacker has physical access to the machine to begin with, you might as well throw in the towel.
Re: (Score:2)
Well but make sure you throw out the machine's power cord before throwing in that towel! This gives you some chances (although this attack decreases them significantly).
Proper overwriting of unusedkey material in memory (Score:2)
Does anybody know whether all current cryptographic implementation properly overwrite memory regions that contained keys when the keys are no longer needed?
I wonder if LUKS (Linux Unified Key Setup) does that properly when you do a "cryptsetup luksClose"?
Once the encrypted filesystem is unmounted and the encrypted device removed, and the encryption key properly overwritten in memory, I figure at that moment you are safe from that attack?
Obligatory puns (Score:2)
Nobody cares if your puns were intended. [thebestpag...iverse.net]
Nothing new really (Score:2)
Used to rip music on this Amiga by loading the game (or demo or whatever) warm boot the machine to a shell and dump the contents of memory to disk and look for the appropriate headers.
You could do the same thing on a pc really - just warm boot the pc and don't initialize the ram.
The Authors missed something significant (Score:2)
"There seems to be no easy remedy for these vulnerabilities."
Yes there is. All one has to do is misprogram the DRAM controller. And then wait until DRAM is fully discharged before continuing on with the boot sequence.
For those who aren't familiar with how DRAM controllers work, they are responsible for laying out memory as seen by the CPU. There are a whole b