gmane.comp.file-systems.ecryptfs.user

Re: Unable to mount with "-o xattr"

Tyler Hicks — 2011-05-29T20:16:39

You're looking for the ecryptfs_xattr mount option. It is an
eCryptfs-specific mount option, so we try not to pollute the global
mount option namespace by using the "ecryptfs_" prefix.


The GPG key module isn't fully implemented so it returns an error during
initialization. You can ignore this.

If you installed ecryptfs-utils with your distro's package manager,
you may want to let the package maintainer know that there is no need to
build that key module at this time. If you built ecryptfs-utils from
source, don't pass --enable-gpg to the configure script.

Tyler

Unable to mount with "-o xattr"

Hagen Fürstenau — 2011-05-28T11:40:50

Hi,

I'd like to mount an ecryptfs file system with the "-o xattr" option
(assuming that it would improve performance of stat calls).

I've mounted the underlying ext4 file system with "user_xattr" and made
sure that setting xattrs with "setfattr" works as it should. But after
mounting with "mount -t ecryptfs -o xattr", the feature doesn't seem to
work: files are still at least 12K big, "mount" doesn't show "xattr"
among the options of the ecryptfs mount, and "getfattr" on the
underlying files doesn't show anything.

Any ideas where to look for the problem? There isn't anything about
ecryptfs in syslog, except for

mount.ecryptfs: Error initializing key module
[/usr/lib/ecryptfs/libecryptfs_key_mod_gpg.so]; rc = [-22]"

which seems to be unrelated.

# uname -a
Linux neko 2.6.32-5-amd64 #1 SMP Wed May 18 23:13:22 UTC 2011 x86_64
GNU/Linux

Cheers,
Hagen

New eCryptfs mailing list

Tyler Hicks — 2011-05-25T15:32:49

Both of the eCryptfs mailing lists (ecryptfs-devel and ecryptfs-users)
are moving. They will be consolidated into a single mailing list that is
hosted on vger.kernel.org. You can find information about the new list
here:

http://vger.kernel.org/vger-lists.html#ecryptfs

We will keep the old mailing lists running for about a week and then
they will be shut down.

The reason for the switch is due to launchpad's list policy of requiring
mail to be from launchpad members. The eCryptfs development community
continues to grow and keeping the list open to non-launchpad members is
needed to foster that growth.

Please take a moment to subscribe to the new mailing list.

Tyler

Re: A desperate post

Xander Pirdy — 2011-05-10T05:05:25

Thank you that worked absolutely beautifully and was very prompt. So
much relief.

Re: A desperate post

Dustin Kirkland — 2011-05-09T22:32:26

If you accurately recorded your mount passphrase, you should be able
to follow the instructions at:
 * http://blog.dustinkirkland.com/2011/04/introducing-ecryptfs-recover-private.html
and recover your data.

Dustin

A desperate post

Xander Pirdy — 2011-05-09T21:25:55

Hello please let me know if this is posted in the wrong place and if
so where I should post to get useful information:

I was trying to mount my encrypted home directory from a livecd in
order to back up my data (according to the instructions at
https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/455709)
, when I accidentally deleted what I thought was one of the .ecryptfs
folders in my encrypted home. Since I performed the "move to trash" in
nautilus I thought that it would be in the trash and I could just
restore it. No such luck. So now I am pretty much freaking out. I have
the password, it looks like all the files are still in .Private but
when I boot my system and logon all that is in my home folder are:
Access-Your-Private-Data.desktop README.txt .Private .cache .gnome2
and a new folder that starts with
ECRYPTFS_FNEK_ENCRYPTED.<longstringofrandomdigitsandletters>--.

In other words I have no idea how to get the data out of my home
folder now. Is it even possible? All the files are still there

Re: hardware token

Serge Hallyn — 2011-04-13T16:41:15

Quoting Fredrik Thulin (fredrik< at >yubico.com):

Awesome, thanks, I'll try this out tonight.

...


Well I don't know - for all my feigned bravado about not caring about
remote access to ecryptfs files, in fact I probably will want to do it
remotely.  In the end it'll probably get automated, but at first I
expect to just copy/paste challenge/response between ssh session and
host.


Yup, I see no reason why not.

thanks,
-serge

Re: hardware token

Serge Hallyn — 2011-04-13T16:36:21

Quoting Dustin Kirkland (kirkland< at >ubuntu.com):

I don't remember you asking before, but


Yup it's exactly what I was suggesting.  I think this is the right
thing to do.

-serge

Re: hardware token

Dustin Kirkland — 2011-04-13T16:09:54

Yeah, and for extra credit, run strings on unencrypted swap.  You'll
be floored by what you find there.  Hence, we always recommend
encrypting swap when using eCryptfs, and have provided the
ecryptfs-setup-swap helper script to do so.


Personally, I think I like this scheme.  The code changes in
ecryptfs-utils would be fairly localized, and safe, I think

Re: hardware token

Fredrik Thulin — 2011-04-13T09:18:39

