Abstract:
A tamper-resistant method is disclosed for controlling the number of users given authorized access to licensed software in a host-based, multiple terminal system by use of an encrypted authorization list depth parameter. The method embedded in the host-licensed software can decrypt the depth parameter only using a key derived from its own CPU ID and an offset.

Description:
FIELD OF THE INVENTION 
     This invention relates to computer system security and, more particularly, to a method for controlling the access of programs, processes, or users to resources defined by a computer system. 
     DESCRIPTION OF RELATED ART 
     Access Matrix View of Computer Resource Protection 
     Reference should be made to Peterson and Silberschatz, &#34;Operating System Concepts&#34;, copyright 1983 by Addison-Wesley Publishing Co., Chapter 11, relating to protection at pp. 387-419; and Dorothy Denning, &#34;Cryptography and Data Security&#34;, copyright 1982 by Addison-Wesley Publishing Co., Chapter 4, relating to access controls at pp. 209-230. 
     These references describe mechanisms for controlling the access of programs, processes, or users to resources defined by a computer system. Both Peterson and Denning apparently favor an access matrix, either statically or dynamically implemented, to be the protection construct of choice in such systems. 
     The matrix construct uses rows to represent domains and columns to represent objects. Each entry in the matrix consists of a set of access rights. If a computer held a global table consisting of a set of ordered triples &lt;user(i), object(j), rights set(k)&gt;, then whenever an operation M was executed on an object 0(j) by user U(i), a search would be made for the triple &lt;U(i),O(j),R(k)&gt;and the operation would be allowed to continue only upon a comparison match. 
     Both references further describe several constructs derived from an access matrix. These include access lists, capability lists, and lock and key mechanisms. It should be appreciated that an access list is list oriented, a capability is ticket oriented, and a lock and key combine features of both. 
     An access list is no more than a set of ordered pairs &lt;U(i), R(k)&gt; sorted on each object O(j). A capability list is a set of ordered pairs &lt;O(j), R(k)&gt;. The capability is a ticket authorizing any bearer (user in possession) R access rights to object O. Simple possession means that access is allowed. 
     In the lock and key modality, each object O(j) includes a unique bit pattern denominated a &#34;lock&#34;, while only designated ones of the users are in possession of a unique bit pattern denominated a &#34;key&#34;. Thus, a U(i) can obtain a key to O(j) only if he has access rights R(k) of a predetermined type. 
     SOME PATENTED IMPLEMENTATIONS 
     Dunham et al., U.S. Pat. No. 4,791,565, &#34;Apparatus for Controlling the Use of Computer Software&#34;, issued Dec. 13, 1988, illustrates the &#34;access control list&#34; construct. In this case, the &#34;access rights&#34; are used to police license restrictions. Dunham uses an EPROM-based microprocessor as a dedicated server. In this arrangement, software usage requests, emanating from terminals and destined for a host computer, are mediated before transmission. Each request is either passed on with or without comment, or rejected, all according to criteria recited in the user software license. 
     Pailen et al., U.S. Pat. No. 4,652,990, &#34;Protected Software Access Control Apparatus and Method&#34;, issued March 24, 1987, illustrates a &#34;lock and key&#34; approach toward limiting unpermitted copying. In Pailen, an interactive encrypted message generation process among a requesting remote terminal and a pair of mediating processors is used to comparison match user, object, and rights identity prior to granting access. 
     Wolfe, U.S. Pat. No. 4,796,220, &#34;Method of Controlling the Copying of Software&#34;, issued Jan. 3, 1989, discloses another lock and key approach in which configuration information of authorized terminals is used as part of a permission code computation sent by a host to the requesting terminal. The computation is appended to each request and operates together with the configuration data as a key for recomputation of the code on subsequent access requests made by the terminal to the host. 
     SUMMARY OF THE INVENTION 
     It is accordingly an object of this invention to devise a tamper-resistant method for controlling the number of users given authorized access to licensed software in a host-based, multiple terminal system. It is a related object that the software expression of such method be embedded among the modules forming the licensed software product. 
     The foregoing object is satisfied by a method based on the unexpected use of an encrypted form of an authorization list depth parameter. More particularly, the object is satisfied by a method for authorizing access to data between a host and a predetermined number N&lt;M attached workstations or users. The host includes a communications server for managing physical data transmission between the host and the M workstations or users, and means for storing access control software and related information. 
     The first method step at the host includes invoking access control software from the storage means and invoking a precomputed list. These invocations are both in response to a service request from a workstation or user. The list includes M station or user identities and an encrypted representation of the parameter N. N≦M represents the number of workstations or users authorized access or attachment to said host. 
     Relatedly, the encryption key is a function of the host identity and an offset. In this regard, an &#34;offset&#34; is a constant that is arithmetically combined with the host identity to obscure the key. For instance, the host identity could be the host serial number hard coded in host memory, or it could be an integer value additively combined thereto. 
     The second method step involves ascertaining the value of depth parameter N by decrypting the representation using the key. The value N defines the depth to which the list is permitted to be searched. 
     The third and last step requires comparing the service requester identity to a depth N on the list and returning an authorization only upon a match condition. Significantly, any change in the search-depth N requires reencryption thereof. 
     Advantageously, any host-resident licensed software product, a portion of which being downloadable to accessing terminals, embodying the method of this invention requires only a single installation step, in addition to regulating the number of authorized users. It even permits dynamic authorization of users to a single machine since the encryption key is a function of the host identity. Note that the use of the host identity limits the use of the code to a predetermined system. 
    
    
     BRIEF DESCRIPTION OF THE DRAWING 
     FIG. 1 depicts a host CPU-to-workstation download system. 
     FIGS. 2-5 set out access control list examples 1-4 according to the invention. 
     FIG. 6 shows a pseudocode flow of control of the method of the invention. 
    
    
     DESCRIPTION OF THE PREFERRED EMBODIMENT 
     Referring now to FIG. 1, there is shown a CPU 1 and a plurality of terminals 17, 19, 21, 23 coupled thereto over paths 9, 11, 13, 15. In the subsequent description, it shall be assumed that the CPU node runs under an operating system that uses a communications server similar to the system described in either &#34;VM/System Product Programmer&#39;s Guide to the Server-Requester Programming Interface for VM/System Product&#34; (pp. 6-7), IBM publication SC24-5291-1, Dec. 1986; or &#34;TSO Extensions Programmer&#39;s Guide to the Server-Requester Programming Interface for MVS/XA&#34; (pp. 1-3), IBM publication SC28-1309-1, Sept. 1987. 
     Other computing facility resources are governed by the IBM/370 Principles of Operation as described in Amdahl et al., U.S. Pat. No. 3,400,371, &#34;Data Processing System&#34;, issued Sept. 3, 1968. 
     Referring again to FIG. 1, in addition to a usual complement of operating system services, CPU 1 preferably includes at least one application executable in a communicating relation with at least one terminal over a download interface to an accessing workstation over a designated path. It should be appreciated that licensed software products are expressed in object code only (OCO) form. They are packaged according to a structured program syntax frequently including a plurality of single entrance/single exit modules (see J. E. Nicholls, &#34;The Structure and Design of Programming Languages&#34;, The Systems Programming Series, copyright 1975 by Addison-Wesley Publishing Co., Chapter 12, relating to modular programming, especially at page 486). Accordingly, in the preferred embodiment, an access control program (ACP) and an access control list (ACL) are embedded among the product modules. Both the OCO product form and dispersal of the ACP and ACL among several modules should render them relatively immune from isolation and casual inspection. 
     ACCESS CONTROL LIST 
     The ACL preferably comprises a file containing a header record followed by one record per authorized user. The header record will characterize the number of authorized users in the list. For instance, if the header records include an encrypted integer value of three, then only the first three users in the ACL will be authorized to invoke the download transfer operation. 
     To authorize a user, access must be made to the data set (module) containing the ACL residing in the host CPU 1. At this point, a new authorized ID may be entered consonant with the depth prescribed by the header record. Note that the data set may be protected additionally as described in IBM&#39;s Resource Control Facility (RACF) set forth in &#34;OS/VS2 MVS RACF Command Language Reference&#34;, IBM publication SC28-0733. 
     Referring now to FIGS. 2-5, there are shown access control list examples 1-4 according to the invention. FIG. 2 lists four names with a parameter depth of N=3. Thus, only the terminal or user identities GEORGE, JOHN, and MARY are authorized, while ROSEALI is not. In FIG. 3, the permitted depth exceeds the length of the list so that another identity could be added. FIG. 4 shows a depth of 1, while FIG. 5 shows a list with a different CPUID. In the latter regard, the depth parameter would not be decrypted since the key is a function of a predetermined CPUID + offset. 
     As a practical matter, whether the host CPU is local area network or VM attached to terminals, authorization and access mechanisms rely principally upon a password match. In the event of mismatch or a repeated pattern of mismatch, entry is merely denied. In other systems, such as the previously mentioned RACF, other criteria such as location or a value of a system clock may be used to control access. 
     ACCESS CONTROL PROGRAM (ACP) 
     Referring now to FIG. 6, there is shown a pseudocode sequence whose execution embodies the method of the invention. The sequence is illustratively expressed in a PASCAL strongly-typed source language. Significantly, the ACP may be called either once per logged-on session or more than once (e.g., every time a data transfer is intended to be performed). 
     The code specifies the following functions including: 
     (a) Opening the file containing the ACL. 
     (b) Reading the header record and decoding the depth level N. This is implemented by decrypting the header with a key formed from the CPUID + offset according to any well-known encryption/decryption algorithm. Such algorithms are to be found in Ehrsam et al., U.S. Pat. No. 4,227,253, &#34;Cryptographic Communication Security for Multiple Domain Networks&#34;, issued Oct. 7, 1980; Matyas et al., U.S. Pat. No. 4,218,738, &#34;Method for Authenticating the Identity of a User of an Information System&#34;, issued Aug. 19, 1980; and Meyer and Matyas, &#34;Cryptography -- New Dimension in Computer Data Security&#34;, copyright 1982 by John Wiley &amp; Sons. 
     (c) Scanning the ACL to find a match between the requester ID and the list within the decrypted depth range N. 
     (d) If the match is successful, then invoke the authorized application on the host. Otherwise, return a message to the requesting workstation indicating UNAUTHORIZED. 
     It should be noted from the code recited in FIG. 6 that the two critical structures are the IF..THEN..ELSE conditional statement for ascertaining the depth parameter, followed by the WHILE..DO loop for scanning the ACL for a match condition. 
     In considering this invention, it should be remembered that the present disclosure is illustrative only and the scope of the invention should be determined by the appended