1. Managing ZFS File Systems in Oracle Solaris 11.4
  2. Managing Oracle Solaris ZFS File Systems
  3. Encrypting ZFS File Systems

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.

Note:

ZFS wrapping and data encryption keys use AES while Trusted Platform Module (TPM) support in Oracle Solaris 11 can only store RSA keys. Consequently, ZFS encryption can not use TPM as the root of trust for storing keys. As best practice, use a remote key management system instead of TPM, such as Oracle Key Management, Oracle Key Vault, or any third party product that supports the KMIP standard. For Oracle Key Manager documentation, see the Storage Encryption section in Tape Storage Products Documentation Library (https://docs.oracle.com/cd/F24623_01/index.html#crypto). For Oracle Key Vault documentation, see the Database Security section in https://docs.oracle.com/en/database/related-products.html.

You can set an encryption policy when a ZFS file system is created, but the policy cannot be changed. For example, the tank/home/megr 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/megr
Enter passphrase for 'tank/home/megr': xxxxxxx
Enter again: xxxxxxxx

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

$ zfs get encryption tank/home/megr
NAME              PROPERTY    VALUE        SOURCE
tank/home/megr  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: 

keysource=format,location

  • 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 ZFS 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 hexadecimal 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/megr@now
$ zfs clone tank/home/megr@now tank/home/megr-new
Enter passphrase for 'tank/home/megr-new': xxxxxxx
Enter again: xxxxxxxx
$ zfs set encryption=off tank/home/megr-new
cannot set property for 'tank/home/megr-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 Sending and Receiving an Encrypted ZFS File System.

Note:

Although ZFS encrypted filesystems can restrict access to data at rest, that protection is lost when the filesystem is mounted. Users who can assume the root role or use the sudo command can have unconstrained access to these files. To add a layer of security, use file and process labeling to implement access control especially to sensitive files. See Chapter 3, Labeling Files for Data Loss Protection in Securing Files and Verifying File Integrity in Oracle Solaris 11.4.