Requirements of Key Management

Fundamental key management requirements

Two fundamental key management requirements apply throughout the various phases of the key lifecycle:

• Secrecy of keys: Throughout the key lifecycle, secret keys (in other words, symmetric keys and private keys) must remain secret from all parties except those authorized to know them. This impacts all phases of the key lifecycle since, for example:

  • If a weak key generation mechanism is used, it might be possible to determine information about a secret key more easily than intended.

  • Secret keys are vulnerable when they are ‘moved around.’ So secure key distribution mechanisms must be used.

  • Secret keys are perhaps most vulnerable when they are ‘sitting around.’ So key storage mechanisms must be strong enough to resist an attacker who has access to a device on which they reside.

  • If secret keys aren’t destroyed properly, they can potentially be recovered after the supposed time of destruction.

• Assurance of purpose of keys: Throughout the key lifecycle, those parties relying on a key must have assurance of purpose of the key. In other words, someone in possession of a key should be confident they can use this key for the purpose they believe it to be for. This ‘purpose’ may include some, or all, of the following:

  • Information concerning which entities are associated with the key (in symmetric cryptography, this is likely to be more than one entity, whereas for public-key cryptography, each key is normally only associated with one entity).

  • The cryptographic algorithm the key is intended to be used for.

  • Key usage restrictions, for example, that a symmetric key can only be used to create and verify a MAC or that a signature key can only be used for digitally signing transactions of less than a certain value.

  The ‘assurance’ necessarily includes some degree of data integrity linking (ideally binding) the above information to the key itself. Otherwise, it cannot be relied upon. Sometimes, perhaps rather casually, assurance of purpose is referred to as authentication of the key.

  However, assurance of purpose is often much more than identifying the entity associated with the key. Assurance of purpose impacts all phases of the key lifecycle since, for example:

  • If a key is established without providing assurance of purpose, then it might later be used for a purpose other than that which was originally intended.

  • If a key is used for the wrong purpose, then there could be very serious consequences.

    In some applications, we require an even stronger requirement, namely the assurance of purpose is provable to a third party, which might be the case for verification keys for digital signature schemes.

The need for secrecy of keys is self-evident, and much of our subsequent discussion about the key lifecycle will be targeted towards providing it. Assurance of purpose of keys is more subtle and is often provided implicitly.

For example, in the AKE protocol from ISO 9798-2, Alice and Bob establish a shared AES encryption (say) key using a TTP, in each case receiving the key encrypted using a key known only to Alice or Bob and the TTP. In this case, the assurance of purpose is implicitly provided through a combination of the facts that:

1. The key arrives shortly after a specific request for a shared AES encryption key.

2. The key has come from the TTP (this case was argued in the protocol analysis).

3. The name of the other communicating party is included in the associated ciphertext.

Assurance of purpose in the above example is largely facilitated by the parties relying on the key. Alice and Bob are both parts of a ‘closed’ system in which they both share long-term symmetric keys with a TTP. In most environments where symmetric key cryptography is used, assurance of purpose is provided through similar implicit arguments.

In contrast, public-key cryptography facilitates cryptography in ‘open’ environments where there are no sources of implicit assurance of the purpose of the keys. Public keys can be public items of data. By default, there are no assurances of whether a public key is correct, with whom it can be associated, or what it can be used for. That’s why the key management of public keys needs to focus much more explicitly on the assurance of the purpose of public keys.

Finally, the purpose of a key is not always intuitive. For example, we saw earlier that a user who has a MAC key might not be allowed to use it both for MAC creation and verification. Similarly, a user might not be allowed to use a symmetric key for both encryption and decryption. We’ll also see an example of a symmetric key that can only ever be used for encryption but never decryption.

Key management systems

We’ll use the term key management system to describe any system for managing the various phases of the key lifecycle. While throughout our discussion of cryptographic primitives we have cautioned against using anything other than a few respected, and standardized, cryptographic primitives, we have to take a more pragmatic view when it comes to key management systems. That’s because a key management system needs to be aligned with the functionality and priorities of the organization implementing it (we use the term organization in a loose sense; this could also be an individual). For example, a key management system may depend on:

• Network topology: Key management is much simpler if it’s only needed to support two parties who wish to communicate securely rather than a multinational organization wishing to establish the capability for secure communication between any two employees.

• Cryptographic mechanisms: As we will see, some of the key management system requirements of symmetric and public-key cryptography differ.

• Compliance restrictions: For example, depending on the application, there may be legal requirements for key recovery mechanisms or key archival.

• Legacy issues: Large organizations with security that partly depends on that of other related organizations may find that their choice of the key management system is restricted by requirements to be compatible with business partners. Some of them might be using an older technology.

Because of this, an organization will almost inevitably have to think carefully about how to design and implement a key management system meeting its specific needs. There are several important standards relating to key management that provide useful guidance. There are inevitably many proprietary key management systems around, some closely related to these standards and others completely non-standard.

It’s also worth noting that most international standards for key management are lengthy documents covering many key management areas, so full compliance with such standards is extremely hard to achieve. Many organizations will comply with the ‘spirit’ of a standard rather than the ‘letter’ of the standard.

Key management is hard, and there are many different approaches to it. This raises a major concern: how can we get some level of assurance that a key management system is doing its job effectively?