Tamper resistant access authorising method

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

Description: The present invention relates to computer system security and, more particularly, to a tamper resistant access authorising method for controlling the access of programs, processes, or users to resources defined by a computer system. Reference should be made to Peterson and Silberschatz, "Operating System Concepts", copyright 1983 by Addison- Wesley Publishing Co., Chapter 11, relating to protection at pp. 387-419; and Dorothy Denning, "Cryptography and Data Security", 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 favour 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 <user(i), object(j), rights set(k)>, then whenever an operation M was executed on an object O(j) by user U(i), a search would be made for the triple <U(i) ,O(j) ,R(k)> 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 list is ticket oriented, and a lock and key mechanism combines features of both. An access list is no more than a set of ordered pairs <U(i), R(k)> sorted on each object O(j). A capability list is a transferrable set of ordered pairs <O(j), R(k)>. The capability is a ticket authorising any bearer (user in possession) R access rights to object O. Simple possession means that access is allowed. With a lock and key mechanism, each object O(j) includes a unique bit pattern denominated a "lock", while only designated ones of the users are in possession of a unique bit pattern denominated a "key". Thus, a U(i) can obtain a key to O(j) only if he has access rights R(k) of a predetermined type. Dunham et al., U.S. Patent 4,791,565, "Apparatus for Controlling the Use of Computer Software", issued December 13, 1988, illustrates the "access control list" construct. In this case, the "access rights" 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. Patent 4,652,990, "Protected Software Access Control Apparatus and Method", issued March 24, 1987, illustrates a "lock and key" approach to 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 check that user, object, and rights match prior to granting access. Wolfe, U.S. Patent 4,796,220, "Method of Controlling the Copying of Software", issued January 3, 1989, discloses another lock and key approach in which configuration information of authorised 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. The IEEE paper by S. Vinter entitled "Extended Discretionary Access Controls" (pages 39-49 of Proceedings of the 1988 IEEE Symposium on Security and Privacy, Oakland, California, April 18-21, 1988, IEEE, New york, USA) discloses resource access authorisation control using access control lists. A client may access an object if its identity appears in an access control list entry that is associated with a privilege for the type of access requested. From one aspect, the present invention provides a method of controlling access to computer resources resident in a host computer of a computer system comprising the host and a plurality M of workstations connected for communication with the host, the method comprising the steps of: (a) responsive to a resource access request from a workstation or user, invoking a precomputed list, the list including M workstation or user identities and an encrypted representation of the number N of workstations or users authorised for resource access, N being a number less than M, the encrypted representation of N being formed using an encryption key as a function of the host identity and an offset; (b) ascertaining the depth N to which the list may be searched by decrypting the encrypted representation of parameter N using the encryption key; and (c) comparing the identity of the workstation or user originating the service request with the identities of the M workstations or users on the list but only to a depth N, and authorising the access if an identity match is found but otherwise refusing the access request. Such a method is considered tamper resistant. In a preferred embodiment, the present invention provides a tamper-resistant method for authorising access to data or application software between a host and a predetermined number N of M attached workstations or users, N being less than M, the host including a communications server for managing physical data transmission between the host and M workstations or users; and means for storing access control software and related information; comprising the steps at the host of: (a) responsive to a service request from a workstation or user, invoking access control software from the storage means and a precomputed list, the list including M station or user identities and an encrypted representation of N indicative of the number of workstations or users authorised access or attachment to the host, the encrypted representation N being formed using an encryption key as a function of the host identity and an offset; (b) ascertaining the depth N to which the list may be searched by decrypting the representation using the key; and (c) comparing the identity of the workstation or user originating the service request with the identities of the M stations or users on the list but only to a depth N, and returning an authorisation only upon a match condition. Such an arrangement is thought to be a tamper-resistant method for controlling the number of users given authorised access to licensed software in a host-based, multiple terminal system. The software expression of such can be embedded among the modules forming a licensed software product. The above method is based on the unexpected use of an encrypted form of an authorisation list depth parameter. As disclosed hereinafter, access to data is authorised between a host and a predetermined number N < 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 operation takes place at the host and 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 authorised access or attachment to the host. The encryption key is a function of the host identity and an offset. In this regard, an "offset" 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 operation 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 operation requires that the service requester identity be compared with the items of the list to that depth N and an authorisation is returned only if a match condition is found within that depth. Significantly, any change in the search-depth N requires re-encryption 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 authorised users. It even permits dynamic authorisation 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. The present invention will be described further by way of example with reference to an embodiment thereof as illustrated in the accompanying drawings, in which:- Fig. 1 depicts a host CPU-to-workstation download system; and Figs. 2-5 set out access control list examples 1-4. 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 "VM/System Product Programmer's Guide to the Server-Requester Programming Interface for VM/System Product" (pp. 6-7), IBM publication SC24-5291-1, December 1986; or "TSO Extensions Programmer's Guide to the Server-Requester Programming Interface for MVS/XA" (pp. 1-3), IBM publication SC28-1309-1, September 1987. Other computing facility resources are governed by the IBM/370 Principles of Operation as described in Amdahl et al., U.S. Patent 3,400,371, "Data Processing System", issued September 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, "The Structure and Design of Programming Languages", 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 authorised user. The header record will characterise the number of authorised 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 authorised to invoke the download transfer operation. To authorise 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 authorised 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's Resource Control Facility (RACF) set forth in "OS/VS2 MVS RACF Command Language Reference", 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 authorised, 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 attached to terminals, authorisation 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) Herein, there is shown one exemplary pseudocode sequence with strong PASCAL overtones, the execution of which embodies the method of the invention. Significantly, the ACP may be called by ACP(userid: char, encrypt: bool) boolean the declaration of the ACP program, either once per logged-on session or more than once (e.g., every time a data transfer is intended to be performed), the inputs being defined as userid - a string of characters defining which userid is to be scanned in the Access Control List (ACL) encrypt - Boolean variable (TRUE if the ACL header is encrypted, FALSE if the ACL header is decrypted) ACL - Access Control List The sequence 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. Patent 4,227,253, "Cryptographic Communication Security for Multiple Domain Networks", issued October 7, 1980; Matyas et al., U.S. Patent 4,218,738, "Method for Authenticating the Identity of a User of an Information System", issued August 19, 1980; and Meyer and Matyas, "Cryptography - New Dimension in Computer Data Security", copyright 1982 by John Wiley & Sons. The depth number is clear in the header. (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 - the returned (not_found) = FALSE -, invoke the authorised application on the host. Otherwise - the returned (not_found) = TRUE -, return a message to the requesting workstation indicating UN-AUTHORISED. It should be noted from the sequence recited, 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.

