|
|
Initiation responsibility: IT Security Management
Implementation responsibility: IT Security Management, IT Procedures Officer
The use of cryptographic security mechanisms (such as encryption or digital signatures) requires that suitable keys must be created, distributed and installed using confidential and authenticated procedures, with integrity ensured. Keys which have become known to unauthorised users, which have been corrupted in the course of distribution or which perhaps even originate from uncontrolled sources (this also applies to the agreement of keys between communication partners) are just as capable of compromising a cryptographic security mechanism as poor quality keys which have been generated in an unsuitable way. Good quality keys are usually created using suitable key generators (see below). Attention must be paid to the following points regarding key management:
Key generation
Key generation should be performed in a secure environment using suitable key generators. Cryptographic keys can either be generated directly at the place where they are used (usually initiated by the user) or they can be generated at a central location. When keys are generated locally, it usually has to be accepted that the security of the environment will be less stringent, whereas when keys are generated centrally it must be ensured that they reach their users authentically and without being compromised.
Suitable key generators must produce controlled, statistically evenly distributed random sequences, making use of the entire possible key space. To do this, for example, a noise source generates random bit sequences, which are post-processed with a logic unit. The quality of the keys obtained in this way is then examined using a variety of test procedures.
Some crypto modules, especially those which do not have an integrated random number generator, make use of user inputs for the generation of keys. For example, these modules may ask for passwords from which a key is subsequently derived, or the user is prompted to type in an arbitrary text in order to obtain random starting values for generating a key. Passwords used in such circumstances should be carefully chosen and as long as possible. If users are requested to make entries that are as random as possible, they should really be random, in other words difficult to predict.
Separation of keys
If possible, cryptographic keys should be employed for only one purpose. In particular, it is important never to use the same keys both for encryption and for the generation of signatures. This makes sense for a number of reasons:
Distribution and exchange of keys
Cryptographic communications relationships can only work if the communicating partners have matched cryptographic keys at their disposal. For this to be possible, all communicating partners must be provided with the necessary keys. Various procedures can be used for distributing keys and for exchanging keys. The differences arise from the use of different cryptographic techniques and mechanisms, or from the combination of such techniques and 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 communication partners. For this, the keys are transferred to the individual communication partners from a (usually central) key generation point, for example a Trust Center.
The keys should be distributed on suitable data media (e.g. chip cards) or via communications links (e.g. LAN or WAN) in a form which ensures confidentiality (e.g. encrypted with a KEK key encryption key), integrity (e.g. MAC-secured) and authentication (e.g. with a digital signature in accordance with the signature law). Gaining unauthorised knowledge of the keys or corruption of the keys must be prevented, or it must at least be possible to detect such an event.
The exchange of keys refers to the key agreement procedure between two communication partners to generate 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 length of time must be specified, because sessions can last a very long time. The time can be specified by relative timing, for example, or by a packet counter. A new session key is negotiated between the communication partners for every new connection.
Advanced systems nowadays make use of asymmetric cryptographic procedures for key distribution and key exchange. A trustworthy certification body can be established to prove the authenticity of the public keys. The communication partners must identify themselves to the certification body and have their public keys certified there by means of a digital signature from the certification body. The digital certificate generated in this way should contain at least the public key and an identification feature specific to the communication partner, the period of validity of the certificate and the digital signature from the certification body. Knowledge of the public signature key of the certification body puts every communication partner in a position to verify the authenticity of the public key of the other party with whom they are communicating.
Installing and storing keys
In the course of key installation it is necessary to check the authentic origin and integrity of the key data. As a general rule, keys should never be stored in the system in plain form but always in encrypted form. When using software encryption products, it must be borne in mind that keys are inevitably present in plain form 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, they should not be stored on those systems. In that case, manual entry as needed is the obvious answer. Another possibility would be to transfer the keys to an external data medium, which would then have to be kept securely, however, as described in the section on the archiving of keys. From the security point of view, therefore, preference is to be given to the use of hardware encryption components, where the keys are loaded directly into the encryption component from the data medium (such as a chip card) and never leave the encryption component in unencrypted form.
It must always be ensured that preset keys are changed on installation of the encryption procedure.
Archiving of keys
For the purpose of archiving, it should also be possible to store the cryptographic key material outside the crypto module in an encrypted form, and if necessary reload it. To do this, several keys can be combined in one record, which is then likewise encrypted with the aid of a KEK (key encryption key). Accordingly, the KEK must also be kept securely (for example on a chip 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 crypto module's reading unit at the same time or immediately one after the other.
Access and deputisation arrangements
Matters relating to access rights and deputisation rights should be settled in the security policy. The relevant mechanisms must be supported by key management and by the crypto modules and devices that are 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 due to illness; see also archiving of keys).
Changing keys
Details of when and how often keys need to be changed must be laid down in the crypto concept, on the basis of the security policy. The larger the quantity of encrypted data that is available to an attacker for analysis, the greater the chance with some algorithms that the analysis process will be successful. Changing keys on a regular basis minimises the opportunities for attacking encrypted data. The frequency of changing is dependent on a variety of factors. The type of encrypted medium (for example long-term data medium or data transmission medium) is just as significant as the cryptographic algorithm, the detection of attacks (such as theft of loss of a key) and the degree to which the data is worth protecting. Other factors playing a part in determining the frequency of change are how often the key is used, the relevant threat potential and the security of the local key storage facility.
Depending on which procedure 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 procedures, without the user noticing. Changing keys in this case means exchanging the master keys that form the basis on which the session keys are generated, and should of course also be carried out regularly.
If a key being used is suspected of having been disclosed, its use should be discontinued and all participants should be informed. Information already encrypted with this key should be decrypted and encrypted with a different key.
Destroying keys
Keys which are no longer required (for example keys whose period of validity 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). A general rule is that products with a key filing system that cannot be controlled should not be used.
Additional controls:
| © Copyright
by Bundesamt für Sicherheit in der Informationstechnik |
July 1999 |