WO2013044307A1

WO2013044307A1 - A system and method for distributing secured data

Info

Publication number: WO2013044307A1
Application number: PCT/AU2012/001172
Authority: WO
Inventors: Stephen Thompson; Lawrence Edward Nussbaum
Original assignee: Cocoon Data Holdings Limited
Priority date: 2011-09-30
Filing date: 2012-09-28
Publication date: 2013-04-04

Abstract

The present invention relates to a system and method for distributing secured data and where the integrity of a communications session may be tracked. The method involves the use of a token which is to be passed between a client and server during the communications session. The method and system perform an identical, pre-determined transformation function on the token at both the server and at the client each time there is a communication. The transformation function calculates a new value of the token. Any difference between the token values calculated by the server and the client are used as an indication that a previous communication was not received by one of the parties. For example, in the event it was intercepted by an authorised third party.

Description

A SYSTEM AND METHOD FOR DISTRIBUTING SECURED DATA

TECHNICAL FIELD

The present invention relates to a system and method for distributing secured data, and particularly, although not exclusively to a system and method for distributing secured data objects which are encrypted and wherein the integrity of a communications session may be tracked.

BACKGROUND

Transferring information electronically through the Internet or another public telecommunication network (such as wired or wireless telephone services) is a cost- effective solution for distributing information. However, as much of the Internet operates on public infrastructure, sensitive or confidential information sent through the Internet may be accessible to unauthorised parties.

To address these security concerns, corporations and other users may choose to encrypt the information before transmitting the data over a public network. One approach is to use encryption software, such as "Zip" programs that offer an encryption routine to encrypt the data before it is transmitted over the public network. Although such encryption software provides some level of security, all such software has a fundamental flaw, in that the

encryption process embeds the decryption key within the encrypted data object itself. As such, it is possible for a hacker to use brute force or other suitable methods to decrypt the data object since the necessary components to decrypt the data object are all integrated within the encrypted object.

In addition, encryption and decryption of data objects usually reguires the use of software which must be installed and verified on a user's computer. This

increases the cost of purchase and maintenance from the user' s point of view and thereby reduces the market uptake of such encryption and decryption technologies.

Moreover, in some instances, the user may be

utilising a computing system which does not possess the necessary software for the encryption and decryption of files .

SUMMARY OF THE INVENTION

In accordance with a first aspect, the present invention provides a computer implemented method for communication of secured data between a sender and a recipient, said method comprising the steps of:

• establishing a token for tracking a communications session with the recipient, storing the token and transmitting the token to the recipient;

· the recipient applying a pre-determined

transformation to the received token;

• the recipient transmitting the transformed token to the sender;

• the sender, upon receipt of a transmission including a token, applying the predetermined transformation to the received token;

• the sender applying the pre-determined transformation to the stored token;

• comparing the transformed token received during the communications session with the stored token; and o continuing the communications session in the event of a match between the stored token and the transformed received token; or

o terminating the communications session in the event of a mismatch between the stored token and the received token. The transmitted token may be transmitted separately from any transmission containing secured data.

Alternatively, the transmitted token may be transmitted together with the secured data.

In an embodiment, the sender requires a token to be sent to the recipient and a transformed token to be received matching the stored token, in order for secured data to be transmitted to the recipient. In an alternative embodiment, the sender sends secured data and a token without waiting to receive a transformed token.

In an embodiment, the sender establishes an initial value of the token or, alternatively, a third party service establishes an initial value of the token and supplies the token to the sender.

In an embodiment, the established token is stored in a database accessible only by the sender. The recipient may also store the received token after application of the pre-determined transformation.

In an embodiment, the sender and the recipient are arranged in a client-server relationship. In such relationship, the token may be initially transmitted to the client by the server as part of a client authorisation process .

In an embodiment, where the communications session is continued after token comparison, the sender:

• applies a further pre-determined transformation to the token and updates said stored token accordingly; and

