[mdlug] Dick encryption

Raymond McLaughlin driveray at ameritech.net
Fri Feb 22 13:49:28 EST 2008


Jeff Hanson wrote:
> On Fri, Feb 22, 2008 at 10:53 AM, Garry Stahl <tesral at comcast.net> wrote:
>> http://www.networkworld.com/news/2008/022108-disk-encryption-cracked.html?page=1
>>
>>  Network World article pointing out that who controls the physical
>>  computer, controls the data in it.  There is a method to crack disk
>>  encryption.  It ain't easy, and you would have to have it ready, but it
>>  is possible.
> 
> The security implications of loading the decryption keys into DRAM is
> something I though of myself a while ago.  I hadn't realized that the
> data retention was that long without power or that cooling them could
> increase the data lifetime.

I was likewise surprised by this. It seems like motherboard
manufacturers adding a "zero all memory" routine to power up, reset,
and power down routines could go quite a ways toward mitigating this
concern.

For that matter, couldn't a "key flush" routine be added to umount
routines to zero the memory location that held the key. DRAM is not
magnetic media that retains "shadows" of its previous states.

> My theory was that it would be possible
> to read the memory bus while the system was active and pick up the
> keys that way. 

But that would require physical access to the memory bus, in which case
you are "owned" from the get go.

<SNIP>

> The only
> advantage they offer is a more complicated architecture that would
> have to be reverse engineered first so that an attacker would know
> where to look before attempting to find the key (obfuscation).  I was
> thinking that storing the key in a CPU register would be better as the
> complexity and small feature size would make it a lot harder to
> extract.  OpenBSD, IIRC, randomizes memory locations so theoretically
> it would be more difficult to find a key (again obfuscation).

Obfuscation wouldn't provide much protection. I've seen other article
mentioning researcher who's developed algorithms for finding crypto keys
in memory dumps, including "error correction" schemes to compensate for
bit rot.

> I think
> the Linux solution is to have the kernel wipe entire memory space
> before halting or suspending.

Ah, yes that's my suggestion, you did beat me to it.

I think an understated aspect of this situation is that it pertains to
encrypted filesystems which were "very recently" mounted. I think
something to be taken away from this is that an encrypted file system
that's "always mounted" isn't really very protected.

 This also speaks well of powering notebook computers all the way down,
rather than suspending, before transport, if the security of encrypted
information is important.

Raymond McLaughlin




More information about the mdlug mailing list