Managing ZFS File Systems in Oracle® Solaris 11.2

Exit Print View

Updated: December 2014

Encrypting ZFS File Systems

Encryption is the process where data is encoded for privacy and a key is needed by the data owner to access the encoded data. The benefits of using ZFS encryption are as follows:

  • ZFS encryption is integrated with the ZFS command set. Like other ZFS operations, encryption operations such as key changes and rekey are performed online.

  • You can use your existing storage pools as long as they are upgraded. You have the flexibility of encrypting specific file systems.

  • Data is encrypted using AES (Advanced Encryption Standard) with key lengths of 128, 192, and 256 in the CCM and GCM operation modes.

  • ZFS encryption uses the Oracle Solaris Cryptographic Framework, which gives it access to any available hardware acceleration or optimized software implementations of the encryption algorithms automatically.

  • Currently, you cannot encrypt the ZFS root file system or other OS components, such as the /var directory, even if it is a separate file system.

  • ZFS encryption is inheritable to descendent file systems.

  • A regular user can create an encrypted file system and manage key operations if create, mount, keysource, checksum, and encryption permissions are assigned to him.

You can set an encryption policy when a ZFS file system is created, but the policy cannot be changed. For example, the tank/home/darren file system is created with the encryption property enabled. The default encryption policy is to prompt for a passphrase, which must be a minimum of 8 characters in length.

# zfs create -o encryption=on tank/home/darren
Enter passphrase for 'tank/home/darren': xxxxxxx
Enter again: xxxxxxxx

Confirm that the file system has encryption enabled. For example:

# zfs get encryption tank/home/darren
NAME              PROPERTY    VALUE        SOURCE
tank/home/darren  encryption  on           local

The default encryption algorithm is aes-128-ccm when a file system's encryption value is on.

A wrapping key is used to encrypt the actual data encryption keys. The wrapping key is passed from the zfs command, as in the above example when the encrypted file system is created, to the kernel. A wrapping key is either in a file (in raw or hex format) or it is derived from a passphrase.

The format and location of the wrapping key are specified in the keysource property as follows:

  • Format is one of the following:

    • raw – The raw key bytes

    • hex – A hexadecimal key string

    • passphrase – A character string that generates a key

  • Location is one of the following:

    • prompt – You are prompted for a key or a passphrase when the file system is created or mounted

    • file:///filename – The key or a passphrase file location in a file system

    • pkcs11 – A URI describing the location of a key or a passphrase in a PKCS#11 token

    • https://location – The key or a passphrase file location on a secure server. Transporting key information in the clear using this method is not recommended. A GET on the URL returns just the key value or the passphrase, according to what was requested in the format part of the keysource property.

      When using an https:// locator for the keysource, the certificate that the server presents must be one that is trusted by libcurl and OpenSSL. Add your own trust anchor or self signed certificate to the certificate store in /etc/openssl/certs. Place the PEM format certificate into the /etc/certs/CA directory and run the following command:

      # svcadm refresh ca-certificates

If the keysource format is passphrase, then the wrapping key is derived from the passphrase. Otherwise, the keysource property value points to the actual wrapping key, as raw bytes or in hexidecimal format. You can specify that the passphrase is stored in a file or stored in a raw stream of bytes that are prompted for, which is likely only suitable for scripting.

When a file system's keysource property values identifies passphrase, then the wrapping key is derived from the passphrase using PKCS#5 PBKD2 and a per file system randomly generated salt. This means that the same passphrase generates a different wrapping key if used on descendent file systems.

A file system's encryption policy is inherited by descendent file systems and cannot be removed. For example:

# zfs snapshot tank/home/darren@now
# zfs clone tank/home/darren@now tank/home/darren-new
Enter passphrase for 'tank/home/darren-new': xxxxxxx
Enter again: xxxxxxxx
# zfs set encryption=off tank/home/darren-new
cannot set property for 'tank/home/darren-new': 'encryption' is readonly

If you need to copy or migrate encrypted or unencrypted ZFS file systems, then consider the following points:

  • Currently, you cannot send an unencrypted dataset stream and receive it as an encrypted stream even if the receiving pool's dataset has encryption enabled.

  • You can use the following commands to migrate unencrypted data to a pool/file system with encryption enabled:

    • cp –r

    • find | cpio

    • tar

    • rsync

  • A replicated encrypted file system stream can be received into a encrypted file system and the data remains encrypted. For more information, see Example 5–4.