Printer Friendly

Key-variable management for encryption of data.

Key-Variable Management for Encryption of Data

Increased use of data encryption in complex networks by government agencies and the private sector has brought with it concern about key-variable management. The key variable (KV) is the "secret code or secret key' used to maintain the security of communications from different users of the same equipment. It is often referred to as "the key.' Handling of key variables is often referred to as "key management.'

Key management encompasses the generation of KVs, their transport to all crypto equipment in the system without compromise, their insertion into the cryptographic equipment (often called key entry), the coordination of key entry in terms of time so that all cryptographic units are using the correct key at the correct time, the destruction or erasure (zeroizing) of keys after use, and the use of alternate and emergency KVs when compromise of the security system is suspected.

Historically, encryption is used primarily in diplomatic and military communications, and secondarily in commerce. Initially, couriers were used to carry key settings to different locations, since the keys were changed relatively infrequently. Communication was in the form of written messages or relatively low-speed teletype and telex, and the amount of communications requiring security at that time was relatively small.

Today's Needs Are More Complex

With contemporary data processing, high-speed data communications and the rapid exchange of communications in digital form, achieving suitable key management has become sophisticated and complex. It's one thing to carry key settings to relatively few locations at intervals of a month or six months. It's quite another to transport key settings all over the globe to literally hundreds of locations on a daily or weekly basis.

The requirement can be summarized as the need to transport, without compromise and without error, the correct key setting to hundreds of locations scattered around the globe on a daily basis, and ensure those key settings are correctly entered at the proper time in every cryptographic device in the system.

The unsatisfactory solutions of the past have inhibited the introduction of cryptographic equipment in many applications where the need is both apparent and long standing. Within the past few years, there have been different proposed and implemented solutions to the key-management dilemma. These solutions reflect different underlying concepts or philosophies. One approach, ANSI X.9.17, implements centralized control. Our company, on the other hand, favors decentralized, flexible key management.

Before key-management systems (such as X.9.17) become widely implemented, it is important to examine the pros and cons of different concepts, particularly centralized versus decentralized management. The concern is that the sheer forces and "weight' of standards committees and standards may direct key management into forms that in the long run won't satisfy the basic requirements. The purpose of this article is to examine the broad issues of key management and to raise questions--to be the devil's advocate before widespread implementation.

Defining the Terminology

At this point, it is important to define terminology and what is meant by centralized and decentralized key management, downline KV indexing, downline KV loading and the like. Downline loading is achieved by generating a KV, encrypting it with a different KV (called the master key), and transmitting the encrypted key to all cipher devices in the network. Indexing is accomplished by pre-loading a large number of KVs into each cipher device. Each KV has an index associated with it. To use a particular key, only the index need be transmitted.

There are different ways to generate KVs, either manually or electronically. For the sake of discussion, assume that they'll be generated electronically, regardless of the key-management system. In the interest of security, it's desirable that no human being have knowledge or access to the KVs, that they be transported and entered into the cryptographic equipment with great protection against compromise, and that the system be capable of changing them often.

At best, they should be changed at the start of every communications exchange, or even have two or more parties communicate using different KVs that would have to be "broken' for an adversary to penetrate both ends of a system. Therefore, it is apparent that most facets of key management focus on a relatively small number of objectives: generating proper KVs, protection from compromise, rapid transport to all locations, the ability to change them frequently, and handling the actual or the potentially compromising situation.

The accompanying illustration serves to depict three different forms of network and key-management configurations. In the solid-line portion, a KV generator (KVG) is connected to the same communications network as the encryption devices (DSD). In this form of centralized control, indexing and/or KV generation takes place at only one location. This implies that all ciphering equipment will use the same key variable and will be unchanged until a new index or key is received from the central source. The total network must be interrupted at such times as the KVG wishes to distribute KVs or their indices to the DSDs. The more frequently this takes place, the more frequently the network is not available for handling normal traffic.

Separate KV Receiver is Used

The broken-line portion depicts a variant of the centralized system in which the KVG uses the network as before but there's separate KV receiver (KVRX) associated with each ciphering device (DSD). The KVRX interprets the encryption header embodying the KV (and usually the initializing vector), which is then electronically inserted into the ciphering device.

The advantage of the separate receiver is that it permits the use of ciphering equipment that otherwise might not be compatible with that key-management system, as long as the receiver can be electronically interfaced with the ciphering device and that the data ciphering still takes place in a mutually compatible form. Again, the KV or index is generated at a centralized point, it either uses the communication network or a separate network (dotted lines) for transport, it effectively ensures that all ciphering equipment uses the same key at the same time, and it provides tight system control.

Take away the KVG and the KVRXs and there remains a decentralized system in which each encryption device is capable of generating KVs or their indices. The decentralized system permits different encryption units to exchange indices or keys and uses the network for key transport at the same time that communication is taking place between different parties. The decentralized system is predicated on a set of assumptions somewhat different from that of the centralized system:

There is no best single key-management system applicable to both the operational and technical requirements of all data communications systems. Different operational environments and different technical constraints require an approach to key management tailored to that particular situation. Thus, the key-management system utilized by a transaction-oriented dedicated communication system is not the same as the key-management system to be used in a packet-switched system or in a long-haul point-to-point system.

Where possible, centralized key distribution is to be avoided, since it becomes a focal point for an adversary's attack and is not consistent with good crypto practice.

Since any ciphering unit in a system is capable of generating KVs, it may be used in a central form of management only when that form of management is appropriate. The "central' KVG may easily be changed by designating that function to any DSD in the network.

Different Keys Used at Same Time

Secure communications using different key variables should be possible between parties of the system simultaneously. In other words, A and B should be capable of communicating with each other using one or two KVs different from that being used by C and D at the same time. This approach increases the complexity and difficulty of penetrating the system by at least an order of magnitude and makes the adversary's job much-more difficult.

The system manager should be able to select different forms of key management at his own initiative. He can tailor the key management to the system and its particular operational needs.

Key-variable information should be capable of being selected without putting the KV or an encrypted form of it on the communication channel itself.

The requirements stated above have in fact been accomplished by a technique called "multiple key indexing.' In this approach, a large number of KVs (up to 800) are initially loaded into each ciphering device, with each KV identified by an index. Different groups of users can be separated from each other by having different keys associated with different indices. For common communication, the same key is at the same index location for all DSDs.

To change or select a KV, a transmitting unit need only send an index that can be unencrypted, along with the initializing vector, to instruct the receiving ciphering unit which key to use for decrypting the following traffic. Indexing can be commanded either manually or automatically, with automatic selection based on time or random selection for different messages. This approach permits Unit A to transmit to Unit B with one KV while Unit B transmits to Unit A using another. In case one wishes to use downline key loading, the multiplicity of KVs stored in the ciphering device may be randomly selected as master keys to encrypt the session key prior to transport, thus providing multiple master keys.

The centralized key-management system at present requires that periodically (every one to six months) master keys be physically transported to each location and loaded into the ciphering devices. This poses the problem of how to ensure that all of the units are using the same master key at the same time for their downline key loading.

Another approach to centralized systems is to use a public key algorithm to encrypt the session keys and transmit them to each location. Tnis certainly has advantages over physically transporting master keys, but restricts how often session keys can be changed, because it takes a significant portion of time to encrypt and decrypt a session key using a public key algorithm. One may encrypt and decrypt public key-encrypted session keys off line in some networks, such as financial transactions, but it is impractical in complex networks.

Key Index Makes Change Easier

We've incorporated the flexible key-management system in cipher equipment that has successfully operated on a variety of networks, including X.25 packet-switched systems. It permits the rapid changing of keys in a safe and uncompromising way. Key indexing aboids the exposure of the KV to transport over the communications network and considerably shortens the amount of information needed to change keys, since an index is considerably shorter than an encrypted session key.

As mentioned earlier, there are undoubtedly advantages and disadvantages to both the centralized and decentralized approaches, as well as to the question of changing keys by indexing as compared to transporting encrypted session keys over the network. The centralized source of KV generation is potentially vulnerable not only to cryptographic attacks in the form of code breaking, but also to spoofing, where adversaries might inject themselves into the system, act like the central source and transmit a known key variable to all units.

Key management is one of the most-important facets of utilizing encryption equipment and has often been identified as the Achilles' heel of any secure communications system. It is important that the pros and cons of all viable approaches be aired prior to the incorporation of one approach or the other. Naturally, this article reflects my bias against standardization on a detailed level in the field of cryptography. It seems that the last things one would want to standardize on are a single encryption algorithm and a single form of centralized key management.

Photo: A three-way illustration of different key-management systems.
COPYRIGHT 1986 Nelson Publishing
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 1986 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Author:McCalmont, Arnold
Publication:Communications News
Date:Apr 1, 1986
Words:1950
Previous Article:Using expert spreadsheets on a personal computer can help you save on long-distance circuit costs.
Next Article:Bank's network competes with industry's biggest and best.
Topics:


Related Articles
Lock your data network.
When Once Isn't Enough.
Watch your back: The mounting risks of unauthorized data access, theft and corruption in secondary storage. (SAN).
Secondary storage exposures. (Storage Networking).
Key terms in cryptography.
Preparing for encryption: new threats, legal requirements boost need for encrypted data.
Data encryption strategies; Part 2: encrypting high-performance, high-volume storage.
Encryption: we know we need it--so now what? Encrypting backed up data stored to tape or other mobile media.
Beyond compliance: protecting sensitive data on the mainframe environment: in the light of the British Government data loss, part two of a rather...
Key management for enterprise data encryption.

Terms of use | Privacy policy | Copyright © 2021 Farlex, Inc. | Feedback | For webmasters |