WO2013152383A1

WO2013152383A1 - System and method for facilitating secure communication of data over a communications network

Info

Publication number: WO2013152383A1
Application number: PCT/AU2013/000197
Authority: WO
Inventors: Philip James MUNNELLY; Ian Charles OTTO
Original assignee: Department Of Industry, Innovation, Science, Research And Tertiary Education
Priority date: 2012-04-13
Filing date: 2013-03-04
Publication date: 2013-10-17
Also published as: AU2013202043A1

Abstract

A method implemented by a key broker for facilitating secure communication of data over a communications network comprises receiving an encryption key request message from an owner of the data. The key request message comprises one or more decryption key distribution conditions. Responsive to receiving the encryption key request message, the key broker generates a cryptographic key pair comprising an encryption key K1 and a decryption key K2. The decryption key K2 is stored in association with the decryption key distribution conditions. The encryption key K1 is communicated to the data owner which is utilisable thereby for encrypting the data to be communicated over the network. The decryption key K2 is communicated to a data recipient for use in decrypting the encrypted data, responsive to determining that the one or more decryption key distribution conditions have been met.

Description

System and Method for Facilitating Secure Communication of

Data over a Communications Network

Field of the Invention

The present invention relates generally to digital

encryption and decryption techniques for data to be asynchronously communicated over an unsecure data network, such as the Internet. Background of the Invention

Every organisation has key information assets (data) that it wishes to keep secret, for commercial advantage, to protect the privacy of customers or employees, or for other reasons.

IT infrastructure is moving from a model of isolated networks with minimal interaction to a distributed model, with services often being outsourced. With each

connection security risks grow, and it is harder to control access to the sensitive data assets of an

organisation .

Traditional data security involves hiding the sensitive data deep inside the infrastructure of an organisation protected by multiple layers of active security. However, providing such infrastructure is very expensive, and a single compromise can result in the loss of the data.

Furthermore, such storage techniques do not provide for an effective or efficient way of making the data accessible to trusted parties who do not have access to the

infrastructure . Dedicated data service providers have emerged to provide readily accessible data storage. One such form of dedicated data service is based on a networked on-line storage model, commonly referred to as ^xcloud based' storage. An advantage of cloud based storage is that data is stored in a centralised repository accessible to any authorised party provided they have a network enabled computer. However, a major concern with cloud based storage is the vulnerability of the data both while it is in transit (i.e. either being uploaded or downloaded), as well as while it is stored. While most providers do provide some form of key based encryption scheme for protecting the data being stored, it is generally the same provider who is responsible for generating and maintaining keys used for encrypting/decrypting the data. Thus, if the service provider is compromised, so too may be the data it is storing. These are among the reasons that have resulted in many organisations being reluctant to store sensitive data with such third party data service

providers. Indeed, in some cases, organisations such as government departments are prevented by law from storing information with such third parties.

It would be advantageous if there was provided a means to leverage the economies of scale provided by such data storage, without compromising the data being stored. It would also be advantageous if there was provided a way of maintaining and publishing a public register, while providing enhanced protected information on that register to an authorised subset of the users of the register. Summary of the Invention

In accordance with a first aspect of the present invention there is provided a computer implemented method for facilitating secure communication of data over a

communications network, comprising:

receiving an encryption key request message from a data owner, the key request message comprising one or more decryption key distribution conditions;

generating a cryptographic key pair comprising an encryption key Kl and a decryption key K2, responsive to receiving the encryption key request message;

storing the decryption key K2 in association with the decryption key distribution conditions;

communicating the encryption key Kl to the data owner which is utilisable thereby for encrypting the data to be communicated over the network; and

communicating the decryption key K2 to a data

recipient for use in decrypting the encrypted data, responsive to determining that the one or more decryption key distribution conditions have been met.

In an embodiment the decryption key distribution

conditions identify one or more recipients authorised to receive the decryption key, such that the decryption key K2 is communicated to the data recipient responsive to the key broker determining that the data recipient is an authorised recipient.

In an embodiment the method further comprises receiving a decryption key request message from the data recipient which includes identification data that the key broker evaluates to determine whether they are an authorised recipient . In an embodiment the identification data comprises a PKI certificate utilised by the data recipient to digitally sign the decryption key request message and which is verifiable by the key broker to determine the identity of the data recipient and to validate the contents of the decryption key request message.

In an embodiment the decryption key conditions

additionally specify an expiry for the decryption key K2.

In an embodiment the method further comprises receiving an update request message from the data owner for updating one or more of the decryption key distribution conditions stored in association with the decryption key K2.

In an embodiment the encryption key Kl and decryption key K2 are generated in PRCS format.