• transmits requested secured data to the recipient together with the further transformed token. In an embodiment, further to such continuation of the communications session, the recipient:

• upon receipt of a further transmission including a token, applies the pre-determined transformation to the further token;

• compares the transformed further token, received

during the communications session, with the stored token; and

• alerts the sender in the event of any mismatch, or otherwise continues the communications session in the event of a match.

The comparison of tokens may involve determining respective values of tokens and comparing the values.

The token may be selected from the group including an integer, a numeric string, an alpha-numeric string, a binary coded decimal (BCD) string. The pre-determined transformation may be selected from the group including: incrementing the token,

decrementing token, applying a hash function to the token.

In accordance with a second aspect, the present invention provides a computer implemented method to track the integrity of a communications session for

communication of secured data between a server and a client, the method comprising the steps of:

• including a token with the secured data transmitted by a sender during the communications session between the server and the client;

• performing a pre-determined transformation on the token when received with the secured data from the sender;

· performing the pre-determined transformation on a token stored by the recipient during a previous transmission in the session; • comparing, after respective said transformations, the received token with the stored token and:

o in the event the transformed tokens match - continuing the communications session, or o in the event the transformed tokens do not match

- either terminating the communications session and/or alerting the sender to the mismatch.

In accordance with a third aspect of the present invention, there is provided a data communications system comprising a sender and a recipient linked by a

communications network, wherein the sender and recipient each include computers having one or more processors and associated storage components having stored thereon instructions to implement any of the methods summarised above .

In accordance with a fourth aspect of the invention, there is provided a system for distributing secured data, the system comprising:

a communications link between a sender and a

recipient;

a token generating sub-system arranged to establish a token for tracking a communications session over the communications link;

a storage sub-system arranged for storing the token; a sender communications interface arranged to transmit the token to the recipient;

a recipient processor arranged to apply a pre- determined transformation to the token upon receipt;

a recipient communications interface arranged to transmit the transformed token to the sender;

a sender processor, upon receipt of a transmission including a token, arranged to:

· apply the predetermined transformation to the received token;

• compare the transformed token received during the communications session with the stored token; and o continue the communications session in the event of a match between the stored token and the transformed received token; or o terminate the communications session in the event of a mismatch between the stored token and the received token.

In an embodiment, the sender includes the token generating sub-system to establish an initial value of the token .

In an embodiment, the system further comprises a third party service including the token generating sub- system to establish an initial value of the token and supply the token to the sender.

In an embodiment, the system further comprises a storage sub-system hosting a database accessible only by the sender wherein upon establishment the token is stored.

In an embodiment, the recipient also stores the received token after application of the pre-determined transformation .

In an embodiment, the recipient and the sender are arranged in a client-server relationship. If required, the sender communications interface is further arranged to initially transmit the token to the recipient as part of a client authorisation process.

In an embodiment, the sender processor is arranged, upon continuing the communications session, to:

• apply a further pre-determined transformation to the token and update said stored token accordingly; and

• transmit requested secured data to the recipient

together with the further transformed token. In an embodiment the recipient processor is arranged, upon continuing the communications session and upon receipt of a further transmission including a token, to:

• apply the pre-determined transformation to the

further token;

• compare the transformed further token, received

during the communications session, with the stored token; and

• alert the sender via the communications link in the event of any mismatch, or otherwise continue the communications session in the event of a match.

The data communications system may further include a third party database server in secure communications with the sender for establishing tokens.

In accordance with a fifth aspect of the present invention, there is provided a system for distributing secured data, comprising:

a token generating sub-system arranged to establish a token for tracking a communication session over a

communications link;

a storage sub-system arranged for storing the token; a sender communication interface arranged to transmit the token to a recipient;

a sender processor, arranged to receive a transformed token from the recipient, the transformed token being transformed by having a predetermined transformation applied to it by the recipient, the sender processor being arranged to;

