WO2013044305A1

WO2013044305A1 - Method and system for securing data

Info

Publication number: WO2013044305A1
Application number: PCT/AU2012/001170
Authority: WO
Inventors: Stephen Thompson; Lawrence Edward Nussbaum
Original assignee: Cocoon Data Holdings Ltd
Current assignee: Cocoon Data Holdings Ltd
Priority date: 2011-09-30
Filing date: 2012-09-28
Publication date: 2013-04-04
Anticipated expiration: 2014-03-30

Abstract

The present invention relates to a method and system for securing data. The method and system incorporates dummy data with legitimate data to create a secure data object. Extraction information is generated, the extraction information comprising information required to facilitate reassembly of the legitimate data.

Description

METHOD AND SYSTEM FOR SECURING DATA

Technical Field of the Invention The present invention relates to a system and method for securing data, and particularly, but not exclusively, to a system and method for encrypting data.

Background of the Invention

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 requires 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 .

The highest standards of data protection are required to keep data secure for extended periods of time. In certain operations, for example, military software or company's corporate secrets must be kept "secure" for long periods of time, for example, up to 99 years. The

encrypted data must, therefore, be able to withstand

99 years of brute force attacks. The length of time required for a brute force attack depends on the time of takes to test each possible key which is a function of the computing speed—the faster the computing speed, the easier it is to "crack" an encryption system via a brute force type method. Computing speeds have been increasing over time and newer and faster processors are increasing at an exponential rate. Brute force methods that are today not feasible, may become feasible in the future with the advent of faster computing technology. For this reason, any improvements in the strength of encryption of value for providing more certainty about long term data.

Summary of the Invention

In accordance with a first aspect of the present invention, there is provided a method for securing data comprising the steps of:

incorporating dummy data with legitimate data to create a secure data object; and

generating extraction information, wherein the extraction information comprises information required to facilitate re-assembly of the legitimate data.

In an embodiment, the extraction information comprises information on the location of the legitimate data in the secure data object

In an embodiment, the extraction information comprises information on the size of the legitimate data.

In an embodiment, the method comprises the step of providing the extraction information to a recipient to enable the recipient to re-assemble the legitimate data In an embodiment, the step of providing the extraction information to the recipient comprises the step of

determining whether the recipient satisfies a

predetermined condition, and only providing the extraction information if the predetermined condition is satisfied.

In an embodiment, the legitimate data is encrypted data, requiring a decryption key to decrypt the data.

In an embodiment, the method comprises the step of providing the decryption key to the recipient separately from the extraction information.

In an embodiment, the method comprises the step of storing the decryption key and extraction information for provision to the recipient, the decryption key and

extraction information being stored in separate locations. In an embodiment, the step of incorporating the dummy data comprises the step of selecting the dummy data from a set of values that is identical to a set of values used in the legitimate data. In an embodiment, the step of incorporating dummy data comprises the step of inserting dummy data at one or more of the following positions:

- within the legitimate data; and

- at one or both ends of the legitimate data.

In an embodiment, a predetermined quantity of dummy data is incorporated in the legitimate data, the

predetermined quantity being specified as a percentage of the size of the legitimate data.

In an embodiment, the method comprises the step of splitting the legitimate data into smaller data blocks and interspersing said data blocks with dummy data blocks. In an embodiment, the step of splitting the legitimate data further comprises randomly selecting, within preset ranges, the size and quantity of the blocks of legitimate data . In an embodiment, the step of splitting the legitimate data further comprises randomly selecting, within preset ranges, the size and quantity of the blocks of dummy data. In an embodiment, the extraction information includes the information about the quantity of blocks of legitimate data and dummy data. In an embodiment, the method comprises the step of changing the order of the blocks of legitimate and dummy data after the legitimate data blocks have been

interspersed with dummy data blocks. In an embodiment, the extraction information comprises an assembly order of the legitimate data blocks.

In an embodiment, the legitimate data is encrypted data requiring at least one decryption key to decrypt the data, further comprising a step of separately providing a plurality of the decryption keys to an authorised

recipient, wherein the quantity of decryption keys is the same as or greater than the quantity of data blocks comprising the legitimate and dummy data, and wherein the extraction information further comprises information to facilitate selection of a suitable decryption key for each block of legitimate data.

In an embodiment, the method comprises the step of encrypting the smaller blocks of legitimate data, wherein the step of encryption comprises selecting an encryption algorithm for each block of legitimate data from a set of containing multiple encryption algorithms . In an embodiment, the method comprises the step of encrypting the legitimate data, wherein multiple

encryption algorithms are applied to the legitimate data. In an embodiment, the method comprises the step of encrypting the dummy data and the legitimate data.

In an embodiment, the encrypted dummy data is

indistinguishable from the encrypted legitimate data.

In an embodiment, the dummy data is composed of the same values contained in the legitimate data, and wherein each value in the dummy data is used with substantially the same frequency as each respective value in the

legitimate data.

In accordance with a second aspect of the present invention, there is provided a system for securing data comprising:

a processor arranged to incorporate dummy data with legitimate data to create a secure data object; and the processor arranged to generate extraction

information, wherein the extraction information comprises information required to facilitate reassembly of the legitimate data.

In an embodiment, comprising a recipient, the

recipient being a computing device, the processor is arranged to provide the extraction information to a recipient to enable the recipient to re-assemble the legitimate data.

In an embodiment, the processor is arranged to determine whether the recipient satisfies a predetermined condition, and the processor only providing the extraction information if the predetermined condition is satisfied.

