Posted
by
Soulskill
on Sunday July 20, 2008 @12:26PM
from the shining-a-spotlight dept.

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.

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.

Nothing is going to save a server which somehow winds up in a private chop-shop where people with unlimited resources and inside knowledge of how it works want to do it harm, but try to think about more likely scenarios for this kind of attack.

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.

I'm sure the is a middle ground. Some desktop managers allow you to "become root" to do administrative things, and this privilege persists until an event resets it. Most commonly this event is simply a time expiration, or locking your screen.

The same could be done for your keys, and doesn't seem too onerous on the user who knew [s]he was going to have to sometimes enter a password to decrypt the files.

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

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.

No you don't, play with the PoC. With McGrew Security's ramdumper you've been able to boot off USB on the machine the ram sat in i

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

Don't get me wrong, I already understand that it is possible - just that the situations in which it is possible are not extremely likely to occur.

Apart from those likely to be facing the forces of law and order exercising search warrents, the biggest risk would seem to be for people losing laptops. It is suggested that PCs which are in hibernate/suspend states may not be safe. Personally, I don't tend to suspsend my PCs when I'm finished with them for the day. But I do sometimes and may suspend one with the expectation of restarting it later, only to get caught up with something else. These machines could be vulnerable.

The DRAM cells are basically little capacitors that store the charge. It should be quite easy to have a single line going into the the DRAM that flushes all the cells as soon as: power is removed, refreshing fails or an external reset is applied.

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.

Why hasn't the team come forth with a fix for this exploit? They have more knowlege on the subject then I do.

The key speaker mentioned that ECC ram scrubs all bits right after startup so its one possible defence (though not very effective still because reports are not throughly tested). Another would be to setup a timer that scrubs the memory if the machine has been idle for a given amount of time....one fancy version was to have your machine trigger the scrubber once your cellphone (running a tracker) had been away for a certain duration. The decay time (IIRC) was an average of 25 seconds....
BTW while you're at

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.

The problem is that all I/O for encryption needs to go through the key, so having the key only available on a smart card would cause great performance losses. Smart cards are intended for very low bandwidth uses -- decrypting a volume key so the bulk decryption can finish, or signing a MD5 hash.

Instead, perhaps move the encryption to the drive controller and have some keymanagement abilities there. Then, come a shutdown, its a lot easier for a drive I/O controller to wipe its limited RAM than for a PC to

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.

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

I'm sure I recall something from last week about individually encrypted filesystems not being secure because the OS will store data - e.g. documents being edited, or recovery files for same - in non-encrypted areas. So the only way to be safe IS to have the whole disk encrypted.

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

Even with cooling, the memory doesn't linger all that long so all that's really needed is to delay removal of the chip(s) for long enough. Eposxy or something similar to fill in screws and secure access panels might suffice. Of course, that would make your own maintenance difficult. Glueing in the memory chips themselves might be better as it would be difficult to get them out using brute force without damaging them.

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

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

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.

For your first alternative physical intrusion detection will work very well as a safety measure since the attacker wants to be discrete.
If you return home and notice somone have drilled/sawed/cut a large hole in the side of your computer would you be suspicious?

As for the Van Eck device, there is a reason military systems that needs to be secure outside of a secured enviroment is usually quite bulky, thats because they are shielded.
If your data is so important that you need to worry about three letter

Honestly, neat but if your smart have your power button set to five second shut down. By the time they get to it, its off. O well. Also, hotplug doesn't work in the US because we actually insulate our plugs with plastic.

Thought experiments like these are fun, and sometimes even productive. After I first read about the Firewire/DMA attack, I got to thinking about about various hardware seizure scenarious, much like you describe.

I've concluded that the only really decent protection is a series of software heartbeats tied to the physical environment in which the computer operates.

You can monitor voltage of various parts of the PC and UPS, so this might help against in the case where a machine's power source is tampered w

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.

If the company lets people leave the office with laptops containing "millions of SSNs", this exploit isn't their biggest problem.

I have to agree with the OP. So far in the entire thread I've yet to see a convincing argument explaining why this is a big problem.

At most it seems this would be a small concern for a very, very small group of people. And before anybody gives another parnoid explanation involving SWAT teams and the CIA, ask yourself how often that really happens.

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

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?

[Disclaimer: The following was from many years ago...]From my experience of a home computer (in the early 80s) with (CMOS) SRAM memory, the contents stay almost intact with a switch off of a second or less and gradually decay to "random" if the power is off for several minutes. IIRC given that CMOS uses MOSFETS which also have tiny capacitors, this is perhaps not too surprising.

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 est

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.

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 fu