apply the predetermined transformation to the received token;

compare the transformed token received from the recipient with the stored token; and

continue a communications session between the sender and the recipient in the event of a match between the stored token and the transformed received token; or

terminate the communication session between the recipient and the sender in the event of a mismatch between the stored token and the received token.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the present invention will now be described, by way of example, with reference to the accompanying drawings in which:

Figure 1 is a schematic block diagram of a system for distributing secured data in accordance with one

embodiment of the present invention;

Figure 2 is a block diagram of a system for securing data in accordance with one embodiment of the present invention;

Figures 3 (a) , 3 (b) , and 3 (c) depict stages in a client-server communications session in accordance with a further embodiment of the invention; Figures 4 (a) and 4 (b) depict alternative stages in the client-server communications session of the further embodiment of the invention; and

Figure 5 is a flow chart of a variation of the method of the further embodiment.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Referring to Figure 1, there is illustrated an embodiment of the present invention. This embodiment is arranged to provide a system for distributing secured data comprising: - a module arranged to receive a request from a data recipient to access the encrypted data; - an authentication routine arranged to authenticate the request and whereupon the request is authenticated; - a decrypting processor arranged to retrieve a key to decrypt the encrypted data into decrypted data; and - a

communication interface arranged to distribute the decrypt data to the data recipient.

In this example embodiment, the module,

authentication routine, and/or decrypting processor may be implemented by one or more electronic circuits, computers or computing devices having an appropriate logic,

software, hardware or any combination thereof programmed to operate with the computing devices. The computer may be implemented by any computing architecture, including stand-alone PC, client/server architecture, "dumb" terminal/mainframe architecture, mobile computers such as smart telephones, mobile telephones and computing tablets or any other appropriate architecture. In some

embodiments, the computing device is also appropriately programmed to implement the invention.

Referring to Figure 1 there is a shown a schematic diagram of a system for accessing secured data which in this embodiment comprises a computer which can include any client or server machine. In this embodiment the computer is a server 100. The computer, such as server 100, comprises suitable components necessary to receive, store and execute appropriate computer instructions . The components may include a processing unit 102, read-only memory (ROM) 104, random access memory (RAM) 106, and input/output devices such as disk drives 108, input devices 110 such as an Ethernet port, a USB port, etc. Display 112 such as a liquid crystal display, a light emitting display or any other suitable display and communications links 114. The server 100 includes instructions that may be included in ROM 104, RAM 106 or disk drives 108 and may be executed by the processing unit 102. There may be provided a plurality of communication links 114 which may variously connect to one or more computing devices such as servers, personal computers, terminals, wireless or handheld computing devices. At least one of a plurality of communication links 114 may be connected to an external computing network through a telephone line, co-axial cable, optical fibre, wireless connection or other type of communication.

The server 100 may include storage devices such as a disk drive 108 which may encompass solid state drives, hard disk drives, optical drives or magnetic tape drives. The server 100 may also use a single disk drive or multiple disk drives. The server 100 may also have a suitable operating system which resides on the disk drive 108 or in the ROM 104.

The system has a database 120 residing on a disk or other storage device which is arranged to store at least one data record relating to data used by the server 100 to provide the function of the system for accessing secured data. The database 120 is in communication with an interface 202, which is implemented by computer software residing on the server 100. The interface 202 provides a means by which a user may input commands, instructions or requests to the server 100 for execution or processing. The interface 202 may be implemented with input devices such as keyboards, touch-pads, a mouse or, in another example embodiment, the interface 202 may be arranged to receive inputs, requests or data through a network connection, including Ethernet, Wi-Fi, Firewire, USB or the like. With reference to Figure 2, there is illustrated a block diagram of an embodiment of a system for securing data. In this embodiment, the system is implemented with a computer server 200 arranged to be connected to a

communication network such as the Internet, Intranet, VPN or any communication network using an appropriate