In an embodiment, the processor is arranged to provide the decryption key to the recipient separately from the extraction information. In an embodiment, the processor is arranged to store the decryption key and extraction information for

provision to the recipient, the decryption key and

extraction information being stored in separate locations. In an embodiment, the system comprises a plurality of separate storage devices, one of the plurality of storage devices arranged to store the extraction information and another storage device arranged to store the decryption key .

In an embodiment, the processor is arranged to select the dummy data from a set of values that is identical to a set of values used in the legitimate data. In an embodiment, the processor is arranged to insert the dummy data at one or more of the following positions:

- within the legitimate data; and

- at one or both ends of the legitimate data. In an embodiment, the processor is arranged to incorporate a predetermined quantity of dummy data in the legitimate data, the predetermined quantity being

specified as a percentage of the size of the legitimate data .

In an embodiment, the processor is arranged to split the legitimate data into smaller data blocks and

interspersing said data blocks with dummy data blocks.

In an embodiment, the processor is arranged to randomly select, within preset ranges, the size and quantity of the blocks of legitimate data.

In an embodiment, the processor is arranged to randomly select, within preset ranges, the size and quantity of the blocks of dummy data. In an embodiment, the extraction information includes the information about the quantity of blocks of legitimate data and dummy data.

In an embodiment, the processor is arranged to change the order of the blocks of legitimate and dummy data after the legitimate data blocks have been interspersed with dummy data blocks.

In an embodiment, the extraction information comprises an assembly order of the legitimate data blocks.

In an embodiment, the legitimate data is encrypted data requiring at least one decryption key to decrypt the data, the processor is arranged to separately provide a plurality of the decryption keys to an authorised

recipient, wherein the quantity of decryption keys is the same as or greater than the quantity of data blocks comprising the legitimate and dummy data, and wherein the extraction information further comprises information to facilitate selection of a suitable decryption key for each block of legitimate data. In an embodiment, the processor is arranged to encrypt the blocks of legitimate data, the processor being further arranged to select an encryption algorithm for each block of legitimate data from a set of multiple encryption algorithms .

In an embodiment, the processor is arranged to encrypt the legitimate data, wherein the processor is further arranged to apply multiple encryption algorithms to the legitimate data.

In an embodiment, the processor is arranged to encrypt the dummy data and the legitimate data.

In an embodiment, the encrypted dummy data is

indistinguishable from the encrypted legitimate data.

In an embodiment, the dummy data is composed of the same values contained in the legitimate data, wherein each value in the dummy data is used with substantially the same frequency as each respective value in the legitimate data .

In accordance with a third aspect of the present invention, there is provided a computer program arranged to, when executed on a computing system, perform any one or more of the method steps described earlier.

In accordance with a fourth aspect of the present invention, there is provided a computer readable medium incorporating a computer program in accordance with the third aspect. In accordance with a fifth aspect, there is provided a data signal comprising a computer program in accordance with the third aspect of the invention.

In accordance with a sixth aspect of the present invention, there is provided a method for securing data comprising the steps of:

adding dummy data with legitimate data to create a secure data object; and

generating extraction information, wherein the extraction information comprises information required to facilitate identification of the legitimate data.

In accordance with a seventh aspect of the present invention, there is provided a system for securing the data comprising:

a processor arranged to add dummy data with legitimate data to create a secure data object; and

the processor arranged to generate extraction

information, wherein the extraction information comprises information required to facilitate identification of the legitimate data.

Detailed Description of the Drawings Notwithstanding any other embodiments that may fall within the scope of the present invention, an embodiment of the present invention will now be described, by way of example only, with reference to the accompanying figures, in which:

Figure 1 is a schematic diagram of a system for distributing secured data;

Figure 2 is a schematic diagram of a system for securing data in accordance with an embodiment of the present invention; Figure 3 shows a flow diagram of a method of securing data, in accordance with the present invention;

Figure 4 shows a flow diagram of a further method fo securing data, in accordance with the present invention;

Figure 5 shows an example of the implementation of a method of securing data, in accordance with the present invention;

Figure 6 shows a diagram of one form of the manifest comprising extraction information to allow a client to extract legitimate data;

Figure 7 shows another example of the implementation of a method of securing data, in accordance with the present invention;

Figure 8a shows a diagram of another form of a manifest comprising extraction information to allow a client to extract legitimate data;

Figure 8b shows a diagram of one form of a data structure containing the assembly information to allow the legitimate data to be extracted;

Description of Preferred/Specific Embodiments Referring to Figure 1, there is illustrated a system for distributing secured data. Components of the system 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 a stand-alone PC, client/server architecture, "dumb" terminal/mainframe architecture, 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 shown a schematic diagram of a system for distributing secured data which in this embodiment comprises a server 100. The system shown in Figure 1 can be used as part of a system for securing data in accordance with the present invention, which will be described later. The 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, input/output devices such as disk drives 108, input devices 110 such as an Ethernet port, a USB port, etc, a display 112 such as a liquid crystal display, a light emitting display or any other suitable display, and communication 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, 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 122, which is implemented by computer software residing on the server 100. The interface 122 provides a means by which a user may input commands, instructions or requests to the server 100 for execution or processing. The interface 122 may be implemented with input devices such as keyboards, mouse or, in another example embodiment the interface 122 may be arranged to receive inputs, requests or data through a network connection, including Ethernet, Wi-Fi, Fire-wire, 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 accordance with the present invention. In this embodiment, the system is implemented with a 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 server 200 to communicate with other computing or

