Method and system of securely enforcing a computer policy

[0001] The present invention relates to the secure enforcement of computer policies, and particularly although not exclusively to methods and systems which enable enforcement by means of delegated trust.

[0002] Many secure computer systems, especially but not only in the banking and financial services industries, make use of automated policies controlled by a “policy enforcer” or auditor. For example, where cryptographic keys are in use, the policy might specify that whenever the system attempts to use an out of date key an entry is written to a secure log for later manual checking by the auditor. A difficulty with this approach is that where a problem occurs it needs to be manually tracked back to its ultimate source after the event. If for example it is found that the system has incorrectly used an invalid key, but has not for some reason written an entry into the log, a lengthy investigation may be required, including an after-the-event check that the routine that writes to the log was not disabled or tampered with by an attacker.

[0003] More generally, current high-security processes normally use manual audit to measure conformance with policies after the event. This is both expensive and potentially unreliable. Such automated systems as exist need to be performed on specialist secured computers if they are to be considered secure.

[0004] It is an object of the invention at least to alleviate these problems of the prior art.

[0005] The invention stems from a development of the concepts disclosed in WO-A-0163385, in the name of the present applicant, which describes a method of selectively controlling access to a computer resource by means of a cryptographic key associated with the resource. The present invention is concerned not just with the controlling of access, but the enforced operation of procedures which the auditor confirms in advance are “safe”. In particular, the invention allows a user to define a policy or method which the auditor accepts as being safe; that is then approved and digitally signed by the auditor. The user then allows that approved policy to run in a secure manner. Should an error be noted at a later stage, the auditor now no longer has to check whether the policy is operating correctly or whether it may have been subverted by an attacker, since that check will now have been done automatically by the system, whenever the policy was run. The fact that the policy has run at all confirms to the auditor that it cannot have been tampered with either before being run or during operation.

[0006] According to a first aspect of the present invention there is provided a method of securely enforcing a computer policy comprising:

• • [0007] (a) providing a secure computer resource including:
    • [0008] (i) data
    • [0009] (ii) a policy to be applied to the resource, the policy including a trigger and an associated computer method;
  • [0010] (b) executing an operation on the data while watching for an occurrence of the trigger; and
  • [0011] (c) when the trigger occurs, securely enforcing execution of the computer method.

[0012] According to a second aspect of the invention there is provided a system of securely enforcing a computer policy comprising:

• • [0013] (a) a secure computer resource including:
    • [0014] (i) data
    • [0015] (ii) a policy to be applied to the resource, the policy including a trigger and an associated computer method;
  • [0016] (b) an operation processor for executing an operation on the data while watching for an occurrence of the trigger; and
  • [0017] (c) a policy processor for securely enforcing execution of the computer method when the trigger occurs.

[0018] This invention allows pre-defined policies to automate the policy audit function while allowing high levels of security, thereby giving cost efficiencies and allowing higher scalability than may be feasible with manual techniques. It further provides general purpose, and therefore flexible automated and secure processes. In addition, it allows clear and flexible demarcation between highly secure parts of a process (i.e. in policies), for less secure programs, which allows for incremental automation of high security parts of current processes.

[0019] The invention may be carried into practice in a number of ways and one specific embodiment will now be described, by way of example, with reference to the accompanying drawings, in which:

[0020] FIG. 1 is a diagrammatic representation of a preferred embodiment of the invention;

[0021] FIG. 2 is a diagrammatic representation of the access processor in FIG. 1; and

[0022] FIG. 3 is a diagrammatic representation of the resource in another embodiment

[0023] In the preferred embodiment of FIG. 1, the system comprises a secure processor (typically a secure hardware module) 100 that performs an operation on a resource 102 when requested by an external agent 104.

[0024] The resource 102 includes data 106, the content of which depends upon the type of resource. If the resource relates to a cryptographic key, for example, the data will include the key value; if the resource relates to database record, the data includes the set of values that correspond to the fields in the record; and if the resource relates to a time stamp, the data defines the time. Also contained within the resource 102 is a control set 108, a policy list 110 and a signature set 112, details of which will now be described.

