ecryptfs-users team mailing list archive

[Tyler Hicks <tyhicks@xxxxxxxxxxxxxxxxxx>]

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