Re: [PATCH 0/12: eCryptfs] eCryptfs version 0.1.6

[Alon Bar-Lev <alon.barlev@gmail.com>]

Phillip Hellewell wrote:
> This patch set constitutes the 0.1.6 release of the eCryptfs
> cryptographic filesystem:
> 

Great work!
I just want to make some notes about the user mode interface.

I think that current security and encryption solutions that
come out these days without a proper smart card support
create a false sense of security for users. So solutions
should first be designed so that a smart card can be used,
and only then provide a passphrase alternative.

This is the first time I've looked on the user mode
keyutils, and it looks quite good. I think that the eCryptfs
should use it more ?correctly? so that keys stored on smart
card may be used.

For example, you can publish a text format of the key data
so that any application can easily and independently
construct this.

A simple example of key content is:
eCryptfs:version:cipher:key
or:
eCryptfs:1:AES256:123DD12ED12312....

You can modify the mount options:
mount -o keytype=type,keydesc=desc,keydata=data

So that any specific key may be provided, and not only keys
derived from a passphrase. And a proper key may be
instantiate from the kernel.

User may already have this key available using keyctl. The
key may be available from any place.

But if the key is not available, the following
request-key.conf this may be written:

---
create user eCryptfs:p11-data:*
|/usr/bin/eCryptfs-key-p11-data /etc/eCryptfs-key-p11-data.conf

create user eCryptfs:pass:* |/usr/bin/eCryptfs-key-pass
---

This will construct the key from the data if the key is not
available.

For PKCS#11 the providers listed in the conf file, key may
be stored as a data object, and data may be:
	cipher:slot-type:slot:application:label:PIN
	Where:
		slot-type
			slot	- slot id
			name	- slot name
			label	- token label

	?Calling without a PIN may allow prompt for dialog
	via a named pipe to a running daemon by uid?

For passphrase the data may be the cipher:passphrase.

Another issue is a multi user access without a shared
secret. This may be done by encrypting the symmetric key in
several asymmetric ones. Again this can be done in user
mode... But there is a need to support reencrypting the
whole filesystem with a new symmetric key so that a user may
be removed from the list.

In order to support this mode using smart cards when key is
unavailable, the following request-key.conf may be written:

---
create user eCryptfs:p11-multi:*
|/usr/bin/eCryptfs-key-p11-multi
/etc/eCryptfs-key-p11-multi.conf
---

Now the data may be:
	cipher:slot-type:slot:id-type:id:PIN
	Where:
		slot-type
			slot	- slot id
			name	- slot name
			label	- token label
		id-type
			id	- CKA_ID
			label	- CKA_LABEL
			subject	- certificate subject


I hope I understood correctly the various components.

If you like, I will be happy to help you with the user mode
stuff, and implement the smart card access.

Best Regards,
Alon Bar-Lev