GB2522096A

GB2522096A - Data encryption and decryption

Info

Publication number: GB2522096A
Application number: GB1417783.6A
Authority: GB
Inventors: Steven John Dixon
Original assignee: SUNDOWN SOLUTIONS Ltd
Current assignee: SUNDOWN SOLUTIONS Ltd
Priority date: 2014-10-08
Filing date: 2014-10-08
Publication date: 2015-07-15
Anticipated expiration: 2034-10-08
Also published as: GB201417783D0; GB2522096B

Abstract

The invention comprises a pseudo random number generator employed to create and encryption key stream. Multiple known key sequences are loaded into memories 304A-D. Segments of each of these sequences are read out in a non linear order and then combined in order to create the key stream. In the embodiments the invention reads multiple segments from a random number loaded into a further memory 302. These segments may step through the random number by differing amounts for each key sequence. The reading points may be calculated using a time dependent formula. The random number segments read out are then used to address the key sequences and the segments of the key sequences read out are combined (e.g. by XOR operations) to produce the output pseudorandom key stream. This can then be combined with the plain text (e.g. in another XOR operation).

Description

Data Encryption and Decryption

Field of the Invention

The present invention relates to data encryption and decryption, and to related devices and methods.

Background to the Invention

A major security risk for IT systems is the human element. End users having access to, and knowing, their usernames and passwords is typically one of the mains threat to any system.

Currently, the main encryption standards for the internet are based on Secure Sockets Layer (SSL) encryption. However, Open SSL has been compromised and the risk of other SSL standards being compromised has increased. Information about SSL encryption standards is publicly available, which can, unfortunately, assist in undermining its security.

It is an aim of example embodiments of the present invention to address at least one disadvantage of the prior art, whether identified herein or otherwise.

Summary of the Invention

Embodiments of the encryption method describe herein can create a secondary, secure encryption mechanism which can be used on top of SSL encryption as an extra layer of protection. Embodiments can use disposable" keys which are used, typically during one data exchange session only, to allow secure transmission of data between client and server.

Embodiments can encrypt the data packet before sending overthe encrypted SSL channel. As embodiments can be independent of SSL encryption, they can be used on any SSL secure channel. Typically, implementations will securely transfer small amounts of security-related data, such as usernames, passwords, geo-coordinates and/or confidential data for applications. Thus, user identifiable data will not normally need to be stored on the user device, effectively removing the conventional need for hard-coding credentials into applications.

Embodiments can use the "disposable" keys which are only used for single connection and then are deleted. In some embodiments, the "disposable" keys comprise 4 X 2048 bit, cryptographically random generated keys and a 1024 byte cryptographically generated number sequence.

The security provided by the embodiments can arise from the unpredictability of the cryptographically generated data, which does not use any pre-existing seed, known phrase, stored data or stored certificate. Further, also each portion, e.g. byte, of the payload can be encrypted multiple (e.g. 4) times, with each such encryption being based on a portion, e.g. byte, of each encryption key. This, along with the 1024 random number sequence, a time sensitive key offset and each key used in a difference sequence, can ensure that the key data is used in an unpredictable order by embodiments.

In order to detect any tampering of the data in transit, embodiments can create a cryptographic SHA256 hash of the payload at the sender device. The payload can be encrypted along with the hash. During decrypting a second hash can be created from the decrypted data and then compared to the original hash. If they are the same, this can indicate that the payload has not been tampered with in transit.

According to embodiments, the first time a client connects to a server it can be given an activation encryption key which can then be used once to en/decrypt a new set of keys. This activation key can be securely stored in an app or securely transferred to the client at first operation. Once the client has the activation key, the server can send a new set of encryption key (encrypted using the activation key), which the client can decode using the activation key.

Once it has decrypted the new set of encryption keys, the activation key is typically no longer needed and all future communication can be completed using the new encryption key (with the activation key being permanently deleted).

In some embodiments, standard communications will start with the client sending the device/client number, or other identifier, over SSL to the server, and then retrieving its own copy of the encryption keys (which have not previously been used). The server can then use the client/device identifier to identify the client and retrieve the server-stored copy of the appropriate encryption keys. Communication can then continue using these encryption keys to securely exchange data between the client and server. Once communication is complete, the last action of the encryption process will typically be for the server to generate a new set of encryption keys and securely send these to the client. Once the client receives the new encryption keys, it can delete the current encryption key and securely store the new encryption key ready for the next communication session.

Embodiments are not normally designed to perform any client/server authentication, but can allow highly secure exchange of authentication data, user identifiable data and app data (for example, geo-coordinates) between the client and server.

In a first aspect, the present invention provides a method of encrypting data comprising: receiving data to be encrypted, the data comprising a sequence of data portions (e.g. a sequence of bytes making up a payload); obtaining a set of keys, each said key comprising a plurality of key portions (e.g. bytes); determining a sequence of the key portions of the keys in the set, the sequence representing an order in which the portions of the keys are to be used for performing encryption operations, and generating encrypted data by using the key portions, according to the sequence of key portions, in combination with corresponding said data portions of the data to be encrypted in a said encryption operation.

The method may include for each said data portion (e.g. byte) of data to be encrypted: a) obtaining the key portion of a first said key in the set based on the sequence of key portions; b)performing a said encryption operation (e.g. an XOR function) based on the obtained key portion of the first said key and the data portion of the data be encrypted to generate an encrypted data portion; c) obtaining the key portion of a next said key in the set based on the sequence of key portions; d) performing a said encryption operation based on the obtained (at step c)) key portion of the key and the encrypted data portion to regenerate the encrypted data portion; e) repeating steps c) and d) for each remaining said key in the set, and fl including the encrypted data portion generated by a last of the performing a said encryption operation steps in the generated encrypted data (e.g. for transfer to a server).

