stlth Files

stlth
-----

http://sourceforge.net/projects/stlth/
aikiyigo@gmail.com


Abstract
--------

stlth (or "stealth") is a script that uses cryptsetup to provide deniable encryption. It does so by allowing several volumes, without any connection, within the same container. stlth is written in bash and uses the 'cryptsetup' program for the encryption. 
The sizes of the volumes in the container will grow and shrink dynamically, based on usage. This is what creates the deniability; It is possible to claim that all data located after a volume is unused space, and it is (should be) impossible to prove otherwise. 


	WARNING: 
		I am not a lawyer, nor a cryptologist, and there might be security issues that I have not thought of. I take no responsibility, you're on your own. 
		Because of the simplicity of the script, though, there should not be any problems. 
		Note also that, even if there are no bugs in the code, some precautions have to be taken. DO NOT use this script until you have read and understood the 'Caveats'-section



Pros
----
	* Really simple. stlth is basically a user interface, nothing more. You can easily extract the vital commands if you wish to do anything automatically. 
	* No limit on the number of hidden volumes. 
	* No header or table. You can do any file operation with default unix tools. Split and join the container to move volumes around if you wish to. 
	* You only have to enter the password for the volume you want to use. No need to 'protect' the other volumes by entering all the password. 

Cons
----
	* It's your own responsibility to remember the offsets of the volumes. This shouldn't be too hard. stlth counts in 1-Megabyte blocks, so if your container is a 1TB drive you have to remember a 6-digit number. Besides, the offset doesn't have to be hard to guess, you can pick something evenly divisible by 100M or 1G. Should you forget the offset anyway, you can always use the search-function. 
	* You _mustn't_ have several versions of the same container, read 'Caveats'. 
	
Alternatives
------------
	
	Truecrypt - http://www.truecrypt.org
		* No gpl license
		* Only supports one hidden volume
	Scubed - http://cube.dyndns.org/~rsnel/scubed/
		* No longer maintained
		* Nice idea, but too complicated
	Stegfs - http://http://www.mcdonald.org.uk/StegFS/
		* No longer maintained, known file corruption bug. 
	Phonebookfs - http://www.freenet.org.nz/phonebook/
		* No longer maintained
	Rubberhose - http://iq.org/~proff/marutukku.org/
		* No longer maintained, not compatible with modern systems


Installation
------------

Just put the script in "/usr/local/bin" or whatever, and add it to your $PATH

	# export PATH=$PATH:/usr/local/bin

Usage
-----

Start by filling the partition with pseudo-random data:

	# dd if=/dev/urandom of=/PATH/TO/DEVICE bs=1M

This should be a usb-drive that you have physical control over, read 'Caveats'
Then you just run the script as root:

	# stlth /PATH/TO/DEVICE

FAQ (aka "I'm too lazy to read the manual")
-------------------------------------------

What? I can't backup my data?
	Yes you can, using the backup-feature of stlth

Why did you include the stupid search function? It makes it super easy for crackers. 
	Wrong. The search fuction will only tell you where the volume is if you have the correct password for that volume. It is just a convenience for the user. The security of the volume relies on the strength of the password only. 


Tutorial
--------

(When I write offset, I refer to a number of Megabytes into the file.)
You have a partition on a usb-stick that is 20Mb large. First let's fill it with random data:

	# dd if=/dev/urandom of=/dev/MYUSBSTICK bs=1M

Now the device looks like this (just random data):
	
[--------------------]

Let's create a volume at the beginning of the file. 

	# sudo stlth /dev/MYUSBSTICK

Choose 'create'
Press 'enter' to select offset=0
Enter password two times

Enter the size of the wanted file system. In this case let's just press 'enter'
to make it as large as possible. 

Now stlth will first tell you the last MB-block it will write to, and then ask
you to enter it as well. This is to make sure the user would know if another 
volume will be overwritten. If you for example know that another volume starts
at offset 12, you should abort if stlth asks if you want to write to offset 19.

In our case it's no problem, because we know there are no other volumes yet. 
Therefore you enter '19' (or whatever it tells you)

The device looks like this. A is the volume you just created. 

[AAAAAAAAAAAAAAAAAAAA]

Wait for mkfs, and then choose 'mount'. 
Let's store something here. Zeros for example. Open a new terminal and run:

	# dd if=/dev/zero of=/tmp/THE_FOLDER bs=1M count=4

Go back to the terminal running stlth and press 'enter' to umount. 
Here's where the magic is happening. You have only written 4Mb to your volume.
As soon as you umount, resise2fs will run. When done your device looks like
this. 

