WO2017006118A1

WO2017006118A1 - Secure distributed encryption system and method

Info

Publication number: WO2017006118A1
Application number: PCT/GB2016/052038
Authority: WO
Inventors: Atri SHARMA
Original assignee: Barclays Bank Plc
Priority date: 2015-07-06
Filing date: 2016-07-06
Publication date: 2017-01-12
Also published as: GB2540220A; GB201514674D0

Abstract

Systems and methods for distributed cryptography are described. In an embodiment, an application programming interface (API) is provided for transmitting encryption/decryption requests from one or more client devices over a secure network connection, and for sending each request to a first one of an ordered sequence of cryptographic processing nodes over a secure network connection, wherein each cryptographic processing node in the ordered sequence is configured to perform at least one cryptographic function on received data and to transmit an output to a subsequent computing node in the sequence after removing a portion of the ordered sequence identifying the previous cryptographic processing node.

Description

SECURE DISTRIBUTED ENCRYPTION SYSTEM AND METHOD Field of the Invention

[0001] This invention relates generally to a cryptographic service system, and more particularly to a secure distributed cryptographic service system.

Background

[0002] Cryptographic systems are known in the data processing art. In general, these systems operate by performing an encryption operation on a plaintext input data, typically by using an encryption key and an associated cipher algorithm or cryptographic protocol, and producing a ciphertext output data. The encrypted output data may then be transmitted to and/or stored on an insecure device. The stored message may be decrypted with the corresponding decryption operation, using the same symmetric key or a corresponding asymmetric key, to recover the plaintext data.

[0003] However, such conventional cryptographic systems are prone to security vulnerabilities and typically require frequent maintenance, upgrading or replacement of cryptographic modules to support more robust encryption protocols and to ensure that the encrypted outputs are secure. This can be costly and inconvenient to both system administrators and client end-users. Furthermore, the encrypted outputs would still be prone to interception and hacking/cracking by malicious fraudsters.

[0004] Accordingly, it is desirable to provide a flexible yet robust cryptographic mechanism to provide greater levels of protection of sensitive data.

Summary of the invention

[0005] Aspects of the present invention are set out in the accompanying claims.

[0006] According to one aspect, the present invention provides a cryptographic service system comprising a plurality of interconnected cryptographic processing nodes in a network, wherein an ordered sequence of at least two of said nodes is used to process data in a received cryptography request. Each cryptographic processing node is configured to receive request data including payload data to be encrypted/decrypted and sequence data identifying at least a subsequent cryptographic processing node of the ordered sequence; perform a cryptographic function on the received payload data to generate output data; modify the received sequence data to remove data identifying the cryptographic processing node as a node in the ordered sequence; and transmit the output data and the modified sequence data as request data to the subsequent cryptographic processing node.

[0007] Each cryptographic processing node may be further configured to select one of a plurality of predefined cryptographic functions, wherein said selected cryptographic function is performed on the received payload data to generate output data, generate signature data identifying the selected cryptographic function, and add the signature data to the payload data of the request data transmitted to the subsequent cryptographic processing node.

Each cryptographic processing node may be further configured to process a received decryption request by identifying the data to be decrypted, the signature data, and the sequence data from the received request data, and to determine the cryptographic function that was used to generate the data to be decrypted, wherein the determined cryptographic function is used to decrypt the received data. Each cryptographic processing node may be further configured to provide an interface for the addition or removal of a selectable cryptographic function.

[0008] The cryptographic service system may further comprise a server configured to receive a cryptography request from a client device and in response, to determine an ordered sequence for the cryptography request and generate said sequence data identifying the plurality of cryptographic processing node of the ordered sequence. An application programming interface (API) may be provided to facilitate transmission of the cryptography request from the client device over a secure network connection.

[0009] The server may be further configured as a root cryptographic processing node of the ordered sequence. The server may be further configured to identify a root cryptographic processing node of the ordered sequence, establish a secure network connection with said root node, and transmit said request data to the root node over the secure network connection.

[0010] The sequence data may comprise an ordered set of ordered pairs/tuples defining a directed path through identified ones of the interconnected cryptographic processing nodes in the network. Each cryptographic processing node may be further configured to identify the next cryptographic processing node and to remove data identifying the cryptographic processing node using ordered smallest subset removal on the received sequence data. The server may be further configured to separate the generated sequence data into a plurality of subsets of sequence data based on a predefined reconstruction algorithm. The server may be further configured to reconstruct sequence data associated with a decryption request from a retrieved plurality of subsets of sequence data, using said predefined reconstruction algorithm.

[0011] The server may be further configured to authenticate an identity of the client device and/or an associated user making the request.

[0012] According to another aspect, the present invention provides a system comprising a server coupled to a plurality of computing nodes over a network, wherein the server is configured to determine a sequence of at least some of the computing nodes and to generate sequence data identifying the computing nodes in the sequence, and wherein each computing node in the sequence is configured to perform at least one cryptographic function on received data, to modify received sequence data to remove reference to that particular computing node, and to transmit an output to a subsequent computing node in the sequence, along with the modified sequence data identifying computing nodes in the remaining sequence.

[0013] In yet another aspect, the present invention provides a cryptographic service system comprising an application programming interface (API) for transmitting encryption/decryption requests from one or more client devices over a secure network connection, and for sending each request to a first one of an ordered sequence of cryptographic processing nodes over a secure network connection, wherein each cryptographic processing node in the ordered sequence is configured to perform at least one cryptographic function on received data and to transmit an output to a subsequent computing node in the sequence after removing a portion of the ordered sequence identifying the previous cryptographic processing node, whereby data identifying the ordered sequence is degenerated by each cryptographic processing node.