communication protocol, such as Internet Protocol Version 4 (IPv4) or Version 6 (IPv6) or any other version which enables the computer server 200 to communicate with other computing or communication devices 204, 206 via the communication network for secure distribution of data utilising an encryption service. The server 200 may have the same configuration as the system of Figure 1 described above .

The server 200 is arranged to receive an encryption request 202 from a sender computing device 204 operated by a user, data sender, processor or controller wanting to encrypt one or more data objects for transmission to another recipient user 206, computer, processor or controller. In this example embodiment, the encryption request 202 may contain information relating to each data object that is to be encrypted by the sending computing device 204. This information may include, but not limited to:

1. The identity of the sending computing device ("sender") 204;

2. The identity of a recipient computing device ("recipient") 206;

3. Filenames of any data object, such as files to be encrypted;

4. File size, dates, properties, permissions

settings and other attributes;

5. access permissions of the recipient 206; 6. The address or reference of the recipient 206; and

7. Any other information relating to the security settings or the data object that is to be encrypted which may be reguired to encrypt the file .

Once the encryption reguest 202 is received by the server 200, the server 200 is arranged to generate a key which can be used to encrypt the data object. The key 208 may then be sent to the sender computing device 204 which has sent the encryption reguest 202 to the server 200. Once received, the key 208 is then used by the computing device 204 to encrypt the data object such that an encrypted data object 210 is generated.

In an embodiment, the encryption process on the computing device operates by encrypting the data object 210 such that the key 208 is not in any way integrated into the encrypted data object 210. As a result, the encrypted data object 210 cannot be decrypted by a hacker or malicious party who is able to obtain an authorized copy of the encrypted data object 210 since the encrypted data object 210 itself is unable to provide the necessary information (e.g. the key 208) for the hacker to decrypt the file. This embodiment is advantageous in that the encrypted data object 210 is highly secured since the key 208 needed to decrypt the file is not incorporated within the data object 210 itself.

After the data object is encrypted, the sender computing device 204 may then be operated by its user, processor or controller to send the encrypted data object 210 to a recipient 206 via the server 200. Alternatively, as the encrypted data object 210 is now secured, it may be sent through a public or private computer network or provided to the recipient in the form of digital media such as CDs, DVDs, Blu-Ray Discs (BR-D) , USB storage or the like. Preferably, in some situations, some form of security consideration is still put into practice with the transmission of the encrypted data object 210 for best practice .

Once the recipient user 206 receives the encrypted data object 210, the recipient user 206 may then contact the server 200 with a request to retrieve the necessary keys to decrypt the data object 210. In one embodiment, the server 200 enforces an authentication process 212 on the recipient 206 by checking and validating the identity of the recipient 206 prior to providing a key 214 to the recipient. The authentication process 212 may include a login/password check, a biometric check, a time delayed validation process, a telephone code check, a pass key check, an IP address check or a combination of one or more of these checks .

After the recipient user 206 is authenticated by the server 200 and is authorized to decrypt the data object 210, a key 214 is provided to the recipient user 206 to decrypt the file. In one example embodiment, the recipient user 206 may be given a key 214 which only decrypts certain portions of the encrypted data object 210 such that only portions of the data may be released to the recipient user 206. In another embodiment, the decryption of the data is restrictive such that certain usage permissions are enforced on the recipient 206. In these examples, it may be necessary to encrypt the data object with necessary information for third party software to control and enforce these permission settings. Examples of these third party software includes Secure Word or Adobe Acrobat reader which have permission controls capable of limited the manipulation of a data file. Alternative embodiments of a system for securing data are also described in WO/2009/079708 which is incorporated herein by reference. These embodiments are advantageous in that the encryption key 208 which can be used to decrypt an encrypted object is transmitted separately from the encrypted data object 210. As such, the encrypted data object may be transmitted in a less secure but more convenient channel. Then, even in the event that the encrypted data object 210 is copied by an unauthorised user, the object cannot be easily decrypted with known methods of decryption since the key is not within the encrypted object.

