Date: Sat, 23 Feb 2008 22:58:50 -0800 (PST) From: Tim Clewlow <tim1timau@yahoo.com> To: hackers@freebsd.org Subject: Re: Security Flaw in Popular Disk Encryption Technologies Message-ID: <257786.91158.qm@web50310.mail.re2.yahoo.com> In-Reply-To: <47C0AD9D.2070701@andric.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--- Dimitry Andric <dimitry@andric.com> wrote:
> On 2008-02-23 02:08, Atom Smasher wrote:
> > article below. does anyone know how this affects eli/geli?
> >
> > from the geli man page: "detach - Detach the given providers, which means
> > remove the devfs entry and clear the keys from memory." does that mean
> > that geli properly wipes keys from RAM when a laptop is turned off?
>
> This is a physical attack, and there's nothing you can do in software to
> prevent it. Of course geli or other software can attempt to erase the
> keys from RAM as soon as it's done using them, but it won't prevent
> hijacking them beforehand.
>
> It's the same with all physical attacks: hardware sniffers, keyloggers,
> TEMPEST, etc. You need physical (hardware) protection to secure
> against these, not software.
The cracking method relies on the ability to find the key in memory, so, if the
key is obfuscated then this would mean the cracking method could no longer find
the key even if it has access to memory. For example, create a series of random
bytes of equal length to the key, lets call that the "obfuscator". And now xor
that with the key, lets call that the "xord key". To use the enc/dec system an
extra step would need to xor back to the original key.
The idea is that real key is only created when needed for use, and then
immediately overwritten after use. If the "obfuscator" and the "xord key" are
stored in memory at unpredictable locations, ie dont just have them sitting
next to each other, then this would make it much more difficult to _find_ the
key as it would now involve identifying two groups of randomly located (in
memory) bytes that are xor'd to create the real key.
Yes, with sufficient reverse engineering it would be possible to find out where
the "obfuscator" and "xord key" have been stored, but this would at least stop
the relatively trivial search method being used in the paper.
Just a thought, and yes, I have now actually read the paper.
Tim.
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?257786.91158.qm>