Re: [T(A)ILS-dev] BHDC11 - De-anonymizing Live CDs through Physical Memory Analysis
Hi, berta...@ptitcanardnoir.org 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 intrig...@boum.org | 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 tails-dev@boum.org https://boum.org/mailman/listinfo/tails-dev
Re: [T(A)ILS-dev] BHDC11 - De-anonymizing Live CDs through Physical Memory Analysis
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 tails-dev@boum.org https://boum.org/mailman/listinfo/tails-dev
Re: [T(A)ILS-dev] BHDC11 - De-anonymizing Live CDs through Physical Memory Analysis
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
