Patent Application
20070100854
The invention relates to a method of allowing validation of a data structure.
Authentication of data using digital signing is well known whereby information is uniquely summarized, for example using hashing, and a digital signature is computed over that summary and attached to the information such that a third party can identify whether the signing entity is the correct entity and the information has not been changed. In one implementation an extensible mark-up language (XML) signing scheme of this nature is provided in which, additionally, parts of a document that do need to be signed are identified, for example, via applying an XPath transform to the original document before summarizing it.
A method of providing a validatable data structure having a changeable part and an unchangeable part having respective content comprises incorporating, in the unchangeable part, an attribute name identifying the changeable part and a policy specifying who can change that part and what changes are allowed. The changed part could further introduce new changeable parts and policies.
Embodiments of the invention will now be described, by way of example only, with reference to the drawings, of which:
In overview the method and apparatus described herein can be understood with reference to
Referring firstly to
By way of explanation one specific example showing operation of the method described herein will be described with reference to the system 100 shown in
One implementation where such a system may be required is in a sales environment where a salesman completes an order for a customer by completing an online form in which he specifies the ordered product. However the salesman may not have pricing information, nor information about where the pricing information can be derived. The document capturing the details of the order is codified as a hierarchical attribute tree and submitted by the salesman at the originator computing entity 102. The document has some changeable part to be filled in including the pricing details by the order processing software at the remote scheduler 104 comprising the front end of the order processing system. The scheduler or front end therefore needs to establish which further remote entity can obtain the pricing information (for example task processor 106, 108 or 110), to implement the “pricing task” and will then deploy the task to the appropriate task processor.
However where the scheduler is partially trusted it is undesirable to require the originator to validate every amendment made by the scheduler. On the other hand, it is important to ensure that the scheduler can only change the required part of the data structure—“the changeable part”—and none other such that a third party can ensure that the remainder or “original intent” of the description—“the “unchangeable part” has not been compromised. For example where the scheduler is only be permitted to add appropriate attributes defining the location at which the task is implemented it is desirable that third parties should be able to identify whether any additional, impermissible changes, have been made by the scheduler such as the nature of the task itself. In an optimization it is further desirable that a third party can establish that only the scheduler, and not some unauthorized party, has made permissible changes.
As discussed in more detail below, the appropriate security features can be implemented by providing extensions to the language used to describe the data structure, and a specific example is presented in relation to the SmartFrog language which will generally be known to the skilled reader such that detailed description is not required here. However it will be appreciated that appropriate extensions can be implemented in any desired language. The SmartFrog language is described in at http://www.smartfrog.org.
An exemplary data structure to which the method described herein can be applied can be understood with reference to
Reverting to the distributed computer system 100 shown in
Once the data structure is originated at originator 102 it is forwarded to the scheduler as shown by arrow A in
Upon receipt of the data structure 200 the scheduler first authenticates this data structure using its own global policy, then modifies the changeable part 206 as appropriate and, for example, deploys the data structure via the communications network 112 to the appropriate task processor which it may itself have scheduled, for example task processor 108 as shown schematically by arrow B. For example the scheduler may identify task processor 108 as the appropriate processor for incorporating the pricing information and identified accordingly by updating the host and port leaf nodes in sub-description 206.
Task processor 108 then validates the received data structure. In particular the task processor will carry out checks to ensure that the content of the data structure corresponds to an unchangeable part validator value associated with the original data structure content such as a global unchangeable part signature added by the originator, shown schematically at 210 in
In order to ensure that permissible modifications by the scheduler to the changeable part do not return a correspondingly changed value for the computed validator value or signature at the task processor, both the originator 102 and the task processor 108 compute the signature as a function of a fixed or common value associated with the changeable part at node “location” and which is independent of the specific content of node “location”. As a result the data structure as a whole can be authenticated even if changes are made to the changeable part.
In a further optimization it is desirable to ensure that the correct party, i.e. the scheduler in the present example was the party that modified the changeable part 206 and the content of the changes satisfy certain policy. This is achieved by further associating a changeable part security policy 212 with the parent node “task” of node “location” for example “SubDescriptionPolicy” at leaf node G 203 or in any other appropriate manner. Once again the policy cannot be altered as it is in the unchangeable part. The policy specifies a security requirement allowing checking of the authenticity of a signature 208 added by a changing entity and the nature of those changes as described in more detail below. In particular, upon modification of the data structure the scheduler 104 adds its signature 208 to the changeable part. The task processor 108 then needs to validate also the signature 208 associated with the independent data structure that forms the changeable part at node “location”, using the policy specified in the non-changeable part. to ensure that the scheduler was authorized to make that kind of modification.
As a result embedded sub-descriptions such as the changeable part 206 can be checked for authenticity and integrity by other components in a distributed computer system as appropriate without requiring validation by the originator of the initial description. where the task processor trusts the originator but not the scheduler.
The steps performed according to the method described herein can be further understood in overview with reference to the flow diagrams of
At step 300 the originator identifies changeable and unchangeable parts of the data structure and at step 302 an identifier and policy are associated with the changeable part, placed in the unchangeable part. At step 304 a global signature is computed for the data structure and added to the unchangeable part. The signature is computed as a function of the content of the data structure including a fixed value associated with the changeable part.
Referring to
Turning to
The manner in which validation is carried out can be in any appropriate manner. For example a system using public-private key pairs can be implemented as is well known to the skilled reader and so not described in detail here. In summary, however, each party has a private key value which can be combined using an appropriate operator with a hash to provide a unique signature which is a function both of the identity of the signing party, i.e., its public key, and the content of the data structure allowing a third party to verify both the identity of the signing party and integrity of the content of the original data structure.
As a result of this approach non-fully trusted agents can partially modify or propagate a data structure such that a description is modified in a controlled way. A third party can then validate that the original intent of the description has not been compromised by the transformation such that certain parts of the description cannot be changed. Furthermore the immutable or unchangeable part contains the identifiers identifying the changeable part and can further specify who can change the changeable parts and the nature of these changes. Security is further enhanced as any attempt to modify the data structure such that other parts appear to be changeable parts will fail because this will alter the content of the unchangeable part of the description and hence the global signature check will fail.
Yet, further part of the data structure can be replaced by appropriate unique values representing the content which, when the global signature is computed, return a validated result meaning that parts of the data structure which are not required for certain entities within a distributed system or which unnecessarily increase the size of a data structure to be delayed, can be replaced by the unique value.
The steps performed at the originator entity 102 can be understood in more detail with reference to flow diagram of
In the context of data structure 200 of
In addition the policy may specify the nature of the changes that can be made in which case, at step 316, the task processor checks that the content and changeable part respect the associated permitted changes in the policy.
In order to secure the data structures of this hierarchical form and in particular a global signature, the originator computes a recursive canonical representation of the description. In particular the function effectively works up the hierarchical tree and concatenates a canonical representation of simple values associated with nodes where available or, if the value is another internal node seeks the extended simple value. The concatenation can comprise, for example, a hash function which will be well known to the skilled reader as having the property of returning a unique, repeatable “digest” value as a function of and shorter than the data content, such that any change to the content is detectable when the operation is repeated on the changed content as a different hash value will be returned.
As a first step, 400, therefore, those parts of the description which it is permissible for a remote entity to change (for example the location information to be changed by a scheduler in the example provided above) are identified by inserting the identifier “signed” in the unchangeable part. The keyword “signed” is introduced as a qualifier to “extends” and represents that the value of the extended attribute is a node that has the property “signed”, that property indicating that the node is “opaque” when its enclosing description, that is, the description of which it forms a changeable part, including its parent node is canonicalized. Hence when the recursive hashing process is carried out, it terminates at the signed node and instead a fixed value associated with the node is operated on by the hashing function. Therefore, the “top level” description can be validated independent of the content of the sub-description.
At step 402 the policy, comprising a security requirement in relation to the signed sub-description allowing requirements relating to authorized modifiers and modifications of the sub-description to be dictated is specified; in this case valid signers of the sub-description can be specified for example by reserving an appropriate attribute name such as “subDescriptionPolicy” and providing an attribute with that name in the immediately enclosing node of the signed nodes. The value of the attribute specifies a security requirement for the signer, for example specifying its public key and can be implemented in any appropriate manner for example using simple path constraints (SPC's) as described in a co-pending patent application commonly assigned herewith and entitled “A method of authorising a computing entity” filed on the same day under reference no. HP200504148 This may be represented as shown in the previous Listing 1
This policy may identify, for example, which parties may modify the changeable part and any other appropriate security features such as the possible modifications available, a timescale of modification and so forth. As discussed below the modifier for example the scheduler must also take various security-related steps including signing the changes which must match with the policy for the eventual data structure to be validated by a third party entity.
Once the policy requirements and marked parts are included in the unchangeable part, the concatenation step 404 is carried out by computing a hash of the description.
To summarize, the hash value computed in step 404 can be obtained recursively applying the following example function:
As a result it will be seen that the output comprises a validator value or validator valve precursor in the form of a hash string comprising an operation performed recursively on the simple values attached to each node traversing the tree from the “bottom up” to find simple values associated with nodes where required, assuming a character encoding, can be converted to a byte array that can be signed using a standard approach. However, this is not carried out for find nodes for which a fixed or common value, for example, the hash of the string “extends Signed { }” is obtained although any fixed value that cannot be a hash of a non-signed description can be adopted. The hash string can be computed in any appropriate manner for example using an approach as follows:
Of course any appropriate manner of obtaining a unique digest of the information content of the data structure may be adopted as will be well known to the skilled reader. The hash is then signed at step 408.
The manner in which the function performs recursively in relation to a hierarchical data structure can further be understood with respect to the following example in the context of Listing 1 and the hierarchy represented therein and in
Then after the second level “canonical” function call, where we assume that hashString({\nsubDescriptionPolicy “(<scheduler_pub_key>)”;\n description extends HASH-SHA-1#sdsdasdasd#;\n location extends SIGNED HASH-SHA-1#efefefefef#;\n}) returns HASH-SHA-1#errwerwsd#, we obtain:
Applying hashString again we obtain HASH-SHA-1#wewewew#
It will be seen, therefore, that an embedded sub-description, for example description extends {class “myTaskImpl.class”;} can be replaced by its hash value such that, when the description as a whole is hashed the same hash result will be provided. For example by replacing description extends {class “myTaskImpl.class”;} with description extends HASH-SHA-1#sdsdasdasd# the same result is returned whilst allowing validation of the “top level” description.
Turning now to
It will be seen that upon validation of this the same hash result will be changed following addition of the attribute as would have been returned for listing 1.
In order subsequently to allow authentication by a third party validating entity, the modifying entity i.e. the scheduler additionally computes a signature in step 502 with a hash of the canonical representation of the new value assigned to the changeable part and its private key attaching any other security credentials required to validate the policy associated with the sub-description. That signature and credentials are attached to the node at step 504 for validation against the policy by a third party entity.
At a validating entity, it is necessary to check that the immutable parts of the description have not been changed, and were created by an authorized party (the originator) and that the changeable parts were changed by an authorized party (the scheduler) and in an authorized manner. It will be noted that although, in the embodiment described here, the validating party is treated as a party executing tasks within the description for example as allocated by the scheduler, any remote third party, for example including the originator itself, can perform validations steps as appropriate.
Referring to
At step 602 the changeable parts are validated according to the associated sub-description security policy, in particular checking that the signature added by a modifying party is verifiable against the specified policy:
In addition to verifying the identity of the modifying party, additional checks can be carried out dependent on the sub-description security policy such as ensuring that the type of attribute added to the changeable part is correct and so forth as appropriate. It will further be noted that, dependent on the sub-description policy, the scheduler may itself be able to modify the changeable part recursively such that, in its modified form, it too includes unchangeable and changeable parts, for example, in the case where the scheduler is able to include some of the required modifications but must delegate other of the modifications to another entity such as a further scheduler. In particular the scheduler can introduce attributes with the SIGNED property in the changeable part and define different policies for them. In that case, of course, the task processor or processors will validate the changeable part recursively in a corresponding manner.
The manner in which the steps described above are carried out in relation to the specific example described with reference to
As a result a scheduler is able to annotate location information for task (“location extends SIGNED{ }” but cannot modify other parts of task such as “description extends{ . . . ”. In addition the originator has identified the scheduler as the party permitted to make those changes by including the “(<scheduler_public_key>)” as part of the security policy referred by attribute “subDescriptionPolicy”. As a result the scheduler can modify the sub-description and attach its own signature as we saw in Listing 8
Following modification it will be seen that the host name and port number for specifying the location are included together with the signature attached by the scheduler.
A third party deploying the component, for example xyz.com at port number 3080, validates the top description using the global security policy as described above and this will not be affected by the changes to “location extends”. A recursive “validate” call is then carried out for the “location” sub-description using the “Scheduler_public_key” as a requirement for the signature validation. As long a match is identified then the changes of the modifying party can be authenticated, however if the scheduler modifies any material outside “location” the top level signature will no longer validate. In addition a new top level signature cannot be created by the scheduler as this can be excluded by the global security policy.
It will be appreciated that the manner in which the security policies are communicated and implemented, and the manner in which the hashing and signing processes are carried out can be adopted using any appropriate known technique. In addition any appropriate language extension or modification can be implemented for signing and changeable parts yet further as an alternative to the Smart Frog language any appropriate language can be introduced. In the context of the Smart Frog language the “standard” transformation phase is associated with a compellation of a description, such as type and link resolution, function evaluation and so forth are performed in the conventional manner as will be understood by the skilled reader such that specific description in is not required. The data structure can take any desired form and may be non-hierarchical, and the content can be validated using any appropriate hashing or concatenation or other technique.
It will be appreciated that the distributed computing system and the individual entities thereof can be any appropriate platform or system and any implementation, task or process and are not limited to the originator/scheduler/executor example set out above. For example referring to
As a result of the arrangement described herein various advantages are achieved. By providing explicit support in the description language to control canonicalisation, and combining this with a recursive signing strategy, constrained and safe modifications to sub-descriptions are allowed. Furthermore signed descriptions can be compressed by replacing non-relevant sub-descriptions by their hashes without affecting the signatures of the enclosing descriptions or requiring resignature of the closing descriptions. Furthermore it can be ensured that modifications are carried out by entities specified by the originator facilitating the development of highly decoupled systems, where partially trusted agents can take autonomous decisions on certain aspects of the system without compromising overall security.
| Number | Date | Country | Kind |
|---|---|---|---|
| 0522100.7 | Oct 2005 | GB | national |
