On Mon, Oct 16, 2006 at 04:47:42PM +0100, Darren J Moffat
wrote:> If passphrase: is given then prompt interactively prompt for
> the passphrase and then pass the text through PKCS#5 just like
> encrypt(1) does pass that raw key to kernel. Must do the
> double prompting.
>
> zfs set key=passphrase:
> or
> zfs set key=passphrase
>
> Is this an appropriate interface for key change ?
> Maybe not since we don''t want an incorrect key to cause a
> key change. This implies we need to distinguish between
> setting the key and changing the key.
You should always be prompted for an old passphrase when one is already
configured.
If the passphrase is not set at ''zfs create'' time, we should
probably
deny setting it at the first time if the dataset is not empty.
> Key versioning/identification
> -----------------------------
> We need to store with each block a keyid. This allows us to have
> a key version number. With key version numbers we can support key change.
>
> Key change alone does not imply data rewritting - that needs a zpool
> level framework for block rewritting that is shared with
checksum/compression.
>
> Each dataset should probably have an easy way to retrieve the list
> of keyids currently in use. Min/Max is not enough we need the full
> list since their could be gaps in the middle.
Can you explain what exacly happens on key change?
I assume passphrase is no the key, it is only used to encrypt the actual
key, right? And on passphrase change you only decrypt the key using the
old passphrase and encrypt it with the new one?
If I understand this correctly, you may want to allow to configure more
than one passphrase per dataset. For example you want user to have its
own passphrase, but also allows company''s security officer to have its
own passphrase for employees dataset. This way we can avoid problems
with employee''s short memory. In that case, the key is stored few
times,
everytime encrypted with different passphrase.
> Key not present
> ---------------
> Do we need the key for the mount to succeed ?
> If we do need the key at mount time then zfs mount needs to
> prompt for the passphrase keys.
>
> If not, which would be better, we can later do a zfs set key= - maybe
> even from a PAM module or a desktop applet.
Eventually you can first ''attach'' the dataset by giving the
passphrase
and then you can easly mount/unmount it without dealing with
passphrases (but I think will be better to ''detach'' on last
close/unmount).
Also, don''t forget about ZVOLs. For them there is no ''zfs
mount'', so
another command which ''opens'' encrypted dataset could be
useful.
You may also think about one-time keys. Such keys are stored only in RAM
at creation time. This is very useful for swap partitions and temporary
file systems.
I found it really handy to be able to specify path to a file with the
key instead of a passphrase. For example the key may be stored in a file
on USB Pen-Drive, eg:
# dd if=/dev/random of=/mnt/pendrive/key bs=64k count=1
# zfs set key=file:/mnt/pendrive/key.bin
--
Pawel Jakub Dawidek http://www.wheel.pl
pjd at FreeBSD.org http://www.FreeBSD.org
FreeBSD committer Am I Evil? Yes, I Am!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/zfs-crypto-discuss/attachments/20061018/325e89e7/attachment.bin>