communication devices 204, 206 via the communication network. 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 a data object for transmission to another

recipient user 206, computer, processor or controller. In this example embodiment, the encryption request 202 may contain information relating to the data object that is to be encrypted by the sending computing device 204. This information may include, but not be limited to:

1. Filenames of any files to be encrypted; File size, dates, properties, permissions settings and other attributes;

3. The identity of the recipient 206 of the file;

4. The access permissions of the recipient 206;

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

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

Once the encryption request 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 request 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.

Preferably, 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 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-Rays, 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 may be provided to the recipient user 206 to decrypt the file. In one example embodiment, the recipient user 206 is 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 limiting the manipulation of a data file.

Alternative embodiments of a system for securing data are also described in WO2009/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 210 may be transmitted in a less secure but more convenient channel. 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 208 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 and the server 200 may be similar in structure to the server 100 described earlier. The user computing devices 204, 206 may comprise at least some of the features of the server 100. In another form the user computing devices 204, 206 may be identical in structure to the server 100. The server 200 may also comprise at least some of the features of the server 100 described earlier.

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.

The user computing devices 204, 206 and server 200 comprise a processor. The user computing devices 204, 206 operate user computing software known as a "client" . The software includes instructions for performing various functions such as addressing the server, encrypting data, decrypting the encrypted data and other functions

described herein. The software can be implemented on a processor such as a processor of the sender device 204 or the processor of the server 200 or a processor of the recipient device 206. The software allows the processor to perform the functions described herein. In one embodiment with reference to the system of Figure 2, the sender computing device 204 runs an

encryption client 220. The receiver computing device 206 runs a decryption client 221. The sender computing device 204 is arranged to implement a method of securing data to create a secure data object. The encryption client 220 is arranged to perform the step of the method of securing data. The encryption client generates extraction

information that is held in a manifest 600 after securing the data and encrypting the data. The receiver computing device 206 is arranged to decrypt the received encrypted data object by using the extraction information from the manifest 600 and a decryption algorithm. The decryption client 221 is arranged to use the extraction information in conjunction with a suitable decryption algorithm to extract the data .

An embodiment of a method for securing data, in accordance with the present invention is shown in Figure 3. In this embodiment, the method of securing data 300 comprises the steps of:

• incorporating dummy data with legitimate data, at step 301.

• recording extraction information at step 302. · encrypting the combination of legitimate data and dummy data at step 303. The data that is encrypted is the legitimate data and the dummy data . Legitimate data is the actual data that needs to be secured and encrypted. The dummy data is additional data that is used to make the legitimate data more resistant to brute-force attacks from hackers. The encryption client 220 communicates the manifest 600 to the server 200 which determines the circumstances in which the information can be released and the parties that may receive it. The server 200 may store the

manifest 600 at a location separate from the encrypted data and encryption keys. The separation reduces the risk that the data, keys and extraction information can be hacked or stolen from one place.

The manifest 600 comprises extraction information to enable the decryption client 221 to re-assemble the legitimate data from the secured data object. In one form the extraction information may comprise the location and size of the legitimate data to enable the legitimate data to be identified and re-assembled. The manifest 600 may be in the form of a data file that records the location and size of each piece of legitimate data. The location and size of the legitimate data is stored in any suitable file known such as an XML file or an HTML file or may be in any other suitable format.

The extraction information can be recorded in a data structure such as an array or a list or a stack or any other suitable data structure

The manifest 600 can be split over multiple data files or split over multiple data structures. For example, the location and size of each piece of data can be specified in a file or data structure without stating which piece of legitimate data and which piece is dummy data. The manifest 600 can identify the legitimate pieces of data and the order for reassembly. A more detailed method for securing data will be described in more detail now. Figure 4 illustrates a method 400 of securing data. The method comprises the steps of:

• Analysing the legitimate data at step 401. The encryption client 220 or the sender computing device 204 may receive the legitimate data to be secured and analyse the data to determine characters or values used in the legitimate data.

• Selecting dummy data at step 402. The dummy data is selected from a set of characters or values identical to the characters or values used in the legitimate data. The details relating to the selection of dummy data is described later.

• Splitting the legitimate data into data blocks at step 403. The legitimate can be split into data blocks of varying sizes which will be described later .

· Adding dummy data at step 404. The dummy data may be added at any location relative to the legitimate data. For example the dummy data may be added before, after or in between blocks of the legitimate data. A secure data object is created once the dummy data is added to legitimate data.

• Encrypting the secure data object to create an encrypted data object 210 at step 405. The encrypted data object comprises the dummy data and the legitimate data. Any suitable type of encryption can be used.

• Recording extraction information for the

legitimate data in a manifest at step 406. The extraction information includes information about the location and size of the legitimate data to allow a decryption client 206 to extract the legitimate data. The extraction information may also comprise information regarding the type of encryption used.

The method 400 comprises adding dummy data to

legitimate data to create a secure data object. The data object may be a data string or a plurality of data blocks or any suitable data structure. The secure data object comprises the legitimate data and the dummy data.

The selected dummy data (step 402) should be

indistinguishable from the legitimate data after

encryption. The dummy data and legitimate data should both consist of the same types of characters or values, both of which are hereafter referred to generically as "values". For example, if the legitimate data includes English letters or words, the dummy data should also include only the English letters and/or words. If the legitimate data comprises numbers or symbols the dummy data must also be chosen from the same character set as the legitimate data. In another example, if the

