Interview with Dustin Kirkland, Ubuntu Core Developer about encryption in Ubuntu

Ubuntu老大对eCryptfs的访问,

有很多有意思的问题.

 

Dustin Kirkland is an Ubuntu Core Developer, working for Canonical on the Ubuntu Server. His current focus is developing the Ubuntu Enterprise Cloud for the Ubuntu 10.04 LTS release, but previously he had worked on a number of Ubuntu features and packages, including Ubuntu's Encrypted Home Directories. He is also the upstream maintainer of eCryptfs, the cryptographic filesystem used to provide Encrypted Home Directories. That is fair enough reasons to ask him a couple of questions.

Slo-Tech: Since Karmic release, Ubuntu offers official support for eCryptFS. Could you give a short description of what is it and how does it work?

Dustin Kirkland: eCryptfs is a cryptographic filesystem that has been in the upstream Linux kernel since 2.6.19. It differs significantly from other Linux filesystem encryption options, such as encfs or sshfs which are handled by FUSE in user space. eCryptfs is a layered filesystem, encrypting each file individually, rather than encrypting the entire block device with something like dmcrypt or encrypted LVM. I believe that these features provide several interesting advantages, and provide a nice solution for Encrypted Home Directories. No passphrase is required at boot time. With the encryption happening in the kernel, the performance is better than user space solutions. The cryptographic algorithms are the same tried and tested functions used by the rest of the kernel. Incremental backups are possible using something like rsync, since only changed files will need to be backed up to remote storage (ie, you can not really do this with an encrypted block device). And there's no need to pre-allocate space for your encrypted data -- the encrypted files are just written to your underlying filesystem.

Slo-Tech: What protections do you use? How is encryption key protected in RAM (is it possible for an administrator to dump RAM into a file and recover a key)? Do you have any measures for decreasing vulnerability to 'off-line' dictionary attacks (like using a salt)? What about /tmp directory?

Dustin Kirkland: Well, personally, I always mount /tmp as a tmpfs in RAM. In Ubuntu, we wipe /tmp on every boot anyway. And most of my systems have more then 4GB of memory, so I simply add the following to /etc/fstab: tmpfs /tmp tmpfs rw

