~ecryptfs/ecryptfs/trunk : contents of doc/ecryptfs-faq.html at revision 17

~ecryptfs/ecryptfs/trunk : (revision 17)
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>
eCryptfs
</title>
</head>
<body>

<h1>eCryptfs</h1>
<h3>FAQ</h3>

<hr>

<a href="http://ecryptfs.sourceforge.net">Main Page</a>

<hr>

<table width="640">
<tr>
<td>

<p>

<h3>Index</h3>

<ul>

<li><a href="#novelty">What is novel about eCryptfs?</a></li>

<li><a href="#versions">What versions of the kernel have eCryptfs
support?</a></li>

<li><a href="#access_lower">Can I access the lower files while
eCryptfs is mounted?</a></li>

<li><a href="#options">What kernel options do I need to enable to
build eCryptfs?</a></li>

<li><a href="#compatibility">On what filesystems can I expect eCryptfs
to function?</a></li>

<li><a href="#stack">Why is the kernel stack such an issue with
eCryptfs?</a></li>

<li><a href="#pubkey">Can I mount eCryptfs with a public key?</a></li>

<li><a href="#pubkey-about">Why would I want to use public key
anyway?</a></li>

<li><a href="#ecryptfsd">What is <code>ecryptfsd</code>?</a></li>

<li><a href="#ecryptfs-manager">What is
<code>ecryptfs-manager</code>?</a></li>

<li><a href="#nonroot">Do I have to be root to mount
eCryptfs?</a></li>

<li><a href="#features">How can I find out which features are in my
eCryptfs kernel module?</a></li>

<li><a href="#xattr">How do I store the metadata in the extended
attribute region of the lower file?</a></li>

<li><a href="#encryptedview">I am using the <code>-o xattr</code>
option, but my backup tools do not preserve extended attributes. How
can I back up the lower files?</a></li>

<li><a href="#filename-enc">What about filename encryption?</a></li>

<li><a href="#sparse">What about sparse files?</a></li>

<li><a href="#passphrase">How should I select my passphrase?</a></li>

<li><a href="#protectkey">How can I protect my key?</a></li>

<li><a href="#lostkey">I forgot my password/lost my key! What can I do
to recover my data?</a></li>

<li><a href="#compare">How does eCryptfs compare with other Linux disk
encryption solutions?</a></li>

<li><a href="#baddir">&quot;<code>Error mounting eCryptfs; rc = [-2];
strerr = [No such file or directory]</code>&quot;</a></li>

<li><a href="#einval">&quot;<code>Error mounting eCryptfs; rc = [-22];
strerr = [Invalid argument]</code>&quot;</a></li>

<li><a href="#keyproblem">&quot;<code>ecryptfs_parse_options: Could
not find key with description: [deadbeaf...]&quot;</code></a></li>

<li><a href="#nothere">My question isn't answered here.</a></li>

</ul>
</p>

</p>

<a name="novelty">

<p><h3>Q. What is novel about eCryptfs?</h3></p>

<p>
Well, nothing, to be honest. All of the techniques used in eCryptfs
are directly based on cryptographic technology that was widely known
and in practical use in the 1970's.
</p>

<p>
Security problems often arise when software tries to ``invent its own
crypto'' by deviating from what has been in common practical use for a
lengthy period of time. eCryptfs sticks to tried-and-true encryption
technology.
</p>

<p>
In terms of per-file key management, eCryptfs simply uses the methods
of PGP (created by Philip Zimmermann in 1991 and formally specified as
a public standard in RFC2440 in 1998) and takes the obvious and
conceptually trivial step of applying those methods within a
filesystem service in the kernel. eCryptfs employs the well-weathered
encryption techniques that have been in common use in the community
for over two decades. Other cryptographic filesystems published and
widely used in the 1990's use the same basic approach to encrypting
files. eCryptfs just happens to be the first such filesystem to make
it upstream in the Linux kernel.
</p>

<a name="versions">

<p><h3>Q. What versions of the kernel have eCryptfs support?</h3></p>

<p>
Linux kernel versions 2.6.19 and later have eCryptfs support. We
provide experimental backports, but only the official mainline kernel
is supported and is in active development.
</p>

