HSM Key Management

AIStor Key Manager uses a software-defined Hardware Security Module (HSM) key to protect the encryption key database. Each HSM has a corresponding generated Root Encryption Key (REK) used to seal or unseal the encryption key database. The following diagram describes the process of ‘unsealing’ the encryption key database using the HSM:

K e y D a t a b a s e R D e e a c d r y e p n t c r D y B p t w e i d t h R o R o o t o t K e K y e y K e y M a n a g e r P R l e a q i u n e t s e t x t d e R c o r o y t p t K i e o y n E x t e r n a l K M S

Key Manager cannot successfully unseal the key database without access to at least one configured HSM. Deleting all HSMs is therefore a destructive process, and is irreversible without HSM backups. If no HSM keys remain available for access, all encrypted keys and by association all encrypted data becomes permanently unreadable.

The Key Manager handles all generation and management of REKs. Users only need to ensure the availability of an HSM key on the configured provider.

Configuring multiple HSM keys

Key Manager supports configuration and storage of multiple HSM keys on the following Key Management Services (KMS):

Each node in the deployment can use any configured KMS to retrieve the HSM key and seal/unseal REK and key database. Configuring multiple HSM keys ensures that the downtime or unavailability of one HSM source does not prevent normal operations on the cluster.

Adding external KMS providers does not necessarily increase the overall security of the system. A cluster using the local filesystem for HSM storage may be more secure in comparison to a remote KMS with weak access protections. Implementation of standard security measures around user access, privilege, and usage audits can have a more practical effect on increasing system security compared to adding several links to a KMS chain.

Internode and root API access

Key Manager uses a configured HSM to deterministically generate an API key for use with internode authentication. Without an explicit root or superadmin identity in the config file, it also uses the HSM to generate a root or superadmin key for the purpose of client operations. All nodes in a Key Manager deployment must have matching HSM configurations to ensure consistent API key generation. Key Manager prints the API key to the system log at startup.

For deployments with multiple configured HSM keys, Key Manager uses a deterministic algorithm to select which HSM to use as the “primary” for the purpose of generating the API Key.

Applications which rely on the generated root or superadmin API key may encounter auth/authz issues after adding or removing an HSM as a result of this behavior. You can instead create an explicit root or superadmin API key in the configuration file using the admin.identity key.