Stacked Encrypted Filesystems

A stacked filesystem comprises filesystems built on top of other filesystems. Gluster and Lustre are two examples of stacked filesystems that quickly spring to mind. In the case of data encryption, the encrypted filesystem uses a “lower” type of filesystem (FS), such as XFS or ext4, to store encrypted data. To a user, the data appears to be gibberish, meaning it is encrypted. You have to “mount” the encrypted filesystem to be able to decrypt the data so that it makes sense.

Two prominent stackable Linux filesystems are EncFS and eCryptfs. I’ll start with EncFS because it can be mounted by a user, giving it enormous flexibility.

EncFS

EncFS is an encrypted virtual filesystem (VFS). It has been around for a while, but its last update appears to have been in 2010. I’m not sure if it’s still under active development, but I know people still use it. EncFS encrypts the data a file at a time and then stores it on a typical Linux filesystem such as XFS or ext4. The author of EncFS refers to it as a “pass-through” filesystem rather than an encrypted block device (such as a SED). I just think of it as a stackable filesystem or a meta-filesystem.

EncFS is a FUSE-based userspace filesystem. The FUSE kernel module allows access to the VFS in the kernel. Consequently, you can create a filesystem entirely in user space using the FUSE API.

Some advantages of using the stackable filesystem approach include the ability to encrypt a directory tree or even an entire filesystem. Plus, you can just keep adding data to the encrypted filesystem until you run out of space on the underlying FS. Moreover, because EncFS deals with files and directories, you can keep using your normal backup tools. If the files change, the backup tool detects that and does the appropriate backup, but the backup just shows encrypted files (gibberish).

The requirements for EncFS are pretty simple:

• FUSE version 2.6 or newer.
• rlog – C++ logging library.
• OpenSSL versions 0.9.6 through 0.9.8 (other version are untested).
• boost – a C++ utility library, version 1.34 or later.

After ensuring your system fulfills these requirements, just download and build EncFS, or you can use your package management tool to install these dependencies and EncFS.

Once everything is installed, you should run two quick commands as root so you can use EncFS as a user:

# usermod -a -G fuse laytonjb
# chmod +x /usr/bin/fusermount

The next step is to create two directories in your account to contain the encrypted and decrypted data.

$ mkdir -p encrypted
$ mkdir -p decrypted

The first directory will contain the data in encrypted form, and the second directory is where you put data to be encrypted (i.e., non-encrypted data). With these two directories, you can run the encfs command to “mount” the EncFS filesystem:

$ encfs ~/encrypted ~/decrypted
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.
?> 
 
Standard configuration selected.
 
Configuration finished.  The filesystem to be created has
the following properties:
Filesystem cipher: "ssl/aes", version 3:0:2
Filename encoding: "nameio/block", version 3:0:1
Key Size: 192 bits
Block Size: 1024 bytes
Each file contains 8 byte header with unique IV data.
Filenames encoded using IV chaining mode.
File holes passed through to ciphertext.
 
Now you will need to enter a password for your filesystem.
You will need to remember this password, as there is absolutely
no recovery mechanism.  However, the password can be changed
later using encfsctl.
 
New Encfs Password: 
Verify Encfs Password: 

I used the default options (by pressing Enter). Notice that I also entered a pass phrase that I need to mount the encrypted filesystem, then I can check to see whether the filesystem is mounted.