[0014] In other aspects, there are provided methods of operating the systems as described above. In one aspect, the present invention provides a method of processing data in a received cryptography request using an ordered sequence of interconnected cryptographic processing nodes in a network, the method comprising, by each cryptographic processing node: receiving request data including payload data to be encrypted/decrypted and sequence data identifying at least a subsequent cryptographic processing node of the ordered sequence; performing a cryptographic function on the received payload data to generate partially encrypted/decrypted output data; and transmitting the partially encrypted/decrypted output data as request data to the subsequent cryptographic processing node. The received sequence data may be modified by each cryptographic processing node to remove data identifying the cryptographic processing node as a node in the ordered sequence, and the modified sequence data included in the request data to the subsequent cryptographic processing node.

[0015] In a further aspect, there is provided a computer program comprising machine readable instructions stored thereon arranged to cause a programmable device to become configured as any one of systems as described above.

Brief Description of the drawings

[0016] There now follows, by way of example only, a detailed description of embodiments of the present invention, with references to the figures identified below.

[0017] Figure 1 is a block diagram showing the main components of a distributed cryptography system according to an embodiment of the invention.

[0018] Figure 2 is a block flow diagram schematically illustrating the main components of the

CS server shown in Figure 1.

[0019] Figure 3A is a block flow diagram illustrating the main elements of a cryptographic processing node used in embodiments of the present invention to process a received encryption request. Figure 3B is a corresponding block flow diagram illustrating the main elements of the cryptographic processing node used in embodiments of the present invention to process a received decryption request.

[0020] Figure 4, which comprises Figures 4A and 4B, is a schematic block diagram of the data components of exemplary cryptography requests.

[0021] Figure 5, which comprises Figures 5A to 5C, is a flow diagram of a computer- implemented encryption process using the distributed cryptographic processing nodes, according to an embodiment of the invention. [0022] Figure 6 is a schematic illustration of an exemplary distributed encryption network.

[0023] Figure 7 is a flow diagram of the sub-process of processing an encryption request, shown in Figure 5.

[0024] Figure 8, which comprises Figures 8A to 8C, is a flow diagram of a computer- implemented decryption process using the distributed cryptographic processing nodes, according to an embodiment of the invention.

[0025] Figure 9 is a flow diagram of the sub -process of processing a decryption request, shown in Figure 8.

[0026] Figure 10 is a block diagram of an example of a computer system on which one or more of the functions of the embodiments may be implemented.

Description of Embodiments Overview

[0027] A specific embodiment of the invention will now be described for a process of distributed cryptography using a defined sequence of cryptographic processing nodes. Referring to Figure 1, a distributed cryptography system 1 according to an embodiment comprises a cryptographic service (CS) server 3 in data communication, via one or more data networks 7, with a plurality of cryptographic processing nodes 5-1 to 5-N, forming a distributed cryptography network 6. The cryptographic processing nodes 5 are interconnected, with each node 5 configured to perform a particular cryptographic function on received data to generate encrypted/decrypted data that is passed on to a subsequent cryptographic processing node 5 in a sequence defined by the CS server 3. Advantageously, each cryptographic processing node 5 may implement a plug-and-play mechanism that allows a wide variety of encryption protocols to be flexibly implemented, for example one or more algorithms complying with the Digital Encryption Standard ("DES") or Advanced Encryption Standard ("AES"), with respective different cryptographic hashing functions, such as MD4, MD5, SHA-1, SHA-2 or the like, to generate respective partial hash output values based on received input data. The processed data output by each node 5 may be considered partially encrypted or decrypted in the context of the distributed cryptography network 6 as a whole, whereby the original data is wholly encrypted or decrypted after sequential processing by each cryptographic processing node 5 in the defined sequence.

[0028] One or more applications 9 on respective client devices 11 may call the CS server 3 via an API 13 to request cryptographic services. For example, an encryption client 11a may transmit an cryptography request token (i.e. data message) to the CS server 3, the request token including data identifying an encryption type request and cleartext data 15 (i.e. original plaintext data) to be encrypted by the cryptography service. Similarly, a decryption client l ib may transmit an cryptography request token to the CS server 3, the request token including data identifying an encryption type request and ciphertext data 17 (i.e. data that was encrypted by the cryptography service) to be decrypted by the cryptography service. Although the encryption and decryption clients 11 are illustrated as separate devices in Figure 1, it will be appreciated that a single client device may be configured to transmit both types of cryptography requests via the API 13. The call/request may be wrapped using various access protocols, Simple Object Access Protocol (SOAP) for example. The request may include a data authentication mechanism and is preferably sent via a confidential link e.g. HTTPS. API command confidentiality and integrity may be protected, for example using transport layer security (TLS), secure sockets layer (SSL), or the like.

[0029] The encryption client 11a and decryption client l ib may be any type of computing devices, such as a personal computer, a laptop, a computing terminal, a smart phone, a tablet computer, or the like, in electronic communication with the CS server 3 via the data network 7. The data network 7 may be any suitable data communication network or combination of networks, such as a wireless network, a local- or wide-area network including a corporate intranet or the Internet, using for example the TCP/IP protocol, or a cellular communication network such as Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), CDMA2000, Enhanced Data Rates for GSM Evolution (EDGE), Evolved High-Speed Packet Access (HSPTA+), Long Term Evolution (LTE), etc.

[0030] Figure 2 is a block flow diagram schematically illustrating the main components of the CS server 3 used in embodiments of the present invention. As shown, the CS server 3 includes a request handler 21 that receives and responds to a cryptography request received from a client device 11 via a network interface 23. The CS server 3, upon receiving the call, may check the identity of a user and/or the device 11 making the request, for example by authentication of identification data provided in the request, or in response to an ID verification sub -process. The request handler 21 generates a request token 27 based on the received cryptography request, the request token 27 including sequence data 29 defining an ordered set of cryptographic processing nodes 5 in the distributed cryptography network 6. A sequence generator 25 of the CS server 3 generates the sequence data 23 by determining a sequence of at least some of the cryptographic processing nodes 5-1 to 5-N that will be used to process the cryptography request. The request token 27 and associated sequence data 29 may be stored in a secure database 31 of the CS server 3. A copy of the sequence data 29a may be stored securely by a decryption client l ib. The request token 27 may include data identifying the associated client device 11 that the cryptographic output will be transmitted in response. In this embodiment, the request handler 21 transmits the request token 27 to a root cryptographic processing node 5 of the determined sequence via the network interface 23, to initiate processing of the cryptography request by the distributed cryptography network 6. The request handler 21 may receive encrypted/decrypted data from a final cryptographic processing node 5 of the determined sequence via the network interface 23, and transmit a response back to the requesting client 11 with the received encrypted/decrypted data.

