Using Hsm For Generating Keys - Red Hat CERTIFICATE SYSTEM 7.2 - ADMINISTRATION Administration Manual

NOTE
Stop the TKS instance before editing the configuration file.
To reference the security database, set the tokenname to internal. All numeric key identifiers in
mapping configurations must be suffixed with #01. #02 represents the master key version.
NOTE
Smart cards from the Axalto Web Store come with a default developer key set where all
keys are set to 404142434445464748494a4b4c4d4e4f. TKS has this key built-in, and
it is referred to with the master key set #01. TKS uses key set #01 by default.

8.4. Using HSM for Generating Keys

By default the TKS is configured to use the internal software token to generate and store its master
keys, but some deployments may require using a hardware security module (HSM) instead of the
software token.
To generate keys on HSMs, do the following:
1. Install the TKS subsystem.
2. After the TKS instance is configured, generate the TKS master key on the HSM using the
tksTool. By default during installation, the TKS master key is generated on the software token.
For example:
tksTool -M -n new_master -d /var/lib/rhpki-tks/alias -h nethsm
This generates a master key named new_master on the nethsm token for the rhpki-tks
instance.
For more information on using the tksTool, see the Certificate System Command-Line Tools
Guide.
3. Update the TKS instance's CS.cfg to contain the following values:
# useSoftToken tells whether to use software token or no. by default it's true,
# even if it's not settks.useSoftToken=false
# mk_mappings maps key version to key name on token name
# in this example, #02 is the version number, nethsm is the token name,
# and new_master is the key nametks.mk_mappings.#02#01=nethsm:new_master
It is not necessary to change the defaultSlot value; it can remain the default value for the
software database:
tks.defaultSlot=Internal Key Storage Token
Using HSM for Generating Keys
185