Re: [gentoo-catalyst] Encrypted livecd's - need testers

[Erick M]

I do not mean to undertake your idea, but I got this simple question that
your design does not solve:

What's next when you get caught?

The whole point of your system is protection of data for the user if the CD
falls into other hands. But the legal context nowadays requires you to give
the key.

- With your system on my livecd, legally I can get in Europe 2 years and a
huge fine if I keep my password secret, hence I will handle the key to get
something under those 2 years, and every one would do so even you, I guess.
Your design is like writing on that CD that it is encrypted: the first guy
who boots it finds out that you have something to hide!

So at the end, the whole design of such system falls into pieces. I mean,
it's alright for the university, your friends but it is simply not enough
against legal constraints which is my main concern, let's face the worst
enemy, cryptography simply fails to protect valuable information because of
yourself: be realistic, will you just keep your mouth shut when that legal
voice will trade:"give us the password or it's 2 years!"?

- With my system on my livecd, the overall clear side is part of the stealth
concept, keep it as usual as you can from the outside, the less change the
better. Then I just copy my binary to something irrelevant into /usr/bin and
my container file somewhere in /usr/lib and here we go. From a forensic
perspective analysis it is much more difficult to reveal the encrypted
material. You got in the first place to actually find the encrypted
material(few bytes over a Gigabytes). How can charges be pressed without
evidence? Then when evidence is found as a file, you have several containers
to fall back to. You give a first and single password away that will decrypt
a different part than the one you are protecting.

Finally, the comparison with true-crypt is unfair (for true-crypt) because
it can handle up to 2 containers inside of each other, as denyfs goes up to
16 containers, along with 16  != passwords . It's programmed so, but again
the setup has to take that 15% data ratio in account or you will start
messing with statistic which is your worst enemy. Truecrypt does not deal
with this issue and will never, because math cannot solve this problem. The
probability of collision increase exponentially with the number of
containers along with the size of the main container. And yes denyfs one so
often breaks, by overwriting some bits here or there, let's say 1/10 but
this is the reason why it makes it so powerful and no reversible. At the end
it is a human choice, the user defines a trade between the size of his main
container and the number of sub containers he will create to fit the
specific amount of data that needs hiding. And this is the missing parameter
in the problem, hence the reason no such perfect system will ever be
implemented.

If you have containers A and B that  do not know their respective
existences, how can you ensure they won't overwrite bit of one another? You
simply can't! You fall into statistics and the only choice to optimize
integrity is to up size a huge main container and work on say 5% max of the
whole size. Add to that, that 5% rate needs to be lower each time as you
create sub containers.

Cryptography is an open door to investigation, the first question is:"wtf
does he want to hide?"
If you can evade this reflexion in your "opponent" mind then it is then very
highly probable that the material that needs to be hidden will stay hidden!

That's the key concept of military data flow over enemy lines (sounds heavy
but true) nowadays in military IT mainly inspired by an Oxford professor
(the one who wrote the first public implementation forked on ext2 called
StegFS, he's easy to find). The point is to evade torture (physical and
psychological) of messengers when they get caught with encrypted data.

anyway I made my point that the "best" technology for such job exists and is
available and it does *not* apply your design but something much more
subtle.

Good work for your stuff, it's good for countries which do not have yet IT
laws like the one mentioned, Africa, South America (except Brazil) and I'm
sure a couple of penguins in the North pole but for European and US
citizens, this kind of protection has no legal dimension, and will fall into
piece in a real governmental situation.

I'm looking forward to a merge into the official catalyst project.

Thanks for reading.





On 7/1/07, Nelson Batalha <nelson_batalha@××××.pt> wrote:
>
> I would like to quote these two statements:
>
> http://gentoo-wiki.com/SECURITY_System_Encryption_DM-Crypt_with_LUKS#Two_things_to_remember
>
> Thanks for your help, but:
>
> > It does not protect more the user while he uses it nor from
> > potential "after-use" trails.
>
> So? Was I supposed to release a complete secure solution right now? :P
>
> > Either you lose the livecd
> > along with your identity (or data that leads to your identity) and
> > you get caught or while using the software you get caught (like
> > your TOR connections have been detected). The only purpose and
> > advantage encryption would have is to
> > obfuscate some passwords like in the firefox example you gave.
>
> The idea is that with this livecd you're on the move, boot the cd, use
> tor and go away asap once finished. Make sure all your sensible data
> is sent in a package just before leaving. If you lose it or someone
> looks at it, it won't suspect much.
>
> > The real solution to your problem would be to use a steganographic
> > layer ( http://en.wikipedia.org/wiki/Steganography[1] ) .
>
>   It's not like I didn't remembered steganography, read below.
>
> > You will not find much (I mean actual real software) besides some
> > linux-2.2 tweak over ext2 "proof-of-concept" (10years old
> > not stable unreliable)
>
> False? Look for TrueCrypt.
>
> > I think that encryption has nothing to do with hiding. In the
> > contrary, it is like a big flag standing saying "hey look at
> > me I got something to hide, come and get me!". It is just
> > obfuscating technology.
>
> Using the crypt_silent option how likely are you of being catched?
> Just put some binaries of emacs and so on on the root, and demonstrate
> in the fake root that's what is for. It is a good hiding technique I
> think, but not perfect.
>
> The thing is, given the low probability of being catched, either by
> having the squashfs with Steganography or not, some large file would
> be there, and if they're good enough to realize it is a bootable
> livecd and it is forcing a fake boot, then they're good enough to see
> a big closed file is there.
>
> Unless one did multiple hidden volumes inside this one, or just hide
> some files inside the root. But we're back to less usability and we're
> being forced to use truecrypt (I don't see a currently free maintained
> option).
>
> If we accept the Truecrypt restrictions (haven't read everything, but
> it's not gpl so I assume they're more restrictive :P), we could
> implement these several layers of encryption and increase
> functionality with some scripts hidden in a pen for example. But to
> put any programs like firefox+torplugin+tor+privoxy in them, and
> separate in small files, that's a lot of work. This implementation is
> good enough for most cases. Also Luks is well maintained and GPL.
>
> > Now, from a legal point of view, being caught with an encrypted
> > material whether livecd or not in major countries
> > (UK,GER,FR,US,china) requires from you the decryption key
>
> Fine for me, don't do anything illegal in free countries. As for the
> China example, just do as on my second point and use the following
> idea: encrypt with luks as it is, and for the more sensitive files you
> can use stenography using stenography software in a separate volume
> (like a usb pen). If they ask you for the key, give it to them and
> show just some more innocent files you were hiding.
>
> It's better then have the cd almost all open, again, because you may lose
> it.
>
> Let me know if I'm wrong or if you have more ideas ;)
>
> Cheers,
> Nelson
> --
> gentoo-catalyst@g.o mailing list
>
>