[0031] The main elements of a cryptographic processing node 5 used in embodiments of the present invention will now be described, with reference to the block flow diagram of Figure 3A illustrating the main elements used to process a received encryption request and to the corresponding block flow diagram of Figure 3B illustrating the main elements used in embodiments of the present invention to process a received decryption request. Reference is also made to Figure 4, which comprises Figure 4A and 4B, schematically illustrating the data components of exemplary cryptography requests.

[0032] Each cryptographic processing node 5 includes a request processor 31 configured to process a request token 27 received from the CS server 3 or from another node 5 via a network interface 33. As shown in Figure 4 A, an exemplary request token 27 received by a root node 5 of the sequence from the CS server 3 may include data 2 identifying the type of the request, such as an encryption or decryption request, a payload data portion 4 including the cleartext data 15 that is to be encrypted or the ciphertext data 17 that is to be decrypted, and the sequence data 29 identifying the determined sequence of cryptographic processing nodes 5 of the distributed cryptography network 101 associated with the request 27. As shown in Figure 4B, the received request at this stage of the sequence includes modified sequence data 29', identifying a remaining portion of the original sequence of cryptographic processing nodes 5 associated with the request 27. Additionally, the payload data portion 4-1 of the exemplary request token 27 received by a subsequent node 5, in this example the fourth node in the sequence, may further include partial hash data 15'-1 and an associated hash signature 6-1 output by the previous node in the sequence, i.e. the third node in the sequence. The partial hash data 15'-1 output by the third node in the sequence may include a partial payload data portion 4-2 output by the node preceding the third node in the sequence, i.e. the second node in the sequence. The partial payload data portion 4-2 output by the second node in the sequence may itself include a partial hash data portion 15'-2 and an associated hash signature 6-2 generated by the second node. Similarly, the partial hash data portion 15'-2 output by the second node in the sequence may include a partial payload data portion 4-3 output by the root node, this partial payload data portion 4-3 in turn including partial hash data 15'-3 and an associated hash signature 6-3 generated by the root node. In this way, the payload data 4 output by the final cryptographic processing node 5 in the defined sequence may include the final encrypted ciphertext 17 and an associated hash signature 6.

[0033] Referring back to Figure 3A, the received data to be encrypted is processed by an encryption/decryption module 35, using a cryptographic function selected by a hash function determiner 37 from a predefined set of cryptographic functions 39, to output a partial hash value 15' of the received data. In this exemplary embodiment, the cryptographic functions are cryptographic hash functions to generate respective partial hash output values based on received input data. It will be appreciated that the cryptographic processing nodes may each be independently configured to flexibly implement any number and/or type of suitable encryption protocols and/or algorithms that are reversible and repeatable. the hash function determiner 37 is also configured to generate a hash signature 6 of the selected cryptographic function, for example using a predefined inverse set selection function to encode an identifier of the cryptographic function that was used by that particular node to generate the partial hash value 15 ' . The set of hash functions 39 is preferably, although not necessarily, a universal hash family. As is known in the art, a universal hash family is a family of hash functions that, when chosen randomly and combined together, form a near perfect outcome, whereby a unique value is output for each unique input. In mathematical terms, a family of functio is called a universal

The hash functions may be invertible to form a two-way hash family, or non-invertible to form a one-way hash family.

[0034] In this embodiment, a request generator 43 of the cryptographic processing node 5 is configured to output a new or modified request token 27 including output data in the payload data portion 4 that is to be processed by the next cryptographic processing node 5 in the received sequence. The output data in the payload data portion 4 includes the partial hash value calculated by the encrypti on/decrypti on module 35, and a hash signature of the selected hash function generated by the hash function determiner 37, for example provided by a combiner 40 configured to append the hash signature to the partial encrypted output. The new or modified request token 27 also includes data identifying the modified sequence 29' output by a sequence modifier 41. The sequence modifier 41 processes the received sequence data 29 from the request token 27 received by the request processor 31 to identify the next cryptographic processing node 5 in the received sequence. The sequence modifier 41 also removes the element identifying that particular cryptographic processing node 5 as the current node in the sequence, for example using ordered smallest subset removal on the received ordered set data, and outputs the modified sequence data 29' to the request generator 43. The request generator 43 transmits the new or modified request token 27 to the identified next cryptographic processing node 5 via the network interface 33. Additionally, the request generator 43 may be configured to transmit the payload data 4 to the CS server 3 when it is determined that the present cryptographic processing node 5 is the final node in the received sequence. Alternatively, the final processing node 5-5 may be configured to output the tokenized response including the final payload data 4 to the original requesting client 11.

[0035] Referring to Figure 3B, the encryption/decryption module 31 of each cryptographic processing node 5 is also configured to process a decryption request token 27 received from the CS server 3 or from another node 5. In this example, the received payload data 4 that is to be processed includes the hash signature 6 corresponding to the hash function that was used by the last node in the associated sequence 27a to generate the received partial hash data, this being the first node in the sequence to decrypt the ciphertext 17. The received partial hash data is processed by the encryption/decryption module 35, using a hash function determined by the hash function determiner 37 from the received hash signature 6. For example, the hash function determiner 37 may be configured to determine an invertible hash function of the stored family of two-way universal hash functions 39, based on the received hash signature and a predefined inverse set selection function. Alternatively, a table lookup may be implemented to determine one of a plurality of non-invertible hash functions 39.

