This article discusses the importance and usage of documentation for a key management system within an organization. Information is an organization’s most important asset. An effective data protection strategy incorporates security controls that are dependent on cryptography, and therefore also dependent on secret keys.
A Key Management System should be designed to provide the necessary protection for keys and metadata. Fully documenting and implementing all key management procedures is essential for a successful performance of a key management system (KMS).
The documentation process should begin early in the cryptographic or system development lifecycle.
Cryptographic applications or Key management devices
The key management components of a cryptographic application or device must be described in its documentation throughout its lifetime. This must include a summary of the cryptographic application or proposed use of the cryptographic device. This includes the cryptographic device's purpose or use.
Through documentation, KMS users can identify key management characteristics and gain a better understanding of the security services provided by the key management system.
The documentation of a key management system should:
- Classify the different types of keys and other cryptographic information according to their functions.
- Identify the states in which a cryptographic key may exist during the key's life cycle.
- Formulate a key compromise recovery plan.
- Define system owners and managers.
- Identify key management component requirements.
- Define access controls for cryptographic device components and functions such as use of passwords and personal identification numbers (PINs) should be included.
- Define crypto-periods and recommend appropriate crypto-periods for each key type.
- Provide guidance on the selection, implementation, and replacement of cryptographic algorithms and key sizes according to their security strengths.
- Define key management phases and functions.
- Specify all automated provisions by the system.
Compromise-recovery plan
The worst form of key compromise is one that is not detected. A KMS should be designed so that the compromise of a single key compromises as little data as possible. For instance, a single cryptographic key could be used to protect the data of only a single user or a limited number of users, rather than a large number of users.
The KMS should specify how to recover from a compromise of the security control used by the system. A compromise-recovery plan is essential for restoring cryptographic security services in the event of a key compromise. A compromise-recovery plan shall be documented and easily accessible. For example, recovery from the compromise of a root CA’s private signature key requires that all users of the infrastructure obtain and install a new trust anchor. If the KMS detects a breach, it should inform the appropriate entity about the breach, as specified in the KMS Security Policy, so that mitigation actions can be taken.
Any detected security failure should result in the initiation of recovery procedures based
upon the Information Security Policy and the KMS capabilities. Typical responses include:
- The activation of a backup facility and system with new keys,
- The notification of current and potential users of the possible security failure, or
- The flagging of the keys that were compromised.
Documenting all processes and procedures
Key management processes such as key generation, key distribution, key storage and key destruction must be fully documented. The role of key custodians, operators, key owners and KMS users should be defined in the document. A key custodian is designated to distribute or load keys or key splits into a cryptographic module. KMS users utilize the system when key management functions are required to support an application. KMS users are usually the key owners. The KMS document should specify the roles and responsibilities employed by the KMS.
Adhering to Laws, Rules, and Regulations
KMS Security Policy specifies rules for the protection of keys and metadata that the KMS supports. This Policy should be written so that the people responsible for maintaining the policy can easily understand the policy and correctly perform their roles and responsibilities. The security policies of an organization should conform to the laws, rules, and regulations of the locality, and nation in which the KMS will be used.
If a KMS is designed for international use, then it should be flexible enough to conform to national restrictions. The KMS document should specify the countries or regions of countries where it is intended for use.
References and further reading
Recommendation for Key Management – Part 1: General (2012), by E. Barker, W.Barker, W. Burr, W. Polk, and M. Smid
