Lifecycle

A cryptographic key does not simply come into existence once and then merely "persist." From the moment of its creation until its invalidation or destruction, it passes through a series of states and operations. Each of these steps can impact the security of the entire system.
Key material is not intended solely for electronic signatures; it can be used for encryption, authentication, the protection of communication channels, the derivation of further keys, or other cryptographic operations. Consequently, the approach to lifecycle management must be based on the key's specific purpose and the consequences of its compromise. Previous sections addressed classification, purpose, and authorization. The lifecycle builds directly upon these topics: it defines what happens to the key over time, who is permitted to make specific changes, and how the execution of those changes can be documented.

Lifecycle States and Phases

It is useful to view the lifecycle as a managed sequence of states. While specific terminology may vary between systems, typical distinctions include:

• key planning and registration,
• generation or import of key material,
• activation,
• usage,
• potential suspension,
• renewal or rotation,
• compromise and invalidation,
• archiving,
• secure destruction.

Not every key necessarily passes through all the listed states. For example, a public key may be used over the long term to verify historical signatures, whereas a private signing key can be revoked and destroyed once it is no longer in use. Conversely, for encryption keys, it may be necessary to retain the ability to recover or decrypt historical data.
Therefore, the priority is not to create a universal list of states, but rather to define the permitted transitions between states and the rules for executing them. Any state change should be authorized and auditable.

Lifecycle Records

Proper record-keeping must be an integral part of lifecycle management. This does not mean that the organization must record the actual content of the private key; in fact, exposing private key material to a standard record-keeping system could pose a security risk. Records should primarily include metadata, such as:

• a unique key identifier,
• the purpose and type of the key,
• the owner or responsible entity,
• the system or service where the key is used,
• the key status,
• the date of creation and, if applicable, activation,
• the planned period of use,
• the link to a certificate or public key,
• information regarding rotation, revocation, or archiving,
• information required for auditing.

Such records make it possible to determine which keys the organization possesses, their purpose, and their status, without the records themselves needing to contain the actual secret key material.

Generation of Key Material

Generation is one of the most sensitive phases of the lifecycle. The security of the resulting key depends not only on the size of the key space but also on the quality of the randomness source, the correct initialization of the generator, and the proper implementation of cryptographic mechanisms.
If the entropy source is predictable or insufficient, the resulting key may be predictable or may originate from a significantly smaller set of values than the algorithm assumes. The problem, therefore, may not lie in the cryptographic algorithm itself, but rather in its implementation or the environment in which it is used.
It is therefore useful to distinguish between two statements:

• the probability of a random collision between two high-quality generated keys is practically negligible, provided the parameters are correct;
• the key generation process is secure only if the entire mechanism for obtaining entropy, initialization, and generation is secure.

Consequently, the practical issue is usually not the number of keys created. What matters more is whether the keys are truly generated in a cryptographically secure manner and whether repeated or predictable generation occurs.
For sensitive keys, it may be advisable to generate the key directly within a secure environment, such as an HSM, to avoid the need to subsequently transfer the private key to a standard operating system.

Key Uniqueness

Uniqueness is particularly important for keys whose use must be unequivocally linked to a specific entity or service. In the case of personal signing keys, the sharing of the same private key among multiple individuals poses a critical problem. If multiple entities possess the same key, it is impossible to determine—based solely on the cryptographic signature—which of them actually performed the operation. This undermines the ability to demonstrate the specific holder's exclusive control over the key.
The situation may differ for other types of keys. For example, certain system or group services may intentionally use a single key for a precisely defined technical purpose. However, this is not merely a matter of technical uniqueness. It is necessary to know who can use the key and what the consequences of its misuse would be.
Uniqueness Keys must therefore be understood in the context of their identity, purpose, and authorization, rather than merely as a requirement that two randomly generated values do not mathematically match.

Activation and Use

A key may not be automatically ready for use upon creation. In some systems, there is a separate process between generation and activation that verifies the key's purpose, its association with an identity or service, and the authorization for its use. This separation is particularly useful when a key is created automatically but its use requires approval or further review. Activation should therefore be logged, just like other significant state changes.
During use, it is necessary to monitor not only the number of cryptographic operations but, above all, who or what can initiate the key's use and whether the key leaves the secure environment. Millions of operations performed directly within an HSM may not pose the same type of risk as a single export of a private key to an insecure environment.

Protection of Key Material

Protection of key material can involve several levels. A simple example is access control via an ACL (Access Control List), where the key file is accessible only to a specific user or process. However, this primarily provides protection at the operating system level. If an attacker gains sufficient system privileges or compromises the process handling the key, an ACL alone may not suffice.
Another option is to store the key in an encrypted form. This limits the risk associated with a compromise of the storage itself, but raises another question: where and how is the key decrypted, and how long does it remain available in system memory?
Specialized tools, such as HSMs or KMSs, can provide a higher level of protection. A key feature of an HSM is the ability to perform cryptographic operations directly within the device, without needing to export the private key to the general-purpose operating system. A KMS, meanwhile, provides centralized management of keys, their lifecycles, and access policies.
However, neither HSMs nor KMSs constitute a complete, standalone key management solution. Issues such as administrator authentication and authorization, auditing, configuration, backup and recovery, availability, and lifecycle termination still need to be addressed.
With cloud-based KMS or HSM solutions, it is also necessary to assess the division of responsibilities between the organization and the provider. Technical key protection is only one aspect of the decision; auditability, administration capabilities, backup and recovery, service availability, provider dependency, and service termination procedures are also important.