[0036] Advantageously, the technique allows for path -based security using set theory and graph algorithms, facilitating a distributed hashing/encryption mechanism which allows for no single point of failure or compromise. System administrators may be allowed to access individual nodes and perform maintenance operations without the risk of exposing access to cleartext and encryption keys. Moreover, no single point within the distributed cryptography network 101 is aware of whether that particular node is dealing with cleartext, partial ciphertext or fully encrypted ciphertext. In this way, tokenization is processed in a distributed manner and using multiple pipelined hash functions that are randomly chosen from a set of hash functions, whereby the pipeline history, i.e. the defined sequence of cryptographic processing nodes for a particular session, is not transmitted from one processing node to subsequent processing nodes. This ensures that the security of final tokenized output is based on two things:

- Multi pipelined hash functions chosen at random, hence ensuring that it is mathematically impossible to reconstruct hash cleartext in a reasonable amount of time. The pipelined hash functions need to be executed in a fixed order, which is also determined securely and secretly at runtime, hence ensuring that even if hash functions are known, it is not possible to reconstruct hash cleartext. Encryption Process

[0037] An overview has been given above of the components forming part of the distributed cryptography system 1 of this embodiment. A more detailed description of the operation of these components in this embodiment will now be given with reference to the flow diagrams of Figure

5, which comprises Figures 5A to 5C, for an example computer-implemented encryption process using the distributed cryptographic processing nodes 5. Reference is also made to an exemplary distributed cryptography network 101 schematically illustrated in Figure 6.

[0038] As shown in Figure 5A, the process begins at step S5-1 where the encryption client 11a establishes a secure connection with the CS server 3 over the data network 7. For example, the application 9a may initiate a call to the API 13a. At step S5-3, the encryption client 11a transmits a request token to the CS server 3 over the established secure connection, the request token including the original cleartext data 15 to be encrypted by the cryptographic service. The request token is received by the request handler 21 of the CS server 3 at step S5-5 and in response, the sequence generator 25 generates sequence data 29 for the received request at step S5-7, based on a determined sequence of at least some of the cryptographic processing nodes 5-1 to 5 -N that will be used to process the cryptography request.

[0039] Figure 6 is a schematic illustration of an exemplary distributed cryptography network 101 formed by five cryptographic processing nodes 5-1 to 5-5. In this example, the nodes 5 are all interconnected to each other, forming a totally connected graph. Each path or edge 33 between respective nodes 5 may be associated with equal cost, thereby initially providing no distinction between any two paths 33 of the graph. It will be appreciated that any number of cryptographic processing nodes 5 may be provided in the network 101, and the graph may not be totally connected nor have paths 33 of equal cost. Additionally, nodes 5 in the distributed cryptography network 101 may be used multiple times in the same encryption/decryption sequence.

[0040] In one embodiment, the CS server 3 determines the sequence at step S5-7 by assigning random weights to all edges in the graph, generating a minimum spanning tree (MST) for the weighted graph, deriving a directed path from the MST, and splitting the directed path into pairs of ordered nodes that form an ordered set of the sequence data 29. In the example illustrated in Figure 6, the directed path through the graph is

c -> a -> b -> e -> d,

where the sequence starts from a root node 5-1 labelled "c", followed by a second node 5-2 labelled "a" along path 31-1, followed by a third node 5-3 labelled "b" along path 33-2, followed by a fourth node 5-4 labelled "e" along path 33-3, and finally ending at a fifth node 5-5 along path 33-4. The ordered pairs/tuples for the exemplary directed path {c,a,b,e,d} may be determined to be

E = { {c}, {a,c}, {a,b,c}, {a,b,c,e}, {a,b,c,d,e} },

where E is the ordered set of the sequence data 29. It will be appreciated the sequence data 29 may instead define the ordered sequence of nodes 5 using any other suitable data format, such as a linear array of ordered elements. Advantageously, the use of ordered pairs/tuples allows specific axioms to be applied, for example facilitating calculation on the sequence data to be processed to remove nodes from the set, and/or splitting the ordered set into independent subsets, without involving indices or keys, as will be described below. Additionally, the number of cryptographic processing nodes 5 in a determined sequence may be pre-defined by the system 1, with inherent security and robustness of the cryptography service increasing with each additional node in a sequence.

[0041] At step S5-9, the request token 27 and associated sequence data 29 may be stored in a secure database 31 of the CS server 3. For example, the data may be securely stored as part of registered user data maintained by the CS server 3, for subsequent retrieval by the CS server 3 to handle a decryption request from the same user or client device 11. The sequence data 29a may also be securely communicated to a decryption client 11a, for example via a communication path, channel or means that is separate and disassociated with the secure connection established between the encryption client 11 a and the CS server 3. The sequence data 29 may be further secured by separating the ordered set into independent subsets using a predefined construction/reconstruction algorithm. For example, based on the axiom of specification, independent subsets A and B may be defined for ordered set E: E = A ^χ B

where A ^χ B is the Cartesian product of subsets A and B. Each subset A and B may be stored separately, thereby ensuring greater security in the event of fraudulent access to either subset A or B. Furthermore, even if a fraudster was able to obtain both subsets A and B, the original sequence data would not be re-constructible without knowledge of the reconstruction algorithm, e.g. the Cartesian product in the above example. At runtime, ordered set E may be reconstructed by the CS server 3 from the retrieved subset data.

[0042] At step S5-11, the CS server 3 identifies the root node 5 of the generated sequence. Following from the above example, the request handler 21 may identify the root node 5-1 from the smallest set in the sequence E, containing the single element {c}. At step S5-13, the CS server 3 established a secure connection with the identified root node 5. At step S5-15, the request handler 21 transmits the request token 27 to the identified root cryptographic processing node 5, to initiate encryption of the original data 15 by the distributed cryptography network 101. The request token 27 may include data identifying the CS server 3 that is handling the request token 27, for the final cryptographic processing node 5 of the determined sequence to transmit the wholly encrypted data 17, as will be discussed below.