legitimate data comprises a JPEG image format, the dummy data can also comprise a JPEG image or at least part of an image in the JPEG format.

In order to further enhance the similarity of the dummy data and legitimate data, the dummy data and

legitimate data are preferably both encrypted and may be both encrypted together and encrypted at the same level. This is advantageous because it makes it difficult for a hacker to differentiate between the legitimate data and the dummy data. Therefore if a hacker managed to hack and decrypt the encrypted data, the hacker would not be able to extract the legitimate data by simply looking at the decrypted data. The hacker would require the extraction information to differentiate the legitimate data from the dummy data . The dummy data can be generated using a random character generator to select characters or values from a predefined set of characters or values used in the

legitimate data. The random character generator is

implemented as software instructions . The random character generator may be implemented by the encryption client or as another software module running on the sender computing device 204.

The user computing device 204 or the encryption client 220 is arranged to split legitimate data into data blocks as per step 403. In one embodiment the encryption client 220 splits the legitimate data into data blocks of the same size. In another embodiment the encryption client 220 is arranged to split the legitimate into differing sized data blocks . The method of securing comprises the step of splitting the legitimate data object into data blocks of varying sizes or the same size. Splitting the blocks allows dummy data to be added at different positions along the legitimate data. The size of the legitimate data block is a function of the total size of the overall size of the legitimate data.

As part of the splitting of legitimate data into data blocks the encryption client is arranged to control any one or more of the following parameters:

^■ size of each block of legitimate data;

^■ the quantity of blocks of legitimate data.

The encryption client 220 is arranged to vary the size of the legitimate data block and the quantity of the legitimate data blocks. The variation of size and quantity of the blocks can be done randomly within predetermined limits such that there is no pattern. In one embodiment, when the method for securing data is applied to several pieces of legitimate data, the parameters for splitting dummy data are varied each time the data is secured in order to avoid creating regular patterns and thereby making brute force attacks more difficult.

Splitting the legitimate data into data blocks provides an advantage since a hacker does not have the entire piece of legitimate data available if the hacker hacks the data. The hacker is required to assemble the blocks . Splitting data into blocks adds more security and hence is advantageous.

The dummy data is added as one or more data blocks . A data block is a string of values. In its simplest form a data block is a collection of values in a finite-sized piece of data. The size of data blocks may vary from each other or may be identical to each other. The dummy data may be added at any suitable position relative to the legitimate data string. For example the dummy data may be added before, after or interspersed at various points within the legitimate data string to create a secure data object . The encryption client 220 or the sender device 204 controls the way the dummy data is added to the legitimate data, such as a number of dummy data insertion parameters. The controlled parameters could be any one or more of:

^■ the size of each block of dummy data; and

^■ the location of the dummy data within the

legitimate data. The values of these parameters for varying the dummy data can be selected randomly within predetermined limits by the sender device 204 or the encryption client 220. In one embodiment, when the method for securing data is applied to several pieces of legitimate data, the

parameters for dummy data insertion are varied each time the data is secured in order to avoid creating regular patterns and thereby making brute force attacks more difficult. For example the encryption client 220 may vary the size of each dummy block in a first data securing operation for a first piece of legitimate data and then in a second securing operation for a second piece of

legitimate data the encryption client may vary the

quantity of blocks of legitimate data and the size of each of legitimate data block. The variation of size and position can be controlled to be randomly selected within predetermined limits by software-encoded instructions.

In one example the size of the added dummy data blocks may be a function of the size of the legitimate data.

The encryption client 220 is also arranged to randomly shuffle blocks of legitimate data and dummy data, once the data is split into blocks. The shuffling, as per step 404, can be done either before or after encryption. The encryption client comprises instructions to shuffle data in a random order. Shuffling data also provides additional security since a hacker who hacks and accesses the data is required to assemble the data blocks in the correct order and differentiate between the dummy data and legitimate data and decrypt the data in order to access the

legitimate data. In another embodiment, the encryption client can divide the legitimate data into blocks before the dummy data has been inserted and then randomly shuffle the blocks once the dummy data has been inserted. The size of each block can be randomly selected and the encryption client 220 may split the combination of the legitimate and dummy data into varying sizes of blocks.

The encryption client 220 tracks the changes made during the shuffling operation in order to provide instructions for reassembling the legitimate data blocks. The encryption client 220 is arranged to record the shuffling information, the size of the dummy data added, the location of the dummy data added, the size and number of data blocks created, and the location of the legitimate data. This information is recorded as part of the manifest 600. The manifest 600 may be recorded in a suitable file as described earlier.

The secure data object can be encrypted using any suitable encryption algorithm. The encryption client 220 is arranged to implement the encryption algorithm as part of step 406. All the blocks of the secure object can be encrypted using the same encryption algorithm. Alternatively the algorithm applied to each block can be randomly selected from a set containing multiple

encryption algorithms, such as AES and triple DES . For example, in one embodiment, some blocks can be encrypted using AES and others can be encrypted using triple DES. The encryption algorithm actually used is recorded by the encryption client as part of the extraction information, in order to allow the decryption client 221 to apply the correct decryption algorithm.

As a minimum at least each block of legitimate data is encrypted using a separate key to increase security.

A decryption client 221 operating on the receiver device 206 receives the encrypted data and then decrypts the encrypted data using the extraction information and at least one decryption key. Decryption keys and the

manifest 600 are only provided to the decryption client in response to specific request for data and after

