Pabel's idea is that you can store sensitive data, such as keys, in the CPU's cache, disable cacheing, and zero the data from memory. This should leave us with the key stored in a usable state in the CPU. It's a good concept, but unfortunately it doesn't seem to be much more than a concept at this point.
Not surprisingly, CPUs have caches for a reason and when they are disabled, performance suffers. In Pabel's demo, he was running what seemed like nothing more than a terminal to enable and disable his proof-of-concept and even that was painfully slow. I realize that Pabel was not presenting a full solution, and I know how far from complete many POCs are, but I'm not sure how much optimization can actually be done.
x86 processor's simply weren't designed for this sort of cache abuse. They don't offer enough control over the cache for this method to really be feasible. There are no obvious ways to disable only the parts of the cache of our choosing, and no way to prevent others from flushing the cache and either destroying our sensitive data or dumping it to RAM.
What we really need is a hardware-tailored solution to this problem. I think there is a need for a dedicated piece of hardware, either built into the CPU or with fast access to it, that could be used as forensically secure storage for sensitive data. Similar solutions seem to work reasonably well in consoles (unless you are into epic math fails like Sony).
Overall, cold boot attacks aren't a huge problem, since they require physical access to pull off, but with an increase in government asshat-ery at airports it would be nice to have a solution.
UPDATE:// Juergen was kind enough to address my concerns in the comments. Read on.
Joe,
ReplyDeletethank you for reviewing my presentation. I also don't expect the performance of FrozenCache to ever become adequate for most users for single-core systems. On multi-core systems I expect near-normal performance because only one core would need to be switched into FrozenCache mode (other core has its own CPU cache and can continue to operate in normal mode).
FYI: I also looked into the AES acceleration on new Core CPUs - they don't provide a secure key storage (as in memory) but work much like the other SIMD extensions (single instruction multiple data).
Juergen
Thanks for your comment, Juergen. Multi-core systems certainly should handle this sort of thing better. It may not be the optimal solution, but it's something that I'm excited about and will be following closely. There's only so much you can do without a hardware solution, and this is a very novel approach.
ReplyDeleteYou mentioned switching into FrozenCache mode when the computer is locked (as an example). If you were going to protect keys that are used for software-based disk encryption, would a CPU need to be in FrozenCache mode indefinitely? If so, do you have any concerns about performance in this case?
Joe,
ReplyDeletethe frozencache mode would only need to be activated for situations when cold-boot attacks are of concern (like computer is running but screen is locked). One of my proof-of-concept scripts listens to the D-BUS for screen(un)locking messages and switches frozencache on/off.
Juergen
Juergen,
ReplyDeleteForgive my ignorance, but why are cold-boot attacks less valid in the case where a computer is not "locked"? I thought at any given point in time (as long as an encrypted disk is mounted), cold-boot attacks could be used to retrieve keys from memory. Are bitlocker and truecrypt keys only in memory when the computer is in a "locked" state?
Thanks again for your reply.
-Joe
Joe,
ReplyDeletetechnically, you're correct. Although in real life it's likely that an unlocked system will yield access all data on that system anyhow. However, if that were not the case then a cold-boot-attack would still be viable even for an unlocked system (user logged in).
Juergen
That's a good point Juergen. Keep up the good work, and thanks for addressing my concerns.
ReplyDelete