Encrypted Filesystem on NSLU2 with UnSlung

Background

The Problem

Attrition's Data Loss Archive and Database provides a fantastic resource for people interested in identity theft. It gives you an idea how careless organizations are with your personal data. Although a large number of the cases center around a stolen laptop(s), having a desktop machine or server does not make you safe. Unknown person(s) walked in a server room for Tricare, a military medical insurance provider and walked off with several hard drives containing all kinds of personal data: medical records, financial data, social security numbers, etc. The only way to protect these drives from this type of threat is to use an encrypted file system on the drives.

The Solution

The Linksys NSLU2, affectionately known as the "Slug", is a low cost network storage device. Through it a network user can access the contents of the two USB attached hard disks. However the true power of the Slug is its ability to run Linux. Through the use of Linux, the Slug can run a web server, MySQL, mt-daap and other assorted software. In fact, the different firmwares allow two different solutions for the data theft problem. The Unslung firmware solves the problem with an encrypted filesytem using XOR through a loopback device. This page covers that solution. The SlugOSBE firmware solves the problem with an encrypted filesystem using AES encryption through the dm-crypt software. Either solution allows you to provide file sharing services to your users while being assured if someone steals your drives, they will not be able to easily access files and their contents.

Important Notes

An XOR cipher is a not a particularly strong cipher in the case it will be employed in below. It is vulnerable to frequency analysis. Frequency analysis takes advantage of given a stretch of written language, certain letters and letter combinations occur with varying frequencies. When used against simple ciphers of which XOR is a part, frequency analysis works by matching the characters in a language to the characters in the ciphertext based on their frequency. If the letter X appears the most frequently in ciphertext, chances are it corresponds to the English letter "E", the most common letter in the English language. Therefore an XOR cipher will not protect your data against a powerful adversary who understands cryptography and frequency analysis. If this is your threat model, you will be better off using the SlugOSBE solution with AES encryption. It will protect your data against common criminals, so if this is your threat model; it is an acceptable solution.

Installing Needed Software

First you need to install the kernel module, loop.o. To do so, follow the instructions below.

# ipkg install kernel-module-loop

Next you need to install the losetup binary. Losetup allows you to associate loop devices with regular files and block devices.

# wget -c http://www.fh-furtwangen.de/~dersch/loop.tar.gz
# tar zxvf loop.tar.gz
# mv losetup /opt/sbin
# chmod 755 /opt/sbin/losetup
# rm -rf loop.o loop.tar.gz

Configuring an Encrypted Filesystem

First you need to setup a container for your encrypted filesystem. This file will store your encrypted data and will not be able to be resized after creation. Therefore please size accordingly. The below example uses /dev/urandom. Unlike /dev/random which generates random data based on "environmental noise", /dev/random can generate pseudo-random data. This makes it faster, but less secure than /dev/urandom. The below example will create a container, "/home/cryptfile", 100 MB in size and containing pseudo-random data. As a note, this operation will take some time, grab a cup of coffee or your beverage and relax.

# dd if=/dev/urandom of=/home/cryptfile bs=1M count=100

Next setup the loop device with the following command. The system will prompt you for a password. It is very important that this password is strong, to prevent others from brute forcing access to your encrypted filesystem and you do not forget it, as you will not be able to recover your data.

# losetup -e 1 /dev/loop0 /home/cryptfile

The "-e" determines the data encryption by the number immediately following it. In the above case, the 1 specifies XOR encryption. The losetup man page covers this option and additional ones.

Create the file system. The below example creates an ext3 filesystem.

# mkfs.ext3 /dev/loop0

Mount the new encrypted filesystem. In the below example, the mount point is "/mnt/loopback". Change the instructions to fit your mount point as appropriate.

# mkdir /mnt/loopback
# mount -t ext3 /dev/loop0 /mnt/loopback

You can now access the encrypted file system through "/mnt/loopback".

Mounting File System After Reboot

When you umount the encrypted file system, you are no longer able to access its contents. This means after reboot, you must run the following steps to be able to access the file system.

# insmod loop
# losetup -e 1 /dev/loop0 /home/cryptfile
Enter your password
# mount -t ext3 /dev/loop0 /mnt/loopback

You will not be able to automate this process in a boot script, as you will need to supply your container's password in order to access it.

Proving the Encryption Works

In order to prove the encrypted filesystem prevent access to files from casual intruders, run the test below.

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

# dd if=/dev/zero of=/home/clearfile bs=4096 count=1024
# losetup /dev/loop0 /home/clearfile
# 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
Should return /home/clearfile
# grep -l afile /home/clearfile /home/cryptfile
Should return /home/clearfile

The first set of commands creates an encrypted container, "/home/cryptfile", mounts it, writes the file "afile" to the container with the contents, hello and umounts the container while disconnecting the loopback device. The second set of commands creates an unencrypted container, "/home/clearfile", mounts it, writes the file "afile" to the container with the contents, hello and umounts the container. The last set of commands checks for the contents "hello" and "afile" in both containers. The last two commands should only return "/home/clearfile".