successfully passing an authentication procedure with the server 200. The server 200 can provide the appropriate decryption key to the decryption client. The server 200 can also provide the extraction information 200 to the decryption client 221. In a preferred embodiment, the server 200 only provides a location of a decryption key, since the decryption key is stored at a location remote to the data and remote to the authentication server 200. In the preferred embodiment the server 200 further provides the location of the manifest 600 since the manifest 600 is stored in location remote to the key and the encrypted data to provide greater security.

In one embodiment, a decryption key corresponding to each block of legitimate data is supplied to the

decryption client 221.

In another embodiment each separate data block is encrypted using a separate encryption key. In this embodiment the dummy data and legitimate data blocks are both encrypted since the data object is split into blocks. Therefore, a plurality of decryption keys provided, one decryption key corresponding to each block. The number of keys provided for the decryption matches or exceeds the total number of blocks of the secure data object. In one example, if the secure data object is split into 10 blocks of data then a total of at least 10 keys are provided the decryption client.

In one embodiment multiple keys are provided in order to allow the decryption client to decrypt the data.

Further, keys are provided for the dummy data to make brute force attacks a lot more time consuming.

Below are two examples of the implementation of the method of securing data.

Figure 5 shows a first example. The legitimate data 501 is the data string "TOP SECRET". As per the method 400 the legitimate data is analysed. Based on this the values in the legitimate data comprise capital English letters.

Prior to encryption the dummy data 502 is selected in accordance with step 402 and then is inserted in

accordance with step 404. As seen in Figure 5, two dummy data blocks 503a and 503b are added to the legitimate data. One block of dummy data 503a is added before the legitimate data string and the other block 503b is added after the legitimate data string. The dummy data is generated by randomly selecting characters from the same set of values used in the legitimate data, hence the dummy data is also capital letters from the English alphabet.

The size of the dummy data blocks is chosen randomly from a selection range predefined by the encryption client 220. The size of the dummy data blocks to be inserted can be predefined to comprise a certain percentage of the size of the legitimate data block or string. In the illustrated example of Figure 5, the size of the dummy data blocks is predefined to comprise between 10-60% of the length of the legitimate data string. It should be understood that the dummy data block size could be larger or smaller than the illustrated example.

A secure data object 504 is created once the dummy data 502 is added to the legitimate data 501. In this example the secure data object 504 is not split and shuffled. The secure data object 504 comprises data blocks of the legitimate data and dummy data.

The secure data object 504 is then encrypted utilising a suitable encryption algorithm. An encrypted data object 505 is created following the encryption. The encrypted data object 505 may be the same as encrypted data object 210 referred to in Figure 2. As can be seen in Figure 5, the first data block 506 of the encrypted data object 505 corresponds to dummy data. The second block 507 corresponds to legitimate data and the third block 508 corresponds to dummy data. The encryption client 220 keeps a track of the three blocks 506-508 and the content of the three blocks 506-508 of the encrypted data object 505. This encrypted data object is the same generalised encrypted data object 210 described earlier. In particular the encryption client tracks the position of the legitimate data. In this example the encryption client knows the legitimate data 501 resides in the second block 507.

Figure 6 shows an embodiment of the manifest 600. In this example only a part of the extraction information is shown since the manifest 600 can comprise additional information such as encryption information. As per Figure 6, part of the manifest 600 is arranged as a table 601.

The table comprises a first column 602, second column 603 and a third column 604. The first column 601 comprises the block number, the second column 602 comprises the offset information and the third column 603 comprises the size information. The size shown in column 603 is the number of characters in each data block. The offset, in column 602, indicates the position of the first character of each data block within the encrypted data object 505. By definition the first character, of the first block 506 has an offset of zero (0) since it is the first character in the object 505. The first character of the legitimate data is the sixth character in the object 505 and hence has an offset of five (5) . The first character of the third block 508, is the sixteenth character and hence has an offset of fifteen (15) .

The information in the manifest 600 is necessary to extract the legitimate data from the dummy data. However, the extraction information in the manifest 600 is not sufficient to completely extract the legitimate data. An additional piece of information is required for the extraction of the legitimate data, namely the identity of the block of legitimate data. In one embodiment this information is communicated separately to the decryption client 221 via a separate message from the encryption client 220. The encryption client 220 has identified that block

507 corresponds to the legitimate data 501 since the encryption client 220 is arranged to track the location and size of the legitimate data. The decryption client 221 can combine this information with the information in the manifest about the offset and size of the block 507 of legitimate data to identify the section of the encrypted data 505 that relates to the legitimate data 501. The decryption client 221 identifies that decryption should start with an offset of five (5) and has a size of 10 characters long, in order to extract the legitimate data 501.

The decryption client 221 can request further decryption keys if required. These keys can be accessed from the server 200 or the location of the keys can be accessed from the server 200. In order to access the decryption keys the decryption client 221 is required to perform an authentication process as any one of the processes described earlier with respect to the recipient 206.

The decryption client may, in one embodiment, authenticate itself with the sever 200 and once authentication is completed, receive the location

information of the key. The decryption client 221 uses the location information of the key to access the decryption key. In this example, the decryption client is provided with information for three keys since three keys can be used to encrypt the secure data object 504. Preferably each block of data is encrypted with a separate encryption key as described. Since there are three blocks of data, three keys are used to encrypt the secure data object 504 to create the encrypted data object 505.