Backup and Recovery

Backing up key material is not merely a matter of availability. It creates an additional copy of the secret that must be protected. For encryption keys, a backup may be essential to restore access to historical data; in such cases, the loss of a single key could mean losing access to a vast amount of information.
The situation is different for personal signing keys. A copy of a private key can compromise the requirement for exclusive control by the holder; therefore, the existence of such a copy must be evaluated based on the key's purpose and the specific requirements for the given type of signature. Thus, the issue is not merely a question of "to back up or not to back up," but also:

• who is authorized to create the backup,
• where it is stored,
• who can restore it,
• under what conditions restoration can be approved,
• how the restoration process is audited,
• and how the backup itself is protected.

Key Rotation and Renewal

A key does not necessarily have to be used throughout its entire lifespan. An organization may establish a maximum period for its active use or define other criteria for its replacement. A new key then assumes its role, while the old key transitions to a different state.
Reasons for rotation may include, for example, changes in security requirements, scheduled renewal, system changes, or a response to a compromise. In some systems, rotation can be performed automatically, whereas in others, a managed process requiring explicit approval may be necessary.
It is important to distinguish between ceasing the use of a key and destroying the key. For example, a signing key may cease to be used for new signatures, yet the public key, certificate, and other information may still be required to verify historical signatures.
Similarly, regarding encryption keys, it may be necessary to retain an old key to decrypt historical data, even if it is no longer permitted for new encryption operations.

Compromise and Revocation

Compromise—or a reasonable suspicion thereof—represents a special situation. If there is a possibility that a private or secret key has fallen into the hands of an unauthorized person, it must be possible to quickly restrict or halt its use. The procedure should include at least:

1. identifying the suspected compromise,
2. restricting or halting the use of the key,
3. assessing the scope of the potential impact,
4. revoking the key or otherwise changing its status,
5. creating and activating a replacement key (if applicable),
6. preserving information needed for a subsequent audit and impact assessment.

Regarding signing keys, the situation is unique in that a compromise does not merely pose a problem for future operations. It is also necessary to assess signatures created prior to the discovery of the compromise and to preserve the information required for their verification and evaluation.

Archiving and Disposal

Ceasing active use does not necessarily mean the immediate destruction of all material associated with the key. An organization may need to retain the public key, the certificate, information regarding its validity, or other evidentiary data. Conversely, the private or secret key itself should be securely destroyed once the necessary retention period has ended, provided there is no longer a reason to keep it. The goal is to prevent the old key from remaining usable—undetected—within a system or backup.
Therefore, disposal must encompass not only the primary storage location but—depending on the architecture—also backup copies, exports, and any other locations where key material might exist. For devices that support secure key destruction directly on the hardware, it is advisable to utilize these built-in mechanisms and log the outcome of the operation.

Usage Frequency and Availability Period

Key usage frequency is a relevant parameter, yet a key's security level cannot be determined based on this factor alone. A key used a thousand times a day might be securely operated within an HSM, whereas a key used only once a year could be stored in an insecure environment. It is therefore advisable to monitor, in particular:

• how often the key is accessed outside of secure storage,
• how long it remains in system memory,
• who or what can initiate its use,
• whether its use is audited,
• what the consequences of a compromise would be,
• and how quickly the key can be revoked and replaced.

It is also important to distinguish between the frequency of cryptographic operations and the frequency with which key material is accessed. A service may perform a large number of signing or decryption operations without the private key ever leaving the HSM. Conversely, a single export of the key to an insecure environment can constitute a critical security incident.

Conclusion

The lifecycle of key material is not merely a sequence of technical operations. It is a managed process that encompasses generation, registration, activation, usage, protection, potential backup and recovery, rotation, response to compromise, archiving, and finally, revocation or destruction.
Each phase may hold different significance depending on the key type. For a signing key, protecting exclusive control and maintaining the trustworthiness of historical signatures are paramount. For an encryption key, on the other hand, long-term availability for data recovery may be the critical factor. For authentication, sealing, or TSA keys, the scope of consequences varies depending on the identity or service the key represents.
Therefore, security cannot be assessed based on a single parameter. What matters is a combination of purpose, authorization, protection method, usage duration, availability, recovery options, and end-of-lifecycle rules. Once the lifecycle is defined, another practical question arises: what characteristics must the system actually using the keys possess to handle their protection without unduly impacting operations? The next part of the series will therefore focus on the latency and throughput of cryptographic operations.

Autor článku:

Jan Dušátko

Jan Dušátko has been working with computers and computer security for almost a quarter of a century. In the field of cryptography, he has cooperated with leading experts such as Vlastimil Klíma or Tomáš Rosa. Currently he works as a security consultant, his main focus is on topics related to cryptography, security, e-mail communication and Linux systems.