To your other question, hiding data from the administrator or root user of a running system is not the goal of eCryptfs at all. Rather, the goal of eCryptfs is to protect your sensitive data at rest as written to the disk. If you're looking for a solution to store data on a system and hide that from an administrative user, you would need some combination of a MAC system (such as SELinux or AppArmor), plus an encryption solution. I don't know of such a solution for Linux (nor do I think it's really that useful). If you have an untrusted root user, you have huge problems. That root user could just install a keylogger and sniff your keys in that way. Or just delete your data. Or tamper with it. Or do a million other malicious things.

The real goal of eCryptfs is to protect your data if your computer or hard disk is stolen. In this case, the thief will only see your encrypted data and would have to crack your keys to access your data -- even if this thief uses a LiveCD and accesses it as root in that live system.

In the default Ubuntu system, we generate a random 128-bit key. We "wrap" that long, random key with your login password. This is what allows you to simply enter your login password and have Ubuntu automatically mount your encrypted home directory. This also allows you to change your login password ad nauseum without having to re-encrypt all of your data.

Of course, this means that if your thief has access to your wrapped passphrase file $HOME/.ecryptfs/wrapped-passphrase, then he would probably attack your login password rather than attacking the 128-bit randomly generated passphrase.

You have two ways of protecting yourself here. First, you should always have a strong login password. That should go without saying. But if you're bothering to encrypt your home directory, it's certainly a good idea to use a long, complex passphrase. Secondly, you can store your wrapped-passphrase on removable media (such as a USB key or secure-digital card), and remove that media once you've logged in. Move your wrapped-passphrase file to that key and put a symlink in the expected location.

Slo-Tech: Do you have any plans for plausible deniability?

Dustin Kirkland: Not at all. If someone comes along with a good patchset for it, then I'd be willing to review and merge it. But I have no interest in plausible deniability.

I understand that there are some other solutions that support this, and it seems most people are interested in using this to "fool" airport security or border guards. That's just never been an interest or goal of mine. Sorry.

If you're in a situation where some government official wants your data, he/she can either get a search warrant for your real passphrase, or point a gun at your knee cap. No amount of software is going to help you in either case.

Slo-Tech: eCryptFS has already been offered in previous releases, but only for testing. However, there were some serious vulnerabilities found, like filenames were not encrypted. Have you done any security testing or the system has been reviewed by some experts?

Dustin Kirkland: I strongly disagree with your assessment. The lack of file name encryption was not a vulnerability. It was a wishlist/feature that was requested, and added in a newer release of the Linux kernel.

eCryptfs was initially developed by IBM's Linux Technology Center, mostly by Michael Halcrow. Tyler Hicks of IBM is currently the upstream maintainer of the eCryptfs kernel functionality (while I maintain the userspace). IBM has a long history of producing great Linux, Unix, and Mainframe filesystems, as well as pioneering modern cryptography. (FYI: I spent 8 years at IBM before joining Canonical.)

We at Canonical, as well as the Ubuntu community have tested eCryptfs extensively. Red Hat has put serious effort into testing and hardening it for RHEL5 (thanks, guys!). I ran a series of "challenges" on my blog, asking people to "crack" different eCryptfs setups, with the winner of each challenge receiving a small prize. These vectors have turned up a few interesting bugs. All of the security-critical ones were fixed immediately. The rest are low or wishlist priority bugs that we're still tracking.

Slo-Tech: What about key recovery (if someone forgets his or her password)? Is there any mechanism to backup your key?

Dustin Kirkland: We note repeatedly that the user must write down their generated passphrase and store it somewhere safely. I print mine out, and store it in my safe deposit box at my bank. I also store my wrapped-passphrase somewhere safe too.

Slo-Tech: What happens when you change your password? Is it possible that a copy of the previous key (or of its fragment) remain in the so called "free space"?

Dustin Kirkland: When you change your password we simply use pam_ecryptfs to re-wrap your wrapped-passphrase.

Slo-Tech: Is it possible to "link" user's eCryptFS key with other authentication modules, like LDAP, one-time passwords, etc. What if LDAP password is changed by administrator, how does this affect eCryptFS key?

Dustin Kirkland: I haven't tested Encrypted Home with LDAP yet, so I'm not sure how well (or if) this works.

If the administrator changes the user's password (without entering the user's previous password), they will break the user's automatic mounting of their home directory.

In this case, the user will need to login, and immediately re-wrap their wrapped-passphrase. They can use the eCryptfs utilities ecryptfs-rewrap-passphrase or ecryptfs-wrap-passphrase to do this. Admittedly this is inconvenient, but hopefully a corner case.

Slo-Tech: What about swap partition?

Dustin Kirkland: Encrypting swap is critically important for *any* system where encryption of any kind is performed -- not just eCryptfs.

If you use the Ubuntu CD installer to setup your system with an Encrypted Home Directory, your swap space will automatically be encrypted for you, using dmcrypt and a randomly generated key at boot time. This keeps you from being prompted for a passphrase at boot time, however, it will break hibernation support (suspend is unaffected).

Personally, I just don't use swap space at all. If I'm swapping to disk, then performance is really suffering, and I add more RAM to my system :-)

Slo-Tech: According to cryptsetup solution, eCryptFS has one great advantage - it is much more suitable for multiuser environments. However, there is still a problem of root partition. Do you have any plans to offer LUKS encrypted filesystems (for root partition for example) in future releases (Debian already has this option in their installer)?

Dustin Kirkland: Ubuntu does offer the same LUKS filesystem encryption in the Alternate and Server installers. Any Ubuntu user comfortable using the advanced installer is welcome to use it. Encrypted LVM + LUKS is mostly definitely a more complete encryption solution, encrypting the entire disk.

