Trust Management

When secure data or keys must be transferred from one HSM to another through the process of token replication, trust management is required. Environments using Work Load Distribution (WLD) and High Availability (HA) are one example. Refer to Work Load Distribution Model and High Availability for details.

Currently, trust management is supported by SafeNet ProtectServer PCIe HSMs and SafeNet ProtectServer Network HSMs.

When a WLD system is configured, tokens must be replicated across all the HSM User slots associated with a common WLD virtual slot. It is essential that the token is deemed trustworthy before it is imported by the HSM; the token must come from a trustworthy source, and remain unaltered during transmission.

Public-key cryptography establishes trust between HSMs. Private keys are used for signing extracted information and unwrapping tokens. Public keys are used for wrapping tokens and verifying signed information. An RSA key-pair must be generated on the administrative token of each device. This key-pair is referred to as the local HSM Identity Key-Pair. The public half of the key-pair is termed the HSM Identity Public-Key, while the private portion is called the HSM Identity Private-Key. An HSM trusts another HSM when it holds the other's HSM Identity Public-Key in its administrative token. This is referred to as the peer HSM Identity Public-Key. Simple trust relationships shows an example of a system where simple trust relationships have been established between HSMs.

The arrows indicate the trust relationship. In this system, HSM A trusts HSM B. That is, HSM A holds the HSM Identity Public-Key of HSM B in its administrative token. However, HSM B does not trust HSM A. HSM B and HSM C share a relationship of mutual trust. In this system, token replication could only be performed between HSM B and HSM C (with either device originating the tokens), as token replication requires a relationship of mutual trust.

Figure 1: Simple trust relationships

Relationships of mutual trust shows a system where every HSM shares a relationship of mutual trust with every other HSM. In this scenario, token replication can be performed from any HSM to any other HSM on the system.

Figure 2: Relationships of mutual trust

Typically, when token replication is performed in a WLD configuration, an HSM is selected to hold the master tokens and tokens are then replicated to the other HSMs.

Trust relationships in a typical WLD/HA configuration illustrates a system in a typical WLD configuration. In this system, HSM A has been selected to hold the master tokens.

The arrows indicate the relationships of mutual trust between HSM A and the other HSMs that are necessary for token replication to be performed. The figure also illustrates that it is not necessary to establish trust among the HSMs that the tokens are replicated to, in other words, no trust need be established among HSM B, HSM C, HSM D and HSM E.

Figure 3: Trust relationships in a typical WLD/HA configuration

Complex trust topologies can be configured depending upon system and administrative requirements. Complex trust topology illustrates an example of a complex trust topology.

Figure 4: Complex trust topology

The ctident utility provides the mechanism for establishing, maintaining and removing trust relationships on HSMs. In an offline environment, the ctkmu utility can be used to import and export the HSM Identity Public-Keys.

The example in Establishing Trust Relationships shows how to establish trust among HSMs. The ctident utility can be used to display, check, and remove trust relationships. It can also be used to rollover the HSM identity keys used in trust management.