[dm-crypt] nuke password to delete luks header

.. ink .. mhogomchungu at gmail.com
Tue Jan 14 13:05:32 CET 2014

On Tue, Jan 14, 2014 at 2:11 AM, Arno Wagner <arno at wagner.name> wrote:

> On Tue, Jan 14, 2014 at 06:00:23 CET, .. ink .. wrote:
> > > > with cryptsetup,the way to do it would be:
> > > > 1. start with a block device like a usb stick
> > > > 2. blank it out with random data.
> > > > 3. put a regular file system like vfat at the beginning of the
> device.
> > > > 4. put an encrypted plain volume somewhere at the back of the device.
> > >
> > > And any reasonable disk forensics tool will find that automatically
> > > and fast. My keyslot-checker could be adapted to find something like
> > > that in maybe one hour.
> > >
> > >
> > are you saying that,if i create a 100MB file with data from
> "/dev/urandom"
> > and then put a vfat file system on it,and then i open a plain mapper at
> > 50MB offset and create a second file system on the file through the
> > mapper,then your keyslot-checker or any other forensic tool will be able
> to
> > detect the presence of this plain volume?
> No, if you crypto-blank it, it will not. But you need to protect
> the additional container against overwriting in some way. One
> way is to not write the outer container at all. This is obvious,
> as it is going to be either old and not written for a long time
> or brand-new, i.e. container has been creatded for the border-
> crossing. The way TC does it by preventing writes to that
> area is likely to leacve traces of the failed writes.
Its possible to use the first volume normally without harming the hidden
one by not filling up the out volume
to near capacity.If you dont cross past 30% volume utilization of the outer
volume,then the hidden volume will be
safe.This assumes using a proper file system and fat seem to be the best
one to use since its the most advanced
among the simplest file systems.

The scenario i am working with says something like this,you are at a border
cross with a external hard drive and there are 10 other people with
external hard drives and there is a government agent who is tasked with
examining external hard drives.What he may do is ask everybody to put their
hard drives in a bucket and he may go through them one by one.He will take
one,plug it in to a computer and look into it by doing file searches,then
go to the next one and do the same.If they reach yours,plug it in and get a
LUKS prompt,then they will call you up and ask you to open it,they will
probably be annoyed at you for slowing them down too.Once there,bringing up
the fifth amendment to the constitution or any other privacy related
explanation will probably not do you any good.The more you delay them,the
more they will be unhappy with you and the more unpleasant they will be.

If they have no reason to suspect you have an encrypted volume hidden at
the back of a regular file system,they will not look for it or ask you
about it and will just go past your hard drive uneventfully,the only time
they will examine your hard drive forensically is if you are already at the
backroom being interrogated while your possessions are being closely
scrutinized and they will do this most likely because they already know who
you are and what you could be carrying and you did something stupid to draw
suspicion to your hard drive.

If asked if the drive has a hidden volume,you could then answer "yes" and
proceed to do what you would have done if asked to unlock a LUKS volume or
any other encrypted volume.

> > If true,then i would appreciate any link to any discussion of it because
> i
> > am unaware of it.
> See above.
> Arno
> --
> Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno at wagner.name
> GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
> ----
> There are two ways of constructing a software design: One way is to make it
> so simple that there are obviously no deficiencies, and the other way is to
> make it so complicated that there are no obvious deficiencies. The first
> method is far more difficult.  --Tony Hoare
> _______________________________________________
> dm-crypt mailing list
> dm-crypt at saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.saout.de/pipermail/dm-crypt/attachments/20140114/f32df8d4/attachment.html>

More information about the dm-crypt mailing list