In an embodiment encryption of the data by the data owner comprises:

generating a session key S I which is encrypted using key Kl to yield K1(S1);

discarding Kl leaving S I which is used to encrypt the data yielding S I (data) ; and

discarding S I .

In an embodiment the key Kl is used to directly encrypt the data by the data owner. In an embodiment the method further comprises generating a unique identifier associated with the generated key pair which is communicated to the data owner with the

encryption key Kl and wherein the unique identifier is stored by the key broker in association with the

decryption key K2 and decryption key distribution

conditions . In an embodiment the encryption key request message further includes a data owner reference for the data to be encrypted and the method further comprises storing the data owner reference in association with the decryption key K2 and the decryption key distribution conditions.

In an embodiment the encryption key request message further includes identification data utilised to determine an identifier of the data owner and the method further comprises storing the identifier in association with the decryption key K2 and the decryption key distribution conditions .

In an embodiment the owner identification data comprises a PKI certificate utilised by the data owner to digitally sign the encryption key request message and which is verifiable by the key broker to determine the data owner identifier and to validate the contents of the encryption key request message prior to generating the key pair. In an embodiment one or more of the data owner reference, the unique identifier and the owner identifier is provided to the key broker by the data recipient for identifying the decryption key K2. In an embodiment the method further comprises

communicating the encryption key Kl to the data owner in an encryption key response message. In an embodiment the method further comprises digitally signing the encryption key response message with a digital certificate which is validatable by the data owner prior to encrypting the data.

In an embodiment the encrypted data is uploaded by the data owner to a data storage service for accessing by the data recipient. In an embodiment the data storage service is a cloud based data storage service.

In an embodiment the communications network is the

Internet .

In an embodiment the method further comprises storing a log of the encryption and decryption requests and

responses associated with a particular key record, the log including an identifier of the owner/recipient and a time the corresponding message was received.

In an embodiment the method further comprises receiving an audit request message from an audit party identifying a particular key record and providing the audit party with access to the associated log, responsive to determining that the audit party is authorised to access the log.

In an embodiment the key encryption request message includes data identifying the parties that are authorised to access the associated log.

In accordance with a second aspect there is provided a key broker service operable to issue cryptographic encryption keys to data owners for use in encrypting data to be communicated over an unsecure communications network and being further operable to issue corresponding decryption keys to recipients of the encrypted data responsive to determining that one or more decryption key distribution conditions have been met, the conditions being

electronically communicated to the key broker service by the data owners when requesting the encryption keys. In accordance with a third aspect there is provided a key broker service for facilitating secure communication of data over a communications network, comprising:

a key processing module operable to generate a cryptographic key pair Kl, K2 responsive to an encryption key request message being received from a data owner, the key processing module being further arranged to

communicate the key Kl to the data owner for encrypting data to be communicated over the network; and

a key store arranged to store the key K2 in

association with decryption key distribution conditions identified in the encryption key request message, the key processing module being further arranged to retrieve and evaluate the key distribution conditions responsive to receiving a decryption key request message from a

requesting party prior to issuing the corresponding decryption key thereto.

In accordance with a fourth aspect there is provided a method for facilitating secure communication of data over a communications network, comprising:

sending an encryption key request message comprising one or more decryption key distribution conditions to a key distribution service, the key distribution service operable to generate a cryptographic key pair comprising an encryption key Kl and a decryption key K2 responsive to receiving the encryption key request message;

receiving the encryption key Kl from the key broker service and encrypting the data utilising the key Kl;

making an identifier of the encrypted data available to a data recipient, the data recipient operable to provide the identifier to the key broker service for retrieving the corresponding decryption key, wherein the decryption key is provided to the data recipient by the key broker service responsive to determining that the associated key distribution conditions have been

satisfied . In accordance with a fifth aspect there is provided computer program code which when executed by a processor is arranged to implement the method as described in accordance with the fourth aspect. In accordance with a sixth aspect there is provided a computer readable medium provided a computer program in accordance with the fifth aspect.

In accordance with a seventh aspect there is provided a data signal comprising the program code of the sixth aspect .

Brief Description of the Drawings

Features and advantages of the present invention will become apparent from the following description of

embodiments thereof, by way of example only, with

reference to the accompanying drawings, in which: Figure 1 is an illustration of a system in accordance with an embodiment of the present invention;

Figure 2 is a block diagram of a key broker service, in accordance with an embodiment;

Figure 3 is a general process flow for implementing an embodiment of the present invention; Figure 4 is a schematic illustrating a particular key broker usage scenario, in accordance with an embodiment of the present invention;

Figure 5 is a process flow for encrypting data using a key broker service in accordance with an embodiment of the present invention;