In one embodiment the decryption client requires information about which of the three keys unlocks the legitimate data. This information may be received as a separate communication. Once the decryption client 221 acquires this information, it can proceed to use the particular key to decrypt the legitimate data from the encrypted data object 505 and ignore the dummy data. The information about which key relates to the legitimate data can either be provided by the server 200 or the encryption client 220. As described in the example above, the identity of the legitimate block is

communicated separately from the manifest 600. This adds extra security since a hacker who intercepts the identity of the legitimate block still requires the manifest 600 to decrypt the data and "steal" the legitimate data.

With reference to Figure 7, a further example of the method of securing data is described. This example is an illustrative embodiment of the general method 400.

Figure 7 shows that the legitimate data 701 is the phrase "TOP SECRET INFORMATION". In accordance with the method step 401 the encryption client analyses the legitimate data to determine the values to use for the dummy data. In accordance with the method step 402 dummy data 702 is selected from the same values as the

legitimate data 701, which in this case is capital letters from the English alphabet.

In accordance with step 403 the legitimate data is split into data blocks 701a, 701b, 701c, 701d and 701e. The size of the data blocks varies, as seen in Figure 7.

In accordance with method step 404, dummy data 702 is added to the legitimate data 701. As can be seen in Figure 7 the dummy data is inserted at various positions such as position before 703, after 704 and within 705 the

legitimate data. The secure data object 706 is created. The secure data object 706 is a combination of the legitimate data and dummy data. The dummy data 702 is added at random locations. The dummy data 702 is generated by randomly selecting characters from the same character set used in the legitimate data 701

Data blocks 707a, 707b, 707c are examples of dummy data blocks within the secure data object 706, and data blocks 701a-701e are examples of the legitimate data blocks. These smaller data blocks are created to allow the dummy data blocks to be added. The data blocks can be any arbitrary sized blocks defined by the encryption client. The number of characters in each block of dummy data and each block of legitimate data is chosen randomly from within a selection range predefined by the encryption client 220. In the example above, the blocks range from 2-6 characters but can be larger or smaller than this, depending on the requirements of the encryption client 220. In this example, the blocks of dummy data and

legitimate data have been predefined to have a size which is anywhere from 9-28% of the total size of the legitimate data 701. The total size of the legitimate data is defined as the size of the entire string "TOP SECRET

INFORMATION".

Following the addition of the dummy data 702 the secure data object 706 is encrypted using a suitable encryption algorithm. Any suitable encryption algorithm can used, for example AES or triple DES. The encrypted blocks of data are then shuffled randomly by the

encryption client 220 to randomise the order of the legitimate data blocks and the dummy data blocks. Feature 709 shows the encrypted data object. The encrypted data object 709 can be the same as the encrypted data object 210 referred to earlier. Feature 710 shows the shuffled data blocks. As can be seen at 710 the arrangement of the legitimate data blocks has been changed. As part of the shuffling process various data blocks may be combined with each other. For example legitimate data blocks 701e and

701d are combined to form one data block. In an alternate form, data blocks are shuffled such that some data blocks are next to each other even if they were not to start with, for example blocks 701e and 701d.

The encryption client is arranged to record extraction information. As part of the extraction information, the encryption client 220 tracks the position and size of the legitimate data blocks and the dummy data blocks. The encryption client 220 is arranged to record the size and position of the legitimate data blocks, and optionally the size and position of the dummy data blocks, in a manifest. The extraction information provided in the manifest 600 allows a decryption client to reassemble the data and/or extract the legitimate data.

Figure 8a shows an extract of the manifest 600 for the encrypted and shuffled data shown in Figure 7. The extract is a table 801.

As with the previous example the manifest 600 does not contain the identity or correct assembly order of the legitimate blocks of data. The manifest 600 tracks the sizes of the blocks and the offset of each block, wherein the offset means the starting point or the starting letter of each block of data. In the example of Figure 8a the information is recorded in a table 801. The table 801 contains the same information regarding the data blocks as table 601. The table 801 includes a column 802 comprising the block number, a column 803 comprising the position of the starting character, defined as the offset, and a column 804 comprising the size of the block. This

information could be implemented in an XML file or HTML file or sent as part of an email such as within the email body or within an email header.

Additional information about the assembly order and the location of the legitimate data is also tracked. This information may be tracked in a suitable file or a

suitable data structure. Figure 8b shows an extract 810 of a file containing the assembly order of the legitimate data. The assembly order of the legitimate data in the example of Figure 8b is recorded in a table 811. The table 811 includes a column 812 that denotes the order of assembly, and a column 813 which includes information about the correct assembly order of the legitimate blocks. In the example of Figure 8b the first block to be

assembled is block number 10. The column 812 specifies the order of the subseguent blocks to be assembled to extract the legitimate data 701.

The method steps described above can be implemented in a different order to that shown while producing an

eguivalent result. In particular, the steps of

incorporating dummy data, encrypting and shuffling can take place in any order.

The system and method of securing data in accordance with the present invention is advantageous because it adds dummy data to legitimate data which makes a brute force attack more time consuming. The system and method further encrypts both the dummy data and the legitimate data which provides additional security and protection against a brute force attack. In an alternative embodiment of the system for securing data, the method for securing data may be

implemented by an encryption client 220 running on the server 200 instead of the sender computing device 204. In this alternative embodiment the sender is arranged to send legitimate data to the server 200. The server may perform the method of securing data as described earlier. The server 200 then sends the encrypted data object either to the sender 204 for sending to the receiver 206 or directly to the receiver 206 based on a transmit prompt from the sender 204. The server 200 may also record the extraction information in a manifest and either provide the manifest to the sender 204 for sending or directly to the receiver based on a transmit prompt from the receiver.

