Re: How about deniability? (read:http://www.zdnet.co.uk/print/?TYPE=story&AT=39269746-39020330t-10000025c)

[Matthias Schniedermeyer <ms@xxxxxxx>]

Jari Ruusu wrote:
> Thomas Weinbrenner wrote:
>
> > The timestamps will show that the files weren't accessed for months or
> > even years. And there are also all those logfiles in /var/log which
> > include dates. I think there will be enough proof that the system wasn't
> > can't be the system you are normally using.
>
>
> Q:  Why haven't files been accessed for months?
> A:  Because file system superblocks contain "noatime" default mount option.
>
> Q:  Why aren't there any log files in /var/log/* ?
> A:  Because init scripts have been modified to shred and remove /var/log/*
>     and some other files and directories in /var on shutdown.
>
> In addition, a shell script, run as cron job once a week from 'normal' root
> partition /dev/hda4, does these: (1) Fsck and mount /dev/hda2 (via encrypted
> loop) and /dev/hda1 partitions so that their previous fsck and mount times
> are updated on their superblocks. (2) Touch some decoy files and directories
> from /dev/hda2 partition.

That wouldn't work in the police-case, when the computer was switched on 
when sized, or when you can recover the "real" time of last use.
For perfect denyability you would have to update the "decoy" system 
continously, when the real-system is used.

Or you could configure  syslog to "/dev/null" everything, or switch off 
syslog entirely.
OTOH it would be "fishy" if only of the system-parts were missing that 
provide time-information, even if they are per definition unusable as PROVE.

Otherwise you could still somewhat prove that the "decoy" system wasn't 
the one running when the computer was switched off (as you have the 
switch-off "timestamp").

But if one doesn't need 100% deniability: In an article about 
warez-servers i read that at least once they encountered a server that 
was 100% "on the fly" configured.
The whole system was on ramdisk(/ramfs/tmpfs). After switching of there 
was nothing left, except a bootstrap barebone-system on HDD(*).

A loop-aes-partition with random-key would be equally secure, when 
switched off if configured "on-the-fly" the key would be unrecoverable.
Only the work and time needed to get the system flying the first time 
and every time it is rebooted, for whaterver reason, seams a bit much. ;-)



*: The "root"-servers i worked with allow to be booted via network into 
a "rescure"-system.
This way even the HDD isn't needed to bootstrap the server.

Bis denn

--
Real Programmers consider "what you see is what you get" to be just as
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated,
cryptic, powerful, unforgiving, dangerous.


-
Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/