TSB System Keys
The TSB automatically creates a number of keys on your HSM partition. This page explains what these keys are and what they are used for.
| Config option | Default key label | Purpose |
|---|---|---|
hsm.backupKeyName | approver-mgmt-backup-key-rsa-wrapping | Used for encrypting the approver keys that are managed by this TSB, before backing them up in the database. This is an SKA key. By default, its policy is empty. You may manually assign a policy to better protect this key. However, you will need to manage the approver keys of this SKA key externally (otherwise there is a circular dependency). |
hsm.attestationKeyName | attestation-key | Used for signing key attestations. Has the "attestation" key attribute set. |
hsm.rfcTimestampKeyName | rfc-timestamp-key | Used for signing trusted timestamps following RFC 3161. Uses the new "timestamp" key attribute. |
hsm.timestampKeyName | timestamp-key | Used for signing timestamps in SKA workflows that use timelocks or timeouts. Uses the old "integrity" key attribute. |
These keys (in particular the attestation key) are why the TSB requires the Root Key Store to be set up on the HSM (as described in the installation guide).
Do I need these keys?
The attestationKeyName and the timestampKeyName are always required.
The backupKeyName and the rfcTimestampKeyName are optional.
If you don't want to use these features, you can comment out or remove the config field.
Then the TSB will not try to create or access these keys, and their corresponding features will be disabled.
This may be necessary if your HSM license does not include these features
(which causes their key generation to fail, thus causing the TSB to fail to start).
What if I delete these keys?
Do not delete these keys manually!
Without the attestationKeyName most REST API functionality (such as listing keys) is impaired.
Without the backupKeyName you risk losing access to the encrypted approver key backups.
If you have accidentally deleted these keys, the TSB automatically tries to create new keys. If key invalidation is disabled on your partition, this should succeed immediately. If key invalidation is enabled, the TSB's attempt to recreate the keys will fail, because the key labels are still present (albeit marked as deleted). In this case, the HSM administrator (SO or PSO) can help you reactivate the keys.