Modular software security - Patent Review 4888798

What is claimed is:

1. A protection method for restricting access by a user to authorized ones of a plurality of software elements in a computer system where the computer system permanently stores an identity key, I.sub.k distinguishing the computer system from other computer systems having the same software elements, comprising,

inputting a capability key, C.sub.k, into the computer system for unlocking a selecting one of said plurality of software elements, said capability key specifying authorization being possessed by the user with respect to said selected software element in said system,

accessing an identity key, I.sub.k, stored in the computer system for identifying the computer system,

transforming the capability key with the identity key to form a transformed key, T.sub.k, including,

transforming the identity key, I.sub.k, by at least one operation to form more than one control number, B.sub.i,

successively transforming the capability key, C.sub.k, using said control numbers, B.sub.i, and a set of reversible transformation functions F.sub.i to form the transformed capability key, T.sub.k, as follows,

B.sub.i F.sub.i X.sub.i-1 =X.sub.i, i=1,2 . . . N

wherein

X.sub.0 =C.sub.k

X.sub.N =T.sub.k,

accessing a stored key S.sub.k, for said selected software element, said stored key defining authorization being expected for unlocking said selected software element,

compairing said transformed key, T.sub.k, and said stored key S.sub.k,

allowing access to said selected software element if the stored key corresponding to said selected software element matches said transformed key.

2. The method of claim 1 wherein the step of transforming the identity key, I.sub.k, by at least one operation consists of multiplying I.sub.k by a constant, J.sub.i, as follows,

(I.sub.k)(J.sub.i)=B.sub.i, i=1,2 . . . N.

3. The method of claim 1 wherein said set of transformation functions includes a bit-by-bit EXCLUSIVE-OR operation.

4. The method of claim 1 wherein said set of transformation functions includes a bisecting permutation indicated by the symbol ##EQU4## as follows, ##EQU5##

5. The method of claim 4 wherein X.sub.i is a 32-bit number and wherein the bisecting permutation is performed in a numbers of steps, where the control number B.sub.i+1 is organized from a high-order bit to lower-order bits, as follows,

if the high-order bit of the control number, B.sub.i+1 is "1", swap the left and right 16-bit groups of X.sub.i transform to form the first permuted value, X.sub.i1,

if the next lower-order bit in B.sub.i+1 is "1", swap the leftmost two 8-bit groups of X.sub.il to form the left half of the next permuted value, X.sub.i2, if the next lower-order bit in B.sub.i+1 is "1", swap the rightmost two 8-bit groups of the X.sub.il value to form the right half X.sub.i2,

if taken one at a time any of the next lower-order four bits of B.sub.i+1 are a "1" swap the left and right 4-bit halves of each of the corresponding next four 8-bit groups of X.sub.i2 to form the next permutted value, X.sub.i3, consisting of eight 4-bit groups, each 4-bit group having 2-bit left and right halves,

if taken one at a time any of the next eight lower-order bits of B.sub.i+1 are "1" swap the corresponding left and right 2-bit halves of the eight 4-bit groups X.sub.i3 to form the next permutted value X.sub.i4 consisting of sixteen 2-bit groups, each group having a 1-bit left and 1-bit right half,

if any one of the next sixteen lower-order bits of B.sub.i+1 is a "1" swap of the corresponding left and right 1-bit halves of the respective sixteen groups of X.sub.i4 to form the next permutted value, X.sub.i5.

6. A protection apparatus for restricting access by a user to authorized ones of a plurality of software elements in a computer system where the computer system permanently stores and identity key, I.sub.k distinguishing the computer system from other computer systems having the same software elements, comprising,

means for inputting a capability key, C.sub.k, into the computer system for unlocking a selected one of said plurality of software elements said capability key specifying authorization being possessed by the user with respect to said selected software element in said system,

means for accessing an identity key, I.sub.k, stored in the computer system for identifying the computer system,

means for transforming the capability key with the identity key to form a transformed key, T.sub.k, including,

means for transforming the identity key, I.sub.k, by at least one operation to form more than one control number, B.sub.i,

means for successively transforming the capability key, C.sub.k,

using said control numbers, B.sub.i, and a set of reversible transformation functions F.sub.i to form the transformed capability key, T.sub.k, as follows,

B.sub.i F.sub.i C.sub.i-1 =X.sub.i, i=1,2 . . . N

where

X.sub.o =C.sub.k

X.sub.n =T.sub.k.

