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."
why are you modded funny? is there any reason that the cpu memory cannot be attacked in a similar way to standard memory? The hardware you need to pull it off is probably a bit more obscure but is there a reason that you cant stick a cold CPU in a multicpu board and read its memory from a second CPU?
IranAir Flight 655 never forget!
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.
Although marked as Funny, you could quite easily open the PC take out the BIOS ROM whilst the machine is running (the BIOS is shadowed in normal operation), stick a new custom one in that probes the cache and do a hard reset.
Additionally this could also be used to get a near perfect dump of RAM too.
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.
Most cache is implemented as a flop, which loses its state on power down almost immediately. I don't think it's possible.
Memory wipe on case intrusion event.
Back to you.
Learning HOW to think is more important than learning WHAT to think.
This sounds like quite an over-complicated solution. Isn't it possible to design "secure" memory chips that zero their contents when power is first applied? I mean, memory chips are pretty "dumb" (from a design logic perspective, which is why cold-boot attacks work) so how hard would it really be to add this function to the chip? If it significantly adds to the manufacturing cost, sell it as a feature. I know of many agencies and individuals who would be interested in memory that's secure against cold-boot attacks, even if it costs twice per MB as normal chips.
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?
SRAM also has parasitic capacitances within each cell, which could act enough like DRAM to enable it to hold some data without power. The DRAM capacitors are essentially parasitics as well, so don't disregard the parasitic capacitance in an SRAM cell as completely insignificant.
perl -e 'print $i=pack(c5, (41*2), sqrt(7056), (unpack(c,H)-2), oct(115), 10);'
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"
Well fuck me in the ass and call me Sally, why the hell are we discussing this then?
I may agree with what you say, but I will defend to the death your right to face the consequences of saying it.
Trusted Computing is built on an entire tree of keys. You're right that the master pair of keys (PrivEK and RSK) never leave the chip. You're right that reading RAM will not give you a simple full crack of the Trust system on your computer. However by reading RAM you can snatch the lower levels keys peicemeal, and you can read out decrypted files piecemeal. For example you play some DRM music and do a RAM grab. If you're lucky that RAM grab will give you the key to decrypt all of the DRM music files on your computer, or if your less lucky you may just get the decrypted version of the particular song you were playing at the time.
Actually I have been collecting notes on some more powerful more promising attacks on Trusted Computing, but this RAM technique is certainly nice and easy addition to the anti-TrustedComputing toolbox.
-
- - You can't take something off the Internet! That's like trying to take pee out of a swimming pool.