Capability-Based Usage Control Scheme for Network-Transferred Objects

Shuichi Tashiro <tashiro@etl.go.jp>
Electrotechnical Laboratory
Japan

Abstract

This paper describes the concept and implementation of the newly proposed "capability-based" software usage control system. This idea aims at implementing a mechanism for managing software usage at the point and place of use, so that regardless of the path taken by the software (proxy servers, etc.) and the means by which it is distributed, the software will be managed in a manner reflecting the wishes of its originator. Software (or objects) distributed under this scheme includes conventional software and a "usage control program," which is protected from illicit modification by digital signature technique. Originators of software can describe conditions for using the software in the form of procedure-oriented programs, and can give users "capability," which represents information describing the right to use the software. The usage control program refers to the capability owned by the user, who determines whether to allow the corresponding software-body to provide the service.

By applying usage control programs and capability, a far more flexible, user-friendly system of usage control can be obtained than by using simple revenue collection and password-based user approval.

Contents

1. Introduction

The rapid expansion of the Internet has enabled a wide range of people to exchange a great variety of information. An important feature of the Internet is homogeneity--equal access regardless of where users are connected. By applying this homogeneous connectivity to the data-transmission and reception functions of the World Wide Web (WWW), an environment has been created in which all kinds of users on the Internet around the world can transmit data, and that data can be freely used by numerous unspecified users.

However, the lack of usage control over the information transferred via this network has become a growing problem.

The data exchanged using such as Web pages on the Internet includes not only free information available to all users without discrimination, but also a considerable amount of information that, because it is of value and because its privacy must be protected, is meant for specified users only. Moreover, because mirror servers and proxy servers, which relay data from Web servers, are being used more and more, the problems of usage control are increasing.

This paper proposes a capability-based usage control system for objects distributed over networks. By "objects" the author refers to any software distributed by a network, including Web home page data, image data, and computer programs.

This idea aims at implementing management mechanism of software usage at the point and place of use, so that regardless of the path taken by the software (proxy servers, etc.) and the means by which it is distributed, the software will be managed in a manner reflecting the wishes of its originator.

Similar ideas have been suggested under the terms "superdistribution" [1][2], "copy-free software" [2], and "pay-per-use software" [3]. These concepts are closely related to usage-based revenue collection schemes in other industries such as cable video. Software itself can be freely copied and distributed without charge but with revenue collection based on usage.

However, revenue collection is not enough to satisfy the various requirements of copyright holders such as authors, owners, or distributors of software. For example, some copyright holders may not want remuneration but may wish to designate their products for use by specified users or user groups.

A capability-based usage control scheme expands on the notion of the superdistribution mentioned above, incorporating a mechanism for assigning usage rights on a capability basis. Software (or all types of objects) distributed under this scheme includes the conventional software and a usage control program. Copyright holders can describe conditions for using the software in the form of procedure-oriented programs. Copyright holders then give users capability, which represents information describing the right to use the software.

By applying usage control programs and capability, a far more flexible, user-friendly system of usage control can be obtained than by using simple revenue collection and password-based user approval.

The idea of capability-based usage control can be used not only for software distributed over networks, but also for hardware scattered throughout the network, such as mirror servers, routers, and network circuits. The author will refer generally to such usage control as a capability-based resource management (CBR) scheme.

2. Concept of the capability-based resource management (CBR) system

As indicated in Figure 1, the term "resource" refers to the software, information servers, network circuits, and so on that are used to provide services to clients. A "client" is anyone who receives such services, whether a person (in fact, the workstation used by that person) or a data packet being sent through a network circuit.


In a CBR scheme, a client must hold the required capability in order to use a resource. The capability contains a description of the rights the client holds with respect to a given resource. On the other hand, the resource contains a description of the condition under which that resource may be used.

Thus, when a client requests the use of a resource [(a) in Figure 1], the capability held by the client and the condition held by the resource are compared [(b) in Figure 1]. The resource provides the service to the client only if the capability and required condition agree [(c) in Figure 1].

3. Software usage control using CBR

3.1 System components and processing steps

When the CBR scheme described above is used for software usage control, the software is the resource in Figure 1, and the workstation attempting to use the resource is the client. The condition is described in the form of a program, called a usage control program, which specifies conditions of usage. A public-key cipher system will be applied to prevent the illicit duplication or forgery of capabilities and conditions.

