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 cryptographic keys may be protected during delivery.

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 of the invention, there is provided a computer implemented method for protection of cryptographic keys during delivery to a recipient, comprising:

a server creating a plurality of keys and

identifiers, each identifier associated with a respective key;

a recipient requesting keys for cryptographic use; the server, upon authentication of the recipient as an authorised client, transmitting to the recipient the plurality of keys with identifiers;

the recipient selecting a sub-set of keys from the plurality of keys and communicating identifiers of keys in the selected sub-set to the server;

the recipient using the selected sub-set of keys to encrypt the data object information, and transmitting the encrypted data object information to the server; and

the server storing in a secure database the

identifiers of the selected keys.

The server may further store the encrypted data object information if transmitted by the recipient.

In an embodiment, the server configures the plurality of keys in a predetermined data structure. The

predetermined data structure may include indices for the plurality of keys to uniquely identify each key. In an embodiment, the predetermined data structure is known to authorised clients.

In an embodiment, the predetermined data structure comprises an array of defined size and order. The array may be non-contiguous and the identifiers or indices are pointers .

In an embodiment, a symmetric cryptographic scheme is used in which encryption keys and decryption keys are the same. If the recipient is an encryption client, the server stores the selected sub-set of keys (the encryption keys) and the encrypted key indices, as identified by the client, for later decryption of data objects under the symmetric cryptographic scheme.

In an alternative embodiment, an asymmetric

cryptographic scheme is used in which encryption keys and decryption keys are different. If the recipient is an encryption client, the server stores the encryption key indices of the selected sub-set of keys. The encryption key indices are the same as the decryption key indices.

In accordance with a second aspect of the invention, there is provided a computer implemented method for protection of cryptographic keys during retrieval by a recipient, comprising:

a server generating a plurality of cryptographic keys, wherein a subset of the plurality of keys are legitimate keys and the other keys are invalid keys; the server maintaining in a secure database, a set of identifiers associated with the legitimate keys;

a recipient requesting keys from the server; the server, upon authentication of the recipient as an authorised client, retrieving from the secure database the identifiers for the legitimate keys; transmitting the plurality of keys to the recipient; and

communicating to the recipient the identifiers for the legitimate keys .

In an embodiment, a symmetric cryptographic scheme is used in which encryption keys and decryption keys are the same. If the recipient is a decryption client, the server further stores the encryption keys, identified by an encryption client, for decryption of data objects. In an alternative embodiment, an asymmetric

cryptographic scheme is used in which encryption keys and decryption keys are different. If the recipient is a decryption client, the identifiers for legitimate keys are common to encryption and decryption keys, in suitable key pairs .

In accordance with a third aspect of the invention, there is provided a system for protection of cryptographic keys during delivery to a recipient by a server over a communications link, comprising:

the server having a key generation module arranged to create a plurality of keys and identifiers, wherein each identifier is associated with a respective key; the recipient including a communications interface for requesting keys for cryptographic use;

the server, upon authentication of the recipient as an authorised client, arranged to transmit to the recipient the plurality of keys and identifiers;

the recipient including:

a processor arranged to select a subset of keys from the plurality of keys for

encryption of data objects, and a communications interface arranged to communicate identifiers of keys in the selected subset to the server; and the server having a secure database arranged for storage of the identifiers of the selected subset of keys received from the recipient client.

In accordance with a fourth aspect of the invention, there is provided a system for protection of cryptographic keys during retrieval by a recipient from a server over a communications link, comprising:

the server having a key generation module for generating a plurality of cryptographic keys, wherein a sub-set of the plurality of keys are legitimate keys and the other keys are invalid keys;

the server having a secure database arranged for maintaining a set of identifiers associated with the legitimate keys;

the recipient including a communications interface for requesting keys from the server;

the server having an authentication module arranged to ensure the recipient is an authorised client and, upon authentication, retrieving from the secure database the identifiers for the legitimate;

the server arranged to transmit the plurality of keys to the recipient; and

communicating to the recipient the identifiers for the legitimate keys .

In an embodiment, the server key generation module is arranged to configure the plurality of keys in a

predetermined data structure. The predetermined data structure may include indices for the plurality of keys to uniquely identify each key.

In an embodiment, the predetermined data structure is known to authorised clients. In an embodiment, the predetermined data structure comprises an array of defined size and order. The array may be non-contiguous and the identifiers or indices are pointers .

In an embodiment the system uses a symmetric

cryptographic scheme, wherein the key generation module provides legitimate encryption keys and decryption keys that are the same.