In another embodiment, the server 200 is arranged to provide dummy keys to the sender computing device 204 and the recipient computing device 206. By transmitting and utilising dummy keys in the encryption process, hackers or other malicious parties listening to the transmissions from the server 200 may receive a plurality of keys without any reference or knowledge as to which of the dummy keys can in fact be used to decrypt the data object. The dummy keys may also be integrated with the genuine key such that the permutations between the dummy keys and the genuine keys render it unfeasible or impractical for a hacker to use the data for any meaningful purpose.

The user computing devices 204, 206 may be any computing device of any architecture, such as a PC, laptop, tablet or any other computing device.

In the above embodiments, it can be important to be assured that a communications session between a server and a client, such as between server 200 and sender computing device 204 or recipient computing device 206, is secure. Examples of processes which would benefit from a secure on-line communications session include the following: • requesting client authorisation, issuing a challenge to a client, submitting a client response;

• requesting encryption keys from a server, sending encryption keys to a client; and

• submitting an alias or password.

Other processes may also benefit from a secure on-line communications session.

Data in the communications session is at risk of being copied or diverted by an unauthorised party when transmitted over public networks. Accordingly, a method of tracking the integrity of communications between a client and a server has been developed in a further embodiment of the invention in order to provide an additional security measure for such important data, including but not limited to distribution of encryption keys .

The method involves the use of a piece of

information, referred to as a "token", which is passed between the client and server during communications. The method comprises performing an identical, pre-determined transformation function on the token at both the server and at the client each time there is a communication. The transformation function calculates a new value of the token. Any difference between the token values calculated by the server and the client are used as an indication that a previous communication was not received by one of the parties, for example in the event it was intercepted by an unauthorised third party.

The token may take the form of a simple number, a BCD number, BDC string or a string of alphanumeric characters, e.g. coded as a 64-bit string. The token is preferably relatively small in size to minimise both communication and transformation processing overheads. On the server side, the token is suitably stored in a secure database accessible by the server. Each time a new value of the token is calculated by application of the pre-determined transformation, it is stored to the database. On the client side, the token is stored locally on the computing device hosting the client.

The initial value of the token may be established by the server and issued to the client when a session begins. Alternatively the server may obtain a token having a random initial value from a trusted database or an independent database server. The transmission of the token can be implemented as a separate communication, or alternatively as part of another preliminary

communication, e.g. client authorisation. The

transformation function can be almost any operation or algorithm, most preferably an algorithm that can be performed efficiently by both the client and server computers. In one basic version, the token is a number and the transformation function merely increments the number by a fixed amount each time it is performed. In another version, the function may be a hash function, such as Secure Hash Algorithm (SHA) 256. It is important that the server and the client both use identical transformation functions and start with a token having the same initial value .

Figure 3 schematically illustrates an example of the use of tokens at three stages of communication, (a) , (b) and (c) , between a server 302 (which may have the

configuration and functionality of server 200) and a client 304 via a communications network 306. In this example, the pre-determined transformation function F performed on a token T is simply a counter which

increments the value of the token by the integer 1 each time the transformation is performed. At the opening stage of the communications session, shown in Figure 3(a), the client 304 does not possess a token. The client does however possess a copy of the predetermined transformation function F required for

communication with the particular server 302. The server 302 generates a token with initial value T_s which in this example is 101. The server stores this token (i.e. with value 101) in a local database 308, and also transmits the token T_s to the client 304 via network 306. The client 304 then stores the token value locally, for later use in calculating client token value T_c.