Figure 6 illustrates components of an encryption key request message, in accordance with an embodiment;

Figure 7 illustrates components of a database entry stored by the key broker system for a particular transaction;

Figure 8 illustrates components of an encryption key response message in accordance with an embodiment;

Figure 9 is a process flow for decrypting data using a key broker system, in accordance with an embodiment;

Figure 10 illustrates components of a decryption key request message, in accordance with an embodiment; Figure 11 illustrates components of a decryption key response message, in accordance with an embodiment;

Figure 12 is a schematic illustrating a further key broker usage scenario, in accordance with an embodiment of the present invention;

Figure 13 is a schematic illustrating yet a further key broker usage scenario, in accordance with an embodiment of the present invention;

Figure 14 is a process flow for updating key distribution conditions with the key broker; Figure 15 illustrates components of an update request message, in accordance with an embodiment;

Figure 16 illustrates components of an update response message, in accordance with an embodiment;

Figure 17 is a process flow for auditing records stored by the key broker service in accordance with an embodiment of the present invention; Figure 18 illustrates components of an audit request message, in accordance with an embodiment; and

Figure 19 illustrates components of an audit response message, in accordance with an embodiment.

Detailed Description of Preferred Embodiments

Embodiments described herein relate to techniques for facilitating secure communication of data over a communications network. This is achieved by way of an independent third party key broker service (hereafter key broker system) responsible for generating asymmetric key pairs, with a first cryptographic key (hereafter the

"encryption key") being provided upon request to a data provider or "owner" to encrypt their sensitive data before it is communicated over a communications network e.g. to an untrusted source. The corresponding cryptographic key ("decryption key") is stored in association with various decryption key distribution conditions specified by the data owner for subsequent communication to a recipient of the encrypted data (i.e. for decrypting the encrypted data) , responsive to determining that the decryption key distribution conditions have been satisfied. The

independence of the key broker system ensures that no single party can compromise the data.

It will be understood that the network across which the sensitive data is communicated could be any form of private or public data network including a LAN (Local Area Network) , WAN (Wide Area Network) , public switched data network (whether cellular or terrestrial) , or any

combination thereof. Furthermore the data may comprise any form of digital information including voice

information, data information, multimedia information, or other such information being capable of being transmitted across the network. For the purposes of illustration, and with reference to the figures, embodiments of the

invention will hereafter be described in the context of a key broker operable to facilitate secure communication of data between remotely located agencies of a particular government department. More specifically, according to the illustrated example, the encrypted data is uploaded to a central repository for subsequent access by selected agencies or external service providers. The central repository shown in the figures is in the form of a commercial cloud data service accessible by the agencies over the Internet 108. It will be understood, however, that in alternative embodiments the data could be stored by a consolidated company data centre, or locally by the individual agencies. According to yet another alternative embodiment, the encrypted data could be published on a public register.

Figure 1 illustrates an example system configuration 100 for implementing an embodiment of the present invention. The system 100 includes two remotely located agencies 102, 104 which communicate with an independent key broker system 106 for receiving cryptographic keys to encrypt and decrypt sensitive data. It will be understood that any number of agencies/entities each consisting of any number of individual users may communicate with the key broker system 106 (although for simplicity only two agencies are shown, each being represented by a single network-enabled computer terminal 105) . A central data repository 110 which is implemented independently of the key broker system 106 is also shown connected to the network. In the illustrated embodiment the central data repository 110 is in the form of a cloud based data storage service. The agencies 102, 104 can access the cloud data service 110 (i.e. by way of the respective network-enabled computer terminals 105) to either upload or download data that has been encrypted using a cryptographic decryption key issued by the key broker system 106, as will be described in more detail below. A general process flow for facilitating secure

communication of data utilising the key broker system 100 is shown in Figure 3. In a first step SI, a data owner (in this case agency 102) sends an encryption key request message to the key broker system 106 requesting an

encryption key for encrypting data to be uploaded to the central repository 110. The encryption key request message includes decryption key distribution conditions which, in this example, identify parties authorised to decrypt the data (although it will be understood that other key distribution control conditions may also be specified by the data owner, as will be described in more detail in subsequent paragraphs) . At step S2, the key broker system 106 generates an asymmetric key pair consisting of encryption key Kl and decryption key K2.

The encryption key Kl is subsequently communicated to the requesting agency 102 (at step S3) for encrypting the sensitive data. The decryption key K2 is stored in a key data store 109 maintained by the key broker system 106. At step S4, upon receiving a decryption key request message, the key broker system 106 evaluates the

