Authorization for Key Material Creation and Access

In previous sections, we discussed how to classify key material and determine its intended purpose. However, key management does not end there. A fundamental question remains: who is permitted to create a key, who may access it, and who may use it?
This is where technical key management intersects with authorization management. It is not appropriate to assume that the person managing a key must necessarily be able to know its value or use it. Likewise, the key owner is not necessarily the person responsible for its technical management. Significant differences exist between the various types of keys. For a personal signing key, exclusive control by the authorized entity is paramount. Conversely, for an encryption key, a legitimate requirement may be managed recovery or access to protected data. For an authentication key, the crucial factor is the link to an identity and the scope of that identity's privileges.

Signing Keys

A signing key is used to create an electronic signature. For a personal signing key, an unambiguous link between the signer, the specific key, and the signature operation performed is essential. This entails a requirement to protect the private key against unauthorized use and to ensure the authorized holder retains control throughout the key's entire lifecycle. Suitable devices include, for example, a smart card, a USB token, a personal HSM, or another device designed to protect the private key. In some architectures, network HSMs and remote signing may also be used. In such cases, however, the authentication of the signer, the authorization of the signing operation, and the protection of the key itself must be adequately ensured.

Therefore, sharing a personal signing key among users is not advisable. If multiple individuals could independently access the same private key, issues arise regarding the ability to prove who had control of the key and who actually created a specific signature. This does not mean that an infrastructure administrator cannot have a technical role; for instance, an administrator might operate an HSM or a remote signing system. However, they should not gain the ability to perform signing operations on the user's behalf simply because they administer the technical infrastructure.
A public key is used to verify a signature. Making the public key available is therefore a standard part of how asymmetric cryptography works. The situation is different for the private key: its compromise can fundamentally undermine the evidentiary value of signatures created with that key, especially if it cannot be proven that it remained under the control of the authorized entity.

Authentication keys

Authentication keys are used to verify the identity of a user, device, or service. Typical examples include access to a corporate network, application authentication, or device verification.
For these keys, the priority is maintaining the link between the key and the authenticated entity and protecting against unauthorized use. Depending on the architecture, the key may be created by the user, the device, or the system administrator.

If an authentication key is uniquely assigned to a specific person, that link must be protected, much like with personal signing keys. Sharing a key among multiple people can make it impossible to determine with certainty who performed the authentication.
Therefore, regarding authentication, it is useful to distinguish between two questions:

• Who is permitted to create or register the key?
• Who is permitted to use the key to prove identity?

The answer need not be the same. For instance, a system might automatically create a key for a service, while an administrator merely approves its registration. Similarly, a user might own an authentication token, while a central system handles its registration and revocation.

Encryption keys

Encryption keys are primarily used to protect the confidentiality of information. Consequently, their management model may differ from that of personal signing keys. In some architectures, it is legitimate for a system or administrator to create the key and for a mechanism for its controlled renewal to exist. Reasons for this might include, for instance, the need for data recovery following a system failure or migration, or the need to maintain operations if the original user becomes unavailable.
This gives rise to an important distinction between the ability to recover a key and the ability to use it in the ordinary course of business. A backup or recovery mechanism does not necessarily imply that an administrator can decrypt arbitrary data at any time. Access may be contingent upon multiple individuals, multiple levels of approval, audit trails, or other controls.
An encryption key can thus be part of the protection of information representing a significant organizational investment. Loss of the key could result in a loss of access to the data. Therefore, the design phase must determine whether and how the key can be recovered, as well as who may initiate the recovery and under what conditions. While data encryption protects the employer's investment, the employer is simultaneously obliged to ensure adequate backups of key material precisely to safeguard that investment. An interesting side effect is that—in a broader sense—inadequate protection of either data or key material can could even be perceived as a breach of the duty of due care.
Handing over key material to a third party is not an automatic consequence of an organization owning or managing the data. Such an approach must be based on specific legal authorization, internal policies, and the security model of the solution in question.

Key question: who knows the key and who uses it?