Figure 2 explains how each component of software usage control operates.

The software distributor is designated by D, and an end user of the software by U. The server that performs the software usage control as the agent of D is designated by P ( In this paper it will be called "CBR proxy").

P is a system designed so that the end user cannot tamper with the contents. There are various ways to protect P. It may be installed in a secure place outside the end user's workstation and communicate with the end user's workstation using secure communication protocol. It may be implemented as a built-in unit of the end user's workstation. In the latter case, the system will contain technology like a decrypting processor [4] and tamper-responding hardware [5] so that even the owner of the machine cannot access the secret key of P.

The author is currently testing a prototype of a system in which the CBR proxy P is placed outside the user's machine.

In Figure 2, D, U, and P are assumed to safely contain the secret keys SKD, SKU, and SKP respectively.

The author uses the notation of Needham and Schroeder [6] to show encryption operations; for example,

{F0,F1,...,Fn}K

denotes the encryption of a record containing fields F0 through Fn with key K.

The system has the following steps:

Step 0: Creation of the software

Software distributor D generates software S whose usage is controlled by the CBR scheme as:
S = {condition, Sid, fh(software-body)}SKD, {software-body}KS .

Here, KS is the key for encrypting and decrypting the software body, which is the data of the Web contents, computer program, image data, and so on. SKD is D's secret key. Sid is the identifier of the software S. Condition is the usage control program of software S. The function fh() is a hash function, which is used to ensure the integrity of S.

S will be stored on a Web server and published on the network.

Step 1: Request for issue of capability

User U sends D an identifier of U in a message requesting issue of capability from D.

Step 2: Issue of capability ticket (Ct)

D creates a capability ticket Ct:
Ct = {{KS}PKP,C,U,Sid}SKD .

Here C is the capability itself, which is referenced from the usage control program. C may includes the expiration date for the capability and can contain any data described by D.

Only CBR proxy P with its secret key SKP can read KS from Ct. Anybody who holds D's public key PKD can read C, U, and Sid, but nobody except D--with its secret key SKD--can create Ct.

Step 3: Presentation of Ct

User U transmits to P a capability ticket signed by U's secret key SKU and session key K-session, which is used in the data transmission between U and P for getting service from P:
{Ct}SKU,{K-session}PKP .

K-session is encrypted by P's public key PKP.

If the communication between P and U can be assumed to be secure, such as the case when the CBR proxy P is installed inside the user's machine, U can send Ct to P in clear (without encryption), and transmission of K-session is unnecessary.

Step 4: Authentication

P calculates
{{Ct}SKU}PKU

and retrieves

Ct = {{KS}PKP,C,U,Sid}SKD

then, {C, U, Sid} is retrieved using PKD.

When P succeeds in retrieving C, U, Sid, and KS using U's public key PKU and verifies that U corresponds to PKU, Ct is verified to have been sent by the correct user U.

After the verification of the authenticity of U, KS is retrieved using P's secret key SKP. KS, C, and U are stored into the c-list (Fig. 3), which is in P's secure storage.

If P is built into U, or the communication between P and U can be assumed to be secure, the authentication process with PKU can be omitted.

Step 5: Acquisition of software

In response to a request from U, P downloads software S:
S = {condition, Sid, fh(software-body)}SKD, {software-body}KS

from the network.

Using public key PKD, the condition is retrieved and stored in the condition-list(Fig. 3), which is in P's secure storage.

Step 6: Verification of usage right

P executes the usage control program retrieved from the condition that was stored in step 5. The usage control program refers to C, which was stored in P in step 4. When the condition for providing the service is judged to be satisfied, the software body is unscrambled using SK.

Step 7: Provision of service

P encrypts the software-body using K-session, which is the session key obtained from U:
{software-body}K-session

and transmits to U.

The software-body is then decrypted using K-session at U, and the service is provided by displaying or executing the contents of the software-body.

When P is built into U, or the communication between P and U can be assumed to be secure, the process of encryption and decryption using K-session can be omitted.

3.2 Usage control program

