ecryptfs-users team mailing list archive

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

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 validation using Yubikeys with
scheme #1 that I'll merge and release in the yubico-pam project next
week.

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

Oh yes, definitely. Sorry for not mentioning that - I focused on the
ecryptfs related things in my original post.

Yes, a user with a Yubikey would most likely use OTP validation to log
in 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.

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

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

Yes, that is definitely supported.

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

I'm not sure actually. I think so. I'll ask the firmware guy on
Tuesday, or you could AES ECB decrypt the OTP and see for yourself =).

/Fredrik