view · edit · print · history

Creating an encrypted filesystem on uNSLUg (or OpenSlug for that matter)


So you've got your wizzy slug serving all your data, hosting all your MP3s, pictures and maybe even videos. Then the worst happens, some guy breaks into your home.

He doesn’t recognise the slug and probably discards that as something too technical to bother with, but he does recognise the attached USB harddisk. He’s seen those in PC World he knows he can probably get some money for that.

Before you know it, your harddisk containing your MP3s, pictures and all that private data is being sold at a local pub.

What to do about it

Well you can add a measure of protection by using a encrypted file system. Only you can access the information on the disk via a password (or key).

How: The Objective

Use a loopback device on an uNSLUng v6 slug to mount a file (yes this doesn’t need to be an openslug). We will use XOR encryption which is fast, and easy to protect the filing system in the file. You will need to mount this filing system using the command line, but this only needs to be done when the slug is rebooted (with only two commands).

XOR encryption is weak, and can be easily broken by people looking to crack it. The method of encryption only protects against speculative attacks, that is people who will plug in your harddisk just to see what is there. You need to be technical and know something about cryptoanalysis to break it. For me this will guard against 99.999% of situations (most thieves aren’t really after your data, they want to make money from selling your stuff).

XOR encryption is fast, is easy to implement. Remember the slug is not a Pentium, we don’t have a lot of CPU cycles to play with. With a little work, other more secure encryption algorithms could be used (this is being done with openslug devices), but probably at a very noticeable performance hit.

Get all you need

You NSLU2 need to be running uNSLUng v6.x or OpenSLUG.