<a name="access_lower">

<p><h3>Q. Can I access the lower files while eCryptfs is mounted?</h3></p>

<p>
Accessing the lower files during an active eCryptfs mount is somewhat
like accessing a block device on which ext3 is mounted. The kernel
allows it, and it may work (depending on what you do with the data),
but it is not a good idea.
</p>

<a name="options">

<p><h3>Q. What kernel options do I need to enable to build
eCryptfs?</h3></p>

<p>
<code>
Code maturity level options  ---><br>
&nbsp;&nbsp;[*] Prompt for development and/or incomplete code/drivers<br>
<br>
Security options  ---><br>
&nbsp;&nbsp;&lt;M&gt; Enable access key retention support<br>
<br>
Cryptographic options  ---><br>
&nbsp;&nbsp;&lt;M&gt;   MD5 digest algorithm<br>
&nbsp;&nbsp;&lt;M&gt;   AES cipher algorithms<br>
<br>
File systems  ---><br>
&nbsp;&nbsp;Miscellaneous filesystems  ---><br>
&nbsp;&nbsp;&nbsp;&nbsp;&lt;M&gt; eCrypt filesystem layer support (EXPERIMENTAL)<br>
<br>
Recommended .config options (some options not available in older kernels):<br>
CONFIG_EXPERIMENTAL=y<br>
CONFIG_KEYS=y<br>
CONFIG_CRYPTO=y<br>
CONFIG_CRYPTO_ALGAPI=y<br>
CONFIG_CRYPTO_BLKCIPHER=y<br>
CONFIG_CRYPTO_HASH=y<br>
CONFIG_CRYPTO_MANAGER=y<br>
CONFIG_CRYPTO_MD5=y<br>
CONFIG_CRYPTO_ECB=y<br>
CONFIG_CRYPTO_CBC=y<br>
CONFIG_CRYPTO_AES=y<br>
CONFIG_ECRYPT_FS=m
</code>
</p>

<p>
Newer versions of the Linux kernel now have a ``Layered filesystems''
submenu under the ``File systems'' menu, where eCryptfs and Unionfs
reside.
</p>

<p>
Make certain that you have loaded all of the crypto modules that you
need to run eCryptfs. This includes <code>ecb</code>,
<code>cbc</code>, <code>md5</code>, and at least one popular symmetric
cipher, like <code>aes</code>.
</p>

<a name="compatibility">

<p><h3>Q. On what filesystems can I expect eCryptfs to function?</h3></p>

<p>
eCryptfs has been well tested on ext3 and jfs. eCryptfs on xfs may be
problematic because xfs can take up most of the available space for
the call stack. eCryptfs currently has some degree of functionality on
CIFS, and the eCryptfs development team is working with a member of
the CIFS development team to get the kinks worked out. eCryptfs is
broken on NFS for all kernels. Unionfs is also affected, and the
Unionfs team is making good progress at getting the issues with
stacking on NFS resolved.
</p>

<a name="stack">

<p><h3>Q. Why is the kernel stack such an issue with eCryptfs?</h3></p>

<p>
eCryptfs is a stacked filesystem. This implies that eCryptfs adds on
top of whatever call stack exists with current filesystems. Each
process in the Linux kernel has a fixed maximum stack size (4k+4k or
8k). Some filesystems (such as xfs) push the limit of the stack by
themselves; adding eCryptfs on top may cause a stack overflow on these
filesystems. If you wish to use eCryptfs on XFS, I recommend that you
first perform stress tests to help determine whether your specific
configuration will lead to a kernel process stack overflow.
</p>

<a name="pubkey">

<p><h3>Q. Can I mount eCryptfs with a public key?</h3></p>

<p>
You can mount eCryptfs with a public key if you have public key
support (<code>pubkey</code>) in your kernel. You first need to
generate a public/private keypair. Run <code>ecryptfs-manager</code>,
follow the prompts to generate the keypair for the key module of your
choosing, start the <code>ecryptfsd</code> daemon, and then specify
the key module when mounting. For instance, for the OpenSSL key
module, assuming you created your key in
<code>/usb-drive/mykey.pem</code> and you want to do a layover mount
on <code>/secret</code>, run:
</p>

