Implementing Encrypted Home Directories
mount prompts you for a password and possibly for a key size.
Now that you understand how to mount and unmount encrypted loopback filesystems manually, an introduction to pam_mount is appropriate. pam_mount is a PAM module that simplifies the management of volumes and should be mounted when a user logs in to a system. It can handle mounting things like Samba-hosted volumes, Novell-hosted volumes and encrypted filesystems. The original author of pam_mount is Elvis Pftzenreuter. Mukesh Agrawal wrote the patch that first added support for loopback encrypted volumes. The author of this article now maintains pam_mount, which is available at www.flyn.org.
Instead of having to mount encrypted volumes manually, a system administrator can configure pam_mount to mount and unmount the volumes automatically when users log on and off. This can be configured so the system password also unlocks the encrypted volume, essentially creating a completely transparent encrypted volume.
pam_mount can employ three different techniques to unlock an encrypted volume. The first technique is rather boring. When the encrypted volume's key is unrelated to the system's login password, pam_mount simply prompts users for the key to their encrypted volume. In order to use this technique on a system, pam_mount.so and pmhelper must be installed and configured. The standard ./configure, make and make install commands build and install pam_mount's binaries and configuration file.
You should find the stock pam_mount.conf in /etc/security. Inspect and tailor it to your own system. The stock pam_mount.conf file is well documented. The most important change necessary is to add definitions for the volumes that should be mounted to the end of the file. The following is the definition format for encrypted loopback filesystems, as documented in the stock file:
volume user local ignored loopback file mount point mount options fs key cipher fs key path
Here is an example that mounts an AES-encrypted loopback filesystem hosted by /home/mike.img at /home/mike when Mike logs on:
volume mike local - /home/mike.img /home/mike loop,user,exec,encryption=aes,keybits=256 - -
Next, add the lines auth required pam_mount.so try_first_pass and session required pam_mount.so try_first_pass to the configuration files of the PAM-supporting services you want to support loopback encrypted filesystems. As an example, here is the /etc/pam.d/login file from my laptop:
auth requisite pam_securetty.so auth requisite pam_nologin.so auth required pam_env.so auth required pam_unix.so nullok account required pam_access.so account required pam_unix.so session required pam_unix.so session optional pam_lastlog.so session optional pam_motd.so session optional pam_mail.so standard noenv password required pam_unix.so nullok obscure \ min=4 max=8 md5 auth required pam_mount.so try_first_pass session required pam_mount.so try_first_pass
Finally, create the user's loopback encrypted filesystem using the steps listed in the introduction to encrypted loopback filesystems.
The second technique for pam_mount to unlock a volume is more convenient for users. If, when creating the encrypted volume using the same method as the first technique, a user specifies his or her login password as the volume key, then pam_mount unlocks the volume using the same password the user enters to login.
The third technique is the most flexible and requires a more sophisticated description. Here are a few terms to help you understand how this technique works:
sk: system key, the key or password used to log in to the system.
fsk: filesystem key, the key that allows you to use the filesystem you want pam_mount to mount for you.
E and D: an OpenSSL-supported synchronous encryption/decryption algorithm, bf-ecb, for example.
efsk: encrypted filesystem key, efsk = E_sk (fsk), stored somewhere on the local filesystem (that is, /home/user.key).
pam_mount reads efsk from the local filesystem, performs fsk = D_sk (efsk) and uses fsk to mount the filesystem. This technique has the advantage of allowing users to change their login passwords without having to re-encrypt their home directories using this new key. If the login password is changed, simply regenerate efsk (that is, /home/user.key) using efsk = E_newsk (D_oldsk (efsk)). A script named passwdehd is included in pam_mount to do this for you.
To implement this third technique, begin by creating the file to host the encrypted filesystem (as before):
dd if=/dev/urandom of=/home/user.img \ bs=1M count=image size in MB
Then, create a file (efsk) containing the volume's password (fsk) using /dev/urandom, encrypted using the user's login password as the key:
dd if=/dev/urandom bs=1c count=keysize / 8 | \ openssl enc -bf-ecb > /home/user.key
Next, create an encrypted loopback filesystem. The filesystem's key should be fsk (generated using /dev/urandom, encrypted and stored as /home/user.key in step 2).
openssl enc -d -bf-ecb -in /home/user.key | \ losetup -e aes -k keysize -p0 /dev/loop0 \ /home/user.img mkfs -t ext2 /dev/loop0 umount /dev/loop0 losetup -d /dev/loop0
Finally, in pam_mount.conf, set the fs key cipher variable to the cipher used to encrypt fsk, in this case bf-ecb, and set the fs key path variable to efsk's path, in this case, /home/user.key.
In his definitive text, Applied Cryptography, Bruce Schneier states, “Software encryption is scary.” What he means is, it is difficult to design truly secure encryption software for computers running general-purpose operating systems such as Linux. For example, modern operating systems can swap memory to disk at any time, and this memory could contain plain text or encryption keys. An encrypted volume is useless if its key has been written to disk by the operating system. One way to reduce the effects of this is to encrypt one's swap volume. CryptoAPI still cannot do this safely, but it is in development. A similar project, LoopAES, already can encrypt a system's swap space.
Consider again the example where I sent my iBook to Apple for repairs. Though my home directory is encrypted, my data still may not be completely safe. A dishonest employee could boot his or her diabolical CD-ROM and replace, for example, the login binary on my system with the employee's own design. When my computer is returned and I log in, my encryption key could be shipped off to a remote computer by the newly installed login program. An intrusion detection system would make this scenario much less likely.
Another possible weak point in a system employing encrypted home directories using pam_mount is the system's login password. Because the login password is used, directly or indirectly, to unlock an encrypted filesystem, it must be strong. Countless studies have shown that most passwords chosen by users are quite weak. Rather than blindly increasing the required length of passwords, spend some time reading Bruce Schneier's Secrets and Lies. A strong passphrase, written down and stored in your wallet may be more secure than a memorized password. The addition of a physical authentication token might be even better. Remember, if your system login password is not secure, your encrypted filesystem is as good as read.
Finally, encrypted filesystems can be a double-edged sword. What if you forget your encryption key? What if you use the third technique described above and accidentally delete all records of your encrypted filesystem key? What if my or someone else's encryption-related software is buggy? All of these problems can result in you having to try 2128 or so different encryption keys to get your filesystem back. Your data may be as good as gone. As with any system administration endeavor, make filesystem backups. Ideally, these backups are not encrypted and are physically locked up somewhere secure.
The bottom line is many subtle considerations and procedures are required to administer a reasonably secure system beyond the use of a modern encryption algorithm like AES. To quote Matt Blaze's contribution to Applied Cryptography:
High-quality ciphers and protocols are important tools, but by themselves poor substitutes for realistic, critical thinking about what is being protected and how various defenses might fail (attackers, after all, rarely restrict themselves to the clean, well-defined threat models of the academic world).
After reading this article, you should be familiar with the concept of an encrypted loopback filesystem. In addition, you should be able to deploy encrypted filesystems on the systems you administer and manage them with the pam_mount PAM module. In the future, I would like to see the CryptoAPI patches and pam_mount supported by the major Linux distributors. I also would like to see the CryptoAPI patch rolled into the mainstream util-linux package. Properly administered encrypted home directories are a powerful security tool.
Mike Petullo is a platoon leader in the US Army, stationed in Germany. He jumps out of airplanes by day, fights C code bugs by night and has been tinkering with Linux since early 1997. He welcomes your comments sent to email@example.com.
|Non-Linux FOSS: Install Windows? Yeah, Open Source Can Do That.||Nov 24, 2015|
|Cipher Security: How to harden TLS and SSH||Nov 23, 2015|
|Web Stores Held Hostage||Nov 19, 2015|
|diff -u: What's New in Kernel Development||Nov 17, 2015|
|Recipy for Science||Nov 16, 2015|
|Firefox's New Feature for Tighter Security||Nov 13, 2015|
- Non-Linux FOSS: Install Windows? Yeah, Open Source Can Do That.
- Cipher Security: How to harden TLS and SSH
- Web Stores Held Hostage
- How Will the Big Data Craze Play Out?
- Firefox's New Feature for Tighter Security
- It's a Bird. It's Another Bird!
- Libreboot on an x60, Part II: the Installation
- diff -u: What's New in Kernel Development
- Strengthening Diffie-Hellman in SSH and TLS
- November 2015 Issue of Linux Journal: System Administration