From the Canyon Edge -- :-Dustin

Saturday, February 28, 2009

How Encrypted-Home + eCryptfs Works

One comment to my last post, Jaunty Encrypted Home Directories, deserves a blog post of its own to answer..

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

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

27 comments:

  1. How about logging in without mounting the encrypted folder?

    How 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.

    ReplyDelete
  2. Am I reading this right that it is your login password that protects the wrapped-passphrase?

    If so we are still at a place where a short passphrase protects the long one.

    ReplyDelete
  3. chuckfrain-

    Two-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

    ReplyDelete
  4. aigarius-

    If 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

    ReplyDelete
  5. 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!)

    The whole Gnome keyring insisting on a password was a pain for a long time until they allowed empty passwords.

    ReplyDelete
  6. Hi Roger-

    Please 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

    ReplyDelete
  7. 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.

    What 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?

    ReplyDelete
  8. Hi Dustin,

    I 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?

    ReplyDelete
  9. Dustin,

    If 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?

    ReplyDelete
  10. chuckfrain-

    Sure, 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

    ReplyDelete
  11. didrocks-

    Great 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

    ReplyDelete
  12. meastp-

    Perhaps, 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

    ReplyDelete
  13. 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? ;)

    An 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.

    ReplyDelete
  14. Dustin,

    Thanks 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.

    ReplyDelete
  15. gotgenes-

    If 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

    ReplyDelete
  16. Hi Dustin,

    Thanks 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?

    ReplyDelete
  17. chuckfrain-

    You 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

    ReplyDelete
  18. I do not know if this is a wrong place to post but I have tried googling without a solution.

    I 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?

    ReplyDelete
  19. 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.

    I 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!

    ReplyDelete
  20. A salt wouldn't be worth much, if you could brute force it.

    See 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

    ReplyDelete
  21. Hi Dustin,
    just 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).

    ReplyDelete
  22. Hi Dustin,
    I 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.

    ReplyDelete
  23. 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.

    It's really simple enough to test. Just make ~/.foo a symlink to /tmp and write some files.

    ReplyDelete
  24. 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.

    ReplyDelete
  25. How 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.

    ReplyDelete
  26. If 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?

    ReplyDelete
  27. Thanks :-Dustin for your explanation of how ecryptfs works.

    Anyway, 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.

    ReplyDelete

Please do not use blog comments for support requests! Blog comments do not scale well to this effect.

Instead, please use Launchpad for Bugs and StackExchange for Questions.
* bugs.launchpad.net
* stackexchange.com

Thanks,
:-Dustin

Printfriendly