<p>
<code>
# ecryptfsd<br>
# mount -t ecryptfs -o key=openssl:keyfile=/usb-drive/mykey.pem /secret /secret
</code>
</p>

<a name="pubkey-about">

<p><h3>Q. Why would I want to use public key anyway?</h3></p>

<p>
Cryptographic keys derived from passphrases are generally
worthless. Most passphrases that people can reasonably remember lack
even the strength of a 64-bit symmetric key. The idea behind using a
public key is to provide an opportunity for two-factor authentication;
for instance, with OpenSSL RSA, the PEM file is ``something you have''
and the passphrase is ``something you know.'' This works best if you
store your public key and your encrypted files on separate media.
</p>

<p>
The ``public key'' mode of operation in eCryptfs is actually more
general than public key. It allows for arbitrary key modules to
perform the File Encryption Key (FEK) encryption and decryption. The
key module could do RSA. Or, it could retrieve an employee's key from
a Domino server. Or, it could unseal the key protected by a Trusted
Computing chip, which will only honor the unseal request if the
machine is booted into a trusted state. This TPM-based protection is
actually on the work queue for this year.
</p>

<a name="ecryptfsd">

<p><h3>Q. What is <code>ecryptfsd</code>?</h3></p>

<p>
<code>ecryptfsd</code> is a daemon that runs as the user performing
file operations under the eCryptfs mount point. It manages public key
operations in userspace on file open events. <code>ecryptfsd</code>
only needs to be run when a mount is done with a public key module.
</p>

<a name="ecryptfs-manager">

<p><h3>Q. What is <code>ecryptfs-manager</code>?</h3></p>

<p>
<code>ecryptfs-manager</code> is an application that manages eCryptfs
objects such as keys. You can use <code>ecryptfs-manager</code> to ask
key modules to generate new keys for you, for instance.
</p>

<a name="nonroot">

<p><h3>Q. Do I have to be root to mount eCryptfs?</h3></p>

<p>
eCryptfs mounts can be set up to be done by non-root users. Generally,
you want to perform the initial key generation and mount as the root
user. Then, you can do a mount as a user by putting the appropriate
options in /etc/fstab, adding the keys to the user session keyring
(using ecryptfs-manager), and performing the mount in such a way that
bypasses the mount helper. This is not very well automated in the
current release, but it is possible right now with some manual
steps. The instructions on using the PAM module are contained in the
README and give the steps necessary to set that up; just follow all
the directions except the last PAM step to see how it works:
</p>

<p>
<a
href="http://ecryptfs.sourceforge.net/README">http://ecryptfs.sourceforge.net/README</a>
</p>

In short, you will want something like this in your fstab:

<p>
<code>
/home/user/secret /home/user/secret ecryptfs
rw,ecryptfs_sig=deadbeefbaadf00d,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,user,noauto 0 0
</code>
</p>

<p>
You need to get the corresponding authentication token for the
ecryptfs_sig into your user session keyring;
<code>ecryptfs-manager</code> and the PAM module can both do this for
you. Alternatively, you can write your own application that calls
<code>ecryptfs_add_passphrase_key_to_keyring()</code> or
<code>ecryptfs_add_key_module_key_to_keyring()</code> in
<code>libecryptfs.so</code>. Then you will want to mount with the -i
option to prevent the mount helper from being called.
</p>

<a name="features">

<p><h3>Q. How can I find out which features are in my eCryptfs kernel
module?</h3></p>

<p>
View the contents of <code>fs/ecryptfs/version_str</code> under your
<code>sysfs</code> mount point (typically <code>/sys</code>). For
instance:</p>

<p>
<code>
# cat /sys/fs/ecryptfs/version_str<br>
passphrase<br>
pubkey<br>
plaintext passthrough<br>
metadata in extended attribute<br>
</code>
</p>

<p>
In this particular example, the kernel has passphrase support, public
key support, plaintext passthrough support, and support for storing
cryptographic metadata in the extended attribute regions of the lower
files.
</p>

