ecryptfs-users team mailing list archive

[Serge Hallyn <serge.hallyn@xxxxxxxxxxxxx>]

Quoting Fredrik Thulin (fredrik@xxxxxxxxxx):
> Serge, thanks a lot for your feedback!
> 
> On Sun, Apr 10, 2011 at 5:55 AM, Serge Hallyn
> <serge.hallyn@xxxxxxxxxxxxx> wrote:
> ...
> > So pam first reads your password, then passes that plus your username
> > back to the key for it to encrypt, right?
> 
> Yes. Well, HMAC-SHA1 hash - not encrypt.
> 
> > 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.
> 
> 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.

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.

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

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 several people are bound to end up (through full
disk, or badly timed ctrl-c, or something else) corrupting their
copy.  So just make sure that the user has another copy of the
ecryptfs key!  Maybe offline, maybe wrapped with login
passphrase, maybe protected using another token, maybe written
in hex on a post-it stuck on the monitor :)  Oops, not that.

> There's an implementation of offline validation using Yubikeys with
> scheme #1 that I'll merge and release in the yubico-pam project next
> week.

Cool, looking forward to it.  You might also push some test python code
which does the same steps for people to play with.

In fact, you seem to be focusing on people doing full home directory
encryption - and that's fine as I suspect that's the model we as a
whole are trying to push.  But please consider users like me, who
have $HOME unencrypted with several separate ecryptfs dirs spread
about.  (See the new options to mount.ecryptfs_private.c in
natty's ecryptfs-utils)

So I guess, for my own use, I'd actually just want to stick with a
non-changing wrapping key, so that I can support 5 (for example)
different ecryptfs directories with different passphrases.  For
that case, I'd actually want to use your current model!  :)  But
without pam (since it's not at login), so something amounting to:

   pw=$(dialog --passwordbox Password 10 20 --stdout)
   printf "%s" $(ykchalresp -2 -H $pw) | ecryptfs-add-passphrase
   mount.ecryptfs_private work
   (now ~serge/work is decrypted and available :)

(With the above being scripted of course)
In fact maybe I'll just start using something like this for a bit
to see how it works for me.

...

> > 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.
> 
> I totally agree that OTPs should be used for authentication (that's
> the core Yubikey concept after all). However, I think C/R is much
> better than static passphrases since they
> 
> 1) require you to know the right input, so someone that gets a hold of
> your Yubikey for a few minutes can't just connect it to a computer and
> press the button to get your wrapping passphrase
> 2) provides 160 bits high entropy output (since you have an 160 bits HMAC key)
> 3) can be triggered through API call (if that is permitted through
> configuration), thereby not requiring the user to press the button
> twice - once for log in and once for home directory decryption

Yup.

-serge