decryption key distribution conditions to determine whether the party requesting the decryption key was identified as being authorised to receive the decryption key K2 (i.e. as stipulated by the stored distribution conditions) . If they are identified, the key broker 106 packages the corresponding decryption key K2 into a decryption key response message and communicates it to the requesting party for decrypting the data (step S4) .

Further Detail of System Configuration

With reference to Figure 2, the key broker system 106 comprises a server computer 107 which includes typical server hardware including a processor, motherboard, memory, hard disk and a power supply. The server 107 also includes an operating system which co-operates with the hardware to provide an environment in which software applications can be executed. In this regard, the hard disk of the server 107 is loaded with a key processing module 113 which, under the control of the processor, is operable to implement various key management and access control components as shown (noting that for the sake of simplicity a data layer between components and data store has been assumed but not shown) . More specifically, the components include a request handler 114 which is a presentation layer component operable to handle all inbound and outgoing requests. The request handler 114 is also operable to provide message validation and perform message translation from an external protocol used over the network to simple internal service calls. The request handler 114 is also responsible for logging request and response messages to an audit data store 132.

A lock request manager 116 implemented by the processing module 113 is a business logic component that requests key pair generation, saves them to a key data store 109 along with the key distribution conditions and returns one of the keys back to the request handler 114. Key pairs may be cached by the request manager 116 to improve

performance of standard key encryption requests, as will be described in subsequent paragraphs. In addition to key encryption requests, the request manager 116 is operable to update the stored distribution conditions, as will be described in more detail in subsequent paragraphs. The key generator 118 is a business logic component that generates key pairs, and encrypts the decryption key of the key pairs (i.e. key K2) using a key broker encryption key (KBEK) . The decryption service component 120 decrypts a key that was encrypted by the key generator 118. The unlock request manager 122 is a business logic component that evaluates decryption key request messages against the distribution conditions corresponding to the requested key, and if valid will return the decryption key (via the request handler 114) .

The agency data store 130 stores data that links

authentication credentials for a particular agency and their agency reference ID. This data is used to identify the agency making the request, for use by the request managers 116, 122. The key data store 109, as previously discussed, holds decryption keys that are being saved, along with the corresponding distribution conditions. A batch job may be implemented to periodically check stored data against expiration dates, overwriting or deleting keys for all key records that have expired. The audit data store 132 holds a record of all the data and outcomes of each request made to the key broker 106. The data is sanitized to remove key information prior to being stored.

As previously mentioned, the agencies 102, 104 connect to the key broker system 106 and central data store 110 using a network-enabled computing device. The computing device 105 may be any suitable device including a workstation, laptop, a smart phone, tablet, or the like. The computing device may employ traditional hardware including a central processing unit, RAM, ROM, non-volatile memory, volatile memory and standard network hardware and software. In this regard, the computing device may connect to the network 108 through a wired or wireless connection.

Further, the connection to the network 106 may be by way of an intermediate network (e.g. LAN and gateway to which the respective agency 102, 104 may be connected) . The communication between the agencies and key broker

system 106 may utilise transport layer security to ensure that the messages cannot be intercepted, although it will be understood that none of the message requests/responses exchanged contain private data and thus the key broker methodology described herein cannot be compromised by any single step being compromised. The computing devices 105 may also be loaded with customised software which enables the users to generate and process the various messages sent to and received from the key broker system 106. In one particular embodiment, the software may be developed using the "Application Programmers Interface" which incorporates a library of functions for generating the software, as will be well understood by persons skilled in the art .

Lastly, the cloud data store 110 comprises a standard storage configuration of server computers for remote data storage, as is well understood by persons skilled in the art. As previously mentioned it is not essential that the data store be a cloud based data store and instead could be either a consolidated data store implemented by the company (e.g. situated on a private WAN to which the agencies 102, 104 are connected), or indeed maintained locally by the agencies 102, 104. It will also be

appreciated that in particular embodiments, the encrypted data may not be stored in an intermediate location and instead be communicated directly from one of the agencies to the other. Various specific process flows which utilise a key broker system 106 as described above will now be outlined with reference to Figures 4 through 16. Process Flow A -

With reference to Figure 4 there is shown a scenario whereby a data owner (in this case agency A 102) wishes to store sensitive data in the data store 110, for subsequent retrieval and access by a data recipient (agency B 104) . The associated process will now be described in further detail, with additional reference to Figures 5 and 6.

At step 1 of Figure 5, the agency 102 prepares and sends an encryption key request message (e.g. using software, as previously described, which is loaded on the computer device 105) to the key broker system 106. A diagram illustrating an example encryption key request message (which, according to the presently described embodiment is coded in XML format) configuration is shown in Figure 6. As shown, the request message 200 includes a data

