Slashdot Mirror
Solution Against Cold Boot Attack In the Making
Bubba writes "I just discovered this blog: Frozen Cache. It describes a concept for preventing cold boot attacks by saving the encryption key in the CPU cache. It is claimed that by disabling the CPU cache the key will remain in cache and won't be written to memory. The blog says they're working on a proof-of-concept implementation for Linux. Could this really turn out to be a working solution?" Update: 01/19 20:26 GMT by KD : Jacob Appelbaum, one of the authors of the cold boot attack paper, wrote in with this comment: "It's not a solution. It simply seeks to make it more obscure but an attacker would certainly still be able to pull off the attack. From what is on that blog, there's still a full keyschedule in memory at this time. This is how we reconstruct the key, the redundant information in memory; it's not just the 128/256 bit key itself. For older methods, they needed the actual specific key bits but we don't need them because we recreate them. Basically, the CPU is acting as a ghetto crypto co-processer. Emphasis on ghetto. It's a nice suggestion but the devil is in the details and sadly the details in this case aren't really up to snuff. It's a bogus solution."
Good idea, until they figure out how to cold boot the CPU as well.
Man I've been waiting for this! Lately the risk of a cold boot attack has really scared me, it's to the point where I don't even turn my computer on anymore!
FTA: "Disabling/freezing" the CPU's cache severely degrades the performance. However, this seems acceptable if one considers that this special mode only needs to be set whenever the screen is locked (all efforts are pretty much worthless if an unlocked laptop is stolen).
br/>Sounds like a tiny back door fix with a hell of a cat flap in it.
"Violence is the last refuge of the competent, and, generally, the first refuge of the incompetent" - Thing_1
Or the converse, I suppose (hardware solutions can add another layer to this). This looks like some very interesting work, and may have more applicability in general beyond this one scenario. I'm certainly looking forward to following their implementation as it comes along. But with that said, if this attack was a serious concern for a given entity there seem to be some obvious potential hardware solutions. The attack essentially depends on being able to shutdown the computer but keep the memory cold enough that the randomization time is slowed down tremendously, giving enough time to perform a dump of the contents onto another system for further analysis. Therefore, it can be prevented by, for example, having electric heater units surrounding the memory connected to a dedicated capacitor bank and temperature sensor, as well as a sensor to detect if someone tries for force open the machine (intrusion alarm). Then the system can perform a scram shutdown (or if it is just shutdown normally), and the heaters can assure that the memory is kept hot for a couple of seconds afterwards even in the face of attempted cooling. It only needs to manage it very briefly and then all the contents are scrambled. Other similar methods (maybe a really micro EMP inside a shield memory space) would be possible to, but basically they just need to deny an attacker for a very short amount of time or ensure entropy in the RAM and then the attack is useless.
Ultimately a dedicated hardware secure key store would be better and easier to integrate across all systems, and this more software solution of course has the massive advantage of being able to run for free on existing hardware. But the above could at least be retrofitted on nearly anything, and while it is more esoteric, then again so is the attack since it requires physical access.
Wasn't the "secure computing" preached by Intel/MS and others a "secure" platform that would solve all the security issues?
To me seams that it was only a farse to disguise DRM into everyones computers...
And fail...
This is supposed to protect the key while the system is locked, and a password is used to unlock the screen. But if a password is required to unlock anyway, the key doesn't even have to be accessible while the system is locked, the password itself could be used to decrypt the key while unlocking. Of course there is a drawback in that any disk operations would have to be delayed until the system is unlocked, that might not be acceptable for all users.
The simplest way to implement my proposal would probably be to suspend the system instead of just locking the screen (like you do if you are not going to be using your laptop for a few hours). It just has to be implemented correctly such that the key really isn't available until decrypted using the password that you enter when waking it up.
If you want to lock your laptop and leave it doing things in the background requiring disk access, then the idea from this article might be valuable. There are other possibilities, one alternative is to store the key in special cryptographic hardware from where it can't just be read out (I haven't thought through the details of such a design, there are obviously some hurdles that would need to be sorted out). Or you could make some use of asymmetric cryptography, I don't think any storage encryption currently does that, since it could have a performance penalty, but it would provide some protection against attacks like this. You could also use ciphers that are less vulnerable to this kind of attack. Part of the attack is to use the key schedule as a kind of error correcting encoding that will help recovering the key. Key schedules are typically designed with performance in mind, and this kind of attack is not considered. But for most storage encryptions the performance of the key schedule isn't important, so a different key schedule could be designed to have no error correcting properties. (I think that just means the function mapping from key to key schedule would have to be a PRNG).
Do you care about the security of your wireless mouse?
The Hitachi Super-H 4 processor (used in the Dreamcast among other things but I believe now as dead as the Dreamcast is). Supported a mode where you could disable half of the cache and use it as general purpose RAM.
Yes, but the benefit of a cold-boot attack is that the data is just there; you don't need to remove the DIMMs and read tiny electrical fields with special machinery; you just read the bytes.
There is no CPU instruction for *any* architecture that will give you the voltage level of a memory cell.
Not to mention, this is posted on the internet. Select the text you don't know about, right click and choose search google for "text". Firefox automagically opens a search on the topic in a new tab, and chances are the Wikipedia article is one of the top five results which should be a good enough starting point to see if the topic is of any interest to you. Magically, the old style of handholding journalism where authors are forced to assume the reader has the education of a 5th grader goes away, and society can actually advance further than the lowest common denominator.
Don't be arrogant and put the blame on the reader. It's called journalistic writing and typing a good summary does take a bit of care. Adhering to some basic writing principles, like the inverted pyramid, would go a long way even for a lowly summary writer/story submiter: http://en.wikipedia.org/wiki/Inverted_pyramid
In the day of multi-core everywhere, a possible solution seems to be:
Dedicate one core to handle both screen unlock and disk encryption, but only when locking the machine.
On this core I would use one (128 bit) or two (256 bit) SSE registers to hold the disk key, and another register to hold the unlock credentials, then setup a static communication area where the other core(s) can leave messages, in particular an attempt to unlock the machine.
The dedicated lock core would stay in a loop, comparing the content with the unlock creds (i.e. hashed/salted password) and write the disk key back to memory upon receipt of a valid entry.
Using this approach means that you don't need to mess around with MTRRs or other cache control instructions, you just need to schedule everything else onto the other core(s), including all interrupts (which would (lazily?) writeback SSE register content on a task switch).
OTOH, there are of course some obvious downsides to this approach as well, in particular the fact that the locked core cannot go into a regular sleep mode, if said mode requires an interrupt to get back out of. :-(
Terje
"almost all programming can be viewed as an exercise in caching"