Using Encryption

Computer users live in a dangerous world filled with evil characters. Mathematics is our only friend; it allows us to encrypt important things and protect them from the prying eyes of strangers and black hats. Of course, encryption depends on the hope that P ≠ NP, but that is far better than depending on the kindness of strangers. Let us look at a few scenarios:

  • Laptops can be stolen, and then the original owner can only hope for the kindness of the thief not to misuse the sensitive data in the stolen laptop before reformatting the hard disk for his own use. Unless the data was encrypted before it was stolen.

  • Computers often have to be given for repair, and the owner depends on the kindness of the technician not to misuse the sensitive data in the machine while repairing it. Unless the data was encrypted before the machine failed.

  • USB sticks and external hard disks that use flash storage are another big headache because (a) they are more easily lost and (b) it is very hard to securely delete data from that short of physically destroying the device. Writing only encrypted data onto these devices is a much better solution than looking for a hammer after you have written data unencrypted.

There are two broad philosophies when it comes to encryption. The first approach believes in encrypting everything: HTTPS-everywhere and Full Disk Encryption are examples of this approach. The second approach is to encrypt only the sensitive data and leave the rest unencrypted. Truly paranoid people might combine both these approaches by encrypting sensitive files and placing these encrypted files inside a disk which is itself under Full Disk Encryption with a different password.

The level of security required also depends on the threat model. My threat model is that somebody might steal my laptop for its hardware value and then having taken possession of it might also try to read what is there. If you engaged in a conflict with an oppressive government or a powerful criminal organization, your threat model might be the reverse: somebody might steal or grab your laptop with the sole purpose of reading the data – the hardware itself is worthless to this kind of thief. I like to hope and believe that I am not in the second category, though this could well be a delusion.

My use of encryption is based on the assumption that

  1. I need to protect only my sensitive files and not everything, and

  2. I need protection only against casual intruders and not against a nation state or a malicious and talented group of hackers.

  3. Given the above, I would like to have the luxury of (a) setting up multiple users who can use the system independently, (b) using hibernation, (c) installing multiple operating systems sharing the same home partition. Each of these might weaken the security against a determined hacker, but might be tolerable weaknesses given my threat model.

    I also have the huge advantage of using Linux which provides kernel level support for a wide variety of strong encryption techniques. For the usability reasons mentioned above, I have chosen not to use full disk encryption or even an encrypted home partition. The solution that I have adopted is to use encrypted LUKS volumes to store sensitive files and leave everything else unencrypted. To do this, I use the packages cryptmount and cryptsetup which are available in the repositories in most linux distributions. These packages allow normal users to mount and unmount encrypted file systems. To set up the encryption for the first time, one has to log in as root (or use sudo), but after that only normal user privileges are required to use the system.

There are many tutorial on the web about cryptmount and cryptsetup, and my github page also provides some useful code for setting up encrypted file systems. I will therefore not talk about that in this post. Instead, I describe how to achieve a tolerable degree of security in this setup while allowing me to share the machine with others, to hibernate the system when not in use, and to restart the system only occasionally.

Hibernation and unencrypted swap

Since I am not using Full Disk Encryption and I am not even encrypting the swap partition, careful consideration needs to be given to the use of hibernation. During hibernation, the entire memory image is written to the swap partition unencrypted. This means that somebody booting the system from a Live Disk could read the swap partition and get hold of the encryption keys from the kernel image.

My solution is to unmount the encrypted volume automatically on hibernation. This can be done by creating an executable script in the folder /etc/pm/sleep.d since Linux executes all files in this folder while hibernating. It is conventional to start the file name with a number indicating the sequence in which the files are to be executed – for example, 50-crypt-unmount:


    #!/bin/bash

    case "$1" in
      hibernate)
        # put commands to run on hibernation here
        cryptmount -u targetname
        ;;
      thaw)
        # put commands to run when returning from hibernation here
        ;;
      suspend)
        # put commands to run on suspend here
        ;;
      resume) 
        # put commands to run when returning from suspension
        ;;
    esac

