You are on page 1of 5

How to Manage ZFS Data Encryption

by Darren Moffat

How to encrypt data in a ZFS file system and how to manage data encryption for the file system or storage pool.

Published July 2012

Oracle Solaris 11 adds transparent data encryption functionality to ZFS. All data and file system metadata (such as ownership, access control lists, quota information, and so on) are encrypted when stored persistently in the ZFS pool. A ZFS pool can support a mix of encrypted and unencrypted ZFS data sets (file systems and ZVOLs). Data encryption is completely transparent to applications and other Oracle Solaris file services, such as NFS or CIFS. Since encryption is a first-class feature of ZFS, we are able to support compression, encryption, and deduplication together. Encryption key management for encrypted data sets can be delegated to users, Oracle Solaris Zones, or both. Oracle Solaris with ZFS encryption provides a very flexible system for securing data at rest, and it doesn't require any application changes or qualification.

Want technical articles like this one delivered to your inbox? Subscribe to the Systems Community Newsletter—only technical content for sysadmins and developers.

ZFS makes it easy to encrypt data and manage data encryption. You can have both encrypted and unencrypted file systems in the same storage pool. You can also use different encryption keys for different systems, and you can manage encryption either locally or remotely. This article shows you how.

About ZFS Data Encryption
The encryption and key management policy for a ZFS file system is controlled via ZFS properties, and the normal ZFS inheritance rules apply. This makes it very easy to set a policy at a given point in the file system hierarchy and have it be inherited automatically. Administrators (or authorized users) manage one or more master wrapping keys for the encrypted data sets in a storage pool. A very simple example of using ZFS encryption is as follows:

# zfs create -o encryption=on rpool/export/project Enter passphrase for 'rpool/export/project': Enter again: # zfs create rpool/export/project/A # zfs create rpool/export/project/A/design # zfs create rpool/export/project/B

In this simple case, we are using a passphrase that is interactively requested; later we will discuss other choices for managing the wrapping keys, many of which will be more appropriate for enterprise deployments. Note that file systems created below project did not prompt for a passphrase because ZFS file systems automatically inherit the wrapping key and encryption property value from the parent file system unless told otherwise.

even while the data set is mounted and shared. but PKCS#11 terminology uses the word PIN for legacy reasons). The wrapping key is needed only at the time the ZFS file system is initially mounted after system boot. How to Manage Encryption Keys Locally As we already saw in the first simple example of enabling encryption. the reason for that will be clearer later. so we were prompted for the keystore PIN (it is really a passphrase. a hardware security module that can store AES keys can also be used. . If you use this method. The wrapping key can be either a passphrase or a raw AES key. The syntax of the PKCS#11 URI that is used with the keysource property allows for specifying a path to the PIN file. Using this method ensures that the actual wrapping key is encrypted and protected in the PKCS#11 keystore. so the removable media can be removed later if required. This keystore requires authentication to create and use keys stored in it.file:///media/stick/passkey tank/project/B In the examples above. The keysource property is how we specify the format and location of the key. They are used to decrypt the actual data encryption keys for a data set. The wrapping key can be changed at any time.pkcs11:object=mykey tank/project/C Enter PKCS#11 token PIN for 'tank/project/C': In the example above. so instead we need to get the key via noninteractive means from somewhere else. it is assumed that the other file system is sufficiently secure by other means. Instead the administrator manages the wrapping key. the raw key file and the passphrase file must already exist. This probably isn't ideal in most data center deployments.file:///media/stick/mykey tank/project/A # zfs create -o encryption=on -o keysource=passphrase. Note that if we are using a file. ZFS can provide for both local and centralized key management as well as the delegation of wrapping key changes and changes of the key type.192. it is also possible to store the wrapping keys in a secure keystore that is accessible from the Oracle Solaris Cryptographic Framework using the PKCS#11 API. # zfs create -o encryption=on -o keysource=raw. it must be specified as a file:// style URI. if you specify no key management policy. The administrator never has access to the data encryption keys. ZFS will prompt interactively for a passphrase. such as being on a removable disk. the system creates a new (randomly generated) data encryption key.Managing Encryption Keys When we create an encrypted file system with ZFS. Wrapping keys are AES keys of 128. The simplest noninteractive method is to store the wrapping key or passphrase in a file and tell ZFS what file to look in for that key. Oracle Solaris provides a local encrypted keystore via softtoken. # pktool genkey keystore=pkcs11 keytype=aes keylen=128 label=mykey Enter PIN for Sun Software PKCS#11 softtoken: # zfs create -o encryption=on -o keysource=raw. we created an AES key in the default softtoken keystore for the user. To provide some additional protection for the wrapping keys.256 bits. The wrapping key can come from a number of different places depending on what type of encryption and key management policy is desired for the system.