[0025] The control set 108 specifies the set of conditions that the creator or owner of the resource (who will be called for the sake of simplicity the “owner”) has specified that must apply before the secure processor 100 is authorised to perform each operation with the data 106. More specifically, the control set comprises a set of two-part entries, with the first part of each pair defining an operation and the second defining a criterion. The operation identifies an inherent, pre-defined function that the secure processor 100 may do on the data, for example reading, writing, encrypting, signing and so on. The criterion defines what must be true before the secure processor is permitted to perform the corresponding operation.

[0026] The policy list 110 specifies a set of activities that the secure processor must automatically invoke as it carries out each operation defined by the control set 108 on the data. The policy list 110 is a list of triggers and corresponding methods (such as a set of instructions in a program) that the secure processor is to perform when the respective trigger is activated. Each trigger identifies a specific condition in a list 124 that will be watched for when the secure processor carries out the operation on the data. Exemplary conditions might include “before starting the operation”, “after completing the operation” and so on. Each condition may be viewed as a pair, namely {Operation, State}. Each trigger corresponds to the pair {Operation, Condition}.

[0027] For example, consider a resource which represents an encryption key, with control set entries:

• [0028] {Op2=encrypt; Crit 2.1=‘before starting’; keyId 2.1=10003}
• [0029] {Op2=encrypt; Crit 2.2=‘before finishing’; keyId 2.2=10004}

[0030] The corresponding operation entry for an operation “encrypt” is:

• [0031] {encrypt, {before starting); after encrypting a block; after finishing}

[0032] The policy list contains: {policy 1; policy 2, . . . }, i.e.

• [0033] {Trig 1={encrypt, before starting}; method 1}
• [0034] {Trig 2={encrypt, before finishing}; method 2}

[0035] Method 1 checks whether the encrypting key is in service, for example, by checking that its expiry date is in the future. If the key has expired, it ‘makes_new_key’—creates a new key and stores the previous one in some archive. Policy 1 is signed by the owner of signing keyId 1000, who may be responsible for day-to-day key operational management.

[0036] Method 2 keeps a total of the amount of data encrypted with the encryption key and ‘makes_new_key’. Policy 2 is signed by keyId 10004, which is owned by the security manager, who sets high level operational policy.

[0037] The conditions for the operation encrypt (where the resource represents a cryptographic key) could be the set: {before starting, after encrypting a block, after completing all the encryption}etc, and may include all the relevant states in all possible encryption operations.

[0038] A given control set, for a given resource, references only those conditions that are relevant to it. Op 2 might for instance have Criterion 2.1=‘before starting’; and criterion 2.2=‘after completing’, only; and not reference ‘after encrypting a block’, since it is not relevant for that specific resource.

[0039] The policy list must contain at least entries that correspond to all the criteria in the corresponding control set.

[0040] However, the policy list will often contain a set of policies for all the conditions in all the operations, since typically the policy lists will be unified over many resources and this unification provides an economy of scale in policy management.

[0041] Of course, a resource's policy list must contain policy entries at least for all criteria on the corresponding control set.

[0042] In many cases the condition list will be embedded in the implementation of the operation processor, so, therefore, will not be distinct or external data. For example, if the resource represents ‘secure time’, the secure processor hardware and firmware will implicitly define the operations {read, modify}, and may explicitly implement the conditions: {before starting, after completing}.

[0043] However, where the resource represents more abstract business data, the operation list may be explicit and distinct from the secure processor; the processor may load and perhaps even manipulate it dynamically. For example, if the operation list is associated with a work-flow process, one may want to be able to upgrade the system periodically to load new operations into the secure processor.

[0044] Clearly it is not necessary to sign the condition list when it is embedded within the secure processor; but if external, it will be signed.

