36

Crypt0 Management Made Manageable - Demands on Crypt0 Equipment Design

Viiveke F%k Dept. of Electrical Engineering Linkijping University, S-58183 Linksping, Sweden

Encryption is a very useful method for data protection, but its

use is often made unnecessarily difficult by products which are

not adjusted to common situations in the real world. Products

should be highly modularized, with encryption/decryption,

key management and protocol-dependent adjustments clearly

kept apart. Then products can be further refined to meet

specific customer demands on physical security, encrypted

communications between “dumb” and “intelligent” terminals

and nodes, true end-to-end encryption in complicated net-

works, etc. All this is necessary if encryption is ever to be of

real use in the computer world.

Keywords: Data security, Cryptographic protection, Key management, Protocol dependency, Cryptographic equipment

Viiveke F%t is graduate of Linkaping University with a doctorate in techni- cal sciences; she has continued her research concerning the use of cryp- tography in computer environments at the university. Her current position is as a member of the data security group which is working with problems in this area. She teaches computer security at Linkiiping University, and she was editor of Proceedings for IFIP/Sec’83. She is chairman of IFIP WG 11 : 4 on Crypt0 Management.

North-Holland

Computers & Security 6 (1987) 36-40

1. Introduction

Since September 1985 there exists an IFIP WG

11 : 4 on Crypt0 management. This reflects two things: 1. Encryption is today an important security mea-

sure. 2. The real problems facing security administra-

tors are concentrated in the areas of installing and handling the equipment or program.

The sudden increase in the use of encryption over the last few years is encouraging for someone who has advocated its use for more than ten years. It also shows that in spite of what was often hinted in the late seventies, crypt0 management is possible in a normal computer environment. One factor, that has to be taken into account is, of course, the dramatic increase in security concious- ness in most large organizations. Thus many mea- sures that were once taken almost as signs of paranoia have become normal routine at many installations. One example is the increased use of personal passwords and the emphasis on their protection. This has created a psychological plat- form and a natural object for comparisons when proper key management is discussed.

If you want to start using encryption, there are situations where you just go out and buy a pro- gram or a set of black boxes. Then you follow the instructions and make sure that all persons res- ponsible for new keys know their responsibilities and can handle the situation. That is all. You have the necessary security, and there are no problems.

One such situation is when you want to protect some specific files on your PC Winchester from colleagues who occasionally use your machine. Just as long as you choose a good key (not the project name or your own name, for example), the security provided by most commercially available programs is sufficient. However, if you want to use encryption in a more complex environment, there is considerable risk that you may run into serious practical problems. The main reason is that encryption is usually added to an otherwise

0167~4048/87/$3.50 0 1987, Elsevier Science Publishers B.V. (North-Holland)

V. F&k / Demands on Gypto Equipment Design 31

complete system, but it may influence the most basic levels of software and even hardware. Your plans for cryptographic protection may be thwarted by incompatibilities between what is offered, your system, and actual user require- ments. A more constructive way to look at the problems is to describe how cryptographic protec- tion should be packaged in order to meet the customers’ needs and thus be truly manageable.

2. Protocol Dependency

Computer data are just a number of bits. If you take a given set of bits, you can interpret it as characters recognizable by humans, you can use its exact bit pattern to control the behaviour of some circuitry (including a computer), etc. Con- trol in computer equipment can be governed by special lines, but data transmission and storage are so complex that you usually use bit patterns on the data lines to signal most events and situa- tions. But then, these patterns must be avoided by encrypted data in order to prevent misinterpreta- tion in some control unit in the system. In prac- tice, this means that the alphabet (the set of allowed bit patterns) is restricted to a subset of all the bit patterns that can be formed. Even worse, some protocols allow bit strings of any size of data, but some others demand that data are di- vided into characters of usually seven or eight bits. If the number is eight, there is very often the restriction that the number of ones in a character should either always be odd (odd parity) or even (even parity).

There may be further complications for the cryptographer in the fact that some protocols compute check characters like the CRC from as- semblies of other characters. With protocols of this kind, you must decide if the check is to be made on encrypted or plaintext data. This deci- sion influences many other activities. Plaintext checks mean that data must be decrypted at checking nodes, that data are readable in common buffers, etc. Checks on encrypted data mean that no logging, tracing or other actions based on the contents of data can be performed before the check. Both facts may cause problems in an ex- isting system with fixed logical and physical sites for different actions.

The ideal then is that the encryption produces

characters that look exactly like plaintext to the

protocol. The easiest way to achieve this is to ensure that encrypted characters never pass any protocol (except that of the encryption procedure of course). But this means that you have to insert the cryptographic procedure immediately before the modem (or writing head) on the sending side and immediately after the corresponding point on the receiving side. With modern integrated mod- ems, this is impossible unless you pay for an extra modem pair in each crypt0 box. You also exclude the possibility to have end-to-end protection in any more complex network. (Here everything but a single stretch of line from each terminal to one computer is a “more complex” network). Last but not least, you will have to pay for many boxes, and each has the cost of encasing, plugs etc.

