initial and only intended commit
This commit is contained in:
pifty
228
site-tutorials/encfs_tutorial.html
Normal file
228
site-tutorials/encfs_tutorial.html
Normal file
@@ -0,0 +1,228 @@
|
||||
<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>
|
||||
Reference in New Issue
Block a user