Ubuntu’s Encrypted Home Directory: A Canonical Approach to Data Privacy

How can users protect themselves from the loss of important data when a computer goes missing? Well, the latest release of Ubuntu makes this not only possible, but frighteningly easy!

A friend recently quizzed me about the Encrypted Home Directory feature in Ubuntu, but unfortunately his questions were not due simply to his naturally inquisitive nature.

A week earlier, he was en route to a Free Software conference and boarding a train in Europe after an overnight flight from the United States. In a flash, one thief created a diversion while his partner-in-crime stole my friend’s laptop case.

While not particularly happy about losing his computer, he was far more distraught at his potentially compromised data which included encryption keys, stored website passwords, personal finance information, confidential documents… everything.

This could just as easily happen to anyone. Do you travel with a laptop that contains private information? If so, what is of more value – the physical hardware itself, or the data? There must be a way to protect this highly sensitive material. Fortunately, there is!

Linux and Encryption

Linux users actually have a suite of data encryption options at their disposal. GPG (GNU Privacy Guard) can be used to provide encryption for email and individual files. Whole-disk encryption is available using a combination of LUKS (Linux Unified Key Setup) and dm-crypt (the device mapper encryption module). These two technologies represent merely the most visible tip of the iceberg.

While dozens of file encryption options exist for Linux users, this article focuses on Ubuntu’s use of eCryptfs, the Enterprise Cryptographic File System originally developed in the IBM Linux Technology Center, and now co-maintained with Canonical’s Ubuntu Platform Team. Users of Ubuntu 9.10 can optionally configure eCryptfs to automatically mount and decrypt their home directory at each login.

eCryptfs is a stacked file system in the Linux kernel. Users mount a directory in one file system on top of another. Content read from, and written to, the upper directory exists as decrypted content in memory and is seamlessly accessible to the user and applications.

Files are written to disk in the lower directory as atomic, encrypted units. File names and directory names are encrypted with a single, mount-wide fnek (file name encryption key).

Each encrypted file embeds a unique, randomly generated fek (file encryption key) in the header, wrapped with a separate, mount-wide fekek (file encryption key, encryption key). Keys are managed by the Linux kernel keyring and the encryption is provided by the common ciphers in the kernel.

Why eCryptfs?

Ubuntu’s initiative to utilize eCryptfs originated in the Ubuntu Server Team’s desire to provide an encrypted, private space for administrators without breaking unattended reboots. Typically, full disk encryption blocks the unattended boot process while waiting at a password prompt during start up. This is highly impractical for servers in data centers. Using an eCryptfs PAM (Pluggable Authentication Module) however, the system can load the necessary keys and mount the home directory at login, rather than during boot time.

Per-user unique keys and mounts with eCryptfs can provide additional data privacy and risk-mitigation among administrators and users on a multi-user system. Some users may have an encrypted home, while others may not, and each user’s encrypted home utilizes unique private keys. System resources are focused on encrypting and decrypting specific private data in /home, rather than gigabytes of stock system binaries and libraries in /usr, /lib, and elsewhere.

The eCryptfs layered file system approach also eliminates the need for a dedicated partition, sparse file, or preallocated disk space for the encrypted data. eCryptfs files are written to the administrator’s chosen underlying file system with the total disk capacity available. Since each encrypted file is written to disk as an atomic unit, users can perform per-file incremental encrypted backups to remote storage – something that is impractical and dangerous with block device encryption solutions.

Ubuntu 8.10 and Encrypted Private Directories

Ubuntu 8.10 introduced eCryptfs to mainstream Linux users in the form of an innovative, optional security feature – an Encrypted Private Directory within a user’s home directory. Users of Ubuntu 8.10 (and later) can configure an Encrypted Private Directory by simply running:

$ sudo apt-get install ecryptfs-utils
$ ecryptfs-setup-private
Enter your login passphrase:
Enter your mount passphrase [leave blank to generate one]:
************************************************************************
YOU SHOULD RECORD THIS MOUNT PASSPHRASE AND STORE IN A SAFE LOCATION:
3770637d136fa485d22e36ab8c94afb1
THIS WILL BE REQUIRED IF YOU NEED TO RECOVER YOUR DATA AT A LATER TIME.
************************************************************************
Done configuring.
Testing mount/write/umount/read...
Testing succeeded.
Logout, and log back in to begin using your encrypted directory.

When the user logs into the system, either graphically or on the command line, the encrypted mount is established:

/home/foo/.Private on /home/foo/Private type ecryptfs (ecryptfs_sig=009d8073058734f2, ecryptfs_fnek_sig=d27234f4a296af68, ecryptfs_cipher=aes, ecryptfs_key_bytes=16)