A better solution is to adjust the encryption algorithm so that it produces only normal printa- ble characters from a standard character set. The best choice today would be ASCII. In spite of its name, it is in practice an international standard, and national variations only influence how certain bit patterns are represented in printed text. Prefer- ably there should be some built-in processing, which makes it possible to choose between seven or eight bits and even or odd parity for both encrypted characters and decrypted plaintext.

This, unfortunately, excludes the present DES

standard and its modes of operation since they will all produce every possible bit pattern of a given length, thus including control characters among the encrypted characters. The DES can be used as the kernel of a system which produces only printable characters, but then it is no longer a question of a standard.

This solution is also not complete and foolproof. So-called control characters might be allowed in the text in some system while they influence the behaviour at, for example, the terminal in others. Thus there is no “foolproof standard.” The really general equipment solves this by allowing the user to specify non-standard restrictions concerning a few characters. These are handled in the crypt0 system by preprocessing and postprocessing.

3. Dependency on Computer Architecture

It is not possible to produce a standard crypto- graphic procedure which can be directly installed

38 V. Fik / Demands on Gypto Equipment Design

in any computer system at any physical and logi- cal point. There is considerable difference between a black box intended for a V24 interface and a chip (or a complete board) meant to be placed within a given computer. There is also no standard language or microprocessor code which is availa- ble on all computers, and there is no standard interface between common languages which could be used for communications with existing pro- grams.

The solution, of course, is modularity. The al- gorithm is the kernel of the system. It should have a very strictly defined interface for input, output and control signals. Then different modules can be added to the algorithm in order to adjust it to different positions in the system, but it will still be possible to exchange encrypted data between these parts.

One example is a terminal which should be able to communicate with both a system that uses only encrypted data and a system which may send both plaintext and encrypted data. These two central systems do not know of each other’s existence and do not cooperate. For both there exist black boxes for decryption at dumb terminals. One decrypts every non-protocol character which passes through. The other obeys an on/off signal indicat- ing when encryption starts and when it ends.

With true modularity the supplier takes the black box for protocol controlled decryption and adds a few instructions to the protocol. These cause the box to set the “encryption on”-switch as soon as a given address is called from the terminal (or an external switch is in a given position). With a microprocessor-based system this addition is very cheap. With a system based more on customised chips, the cost is more noticeable, but it is very far from that of constructing a new box from scratch.

4. Algorithm

Another advantage with full modularity is that you can use a unique algorithm for each customer. A really good algorithm should be applicable ev- erywhere, but in reality there may be many rea- sons for wanting an algorithm of your own. One general reason is that there is no algorithm with guaranteed security. Evaluation of algorithms can lead to one of two statements today:

1. “We know that this algorithm can be broken under these circumstances and with this amount of resources spent on the effort.”

2. “We, who have so far taken a serious look at this algorithm, know today of no better method than exhaustive key search which will break this algorithm.”

The third evaluation, “This algorithm will defi- nitely not be broken within my lifetime,” will never be pronounced by a serious cryptologist unless, of course, it is a question of a “one time pad”-cipher.

Since security can never be guaranteed, some customers simply will refuse to put their eggs in the same basket where a lot of others already have put theirs. Naturally, there is more reward in breaking a cipher which is used by almost every one compared to a cipher which will give access to only one system. Thus the possibility to use differ- ent algorithms in the same basic equipment is an advantage.

This discussion is tightly linked to the question of standards. So far there has only been one standard in encryption, DES (DEA) and its modes of operation. The DES has now reached its pre- dicted lifespan of ten years. There are a lot of hints and guesses right now concerning its succes- sor, but one thing remains clear: some organi- zations will never install anything but a standard algorithm, while other will never install a standard algorithm. The really interesting part, however, is that the interface has not been standardized. The DES has created a de facto standard for its users, but that interface is actually a very inconvenient one for ECB and CBC modes. CFB and OFB are more useful, but the most important things, how to handle start, stop, new IV and key management, are left to the specific implementation.

5. Key Management

No matter when, where and how cryptography is used, real security can never be obtained without proper key management. The main issue here is to insure that no key is used long enough to weaken protection. The ideal is to relieve the user com- pletely from all tasks related to this problem, the equipment should take care of all the necessary actions. Unfortunately this is impossible, except for a few special cases. But the equipment should

V. Fdk / Demands on Cypio Equipment Design 39

still automatically perform as much as possible of the related work, and it should support any user- initiated actions.

The diversity of possible environments and uses for cryptography has a very marked effect on requirements for key management support. There are, however, a few basic features which should

always be present. Other features should be desig- ned to form a carefully chosen set of building blocks, which can be assembled into all variants of perceived useful configurations.