Figure 3(b) shows a second stage of the session when the client 304 needs to communicate with the server 302, such as to respond to an authorisation challenge. The client 304 uses the local copy of the pre-determined transformation function F and the stored session starting value 101 of the token to calculate a new value of the client token T_c. Since the transformation function increments the value of the token by 1, the new value is calculated as: T_c = F(101) = 102. The client 304 sends the transformed value of the client token T_c = 102 to the server 302 over communications link 306. When the server 302 receives the client token T_c it performs the same function F on its database value of the server token: T_s = F(101) = 102 and compares the transformed server token T_s with the value of T_c received from the client 304. In this case, T_s matches T_c so the server 302 concludes that the session integrity has not been compromised. The

transformed value of the server token T_s = 102 is then stored in the database 308.

Figure 3(c) shows a third stage of communications when the server 302 responds with a communication back to the client 304, e.g. to advise that authorisation has been successful. The server 302 uses the last value of the token stored in the database 308, T_s = 102, to calculate a new value of the server token: T_s = F(102) = 103. The server sends the new transformed value of the server token T_s = 103 to the client 304. When the client receives the server token T_s it performs the same function F on its own local token value T_c = F(102) = 103 and compares it with the current received value of T_s . In this case, T_c matches T_s so the client concludes that the session integrity has not been compromised. The new value of the client token T_c = 103 is then stored locally by the client 304.

Figure 4 illustrates stages (a) and (b) of a scenario in which an impostor 310 hijacks a communication session by intercepting data transmitted from the server 302 to the client 304 over network 306. The transformation function F in this example is the same incrementing algorithm described in the example of Figs 3(a) to 3(c) above. Figure 4(a) shows that the new value of the server token is T_s = 103 (calculated from the previous value of 102, as per Fig 3(c) above) and that the token T_s is unintentionally sent by server 302 to the impostor 310 instead of the client 304. An error is not generated at this stage .

Figure 4 (b) shows a second stage when the client 304 now attempts to communicate with the server 302. Since the client 304 did not receive the previous communication, it did not change its local value of its token T_c by

application of the pre-determined transformation.

Therefore, according to the client 304, the most recent value of the token after performing the transformation function is T_c = 103. When the server 302 receives the client's token T_c and compares it with the value of the server token (T_s=104), a mismatch will be found. The mismatch in token values causes the server to log an error and terminate the communication session with the client. The server also terminates any communication session with the diverting imposter 310. The legitimate client 304 can, in the absence of acknowledgement from the server 302, continue communications by requesting a new session which would proceed as shown in Figure 3. It should be further noted that, should the imposter

310 attempt to communicate directly with the server 302 is also bound to fail in the absence of knowledge of both the existence of the token, the pre-determined transformation function, and when it is to be applied to the token.

Figure 5 is a flow diagram illustrating the steps of a variation on the method described in the above example, wherein the sender and the recipient are linked in a client 501 - server 500 communications relationship. Upon initiation of a secure communications session, the server 500 establishes a token T_s and stores the token in step 502. The server token T_s is then transmitted to the client 501 over a communications link in step 504.

Optionally during subsequent transmissions by the server in the session, the token can be sent together with data objects that are requested by the client 501.

In step 506, the client receives the token from the server and applies a pre-determined transformation function F to the token, thus creating a client token T_c. The client then stores the token T_c and re-transmits it to the server in step 508. Optionally during subsequent transmissions by the client in the session, the token can be sent together with requests for desired data objects to the server 500.

When a transmission is received at the server 500 by a client (including purported clients, i.e. including actual recipients 304 or potential imposters 310) in step 510, the pre-determined transformation function is applied to the stored server token F(T_S) in step 512 and a comparison made in step 514 with the client token T_c received with the transmission. A tokens match (Y) result (i.e. F(T_S) = T_c) of the comparison in decision step 514 allows continuation of the communications session after re-storing the transformed token in step 516. Any other data processing steps may then performed by the server in step 518, for example in response to a client request. Control is then passed back to transmission in step 514. In the event the tokens do not match (N) in decision step 514, the communications session is terminated in step 520.

