Hiding A File
When an existing file in the filesystem has to be hidden magikfs asks for the filename and the password. We have planned to use Rijndael A.E.S. for encryption. The filename is encrypted with the password and a signature is formed. Our ‘inode’ structure will look like this…we may modify it later for more security
Struct ext2_inode inode;
The whole structure will be encrypted and stored.The procedure for hiding will be as follows.
A random block number will be generated from the filename and password. An example for such a generation would be to take the add and subtract alternate squares of characters from the filename and password and then multiply these values. Then it is divided by the total number of blocks and the remainder is taken as the random block where the magikfs inode will be placed. But if this block is already allocated then the next block will be taken and this will go on until an unused block is found.
Then random blocks are generated for each block that is needed by the file and stored in the appropriate indexes of the inode upto triple indirection. The bitmap will be set for each of the used blocks. But no other changes to the filesystem are made. The superblocks and the group descriptors and the inodes remain as it was before. The number of free blocks will not be altered anywhere. (We have to test this because we doubt that it may cause some inconsistencies and also be careful about programs like e2fsck which may change these entries) . Note that apart from setting the bitmaps, no change in any of the inodes, directories, group descriptors etc are made. There will also be an option NOT to set the bitmap so that it becomes even more difficult to detect the presence of sensitive data. But there is the risk of data getting overwritten so users will get a warning before using this feature. (The data needs to be backed up somewhere, if this feature is used).
At the end of all this the original file is destructively deleted if it resides in an ext2/3 partition.
Unhiding A File
The user will be asked to enter the filename and the password and the random block will be generated using the above method. Now each block from this random block is checked to see whether it is allocated or not. Once it encounters an allocated block it decrypts the signature i.e. by taking just the first 256 bytes ad it is compared with the original filename. If they mach then that is the correct inode. Then the remaining blocks of the file are got by decrypting the inode.
There will also be 2 modes of unhiding the file.
Permanent Unhiding:-In this mode the hidden file will be mounted as a non hidden file in the file system ie. A normal file. This means that it is no longer hidden unless the hiding process is repeated again.
Temporary Unhiding:-In this mode the hidden file will be temporarily made visible for a period of time after which it will return back to its original hidden state without leaving any trace. It will not be mounted anywhere on the hard disk but only in main memory (may be only a part of the file). This means that the file can be made visible before unhiding only
if you have the filename and password.
At the time of installation of the file system the whole of the unallocated blocks are filled with random values so that it cannot be distinguished from the hidden file blocks. These operations will be done by a program called mkmagikfs (similar to mke2fs). There are many optional features that you can set too. You can set some abandoned blocks whose bitmap values are set so that it becomes indistinguishable from that of the hidden file blocks whose bitmap values are also set. Also some dummy hidden files could be added to mislead the intruder.
Hiding Directories ( Levels of hiding)
There would also be a provision for hiding directories as a whole and in this case the inode would point to a set of directory entries and these would in turn point to the inodes of files of subdirectories. By using this method levels of hiding can be done with each such directory being one level. So even if some one gets suspicious and detects magikfs one can show some of the useless levels and keep silent about the more important levels.
The above mentioned details are included in the basic implementation and later we plan to take further steps so as to support steganography on a multi-user environment and also the backup of a steg filesystem.
Initially the above mentioned aspects are tested on a file as a filesystem using the read() write() system calls to access raw filesystem data. After this, the code will be moved to kernel space and tested again.Currently we are developing the filesystem using FUSE (Filesystem in USEr space) which is a source forge project.