Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
This information is Copyright 2009 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
ZFS Crypto Updates
1.2. Name of Document Author/Supplier:
Author: Darren Moffat
1.3 Date of This Document:
17 August, 2009
4. Technical Description
The following changes are being made to the ZFS Crypto design
as documented in PSARC/2007/261
Block Pointer Changes
---------------------
In order to facilitate a future project that allows for an encrypted
(and compressed) "raw" send/recv stream and interaction with the in
progress "BP rewriter (aka device removal work)" the crypto IV
(Initalisation Vector) will now be stored in the BP.
This is done by reusing the third DVA slot. The impact of this is that
when encryption is enabled on a dataset "copies" can be set to a maximum
of 2. Attempting to set copies=3 on an encrypted dataset fails:
# zfs set copies=3 tank/fs
cannot set property for 'tank/fs': copies cannot be set to 3 on encrypted
datasets.
Since all data blocks in an encrypted dataset are always encrypted with
the same encryption algorithm a single bit is used to store the fact that
this is a pointer to an encrypted block rather than storing the index value
of the encryption property.
On disk wrapped key changes
---------------------------
Instead of a hidden "wrappedkey" property a per objset ZAP object will
be used instead. This avoids the need to introduce a new binary property
type and also allows for key chains.
A key chain is a set of ZAP objects indexed by txg (transcation group)
the value of the ZAP object is a wrapped key. This is represented in memory
as an AVL tree of unwrapped keys per dataset.
Simpiler defaults
-----------------
It is no longer necessary to specific the keysource property, if it is
not specififed and encryption is enabled then a default of "passphrase,prompt"
is assumed. This allows users to enable encryption easily thus:
# zfs create -o encryption=on tank/fs
Enter passphrase for 'tank/fs':
Enter again:
#
AES keylength/modes
-------------------
Based on the performance of AES at various key lengths and the recent
papers in the cryptography community on weakness in AES when used with
a 256 bit key the default "on" value for encryption will be "aes-128-ccm".
This provides the best performing default and based on current research
in the crypto community it my ironically be stronger than "aes-256-ccm".
The "aes-192-ccm" mode will also be added.
See: http://eprint.iacr.org/2009/374
This case also seeks approval to add "aes-128-gcm, aes-192-gcm, aes-256-gcm",
using AES GCM. From a cryptographic view CCM and GCM are
very similar however GCM is significantly more expensive due to Galois
filed multiplication requirements. GCM is the preffered mode for
NSA Suite B compliance so it is included as an option.
Keyscope property removed
-------------------------
The keyscope property and the concept of keyscope is removed. Instead the
keyscope is always now per dataset and is properly inherited. With this
all the benefits of the previous keyscope=pool are available while providing
a much simplified admin model that is now consistent with how property
inheritance works in ZFS. This means there are no crypto related
changes to zpool(1M).
Explain this by example:
# zfs create -o encryption=on -o keysource=raw,file:///media/my/key tank/fs
At this point a single encrypted dataset exists and is wrapped using the
AES key in /media/my/key.
# zfs create tank/fs/sub
The keysource property is inherited as is the actual value of the wrappingkey.
This is more obvious in the following example:
# zfs create -o encryption=on tank/a
Enter passphrase for 'tank/a':
Enter again:
# zfs create tank/a/sub
On creating tank/a/sub the user is NOT prompted to enter a passphrase
because tank/a is already mounted (ie its key is available) so we inherit
the wrapping key from our parent. This also ensures that on import/mount
the user is only prompted for the passphrase for tank/a and not all the
child datasets of it.
If the user actually wishes to "stop" the inheritance of the passphrase
(ie the wrapping key value) then they can explicitly set the keysource
property when creating the dataset or performing a key change.
Dataset rename restrictions
---------------------------
On rename a dataset can non be moved out of its wrapping key hierarchy
ie where it inherits the keysource property from. This is best explained
by example:
# zfs get -r keysource tank
NAME PROPERTY VALUE SOURCE
tank keysource none default
tank/A keysource passphrase,prompt local
tank/A/b keysource passphrase,prompt inherited from tank/A
tank/A/b/c keysource passphrase,prompt inherited from tank/A
tank/D keysource none default
tank/D/e keysource passphrase,prompt local
Simple rename of leaf dataset in place:
# zfs rename tank/D/e tank/D/E OK
Rename within keysource inheritance remains the same:
# zfs rename tank/A/b/c tank/A/c OK
Rename out of keysource inheritance path:
# zfs rename tank/A/b/c tank/D/e/c FAIL
Key Change
----------
Due to the above mention keyscope removal the zfs key command now only
accepts a new keyscope property with -o when changing key. Key change
is also now applied recursilvey in a single transaction to all datasets
inheriting the wrapping key.
Dataset mount
-------------
The zfs_mount() library call in libzfs, and thus zfs(1M) mount command
will load keys if they are available when a dataset is attempting to be
mounted. Note that this means that 'zfs mount -a' can attempt to be
interactive if the keysource locator is "prompt". Note that this does
NOT cause a prompt for system boot and we do NOT wait looking for keys
(there is no facility to do so with SMF anyway).
Dataset/Clone Rekey
-------------------
A new "-K" flag for 'zfs clone' is introduced. If supplied new data
encryption key will be created in the transaction group the clone is
created in and used for all data that is unique to the clone.
The previous state of the keychain will be copied from the origin snapshot.
The 'zfs key' subcommand also has the "-K" flag, in this case it will
create a new data encryption key for the named dataset(s).
The rationale for this is allowing compliance with NIST guideless for
the amount of time a data encryption key should be used.
In both the cases the last rekeyed date can be found in the new 'rekeydate'
property. If a dataset has not been rekeyed then the value of 'rekeydate'
is the same as the 'creation' date. For a dataset that is not encrypted
then the value is "-".
For example:
zfs get -r -H creation,rekeydate tank
tank creation Tue Aug 4 14:37 2009 -
tank rekeydate - default
tank/128g creation Tue Aug 4 15:52 2009 -
tank/128g rekeydate Tue Aug 4 15:52 2009 local
tank/192g creation Tue Aug 4 16:08 2009 -
tank/192g rekeydate Tue Aug 4 16:19 2009 local
Summary of zfs(1M) command synopsis
-----------------------------------
zfs key
usage:
key -l <-a | [-r] filesystem|volume>
key -u [-f] <-a | [-r] filesystem|volume>
key -c [ -o <keysource=value>] <-a | [-r] filesystem|volume>
key -K <-a | [-r] filesystem|volume>
zfs set properties:
keystatus NO NO undefined | unavailable | available
rekeyed NO NO <date>
clonerekey YES YES on | off
encryption YES YES on | off | aes-128-ccm | aes-192-ccm | aes-256-ccm |
aes-128-gcm | aes-192-gcm | aes-256-gcm
keysource YES YES keysource=raw|hex|passphrase,prompt|file://<path>
Dnode Bonusbuf Encryption
-------------------------
Instead of encrypting the bonusbuf section of the dnodes the ZFS Crypto feature
will now depend on the ZFS fast system attributes project and will cause
the bonusbuf to always completely spill. Note there are no user visible
interface change from this and the ZFS fast system attribtues project isn't
expected to be reviewed in ARC as it is an implementation detail only.
Management of the dependency is thus not an ARC issue but an internal team
coordination issue.
6. Resources and Schedule
6.4. Steering Committee requested information
6.4.1. Consolidation C-team Name:
ON
6.5. ARC review type: FastTrack
6.6. ARC Exposure: open
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
