Patent Publication Number: US-7900239-B2

Title: Controlling access to a resource by a program using a digital signature

Description:
The present invention relates to a computer system and particularly, but not exclusively, to a so-called secure computer system. 
     In many computer systems, it is necessary to control access to certain resources, such as areas of computer memory, cryptographic keys or other sensitive data. This might be because they contain secret information, because the resource is scarce, because the resource has intrinsic value or a combination of factors. In such systems it may be necessary to allow some parties access to the resources while denying access to other parties. 
     There are a number of existing systems which are designed to enforce access control to such resources. There are, however, other more demanding systems where simply controlling who can access the resource is not sufficient. In these systems it may also be necessary to control what is done with the resource. 
     The present invention aims to provide an improved method for securing a resource on a computer system and an improved computer system. 
     Accordingly, the present invention provides a method of controlling access to a resource in a computer system by a body of code having a signature associated therewith, the method comprising the steps of providing a cryptographic key associated with said resource, conducting a verification operation on said signature using the cryptographic key associated with said resource and controlling access to the resource by the code in dependence upon the result of said verification operation. 
     The present invention also provides a computer system comprising verification means for verifying a digital signature associated with a body of program code and a resource having a cryptographic key associated therewith wherein said verification means is operable to use said cryptographic key to verify said digital signature thereby to allow access of the code to said resource in dependence upon the verification. 
     The invention provides a novel system for controlling, on a fine grained basis, what can be done with a resource. In our system the actions will be carried out by a computer program and our invention allows various resources to specify which parties may perform which actions. 
    
    
     
       The present invention will now be described, by way of example only, with reference to the accompanying drawings in which: 
         FIG. 1  is a diagrammatic representation of a conventional secure computer system; 
         FIG. 2  is a representation of the operation of the system of  FIG. 1 ; 
         FIG. 3  is a representation of a second known computer system; 
         FIG. 4  is a diagrammatic representation of a secure computer system according to the present invention; 
         FIG. 5  is a representation of the operation of the system of  FIG. 4 ; 
         FIG. 6  is a representation similar to that of  FIG. 5  of the operation of a modification to the system of  FIG. 5 ; 
         FIG. 7  is a representation similar to that of  FIG. 5  of the operation of a second modification to the system of  FIG. 5 ; 
         FIG. 8  is a representation similar to that of  FIG. 5  of the operation of a third modification to the system of  FIG. 5 ; and 
         FIG. 9  is a representation similar to that of  FIG. 5  of the operation of a fourth modification to the system of  FIG. 5 . 
     
    
    
     In the drawings like parts are given like reference numbers. 
       FIG. 1  is a representation of a hardware computing system  10  which allows a user access to a sensitive or restricted resource. The system has a host computer  12  connected to a secure module  14  which may be a card in the computer  10  or a separate and remote unit. The secure module  14  contains the resource  100 , an execution engine  200  and an access control unit  300 . The system  10  may constitute, for example, a main frame or server PC of a business such as a bank which may be accessed internally or by way of an on-line access, e.g. by a customer. The execution engine  200  is code which is running in the secure module  14  and has access to the security sensitive resource  100  which typically may be bank account data stored in Random Access Memory (RAM). 
     In use, when a third party attempts to gain access to the resource  100  via the host computer  12  the latter applies a computer program code  22  to the execution engine  200  to gain access to the resource  100 . The code  22  to be executed has a digital “signature”  24 , in the form of a unique code, encoded either within the program code  22  or presented alongside the program code. The signature is indicated as Sig  1  to show that it is specific to a particular individual or group of individuals referred to here as the primary owner. Before the code is loaded into the execution engine  200  the signature is verified in the access control unit  300  using a cryptographic key (Key  1 ) and only if the verification is positive is the code allowed to load into the execution engine to give the third party access to the resource  100 . 
       FIG. 2  is a representation of the operation of the system software and shows the program code  22  and associated digital signature  24  in the host computer  12 , and the resource  100 , execution engine  200  and access control unit  300  in the secure module  14 . The access control unit  300  includes an access control device  302  which controls access to the resource  100 . 
     In use, the program code  22  to be executed by the execution engine  200  is applied to the access control unit  300 . As indicated above, the code  22  to be executed has a digital “signature”  24 , in the form of a unique code, encoded either within the program or presented alongside the program. The access control unit  300  contains a cryptographic key  304  (Key  1 ), which may be referred to as the primary key, and a signature verifier  306  in the form of a comparator operable to check the signature  24  associated with the code. The cryptographic key  304  is set by the manufacturer of the secure module  14 . The signature verifier  306  checks the signature  24  using the cryptographic key  304  in the access control unit  300 . Providing the signature  24  on the code is correct, the access control unit  300  allows the code to be loaded into the execution engine  200  where it can be run and gain access to the resource. 
     Thus, the verification of the signature relies upon key  304  that is built into the access control unit  300  by the module manufacturer and it is the loading of the code  22  into the execution engine  200  which is controlled by the verification process. 
       FIG. 3  shows a conventional variant of the system of  FIG. 2  where the primary owner wishes to delegate access to the resource  100  to another party. The code  22  contains a delegation certificate  101  consisting of a further cryptographic key  42  (Key  2 ) and the signature  24  of the primary owner, possibly accompanied by other data. The code also contains a new signature  26  (Sig  2 ) for the other party, referred to here as the secondary owner, to whom the primary owner of the first signature  24  wishes to delegate access to the resource. In this system the key  304  (Key  1 ) built into the access control unit  300  uses the verifier  306  to verify the signature  24  of the primary owner on the certificate  101  while a second verifier  308  checks the second signature  26  of the secondary owner on the code against the key  42  of the primary owner in the certificate  101 . The outputs of the two verifiers are taken together using an “and” operation  310  and only if the first signature AND the second signature are verified is the secondary owner allowed access to the resource  100  by the access control device  300 . 
     A common property of these conventional systems is that ultimately the verification of the signature, or the chain of delegation certificates, ends with a key that is built into the system. It is up to the owner of the system which keys are to be trusted for which operations. 
       FIG. 4  is a representation similar to that of  FIG. 1  of a preferred form of hardware computer system  50  according to the invention. In  FIG. 4 , the secure module  14  contains a secure sub unit  30  in which the execution engine  200  is located. The access control unit  300  and the resource  100  are separated from the execution engine  200  within the module  14  so that the execution engine  200  operates within the secure sub-unit  30 . The separation of these devices may be physical, by means of controlling the electrical and mechanical connections between the devices, or through logical separation in the operation of software components within the computer system. The resource  100  also contains a cryptographic key  102  (Key  1 ) which is the primary key and is similar to key  304  of  FIGS. 2 and 3 . However, the key  102  is set by the owner of the resource  100  and not by the manufacturer of the module  14 . It will be appreciated that, as mentioned above, although  14  is referred to as a module it may be in the form of a card contained within the host computer  12  or may be one or more discrete units physically separate from the host computer  12 . 
     The host computer  12  may communicate with the execution engine  200  only through the access control unit. As shown in  FIG. 4 , any code operating within the secure sub-unit  30  is unable to access any resource outside the secure sub-unit  30  other than by issuing a request through the access control unit  300 . 
     When the host system  10  attempts to load the program code  22 , together with its associated authentication signature  24 , into the execution engine  200 , this code is first passed through the access control unit  300  which checks that the signature  24  associated with the code  22  is a valid signature using the key  102 . At this point, the access control unit  300  does not associate this signature with any authority to access the resource  100 . However, the access control unit  300  records the identity of the signature creator and associates this with the program code  22  that has been loaded. When the program code  22  is subsequently executed by the execution engine  200  within the sub-unit  30 , the code may request access to the resource  100  and the request is passed through the access control unit  300 . The identity recorded against the code at the time that it was loaded is then checked by the access control unit  300  using an access control policy to ascertain what actions, if any, are authorised by the signature  24 . Only those authorised actions are allowed to be carried out on the resource  100 . 
       FIG. 5  is similar to  FIG. 2  and is a representation of the operation of the system software within the module  14 . 
     In the system of  FIG. 5 , the resource has associated with it the cryptographic key  102  which may be used to verify the digital signature  24  associated with the body of program code  22 . The program code, along with its associated digital signature  24  is first loaded into the module  14  where the access control block  300  compares the signature with the key  102  associated with the resource  100 . The access control unit  300  includes access control device  302  which controls access to the resource  100 , and signature verifier  306 . If the signature is correctly verified then the code is allowed to load in the execution engine  200  but still does not have access to the resource  100  and the access control unit  300  records the identity of the signature creator and associates this with the program code  22  that has been loaded. 
     If the user then requires access to the resource  100  to carry out a particular operation, the code  22  is run in the execution engine  200  and requests access to the resource  100 . This access has to be effected through the access control unit  300  and at this stage the signature  24  is checked against the access control policy. 
     In its simplest form in  FIG. 5  the signature  24  is verified against the key  102  by the verifier  306  and if verified access is allowed to the resource  100 . Thus, it is the resource itself that determines which code is allowed access to the resource because the key  102  is in the resource and not the module  100 . This means that each user can set his own key in his own data block in the resource  100  and this is not therefore accessible by whoever has access to the module  14 . 
     In variants of this invention more than one signature can be applied to the program code using different cryptographic keys. In this case access to the resource will be granted if any of the signatures verify against any of the listed keys given with the resource. The signature on the program code may be replaced by a signature on a cryptographic hash of the program code, a signature on a set of hashes of parts of the program code, on a hash or hashes of the parts of the program code or on any other method which allows the verification of the signature to be completed only if the code is identical to the code upon which the signature was originally placed, since the signature is unique to the code. 
     The keys associated with the resource may be replaced by cryptographic hashes of those keys or other identifiers of the keys which allow the device uniquely to identify the correct keys with which to verify the signature. In these cases the real signature verification keys must be available to the device in order to carry out the verification process. 
     In this invention the signature can be any form of digital or electronic signature which can be verified by the device. 
     The system of  FIG. 5  does not restrict the actions which the signature holder might carry out on the resource  100  once the code is allowed access to the resource  100  by the access control unit  300 , since the key does not have any access restrictions associated with it.  FIG. 6  shows a system in which the actions are restricted to those allowed by the associated key. In this system, the resource  100  has associated with it an access control list (ACL)  106  comprising key sets  108 . Each set  108  indicates some actions which may be performed using the resource, some key which may be used to authorise those actions and, optionally, some constraints upon those actions including time limits, usage limits, parameter limits or other constraints. As before, the resource is made available to the execution engine  200  but this time it is bound to the access control lists rather than simply to keys. The program code  22  is loaded into the execution engine  200  as before along with the signature  24  upon the code. The code may then be executed inside the execution engine  200  and when the code attempts to carry out any operation upon the resource the access control list  106  is checked. If the signature on the code can be verified by the verification unit  306  with respect to one of the keys in the ACL the access control unit  300  allows the code access to the operations listed in the ACL entry which has the correct key, providing the access falls within any given constraints. Otherwise the actions are not permitted. For example, one access key may allow the user read only rights to data in the resource whilst another might allow read/write access. Another possibility where the resource is memory is for different keys to allow access to different parts of memory. 
     In a third version of the invention ( FIG. 7 ) intermediate access control lists may be used to delegate control. The code  22  contains a delegation certificate  400  consisting of a further cryptographic key  402  (Key  3 ) and the signature  24  of the primary owner. The code also contains a new signature  28  (Sig  2 ) for the secondary owner, to whom the primary owner of the first signature  24  wishes to delegate access to the resource  100 . As in the embodiment of  FIG. 6  the use of the resource  100 , or individual operations on the resource, is associated with signature verification keys  108  of access control list  106 . However, in this system delegation credentials may be constructed in the following manner: an access control list  402  in the delegation certificate  400  is built in a similar form to the list  106  associated with the resources. This list  402  is then signed using the cryptographic signature key  24 . The resource  100  is made available to the execution engine  200 , along with its access control list  106 , and the program code  22 , its signature  28 , and the delegation credential  400 , including its signature  24  are all loaded into the execution engine  200 . The signatures on the code can be checked by verification unit  308  against the keys in delegation credential  400  and the signature  24  on the delegation credential is verified against the keys  108  in the resource&#39;s access control list  106  using verification unit  306 . The intersection is taken at  310  of the operations listed in validated ACL entries and validated delegation credentials. Access is granted by access control device  302  to the code for operations that fall within this intersection of operations. 
     It will be appreciated, therefore, that one user with rights to one part of the resource  100  can sign off or delegate part or all of those rights to a third party. Referring again to  FIG. 7 , the output of verifier  308  shows operations identified as [ 2 ,  3 ,  4 ] being allowed by the verification check of the secondary owner&#39;s signature  28  against the delegation key  402 , for that signature, of the code access control list  400 . However, the output of verifier  306  shows only operations identified as [ 1 ,  3 ] being allowed by the verification check of the primary owner&#39;s signature  24  against the delegation key  108  in the resource access control list  106  for that signature. Thus, the secondary owner is only allowed to carry out operation [ 3 ] on the resource  100 . 
     In a fourth variant of this invention ( FIG. 8 ) access can be granted to all code which is authorised under the system shown in  FIG. 6  as well as code authorised as described above in relation to  FIG. 7 . Multiple levels of delegation may be permitted in which the operation must be listed in each ACL with a key which verifies the signature on the next credential, or which verifies the program code in the last credential. 
     As shown in  FIG. 8  this scheme can be used to allow multiple bodies of code  22   a ,  22   b  to have differing levels of access to the same resource  100  by having different delegation certificates  400   a ,  400   b  and signatures  24   a ,  24   b ,  28 ,  32 . 
     The codes  22   a ,  22   b  are loaded into different execution engines  200   a ,  200   b  within the secure module  14 . It will be appreciated that the different execution engines  200   a ,  200   b , as well as individual resources, may be in different secure sub units within the secure module  14  and cannot therefore interfere with one another. 
     In a further modification ( FIG. 9 ) the system of  FIG. 8  can be used to allow one body of code  22  different levels of access to more than one resource  100   a ,  100   b . The code  22  is similar to code  22   a  or  22   b  of  FIG. 8  but has two or more delegation certificates  400   a ,  400   b , each with a cryptographic key  402   a ,  402   b  and signature  24 ,  26 . Here there are two primary owners of signatures  24 ,  26  who both wish to delegate to the same user or secondary owner of signature  28 . The secondary user is granted different rights to the two resources  100   a ,  100   b  in dependence on the delegation credentials. The access control unit of  FIG. 9  can perform the verification for both primary signatures  24 ,  26  and the secondary signature  28  at the same time as is indicated by the broken lines. In the example of  FIG. 9 , the secondary user is allowed by the ACLs of the delegation certificate  400   a  of primary owner of signature  1  to carry out operation [ 3 ] where the resource  100   a ,  100   b  allows according to its own ACL whilst the secondary user is allowed by the ACLs of the delegation certificate  400   b  of primary owner of signature  2  to carry out operations [ 2 ,  3 ] where the resource  100   a ,  100   b  allows. 
     In a further modification of the system, which may be combined with previous versions, the access control lists either attached to the resources or used in the delegation certificates can specify that any further delegation certificate must contain a “challenge” value. In this system when accessed by the code the access control unit  300  returns a “challenge” value which is unlikely to be guessed usually because the number is large and appears to be random. The access control unit  300  keeps a record of all the challenges that have been issued, along with information about the how long the challenge value is considered to be valid. For the code to be allowed access to operations permitted by an ACL entry requiring a challenge it must have a certificate that includes a currently valid challenge and this must be correctly signed. By controlling the lifetime of the challenge the system can control the lifetime of certificates used by the code. This can be used to grant temporary access rights to a body of code. 
     The differences between known systems and the system of the present invention will clearly be understood from the foregoing. In particular, in known systems, the code once authorised can access any available resource and the system requires the secure unit to protect the code, the resources and the checking process from hostile external attacks. In contrast, in the system of the present invention, the authorisation is contained in the resource access rather than the loading of the code and the secure sub-unit  180  not only protects the code, resources and the checking process from hostile external attacks but also protects the resources and checking processes from attacks from hostile code already loaded in the execution engine  200 . This extra protection is necessary owing to the delayed nature of the authorisation of accesses to the resources. 
     It will be appreciated that the code, once loaded in the secure sub-unit  180 , can perform any operation within the sub-unit including altering the code itself, since the authenticity of the code is checked before execution begins. It will also be appreciated that the present invention is more efficient than systems where the code is authenticated each time an access to the resources is made since the signature on the code need only be validated once. 
     In cases where more than one signature is applied to the code before it is loaded, all of the signatures are verified as the code is loaded and the identities of all the code signors are recorded. When an access to a resource is made, either the verification device can allow the access if any of the signors would have the right to make the access or, alternatively, the code might indicate in the request the identity whose credentials should be used for the authorisation. 
     In all of the systems represented in the drawings, various resources are required to be accessed by particular blocks of computer program code. The programs may be general purpose programs which make use of the various resources. An aim of the invention is to control the access to the resources so that only authorised programs may access the resources in authorised ways or cryptographic keys which may be accessed by selected users. 
     It is up to the owner of the computer system to determine which keys are to be trusted for which operations. Consequently, if further resources are added to the computer system, further keys must be added to the access control unit  300 .