Download Practical Problems with a Cryptographic Protection Scheme and more Exercises Cryptography and System Security in PDF only on Docsity!
Practical Problems with a Cryptographic Protection
Scheme
Jonathan M. Smith Distributed Systems Laboratory Department of Computer and Information Science University of Pennsylvania Philadelphia, PA 19104-
ABSTRACT
Z is a software system designed to provide media-transparent net- work services on a collection of UNIX® machines. These services are comprised of file transfer and command execution; Z preserves file owner- ship on remote transfer, and more significantly, owner and group identity when executing commands remotely. In order to secure known vulnerabil- ities in the system, enhancements were made. In particular, a crypto- graphically-derived checksum was added to the messages. After the initial implementation of the checksumming scheme, several iterations of perfor- mance improvement occurred. The result was unsatisfactory to the user community, so the checksum was removed. Instead, vulnerabilities were reduced by improved monitoring and maintenance procedures.
1. Introduction
1.1. History
Z was initially implemented circa 1978 in order to cope with an ever-increasing number of UNIX systems at a large industrial computation center. The environment was becom- ing unmanageable; unmanageable in the sense that it was difficult to administer the sys- tems in a controlled and consistent manner. It was clear that some mechanism which allowed a user to operate in a true multi-system environment was necessary. However, there was no consistent network organization. There were a variety of subnetworks of various reliabilities and bandwidths, these included bus-to-bus, channel-to-channel, and synchronous remote job entry (RJE) links. RJE served as a fully-connected network (albeit
This work was supported, in part, by Bell Communications Research, (Morristown, NJ) under Pro- ject DAWN.
a slow one) as all systems were connected to some mainframe system for various ser- vices, e.g., bulk printing. The Network Systems Corporation HYPERChannelTM^ bus is a very high speed ( circa 50Mbits/sec) device that allows machines to be interconnected in a local area network. In late 1981, an NSC HYPERchannel began to connect all the sys- tems, and due to its bandwidth, became the primary media for Z communication. Z pro- vided an easy to use and uniform interface to the network; the physical media used in the transport is transparent to the user. Use of the media was optimized by a statically- calculated bandwidth-weighted best-path selection scheme coupled with dynamically- calculated reliability data.
1.2. Architecture
Z is viewed by a large segment of its user population as a UNIX command with which they accomplish various tasks across several computing systems. In actuality, Z is a large collection of both loosely and tightly coupled cooperating software modules, distributed across all machines on the network. The command invocation is the first link in a long chain of events.
The Z command line syntax specifies file transfer or remote execution. The stan- dard input of the local Z execution can be used to provide input for the remote command. The Z semantics preserve user ids on the remote system, both for file permissions and command execution. One or more systems can be specified as destinations, and aliasing is available for compact naming of subsets of the available systems.
The Z system provides facilities for examining queued jobs, retrying jobs when fail- ures occur, removing corrupted files, notifying senders upon error or job completion, and secondary routing on link failure. Various internal machine-to-machine interfaces were devised to mask incompatibilities between heterogeneous processor families.
The basic architecture of the system is illustrated in figure 1.
1.2.1. Local Actions
The Z command serves as a gateway to the lower level transport layers of the system. It ‘‘packetizes’’ the data to be transported, storing such information as can only be gathered at invocation time, such as the current directory and identity of the invoking user. If a file name was given as an argument, Z ensures that the file is accessible, and saves other information, such as the file’s ownership, the access permissions, and the file size in char- acters. Also on the command line can be a list of one or more destination systems; some validity checking is done on these names. Z can also take a command string as an argu- ment.
Based on the arguments and the identity information, Z builds a header, which is used by other modules. Any data to be transmitted is then appended to the header. The bound data ‘‘packet’’ is passed to a ‘‘gatekeeping’’ module, Z qer. Z qer is invoked as the last action of the Z command with the exec() system call. It takes the formed data packet and enqueues it in a known spool directory, where the transport control module, Z demon,
Z
command
Z
spool
local network service
data transfer
remote network service
Z
spool
Z xmit
Z qer
Z demon Z recv+qer
Z demon
Figure 1: Z Architecture So that Z can maintain user id’s across systems, several modules must possess super-user (unlimited file access) privileges. While passive interception is potentially dangerous, as it provides information, we were rather more concerned with active inter- lopers; those who intend to modify data and/or commands.
1.3. Security Problems
In 1983, we became concerned about the security of Z , and immediately recognized sev- eral potential vulnerabilities. These stemmed from several architectural features, as can be gleaned from figure 1. The fact that the system preserves user identity is the major reason for a security threat. First, the ability to execute commands remotely means that a breakin on one system can be extended to others. Second, the complete interconnectivity provided by Z meant that a breakin on one system could be extended to all of the machines. If a Z packet could be modified enroute to its destination, then the user id or any message contents could be set to interesting values. Thus, the points of vulnerability [8] were those which had the potential for message alteration.
First, the spool had to be kept secure, or otherwise files with arbitrary contents could be written. Second, the local network services had to be kept secure. This was more of a problem than it appeared; these systems often spooled jobs internally, and their access- control strategies were not easy to change. To verify the claims we made about the lack
of security inherent in the system, we obtained root permissions from an ordinary account. This was done through altering a file spooled by the RJE mechanism. The file resided in the UNIX spool for about 0.5 second, and was enciphered with a simple modifi- cation of a Caesar scheme. Unfortunately, the software preserved user ownership of the spooled file, so that a user could modify the file. This was necessary due to the design of the RJE software. Breaking the cipher was trivial, and by repeatedly sending messages and polling, a file was captured, modified, and transmitted to its (unsuspecting!) destina- tion. Simply protecting this spool directory and modifying the RJE software was insuf- ficient; the RJE jobs were spooled on the mainframe as well, where we could not guaran- tee security.
2. A Server-based solution
After studying the problem, we came to some conclusions:
- While administrative control was not completely ours (as was the case with interme- diate mainframe systems) the system was at risk.
- We were far less interested in protecting against traffic analysis than in protecting against modification.
- Sending enciphered messages was undesirable for several reasons, including (1) recovery from errors, (2) use of intermediate nodes needing source and destination data, and (3) system status reporting.
- In addition, requirements were that the user interface could not change, e.g., by requesting a password.
After examining the literature on data security [5, 2] we decided that the right approach was to use a cryptographic checksum in order to detect data modification. The checksum is computed by encrypting the data and then computing a checksum from the encrypted text. Thus, the messages could be sent in cleartext, with a checksum prepended to the header. Modifications could be detected, and modified messages discarded. The improved error-detection was a byproduct. Since changes to either the header (uids) or the message (binaries for system programs) were dangerous, the entire packet had to be involved in the checksum. The initial implementation used a 32-bit checksum.
A variety of encipherment schemes were examined, and experimental implementa- tions were done to evaluate the performance of the schemes. Even after implementation in assembly language, a cryptosystem using large primes consumed unacceptable amounts of CPU time, even for very short strings. DES [4, 5] was examined, but once again the throughput of the implementation was insufficient. While it is clear that DES is intended to be implemented in hardware, the chips available at the time were expensive and slow. In addition, we had three architectures to contend with, and kernel changes would have been necessary. We sped up the UNIX library implementation of DES by a factor of 3 using hand-optimized code and small assembly-language routines. Recent research [1] indicates that speedups up to a factor of 20 or more can be accomplished by applying some mathematical sophistication in the software implementation. Our speedup reduced the CPU time required for encrypting a one megabyte file from about 2340
Z
command
Z
spool
local network service
data transfer
remote network service
Z
spool
Z xmit
cksum server
Figure 2: Z Architecture with checksum server
The server was passed a filename argument using a secure FIFO queue. The filename was for the packet which Z had just gathered. Insertion in the queue by a process woke the server, which enciphered the file, computed the checksum, and passed back the result to the calling process. The passwords were per-system, stored in a secure file, which the server checked frequently for modification. The passwords were encrypted using DES [6], and served as seeds to the rotor generation for the Enigma-clone. If the file hadn’t changed, the encryption was cached, for performance reasons. It’s clear that a public-key system would have been more effective for this task, but the available systems performed too poorly.
The idea of the server architecture was to emulate the semantics of a remote proce- dure call. In this way, the server process could be transparently replaced by another server process with the same functionality which used hardware encryption or other tricks to get better response times.
2.2. Problems
The basic design of the server was well thought out, and in another systems environment, may still be the right way to go, because the advantages in terms of software engineering are manifold, e.g. modularity, information-hiding, et cetera. Unfortunately, encryption is a CPU-intensive activity; hence, the UNIX system scheduler assigns the server process
lower and lower priority as time goes on, and it becomes "slower" with respect to response time. Improved scheduling technology could remedy this problem, but it was neither available nor administratively desirable, except for our application’s use.
Since the process ( Z ) waiting for a reply (the checksum) cannot assume that the server is up, it can time out on the write to the server’s request queue, using the alarm() facility. While it can retry, if the server is sufficiently slow the request may not be ser- viced ‘‘in time’’. If this occurs, the packetizing software will assume server failure and therefore fail to packetize the request. On the other hand, if timeouts are not facilitated, the software may appear to be so slow that users will find alternate means of data trans- port. For large files and a busy server, the response times were measured in minutes.
In addition, the server proved to be an administrative nightmare: it was hard to understand without a great deal of expertise in encipherment, systems programming, and network software; it created ‘‘mysterious’’ files when it wasn’t keeping up with the request queueing rate; and it was dependent on the sanity of several files. Consequently, a re-design was done which preserved most of the positive features of the server design, while improving response time and reducing administrative effort.
3. Re-design, no server
The major goal of the redesign effort was (initially) to increase the reliability of the server process, and hence reduce the administrative effort. After a painstaking analysis of the alternatives, it was decided that the server module should be removed and the encryption services be provided by in-line code rather than interprocess communication. While on the one hand, the burden of performing a DES encryption on the cleartext password could not be shared between users of a server, the following were true:
- A small data transfer would not be penalized in real-time response for following a large data transfer in the request queue. (The large transfer would cause an external server to accumulate a large amount of CPU time, thus penalizing it in the schedul- ing discipline.)
- The DES encryption is not necessary, provided that any cleartext password is encrypted before being put into a secured file.
- Per system passwords were eliminated, as this proved to be of little use in practice. One password is used for all systems on a Z network; eliminating a system would then require changing the password on all machines except the one to be cut off.
- While re-engineered to be robust, the interprocess communication was complex, and slow in response time. Putting the code in-line permitted several optimizations, which led to significant performance improvements, a factor of 3 to 5.
The necessary code to perform checksumming and encrypting of file contents was moved inline. The Pack() and UnPack() calls were designed so that callers would be ignorant of their methodology; this proved to be true in practice, as not one line of the calling mod- ules had to be re-coded to reflect the fact that the server had been eliminated. The inter- process communication code was eliminated and the CheckSum() call made directly. The encryption algorithm was modified to remove a reflecting rotor from the encipherment
However, when the networking technologies such as EthernetTM^ are broadcast media, ‘‘promiscuous-listeners’’, and more seriously, ‘‘modifiers’’, start to resurface as an issue. Thus, the increased computational cost of creating a system with a higher crypto- graphic ‘‘work factor’’ begins to seem more reasonable. The economics of cost/performance might justify special-purpose hardware, e.g., for DES encipherment. The tradeoffs between security and response-time should be examined carefully, and fre- quently.
In particular, a useful and productive area of research would be one which resulted in a set of curves which related cryptographic strength to some useful performance met- ric. One such metric, alluded to in this paper, is the number of arithmetic operations required per byte of a large file. The analysis represented by the performance curve allows a system designer to compare systems and select an appropriate system for the application. Without such analysis, most cryptographic work is likely to remain of inter- est mainly to mathematicians; practical work requires getting the details right.
5. Notes
® UNIX is a Registered Trademark of AT&T Bell Laboratories.
3B20 is a trademark of AT&T.
VAX is a trademark of Digital Equipment Corporation.
HYPERChannel is a trademark of Network Systems Corporation.
Ethernet is a trademark of Xerox Corporation.
6. References
[1] Matt Bishop, ‘‘An Application of a Fast Data Encryption Standard Implementation,’’ Computing Systems 1 (3), pp. 221-254 (1988).
[2] D.R. Denning, Cryptography and Data Security, Addison-Wesley (1982).
[3] F. T. Grampp and R. H. Morris, ‘‘UNIX Operating System Security,’’ AT&T Bell Laboratories Technical Journal 63 (8, Part 2), pp. 1649-1672 (October 1984).
[4] A. G. Konheim, Cryptography: A Primer, Wiley-Interscience, New York (1981).
[5] C. Meyer and S. Matyas, Cryptography: A New Dimension in Computer Data Secu- rity, Wiley-Interscience (1982).
[6] R. Morris and K. Thompson, ‘‘UNIX Password Security,’’ Communications of the ACM 22 , pp. 594-597 (November 1979).
[7] J. A. Reeds and P. J. Weinberger, ‘‘File Security and the UNIX System Crypt com- mand,’’ AT&T Bell Laboratories Technical Journal 63 (8, Part 2), pp. 1673-1684 (Octo- ber 1984).
[8] D. M. Ritchie, ‘‘On the Security of UNIX,’’ in UNIX Programmer’s Manual, Section 2 (1983). AT&T Bell Laboratories