Since the encryption keys are wiped from the kernel memory during the unmounting, I am not excessively worried about an unencrypted swap partition.

Logout and Switch User

I often share the machine with another user by simply logging out from my account (without a shutdown or restart) before handing over the machine. It is therefore essential to unmount the encrypted volume automatically on logout. Xubuntu uses the LightDM display manager and I ensure unmounting at logout by adding an entry to /etc/lightdm/lightdm.conf

    session-cleanup-script=/etc/lightdm/my-cleanup.sh

Of course, I make sure that my-cleanup.sh includes cryptmount -u targetname. Other display managers would need different settings to be changed, but most of them would allow this facility.

Switch User is more problematic, and the safe solution is to avoid Switch User. I typically share the machine with others only after a logout. Very infrequently, I may choose to do a Switch User and share the machine with a trusted person because I do not want to interrupt a running job which takes a long time to complete. The minimal safeguard here is to rely on Linux file permissions and deny read access to anybody other than the owner of the filesystem. As long as the other person does not have root privileges, this provides a modest amount of protection.

Password files

Password managers store passwords on the disk in encrypted form. So if the only secrets that you want to keep away from prying eyes are your passwords, you can get by without any of the above steps. I adopt this approach for my less important passwords which I keep in the Gnome keyring which is protected by the login password and is automatically unlocked during login. This is very useful for cron jobs which cannot prompt for the password. The Gnome Keyring Security FAQ states that the key ring is automatically locked during hibernation and passwords are not written into the swap partition. This means that the unencrypted swap partition is not too worrying.

Nevertheless, I do not keep important passwords in the Gnome Keyring. For that, I use a separate password file in the encrypted file system. (I use KeePass with mono, but will probably shift to KeePassX when it comes out of beta.) This means that I need three passwords to get to access my important passwords: first to login to the computer, second to mount my encrypted volume and third to open the password manager. On the other hand, I need only my login password to get to my unimportant passwords sitting in the Gnome Keyring.

Encrypting Files and Folders

If I want some files or folders in the home partition to be encrypted, I simply copy them to the encrypted volume and the shred the original files. In case of folders and files which are required to be at specific locations in the home folder, I use a symbolic link. For example, if I want to encrypt my entire Firefox profile (including bookmarks, cache, cookies, history), I shutdown firefox, move ~/.mozilla to a folder in my encrypted volume and then create a symlink from there to ~/.mozilla. This of course means that I cannot run firefox at all without mounting the encrypted volume because the profile location is not writable.

One can get around this problem by using a different home folder. I create a folder .original inside my home folder. Then I can run the command HOME=/home/username/.original firefox. When this command is run the first time, firefox will create a new folder /home/username/.original/.mozilla and create a new profile inside that folder. During subsequent invocations of this command, firefox will simply run with this profile as the default profile.

Conclusion

The result of all this setup is that:

  • When I log in to the system, the encrypted volume is not available, but the rest of the file system including the home partition are available. Most commands can be run in this situation.

  • When I need the encrypted files, I issue the appropriate cryptmount command to mount the encrypted filesystem. This does not need root privileges.

  • The volumes are automatically unmounted before logout or hibernation. Since the encryption keys are wiped from the kernel memory during the unmounting, I am not excessively worried about an unencrypted swap partition.

With these techniques, I achieve a reasonable level of encryption without any significant loss of usability. The only cost is one additional password to access most of my files, and a third password to access my most important passwords. Even though all the passwords are rather long, I do not regard this cost as excessive. At the same time, I am aware that higher levels of security are possible, but I am not sure that the additional security is worth the extra cost.

Advertisements

3 thoughts on “Using Encryption

  1. Pingback: Digital wills and printable password vaults | Prof. Jayanth R Varma's blog on computing

  2. Pingback: OAuth2 authentication for offline email clients | Prof. Jayanth R Varma's blog on computing

  3. Pingback: Setting up a Raspberry Pi as a home file server | Prof. Jayanth R Varma's blog on computing

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s