In an alternative embodiment the system uses an asymmetric cryptographic scheme, wherein the key

generation module provides legitimate encryption keys and decryption keys that are different, in suitable key pairs.

In accordance with a fifth aspect of the invention, there is provided a method for protection of cryptographic keys during delivery to a recipient, comprising the steps of creating a plurality of keys and identifiers, each identifier associated with a respective key:

receiving a request for keys for cryptographic use;

upon authentication of a recipient as an authorised client, transmitting to the recipient a plurality of keys with identifiers; receiving identifiers of a selected subset of keys from the plurality of keys;

receiving encrypted data object information, encrypted by the selected subset of keys; and storing the identifiers of the selected keys.

In accordance with a sixth aspect of the present invention, there is provided a method for protection of cryptographic keys during retrieval by a recipient, comprising the steps of:

generating a plurality of cryptographic keys, wherein a subset of the plurality of keys are legitimate keys and the other keys are invalid keys ;

storing a set of identifiers associated with the legitimate keys;

receiving a request for keys and, upon authentication of a recipient as an authorised client, retrieving the identifiers for the legitimate keys;

transmitting the plurality of keys to the recipient; and

communicating to the recipient the identifiers for the legitimate keys . In accordance with a seventh aspect, the present invention provides a system for protection of

cryptographic keys during delivery to a recipient by a server over a communications link, comprising:

the server having a key generation module arranged to create a plurality of keys and identifiers, wherein each identifier is associated with a respective key;

the server being arranged, upon authentication of the recipient as an authorised client, and upon receiving a request for keys for cryptographic use, to transmit to the recipient the plurality of keys and identifiers; the server being arranged to receive selected communication identifiers of a selected subset of keys selected by the recipient; and the server being arranged to store the identifiers of the selected subset of keys received from the recipient client. In accordance with an eighth aspect, the present invention provides a system for protection of

cryptographic keys during retrieval by a recipient from a server over a communications link comprising:

the server having a key generation module for generating a plurality of cryptographic keys, wherein a subset of the plurality of keys are legitimate keys and the other keys are invalid keys ;

the server storing a set of identifiers associated with the legitimate keys;

the server being arranged to receive a request for keys and having an authentication module arranged to ensure the recipient is an authorised client and, upon authentication, the server being arranged to retrieve the identifiers for the legitimate keys;

the server being arranged to transmit the plurality of keys to the recipient and to communicate to the recipient the identifiers for the legitimate keys. In accordance with a ninth aspect of the invention, there is provided a method for facilitating the security of encrypted data, comprising steps of generating a plurality of keys for encryption of data or decryption of data, one or more of the keys being valid for encryption or decryption, and one or more being invalid for

encryption or decryption, and generating identification information enabling identification of the one or more valid keys . In accordance with a tenth aspect of the invention, there is provided a system for facilitating the security of encrypted data, comprising a processor arranged to generate a plurality of keys for encryption of data or decryption of data, one or more of the keys being valid for the encryption or data or decryption of data, and one or more of keys being invalid for encryption of data or decryption of data, the processor arranged to generate identification information enabling identification of the one or more valid keys.

In accordance with an eleventh aspect, the present invention provides a computer program comprising

instructions for controlling a computer to implement a method or system in accordance with any of the preceding aspects of the invention.

In accordance with a twelfth aspect, the present invention provides a computer readable medium providing computer program in accordance with the ninth aspect of the invention.

In accordance with a thirteenth aspect, the present invention provides a data signal comprising a computer program in accordance with the ninth aspect of the invention . 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;

Figure 3 is a block diagram of a system for

protecting encryption keys in accordance with a further embodiment of the invention, including an encryption client; Figure 4 is a block diagram of a system for

protecting encryption keys in accordance with the further embodiment of the invention, including a decryption client;

Figure 5 is a flow chart illustrating an embodiment of the method relating to encryption, such as employed in the embodiment of the system shown in Figure 3; and

Figure 6 is a flow chart illustrating an embodiment of the method relating to encryption, such as employed in the embodiment of the system shown in Figure 4.

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 decrypted data to the data recipient.

In this example embodiment, the module,

authentication routine, and/or decrypting processor may be implemented by one or more electronics 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 a server, personal computers, terminals, wireless or handheld computing devices. At least one of a plurality of communications link 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, 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 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. The 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 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 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 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 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 the above embodiments, it can be important to protect cryptographic keys during their delivery by transmission over a communications network from an encryption service provider to clients involved in encryption and/or decryption processes. For example, delivery to a client machine running an encryption application (referred to as an "encryption client") and to a separate client machine running a decryption application (referred to as a "decryption client") .