A said encryption operation may comprise an XOR operation (e.g. based on the portion of the key and the portion of the data to be encrypted, or based on the portion of the key and the encrypted data portion).

The determining of the sequence of key portions may comprise (for each said key in the set): generating or obtaining data representing a number sequence; selecting a number from the number sequence; using the selected number to select a said key portion of the key, and adding the selected key portion of the key to the sequence of key portions.

The selecting of the number from the number sequence may be based on a step size for a said key (wherein the step size indicates a distance between the bytes/portions that are selected for the key from the number sequence), a computed time-related value and/or a location of the portion of the data to be encrypted (with respect to a first/start location of the data to be encrypted) being currently processed by the method.

The computed time-related value may be computed based on a time period of time elapsed between when the method started to encrypt the data to be encrypted and a reference time stored in a storage location in communication with/accessible by a device that is performing the encryption method.

The computation of the time-related value may be based on a formula. In some embodiments, the formula may comprise: TimeOffset = (EncryptionTimeMs -ReferenceTimeMs) MOD Seqlen wherein EncryptionTimeMS = the time when the method started to encrypt the data to be encrypted in milliseconds; ReferenceTimeMS = the reference time in milliseconds, and Seqlen corresponds to an amount of numbers in the number sequence.

Data (typically not encrypted) representing the reference time may be transferred to a receiver of the generated encrypted data, e.g. by inclusion in a packet containing the generated encrypted data.