One basic feature is a protected storage area for the working key. In a hardware design this means that the key should not be shuffled back and forth from a “peripheral” cache storage or any such device during the actual encryption operation. There should be no internal lines where a bug could intercept the key. The encryption should be performed in a perfectly sealed device. The ideal is a single chip, which is encapsulated in a coating which cannot be removed without destroying the chip. When this is not possible, it can be sufficient to use a carefully sealed box around processor, storage etc. This box will hold the key in a volatile storage with battery back-up. At the slightest sign of attempts to open the box, the key is erased.

Software cannot offer sufficient physical pro- tection for the key. Software should never be used unless the environment is regarded as protected. This means, among other things, that there should not exist any realistic risk of bugs placed in the computer, surveillance routines added to operat- ing system, etc. Software can be used mainly in two special cases: transmission between two sites with 24-hour surveillance, and storing of data in an environment where the corresponding operat- ing system is not available for manipulation. Even in these environments the software must contain some extra precautions. Preferably it should be run only on machines which automatically clear all temporary storage areas at the end of each session. This must include such items as tem- porary areas on hard disk, etc. The encryption routine should itself erase the key at the end of a session. This is obviously not possible for routines which call for a letter by letter encryption since there is no “end of file” signal in that case. Thus, such routines should never be used for really sensitive data. Software should never be used for “top secret” data unless the computer is protected as if it were an encryption black box.

It would be very convenient if the working key

were the only key ever needed. If that were the case, this key could be physically locked into the equipment and that would be all the key manage-

ment needed. Unfortunately, the number of bits that can be protected in this way is very limited. This means that after a fairly short time the key must be changed. The ideal is to have this proce- dure automated, but the requirements for how and when this should be done are so different that generally applicable equipment must have several possibilities. The best way to achieve this is to have different modules with a standard interface to the encryption-and-working-key-storage mod- ule.

This design means that there must exist a secure channel into the protected module. This can be achieved in two ways: there can be a channel protected by physical locks, and there can be one protected by encryption. The second alternative means that there must exist a fixed key within the module; this key is usually called the main key. The first alternative means that humans must be highly involved in getting the key into the system. Such demands on the users are undesirable, so that alternative is used mainly for the infrequent loading of the main key.

Once there is a main key stored in the equipment, the key change can be automated. The machine can count the number of encrypted char- acters, detect the end of a session, etc. Whenever such a key change condition is recognized, the equipment generates a new key, encrypts it with the main key, and (in the case of transmission) passes it to the other end. It is highly likely that such procedures will mean that even the main key will reach its threshold of “too much used.” Thus, there should be intermediate levels of “session k eys, ” “key of the month,” etc, or there should be several main keys which are chosen at random for each key exchange. (The present choice is indi- cated by a serial number or any such innocent variable.) In the end there must still be a human, such as the security manager, who checks the present use of the equipment against the supplier’s recommended limits. Whenever such a limit is approached, the main key should be changed or the equipment discarded, an expensive and cum- bersome procedure. Thus, equipment should be designed to make this a very rare event.

It is obvious that key exchange of the kind

40 V. F6k / Demands on Ctypto Equipmeni Design

indicated above must rely on some kind of proto- col, so that the equipment “knows” whether the present data actually are the next working key, the next session key, encrypted user data or anything else. Here we are back to the protocol problems indicated above, since this protocol should be absolutely transparent to the rest of the transmis- sion or storage handling. In general, the demands from protocol independency and key management in combination are so diverse and yet fundamen- tal, that it is impossible to make a truly generally applicable encryption module, unless it is highly modularized and equipped with a simple way for the user to choose this desired functions.

A last comment on key management and physi- cal design: keys are generated and loaded (some- times through long distance transmission) but they are never read from the equipment. There should not exist any such physical channel. Keys are always produced through true random procedures, and any desired structure, such as parity bits, are added to this random skeleton. If the key genera- tion is not performed within the protected area, the generated key is always regarded as the en- crypted version and it is “decrypted” at both the generating and receiving ends when it is loaded as a working key.

6. Standard Equipment

Even if the individual case must always be care- fully analysed before installation of cryptographic protection, there are some situations which are

common enough to make it possible to construct equipment which can often be used without mod- ifications.

One such situation is encryption for “dumb” terminals in a poorly protected environment. This makes it necessary to use an “intelligent” black box which is adjusted to the transmission proto- col. Equipment without protocol adjustments will mean that end-to-end encryption is impossible, and that the customers will often be forced to place equipment at nodes which are actually not under their control. Thus protocol adjustment is a “ must.”

Another common situation is when small com- puters are used as intelligent terminals. In this case the user may use the computer for connec- tions to many different sites. Thus, the encryption cannot be performed in a black box adjusted to a single protocol. (Maybe even different algorithms will be needed.) Here the user needs a module which can easily be called both directly from user programs and from special communications rou- tines provided by the supplier.

Computer centers need high speed devices which can handle several communications simul- taneously with different working and basic keys for different connections. All these keys should have sufficient protection against disclosure. Here public keys may be of use.

Finally, there may be a need for a software routine which can perform with reasonable speed on any standard processor. This should be used with care, since its protection is always inferior to that of a special device in the same location.