However, it has some disadvantages solved by our Encrypted Home solution. For one thing, Encrypted LVM + LUKS requires the user to enter a passphrase just to boot the system. We've worked hard to improve boot times on Ubuntu, but if it's stuck waiting for a passphrase before it can boot, those boot speed advantages are erased. This also doesn't work very well in server environments, where systems are located in a data center and must boot remotely, and unattended. Also, this boot passphrase needs to be known by all users of the system who might need to trigger a reboot. It's also impossible to incrementally backup the underlying encrypted data to remote storage. Finally, there are performance penalties for encrypting the entire system. There's plenty of non-sensitive data in /usr/bin and /lib, for instance, that really don't need to be encrypted/decrypted.

Slo-Tech: You are probably familiar of Evil Maid and other bootkit attacks. Are there any plans to mitigate that, like, boot partition will could be stored on external USB key, and root partition LUKS encrypted? Or some integrity checking of boot scripts?

Dustin Kirkland: I am familiar with these, and I have no plans to try and thwart them. I believe that these are logically solved by being more careful with your physical systems, rather than over-engineering a software system. A TPM could help with this, or, as you said, using a /boot on an external USB key. While there are a few people who might benefit from this, it's not something that would be generally used by Ubuntu users.

Slo-Tech: Palimpsest, new GNOME disk utility, now supports encrypted partitions. But unfortunately, only passphrase is supported, not keyfiles. (The same is true also for GNOME mount utility). Do you have any information if that would change in near future?

Dustin Kirkland: Sorry, I don't know anything about these.

Slo-Tech: One practical question - when I tried to create a new user in Ubuntu, there was no option for encrypted home directory. Why?

Dustin Kirkland: I assume you mean in the GUI.

From the command line, you can: $ sudo adduser --encrypt-home

And this will take care of that for you. It's just something that needs to be integrated into the GUI. I'm a developer on the Ubuntu Server, which has no graphical window manager, and I tend to avoid graphical utilities ;-)

Slo-Tech: Since Karmic, Ubuntu offers Ubuntu One solution. Could you explain briefly what is it about? (I am especially interested in technology behind? (Is it NFS?)

Dustin Kirkland: Ubuntu One is a remote cloud storage solution, tightly integrated with the Ubuntu desktop, perhaps similar to something like DropBox. All Ubuntu users are offered a small amount of storage for free (2GB, I believe), and users can optionally purchase more (up to 50GB, I believe) as an added service. It's quite useful if you use multiple systems running the Ubuntu Desktop, and you want access to your same data in each location. I don't know much about the implementation, but it's not NFS. It's some sort of FUSE based system.

Slo-Tech: Tahoe-LAFS is cloud filesystem, which offers encryption and great possibilities for recovery of data. Now binary packages are included in Karmic. Are there any plans for some GUI tools for creating private clouds (encrypted storages)?

Dustin Kirkland: I helped review Tahoe-LAFS and worked with the developers to get it into Karmic. As I said above, I generally avoid GUI tools, so I don't know about any such plans.

Slo-Tech: What about peripheral devices, like USB keys? Are there any plans to offer eCryptFS encryption layer for them also? What about Cryptsetup-LUKS support for them (with some GUI utility)?

Dustin Kirkland: I don't have any specific plans to integrate USB storage and eCryptfs. I'll be happy to review and merge patches, however.

I don't really work on Cryptsetup-LUKS, or GUI utilities, so I can't really speak to those plans.

Slo-Tech: Ubuntu does not have default backup utility. Do you plan to include it, and if yes, which one (SBackup, Grsync, time-drive (Duplicity GUI)? Which one would you recommend?

Dustin Kirkland: I just use cron + rsync + ssh. Bacula is Ubuntu's official network backup, recovery, and verification utility.

Slo-Tech: French police is now migrating to Ubuntu. However, they might have some special requirements, like hardware tokens and smart cards for storing encryption keys. How are this devices supported in Ubuntu?

Dustin Kirkland: I have not seen any such specific requirements. I know people who are using smart cards for their SSH and GPG keys in Ubuntu. I don't have a smart card reader, so I cannot speak from personal experience, though.

Slo-Tech: Thank you for your answers.