On Mon, Apr 11, 2011 at 1:15 AM, Serge Hallyn
<serge.hallyn< at >canonical.com> wrote:
...

Yup, that's the single largest drawback of that scheme =).


I agree, since ecryptfs already do this with the mount pass phrase it
doesn't make things worse to do it with the HMAC key too.


Sounds easy, but apparently is not. For an interesting read, see
http://www.schneier.com/blog/archives/2007/01/choosing_secure.html -
the paragraphs about how 50% of all passwords to computers can be
recovered through using 'strings' on the hard drive as a dictionary...


I think I've asked before but do not remember if it was answered...
what do you think about a scheme where the user has (any combination
of) the file ~/.ecryptfs/wrapped-passphrase just like today,
~/.ecryptfs/wrapped-passphrase.yubikey-123456 with the mount
passphrase protected using challenge-response involving YubiKey with
serial number 123456 (just as an index, to be able to have multiple)
and ~/.ecryptfs/wrapped-passphrase.pgp for a PGP encrypted version and
...

Re: hardware token

Serge Hallyn — 2011-04-10T23:15:55

Quoting Fredrik Thulin (fredrik< at >yubico.com):

How does this help?  If I MITM while you are, say, authenticating
with (C15:R15) and you pass (C16:R16) as the next to be used, then
I can simply authenticate with C16:R16 and hand over a dummy
C17:R17.  Yes, I cost you future access to your data, but that
doesn't bother me :)

I know right now you see this as being for local-only use, but
honestly that seems very un-unixy to me, and I think you pretty
much have to, eventually, implement a way to do this remotely :)
Presumably with a patch to ssh which does the challenge-response
and passes data back and forth to the remote PAM module.


This daemon is going to get access to your ecryptfs key temporarily
anyway, so I don't think that giving it access to the HMAC key
gives anything away.  Just make sure to reliably clear all memory :)

So I like option 2, personally.

In a later email you ask about re-wrapping the wrapped ecryptfs
passphrase on every mount.  I'll answer here:  it promises to be
disastrous, as seve

Re: hardware token

Fredrik Thulin — 2011-04-10T15:56:36

On Sun, Apr 10, 2011 at 4:17 PM, Serge Hallyn
<serge.hallyn< at >canonical.com> wrote:
....

I don't like it either - I mean there is even USB over IP (even though
that approaches the old "if it hurts, don't do it").

I think that brings us to exploring either version 1 or 2 of the
"rolling challenges" I described in my previous e-mail.

My initial questions are then

- is it a good or bad idea to re-wrap your mount passphrase on each mount?

- where should the required metadata be stored? In scheme 1 this would
be the next expected response, in scheme 2 the AES key of the Yubikey
encrypted with the next response, and the next challenge in clear text

- how to make this either completely separate from eCryptfs, or vendor
neutral enough for you to think it is a good idea to include it in
eCryptfs


I think the current BCP is to use Password-Based Key Derivation
Function 2 (PBKDF2) with a sufficiently large number of iterations.
Wikipedia says the iPhone4 uses 10,000. You come very close with your
suggestion =).

/

Re: hardware token

Serge Hallyn — 2011-04-10T14:17:09

Quoting Fredrik Thulin (fredrik< at >yubico.com):
...

Ok, that makes all the difference :)

I agree the static passphrase has its problems with someone able to
just sneakily plug it into their own laptop to steal the passphrase :)


Cool.  Now the other thing I don't like is having the username:pwd
pushed to the yubikey, only bc it's usb and i dunno, I can just see
someone coming up with a sneaky way to grab that.  Does it help at
all to have send sha1sum(username:pwd) to the yubikey instead?  It also
helps with your concerns about sufficent salt, right?

-serge

Re: hardware token

Fredrik Thulin — 2011-04-10T06:51:24

Serge, thanks a lot for your feedback!

On Sun, Apr 10, 2011 at 5:55 AM, Serge Hallyn
<serge.hallyn< at >canonical.com> wrote:
...

Yes. Well, HMAC-SHA1 hash - not encrypt.


That's absolutely true for the current version. I know of two ways to
improve on this, both with their drawbacks and advantages.

1) Every time the user logs in, you take your challenge C1 and
generate R1 using it. You then generate another challenge C2 and have
the Yubikey generate R2 using C2. You rewrap your mount passphrase
using R2, so this is the response that has to be generated the next
time. The challenges could be "$username:$password:$nonce", with
$nonce stored in plain text on the computer.

2) You rig it so that every time the correct response is presented,
you are able to decrypt a file that contains the HMAC key inside the
YubiKey (which you know, since you programmed it). You can then
randomize a new C2 and calculate what R2 would be, and re-encrypt the
file with the HMAC key using R2.

There's an implementation of offline va

Re: hardware token

Serge Hallyn — 2011-04-10T03:55:22

Quoting Fredrik Thulin (fredrik< at >yubico.com):

Hi,

Thanks very much for writing.  I'm definately eager to support
token based auth enhancements.  In the late 90s I was very
excited about the javabutton, but their choice of java (and
crappy libraries which never quite worked on my sparcstation at
home) ruined it.  I love that you have python support :)