<a name="xattr">

<p><h3>Q. How do I store the metadata in the extended attribute region
of the lower file?</h3></p>

<p>
If your kernel has support for it, mount with the <code>-o
xattr</code> option. Be sure to preserve the extended attributes in
the lower files, or you will lose your data. Bear in mind that many
userspace utilities such as <code>tar</code> lack extended attribute
support, and so you need to use utilities like <code>star</code> with
the proper options instead.
</p>

<a name="encryptedview">

<p><h3>Q. I am using the <code>-o xattr</code> option, but my backup
tools do not preserve extended attributes. How can I back up the lower
files?</h3></p>

<p>
Mount with the <code>-o encrypted_view</code> flag and read the files
from under the eCryptfs mount point. The files read will be encrypted,
and the cryptographic metadata will be in the headers of the encrypted
files that are passed through, even if this metadata is actually
stored in the extended attribute regions of the lower files.
</p>

<a name="filename-enc">

<p><h3>Q. What about filename encryption?</h3></p>

<p>
The namespace problem arises when we consider the case where two files
have the same unencrypted name. This can be a problem when the user
does not have the key for every file in any given directory. Imagine,
for instance, that Alice creates a file named ``meeting_notes.txt'' in
a shared directory on an NFS server. The filename is encrypted with a
key known only to Alice and Carol. Bob then creates a file in the same
shared NFS directory and also names it ``meeting_notes.txt'',
encrypting the filename with another key only known to Bob and
Carol. Bob's eCryptfs client cannot detect the unencrypted filename
conflict in the namespace because Bob does not have Alice's key.
</p>

<p>
So two different files that have the same unencrypted name and
different encrypted names appear in the same directory. When Carol,
who has both Alice's key and Bob's key, lists the contents of the
directory, he winds up seeing two different files with the same
filename in the same directory, which is a POSIX violation.
</p>

<p>
The solution we may implement is to use a separate key just for
filename encryption, requiring all filenames encrypted under any given
directory to be encrypted with that key. Filename encryption is a
planned feature, but there is currently no set date for when it will
be completed.
</p>

<a name="sparse">

<p><h3>Q. What about sparse files?</h3></p>

<p>
eCryptfs does not currently support sparse files. Sequences of
encrypted extents with all 0's could be interpreted as sparse regions
in eCryptfs without too much implementation complexity. However, this
would open up a possible attack vector, since the fact that certain
segments of data are all 0's could betray strategic information that
the user does not necessarily want to reveal to an attacker. For
instance, if the attacker knows that a certain database file with
patient medical data keeps information about viral infections in one
region of the file and information about diabetes in another section
of the file, then the very fact that the segment for viral infection
data is populated with data at all would reveal that the patient has a
viral infection.
</p>

<a name="passphrase">

<p><h3>Q. How should I select my passphrase?</h3></p>

<p>
There are plenty of good guides out there to help you choose a strong
passphrase. Here is one, for instance: <a
href="http://www.iusmentis.com/security/passphrasefaq/">http://www.iusmentis.com/security/passphrasefaq/</a>.
</p>

<a name="protectkey">

<p><h3>Q. How can I protect my key?</h3></p>

<p>
Make a copy and store it in a physically secure location. For
instance, copy your public/private keypair to a USB flash drive or
write your passphrase onto a sheet of paper. Then, lock the drive and
paper in your desk drawer or put them in a safe deposit box (depending
on the sensitivity of the data that the keys protect). Future versions
of eCryptfs userspace utilities may implement key splitting functions
to provide even more paranoid levels of key protection.
</p>

<p>
Do not store your keys under the same physical security context in
which you are storing your media. It should be much harder for an
attacker to get to your keys than it is for him to get to your media.
</p>

<p>
When you use public key mode and generate a new key using
<code>ecryptfs-manager</code>, the generated key file is the one that
you must back up in order to access your files.
</p>

