zfs code - Apr 2007 - Dataset Key storage

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
-- 
Darren J Moffat

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-crypto-discuss/attachments/20070423/0e749c47/attachment.bin>

Pawel Jakub Dawidek wrote:
>> [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? 
The initial phase will only have a single passphrase per pool, since all 
we need is the passphrase to generate the unwrapping key that is used to 
wrap the per dataset keys.

zpool(1M) will be interactive.  There will also be an API for this in 
libzfs and libzfs_jni.

I attempted to document this in Section 6 of the document.

 > If keys are stored on a
> hardware, which is available immediately we could decrypt and mount
> datasets automatically on ''zfs mount -a'', 
That depends on the hardware and what kind of key object it is.  Even in 
the hardware case we may actually need the PIN to login to the hardware. 
  This is certainly true for the SCA-6000 card (and its predecessor the 
SCA-4000).

It may well end up being different for a TPM though.

 > 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?
Thats what I''m hoping will work.  In actual fact I think the mount
might
work but you will get EIO on any attempt to access them until the key is 
made available.
> 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.
I''ll get the rationale for this added to the document.  I''m
asking James
Hughes to write this up for me since the choice of CCM rather than CBC 
is based heavily on his input.
> 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)?
The functions that do the actual encrypt/decrypt are generic.  They have 
to be since I need to be able to deal with encrypting not only the data 
but also things like dn_bonus in the dnode_phys_t.

One thing I would say is that the choice of AES mode may not be the same 
if we did the encryption at the VDEV level rather than at the ZIO layer. 
  Doing it at the VDEV layer is more like doing what the loficc project 
(or dm-crypt / cryptoloop on Linux, File Vault on MacOS X) does.  There 
AES CBC isn''t a good choice.
> Do you have an analysis/list of things that won''t be encrypted?
What are
> the possible threats?
I have some of this but I''m not finished yet - it will be in the 
document when I''m finished this part.  At present I have:

Encrypted:

All ?application? data
POSIX layer data
Permissions, owner etc
Directory structure
All ZVOL data
Snapshots
Take parent policy
Clones[ Will have different key for non shared blocks]

Likely in Clear:

Pool metadata
	VDEL layout, zpool history.

Open issue:

Data set names
Data set properties - probably need to encrypt all user properties.

 > For example will it be possible to move blocks
> within a pool, which won''t be discovered by ZFS?
How would you move blocks without ZFS noticing it given that we checksum 
everything ?  One of the things I haven''t made a decision on yet is if 
we should actually use HMAC-SHA256 when doing crypto instead of just 
SHA256.  The issue here is what happens when only some datasets are 
encrypted.

-- 
Darren J Moffat

Darren J Moffat wrote:
> 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.
Yep, I would recommend that you store each key in an object in the MOS, 
and keep that object''s number in the dsl_dataset_phys_t.  (I''m
guessing
that the key is around 1kB in size; if this is wrong let me know.)

--matt

On Fri, 2007-05-04 at 20:07 -0700, Matthew Ahrens wrote:
> I''m guessing that the key is around 1kB in size; if this is wrong
let me know.)
Your guess seems high to me.

These days, typical (symmetric) encryption keys are more like 128-256
bits (16-32 bytes).  128 is common; 256 bits is overkill against likely
threats -- when used, it may be a speculative hedge against significant
breakthroughs in quantum cryptography.  

It''s plausible that some keys would be stored in wrapped/encrypted
form,
or with additional metadata, and that might double or triple the 16-32
bytes but that still leaves you a good distance from using up a whole
kilobyte.

						- Bill

Matthew Ahrens wrote:
> Darren J Moffat wrote:
>> 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.
> 
> Yep, I would recommend that you store each key in an object in the MOS, 
> and keep that object''s number in the dsl_dataset_phys_t. 
(I''m guessing
> that the key is around 1kB in size; if this is wrong let me know.)
Can you point me to which ZFS APIs I should be using for storing stuff 
in the MOS please.

-- 
Darren J Moffat

Darren J Moffat wrote:
> Matthew Ahrens wrote:
>> Darren J Moffat wrote:
>>> 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.
>>
>> Yep, I would recommend that you store each key in an object in the 
>> MOS, and keep that object''s number in the dsl_dataset_phys_t. 
(I''m
>> guessing that the key is around 1kB in size; if this is wrong let me 
>> know.)
> 
> Can you point me to which ZFS APIs I should be using for storing stuff 
> in the MOS please.
Use the normal DMU routines -- dmu_buf_hold, dmu_write, etc.  See 
dsl_dataset.c, especially dsl_dataset_create_sync_dd().

However, I realized that you should consider just storing the key using 
the property infrastructure, which now supports non-inheritable 
properties.  See dsl_prop_set().  If this works then it will be cleaner.

--matt

Matthew Ahrens wrote:
> Darren J Moffat wrote:
>> Matthew Ahrens wrote:
>>> Darren J Moffat wrote:
>>>> 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.
>>>
>>> Yep, I would recommend that you store each key in an object in the 
>>> MOS, and keep that object''s number in the
dsl_dataset_phys_t.  (I''m
>>> guessing that the key is around 1kB in size; if this is wrong let
me
>>> know.)
>>
>> Can you point me to which ZFS APIs I should be using for storing stuff 
>> in the MOS please.
> 
> Use the normal DMU routines -- dmu_buf_hold, dmu_write, etc.  See 
> dsl_dataset.c, especially dsl_dataset_create_sync_dd().
> 
> However, I realized that you should consider just storing the key using 
> the property infrastructure, which now supports non-inheritable 
> properties.  See dsl_prop_set().  If this works then it will be cleaner.
can I have properties that don''t appear in zfs(1) ?  These
aren''t
something I want to expose directly via zfs(1) (at least not just now).

-- 
Darren J Moffat