This user can now read and write data in /home/foo/Private like any other directory, with any application. The encryption and decryption happens transparently, on-the-fly. The encrypted data on the physical disk actually lives in /home/foo/.Private. When the user logs out, /home/foo/Private is unmounted and his data is only visible as encrypted content in /home/foo/.Private.

This provides an interesting bit of on-demand security for systems that use the GNOME or KDE auto-login feature. Such users can boot directly into their desktop environment without entering a password, but then consciously store their most confidential information cryptographically in ~/Private, which requires a password to access.

Ubuntu 9.10 and Encrypted Home Directories

Keeping track of what is and is not stored in ~/Private can become impractical if you consider most of your home directory data confidential. But Encrypted Private Directories in Ubuntu 8.10 were well received. The new feature did not introduce any insurmountable problems and has generally been very stable.

For these reasons, Ubuntu 9.04 extended the Encrypted Private Directory feature to cover entire home directories. Ubuntu’s Encrypted Home Directory feature protects the entire contents of home directories with automatic, seamless, on-the-fly encryption. Ubuntu’s traditionally excellent user experience is maintained with a minor performance impact for most workloads and tight integration with the existing Ubuntu Desktop and Server login prompts.

Encrypted Home Directories were only offered to advanced users of Ubuntu 9.04, but as of Ubuntu 9.10, the option is available in all desktop installations. This feature is similar in feel and usability to FileVault on Mac OS X, and is the first of its kind in a major Linux desktop distribution.

How does it Work?

Comments on "Ubuntu’s Encrypted Home Directory: A Canonical Approach to Data Privacy"

desnotes

Seems like a much better method than the encryption method used on my work laptop. After every reboot, I need to type in a password in addition to the login password.

Reply
    ronocdh

    If it’s using full-disk encryption, then you’re fine not using a login password. That way you still have to type your password in during a reboot, but only once, and that very quickly after boot.

    Reply
davidmintz

Sounds like a wonderful idea for laptops that travel, but kind of a PITA, e.g., for a desktop at home that you like to access frequently via SSH because, as the article says,

\”if the home directory is not already mounted then automatic desktop logins, ssh public key authentication and cronjobs that require access to data in $HOME are not possible. This issue can be worked around by disabling automatic unmount (remove $HOME/.ecryptfs/auto-umount), logging in, and establishing the mount at some point prior to public key authentication or cronjob execution. However, the home directory will only be unmounted at shutdown, or when ecryptfs-umount-private is invoked directly.\”

I don\’t completely understand the workaround but, again, it sounds kind of painful.

Reply
ionutg

Shouldn\’t be that difficult to combine with ssh remote logins if one uses the pam_mount module. I haven\’t used pam_mount with eCryptfs yet, but it should be possible according to

http://wiki.archlinux.org/index.php/System_Encryption_with_eCryptfs

Reply
bobberm

Looks like a recipe for disaster. I have had a bad experience with encrypting a drive, the algorithm appeared to have a bug, it was encrypted allright, but impossible to recover. If you try this, you MAY want to take that backup of your unencrypted data you made and keep it in a safe somewhere. Encryption algorithms are complicated and sometimes fail. Bobby B.

Reply
blanik

Just how secure is Ubuntu\’s new encrypted home directory system, when it is installed using Ubuntu\’s default configuration ? Your article includes a nice explanation of how you can boot the PC using a Ubuntu LiveCD, and then recover the data.

Am I missing something here ? To me it looks like a \”bad guy\” who wanted to steal the confidential information stored on the notebook computer that he has just stolen could have access to your encrypted home partition data in a matter of minutes….

Your article suggests that you can make it harder for the bad guy by implementing two-factor authentication – \”simplymove $HOME/.ecryptfs/wrapped-passphrase to removable media (such as a USB key or flash disk)\”.

Yes this approach does put the wrapped passphrase on a USB Key or similar device, but all of these security measures are still reliant upon the thief not getting hold of the USB Key at the same time as the Notebook Computer is stolen. What are the odds that the User will end up storing the USB Key in the Laptop Bag, just so that they make sure that they always have the USB Key with them when they travel.

The concept of using the USB Key also raises a potential personal safety issue for the Computer User. If the thief has found a victim using a notebook computer, at say a coffee shop, the thief will also note that when the user shutdown the PC prior to leaving the Coffee Shop, that the user unplugged a USB Key and hung it around his neck or somewhere else on their person. Odds On – the thief, when he/she makes a move to distract you and steal your notebook computer, will also do a pick pocket job on your USB Key……