So pam first reads your password, then passes that plus your username
back to the key for it to encrypt, right?

The only thing that worries me is that the authentication is not
really partly based on 'something you have'.  Because if I can play
man in the middle and read your password and the hmac once, I can
replay them any time I want.

So with that in mind, here's how I might prefer to go about it.  The
yubikey supports two 'configs' or 'slots'.  I propose we exploit that.
First we use config 1 for OTP challenge-response - but we only use that
to authenticate to the system.  Then we use a static long passphrase for
the ecryptfs passphrase.  The long passp

Re: hardware token

Serge E. Hallyn — 2011-03-21T20:49:13

FWIW I am hoping to take a good close look thursday or friday.

thanks,
-serge

Re: hardware token

Fredrik Thulin — 2011-03-21T17:11:24

...
...

For sure. For the authentication part of the PAM module, I've added
the ability to have multiple tokens for one user (like a backup
Yubikey, or an administrator with another Yubikey).

Perhaps it's easier for users to present multiple authentication
devices (one USB disk, one Yubikey, one smartcard or any combination
of these) to effectively get backup access to their files, than it is
to get them to actually print the mount passphrase?

The mount passphrase would be stored one time for each authentication
device, encrypted with the PAM_AUTHTOK the authentication device is
capable of producing.

Have you had any thoughts along these lines?

...

I'm no pro-packager, but there is a PPA for pam_yubico available on my
Launchpad page. Consider it a start - any help welcome =).

  https://launchpad.net/~fredrikt/+archive/yubico-pam

/Fredrik

Re: hardware token

Dustin Kirkland — 2011-03-21T14:45:02

On Tue, Mar 15, 2011 at 8:57 AM, Serge E. Hallyn
<serge.hallyn< at >ubuntu.com> wrote:

Hi Fredrik,

interest from eCryptfs users out there.

I posted in my blog a quick-n-dirty way to get 2-factor authentication
working with encrypted-home:
 * http://blog.dustinkirkland.com/2009/03/ubuntu-encrypted-home-with-2-factor.html

Basically, you move your ~/.ecryptfs/wrapped-passphrase to a usb key,
and symlink ~/.ecryptfs/wrapped-passphrase to wherever udev mounts
that usb key.  At this point, you'll have to have that USB key plugged
in (and udev will have to have mounted it) such that you can log in
and see your data.


Interesting.  That sounds cryptographically more complex than the
quick/dirty hack I mentioned above.


I think so, but I'd like to hear Serge's opinion on the matter.


Yeah, I think this is the "feature" of your approach.  However, this
is going to require very, very, very clear documentation and user
culling.  Too many users get involved with eCryptfs already, who have
no idea what's going on, and a

Re: hardware token

Fredrik Thulin — 2011-03-15T18:59:35

On Tue, Mar 15, 2011 at 2:57 PM, Serge E. Hallyn
<serge.hallyn< at >ubuntu.com> wrote:
...

I'm thinking there might be security concerns with passing the
unprotected pass phrase from one PAM module to another for example,
and that perhaps passing it through PAM places unwanted restrictions
on the passphrase.

eCryptfs seems to support 64 chars pass phrases. The YubiKey currently
"only" produces 20 bytes HMAC-SHA1, so I can just hex encode that into
40 bytes to avoid problems with special bytes (null, linefeed, perhaps
others), but the best design would allow for passing the full 64 bytes
binary clean I guess... or more in case eCryptfs ever gets support for
even longer pass phrases.

/Fredrik

Re: hardware token

Serge E. Hallyn — 2011-03-15T13:57:12

Quoting Fredrik Thulin (fredrik< at >yubico.com):

I'm interested, yes.


Cool, two or three years ago I was just about set to place an order for
some of these keys (group order to make them cheaper :).  Something
happened, forget what...


(Not sure what you mean.  I'll take another look after I clear some
things off my plate)


Depends who you ask :)  For me it would be a feature.


Thanks, I'd like to take a look, though probably won't have time during
this week.


Winning  :)

thanks.
-serge

hardware token

Fredrik Thulin — 2011-03-15T07:57:29

Hi

[repost after properly registering e-mail address]

I'm sending this message to see if there is any interest of
collaboration regarding development of multi-factor protection of user
data.

I'm currently experimenting with using YubiKey USB tokens with
HMAC-SHA1 challenge-response to unlock my encrypted home directory
(disclaimer: I work for Yubico).

I'm glad to report that I've got a proof of concept working. We have a
PAM module for doing OTP validated logins that has recently been
extended to also support offline authentication using the
challenge-response mode available since YubiKey 2.2.

Today, I made that PAM module store an authentication token (currently
the result of a static challenge) upon successful validation which
meant that pam_ecryptfs would not get my login password from PAM
anymore, but rather get the result of the challenge-response.

After that, it was simply a matter of rewrapping my ecryptfs
passphrase to get it protected by something I have (my YubiKey) plus
something I know (my