You can change an encrypted file system's wrapping key by using the zfs key –c command. The existing wrapping key must have been loaded first, either at boot time or by explicitly loading the file system key (zfs key –l) or by mounting the file system (zfs mount filesystem). For example:
# zfs key -c tank/home/darren Enter new passphrase for 'tank/home/darren': xxxxxxxx Enter again: xxxxxxxx
In the following example, the wrapping key is changed and the keysource property value is changed to specify that the wrapping key comes from a file.
# zfs key -c -o keysource=raw,file:///media/stick/key tank/home/darren
The data encryption key for an encrypted file system can be changed by using the zfs key –K command, but the new encryption key is only used for newly written data. This feature can be used to provide compliance with NIST 800-57 guidelines on a data encryption key's time limit. For example:
# zfs key -K tank/home/darren
In the above example, the data encryption key is not visible nor is it directly managed by you. In addition, you need the keychange delegation to perform a key change operation.
The following encryption algorithms are available:
aes-128-ccm, aes-192-ccm, aes-256-ccm
aes-128-gcm, aes-192-gcm, aes-256-gcm
The ZFS keysource property identifies the format and location of the key that wraps the file system's data encryption keys. For example:
# zfs get keysource tank/home/darren NAME PROPERTY VALUE SOURCE tank/home/darren keysource passphrase,prompt local
The ZFS rekeydate property identifies the date of the last zfs key –K operation. For example:
# zfs get rekeydate tank/home/darren NAME PROPERTY VALUE SOURCE tank/home/darren rekeydate Wed Jul 25 16:54 2012 local
If an encrypted file system's creation and rekeydate properties have the same value, the file system has never been rekeyed by an zfs key –K operation.
ZFS encryption keys can be managed in different ways, depending on your needs, either on the local system or remotely, if a centralized location is needed.
Locally – The above examples illustrate that the wrapping key can be either a passphrase prompt or a raw key that is stored in a file on the local system.
Remotely – Key information can be stored remotely by using a centralized key management system like Oracle Key Manager or by using a web service that supports a simple GET request on an http or https URI. Oracle Key Manager key information is accessible to an Oracle Solaris system by using a PKCS#11 token.
For more information about managing ZFS encryption keys, see http://www.oracle.com/technetwork/articles/servers-storage-admin/manage-zfs-encryption-1715034.html
For information about using Oracle Key Manager to manage key information, see:
http://docs.oracle.com/cd/E24472_02/
Review the following permission descriptions for delegating key operations:
Loading or unloading a file system key by using the zfs key –l and zfs key –u commands require the key permission. In most cases, you will need the mount permission as well.
Changing a file system key by using the zfs key –c and zfs key –K commands require the keychange permission.
Consider delegating separate permissions for key use (load or unload) and key change, which allows you to have a two-person key operation model. For example, determine which users can use the keys verses which users can change them. Or, both users need to be present for a key change. This model also allows you to build a key escrow system.