<p>
When mounting with a new key, I recommend performing a full mount,
creating a new file, unmounting, clearing the user session keyring
(<code>keyctl clear @u</code>), mounting again, and then trying to
access the newly created file. This minimizes the likelihood that you
will mistype a passphrase and create files that you will not be able
to later recover. When mounting in passphrase mode, make sure that the
ecryptfs_sig value matches between mounts. Future versions of eCryptfs
will store a cache of previous ecryptfs_sig values and warn the user
if a mount passphrase does not match any passphrases used for previous
mounts.
</p>

<a name="lostkey">

<p><h3>Q. I forgot my password/lost my key! What can I do to recover
my data?</h3></p>

<p>
Nothing; you're screwed. (<a
href="http://www.cskk.ezoshosting.com/cs/goodstuff/bs-spc.html">Apologies</a>
to Bruce Schneier).
</p>

<p>
If you have forgotten your passphrase, your only hope is that you
chose a weak passphrase in the first place. There is an outside chance
that you might be able to perform a successful dictionary attack to
recover your passphrase. If you manage to recover your passphrase that
way, then you may as well have not been bothering to encrypt your data
in the first place, since a malicious attacker could have done the
exact same thing to recover your passphrase.
</p>

<p>
If you selected a strong passphrase or lost your key file, you are
screwed no matter what. Nobody can help you recover your data.
</p>

<a name="compare">

<p><h3>Q. How does eCryptfs compare with other Linux disk encryption
solutions?</h3></p>

<p>
eCryptfs is an actual filesystem. Some other popular disk encryption
technologies are not filesystems; they are block device encryption
layers (they provide what appears to be a physical block device to
some actual filesystem). There is no filesystem logic in these
layers. A few of the more well-known block device encryption layers
include dm-crypt, Truecrypt, and Loop-AES. Perhaps the best thing
about block device-layer encryption is that it is an order of
magnitude simpler to implement than filesystem-layer
encryption. Another advantage of block device-layer encryption is that
it will encrypt the entire filesystem, including all of the filesystem
metadata. However, for many use cases, this can turn out to be more of
a disadvantage than an advantage.
</p>

<p>
While eCryptfs uses a powerful and flexible approach to protecting
filesystem content, block device-layer encryption technology is still
required to protect swap space and certain databases that use their
own block device partition. The table below provides a
compare-and-constrast of the two technologies. I anticipate that block
device encryption will be the best solution for some people, while
stacked filesystem encryption will be the best solution for
others. Sometimes it even makes sense to use them both together, to
combine the comprehensive full-disk encryption of a block device layer
encryption technology with the transparent per-file encryption
provided by eCryptfs (this will result in double-encryption of the
file contents).
</p>

<br>

<table border=1 cellspacing=5 cellpadding=4>

<tr>
 <td width="50%"><center><b>Block Device Encryption</b></center></td>
 <td width="50%"><center><b>Stacked Filesystem Encryption</b></center></td>
</tr>

<tr>
 <td>Simple in concept and implementation; just transform blocks as
 they pass through.</td>
 <td>High level of design complexity; meticulous handling of internal
 filesystem primitives required.</td>
</tr>

<tr>
 <td>Must allocate a block device to dedicate for the entire
 filesystem.</td>
 <td>Stacks on top of existing mounted filesystems; requires no special
 on-disk storage allocation effort.</td>
</tr>

<tr>
 <td>Everything in the filesystem incurs the cost of encryption and
 decryption, regardless of the confidentiality requirements for the
 data.</td>
 <td>Selective encryption of the contents of only the sensitive
 files.</td>
</tr>

<tr>
 <td>Fully protects the confidentiality of the directory structures,
 superblocks, file sizes, file permissions, and so forth.</td>
 <td>Cannot keep all filesystem metadata confidential. Since stacked
 filesystems encrypt on a per-file basis, attackers will know the
 approximate file sizes, for instance.</td>
</tr>

<tr>
 <td>Coarse granularity; only fixed per-mountpoint encryption policies
 are possible.</td>
 <td>Fine granularity; flexible per-file encryption policies are
 possible.</td>
</tr>

<tr>
 <td>No notion of ``encrypted files.'' Individual files must be
 re-encrypted via a userspace application before written to backups,
 sent via email, etc.</td>
 <td>Individual encrypted files can be accessed transparently by
 applications; no additional work needed on the part of applications
 before moving the files to another location.</td>
