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. _______________________________________________ tails-dev mailing list [email protected] https://boum.org/mailman/listinfo/tails-dev