[0045] Associated with each element of the policy list 110 is a signature set 112, comprising a set of one or more digital signatures. Each of these digital signatures is made with a signing key 114 having a key Id 116.

[0046] In this embodiment, the signature set is a digital signature with a signing key thus: Sign({trigger, method}, signing key), where ‘a{a, b, . . . }’ means concatenate ‘a’ and ‘b’, etc. although specific implementations may choose to concatenate other data in the signature.

[0047] The key ID is cryptographically derived from a {signing, verifying} key-pair, in such a way that the secrecy of [at least] the signing key is not compromised.

[0048] For example, the key ID could be:

• [0049] ‘hash({signing key, verifying key})’
• [0050] where ‘hash( )’ is a one-way digest function with the property that it is very difficult to deduce ‘a’, given ‘hash(a); and ‘{a, b}’ means ‘a’ concatenated with ‘b’.

[0051] A criterion references one or more key Ids, thereby associating to a signing key, and corresponding verifying key, without compromising their confidentiality.

[0052] The functions of secure processor 100 are performed by an operation processor 118, an access processor 120 and a policy processor 122.

[0053] The operation processor 118 executes the steps of the operation that has been requested by the agent 104. As the operation proceeds, the processor watches for the existence of any condition taken from a condition list 124, the contents of this list being dependent upon the operation being performed. The entries in this condition list correspond with the triggers within the policy list 110 of the resource.

[0054] When the operation processor reaches a condition within the condition list 124, it stops and passes control to the access processor 120. This checks the resource to ensure that the relevant policies satisfy the associated criteria within the control set 108. If so, control is then passed to the policy processor 122. This is done by means of a verifying key 124 which corresponds to the signing key 114 of the signature set 112 within the resource. The verifying key 124 is identified by means of a key Id 116′ which is the same as the key Id 116 of the signing key 114.

[0055] The purpose of verifying key, of course, is to enable the access processor 120 to verify a signature which has purportedly been made with the signing key 114. Accordingly, the secure processor 100 may execute a particular policy during a given operation on a resource if and only if that policy contains a signature within its signature set 112 that was signed by the signing key 114 that the key Id 116′ identifies.

[0056] The policy processor executes the appropriate method from the policy list 110, depending upon which condition has triggered, and then returns control back to the operation processor.

[0057] By this mechanism, the owner of the signing key 114 (which could be a person or a machine) can:

• [0058] (a) delegate trust to a signed policy (as represented by the combination of the policy list 110 and the signature set 112);
• [0059] (b) bind that trust to an individual resource 102, thereby ensuring that a policy is run only against appropriate resources; and
• [0060] (c) revoke the trust in (b) by ensuring the removal of the verifying Key 124

[0061] A signature by the Owner of the signing key can thus be used to convey one or more of these properties:

• [0062] ‘proof of origin’
• [0063] that the owner of signing key originated the associated policy or policy list;
• [0064] ‘integrity’
• [0065] that the policy, or policy list, is unchanged from when the owner signed it; and
• [0066] ‘delegation’
• [0067] that the owner authorises in advance the execution of the method in the associated policy (or methods in the associated policies in the policy list).

[0068] In that way, the use to which the data 106 may be put can be predefined and controlled in advance by the owner of the resource or the auditor. Since the policies always stay with the resource throughout its life, no additional external or gatekeeper control is required when the resource is run: the resource effectively polices itself.

[0069] The detailed operation of the described system will now be set out, with further reference to FIG. 1 and also to FIG. 2. In order that the operational flow may be easy understood, reference should be made to the paragraph numbers below which correspond with the similarly numbered arrows in the drawings.