reference 202 in the form of an alphanumeric reference that is assigned by the agency 102. A key size 204 (e.g. 512, 1024, 2048, 4096, etc.) and key expiry 206 may also be specified by the agency 102. In this example

embodiment, the decryption key distribution data DKDD 208 optionally includes a listing of parties authorised to decrypt the data, validity periods (i.e. periods during which the corresponding decryption key for a particular authorised recipient will remain available and considered ^ληοη expired' ) and a high assurance flag which dictates whether or not the key broker 106 is to dynamically generate a key pair responsive to receiving the request (as opposed to allowing the key broker to utilise a set of pre-generated keys stored in a key cache) . Typically the DKDD 208 will identify the data owner (i.e. agency 102) as having full access rights, although in certain cases this might not be appropriate. The request message 200 is digitally signed by agency 102 (see field 210) using a digital certificate to prevent tampering. The digital certificate is also utilised by the key broker 106 to verify the identity of agency 102, thus advantageously avoiding the need for agency 102 to register with the broker 106 prior to using the service. In this regard it will be noted that all of the parties wanting to access the key broker system (i.e. both data owners and data recipients) have certificates that they can sign messages with that are issued from a certificate issuer that is trusted by the key broker 106. As will be understood by persons skilled in the art, a digital signature comprises a statistically unique standards-based digest of the data being signed, encrypted using the private key of the signer. The particular algorithm used to create the digest (e.g. MD5) is also included in the signature, as is the public certificate of the signer (the public certificate contains the public key, signed by a certificate issuer, such as Verisign™- see URL http://www.verisign.com/, who is trusted by both parties) . A recipient of the message (e.g. agency 102, 104) can compute the digest, and then compare it to the encrypted digest provided after it has been decrypted using the public key from the certificate provided. Provided the recipient trusts the certificate issuer they can trust that the data signed was from the owner of the certificate, and that the data has not been altered . At step 2, the encryption key request message 200 is subsequently received by the request handler 114 of the key broker system 106 and subsequently validated (e.g. by checking the digital signature as described above) . If validation fails processing will not proceed. Otherwise, the agency identifier is determined from the message signature and the message is sent to the request

manager 116 (step 3) . At step 4 the request manager 116 requests an asymmetric Public Key Infrastructure (PKI) key pair having a length specified by the encryption key request message. At step 5 the key generator 118

generates a key pair, consisting of an encryption key Kl and decryption key K2, using techniques well understood in the art. The key generator 118 subsequently encrypts the decryption key K2 yielding e(K2), which is returned to the request manager 116 (steps 6 and 7) . At step 8, the request manager 116 generates a unique key broker

reference ("UID") 212 for the transaction, since the agency reference 202 provided in the encryption key request message may not be unique across all transactions handled by the key broker system 106. At step 9, the request manager 116 subsequently saves relevant key data to the key data store 109, in this case including the data reference 202, agency identifier, DKDD 208, e(K2), UID 212 and expiry 206 (see Figure 7 showing an example storage format) . At step 10, the same data is saved to another site, such that if either of the writes fails the request will be declined (thus providing higher assurance that if the site was only written to a single location) . At step 11, the UID 212 and key Kl are communicated back to the request handler 114 which in turn saves relevant audit data (in this example including the data reference 202, agency identifier, key length 204, expiry 206, UID 212) to the audit store 132 at step 12. At step 13, the UID 212 and decryption key K2 are communicated back to agency 102 in an encryption key response message 230, an example format of which is shown in Figure 8. As shown, the encryption key response message 230 is digitally signed

(see item 232) by the key broker 106 in the same manner as previously described for the corresponding request

message . Upon receipt of the encryption key response message 230, agency A validates the digital signature 232 prior to utilising the encryption key K2 (step 14) . Assuming the signature is valid, at step 15 agency 102 generates a session key SI, which it encrypts using Kl, yielding

K1(S1). The key Kl is then discarded (step 16), with SI being used to encrypt the data, yielding SI (data) at step 17. SI may then be discarded at step 18. Agency 102 is then free to upload/publish the encrypted data SI (data) and encrypted session key K1(S1), which according to

Figure 4 involves uploading the encrypted data to the storage service 110. It will be understood that the encryption process outlined above may be simplified by directly encrypting the data using Kl, therefore not requiring a session key. The decision on whether to use Kl to encrypt a session key or the actual data may depend on the size of the data being protected. For a small amount of data (e.g. a single credit card number or bank account details) direct encryption using Kl may be preferable. The unlock process will now be described with reference to the process flow diagram of Figure 9. At step 1, the data recipient (in this case the agency 104) downloads or otherwise accesses the encrypted data. Agency 104 then generates a decryption key request message 240 (see

Figure 10) including either the UID 212, or a combination of the data reference 202 and agency identifier. Again, the unlock request message 240 is signed with a digital signature 231 and then communicated to the key broker system 106.

At step 2 the request handler 114 validates the unlock request message 240 using the digital signature 231 and determines the agency 104 identifier. Provided the digital signature 231 is valid, the request handler 114 then passes the message 240 to the unlock request

manager 122 for retrieving the decryption key

corresponding to the data included in the message. At step 4, the unlock request manager 122 retrieves e(K2) and the DKDD 208 from the key store 109 using either the

UID 212 or the agency identifier and data reference 202. At step 5, the unlock request manager 122 checks that the expiry has not been reached and, at step 6, verifies the agency identifier against the DKDD 208. If agency 104 was not identified as authorised to receive the decryption key (or any other distribution key conditions were not met) the key broker system 106 rejects the request from agency 104 and stores the relevant reasons (i.e. outcomes) for the rejection in the audit store 132. Otherwise, at step 7, the request manager 122 sends a request message to the decryption service 120 to decrypt e(K2) . At steps 9 to 11, the decrypted key K2 is returned to the request handler 114 and relevant audit data is stored in the audit store (in this case, agency identifier, the unlock request and the outcome, i.e. allowed or rejected) . At step 12, the request handler 114 generates and digitally signs a decryption key response message 250 containing the key K2 (again in PKCS#8 format) which is communicated to agency 104.

At step 13, agency 104 receives the decryption key

response message 250 and validates the digital

signature 232. If valid, at step 14, agency 104 unpacks the response message 250 to obtain key K2 and uses it to decrypt the session key SI previously encrypted using Kl . Finally, at step 15, agency 104 uses SI to decrypt the data.

Using a key broker system 106 in accordance with process flow A has a number of benefits, including allowing the agencies to leverage the benefits of cloud services without the concern that the data will be misused. It also provides that the individual agencies do not have to develop their own cryptographic key management process. Access to the data can be defined at any level of

granularity - down to a specific application or agency division if required. For example, the data itself can be encrypted at a database row level meaning that different unlock rules can be applied to each row if required.

Also, it will be evident that the key broker system 106 as described ensures that no single party can compromise the data and that access to the data is independently

auditable via the key broker (described in more detail in subsequent paragraphs) .

Process Flow B - With reference to Figure 12 there is shown an alternative scenario whereby a party (agency 102) wishes to provide confidential information to another party (agency 104), but does not have a secure link. The associated process will now be described in further detail.

As a first step agency 102 obtains a cryptographic key using the same techniques as previously described for process flow A. The encryption key request message 200 generated by agency 102 includes DKDD 208 specifying agency 104 as being authorised to receive the decryption key. An encryption key response message 230 is

subsequently received from the key broker system 106 and the resulting key Kl used is used to encrypt the data as per the previous example. The encrypted data is then communicated to agency 104 at step 2. An insecure medium, such as email or electronic media can be used for this transfer if required. On receipt of the encrypted data

(step 3) agency 104 retrieves the decryption key from the broker system 106 and decrypts the data.

Many of the same benefits as described for process flow A also apply for process flow B. In addition, it will be appreciated that the communications network over which the data is communicated does not need to be secure e.g. the data could be emailed or transferred to the authorised data recipient via a public web site. Another advantage is that the parties do not need to authenticate each other .

Process Flow C -

In this scenario, one of the parties has a requirement to keep a public register of information. However there is extended private data also held in the register that is only to be made available to authorised parties. The publishing party (in this case agency 102) advantageously uses the key broker system 100 to encrypt the extended private data before publishing the entire data set on a public website. Such a scenario is illustrated in

Figure 13.

At step 1 of Figure 13, agency 102 obtains a cryptographic key using the same techniques as previously described for process flow A. The encryption key request message 200 generated by agency 102 includes DKDD 208 identifying a list of parties authorised to gain access to the extended private data held on the register 121. Agency 102

encrypts the data using the cryptographic key provided by the key broker 106 and publishes the register 121 (step 2) . At steps 3 and 4, an authorised agency (e.g. agency 104) reads the register and uses the key broker system 106 to obtain a key for decrypting extended private data that it is interested in, using techniques previously

described. Public users 123 can also access the data on the register (step 5) , but the encrypted extended data is meaningless to them as they do not have a key to decrypt the private data.

Again, many of the same benefits as described for the preceding process flows also apply. A specific advantage for process flow C is that a publishing party 102 does not need to provide secure transfer of information to

consuming authorised parties, nor worry about

authenticating users - they simply publish the register on their public web site.

Updating Decryption key Distribution Data (DKDD)

Embodiments allow a data owner to update the key

distribution conditions/data, thereby allowing flexibility to change or revoke access conditions associated with encrypted data even after the encrypted data has been communicated over the network. Further, the ability to change access control conditions also means that the data owner retains complete control over the data, even after it has been transmitted. For example, where the data owner no longer wants a particular recipient to have access to a particular piece of encrypted data, the owner can simply send an update request message to the key broker 106 for immediately revoking that party's access to the decryption key .

An example process flow is shown in Figure 14. At step 1, a digitally signed update request message 260 is sent to the key broker 106 by the requesting agency (in this example being agency 102) . An example message format is shown in Figure 15. As shown, the update request message includes the data reference or UID, updated DKDD 208 (i.e. stipulating the various conditions imposed by the

agency 102) and expiry 206. At step 2, the request handler 114 determines and verifies the identifier of the agency 102 and passes a modified update request (including the agency identifier and key length) to the lock request manager 116 (step 3) . At step 4, the request manager 116 updates the DKDD 208 for the corresponding key record and returns the UID and key Kl to the request handler 114 (step 5) . The request handler 114 writes the outcome to the audit store 132 (step 6) . At step 7 an update

response message 262 is sent to the agency 102, an example of which is shown in Figure 16. According to Figure 16, the response message 262 contains the outcome of the operation (i.e. successful or not successful). Audit Process

As previously mentioned, the key broker 106 maintains a record of any key access requests (whether it be a lock or unlock request) in the audit store 132. A typical audit process flow is shown in Figure 17. As shown, an auditing party (in this example being agency 102) sends an audit request message to the key broker system 106 to request audit data for a particular key record. An example format for such an audit request message 270 is shown in Figure 18. As shown, the audit request message 270 contains filtering information/data 272 (such as a list of

references, a time period, or a list of parties authorised to receive the key) and is digitally signed by the

auditing party. After validating the identity of the auditing party, the handler 114 of the key broker

system 106 checks that the party has been is authorised to access the audit data (i.e. by inspecting the DKDD for the identified record) . At step 3, the request handler 114 accesses the audit store 132 to retrieve the requested audit data. The audit request is then logged by the handler 114 at step 4, and at step 5 an audit response message including the requested audit information is returned to the auditing party. An example audit response message format 280 is shown in Figure 19.

Persons skilled in the art will appreciate that not all of the modules shown in Figure 2 need be implemented by processor 114. Other implementations are envisaged. For example, the functional modules of Figure 2 may be

implemented in hardware of separate units, or a

combination of hardware and software as separate units. Any practical implementation of these functional units may be employed. In one particular embodiment, for example, the key management and other cryptographic functions (as previously described with reference to Figure 2) may be implemented by a specialised piece of hardware known as a HSM (Hardware Security Module) . As will be understood by persons skilled in the art, a HSM is a form of secure cryptographic processor which has the same internal hardware as a server computer but which is implemented as an external Transmission Control Protocol/Internet

Protocol (TCP/IP) security device.

While the invention has been described with reference to the present embodiment, it will be understood by those skilled in the art that alterations, changes and

improvements may be made and equivalents may be

substituted for the elements thereof and steps thereof without departing from the scope of the invention. In addition, many modifications may be made to adapt the invention to a particular situation or material to the teachings of the invention without departing from the central scope thereof. Such alterations, changes,

modifications and improvements, though not expressly described above, are nevertheless intended and implied to be within the scope and spirit of the invention.

Therefore, it is intended that the invention not be limited to the particular embodiment described herein and will include all embodiments falling within the scope of the independent claims.

In the claims which follow and in the preceding

description of the invention, except where the context requires otherwise due to express language or necessary implication, the word "comprise" or variations such as "comprises" or "comprising" is used in an inclusive sense, i.e. to specify the presence of the stated features but not to preclude the presence or addition of further features in various embodiments of the invention.

Claims

THE CLAIMS DEFINING THE INVENTION ARE AS FOLLOWS:

1. A method implemented by a key broker for facilitating secure communication of data over a communications

network, comprising:

communicating the decryption key K2 to a data

2. A method in accordance with claim 1, wherein the decryption key distribution conditions identify one or more recipients authorised to receive the decryption key, such that the decryption key K2 is communicated to the data recipient responsive to the key broker determining that the data recipient is an authorised recipient.

3. A method in accordance with claim 2, further

comprising receiving a decryption key request message from the data recipient which includes identification data that the key broker evaluates to determine whether they are an authorised recipient.

4. A method in accordance with claim 3, wherein the identification data comprises a PKI certificate utilised by the data recipient to digitally sign the decryption key request message and which is verifiable by the key broker to determine the identity of the data recipient and to validate the contents of the decryption key request message .

5. A method in accordance with claim 3 or 4, wherein the decryption key conditions additionally specify an expiry for the decryption key K2.

6. A method in accordance with any one of the preceding claims, further comprising receiving an update request message from the data owner for updating one or more of the decryption key distribution conditions stored in association with the decryption key K2.

7. A method in accordance with any one of the preceding claims, wherein the encryption key Kl and decryption key K2 are generated in PRCS format.

8. A method in accordance with any one of the preceding claims, wherein encryption of the data by the data owner comprises :

generating a session key SI which is encrypted using encryption key Kl to yield K1(S1);

discarding encryption key Kl leaving SI which is used to encrypt the data yielding SI (data) ; and

discarding SI .

9. A method in accordance with any one of claims 1 to 7, wherein the encryption key Kl is used to directly encrypt the data by the data owner.

10. A method in accordance with any one of the preceding claims, further comprising generating a unique identifier associated with the generated key pair which is

communicated to the data owner with the encryption key Kl and wherein the unique identifier is stored by the key broker in association with the decryption key K2 and decryption key distribution conditions.

11. A method in accordance with claim 10, wherein the encryption key request message further includes a data owner reference for the data to be encrypted and the method further comprises storing the data owner reference in association with the decryption key K2 and the

decryption key distribution conditions.

12. A method in accordance with any one of the preceding claims, wherein the encryption key request message further includes identification data utilised to determine an identifier of the data owner and the method further

comprises storing the identifier in association with the decryption key K2 and the decryption key distribution conditions .

13. A method in accordance with claim 12, wherein the owner identification data comprises a PKI certificate utilised by the data owner to digitally sign the

encryption key request message and which is verifiable by the key broker to determine the data owner identifier and to validate the contents of the encryption key request message prior to generating the key pair.

14. A method in accordance with any one of claims 10 to 13, wherein one or more of the data owner reference, the unique identifier and the owner identifier is provided to the key broker by the data recipient for identifying the decryption key K2.

15. A method in accordance with any one of the preceding claims, further comprising communicating the encryption key Kl to the data owner in an encryption key response message .

16. A method in accordance with claim 15, further comprising digitally signing the encryption key response message with a digital certificate which is validatable by the data owner prior to encrypting the data.

17. A method in accordance with any one of the preceding claims, wherein the encrypted data is uploaded by the data owner to a data storage service for accessing by the data recipient .

18. A method in accordance with claim 17, wherein the data storage service is a cloud based data storage

service .

19. A method in accordance with any one of the preceding claims, wherein the communications network is the

Internet .

20. A method in accordance with any one of the preceding claims, further comprising keeping a log of the encryption and decryption requests and responses associated with a particular key record, the log including an identifier of the owner/recipient and a time the corresponding message was received.

21. A method in accordance with claim 20, further

comprising receiving an audit request message from an audit party identifying a particular key record and providing the audit party with access to the associated log, responsive to determining that the audit party is authorised to access the log.

22. A method in accordance with claim 21, wherein the key encryption request message includes data identifying the parties that are authorised to access the associated log.

23. A key broker service operable to issue cryptographic encryption keys to data owners for use in encrypting data to be communicated over an unsecure communications network and being further operable to issue corresponding

decryption keys to recipients of the encrypted data responsive to determining that one or more decryption key distribution conditions have been met, the conditions being electronically communicated to the key broker service by the data owners when requesting the encryption keys .

24. A key broker service for facilitating secure

communication of data over a communications network, comprising : a key processing module operable to generate a cryptographic key pair Kl, K2 responsive to an encryption key request message being received from a data owner, the key processing module being further arranged to

a key store arranged to store the key K2 in

requesting party prior to issuing the corresponding decryption key thereto.

25. A third party key broker operable to generate a cryptographic key pair consisting of an encryption key and a decryption key responsive to receiving an encryption key request message from a first party, the key broker being further operable to:

communicate the encryption key to the first party for use in encrypting data to be transmitted over an unsecure network;

store the decryption key in a key database maintained by the third party key broker, the private key being stored in association with updatable access control conditions specified by the first party in the request message; and

communicate the decryption key, upon request, to a second party who has received or obtained the encrypted data over the unsecure network provided that the access control conditions have been satisfied.

26. A method for facilitating secure communication of data over a communications network, comprising:

satisfied .

27. A computer program comprising at least one

instruction which, when implemented by a computer system, is operable to implement the method in accordance with any one of claims 1 to 22.

28. A computer readable medium implementing a computer program in accordance with claim 27.