Using encFS on the B3

encFS is an encrypted filesystem available for many operating systems like Linux, Windows, and MacOS. Like eCryptfs, it does not use a single large image, i.e. file, to store the whole encrypted file system, but it maps the encrypted files to your normal file system. This has a lot of advantages, and some disadvantages, too: (partially taken from eCryptfs):

• You don't need to reserve space for encryption (like with creating a partition or a container file).
• You can access the encrypted files and backup them to an untrusted location. Plus, while you are backing them up, both versions - the original, and the copy - will stay in a defined, usable state, with the exception of the file being copied at the moment.
• If a part of the encrypted filesystem, or the media where it is store, gets corrupted, chances are that you loose only a file or two (provided that it is not the .encfs6.xml file that gets corrupted, but you will keep a good copy of this file in a safe place, won't you?). With an image-based filesystems, recovery may (and, generally, will) be much more difficult.

The disadvantage is:

• An attacker will learn how many files there are, and she will learn the length of your files, and how long their filenames are, approximately. I do not normally consider that a problem, but there may be use-cases where unveiling even this information may be harmful.

For more information on the advantages, and disadvantages, of file-based versus image-level encryption, see e.g. the eCryptfs FAQ or the EncFS Introduction.

encFS or eCryptfs...?

At this stage, you will probably ask: Shall I/you/he/she/it use encFS, or eCryptfs, or both? There is no simple answer to that question.

Generally, eCryptfs has a much better write performance than encFS (typically twice as fast, sometimes even up to three times as fast), while encFS has a slightly better read performance (see [1] - unfortunately in German, the numbers are universal. The first table shows write performance, the second table read performance.)

On the other hand, encFS completely resides in user-space, meaning that, in theory, it cannot, by any means, harm your kernel, your system, your hardware, your hamster, and so on. This results in a number of end-user advantages: encFS is, generally, easier to install and even to use.

I, personally, prefer encFS, but this is mostly due to the fact that I encountered it first (long before eCryptfs), and that it is being used by the great transparent DropBox[2] encryption software BoxCryptor [3] (I am in no way affiliated with them). So, using encFS, you can mount your BoxCryptor-encrypted folders.

Installing encFS

Login to your B3 shell using your user account, and use the su command to become root. (When not extremely perfectly with the Unix shell, please be extremely cautious while being root - even the smalles mistake may easily lead to disaster. I would recommend entering the commands by copy and paste.

christian@b3:~$ su -

Here, the "christian" part of the shell prompt is my user name. Should you happen to be called in a different way, you might see a slightly different prompt. If "su-ing" has worked, your prompt will have changed to:

root@b3:~#

The B3 ships with a default root password that you can get from the documentation (I think that it is excito at the moment). If you have not done already, you should use this opportunity to change your root password to something even harder to guess:

passwd root

Here you will have to enter the new password twice. You should record your new root password in a safe way, or in a safe place (I like Keepass/KeepassX, see http://keepass.info/ and http://www.keepassx.org/)

First, you will have to install the encFS package:

apt-get install encfs

Next, you will have to add your user account to the fuse user group (FUSE - Filesystem in Userspace - is the kernel extension required for user-space file systems, like encFS).

adduser christian fuse

Should you happen not to be called christian, you will have to modify this command. And if there is more than one user who wants to use encFS, add the other users to the fuse group in the same way. Note that if a user is logged in, changes in group membership will take effect only after the respective user logging off, and logging in, again.

In order to actually make fuse user-usable, you will have to ensure that /dev/fuse is readable by all members of the fuse group:

chmod g+rw /dev/fuse

Just to be sure, make a quick check that all is well by issuing the

 ls -l /dev/fuse

command. Its output should look like this:

crw-rw---- 1 root fuse 10, 229 Apr  4 02:54 /dev/fuse

Here the important thing is the second rw, and the string fuse. If your output varies, there may have been some problem with the installation.

Next, just to be sure that everything is working so far, enter the following command:

modprobe fuse

In this case, no news is meaning good news: The command will execute silently if your fuse installation is working. Should any error message be shown at this stage, encFS will not work.

Now, encFS is installed and ready to be used. One important thing at this stage: Stop being root, e.g. by entering the exit command:

root@b3:~# exit

Now, you will see something along the following lines:

logout
christian@b3:~$ 

If your prompt switches back to your normal user name, and if the "#" paves way for the "$" sign, all is okay.

Next, you will have to log out (e.g. by using the exit command for a second time, or by simply closing your terminal window). (This is necessary to have your membership of the fuse group come into effect.)

Just to be sure that group membership has been granted, enter the following command:

christian@b3:~$ groups

The output of this command should look like this:

users fuse

Your list may be longer than mine, but is has to contain the fuse group. If it does not, there has been an impossible problem. In this case, you might consider re-issuing the adduser christian fuse command, and logging out, and logging in, one more time.

Setting up encFS

When using encFS, you need two directories: one for storing your encrypted data, and one for showing the unencrypted content. I will call then encrypted and clear, respectively. You may name them as you wish, but I like the strings "encrypted", and "clear", in their sheer shortness, and simplicity, so I will stick to them for the rest of this turorial.

It is completely on you where you want to place these directories, but you should take into consideration two things:

• It is a good idea to have backups of the encrypted directory. No-one will be able to read the backup of your encrypted directory because it is kind of, well, encrypted.
• Normally, you will not include your unencrypted (clear) directory into your normal backups, at least not in your off-site backups.

Since the miscellaneous B3 backup routines (and many other backup tools) save miscellaneous, or all, directories from the /home tree, I would recommend storing your clear directory in a completely different place. Why not follow an old Unix convention and use the /mnt tree? I, personally, use /mnt/clear/ for my clear directory.

Since non-root users may not normally access /mnt, you will have to issue three more privileged commands. Since they are so few, I rcommend using the su -c variant of the su command:

su -c "mkdir /mnt/clear"
su -c "chown christian /mnt/clear"
su -c "chmod go=,u=rwx /mnt/clear"

Each time, you will be asked for your root password.

Just to be sure, enter the following command:

ls -ld /mnt/clear

Its output should look like this:

drwx------ 2 christian root 4096  4. Apr 15:04 /mnt/clear

Next, let's create your encrypted directory. This should be included in your regular backups (you have set up regular backups, haven't you?), so it might be a good idea to store it in your B3's private folder. Enter the following commands:

mkdir ~christian/private/encrypted
chmod go= ~christian /private/encrypted

Again, let's check if all is fine by entering the following command:

ls -ld ~christian/private/encrypted

Its output should look like this:

drwx------ 4 christian users 4096  4. Apr 15:17 /home/christian/private/encrypted

Now - at last! - you may actually set up encFS. Enter the following command (and be prepared for a lengthy dialog):

encfs ~/private/encrypted /mnt/clear

For the beginning, I would recommend using encFS's "paranoia" mode which uses sane, and safe, defaults for most settings. Answer the first question of encfs with P, and press enter. encFS will require only one further input: that of a password. Choose wisely, and remember this password carefully - without this password, there is no way to decrypt your data again (at least the makers, and the users, of encFS hope so). Here, I strongly recommend using a long password (20 characters? 30? better even more - there is a strength in number!), and, of course, it should not mean anything. It would be best to randomly generate it (e.g. using Keepass or, even better, because more portable: KeepassX - in this case, there is also no problem with an even longer password).

Using encFS

If you have set up encFS like shown in this tutorial, you have now two directories: /mnt/clear and ~/private/encrypted. All files you copy to /mnt/clear will get encrypted and will show up in ~/private/encrypted. Do not manually touch ~/private/encrypted! (You won't normally break something by creating files in your encrypted directory, but they simply do not belong there. And by deleting a file from encrypted, you will not damage your encrypted filesystem - but, of course, you will lose the single file you have deleted.)

One more important thing: Your clear directory will show your unencrypted files until it gets unmounted:

1. You may, at any time, unmount the directory manually using the umount command (note the missing "n" in the name of the command). Unfortunately, in our setup, this requires root privileges, so you have to enter the following command: su -c "umount /mnt/clear" Here you have to provide your root password again.
2. When you shut down your B3 (more precisely: when your B3 restarts - this may totally happen without user interaction, e.g. after a power failure), the clear directory gets unmounted, too. This is a good thing because if someone wants to steal your B3, he and/or she will normally interrupt the power, thereby unmounting the clear directory and losing any access to your protected data.

If, at any time in the future, you want to access your encrypted data again, you will have to re-mount it again. This is done by re-issuing the simple encfs command:

encfs ~/private/encrypted /mnt/clear

At this stage, remembering your encryption password will make you a much happier person.

Maintenance, Backup, Further Considerations

There is no actual maintenance needed, but you should always backup your encrypted directory. Though damage to, or loss of, one ore more single files will by no means harm all the other files, there is one notable exception: the file .encfs6.xml in your encrypted directory.This file is as important as your encryption password! If you loose, or damage, either this file, or your password, you will not be able to retrieve your valuable data. So be sure that your backups do include this file, and even if you don't do any backups - at least keep a copy of .encfs6.xml in a safe place.

One more thing: Before copying a file to your cleardirectory, make sure that it is actually mounted! If it is not, your files will not get encrypted, and they will never show up in your encrypted directory. And they will not get backed up either, because /mnt is normally excluded from any decent backup.

The easiest way to make sure that the clear directory is mounted is looking at its contents: If it is empty, either someone has deleted all your files, or the directory got unmounted (e.g. due to an interruption of power).

A more professional way would be to issue the mount command. This command shows all mounted directories. If it contains an entry like this…

encfs on /mnt/clear type fuse.encfs (rw,nosuid,nodev,default_permissions,user=christian)

...then you can be sure that your clear directory is up and working.