So – am I missing something ? Or does Ubuntu\’s new encrypted home directory functionality only protect your data against an honest thief, who knows nothing about Linux, and ideally who wouldn\’t also think to steal your USB Key at the same time they steal your Notebook computer ?????

Reply
webmanaus

To recover your data, you will require the encryption key which you were instructed to \”write down, print, etc and store in a *secure* location\”. So simply booting from a live CD doesn\’t give you anything more than access to the encrypted data (ie, useless).

Secondly, a lot of people store data on USB keys, when they shutdown, they remove the USB key and drop it in:
1) Laptop bag
2) Pocket
3) Keyring/etc/whatever

Unless you are being specifically targeted (ie, the thief knows where you work, and knows you have access to the data they are after) then they would only be interested in the re-sale value of the hardware. As such, the re-sale value of a USB key is negligible and so definitely not worth any additional risk.

The point of the above would be to ensure that the thief and/or recipient/purchaser of your laptop can\’t accidentally stumble across the fact that they have complete access to \”Some Corporate Server Farm\” or \”Some Users\” bank account details complete with passwords, or personal home movie collection, or whatever…

PS, the truly serious thief targeting the theft of a specific users laptop will go after the USB key, probably won\’t be concerned with threatening your safety, etc and if all else fails, will use automated decryption tools to access your decrypted data in 6 months or however long it would take. (BTW, anyone know how long it would take to brute force this type of encryption?)

PPS, This is definitely something I will be enabling on my laptops as soon as I install Ubuntu 9.10 which I am eagerly awaiting!

Regards,
Adam

http://www.websitemanagers.com.au

Reply
justwally

It is important to note that the mere presence of an encrypted volume or directory is enough of a reason (in and of itself) for your computer to be indefinitely seized in the US. Just so everyone is aware of this. \”Encryption\” _IS_ the probable cause in these instances.

Reply

    @justwally: This is not true, either legally or in practice. Millions of individuals carry around encrypted folders, partitions and entire drives for many reasons. Anyone carrying HIPAA data, for example. It is not a basis for any search or seizure. Please do not spread disinformation on this point, as it has a chilling effect on the decision to encrypt.

    Reply
dragonwisard

@justwally: If we can advocate for encryption to become the default option in common operating systems (which I don\’t think is unreasonable in today\’s climate of data breeches and privacy concerns) encryption would no longer be grounds for probable cause.

Reply
pannsoln

I\’ve just tried the recovery, and the method described doesn\’t work. You need to create the directories in /mnt (that\’s not a problem).

But sudo chroot /mnt gives the error:
cannot run command \’/bin/bash\”: No such directory.

And su – foo (using the correct name for the user) also gives an error.

And ecrypt-mount-private says:
Encrypted private directory is not setup properly.

I have tried everything that I can think of, but to no avail. My /home is mounted on a separate directory, so I also have tried variations to cope with that, but it still doesn\’t work!

It seems impossible to find anywhere that documents how to recover an encrypted directory!

Reply
perfmonk

Mr pannsoln,

If you want to use a chroot, your should mount the root \”/\” inside your mount point. Since, from the jail, you wont see any directory from your $PATH… Thus you can\’t see /bin/bash either.

if you want to chroot inside /mnt, before do #: mount -o bind / /mnt
and create a mount point for any other mount that you want accessible from inside /mnt and mount them the same way.

The problem is not Ubuntu. It\’s just a little misunderstanding.

Regards,
BT

Reply

Thanks for this, very helpful! I believe there is a small error in the terminal commands. I think this line:

sudo ln -s /home/.ecryptfs/$USER/.ecryptfs /home/$USER.new/.ecryptfs

Should actually read:

sudo ln -s /home/.ecryptfs/$USER /home/$USER.new/.ecryptfs

Reply

Hi! I realize this is kind of off-topic but I had to ask. Does managing a well-established website such as yours
require a lot of work? I’m completely new to writing a blog however I do write in my journal every day. I’d like to start
a blog so I will be able to share my own experience and thoughts online.
Please let me know if you have any suggestions or tips
for brand new aspiring blog owners. Appreciate
it!

Reply

Once the home directory is encrypted can I still run programs like sbackup to make unencrypted backups?

Reply

    can I still run programs like sbackup

    yep.

    if you encrypt the home, and log in, it will be unencrypted to your eyes. you can do as you wish with the files.
    i use a Private folder with manual mount so even logged in, my stuff is encrypted unless i change it.

    when power is off your setup will protect your home folder from view, mine will only protect the Private folder. my only wish list contains multiple folders.

    Reply

Leave a Reply to green sleeves Cancel reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>