Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Cold Boot Attack Utilities Released At HOPE Conference

Soulskill posted about 6 years ago | from the shining-a-spotlight dept.

Security 113

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

cancel ×

113 comments

I really HOPE (-1, Offtopic)

Anonymous Coward | about 6 years ago | (#24263817)

...I'm first!!!

RE: Editor/Submitter (4, Funny)

Ihmhi (1206036) | about 6 years ago | (#24263845)

I think the editor and submitter both need to read this [thebestpag...iverse.net] .

Re: Editor/Submitter (0)

Anonymous Coward | about 6 years ago | (#24271935)

And I think you need to see this [goatse.cz] .

Yup (2, Interesting)

Anonymous Coward | about 6 years ago | (#24263873)

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:Yup (1)

Jrabbit05 (943335) | about 6 years ago | (#24263909)

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

Re:Yup (1)

4D6963 (933028) | about 6 years ago | (#24263959)

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?

Re:Yup (1, Interesting)

Anonymous Coward | about 6 years ago | (#24265087)

With multicore processors, it might be feasible to keep the key in a CPU register and not in RAM at all times.

because the fix would have to be in-hardware (5, Informative)

Animaether (411575) | about 6 years ago | (#24263993)

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.

Re:because the fix would have to be in-hardware (4, Insightful)

Minwee (522556) | about 6 years ago | (#24264129)

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.

Re:because the fix would have to be in-hardware (1)

zx-15 (926808) | about 6 years ago | (#24268365)

Hardly foolproof - well that's an understatement; since most of these systems could be easily defeated with a can opener.

Re:because the fix would have to be in-hardware (1)

Minwee (522556) | about 6 years ago | (#24271477)

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.

Re:because the fix would have to be in-hardware (2, Insightful)

jeiler (1106393) | about 6 years ago | (#24264233)

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:because the fix would have to be in-hardware (2, Informative)

the_olo (160789) | about 6 years ago | (#24266311)

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:because the fix would have to be in-hardware (2)

jeiler (1106393) | about 6 years ago | (#24267213)

Security versus convenience. If you have no files (or relatively few files) that require this level of security, use a more convenient method.

Re:because the fix would have to be in-hardware (1)

mysidia (191772) | about 6 years ago | (#24264497)

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.

So then the attacker solders a wire to your capacitor, and shorts the capacitor to ground the moment they cut power to the RAM stick.

Re:because the fix would have to be in-hardware (2, Insightful)

Eternauta3k (680157) | about 6 years ago | (#24265295)

Unless they pot it, or stick it somewhere inaccessible. Of course, someone determined enough will find a workaround (I mean CIA, not random hacker)

Re:because the fix would have to be in-hardware (1)

harry666t (1062422) | about 6 years ago | (#24264759)

> 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 detection system would do the job, but nothing would help if your laptop gets stolen while it's on...

Re:because the fix would have to be in-hardware (0)

Shadow-isoHunt (1014539) | about 6 years ago | (#24264791)

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 initially, and reading through some of this stuff over three minutes, the princeton shit is even more badass and does PXE bootstrapping and stuff.

Re:because the fix would have to be in-hardware (1)

Animaether (411575) | about 6 years ago | (#24266295)

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 are not extremely likely to occur. Those places where they are paranoid to think that something like that might occur are also already likely to have measures in place to prevent it as a side-effect of general prevention measures. Like, say, disabling boot-from-floppy/USB and passwording the BIOS to make sure they can't just go around changing that either; which leads back to having to open the machine in order to reset the BIOS by shorting two points on the motherboard, etc. etc.

Re:because the fix would have to be in-hardware (1)

the_olo (160789) | about 6 years ago | (#24266463)

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 most of the people involved are analysing.

Re:because the fix would have to be in-hardware (1)

VdG (633317) | about 6 years ago | (#24271761)

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.

There far better ways to do this. (1)

EmbeddedJanitor (597831) | about 6 years ago | (#24268189)

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.

Re:Yup (2, Funny)

DAldredge (2353) | about 6 years ago | (#24264119)

Because changing the laws of physics is hard.

Re:Yup (1)

CDMA_Demo (841347) | about 6 years ago | (#24265837)

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 it, look up VileFault ;)

Very Orwellian (1)

k4_pacific (736911) | about 6 years ago | (#24263947)

If you want to imagine the future, picture a cold boot attack on a human face, over and over, forever.

Memory wiper? (1)

Daimanta (1140543) | about 6 years ago | (#24263967)

Isn't there a memory wiping utility that fills the memory with random noise?

Re:Memory wiper? (5, Informative)

jonbryce (703250) | about 6 years ago | (#24264003)

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.

Re:Memory wiper? (1)

Cheerio Boy (82178) | about 6 years ago | (#24264107)

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.

There'd obviously be overhead in the application because you'd be constantly decrypting after every timeout but with computer speeds increasing I don't think that will be that big of an issue.

Re:Memory wiper? (1)

jonbryce (703250) | about 6 years ago | (#24264155)

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:Memory wiper? (1)

Cheerio Boy (82178) | about 6 years ago | (#24264229)

So make it a quick inactivity timer and tie it to the screensaver so you have to re-enter the encryption passphrase before being able to work again.

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:Memory wiper? (0)

Anonymous Coward | about 6 years ago | (#24264207)

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

I believe you're correct. One would have to build an internal physical countermeasure at the power supply (internal battery with a fail-safe?) to beat the cord yank scenario.

Re:Memory wiper? (1)

Cheerio Boy (82178) | about 6 years ago | (#24264289)

Or beef up capacitors on the motherboard.

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:Memory wiper? (1)

mysidia (191772) | about 6 years ago | (#24264573)

The solution is: don't store an unencrypted version of the key in RAM.

Have the decryption require input from a tamper-proof smart card.

If the smart card loses communication with the system, the smart card is programmed to stop operating, until the user re-authenticates.

An attacker can pull and access the entire RAM, but it's useless without also having the smart card.

Re:Memory wiper? (1, Insightful)

Anonymous Coward | about 6 years ago | (#24265673)

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 do the same. To boot, the I/O controller can store the key in a tamper resistant package that is a lot harder to compromise than a SIMM/DIMM.

Re:Memory wiper? (2, Interesting)

freddy_dreddy (1321567) | about 6 years ago | (#24264617)

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.

Re:Memory wiper? (1)

the_olo (160789) | about 6 years ago | (#24266353)

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:Memory wiper? (1)

neomunk (913773) | about 6 years ago | (#24267149)

Until this point I hadn't considered the fact that my laptop battery degrading to the point of *immediate power-off when plug is pulled* could be a feature.

Thank you HP!

Re:Memory wiper? (1)

smidget2k4 (847334) | about 6 years ago | (#24269707)

Most laptops I've used have a pretty quick release on the battery. Pulling the power cord and popping out the battery in a couple seconds doesn't seem unreasonable.

Re:Memory wiper? (1)

Tuoqui (1091447) | about 6 years ago | (#24265443)

Theres a hardware solution, its called a boot to the head.

Re:Memory wiper? (1)

RollingThunder (88952) | about 6 years ago | (#24265927)

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.

Re:Memory wiper? (0)

Anonymous Coward | about 6 years ago | (#24267543)

"No software solution can be used to stop you doing this, it has to be a hardware based solution."

That's right. It's called a fried DIMM. Did you know that there's a reason why people don't usually pull the chips out of a running system?

Did you know that it's usually extra engineering and hardware just to enable hot-swappable disk drives? There's a reason for that.

Re:Memory wiper? (1)

Nethead (1563) | about 6 years ago | (#24267559)

...it has to be a hardware based solution.

Spray epoxy. ("This is glue ... strong stuff." -Elwood Blues)

There are some ways to minimize the problem (5, Interesting)

Psionicist (561330) | about 6 years ago | (#24263979)

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!

Re:There are some ways to minimize the problem (3, Interesting)

Anonymous Coward | about 6 years ago | (#24264133)

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

Re:There are some ways to minimize the problem (1)

the_olo (160789) | about 6 years ago | (#24266069)

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, at most in a matter of seconds. Now it turns out that not, it's actually a matter of minutes, enough to make this kind of attack practical.

This attack emphasizes the importance of keeping your keys in memory only when they are actually needed and the data is accessed, and properly overwriting the memory when the keys are released.

Re:There are some ways to minimize the problem (1)

VdG (633317) | about 6 years ago | (#24271831)

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.

I think what it really shows is that there's no absolute security.

BRB (0)

Anonymous Coward | about 6 years ago | (#24264043)

Stealing a sensitive laptop to test these tools on

(Captcha: prisons)

Tamper proof case, anyone? (1)

tinkertim (918832) | about 6 years ago | (#24264057)

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:Tamper proof case, anyone? (1)

tinkertim (918832) | about 6 years ago | (#24264071)

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:Tamper proof case, anyone? (1)

the_olo (160789) | about 6 years ago | (#24266145)

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 a difference. Further investigation demonstrated conclusively that the bit drops were due to alpha particle emissions from thorium (and to a much lesser degree uranium) in the encapsulation material. Since it is impossible to eliminate these radioactives (they are uniformly distributed through the earth's crust, with the statistically insignificant exception of uranium lodes) it became obvious that one has to design memories to withstand these hits.

Obviously, modern memory chips are designed to be properly shielded from those, otherwise as memory densities increase, memory errors caused by that radiation would render them useless.

See also: US patent 6531759 - Alpha particle shield for integrated circuit [patentstorm.us] from IBM.

Re:Tamper proof case, anyone? (2, Interesting)

Sir_Lewk (967686) | about 6 years ago | (#24264099)

You can hardhack your way around any hardhack.

Re:Tamper proof case, anyone? (2, Interesting)

rwillard (1323303) | about 6 years ago | (#24264465)

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 device into the open slot (or plugging a new device in by removing an existing one without disabling the security feature) would cause the computer to fry itself.

Is it foolproof? No, but it'd be a start.

Re:Tamper proof case, anyone? (1)

VdG (633317) | about 6 years ago | (#24271911)

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.

Re:Tamper proof case, anyone? (3, Insightful)

kesuki (321456) | about 6 years ago | (#24264401)

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 irretrievably destroyed, there is nothing like thermite.

Re:Tamper proof case, anyone? **MOD PARENT DOWN** (1, Informative)

Anonymous Coward | about 6 years ago | (#24266843)

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!

A candidate for the Darwin Awards (2, Funny)

Anonymous Coward | about 6 years ago | (#24267455)

So, do you use this thermite enabled system on your LAPtop?

Re:Tamper proof case, anyone? (0)

Anonymous Coward | about 6 years ago | (#24264539)

Perhaps if the X-rays are strong enough.. TSA x-rays laptops all day long.

Magnets don't hurt semiconductor memory.

Perhaps another ploy would be to put the memory inside 3 layers of box, when the first layer is opened the power is removed, some how hold up the bad guy with the next two layers so the memory has time to forget.

Capturing machines with full disk encryption (5, Interesting)

Animats (122034) | about 6 years ago | (#24264157)

Here's the existing approach to this problem.

  1. Send in SWAT team. Stop user from turning off computer.
  2. Bring in HotPlug kit [wiebetech.com] and UPS.
  3. Plug "Mouse Jiggler" into USB port to keep no-activity timeout from causing logout.
  4. Turn on UPS.
  5. Plug HotPlug unit into UPS.
  6. 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.
  7. Unplug power strip from line power. HotPlug unit will switch in power from UPS.
  8. Plug power strip into UPS. HotPlug unit will recognize this and deenergize its output plug.
  9. Unplug HotPlug output plug and input plug. Computer is now running entirely on UPS.
  10. Carry computer and UPS to forensics lab before UPS battery runs down.
  11. Plug in UPS to keep battery charged.
  12. Access disk as desired.

Re:Capturing machines with full disk encryption (0)

Anonymous Coward | about 6 years ago | (#24264303)

Sounds good to me. Hopefully we can keep that trend going. It would be nice to feel that our data is somewhat secure.

Re:Forgot the most important (0)

Anonymous Coward | about 6 years ago | (#24264317)

13. PROFIT!!!

Re:Capturing machines with full disk encryption (1)

bazorg (911295) | about 6 years ago | (#24264579)

looks like a forced login every 10 minutes is a good idea for people working with really sensitive data.

Re:Capturing machines with full disk encryption (3, Funny)

Eternauta3k (680157) | about 6 years ago | (#24265333)

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

Re:Capturing machines with full disk encryption (1)

Entropy (6967) | about 6 years ago | (#24267993)

Uh .. you Lost me there.

Re:Capturing machines with full disk encryption (1)

ypctx (1324269) | about 6 years ago | (#24265427)

Try it. If you use Gnome, go Menu -> System -> Preferences -> Keyboard -> Typing Break.
You will not have to log in, just to wait a minute.
My estimation is that you will go crazy inside of 5 hours.

Re:Capturing machines with full disk encryption (0)

Anonymous Coward | about 6 years ago | (#24264609)

Put sensitive computers in an inside room with intrusion detection that kills power when detected.

Also provide SCRAM buttons all around the outer offices that kill power.

SWAT busts in, and in opening the outer door they kill all power in the inner room.

Now if it's SWAT, or other law enforcement busting in - what are you up to with those computers hmmm?

(Haha captcha = protests)

Re:Capturing machines with full disk encryption (1)

Arimus (198136) | about 6 years ago | (#24265971)

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:Capturing machines with full disk encryption (0)

Anonymous Coward | about 6 years ago | (#24268481)

Good bye retinas and bone strength, too.

Perhaps something less inclined to kill you painfully.

Re:Capturing machines with full disk encryption (0)

Anonymous Coward | about 6 years ago | (#24264755)

Still circumventable. Require a certain key combination (or even the password) every x minutes. If not entered, unmount disks/wipe memory.

Also, provide a hotkey on the keyboard to do the same. Maybe the pause key could be mapped to do the same thing. Once you see people smashing in through the windows, well, you probably have time to hit it.

And, FTW, place mercury switches in the PSU, which activate a cutoff relay inside the PSU. It is pretty likely whatever humans are moving the computer are going to be able to keep it *that* steady, and tampering with the PSU is almost inevitably going to end up tilting it.,.

Total cost: About $5 for the mercury switches, relay, and whatever passives you need in between to make it run.

If you're *that* likely to have a SWAT team bust in and take your stuff, those precautions are child's play.

Re:Capturing machines with full disk encryption (3, Funny)

Chris Burkhardt (613953) | about 6 years ago | (#24265089)

13. Try not to get hit by truck as you maneuver Frogger machine across street.

Re:Capturing machines with full disk encryption (0)

Anonymous Coward | about 6 years ago | (#24265255)

So basically it is, as you say "a male plug which is a power output" and a switch to turn it on and off - apaprt from that what makes they product so special (and patentable)? Can't everyone just make a device like this from some scrap cables and a switch?

Re:Capturing machines with full disk encryption (1)

Rich0 (548339) | about 6 years ago | (#24266281)

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 passing through them. They're going to look for something reputable. Plus, if the hard drive contains critical intelligence on a terrorist cell you're going to want to use tools that are reliable. Saving $100 on your interim power supply doesn't sound too good when it causes you to lose all the intel you could have gathered from an operation that involved a whole truck full of commandos and who knows how much background intelligence-gathering.

Sometimes it just pays to do it right...

Re:Capturing machines with full disk encryption (1, Insightful)

Anonymous Coward | about 6 years ago | (#24265619)

Sounds a bit complicated. Here is how it's done:

1. Get physical access to computer, install hardware keystroke logger.

2. Wait a few days.

3. Seize computer, decrypt harddrive.

Or, for the lazy ones:

1. Park van with Van Eck device at next corner, record keystrokes.

2. Seize computer and decrypt harddrive.

Or, for the people that prefer to stay at home/office:

1. Break into system over network.

2. Download data over network.

Or, alternatively but more risky:

1. Seize computer.

2. Decrypt harddrive on the basis of a HUGE dictionary of known and generated passwords

Re:Capturing machines with full disk encryption (1)

Elldallan (901501) | about 6 years ago | (#24271901)

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 agencies or the military will come after your data you can pay to install shielding too.

Deal with the network invasion way the same way it is usually dealt with.

And your last alternative, Construct your own secure nonsense password.

Re:Capturing machines with full disk encryption (1)

thunderclap (972782) | about 6 years ago | (#24265961)

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.

Re:Capturing machines with full disk encryption (1)

ofc (311641) | about 6 years ago | (#24266499)

Interesting, I hadn't thought about them taking away my TOR node while it was running.

It shouldn't be too hard to fix this:
The machine can be configured to shutdown when it detects hardware changes, like the insertion of the "Mouse Jiggler" or the removal of ethernet cables.

not such a big deal (1)

speedtux (1307149) | about 6 years ago | (#24264221)

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:not such a big deal (1)

I)_MaLaClYpSe_(I (447961) | about 6 years ago | (#24266377)

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.

Re:not such a big deal (1)

jlarocco (851450) | about 6 years ago | (#24267159)

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.

Re:not such a big deal (0)

Anonymous Coward | about 6 years ago | (#24268887)

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.

It's not the threat of it happening now that most people are motivated by. It's the threat of it happening in the future, which given the current political situation in the US, is likely to go up.

Originally, wiretaps were only supposed to be used in extreme cases (witness the original intent of FISA), but over time, became much more prevalent to the point where the Executive doesn't feel they need to consult with the Judicial to even order a wiretap or even inform the Judicial as to who or why they're wiretapping. Expect the monitoring and intrusion into privacy to continue to grow. As cold-boot attacks become easier, they will also become a more-used tool.

Re:not such a big deal (1)

speedtux (1307149) | about 6 years ago | (#24267267)

Many corporate users live in the false sense of security that their (personal and corporate) data is secure should the laptop get stolen.

Yes, they do, but not because of this. Among the many things wrong with corporate laptop security, this is way down on the list.

(It's also not news to anybody who has ever power-cycled an Apple II.)

That might also hold true for the guy that is walking around with millions of SSNs on his laptop, including yours.

Tens of thousands of people have access to my social security number; why would I care?

Nig6a (-1, Troll)

Anonymous Coward | about 6 years ago | (#24264225)

EyeS on the real some intelligent minutes. At home, it. Its mission is OS don't fear the every day...Like Knows for sure what WHEN IDC RECENTLY

Privatizing memory contents (1)

Skapare (16644) | about 6 years ago | (#24264943)

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

Re:Privatizing memory contents (1)

tftp (111690) | about 6 years ago | (#24265039)

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, like it's done [seemingly] for audio and video in MAFIAA mode. With a properly designed architecture it can be done. But then the prices of peripherals will go up, even though the problem is not relevant to 99.999999% of computer owners.

If anyone believes there is a market for secure computers, here is your chance - build the whole PC in a secure way, with all peripherals done per your needs. I'm sure DoD and other places will be interested.

Re:Privatizing memory contents (1)

the_olo (160789) | about 6 years ago | (#24266269)

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 bootup would probably erase this SRAM page before you have a chance to read it.

So now this all depends on what the characteristics of SRAM are. This is an interesting workaround indeed. Take note that you'd have to not only modify the CPU but the whole system architecture to account for DMA and all those devices that access memory directly. DMA would need to go out of the equation and go through the CPU that has the encryption/decryption keys (some DMA emulation?). The system would of course significantly slow down, and it would be actually falling back to pre-DMA technology with a backward compatibility layer added in.

Re:Privatizing memory contents (1)

N Monkey (313423) | about 6 years ago | (#24271035)

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.

Physical access (1)

dr_dank (472072) | about 6 years ago | (#24265803)

If the attacker has physical access to the machine to begin with, you might as well throw in the towel.

Re:Physical access (1)

the_olo (160789) | about 6 years ago | (#24266209)

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

Re:Physical access (1)

Ian Alexander (997430) | about 6 years ago | (#24267865)

Replying to undo accidental moderation...

Re:Physical access (1)

dr_dank (472072) | about 6 years ago | (#24269213)

Please state the nature of the accidental moderation.

Re:Physical access (1)

Ian Alexander (997430) | about 6 years ago | (#24270299)

uh, was going for "insightful", hit "redundant" instead.

Proper overwriting of unusedkey material in memory (1)

the_olo (160789) | about 6 years ago | (#24265975)

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?

Nothing new really (1)

Skuld-Chan (302449) | about 6 years ago | (#24266071)

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 (1)

btarval (874919) | about 6 years ago | (#24266301)

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

This is what we do in our shop... (1)

kyoko21 (198413) | about 6 years ago | (#24266885)

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.

How to bypass the drive password (1)

brunes69 (86786) | about 6 years ago | (#24268049)

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.

Hierarchical memory (0)

Anonymous Coward | about 6 years ago | (#24268547)

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?

Re:Hierarchical memory (1)

archeopterix (594938) | about 6 years ago | (#24271267)

We can store keys in L1 and/or L2 memory.

Are L1 and L2 explicitly adressable by processors? Is there a "store in cache" opcode?

I don't think so - it would mix terribly with the way the cache usually works (transparently to the code executed by the processor).

San Francisco calling? (1)

Forbman (794277) | about 6 years ago | (#24269871)

Have the SanFran IT system admins gotten into a running conversation with this team yet?

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...