[0043] At step S5-17, the root cryptographic processing node 5-1, labelled "c" in the working example with reference to Figure 6, receives the encryption request token 27, including the original data 15 to be encrypted and the generated sequence data 29, from the CS server 3. At step S5-19, the root node 5-1 processes the received encryption request token 27 and outputs partially encrypted data for transmission to the next cryptographic processing node 5 of the determined sequence, the partially encrypted data including output from the encryption/decryption module 35 and the hash signature generated by the hash function determiner 37.

[0044] The sub-process of processing the encryption request token 27 is described in more detail with reference to the flow diagram of Figure 7. As shown, at step S7-1, the request processor 31 of the hash function cryptographic processing node 5 identifies the data to be encrypted and the sequence data 29 from the received request token 27. The data to be encrypted is passed to the encryption/decryption module 35 and the received sequence is passed to the sequence modifier 41. At step S7-3, the hash function determiner 37 selects a cryptographic hash function from the stored family of universal hash functions 39 defined for that particular cryptographic processing node 5, and generates a hash signature based on the selected hash function at step S7-5.

[0045] Purely by way of a simplified example, let the universal hash family H on one particular node be defined as

H = {H1, H2, H3, H4, H5}

where each member represents a single hash function.

[0046] Consider an invertible mathematical function on each node:

f(x) = x + 3

f~(x) = x -3

Each node may be associated with an independent invertible mathematical function that is secret.

[0047] The hash signature is a unique identification of a hash function in its universal hash family on specific node. In this simplified example, the hash signatures are defined as integers that are iteratively assigned to each hash function in the whole universal hash family of a specific node:

for (i = 1; i < = size (universal hash family); i++)

f

Hash signature fij =f(i);

}

[0048] Suppose hash function H3 is randomly selected by the hash function determiner 37 of a particular cryptographic processing node 5 to process encryption of received data. At step S7-7, the encryption/decryption module 35 generates partial encrypted output using the selected cryptographic hash function. In the present example, output from current node 5 may be:

{H3(D), 6}

where H3(D) is the partial ciphertext output by the encryption/decryption module 35 after processing received data D using a selected third one H3 of the set of hash functions H, followed by the hash signature "6", calculated by the defined function f(x) = x + 3, where x is 3 for the selected function H3. [0049] In decryption of received data by the same cryptographic processing node 5, the received hash signature "6" would be passed to the hash function determiner 37 to identify the third hash function H3, using the inverse set selection function f~(x) to determine that x=3.

[0050] At step S7-9, the sequence modifier 41 of the cryptographic processing node 5 processes the received sequence data 29 to identify the next node in the remaining portion of the ordered sequence, and modifies the received sequence data 29 to remove the current root node from the sequence at step S7-11. Alternatively, the node 5 may determine at step S6-9 that it is the final processing node 5 in the sequence. Steps S7-9 and S7-11 performed by the sequence modifier 41 may be calculated using ordered smallest subset removal on the ordered set E. In the present worked example, the root node 5-1 may calculate the intersection of the smallest element of E, {c}, with the second smallest element of E, {a,c}, to identify the next node as {a}. The root node 5-1 removes itself from the ordered set E, by removing the smallest member of E, which is {c} in this example, leaving the remaining sequence as modified order set

E' = { {a,c}, {a,b,c}, {a,b,c,e}, {a,b,c,d,e} } .

[0051] Referring back to Figure 5, at step S5-21, the request generator 43 generates a subsequent request token, for example based on the received request token and including the modified sequence data generated at step S7-11, along with partial encrypted data including the output from the encryption/decryption module 35 at step S7-7 and the hash function signature output by the hash function determiner 37 at step S7-5. Alternatively, the request generator 43 may be configured to forward a modified version of the received request token, with replacement sequence data and data to be encrypted by the next node. At step S5-23, the subsequent request token is transmitted by the root node 5-1 to the next cryptographic processing node 5, as identified at step S7-9. Each cryptographic processing node 5 may establish a secure network connection to the next node 5, but it will be appreciated that enhanced security of the transmission channel between processing nodes 5 in the distributed cryptography network 101 can be omitted since the present embodiment advantageously provides a mechanism whereby data intercepted at this point, between any subsequent cryptographic processing nodes, is incomplete and meaningless to a fraudster. [0052] At step S5-25, the next cryptographic processing node 5, this being the second node 5-2 labeled "a" in the example shown in Figure 6, receives the subsequent request token from the root node 5-1 and processes the encryption request at step S5-27. In a similar sub-process as described above with reference to Figure 7, each subsequent cryptographic processing node 5 of the determined sequence processes a received encryption request, removes itself from the received modified sequence, and outputs the remaining portion of the modified sequence along with the further encrypted data in a request token for processing by the next cryptographic processing node 5. For example, the second node 5-2 labelled "a" identifies the next node as "b", from the intersection of the smallest element of the received modified sequence E', {a,c}, with the second smallest element of E', {a,b,c}. The smallest element of E' is removed by the second node 5-2 and the resulting further modified sequence

E' = { {a,b,c}, {a,b,c,e}, {a,b,c,d,e} } .

is included in the request token to the identified next cryptographic processing node 5.

[0053] At step S5-29, the request generator 43 of the next cryptographic processing node 5 determines if there is another cryptographic processing node 5 in the received sequence. If it determined that there is another cryptographic processing node 5 in the received sequence, then at step S5-31, a further subsequent request token is generated by the request generator 43 and transmitted to the identified next node 5, similar to steps S5-21 and S5-23 discussed above. Processing returns to step S5-25 where the request token is received by the next cryptographic processing node 5 in the remaining portion of the sequence.