The basic idea of attaching a usage control program to software to be distributed so as to manage the usage of the software was proposed as one of the important elements of a superdistribution scheme [1][7]. In this system, the basic mechanism to execute a similar function of the systems based on the superdistribution concept is also provided in CBR proxy P.

CBR proxy P keeps a capability list (c-list) for each user in which the capability described in step 3 is stored. CBR proxy P also holds the usage control program retrieved in step 5 from the condition attached to the software in its condition list (Fig. 3).

The usage control program that corresponds to a certain software item can only access the slot indicated by the Sid of the software item in the capability list corresponding to a user U who is currently in service. Each slot in the c-list contains Sid, C, sp, KS, and K-session. "Sp" is a scratch pad on which the corresponding usage control program can write and read any data. By writing/referring to sp, the usage control program can record the history of its usage. For example, it can count the total number of invocations of the corresponding software for a given user.

P provides a usage control program with an instruction that tells P that it is judged OK to provide the service from the software body to which the usage control program corresponds. When P receives this instruction, P decodes the software body using KS of the corresponding slot of the c-list, and the result is encoded by K-session and transmitted to user U.

In the current prototype system, P is implemented as software run on UNIX workstations. The instructions to access C, sp as described above, and the instruction to indicate start of service are implemented as functions called from a program written in C language.

4. Experimentation

Currently, we are testing an access control system using the CBR scheme in cooperation with the international joint research project for air pollution measurement using laser radar, conducted by Japan and Indonesia.

We are using the DeleGate server[8], which is one of the widely used HTTP proxy servers and which was developed in the Electrotechnical Laboratory, as the base of the CBR proxy server. The functions of the CBR proxy have been added to the DeleGate.

The laser radar observation systems are installed in Jakarta, which is also where the various types of data collected are stored, mainly on WWW servers. The computer program developed to analyze the data gathered by the laser radar systems is also stored on the same servers. This experiment involves the participation of three research institutes in Indonesia, four research institutes in Japan, and two software companies.

In this experiment, the measurement data obtained from laser radar, the software used to process that data, and the resulting processed data are used jointly by the participating institutes by means of the Internet.

While much of the final processed results from the measurement data obtained from the laser radar is used by all project participants, part of the software under development for processing the data and the measurement data experimentally processed by those programs are used exclusively by the research groups and the software companies involved in developing the programs (Fig. 4).

The CBR proxy servers implemented, based on DeleGate servers, are installed in Japan and Indonesia, and each participant can issue capability for other research participants by means of a shared capability issuing system. Capability is assigned simply by describing a character string that indicates the name of the access group.

An example of the usage control program incorporated in the software is shown in Figure 5.

Each software component (program or data) can only be referenced by users carrying the capability that describes the access group corresponding to each software component. By applying this CBR scheme, access control based on each research group's policy was achieved, as we intended.

In each user's workstation, "capability management daemons" perform the processing for transmission of capabilities without the operation of users. When users access information that requires an appropriate capability, the CBR proxy requests transmission of the capability for the capability management daemon of the user who requires the information, and the capability is automatically transmitted.

In the experiment's present phase, the CBR proxy servers are installed on LANs within the participating institutions. Transmission between the CBR proxy and the user's workstations is therefore assumed to be secure, and encryption using session-key is not carried out. Therefore, we were able to conduct this experiment using existing users' Web browsers without any modification.

5. Considerations

5.1 Security of the system

There have been a number of discussions concerning the security of the public key cipher system (i.e., the difficulty of decrypting without an appropriate key or the difficulty of deducing the secret key from its corresponding public key). However, closer examination of the security of the cipher algorithm itself is not within the scope of this paper.

In this system, each of the participants--Distributor, User, and CBR Proxy--is assumed to store the corresponding secret keys SKD, SKU, and SKP safely so that other persons cannot access them.

Since it is in the interests of the developers to keep their SKDs secret, we can expect that they will do so.

In this system, capability ticket Ct becomes effective for a user who holds the same key as the secret key of the user specified when the developer generates the capability ticket for the user. Therefore, if a user gives its secret key to another person, illegal copying of the capability can occur. It is thus advisable to make the secret key SKU the same as the secret keys for e-mail systems such as PEM [9], which are becoming common.