You need a command called losetup. I couldn’t find this in any packages for the uNSLUng release (it's not in busybox or unix coreutils pkg), but you can find it here on the Yahoo nslu2-linux website... http://groups.yahoo.com/group/nslu2-linux/message/8537 (credit goes to Helmut Dersch). This program (found in most distributions of linux) is used to setup loopback devices. You need it to setup the encryption options.

Log on as root and copy your downloaded losetup into /opt/sbin and loop.o into /lib/modules

(loop.tar.gz didn't work for me, i used ipkg --install kernel-module-loop and it works fine. HB)

You will need to...
insmod loop
... to install the loop module, that is to install the loopback feature into the kernel.

Creating a system

Create mount point for the new encrypted filing system mkdir /mnt/loopback

Create a file of random data. This will be the container of the encrypted filing system (change count to be the size of the filing system in MBytes, i.e. in this case am creating a 100MByte container)...
dd if=/dev/urandom of=/home/cryptfile bs=1M count=100

Warning! This can take some time to create as /dev/urandom is not that fast. You may wish to log in on another session to monitor its progress (it took 15/20mins for my 1Gbyte file to be made).

Setup the loop device (the –e 1 selects xor encryption)...
losetup -e 1 /dev/loop0 /home/cryptfile
...And enter your password (you are asked only once – make sure it is right).
Create your filing system (this shouldn’t take more than a minute or two as it doesn’t need to parse the whole container file)...
mkfs.ext3 /dev/loop0
(unnervingly I did experience one crash here, but after a reboot it was fine).
Mount the new (encrypted) filing system...
mount -t ext3 /dev/loop0 /mnt/loopback/
(if you are worried about spindown of harddisks, you may wish to pass the –noat (no access time) option as well)
Check everything is ok
ls /mnt/loopback/
Make links to it from your existing accounts / samba shares. cd to your accound or share and...
ln –s /mnt/loopback encrypted

All done.


To unmount the encrypted filing system...
umount /mnt/loopback/

(this seems to automatically disconnect the loopback device, i.e. you don’t need to do losetup –d /dev/loop0)

Upon next bootup (or to remount after unmounting)

insmod loop
losetup -e 1 /dev/loop0 /home/cryptfile
(enter your password)
mount -t ext3 /dev/loop0 /mnt/loopback/
If you got the password wrong you will get an error when trying to mount. You will need to then need to disconnect the loopback device by...
losetup -d /dev/loop0
...before repeating the losetup and mount commands.

A comment on Backing Up

Backing up is very strongly recommended for encrypted filing systems. Lots of things can go wrong. As operations are more complicated, there is a possibility of typos in commands, or maybe even crashes (seems reliable to me, but I've not tested it for long). Then of course the more likely possibility that you forget a password or do something daft to the container file.

You can backup your system as normal, however you are likely to have made the container files be very large (to allow lots of room for storage). As a result your backup jobs could become much longer (as when you update a file in the container, the whole container file has now changed and is then copied across). A better policy is not to backup your container files, but instead to backup the contents of the containers via the mounted point (i.e. backup /mnt/loopback as used above).

Of course you may wish to add encryption to what you are backing up and thankfully there are two loopback devices (so you can use two at once, /dev/loop0 and /dev/loop1).

Does it work?

Well here was my little test...

dd if=/dev/urandom of=/home/cryptfile bs=4096 count=1024
losetup -e 1 /dev/loop0 /home/cryptfile
mkfs.ext3 /dev/loop0
mount -t ext3 /dev/loop0 /mnt/loopback/
echo hello > /mnt/loopback/afile
umount /mnt/loopback/

dd if=/dev/zero of=/home/clearfile bs=4096 count=1024
losetup /dev/loop0 /home/clearfile			# note no –e option
mkfs.ext3 /dev/loop0
mount -t ext3 /dev/loop0 /mnt/loopback/
echo hello > /mnt/loopback/afile
umount /mnt/loopback/

grep -l hello /home/clearfile /home/cryptfile 
grep -l afile /home/clearfile /home/cryptfile 

(notice that you only see the data in the clearfile and not the cryptfile)


I’ve not done extensive tests, but my experience shows that read and write performance with XOR loopback is incurs a delay of 1 second for every 2Mbytes of data. I have a slug that has been modified to OverClockTheSlug (i.e. running at full speed).

My test to was to copy a 50Mbytes file full of random bytes (random is important as there appears to be some speed up with files with zeros in them). For the first set of tests, this is done via a terminal on the slug itself to eliminate network effects (I wanted to assess the impact of the XOR operation). The second set are over my 100Mbit network.

Control. Just copying between two directories both on a native file system...

[root@CC-NAS1] home> time cp test/file test/file2
real    0m12.072s
Test 1. Copying to and from the container via the loopback device without XOR encryption...
[root@CC-NAS1] home> time cp test/file /mnt/loopback/file2
real    0m13.679s

[root@CC-NAS1] home> time cp /mnt/loopback/file2 test/file
real    0m13.480s
Test 2. Copying to and from the (encrypted) container via the loopback device with XOR encryption...
[root@CC-NAS1] home> time cp test/file /mnt/loopback/file2
real    0m34.888s

[root@CC-NAS1] home> time cp /mnt/loopback/file2 test/file
real    0m36.775s

And here are the results over my 100Mbit network...

Control. Just reading and writing across the network (NSLU2 drive is on N:) to/from native filesystem.

James Covey-Crump@Custard /cygdrive/n
$ time cp c:/file n:/
real    1m25.097s

James Covey-Crump@Custard /cygdrive/n
$ time cp n:/file c:/
real    0m9.533s

Test 3. Reading and writing across network. Clearfile mounted on loopback (not encrypted)...

James Covey-Crump@Custard /cygdrive/n/Encrypted
$ time cp c:/file n:/Encrypted
real    1m27.015s
(extra 1.91s - 25Mbytes/s for loopback WRITING)

James Covey-Crump@Custard /cygdrive/n/Encrypted
$ time cp n:/Encrypted/file c:/
real    0m10.925s
(extra 1.42s - 35Mbytes/s for loopback READING)

Test 4. Reading and writing across network. Cryptfile mounted on loopback (XOR)...

James Covey-Crump@Custard /cygdrive/n/Encrypted
$ time cp c:/file n:/Encrypted
real    1m49.958s
(extra 24.86s - 2Mbytes/s for XOR and loopback WRITING)

James Covey-Crump@Custard /cygdrive/n/Encrypted
$ time cp n:/Encrypted/file c:/
real    0m34.855s
(extra 25.32s - 2Mbytes/s for XOR and loopback READING)

This suggests to me that using loopback has little affect on speed, but the NSLU can only XOR at 2Mbytes a second.

And AES also works:

Using Debian/Etch LE also AES128 via loopback works (with unslung you wont get it work unfortunately yet). Speed is roughly 1.1 MB/sec over a network. That is still quite workable, though it might get tight for video streaming in HQ.

Another way is using "cryptsetup"

With the cryptsetup package from Debian/Etch you can also easily set up an encrypted fileserver. And with the CryptoNAS (http://cryptonas.org) you have a nice webinterface for managing all the disks. But encryption is very slow (~700KB/s). Update: ARM packages are now available for CryptoNAS.

view · edit · print · history · Last edited by fcarolo.
Based on work by friscosystemausfallorg, me, Harald Biehl, fcarolo, mas, and JamesCC.
Originally by JamesCC.
Page last modified on August 12, 2008, at 02:03 PM