[0054] On the other hand, if it is determined at step S5-29 that there are no further nodes in the remaining portion of the received sequence, then at step S5-33, the final processing node 5 may transmit a response with the final encrypted output back to the CS server 3. It will be appreciated that the encrypted output data from step S7-7 of the current iteration will be the fully encrypted version of the original ciphertext (or fully decrypted version in the case of the counter-part decryption process described below), as this is the final cryptographic processing node 5 in the original sequence For example, the final node 5-5 labelled "d" in the example shown in Figure 6, processes the received request token, including a modified sequence E' having a single remaining element, {a,b,c,d,e}, and returns the wholly encrypted data output from its encryption/decryption module 35 back to the CS server 3.

[0055] At step S5-39, the CS server 3 receives the response from the final cryptographic processing node 5. At step S5-41, the CS server 3 returns to the API 13a of the encryption client 11a the final encrypted data, in response to the call/request to initiate the encryption process, which is passed to the calling application 9a at step S5-43.

Decryption Process

[0056] Figure 8, which comprises Figures 8A to 8C, is a flow diagram illustrating the inter- related computer-implemented decryption process using the distributed cryptographic processing nodes 5, according to an embodiment. As shown in Figure 8 A, the process begins at step S8-1 where the decryption client 1 lb establishes a secure connection with the CS server 3 over the data network 7. For example, the application 9b may initiate a call to the API 13b. At step S8-3, the decryption client 1 lb transmits a request token to the CS server 3 over the established secure connection, the request token including the encrypted data 17 to be decrypted by the cryptographic service. The request token is received by the request handler 21 of the CS server 3 at step S8-5 and in response, retrieves stored sequence data 29 associated with the received decryption request at step S8-7. For example, the sequence data 29 may be retrieved from a secure registered user database 31 and/or from sequence data 29a securely communicated to the CS server 3 from the decryption client 1 lb via a communication path, channel or means that is separate and disassociated with the secure connection established between the decryption client l ib and the CS server 3.

[0057] At step S8-9, the CS server 3 identifies the root node of the retrieved sequence, in a similar way to the processing described at step S5-11 above. At step S8-11, the CS server 3 established a secure connection with the identified root node 5. At step S8-13, the request handler 21 transmits the request token 27 to the identified root cryptographic processing node 5, to initiate encryption of the original data 15 by the distributed cryptography network 101. The request token 27 may include data identifying the CS server 3 that is handling the request token 27, for the final cryptographic processing node 5 of the determined sequence to transmit the wholly encrypted data 17, as will be discussed below. At step S8-15, the root cryptographic processing node 5-1 receives the decryption request token 27, including the original ciphertext 17 to be decrypted and the associated sequence data 29, from the CS server 3. At step S8-17, the root node 5-1 processes the received decryption request token 27 and outputs partially decrypted data for transmission to the next cryptographic processing node 5 of the remaining portion of the sequence, the partially decrypted data including output from the encryption/decryption module 35 of the root cryptographic processing node 5-1.

[0058] The sub-process of processing the decryption request token 27 is described in more detail with reference to the flow diagram of Figure 9. As shown, at step S9-1, the request processor 31 of the hash function cryptographic processing node 5 identifies the data to be decrypted, the associated hash signature of the hash function that was used to encrypted the received ciphertext, and the sequence data 29, from the received request token 27. The data to be decrypted is passed to the encryption/decryption module 35, the hash signature is passed to the hash function determiner 37, and the received sequence is passed to the sequence modifier 41. At step S9-3, the hash function determiner 37 determines the cryptographic hash function from the stored family of universal hash functions 39 defined for that particular cryptographic processing node 5, based on the received hash signature identified at step S9-1. For example, the hash function may be determined using the predefined inverse set selection function or lookup table.

[0059] At step S9-5, the encryption/decryption module 35 generates partial decrypted output using the cryptographic hash function determined at step S9-3. The encryption/decryption module 35 may be configured to verify that the received hash signature matches a hash signature re-generated by the hash function determiner 37 before proceeding with the decryption process. At step S9-7, the sequence modifier 41 of the cryptographic processing node 5 identifies the next node in the received sequence data, in a similar manner to step S7-9 described above. Alternatively, the node 5 may determine that it is the final processing node 5 in the sequence. At step S9-9, the sequence modifier 41 modifies the received sequence data 29 to remove the current root node from the sequence, in a similar manner to step S7-11 described above.

[0060] Referring back to Figure 8, at step S8-19, the request generator 43 generates a subsequent request token, for example based on the received request token and including the modified sequence data generated at step S8-9, along with partial decrypted data that is output from the encryption/decryption module 35 at step S8-5. It will be appreciated that the partial decrypted data will include a further portion of data to be decrypted by the next node in the sequence, along with an associated hash signature. Alternatively, the request generator 43 may be configured to forward a modified version of the received request token, with replacement sequence data and the output data to be processed by the next node. At step S8-21, the subsequent request token is transmitted by the root node 5-1 to the next cryptographic processing node 5, as identified at step S8-7. At step S8-23, the next cryptographic processing node 5, this being the second node 5 -2 in the present example, receives the subsequent request token from the root node 5-1 and processes the received decryption request at step S8-25. In a similar sub-process as described above with reference to Figure 9, each subsequent cryptographic processing node 5 of the associated sequence processes a received decryption request, removes itself from the received modified sequence, and outputs the remaining portion of the modified sequence along with the further decrypted data in a request token for processing by the next cryptographic processing node 5.

