Hi,
bertagaz@??? 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 <intrigeri@???>
| 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.
