On Mon, Apr 23, 2007 at 05:08:08PM +0100, Darren J Moffat wrote: > I'm planning on storing the per data set encryption keys on the disk with the > dataset in a wrapped form. They would be wrapped either with a symetric key > or an asymetric > key. I don't want to store these as properties since you won't be > manipulating them via 'zfs set', plus they are significantly larger in size > than any of the existing > properties. > > A master (effectively per pool for the inital phase) key would then be stored > either in hardware (such as the SCA-6000 or a TPM) or be a passphrase that is > entered by hand > (and passed through PKCS#5 PBE to generate the master symetric key). See the > udpated draft design document at [1] some for more details > > I'm looking for some hints on what APIs in ZFS I should be using to store the > wrapped keys and what structures I should be hanging them off of. I need to > be able to > "lookup" these wrapped keys using a zbookmark_t while in the ZIO pipeline. > My initial thought was using *dsl_dataset_phys_t* however that doesn't have > sufficient space so > it may be better to store a "pointer" there to some external object. > > > [1] http://opensolaris.org/os/project/zfs-crypto/files/zfs-crypto.pdf
Nice to see progress on that front. How do you plan to ask for passphrases exactly? If keys are stored on a hardware, which is available immediately we could decrypt and mount datasets automatically on 'zfs mount -a', but if someone has to enter a passphrase/pin, maybe we should just skip such datasets and allow to mount them manually later, when administrator is ready? That's the plan? I'm not sure I agree than CBC mode is not ok. It can be used in a secure way for data disk encryption and I think it should be done. The main reason is that there is a lot of h/w accelerators out there that already support CBC. For some time now I'm thinking about encryption implementation at VDEV level. This should allow to encrypt more ZFS metadata, which may be desirable for some uses. Will it be possible to make the code responsible for encryption/decryption as much general as possible to make it usable for encryption at VDEV level (if you guys decide it makes sense)? Do you have an analysis/list of things that won't be encrypted? What are the possible threats? For example will it be possible to move blocks within a pool, which won't be discovered by ZFS? -- 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-code/attachments/20070423/0e749c47/attachment.bin>
