Slashdot Mirror
Cold Boot Attack Utilities Released At HOPE Conference
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 think the editor and submitter both need to read this.
Random Thoughts From A Diseased Mind (Not For Dummies)
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.
If you want to imagine the future, picture a cold boot attack on a human face, over and over, forever.
Unknown host pong.
Isn't there a memory wiping utility that fills the memory with random noise?
Knowledge is power. Knowledge shared is power lost.
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!
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.
Stealing a sensitive laptop to test these tools on
(Captcha: prisons)
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?
Here's the existing approach to this problem.
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.
13. PROFIT!!!
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 (memory held in state by power, a technology that does not lend itself to the high density that DRAM 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" all memory fetches are decrypted in hardware, and all memory writes are encrypted. The one page that was not encrypted is now reclaimed, wiped, and made available for other uses.
Simple XOR encryption will not work. Much of memory is written with zeros or predictable data. That would make recovering this key trivial. What is needed is a type of encryption that makes the key recovery impossible or at least very difficult. One possible approach is to combine the key and address and produce a checksum that is used to do the actual memory contents encryption or decryption. The problem with all this is that it would slow down memory a great deal. But maybe by doing this only on select portions of memory, it becomes a practical tradeoff.
But maybe it is enough to just have a page of SRAM inside the CPU chip itself, where the normal data keys can be kept by the kernel, which will have to be sure to clean up after any cryptographic operations in regular DRAM.
now we need to go OSS in diesel cars
If the attacker has physical access to the machine to begin with, you might as well throw in the towel.
Where does the school board find them and why do they keep sending them to ME?
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?
Nobody cares if your puns were intended.
Slashdot: Failed Car Analogies. Amateur Lawyering. Anecdote Battles.
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.
"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 bunch of parameters which the DRAM module supplies, and the DRAM controller needs, in order for RAM to work. Usually this is all done fairly automatically and quite quickly as one of the very first things which happens when you boot up. If the DRAM controller is misprogrammed, then all of your memory accesses are at best scrambled. At worst, you can't even get to the various memory locations.
Good luck getting around that. While it's still not impossible, it does significantly raise the bar enough to defeat any attack via the CPU (as in booting these types of utilities, instead of an OS). I believe it would also defeat any bus-based attacks, say via a compromised PCI card, or a USB card. Perhaps I'm mistaken there, as I really haven't thought the latter cases through, and whether there's a way to cheat.
As an aside, yes, this trick has been known for years in the industry. For certain products that I've worked on, it's been tempting to use this in order to speed up the warm boot cycle. The problem is that the results from this type of behaviour are completely unspecified. So it's not something that you want to do in a commercial product. At least not lightly, when your reputation is on the line.
The best way to predict the future is to create it. - Peter Drucker.
The parent poster to this post shouldn't be marked as insightful as the poster hasn't got a single clue what they are talking about. Quote:thermite goes off, and boom just a molten blob of goo.
Goes off? Boom?!? WTF?!? The poster obviously hasn't even got a basic clue what they are talking about. Indeed to quote wikipedia at a basic level: "....It is not explosive, but can create short bursts of extremely high temperatures focused on a very small target for a short period of time...."
Hence why Thermite is used to do things such as weld metals such as railway lines together rather than an explosive which strangely has the opposite effect. It also doesn't just go off either!
The following is we implemented in our shop to prevent cold-boot attacks. Our shop is a Panasonic Toughbook shop, so keep that in mind as some features in the Toughbook line of laptops may not be available, but most of them are.
1.) Establish a system administrator password in the BIOS. Also establish a user password in the BIOS as well.
2.) Enable the feature to require password entry in order to boot the system.
3.) Hardware lock the hard drive to the system using the system administrator's password established from step 1.
4.) Remove all boot devices with the exception of the hard-drive as the only device allowed to boot the system.
5.) Use your favorite encryption software, i.e. TrueCrypt, PointSec, PGP. Our shop uses the PGP WholeDisk encryption with FIPS 140-2 operation enabled.
6.) As an option, enable the fingerprint reader on the CF-30 as an alternative means to the system administrator boot password requirement.
So you are wondering what does all this procedures and passwords buy you?
The cold boot attack aims its attack at the hardware, specifically the trace memories that are left on the DRAM when a system is powered down (via safe or simply brute force by removing the power supply, i.e power blug or battery). Yes, there are software that can extract the data from the DRAM memory modules, and they have been demonstrated to work quite well for several months now. However, there is a catch with this attack as this attack assumes that while you have the ability to gain access to duplicating a set of cryptographic keys, you also have access to the actual locks and door that are safeguarding the data.
By establishing the BIOS passwords and enabling the feature to tie the hard drive to the actual laptop via the BIOS password, the attacker would need to make the attack directly on the laptop by having the hard drive attached to the system. To prevent the attacker from gaining access to hard drive, you enable the feature to require end-users to enter a password or biometric readers to scan in finger-prints. At the same time, you also disable all non-essential boot devices from the ability to boot the system from alternative devices by removing the boot devices with the exception of the hard-drive. Providing end-users with a user password for the bios password, authorized end users are allowed to boot the system but will not be able to gain entry to the BIOS to alter system boot orders.
With these combinations of provisions in place, if the DRAM modules were compromised, the data is inaccessible because the attacker has no means to launch the attack against the data. Simply removing the hard-drive and connecting it to another system will not be useful because the hard drive is at this point tied to the motherboard and without it, it is useless and will not be accessible at all without knowing the system administrator's password.
You have a copy of the keys. But if you have no means to use the keys and you can't find the lock or door, the keys are useless to you.
So, do you use this thermite enabled system on your LAPtop?
Not sure if you are aware but it is pretty trivial to bypass ATA password lockouts if you really want to... all you have to do is swap out the controller chip and/or controller itself on the drive. You can usually do this without even having to remove the platters of the drive.
The other trick is to write the random crap, or apply the clearing, when a DRAM is powered up. That way the RAM would get cleared even if yanked from a hot box.
Engineering is the art of compromise.
We can store keys in L1 and/or L2 memory. Keys are small - just a few bytes. Maybe even they can stay in CPU registers, but that might add unwanted/unneeded register pressure. Any thoughts - can this be done?
Anyone know if L1/L2 can be read from a cpu that's just been yanked?
Have the SanFran IT system admins gotten into a running conversation with this team yet?
And I think you need to see this.
After reading the "Key expansion" defense, I got to thinking. Perhaps a fuzzy margin for the key length could be built into these crypto schemes? I know that common algorithms seem to usually be in multiples of, say, 128 bits (AES 128 and 256, for example). I've never tried using a weird bit length for anything (say, AES with 231 bits), and I don't know if these algorithms can even use such an odd key.
However, if they could, maybe during initialization the user could be prompted for a bit length and fuzz factor, say AES 256 +/- some percentage or absolute number. This wouldn't make the attack impossible, of course, but it would vastly increase the amount of effort required to test the possible permutations of what's left in memory. I wish they had tested FreeBSD's gbde and geli for this paper. I look forward to seeing how other platforms fare against this attack.
Method of processing duck feet
the 'boom' wasn't an explosion, besides I've seen a thermite loaded laptop go off, in video with audio, it's a lot like a very large firework, hissing with a big gout of flame. the boom was just slang, because the data will be destroyed in a very entertaining way.
you should read up more on slang, since you assume boom means explosion, 'bang' means explosion. http://www.urbandictionary.com/define.php?term=boom
https://www.gnu.org/philosophy/free-sw.html
I realized now 'Kaboom' == cartoon explosion not boom, completely different words man.
https://www.gnu.org/philosophy/free-sw.html
Putting on my pedantichat, I feel I should point out that he never said anything about whether his pun was intended. In fact, he seemed to be apologizing for it.