How do HSM Backups work?

When you make a backup (and authorize the backup by physically pressing the button on the HSM), the HSM encrypts all of its data using the following industry best practice process.

The HSM generates a unique (per backup) randomly generated AES 256-bit key to encrypt each backup - the OTK (the one time or ephemeral key).

The OTK is then wrapped (encrypted) using a FIPS approved AES 256-bit wrapping algorithm that conforms with NIST publication 800-38F (also see the equivalent rfc3394). The encrypted data includes the wrapped key.

To wrap the OTK, the HSM uses another AES 256-bit key derived using a FIPS approved key derivation function that complies with NIST special publication 800-108, specifically section 5.1 (KDF in Counter Mode).

Some of the inputs to the KDF are:

• A key programmed into the HSM firmware itself.
• A unique diversified backup key programmed into the secure element (tamper proof silicon) on the HSM during personalization of the HSM.

The effect of using a unique diversified key as input to the KDF is that a backup can only be restored to the same device OR to an HSM specifically prepared for a restore of the original by programming the same key into the secure silicon element. Devices sold in pairs are already prepared by the factory to have the same backup keys and are essentially clones of each other.

What is backed up?

When an HSM is initialized by the admin user, a unique storage key is generated derived from the admin user password. All objects marked as private (with attribute CKA_PRIVATE) are stored encrypted with the storage key. No password is stored on the HSM, rather a password based KDF is used (PBKDF2) to verify logins.

This means that even if the HSM is stolen and an attacker is able to extract the unreadable internal flash of the device - the storage is still encrypted.

The backup process described above wraps the encrypted storage as is, public data and settings to form the encrypted backup data.