On 02/25/2010 11:08 PM, Li, Yan I wrote: > On Fri, Feb 26, 2010 at 12:38:32PM +0800, Dustin Kirkland wrote: >>> Exactly. Does such an infrastructure exist? Or maybe I can start to >>> write one. >> >> No, none exists yet. Let's discuss it a bit more, make sure we agree >> on a design. I'd also like to get Tyler's opinion on it. > > Yeah, sure. > >> The functions that deal with the wrapped-passphrase file are >> relatively few. We could support a glob-type interface reasonably >> easily. I'm just not sure of the security of doing so. I guess we'd >> need to know a little more about the use case, if possible. > > I'm exploring alternative ways for authenticating a user. > > For example: > > 1. two people share a single encrypted directory but don't want to > share their passwords with each other
Are these two people sharing the same user account? If not, why would one user need to attempt to unwrap multiple wrapped-passphrase files? Each user would just need to unwrap the shared mount key with their unique, secret passphrase. It should also be noted that we support multiple encrypted file encryption keys (EFEK) in the metadata of each file. You can have copies of the FEK that are wrapped by a combination of passphrase based tokens and/or public key based tokens (which are handled by the userspace key modules). > > 2. the user may want to use either a smart card or a password to > login It has been a long time since I've looked at our pam module. Dustin will better be able to decide if this is required for this use case. > >>> BTW, does this has anything to do with PKCS#11 support? >> >> Hmm, not that I know of. It's more of a token interface. Like a >> fingerprint reader that produces an authentication token. Keep in mind that we do have PKCS#11 support through the pkcs11-helper key module. The problem is that there's a bit of a chasm between our mount.ecryptfs_private and mount.ecryptfs mount helpers. The mount.ecryptfs_private mount helper can't use the key modules that are supported by the mount.ecryptfs helper, while the mount.ecryptfs helper can't use the wrapped-passphrase feature of the mount.ecryptfs_private helper. The mount.ecryptfs_private helper needs to be simple and compact, as it is intended to be installed setuid root, but the key module infrastructure is anything but simple. If you needed PKCS#11 support from the pam module, one way to start would be to add command line parsing, similar to what is available in mount.ecryptfs, to the ecryptfs-manager application (it is only interactive at the moment). That way, mount.ecryptfs_private would remain a small piece of code that could perform the mount with the key sig of the key inserted into the keyring by ecryptfs-manager. Tyler _______________________________________________ Mailing list: https://launchpad.net/~ecryptfs-users Post to : [email protected] Unsubscribe : https://launchpad.net/~ecryptfs-users More help : https://help.launchpad.net/ListHelp
