A trend that I’ve discovered as I work with hardware security modules (HSMs) is that the systems with the highest level of claimed security ultimately reduce key management to a physical problem. That is, credentials that are used to expose key material to applications are password or PIN protected physical devices (smart cards, USB tokens and the like). This approach does make sense since theoretically such tokens are impervious to attacks that can be used against typical password based authentication systems. However, physical key management introduces it’s own problems.

First, it’s much easier to lose physical keys than it is to forget critical system passwords (assuming a robust password management system is in place). Loss of physical keys renders some or all of the HSM contents unusable to applications. Therefore, when setting up a HSM to prepare it for use by applications, it’s critical to make backups of your physical keys. The approach I recommend to clients is to identify at least 2 system owners that will act as key custodians for the physical keys. In addition to the keys that are assigned to system owners, a third and possible fourth set of keys are created for disaster recovery or for unlikely scenarios such as the two system owners simultaneously winning the lottery! Passwords or PINs used to access the material stored on the physical keys need to be protected as any other high value system password needs to be. For backup material, I always recommend that a slip of paper with the PIN/password used by the physical keys be stored directly with the keys in a tamper evident bag that is locked away in a safe (along with backup media that stores copies of the key material stored on the HSM itself of course!)

Another concern with physical key management is ensuring that all copies of keys are carefully inventoried and controlled. Unfortunately, I have found that this is much easier said than done and that you are better off designing your system under the assumption that there will be duplicate physical keys made that you will lose track of. The best defense against uncontrolled key material is to ensure that additional credentials/keys are necessary in order to use a duplicated key. The method that I recommend to clients using HSMs that support this feature is to require MofN authentication, otherwise known as witness keys. Witness keys are basically additional physical keys that all need to be presented together with a master key in order to gain access to HSM contents. The intent is that there would need to be collusion between multiple parties to actually make use of any single set of duplicated key material.

The last concern that I’ll discuss in this post are the responsibilities associated with being a physical key custodian. Obviously, anyone who is assigned a physical key needs to take all possible precautions to protect against the loss of their key and report it’s loss as soon as possible to system owners. Assuming that good backups are in place, it is relatively simple to replace a lost key. Perhaps a more important role, however, is to always question why their physical keys are needed for accessing the system. Applications which use HSMs for key storage can generally be configured to require physical keys to be used to unlock the HSM for each key access or to permit the HSM to be unlocked for a period of time while key access is required. The method and frequency of access to the HSM must be understood by all key holders (including witness key holders) so that out of the ordinary requests for presenting physical keys to the HSM can be detected.

As with any other security control, HSMs using physical keys can greatly reduce an organization’s risk, but only if solid operational processes are in place.