gotgenes said...
Very cool. So does this mean there's now a separation of a user's password from the user's decryption password? This was an issue brought up in your previous post--oftentimes we want our encrypted data passphrase to be significantly longer than our user passphrase.
Yes. And we provided that same separation in Intrepid as well. Let me explain in better detail how this feature works...
When you login, the pam_ecryptfs module takes your login passphrase (which is usually pretty short, and easy to remember), and symmetrically decrypts the file ~/.ecryptfs/wrapped-passphrase, which will yield your mount passphrase.Your mount passphrase is a randomly generated 128-bit key. This is very hard to remember, and rather hard to guess. 2^128 is a big number!
340,282,366,920,938,463,463,374,607,431,768,211,456
unique passphrases
unique passphrases
This mount passphrase is salted, hashed 65536 times using sha512 (i.e. key strengthened), and loaded into your kernel keyring. In eCryptfs terms, the salted, hashed passphrase is your "file encryption key, encryption key", or fekek.
New for Jaunty (and the upstream 2.6.29 kernel), we have encrypted filenames too. In this case, the mount passphrase is salted with a different value, hashed 65536 times using sha512, and also loaded into your kernel keyring. This second key is your "filename encryption key", or fnek.
Now, every time the kernel encounters an encrypted filename in your encrypted home directory, it is decrypted using your fnek and presented to you in plaintext.
To read/write encrypted data from/to a file, your fekek is used to decrypt the "file encryption key", or fek, which is embedded in the header of the file. This embedded fek is unique per file! This means that two files, with the exact same contents, will produce two completely different encrypted files, which helps thwart known-plaintext attacks.
Does that explanation help?
:-Dustin
How about logging in without mounting the encrypted folder?
ReplyDeleteHow about plausible denyability mounting? (Mounting with an alternative password to show another set of files)
Ideally one should be able to use one of multiple passwords to open multiple file storage areas and there would be no way to determine how many areas there are without having all the passwords.
Am I reading this right that it is your login password that protects the wrapped-passphrase?
ReplyDeleteIf so we are still at a place where a short passphrase protects the long one.
chuckfrain-
ReplyDeleteTwo-factor authentication involves:
1) something you have
2) something you know
See:
* http://en.wikipedia.org/wiki/Two-factor_authentication
In this case, your login passphrase is something you know.
And your ~/.wrapped-passphrase file is something you have.
Some eCryptfs users increase the overall security of their system by storing their wrapped-passphrase file on some removable media, such as a USB key.
:-Dustin
aigarius-
ReplyDeleteIf you want to log in without mounting your entire encrypted home directory, I suggest that you look at eCryptfs encrypted-private support. You can setup your system to only encrypt data in ~/Private, and you can configure whether you want it automatically mounted on login.
eCryptfs does not currently support plausible deniability.
:-Dustin
The biggest problem I have with these schemes is that they only work with password authentication. My laptop (ThinkPad T61) has a fingerprint reader so I can login using that, but then it provides no way of doing the encrypted home directory other than also demanding a password, defeating the purpose of the fingerprint authentication. (And just to make life even more fun, thinkfinger stores the fingerprint data in your home directory!)
ReplyDeleteThe whole Gnome keyring insisting on a password was a pain for a long time until they allowed empty passwords.
Hi Roger-
ReplyDeletePlease see:
* https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/255799
The prevailing opinion from security professionals is that fingerprints are perhaps a good replacement for usernames. However, they're really not a good replacement for passwords.
Consider your laptop... How many fingerprints of yours are there on your laptop right now? As such, it's about as secret as your username. You don't leave your password on your spacebar, or on your beer bottle :-)
This wikipedia entry (although it's about Microsoft Fingerprint Readers) is pretty accurate:
* http://en.wikipedia.org/wiki/Microsoft_Fingerprint_Reader
:-Dustin
Dustin, let me start this post saying that I have not delved deeply into eCryptfs. I may be missing something that is covered elsewhere more in depth than the reading I have done on the topic. Here's what I don't understand about your argument.
ReplyDeleteWhat I have (~/.wrapped-passphrase) is protected by what I know (login password).
How is gotgenes' premise that the encrypted data is not separated from the login password? Yes I can put the key on a thumbdrive but I'd argue that most users are not going to do this considering the small percentage that will use encryption for their data to begin with. At the end of the day the 128-bit key is still protected with a [arguably] weaker key, the login passphrase [short, easy to remember].
What is the difficulty of offering an option to protect the 128-bit key with a different passphrase from what you use to login?
Hi Dustin,
ReplyDeleteI remebered you exlained that one of the biggest issue for you in the intrepid version to encrypt whole home directory is that the passphrase is in ~/.wrapped-passphrase.
From your previous comment, it seems to be still the case. So, how do you do? Do you put an exception to not encrypt this specific file and have it accessible, even when ~ is not decrypted yet?
Dustin,
ReplyDeleteIf you had a backup of the .wrapped-passphrase on removable media, perhaps you could have an option to delete the .wrapped-passphrase file stored on your computer if the login passphrase is entered incorrectly x times?
Would that improve security if the computer is stolen? Or do you need the correct login passphrase to be able to delete .wrapped-passphrase?
chuckfrain-
ReplyDeleteSure, please see the manpage ecryptfs-setup-private(1):
* http://manpages.ubuntu.com/manpages/jaunty/en/man1/ecryptfs-setup-private.1.html
Refer to the -w, --wrapping option:
-w, --wrapping
Use an independent wrapping
passphrase, different from the
login passphrase
You can certainly set it up this way. But this will not be the Ubuntu-default mechanism.
:-Dustin
didrocks-
ReplyDeleteGreat question!
In both your mounted, and unmount home directory, $HOME/.ecryptfs is a symbolic link to /var/lib/ecryptfs/$USER
As such, this is where your wrapped-passphrase actually lives.
In my case, where I want to improve the strength of my 2-factor authentication, /var/lib/ecryptfs/$USER is actually another symlink to some removable media.
:-Dustin
meastp-
ReplyDeletePerhaps, but I don't think you would be able to increase the overall security of the system.
If that person has acquired your laptop, and has access to the wrapped-passphrase, the first they would do is copy that file to another computer that doesn't have the self-destruct mechanism.
Basically, there's no way to enforce such a system.
:-Dustin
Ah, I didn't think of that. The thief would need to know how the feature works, though, but all the info is on your blog, isn't it? ;)
ReplyDeleteAn integrated tool / option to move the .wrapped-passphrase -file to a usb-stick and make this symbolic link, or move it back from a usb-stick to the system might be a nice feature. And a warning on first boot to backup this file on external media, and a tool to do so.
Dustin,
ReplyDeleteThanks a lot for taking the time to make this post. I do find the concept clearer now. I guess I have a similar question to Chuck Frain with regards to the safety of my encrypted information.
If I use the alternate installer and do encryption via LUKS and LVM, then I'm prompted with a password before my system can even mount my home directory. I make this password (which I'll call my data access password) extremely long--at the limits of what I can remember, because it makes brute force guessing of this data access password unreasonably long. My user login password, however, is shorter; something I'm sure to remember, and something which I'm comfortable changing from time to time.
The way this is, it's okay if someone steals my laptop (well, it isn't for me, but for the safety of my data). They will have to brute force the data access password to even get to my files.
Now let's talk about the new eCryptfs arrangement. My data access password is still required to get to my data. Now instead of entering that actual password, however, I have the convenience of having that password "unwrapped" if I can recall my user login password. Am I understanding your post correctly?
If so, then my data is much closer to being obtained. My shorter user login password length makes brute-force guessing more possible, and once the attacker has cracked my user login password, they can unwrap the data access password, and get access to my data. That doesn't sound very appealing.
gotgenes-
ReplyDeleteIf these are your concerns, I consider you implement the suggestions I have in the 2-factor Authentication post:
* http://blog.dustinkirkland.com/2009/03/ubuntu-encrypted-home-with-2-factor.html
:-Dustin
Hi Dustin,
ReplyDeleteThanks for your time on answering questions on this and clarifying some of these issues we're asking about.
I have another question for you on the passphrase. If I set this up under a default installation of Ubuntu what is the mechanism to change the passphrase for my .wrapped-passphrase to make it unique and separate from the login password after it has been set initially?
chuckfrain-
ReplyDeleteYou can re-wrap your wrapped-passphrase with:
$ ecryptfs-rewrap-passphrase $HOME/.ecryptfs/wrapped-passphrase
Note that this will break automatic mounting your encrypted-private and encrypted-home upon login.
Thus, you can do this for an encrypted-private directory and mount it manually after-the-fact, but you cannot do this for an encrypted-home. You won't be able to login to the system.
:-Dustin
I do not know if this is a wrong place to post but I have tried googling without a solution.
ReplyDeleteI am using Ubuntu 9.04 (Jaunty). I have a /home partition with an encrypted user folder. My problem is that I lost the root partition and thus the .sig and wrapped passphrase files. I do remember the passphrase.
I have been able to mount the encrypted folder and can read the contents of at least some of the files. But! the filenames are still encrypted.
Any help on this?
I still have my files locked into the ecrptfs. And I have discovered that the few files I have been able to decrypt was from one of my attempts. So I am still in tourble with these files.
ReplyDeleteI think I know what the problem is might be though - the salt value might give a different key/sig. Now my question is: is it possible to 'brute force' my way through different key values to find the right one that will create my signature that will unlock my files. I still have my passphrase remembered.
Thanks in advance!
A salt wouldn't be worth much, if you could brute force it.
ReplyDeleteSee ecryptfs-utils/src/include/ecryptfs.h:
#define ECRYPTFS_SALT_SIZE 8
#define ECRYPTFS_SALT_SIZE_HEX (ECRYPTFS_SALT_SIZE*2)
#define ECRYPTFS_DEFAULT_SALT_HEX "0011223344556677"
#define ECRYPTFS_DEFAULT_SALT_FNEK_HEX "9988776655443322"
So that 16 hex digits, 16^16, which is pretty big.
By my calculations, if you try 1000 salts per second, it would take you 585 million years in the worst case to crack it.
:-Dustin
Hi Dustin,
ReplyDeletejust to make to clear: is generated passphrase everything I need to decrypt my data from .Private folder (including file names)?
What about salt? It is said in this blog that the passphrase is salted before being hashed. Where is that salt got from? Is it somehow derived from the passphrase? And there are two salts, one for fekek and another one for fnek. Where do I get them from? My point is that if it can be derived from passphrase, than that salt doesn't improve security, as anyone can get it. If not, then the passphrase isn't the only thing needed to know.
And one more question:
I have been playing and trying to decrypt my .Private home folder from the different user account (to test it if I could recover data in case of need, using only .Private directory and passphrase, without .ecryptfs config files). And I was trying to do it using "mount -t ecryptfs" command (so I can choose the source and destination locations). I succeeded decrypting the files, but, however, I couldn't decrypt the file names (even when I also typed "ecryptfs-add-passphrase --fnek" before mounting).
Does it has to do anything with salt for fnek, which is different from the salt for fekek?
You gave an advice on accessing encrypted data from Jaunty LiveCD in another blog, but if I understood correctly, it assumes having /dev folder together with /home folder on that device (so it is root partition, not just home).
Hi Dustin,
ReplyDeleteI have a question that I wonder if your experience can answer.
I am looking at converting my current home to an encrypted one. I have a tutorial that should work for this. My one concern is that I have a very large .Virtualbox directory containing filesystems used by VirtualBox and I don't really want to have that included in the encrypted home. I thought I could move it elsewhere and add a symlink to my home to locate it.
So I'm wondering if a symlink is made in home after mounted will the encryptfs know that it's a link outside the encryption and just handle it transparently or is it going to mess up and think it should be encrypted too? I general how are symlinks like this handled?
Thanks for any input you may have.
Symlinks will work as you desire for this case. If ~/.virtualbox is a symlink to, say /tmp, then data written to ~/.virtualbox will not be encrypted.
ReplyDeleteIt's really simple enough to test. Just make ~/.foo a symlink to /tmp and write some files.
Well Aigarius, Plausible deniability means to the denial of blame in free and familiar chains of command where upper rungs quarantine the blame to the lower rungs and vise-versa. In this case, illegal and unpopular activities become public and high-ranking officials could refuse any awareness of such act or any connection to the agents used to carry out such acts.
ReplyDeleteHow the things are working are quite clear now except one thing i.e what is the use of these encryption keys if they are very impossible to be memorised? One has to store it somewhere on the system and if this happens then anyone can have a look at it.
ReplyDeleteIf its your system login that's used to decrypt the Private area, why when you change your password using root (following a forgotten password) does your private area refuse to mount? And if you try to mount it with ecrypt-mount-private, what is the passphrase its prompting you for - your old forgotten password, or some key it generated for you when you first had your home area encrypted?
ReplyDeleteThanks :-Dustin for your explanation of how ecryptfs works.
ReplyDeleteAnyway, I have a question. I noticed that the login takes longer if ecryptfs is involved. This does not surprise me, but why both gdm and console login are long? Since you say that files and filenames are decrypted only when the kernel comes into, you would expect that the login on a tty would be as long as without ecryptfs.