Native (Open-) ZFS encryption is in Illumos now

[gea]

Native Open-ZFS encryption is in Illumos since today
Topicbox

OmniOS:
omniosorg/Lobby
OpenIndiana
if illumos is at 0.5.11-2018.0.0.18656 or newer
(= current OpenIndiana 2019.05 after a pkg upgrade)

 

[gea]

Current OpenIndiana 2019.05 supports encryption after a
pkg upgrade

Then update your pool to support encryption
pkg upgrade pool

Then create a file with the key (ex 31 x 1)
echo 1111111111111111111111111111111 > /key.txt

Then create an encrypted filesystem ex enc on your "pool" based on that key
zfs create -o encryption=0n keyformat=raw -o keylocation=file:///key.txt pool/enc

Limitations:
Do not encrypt rpool (bootloader does not support this at the moment)
Keymanagement options are still limited

Documentation on Open-ZFS encryption is still quite limited
(beside Oracle Solaris, but their implementation is still more feature rich)
what I found is How-To: Using ZFS Encryption at Rest in OpenZFS (ZFS on Linux, ZFS on FreeBSD, ...) - Philipp's Tech Blog

 

[Stril]

Hi!

Great news.
Do you know, how this works exactly with zfs-send/receive?

Is it possible to have:
- unencrypted source
- to encrypted destination
...without having the destination zpool mounted (untrusted cloud-like-destination as backup)

 

[gea]

I have not yet tested all features
What I expect

unencrypted source -> encrypted target: only ok when target is unlocked
encrypted source -> any target without the -w: ok when source is unlocked
encrypted source (locked) -> unencrypred target with -w: creates a locked encrypted target filesystem without the need to enter the key for send

This raw option -w allows to backup encrypted filesystems to an unsecure backup location without the need to unlock the filesystem or even knowing the key. In this case the transfer and the resulting filesystem is encrypted and can be unlocked only with the key from the source filesystem.

see man zfs

       -w, --raw
           For encrypted datasets, send data exactly as it exists on disk.
           This allows backups to be taken even if encryption keys are not
           currently loaded.  The backup may then be received on an untrusted
           machine since that machine will not have the encryption keys to
           read the protected data or alter it without being detected.  Upon
           being received, the dataset will have the same encryption keys as
           it did on the send side, although the keylocation property will be
           defaulted to prompt if not otherwise provided.  For unencrypted
           datasets, this flag will be equivalent to -Lec.  Note that if you
           do not use this flag for sending encrypted datasets, data will be
           sent unencrypted and may be re-encrypted with a different
           encryption key on the receiving system, which will disable the
           ability to do a raw send to that system for incrementals.

 

[gea]

update
current napp-it 19.dev supports ZFS encryption on Illumos based systems with password prompt.

 

[gea]

From OmniOS-discuss

There was a bug in loader that if encryption was enabled even if not on
the Root dataset but like you on one in the rpool then loader would
refuse to load rpool.

Rhis has been fixed since then. Booting from encrypted dataset is still
not supported by loader as of today.

 

[gea]

OmniOS bloody 151031 now supports native ZFS encryption

napp-it 19.dev from today (jul 04) supports encryption
in menu ZFS filesystem (create, lock, unlock)