New ZFS Encryption features in Solaris 11.1

Solaris 11.1 brings a few small but significant improvements to ZFS dataset encryption.  There is a new readonly property 'keychangedate' that shows that date and time of the last wrapping key change (basically the last time 'zfs key -c' was run on the dataset), this is similar to the 'rekeydate' property that shows the last time we added a new data encryption key.

$ zfs get creation,keychangedate,rekeydate rpool/export/home/bob
NAME                   PROPERTY       VALUE                  SOURCE
rpool/export/home/bob  creation       Mon Mar 21 11:05 2011  -
rpool/export/home/bob  keychangedate  Fri Oct 26 11:50 2012  local
rpool/export/home/bob  rekeydate      Tue Oct 30  9:53 2012  local

The above example shows that we have changed both the wrapping key and added new data encryption keys since the filesystem was initially created.  If we haven't changed a wrapping key then it will be the same as the creation date.  It should be obvious but for filesystems that were created prior to Solaris 11.1 we don't have this data so it will be displayed as '-' instead.

Another change that I made was to relax the restriction that the size of the wrapping key needed to match the size of the data encryption key (ie the size given in the encryption property).  In Solaris 11 Express and Solaris 11 if you set encryption=aes-256-ccm we required that the wrapping key be 256 bits in length.  This restriction was unnecessary and made it impossible to select encryption property values with key lengths 128 and 192 when the wrapping key was stored in the Oracle Key Manager.  This is because currently the Oracle Key Manager stores AES 256 bit keys only.  Now with Solaris 11.1 this restriciton has been removed.

There is still one case were the wrapping key size and data encryption key size will always match and that is where they keysource property sets the format to be 'passphrase', since this is a key generated internally to libzfs and to preseve compatibility on upgrade from older releases the code will always generate a wrapping key (using PKCS#5 PBKDF2 as before) that matches the key length size of the encryption property.

The pam_zfs_key module has been updated so that it allows you to specify encryption=off.

There were also some bugs fixed including not attempting to load keys for datasets that are delegated to zones and some other fixes to error paths to ensure that we could support Zones On Shared Storage where all the datasets in the ZFS pool were encrypted that I discussed in my previous blog entry.

If there are features you would like to see for ZFS encryption please let me know (direct email or comments on this blog are fine, or if you have a support contract having your support rep log an enhancement request).




  

  


Comments:

Sounds very cool. I'd like to see these pushed back upstream to the ZFS project!

Posted by Magnus on October 30, 2012 at 05:36 PM GMT #

Darren - a couple of things I noticed going from 11 to 11.1 on my (small) test environments. First of all, whatever optimizations were made to sha256 and/or gzip (and crypto, but that again uses the sha256 checksums) causes ZFS to only use 1/2 the processor cores in the box. Extremely irritating, as it caps performance severely, especially considering these would be dedicated storage boxes. Using fletcher4, I see relatively normal throughput.

Another thing is about encrypted swap. I see very little out on the web about this, and even though a ZFS block device is used as swap (which should have encryption natively), lofi is always being interposed between the system and the ZFS block device. Why is this? lofi doesn't have near the performance of native ZFS crypto.

I'm trying to work out an approved solution with sales to get us on SPS so we have support, but I'd hate to spend so much time and effort and end up having a huge performance deficit.

Posted by guest on April 12, 2013 at 03:45 PM BST #

There is a set of changes to improve the CCM and GCM encryption modes for AES on Intel CPUs in development (Mentioned here too: https://blogs.oracle.com/BestPerf/entry/20130326_sparc_t5_2_zfscrypto). If you have a support contract please log an SR.

The interposing of lofi for encrypted swap is intentional at this time.

Posted by Darren J Moffat on May 08, 2013 at 10:32 AM BST #

Hi Darren,

I am using the ZFS encryption feature and wants to generate the keys on our Safenet Luna HSM. To do this I have searched the net but do not found anything that gives the idea to integrate third party HSM with ZFS. Couple of questions regarding the same are below:

1. Is ZFS support the third party HSM as I have seen it uses only Sun PKCS11 Softtoken?

2. If it is supported then how can we integrate our Luna HSM so that pktool and ZFS commands understand our HSM. I mean steps, so that we can generate the AES keys on Luna HSM and use those keys for ZFS data encryption.

Please help us.

Posted by guest on July 09, 2013 at 05:33 AM BST #

Hi Darren,

I am trying to generate the zfs encryption keys on Luna HSM using pktool and want to use those keys for zfs file encryption on Solaris 11.1 x86 platform. To do this I have searched a lot but have no luck. Currently ZFS support pksc11 but uses only Sun PKCS11 Softtoken. Please provide the answers of my question.

Is ZFS supports the third party HSM also. If yes how can we use our Luna HSM so that we can generate the keys using pktool and use those keys for zfs encryption?

Posted by Mohammad Arif on July 09, 2013 at 05:47 AM BST #

Post a Comment:
  • HTML Syntax: NOT allowed
About

DarrenMoffat

Search

Categories
Archives
« April 2014
MonTueWedThuFriSatSun
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today