Opiated file systems

[Adam Back]

Joseph Block <jpb at miamisci.org> writes:
> At 10:44 AM -0400 7/16/96, Mark O. Aldrich wrote:
> >One problem, however, would be how to keep the "decoy" data, accessible
> >with only the ambush key, "fresh" in that it must undergo a certain amount
> >of turbulence to appear real.

A problem yes.  My thoughts were that you would effectively have two
filesystems and use them both yourself for real work.  That is to say
that you would say have some consulting work doing some programming or
something, and use the 1st encrypted filesystem for this work.  If
this work was covered by an NDA, so much the better, as it would
provide an understandable reason for encrypting.

> >The two file systems would essentially have to
> >mirror each other, one with the juicy bits and one with the decoy bits.
> >It would seem to be practically impossible to just build two file systems
> >as one would 'disappear' when only the ambush key was used.  Wouldn't it
> >be sort of obvious that something was wrong if half the disk vanished?

I don't think nuking the data is the way to go, from what I understand
of the way these things work, is that they kick down the door in the
dead of night and make sure you don't get to touch the equipment.
Also they'd be sure to take a sector level backup of the drive as a
first step.

If you have your duress encrypted file system, with the "real" file
system in the unused space of that filesystem, and the hidden file
system is encrypted with an unknown (to them) 3DES key, I don't see
how they are going to be able to prove that it is not just noise.
(This is presuming it is a feature of this encrypting file system that
it ensures unused space is always filled with noise anyway, even
inside the first layer of encryption)

The question of freshness Mark raised, if I understand correctly is
interesting.  I presume here he is talking about the fact that under
analysis it is possible to retrieve information from hard drives which
has been deleted and overwritten even multiple times with other data,
due to the relative inaccuracy of disk head placement, and other
factors.  Perhaps it is even possible to tell how recent a magnetic
pattern is even?

In an encrypted file system with no hidden file system, if the unused
space were filled with random garbage, you might expect that garbage
to have been modified fewer times, or less recently than the real
data.  If there were a second hidden file system in those unused
blocks, it might show up due to being written to more recently, or
more often than expected.

If the threat model includes this kind of analysis, I think it would
be necessary to ensure that all the data is churned evenly, or
sufficiently that there is little chance of extracting this kind of
information.

What I would suggest is that during periods of disk inactivity the
data (even the unused space whether it is a 2nd partition or not) is
re-encrytped with a new random IV at some frequency.  The frequency
chosen should be to ensure that all the data on the disk is recent,
and that in the course of disk usage over a period of a week there are
many re-writes with data re-encrypted with random IVs to all areas of
the disk.

> As far as churning goes, why not just mount both the decoy and the
> encrypted filesystems simultaneously?  

I think you would have to mount them both during normal usage to avoid
damaging the real filesystem hidden in the unused space.  Only in the
event of a duress situation would you mount only the duress file
system.

This next bit must be talking about the stegoed file system:

> Have a perl script (stored on the hidden volume of course) that
> automatically decodes random images from alt.binaries.pictures.*
> into the decoy system and nukes the oldest decoy files.

Careful.  For stego you can't use publically available images -- they
have to be images you scanned yourself, other-wise comparison will
show that the images have been altered.  (Law enforcement agents read
a.b.p.* too).

Adam
--
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)