• [0070] 1. To start, the secure processor 100 receives an instruction from an external agent 104 to perform Operation 1 on a given resource 102, which it passes to the operation processor 118.
• [0071] 2. The operation processor notes the list 124 of conditions that correspond to Operation 1. It executes Operation 1, step by step, and stops at the first condition in the list, namely Condition 1.
• [0072] 3. The operation processor then passes control to the access processor 120.
• [0073] 4. The access processor requests the control set 108 from the resource, and loads all the operation/criteria pairs that correspond to Operation 1. It also loads all the associated key Ids 126 that each criterion references. In the example shown, the access processor loads criterion 1.1 and key Id 1 both of which are associated with Operation 1.
• [0074] 5. The access processor loads from the policy list 110 all the policies that have a trigger equal to Condition 1, along with the associated signature set 112. In this case, signature set 1 is loaded (these signatures having previously been prepared by means of the signing key 1).
• [0075] 6. The access processor loads all of the verifying keys 124 that are associated with the loaded key Ids. Since signature set 1 is associated with key Id 1, the access processor simply loads the corresponding verifying key 1.
• [0076] 7. Then, for each policy which has been loaded into the access processor, the following steps occur (refer to FIG. 2):
  • [0077] 7.1 the access processor matches key Ids. Specifically, it compares the key Id 126 corresponding Criteria 1.1 with the key Id 116 from the loaded signature set 112.
  • [0078] 7.2 If the match succeeds for at least one key Id, processing continues at step 7.3; otherwise an error is signalled and the procedure ends.
  • [0079] 7.3 Next, the access processor verifies the signature. Specifically, it verifies the signature from the policy that matches key Id 1, namely signature 1.1, with the corresponding verifying key 1.
  • [0080] 7.4 If the verification succeeds, processing continues to step 8; otherwise, an error is signalled and the process stops.
• [0081] 8. Once all of the tests within the access processor have been completed successfully, control passes to the policy processor 122. The policy processor executes the corresponding method in the policy list 110 that has been triggered; in this case, method 1.
• [0082] 9. Once the policy processor has executed the required method, control is returned to the operation processor 118 which continues to step through Operation 1 until Condition 2 is reached. The entire cycle repeats until the operation is complete.
• [0083] 10. Finally, the processor returns control to the agent 104.

[0084] Where there is no access to the resource except via the secure processor, there is no need for the resource itself to be further protected. But where direct access is permitted, the response (or at least the data within it) may be cryptographically protected and/or digitally signed, as shown at 150 in FIG. 1. Where the condition lists 124 are separate from the resource, they may also be encrypted and/or signed, as shown at 160 in FIG. 1. The resource and/or the condition list may be signed multiple time—i.e. signature A and signature B may represent signature sets. Where the resource and/or the condition list is or are signed and/or encrypted, the operations processor and the access processor should respectively verify the signature and/or decrypt when reading the data (see the arrows 2 and 4 in FIG. 1). Such an approach allows the owner to protect both integrity and proof of origin, as well as confidentiality (if encryption is used). It will be understood, of course, that the signing key(s) 150, 160 used to sign the condition lists 124 and/or the resource need not be the same as those keys 114 used to make the signatures set 112 that is associated with a policy.

[0085] All of the signatures previously mentioned may use either symmetric or asymmetric keys.

[0086] In yet another embodiment, shown in FIG. 3, the resource is split between a data portion 310 and a policy portion 320. The former includes data 106, control set 108, and key ids 126, while the latter includes the policy list 110 and the signature set 112. Where the resource may be accessed other than via the secure processor 100, the two separate parts may be digitally signed by signatures or signature sets 150, 150; where confidentiality is important, the two parts may also be encrypted.

[0087] The data portion 310 is associated with the policy portion 320 in any convenient way, for example by ensuring that at least one of the signing keys in Sig. B₁ is the same as at least one of the keys in Sig. B₂. When the access processor 120 loads the data and policy portions, as shown by the arrows 4, 5, the system confirms that this is the case.

[0088] Where encryption is used, the signature is taken over the encrypted data, i.e.

[0089] Sign(Encrypt(Data, Encryption Key, Signing Key)).