Claims: A method of controlling access to computer resources resident in a host computer of a computer system comprising the host and a plurality M of workstations connected for communication with the host, the method comprising the steps of: (a) responsive to a resource access request from a workstation or user, invoking a precomputed list, the list including M workstation or user identities and an encrypted representation of the number N of workstations or users authorised for resource access, N being a number less than M, the encrypted representation of N being formed using an encryption key as a function of the host identity and an offset; (b) ascertaining the depth N to which the list may be searched by decrypting the encrypted representation of parameter N using the encryption key; and (c) comparing the identity of the workstation or user originating the service request with the identities of the M workstations or users on the list but only to a depth N, and authorising the access if an identity match is found but otherwise refusing the access request. A method according to claim 1, for controlling access authorisation for application programs, wherein access to an application program comprises invocation of the application program, and wherein the refusal of an access request involves a refusal message being sent to the requesting workstation or user. A method according to claim 2, wherein the step of invoking the list includes invoking access control software, the list and the access control software being embedded within the application program. A method according to any preceding claim, wherein the arrangement of the host communicatively attaching the workstations or users is selected from a set consisting of a local area network and a multiprogramming, multiprocessing system exemplified by VM. A method as claimed in any preceding claim, wherein the method steps further include modifying the search depth N only by re-encrypting same.

Inventors: ENESCU MICHAEL ALEXANDER, LUM JAMES, ENESCU, MICHAEL ALEXANDER, LUM, JAMES
Applicants: IBM, INTERNATIONAL BUSINESS MACHINES CORPORATION
Application year: 1990
Main classification: G06F1
IPC codes: G06F12, G06F21, G06F1