Hi, [email protected] wrote (13 Jan 2011 12:29:22 GMT) : > When you luksClose a disk/volume, it's key material is forgotten by > the kernel, but still in memory (if I understood how it works). But > it seems that in the kernel the code to wipe a key material is > already there, and used by cryptsetup with the luksSuspend command > (used whe suspending a machine).
Argh. As you highlighted on IRC, if this is really true, this shall be fixed upstream. > I'm no kexec expert, what I understood was loading a kernel this way > overwrite the previous kernel ram space Not really. kexec is a two-step process: 1. load a new kernel/ramdisk into memory (and go on running the current one) 2. boot into the loaded kernel/ramdisk => The new kernel does not overwrite anything. However, all memory that was in use by the previous kernel is considered as free by the new one (apart from the memory space used by the new kernel/ramdisk obviously). > but I'm actually not sure (well, I doubt) that a remainig unused key > material would be overwritten. It is overwritten if and only if the new kernel+ramdisk is loaded at the same place in memory where the key material used to be. This is pure luck and cannot be relied on. > 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. 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. Bye, -- intrigeri <[email protected]> | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc | If you must label the absolute, use it's proper name: Temporary. _______________________________________________ tails-dev mailing list [email protected] https://boum.org/mailman/listinfo/tails-dev
