On Sun, Nov 7, 2010 at 1:57 PM, Stephen John Smoogen <smooge@xxxxxxxxx> wrote: > Ok there are several different "cold boot attacks". The one ÂI think > you are talking about is the removing memory from the system and > reading its contents with a special board. The kernel does not [snip] Not even with a special board, ... > In the end, if someone has physical access to your system, you are not > going to be able to completely defend against a cold boot attack. > Encrypting the drive and keeping it reasonably secure is about all you > can do without having hardware that helps. Here is the attack: Your system is running with nice secure encrypted drives, no console access (or a locked screen on a laptop). The attacker inserts a bootable USB key and hits the power switch. System reboots into the USB key, it retrieves the cryptographic keys for reading your disk from memory, then copies whatever information it likes. This works even when a fairly high percentage of the key bits are corrupted because the bits of the AES key schedule have simple linear relationships with the key, so it functions as an excellent error correcting code. For some common situations like protecting your laptop with disk encryption this attack completely invalidates the protection, at least against a moderately savvy attacker. The software for performing this attack is available from here: http://citp.princeton.edu/memory/code/ This is not merely a theoretical weakness. It is easily executable by anyone without the need for special hardware. Without special hardware (like support for CPU-internal key management, CPU support for encrypted ram) this attack is impossible to close completely but small improvement could easily be made which dramatically increased the difficulty of the attack. * The kernel could avoid leaving confidentiality critical data laying around for long spans of time, long term keying could be stored in areas of memory more reliably overwritten at reboot * Bioses could be modified to zero-ize memory at start * Ciphers with linear key-schedules could be avoided (unfortunately everything from the AES contest is bad at this, because the contest pressure to work on low memory devices and small message sizes made everyone use very cheap initialization; blowfish is an example of something which I think is mostly free of that particular weakness) * Userspace could freeze all access to encrypted volumes when the screen is locked and toss the keys. (This is most reasonable when the volume password and the user's login password are the same) There were patches posted to the Linux kernel to reduce the exposure from this kind of attack: http://lwn.net/Articles/334747/ but unfortunately the author and the LKML didn't get along and the patches were never merged. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
