BHDC11 - De-anonymizing Live CDs through Physical Memory Analysis

[coderman]

On Wed, Jan 12, 2011 at 5:44 AM,  <bertagaz at ptitcanardnoir.org> wrote:
> ...
>> 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).

right.  there are trade-off's with the kexec approach, mainly that
you're bypassing most normal shutdown.

i don't care, as long as dirty pages are written before mem is trashed...

the kernel key management facilities do make it easy, although you
also need to consider userspace like OpenSSL keys and cipher state.


>> synchronous wipe on shutdown in foreground with progress indication. i
>> argue this necessity on usability basis.
>
> Which is T(A)ILS does :)

kudos sir!


>> 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.

nope, that's the method. it is ghetto, for sure, but unless you've got
a real HSM that's as good as you'll get.

and as mentioned, cache line key storage is only effective if the
entire key, including any expanded key schedules, is kept in cache.
this is another performance hit, unless you've got AES-NI on die or
other acceleration.

anyway, not really practical yet. and likely never will be.

best regards,
***********************************************************************
To unsubscribe, send an e-mail to majordomo at torproject.org with
unsubscribe or-talk    in the body. http://archives.seul.org/or/talk/