It will be appreciated that a further variation on the method is to conduct token matching at each reception and transmission cycle in the communications session at the client side 501 in order to track possible bogus server substitution or other tampering or diversion of the data .

In a particularly preferred embodiment of the tracking method suited to the secure data transfer system described in relation to Figure 1, an independent or "gatekeeper" server issues the initial token to the client. On the server side, there are a range of other processes that may communicate with the client. These processes may run on the same physical server machine as the Gatekeeper, or on different machines. Each time a process communicates with the client, it refers back to a secure database to obtain the most recent value of the token. The process uses the pre-determined transformation function to calculate a new value of the token and then stores that token having the new value in the secure database .

When a client-server communication session is terminated, the client erases the token from the place it was stored locally. In the preferred embodiment it is desirable that only the client or the server can

legitimately terminate a session. If a session is interrupted or times out due to inactivity, an error can be logged by the server to indicate that client did not terminate the communications session. Although not required, the embodiments described with reference to the drawing figures can be implemented as an application programming interface (API) or as a series of libraries for use by a developer or can be included within another software application, such as a terminal or personal computer operating system or a portable computing device operating system. Generally, as program modules include routines, programs, objects, components and data files assisting in the performance of particular

functions, the skilled person will understand that the functionality of the software application may be

distributed across a number of routines, objects or components to achieve the same functionality desired herein . It will be appreciated that where the methods and systems of the present invention are either wholly implemented by computing system or partly implemented by computing systems then any appropriate computing system architecture may be utilised. This will include stand alone computers, network computers and dedicated hardware devices. Where the terms "computing system" and

"computing device" are used, these terms are intended to cover any appropriate arrangement of computer hardware capable of implementing the function described.

It will also be appreciated by persons skilled in the art that numerous variations and/or modifications may be made to the invention as shown in the specific embodiments without departing from the spirit or scope of the

invention as broadly described. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive. Any reference to prior art contained herein is not to be taken as an admission that the information is common general knowledge, unless otherwise indicated.

Embodiments of the invention provide a relatively simple method of identifying when a communications session might be compromised. In some embodiments, the method does not in itself prevent third parties from intercepting communications, but it can be used as part of an alert system which allows appropriate corrective action to be taken .

Although not required, embodiments described with reference to the drawings can be implemented to operate with any form of communication network operating with any type of communication protocol. Generally, where the underlying communication network or communication protocol includes additional routines, functionalities,

infrastructure or packet formats, the skilled person will understand that the implementation of embodiments

described including with reference to the drawings may be modified or optimized for operation with these additional routines, functionalities, infrastructure or packet formats .

Claims

1. A computer implemented method for communication of secured data between a sender and a recipient, said method comprising the steps of:

• the recipient applying a pre-determined

transformation to the received token;

• the recipient re-transmitting the transformed token to the sender;

• the sender applying the pre-determined transformation to the stored token;

o terminating the communications session in the event of a mismatch between the stored token and the received token.

2. The method of claim 1 wherein the sender establishes an initial value of the token.

3. The method of claim 1 wherein a third party service establishes an initial value of the token and supplies the token to the sender.

4. The method of any one of claims 1 to 3 wherein upon establishment the token is stored in a database accessible only by the sender.

5. The method of any one of claims 1 to 4 wherein the recipient also stores the received token after application of the pre-determined transformation.

6. The method of any one of claims 1 to 5 wherein the sender and the recipient are arranged in a client-server relationship .

7. The method of claim 6 wherein the token is initially transmitted to the client by the server as part of a client authorisation process.

8. The method of any one of claims 1 to 7 wherein, upon continuing the communications session the sender:

• transmits requested data and the further transformed token to the recipient.

9. The method of claim 8 wherein the token is

transmitted together with the requested data to the recipient .

10. The method of claim 8 wherein the token is

transmitted separately from the requested data to the recipient .

11. The method of any one of claims 1 to 10 wherein, upon continuing the communications session, the recipient:

• compares the transformed further token, received

during the communications session, with the stored token; and

12. The method of any one of claims 1 to 10 wherein comparison of tokens involves determining respective values of tokens and comparing the values.

13. The method of any one of claims 1 to 12 wherein the token is selected from the group including an integer, a numeric string, an alpha-numeric string, a binary coded decimal (BCD) string.

14. The method of any one of claims 1 to 13 wherein the pre-determined transformation is selected from the group including: incrementing the token, decrementing token, applying a hash function to the token.

15. The method of any one of claims 1 to 14 wherein the token is transmitted separately from any transmission containing secured data.

16. A computer implemented method to track the integrity of a communications session for communication of secured data between a server and a client, the method comprising the steps of:

• performing the pre-determined transformation on a token stored by the recipient during a previous transmission in the session;

• comparing, after respective said transformations, the received token with the stored token and:

o in the event the transformed tokens match - continuing the communications session, or o in the event the transformed tokens do not match - either terminating the communications session and/or alerting the sender to the mismatch.

17. The method of claim 14 wherein the token is

transmitted separately from any secured data.

18. A data communications system for distributing secured data comprising a sender and a recipient linked by a communications network, wherein the sender and recipient each include computers having one or more processors, communications interfaces and associated storage subsystems having stored thereon instructions to implement a method in accordance with any one or more of claims 1 to 15.

19. The secure data communications system of claim 18 further including a third party database server in secure communications with the sender for establishing tokens.

20. A system for distributing secured data, the system comprising :

a communications link between a sender and a

recipient;

a recipient processor arranged to apply a predetermined transformation to the token upon receipt;

a recipient communications interface arranged to re- transmit the transformed token to the sender;

a sender processor, upon receipt of a transmission including a token, arranged to: • apply the predetermined transformation to the received token;

21. The system of claim 20 wherein the sender includes the token generating sub-system to establish an initial value of the token.

22. The system of claim 21 further comprising a third party service including the token generating sub-system to establish an initial value of the token and supply the token to the sender.

23. The system of any one of claims 20 to 22 further comprising a storage sub-system hosting a database accessible only by the sender wherein upon establishment the token is stored.

24. The system of any one of claims 20 to 23 wherein the recipient also stores the received token after application of the pre-determined transformation.

25. The system of any one of claims 20 to 24 wherein the recipient and the sender are arranged in a client-server relationship .

26. The system of claim 25 wherein the sender

communications interface is further arranged to initially transmit the token to the recipient as part of a client authorisation process.

27. The system of any one of claims 20 to 26 wherein the sender processor is arranged, upon continuing the

communications session, to:

• transmit requested data and the further transformed token to the recipient.

28. The system of claim 27 wherein the token is

transmitted together with the requested data to the recipient .

29. The system of claim 27 wherein the token is

transmitted separately from any secured data to the recipient .

30. The system of any one of claims 20 to 29 wherein the recipient processor is arranged, upon continuing the communications session and upon receipt of a further transmission including a token, to:

• apply the pre-determined transformation to the

further token;

• compare the transformed further token, received

during the communications session, with the stored token; and

31. A system for distributing secured data, comprising: a token generating sub-system arranged to establish a token for tracking a communication session over a

communications link;

a storage sub-system arranged for storing the token; a sender communication interface arranged to transmit the token to a recipient; a sender processor, arranged to receive a transformed token from the recipient, the transformed token being transformed by having a predetermined transformation applied to it by the recipient, the sender processor being arranged to;

apply the predetermined transformation to the received token;

32. Computer readable media having stored thereon sequences of instructions which, when executed by a plurality of processors, implement the method of any one or more of claims 1 to 17.

33. A computer program arranged when loaded into at least one computing device to instruct the computer to operate in accordance with the method of any one of claims 1 to 17 or in accordance with the system of any one of claims 18 to 31.

34. A data signal, comprising a computer program in accordance with claim 33.