On Mon, Apr 11, 2011 at 1:15 AM, Serge Hallyn <[email protected]> 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 _______________________________________________ Mailing list: https://launchpad.net/~ecryptfs-users Post to : [email protected] Unsubscribe : https://launchpad.net/~ecryptfs-users More help : https://help.launchpad.net/ListHelp