In further 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, referred to as "key obfuscation" , render it unfeasible or impractical for a hacker to use the data for any meaningful purpose, thus protecting the legitimate keys. Each key, genuine or dummy, is suitably associated with a unique identifier.

In an example system of the further embodiment an intermediate encryption service provider, such as an authorisation server ("Auth server") , prepares the sets of keys K for purposes of encryption and decryption. Each key in a set of keys is suitably associated with an identifier. Thus, the arrangement suitably provides a unique identifier for each key in the set. The Auth server arranges the sets of keys in a data structure that has a defined size and order known to both the encrypting client and decrypting client applications. The same data structure should be used for encryption and decryption in the system of the embodiment. The data structure for the sets of keys can be an array, such as a one-dimensional or two-dimensional array. Each key within the data structure has an identifier in the form of an index which is unique within the data structure, allowing the key to be

referenced. For example, if a set K of 10 keys

{ki, k ₂ ,...ki ₀ } is stored as a one-dimensional array, the indices i of the keys are {1, 2, ...10}.

At encryption, as illustrated in Figure 3, the encryption client 304 requests the Auth server 302 (Auth server may have similar configuration and functionality to server 200) to supply a set of encryption keys K _e over communications link 306. When the key set K _e is received by the client, the encryption client 304 selects a subset of the keys K _e for encrypting the data. The selected subset of keys are then the "legitimate" keys for use in data encryption and the others are "invalid" keys.

Example I : If K _e contains 6 keys {A, B, C, D, E, F} and the client needs to encrypt two pieces of data, it might select two legitimate keys B and E which have indices 2 and 5, respectively. This arrangement of keys is set out in encryption portion of Table 1, below .

The encrypting client 304 then communicates to the Auth server 302 the index of each key used in the

encryption of the data, but does not send the keys themselves . One method of communicating the indices to the Auth server is described below in relation to Figure 5. If multiple pieces of data 308 (usually separate files F) are encrypted, the encryption client 304 advises: (a) which keys are legitimate; and (b) which legitimate key was used to encrypt each file. The encryption client 304 does this by communicating the corresponding index i of the legitimate key for each piece of data to the Auth server 302.

Example I (cont.) : The encryption client 304

communicates indices 2 and 5 to the Auth server 302, e.g. Fx : Index = 2; F ₂ : Index = 5. The encryption client 304 can also specify additional access restrictions for each encrypted file F _x and F ₂ , e.g. the authorised recipient name, or a window of time in which file access is valid, as required.

The auth server 302 then stores, the corresponding index and any other access restrictions for each encrypted data item ( Fi , F ₂ ) in records contained in a secure database 310.

Turning to Figure 5, there is shown an embodiment of the method which concerns key generation for encryption purposes. This commences on the recipient (client) side 500 with a request 502 to a server (such as server 200) for encryption keys. In response the server creates an indexed, key set suitable for cryptographic purposes in step 503. The key set is then transmitted to the

recipient in step 504, after ensuring the recipient 500 is an authorised encryption client. The client 500 then selects a subset of the keys for encrypting data objects, here in the form of files, in step 505. The encrypted files will then be considered secure data objects. In step 506, the client communicates the indices of the selected keys, i.e. indices of the "legitimate keys", together with data object information, including file names to the server 501. The server then stores the key indices with the respective file names in order to facilitate later decryption . It will be appreciated that the method of the further embodiment can be implemented as either a symmetric cryptographic scheme (identical keys are used for

encryption and decryption) or an asymmetric cryptographic scheme (key pairs that are different for encryption and decryption) .

Symmetric keys: where the implementation uses a symmetric cryptographic scheme, the Auth server 302 stores the legitimate keys in database 310 for later use also in decryption as in the foregoing example.

Asymmetric keys: where the implementation uses an asymmetric cryptographic scheme the Auth server stores the indices but not the encryption keys. In relation to Figure 4, the Auth server 402 does not store the legitimate decryption keys .

Example II : The Auth server 402 stores indices 2 and 5 in database 410.

In the asymmetric scheme of the present example, the server does not store any of the encrypting keys. In contrast, a symmetric scheme, the server stores the legitimate keys B and E but does not store the invalid keys.

We turn now to the counterpart decryption aspects of the secure data communications transaction of the further embodiment, with reference to Figure 4. When a decryption client 404 requests keys to decrypt a piece of secure data in an asymmetric scheme, the Auth server 402 prepares a new set of keys K _d specific to the decryption client 404 and for that piece of information. The decryption keys K _d have the same data structure as K _e and include the same quantity of legitimate keys as K _e . The legitimate keys of K _d have the same indices as the legitimate keys of K _e . The invalid, keys of K _d are however different to the invalid keys of K _e . The Auth server 402 generates new invalid keys each time decryption keys are issued, but the indices of the legitimate keys do not change.

