[Next] [Up] [Previous] [Index]

Key Management

In the simplest case, when two individuals wish to communicate secretly, all that is needed is that they prearrange a key which only they share. If each one generates a public key, keeping secret the corresponding private key, then only authentication of the public key, not secrecy, is required to allow the two to correspond securely.

Already, though, we have met one case where things become more complicated than that. In the conclusions to Chapter 2, it was observed that if two correspondents, or a larger pool of trusted correspondents, wish to exchange securely a large number of messages, in a cipher with a limited resistance to cryptanalysis, it is necessary to change the key that is used on a frequent basis.

The general practice for this has been to divide the key into three parts. One small part is changed with each message, and may be sent in the clear or encrypted somewhat as required. Another part is kept secret, and changed each day, from prepared lists issued monthly. A third part involves secret elements of the cipher system, such as rotor wirings, that are not practical to change rapidly, but which still can be altered from time to time.

This illustrates how key management becomes more complicated in order to solve the problem of limiting the amount of text transmitted with the same key.

We will be examining in this section key management measures intended to solve other problems.

Looking at the IBM key management scheme outlined in their Journal of Systems and Development shortly after the announcement of DES, we will see a system designed to solve the problem of secure communications in a computer system where the operating system is not fully trusted, and even legitimate users of the same computer system are not trusted with each others' communications. Hardware with a very limited capacity to store keys is used to provide the required security.

Kerberos is oriented towards a case where users, rather than terminals, have keys, and deals with the problem of the initial identification and set-up of a user, in a system where communication links can be tapped, but some computer systems are trusted to some extent, and encryption may be performed in software.

The section on military key management discloses no secrets (I don't know anything secret; if I did, I would not be writing so chatty a web page on so sensitive a topic as cryptography) but it examines the problem of maintaining the security of communications in a wide communications network, in the face of compromise of some of its parts.

The section on "Red Thread" resistance discusses how computer (object) programs and cryptographic hardware can be rigged, and ways to avoid that danger.

The section on Key Escrow deals with a subject that has aroused controversy; how to provide supervisory access to encrypted communications without (otherwise) compromising their security.


[Next] [Up] [Previous] [Index]

Skip to Next Section
Table of Contents
Home Page