We introduced Encrypted Private Directories in the Ubuntu 8.10 release, using eCryptfs (an enterprise cryptographic filesystem in the Linux kernel) on $HOME/Private. This release helped "prove" eCryptfs, and helped us identify and fix a number of issues. This new approach to encrypted private data in Ubuntu provided a safe folder where users could store confidential information, automatically mounted at login, and unmounted at logout.
In Ubuntu 9.04, we retained the Encrypted Private Directory feature, but additionally offered Encrypted Home Directories to advanced users, through the alternate installer and a special boot parameter. This release generated quite a bit of interest in the feature and a healthy user community. Many, many thanks to the Ubuntu users and developers who used this feature, helping to file and fix bugs along the way.
So far in Ubuntu 9.10, we have:
- fixed a number of bugs and usability issues (changelog)
- provided AppArmor rules
- enabled the shell scripts for localization/translations
- and most importantly, set up encrypted swap in the installer if you enable home directory encryption
I believe Ubuntu now provides the most user-friendly personal data encryption solution in the industry.
So secure your data in Ubuntu! Get those Karmic home directories encrypted!
:-Dustin
p.s. I authored an article for Linux Magazine that should be published in an upcoming issue discussing the technology in much greater detail. Stay tuned!
Out of curiosity, do you happen to know the performance hit home directory encryption has? You've suddenly made me really interested :)
ReplyDeletequestion:
ReplyDeleteHow does autologin in gdm interact with ecrypted home directory feature? Does autologin stop and ask you for the de-encryption key if encrypted home is enabled? Also do you know what the decryption/mount time penalty is from a boot to idle desktop perspect?
I ask because the 10 second boot performance target for Karmic+1 which has been widely publicized specifically mentions autologin but doesn't mention encrypted home so I thought its worthwhile to make sure you talk to that scenario and calibrate expectations before drive-by reviewers turn on encrypted home looking for 10 second boot times and not finding them because of a password dialog or due to the additional time delay that is outside of the target specification for fast boot.
Thanks. I was waiting for this. Hopefully it also works with manual partitioning, where I have my own /home and swap partitions already set up. Or is that not possible (non-destructive for /home)?
ReplyDeleteDylan-
ReplyDeleteIn most workloads, the performance penalty is under 5%. Phoronix has published studies on eCryptfs in the past. I'll ping Michael Larabel and ask for a new one on Karmic.
:-Dustin
Tomasz-
ReplyDeleteIf you want to migrate to an encrypted home directory, you will want to follow the instructions I've previously published at:
* http://blog.dustinkirkland.com/2009/06/migrating-to-encrypted-home-directory.html
As for manual partitioning, that should not affect eCryptfs. I do strongly recommend you encrypt your swap space, if you're manually configuring swap.
:-Dustin
Jef-
ReplyDeleteAuto-Login and Encrypted-Home are incompatible features. See the screenshot above, where a radio button was cleverly chosen to allow one of:
* Log in automatically
* Require a password to log in
* Require a password to log in and decrypt home
Auto-login is intended for systems where data security is of a lower priority than quick access to the internet. I set up my mom's laptop, for instance, with Ubuntu and Auto-login. However, I also configured an Encrypted-Private directory, where she stores her most sensitive documents. This way, she can quickly boot her computer and get on the internet. When she needs access to her Private data, she enters a password and her $HOME/Private directory is mounted at that time.
An Encrypted Home might add a second or two (plus the password prompt) to a normal Ubuntu boot. Encrypted Home directories are most certainly *not* part of Karmic+1's 10-second boot target.
:-Dustin
Dustin:
ReplyDeleteThanks for the answers. One more follow up just for my own information.
How does password entry for decrypting home directories work for resume from suspend when the system was suspended. I'm trying to imagine how that will work when there was multiple users logged in to a desktop via fast user switching before the suspend..and my pea-sized brain is failing to come up with something plausible based on my existing understanding on ecryptfs tools.
-jef
-jef
Hi Dustin mate - thanks for working on this, it's so important in the environment I'm working in.
ReplyDeleteI think that we're going to have to draw more attention in Ubiquity to its availability though - you mention the radio buttons and that was the first clue I had it was there!
So does the encrypted swap work with hibernate now? I remember you saying that was your aim, but I have never seen an announcement saying that it is the case.
ReplyDeleteAlso, how is encrypted swap done? Random key? Key stored in a file on a non encrypted bit? User password (with obvious problems if different users are using the system ...)
Jef-
ReplyDeleteYour $HOME is only unmounted when you actually logout (where logout is defined as going through the PAM session close module).
Thus, neither suspending nor fast-user-switching has an effect on encrypted home.
While the home directory is mounted, you are relying on normal DAC permissions to protect your data. eCryptfs (and any other software encryption solutions) provide cryptographic protection of your data at rest.
:-Dustin
mish-
ReplyDeleteOur encrypted swap implementation uses a random key generated at each boot. We don't yet have hibernation working yet with encrypted swap.
:-Dustin
I usually set up my Ubuntu with a separate partition for the home directory. When I reinstall I just wipe the root partition and put a new Ubuntu installation on it, keeping my existing /home partition but recreating the users.
ReplyDeleteDoes encrypted home directories work with this way of doing it? Is there a way to connect already encrypted home directories?
Dustin:
ReplyDeleteCan you look into forcing the locked screensaver ui to engage on resume from suspend for encrypted home directories?
There is a potential weakness here in the model for laptop owners. Theft of a suspended system may encrypted data open for copying..if there is no password dialog required on resume from suspend.
Or barring a technical solution which forces a password UI to engage on resume can you make sure that is covered in the release notes. Worst case is someone assumes their data is safe even when the laptop is in suspend when its not.
-jef
Thanks for your work.
ReplyDeleteWhile I have used Linux for 10 + years, I am new to encryption. As I understand it, the decryption process takes place with the entering of your login name/password after installing fresh with home folder encryption. That being said, my question is does changing ones password cause any problems with decryption or should the password not be changed?
Maybe stupid question, but like to know ahead of time.
Fakeer-
ReplyDeleteHeh, yeah, off topic :-) Actually, I went back to Scotland last month, and had a blast again. I still need to write up that trip report. Thanks so much for the interest, and the reminder!
:-Dustin
Adam-
ReplyDeleteAs of 9.10, yes, that will work fine. All of the encrypted data is actually stored in /home/.ecryptfs/$USER/.Private, and all of the ecryptfs configuration data is stored in /home/.ecryptfs/$USER/.ecryptfs.
This was *not* the case in 9.04. There was some configuration data stored in in /var/lib/ecryptfs/$USER. I can't tell you how many people did not record their generated password as instructed and inadvertently wiped their /var partition with a reinstall.
As I said, we have rectified this situation in 9.10. And I have posted instructions on how 9.04 users could/should migrate to this setup:
* http://blog.dustinkirkland.com/2009/08/moving-your-encrypted-home-meta-data.html
:-Dustin
Jef-
ReplyDeleteI agree with you, that requiring a password on resume-from-suspend is security critical.
But this is the default behavior in Ubuntu (except where login-automatically is selected, and as discussed above, this is incompatible with encrypted-home).
Thanks for the concern and the keen eye for security.
:-Dustin
This comment has been removed by the author.
ReplyDeletebtberch-
ReplyDeleteNot a dumb question at all. Yes, we absolutely have taken care of this situation. Basically, your login password is only used to decrypt/encrypt a much longer, random passphrase which is used for the actual filesystem mounting.
So when you change your system password, we merely need to unwrap your mount passphrase file with your old password, and re-wrap it with your new password.
If you're interested in more of the details, please read:
* http://blog.dustinkirkland.com/2009/02/how-encrypted-home-ecryptfs-works.html
:-Dustin
Okay, so as long as you keep your generated password (passphrase?) and use it with your new account you should be okay?
ReplyDeleteIs that set up automatically during install or do you have to associate your new user account with the old data in some way?
Adam-
ReplyDeleteRight. As long as you have your generated passphrase, you can recreate everything else.
It should be setup automatically in the install, however, this is something I need to test.
Thanks,
:-Dustin
So does changing your password in the normal ways ( $ passwd, "About Me" dialog) update the ecryptfs passphrase file, or is that a manual process you have to do separately.
ReplyDeleteIf it is a separate process, could you write a blog post explaining how to update the passphrase file?
Adam-
ReplyDeleteBoth of those methods should work as expected.
The only one that's known not to work is when root forcibly changes another user's password, since root is not prompted for that user's old passphrase, the rewrap doesn't work.
In this case, the user will need to manually run ecryptfs-rewrap-passphrase, or run ecryptfs-wrap-passphrase with their recorded key.
I don't think a blog post is necessary. Just see the manpages.
* http://manpages.ubuntu.com/manpages/karmic/en/man1/ecryptfs-rewrap-passphrase.1.html
* http://manpages.ubuntu.com/manpages/karmic/en/man1/ecryptfs-wrap-passphrase.1.html
:-Dustin
Thanks! I think I feel confident enough now to enable it when Karmic comes.
ReplyDeleteQuote: "I believe Ubuntu now provides the most user-friendly personal data encryption solution in the industry."
ReplyDeleteQuote: "Your $HOME is only unmounted when you actually logout (where logout is defined as going through the PAM session close module).
Thus, neither suspending nor fast-user-switching has an effect on encrypted home.
While the home directory is mounted, you are relying on normal DAC permissions to protect your data. eCryptfs (and any other software encryption solutions) provide cryptographic protection of your data at rest."
It doesn't make much sense for laptop-owners, if data is not encrypted after suspend/hibernate (which I use mostly instead of shutting down / logging off for fast usage of my computer) .
Fedora allows full disk encryption with their installer using LVM - even after suspend/hibernate data is encrypted and one needs a password to decrypt. This scenario is also compatible with auto-login.
What is the advantage of ecryptFS over the encryption with dm-crypt / LVM?
Cool. Something to look for when I upgrade next month. Thanks for the heads up.
ReplyDeletejajaja-
ReplyDeleteUbuntu, like Fedora, also supports dmcrypt + LVM in the installer.
And while I think dmcrypt + LVM is an excellent solution in some scenarios, I think eCryptfs + encrypted home has a couple of significant advantages over dmcrypt + LVM...
dmcrypt + LVM is not acceptable in many server environments, or anywhere a machine is expected boot unattended. Systems such as this in a data center will just hang, shortly after the bootloader, waiting for someone to walk by and type in a password. In the eCryptfs + Encrypted Home world, we require a password at login time, rather than to boot the system.
Secondly, dmcrypt + LVM encrypts *everything*, including /usr, /lib, and so on. In some cases, perhaps this is what you want. But in many cases, this is encryption overkill. How much secret data do you really have in /usr or /lib? I'll admit that super secure, really paranoid people might prefer encrypting everything (particularly /var), but I don't believe that's the case for most laptop users, and you pay a performance penalty on every file read or written.
Third, in multi-user systems, each user's $HOME is encrypted with different keys. This provides some subtle separation of the encrypted data. In the dmcrypt + LVM case, all users on the multi-user system would need to share the same key to boot the encrypted system.
Finally, from an incremental backup standpoint, eCryptfs provides a tremendous advantage. Each file is independently encrypted. Thus a user can rsync their $HOME/.Private directory to remote storage, only sending the files that have changed. This is really, really impractical with LVM. You can't really rsync /dev/sda3...
In terms of suspend/hibernate, as long as you require a passphrase to log back into your system on resume, your data is secure, even though mounted. How else is someone going to access your data? I'm interested to know...
:-Dustin
@Dustin
ReplyDeleteIf I from a USB-Stick or a Boot-CD or just take out the harddrive of the hibernated machine and plug it in a different machine, isn't my data in $HOME readable if it's mounted?
Or maybe I don't get the concept?
jajaja-
ReplyDeleteFirst of all, at least with Ubuntu 9.10, your swap is going to be encrypted, which means that hibernation is not going to work.
So, yes, you could move that hard drive elsewhere. But if the swap is encrypted, and you don't have the swap encryption key (in Ubuntu, it's randomly generated at boot), then the data is inaccessible.
In the suspend case, you won't get anything out of moving the hard drive, as the data wasn't moved to disk (it stayed resident in RAM, which requires power to preserve stat).`
:-Dustin
Thanks for the reply. I did a fresh install from alpha 3 to alpha 5 to try out the install of the encrypted home. Nice feature. Booting up to the login screen seemed to be a little longer, but I wouldn't think that would be the encrypted home file. As for logging in, it only takes 10 to 15 seconds longer. I been using karmic on a toshiba nb205 netbook and would expect things to go slower on it.
ReplyDeleteThanks again
Quote: "First of all, at least with Ubuntu 9.10, your swap is going to be encrypted, which means that hibernation is not going to work."
ReplyDeleteI don't think that is a step in the right direction (even though hibernation is quite unreliable with Ubuntu and fails every 2nd or 3rd time with a "not enough swap").
Having to shutdown and reboot every time you're disconnected from power for a while is a big hassle.
jajaja-
ReplyDeleteI respect your opinion, though I disagree.
I find suspend-to-ram adequate for most of my needs, which works very, very well on my Intel-based Thinkpad
And the boot speed has improved so much in Karmic that I now just poweroff instead of hibernating.
:-Dustin
On my Dell suspend-to-ram never worked.
ReplyDeleteWith an older battery, I wouldn't rely on suspend-to-ram if you're e.g. on a longer plane trip.
Only hibernation guarantees zero power consumption...
And poweroff.
ReplyDelete... which requires rebooting, opening your documents again, scrolling to the point in your document where you were before, etc. pp. (session saver is NOT an adequate replacement for waking up from hibernation).
ReplyDeleteAnd in other OSes a wake-up from hibernation takes 5 -10 seconds (depending on your RAM)...
jajaja-
ReplyDeleteI invite you, then, to skip over the encrypted-home option. It's not required, and it's not even default. Use dmcrypt+LVM to encrypt your system, if you so wish.
Many people will, and do find Ubuntu's Encrypted Home useful.
I have no interest in continuing to respond to your trolling.
:-Dustin
will do. sorry that you feel offended.
ReplyDeleteDustin, I clicked on the link to your changelog and it says the page cannot be found.
ReplyDeleteSurfin-
ReplyDeleteThanks. Link fixed.
:-Dustin
If I encrpyt my home folder does that mean all the files are still encrypted when they are uploaded if I'm using Ubuntu One?
ReplyDeleteDill-
ReplyDeleteOnly if you upload the encrypted version of the file.
Personally, that's what I do. I sync my $HOME/.Private directory to Ubuntu One, such that my privacy is preserved there. There are a few drawbacks, though. If you use the web interface to browse your files in Ubuntu One, you only see encrypted filenames and data. That's okay by me, though. I don't use the web interface that much.
:-Dustin
I don't have ubuntu one yet, so sorry if it's a dumb question: Isn't the Ubuntu one folder within the home folder? If so, would the default behavior be that the data remains encrypted when uploaded by ubuntu one if I have my whole home folder set to be encrypted?
ReplyDeleteJustin, how about to further discuss about a perfect partitioning scheme in Karmic? Maybe covering topics like LVM, encryption, separating personal data etc.
ReplyDeleteIt will be great to have it as a guide to the next upcoming release.
Best,
Igor Gomes
Hi Kirk,
ReplyDeleteI'm using Karmic with encrypted home directory. So I wasn't able to see my desktop after I had changed my login password (Through Users and Groups).
I tried getting it to work with the the "ecryptfs-wrap-passphrase ~/.ecryptfs/wrapped-passphrase" command. This also didn't work. I tried many things, but to make a long story short...
Looks like I messed up my unwrapped Mount Passphrase, since when I unwrap it now it shows my current password instead of the initial phrase (that I also backed up after installation)
Now my question: Is it possible change the unwrapped mount phrase back to what it was using my backup? What command would I use for that?
You can fix your setup with ecryptfs-rewrap-passphrase.
ReplyDeleteYou should really use either passwd from the command line, or System->Preferences->About_Me to change your password.
I think Kees *just* fixed the bug you mentioned.
:-Dustin
Hi Dustin,
ReplyDeleteFirst of all sorry for mixin your name up. Well I tried ecryptfs-rewrap-passphrase and the command was successfull.
But I still cannot mount my home dir. When I do ecryptfs-unwrap-passphrase it still shows "my login password" as my passphrase instead of the "987324072749032075" which I recorded as my mount passphrase after installation. (Or am I getting something wrong here?)
I guess everything should be fine if I get my recorded passphrase back in there.
How can I achieve that?
Thanks
Felix
Felix-
ReplyDeleteRight, so if you've recorded your long, random passphrase, you should be able to just run 'ecryptfs-wrap-passphrase' and store that in $HOME/.ecryptfs/wrapped-passphrase. That should get you going ;-)
:-Dustin
Thanks Dustin that did the trick.
ReplyDeleteAfter reading all the answers and questions from the people here has answered *all* my concerns.
ReplyDeleteYou should really put them in a FAQ, because your detailed explanations are gold. Sorry to be somehow off topic. But I wanted to thank you Dustin for your contribution.
There is very nasty installer user experience bug related to encrypted home - indicator hangs for several dozens of minutes:
ReplyDeletehttps://bugs.launchpad.net/ubuntu/+source/user-setup/+bug/432422
Also the encrypted home has serious performance issues:
http://www.phoronix.com/scan.php?page=article&item=ubuntu_910_encryption&num=3
I opened a "tuning thread" related to tuning the performance at ubuntuforums.org:
http://ubuntuforums.org/showthread.php?p=8084140#post8084140
The installer is clearing the swap space, which is absolutely necessary to secure your setup.
ReplyDelete:-Dustin
Mikko,
ReplyDeleteI find your complain very misleading to people reading this blog. You should mention what has been tested there! If you read the hardware tested, it was a Dell netbook with an Intel Atom N270 CPU.
What do you expect? It's an Atom CPU for God's sake! Test on a Core 2 duo to have a more representative benchmark.
I'd like to see how this Netbook performs with Windows 7 Ultimate and bitlocker, or full disk encryption. Probably not that well either. The full-disk encryption test made a year earlier by the same people was on AMD Athlon 64 X2 4200+ AM2. So we are comparing apples and oranges.
I have tested the latest Karmic Beta with home encryption on my Core2 duo and I'm very happy with the performance. I have also tried with full-disk encryption and with encrypted home I perceive a faster booting.
So please instead of saying "Also the encrypted home has serious performance issues"
better say "encrypted home is not really suitable for netbooks or low-end CPUs".
Dustin, what about this? I have an idea:
Before offering the menu with installation options, run a quick CPU benchmark. If the test detects a slow CPU and the user selects home encryption, issue a warning that it might be too slow. If the CPU test is really discouraging, disable the option altogether or suggest Private folder instead.
After all, most people use netbooks for browsing, where encryption should have a minimal effect. Who would run an SQL server on a netbook? And if you are afraid of performance loss, just have the Private directory separated from your home.
I really don't see a problem with the current implementation. All the contrary, we have one more option to the set
- No encryption
- Home encryption
- Private directory
- Full disk encryption
By the way, is the Private directory gone or offered by the alternate install CD? I'd keep it as an option for advanced users.
The only thing missing is a container-based home encryption with dynamic size, just like MacOS X. A fixed size container based, like Opensuse, is in my opinion not that good.
At the moment, I think the major downside to eCryptFS is its lack of Windows drivers. You can't access your files from Windows. But neither can you with Luks+LVM :-(
Quote: At the moment, I think the major downside to eCryptFS is its lack of Windows drivers. You can't access your files from Windows. But neither can you with Luks+LVM :-(
ReplyDeleteI think that's not correct:
http://www.freeotfe.org supposedly supports LUKS and LVM, see http://www.freeotfe.org/downloads/FreeOTFE_PC5_10_PDA5_10.pdf on Page 99.
how do you turn off home drive encryption??
ReplyDelete@jajaja
ReplyDeleteI wish you were right. But all the documentation says is that it should work, as long as other applications stack on top of it. I couldn't find an Ext2/3 file manager that supports LVM and recognizes volumes decrypted by freeotfe. I couldn't find references to anyone who succeeded doing this either. This was about 4 months ago.
Just found this great blog. Thanks for it.
ReplyDeleteI still have some questions. I'm using Linux for some years now (mainly Arch Linux) but never dived into the world of encryption.
On my Netbook I recently installed Ubuntu 9.10. by just wiping my / and leaving /home as it is.
I was interested in the encryption thing so I marked the appropriate option during installation.
First, I didn't know about encrypted swap and hibernation so I changed my fstab back to a "normal" swap. I only commented the encrpyption line so can I undo this by just uncomment it?
I'm also not sure if my /home is encrypted although I marked this option. Booting from a Live USBDrive allows me to read my home using nautilus as root.
Did I miss a step or is encrpytion only possible with fresh /home?
Thanks in advance!
Thomas-
ReplyDeleteIf you can read your home directory contents from a LiveCD without entering a password, then yes, you missed a step. Your home directory is not encrypted.
You should be able to just uncomment that line again in your fstab (and remove any other non-encrypted swaps you might have) to re-enable encrypted swap.
As for migrating your non-encrypted $HOME to an encrypted $HOME, you certainly can do this by following the steps at:
* http://blog.dustinkirkland.com/2009/06/migrating-to-encrypted-home-directory.html
:-Dustin
Hi Dustin,
ReplyDeletethanks for the swift reply. Ok, so an already existent home isn't encrypted automatically.
Thanks for the link - I'll try (fortunately there's already a hint for using rsync with an encrypted home in the comments)
Thomas
@Dustin
ReplyDeleteYou said
"
In terms of suspend/hibernate, as long as you require a passphrase to log back into your system on resume, your data is secure, even though mounted. How else is someone going to access your data? I'm interested to know...
"
Suppose your system is hibernating. That mean the full state of the machine is sleeping on disk (full copy of the ram). Including the current crypt/decrypt key.
I do not want to explain here use how to use this fact but it is clear that crypto-security is broken.
For suspend case it may be more complex, but feasible as well. One best idee may be to find a mean to go from suspend to hibernate.
Another method would be (for example if disk is a sata disk) to access to the sata socket (the pc still suspended), plug out the disk, plug it to another PC (sata is hot pluggable) and insert some backdoor. Then plug it back.
I'm considering syncing the private files to Ubuntu One, as you are doing. Do I have to log out to get the ecrypt fs to sync my data to the ecrypted store? Can I do that manually? (I normally leave this machine logged in for weeks at a time). Thanks, cheers, W
ReplyDeleteI too am interested in sync'ing my .Private directory to the cloud. Is it safe to write to the .Private directory while it's mounted?
ReplyDeleteI did some quick experiments: with a file from the Private directory open in emacs, I deleted the corresponding file in .Private and things didn't work too well after that.
Wouldn't syncing the .Private directory to Ubuntu One potentially do what I did in my experiments?