ecryptfs-users team mailing list archive

[Dustin Kirkland <kirkland@xxxxxxxxxx>]

On Wed, Apr 13, 2011 at 4:18 AM, Fredrik Thulin <fredrik@xxxxxxxxxx> wrote:
> 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...

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.

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

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

>>> 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
>
> _______________________________________________
> Mailing list: https://launchpad.net/~ecryptfs-users
> Post to     : ecryptfs-users@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ecryptfs-users
> More help   : https://help.launchpad.net/ListHelp
>



-- 
:-Dustin

Dustin Kirkland
Ubuntu Core Developer