Fig. 4 Conceptual diagram of Prototype 11.
The structure of an S-program as implemented in Prototype II is shown in Fig. 5. The pricing information for a S-program is contained in its tariff section. When execution of the S-program is initiated, the coprocessor verifies the information in the tariff section and copies the pricing information into the accounting buffer of the S-box. A verification routine, described below, is embedded in the body of the S-program. Execution is aborted if the verification routine detects any inconsistency in the tariff section.
The tariff section includes the following:
Fig. 4 Conceptual diagram of Prototype 11.
Note that items (4) and (5), which together constitute the pricing information, allow for two styles of charging: per unit of time (by setting (5) to zero) or per execution (by setting (4) to zero). Combinations of the two styles are also possible.
Fig. 5 Structure of S program.
Execution of an S-program is monitored by the program and the coprocessor working together. The coprocessor halts execution whenever it detects a protocol violation. For proper protection, the S-software must be structured so that analysis of it by an intruder is not possible. Some methods of achieving this are:
These methods can be used individually or in combination.
The sequence of events that takes place as an item of S-software is executed is as follows:
*Initialization. The pricing information is sent to the coprocessor by the initialization routine when execution of the S-software commences. This can be done using general purpose coprocessor instructions[9] S-credits are then decreased periodically until execution of the S software is terminated.
*Execution. The check routine in the software body is executed, and execution of the software is aborted if the prescribed protocol is not satisfied. Methods 1-3 of execution control as described above have been implemented. The implementation techniques are as follows:
--For (1), the software ID, the access control key, and a random number are sent to the coprocessor The random number can be encrypted, although we have not yet done this. The result of comparing the random number with a known value is then returned to the processor.
--For (2), we transfer a jump address table to the coprocessor during initialization. This table can subsequently be referenced by the S-software. The coprocessor then returns the appropriate jump address.
--For (3), the access control key, the range of acceptable response times, and a random number are sent to the coprocessor. The range is represented as a lower limit and an upper limit. The coprocessor then checks that the time of the next message is within the limits. *f it is not, the coprocessor aborts execution of the S-software by interrupting the main processor.
*Termination. The coprocessor is informed when the S-software has completed execution. This can be implemented using general purpose coprocessor instructions. At this time the payment file is updated to account for the usage.
The payment file keeps track of S-credits that are owed as the result of software usage. Each record in a payment file ordinarily contains three fields: a payer. a receiver, and an amount. The collection of payment files is an essential function in a superdistribution system in order to make sure that revenues are properly distributed to the providers of services.
The privilege file records a user's privileges with respect to software usage. For example, if a user has purchased a program then the user has the privilege of using it thereafter without paying any additional fees. Another kind of privilege is a volume discount: after a certain amount of usage, the charging rate is decreased. Carryouer is a form of discount in which the money that a user pays for usage of a program is deducted from its purchase price if the user chooses to purchase the program at some later time. Carryover can be accommodated by associating a carryover parameter c with a particular program, where c is no greater than 1. Should the user decide to purchase the program, a credit of c times the accumulated usage charges is deducted from the purchase price. If a vendor chooses to set c to 1 for a particular program, then a user of that program need not make any decision as to whether or not to purchase the program. Carryover, if provided, is also recorded in the privilege file.
Some forms of superdistribution can be realized without having a privilege file. In these forms the charges are based on services provided, e. g. 10 credits for each program execution, 2 credits for each file save, 5 credits per printout, and 1 credit per 18 seconds of execution time.
The privilege file grows with time, since information is added to it but is rarely if ever deleted. Moreover it must be preserved indefinitely. It is ordinarily the obligation of a software vendor to provide backup for the portion of the privilege file pertaining to that vendor' s software.
A record in the privilege file is ordinarily generated at the same time as a record in the payment file and stored in the user's machine. In some environments in which users send payments separately, the vendor may generate records to be placed in the privilege file, but this arrangement is usually less convenient for users.
The portion of the privilege file pertaining to a particular vendor's software can be kept either in the user's machine or by the vendor. If privilege records are generated in one place and stored in another, then the superdistribution system must make allowances for delays in transmission and in confirmation.
If a superdistribution system provides for trial usage of software either free or at a discount, it must keep records of that usage in a trial usage file. Otherwise a user could use software indefinitely on a trial basis. a. These records need to be backed up. although backup is less critical than it is for the privilege file. The reason is that trial usage is not an obligation but rather a gratuity on the part of a vendor, and a vendor can reserve the right to cancel the privilege of trial usage at any time.
The benefit file keeps track of special benefits granted to the user by various vendors. The benefit file differs from the privilege file in that the information in the benefit file has no direct correspondence to the information in the payment file and is unaffected by what software is used or how much it is used. Examples of information in the benefit file are a certification entitling the user to educational discounts or a secret number entitling the user to run a certain program not available to the general public.
The account file is an aggregation of the particular files we have just discussed: the payment file, the privilege file, the trial usage file, and the benefit file.
A superdistribution system needs to provide secure backup for its accounting files and for the privilege file in particular. It need not make any special provision for backing up software since a user can back it up by any convenient means or get another copy without cost if the original copy is lost.
The backup requirements for the privilege file depend on whether or not privileges can decrease with time. If not, it suffices to ensure that the process of restoring the privilege file from its backup cannot generate additional privileges. This requirement can be met by associating an ID and a randomly generated validation number with each privilege file and encrypting the file before backing it up. The restoration process checks to make sure that the decrypted validation number is correct and that the backup file is indeed a proper one.
Since a user of an S-computer should be able to ascertain the status of his account at any time. we have built a user interface for retrieving and displaying that information. The user interface program provides two functions:
Fig. 6 Example of execution of user utility program.
In Prototype I we implemented the user interface within the Software Usage Monitor; in Prototype II we have implemented it as a separate program. By making it a separate program we reduce the size and complexity of the software that needs to be permanently resident in the S-box. Prototype I allowed a great deal of flexibility in the way that usage was charged; Prototype II has adopted a simpler system based on a combination of charges for performing specific actions, e. g. opening a file, and charges per unit of time.
An example showing the execution of the user utility program is shown in Fig. 6. The user can inspect the record of software charges, the remaining credit balance. etc., through this program. Although Prototype II does not have a general multi-programming capability, it does allow the user utility program to be executed while an application program is also executing.
| Virtual School | Middle of Nowhere | Brad Cox |
|---|