Native Encryption for ZFS on Linux
This change incorporates three major pieces:
The first change is a keystore that manages wrapping
and encryption keys for encrypted datasets. These
commands mostly involve manipulating the new
DSL Crypto Key ZAP Objects that live in the MOS. Each
encrypted dataset has its own DSL Crypto Key that is
protected with a user's key. This level of indirection
allows users to change their keys without re-encrypting
their entire datasets. The change implements the new
subcommands "zfs load-key", "zfs unload-key" and
"zfs change-key" which allow the user to manage their
encryption keys and settings. In addition, several new
flags and properties have been added to allow dataset
creation and to make mounting and unmounting more
convenient.
The second piece of this patch provides the ability to
encrypt, decyrpt, and authenticate protected datasets.
Each object set maintains a Merkel tree of Message
Authentication Codes that protect the lower layers,
similarly to how checksums are maintained. This part
impacts the zio layer, which handles the actual
encryption and generation of MACs, as well as the ARC
and DMU, which need to be able to handle encrypted
buffers and protected data.
The last addition is the ability to do raw, encrypted
sends and receives. The idea here is to send raw
encrypted and compressed data and receive it exactly
as is on a backup system. This means that the dataset
on the receiving system is protected using the same
user key that is in use on the sending side. By doing
so, datasets can be efficiently backed up to an
untrusted system without fear of data being
compromised.
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Jorgen Lundman <lundman@lundman.net>
Signed-off-by: Tom Caputi <tcaputi@datto.com>
Closes #494
Closes #5769
2017-08-14 20:36:48 +03:00
|
|
|
/*
|
|
|
|
* CDDL HEADER START
|
|
|
|
*
|
|
|
|
* This file and its contents are supplied under the terms of the
|
|
|
|
* Common Development and Distribution License ("CDDL"), version 1.0.
|
|
|
|
* You may only use this file in accordance with the terms of version
|
|
|
|
* 1.0 of the CDDL.
|
|
|
|
*
|
|
|
|
* A full copy of the text of the CDDL should have accompanied this
|
|
|
|
* source. A copy of the CDDL is also available via the Internet at
|
|
|
|
* http://www.illumos.org/license/CDDL.
|
|
|
|
*
|
|
|
|
* CDDL HEADER END
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Copyright (c) 2017, Datto, Inc. All rights reserved.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef _SYS_ZIO_CRYPT_H
|
|
|
|
#define _SYS_ZIO_CRYPT_H
|
|
|
|
|
|
|
|
#include <sys/dmu.h>
|
|
|
|
#include <sys/refcount.h>
|
|
|
|
#include <sys/crypto/api.h>
|
|
|
|
#include <sys/nvpair.h>
|
|
|
|
#include <sys/avl.h>
|
|
|
|
#include <sys/zio.h>
|
|
|
|
|
|
|
|
/* forward declarations */
|
|
|
|
struct zbookmark_phys;
|
|
|
|
|
|
|
|
#define WRAPPING_KEY_LEN 32
|
|
|
|
#define WRAPPING_IV_LEN ZIO_DATA_IV_LEN
|
2017-09-12 23:15:11 +03:00
|
|
|
#define WRAPPING_MAC_LEN ZIO_DATA_MAC_LEN
|
Native Encryption for ZFS on Linux
This change incorporates three major pieces:
The first change is a keystore that manages wrapping
and encryption keys for encrypted datasets. These
commands mostly involve manipulating the new
DSL Crypto Key ZAP Objects that live in the MOS. Each
encrypted dataset has its own DSL Crypto Key that is
protected with a user's key. This level of indirection
allows users to change their keys without re-encrypting
their entire datasets. The change implements the new
subcommands "zfs load-key", "zfs unload-key" and
"zfs change-key" which allow the user to manage their
encryption keys and settings. In addition, several new
flags and properties have been added to allow dataset
creation and to make mounting and unmounting more
convenient.
The second piece of this patch provides the ability to
encrypt, decyrpt, and authenticate protected datasets.
Each object set maintains a Merkel tree of Message
Authentication Codes that protect the lower layers,
similarly to how checksums are maintained. This part
impacts the zio layer, which handles the actual
encryption and generation of MACs, as well as the ARC
and DMU, which need to be able to handle encrypted
buffers and protected data.
The last addition is the ability to do raw, encrypted
sends and receives. The idea here is to send raw
encrypted and compressed data and receive it exactly
as is on a backup system. This means that the dataset
on the receiving system is protected using the same
user key that is in use on the sending side. By doing
so, datasets can be efficiently backed up to an
untrusted system without fear of data being
compromised.
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Jorgen Lundman <lundman@lundman.net>
Signed-off-by: Tom Caputi <tcaputi@datto.com>
Closes #494
Closes #5769
2017-08-14 20:36:48 +03:00
|
|
|
#define MASTER_KEY_MAX_LEN 32
|
2017-09-12 23:15:11 +03:00
|
|
|
#define SHA512_HMAC_KEYLEN 64
|
Native Encryption for ZFS on Linux
This change incorporates three major pieces:
The first change is a keystore that manages wrapping
and encryption keys for encrypted datasets. These
commands mostly involve manipulating the new
DSL Crypto Key ZAP Objects that live in the MOS. Each
encrypted dataset has its own DSL Crypto Key that is
protected with a user's key. This level of indirection
allows users to change their keys without re-encrypting
their entire datasets. The change implements the new
subcommands "zfs load-key", "zfs unload-key" and
"zfs change-key" which allow the user to manage their
encryption keys and settings. In addition, several new
flags and properties have been added to allow dataset
creation and to make mounting and unmounting more
convenient.
The second piece of this patch provides the ability to
encrypt, decyrpt, and authenticate protected datasets.
Each object set maintains a Merkel tree of Message
Authentication Codes that protect the lower layers,
similarly to how checksums are maintained. This part
impacts the zio layer, which handles the actual
encryption and generation of MACs, as well as the ARC
and DMU, which need to be able to handle encrypted
buffers and protected data.
The last addition is the ability to do raw, encrypted
sends and receives. The idea here is to send raw
encrypted and compressed data and receive it exactly
as is on a backup system. This means that the dataset
on the receiving system is protected using the same
user key that is in use on the sending side. By doing
so, datasets can be efficiently backed up to an
untrusted system without fear of data being
compromised.
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Jorgen Lundman <lundman@lundman.net>
Signed-off-by: Tom Caputi <tcaputi@datto.com>
Closes #494
Closes #5769
2017-08-14 20:36:48 +03:00
|
|
|
|
2017-11-08 22:12:59 +03:00
|
|
|
#define ZIO_CRYPT_KEY_CURRENT_VERSION 1ULL
|
|
|
|
|
Native Encryption for ZFS on Linux
This change incorporates three major pieces:
The first change is a keystore that manages wrapping
and encryption keys for encrypted datasets. These
commands mostly involve manipulating the new
DSL Crypto Key ZAP Objects that live in the MOS. Each
encrypted dataset has its own DSL Crypto Key that is
protected with a user's key. This level of indirection
allows users to change their keys without re-encrypting
their entire datasets. The change implements the new
subcommands "zfs load-key", "zfs unload-key" and
"zfs change-key" which allow the user to manage their
encryption keys and settings. In addition, several new
flags and properties have been added to allow dataset
creation and to make mounting and unmounting more
convenient.
The second piece of this patch provides the ability to
encrypt, decyrpt, and authenticate protected datasets.
Each object set maintains a Merkel tree of Message
Authentication Codes that protect the lower layers,
similarly to how checksums are maintained. This part
impacts the zio layer, which handles the actual
encryption and generation of MACs, as well as the ARC
and DMU, which need to be able to handle encrypted
buffers and protected data.
The last addition is the ability to do raw, encrypted
sends and receives. The idea here is to send raw
encrypted and compressed data and receive it exactly
as is on a backup system. This means that the dataset
on the receiving system is protected using the same
user key that is in use on the sending side. By doing
so, datasets can be efficiently backed up to an
untrusted system without fear of data being
compromised.
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Jorgen Lundman <lundman@lundman.net>
Signed-off-by: Tom Caputi <tcaputi@datto.com>
Closes #494
Closes #5769
2017-08-14 20:36:48 +03:00
|
|
|
typedef enum zio_crypt_type {
|
|
|
|
ZC_TYPE_NONE = 0,
|
|
|
|
ZC_TYPE_CCM,
|
|
|
|
ZC_TYPE_GCM
|
|
|
|
} zio_crypt_type_t;
|
|
|
|
|
|
|
|
/* table of supported crypto algorithms, modes and keylengths. */
|
|
|
|
typedef struct zio_crypt_info {
|
|
|
|
/* mechanism name, needed by ICP */
|
|
|
|
crypto_mech_name_t ci_mechname;
|
|
|
|
|
|
|
|
/* cipher mode type (GCM, CCM) */
|
|
|
|
zio_crypt_type_t ci_crypt_type;
|
|
|
|
|
|
|
|
/* length of the encryption key */
|
|
|
|
size_t ci_keylen;
|
|
|
|
|
|
|
|
/* human-readable name of the encryption alforithm */
|
|
|
|
char *ci_name;
|
|
|
|
} zio_crypt_info_t;
|
|
|
|
|
|
|
|
extern zio_crypt_info_t zio_crypt_table[ZIO_CRYPT_FUNCTIONS];
|
|
|
|
|
|
|
|
/* in memory representation of an unwrapped key that is loaded into memory */
|
|
|
|
typedef struct zio_crypt_key {
|
|
|
|
/* encryption algorithm */
|
|
|
|
uint64_t zk_crypt;
|
|
|
|
|
2017-11-08 22:12:59 +03:00
|
|
|
/* on-disk format version */
|
|
|
|
uint64_t zk_version;
|
|
|
|
|
Native Encryption for ZFS on Linux
This change incorporates three major pieces:
The first change is a keystore that manages wrapping
and encryption keys for encrypted datasets. These
commands mostly involve manipulating the new
DSL Crypto Key ZAP Objects that live in the MOS. Each
encrypted dataset has its own DSL Crypto Key that is
protected with a user's key. This level of indirection
allows users to change their keys without re-encrypting
their entire datasets. The change implements the new
subcommands "zfs load-key", "zfs unload-key" and
"zfs change-key" which allow the user to manage their
encryption keys and settings. In addition, several new
flags and properties have been added to allow dataset
creation and to make mounting and unmounting more
convenient.
The second piece of this patch provides the ability to
encrypt, decyrpt, and authenticate protected datasets.
Each object set maintains a Merkel tree of Message
Authentication Codes that protect the lower layers,
similarly to how checksums are maintained. This part
impacts the zio layer, which handles the actual
encryption and generation of MACs, as well as the ARC
and DMU, which need to be able to handle encrypted
buffers and protected data.
The last addition is the ability to do raw, encrypted
sends and receives. The idea here is to send raw
encrypted and compressed data and receive it exactly
as is on a backup system. This means that the dataset
on the receiving system is protected using the same
user key that is in use on the sending side. By doing
so, datasets can be efficiently backed up to an
untrusted system without fear of data being
compromised.
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Jorgen Lundman <lundman@lundman.net>
Signed-off-by: Tom Caputi <tcaputi@datto.com>
Closes #494
Closes #5769
2017-08-14 20:36:48 +03:00
|
|
|
/* GUID for uniquely identifying this key. Not encrypted on disk. */
|
|
|
|
uint64_t zk_guid;
|
|
|
|
|
|
|
|
/* buffer for master key */
|
|
|
|
uint8_t zk_master_keydata[MASTER_KEY_MAX_LEN];
|
|
|
|
|
|
|
|
/* buffer for hmac key */
|
|
|
|
uint8_t zk_hmac_keydata[SHA512_HMAC_KEYLEN];
|
|
|
|
|
|
|
|
/* buffer for currrent encryption key derived from master key */
|
|
|
|
uint8_t zk_current_keydata[MASTER_KEY_MAX_LEN];
|
|
|
|
|
|
|
|
/* current 64 bit salt for deriving an encryption key */
|
|
|
|
uint8_t zk_salt[ZIO_DATA_SALT_LEN];
|
|
|
|
|
|
|
|
/* count of how many times the current salt has been used */
|
|
|
|
uint64_t zk_salt_count;
|
|
|
|
|
|
|
|
/* illumos crypto api current encryption key */
|
|
|
|
crypto_key_t zk_current_key;
|
|
|
|
|
|
|
|
/* template of current encryption key for illumos crypto api */
|
|
|
|
crypto_ctx_template_t zk_current_tmpl;
|
|
|
|
|
|
|
|
/* illumos crypto api current hmac key */
|
|
|
|
crypto_key_t zk_hmac_key;
|
|
|
|
|
|
|
|
/* template of hmac key for illumos crypto api */
|
|
|
|
crypto_ctx_template_t zk_hmac_tmpl;
|
|
|
|
|
|
|
|
/* lock for changing the salt and dependant values */
|
|
|
|
krwlock_t zk_salt_lock;
|
|
|
|
} zio_crypt_key_t;
|
|
|
|
|
|
|
|
void zio_crypt_key_destroy(zio_crypt_key_t *key);
|
|
|
|
int zio_crypt_key_init(uint64_t crypt, zio_crypt_key_t *key);
|
|
|
|
int zio_crypt_key_get_salt(zio_crypt_key_t *key, uint8_t *salt_out);
|
|
|
|
|
|
|
|
int zio_crypt_key_wrap(crypto_key_t *cwkey, zio_crypt_key_t *key, uint8_t *iv,
|
|
|
|
uint8_t *mac, uint8_t *keydata_out, uint8_t *hmac_keydata_out);
|
2017-11-08 22:12:59 +03:00
|
|
|
int zio_crypt_key_unwrap(crypto_key_t *cwkey, uint64_t crypt, uint64_t version,
|
|
|
|
uint64_t guid, uint8_t *keydata, uint8_t *hmac_keydata, uint8_t *iv,
|
|
|
|
uint8_t *mac, zio_crypt_key_t *key);
|
Native Encryption for ZFS on Linux
This change incorporates three major pieces:
The first change is a keystore that manages wrapping
and encryption keys for encrypted datasets. These
commands mostly involve manipulating the new
DSL Crypto Key ZAP Objects that live in the MOS. Each
encrypted dataset has its own DSL Crypto Key that is
protected with a user's key. This level of indirection
allows users to change their keys without re-encrypting
their entire datasets. The change implements the new
subcommands "zfs load-key", "zfs unload-key" and
"zfs change-key" which allow the user to manage their
encryption keys and settings. In addition, several new
flags and properties have been added to allow dataset
creation and to make mounting and unmounting more
convenient.
The second piece of this patch provides the ability to
encrypt, decyrpt, and authenticate protected datasets.
Each object set maintains a Merkel tree of Message
Authentication Codes that protect the lower layers,
similarly to how checksums are maintained. This part
impacts the zio layer, which handles the actual
encryption and generation of MACs, as well as the ARC
and DMU, which need to be able to handle encrypted
buffers and protected data.
The last addition is the ability to do raw, encrypted
sends and receives. The idea here is to send raw
encrypted and compressed data and receive it exactly
as is on a backup system. This means that the dataset
on the receiving system is protected using the same
user key that is in use on the sending side. By doing
so, datasets can be efficiently backed up to an
untrusted system without fear of data being
compromised.
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Jorgen Lundman <lundman@lundman.net>
Signed-off-by: Tom Caputi <tcaputi@datto.com>
Closes #494
Closes #5769
2017-08-14 20:36:48 +03:00
|
|
|
int zio_crypt_generate_iv(uint8_t *ivbuf);
|
|
|
|
int zio_crypt_generate_iv_salt_dedup(zio_crypt_key_t *key, uint8_t *data,
|
|
|
|
uint_t datalen, uint8_t *ivbuf, uint8_t *salt);
|
|
|
|
|
|
|
|
void zio_crypt_encode_params_bp(blkptr_t *bp, uint8_t *salt, uint8_t *iv);
|
|
|
|
void zio_crypt_decode_params_bp(const blkptr_t *bp, uint8_t *salt, uint8_t *iv);
|
|
|
|
void zio_crypt_encode_mac_bp(blkptr_t *bp, uint8_t *mac);
|
|
|
|
void zio_crypt_decode_mac_bp(const blkptr_t *bp, uint8_t *mac);
|
|
|
|
void zio_crypt_encode_mac_zil(void *data, uint8_t *mac);
|
|
|
|
void zio_crypt_decode_mac_zil(const void *data, uint8_t *mac);
|
|
|
|
void zio_crypt_copy_dnode_bonus(abd_t *src_abd, uint8_t *dst, uint_t datalen);
|
|
|
|
|
|
|
|
int zio_crypt_do_indirect_mac_checksum(boolean_t generate, void *buf,
|
|
|
|
uint_t datalen, boolean_t byteswap, uint8_t *cksum);
|
|
|
|
int zio_crypt_do_indirect_mac_checksum_abd(boolean_t generate, abd_t *abd,
|
|
|
|
uint_t datalen, boolean_t byteswap, uint8_t *cksum);
|
|
|
|
int zio_crypt_do_hmac(zio_crypt_key_t *key, uint8_t *data, uint_t datalen,
|
2017-09-12 23:15:11 +03:00
|
|
|
uint8_t *digestbuf, uint_t digestlen);
|
Native Encryption for ZFS on Linux
This change incorporates three major pieces:
The first change is a keystore that manages wrapping
and encryption keys for encrypted datasets. These
commands mostly involve manipulating the new
DSL Crypto Key ZAP Objects that live in the MOS. Each
encrypted dataset has its own DSL Crypto Key that is
protected with a user's key. This level of indirection
allows users to change their keys without re-encrypting
their entire datasets. The change implements the new
subcommands "zfs load-key", "zfs unload-key" and
"zfs change-key" which allow the user to manage their
encryption keys and settings. In addition, several new
flags and properties have been added to allow dataset
creation and to make mounting and unmounting more
convenient.
The second piece of this patch provides the ability to
encrypt, decyrpt, and authenticate protected datasets.
Each object set maintains a Merkel tree of Message
Authentication Codes that protect the lower layers,
similarly to how checksums are maintained. This part
impacts the zio layer, which handles the actual
encryption and generation of MACs, as well as the ARC
and DMU, which need to be able to handle encrypted
buffers and protected data.
The last addition is the ability to do raw, encrypted
sends and receives. The idea here is to send raw
encrypted and compressed data and receive it exactly
as is on a backup system. This means that the dataset
on the receiving system is protected using the same
user key that is in use on the sending side. By doing
so, datasets can be efficiently backed up to an
untrusted system without fear of data being
compromised.
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Jorgen Lundman <lundman@lundman.net>
Signed-off-by: Tom Caputi <tcaputi@datto.com>
Closes #494
Closes #5769
2017-08-14 20:36:48 +03:00
|
|
|
int zio_crypt_do_objset_hmacs(zio_crypt_key_t *key, void *data, uint_t datalen,
|
|
|
|
boolean_t byteswap, uint8_t *portable_mac, uint8_t *local_mac);
|
2018-05-03 01:36:20 +03:00
|
|
|
int zio_do_crypt_data(boolean_t encrypt, zio_crypt_key_t *key,
|
|
|
|
dmu_object_type_t ot, boolean_t byteswap, uint8_t *salt, uint8_t *iv,
|
|
|
|
uint8_t *mac, uint_t datalen, uint8_t *plainbuf, uint8_t *cipherbuf,
|
|
|
|
boolean_t *no_crypt);
|
|
|
|
int zio_do_crypt_abd(boolean_t encrypt, zio_crypt_key_t *key,
|
|
|
|
dmu_object_type_t ot, boolean_t byteswap, uint8_t *salt, uint8_t *iv,
|
|
|
|
uint8_t *mac, uint_t datalen, abd_t *pabd, abd_t *cabd,
|
Native Encryption for ZFS on Linux
This change incorporates three major pieces:
The first change is a keystore that manages wrapping
and encryption keys for encrypted datasets. These
commands mostly involve manipulating the new
DSL Crypto Key ZAP Objects that live in the MOS. Each
encrypted dataset has its own DSL Crypto Key that is
protected with a user's key. This level of indirection
allows users to change their keys without re-encrypting
their entire datasets. The change implements the new
subcommands "zfs load-key", "zfs unload-key" and
"zfs change-key" which allow the user to manage their
encryption keys and settings. In addition, several new
flags and properties have been added to allow dataset
creation and to make mounting and unmounting more
convenient.
The second piece of this patch provides the ability to
encrypt, decyrpt, and authenticate protected datasets.
Each object set maintains a Merkel tree of Message
Authentication Codes that protect the lower layers,
similarly to how checksums are maintained. This part
impacts the zio layer, which handles the actual
encryption and generation of MACs, as well as the ARC
and DMU, which need to be able to handle encrypted
buffers and protected data.
The last addition is the ability to do raw, encrypted
sends and receives. The idea here is to send raw
encrypted and compressed data and receive it exactly
as is on a backup system. This means that the dataset
on the receiving system is protected using the same
user key that is in use on the sending side. By doing
so, datasets can be efficiently backed up to an
untrusted system without fear of data being
compromised.
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Jorgen Lundman <lundman@lundman.net>
Signed-off-by: Tom Caputi <tcaputi@datto.com>
Closes #494
Closes #5769
2017-08-14 20:36:48 +03:00
|
|
|
boolean_t *no_crypt);
|
|
|
|
|
|
|
|
#endif
|