Linux File Encryption

We live in a world where privacy and security are becoming increasingly important. Nearly every day there is news about a data breach or a leak. While there are other measures you can take to safeguard your data, encrypting files is one of the more obvious ones.

Alternatives to File Encryption.

Before we dive deeper into file encryption, let’s consider the alternatives and see if the file encryption is suitable for your needs. Sensitive data can be encrypted on different levels of granularity: full disk encryption, filesystem-level, database level and application level. This article does a good job comparing these approaches. Let’s summarize them.

Full disk encryption (FDE) makes sense for devices that are susceptible to physical loss or theft, such as laptops. But FDE is not going to protect your data from much else including remote hacking attempts and is not suitable for encrypting individual files.

In the case of filesystem-level encryption, the file system performs the encryption directly. This can be accomplished by stacking a cryptographic file system on top of the main one or it might be built in. According to this wiki, some of the advantages are: each file can be encrypted with a separate key (managed by the system) and additional access control through public-key cryptography. Of course, this requires modifying OS configuration and might not be suitable for all users. However, it offers protection suitable for most situations, and it is relatively easy to use. It will be covered in down below.

The database level encryption can target specific parts of data such as a specific column in a table. However, this is a specialized tool that deals with file contents rather than entire files and is thus outside the scope of this article.

Application level encryption, may be optimal when security policies require safeguarding specific data. An application can use encryption to protect data in many ways, and encrypting a file is certainly one of them. We will be discussing an application for encrypting files below.

Encrypting a file with an Application

There are several tools available for encrypting files under Linux. This article lists the most common alternatives. As of today the GnuPG seems to be the most straightforward choice. Why? Because, chances are, it is already installed on your system (unlike ccrypt), the command line is simple (unlike using openssl directly), it is being very actively developed and is configured to use an up to date cypher (AES256 as of today).

If you don’t have gpg installed, you can install it by using a package manager appropriate for your platform such as apt-get:

pi@raspberrypi:~ $ sudo apt-get install gpg
Reading package lists… Done
Building dependency tree
Reading state information… Done

Encrypt a file with GnuPG:

pi@raspberrypi:~ $ cat secret.txt
Top Secret Stuff!
pi@raspberrypi:~ $ gpg -c secret.txt
pi@raspberrypi:~ $ file secret.txt.gpg
secret.txt.gpg: GPG symmetrically encrypted data (AES256 cipher)
pi@raspberrypi:~ $ rm secret.txt

Now, to decrypt:

pi@raspberrypi:~ $ gpg –decrypt secret.txt.gpg >secret.txt
gpg: AES256 encrypted data
gpg: encrypted with 1 passphrase
pi@raspberrypi:~ $ cat secret.txt
Top Secret Stuff!

Please note “AES256” above. This is the cypher used for encrypting the file in the example above. It is a 256 bit block sized (secure for now) variant of “Advanced Encryption Standard” (also known as Rijndae) cypher suit. Check out this Wikipedia article for more information.

Setting up Filesystem-level Encryption

According to this fscrypt wiki page, ext4 filesystem has built in support for file encryption. It utilizes fscrypt API to communicate with the OS kernel (assuming encryption feature is enabled). It applies the encryption at directory level. The system can be configured to use different keys for different directories. When a directory is encrypted so is all filename related data (and metadata) such as file names, their contents and subdirectories. Non-filename metadata, such as timestamps, are exempt from encryption. Note: this functionality became available in Linux 4.1 release.

While this README has instructions, here is a brief overview. The system adheres to the concepts of “protectors” and “policies”. “Policy” is an actual key that is used (by OS kernel) for encrypting a directory. “Protector” is a user passphrase or equivalent that is used to protect policies. This two level system allows controlling user’s access to directories without having to re-encrypt every time there is a change in the user accounts.

A common use case would be setting up fscrypt policy to encrypt user home directory with their login passphrases (obtained via PAM) as a protector. Doing so would add an additional level of security and allow safeguarding the user data even if the would be attacker managed to get admin access to the system. Here is an example illustrating what setting it up would look like:

pi@raspberrypi:~ $ fscrypt encrypt ~/secret_stuff/
Should we create a new protector? [y/N] y
The following protector sources are available:
1 – Your login passphrase (pam_passphrase)
2 – A custom passphrase (custom_passphrase)
3 – A raw 256-bit key (raw_key)
Enter the source number for the new protector [2 – custom_passphrase]: 1
Enter login passphrase for pi:
"/home/pi/secret_stuff" is now encrypted, unlocked, and ready for use.

This could be completely transparent to the user once set up. The user could add an additional level of security to some subdirectories by specifying different protectors for them.

Conclusion

Encryption is a deep and complex subject and there is much more to cover and it is also a rapidly growing field, especially with the advent of quantum computing. It is crucial to keep in touch with new technological developments as what is secure today could be cracked in a few years. Be assiduous and pay attention to the news.