Secure Datacontainer (I hope, Coding Flaw somewere)

[RobinVossen]

I try to make a 'Secure' Data Container without having to install Extra Kernel Modules..
but I have some problems. (I do this since I run OpenVZ and Thus I cant run Truecrypt or something like that)

Can someone Correct me were I am wrong?

I can Make a Device doing:

dd if=/dev/zero of=/home/user/storage bs=$1 seek=2047 count=1 
mkfs.ext2 /home/user/storage
aescrypt /home/user/storage $2

Where $1 is the Size of the Device and $2 is the SecretKey
aescrypt is a Small program I wrote that encrypts a file using the AES Algorytmn and replaces it with the original file.

Then I can Mount Device doing:

aescrypt -u /home/user/storage $1
mount /home/user/storage /dev/loop2
mkdir /home/user/storage
mount -o bind /dev/loop2 /home/user/storage

Where $1 is the SecretKey
the -u makes it to decrypt instead of encrypt.

Now I can just save all my data that I want to be Secure in the /home/user/storage folder (Don't confuse me with the /home/user/storage file they are Different)

Then I can UnMount the Device doing

umount /home/user/storage
rm -r /home/user/storage
umount /dev/loop2
aescrypt /home/user/storage $1

Where $1 is the SecretKey again.

Making the Files Unreadable again right?

I hope I am right but I have a problem at the Beginning already.
I cant mount my Device to /dev/loop
Since I get:

Application_Server _sxb # mount secure /dev/loop2
mount: unknown filesystem type 'ext2'

Can anyone help me with this?

Oh and if I do it with ext3 I get:

Application_Server _sxb # mount secure /dev/loop2
mount: secure is not a block device (maybe try `-o loop'?)
Application_Server _sxb # mount secure -o /dev/loop2
mount: can't find /home/_sxb/secure in /etc/fstab or /etc/mtab
Application_Server _sxb # mount -o loop secure /dev/loop2
mount: Could not find any loop device. Maybe this kernel does not know
       about the loop device? (If so, recompile or `modprobe loop'.)
Application_Server _sxb # modprobe loop
FATAL: Could not load /lib/modules/2.6.18-1-openvz/modules.dep: No such file or directory

[HROAdmin26]

I don't know how your aescrypt script is written, so I can't speak to that...

I use the LUKS-extended dm-crypt/cryptsetup that is available in any newer kernel: LUKS

For example, SuSE 10.3 by default includes the latest 1.0.5 version of cryptsetup-luks.

Without having to write any custom cipher, you can:

1. Use dd to create your volume/file.
2. Format the device as an encrypted volume and set the passphrase:

cryptsetup-luks -c aes-cbc-essiv:sha256 -y -s 256 luksFormat /path/to/file

3. Create the mapper link (loop device) to mount it (will be /dev/mapper/enc-volume):

cryptsetup-luks luksOpen /path/to/file enc-volume

4. Format it:

mkfs.ext2 /dev/mapper/enc-volume

5. Mount it:

mount /dev/mapper/enc-volume /mnt/name

Moving forward, you must "unlock" the volume in subsequent reboots before it can be mounted. You provide the passphrase to unlock it:

cryptsetup-luks luksOpen /path/to/file enc-volume
mount /dev/mapper/enc-volume /mnt/name

Done.

* Note that some distro's (like SuSE) have integrated the LUKS extension directly into cryptsetup, so the binary is just "cryptsetup" and a separate "cryptsetup-luks" is not needed.

HTH.

[kakariko81280]

The file you have created is not a block device so can't normally be used as such. The loop module lets you use a file as a block device. Way back when this was new you had to use losetup to configure the file-to-block-device bit and then use mount separately to mount the loop device to a mount point. Since you are experimenting in this regard, it may be useful for you to google losetup and try it out so you know the full workflow.

In the meantime, loopback devices became more common and the mount command was extended to support them more easily.

Try this:

mount -o loop /home/user/storage <mount point>

Personally, I'd investigate cryptsetup like HROAdmin26 said. The modules it relies on are pretty common these days (noting a total lack of knowledge about the effect of openVZ).

Let us know how you get on,

Chris...