The function of the S-box is to execute the Software Usage Monitor in a secure way. The S-box also contains the cryptographic keys that ensure the integrity of the system. These keys are kept secret by storing them within a digitally protected modules (see Sect. 6).
An S-box can be added to an existing computer in any of several ways:
Methods (1) and (2) require no modification to the computer; our Prototype I used method (1). This method has the disadvantage that it introduces significant overhead in a multi-programming environment. Method (4), though more difficult to implement initially, offers the best performance and the lowest cost. Because methods (3) and (4) require modifying the computer, we chose to use method (2), connection to the bus, for Prototype II.
This connection is best realized by making the S-box a coprocessor and using an existing coprocessor socket. Our current implementation uses a second computer connected to the coprocessor socket of the first one; our goal is to fabricate the S-box as a single chip that can be placed in that co-processor socket. We are using an MC68020-based computer because of its compatibility with other equipment in our laboratory, but adapting the design to other types of processors is not difficult.
All the protection needed to ensure the integrity of the payment files and of the software is concentrated in the S-box. There is no need to protect any of the communication paths shown in Fig. 2. The signals sent over the communication paths are all encrypted, so dedicated networks are not necessary to ensure the security of the system. Any public network can be used, and the added cost of a dedicated network can be avoided. In fact, since the communications links need not be kept constantly active the system is even suitable for use with portable personal computers.
The S-box provides a limited form of protection against viruses, in that programs that are specifically designed to work with the S-box,cannot be modified at the user's computer and so cannot be disabled or other wise taken over by a virus. However, the S-box does not protect against programs, distributed through superdistribution or otherwise, whose effect is on parts of the system unrelated to the S-box.
Fig. 2: No protection of communication paths results in better performance/cost
Some of the functions called for may appear to be expensive--in particular, the ability
to provide the necessary physical protection and to erase the cryptographic keys
recorded in the S-box in the event of an attack. However, these functions can be
achieved at reasonable cost if the S-box is mass-produced as a single IC chip (or
a small group of such chips).
The workings of the S-box, which we describe below, depend on the existence of cryptographic keys within the S-box. A potential problem could arise were the equipment manufacturing the S-box to be disabled and the values of the keys to be lost. This problem can be solved, although it requires the use of a different kind of protected module.
We ha*re considered but rejected the idea of using simpler memory cards[2] similar to the farecards used in some transit systems, that would merely rec.ord an account balance. There are two problems with such cards. First, separate mechanisms would still be needed to record and transmit the accounting information described above. Second, the devices generally available for reading and writing such cards are insufficiently secure. A cheater could obtain such a device and modify the data on the card without using the S-box at all.
The Software Usage Monitor is executed in the S-box. It performs the following functions:
An S-program can issue instructions to the Software Usage Monitor. These instructions are realized as extended instructions of the CPU.
In Prototype II we have implemented the Software Usage Monitor through an emulation of the coprocessor functions. We have used an MC68020 board fitted with an MC68881 coprocessor socket, connecting a second computer (the emulator) to that socket through an interface circuit as shown in Fig. 3. The current implementation does not provide for multi-programming because the Apple Macintosh we are using, to which an MC68020 board is plugged in, does not yet have that capability.
Further limitations on Prototype II are that it does not provide encryption and that it is not encapsulated as a digitally protected module. We consider those limitations acceptable because the purpose of our experiments at this stage is to validate the execution control and charge control functions of the Software Usage Monitor.
Figure 4 shows a conceptual diagram of the architecture of Prototype II.
Fig. 3 Implementation of Prototype II.
The cryptography section performs three functions:
| Virtual School | Middle of Nowhere | Brad Cox |
|---|