$ mount
/dev/sda2 on / type ext4 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw)
/dev/sda1 on /boot type ext2 (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
nfsd on /proc/fs/nfsd type nfsd (rw)
encfs on /home/laytonjb/decrypted type fuse.encfs (rw,nosuid,nodev,default_permissions,user=laytonjb)
 
$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda2              53G   35G   15G  70% /
tmpfs                 3.6G  536K  3.6G   1% /dev/shm
/dev/sda1             485M   73M  387M  16% /boot
encfs                  53G   35G   15G  70% /home/laytonjb/decrypted

The EncFS filesystem is there. Notice that I did all of this as a user – no root access is required. This means that as a user I can control what data is encrypted.

I don’t want to get into a tutorial on EncFS, but I’ll show how it works because other encrypted filesystems are similar. First, I’ll create a couple of files and a symlink in the decrypted filesystem (~/decrypted ).

[laytonjb@test1 ~]$ cd decrypted
[laytonjb@test1 decrypted]$ echo "hello foo" > foo
[laytonjb@test1 decrypted]$ echo "hello bar" > bar
[laytonjb@test1 decrypted]$ ln -s foo foo2
[laytonjb@test1 decrypted]$ ls -l
total 8
-rw-rw-r-- 1 laytonjb laytonjb 10 Sep  4 15:12 bar
-rw-rw-r-- 1 laytonjb laytonjb 10 Sep  4 15:12 foo
lrwxrwxrwx 1 laytonjb laytonjb  3 Sep  4 15:12 foo2 -> foo

The results of the ls -l tells me that my access is to the decrypted data. If I change directories to the encrypted directory and try a similar command, I would see the following:

[laytonjb@test1 decrypted]$ cd ~/encrypted
[laytonjb@test1 encrypted]$ ls -l
total 8
lrwxrwxrwx 1 laytonjb laytonjb 24 Sep  4 15:12 acS5u3K9TJ,9FWTDUq0yWqx6 -> XuD50Mah2kp2vukDeo04cOv,
-rw-rw-r-- 1 laytonjb laytonjb 18 Sep  4 15:12 WvPjlWtCaq5g9hE1NHMI3lfi
-rw-rw-r-- 1 laytonjb laytonjb 18 Sep  4 15:12 XuD50Mah2kp2vukDeo04cOv,

Although the files are there, the names and data are encrypted and consequently unintelligible.

Next I’ll unmount EncFS and look at the files in ~/encrypted and ~/decrypted :

[laytonjb@test1 ~]$ fusermount -u ~/decrypted
[laytonjb@test1 ~]$ mount
/dev/sda2 on / type ext4 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw)
/dev/sda1 on /boot type ext2 (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
nfsd on /proc/fs/nfsd type nfsd (rw)
[laytonjb@test1 ~]$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda2              53G   35G   15G  70% /
tmpfs                 3.6G  536K  3.6G   1% /dev/shm
/dev/sda1             485M   73M  387M  16% /boot
[laytonjb@test1 ~]$ cd decrypted
[laytonjb@test1 decrypted]$ ls -l
total 0
[laytonjb@test1 decrypted]$ cd ../encrypted
[laytonjb@test1 encrypted]$ ls -l
total 8
lrwxrwxrwx 1 laytonjb laytonjb 24 Sep  4 15:12 acS5u3K9TJ,9FWTDUq0yWqx6 -> XuD50Mah2kp2vukDeo04cOv,
-rw-rw-r-- 1 laytonjb laytonjb 18 Sep  4 15:12 WvPjlWtCaq5g9hE1NHMI3lfi
-rw-rw-r-- 1 laytonjb laytonjb 18 Sep  4 15:12 XuD50Mah2kp2vukDeo04cOv,

In the first line I used the command fusermount -u to unmount the filesystem because it’s a userspace filesystem. Also notice that the decrypted part of the filesystem is not visible anymore (i.e., the files aren’t there), but the encrypted directory still has the encrypted files. When EncFS is used a again with the same decrypted and encrypted directories, it will automatically decrypt the files and allow you to access them in the ~/decrypted directory.

The first key point about using EncFS is that a user can use without administrator intervention. I believe this is a strength of EncFS, because it allows each user to control what they do and don’t want to encrypt. Theoretically this reduces the number of people who are in the middle of encrypting data.

The second thing to notice is that when EncFS is mounted, you can view the decrypted data in the decrypted directory. If the system is compromised, then an intruder can access your data. EncFS is not designed to encrypt data from an intruder, but you should be aware that the data can be “seen” by someone when EncFS is mounted (they just go to the ~/decrypted directory).

The third thing to notice is that although the file name and data are encrypted, some of the basic metadata information is not. Someone can still see that you have a certain number of files and that you own them. They can also see file permissions. This information might not seem valuable, but it could be useful in some situations. This is one of the limitations of EncFS.

eCryptfs

One of the best known Linux filesystem encryption solutions is called eCryptfs (Enterprise Cryptographic Filesystem). It has been in the kernel since version 2.6.19 and is fully configured in some distributions. The eCryptfs filesystem stacks on top of other filesystems (called the lower filesystem), such ext2/3/4, JFS, XFS, and others (i.e., any filesystem that has extended attributes). It encrypts and decrypts the files as they are being written to, or read from the lower filesystem by operating on the files one at a time instead of at a block device or partition level. The metadata associated with the file is stored with the file itself on the lower filesystem. This can make the encrypted files a little larger than the decrypted version, but there are some clear advantages to this approach:

• It allows files from different users to use different encryption keys, controlling access to the data.
• You can move or copy the files to a different location, and they can be decrypted with the correct key (encryption of whole partitions or devices requires a different process before the files can be accessed).
• You can give the file to other users, and they can decrypt it as long as the correct key is supplied as well.
• You can use typical incremental backup processes because they can easily detect differences in files in the lower filesystem. This is almost impossible with encrypted partitions or block devices.

A few quick disadvantages:

• The CPU cycles required to perform the encryption are not small.
• Because of the time involved to encrypt the filesystem, the speed (performance) of the encrypted filesystem is less than the lower filesystem. In fact, it can be quite a bit less in some cases, so only use an encrypted filesystem if performance is not a key consideration and security (encryption) is an extremely important requirement.

The kernel component of eCryptfs has been in the kernel since 2.6.19. The userspace tools for eCryptfs can be obtained from the eCryptfs site. Follow the directions from the website that explain how to build and install the tools.

To use eCryptfs, it must be active either in the kernel or as a module. A simple way to get started is just to mount an eCryptfs filesystem in your account (i.e., a single directory). This has to be done as root because you are mounting a filesystem:

[root@test1 laytonjb]# mount -t ecryptfs /home/laytonjb/private /home/laytonjb/private
Select key type to use for newly created files: 
 1) tspi
 2) passphrase
 3) openssl
