BHDC11 - De-anonymizing Live CDs through Physical Memory Analysis

[bertagaz at ptitcanardnoir.org]

Hi,

On Wed, Jan 12, 2011 at 04:06:05AM -0800, coderman wrote:
> On Wed, Jan 12, 2011 at 3:11 AM, intrigeri <intrigeri at boum.org> wrote:
> > ...
> >> (do Tor Live CDs need a new kexec target for memtest sweeps / ram
> >> zeroisation? :)
> >
> > As far as I understand, this seems like enhancements over the cold
> > boot attack, and one more reason why Tor Live CDs should wipe the
> > system memory on shutdown. Am I misunderstood?
> 
> likely so. however, more than just wipe at shutdown is useful.
> 
> explicit ordered zeroisation is handy. (starting with keys and key
> schedules, working cipher state, then on to user data, before
> completing a full pass or three. this takes a smart kexec or other ham
> fisted - still worth the effort.)

There is actually discussions on lkml about this [1]. Actually, code to wipe
the encryption keys in ram is already in the linux kernel, but available
only when you do a suspend. That is cryptsetup luksSuspend does use
dm_crypt's crypt_wipe_key function. 

There is an obvious problem when the rootfs is encrypted, as once you wipe
the encryption keys, you can't access anymore the necessary files to go on
with the shutdown process. A page on the debian wiki has started some
thoughts about this [2], surely the solution would be the kernel to issue
this wipe key function at the very end of the shutdown process. Still this
wouldn't address the issue of the system being shutdown the hard way (e.g
by removing the computer power source).

I did not test extensively, but it seems you can luksSuspend a device, and
then luskClose it, so maybe closing a non-rootfs this way might be help in
zeroing its key material.

> synchronous wipe on shutdown in foreground with progress indication. i
> argue this necessity on usability basis.

Which is T(A)ILS does :)

> experimental methods like key and state storage in CPU cache lines may
> hold promise.

There were discussions about this when the cold boot attack was disclosed,
and it didn't appears to be such a good solution [3]. But maybe you're
talking about another method.


[1] http://lkml.org/lkml/2010/6/26/37 (read the thread)
[2]
http://wiki.debian.org/AdvancedStartupShutdownWithMultilayeredBlockDevices/How-To-Secure-Cryptsetup-Shutdown
[3] http://it.slashdot.org/article.pl?sid=09/01/18/2110235
***********************************************************************
To unsubscribe, send an e-mail to majordomo at torproject.org with
unsubscribe or-talk    in the body. http://archives.seul.org/or/talk/