Hi,
This thread on or-talk made me discover a way that might be interesting to
implement to actually wipe encrypted disks key material.
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).
I'm no kexec expert, what I understood was loading a kernel this way
overwrite the previous kernel ram space, but I'm actually not sure (well,
I doubt) that a remainig unused key material would be overwritten. That
would require some tests I guess, or explanation of the kexec process
which I'm not sure to understand completely.
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.
Any opinions?
bert.
On Thu, Jan 13, 2011 at 12:37:51PM +0100, intrigeri wrote:
> Hi,
>
> (Now Cc'ing tails-dev mailing list.)
>
> coderman wrote (12 Jan 2011 12:06:05 GMT) :
> > however, more than just wipe at shutdown is useful.
>
> Ack. On second thought, it appears to me the current T(A)ILS "wipe
> memory on shutdown" implementation does not necessarily protect
> against the attacks that the mentioned talk will probably highlight.
> It is likely that some other similar implementations in Live systems
> are affected as well.
>
> In short: we wipe *free* memory only, in order to keep the system in
> working state and let the shutdown sequence finish its work afterwards
> (i.e. actually halt or reboot the system). On the other hand, data
> saved in the {union,au}fs ramdisk branch is not free memory and might
> thus be recovered. A security announce about this is being worked on
> (explaining this problem and the possible consequences to
> non-technical users is, well, tricky).
>
> > 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.)
>
> The kexec idea seems brilliant to me: this is the best way I can think
> of to run the memory wipe process inside an environment where almost
> all of the memory is considered as being free.
>
> I have thus started implementing this idea in T(A)ILS. Thanks to
> Debian's initramfs-tools and kexec-tools, drafting an early prototype
> was quite easy. Stay tuned, more to come soon.
>
> > in any case, this begs the question of best practice in solid state
> > remanence avoidance. it would make a good FAQ entry, perhaps...
>
> T(A)ILS specification and security design document (draft almost ready
> to be published to a wild, unsuspecting world) intends to propose a
> set of best practices in this field.
>
> Bye,
> --
> intrigeri <intrig...@boum.org>
> | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
> | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
> | Do not be trapped by the need to achieve anything.
> | This way, you achieve everything.
> _______________________________________________
> tails-dev mailing list
> tails-dev@boum.org
> https://boum.org/mailman/listinfo/tails-dev
_______________________________________________
tails-dev mailing list
tails-dev@boum.org
https://boum.org/mailman/listinfo/tails-dev