7. The apparatus of claim 6 wherein means for transforming the identity key, I.sub.k, by at least one operation includes means for multiplying I.sub.k by a constant, J.sub.i, as follows,

(I.sub.k) (J.sub.k)=B.sub.i, i=1,2 . . . N.

8. The apparatus of claim 6 wherein the first control number, B.sub.1, with the capability key C.sub.k, includes means for performing said set of transformation functions include a bit-by-bit EXCLUSIVE-OR operation [as follows:

B.sub.1 .sym.C.sub.k =Y.sub.k

wherein the operation symbol ".sym." indicates an EXCLUSIVE-OR is bit-by-bit between each pair of correspondings bits of B.sub.1 and C.sub.k and yields for corresponding bits of X.sub.k a "1" if the corresponding bits of B.sub.1 and C.sub.k are different and "0" if the corresponding bits of B.sub.1 and C.sub.k are the same.

9. The apparatus of claim 6 wherein the means for transforming the intermediate transform, X.sub.k, using the second control number, B.sub.2, includes means for performing a bisecting permutation indicated by the symbol ##EQU6## as follows, ##EQU7##

10. A protection method for restricting access by a user to authorized ones of a plurality of software elements in a computer system where the computer system permanently stores an identity key, I.sub.k distinguishing the computer system from other computer system having the same software elements, comprising,

inputting a capability key, C.sub.k, into the computer system for unlocking a selected one of said plurality of software elements,

accessing an identity key, I.sub.k, stored in the computer system for identifying the computer system,

transforming the capability key with the identity key to form a transformed key, T.sub.k, including,

transforming the identity key, I.sub.k, by at least one operation to form two numbers, B.sub.1 and B.sub.2, wherein the step of transforming the identity key, I.sub.k, by one or more operation includes multiplying I.sub.k by constants, to form B.sub.1 and B.sub.2 as follows:

(I.sub.k)(J.sub.1)=B.sub.1

(I.sub.k)(J.sub.2)=B.sub.2

transforming the first control number, B.sub.1, with the capability key, C.sub.k, to yield an intermediate transform, X.sub.k, as follows:

B.sub.1 .sym.C.sub.k =X.sub.k

transforming the intermediate transform, X.sub.k, using the second control number, B.sub.2, to form the transformed capability key, T.sub.k, as follows:

B.sub.2 .sym.X.sub.k =T.sub.k

accessing a stored key, S.sub.k, for said selected software element,

compairing said transformed key T.sub.k and said stored key, S.sub.k,

unlocking said selected software element if the transformed key corresponding to said selected software element matches said stored key.

11. A protection method for restricting access by a user to authorized ones of a plurality of software elements in a computer system where said computer system includes storage for storing said software elements and for storing an element directory, said element directory having for each software element a name field for identifying the software element, having a location field for identifying the location in storage of the software element having the corresponding name in the element directory, and having a capability key field for storing a capability key and where the computer system permanently stores an identity key, I.sub.k, distinguishing the computer system from other computer systems having the same software elements, comprising,

inputting a capability key, C.sub.k, into the computer system for unlocking a selected software element where said selected software element is one said plurability of software elements, said capability key specifying authorization being possessed by the user with respect to said selected software element in said system,

accessing the identity key, I.sub.k, stored in the computer system for identifying the computer system,

transforming the capability key, C.sub.k, with the identity key, I.sub.k, to form a transformed key, T.sub.k,

accessing a stored key, S.sub.k, for said selected software element, said stored key defining authorization for unlocking said selected software element,

compairing said transformed key, T.sub.k, and said stored key, S.sub.k,

allowing access to said selected software element if the stored key corresponding to said selected element matches said transformed key, storing said capability key in the corresponding capability key field of the element directory if said transformed key matches said stored key corresponding to said selected one element.

12. The method of claim 11 further comprising, in response to a request by the computer system to access said selected software element, the steps of,

accessing any capability key stored in the capability key field of the element directory of said selected software element,

reaccessing the identity key,

transforming the capability key accessed from the element directory with the identity key to reform a new transformed key,

reaccessing the stored key for said selected software element,

compairing said new transformed key and said stored key to determine if the transformed key and the stored key match,

granting access to said selected software element if the transformed key and said stored key match.

13. The method of claim 12 further comprising the step of counting the number of unsuccessful attempts to access said selected software element,

inhibiting further attempts to access said selected software element after the number of unsuccessful attempts reaches a predetermined number.

Description Submit all comments and votes

The present invention relates to computers and cryptosystems for use with computer software to prevent unauthorized use of the software on computers.

Frequently, a computer system is capable of receiving software which includes a number of different elements (sometimes called files, functions, modules, capabilities or options). Each element (file) may be segregated from the other elements so that the elements may be priced separately or otherwise separately controlled. The software distributor needs to deliver to each computer user those elements for which the computer user pays or is otherwise authorized. The software distributor wishes to prevent unauthorized users from having access to the elements for which the users have not paid or are otherwise unauthorized. Also, the distributor does not wish the user to be able to copy or otherwise share the software with other unauthorized users.

The ease with which computer software can be copied is both a great operational convenience and a great commercial weakness. Once a copy of software for standard computers has been delivered to a user in some form, it is usually a simple matter for the user to replicate and redistribute the software to other users whether or not the other users are authorized. Legal barriers, such as software licensing agreements and copyrights, offer some protection against unauthorized use, particularly for expensive software that has a limited number of users. Legal barriers offer less practical protection for low-priced software that runs on many machines such as personal computers.

In the environment where the software distributor also controls the design of the computer hardware on which the software will run, it is possible to erect barriers to unauthorized use by using encrypted software. For example, each computer may have an assigned identity key (typically, a unique serial number) that is accessible to the computer program and may have a built-in decryption mechanism which utilizes the identity key as a decryption key. When encrypted software is loaded into the computer, the software is automatically decrypted using the assigned computer identity key as the decryption key. In such a cryptosystem, any attempt to load encrypted software created for a different computer will fail because of the inability to decrypt the software. Key stream crypting in a cryptosystem is executed typically as follows.

Key-stream encryption uses the same process to either encrypt an unencrypted software element (file) or to decrypt an encrypted software element (file) to restore the encrypted element (file) to its original unencrypted form. The source data from the unencrypted software element (file) is treated as a data stream (that is, as a string of bits). Typically, the encryption process performs an "exclusive-or" operation between each bit of the source data stream and a corresponding bit from a key data stream. The key data stream is typically a random or pseudo-random sequence of bits. The result of this encryption operation is an encrypted data stream in which 0's and 1's occur with approximately equal probability.

Decryption of the encrypted data stream is accomplished by performing exactly the same "exclusive-or" operation on the encrypted data stream, using the same key data stream as was used during encryption. The second "exclusive-or" operation utilizing the same key data stream restores the encrypted data stream to its original unencrypted source data stream form. In other words, the "exclusive or" operation is its own inverse. In order for this key-stream cryptosystem to work, it is necessary to use identical key data streams in both the encryption and decryption processes.

By using key-stream crypting on software elements (files) stored on floppy disk or other media, the contents of those elements (files) are rendered unintelligible in the sense that a static analysis yields no information since the stored data looks like random bit patterns.

Pseudo-random number generators can be made to synthesize suitable key data streams. They have the nice property that they can generate a wide variety of such key streams under parametric control. In one system, for example, a simple additive process is used to generate the key-stream. Beginning with a "seed key" (a starting value for the "old key"), a "new key" is generated using 32-bit words by the following calculation of Eq.(1).

"new key"=("seed key"+"code")modulo 32 Eq.(1)

In Eq.(1), the "code" is a constant in any given software version. By choosing different values of the "seed key" and "code" for different software versions, Eq.(1) generates a series of quite different "new keys".

Many other simple or elaborate key-stream generators are possible and have been described in well-known literature under the category "pseudo-random number generators."

While the above key-stream cryptosystem makes unauthorized use of software difficult, the cryptosystem creates a serious problem for the software distributor since the cryptosystem requires that the software be specifically encrypted for each machine on which it is to be run based on the identity key of that machine. Therefore, the software to be distributed is different for each computer so that the distributor must treat every user's computer differently and such treatment is obviously inefficient and expensive.

In view of the above limitations, there is a need for improved software cryptosystems which do not require a different encrypting of the software for each computer authorized to use the software.

SUMMARY OF THE INVENTION

The present invention is a computer method and apparatus that permits identical copies of encrypted computer software (including a number of software elements) to be distributed to many users while retaining central control over which elements are "unlocked", that is, are authorized for use by each user.

The computer software after distribution to a user is stored within the user's computer and may include both authorized and unauthorized elements. The user may "unlock" any one or more of the authorized elements by entering corresponding encrypted capability keys, usually one key for each authorized element. Each of the capability keys typically is a short string of alphanumeric characters entered through a keyboard or equivalent input device. While the capability keys may be different for each computer, the computer software including the encrypted elements are the same for all computers so that the software can be copied and disseminated by a distributor without concern about whether or not use of any particular element is authorized.

The user's computer system has interlocks that permit only those elements that have been "unlocked" by entry of a capability key to function in the computer. At the time of the initial delivery of the software, the user is given capability keys for only those elements that the user has purchased or for which the user is otherwise authorized. If the user later obtains additional capability keys corresponding to newly authorized elements, the user is then able to access the corresponding newly authorized elements. Typically, the newly authorized elements are already stored in the user's computer so that there is no need for the user to again receive the newly authorized software elements. The user need only receive the capability keys for those elements.

The computer software is typically distributed in different versions where each version has a different key-stream generator and encrypts software elements differently.

The present invention offers a substantial barrier to casual software piracy while facilitating software updates. Key-stream crypting (encryption and decryption) is used in the security system as a "first line of defense" together with capability keys which provide modular control of access to software elements.

In one embodiment, the number of uses of a software element authorized by a capability key is limited. When the limit for one capability key is reached, a user is required to enter another capability key to obtain authorization for additional uses of the same software element.

In a specific embodiment, the modular software security system permits modular control of access to software elements using specific "keys", including a "capability" key, an "identity" key, and a "stored" key.

The stored key is a key which is identical to the transformed key resulting from the transform of the capability key and the identity key. In one typical system, the stored key has two components, namely, an "authentication" key and an "access" key.

When the user is authorized to use a particular software element, as evidenced by the user having the corresponding capability key, the user enters the capability key into the user's computer system. The user's computer system transforms the capability key using the identity key to form a transformed key. The transformed key is then compared with the stored key and if a match occurs, that match indicates that access to the protected software element is authorized. Each "capability" key is provided to the user by the software distributor and controls access to a particular software element.

The "identity" key is a number for identifying a particular computer, user or other thing. When used to identify a computer, the identity key is permanently stored in the user's computer and is unique to the user's computer and therefore can function to assure that the authorized software element is authorized only for the computer having the proper identity key. The identity key transforms the capability key.

The "authentication" key is an arbitrary number that is compiled into the firmware of the computer system. The authentication key is used to check the validity of capability keys that are entered. All systems that use a given firmware version typically have the same authentication key, but the authentication key may be changed between versions.

Each software element in the system has an associated "access" key which must be matched with a portion of the transformed capability key to obtain permission to access the file. Typically, the access key is interleaved with the file data stored in the software element in a way that depends on the firmware version.

At the time of delivery of the computer system, the system has a stored key including an authentication key (software version dependent) an access key (one for each element), and a machine identity key (different for each computer). When the computer system is started, the system decrypts and downloads the computer software including certain main operating programs from the floppy disk or other program source using the same key-stream decryption process for all software. The computer software on the disk has a directory element that associates software element names with disk addresses and capability keys. Generally, there is one capability key per software element. Each software element stores an access key, generally in a number of distributed locations that are software version-dependent. Any elements with access keys of "0" are considered to be "unprotected" and no capability key is needed to access them.

In its initial configuration (before entry of any capability keys), the capability keys of all elements are set to a pre-establish value, for example, "0". No element with a capability key "0" can be accessed until a non-zero capability key has been computed and stored in the corresponding capability key field of the element directory except for unprotected elements which, as indicated by a "0" access key, require no capability key. Initially, therefore, before entry of any capability key, only the unprotected elements are accessible. Additional software elements having non-zero access keys can be "unlocked" by a capability key unlocking process.

In order to initialize the system and to unlock a protected element using the unlocking process, a capability key for the protected element is entered into the system. The entered capability key is transformed with the system identity key to form a transformed key. The transformed key is compared with the stored key. Typically, a portion of the transformed key is compared with the authentication key stored in firmware to verify the entered capability key's authenticity. If an authentication match occurs, the match resulting from entry of the correct capability key is used to "unlock" protected elements provided also that access is authorized. If an authentication key match does not occur, a special "cracker countermeasure" procedure can be performed.

If the authentication key is matched correctly, each element that has a "0" in its capability key field in the element directory is examined to determine which elements also have an access key matching another portion of the transformed capability key. Wherever an access key match is found, the capability key (not the transformed capability key) is stored into the capability key field of that element in the element directory. When the capability key is thus stored in the directory, the protected element has been unlocked and is available for use. In order to access the protected element, however, the capability key must be entered before each access.

Thereafter, whenever access to a software element is requested, the capability key stored (if any) in the element directory for that element is transformed in the same way as when the capability key was entered into the system. Portions of the transformed key derived from the stored capability key are compared with the stored authentication key and the stored access key.

If either the stored authentication key or the stored access key does not match the corresponding portion of the transformed key, the failure to match indicates that access to the element is unauthorized. Access is unauthorized, for example, if the element has been reproduced from a system with a different version of the firmware or if a floppy disk storing the element has been moved from another system to the present system. In either case, the system typically resets all capability key fields in the element directory to "0". The user must then reenter non-zero capability keys into the system in order to gain access to any protected element.

The transformation of the capability key can be done in many different ways. The important criterion is that the capability key transformation be reversible so that, given a stored key (typically including an authentication key and an access key) and a system identity key, a capability key can be computed having the property that, when transformed, it will match these keys.

Additional objects and features of the invention will appear from the following description in which the preferred embodiments of the invention have been set forth in detail in conjunction with the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts a cryptosystem for use in connection with or a computer.

FIG. 2 depicts a flow chart which represents the operation of the FIG. 1 cryptosystem in order to enter a capability key.

DETAILED DESCRIPTION

Encrypted Capability Keys

A practical realization of the modular capability-key cryptosystem embodied in a printing system is shown in FIG. 1. The printing system employs a general purpose processor and a number of different computer software elements which represent different capabilities of the system. Typical hardware elements used in the printing system are as follows.

A general purpose computer 10 with integral random-access memory (RAM) 11 to store computer software (including a number of protected and/or unprotected software elements) and to store data is employed. A Motorola MC68000 microcomputer with 256k bytes of MOS RAM memory is suitable for computer 10.

An input device 12 for entering an alphanumeric string representing the capability key is employed. A display terminal 12-2 and keyboard 12-1 connected to standard RS232C port 13 of computer 10 is suitable for input device 10.

A permanent, machine-readable memory device 14 is employed to store the serial number identity key and other firmware. A PROM (programmable read-only memory) physically and electronically attached to a backplane 15 of the computer 10 is suitable for permanent memory device 14.

A small amount of permanent, alterable memory 16 is employed to keep track of the "cracker count" which is the total number of erroneous capability keys that have been entered. NOVRAM (non-volitile RAM) storage associated with the computer is suitable for memory 16.

Software file storage 17 is employed for storing software elements in encrypted form. Storage 17 typically includes a floppy disk which stores programs (including a number of protected software elements such as font files), other data, and an element directory in encrypted form.

Key-stream crypting is used to render all software elements stored in storage 17 unintelligible until key-stream decrypting is performed. The key-stream crypting is the same for all software elements of a particular version of the software and is the same for all computers (printers) of a particular release; but the crypting may be different for other versions of the software and other releases of the computer. The function of the key-stream cryptosystem is to make static analysis of software elements difficult, but such a key-stream cryptosystem is not necessary for the "unlocking" of protected software elements by use of capability keys. The unlocking of protected software elements employs capability keys and requires that the capability keys be transformed. One convenient capability-key transformation that will be used in one embodiment of the system is now described.

The computer system's identity key, I.sub.k, (for example, a 32-bit serial number) is read from the system firmware stored in PROM memory 14 of FIG. 1. The identity key, I.sub.k, is then transformed with the capability key, C.sub.k, entered through keyboard 12 to form a transformed capability key, T.sub.k, as follows:

I.sub.k * C.sub.k =T.sub.k Eq.(2)

In Eq.(2), the symbol "*" designates a reversible transform which typically is performed in a number of steps. First, the serial number identity key, I.sub.k, is transformed by one or more arithmetic or logical operations into two 32-bit control numbers, B.sub.1 and B.sub.2. Typically, these transformations of I.sub.k are version-dependent. For example, the transformations consist of multiplying I.sub.k by two different constants, J.sub.1 and J.sub.2 (where J.sub.1 and J.sub.2 may be different for different versions), as follows:

(I.sub.k)(J.sub.1)=B.sub.1 Eq.(3)

(I.sub.k)(J.sub.2)=B.sub.2 Eq.(4)

The transformation of the capability key, C.sub.k, then further proceeds in two steps. The first control number, B.sub.1, is transformed with the numeric capability key, C.sub.k, to yield another 32-bit number, called the intermediate transform, X.sub.k, as follows:

B.sub.1 * C.sub.k =X.sub.k Eq.(5)

In Eq.(5), the transform is typically an EXCLUSIVE-OR operation as follows:

B.sub.1 .sym.C.sub.k =X.sub.k Eq.(6)

The EXCLUSIVE-OR operation indicated by the symbol ".sym." in Eq.(6) is bit-by-bit between each pair of correspondings bits of B.sub.1 and C.sub.k and yields for corresponding bits of X.sub.k a "1" if the corresponding bits of B.sub.1 and C.sub.k are different and "0" if they are the same.

The second control number, B.sub.2, is used to transform the intermediate transform, X.sub.k, of Eq.(6) to form the transformed capability key, T.sub.k, as follows:

B.sub.2 * X.sub.k =T.sub.k Eq.(7)

In Eq.(7), the transform indicated by the symbol- "*" is typically a bisecting permutation indicated by the symbol ##EQU1## as follows: ##EQU2##

The bisecting permutation of Eq.(8) is performed typically in a number of steps as follows. In Eq.(8), if the high-order bit of the control number, B.sub.2, is "1", swap the left and right 16-bit groups of the X.sub.k transform to form the first permuted value, X.sub.k1. If the next bit to the right in B.sub.2 is "1", swap the leftmost two 8-bit groups of X.sub.k1 to form the left half of the next permuted value, X.sub.k2. If the next bit to the right in B.sub.2 is "1", swap the rightmost two 8-bit groups of the X.sub.k1 value to form the right half of X.sub.k2. Use one at a time the next four bits of B.sub.2 to control swapping of the left and right halves of each of the four 8-bit groups of X.sub.k2.

Each 8-bit group of X.sub.k2 will swap a 4-bit left and a 4-bit right half as a function of one corresponding bit in B.sub.2. When each of the four 8-bit groups of X.sub.k2 is swapped or not as determined respectively by four bits of B.sub.2, the result is the next permutted value, X.sub.k3. The value X.sub.k3 consists of eight 4-bit groups, each 4-bit group having 2-bit left and right halves. The next eight bits of B.sub.2 control swapping of the left and right halves of the eight 4-bit groups of X.sub.k3 and the result formed is the next permutted value X.sub.k4. The value X.sub.k4 consists of sixteen 2-bit groups, each group having a left bit and right bit. The next sixteen bits of B.sub.2 are used to control the swapping of the left and right bits of the respective sixteen groups of X.sub.k4 to form the next permuted value X.sub.k5 which is the final value, T.sub.k.

Note that this bisecting transform of Eq.(8) is reversible since given a desired transformed key, T.sub.k, the system serial number identity key, I.sub.k, and knowledge of the transform process, the process can be executed "in reverse" so as to compute a corresponding capability key, C.sub.k.

After the capability key, C.sub.k, has been transformed by I.sub.k to form the transformed capability key, T.sub.k, the transformed capability key, T.sub.k, is compared with a stored key, S.sub.k. If T.sub.k matches S.sub.k, then the software element associated with S.sub.k is unlocked and ready to be accessed by the system. Typically, S.sub.k is formed of two parts, namely, an authentication key, V.sub.k, and an access key, A.sub.k. The stored key, S.sub.k, should be identical to the transformed key, S.sub.k. After the capability key transformation is completed to form T.sub.k, the 16-bit left half, T.sub.L, of T.sub.k is compared with the authentication key, V.sub.k, for this system. If T.sub.L does not match V.sub.k, the failure to match indicates that use is not authorized and a special "cracker countermeasure" procedure is entered.

If the authentication code, V.sub.k, matches T.sub.L correctly, each element that still has "0" in its capability key field in the element directory is examined to determine which ones have an access key, A.sub.k, matching the 16-bit right half, T.sub.R, of the transformed capability key, T.sub.k.

Wherever a match is found between A.sub.k and T.sub.R, the capability key, C.sub.k, (not the transformed capability key, T.sub.k) is stored in that elements capability key field of the element directory. Storing the capability key, C.sub.k, into the directory constitutes entry of the capability key into the system and the "unlocking" of the corresponding protected software element.

It is important that the transformation of Eq.(2) used with the capability key effectively permutes the bits. If only key-stream encryption were used, a clever software user who had obtained authorization for several capabilities for a given computer system might compare them and deduce which elements made up the authentication key. Given that information, the security systems on all machines could be attacked without fear of countermeasures. Using a cryptosystem which permutes the bits in a system-dependent way avoids this problem.

File Access Control

Whenever file access is requested to obtain access to a protected software element