when the shit goes down …

Къде бях, къде отидох и пак и пак и пак … къде се връщам … след айляк :D

I have recently migrated my desktop PC from Linux to FreeBSD-6.2 after I have messed up the system libraries of the both Linux distributions I had installed on my PC … at the same time :) Fortunately the file system stayed in tact and I did not loose any files (except the libs heaheah)

I used to have a small 512MB encrypted file container which was using the Linux Cryptoloop (AES-256) devices to protect the data in it on my ex-Linux boxes.

The container was mounted as a regular disk drive with the help of the Linux Loop devices kernel option (mount -o loop,encryption=aes-256) as I did not need an entire encrypted hard drive.

After the migration I had to move the data from this container to a similar one but encrypted with a system supported by the FreeBSD operation system.

I was aware of GBDE (GBDE is GEOM based disc encryption scheme that allows the users to encrypt their entire hard drive) and I tough that it will fit to my personal needs. Since I did not need the entire hard drive encrypted I have decided to look for tools similar to the Linux loop devices.

It took me a while to find out that Linux loop device system = FreeBSD memory devices and I have decided to write a small FAQ.

I hope that it will save your time if you face a similar problem.

Fortunately FreeBSD-6.x comes with options that allows hard disk encryption by default and they are fully supported by the GENERIC FreeBSD-6.x kernel.

Additionally the system comes with memory devices (md(4)) support turned on by default. Memory devices allow the user to attach a single file as a storage device. Memory devices can be controlled by using the mdconfig utility. From its man pages:

*cut*
mdconfig — configure and enable memory disks
*cut*
The mdconfig utility configures and enables md(4) devices.
*cut*

For more information, please check:

man 8 mdconfig

Ok. Let’s start with the preparation of our file container:

[root@sunrise ~]# cd /usr/

We have to create a file with a size of our personal choice. Since I do not need a lot of space for my private files 512MB are more than enough for me:

[root@sunrise /usr]# dd if=/dev/urandom of=magick bs=1024k count=512
512+0 records in
512+0 records out
536870912 bytes transferred in 88.384740 secs (6074249 bytes/sec)

The dd utility copies the standard input to the standard output. By using the if option we specify that the input should be copied from the /dev/urandom system device. The output is written to a file named magick. This is specified by the of=magick option. The size of the buffer that should be copied is 1024k (bs=1024k) and count=512 specifies how many times we should copy 1024k buffer from the /dev/urandom device into the magick file.

In order to be able to manipulate the magick file as a standard memory device we have to attach it to the system. This will allow us to re-attach the file as an encrypted disk and later to create a new file system inside the GBDE encrypted disk.

[root@sunrise /usr]# mdconfig -a -t vnode -f magick
md0

The above command:

-a Attach a memory disk. This will configure and attach a memory
disk with the parameters specified and attach it to the system.

-t type
Select the type of the memory disk.

vnode A file specified with -f file becomes the backingstore
for this memory disk.
-f file
Filename to use for the vnode type memory disk. Options -a and -t
vnode are implied if not specified.

attaches magick as a system memory device :). If you do not have other memory devices configured with the mdconfig tool the command will create a new device node:

/dev/md0

Ok. As we have just configured our file container as a hardware storage node we can continue with the setup of the GBDE disk encryption.

By using the gbde tool:

gbde — operation and management utility for Geom Based Disk Encryption

we can encrypt md0 which represents our magick file container.

[root@sunrise /usr]# gbde init /dev/md0
Enter new passphrase: zvQzdi heahheah
Reenter new passphrase: zvQzdi heahheah
[root@sunrise /usr]# gbde attach /dev/md0

You should provide the password that you will use in future to mount your encrypted file twice.

***NOTE*** Due to security reasons you should use a strong password that contains minimum 20 characters. It is recommended for the password to contains all of the below:

Upper case characters
Lower case characters
Numeric characters
Other punctual symbols

Also please note that you should remember the password. If you forget it you will NOT be able to repair the password in any other way but by only using a brute force attack against the gbde tool. At least I am not aware of other methods.

Ok. We have our container prepared and the password is already set. Now we have to attach it to the system once again so we can later create the file system that will store our data:

[root@sunrise /usr]# gbde attach /dev/md0
Enter passphrase: i pak zvQzdi

Above we are attaching our newly created encrypted container to the system. We are asked to provide the password otherwise we can not manipulate the data we stored in the file. If the password matches with the one we provided during the initial GBDE setup a new special device file is created:

[root@sunrise /usr]# ls -al /dev/md0*
crw-r—– 1 root operator 0, 126 Jul 7 05:02 /dev/md0
crw-r—– 1 root operator 0, 127 Jul 7 05:02 /dev/md0.bde
[root@sunrise /usr]#

The next step we should follow is to create our file system inside the encrypted system by manipulating the md0.bde device by using the newfs(8) tool.

[root@sunrise /usr]# newfs /dev/md0.bde
/dev/md0.bde: 496.5MB (1016768 sectors) block size 16384, fragment size 2048
using 4 cylinder groups of 124.12MB, 7944 blks, 15936 inodes.
super-block backups (for fsck -b #) at:
160, 254368, 508576, 762784

So we are all set. Now we can mount mount /dev/md0.bde as a regular disk drive and copy our private files in it:

[root@sunrise /usr]# mkdir /mnt/magick
[root@sunrise /usr]# mount /dev/md0.bde /mnt/magick/
[root@sunrise /usr]# chmod 700 /mnt/magick/

***NOTE*** Please make sure to execute the chmod command. Otherwise each time the the device is mounted file group owners and the others will be allowed to see the directory content and read the files in our mount point. As it holds our private files we do not want this right?

[root@sunrise /usr]# cd /mnt/magick/
[root@sunrise /mnt/magick]# ls -al
total 6
drwxr-xr-x 3 root wheel 512 Jun 28 15:02 .
drwxr-xr-x 4 root wheel 512 Jun 28 15:03 ..
drwxrwxr-x 2 root operator 512 Jun 28 15:02 .snap

You can now do what you got to do copy your files to the mount point, edit them etc.

Once you finish you have to unmount the container, detach the encrypted device from the system and remove the configured memory device:

[root@sunrise /mnt]# umount /dev/md0.bde

After the above command your encrypted file system can be re-mounted again without the need to provide the password as /dev/md0.bde still exist as a system device.

You are not safe before it is detached:

[root@sunrise ~]# gbde detach /dev/md0
[root@sunrise ~]# ls -al /dev/md0*
crw-r—– 1 root operator 0, 126 Jul 7 05:02 /dev/md0

Ok. Once detached the GBDE device can not be re-attached and mounted to the system without the password. If you wish you can remove the memory device from the system too:

[root@sunrise /mnt]# mdconfig -d -u 0

Now your private files are inside a single file that consists of nothing but a garbage bits :)

[root@sunrise /usr]# file magick
magick: data
[root@sunrise /usr]# strings magick
hj |cc}
UPJ!
p`r~
etc. etc.

References:

FreeBSD mail list
FreeBSD handbook
For security fanatics and paranoids it seems that AES is breakable …

Please excuse my poor English. Damn. I still have problems with it :)

[root@sunrise /usr]# reboot
The author is transferring himself to “How-high” NOW :)