it might be more desirable to have a centralized key management system that provides for the unattended reboot of servers with ZFS-encrypted file systems and also for centralized control over a wrapping key's lifetime.example. the syntax looks very similar to the previous example with the local softtoken except the key material is actually stored and managed on the remote system. Let's go back to our original simple example and change the key: $ zfs key -c rpool/export/project Enter new passphrase for 'rpool/export/project': Note that ZFS did not prompt for the current passphrase.pem /etc/certs/CA/ # svcadm refresh ca-certificates How to Change Wrapping Keys The wrapping key can be changed for a data set hierarchy at any time after it has initially been created or mounted. The first is to use a remote key management system. This allows for online migration between local and remote key management even after there is data in the file system. It also knows the user who is authorized to change the wrapping tank/project/R The Web service can be accessed over HTTP or HTTPS. ZFS provides two methods of remote key management. such as the Oracle Key Manager system. that is made accessible to Oracle Solaris via a PKCS#11 token. ZFS provides the ability to start using new data encryption keys for newly written data at any point in time. because the file system is already mounted and ZFS knows the wrapping key. This allows for managing both wrapping keys and data encryption keys in a way that is compliant with NIST SP800-57 key lifetime. It is also possible to change the format and location of the wrapping key at the same time its value is changed. this requires that the X. In this case. How to Change Data Encryption Keys In addition to being able to change the wrapping key (which is used only for encrypting the data encryption keys). Oracle Solaris allows augmenting the standard list of certificates as follows: # cp myservercert.509 certificate used by the Web service for SSL/TLS be signed by one of the known CA certificates or that it be a known self-signed certificate. ZFS uses libcurl and OpenSSL to access the Web service. The other method of providing centralized key management is via Web services.https://keys.How to Manage Encryption Keys Remotely In some cases. Changing the wrapping key doesn't re-encrypt any data on disk and it is done atomically for all data sets that inherit the wrapping key. for example: # zfs create -o encryption=on -o keysource=raw. ZFS can get the wrapping key or passphrase from any Web service that supports a simple GET request on a URI. # zfs key -K tank/project/A # zfs clone -K tank/project/C@snap-1 tank/project/D .

One reason you might want to select aes-128-gcm rather than aes-128-ccm is that GCM is one of the modes for AES in NSA Suite B. and keysource. and T4 processors and on Intel processors with the AES-NI extension. # zfs allow -u bob keychange tank/project/C The example above allows the user bob to change the wrapping key value for the data set and its children but not to change the keysource property. and T4 processors also accelerate the SHA256 checksum that is always used for data and metadata when encryption is enabled on a ZFS data set. The root user (and the system boot itself) has all ZFS delegations. T3. There are separate ZFS delegations for using and changing keys as well as changing the format and location of the wrapping key: key. Using combinations of these delegations. T3. Both AES CCM and AES GCM are provided so that if one turns out to have flaws —and modes of an encryption algorithm sometimes do have flaws independent of the base algorithm —the other will still be available for use safely. Note also in this case that user bob can't actually mount the ZFS data set after boot nor can he force unload the data set and its keys. How to Choose the Encryption Property Value The on value for the ZFS encryption property maps to aes-128-ccm. Other users might be authorized to change the value of a wrapping key but not to use it and they might or might not be authorized to change its location (for example.rekeydate tank/project/A NAME tank/project/A tank/project/A PROPERTY creation rekeydate VALUE Thu Oct Thu Nov 6 12:10 2011 9 11:01 2011 SOURCE local How to Delegate Key Management The ZFS delegation system provides a mechanism for allowing users to perform certain actions on ZFS data sets. Depending on the file system or ZVOL workload. . The SPARC T2. all encryption for ZFS is hardware accelerated. but we explicitly request that all data that is unique to the clone be written with a new data encryption key. you might not be able to notice (or you might not care. In the second example above. ZFS encryption was designed and implemented to be extensible to new algorithm/mode combinations for data encryption and key wrapping. On Oracle's SPARC T2. keychange. aes-192ccm. we create a new file system by cloning an existing snapshot. if you do notice) the difference between the AES key lengths and modes.In the first example above. The time of the last data encryption key change is stored in the read-only rekeydate property: $ zfs get creation. between local and remote key management styles). we change the data encryption key for all new data that is written after this point in time for the tank/project/A file system. is it possible to build a key escrow system where certain users are authorized to know and use the wrapping key for a data set but not to change the value or location. because that is the fastest of the six available modes of encryption currently provided and it is believed to provide sufficient security for many deployments. The other reason to choose between CCM and GCM modes is that only the CCM modes ( aes-128-ccm. and aes-256-ccm) allow for combining ZFS encryption and deduplication.

07/23/2012 . if zfs key -K and zfs clone -K are not used). Conclusion Much more can be done with ZFS encryption. which contains posts about ZFS and cryptography And here are some additional resources:        Download Oracle Solaris 11 Access Oracle Solaris 11 product documentation Access all Oracle Solaris 11 how-to articles Learn more with Oracle Solaris 11 training and support See the official Oracle Solaris blog Check out The Observatory and OTN Garage blogs for Oracle Solaris tips and tricks Follow Oracle Solaris on Facebook and Twitter About the Author Darren is a Senior Principal Engineer in the Solaris Core Technologies group. and data deduplication. Prior to that. where he had been in the Solaris development organization for 12 years. cryptography. He joined Oracle as part of the Sun acquisition. and only if the data encryption keys are not changed (that is. See Also For more information on ZFS and encryption please see the following resources:    Oracle Solaris Administration: ZFS File Systems Oracle Solaris 11 ZFS Technology Spotlight page Darren Moffat's blog. Darren worked in SunService supporting Trusted Solaris and other Solaris security functionality. Prior to Sun.Encrypted data will be deduplicated only within a file system or a clone of that file system. He was also the architect and lead developer for the encryption functionality in ZFS. ZFS encryption is fully integrated into the ZFS storage system and administration tools. Revision 1. Darren worked for the UK Ministry of Defence.0. He is a graduate of the Computing Science Department at the University of Glasgow (Scotland). including combining encryption. It is even possible to provide completely transparent encryption for Oracle Solaris Zones. compression. and application containment. He is one of the architects for Oracle Solaris Security and focuses on authentication.