Locking up Linux: Creating a Cryptobook

Technical Discussion On Encryption

Cryptographic functions are essential to all modern multi-user computer systems, where the logical separation of user data, processes, and information is instrumental to maintaining order. Login passwords are hashed and compared against saved hashes to authenticate users in many multi-user operating systems. Single files or entire partitions may be individually encapsulated inside cryptographic containers to secure private data from public view. Even network protocols such as SSL/TLS and IPSec leverage serious cryptographic functionality from random devices (/dev/random, /dev/urandom, etc.) through modular algorithms supplied to the kernel when and as they're needed.

The goal of any disk encryption technology is to prevent unauthorized access to private information, and limit the loss of intellectual property resulting from unauthorized access or theft of the physical property itself. Linux kernel version 2.6.4 introduced an improved cryptographic infrastructure that enables relatively easy and secure containment of sensitive data at many levels of software. There are block-level encryption infrastructures like those provided by the Linux Unified Key Setup (LUKS), and user-space implementations like those in the EncFS and CryptoFS file systems, themselves based entirely on the Fast Userspace File System (FUSE) for Linux. Of course, any crypto system is ultimately only as strong its passwords or keys.

There are four primary layers at which drive encryption technology may be applied:

• File level (file-by-file basis)
• File system level (a container for files)
• Block device level (a container for the file system)
• Hardware level (specialized cryptographic devices)

File level encryption is straightforward and commonly takes the form of secure messaging systems. It works on a case-by-case (or file-by-file) basis, which is good for manageable quantities of files with low risks of exposure. Key management becomes a critical issue for multi-user file systems where all folders or files are encrypted using individual keys, unless all data is keyed similarly, which then essentially becomes something like typical drive encryption. As always, the onus is on the user to choose strong passwords.

More advanced encryption applications operate at the file system level and handle files as they are created, stored or modified. This method provides better coverage for private content used in an unpredictable fashion, or for large numbers of files - especially for applications where it might be impractical to regulate control on an individual basis.

Encryption Products For Linux

Some cryptographic technologies come free of charge and are included with many community distributions - even some versions of Windows ship with Encrypted File System (EFS) capability. In this case, Fedora supplies cryptsetup with LUKS capability - which can also be used from Windows through a sharable file system format such as FAT or FAT32 and the FreeOTFE application - and provides FUSE and EncFS in a package repository called Extras. CryptoFS may be obtained directly from its main distribution at site.

The FUSE infrastructure consists of a loadable kernel module and a userspace library that serves as a basis for both the Crypto file system (CryptoFS) and the Encrypted file system (EncFS). By design, FUSE is non-intrusive to kernel sources, and provides a great deal of flexibility for implementing many interesting applications for file systems, such as the remotely mountable Secure Shell file system (SSHFS).

CryptoFS stores encrypted data in a typical directory structure comprised of two basic parts: the plain text information (files, directories, archives) and the actual encrypted directory itself. Once taken offline, the source directory can only be re-mounted if the key is known. CryptoFS does not require special privileges, nor is it particularly difficult to configure.

EncFS also provides a userspace cryptographic implementation using the FUSE library to provide security against offline attack, and operates on a case-by-case basis for files. Its structure is derived from earlier implementations, with improvements in both its form and function. Today, EncFS can expand dynamically to satisfy increased usage requirements, and files can be backed up individually based on changes to content, attributes, and so forth. In fact, the underlying storage for EncFS can be virtually anything from an ISO image to a network drive share, or even a distributed file system.

Both systems work in a pass-through fashion and can be layered atop other file system formats and logical abstractions - such as a journaling or extended file systems spread across separate physical volumes joined by a logical volume manager (LVM). For setups like EncFS, no protection adheres to the number of files encrypted, permissions and sizes for each file, or file name size - all of which can potentially leak sensitive information about the contents or activities of a volume. See the following image for a conceptual view of how this works: there, the visible directory is indicated by the /mount point in the diagram (which is associated at that level with the unencrypted EncFS data).