If the key for SKU were also used in other systems such as e-mail, a user would be less likely to give the key to another party since it would compromise the user's privacy. In reality, SKU would not be copied except between computers used by a single person. Considering these circumstances, we can assume that SKU will not be copied among unrelated persons and that the copy made between machines of a single user can be considered to be legal (i.e., there is no reason to believe that this would cause a loss of royalties for the software copyright holder).

One way to increase protection against the copying of capabilities is to include information that specifies the user's machine, such as IP addresses or serial numbers of machines imprinted in them, in the capability. The software developer can select the appropriate type of protective procedure based on software type and characteristics of the user.

To protect CBR proxy P's secret key SKP, a hardware solution such as a tamper-responding hardware [5] may be necessary, although this was not used in the prototype system.

Finally, it will be necessary to organize a system whereby a trustworthy third party generates an SKP-PKP pair and supplies a secure chip containing SKP.

5.2 Usage control of hardware resources

Usage control using the CBR scheme can also be applied to hardware resources. For example, a usage control mechanism for a router, a data server, a network circuit, etc., can be set up using the CBR scheme, in which users possessing the appropriate capability are the only ones permitted to use these hardware resources.

Figure 6 shows an example of integrated network resource management using CBR for both hardware and software usage.

The end user of the software obtains capability for software use from the software copyright holder, and uses the software.

At the same time, the hardware manager of a mirror server gives the software developer the necessary capability to upload the software to the mirror server. The condition corresponding to the capability is stored in the mirror servers. The software developer adds a condition to the usage of the software he developed himself, and adds a capability for use of the mirror server.

Therefore, software copyright holders, hardware managers, and all other network participants can coexist on the Internet and manage their assets appropriately.

6. Conclusion

The author has proposed a CBR scheme and outlined an appropriate way of managing the usage of Web pages. Using CBR software usage control, copyright holders can specify what conditions must be satisfied to permit use of the software at the point of use of the software, regardless of the routes by which the software is acquired.

In the prototype system, we succeeded in using capabilities to define user groups and to share information on a Web page only within a special group. We believe that this type of usage control will be effective for general collaboration on the Internet. It is easy to make a usage control program to record the history of the usage including the number of invocation of the software to sp and to send the history record to the software developer through the Internet periodically. This type of usage control program enables software developers to find out how much their software is being used by each end user, even in a network environment in which mirror servers are relaying the distribution of the software.

However, the user's privacy must be given careful consideration when planning such a system. This is an issue we will examine in the future.

As electronic money becomes more widely adopted, this system can be expanded to embrace a pay-per-use system, in which electronic money is automatically transmitted from the user's machine to the software copyright holder on the direction of a usage control program. In the future, we aim to create a system that uses the CBR proxy P inside a user's workstation, as well as a comprehensive software usage control system that uses both capability and electronic money.

References

  1. R. Mori and S. Tashiro, The concept of Software Service System (SSS), Trans. IEICE, Vol. J70-D, No. 1, pp.70-81, 1987.
  2. Brad Cox, Superdistribution, Addison-Wesley, 1995.
  3. Theodor H. Nelson, Xanadu: document interconnection enabling re-use with automatic author credit and royalty accounting, Information Services & Use, Vol. 14, No. 4, pp. 255-265, 1994.
  4. D. J. Albert and S. P. Morse: "Combatting software piracy by encryption and key management", IEEE Computer, Vol. 17, No. 4, pp. 68-73, 1984.
  5. David Chaum, Design Concepts for Tamper Responding Systems, Proceedings of Crypto '83, Plenum Press 1984, pp. 387-392.
  6. R. M. Needham and M. D. Schroeder, "Using Encryption for Authentication in Large Networks of Computers", CACM, Vol. 21, No. 12, pp. 993-999, 1978.
  7. S.Tashiro and R. Mori, The implementation of a small scale prototype for Software Service System (SSS), Trans. IEICE, Vol. J70-D, No. 2, pp. 335-345, 1987.
  8. Yutaka Sato, Multipurpose Protocol Mediation System: DeleGate, Bulletin of The Electrotechnical Laboratory, Vol. 59, No. 6, pp. 381-397, 1995.
  9. Stephen T. Kent, Internet Privacy Enhanced Mail, CACM, Vol. 36, No. 8, pp. 48-60, 1993.