The selecting of the number from the number sequence may be based on a formula. In some embodiments, the formula may comprise: Number to be selected = ((TimeOffset + CurrentPayloadLocation) * (Stepsize + (CurrentPayloadLocation / 1024D) % 1024 wherein CurrentPayloadLocation = current byte/portion of the data to be encrypted Stepsize = number of bytes/portions skipped between each read of the number sequence.

The method may further include: generating a hash value based on the data to be encrypted; encrypting the hash value according to the method, and transferring data representing the encrypted hash value to a receiver of the generated encrypted data, e.g. by inclusion in a packet containing the generated encrypted data.

A number of the numbers in the number sequence for each said key may correspond to a number of the portions of the data to be encrypted, plus a number of portions representing the encrypted hash value.

The method may comprise: storing data representing the reference time, the number sequence and/or the set of keys in a storage location accessible by a device performing the encryption method; storing data representing the reference time, the number sequence and/or the set of keys in a storage location accessible by a device that is to decrypt the generated encrypted data; Following the generation of encrypted data the method may further comprise: deleting the stored data representing the reference time, the number sequence and/or the set of keys in the storage location accessible by the device that is performing the encrypted method; deleting the stored data representing the reference time, the number sequence and/or the set of keys in the storage location accessible by the device that is to decrypt the generated encrypted data; generating a new said reference time, said number sequence and/or said set of keys to replace the set of keys; storing data representing the new said reference time, said number sequence and/or said set of keys in the storage location accessible by the device performing the encryption method, and storing data representing the new said reference time, said number sequence and/or said set of keys in the storage location accessible by the device that is to decrypt the generated encrypted data.

The method may further comprise: obtaining or generating an initial encryption key; transferring data representing the initial encryption key to a device that is to receive the generated encrypted data (e.g. via a secure network channel, such as an SSL link); encrypting the set of keys using the initial encryption key; transferring the encrypted set of keys to the device.

The initial encryption key may comprise data representing said reference time, said number sequence and/or said set of keys.

The data to be encrypted may include security-related data, e.g. username, password, or location information.

The set of keys may be obtained (e.g. retrieved from a secure storage location) based on an identity of a device that is creating/sending the encrypted data.

A said portion of a said key may comprise a byte. A said portion of the data to be encrypted may comprise a byte.

In some embodiments, the set of keys comprises four said keys.

The method may include transferring the generated encrypted data to a receiver. The generated encrypted data may be transferred via a secure SSL channel.

In another aspect, the present invention provides a method of decrypting data comprising: receiving encrypted data, the encrypted data including a sequence of data portions; obtaining a set of keys, each said key comprising a plurality of key portions; determining a sequence of key portions of each said key in the set, the sequence representing an order in which the portions of the keys are to be used for decryption operations, and generating decrypted data by using the key portions of the keys, according to the sequence of key portions, in combination with corresponding said data portions of the encrypted data in a said decryption operation.

The method of decrypting data may comprise steps that can be the reverse of the steps of the encryption method described herein.

The method may further include: decrypting a portion of the received data representing the encrypted hash value to generate a first hash value; generating a second hash value based on the decrypted data; comparing the first hash value and the second hash value to determine if the decrypted data accurately corresponds to the original data to be encrypted.

In another aspect, the present invention provides a (server) method of securely transferring data comprising: obtaining or generating an initial encryption key; transferring data representing the initial encryption key to a remote device (e.g. via a secure network channel, such as an SSL link); obtaining or generating a set of encryption keys;

B

generating encrypted data representing the set of encryption keys encrypted using the initial encryption key; transferring the encrypted data to the remote device, and using the set of encryption keys for further communication with the remote device.

In another aspect, the present invention provides a (client) method of securely transferring data comprising: receiving data representing an initial encryption key from a device (e.g. via a secure network channel, such as an SSL link); receiving encrypted data representing a set of encryption keys encrypted using the initial encryption key from the device; decrypting the set of encryption keys using the initial encryption key, and using the set of encryption keys for further communication with the device.

In another aspect, the present invention provides a (server) method of secure communication comprising: obtaining data representing a set of encryption keys associated with a remote device from a data store; using the set of encryption keys for secure communication with the remote device; deleting the set of encryption keys from the data store; generating or obtaining a new set of encryption keys; storing the new set of encryption keys in the data store, and transferring data relating to the new set of encryption keys to the remote device.

In another aspect, the present invention provides a (client) method of secure communication comprising: obtaining data representing a set of encryption keys from a data store; using the set of encryption keys for secure communication with a device; deleting the set of encryption keys from the data store; obtaining data relating to a new set of encryption keys, typically from the device, and storing the new set of encryption keys in the data store.

In another aspect the present invention provides a data encryption/decryption method comprising: obtaining a set of encryption keys, and using at least a portion (e.g. byte) of at least some of the encryption keys in the set to encrypt (or decrypt) a portion of data to be securely stored or transferred.

In another aspect the present invention provides a method of providing secure access to a device or data comprising: requesting access to a device or data, and transferring security-access data encoded using an encryption technique to a device sending the access request.

In another aspect the present invention provides a secure data transfer method comprising: transferring news-related data or location-related data encoded using an encryption technique to/from a device over a network.

In another aspect the present invention provides a method of generating a set of encryption keys substantially as described herein.

According to other aspects of the present invention there are provided computer readable mediums storing computer programs to operate methods substantially as described herein.

According to other aspects of the present invention there are provided systems or devices (e.g. client and server devices) configured to operate methods substantially as described herein.

In an aspect the invention provides apparatus configured to encrypt data comprising: a device configured to receive data to be encrypted, the data comprising a sequence of data portions; a device configured to obtain a set of keys, each said key comprising a plurality of key portions; a device configured to determine a sequence of the key portions of the keys in the set, the sequence representing an order in which the key portions of the keys are to be used for performing encryption operations, and a device configured to generate encrypted data by using the key portions, according to the sequence of key portions, in combination with corresponding said data portions of the data to be encrypted in a said encryption operation.

In another aspect the invention provides apparatus configured to decrypt data comprising: a device configured to receive encrypted data, the encrypted data including a sequence of data portions; a device configured to obtain a set of keys, each said key comprising a plurality of key portions; a device configured to determine a sequence of key portions of each said key in the set, the sequence representing an order in which the key portions of the keys are to be used for decryption operations, and a device configured to generate decrypted data by using the key portions, according to the sequence of key portions, in combination with corresponding said data portions of the encrypted data in a said decryption operation.

According to the present invention there is provided an apparatus and method as set forth in the appended claims. Other features of the invention will be apparent from the dependent

claims, and the description which follows.

Brief Introduction to the Figures

For a better understanding of the invention, and to show how embodiments of the same may be carried into effect, reference will now be made, by way of example, to the accompanying diagrammatic drawings in which: Figure 1 schematically shows examples of computing devices in communication over a network, the devices being configured to perform data encryption/decryption methods as described herein; Figure 2 is a flowchart showing steps typically involved in an embodiment of the encryption method; Figure 3 schematically illustrates how a setof encryption keys and a numbersequence can be used to generate a key byte sequence usable for encrypting (or decrypting) data; Figure 4 is a flowchart showing how a byte of the data packet is encrypted using bytes from the sequence; Figure 5 schematically illustrates an example format of a packet containing encrypted data that can be transferred between the computing devices; Figure 6 is a diagram illustrating an example of an initial communication sequence between the computing devices; Figure 7 is a diagram illustrating an example of a standard communication sequence between the computing devices, and Figure 8 is a flowchart showing steps typically involved in an embodiment of the decryption method.

Description of Example Embodiments

Example embodiments of the present invention will be described in detail with reference to the accompanying drawings. Referring first to Figure 1 there is shown an example system 100 can encrypt data, transfer encrypted data and decrypt encrypted data. The system includes a first computing device 101 that is communication over a network 103 with a second computing device 110.

The computing devices 101, 110 can comprise any standard types of computers, with each including a respective processor 104, 114, memory 106, 116 and communication interface 108, 118. The skilled person will appreciate that the devices can include, or be connected to, other standard components, such as display units, keyboards, external storage, etc, that need not be described in detail herein. The network may comprise any communications network(s), typically including the internet, and the communication interfaces can connect to it using any suitable wired and/or wireless means. It will be understood that the illustrated system is a simple example only and additional/alternative components could be present in other embodiments. For instance, the second computing device may comprise a sewer and the first computing device and one or more further computing devices may interact with the server in order to encrypt/decrypt data and exchange such data with each other. It should also be understood that the functions/data described herein in relation to one of the computing devices could be performed by/stored across multiple or disturbed devices.

In a typical use case, a user of the first computing device 101 has data that he wishes to securely exchange with the second computing device 110. The processors 104, 114 of the first and second computing devices can access code (typically at least temporarily stored in their respective memories 106, 116) that causes them to interact with each other in order to perform encryption/decryption processes according to the methods described herein on the data and transfer the processed data over the network 103. The second computing device may process decrypted data in various ways, e.g. display it to a user of that device or store/transfer it for further processing.

The memory 106 of the first computing device 101 can also store a set of encryption keys (unique to that first computing device) and related data, e.g. a timestamp reference and a number sequence, that are used by the encryption process as described below. The memory 116 of the second computing device 110 may store its own copy of the keys of the first computing device and in some embodiments may also store copies of (unique) sets of keys and related data, e.g. timestamp references and number sequences, associated with other computing devices with which it can perform data encryption/decryption processes. For example, the second computing device 110 can act as a server that provides data encryption/decryption services so that a plurality of other computing devices/sewers can securely exchange data.

Figure 2 is a flow chart showing steps performed to encrypt a payload. It will be understood that the flowcharts and communications sequences illustrated herein are exemplary only and in alternative embodiments some steps/events may be omitted and/or re-ordered. Further, additional steps/events may be performed. The processes can be implemented using any suitable data structures and programming languages.

At step 202 the encryption process starts, typically as a result of a user of the first computing device 101 selecting an appropriate "transfer encrypted data" option in an application.

At step 204 a time offset marker value is generated. This time-related value can be used to effectively strengthen the encryption process as it introduces a "random-like element into the process, as will be described below. This can ensure that a third party cannot predict the reference timestamp and related data as it is dynamically generated and is different for each device and en/decryption session. The dates and times used in the processes described herein can be based on UTC and so should not suffer from timezone-related issues. In some embodiments, the time offset marker value is computed based on a period of time (e.g. number of milliseconds) that has elapsed between when the encryption method was started (e.g. step 202) and a reference timestamp stored in a storage location in communication with/accessible by the computing device 101, e.g. memory 106. The reference timestamp is normally provided during initial or previous communication between the client and server, as described below. The time offset marker value is divided by 1024 (which corresponds to the size of a number sequence in the embodiment, see step 206 below), with the remainder being used as the starting point for reading the number sequence. In such embodiments, the formula used may be as follows: TimeOffset = (EncryptionTimeMs -ReferenceTimeMs) MOD Seqlen wherein EncryptionTimeMS = the time when the method started to encrypt the data to be encrypted in milliseconds; ReferenceTimeMs = the reference timestamp in milliseconds, and Seqlen corresponds to an amount of numbers in a number sequence (see step 206 below).

At step 206 data representing the number sequence (provided during initial or previous communication between the client and server, as described below) is retrieved.. This number sequence is used to effectively strengthen the encryption process as will be described below.

In some embodiments, the number sequence is 1024 bytes long.

At step 206 an encryption key byte sequence is generated. This sequence determines an order in which bytes of each of the set of encryption keys are used to perform encryption operations to encrypt bytes of the payload. In alternative embodiments, portions/segments other than bytes of the encryption keys can be used in the manner described herein. Further, different lengths/bit patterns may be used for different ones of the encryption keys, with the processing steps being modified accordingly.

Figure 3 schematically illustrates how the number sequence 302, along with the time offset value 303, can be used to generate the encryption key byte sequence. In the example embodiment, each byte of the payload (and the computed hash value (see step 210 below)) is encrypted four times, once using a particular byte of each encryption key in the set of four keys.

In some embodiments, the method uses a set of four 2048 bit (256 byte) encryption keys 304A -304D (which may be generated using a pseudo-random number generator or the like), the 1024 byte number sequence 302 and the time offset marker value to encrypt the payload and a computed hash value. However, it will be understood that this can be varied, e.g. a number other than four keys could be used. Using a random byte sequence to determine which byte of the key is to be used can ensure that the keys are never used in numerical order and can prevent linear prediction of the keys. In the example embodiment using different random read sequences for each key ensures that the same pattern of keys used does not repeat itself for 1,048,576 bytes so for 16,384 bits (2KB) of encryption keys and number sequence, the resultant effective bit key size is 8,388,608 bits (1MB) in size.

As mentioned above, numbers from the number sequence are selected to determine the order in which bytes of the encryption keys will be used to perform encryption operations. In some embodiments the value read from the random number sequence is selected using the formula below: RandomNumberLocation = ((Timeoffset + CurrentFayloadLocation) * (StepSize + (CurrentPayloadLocation / 1024fl) % 1024 Thus, a key sequence is created for each encryption key that contains a number of bytes equal to the number of bytes to be encrypted in the payload, plus 32 further bytes for the hash value. Each key has its own step size for reading the random number sequence (i.e. a step size of X would read every Xth byte of the random number sequence). In some embodiments, the step size is hardcoded for each key at the sender and receiver devices, although it will be appreciated that step sizes may be accessed by the encryption/decryption processes in different ways (e.g. values being securely transferred via the network). The step sizes will be the same at both the client and server devices otherwise the en/decryption will fail. If the process reaches the end of the random number sequence, it will loop round and re-start at the beginning.

Optionally, in order to detect any tampering of the data in transit, embodiments can create, at step 210, a value based on a cryptographic hash function performed on the payload at the sender computing device 101. In some embodiments a SHA256 hash function is used, although it will be understood that other functions could be used instead of, or in addition to, this. This hash value can then be encrypted, using the method described below, and included in a packet along with the encrypted payload for transfer over the network.

At step 212 the key byte sequence generated at step 208 can be used encrypt to the payload (and the hash value) on a byte-by-byte basis. Figure 4 schematically illustrates this process for a byte of payload.

At step 402 the first/next byte of the payload to be encrypted is selected and at step 404 a function is performed using the selected payload byte and the selected byte of the first key 304A as its inputs. In the example embodiment the function is an XOR function (i.e. byte of payload XOR selected byte of the first key), although it will be understood that other (simple or complex) functions could be used.

At step 406 the result of the function performed at step 404 is used, along with the selected byte of the second key 304B (i.e. byte resulting from function performed at step 404 XOR selected byte of the second key), as inputs for a function. The function may be another XOR operation, although it will be understood that this may vary.

At step 408 the result of the function performed at step 406 is used, along with the selected byte of the third key 304C, as inputs for a function. The function may be another XOR operation, although it will be understood that this may vary.

At step 410 the result of the function performed at step 408 is used, along with the selected byte of the fourth key 304D, as inputs for a function. The function may be another XOR operation, although it will be understood that this may vary.

The result of the function performed at step 410 is an encrypted byte, which is added to the payload.

These steps can be repeated for all bytes of the payload, as well as bytes of the hash value calculated at step 210.

At step 412 a packet containing the encrypted data and associated information is created.

An example execution of the encryption process is given below.

For the first byte P1 of the payload (selected at step 402) the encryption process is as follows: -select a number from the number sequence based on the "RandomNumberLocation" formula = number Xl; -select byte of first key that corresponds to the selected number Xl (e.g. if Xl = 2 then second byte of the first key is selected) = byte KlOl -add the selected byte KlOl of the first key to the key sequence for the first key (first key sequence now contains KIOl) -select number in random number sequence based on formula = number X2 -select byte of second key that corresponds to number X2 (e.g. if X2 = 5 then fifth byte of the key is selected) = byte K201 -add the selected byte K201 of the second key to the key sequence for the second key (second key sequence now contains K201) -select number in random number sequence based on formula = numberX3 -select byte of third key that corresponds to number X3 = byte K301 -add the selected byte K301 of the third key to the key sequence for the third key (third key sequence now contains K301) -select number in random number sequence based on formula = numberX4 -select byte of fourth key that corresponds to number X4 = byte K401 -add the selected byte K401 of the fourth key to the key sequence for the fourth key (fourth key sequence now contains K401) -Perform encryption operation (steps 404, 406, 408, 410) on ft byte (P1) of payload as follows: P1 xorKlOl xorK2Ol xorK3Ol xorK4Ol = encrypted byte El -Add the encrypted byte El to payload of packet (step 412) For the second byte P2 of the payload (selected at step 402): -select a number from the number sequence based on the formula = number Yl; -select the byte of the first key that corresponds to number Yl = byte Kl 02; -add the selected byte K102 of the first key to the key sequence for the first key (first key sequence now contains Kl 01, Kl 02); -select number in random number sequence based on formula = number Y2 -select byte of second key that corresponds to number Y2 = byte K202 -add the selected byte K202 of the second key to the key sequence for the second key (second key sequence now contains K201, K202) -select number in random number sequence based on formula = number Y3 -select byte of third key that corresponds to number Y3 = byte K302 -add the selected byte K302 of the third key to the key sequence for the third key (third key sequence now contains K301, K302) -select number in random number sequence based on formula = number Y4 -select byte of fourth key that corresponds to number Y4 = byte K402 -add the selected byte K402 of the fourth key to the key sequence for the fourth key (fourth key sequence now contains K401, 402) -Perform encryption operation (steps 404, 406, 408, 410) on 2nd byte (P2) of the payload as follows: P2 xor K1 02 1 xor K202 xor K203 xor K204 = encrypted byte E2 -Add the encrypted byte E2 to payload of packet (step 412) The above steps are repeated to the last byte (n) of the payload so that for each key there is a byte sequence, i.e. for first key the sequence is K101, K102... KiOn; for second key the sequence = K201, 202,... K20n; for third key the sequence = K301, 302, ... K30n; for fourth key the sequence = K401,402 K40n.

The above steps are also performed for each byte of the 32 byte hash value (created at step 210 of Figure 2), with the 32 encrypted hash value bytes also being added to the packet.

During decryption (see Figure 8 and the description below) of the data, the same key byte sequence is generated and is used to identify which byte of each of the keys (which are also stored locally at the device performing the decryption) should be used to decrypt each byte of the received encrypted data.

For example, for the first byte (El) of the encrypted payload, the decrypting device uses key sequence generation processes corresponding to those performed during encryption so that byte KiOl of the sequence for the first key is used, as well as byte K201 of the second key, byte K301 of the third key, and byte K401 of the fourth key. Thus, the decryption operation performed on the first byte (El) of the encrypted payload should be as follows: El xor K102 1 xor K202 xor K203 xor K204 = decrypted byte El'.

If the payload has been transferred and decrypted correctly then the decrypted byte El will correspond to the original payload byte Fl. Also, during decryption a second SHA1 32 Byte hash check is created based on the decrypted payload and this is used to verify that the payload is the same as the encoded copy. This check ensures that the encrypted content has not been tampered with or corrupted during transit.

Figure 5 schematically illustrates an example format of the packet 500 (e.g. created at step 412) which can be transferred between the client computing device 101 and the server computing device 110. It will be understood that the format of the packet is exemplary only and data encrypted according to embodiments of the methods described herein can be transferred using various protocols and mechanisms.

The example packet 500 includes a payload 506 comprising the encrypted data. The payload can be of any length and so can be used to encode any type of data. In the example embodiment the packet 500 also includes an 8 byte Reference Time Marker 502 (which is not encrypted in the packet) that can be used during decryption to generate the key byte sequences. This marker can correspond to the calculated TimeOffset value.

In altemative embodiments, the example packet 500 can further include an 8 byte client/device identifier. This value (typically not encrypted in the packet) can be used to retrieve the correct set of encryption keys associated with the device that is providing the encrypted data, although it is preferred that the device identifier is transferred separately to the sewer as described below.

The example packet 500 further includes the encrypted hash value (32 bytes) 508.

At step 216 the creation of the packet containing encrypted data is complete and the packet is ready to be transferred from the client device 101 to the server device 110 using a suitable sequence of communications.

Figures 6 and 7 schematically illustrate communication sequences involving the client computing device 101 and the server computing device 110.

The initial communications shown in Figure 6 only normally take place when the client 101 and the server 110 do not know about each other, e.g. the very first time the client connects to the server; if the client is unknown to the server, or if the encryption keys are out of sync between the client and server.

At event 602, a TCP tunnel is established between the client 101 and the server 110, e.g. in response to a request from an application running on the client to transfer encrypted data. At event 604 an SSL is established over the tunnel. It will be understood that in alternative embodiments, other secured or unsecured communications channels could be used. At event 605 the client sends data identifying itself to the server.

At event 606 the server 110 generates an activation key, which comprises a reference timestamp value, a 2048 byte number sequence and a set of (4 x 256 byte) encryption keys.

These can be produced by a pseudo-random generator or the like. The activation key is used to allow the server to generate, encrypt and send a new set of encryption keys to the client 101. The activation key allows the client to successfully decrypt and start using the new set of encryption keys for all future communications. The activation key is therefore only ever used to receive a new set of encryption keys, thereby keeping the amount of data that can be decrypted using the activation key to a minimum.

There are other ways that encryption keys could be made known to both the client 101 and the server 110. Examples include Hard Coded Keys (not recommended because the client app could be disassembled to extract the key), or Logically Generated Keys (not recommended as the client app could be disassembled and the key generation routine be reversed engineered).

Thus, preferred embodiments use the activation key generated by the server and sent over SSL to the client.

At event 608 the activation key generated at 606 is transferred from the server 110 to the client 101 using the SSL link. In the event that the SSL packet containing the activation key is intercepted and cracked, the activation key would have already been used by the client and both the client and server will have deleted it (as described below). Therefore, the usefulness the activation key is very limited to a party attempting to break encrypted communication between the client and server.

At event 610, the server 110 generates a new reference timestamp value, a new number sequence and new a set of encryption keys (e.g. four 2048 bit keys generated using a pseudo-random number generator) and uses the activation key generated at step 606 to encrypt these values using the encryption method described herein (although it will be appreciated that in alternative embodiments, other encryption/decryption techniques could be used for encrypting/decrypting these values, and another type of activation key could be used). The encrypted new reference timestamp, number sequence and keys are then, at event 612, transferred to the client 101 using the SSL link.

At event 614 the client 101 decodes the encrypted new reference timestamp, number sequence and keys it received at event 612 using the activation key it received at event 608.

At events 616, the client 101 and the server 110 use the encryption keys (decoded at step 614) to encrypt data and exchange encrypted data. When such data exchange has been completed (event 618), the server generates new reference timestamp, number sequence and set of encryption keys and encrypts them using the current keys at event 620. At event 622 the encrypted new reference timestamp, number sequence and keys are transferred to the client.

At event 624 the client 101 decrypts the new reference timestamp, number sequence and set of encryption keys transmitted to it at event 622. At event 626 the client stores the new reference timestamp, number sequence and keys. The data may be stored (in a plain or encrypted format) in a particular location of its memory 106 or some other data storage device.

The client also sends an acknowledgement that it has received the new reference timestamp, number sequence and keys to the server 110 at event 628. Upon receiving that acknowledgment the server stores the new reference timestamp, number sequence and encryption keys (event 630). The data may be stored (in a plain or encrypted format) in a particular location of the server memory 116 or in some other data storage device.

This can ensure that the encryption keys are only ever used for a single communication session and can therefore be considered as "disposable". Should an intercept manage to crack an encryption key, it will only be able to decrypt communications in the current session.

Event 632 denotes the end of the initial communications between the client 101 and the server 110.

Figure 7 illustrates standard communications that can take place between the client 101 and the server 110 when they know about each other and have each stored a set of encryption keys following successful initial communications.

At event 702 a TCF tunnel is established between the client 101 and the server 110, e.g. in response to a request from an application running on the client to transfer encrypted data. At event 704 an SSL is established over the tunnel. It will be understood that in alternative embodiments, other secured or unsecured communications channels could be used. At event 705 the client sends data identifying itself to the server.

At event 706 the client 101 retrieves its set of encryption keys and at event 708 uses the keys to encrypt the payload data and generate a packet containing encrypted data. At event 710 the client sends the encrypted packet to the server 110. At event 712 the server retrieves the appropriate reference timestamp, number sequence and set of encryption keys for the client 101, e.g. using the identifier provided at step 705 to find the associated reference timestamp, number sequence and set of keys in its data store.

At events 714, the client 101 and the server 110 use the retrieved reference timestamp, number sequence and encryption keys to encrypt data and exchange encrypted data. When such data exchange has been completed (event 716), the server generates a new reference timestamp, number sequence and set of encryption keys and uses the current set of keys to encrypt these at event 718. At step 720 it transfers the encrypted new reference timestamp, number sequence and keys to the client.

At event 722 the client 101 decrypts the new reference timestamp, number sequence and set of encryption keys transmitted to it at event 720. At event 724 the client deletes the current reference timestamp, number sequence and keys and stores the new reference timestamp, number sequence and keys instead of them. The reference timestamp, number sequence and key set data can be stored (in a plain or encrypted format) in a particular location of its memory 106 or some other data storage device. The client also sends an acknowledgement that it has received the new timestamp, number sequence and keys to the server 110 at event 726.

Upon receiving that acknowledgment the server stores the new timestamp, number sequence and encryption keys (event 728). Again, the data may be stored (in a plain or encrypted format) in a particular location of the sewer memory 116 or in some other data storage device.

This ensures that the encryption keys are only ever used for a single communication session and are therefore considered "disposable". Should an intercept actually crack an encryption key, it will only be able to decrypt communications in the current session.

Event 730 denotes the end of the standard communication session between the client 101 and the server 110.

Figure 8 is a flow chart example steps that are performed in order to decrypt a packet containing an encrypted payload, e.g. when an application running on the sewer device 110 receives, at step 802, an encrypted packet from the client device 101 during a standard communications session.

At step 804, the server 110 reads the time marker 502 from the packet. At step 806 the random number sequence is calculated (using a reverse process corresponding to step 206 of the encryption process described above).

At step 808, the key byte sequence is generated (using a reverse process corresponding to step 208 of the encryption process described above). This sequence determines an order in which bytes of each of the set of keys are used to perform operations to decrypt bytes of the payload.

At step 810, the payload 506 of the packet is decrypted (using a reverse process corresponding to step 212 of the encryption process described above), as well as the hash value 508.

At step 812, a hash value is created for the decrypted payload data using a process corresponding to step 210 of the encryption process described above.

At step 814 a check is performed as to whether the value of the hash calculated at step 812 is equal to the hash value contained in the packet (i.e. whether the hash values indicate that the payload has not been tampered with). If the result of this check is negative then at step 816 it is determined that the payload decryption process has failed and appropriate action may be taken, e.g. notify the user(s), attempt re-transmission, etc. However, if the result of the check is positive then at step 818 it is determined that the decryption of the payload has been successful and appropriate action may be taken, e.g. notify the user(s), save/view the decrypted data on the server 110, etc. Step 820 denotes the end of the decryption process.

It will be appreciated that embodiments of the encryption/decryption processes described herein can be used in many situations and applications.

One example comprises an application for providing news-related data to a mobile device, such as a WindowsTM phone. A server that collects news data can encrypt the data before transferring it to the mobile device.

To access the news application backend over SSL a user name and password need to be presented. Conventionally, the username and password would need to be hard coded into the app on the mobile device (this is the reason why conventional news apps are read only and send all communication over http). If SSL is required, or a user wants the content to be transmitted securely then the conventional solution would be to hardcode a username and password into the app. However, anyone with developer access could open the app locally and read the usemame and password in clear text.

Using an embodiment of the encryption method described herein with the app, on load a connection is made to a server providing the encryption service in order to receive the username and password to be used for the data exchange session with the news application server. Once the app closes the credentials are destroyed. This ensures that the usemame and password are never stored in the app and also ensures that the app and its data can securely connect to an SSL backend website using a non-hardcoded username and password.

Also, the credentials used by the news app to access the secure web are managed centrally, allowing each client to use a unique usemame and password, which can be changed as required without any communications needing to take place between the client and the news service.

In essence, embodiments make it possible to create applications with full SSL and proprietary security with auditing capability via specific username and password per person that the end user never needs to know. In other words, all the benefits of having highly secure username and password protection over SSL without any of the pitfalls or security holes that stem from allowing end users to know their own usernames/passwords.

At present most other news applications transmit data in clear text and not over SSL. Having a news service that uses encryption methods as described herein can allow seamless, anonymous authentication to a SSL backend site so that all transmissions are encrypted.

Thus, it can be possible to encrypt all anonymous internet traffic between two points whilst ensure data security without end users ever needing to know a usemame or password Other example applications include a suite of apps that are used to track a device's location in real time, allowing other devices or users (via a website) to monitor the whereabouts of the device at any given time. Currently, device location tracking apps do not securely send the device's location data using secure data exchange and are vulnerable to "Man in the Middle" attacks to gain unauthorised access to a devices location data. However, using embodiments of the encryption solution described herein can ensure that all device location and other information is securely transferred between the device and location service server. This can remove the vulnerability from "Man in the Middle" attack being able to sniff and obtain the device's location data.

These measures and the fact the disposable keys are dropped and forgotten after each data exchange ensures that any intercept of data between the client and server will have advantages, including: very low risk of being cracked and the data read; any reverse engineering of the data will take a long time even on high specification servers; if the keys are reverse engineered, they will only be valid for the intercepted data and cannot be used for any future data transfer -essentially they will only have one line of data, for them to do anything harmful they you would need the entire paragraph, and any tampering with the encrypted packet in transit will be detected by the hash check.

The present invention will be understood readily by reference to the above description of example embodiments and the accompanying drawings. The present invention may, however, be embodied in many different forms and should not be construed as being limited to the example embodiments described above. Rather, these embodiments are provided so that this disclosure will be thorough and complete and will fully convey the concept of the invention to those skilled in the art. The present invention is defined by the statements of aspects of the invention in the summary of invention section above, and with reference to any appended claims.

Although a few preferred embodiments have been shown and described, it will be appreciated by those skilled in the art that various changes and modifications might be made without departing from the scope of the invention, as defined in the appended claims.

Attention is directed to all papers and documents which are filed concurrently with or previous to this specification in connection with this application and which are open to public inspection with this specification, and the contents of all such papers and documents are incorporated herein by reference.

All of the features disclosed in this specification, including any accompanying claims, abstract and drawings, and/or all of the steps of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and/or steps are mutually exclusive.

Each feature disclosed in this specification, including any accompanying claims, abstract and drawings, may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise. Thus, unless expressly stated otherwise, each feature disclosed is one example only of a generic series of equivalent or similar features.

The invention is not restricted to the details of the foregoing embodiment(s). The invention extends to any novel one, or any novel combination, of the features disclosed in this specification, including any accompanying claims, abstract and drawings, orto any novel one, or any novel combination, of the steps of any method or process so disclosed.

Claims

Claims: 1. A method of encrypting data comprising: receiving data to be encrypted, the data comprising a sequence of data portions; obtaining a set of keys, each said key comprising a plurality of key portions; determining a sequence of the key portions of the keys in the set, the sequence representing an order in which the key portions are to be used for performing encryption operations, and generating encrypted data by using the key portions, according to the sequence of key portions, in combination with corresponding said data portions of the data to be encrypted in a said encryption operation.
2. A method according to claim 1, including for each said data portion of the data to be encrypted: a) obtaining the key portion of a first said key in the set based on the sequence of key portions; b) performing a said encryption operation based on the obtained key portion of the first said key and the data portion of the data be encrypted to generate an encrypted data portion; c) obtaining the key portion of a next said key in the set based on the sequence of key portions; d) performing a said encryption operation based on the obtained key portion of the next said key and the encrypted data portion to regenerate the encrypted data portion; e) repeating steps c) and d) for each remaining said key in the set, and f) including the encrypted data portion generated by a last of the performing a said encryption operation steps in the generated encrypted data.
3. A method according to claim 2, wherein a said encryption operation comprises an XOR operation.
4. A method according to any of the preceding claims, wherein the determining of the sequence of key portions comprises, for each said key in the set: obtaining data representing a number sequence; selecting a number from the number sequence; using the selected number to select a said key portion of the key, and adding the selected key portion to the sequence of key portions.
5. A method according to claim 4, wherein the selecting of the number from the number sequence is based on: a step size associated with each said key; a time-related value, and a location of the portion of the data to be encrypted being currently processed within the data to be encrypted.
6. A method according to claim 5, wherein the time-related value is computed based on a time period of time elapsed between when the method started to encrypt the data to be encrypted and a reference time.
7. A method according to claim 6, wherein the computation of the time-related value (TimeOffset) is based on a formula: TimeOffset = (EncryptionTimeMs -ReferenceTimeMs) MOD Seqlen wherein EncryptionTimeMS = time when the method started to encrypt the data to be encrypted in milliseconds; ReferenceTimeMs = the reference time in milliseconds, and Seqlen corresponds to an amount of numbers in the number sequence.
8. A method according to claim 7, wherein data relating to the reference time is transferred to a receiver of the generated encrypted data, e.g. by inclusion in a packet containing the generated encrypted data.
9. A method according to claim 8, wherein the selecting of the number from the number sequence is based on a formula: Number to be selected = ((TimeOffset + CurrentPayloadLocation) * (Stepsize + (CurrentPayloadLocation / 1024))) % 1024 wherein CurrentPayloadLocation = currently-processed said portion of the data to be encrypted, StepSize = number of portions skipped between each read of the number sequence.
10. A method according to any of the preceding claims, further including: generating a hash value based on the data to be encrypted; encrypting the hash value, and transferring data representing the encrypted hash value to a receiver of the generated encrypted data (e.g. by inclusion in a packet containing the generated encrypted data).
11. A method according to claim 10, wherein a number of the numbers in the number sequence for each said key corresponds to a number of the data portions of the data to be encrypted, plus a number of portions representing the encrypted hash value.
12. A method according to any of claims U to 11, further comprising: storing data representing the reference time, the number sequence and/or the set of keys in a storage location accessible by a device performing the encryption method; storing data representing the reference time, the number sequence and/or the set of keys in a storage location accessible by a device configured to decrypt the generated encrypted data;
13. A method according to claim 12, wherein following the step of generating the encrypted data, the method further comprises: deleting the stored data representing the reference time, the number sequence and/or the set of keys in the storage location accessible by the device that is performing the encrypted method; deleting the stored data representing the reference time, the number sequence and/or the set of keys in the storage location accessible by the device configured to decrypt the generated encrypted data; generating a new said reference time, said number sequence and/or said set of keys to replace the set of keys; storing data representing the new said reference time, said number sequence and/or said set of keys in the storage location accessible by the device performing the encryption method, and storing data representing the new said reference time, said number sequence and/or said set of keys in the storage location accessible by the device configured to decrypt the generated encrypted data.
14. A method according to any preceding claim, further comprising: obtaining or generating an initial encryption key; transferring data representing the initial encryption key to a device configured to receive the generated encrypted data; encrypting the set of keys using the initial encryption key; transferring the encrypted set of keys to the device.
15. A method according to any preceding claim, wherein the data to be encrypted includes security-related data, e.g. username, password, or location information.
16. A method according to any preceding claim, wherein the set of keys is obtained (e.g. retrieved from a secure storage location) based on an identity of a device that is creating/sending the encrypted data.
17. A method according to any preceding claim, wherein a said key portion of a said key comprises a byte, and a said data portion of the data to be encrypted comprises a byte.
18. A method according to any preceding claim, wherein the set of keys comprises four said keys.
19. A method according to any preceding claim, including transferring the generated encrypted data to a receiver via a secure/encrypted communications channel.
20. Apparatus (101) configured to encrypt data comprising: a device (104, 104) configured to receive data to be encrypted, the data comprising a sequence of data portions; a device (104, 106) configured to obtain a set of keys, each said key comprising a plurality of key portions; a device (104) configured to determine a sequence of the key portions of the keys in the set, the sequence representing an order in which the key portions of the keys are to be used for performing encryption operations, and a device (104) configured to generate encrypted data by using the key portions, according to the sequence of key portions, in combination with corresponding said data portions of the data to be encrypted in a said encryption operation.
21. A method of decrypting data comprising: receiving encrypted data, the encrypted data comprising a sequence of data portions; obtaining a set of keys, each said key comprising a plurality of key portions; determining a sequence of key portions of each said key in the set, the sequence representing an order in which the key portions of the keys are to be used for decryption operations, and generating decrypted data by using the key portions, according to the sequence of key portions, in combination with corresponding said data portions of the encrypted data in a said decryption operation.
22. A method according to claim 21, further comprising: obtaining a first hash value included in the decrypted data; generating a second hash value based on the decrypted data, and comparing the first hash value and the second hash value to determine if the decrypted data accurately corresponds to original data portions that were to be encrypted.
23. Apparatus (110) configured to decrypt data comprising: a device (114, 118) configured to receive encrypted data, the encrypted data including a sequence of data portions; a device (114, 116) configured to obtain a set of keys, each said key comprising a plurality of key portions; a device (114) configured to determine a sequence of key portions of each said key in the set, the sequence representing an order in which the portions of the keys are to be used for decryption operations, and a device (114) configured to generate decrypted data by using the key portions, according to the sequence of key portions, in combination with corresponding said data portions of the encrypted data in a said decryption operation.
24. A computer readable medium storing a computer program to operate a method according to any of claims ito 19, or any of claims 21 to 22.
25. A device configured to encrypt data substantially as described herein and/or with reference to the accompanying drawings.
26. A device configured to decrypt data substantially as described herein and/or with reference to the accompanying drawings.
27. A method of encrypting data substantially as described herein and/or with reference to the accompanying drawings.
28. A method of decrypting data substantially as described herein and/or with reference to the accompanying drawings.