Key Management Plan, though keys are widely used in various of domains like ATM, HSM, IPSec Tunnel, VPN Tunnels and many others, ways of managing those keys are not widely mentioned. Part of my role is to provide clients with procedures that they could use to manage and maintain the safes.. Lack of defined structure and clarity enables confusion so this is my attempt to standardise the life cycle of sensitive Symmetric Keys.
The Life cycle includes Key Generation, Key Transfer/Conveyance, Key Storage, Key Accounting, Key Destruction, Key Archival and compromise.
High Level Logical Process
- Provide the high level process to describe the overall cryptographic work flow. Right from task initiation to the different environment the keys or certificate flow into and expected outcome.
- Provide the high level diagram on different aspects involved and the order the work flows.
Key Generation Process:
- Provide dates; location details if appropriate.
- Provide a description of how the key(s) will be sourced. This may be via another agency or may be key(s) generation processes or equipment. It may be required to provide details of the initial key generation or seeding.
- Provide details on how the key is to be physically loaded into the hardware and/or software cryptographic system.
- Provide details on how the key(s) are produced and distributed to the relevant parties.
- Describe how the key(s) are to be used, to the extent that this information is not already covered in sections earlier. Include the following:
- When encryption and decryption occurs;
- What data is to be encrypted and decrypted; and
- The keys and algorithms are to be used in these transformations.
- Detail the crypto period(s) for the various key(s).
- Provide details of how the key(s) will be electronically and physically stored. Include security countermeasures that will be used to protect the key(s) from compromise.
Key Accounting:
- Detail the number of copies of key to be produced and distributed to the various parties.
- Provide details on the identification of the various key(s) to be produced and/or receipted.
- Detail the procedures for labelling and recording of the name, version and number of copies that were distributed, and the recipients of the key(s).
- If appropriate, detail how key(s) are to be destroyed.
- Provide detailed inventory of various types of key involved with key name, length and type.
Key Distribution
- Provide details on how keys will be distributed electronically or physically. This should include security details of courier(s), if used, as well as how the couriers will handle contingencies such as loss or compromise of keys. Electronic distribution of keys may already have been discussed in the section titled “Key Management” above.
Key Contingency
- Describe the conditions under which a compromise of cryptographic key material should be declared. This should include loss or theft of keying material, unauthorised access to keys or equipment, and unauthorised extensions of crypto periods.
- Describe the reporting action that is to be effected as part of a compromise declaration. This should include the addressees of the report, the details of the minimum amount of information that should be included in the report, and any action that is or will be taken to further scope the compromise and/or limit the exposure.
- Detail the procedures for recovery of keys and encrypted material.
Key Compromise
- Detail the key compromise procedure on how the incident will be investigated and how to escalate the incident.
- Detail some event which is considered as compromise
- Whenever the HSM is replaced
- The physical appearance of the HSM indicates a possible tamper
- The tamper indicator on the HSM is flashing
- Any safe is unexpectedly found open
- Any safe is inadvertently left open and unattended by a custodian
- The seal on an envelope containing a part of the key component is broken
- The HSM does not accept or validate one or more steps in any key creation or loading procedure
- The HSM does not accept an authentication attempt from a previously used custodian smartcard
- Detail the escalation procedure on whom to contact in terms of incident. .
Key Destruction
- Keys and their bound metadata should be destroyed when they no longer to be used. Destroying a key in a high security application can be a complex process, depending on the storage media of the key. Keys in electronic storage media may be overwritten with zeros or random patterns of zeros and ones repeatedly in a prescribed manner. Magnetic media that has a propensity for retaining low levels of magnetism may be physically destroyed, degaussed, or over-written with various bit patterns numerous times.
- Provide explanation/procedure on the circumstance under which a key may be destroyed.
Key Archival
- Key archive involves placing a key in a safe long-term storage facility so that it can be retrieved when needed. Key archiving usually requires provisions for moving the key to new storage media when the old media are no longer readable because of ageing of, or technical changes to, the media readers. Archived keys should be automatically retrieved from the old storage medium and restored on the new storage medium when a storage medium replacement is made.
- The KMS design shall specify how, where, and the circumstances under which keys and their bound metadata are archived.
Key retrieval
- Obtaining a cryptographic key from storage, a backup facility, or an archive is considered retrieval if done during normal KMS operation. If there has been an environmental or man-made disaster and the key cannot be normally retrieved and used, the key may have to be recovered by special means or with special permission. The KMS security policy should state the conditions under which a key may be retrieved normally.
- The KMS design shall specify how, and the circumstances under which, keys and their bound metadata may be retrieved from a key database storage facility.
Key Escrow
- Key escrow involves providing copies or components of secret or private keys to trusted parties so that the key owner or other authorised parties can recover the key when the owner’s key is destroyed or otherwise unavailable.
- The KMS design shall specify the security policy (e.g., continuous two-person control) for the protection of escrowed keys.
- The KMS design shall specify how the security policy is implemented during the key escrow, i.e., how the confidentiality and multi-party control requirements are implemented during transport and storage of the escrowed key.
Hardware and/or Software Maintenance
- Detail the maintenance procedures for hardware and/or software items that are critical to successful operation of the cryptographic services. This should include the security measures taken to protect the integrity of the hardware and/or software by uncleared maintenance staff, as well as ensuring hardware and/or software has been adequately sanitised prior to release.
- Detail the procedures for testing or verification of software upgrades to critical cryptographic services in either the hardware (through firmware) or software.
Key Resources
- Provide a description of the resources required for operating, maintaining, and supporting the system once it is put into production. Roles to consider include any key custodians, support groups, and any business roles etc.
Risk
- Outlining the risk aspect of the keys with likelihood, consequences and impact for various likely scenario needed to be outlined.
Forms:
- Key conveyance and Key Destruction must be tracked either as soft-copy or hard copy, so its best practise to use standard Key conveyance forms/ Key Destruction forms and file them for record purposes.
