Q. What is novel about eCryptfs?
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.
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.
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.
Q. What versions of the kernel have eCryptfs support?
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.
Q. Will eCryptfs by itself protect all my data?
eCryptfs is just one component in a comprehensive set of mechanisms to protect the confidentiality of your data. Simply mounting eCryptfs over a directory in your home directory will probably not provide sufficient coverage for everything your applications will write to disk. For instance, applications that produce and store thumbnails of your images may write the thumbnails to an unprotected location.
Sensitive application data will typically wind up in the following locations, although some applications will write data to other locations not listed here:
The /tmp directory and the swap device can be easily protected with dm-crypt using a key randomly generated when the system is booted, since the information in those locations does not need to persist between reboots. eCryptfs must mount the /var directory prior to any daemons or other system applications reading from or writing to that location (including the syslog utility). eCryptfs must also mount over the user's home directory prior to the user logging into the system.
You will need to consider other applications that diverge from traditional paths for storing data on a case-by-case basis. Analyzing application behavior with the kernel auditing system is one way to profile the behavior of an application, and explicit SE Linux rules that only allow applications to write to encrypted mountpoints helps prevent inadvertent information leakage. We recommend always using eCryptfs together with appropriate Mandatory Access Control (MAC) mechanisms to ensure that your sensitive data is always encrypted.
Proper deployment of a comprehensive per-file encryption mechanism is a task best tackled by the entire Linux distribution. The eCryptfs team is working closely with various major Linux distributions to help ensure that eCryptfs is properly used as one component of a comprehensive data protection strategy.
Q. Can I access the lower files while eCryptfs is mounted?
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.
Q. What kernel options do I need to enable to build eCryptfs?
Newer versions of the Linux kernel now have a ``Layered filesystems'' submenu under the ``File systems'' menu, where eCryptfs and Unionfs reside.
Make certain that you have loaded all of the crypto modules that you
need to run eCryptfs. This includes
Q. On what filesystems can I expect eCryptfs to function?
eCryptfs has been well tested on EXT3, and it should work well on other popular local filesystems such as JFS, XFS, ReiserFS, and so forth. Changes in the 2.6.24 kernel make eCryptfs more functional on NFS and CIFS, although there is still a little more work to do in order to make eCryptfs function as well on networked filesystems as it currently works on local filesystems. There is a patch to help resolve an unlink bug with eCryptfs on NFS; this patch will eventually make it upstream once it is well tested.
Q. Why is the kernel stack such an issue with eCryptfs?
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.
Q. Can I mount eCryptfs with a public key?
You can mount eCryptfs with a public key if you have public key
Q. Why would I want to use public key anyway?
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.
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.
A key module now ships in ecryptfs-utils to interface with cryptographic tokens via PKCS#11. There is also a key module to interface with a TPM chip.
Q. What is
|Simple in concept and implementation; just transform blocks as they pass through.||High level of design complexity; meticulous handling of internal filesystem primitives required.|
|Must allocate a block device to dedicate for the entire filesystem.||Stacks on top of existing mounted filesystems; requires no special on-disk storage allocation effort.|
|Everything in the filesystem incurs the cost of encryption and decryption, regardless of the confidentiality requirements for the data.||Selective encryption of the contents of only the sensitive files.|
|Fully protects the confidentiality of the directory structures, superblocks, file sizes, file permissions, and so forth.||Cannot keep all filesystem metadata confidential. Since stacked filesystems encrypt on a per-file basis, attackers will know the approximate file sizes, for instance.|
|Coarse granularity; only fixed per-mountpoint encryption policies are possible.||Fine granularity; flexible per-file encryption policies are possible.|
|No notion of ``encrypted files.'' Individual files must be re-encrypted via a userspace application before written to backups, sent via email, etc.||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.|
|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.||Clients can stack on locally mounted networked filesystems; individual files are sent to the server and stored in encrypted form.|
|Can protect databases that use their own dedicated block device.||Can only protect databases that write their tables to regular files in an existing filesystem.|
|Used to protect swap space.||Not designed to protect swap space; we recommend using block device encryption to protect swap space while using eCryptfs on the filesystem.|
|Possible to hide the fact that the partition is encrypted.||The fact that encrypted data exists on the device is obvious to an observer.|
|Filesystem-agnostic; any filesystem will work on an encrypted block device.||Can only be expected to work with existing filesystems that are upstream in the official Linux kernel.|
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.
You are probably using a kernel with the netlink interface to the userspace daemon. The netlink interface with the userspace daemon is buggy and obsolete.
To resolve the issue, there is a patch to migrate eCryptfs from using netlink for kernel-daemon communications to using a device handle instead. This patch has been merged into the -mm tree, and we anticipate that this patch will find its way into kernel release 2.6.26. In addition to this patch, you will need ecryptfs-utils release 44 or greater.
eCryptfs deliberately makes no attempt to re-implement the discretionary and mandatory access control mechanisms already present in the Linux kernel. eCryptfs will simply require that a File Encryption Key (FEK) be associated with any given inode in order to decrypt the contents of the file on disk. This prevents an attacker from accessing the file contents outside the context of the trusted host environment; for instance, by removing the storage device or by booting a live CD. This is the only type of unauthorized access that eCryptfs is intended to prevent.
Once eCryptfs has associated that FEK with the inode, it does not impose any additional restrictions on who or what can access the files, deferring to the standard user/group/other permissions, capabilities, SE Linux type enforcement, and so forth to regulate access to the files. eCryptfs maintains no pedigree regarding how the FEK found its way to the inode, so it has no way of knowing that any particular UID should or should not be able to open the file, nor should eCryptfs do such a thing.
Having eCryptfs impose additional access control onto the decrypted file contents in a trusted host environment would provide no additional security while introducing unintended usability issues. For instance, a user may wish to share his decrypted files with certain other users on the system without having to share his key with them or add their keys to a set of keys wrapping the inode's FEK. Users expect to be able to accomplish such a task via users, groups, capabilities, and types, and eCryptfs defers access control decisions on trusted host environments to these existing access control mechanisms.
Unable to allocate crypto cipher with name [---]; rc = [-2]"
Make sure that you have enabled the kernel crypto API and that you have built the ciphers, hashes, and chaining modes that you wish to use. This will usually be md5, aes, cbc, and ecb. Also, make sure that the requested key size is valid for your cipher.
Error mounting eCryptfs; rc = [-2]; strerr = [No such file or directory]"
Make sure that both the source and destination directories that you provide to the mount command exist.
Error mounting eCryptfs; rc = [-22]; strerr = [Invalid argument]"
Check your system log for the real problem.
ecryptfs_parse_options: Could not find key with description: [deadbeaf...]"
If the mount fails and the message "
Could not find key with description: [deadbeaf...]" is in
your system logs, then there was a problem inserting your mount key
into your kernel user session keyring.
After a mount attempt, run
keyctl_show. You should see
something like this:
# 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...
deadbeef is the signature that corresponds with
your key. If you don't see this, then there is a problem with your
If you su to root, be sure to initiate the session by using the - flag.
Finally, try linking your user keyring into your active session keyring:
# keyctl link @u @s
ecryptfs_parse_packet_set: Expected signature of size ; read size "
Older versions of eCryptfs shipping in older kernels had a minor bug where eCryptfs would only write out and read in 7 of the 8 key signature characters to the metadata of the lower file. This violates the eCryptfs spec, so newer versions of eCryptfs correct this bug and refuse to read files that do not conform to the spec.
The current correctly implemented version of eCryptfs cannot read files created with the early nonconformant and buggy release. If you have any files created with the earlier version, you will need to boot with the earlier version of eCryptfs and copy the decrypted files to secure location (e.g., a loopback mount image protected with dm-crypt). You will then need to copy the data from the secure location into an eCryptfs mount using the most recent kernel release.
Note that the Versions of eCryptfs from 2.6.24 and on will be able to read files created by earlier versions, back through to 2.6.24, as indicated in the ecryptfs-utils package README file:
eCryptfs is still in a developmental stage. When you upgrade the eCryptfs kernel module, it is possible that the eCryptfs file format has been updated. For this reason you should copy your files to an unencrypted location and then copy the files back into the new eCryptfs mount point to migrate the files. File format version 3 and beyond (in kernel version 2.6.24) is expected to remain readable, however.
Send a message to the ecryptfs-users mailing list.