Countermeasures for cold boot attacks on encryption keys?
I noticed today that those guys that published the report on cold boot attacks on encryption keys back in Februrary have now released source code which illustrates the techniques they use. So I was just wondering if, during these months since the report first surfaced, anyone has heard about any new GNU/Linux software which helps at least mitigate this vulnerability. Or is the consensus still that there is no way to address this problem using software?
|
Well, first of all you need physical access to the machine and it must be booted.
The mentioned use of Treacherous Computing (storing an encryption key) is pretty stupid - hell, why not just store the key in ROM? The reason of course is that without significant specialized hardware, it will take forever and a day if you relied on the Treacherous Computing chip to decrypt the filesystem, so currently existing chips in consumer devices just aren't up to the task. So how do you 'fix' that? Well, you can store everything in memory encrypted and decrypt on the way to the CPU (treacherous computing built into the CPU). Using the right algorithms, this can absolutely defeat the technique used by those Princeton guys. One possible way around that protection scheme would be to make an image of the memory, then tear out the decryption device and trick it into decoding that memory - if you have zero bitrot then your attack succeeds, but if a single bit in the block goes bad, you get nothing but garbage out anyway. Another hardware scheme to foil such a plan is to put in circuitry, possibly within the RAM chips themselves, which scramble the memory contents when power is removed. The trick here is that there still needs to be enough power available to the chips to do their job, but a 'power failure' circuit somewhere needs to send a signal to indicate that power loss is imminent - screw up the memory. Now lets pretend we have an encoder/decoder implemented in an extremely fast FPGA running at the same clock rate as the CPU, or even slightly higher. Now every time data is transferred from the RAM to the cache (or the other way) it must be encrypted/decrypted, which adds time to the data transfer and essentially slows things down - possibly even 'starving' the CPU. Most people wouldn't approve of that, but I bet if you build a computer like that you'll have government departments lining up to buy them; after all, most modern CPUs are overkill for the processing required and a sacrifice in speed for secrecy is an easy trade. Even a Treacherous Computing device is not a good place to store cryptographic data anyway. Combining the Princeton folks' "put the RAM into cold storage to prevent bitrot" with other silicon forensic techniques which the semiconductor industry has been using as diagnostic techniques for over 30 years, the keys in the Treacherous Computing device can be recovered within a few hours - you just need a lab with the right equipment. |
Some simple precautions to take on existing machines to foil such an attack would include:
1. Set your BIOS to boot only from HD, and activate your BIOS password. This will force someone to have a HD handy to swap with yours. 2. If you use treacherous computing anyway, and you have a BIOS that makes good use of it (maybe only hypothetical at this point in time), the machine can be forced to boot from an encrypted bootloader. If you didn't encrypt the bootloader correctly, you're just not going to boot from that mass storage device (with the exception of CDs). Another option is to set to boot from that HD only; you'll have great fun when you need to replace the HD. :) |
Is it true that you not only have to have your computer powered on, but your data has to be currently decrypted, or not properly unmounted when an adversary gets physical access to your computer?
|
Quote:
How about just having the key overwritten when the computer switches off, goes to sleep or whatever. I believe that PGP does this already. Any hibernation, sleep etc causes the encrypted filesystem to be unmounted, and the keys shredded. It shouldn't be too hard to implement for other systems (if it's not already). And of course, don't leave your PC on in a vulnerable place. I'm sure that a determined attacker on a high profile target would be able to get the keys, but it's probably easier for them to kidnap and torture you to give up the keys. |
Quote:
|
Quote:
OK, not that this is practical (security rarely is though) but if you rarely use the encrypted data, could you shutdown the computer sometime soon after you were done with it to clear the password from memory? Then would you be safe as long as you haven't decrypted the data again without having shutdown afterwards? |
Quote:
|
Just do like in the movies - 'James Bond' - load the machine with explosives, then go to the bar and ask for another martini - shaken, not stirred.
|
Quote:
Now if you're worry is somebody sneaking up behind you and conking you on the head (or something) while you are using the computer maybe you do need James Bond like defenses such as the computer deleting the key if it loses a valid retina scan and blowing up if anybody yanks the power cord. (Heaven help you if you have a power failure! ;) ) |
Cold boot attack
Well I wanted to get more involved with c++, but I got a bit side tracked with security related issues. Honestly I find this more fascinating then anything else right now.
Anyways. I stumbled across something that was pretty much new to me. The quote below is from Wikipedia. It would be great to hear others opinions on a Cold Boot Attack. Some of my questions are: It sounds like it can happen, but how likely is it to happen? Has this been a serious problem in the past? How can one protect themselves against this since it is hardware related? How much data can actually be in the memory? Is there a way to purge the RAM before or during shutdown of a PC? Are there any safe guards that can be put into place in case the computer looses power or doesn't shut down normally, etc? I would love to hear any thoughts, opinions and experiences concerning this. Quote:
http://en.wikipedia.org/wiki/Cold_boot_attack |
This is simply one example that illustrates the long standing truism in computer security that if you can get your hands on a computer then you can disable its security. Computer security specialists have long known that physical access to the machine is the front line of security. That is why you often hear people say that the only secure computer is one that is stored in a vault with no connection to the outside of the vault and with the computer's power cord removed.
Computer security is just like home security insofar as you cannot create an unbreakable system. The best that you can hope do is to make your security so difficult to break that most people will give up before they succeed. |
I am starting to understand that. I love computers but it worries me how much we rely on them and assume that they are safe and nothing or no one can break into them.
I think I will be focusing on this more now and all related topics. |
I am finding some more information about this. So I wanted to post it here.
http://citp.princeton.edu/memory/ |
Amdx2_x64, I've merged your thread into this one, as it's essentially the same question/discussion.
|
@ Amdx2_x64
While I was being a little flippant in the second paragraph of post #10, I was fully serious on the first sentence of that post. I am speaking specifically about protecting keys you use to decrypt partions/hard drives. My impression is that your only serious defence against a cold boot attack is to make sure that when the computer is shut off (and possibly suspended/hibernated) that the relevant keys in memory are overwritten first. And then make sure that while those keys are in memory that you are physically protecting the computer. |
Quote:
Thank you. I somehow missed this thread. |
Quote:
Personally I never see this as a problem for me. The more I read the more it seems that someone is more likely to get hit by lightening then a cold boot attack. But it still is interesting that this can be done and that some, especially those with laptops, need to just take an extra, simple step for added security. Now if you will excuse me, I am going to get a cup of coffee, stirred not shaken ;) |
Quote:
That said, don't forget that (as has already been mentioned), the bad guy can just cut the power, preventing the overwrite from happening, and then launch a cold boot attack. Overwriting at shutdown provides a little bit of comfort for desktop/laptop users who are fairly certain their boxes won't get physically owned while turned on (such as if your residence was raided), but it's not applicable to servers unless you've got some sort of interface between your physical site alarm system or something like that (which will alert the server that the physical perimeter has been breached and it should unmount encrypted stuff and overwrite the keys). Perhaps new RAM modules will use storage technology which guarantees there is no residue when power is cut? Actually I'd bet there's stuff like this already. Anyone? |
Quote:
Also, when I was thinking about this attack I was thinking about dekstops/laptops. (Particularly laptops.) Is it even common to use disk encryption on servers? I thought servers containing sensitive info were usually physically locked down pretty well. I remember reading about a server at some university (Harvard?) that was in what was darn near the equivalant of a bank vault. |
Code:
#!/usr/bin/perl -w run this 2-3 times to clear the ram on 12Gb of ram it takes about 3 seconds to run and then it get "out of memory" error which is what we want. |
BIOS passwords do not mitigate this, because guess what? The RAM shadows the password after it's entered correctly, so while the system is waiting at the "enter your password" prompt, the correct password is already in RAM.
I just saw Jacob present this at Toorcon over the weekend and the consensus seemed to be that the only way to defend against it is to have proximity sensors around the machine to detect unauthorized presence and zero-out memory. If an attacker is able to remove power you're pretty much hosed, because they can immediately chill the RAM chips and then transport them off-site to place in their own memory reader and dump the contents. By the way, turning off a machine may work for a laptop, but what do you do with servers that are supposed to be up 24x7? |
For 24x7 servers it comes down to physical access. You don't have a 24x7 production server sitting out in a unprotected area. Myself in perticular (considering I work in a classified area where no cellphone, pagers, pda, camera's, etc are allowed) would worry more about the person in my facility then them getting access to the ram.
|
Seems like someone has decided to take a shot at this. My guess is it won't end up being a solution, but will at least make the attack much more difficult. I do wish this guy the best of luck with his project.
|
All times are GMT -5. The time now is 06:07 PM. |