ecryptfs-users team mailing list archive

[Fredrik Thulin <fredrik@xxxxxxxxxx>]

On Mon, Apr 11, 2011 at 1:15 AM, Serge Hallyn
<serge.hallyn@xxxxxxxxxxxxx> wrote:
...
>> 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 :)

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

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

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.

> Just make sure to reliably clear all memory :)

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

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

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

That would be a way to reduce the likelihood that a user
looses/corrupts their mount passphrase, while of course increasing the
risk of the user's mount passphrase being stolen (bad PGP passphrase
or something).

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

That's an excellent idea. I've added
examples/rolling_challenge_response to python-yubico.

To try it out :

  $ git clone git://github.com/Yubico/python-yubico.git
  $ cd python-yubico/
  $ export PYTHONPATH="Lib"
  $ ./examples/rolling_challenge_response --filename foo --verbose --init

Answer the prompts about HMAC key and passphrase to protect. You will
now have a file 'foo' that is only decryptable using the next expected
response.

Then run (optionally add --verbose)

  $ ./examples/rolling_challenge_response --filename foo

any number of times and watch the challenges and responses roll.

The demo is usable without a YubiKey too, but then you have to
copy-paste the expected response manually (of course only shown on
screen for demo purposes).

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

You're right. Thanks for reminding me. I'll check the new things in Natty out.

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

You should be able to use rolling challenges for that model too, with
one 'state file' per encrypted directory, right?

/Fredrik