[AAAA----------------]

Choose 'close' to wipe the encryption key, and then 'create' again. 
This time choose offset=8 and _A DIFFERENT PASSWORD_.  
Repeat the preceeding steps, and you got:

[AAAA---BB-----------]

Do it a couple of more times and you got: 

[AAAA---BB---CCCCCC--D]

The encrypted data is, without the right password, indistinguishable from the
random, unused, data. Because of this you can deny the existance of any or all
of the volumes and claim the space if for future use (except maybe first one,
since you can never expand backwards). For example you can claim that you
only have two volumes:

[AAAA--------CCCCCC---]

All usage should be rather straight-forwand. 
When you want to read (or modify) the content of a volume you choose:
'open' and 'mount'. 
When you want to add data you choose:
'open' and 'resize', to enlarge the filesystem. It will be shrunk automatically
again when umounted. 
Should you forget the offset of you volume you use the search-function. It
will ask for the password to you volume, and try all the offsets. It might take
a while but it's still better than losing you data forever. If you know you 
chose an offset ending with 000, or something, feel free to edit the code to 
just check the probable offsets. 

The backup-feature is not implemented yet, but check the code and do it 
manually if you want. 

	The script accually does this:
		show the menu; user selects 'open'
		Get the offset=o
		create an encryption mapping with the user password
		copy the data between o and o+1 ('salt')
		create a new mapping with that data as the password. (This dev contains the data between the offset and the end of the file)
		use 'dumpe2fs' to verify that there is a filesystem
		show the 'stlth open menu'; User selects (m)ount
		use 'dmsetup' to "lock" the device. This creates a new device that is as small as possible, based on the filesystem size reporte by 'dumpe2fs'. This is to prevent accidental modification of other volumes. 
		mount the device
		User presses Enter
		umount
		shrink fs with 'resize2fs -M' if needed
		show the 'stlth open menu'; User selects (q)uit
		remove encryption mappings
		show the menu; user selects (q)uit
		

Caveats
-------

There are three rules:
	* Maintain control over the media (i.e. usb-stick/portable harddrive)
	* Only backup with the feature in this script
	* Think about the environment

(It might be obvious, but: USE DIFFERENT PASSWORDS FOR DIFFERENT VOLUMES)

The idea behind stlth is very simple. Because of this you have to be aware of
some things. stlth writes exactly where you tell it to write and doesn't try
to hide it. This means that as soon as there are two different versions of the
same container it will be obvious where your secret volume is, and the the 
deniaility is gone. Therefore you should follow these guidelines:

First of all, before creating any volumes, fill the container with random data.
Do not let anyone copy the container.
Do not make normal backups of the container.
Only use devices as containers. If the container is a regular file, it might 
get backed up by accident. 
If you know or suspect that someone has made a copy of the container, you 
simply use the backup feature to create a new one, and discard the old one. 
You may backup the container to a regular file, as long as you _never_
modify it. 
Close your terminal when you're done. 

BACKUP IS NOT IMPLEMENTED YET. (If you really need this now, you can do it manually. Do it right)

	
_IMPORTANT_

When working with steganography, it is hard to make sure the environment is not revealing anything. 
Please read this: 
	http://www.schneier.com/paper-truecrypt-dfs.html
If you use this script on an installed system, a lot of things must be considered. It's your own responsibility. 
The only completely (or not) secure way I know of is booting from a live-cd. But please prove me wrong. 
One idea might be to create a special "stlth"-user, that only has permission to write to the mounted filesystem. But how do you restrict a user from writing to /tmp, /var/tmp, etc. ?

Some potential problems:

	locate is indexing mounted volumes; locate is not indexing /tmp as default on my system
		check out /etc/updatedb.conf
	The following folders can be written to when using the "stlth"-user
		sudo find -L / -maxdepth 3  -perm /o=w -type d  2>/dev/null
	/var/log/auth.log?
	dmesg log?
	kernel event log?
	other services?


Security bugs
-------------
	None known. Someone experienced in this field should confirm this though. 
	Some questions have to be answered: 
		Are these cryptsetup settings sufficient:
			aes-cbc-essiv:sha256, Key: 256 bits, Password hashing: ripemd160
		Is the storage of the password in memory unsafe when searching? (in a bash variable)
		Is the key strengthening insecure?
			make sure the hash process takes one second, to provide equal security to LUKS
		Is /dev/urandom sufficient for the salt?

Other bugs
----------
	Probably many.