Symmetric system: the legitimate keys within K _d and K _e are effectively identical and the legitimate keys are the only keys that K _e and K _d have in common .

Asymmetric system: all keys within K _d and K _e are different but the indices of legitimate keys for

decryption and encryption are preferably the same. Example II (cont.) : The legitimate keys are allocated to indices 2 and 5.

For a symmetric system (Table 1) the legitimate keys of K _d are B and E, i.e. the same legitimate keys used at encryption.

For an asymmetric system (Table 2) the legitimate keys of K _d are H and K, i.e. different to the keys B and E used at encryption. The Auth server 402 stores keys H and K in database 410.

Encryption Decryption

keys K _e keys K _d

Table 1: Keys in a symmetric cryptographic scheme.

In Table 1, above, it can be seen that the legitimate keys at indices 2 and 5 are identical at encryption and decryption for a symmetric scheme.

Encryption Decryption keys K _e keys K _d

Index Key Index Key

1 A 1 G

2 B 2 H

3 C 3 I

4 D 4 J

5 E 5 K

6 F 6 L Table 2: Key pairs in an asymmetric cryptographic scheme

It can be seen from Table 2, above, that the

legitimate keys at indices 2 and 5 are different at encryption and decryption in an asymmetric scheme.

For the decryption client 404 to be able to identify the legitimate keys of K _d , it must obtain the indices of the legitimate keys. A method of communicating the indices to a decryption client is described below in relation to Figure 6. Based on these indices, the decryption client can identify the legitimate keys and use these keys to decrypt the files.

Example II (cont.) : The decrypting client is advised by the Auth server 502 that the legitimate keys have indices 2 and 5.

For an asymmetric system (Table 2) the client uses indices 2 and 5 to determine that the legitimate keys are H and K.

In contrast, for a symmetric system (Table 1) the client uses indices 2 and 5 to determine that the legitimate keys are A and E.

If, on another occasion, the decryption client 404 again requests decryption keys for the same data items - such as files F _x and F ₂ , the Auth server 402 generates a new set of keys K _d with the same legitimate keys and corresponding indices but new keys are allocated to others of the indices .

Turning to Figure 6, there is shown an embodiment of the method which concerns key retrieval for decryption purposes. The server side 601 currently maintains a database of key sets, including keys for secure data objects and associated data object information, such as file names of files contained in the secure data objects. On the recipient (client) side 600, a request is

transmitted in step 603 to the server for encryption keys to enable decryption of files. The recipient 600 is authenticated by the server 601 as an authorised

decryption client in step 604. The server 601 then generates decryption keys and sends these to the client. The server also retrieves the indices of legitimate keys relating to the target files in step 605. The indices of legitimate keys are transmitted by the server in step 606. The client 600, after receipt in step 607, then receives from the server the full set of keys (comprising

legitimate and invalid keys) and the indices of the legitimate keys to enable decryption in steps 608 and 609. Generally speaking, a recipient's level of access to the content of secure data is determined by the sender at the time of encryption. The recipient will only be provided with indices of legitimate keys for data that they are authorised to access and that they have

specifically requested. This means that the recipient of secure data may not necessarily be given access to all of the pieces of the secure data. The remaining pieces or parts of the secure data remain encrypted without the legitimate keys to those parts.

An advantage of the embodiment for protecting encryption keys is that the transitory nature of the keys tends to deters hackers from making repeated brute-force attempts .

Both encryption and decryption require the indices of the legitimate keys to be communicated between an

intermediate encryption service provider and its clients. There are many ways of doing this. One way is to simply send the indices to the intermediate encryption service provider, such as Auth servers 302 or 402 in the above described embodiments, optionally in a separate

transmission to the keys.

In summary , the method and system of the preferred embodiment employs obfuscating keys whenever encryption and/or decryption keys are transmitted to a client.

Legitimate keys are transmitted within a larger set of keys that includes invalid keys with the same format as the legitimate keys. Accordingly, a brute-force attack on the encryption system would require the invalid keys to be tested as well as the legitimate keys. This allows the embodiment to increase data security without increasing the number of bits in the keys or otherwise increase their complexity .

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

Any reference to prior art contained herein is not be taken as an admission that the information is common general knowledge, unless otherwise indicated.

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 .