ecryptfs-users team mailing list archive

[Serge Hallyn <serge.hallyn@xxxxxxxxxxxxx>]

Quoting Fredrik Thulin (fredrik@xxxxxxxxxx):
> 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.

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 :)

>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 password, part of the challenge) and voila, two
>factor authenticated eCryptfs!

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 passphrase has low entropy due to
modhex (to satisfy the requirements on valid characters), but the pam
module can take the long low-entropy passphrase and mogrify it into a
shorter high-entropy one.  (That, of course, continues to be our
wrapping passphrase, not the actual ecryptfs key.)

This way authentication isn't susceptible to replay.  We get a nice long
passphrase for ecryptfs.  We don't need any changes to the ecryptfs
password handling.  And it's simple.

Anyway that's how I'd go about it off the top of my head.  I got worried
when the Yubikey Manual 2010-09-16.pdf seemed to tell me you couldn't
have one slot do challenge-response while the other did simple OTP or
passphrase, but the ykpersonalize manpage said differently, so I tested
it - and it worked fine.

Separately, I had a question regarding challenge-response mode.  In
Yubico chal-resp mode it takes a 6 byte challenge and generates OTP.
But the doc doesn't say what piece of data is replaced by the 6 byte
challenge.  Is it the uid (bytes 0-6)?

thanks,
-serge