On Thu, 29 May 2008 17:37:11 -0700 Jacob Appelbaum <jacob@xxxxxxxxxxxxx> wrote: > We have suggested this very thing as a very simplistic countermeasure. > Sadly, it's not easy to implement in a way that is honored. Also, it > doesn't help with key schedules (... which we automatically detect and > use to reconstruct keys even with bit decay). > > All of this is useful but simple to work around for an attacker. We can > easily remove the memory chips and read them with a device that doesn't > have constraints of a typical BIOS. I realize it can be worked around with hardware, but wouldn't it be useful to raise the bar from "reboot the system with a crypto-key fishing USB stick" to "need special hardware"? As for the key schedules, can't the generated keys also be placed in memory which the BIOS will overwrite? The 512 bytes at 0x7c00 are guaranteed to be overwritten by the BIOS (partition table or PXE software is loaded there) and I've been told that most BIOSes zero out the entire area below 640kB. Of course, if there are crypto software solutions that somehow manage to defeat the cold boot attack, that would be even better. A future hardware solution to help defeat it could help too, for example the ability to put a crypto key into a special CPU register and use that to encrypt and decrypt the memory holding crypto keys, with a page table bit to indicate that the page is encrypted. In the mean time - how useful (or useless) is it to raise the bar a little? -- All rights reversed. - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/