In an alternative embodiment of the method of securing data the encryption step 405 can be performed prior to adding the dummy data such that only the legitimate data is encrypted and then dummy data is inserted after

encryption to form a secure data object. In a further alternative embodiment the method 400 may comprise be two encryption steps, one occurring before adding the dummy data and one after adding the dummy data. In this

alternative embodiment the legitimate data is encrypted, and then the secure data object (i.e. the combination of the dummy data and legitimate data) is encrypted once again. This provides the legitimate data with two "layers" of encryption since it has been encrypted twice. This alternative embodiment provides the advantage of

additional security.

In a further alternative embodiment the encryption client 220 (i.e. the sender device 204) is arranged to transmit the manifest 600 to the decryption client

221(i.e. the receiver device 206) . The manifest 600 information may be transmitted by a secure electronic message such as an encrypted email, Bluetooth or as an unsecured electronic message as a standard email, text message, infrared communication. In another embodiment the manifest 600 may be transmitted by CD, USB key, DVD,

Blu-ray or any other physical data transfer. In yet another embodiment the manifest 600 may be transmitted as part of the message that transmits the encrypted data object 210.

In an alternative embodiment the example, the manifest itself 600 may contain the identity of the legitimate data block rather than having the identity information

separate. In this alternative embodiment the manifest 600 itself may comprise all the information required to decrypt the encrypted data object and extract the

legitimate data. The manifest 600 may contain, as part of the identity information, the offset and the size of the legitimate data.

In the example described with reference to Figures 5 and 6, the legitimate data is short string of characters, but could be a much larger data file or a much larger string or multiple strings of characters. For larger data, the dummy data used can also change to substantially correspond to the legitimate data as described earlier. The principle of inserting the dummy data is the same except the offset and size of the dummy data may be measured in bytes, kilobytes, megabytes or any other suitable measurement. It will also 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. Although a server/client architecture is described in preceding embodiments, any computer architecture may be utilised to implement embodiments of the present invention.

The above described embodiments may be implemented utilising program code. The program code may be supplied in a number of ways, for example in a computer readable medium, such as a disc or memory, or as a data signal (by downloading it from a computer) .

In the above embodiments, dummy data may be

interspersed with legitimate data so breaking the

legitimate data up. Invention is not limited to this embodiment. In other embodiments, legitimate data may be in a single block and have dummy data at one or both ends. The legitimate data can be recovered by obtaining it from the dummy data at one end or both ends . The term

"reassembly of legitimate data" should be read to cover recovery of data where the legitimate data may not be split into portions but may be in a single block.

It will 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.

Claims

THE CLAIMS DEFINING THE INVENTION ARE AS FOLLOWS:

1. A method for securing data comprising the steps of: incorporating dummy data with legitimate data to create a secure data object; and

generating extraction information, wherein the extraction information comprises information required to facilitate re-assembly of the legitimate data. 2. A method in accordance with claim 1, wherein the extraction information comprises information on the location of the legitimate data in the secure data object

3. A method in accordance with claim 1 or claim 2, wherein the extraction information comprises information on the size of the legitimate data.

4. A method in accordance with claims 1, 2 or 3, comprising the step of providing the extraction

information to a recipient to enable the recipient to reassemble the legitimate data

5. A method in accordance with claim 4, wherein the step of providing the extraction information to the recipient comprises the step of determining whether the recipient satisfies a predetermined condition, and only providing the extraction information if the predetermined condition is satisfied. 6. A method in accordance with claim 4 or claim 5, wherein the legitimate data is encrypted data, requiring a decryption key to decrypt the data.

7. A method in accordance with claim 6, comprising the step of providing the decryption key to the recipient separately from the extraction information. 8. A method in accordance with claim 6 or claim 7, comprising the step of storing the decryption key and extraction information for provision to the recipient, the decryption key and extraction information being stored in separate locations .

9. A method in accordance any one of the preceding claims, wherein the step of incorporating the dummy data comprises the step of selecting the dummy data from a set of values that is identical to a set of values used in the legitimate data.

10. A method in accordance with any one of the preceding claims, wherein the step of incorporating dummy data comprises the step of inserting dummy data at one or more of the following positions:

- within the legitimate data; and

- at one or both ends of the legitimate data.

11. A method in accordance with any one of the preceding claims wherein a predetermined quantity of dummy data is incorporated in the legitimate data, the predetermined quantity being specified as a percentage of the size of the legitimate data. 12. A method in accordance with any one of the preceding claims, further comprising a step of splitting the legitimate data into smaller data blocks and interspersing said data blocks with dummy data blocks.

13. A method in accordance with claim 12, wherein the step of splitting the legitimate data further comprises

randomly selecting, within preset ranges, the size and guantity of the blocks of legitimate data.

14. A method in accordance with claim 12, wherein the step of splitting the legitimate data further comprises

randomly selecting, within preset ranges, the size and guantity of the blocks of dummy data.

15. A method in accordance with claim 12, wherein the extraction information includes the information about the guantity of blocks of legitimate data and dummy data.

16. A method in accordance with claim 12, further

comprising a step of changing the order of the blocks of legitimate and dummy data after the legitimate data blocks have been interspersed with dummy data blocks .