[0061] At step S8-27, the request generator 43 of the next cryptographic processing node 5 determines if there is another cryptographic processing node 5 in the received sequence. If it determined that there is another cryptographic processing node 5 in the received sequence, then at step S8-29, a further subsequent request token is generated by the request generator 43 and transmitted to the identified next node 5, similar to steps S8-19 and S8-21 discussed above. Processing returns to step S8-23 where the decryption request token is received by the next cryptographic processing node 5 in the remaining portion of the sequence. On the other hand, if it is determined at step S8-27 that there are no further nodes in the remaining portion of the received sequence, then at step S8-31, the final processing node 5 may transmit a response with the final decrypted output back to the CS server 3. A secure connection between the final node 5 and the CS server 3 may be established at this step, to provide an additional level of security for transmission of the response including the fully decrypted cleartext. At step S8-33, the CS server 3 receives the response from the final cryptographic processing node 5 and returns to the API 13b of the decryption client l ib the cleartext in response to the call/request, at step S8-35, which is passed to the calling application 9a at step S8-37. Computer Systems

[0062] The servers, nodes and entities, and associated processing modules and blocks described herein, such as the CS server 3, cryptographic processing nodes 5 and client devices 11 may be implemented by respective computer systems such as computer system 1000 as shown in Figure 10 with execution by such computer systems 1000. After reading this description, it will become apparent to a person skilled in the art how to implement the invention using other computer systems and/or computer architectures and other signal processing hardware.

[0063] Computer system 1000 includes one or more processors, such as processor 1004. Processor 1004 may be any type of processor, including but not limited to a special purpose or a general -purpose digital signal processor. Processor 1004 is connected to a communication infrastructure 1006 (for example, a bus or network). Various software implementations are described in terms of this exemplary computer system. After reading this description, it will become apparent to a person skilled in the art how to implement the invention using other computer systems and/or computer architectures and other signal processing hardware.

[0064] Computer system 1000 also includes a user input interface 1003 connected to one or more input device(s) 1005 and a display interface 1007 connected to one or more display(s) 1009. Input devices 1005 may include, for example, a pointing device such as a mouse or touchpad, a keyboard, a touchscreen such as a resistive or capacitive touchscreen, etc. After reading this description, it will become apparent to a person skilled in the art how to implement the invention using other computer systems and/or computer architectures, for example using mobile electronic devices with integrated input and display components.

[0065] Computer system 1000 also includes a main memory 1008, preferably random access memory (RAM), and may also include a secondary memory 610. Secondary memory 1010 may include, for example, a hard disk drive 1012 and/or a removable storage drive 1014, representing a floppy disk drive, a magnetic tape drive, an optical disk drive, etc. Removable storage drive 1014 reads from and/or writes to a removable storage unit 1018 in a well-known manner. Removable storage unit 1018 represents a floppy disk, magnetic tape, optical disk, etc., which is read by and written to by removable storage drive 1014. As will be appreciated, removable storage unit 1018 includes a computer usable storage medium having stored therein computer software and/or data.

[0066] In alternative implementations, secondary memory 1010 may include other similar means for allowing computer programs or other instructions to be loaded into computer system 1000. Such means may include, for example, a removable storage unit 1022 and an interface 1020. Examples of such means may include a program cartridge and cartridge interface (such as that previously found in video game devices), a removable memory chip (such as an EPROM, or PROM, or flash memory) and associated socket, and other removable storage units 1022 and interfaces 1020 which allow software and data to be transferred from removable storage unit 1022 to computer system 1000. Alternatively, the program may be executed and/or the data accessed from the removable storage unit 1022, using the processor 1004 of the computer system 1000.

[0067] Computer system 1000 may also include a communication interface 1024. Communication interface 1024 allows software and data to be transferred between computer system 1000 and external devices. Examples of communication interface 1024 may include a modem, a network interface (such as an Ethernet card), a communication port, a Personal Computer Memory Card International Association (PCMCIA) slot and card, etc. Software and data transferred via communication interface 1024 are in the form of signals 1028, which may be electronic, electromagnetic, optical, or other signals capable of being received by communication interface 1024. These signals 1028 are provided to communication interface 1024 via a communication path 1026. Communication path 1026 carries signals 1028 and may be implemented using wire or cable, fibre optics, a phone line, a wireless link, a cellular phone link, a radio frequency link, or any other suitable communication channel. For instance, communication path 1026 may be implemented using a combination of channels.

[0068] The terms "computer program medium" and "computer usable medium" are used generally to refer to media such as removable storage drive 1014, a hard disk installed in hard disk drive 1012, and signals 1028. These computer program products are means for providing software to computer system 1000. However, these terms may also include signals (such as electrical, optical or electromagnetic signals) that embody the computer program disclosed herein.

[0069] Computer programs (also called computer control logic) are stored in main memory 1008 and/or secondary memory 1010. Computer programs may also be received via communication interface 1024. Such computer programs, when executed, enable computer system 1000 to implement embodiments of the present invention as discussed herein. Accordingly, such computer programs represent controllers of computer system 1000. Where the embodiment is implemented using software, the software may be stored in a computer program product 1030 and loaded into computer system 1000 using removable storage drive 1014, hard disk drive 1012, or communication interface 1024, to provide some examples.

[0070] Alternative embodiments may be implemented as control logic in hardware (e.g. dedicated circuitry, processors, chips, etc.), firmware, or software or any combination thereof.

Alternatives and Modifications

[0071] It will be understood that embodiments of the present invention are described herein by way of example only, and that various changes and modifications may be made without departing from the scope of the invention.

[0072] For example, in the embodiments described above, the CS server is configured to define an associated sequence of cryptographic processing nodes for each encryption request. A subsequent encryption request token is then transmitted to a root node of the defined sequence for initial partial encryption of the original cleartext. As those skilled in the art will appreciate, the CS server may itself be configured with the processing functionality of a cryptographic processing node. In such an alternative, the CS server may be set as the root node of the determined sequence and to generate partial encrypted output for transmission to the next node in the sequence. Advantageously, no subsequent node in the distributed cryptography network will be aware of the entire defined sequence, as the predecessors, such as the CS server acting as a root node in this alternative, are removed from the sequence data prior to onward transmission to the next node. In a further alternative, the CS server may instead or additionally be set as the final node of the determined sequence and to generate the fully decrypted cleartext for direct transmission back to the decryption client.

