U.S. patent application number 12/238917 was filed with the patent office on 2010-04-01 for storing composite services on untrusted hosts.
This patent application is currently assigned to Microsoft Corporation. Invention is credited to Laurent Bussard, Joris Claessens, Christian Geuer-Pollmann, Anna Nano, Ulrich Pinsdorf.
Application Number | 20100082989 12/238917 |
Document ID | / |
Family ID | 41720053 |
Filed Date | 2010-04-01 |
United States Patent
Application |
20100082989 |
Kind Code |
A1 |
Bussard; Laurent ; et
al. |
April 1, 2010 |
Storing Composite Services on Untrusted Hosts
Abstract
A method of storing a composite service on an untrusted host
without enabling the untrusted host to access resources called by
the composite service is described. In an embodiment, the delegator
provides a delegatee with credentials to enable verification of the
composite service and to enable access to the resources. The
credential which is provided to enable access to the resources may
be a credential which can be used to decrypt access credentials for
each of the resources. These access credentials are stored in
encrypted form in a credential store. The delegatee downloads the
composite service and the encrypted access credentials and executes
the composite service once it has been verified.
Inventors: |
Bussard; Laurent; (Aachen,
DE) ; Pinsdorf; Ulrich; (Herzogenrath, DE) ;
Nano; Anna; (Nordrhein-Westfalen, DE) ; Claessens;
Joris; (Heverlee, BE) ; Geuer-Pollmann;
Christian; (Dusseldorf, DE) |
Correspondence
Address: |
LEE & HAYES, PLLC
601 W. RIVERSIDE AVENUE, SUITE 1400
SPOKANE
WA
99201
US
|
Assignee: |
Microsoft Corporation
Redmond
WA
|
Family ID: |
41720053 |
Appl. No.: |
12/238917 |
Filed: |
September 26, 2008 |
Current U.S.
Class: |
713/176 ;
380/278; 713/168; 726/8 |
Current CPC
Class: |
G06F 21/6218
20130101 |
Class at
Publication: |
713/176 ; 726/8;
713/168; 380/278 |
International
Class: |
H04L 9/32 20060101
H04L009/32; G06F 21/00 20060101 G06F021/00; H04L 9/08 20060101
H04L009/08 |
Claims
1. A method comprising: downloading a piece of software code from a
host, the piece of software code being associated with a user and
being arranged to access a plurality of resources when executed;
verifying the piece of software code using a credential received
from the user; and executing the piece of software code locally,
the execution comprising accessing the plurality of resources using
at least one credential received from the user.
2. A method according to claim 1, wherein executing the piece of
software locally comprises: retrieving encrypted service
credentials from a host; decrypting the encrypted service
credentials using at least one credential received from the user;
and accessing the plurality of resources using the decrypted
service credentials.
3. A method according to claim 2, further comprising, prior to
retrieving the encrypted service credentials from a host:
generating a parameter using a one-way function and a key; and
authenticating with the host using said parameter.
4. A method according to claim 2, wherein accessing the plurality
of resources comprises: retrieving encrypted data and an encrypted
access key from each of the plurality of resources using the
decrypted service credentials; decrypting the access keys; and
decrypting the data using the access keys.
5. A method according to claim 1, wherein said host is an untrusted
host.
6. A method according to claim 1, further comprising, prior to
executing the piece of software locally: decrypting the piece of
software downloaded from the host using a credential received from
the user.
7. A method according to claim 1, wherein the piece of software
code comprises an encrypted part and an unencrypted part and
wherein executing the piece of software code locally comprises:
executing the unencrypted part, wherein said unencrypted part is
arranged, on execution, to decrypt the encrypted part and execute
the encrypted part, and wherein said encrypted part is arranged, on
execution, to access the plurality of resources using at least one
credential received from the user.
8. A method according to claim 1, wherein verifying the piece of
software code using a credential received from the user comprises
one of: verifying a signature associated with the piece of software
code using a credential received from the user; and verifying a
parameter using a credential received from the user, the parameter
having been generated from the piece of software code using a
one-way function.
9. A method according to claim 1, further comprising: receiving at
least one credential from the user.
10. A method comprising: storing a signed piece of software code on
an untrusted host, the piece of software being arranged to access a
plurality of resources when executed; sending a message to an
entity comprising credentials to enable verification of a signature
associated with the piece of software code and to enable the piece
of software code to access the plurality of resources when executed
locally by the entity.
11. A method according to claim 10, further comprising: generating
a service credential for each of the plurality of resources for the
entity; and updating access rights for each of the plurality of
resources to provide access using the service credential for each
of the plurality of resources.
12. A method according to claim 11, further comprising: encrypting
the service credentials; and storing the encrypted service
credentials on a host, and wherein said credential to enable the
piece of software to access the plurality of resources when
executed locally by the entity comprises a credential to enable
decryption of the encrypted service credentials.
13. A method according to claim 12, further comprising: generating
an authentication parameter for said entity using a one-way
function and a secret known by the entity; and providing the
authentication parameter to said host.
14. A method according to claim 12, wherein encrypting the service
credentials comprises: generating a decryption key using a secret
known by the entity; and encrypting the service credentials such
that they can be decrypted using the decryption key.
15. A method according to claim 10, further comprising: signing the
piece of software code and any associated configuration data.
16. A method according to claim 10, further comprising: encrypting
at least a part of the piece of software code and any associated
configuration data, and wherein said message further comprises
credentials to enable decryption of said at least a part of the
piece of software code and any associated configuration data.
17. A method according to claim 10, further comprising: generating
an access control key for a data element stored at one of the
plurality of resources and required by the piece of software code;
encrypting the data element using the access control key;
encrypting the access control key; and storing the encrypted data
element and the encrypted access control key at said one of the
plurality of resources.
18. A delegation system comprising: a first computing-based device
comprising software arranged to download a composite service and an
associated signature from an untrusted host, verify the signature
using a credential received by a first user from a user associated
with the composite service and execute the composite service, and
wherein the composite service comprises computer executable
instructions arranged, on execution, to cause the first
computing-based device to access data from a plurality of sources
using at least one credential received by said first user from said
user associated with the composite service.
19. A delegation system according to claim 18, further comprising:
a second computing-based device comprising software arranged to
store said composite service and said associated signature on said
untrusted host, to generate an encrypted service credential for
each of said plurality of sources, to store said encrypted service
credentials in a credential store and to send credentials to said
first user to enable verification of said composite service and
decryption of said service credentials.
20. A delegation system according to claim 19, wherein said second
computing-based device further comprises software arranged to
update access rights for each of the plurality of sources to enable
access using the service credential for each of the plurality of
sources.
Description
BACKGROUND
[0001] There are currently two ways in which a user can access
software to handle data: the user can either use applications which
are executed in their local computer or they can use remote
services, where the application runs on a remote computer. Use of a
remote service does not require the user to obtain special
software, however, locally run applications are generally
considered to provide advantages in security and trust.
[0002] Where a remote service is used, the service may be a
composite service. A composite service is a service which is built
upon resources (such as other services) such that when the
composite service runs, it calls those resources. Examples of
resources include a web service, a web page, a file sharing
service, a database, a data object in a storage system etc. If
access to the resources (e.g. to the other services) is protected
in some manner, the composite service requires access rights to
enable the composite service to call those resources.
[0003] The embodiments described below are not limited to
implementations which solve any or all of the disadvantages of
known methods of service provision.
SUMMARY
[0004] The following presents a simplified summary of the
disclosure in order to provide a basic understanding to the reader.
This summary is not an extensive overview of the disclosure and it
does not identify key/critical elements of the invention or
delineate the scope of the invention. Its sole purpose is to
present some concepts disclosed herein in a simplified form as a
prelude to the more detailed description that is presented
later.
[0005] A method of storing a composite service on an untrusted host
without enabling the untrusted host to access resources called by
the composite service is described. In an embodiment, the delegator
provides a delegatee with credentials to enable verification of the
composite service and to enable access to the resources. The
credential which is provided to enable access to the resources may
be a credential which can be used to decrypt access credentials for
each of the resources. These access credentials are stored in
encrypted form in a credential store. The delegatee downloads the
composite service and the encrypted access credentials and executes
the composite service once it has been verified.
[0006] Many of the attendant features will be more readily
appreciated as the same becomes better understood by reference to
the following detailed description considered in connection with
the accompanying drawings.
DESCRIPTION OF THE DRAWINGS
[0007] The present description will be better understood from the
following detailed description read in light of the accompanying
drawings, wherein:
[0008] FIG. 1 is a schematic diagram of a delegation system;
[0009] FIG. 2 shows a flow diagram of an example method of
operation of a delegation system;
[0010] FIGS. 3-8 show diagrams of an example method of
delegation;
[0011] FIGS. 9-11 show diagrams of further example methods of
delegation in which the composite service is encrypted;
[0012] FIGS. 12-13 show diagrams of further example methods of
delegation which have increased resilience to dictionary
attacks;
[0013] FIGS. 14-16 show diagrams of further example methods of
delegation in which the services are untrusted;
[0014] FIGS. 17-18 show an example implementation of a method of
delegation;
[0015] FIG. 19 shows two examples of a schematic architecture for
use in the methods described herein; and
[0016] FIG. 20 illustrates an exemplary computing-based device in
which embodiments of the delegation methods described herein may be
implemented.
[0017] Like reference numerals are used to designate like parts in
the accompanying drawings.
DETAILED DESCRIPTION
[0018] The detailed description provided below in connection with
the appended drawings is intended as a description of the present
examples and is not intended to represent the only forms in which
the present example may be constructed or utilized. The description
sets forth the functions of the example and the sequence of steps
for constructing and operating the example. However, the same or
equivalent functions and sequences may be accomplished by different
examples.
[0019] FIG. 1 is a schematic diagram of a delegation system 100
which comprises a delegator 101, a delegatee 102, a host 103 and a
resource (or service) 104. In such a delegation system, the
resource 104 is `owned` by the delegator 101 such that the
delegator 101 can grant access rights to the resource (and does not
necessarily host the resource), e.g. to the delegatee 102. In the
example of an online picture service that hosts users' digital
photo collections, a user does not own the online picture service
as such, but does own the user's own photo collection at this
service. The delegatee 102 is a user of a composite service or
mash-up 105 stored on the host 103 and which calls on the resource
104. The host 103 may be an untrusted host, e.g. a host which is
unknown and which may not be trusted not to collect the data
provided by the resource, or a distrusted host, e.g. a host which
is not trusted.
[0020] The term `mash-up` is used herein to refer to a client-side
composite service which may make use of multiple resources. In an
example, the mash-up may be an application (e.g. a web application)
that combines data from more than one source into a single logical
application (which comprises distributed resources). The sources of
data may be web services or other resources. Composite services
(including mash-ups) may make use of application programming
interfaces (APIs) published by many service providers and which may
be based on web standards. These APIs allow the functionality of
services to be used. Depending on the technology used for creating
composite services, they can be executed in the browser on the
client-side or on the server-side. Composite services may be used
to access services provided by other entities (e.g. other
enterprises, which may provide the resources for free or may charge
for their use) or may be used within enterprises. Composite
services (and mash-ups) are used herein by way of example and the
methods and systems described herein may be used for any mobile
software code which may be downloaded and executed on the client
side (e.g. executables).
[0021] Resources, such as resource 104, provide services which are
valuable to a user (e.g. to the delegator) and often use mechanisms
to enforce access control, e.g. for security and privacy reasons
including confidentiality (e.g. pictures, medical records) and
integrity. The delegator may be defined as an authorized entity
that manages the access control of a resource in a way that another
entity, (e.g. the delegatee 102), can use the resource in a way
that was previously explicitly or implicitly agreed between the
authorized entity (e.g. delegator 101) and the other entity (e.g.
delegatee 102). A delegatee may be defined as an entity that
requests access (or is granted access) to a resource (e.g. resource
104) from a delegator (e.g. delegator 101) which is authorized to
administrate the access control mechanism of that resource. The
process of delegation refers to the fact that the delegator
authorizes the delegatee to access the particular resource. There
are many ways in which the delegation may be implemented. The
delegator may for example grant access by configuring the access
control mechanism of the resource accordingly and providing
information to the delegatee how to invoke the service. This
management operation could, for example, involve the creation of a
new credential, uploading an X.509 certificate of the delegatee to
an access control list, or modifying an existing security policy.
Any suitable mechanism may be used to grant access to the resource.
Delegation is separation from impersonation, i.e. where an entity
temporarily acts as another entity in order to gain access to a
resource.
[0022] The operation of the system 100 shown in FIG. 1 can be
described with reference to FIG. 2, which shows a flow diagram of
an example method of operation of a delegation system. The arrows
between elements in FIG. 1 are labeled with reference numerals
which correspond to method blocks shown in FIG. 2. Although FIG. 1
shows double and single ended arrows, it will be appreciated that
communication between elements may be bidirectional or
unidirectional and there may be additional communication flow which
is not shown in FIG. 1. The same also applies to subsequent
FIGS.
[0023] As shown in FIGS. 1 and 2, a signed composite service (such
as a mash-up) 105 is stored on a host 103 (block 201). This signed
composite service 105 may be placed on the host 103 by the
delegator 101 or by another entity (e.g. a software vendor, as
described in more detail below). The delegator 101 provides
credentials to the delegatee 102 (block 202) and these credentials
comprise one or more credentials to enable the delegatee 102 to
verify the signature of the composite service and, where required,
to access the resource 104 (e.g. one or more credentials to enable
decryption of service credentials, as described in more detail
below). In many examples, the credentials provided to the delegatee
(in block 202) comprise a single credential. The delegatee 102
downloads the signed composite service 105 from the host 103 (block
203), verifies the signature of the composite service (block 204)
using the credential(s) received from the delegator (in block 202)
and if the verification (in block 204) confirms that the composite
service is the expected composite service and has not been tampered
with, the delegatee executes the composite service (block 205). In
order to execute the composite service, the composite service code
may run temporarily, e.g. inside a browser or browser plug-in
running on the computer. In other examples, the composite service
code may be installed on the computer to which it is downloaded.
When the composite service is executed (in block 205), the resource
104 is accessed. It will be appreciated that the composite service
may access more than one resource and therefore the system 100 may
comprise a plurality of resources. The composite service may also
access any resource zero, one or more times.
[0024] Where the delegatee 102 requires credentials to access the
resource 104, these may be provided to the delegatee directly by
the delegator (in block 202). Alternatively, encrypted service
credentials may be stored on a host (block 206) and the credentials
provided to the delegatee (in block 202) may include information to
enable these service credentials to be decrypted. The composite
service and the encrypted service credentials may be stored on the
same host or may be stored on different hosts. In a further
example, service credentials may be stored in unencrypted form on a
trusted host. The host on which the credentials are stored is
referred to as a credential store. The address of the credential
store may be provided to the delegatee by the delegator (e.g. in
block 202) or may be stored along with the composite service (e.g.
as configuration data).
[0025] Where encrypted service credentials are stored on a host (in
block 206), the execution of the composite service (in block 205)
may comprise: retrieving the encrypted service credentials from the
host on which they are stored (block 251), decrypting the service
credentials (block 252), e.g. using the credentials provided by the
delegator (in block 202), and accessing the resource using the
decrypted service credentials (block 253). Alternatively, the steps
of retrieving the encrypted service credentials (block 251) and
decrypting these credentials (block 252) may be performed
separately (e.g. prior) to the execution of the composite service
(in block 205).
[0026] There are many applications for the system and method
described above. In an example, Bob is a traveling salesman. He is
leaving for a business trip where he has to travel long distances
by car. He has been having health issues and his heart is weak. His
friend Alice is concerned about him leaving and wants to be able to
locate and assist him in case of problems.
[0027] Bob is registered with a medical record service (a resource)
where his health data is stored. He is further registered with a
location service (another resource) that provides his real time
location. In this example scenario, Bob's physical health status
and his location are available through these services, e.g. as
provided through a heart monitor device with cell phone connection
and a GPS-based anti-theft system in his car.
[0028] Bob does not want to hand out his credentials for the two
services to Alice, because he wants to delegate a subset of his
privileges. He simply wants Alice to know where he is and what his
physical condition is. Therefore, Bob (as delegator) creates (or
gets from a third party) a composite service that displays a
combination of his medical and location information obtained from
the two services. Alice (as delegatee) can use this composite
service to view Bob's medical and location information.
[0029] Alice may access the composite service frequently and from
different locations. Bob stored the composite service at a web host
on the Internet. Alice knows the web address of this host and can
download the composite service code and execute it locally on
whatever computer she is using (and which has internet access and
the ability to execute the downloaded code). The composite service
code needs not necessarily to be installed on each computer; it is
more likely that the mash-up code runs temporarily inside the
browser.
[0030] Bob stored the composite service code at a web host that is
operated by Eve. Bob trusts Eve to behave orderly, which means that
Eve runs the host properly and guarantees delivery of services.
However, Bob knows that Eve is honest but curious and may try to
collect Bob's data. Eve may therefore be considered to be an
untrusted host. The method described herein (and shown in FIG. 2)
enables Alice, but not Eve, to access the resources behind the
composite service, i.e. the health and location of Bob.
Furthermore, the method enables Bob to provide only a subset of
rights to Alice to enable her to access his underlying personal
services (e.g. she may only have access to a few aspects of his
medical information) and he can revoke these access rights granted
to Alice at any time (e.g. when he returns from the business
trip).
[0031] The composite service is signed and the service credentials
are encrypted. Alice has (or gets from Bob, e.g. in block 202) the
credentials to verify the composite service signature and decrypt
the service credentials. When Alice wants to invoke the composite
service, which will in turn invoke the underlying services, she
downloads everything from Eve (e.g. in block 203) and executes the
composite service code (e.g. in block 205). This method combines
the trust advantages of a local running application with the
availability advantages of an online service. Bob keeps control
over who can access the composite service and has the guarantee
that Eve hosting the composite service cannot access the underlying
services.
[0032] Different forms of cryptography may be used in the methods
described herein and the key material (e.g. as used in encryption
of credentials etc) may comprise symmetric or asymmetric keys. In
example implementations, different types of credentials including
asymmetric key pairs, symmetric keys, and username/password may be
used. For the purposes of explanation only, the following
description refers to the use of public keys (also referred as
security tokens, K.sub.P) and private keys (also referred as proof
tokens, K.sub.S). In variations or extensions of the methods
described, the public key and the private key may be the same
symmetric key or may be mapped to other cryptographic schemes such
as username/password, anonymous credentials, or identity-based
encryption.
[0033] The methods described herein provide the improved security
and trust as may be typically provided when an application is run
locally. Additionally the methods provide improved availability,
i.e. the ability to access a service or application from anywhere.
The methods enable a composite service stored on a host to access
resources (which may be sensitive in nature) which are protected by
access control without the hosting party gaining access.
[0034] A more detailed example of a method of delegation can be
described with reference to FIGS. 3-8. For the purposes of the
following explanation only, the following characters are used:
[0035] Bob--delegator, who owns a composite service that summarizes
his private information [0036] Alice--delegatee, a friend of Bob's
who is to access Bob's composite service [0037] Eve--host that
stores Bob's composite service [0038] Mallory--host that Bob uses
to store credential data for Alice [0039] Carol--operates a
resource (e.g. a service) that provides data for Bob's composite
service [0040] Dave--operates a resource (e.g. another service)
that provides data for Bob's composite service It will be
appreciated that these characters are only used to assist in
understanding the methods described. As described above, the same
host may be used to store both the composite service and the
credential data. One or both hosts may be untrusted. For the
purposes of the following explanation, it is assumed that the
delegator Bob wants to grant access to his composite service
(M.sub.1) and related resources (S.sub.1 and S.sub.2) to delegatee
Alice. For the purposes of the following description, the resources
are services, although it will be understood that this is by way of
example only and other resources may alternatively be used.
[0041] The creation of the composite service itself is not
described herein and the composite service may be implemented in
any suitable technology. For example, in a web browser the
composite service could be implemented with Microsoft.RTM.
Silverlight.TM. or Java Applet. The methods described herein may
also be applied to other forms of downloadable code such as
Microsoft.RTM. Windows Vista gadgets, or Java Web Start.
[0042] In the following description, the following nomenclature is
used: [0043] K.sub.P(B)--public key of delegator (Bob) [0044]
K.sub.S(B)--private key of delegator (Bob) [0045]
K.sub.P(A)--public key of delegatee (Alice) [0046]
K.sub.S(A)--private key of delegatee (Alice) [0047]
M.sub.1--composite service (of Bob) and all necessary data to run
it, e.g. configuration data [0048] K.sub.P(A, M1), K.sub.S(A,
M1)--credential (of Alice) to access composite service M.sub.1
(provided by Bob) [0049] S.sub.1--service owned by Bob and accessed
during the execution of M.sub.1 [0050] K.sub.P(A, S1), K.sub.S(A,
S1)--credential of delegatee Alice to access service S.sub.1
(provided by Bob) [0051] S.sub.2--another service owned by Bob and
accessed by M.sub.1 [0052] K.sub.P(A, S2), K.sub.S(A,
S2)--credential of delegatee Alice to access service S.sub.2
(provided by Bob) [0053] Addr.sub.S1--service address of S.sub.1
[0054] Addr.sub.S2--service address of S.sub.2 [0055] E.sub.KP(A,
M1)(Addr.sub.S1, K.sub.S(A, S1))--Service address of S1 and
credentials to access it encrypted with Alice's public key for the
composite service [0056] E.sub.KP(A, M1)(Addr.sub.S2, K.sub.S(A,
S2))--Service address of S.sub.2 and credentials to access it
encrypted with Alice's public key for the composite service [0057]
S.sub.KS(B)(M.sub.1)--Signature of M.sub.1 by Bob [0058]
Addr.sub.E, M1--Address of composite service M.sub.1 at Eve's web
host [0059] Addr.sub.M, M1--Address of credentials for M.sub.1
(e.g. the encrypted service credentials) at Mallory's web host
[0060] The method may be considered in three phases: delegation (as
shown in FIGS. 3-5), access (as shown in FIGS. 6-7) and revocation
(as shown in FIG. 8). In the delegation phase Bob sets up
everything so that Alice can access his composite service and in
the access phase Alice executes the composite service. In the
revocation phase, which is optional, Bob revokes Alice's rights on
his composite service.
[0061] FIG. 3 shows a schematic diagram of the situation at the
beginning of the delegation phase. The diagram shows the delegator,
Bob, 301 who is equipped with his own key pair 302, consisting of a
public and a private key. Delegatee, Alice, 303, also has her own
key pair 304 and in this example, Bob knows Alice's public key,
K.sub.P(A) 305 (e.g. for use in block 408 as described below). Each
of the services 306, 307 which provide data for Bob's composite
service are shown having an access control list (ACL) 308, 309
which indicates that Bob may administer the list after
authenticating with his private key. Other access control
mechanisms may alternatively be used.
[0062] The delegation process is shown in the example flow diagram
of FIG. 4 and in FIG. 5 which shows a schematic diagram of the
situation at the end of the delegation phase. Arrows in FIG. 5 are
labeled with reference numerals that correspond to the method
blocks shown in FIG. 4. Bob decides to let delegatee Alice access
his composite service. Bob is authorized to administrate each
service behind the composite service, i.e. S.sub.1 operated by
Carol and S.sub.2 operated by Dave. In this example, Bob may not
want to share his credentials for S.sub.1 and S.sub.2 with Alice,
because that would allow Alice to impersonate Bob. Hence, Bob
creates two credentials (block 401), e.g. key pairs, for Alice, one
for each service. The keys for Alice to use for service S.sub.1 are
public key K.sub.P(A, S1) and private key K.sub.S(A, S1); the keys
for Alice to use for service S.sub.2 are public key K.sub.P(A, S2)
and private key K.sub.S(A, S2).
[0063] Bob modifies the access rights (e.g. an Access Control List)
of both services S.sub.1 and S.sub.2 to grant appropriate rights to
the owner of the private key K.sub.S(A, S1) and K.sub.S(A, S2)
(block 402). The granted permissions correspond to the
requirements/expectations of Bob's composite service M.sub.1. For
instance, if the composite service needs write access to service
S1, then Bob grants write access to the owner of K.sub.S(A, S1)
(e.g. Alice in this example). Any access control mechanism may be
used and the granularity of access which can be granted by the
delegator (Bob) may be dependent upon the actual access control
mechanism of the particular service.
[0064] Bob creates a specific credential for Alice to use the
composite service M.sub.1 (block 403) and this credential may be
referred to as K.sub.P(A, M1) and K.sub.S(A, M1). This key material
is used to encrypt the credentials necessary to access the
services. Bob encrypts the credentials K.sub.S(A, S1) and
K.sub.S(A, S2) with K.sub.P(A, M1) (block 404) so that only Alice,
who will get the private key K.sub.S(A, M1) from Bob, can decrypt
the credentials necessary to access S.sub.1 and S.sub.2. The
encrypted credentials for S.sub.1 may be referred to as E.sub.KP(A,
M1)(Addr.sub.S1, K.sub.S(A, S1)) and the encrypted credentials for
S.sub.2 as E.sub.KP(A, M1)(Addr.sub.S2, K.sub.S(A, S2)). Each
encrypted container holds two pieces of information: the service
address (Addr.sub.S1 or Addr.sub.S2) and the credential which is
necessary to access the service (K.sub.S(A, S1) or K.sub.S(A,
S2)).
[0065] The composite service and any meta-data that is necessary to
run it (e.g. configuration data) are referred to as M.sub.1. Bob
signs M.sub.1 (block 405) to make sure that Eve cannot replace it
with a modified version. Bob uses his private key K.sub.S(B) to
sign the code and the result may be referred to as
S.sub.KS(B)(M.sub.1).
[0066] So far, Bob has computed everything on his local machine and
has not shared any information with any other person, including
Alice. Now, Bob uploads the composite service M.sub.1 and its
signature S.sub.KS(B)(M.sub.1) to the distrusted web host 501
operated by Eve (block 406). The address of the stored composite
service may be referred to as Addr.sub.E,M1. Additionally Bob
stores the encrypted credentials E.sub.KP(A, M1)(Addr.sub.S1,
K.sub.S(A, S1)) and E.sub.KP(A, M1)(Addr.sub.S2, K.sub.S(A, S2)) at
a distrusted credential store 502 (block 407). The address of the
credentials at the credential store may be referred to as
Addr.sub.M,M1. The credential store 502 may be some publicly
accessibly web space which Bob uses to place the credentials for
Alice. In this particular example, it is assumed that Mallory
operates this credential store. Like Eve, Mallory may not be
trustworthy. In some examples, the credential store 502 and the
host 501 may be combined or may cooperate. This does not affect the
operation of the methods described herein.
[0067] Finally, Bob gives Alice the information that she needs to
execute the composite service M.sub.1 and thus invoke the services
S.sub.1 and S.sub.2 (block 408). The information he provides to
Alice are the address of the composite service code
(Addr.sub.E,M1), the credential to verify the signature
(K.sub.P(B)), and Alice's decryption credential K.sub.S(A, M1). In
another example, Bob may provide other information in addition to,
or instead of, that described. For example, Bob may give Alice the
service credentials rather than storing them in the credential
store. Bob may send the information (in block 408) to Alice out of
band. Depending on the scenario and on the type of credential, this
can, for instance, be done by e-mail or verbally. Bob could, for
example, obtain Alice's public key K.sub.P(A) to establish a secure
channel for key exchange, e.g. encrypted e-mails. Another option
would be the use of identity based encryption (IBE) for the same
purpose. In this case, the e-mail address of Alice would directly
be used as public key in Identity Based Encryption. Assuming that
only Alice can get the corresponding private key from the chosen
Private Key Generator, only Alice can decrypt the credential
K.sub.S(A, M1). A further option would be to use another secure
channel (e.g. phone call, memory stick etc).
[0068] It will be appreciated that although the delegation process
shown in the example flow diagram of FIG. 4 includes method blocks
in which the composite service (and any meta data) is signed (block
405) and the signed data and signature is uploaded to a host (block
406), these method blocks may be omitted if the method is repeated.
For example, if Bob wished to delegate access to another individual
(e.g. Fred), the delegation process may omit blocks 405 and
406.
[0069] The access process is shown in the example flow diagram of
FIG. 6 and in the schematic diagram shown in FIG. 7. Arrows in FIG.
7 are labeled with reference numerals that correspond to the method
blocks shown in FIG. 6. At the end of the delegation phase Alice
has all information to which is required to access Bob's composite
service. In the access phase she uses the address Addr.sub.E,M1 to
download the code of the client side composite service M.sub.1 plus
the associated signature S.sub.KS(B)(M.sub.1) (block 601). Alice
uses Bob's public key K.sub.P(B) to verify the signature on M.sub.1
(block 602). The signature lets Alice verify that she has
downloaded the right piece of code prior to execution of the code
itself and/or prior to any credential being handed to the composite
service. This prevents Eve from mounting a phishing attack to steal
K.sub.S(A, M1), e.g. by replacing M.sub.1. The verification of the
composite service signature (in block 602) may, for example, be
performed by the web browser running on Alice's local machine or by
a plug-in installed in this browser.
[0070] When the signature is verified by Alice, the composite
service is started (block 603), i.e. the downloaded piece of code
is executed locally on Alice's machine. For instance, M.sub.1 could
be a piece of code (e.g. Microsoft.RTM. Silverlight.TM., Java
applet etc) which is executed in Alice's web browser. Alternatively
M.sub.1 could be an application that Alice installs on her machine
if appropriate sandboxing mechanisms are available. The composite
service retrieves the encrypted credentials from Mallory's
credential store (block 604). The composite service knows the
address of the credential Addr.sub.M,M1 because it is part of
M.sub.1's configuration data (or meta-data). In this example, the
encrypted credentials are: E.sub.KP(A, M1)(Addr.sub.S1, K.sub.S(A,
S1)) and E.sub.KP(A,M1)(Addr.sub.S2, K.sub.S(A, S2)). The
credential K.sub.S(A, M1) which is required to decrypt the
credentials (in block 605) is provided to the composite service by
Alice. In course of its execution, the composite service M.sub.1
accesses S.sub.1 and S.sub.2 with appropriate credentials
K.sub.S(A, S1) and K.sub.S(A, S2) (block 606).
[0071] The revocation process is shown in the example flow diagram
of FIG. 8. In order for Bob to revoke Alice's access rights, he
modifies the access control lists (or other access rights) of
S.sub.1 and S.sub.2 (block 801). In addition, he may remove the
credentials from Mallory's credential store (block 802) and/or the
signed composite service from Eve's composite service store (block
803). Just removing the composite service and credentials (blocks
802-803) does not guarantee that Alice's access rights have been
revoked because Alice could hold a copy of the composite service
code and the encrypted credentials. To improve the security of the
methods described herein, a fresh key pair for each service
(K.sub.P(A, S1), K.sub.S(A, S1), K.sub.P(A, S2), K.sub.S(A, S2))
may be generated for every act of delegation (in block 401), so
that stored keys become useless.
[0072] As described above, the revocation phase is optional as it
may not be necessary to revoke rights once granted. In another
example implementation, rights may be granted for a defined period
of time (in the delegation phase) such that they expire and
therefore a specific revocation act is not required. The ability to
set a lifetime of the access rights may depend on the access
control complexity for each resource. Where sophisticated access
control mechanisms are used it may be possible to set access rights
for a defined period, for a particular number of access attempts
etc. In further examples, the composite service may expire.
[0073] In the above examples, a different credential or key is used
for verifying the composite service and decrypting the service
credentials used by the composite service. In other examples, the
same credential may be used for both verification of the composite
service and decryption of the service credentials, e.g. the
delegator's private key (K.sub.P(B)).
[0074] In a variation on the methods described above, the composite
service may be created by a third party rather than by the
delegator (e.g. by someone other than Bob). In such a situation,
the composite service may, for example, be created by a software
vendor and be purchased by the delegator (e.g. by Bob). In this
case the composite service may be signed by the software vendor.
This vendor signature may be associated with the composite service
and retrieved by the delegatee. When the delegatee does not know
the vendor, the public key of the vendor may be provided to the
delegatee (e.g. in block 408). When the delegatee already trusts
the software vendor then the delegatee knows that the delegator
purchased the client-side composite service code from a trustworthy
source. In another example, the composite service may be signed by
the delegator in addition to the software vendor and in this case
both the public key of the vendor (or the signature of the vendor)
and the public key of the delegator may be provided to the
delegatee (in block 408) in order that the signatures can be
verified (in block 602).
[0075] In many examples, the composite service itself may not be
particularly sensitive and in the examples described above, the
composite service is not encrypted before it is uploaded to the
host (in block 406). In another variation of the methods described
above, however, the composite service may be encrypted. This may,
for example, be because the composite service is sensitive (e.g. it
contains a new or secret algorithm) or because the delegator does
not want to disclose what services he subscribes to. This variation
is shown in FIGS. 9 and 10. In order to address this scenario, Bob
encrypts the composite service M.sub.1 (code and configuration
data) before storing it on Eve's host (blocks 901-902). A new key
K.sub.M1 may be used for the encryption (in block 901) and this key
is made available to users of the composite service. For instance,
Alice may be provided with E.sub.KP(A,M1)(K.sub.M1) (e.g. in block
903) to decrypt the encrypted composite service,
E.sub.1=E.sub.KM1(M.sub.1) before executing the composite service.
In other examples they key could be stored in the credential store.
The method (shown in FIG. 9) introduces an additional step for
Alice: before she can run the composite service she decrypts it
(block 1001).
[0076] Although the methods shown in FIGS. 9 and 10 and described
above involve the generation of a new key to encrypt the composite
service, in other examples, an existing key (e.g. Bob's public key)
may be used instead of a new encryption key.
[0077] In a further variation of that described above, the
encrypted composite service (e.g. as generated in block 901) may
comprise two parts: an unencrypted code part M.sub.11 and an
encrypted code part E.sub.12=E.sub.KM1(M.sub.12) that can be
decrypted by Alice with K.sub.S(A,M1) as described above. FIG. 11
shows a flow diagram of an example of the access phase in such an
example. The unencrypted part M.sub.11 can be executed first
without any prior decryption (block 1101). The unencrypted part
contains the decryption algorithm for the encrypted part and a
simple user-interface which allows Alice to enter her decryption
key K.sub.S(A,M1). After Alice has provided this key, the
unencrypted part M.sub.11 uses it to decrypt E.sub.12 (block 1102)
and executes the decrypted result M.sub.12 (block 1103). All
confidential aspects of the composite service may be part of
M.sub.12. This variation does not require an extra key as Alice
already receives the decryption key K.sub.S(A,M1) (in block 408).
In this example, the signature on the composite service is applied
on M.sub.11 and E.sub.12. For instance S.sub.KS(B)(M.sub.1) would
be replaced by S.sub.KS(B)(M.sub.11, E.sub.KM1(M.sub.12)). This
ensures that neither part has been tampered with
[0078] In the examples described above, the delegator and the
delegatee are different users, e.g. Bob delegates to Alice. The
methods may, however, also be used for self-delegation, e.g. for
Bob to delegate to himself. This may be used to enable the
delegator (e.g. Bob) to access his own composite service from
anywhere, e.g. from his computer at home and from a public Internet
Cafe. In this case, Bob delegates access to himself, following the
procedure above. Therefore, a new credential is created for Bob
(K.sub.P(B,M1) and K.sub.S(B,M1) in block 403), which will be used
for the verification of the signature and for decryption of the
service credentials.
[0079] In some implementations of self-delegation, the new
credential may be such that it can be memorized by the delegator.
In such a scenario, a single password or pass-phrase may be used to
verify the signature (in block 602) and to decrypt encrypted
credentials (in block 605) and data (where this is also encrypted,
e.g. as described below). In an example a symmetric key
K.sub.S(B,M1) may be generated using a memorized secret as input
parameter, e.g. an AES (Advanced Encryption Standard) key may be
generated from a pass-phrase. At the encryption stage (e.g. in
block 404), the symmetric key, (e.g. AES), used to encrypt the data
and/or credentials can be generated from the memorized secret. By
knowing and inputting this secret, the delegatee can enable the
composite service to regenerate the same key in another environment
in order to decrypt necessary credentials and/or data. The secret
may be selected to be strong enough to forbid dictionary attacks. A
dictionary attack is a form of attack where a long list of possible
values is used in attempt to guess the value of a secret or
pass-phrase.
[0080] The electronic signature used to verify the composite
service (e.g. as created in block 405 and verified in block 602) is
based on asymmetric cryptography. However, since the signer (who is
usually the delegator) and the verifier (the delegatee) share a
secret (in this case the signer and verifier are even the same
party), the signature may comprise a message authentication code
(MAC). The MAC may be the result of the hash of the composite
service code concatenated with the secret. The verification (in
block 602) is done by doing the same process (i.e. generating the
hash of the composite service code concatenated with the secret)
and comparing the generated and the downloaded values.
[0081] These techniques which may be used for self-delegation
enable the use of a single credential (referred to herein as the
secret) to verify the composite service and to decrypt the
necessary credentials and/or data.
[0082] The methods described above may be further modified to
increase their resilience against dictionary attacks and various
techniques may be used. In a first example, access to the encrypted
service credentials (which is the cipher-text in this method) may
be restricted. A combination of access control and encryption may
be used to restrict the access to the cipher-text. In a second
example, the cost of checking a key may be increased, e.g. by using
mechanisms which require higher computational power to perform the
decryption (e.g. by using multiple layers of encryption with same
key). This would penalize the attacker but may increase the
response time to an unacceptable level where the composite service
is accessed by legitimate users using devices which have a low
computing power (e.g. mobile telephones). In a third example,
interaction with the (distrusted) service provider (or the
credential store) may be required when checking a key. In such an
example, the key used to encrypt the service credentials (or other
data) may depend on a secret known by the service provider (or the
credential store) in order to force an interaction with this entity
for each decryption.
[0083] FIGS. 12 and 13 show example implementations of parts of the
delegation and access phases which use the third of the approaches
given above to increase resilience to dictionary attacks (e.g. an
implementation of blocks 404, 407 and 604). In the delegation
phase, the delegatee's (e.g. Alice's) secret (which is generated by
Bob and communicated to Alice) is used to generate the decryption
key K.sub.S(A,M1) (block 1201). In an example, the key may be a
symmetric key, e.g. AES, and this may be expressed as
K.sub.S(A,M1)=K.sub.P(A,M1). This key is used to encrypt the
service credentials (block 1202) before they are stored in the
credential store (in block 407). The decryption key may be passed
to Alice by Bob (e.g. in block 408) or may alternatively be
regenerated by Alice to avoid providing her with additional
credentials.
[0084] Although in FIGS. 12 and 13, her credential is generated by
Bob, in other examples, Alice may be able to choose or change her
credential (e.g. password) and a mechanism may be provided to
provide the credential to Bob in a secure manner. Similarly in the
other examples described herein, the delegatee (e.g. Alice) may be
able to choose or change her credential.
[0085] The delegatee's secret K.sub.S(A) is also used to create
another secret K.sub.S(A)2, (e.g. a new username/password) with a
one-way function H.sub.1 (block 1203) so that K.sub.S(A) cannot be
computed from K.sub.S(A)2. In many examples this additional secret
is generated by Bob, although alternatively this may be generated
by Alice and communicated to Bob. An example of a one-way function
is a hash function. This new secret K.sub.S(A)2 is provided to the
credential store along with the encrypted service credentials
(block 1204) such that the credential store (e.g. Mallory 502) can
authenticate the delegatee (e.g. Alice 303) but cannot decrypt the
data (as the credential store does not know K.sub.S(A)).
[0086] In the access phase, the delegatee (e.g. Alice) also
generates the new secret K.sub.S(A)2 from their first secret
K.sub.S(A) using the same one-way function (block 1205) and this
new secret is used by the delegatee to authenticate to the
credential store (block 1206), who may be a distrusted party, in
order to retrieve the encrypted service credentials (block 1207).
Having retrieved the encrypted service credentials, they can be
decrypted using the decryption key K.sub.P(A,M1) (in block
605).
[0087] The method described above and shown in FIGS. 12 and 13
reduces the possibility of an attacker obtaining access to the
delegator's (e.g. Bob's) data and/or services while not impacting
the delegatee (e.g. Alice) because the delegatee does not need to
deal with any additional credentials.
[0088] In the above examples it was assumed that the resources
(which are services in the examples above) used by the composite
service are trusted. The following variation, which is described
with reference to FIGS. 14-16, enables use of resources which are
(or may be) distrusted. In the delegation phase, as shown in FIG.
14, instead of updating access rights for a resource (e.g. service
S.sub.1 1601), e.g. as in block 402 of FIG. 4, the delegator (e.g.
Bob 301) creates access control keys K.sub.1, K.sub.2 (block 1401)
and encrypts one or more pieces of data (data.sub.1, data.sub.2)
with those access control keys (block 1402). As a result, the party
offering the resource and storing the data cannot decrypt them.
Next, the delegator (Bob) encrypts those keys K.sub.1, K.sub.2
accordingly to the access control he wants to grant to the
delegatee (Alice) and any other parties (block 1403). For instance
Bob can encrypt K.sub.1 with key K.sub.P(A, S1) and provide this
key to Alice in order to let her access data.sub.1. As previously,
the key K.sub.P(A, S1) can be stored in the (distrusted) credential
store (in block 407). The encrypted data (e.g.
E.sub.K1(data.sub.1)) and the encrypted access control keys (e.g.
E.sub.KP(A, S1)(K.sub.1)) are uploaded to the resource 1601 (block
1404).
[0089] In the access phase, the delegatee only sees minor
differences. As shown in FIG. 15, in accessing the resources as
required during execution of the composite service (block 606), the
delegatee (e.g. Alice) accesses the encrypted data and encrypted
access keys (block 1501), decrypts the access keys (block 1502) and
then uses the decrypted access keys to decrypt the data (block
1503).
[0090] In the example shown in FIG. 16, composite service host 501,
the credential store 502 (which may also be referred to as a key
store), and the resource 1601 could all be run by the same party
(which may be distrusted party) or different parties may run one or
more of these elements without affecting the methods described
above. In this example, the resource 1601 could be a publicly
available web page or web server because the data is stored in an
encrypted manner such that only the delegatees can access the
decrypted data.
[0091] Although the above examples are described in relation to a
distrusted host and a distrusted credential store, the methods are
also applicable to other scenarios, e.g. where these entities are
trusted or where their trust status is not known. The methods are
also applicable where the access to the resource is public instead
of being restricted. As described above, the delegator may be the
same as, or different from, the delegatee.
[0092] The following description, with reference to FIGS. 17 and
18, describes a specific implementation of the techniques described
above by way of example only. This example uses a composite service
which is implemented with Microsoft.RTM. Silverlight.TM. 2.0 and
which runs within the delegatee's web browser.
[0093] Bob 1701 (the delegator) creates a new Microsoft.RTM.
Silverlight.TM. page or selects and existing one and signs the
resulting files. The signature is embedded in the HTML page, which
is stored at the distrusted host 1702 (as indicated by arrow 1801).
This composite service displays a combination of medical and
location information to quickly locate and help Bob (e.g. in case
of an accident or other incident).
[0094] In order to give Alice 1703 access to this webpage Bob
configures both resources that are used by the composite service
(health record 1704 and location service 1705). For instance, a new
username, random password, and corresponding privileges can be
added to the access control list. Bob creates a new AES key, uses
this key to encrypt the service passwords, and stores those
encrypted credentials at the distrusted credential store 1706 (as
indicated by arrow 1802).
[0095] Bob then sends Alice an e-mail or other form of message (as
indicated by arrow 1803) containing: [0096] the address of the
composite service: e.g. the URL of the distrusted composite service
store, [0097] the credential to verify the signature: e.g. Bob's
public key, and [0098] the key to decrypt the service credentials
used by the composite service: e.g. the generated AES key. The URL
in the mail may, for example, look like:
http://localhost/SLSecurityDemo_Web/DefaultPage.aspx?pk=MIGJAoGBAO2a7
. . . where `pk=MIGJAoGBAO2a7 . . . ` is the full public key of Bob
(K.sub.P(B)) to be used to verify the signature.
[0099] The access phase is shown in FIG. 18. When Alice gets Bob's
e-mail, she clicks on the URL (as indicated by arrow 1804). In this
example the URL is shaped in a way that it contains the composite
service address and Bob's public key as a parameter. The composite
service (i.e. the Microsoft.RTM. Silverlight.TM. code), referenced
by this URL and the embedded signature are downloaded to Alice's
web browser (as indicated by arrow 1805). A plug-in for the browser
(e.g. Internet Explorer.RTM.) verifies the signature embedded in
the HTML page with the Microsoft.RTM. Silverlight.TM. code in the
same page and indicates whether the signature is valid (as
indicated by arrow 1806). In some examples the browser may verify
the integrity and authentication of Microsoft.RTM. Silverlight.TM.
code. If the signature is valid, Alice can copy the AES key from
the mail to into the composite service (arrow 1807). The
Microsoft.RTM. Silverlight.TM. code offers her a form field where
she can paste the key to. This copy and paste approach just is
exemplarily, other means to provide the key to the client-side
composite service are imaginable, e.g. direct file access to
Alice's key store or integration of Microsoft.RTM. Silverlight.TM.
with the operating system's crypto subsystem. The composite service
loads the encrypted credentials from the credential server 1706
(arrow 1808) and the composite service decrypts these credentials
(arrow 1809). The credentials are used to access the health record
and location service (arrow 1810) and the heath and location data
are displayed.
[0100] For the purposes of this particular implementation and by
way of example only, the public key of the delegator is embedded in
the URL as this reduces the number of operations necessary to
access the composite service. However, other implementations may
use other techniques such that the URL does not contain Bob's
public key. Such alternatives prevent the host (Eve) from mounting
a phishing attack by creating malicious composite service code and
signing it with another key (e.g. the host's public key). In such
an attack, when Alice clicks on the correct link in the mail, the
host redirects the incoming page request to another URL which
contains the host's public key instead of Bob's. The signature
verification will succeed since the malicious code can be correctly
verified against the host's public key and therefore Alice will run
the malicious composite service code. If Alice does not notice the
redirection, the malicious composite service may be able to ask
Alice for the AES key and steal the credentials for Bob's
services.
[0101] The above example implementation is based on Silverlight.TM.
2.0 and an example of the schematic architecture is depicted in the
left part 1901 of FIG. 19. It consists of a plug-in 1902 for
Internet Explorer.RTM. that does the verification of the
SilverLight.TM. code. A SilverLight.TM. plug-in 1903 may also be
used to process the security protocol (e.g. which performs the
decryption of the service credentials). In other example
implementations, the verification of the signature may
alternatively be done by the browser or by the Silverlight.TM.
plug-in (instead of by the dedicated Internet Explorer.RTM. plug-in
1902). The right part 1904 of FIG. 19 shows another example of a
schematic architecture in which the different aspects are
implemented in a version of a web browser. In this example
SilverLight.TM. may be used to detect redirection attacks (i.e. the
phishing attack described earlier) and verify the signature of
SilverLight.TM. code. The SilverLight.TM. DLL 1905 may continue to
deal with the crypto protocol described herein.
[0102] In the examples described above, the delegatee credential is
created and provided by the delegator. However, where the delegator
knows the public key of the delegatee, the encryption and
decryption process may be simplified and may be automated. In
further examples, groups of delegatees may be supported so that the
delegator can let a group (e.g colleagues, friends, etc) access his
composite service.
[0103] FIG. 20 illustrates various components of an exemplary
computing-based device 2000 which may be implemented as any form of
a computing and/or electronic device, and in which embodiments of
the methods described herein may be implemented. For example, the
computing-based device 2000 may be used by the delegator or the
delegatee for any of the delegation, access and revocation phases
of the methods described herein.
[0104] Computing-based device 2000 comprises one or more processors
2001 which may be microprocessors, controllers or any other
suitable type of processors for processing computing executable
instructions to control the operation of the device in order to
perform the methods described herein (e.g. the delegation, access
or revocation phase). Platform software comprising an operating
system 2002 or any other suitable platform software may be provided
at the computing-based device to enable application software 2003
to be executed on the device.
[0105] The application software 2003 may depend on the phase that
the computing-based device is required to perform and may, for
example, comprise a browser and SilverLight.TM.. The application
software may further comprise one or more plug-ins, e.g. as
described above and shown in FIG. 19. The application software may
enable the delegation to be performed in a single mouse click (or
in a few operations) by a user. In such an example, the software
hides the process steps from the user.
[0106] The computer executable instructions may be provided using
any computer-readable media, such as memory 2004. The memory is of
any suitable type such as random access memory (RAM), a disk
storage device of any type such as a magnetic or optical storage
device, a hard disk drive, or a CD, DVD or other disc drive. Flash
memory, EPROM or EEPROM may also be used.
[0107] The computing-based device 2000 further comprises a user
interface 2005, to enable the user (e.g. Alice or Bob) to interact
with the application software and specify the aspects of the
delegation that are required. The computing-based device also
comprises a communication interface 2006 to enable the device to
communicate with other entities in the system, e.g. the host, the
credential store, the services etc.
[0108] Additionally, the computing-based device 2000 may further
comprise one or more inputs (e.g. which are of any suitable type
for receiving media content, Internet Protocol (IP) input, etc)
and/or one or more outputs (e.g. an audio and/or video output to a
display system integral with or in communication with the
computing-based device), which are not shown in FIG. 20.
[0109] Although the present examples are described and illustrated
herein as being implemented in a web-based system, the system
described is provided as an example and not a limitation. As those
skilled in the art will appreciate, the present examples are
suitable for application in a variety of different types of
computing systems.
[0110] The above examples describe the delegatee as an end user. It
will be appreciated, however, that the delegatee may not be an end
user in some scenarios and may, for example, be a system (e.g. an
automated process).
[0111] The term `computer` is used herein to refer to any device
with processing capability such that it can execute instructions.
Those skilled in the art will realize that such processing
capabilities are incorporated into many different devices and
therefore the term `computer` includes PCs, servers, mobile
telephones, personal digital assistants and many other devices.
[0112] The methods described herein may be performed by software in
machine readable form on a tangible storage medium. The software
can be suitable for execution on a parallel processor or a serial
processor such that the method steps may be carried out in any
suitable order, or simultaneously.
[0113] This acknowledges that software can be a valuable,
separately tradable commodity. It is intended to encompass
software, which runs on or controls "dumb" or standard hardware, to
carry out the desired functions. It is also intended to encompass
software which "describes" or defines the configuration of
hardware, such as HDL (hardware description language) software, as
is used for designing silicon chips, or for configuring universal
programmable chips, to carry out desired functions.
[0114] Those skilled in the art will realize that storage devices
utilized to store program instructions can be distributed across a
network. For example, a remote computer may store an example of the
process described as software. A local or terminal computer may
access the remote computer and download a part or all of the
software to run the program. Alternatively, the local computer may
download pieces of the software as needed, or execute some software
instructions at the local terminal and some at the remote computer
(or computer network). Those skilled in the art will also realize
that by utilizing conventional techniques known to those skilled in
the art that all, or a portion of the software instructions may be
carried out by a dedicated circuit, such as a DSP, programmable
logic array, or the like.
[0115] Any range or device value given herein may be extended or
altered without losing the effect sought, as will be apparent to
the skilled person.
[0116] It will be understood that the benefits and advantages
described above may relate to one embodiment or may relate to
several embodiments. The embodiments are not limited to those that
solve any or all of the stated problems or those that have any or
all of the stated benefits and advantages. It will further be
understood that reference to `an` item refers to one or more of
those items.
[0117] The steps of the methods described herein may be carried out
in any suitable order, or simultaneously where appropriate.
Additionally, individual blocks may be deleted from any of the
methods without departing from the spirit and scope of the subject
matter described herein. Aspects of any of the examples described
above may be combined with aspects of any of the other examples
described to form further examples without losing the effect
sought.
[0118] The term `comprising` is used herein to mean including the
method blocks or elements identified, but that such blocks or
elements do not comprise an exclusive list and a method or
apparatus may contain additional blocks or elements.
[0119] It will be understood that the above description of a
preferred embodiment is given by way of example only and that
various modifications may be made by those skilled in the art. The
above specification, examples and data provide a complete
description of the structure and use of exemplary embodiments of
the invention. Although various embodiments of the invention have
been described above with a certain degree of particularity, or
with reference to one or more individual embodiments, those skilled
in the art could make numerous alterations to the disclosed
embodiments without departing from the spirit or scope of this
invention.
* * * * *
References