Mounting an encrypted partition with EncFS

Introduction

EncFS is the simplest way to manage an encrypted group of files and folders. It provides an encrypted filesystem in user-space using the FUSE library so it doesn't need root access to work. This means that all users can manage their encrypted partitions independently.

How it works

The idea behind EncFS is to create a directory where the encrypted information is saved. This directory is then mounted (using FUSE) in a user-defined mountpoint, where the contents of the encrypted directory are accessible as decrypted data. The translation between these two parts is the work of EncFS.

This is designed to protect against off-line attacks, that is, the contents of the encrypted folder are safe(er) while the directory is unmounted. While it is mounted, anyone with enough permissions over the mountpoint can still access the information of the files. Furthermore, since the encryption works on a file-by-file basis, some metadata will remain visible even while unmounted. Things like the number of files, their permissions, sizes and approximate filename size will be accessible to anyone with appropriate permissions over the encrypted folder.

Read the Tips and Tricks section for a few of suggestions on how to ameliorate some of these problems.

Set-up

The set up of the encrypted folder is very easy. First of all you need to run

$ man encfs

and read ahead. After that, we need to create both, the encrypted folder and the mount point. We call ~/.crypt the encrypted folder (so it is hidden) and ~/crypt the mountpoint.

$ mkdir ~/.crypt ~/crypt

Now we just need to run

$ encfs ~/.crypt ~/crypt

which mounts ~/.crypt on ~/crypt. Anything we write to ~/crypt/ will be encrypted and saved into ~/.crypt/. When we unmount the filesystem, the ~/crypt folder is left empty and everything is only saved encrypted in ~/.crypt. When we need to re-gain access to our files, we can run the last command line to remount the encrypted directory, showing its decoded contents at the mount point.

The first time we run this command we will be asked for some configuration details for the ~/.crypt directory. The dialog looks like this:

$ encfs ~/.crypt ~/crypt
Creating new encrypted volume.
Please choose from one of the following options:
 enter "x" for expert configuration mode,
 enter "p" for pre-configured paranoia mode,
 anything else, or an empty line will select standard mode.
?> 

Choosing the standard mode should be good enough for most cases but if you would like extra security, choose p for the paranoia mode (be aware that paranoia mode can make more difficult to make backups of the data. See Section Tips and Tricks for further details). After this, we will be prompted to enter a password twice, to confirm it and reduce the chances of a typo.

EncFS allows us to automatically unmount the filesystem if it is idle for a certain period of time by giving the command line option --idle=X where X is the number of minutes before unmounting.

To check that everything is working fine, we can run the mount command, which output should look like this:

$ mount
...
...
encfs on /path/to/crypt type fuse.encfs (rw,nosuid,nodev,default_permissions,user=your_username)
$

To unmount the filesystem leaving only the encrypted contents, we just need to do

$ fusermount -u ~/crypt

Make sure to do this before logging out, otherwise the information could be left unprotected.

Tips and Tricks

As mentioned before, this method is intended for protection against off-line attacks. If you would like to avoid ever having the information on the clear on the remote server, and if you have access to EncFS at your local machine, you have at least two possibilities; one is to keep a local encrypted folder and make backups of that encrypted data to your sdf account, or you can use sshFS in conjunction with EncFS to write your encrypted data directly.

Backups

Since the encryption is done file-by-file, we can easily make backups of the encrypted data without the need to mount the filesystem, so for instance, we can leave the backup to a cron job without compromising the safety of the files. Make sure to include the file ~/.crypt/.encfs6.xml in the backup. This file saves the encryption configuration, and you will need it to decode the information later on. See the tutorial on rsync for more information on how to make a backup.

The paranoia mode has a feature named "External IV Chaining", which ties the filename (possibly including the absolute path) with the data for its encryption, so a file that has been moved or renamed will fail to decode properly. Make sure that, if you are doing backups of encrypted files, you will either have this option disabled or have a way to restore the whole path and filenames of the encrypted data.

sshFS+EncFS

Using this method will allow you to write to a local ~/crypt directory which automatically, locally encrypts and securely transfers the information to a remote folder ~/.crypt-remote, so the un-encrypted files are never accessible at the remote location and there is no need to make explicit backups.

We achieve this by doing the following:

• Create a ~/.crypt-remote/ directory on the remote machine

  local.machine:~$ ssh username@remote.machine mkdir .crypt-remote
  

• Mount that directory using sshFS on your local machine as ~/.crypt/

  local.machine:~$ sshfs -o idmap=user username@remote.machine:./.crypt-remote ~/.crypt 
  

  The option -o idmap=user will map your local user name to the user name on the remote machine, that is, files on the remote system that are from the user username, appear to be from the user that you are logged in as on the local system (see the tutorial on sshFS if you need).

• Use EncFS locally to mount ~/.crypt at ~/crypt

  local.machine:~$ encfs ~/.crypt ~/crypt
  

• To unmount you then need to do the following

  local.machine:~$ fusermount -u ~/crypt
  local.machine:~$ fusermount -u ~/.crypt
  

• You now can remount the ~/.crypt-remote directory on your local machine, or in the remote one, as needed.

Beware that this can yield to irrecoverable data loss! If there are connectivity problems, the partially transmitted files will not contain usable information, so you shouldn't use this method with files for which you do not have an extra copy. You will need to gauge carefully which solution offers the best relation between confidentiality and data integrity, and which works better for your particular needs.