[0090] As before, the signing keys may be symmetric or asymmetric.

[0091] The method and operation of the present invention is applicable to a wide variety of types of resource 102 and associated data 106. However, there are three particular examples which merit special mention, namely cryptography, database records, and time servers. These are addressed separately below.

[0092] Where the invention is used in a cryptographic setting, the resource may represent a cryptographic key. The data 106 will then generally contain cryptographic material that determines the particular key, for example the 56-bits of a given Data Encryption Standard (DES) key, or large integers for an RSA public or private key. The data may also contain other information, for example creation date, destruction date, “don't use after” date and so on. Operations that may be defined in respect of the data will include encrypt/decrypt, sign/verify, load, create, delete and so on.

[0093] The policy associated with the encrypt or load operations might include a method that checks the “don't use after” date, and signals to an external system if the key is being used inappropriately. The create operation could result in the invocation of a method that populates the data which a new key that is generated with parameters which are defined within the method.

[0094] In the database example, the resource may represent a relational database record, with the data containing the values of all of the fields that constitute that record. Operations may typically include read, create (write) modify and delete. Other high-level operations could equally well be envisaged, for example the running of a SQL script.

[0095] In the final example, the resource may represent time as supplied by a secure clock. The data then contains the current time, with the operations including such things as read and modify. A resource of this type may be useful in for example a market trading system, in which rules about when things can happen may be encapsulated in the resource policies. Rules could also be set up to control and/or to record the ordering of events in time.

[0096] In the specific embodiments so far described, a resource owner or auditor can reliably trust the way in which the resource is going to be used because the rules defining that trust—in other words the policies—are built into the resource itself. It is also anticipated, however, that more complex webs or chains of trust may be created by the use of multiple signatures having multiple owners. For example, a single policy may define multiple rules, each having separately-owned signatures. The resource itself would then decide who will next be allowed to authorise the next step. In this way, work-flows may be built in. An example of this would be a document the entire life cycle of which is to be specified in advance. The policy may define a chain of users who are authorised to review and to modify the document one by one. After the first person has made any required amendments, the policy automatically encrypts the document using the public key of the second person in the list; once the second person has made amendments the document is automatically re-encrypted with the public key of the third person on the list, and so on.

[0097] Multiply-owned signatures may also be used to require multiple authorisations. An example of such a situation might be the records of a particular house for sale. Those records may be protected by the house owner and may be stored on the individual databases of a number of different estate agents only if the owner gives permission on an agent-by-agent basis. But if an aggregator service were to wish to take data from a particular agent, for display on an aggregation web site, that data would require authorisation from the agent. The data for an individual house might therefore be defined by an individual house-resource which is protected by two separate signing keys, the first owned by the house owner which authorises the data to be stored on the agent's database, and the second owned by the estate agent which authorises that data to be used by the aggregator.

[0098] The system of the present invention may be embodied either in software or in hardware, or in a combination of the two. Typically, the secure processor 100 may be a hardware security module, either with separate individual modules 118, 120, 122 within it, or alternatively corresponding logically separate processes running as a computer program.

[0099] In some embodiments, only the secure portions of the operation processor 118 need be contained within a secure processor module: those portions in the operation which are not required to be secure may be outside the secure boundary. In an alternative. embodiment, the operation processor 118, the access processor 120 and the policy processor 122 may comprise separate secure physical modules, or separate logical processes, which communicate with each other via one or more secure channels.

[0100] In one arrangement, the policy processor 122 may take the form of a secure module on a motherboard of a client machine (not shown). That enables the individual user to securely execute the required methods without needing to access a central server.

[0101] Alternatively, a proxy model may be used, in which a small secure box on a client machine provides sufficient functionality to bootstrap a secure connection with a central policy processor on the server which actually carries out the work.

[0102] Where the policy processor is client-based, it could also take the form of a SIM card on a mobile telephone, or a card which fits into an expansion slot within a desktop or laptop computer.