On Fri, Jan 14, 2011 at 12:26:13AM +0100, intrigeri wrote:
> Hi,
>
> > Still, if the kexec method don't help in wiping key material, I
> > suppose writing a very simple wrapper to cryptsetup that use
> > luksSuspend then luskClose when cryptsetup is called to luksClose an
> > encrypted disk might be an excellent way to wipe remaining key
> > materials.
>
> As I explained above, kexec itself does not wipe the key material. It
> is merely a tool that provides us a fresh runtime environment, inside
> which we can wipe all free memory without the system getting stuck,
> i.e. we can still properly halt/shutdown the system afterwards,
> without relying on really black magic tricks and calculations that
> cache stuff and kill smem before it erases tools needed to shutdown
> the system.
>
> The work I am doing aims at booting (using kexec) a kernel+ramdisk
> that:
>
> 1. wipes memory (i.e. all memory but the one that is used by the new
> kernel/ramdisk)
> 2. halts/reboots the system, accordingly to what the user asked for.
This is surely a big enhancement over our previous implementation, nice
you're working on it.
> Having cryptsetup wipe the key material itself on luksClose would
> nevertheless be welcome: not only defense in depth seems really useful
> in our usecase, but doing this would ensure the key material for
> closed encrypted devices is not available anymore, even in case the
> shutdown-time memory erasure cannot happen for whatever reason.
On that subject, I realized this morning that I was wrong, actually
cryptsetup DO wipe keys on luksClose and some other operations. It has
implemented it in lib/volumekey.c (crypt_free() function), which I hadn't
really reviewed yet. Sorry for my mistake, but happy being safe :)
bert.
