tutes-dump/site-tutorials/encfs_tutorial.html

<style type="text/css">
p {
  margin-right:10em;
}
pre {
  margin-left: 2em;
  margin-right: 30em;
  background-color: #ddd; padding: 10px;
  color: green;
}
</style>

<h2>Mounting an encrypted partition with EncFS</h2>
<hr>

<h3>Introduction</h3>
<p>
<a href="http://www.arg0.net/encfs">EncFS</a> is the simplest way to
manage an encrypted group of files and folders. It provides an
encrypted filesystem in user-space using
the <a href="http://fuse.sourceforge.net/">FUSE</a> library so it
doesn't need root access to work. This means that all users can manage
their encrypted partitions independently.
</p>

<h3>How it works</h3>
<p>
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. 
</p>

<p>
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.
</p>

<p>Read the <a href="#tips_and_tricks">Tips and Tricks</a> section for
a few of suggestions on how to ameliorate some of these problems.
</p>

<h3>Set-up</h3>
<p> The set up of the encrypted folder is very easy. First of all you
need to run
</p>
<pre>
$ man encfs
</pre>
<p> and read ahead. After that, we need to create both, the encrypted
folder and the mount point. We call <b>~/.crypt</b> the encrypted
folder (so it is hidden) and <b>~/crypt</b> the mountpoint.</p>
<pre>
$ mkdir ~/.crypt ~/crypt
</pre>
<p>Now we just need to run</p>
<pre>$ encfs ~/.crypt ~/crypt</pre>
<p>which mounts <b>~/.crypt</b> on <b>~/crypt</b>. Anything we write
to <b>~/crypt/</b> will be encrypted and saved
into <b>~/.crypt/</b>. When we unmount the filesystem,
the <b>~/crypt</b> folder is left empty and everything is only saved
encrypted in <b>~/.crypt</b>. 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.
</p>
<p>
The first time we run this command we will be asked for some
configuration details for the <b>~/.crypt</b> directory. The dialog
looks like this:
</p>
<pre>
$ 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.
?> 
</pre>
<p>Choosing the standard mode should be good enough for most cases but
if you would like extra security, choose <b>p</b> for the paranoia
mode (be aware that paranoia mode can make more difficult to make
backups of the data. See Section <a href="#tips_and_tricks">Tips and
Tricks</a> for further details). After this, we will be prompted to
enter a password twice, to confirm it and reduce the chances of a
typo.</p>

<p>
EncFS allows us to automatically unmount the filesystem if it is
idle for a certain period of time by giving the command line
option <b>--idle=X</b> where <b>X</b> is the number of minutes before
unmounting.  
</p>
<!-- 
It also provides the option to remount on-demand, that
is, it will remount the filesystem if we try to access it again and if
we provide the correct password. This can be achieved like this:
</p>
<pre>
$ encfs --idle=5 --ondemand --extpass=~/bin/ask-pass ~/.crypt ~/crypt
</pre>
<p>
will stop allowing access to the filesystem after being inactive for 5
minutes. Then, if you try to access the unmounted filesystem it will
prompt for your password using the program <b>~/bin/ask-pass</b> that
in my case is just
</p>
<pre>
#!/bin/bash
echo -n Password: >&2

stty -echo
read password
stty echo

echo "" >&2 #force new line
echo $password
</pre>
<p>Note that this will work only if you access the mountpoint directly from the command line, but will fail if a program tries to do it, since the password prompt will not be visible.
-->

<p>
To check that everything is working fine, we can run the <b>mount</b> command, which output should look like this:</p>
<pre>
$ mount
...
...
encfs on /path/to/crypt type fuse.encfs (rw,nosuid,nodev,default_permissions,user=your_username)
$
</pre>

<p> To unmount the filesystem leaving only the encrypted contents, we just
need to do</p>
<pre>
$ fusermount -u ~/crypt
</pre>
<p>Make sure to do this before logging out, otherwise the information
could be left unprotected.</p>

<h3><a name="tips_and_tricks">Tips and Tricks</a></h3>
<p>
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.
</p>

<h4>Backups</h4>
<p>
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 <b>~/.crypt/.encfs6.xml</b> in the backup. This file saves the
encryption configuration, and you will need it to decode the
information later on. See the tutorial on
<a href="http://sdf.org/?tutorials/rsync-backup">rsync</a> for more
information on how to make a backup.
</p>
<p>
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.
</p>

<h4>sshFS+EncFS</h4>
<p>
Using this method will allow you to write to a local <b>~/crypt</b>
directory which automatically, locally encrypts and securely transfers
the information to a remote folder <b>~/.crypt-remote</b>, so the
un-encrypted files are never accessible at the remote location and
there is no need to make explicit backups.
</p>
<p>
We achieve this by doing the following:
</p>
<ul>
<li>Create a <b>~/.crypt-remote/</b> directory on the remote machine
<pre>
local.machine:~$ ssh username@remote.machine mkdir .crypt-remote
</pre>
<li>Mount that directory using sshFS on your local machine
as <b>~/.crypt/</b> 
<pre>
local.machine:~$ sshfs -o idmap=user username@remote.machine:./.crypt-remote ~/.crypt 
</pre>
<p>The option <b>-o idmap=user</b> 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 <a href="http://sdf.org/?tutorials/sshfs">sshFS</a> if you need).
</p>
<li>Use EncFS locally to mount <b>~/.crypt</b> at <b>~/crypt</b>
<pre>
local.machine:~$ encfs ~/.crypt ~/crypt
</pre>
<li> To unmount you then need to do the following
<pre>
local.machine:~$ fusermount -u ~/crypt
local.machine:~$ fusermount -u ~/.crypt
</pre>
<li> You now can remount the <b>~/.crypt-remote</b> directory on your local machine, or in the remote one, as needed.
</ul>
<p>
<b>Beware that this can yield to irrecoverable data loss!</b> 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.
</p>

<cite>$Id: encfs_tutorial.html,v 1.2 2013/09/26 10:10:53 olvar Exp $</cite>