</tr>

<tr>
 <td>Clients cannot use directly on networked filesystems; encryption
 must be set up and managed on the server, or the client must encase
 all of his files in a loopback mount, losing the per-file granularity
 from the perspective of other clients.</td>
 <td>Clients can stack on locally mounted networked filesystems;
 individual files are sent to the server and stored in encrypted
 form.</td> </tr>
<tr>
 <td>Can protect databases that use their own dedicated block device.</td>
 <td>Can only protect databases that write their tables to regular
 files in an existing filesystem.</td>
</tr>

<tr>
 <td>Used to protect swap space.</td>
 <td>Not designed to protect swap space; we recommend using block
 device encryption to protect swap space while using eCryptfs on the
 filesystem.</td>
</tr>

<tr>
 <td>Possible to hide the fact that the partition is encrypted.</td>
 <td>The fact that encrypted data exists on the device is obvious to an
 observer.</td>
</tr>

<tr>
 <td>Filesystem-agnostic; any filesystem will work on an encrypted
 block device.</td>
 <td>Can only be expected to work with existing filesystems that are
 upstream in the official Linux kernel.</td>
</tr>

</table>

<p>
EncFS is another popular cryptographic filesystem that behaves much
like a stacked filesystem. EncFS is a userspace filesystem, and so
individual page reads and writes require additional context switches
between kernel and userspace. One advantage a userspace cryptographic
filesystem is that it is possible to use symmetric ciphers implemented
in userspace libraries, but the frequent context switching impacts
performance. In addition, EncFS uses FUSE, which suffers from the fact
that shared writable memory mappings must be entirely disabled in
order to avoid deadlock on some page swap events.
</p>

<a name="baddir">

<p><h3>Q. &quot;<code>Error mounting eCryptfs; rc = [-2]; strerr = [No
such file or directory]</code>&quot;</h3></p>

<p>
Make sure that both the source and destination directories that you
provide to the mount command exist.
</p>

<a name="einval">

<p><h3>Q. &quot;<code>Error mounting eCryptfs; rc = [-22]; strerr =
[Invalid argument]</code>&quot;</a></h3></p>

<p>
Check your system log for the real problem.
</p>

<a name="keyproblem">

<p><h3>Q. &quot;<code>ecryptfs_parse_options: Could not find key with
description: [deadbeaf...]&quot;</code></h3></p>

<p>
If the mount fails and the message &quot;<code>ecryptfs_parse_options:
Could not find key with description: [deadbeaf...]&quot;</code> is in
your system logs, then there was a problem inserting your mount key
into your kernel <i>user session</i> keyring.
</p>

<p>
After a mount attempt, run <code>keyctl_show</code>. You should see
something like this:
</p>

<pre>
# keyctl show
Session Keyring
       -3 lswrv----------     0     0  keyring: _uid_ses.0
        2 lswrv----------     0     0   \_ keyring: _uid.0
892244932 lswrv----------     0     0       \_ user: deadbeef...
</pre>

<p>
Where <code>deadbeef</code> is the signature that corresponds with
your key. If you don't see this, then there is a problem with your
keyring setup.
</p>

<p>
If you su to root, be sure to initiate the session by using the -
flag.
</p>

<p>
Finally, try linking your user keyring into your active session
keyring:
</p>

<pre>
# keyctl link @u @s
</pre>

<a name="nothere">

<p><h3>Q. My question isn't answered here.</h3></p>

<p>
Send a message to the <a
href="http://lists.sourceforge.net/lists/listinfo/ecryptfs-users">ecryptfs-users</a>
mailing list.
</p>

<!--
<p><h3>Q. </h3></p>

<p>

</p>
-->

</td>
</tr>
</table>

<br><br><br><br><br><br><br><br><br><br><br><br><br><br>
<br><br><br><br><br><br><br><br><br><br><br><br><br><br>
<br><br><br><br><br><br><br><br><br><br><br><br><br><br>
<br><br><br><br><br><br><br><br><br><br><br><br><br><br>

</body>
</html>