<delurk/>
Hi all,
I just read an interesting entry on Bruce Schneier's blog: http://www.schneier.com/blog/archives/2008/02/cold_boot_attac.html about how to recover the keys for a whole-disk encryption system.
Apparently, the problem here is DRAM doesn't fade fast enough. If the reboot is fast, then the memory contents are preserved, so exposing the in-memory cache of the disk encryption key. Boot off a memory stick and one can analysis the memory's content.
The (perhaps flippant ;-) remark from "bootman" about storing the keys somewhere where the data will be erased by the BIOS led me to wonder if coreboot could do something like this.
Perhaps coreboot could add the option of wipe the memory contents before handing over to the payload, maybe a "wipe-memory" payload that fails over to the next, main payload? If erasing the whole memory would take too long, could it wipe some part of the memory and (by convention) that part of the memory be used for storing secrets?
Neither offers a completely solution to the problem: apparently, as the temperature is lowered, the data in DRAM will survive longer---at liquid Nitrogen temperatures it can last for hours---but perhaps it could help.
Cheers,
Paul.
Quoting Paul Millar paul@astro.gla.ac.uk:
<delurk/>
Hi all,
I just read an interesting entry on Bruce Schneier's blog: http://www.schneier.com/blog/archives/2008/02/cold_boot_attac.html about how to recover the keys for a whole-disk encryption system.
Apparently, the problem here is DRAM doesn't fade fast enough. If the reboot is fast, then the memory contents are preserved, so exposing the in-memory cache of the disk encryption key. Boot off a memory stick and one can analysis the memory's content.
The (perhaps flippant ;-) remark from "bootman" about storing the keys somewhere where the data will be erased by the BIOS led me to wonder if coreboot could do something like this.
Perhaps coreboot could add the option of wipe the memory contents before handing over to the payload, maybe a "wipe-memory" payload that fails over to the next, main payload? If erasing the whole memory would take too long, could it wipe some part of the memory and (by convention) that part of the memory be used for storing secrets?
You can't wipe the memory right before the payload. At this point the memory is already itialized and memory alociation is already setup. This could potentially wipe out parts of the setup process. The best time to impliment something like this would be in the very begining. Something like initalize memory -> wipe memory -> re-initalize memory -> continue with the coreboot process.
Thanks - Joe
On Thu, Feb 21, 2008 at 12:10 PM, Paul Millar paul@astro.gla.ac.uk wrote:
Apparently, the problem here is DRAM doesn't fade fast enough. If the reboot is fast, then the memory contents are preserved, so exposing the in-memory cache of the disk encryption key. Boot off a memory stick and one can analysis the memory's content.
yes, this is a problem and has been for as long as DRAM has been around. I kept wondering if anyone would notice :-)
I used to debug DRAM-based micros by power cycling them and then dumping DRAM. Most of it survived. I won't even mention how long ago this was.
The (perhaps flippant ;-) remark from "bootman" about storing the keys somewhere where the data will be erased by the BIOS led me to wonder if coreboot could do something like this.
yes, very easily.
Perhaps coreboot could add the option of wipe the memory contents before handing over to the payload, maybe a "wipe-memory" payload that fails over to the next, main payload?
We could do it in initram with no trouble.
You pretty much have to do a full memory write to reset the ECC tags anyway (note: NOT zero. Just write). I'm kind of opposed to zeroing memory, since frequently, you want the contents of memory for port-mortem. That said, I'm surprised their attack worked since I assumed all those wonderful "secure" BIOSes -- such as EFI -- would zero all of memory. There must be something else going on here. Oh, there is -- they turned off memory wipe. I'm not that astonished, I'm surprised that anyone is ... DRAM retention is a widely known issue.
If erasing the whole memory would take too long, could it wipe some part of the memory and (by convention) that part of the memory be used for storing secrets?
HMM, the K8 has 3.2 GB/sec memory bw at minimum. Put 128 GB on a single CPU ->40 seconds. People might get upset. But people who care about security should not.
It's funny. Those incredibly slow BIOSes disable a very important security item to get faster boot :-)
Neither offers a completely solution to the problem: apparently, as the temperature is lowered, the data in DRAM will survive longer---at liquid Nitrogen temperatures it can last for hours---but perhaps it could help.
The problem is easily solved -- on some machines, it should not be possible to disable (at minimum) a full zero'ing of memory.
Neat paper though. It makes a widely known but not much discussed problem more widely known.
ron
On 21.02.2008 21:55, ron minnich wrote:
On Thu, Feb 21, 2008 at 12:10 PM, Paul Millar paul@astro.gla.ac.uk wrote:
Apparently, the problem here is DRAM doesn't fade fast enough. If the reboot is fast, then the memory contents are preserved, so exposing the in-memory cache of the disk encryption key. Boot off a memory stick and one can analysis the memory's content.
yes, this is a problem and has been for as long as DRAM has been around. I kept wondering if anyone would notice :-)
I used to debug DRAM-based micros by power cycling them and then dumping DRAM. Most of it survived. I won't even mention how long ago this was.
The (perhaps flippant ;-) remark from "bootman" about storing the keys somewhere where the data will be erased by the BIOS led me to wonder if coreboot could do something like this.
yes, very easily.
And it's circumvented just as easily.
Perhaps coreboot could add the option of wipe the memory contents before handing over to the payload, maybe a "wipe-memory" payload that fails over to the next, main payload?
We could do it in initram with no trouble.
You pretty much have to do a full memory write to reset the ECC tags anyway (note: NOT zero. Just write). I'm kind of opposed to zeroing memory, since frequently, you want the contents of memory for port-mortem. That said, I'm surprised their attack worked since I assumed all those wonderful "secure" BIOSes -- such as EFI -- would zero all of memory. There must be something else going on here. Oh, there is -- they turned off memory wipe. I'm not that astonished, I'm surprised that anyone is ... DRAM retention is a widely known issue.
Yeah, I don't understand those people acting surprised.
If erasing the whole memory would take too long, could it wipe some part of the memory and (by convention) that part of the memory be used for storing secrets?
HMM, the K8 has 3.2 GB/sec memory bw at minimum. Put 128 GB on a single CPU ->40 seconds. People might get upset. But people who care about security should not.
It's funny. Those incredibly slow BIOSes disable a very important security item to get faster boot :-)
Maybe that's the final nail in their coffin.
Neither offers a completely solution to the problem: apparently, as the temperature is lowered, the data in DRAM will survive longer---at liquid Nitrogen temperatures it can last for hours---but perhaps it could help.
The problem is easily solved -- on some machines, it should not be possible to disable (at minimum) a full zero'ing of memory.
Neat paper though. It makes a widely known but not much discussed problem more widely known.
There's an even better solution than zeroing memory during initram: zeroing memory on poweroff. There's no reason the firmware poweroff handler can't zero all memory.
Regards, Carl-Daniel
On Thu, Feb 21, 2008 at 1:24 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
There's an even better solution than zeroing memory during initram: zeroing memory on poweroff. There's no reason the firmware poweroff handler can't zero all memory.
won't help as I can simply yank DC power and not give you the chance. Physical access gives you everything.
ron
-
Carl-Daniel Hailfinger -
joe＠smittys.pointclark.net -
Paul Millar -
ron minnich