merit for a network. User-level performance figures, such as response time and communication quality, are often much more important. The effect of security is to contribute to the values added to the network, at some degradation to the communication efficiency.

A quantitative evaluation of the overhead due to encryption security can only be made in the specific context of a given protection approach. The following factors must be considered in the determination of this overhead. No one system would utilize all of these approaches, so the contents of the list should be regarded as examples rather than as a suggested set of controls.

1. If clear text data blocks are less than 64 bits in length, ECB operation will result in a corresponding inefficiency in transmission usage.

2:

3.

4.

5.

If error control bits are included in the 64-bit block as a non-
forgeable check-sum, this overhead must be included as above.

Sequence numbers or time-of-day information may be embedded in each 64-bit block to detect spoofing threats such as the recording and subsequent playback of certain messages (e.g., a funds transfer authorization message).

A portion of the previously received message may be embedded in
each outgoing message to acknowledge the previous message and to
provide a "security handsḥake" (to authenticate that the receiver
of the messages can indeed decipher the messages).

Key distribution is via the same communication facility as regular
messages and therefore results in some small loss of transmission
throughput.

6. If CFB operation is used, there is a 64-bit prelude for each

separately synchronized message or packet.

A particular network design will utilize some subset of the above approaches in providing its security mechanisms. The subset should be evaluated to determine the overhead for that particular set of controls, and alternative designs should be considered to determine the optimal protection mechanisms for a given network and set of threat conditions.

The ICD has a very limited context of its overall usage, and therefore can only augment other monitoring functions and provide some degree of protection against accidentally induced security flaws. This latter category includes self-monitoring of its own operation, as well as some level checking against improper usage of a connection. Each of these areas will be briefly discussed

The ICD should be designed in a manner that will detect with a high degree of confidence any operational errors such as improper encipherment (in particular, the sending of clear text when it was intended to be enciphered), and an imbalance in the randomization; at least to the level of 1/0 statistics. Other tests are probably available, but are outside the scope of this investigation.

The ICD might be designed to detect, and perhaps report, a number of anomalous events such as (1) the receipt of an invalid initial connection request (e.g., attempted playback or forgery of a control message) and (2) the attempted transmission of a message with an indicated security level that is higher than allowed for the established connection. These features would add some complexity to the ICD, namely the need for detection capabilities and for reporting to the SC.

The SC has little or no monitoring capability for the usage of a connection, and it is unlikely that the ICD can improve this situation to any significant extent. However, the ICD could augment the SC's capabilities in other ways such as by allowing the SC to "break" an existing connection under certain circumstances. Such a feature would have to be included in the initial design, if desired, and would also be affected by the type of communications net (e.g., direct dial or store-and-forward).

There is no reason to believe that the usage of ICD's will decrease the physical and procedural protection requirements from those of current crypto devices. The primary difference in this regard will be that the manual updates of private keys will not be required with as great a frequency as the manual updates of working keys. The procedural aspects of such changes would not necessarily differ.

The basic technology has changed considerably in recent years, and there are cost and reliability motivations to utilize the more recent techniques. Therefore, we can assume that the ICD development would be oriented towards the usage of microprocessor/ROM-logic*, and therefore could also utilize the proofof-correctness techniques that were discussed in Section 3.6.

There is a growing tendency towards the usage of ROM (Read Only Memory) program steps to replace hard-wired logic.

If ROM's were to be utilized in the ICD development, they might also serve as
This might be particularly attractive

an ideal mechanism for the private keys.
for the case of programmable ROM's (PROM's).

The remaining items to be considered fall into two major categories: (1) those related to the cost/complexity issues of the ICD's and (2) those related to the communications network and the HOST-level control programs.

The ICD should be viewed as a set of components from which one can tailor a set of devices to meet differing operational and technological requirements. These differences are caused by differing requirements for:

Since it is quite likely that networks will continue to involve a variety of needs, devices, and communication technologies, one should develop the ICD's with an appropriate degree of flexibility. However, the cost constraints will also differ such that one can not afford generality at the expense of raising the cost to all end users. Therefore, the modular (building block) approach seems most desirable. Referring back to Figure 4-5, we can assert that (1) there should be at least four versions of the interface to the data processing

equipment (for the four types of equipment listed above), (2) three versions of the crypto device (dedicated, multiplexed, and master), and (3) the four different network interfaces. Not all combinations of these three modules would be allowed (e.g., a master crypto device would not be attached to anything other than an SC), but the standardization of inter-module interfaces is still desirable. If current Large Scale Integration (LSI) technology is to be utilized in the development of ICD's, the need for volume production must be considered, and might swing the balance towards more commonality even if the resulting devices were more complex. Since the network and HOST interfaces

are typically not standardized in any meaningful fashion, such commonality could only apply to the inner portion of the ICD, namely the cryptographic subsystem. If, on the other hand, hard-wired logic were to be utilized, there appears to be an economic advantage to simplifying the terminal ICD's whenever possible, at the expense of adding complexity to the HOST ICD's.

The network interface module of the ICD (as shown in Figure 4-5) should contain those control functions appropriate for the particular communications network. This would include the capability to automatically dial numbers in a direct dial network, or to create connections via protocol control messages in an ARPAlike net. All such network-dependent functions should be implemented in this module to ensure that the higher-level modules (e.g., the HOST interface) is generally usable.