Dynamic keys
In many applications, and in particular in the area of data transmission security, it is common practice to use dynamic keys. Such keys are also called ‘temporary keys’ or ‘session keys’. To generate a dynamic key, one of the two communicating parties first generates a random number, or some other value for use in a specific session, and passes it to the other party. The further course of the process depends on whether cryptographic algorithms used are only symmetric or also asymmetric.

Dynamic keys with symmetric cryptographic algorithms
For procedures that use only symmetric cryptographic algorithms, the random number generated by one of the two parties is sent as plaintext to the other party. The smart card and the terminal then encrypt this number using a derived key. The result, as shown in Figure 4.37, is a key that is valid only for one particular session.
dynamic key = enc (derived key; random number)

The main advantage of dynamic keys is that they are different for each session, which makes attacks significantly more difficult. However, care must be taken when a dynamic key is used to generate a signature, since the dynamic key will also be needed to verify the signature. This key can only be generated using the same random number as was used when the signature was created. This means that whenever a dynamic key is used for a signature, the random number used to generate the key must be retained for use in verification, which means it must be stored. The ANSI X 9.17 standard proposes a different method for generating derived and dynamic keys. Although it is somewhat more complicated than the previously described method, it is widely used in financial transaction systems. This method requires two inputs: a value Ti that is independent of the time or session and a key KeyGen that is reserved for generating new keys. The resulting initial key Keyi can be used to compute as many additional keys as desired. This key generation method has the additional advantage that it cannot be computed in reverse; in other words, it is a one-way function:
Keyi+1 = enc (KeyGen; enc (KeyGen; (Ti XOR Keyi )))

Exchanging dynamic keys using an asymmetric cryptographic algorithm
Figures 4.38 and 4.39 show procedures for generating and subsequently exchanging a symmetric dynamic key for message encryption. An asymmetric cryptographic algorithm, such as RSA or DES, is used for key exchange. A similar process is used in PGP, for example, which uses the IDEA and RSA algorithms. The basic advantage of this hybrid process is that the actual encryption of large volumes of data can be performed using a symmetric cryptographic algorithm, which has significantly higher throughput than an asymmetric algorithm.

Key parameters
A mechanism that is as simple as possible is needed to allow the key stored in the card to be externally addressed. The smart card operating system must also always ensure that the key can only be used for its intended purpose. For instance, it must prevent an authentication key from being used for encrypting data. Besides the intended use, the key number must be known for it to be addressed. This number is the actual reference to the key. In addition, the version number is also needed to address a specific key.
Some smart card operating systems cause a retry counter associated with the key to be incremented each time a failure occurs in some activity that uses the key, such as an authentication. This can be used to quite reliably prevent the key value from being fished out by repeated trials, although this type of an attack does not represent a serious risk due to the long processing times in the card. If the retry count reaches its maximum value, the key is blocked and cannot be further used. The retry counter is reset to zero if the attempt to use the key is successful. Such a mechanism must always be used with great care, since an incorrect master key in a terminal could easily lead to massive card failures. A retry counter can normally only be reset using a special terminal, and the identity of the cardholder must be verified before this is done. Some systems prohibit the reuse of old versions of keys. This is accomplished by providing the key with a ‘disable’ field that is activated as soon as a new key with the same key number
is addressed.

Key management example
Here we would like to describe an example of key management for a system based on smart cards. The objective is to further illustrate the previously described principles by means of an easily understood general example. Compared with this example, large real systems frequently have arrangements that are much more complex, with several structural layers. Small systems often have no key hierarchy at all, since a secret global key is used for all cards. The system presented here occupies a middle position between systems with very simple structures and large systems, and thus represents a good example. In the example shown in Figure 4.40, the keys for loading and paying can be used with an electronic purse. They use symmetric cryptographic procedures. These keys are evidently important within the system, since they are relatively well protected by the described key hierarchy. The individual derivation functions are not shown in detail here, but the DES or triple-DES algorithm could always be used for them. The lengths of the keys are also not dealt with in detail, but they certainly may vary. The keys at the top of the hierarchy are normally derived using more powerful cryptographic functions than those used at the lower level keys, for reasons of security. The key at the top of the hierarchy is called the general master key. There is only one such key for an entire generation of keys. A generation could remain valid for a year, for example, and be replaced in the following year by a new generation, which means a new generation of the general master key. The general master key is the most sensitive key of the system with regard to security. If it becomes known, all of the keys of its generation can be computed, and the system is broken for one generation. The general master key may be generated from a random number. It is also conceivable to base the general master key on the values shown by dice thrown by several independent persons, each of whom consequently knows only part of the value of the key. The general master key should never be completely known by any single person, and its generation must under no circumstances be reproducible.

Amaster key for each function is separately derived from the general master key. These keys may be used for loading or paying with an electronic purse, for example. A one-way function, such as a modified triple-DES algorithm, is used in our example to derive the separate master keys for the various functions. This makes it impossible to compute the general master key from a master key by applying the procedure in reverse. If a one-way function is not used to derive the master keys, the general master key could be computed if, despite all security measures, a master key becomes known and the derivation parameters are also known. A one-way function is used here because it is assumed that in this imaginary purse system, the master keys will be located in the security modules of local terminals. This means that with regard to system security, they are much more endangered than the general master key, which never leaves the background system. The derived keys form the next level in the key hierarchy. These are the keys that are located in the smart cards. Each card contains a set of derived keys, which are classified according to their functions and generations. If such a card is used at a terminal, the terminal can compute the derived key for itself, based on the parameters used to derive the key in question. Naturally, the terminal first reads the derivation parameters from the card. Once the derived key is available, the following step is to compute the dynamic key, which is specific to a particular session. This key is valid only for the duration of a single session. The duration of a session ranges from a few hundred milliseconds to a few seconds in most smart card applications. A dynamic key is no longer used after the end of the session. This example system may appear complicated at first glance, but it is relatively simple compared with real systems. The objective of the example is to show exactly how all the keys in a system can be generated. It also implicitly shows what measures must be taken if a key becomes known. If the general master key becomes known, a switch to a new generation must be made if the system is to continue to be used without concerns about security risks. By contrast, if a derived key becomes known, all that is necessary is to block the card in question; any other key management changes would surely be inappropriate. Of course, all of these measures presume that the reason why one or more keys have become known can be determined, so that it can be prevented in the future. Given this key hierarchy, it is evident that very many keys must be generated and stored in the smart cards. Of course, it is always possible to assign several functions to a single key in order to save memory space. It is also quite conceivable to use a different structure for the key hierarchy, which naturally strongly depends on the system for which the key management system is developed.