[0073] In the embodiments described above, the original data is processed by a sequence of independent nodes of the distributed cryptography network, each node applying its own randomly selected cryptographic hash function, and passing the cryptographic result as payload data to the next node in the sequence for subsequent processing. As those skilled in the art will appreciate, the pipelined hash functions implemented by a determined sequence of nodes may be related. For example, each node in the sequence may be assigned or associated with a respective portion of the original data to be encrypted/decrypted.

[0074] In the embodiments described above, the encryption/decryption module of a cryptographic processing node is configured to process received data using a selected cryptographic function and to output a partial encrypted/decrypted version of the received data. As those skilled in the art will appreciate, each cryptographic processing node may be further configured to provide a plug-and-play interface to facilitate the addition or removal of one or more stored, selectable cryptographic functions.

[0075] Alternative embodiments may be envisaged, which nevertheless fall within the scope of the following claims.

Claims

1. A cryptographic service system comprising a plurality of interconnected cryptographic processing nodes in a network, wherein an ordered sequence of at least two of said nodes is used to process data in a received cryptography request, each cryptographic processing node configured to: receive request data including payload data to be encrypted/decrypted and sequence data identifying at least a subsequent cryptographic processing node of the ordered sequence; perform a cryptographic function on the received payload data to generate output data; modify the received sequence data to remove data identifying the cryptographic processing node as a node in the ordered sequence; and transmit the output data and the modified sequence data as request data to the subsequent cryptographic processing node.

2. The cryptographic service system of claim 1, wherein each cryptographic processing node is further configured to: select one of a plurality of predefined cryptographic functions, wherein said selected cryptographic function is performed on the received payload data to generate output data; generate signature data identifying the selected cryptographic function; and add the signature data to the payload data of the request data transmitted to the subsequent cryptographic processing node.

3. The cryptographic service system of claim 2, wherein each cryptographic processing node is further configured to process a received decryption request by identifying the data to be decrypted, the signature data, and the sequence data from the received request data, and to determine the cryptographic function that was used to generate the data to be decrypted, wherein the determined cryptographic function is used to decrypt the received data.

4. The cryptographic service system of claim 2 or 3, wherein each cryptographic processing node is further configured to provide an interface for the addition or removal of a selectable cryptographic function.

5. The cryptographic service system of any preceding claim, further comprising a server configured to receive a cryptography request from a client device and in response, to determine an ordered sequence for the cryptography request and generate said sequence data identifying the plurality of cryptographic processing node of the ordered sequence.

6. The cryptographic service system of claim 5, further comprising an application programming interface, API, to facilitate transmission of the cryptography request from the client device over a secure network connection.

7. The cryptographic service system of claim 5, wherein the server is further configured as a root cryptographic processing node of the ordered sequence.

8. The cryptographic service system of claim 5, wherein the server is further configured to identify a root cryptographic processing node of the ordered sequence, establish a secure network connection with said root node, and transmit said request data to the root node over the secure network connection.

9. The cryptographic service system of any preceding claim, wherein the sequence data comprises an ordered set of ordered pairs/tuples defining a directed path through identified ones of the interconnected cryptographic processing nodes in the network.

10. The cryptographic service system of claim 9, wherein each cryptographic processing node is further configured to identify the next cryptographic processing node and to remove data identifying the cryptographic processing node using ordered smallest subset removal on the received sequence data.

11. The cryptographic service system of claim 9, wherein the server is further configured to separate the generated sequence data into a plurality of subsets of sequence data based on a predefined reconstruction algorithm.

12. The cryptographic service system of claim 11, wherein the server is further configured to reconstruct sequence data associated with a decryption request from a retrieved plurality of subsets of sequence data, using said predefined reconstruction algorithm.

13. The cryptographic service system of claim 5, wherein the server is further configured to authenticate an identity of the client device and/or an associated user making the request.

14. A cryptography service server coupled to a plurality of computing nodes over a network, wherein the server is configured to determine a sequence of at least some of the computing nodes and to generate sequence data identifying the computing nodes in the sequence, and wherein each computing node in the sequence is configured to perform at least one cryptographic function on received data, to modify received sequence data to remove reference to that particular computing node, and to transmit an output to a subsequent computing node in the sequence, along with the modified sequence data identifying computing nodes in the remaining sequence.

15. A system comprising an application programming interface (API) for transmitting encryption/decryption requests from one or more client devices over a secure network connection, and for sending each request to a first one of an ordered sequence of cryptographic processing nodes over a secure network connection, wherein each cryptographic processing node in the ordered sequence is configured to perform at least one cryptographic function on received data and to transmit an output to a subsequent computing node in the sequence after removing a portion of the ordered sequence identifying the previous cryptographic processing node, whereby data identifying the ordered sequence is degenerated by each cryptographic processing node.

16. A cryptographic service method to process data in a received cryptography request using an ordered sequence of interconnected cryptographic processing nodes in a network, the method comprising the computer -implemented steps, by each cryptographic processing node, of: receiving request data including payload data to be encrypted/decrypted and sequence data identifying at least a subsequent cryptographic processing node of the ordered sequence; performing a cryptographic function on the received payload data to generate partially encrypted/decrypted output data;; and transmitting the partially encrypted/decrypted output data as request data to the subsequent cryptographic processing node.

17. A storage medium comprising machine readable instructions stored thereon for causing a computer system to perform a method in accordance with claim 16, or to become configured as the cryptographic service system of any one of claims 1 to 13.

18. A computer system substantially as hereinbefore described with reference to, or as illustrated in Figures 1, 2, 3A, 3B and 10 of the accompanying drawings.

19. A method substantially as hereinbefore described with reference to, or as illustrated in Figures 4A, 4B, 4C and 6, or Figures 7A, 7B, 7C and 8 of the accompanying drawings.