In the early 1970s, a series of papers funded by the U. S. government fo-cused on computer security. These papers form the basic building blocks for trusted computing. The following discussion is by no means exhaus-tive; rather the list highlights some of the major findings of those early researchers.2
1970 Task Force
In 1970, long before personal computers, a computer task force made a seminal report on computer security (Ware 1970). The task force, lead by the Rand Corporation, was attempting to define the security requirements for computer systems that had a mixed of users and systems. While the thoughts of the group were concentrated on time-shared mainframes, the actual results hold true for client and server platforms of today.
The task force had some specific recommendations for both hard-ware and softhard-ware. The hardhard-ware recommendations were:
■ User isolation. The isolation requirement stated that each user program must be isolated from every other user program.
■ Supervisor protection. The supervisor, or the entity managing the user programs, must have protection from every user program.
One distinct recommendation was to create a user mode and a supervisor mode. The user mode would be restricted and the su-pervisor mode would have complete control of the system.
2 The author is a great lover of history and reading historical documents and findings. You can provide the impetuous for solutions to today’s problems by rereading these papers and coming to the understanding that many of the issues we face today are not new, that they are variations on an old theme.
Chapter 2: History of Trusted Computing 19
■ Assurance against unanticipated conditions, including an in-terrupt system. With programs not always operating correctly, something unexpected could always happen. The system must have the ability to handle the unexpected events in a set manner.
The software recommendations were:
■ Language processors and utility routines. For code in assembly language, the recommendation was to make the code particularly difficult to secure. High level languages—think FORTRAN3 at the time this document was produced—should use libraries of evalu-ated utility routines.
■ Supervisor program. The key to the hardware’s supervisor pro-tection lay in these characteristics:
− Run as much of the supervisor as you can in user mode.
This recommendation seems to have fallen of deaf ears. Many operating systems of today require user applications to have access to supervisor mode, and the size of the operating sys-tem is growing exponentially. Much of LaGrande technology (LT) is an attempt to separate user and supervisor modes and to allow the supervisor to place portions of the supervisor into user mode.
− Clean up after sensitive data is in use. After a user program uses sensitive data, the supervisor must ensure that all sensi-tive data is not available to any other process. While user mode should perform the cleanup, the supervisor must en-force the protection of sensitive data.
− Orderly startup and shutdown. This point is very important.
The requirement is for a controlled startup that puts the ma-chine in a known state. The shutdown must occur in a way that properly validates all sensitive information. Remember, this requirement in the design of LT.
− Certified ability to control access to files. The recommenda-tion was to ensure that all file accesses were validated, and that they went through a known control point.
3 While the author hates to admit it, he actually coded FORTRAN on punch cards
20 The Intel Safer Computing Initiative
One point to remember with this paper is the date, 1970. The requirements for a secure system are being defined before personal computers, before the Internet, before computers on every desk. The requirements come out of trying to share a computer that does more than one job at a time.
Bell-LaPadula
By 1976, research was taking some of the task force recommendations and diving deeper. The Bell-LaPadula paper (Bell 1973) presents a mathematical model of a secure system. The paper contains descriptions of all of the “actors” in a secure system and of the operations that are necessary to enforce the security. The basic building blocks are:
■ Domain separation. Separate processes make sure that the re-sources of one process are not available to any other process.
This recommendation matches the user isolation and supervisor requirements of the 1970 task force.
■ Identification. The identity of the user is very important. The identity allows the system to make decisions about use that are based on the user’s identity. For example, a user might be granted access to a process only during regular business hours.
Without properly identifying the user, the system owner would have no way to enforce the use restriction.
■ Authorization. Using the user identity, the system owner gives the user permission to perform various operations. As in the pre-vious example, the authorization might allow the identified user access to the process during regular business hours or during weekend hours, depending on the job function of that user.
The Rainbow Series
In 1985, the U.S. Department of Defense released the “Rainbow Series.”
The individual volume that people most often remember is the “Orange Book” (Department of Defense 1985), which describes a trusted com-puter system, the evaluation criteria for a trusted system, and how to use the trusted system. Other colored volumes in the rainbow of this series describe the nitty-gritty details of the trusted system and its use.
Chapter 2: History of Trusted Computing 21
Security System Evaluation
The Rainbow Series begat the European ITSEC evaluations, and the combination of the Rainbow Series and the ITSEC begat Common Criteria, an international agreement on how to evaluate security sys-tems. Evaluation is way beyond the scope of this book. If you are in-terested in looking at evaluations, the Common Criteria Web site is listed in “References.”
The Rainbow Series is a wonderful source of the requirements for a trusted system in the 1980s. It defines how to build, distribute, and use the trusted system. What it does not contemplate is how to work with a per-sonal computer. The whole thought process behind the Rainbow Series, and the Orange Book in particular, takes place in the context of a main-frame computer sitting in a computer room. The idea that the user would be able to load programs, or change the operating system, is just not possi-ble with the Rainbow Series. It turns out that getting an Orange Book evaluation of a PC is very difficult and depends on the system being “locked down.” The Common Criteria begins to solve many of those issues.
Industry Response
The U.S. Department of Defense was both a definer of trusted systems requirements and a purchaser of trusted systems. Industry provided to the government both the hardware and software to meet the Department of Defense requirements.
On the hardware side, industry leaders like IBM, Control Data, Digi-tal, and others, defined and developed mainframe computers that pro-vided the underlying features that enable trusted systems. From the ability to create user modes and supervisor modes, to the ability to sepa-rate applications, to the ability to handle unexpected operations, main-frame hardware supported trusted system development and deployment.
On the software side, mainframe operating systems used the hard-ware and provided the separation recommended by the various research papers. Some operating systems and applications implemented the mathematical models of Bell-LaPadula. A rich history of operating system research attempts to implement the necessary controls. A Google search of topics like “Trusted MACH,” “Fluke,” “Flask,” and “SELinux” would show you the ongoing research to define and implement trusted operat-ing systems.
22 The Intel Safer Computing Initiative