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.
Memory wipe on case intrusion event.
Back to you.
Learning HOW to think is more important than learning WHAT to think.
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
Cut hole in case wall so your "intrusion switch" doesn't trip.
Oh the fun cat and mouse game of security.
It is still alive, with its sibling the SH-5, for the embedded market. Its core is licensed in the same way as ARM and MIPS.
Slashdot - The great and glorious cluster fuck of Internet wisdom.
The scenario is that someone steals a running, but locked laptop
Let's assume a REAL scenario. The real scenario is not everyone runs Windows and not everyone runs laptops, and not everyone uses X86 architecture. Just because the screen is locked doesn't mean the encrypted volume is not in use. Come to think of it, Windows + Laptop + Locked doesn't even mean it's not in use. The cold boot attack is also more useful against desktop machines because it's much easier to freeze up the memory good because you usually have unrestricted access to most of its surface area.
Example: I leave my computer calculating possible attack vectors for that exhaust port and lock the screen while I go make a coffee; it's going to take a couple of hours to compute, you see. I'm in the next room but it's possible that I am raided and the computer seized before I can get back to it and kill it off. In this case the key is very certainly loaded on the machine - either in RAM or cache, we can't be 100% sure. The key is also very certainly required to be there, and we can't cripple the machine with cache tricks because it's actually working on sensitive calculations. I'd suggest this is a likely scenario for most users of encrypted volumes.
Sure, if you were 250% paranoid you wouldn't walk away from your computer without first ensuring the key space in RAM was DoD wiped, but find me someone _that_ paranoid.
I drink to make other people interesting!
"Scramble" circuitry within the DIMM itself, so that once it's pulled it triggers, independent of the mobo it was previously attached to.
CAn'T CompreHend SARcaSm?
How exactly would a memory chip define "power first applied"? And how would the memory itself erase anything?
Well, I might be taking a stab in the dark here, but perhaps it has something to do with THE ADDITIONAL CIRCUITRY proposed by the Parent?
Nothing ever gets done in the world anymore because those of us with an understanding of our surroundings are too busy facepalming ourselves constantly.
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"