17. A method in accordance with claim 16, wherein the extraction information comprises an assembly order of the legitimate data blocks. 18. A method in accordance with claim 12, wherein the legitimate data is encrypted data reguiring at least one decryption key to decrypt the data, further comprising a step of separately providing a plurality of the decryption keys to an authorised recipient, wherein the guantity of decryption keys is the same as or greater than the

guantity of data blocks comprising the legitimate and dummy data, and wherein the extraction information further comprises information to facilitate selection of a suitable decryption key for each block of legitimate data.

19. A method in accordance with claim 12, further comprising a step of encrypting the smaller blocks of legitimate data, wherein the step of encryption comprises selecting an encryption algorithm for each block of legitimate data from a set of containing multiple

encryption algorithms . 20. A method in accordance with claim 1, further

comprising a step of encrypting the legitimate data, wherein multiple encryption algorithms are applied to the legitimate data. 21. A method in accordance with claim 1, further

comprising a step of encrypting the dummy data and the legitimate data.

22. A method in accordance with claim 21, wherein the encrypted dummy data is indistinguishable from the encrypted legitimate data.

23. A method in accordance with claim 21, wherein the dummy data is composed of the same values contained in the legitimate data, wherein each value in the dummy data is used with substantially the same freguency as each respective value in the legitimate data.

24. A system for securing data comprising:

a processor arranged to incorporate dummy data with legitimate data to create a secure data object; and

the processor arranged to generate extraction information, wherein the extraction information comprises information required to facilitate re-assembly of the legitimate data.

25. A system in accordance with claim 24, wherein the extraction information comprises information on the location of the legitimate data in the secure data object

26. A system in accordance with claim 24 or claim 25, wherein the extraction information comprises information on the size of the legitimate data.

27. A system in accordance with claims 24, 25 or 26, comprising a recipient, the recipient being a computing device and the processor is arranged to provide the extraction information to a recipient to enable the recipient to re-assemble the legitimate data

28. A system in accordance with claim 27, wherein the processor is arranged to determine whether the recipient satisfies a predetermined condition, and the processor only providing the extraction information if the

predetermined condition is satisfied.

29. A system in accordance with claim 27 or claim 28, wherein the legitimate data is encrypted data, requiring a decryption key to decrypt the data.

30. A system in accordance with claim 29, wherein the processor is arranged to provide the decryption key to the recipient separately from the extraction information.

31. A system in accordance with claim 29 or claim 30, wherein the processor arranged to store the decryption key and extraction information for provision to the recipient, the decryption key and extraction information being stored in separate locations . 32. A system in accordance with any one of claims 24 to 31 comprising two or more separate storage devices, one of the plurality of storage devices arranged to store the extraction information and another storage device arranged to store the decryption key.

33. A system in accordance any one of claims 24 to 32, wherein the processor is arranged to select the dummy data from a set of values that is identical to a set of values used in the legitimate data.

34. A system in accordance with any one of the claims 24 to 32, wherein the processor is arranged to insert the dummy data at one or more of the following positions:

- within the legitimate data; and

- at one or both ends of the legitimate data.

35. A system in accordance with any one of the claims 24 to 34 wherein the processor is arranged to incorporate a predetermined quantity of dummy data in the legitimate data, the predetermined quantity being specified as a percentage of the size of the legitimate data.

36. A system in accordance with any one of claims 24 to 35, the processor is arranged to split the legitimate data into smaller data blocks and interspersing said data blocks with dummy data blocks . system in accordance with claim 36, wherein the processor is arranged to randomly select, within preset ranges, the size and quantity of the blocks of legitimate data . 38. A system in accordance with claim 36, wherein the processor is arranged to randomly select, within preset ranges, the size and quantity of the blocks of dummy data.

39. A system in accordance with claim 36, wherein the extraction information includes the information about the quantity of blocks of legitimate data and dummy data.

40. A system in accordance with claim 36, wherein the processor is arranged to change the order of the blocks of legitimate and dummy data after the legitimate data blocks have been interspersed with dummy data blocks .

41. A system in accordance with claim 40, wherein the extraction information comprises an assembly order of the legitimate data blocks.

42. A system in accordance with claim 36, wherein the legitimate data is encrypted data requiring at least one decryption key to decrypt the data, the processor is arranged to separately provide a plurality of the decryption keys to an authorised recipient, wherein the quantity of decryption keys is the same as or greater than the quantity of data blocks comprising the legitimate and dummy data, and wherein the extraction information further comprises information to facilitate selection of a suitable decryption key for each block of legitimate data. system in accordance with claim 36, wherein the processor is arranged to encrypt the smaller blocks of legitimate data, the processor being further arranged to select an encryption algorithm for each block of

legitimate data from a set of multiple encryption

algorithms .

44. A system in accordance with claim 24, wherein the processor is arranged to encrypt the legitimate data, wherein the processor is further arranged to apply multiple encryption algorithms to the legitimate data.

45. A system in accordance with claim 24, wherein the processor is arranged to encrypt the dummy data and the legitimate data.

46. A system in accordance with claim 45, wherein the encrypted dummy data is indistinguishable from the encrypted legitimate data. 47. A system in accordance with claim 45, wherein the dummy data is composed of the same values contained in the legitimate data, wherein each value in the dummy data is used with substantially the same frequency as each respective value in the legitimate data.

48. A computer program arranged to, when executed on a computing system, perform the method steps of any one of Claims 1 to 23. 49. A computer readable medium incorporating a computer program in accordance with Claim 48.

50. A data signal, comprising a computer program in accordance with Claim 48.