Selection: 2
Passphrase: 
Select cipher: 
 1) aes: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)
 2) blowfish: blocksize = 16; min keysize = 16; max keysize = 56 (not loaded)
 3) des3_ede: blocksize = 8; min keysize = 24; max keysize = 24 (not loaded)
 4) cast6: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)
 5) cast5: blocksize = 8; min keysize = 5; max keysize = 16 (not loaded)
Selection [aes]: 1
Select key bytes: 
 1) 16
 2) 32
 3) 24
Selection [16]: 2
Enable plaintext passthrough (y/n) [n]: n
Enable filename encryption (y/n) [n]: n
Attempting to mount with the following options:
  ecryptfs_unlink_sigs
  ecryptfs_key_bytes=32
  ecryptfs_cipher=aes
  ecryptfs_sig=f1c2c0b669730359
WARNING: Based on the contents of [/root/.ecryptfs/sig-cache.txt],
it looks like you have never mounted with this key 
before. This could mean that you have typed your 
passphrase wrong.
 
Would you like to proceed with the mount (yes/no)? : yes
Would you like to append sig [f1c2c0b669730359] to
[/root/.ecryptfs/sig-cache.txt] 
in order to avoid this warning in the future (yes/no)? : yes
Successfully appended new sig to user sig cache file
Mounted eCryptfs

When you mount for the first time, eCryptfs asks you a number of questions about security and encryption. In the beginning, you can easily accept the defaults. Notice that I’ve used eCryptfs before, so it asked me about the different passphrase.

In the mount command, the first path is the lower directory (the lower filesystem where the data is actually stored). In this case, the full path is used. The second path is the eCryptfs mountpoint. For this particular example, the lower filesystem and the mountpoint are the same, although they don’t have to be. Any file that is written to /home/laytonjb/private is encrypted and written to /home/laytonjb/private on the lower filesystem. Effectively, it looks like the directory /home/laytonjb/private is encrypted. Note that if I already had files in the directory /home/laytonjb/private , I wouldn’t be able to access them because eCryptfs was mounted over it. This is the same behavior when mounting a filesystem for any mountpoint – any files in the mountpoint are no longer accessible.

You can check that the filesystem is mounted with the mount command:

[root@test1 laytonjb]# mount
/dev/sda2 on / type ext4 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw)
/dev/sda1 on /boot type ext2 (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
nfsd on /proc/fs/nfsd type nfsd (rw)
gvfs-fuse-daemon on /home/laytonjb/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=laytonjb)
/home/laytonjb/private on /home/laytonjb/private type ecryptfs (rw,ecryptfs_sig=f1c2c0b669730359,ecryptfs_cipher=aes,ecryptfs_key_bytes=32,ecryptfs_unlink_sigs)

Notice the eCryptfs filesystem in the last line. If I do an ls on the directory, you can see that it looks just like any other directory:

[laytonjb@test1 ~]$ ls -lstar ~/private
total 8
4 drwxrwxr-x   2 laytonjb laytonjb 4096 Sep  6 13:10 .
4 drwx------. 46 laytonjb laytonjb 4096 Sep  6 13:19 ..

