Protection of CLDB and DARE Master Keys

This section describes how the CLDB key and DARE master keys are encrypted and stored during normal operations.

The following table specifies the location of the the cldb.key and dare.master.key for Data Fabric with and without HSM integration.

Data Fabric version Location of cldb.key/dare.master.key cldb.key/dare.master.key generation/security mechanism
Data Fabric version 6.2.0 or earlier without HSM integration /opt/mapr/conf/ folder

The keys are protected by the file level permission with Mode bits.

The CLDB key is encrypted using a weak hard-coded key and stored in Base-64 format in ${MAPR_HOME}/conf/cldb.key. The DARE master key is stored in clear text in hexadecimal format in ${MAPR_HOME}/conf/dare.master.key. The files must be encrypted and protected using FIPS-approved algorithms.
Data Fabric 6.2.0 with external HSM integration stored as part of the /opt/mapr/conf/tokens folder. The keys are encrypted with HSM encryption keys
Data Fabric version 7.0.0 and later without explicit enterprise HSM integration /opt/mapr/conf/tokens folder The keys are generated as part of the configure.sh -genkeys option , and are encrypted using cryptographic keys generated from HSM.
NOTE
By default, Data Fabric simulates file-based HSM locally.
Data Fabric version 7.0.0 and later explicitly integrated with enterprise HSM /opt/mapr/conf/tokens folder in encrypted form. The cryptographic keys that are used for encryption of the cldb.key or the dare.master.key lifecycle are managed by the enterprise HSM. The dare.master.key and cldb.key files are protected by using KMIP.
NOTE
It is important to note that dare.master.key is generated only when data-at-rest-encryption (DARE) is enabled at cluster level. In MFS Only node, the dare.master.key will be created as a zero KB file.

When DARE is enabled at cluster level by passing -cldb -dare -genkeys option as part of the configure.sh script, it generates cldb.key/dare.master.key and encrypts them and store in /opt/mapr/conf/tokens folder. It is not required to copy the tokens folder to nodes that are not running the cldb service or the zookeeper service. On MFS only nodes, a 0 kb dare.master.key gets automatically generated as part of the configure.sh -dare option while adding node to cluster. It is not required to create a dare.master.key explicitly on nodes that are not running the cldb service or the zookeeper service.

IMPORTANT
While upgrading from 6.x to 7.x, back up the /opt/mapr/conf/token folder. If the /opt/mapr/conf/token folder is accidentally deleted, the cluster or fabric can be restored from the backed up /opt/mapr/conf/token folder.

In case of upgrade of Cluster from 6.2.x to 7.x , the deployments still contain cldb.key/dare.master.key. As part of the cluster upgrade, the token folder is generated and it encrypts the cldb.key or dare.master.key.

For information on mrhsm commands, see mrhsm commands.

Note these important considerations:

  • Instead of backing up the cldb.key and dare.master.key as recommended in previous versions, you are encouraged to back up the ${MAPR_HOME}/conf/tokens directory as well as the ${MAPR_HOME}/conf/maprhsm.conf file. These are both essential to retrieve the keys.
  • During the configuration, you must copy the ${MAPR_HOME}/conf/tokens directory and the ${MAPR_HOME}/conf/maprhsm.conf file to all CLDB nodes and Zookeeper nodes, instead of merely copying the cldb.key and dare.master.key files.
  • On MFS only nodes a dare.master.key file of size 0 KB gets generate automatically as part of the configure.sh -dare option while adding node to cluster. MFS-only nodes still need an empty ${MAPR_HOME}/conf/dare.master.key file to detect that DARE is enabled. This file does NOT need to contain the actual key. It is NOT required to create dare.master.key explicitly on nodes that are not running the CLDB service or Zookeeper service.
  • During an upgrade, the cldb.key and dare.master.key are left intact and untouched even though we expect to have them stored in the PKCS#11 file store. It is a best practice to remove them from the node and store them in a safe location in case they are needed again.