When managing key material, it is useful to distinguish between several roles:

• key owner – responsible for the purpose and rules of its use,
• holder or authorized entity – the entity whose identity or authorization is linked to the key,
• administrator – ensures technical management of the system and the key lifecycle,
• cryptographic operation user – the entity authorized to perform the required operation,
• recovery or backup role – ensures key recovery in defined situations.

In a small system, these roles may be combined into a single person. However, for sensitive keys, separation of duties is advisable. The aim is not to create excessive administrative overhead, but to prevent a single person from being able to create, take possession of, use, and subsequently conceal the use of a key without oversight.
This highlights an important distinction between access to the key and access to the cryptographic operation. With an HSM, for example, an administrator may never gain access to the private key value itself, yet may still be able to configure the system that facilitates its use. Without appropriate separation of roles, the protection of the secret could be bypassed simply by having authorization to perform the operation.

Key backup, recovery, and disclosure

The requirement for key backup is an area where security, availability, and the requirement for exclusive control may conflict. For an encryption key, a backup may be essential for data recovery. Conversely, for a personal signing key, a copy of the key can significantly increase risk, as every additional copy expands the scope for potential compromise. Therefore, backing up is neither inherently right nor wrong. It is necessary to first determine the key's purpose and lifecycle requirements, and then decide:

• whether the key can be backed up,
• who can create the backup,
• where it is stored,
• who can restore it,
• under what conditions it may be used,
• how its use is audited,
• when the backup must be destroyed.

For personal signing keys, it is necessary to specifically assess whether creating a backup would violate the requirement for the authorized person to maintain control over the key, or conflict with the requirements of the specific signing device and service.

Key disclosure and protection against self-incrimination

Cryptography protects information against unauthorized access. However, legal systems may, under certain conditions, address situations where an authorized body requests access to protected information or cooperation in making it accessible. Some jurisdictions have legal mechanisms known as "key disclosure laws," which—under specified conditions—can mandate the surrender of cryptographic material or require that access to protected information be granted. The scope of these obligations varies across legal systems, making it impossible to formulate a universal technical rule.
A related issue is protection against self-incrimination. Here, too, the outcome depends on the specific legal system, the type of proceedings, and the circumstances of the case. From the perspective of cryptographic system design, it is therefore crucial to recognize that the requirement to protect a key and the requirement to disclose it may, in certain situations, conflict with one another.
This raises a practical question for system design: if no one normally knows the key, how can the system be recovered or a legitimate request for disclosure be fulfilled—assuming such a request can arise in the first place? The answer must be built into the architecture and key management policies, rather than being improvised during a system failure or security incident.

Separation of Authority

Several practical principles emerge from the preceding sections. This is not a universal configuration for every system, but rather a set of baseline rules that must be adapted to the key's purpose and the risk analysis.

Importantly, the process of creating a key is not the same as the authorization to use it. Likewise, a system administrator need not be the key holder, and a key holder need not have the authority to modify the key's configuration or lifecycle.

Conclusion

Authorization policies for key material cannot be designed in isolation from the key's purpose. Different rules apply to personal signing keys, authentication keys, and data encryption keys. For signing keys, exclusive control by the authorized entity and an unambiguous link between identity, key, and signing operation are paramount. For authentication keys, the link to identity and the scope of authorization are the deciding factors. For encryption keys, in addition to protecting confidentiality, one must also address availability, renewal, and any necessary recovery mechanisms.
It is equally important to separate key management from key usage. A technical administrator may be authorized to manage an HSM or KMS without needing to know the private key value or perform operations on behalf of the key holder. Conversely, a user may be authorized to use a key without having the ability to alter its lifecycle.
Backup and recovery are therefore not merely technical functions. For some keys, they are a prerequisite for availability; for others, they may compromise the required level of control. A proper design must account for this distinction right from the architectural planning stage.
This leads to another question regarding key material management: how long should a key exist, when should it be renewed, when must it be replaced, and when should it be permanently invalidated? The next part of the series, dedicated to the key material lifecycle, addresses this topic.

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.