Now I’ll create a couple of files and a symlink in the directory:

[laytonjb@test1 ~]$ cd private
[laytonjb@test1 private]$ echo "hello foo" > foo
[laytonjb@test1 private]$ echo "hello bar" > bar
[laytonjb@test1 private]$ ln -s foo foo2
[laytonjb@test1 private]$ ls -l
total 24
-rw-rw-r-- 1 laytonjb laytonjb 10 Sep  6 13:23 bar
-rw-rw-r-- 1 laytonjb laytonjb 10 Sep  6 13:23 foo
lrwxrwxrwx 1 laytonjb laytonjb  3 Sep  6 13:23 foo2 -> foo
[laytonjb@test1 private]$ cat bar
hello bar

The encrypted filesystem is mounted, so I can easily create files that appear to be decrypted in that directory. However, if I umount the filesystem, you will see something different (note: root has to umount the filesystem):

[root@test1 laytonjb]# umount /home/laytonjb/private
[root@test1 laytonjb]# mount
/dev/sda2 on / type ext4 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw)
/dev/sda1 on /boot type ext2 (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
nfsd on /proc/fs/nfsd type nfsd (rw)
gvfs-fuse-daemon on /home/laytonjb/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=laytonjb)
[laytonjb@test1 ~]$ cd private
[laytonjb@test1 private]$ ls -lstar
total 32
12 -rw-rw-r--   1 laytonjb laytonjb 12288 Sep  6 13:23 foo
12 -rw-rw-r--   1 laytonjb laytonjb 12288 Sep  6 13:23 bar
 0 lrwxrwxrwx   1 laytonjb laytonjb     3 Sep  6 13:23 foo2 -> foo
 4 drwxrwxr-x   2 laytonjb laytonjb  4096 Sep  6 13:23 .
 4 drwx------. 46 laytonjb laytonjb  4096 Sep  6 13:26 ..
[laytonjb@test1 private]$ cat foo
 
�
 ��ՍW0�-   "3DUfw`�.�}�M�>

The directory private is where the encrypted files are stored; notice the file output is gibberish, indicating encryption.

To decrypt a file in this example, just copy it from the mountpoint to a non-encrypted directory:

[laytonjb@test1 private]$ cp /home/laytonjb/private/foo /home/laytonjb/public/foo.decrypted

eCryptfs will decrypt the file foo , and it will be put in the directory /home/laytonjb/public as foo.decrypted , which is not an encrypted filesystem.

This quick example shows how to create an encrypted directory in your /home account. It is also possible to encrypt a user’s entire /home by root or by the user (as long as they have permission for the mountpoint – which they should). Finally, some blogs and tutorials provide more detail on how to use eCryptfs:

• Single-file encryption in Linux

• Ubuntu tutorial

• eCryptfs tutorial

• Debian instructions, but a good overall tutorial

• IBM tutorial

• Encrypting your entire /home directory

Summary

As with everything else, encrypting your data has its pluses and minuses. On the plus side are the obvious benefits of having your data encrypted so prying eyes can’t make heads or tails of it. They may be able to copy it, but either they will have to know how to crack the encryption or they will have to “brute force” the decryption using lots of computational power. On the minus side, encryption will slow down the system I/O because of the computational load. Also, if you happen to forget your passphrase, you won’t be able to access your data again (unless you crack the algorithm or the passphrase). Encryption also makes data portability a bit more difficult. However, given the overall scrutiny of data security, these minuses might not be such a bad thing.

In this article, I presented two options for encrypting files, directories, or filesystems. The ability to encrypt these structures, in my opinion, provides a great deal of flexibility by allowing you to keep some data encrypted and some decrypted. For example, I might not want people to know my taste in music, but I might not mind if they see email, some documents, or my fantasy football picks. As a user, allowing me to control what is encrypted helps me if I forget my passphrase, because in that case, I will not have lost everything.

In the first option, EncFS, encryption is in user space under the control of the user – bypassing requests, approval, and administration scheduling – so data can be encrypted whenever needed. One benefit of this is that fewer people are involved in the data encryption process, which can help with security in some cases.

The second option, eCryptfs, also allows you to encrypt files, directories, and filesystems, but requires administrator intervention for the creation and mounting of an encrypted directory. Many people use eCryptfs for encrypting their entire /home directory because it is so easy to use.