S 2.46 Appropriate key management

Initiation responsibility: IT Security Officer

Implementation responsibility: IT Security Officer, Specialists Responsible

The use of cryptographic security mechanisms (e.g. encryption or digital signatures) requires suitable keys to be generated, distributed, and installed using confidential, authenticated procedures with guaranteed integrity. Keys that have fallen into the hands of unauthorised persons, have been tampered with during distribution, or even come from uncontrolled sources (this also applies when communication partners agree on the keys to be used) are just as capable of compromising a cryptographic security mechanism as poor quality keys generated in an unsuitable manner. Good quality keys are usually created using suitable key generators (see below). The following points must be taken into account for key management:

Key generation

Key generation should be performed in a secure environment using suitable key generators. Cryptographic keys can either be generated directly where they are used (in which case generation is usually initiated by the user) or they can be generated at a central location. When keys are generated locally, you are usually forced to accept a lower level of security in the local environment, and when keys are generated centrally, it must be ensured that the keys reach their users authentically and without being compromised.

Suitable key generators must produce controlled, random sequences that are evenly distributed in statistical terms, and they must make use of the entire possible key space. To do this, for example, a noise source generates random bit sequences that are then processed by a logic unit. The quality of the keys obtained in this manner is then examined using a variety of test procedures.

Some cryptographic modules, especially those that do not have an integrated random number generator, generate keys based on user inputs. For example, they may ask for passwords from which a key is subsequently derived, or the user may be prompted to type in an arbitrary text in order to obtain random seed values for the key generation process. Passwords used in such circumstances should be chosen carefully and should be as long as possible. If users are requested to enter data that is as random as possible, then the data should really be random, i.e. difficult to predict.

Key separation

If possible, cryptographic keys should be used once only. In particular, it is important never to use the same key for encryption and for signature generation. This makes sense for a number of reasons:

Key distribution/key exchange

Cryptographic communications can only work when the communicating partners have matched cryptographic keys at their disposal. For this to be possible, all communicating partners must be supplied with the necessary keys. Various methods can be used for distributing and exchanging keys. The differences between the methods are due to the use of different cryptographic techniques and mechanisms, or of a combination of these mechanisms (see S 2.164 Selection of a suitable cryptographic procedure). In this case, the term key distribution refers to the initial provision of basic keys to the communication partners. To distribute the keys, they are sent to the individual communication partners from a (usually centrally located) key generation point (for example a trust centre).

The keys should be distributed on suitable data media (e.g. smart cards) or over communications links (e.g. LAN or WAN) in a form which ensures their confidentiality (e.g. encrypted with a KEK (Key Encryption Key)), integrity (e.g. MAC-secured), and authenticity (e.g. with a digital signature in accordance with the Digital Signature Act). The gaining of unauthorised knowledge of the keys and tampering with the keys must be prevented, or it must at least be possible to detect such events.

Key exchange refers to the key agreement procedure used between two communication partners on a session key. The session key is a key that is used for only a limited time, such as for the duration of a communication connection. This time must be specified because sessions can last a very long time. The duration can be specified by a timer, for example, or by a packet counter. A new session key is negotiated between the communication partners for every new connection.

Modern systems make use of asymmetric cryptographic procedures for key distribution and key exchange. A trustworthy certification authority can be set up to verify the authenticity of the public keys. The communication partners must provide the certification authority with identification and have their public keys certified there using a digital signature from the certification authority. Digital certificates generated in this manner should contain a minimum of the public key, an identification feature specific to the communication partner, the period of validity of the certificate, and the digital signature of the certification authority. Knowledge of the public signature key of the certification authority enables every communication partner to verify the authenticity of the communication partner's public key.

Installing and storing keys

When installing keys, it is necessary to check the authenticity of the origin and integrity of the key data. As a general rule, keys should never be stored in the system in plain text, and must always be stored in encrypted form instead. When using software encryption products, bear in mind that plain text versions of the keys exist on the PC system at least temporarily during the encryption/decryption process. If the IT systems on which the cryptographic product is being used do not offer adequate access protection for the keys, then they should not be stored on those systems. In that case, manual entry is the obvious answer. Another possibility would be to transfer the keys to an external data medium, although the data medium would then have to be kept securely as described in the section on archiving keys. From a security point of view, therefore, it is preferable to use hardware encryption components in which the keys are loaded directly into the encryption component from the data medium (e.g. smart card) and never leave the encryption component in unencrypted form.

In all cases, it must be ensured that all default key settings are changed during the installation of the encryption program.

Archiving keys

For archiving purposes, it should also be possible to store the cryptographic key material in an encrypted form outside of the cryptographic module, and if necessary to read it in as well. To accomplish this, several keys can be combined into a single record that is then encrypted with the aid of a KEK (Key Encryption Key: over-encryption key). The KEK must also be stored securely (e.g. on a smart card in a safe). If the KEK is split into two partial keys, the two-person rule can be implemented: two different people each have access to a separate data medium (e.g. a chip card or floppy disk) on which only one of the two partial keys is stored. In order to generate the KEK, both data media must be inserted in the read unit of the cryptographic modules at the same time or immediately after each other.

Access and deputisation arrangements

Questions relating to access rights and deputisation rules should be answered in the security policy. The corresponding mechanisms must be supported by key management and by the cryptographic modules and devices to be used (e.g. key escrow in the event that a member of staff leaves the company or is absent for a long period of time due to an illness (see also "Archiving keys").

Changing keys

When and how often keys need to be changed must be specified in the cryptographic concept based on the security policy. With some algorithms, the more encrypted data there is available to an attacker for analysis, the greater the probability that it will be successfully analysed. Changing keys on a regular basis minimises the opportunities for attacking encrypted data. The frequency with which keys are changed depends on a variety of factors. In this case, the type of encrypted medium (e.g. long-term data medium or data transmission medium) is just as important as the cryptographic algorithm, the detection of attacks (such as theft or loss of a key), and the degree to which the data is worth protecting. Other factors relevant to determining the frequency with which keys are changed include how often the key is used, the relevant threat potential, and the security of the local key storage facility.

Depending on which method is used, new keys have to be negotiated for every single communication connection, i.e. session keys have to be used. This should of course be controlled by the procedure without the user noticing. Changing keys in this case means replacing the master keys on which the generation of the session keys is based, and should of course be done regularly.

If it is suspected that one of the keys currently in use has been disclosed, then that key must no longer be used, and all relevant parties must be informed. Information already encrypted with this key should be decrypted and then re-encrypted using a different key.

Destroying keys

Keys that are no longer needed (e.g. keys whose validity period has expired) must be deleted in a secure manner or destroyed (for example by multiple deletion/overwriting and/or mechanical destruction of the data medium). As a general rule, products in which the storage of the keys cannot be controlled should not be used.

Review questions:

© Federal Office for Information Security. All rights reserved.