Author: Rui Lopes
If you have a dedicated encrypted partition or disk, you need to keep only one passphrase or key to unlock all your protected files. Some solutions allow you to go as far as encrypting the swap and the root partition. The drawbacks include sometimes a loss of performance (unfortunately, a necessary trade-off for security), and the fact that if an attacker gets ahold of your key (or you just happen to lose it), you can say goodbye to all your protected files.
The loopback device and dm-crypt
Presently, the main approaches to filesystem encryption supported by the Linux kernel use the loopback device driver and the device-mapper system (using the dm-crypt target). If you intend to use the loopback device approach, then loop-AES is your best choice. It’s one of the most mature disk encryption methods available for Linux, and its excellent README provides precious real-world examples on filesystem encryption.
Dm-crypt was bundled with the 2.6 series of the kernel, and provides better performance and more security than the loopback device driver. It is also richer in features.
The most promising project presently using dm-crypt seems to be LUKS, which aims to provide a standard on-disk format, making it easier to migrate protected data between distributions. Besides that, it offers multiple key management (a big plus), and the encrypted partitions can be accessed in Windows through FreeOTFE (an even bigger plus).
Approaches using FUSE
Two other applications take a different tack. Both CryptoFS and EncFS are encrypted filesystems that run on top of FUSE, a package that allows users to create a filesystem in userspace and mount it without needing to have root privileges, among other things. With these applications, files (and their filenames) are encrypted and contained in a normal directory. The user must select another directory as a mount point for the encrypted filesystem: the protected data will be decrypted there, using a key. Without the
key, there is no way to mount the directory with the decrypted files.
CryptoFS and EncFS provide a good ratio between security and convenience for the user. Filesystems created with FUSE can dynamically grow to any size, as opposed to the loopback approach, for instance, which requires the creation of a fixed-size partition. However, for the most cautious (or paranoid) user, there is a big disadvantage in using FUSE filesystems: looking inside the regular directory, anyone can still see how many encrypted files there are in total, calculate their real sizes, and check the permissions they have.
A benchmark by Tom’s Hardware, comparing EncFS and CryptoFS with LUKS, indicates that LUKS has the upper hand in terms of file performance.
eCryptfs
Another option found upstream in the Linux kernel is eCryptfs. You’ll need the kernel module and the userspace utilities to install and use it. eCryptfs provides a stacked encrypted filesystem, meaning it works on top of another existing filesystem and its call stack (due to that, some filesystems, such as XFS, may cause problems; check the eCryptfs FAQ).
An advantage of using eCryptfs is that it’s a native Linux filesystem, and doesn’t need to operate through FUSE or RPC calls, which means it has less dependencies, and is probably cleaner to develop. Cryptographic metadata about each file is stored in the header of the file itself, which makes migration of data and backups easier. Features like key management are available, and others, like filename encryption, are planned for the near future.
Deniable encryption
In some situations, data needs not only to be protected, but also kept invisible to everyone except the owner. There are already laws in some countries that state you can go jail if you refuse to supply the keys to your encrypted files, if asked to do so by the authorities. The best protection, sometimes, is not to have any visible encrypted data.
Some steganographic tools allow the user to inconspicuously hide data “behind” other files (normally image or sound files). However, when you have many files to hide, or their size is too large to be hidden behind a simple .jpg, your best bet is to use steganographic filesystems.
One recent interesting proposal is an MP3 steganographic filesystem. Most of the other approaches involve simply creating hidden encrypted partitions. But they don’t stop there: they also allow users to create layers within those partitions, with different passwords for each. When forced to give a password for a hidden partition, the user could supply one that gave access to a layer filled with dummy data. Each layer knows nothing about the other layers, so it’s impossible to prove their existence. There you have it: plausible deniability.
Steganographic filesystems also carry disadvantages. Since hidden data has to be randomly distributed throughout the entire disk or partition (which makes it almost impossible to trace — a very good thing), that means it can be overwritten by regular file operations in your visible partitions. Data collisions can also occur. File performance with this type of filesystem is remarkably poor as well. But the worst part is that, sadly, almost all the projects that I know of are dead or half-dead. I’m talking about Rubberhose, Phonebook, and StegFS. MagikFS looks promising in theory; let’s hope it doesn’t follow the same fate as the others.
There is, however, a stable and well-maintained tool I recommend if you need to use deniable encryption: Truecrypt. Besides allowing the creation of simple encrypted partitions, Truecrypt can also create hidden volumes, where an encrypted “outer partition” is used to conceal dummy data, and then, inside of it, a smaller and invisible “inner partition” is created, its data kept in the free space of the outer partition.
If you read its instructive documentation, you’ll see that Truecrypt has found several ways to evade the problems of data corruption and file performance associated with steganographic filesystems. Besides that, it’s easy to install and use, and has both Linux and Windows versions available (you’ll need the kernel sources to install it on Linux). It’s one of the best disk encryption solutions available for both operating systems.
Making security a priority
As someone said, security is a state of mind. It is you who, in the end, make your system secure, not the software you use. There are common vulnerable spots in every system that file and even disk encryption won’t cover. Every time you access a file, a copy may be left in the swap space, or in temporary directories. The history file of your shell will show the most recent commands typed in. Many applications make backup copies of files created with them. And that document you just printed and wiped from disk may still be recoverable from the printer spool. Your keys should be written on a paper or stored in a portable medium (pendrive, CD-ROM) and kept in a safe place. Given the choice, it’s better to be paranoid than careless.
As a final note, if you’re using FreeBSD, you can try CryptoFS and EncFS through Fuse4BSD. And you should also take a look at CGD (NetBSD) and GBDE. For more information on steganography and data concealment, check the information hiding homepage. I must also add that you should not simply discard regular file encryption in favor of encrypted filesystems, but instead consider a solution involving both. And, if you have the resources for it, consider hardware encryption such as the Trusted Platform Module.
Rui Lopes is a Portuguese Web designer and filmmaker who has a wide range of interests in the technology field.
Category:
- Security
