Key Usage Mechanism—Key Change

The need for key change

The need for a change of key tends to arise in two different types of circumstances:

• Planned key changes: These will most likely occur at regular intervals. One reason for a planned key change might be the end of the key lifetime. Another reason might be regularly practicing key change procedures in preparation for an unplanned key change (the equivalent of a ‘fire drill’). In some organizations, this is the most common planned change since their key lifetimes are very long.

• Unplanned key changes: These may occur for various reasons. Indeed, many of the reasons we gave previously for having finite key lifetimes were to mitigate the potential harm from unplanned events. An unplanned key change may be required if unplanned events occur, for example:

  • A key is compromised.

  • A security vulnerability becomes apparent with the potential to lead to key compromise (such as an operating system vulnerability, a breakthrough in cryptanalysis, or a failure of a tamper-resistance mechanism in an HSM).

  • An employee unexpectedly leaves an organization.

Note: In some cases, it may simply be enough to withdraw a key (remove it from active use) rather than change it. However, care must be taken before making this type of decision. For example, when an employee unexpectedly leaves an organization on good terms, it may suffice to withdraw any personal keys they held, such as any symmetric keys shared only by the employee and a central system or any public-key pairs relating only to the employee. However, the employee might also have held group keys shared by several staff members. It would be advisable to change these keys since they will likely remain in use after the employee’s departure.

Impact of key change

Key change can be a very expensive process, depending on the importance of the key being changed. An unplanned key change is particularly problematic, especially in the event of a key compromise since it raises questions about any cryptographic operations conducted using the affected key and the confidentiality of any encrypted data. One likely consequence of a key change is that it will probably be necessary to change any other keys encrypted using the affected key, which raises questions about any cryptographic operations conducted using them.

The minimum impact of a key change is that a new key needs to be generated and established. However, the impact can be severe, especially in the case of high-level key compromise. For example, if a master key is compromised in a financial system, then the resulting costs might include costs of an investigation into the compromise, costs related to any ‘rogue’ transactions conducted using compromised keys, damage to reputation, and loss of customer confidence. Recovery from unplanned key changes should be part of an organization’s wider disaster recovery and business continuity processes.

One situation in which the damage caused by a key compromise might be limited is when the time of a cryptographic operation is logged and the time of key compromise is known. For example, if a signature key is compromised, it might only be necessary to deem all signatures generated using the key after the compromise to be invalid.

Mechanisms for changing keys

As mentioned above, key change requires:

• Generation and establishment of a new key.

• Withdrawl of the old key (and potentially the destroying or archiving of it).

Any of the mechanisms for these operations discussed elsewhere in this chapter could, in theory, be used to conduct these processes. Ideally, planned key changes should happen automatically and require very little intervention. For example, UKPT schemes automate planned key changes after every transaction. More intervention may be required in the case of unplanned key changes.

High-level key changes are more complex to manage. For example, if a storage master key in an HSM goes through a planned change, all keys encrypted under the old storage master key will need to be decrypted and then re-encrypted using the new storage master key. In this case, since the storage master key has not been compromised, there is no need to change all the keys which were encrypted using it.

Note: Key changes aren’t always easy to facilitate. Indeed, the migration process from one key to another can be particularly challenging and, when possible, needs to be carefully planned to make the transition as smooth as possible.

Changing public-key pairs

It’s perhaps slightly surprising that key change is generally simpler to perform for symmetric keys. It’s ‘surprising’ because key change forces a new key establishment operation, which is usually a more difficult process for symmetric keys. There are two reasons why changing public-key pairs is normally more challenging:

• Knowledge of public keys: Since symmetric keys need to be carefully ‘positioned’ in a network so that entities relying on them have the right keys, a key management system tends to be fully ‘in control’ of where its symmetric keys are located. This, at least in theory, makes withdrawing a symmetric key straightforward. In contrast, a public key’s ‘public’ nature means that a key management system may have little control over which entities have knowledge of a public key. Indeed, in open environments such as the internet, a public key could be known by anyone.

• Open application environments: Symmetric cryptography tends to be employed in closed environments. So any key management system handling symmetric keys should have mechanisms and controls in place for key establishment that can be reused for key change. In contrast, public-key cryptography tends to be used in open environments, where this may be more challenging.

Since private and public keys are interdependent, any requirement to change one requires the other also to be changed. Changing a private key is arguably simpler than changing a symmetric key. However, changing public keys requires special mechanisms.