GB2488753A - Encrypted communication - Google Patents

Abstract

A cryptography system is presented with several aspects. In the first aspect (Figure 2) the system is characterised by creating a secure communication channel between a device and a server wherein encryption modules, with associated identifiers, are obtained from a second server and used at both the device and the server in establishing the secure communication channel. This arrangement provides protection from devices affected by viruses or malware and provides a heterogeneous communication interface/component at either end of the created secure communication channel. The encryption component may be updated at regular intervals and pushed from the second server. The second aspect relates to generating a common encryption key involving bitwise processing and a mask size threshold (see Figure 3). The third aspect is characterised by transmitting encrypted data between a first and second device using encryption and decryption with a common key which is generated by the first device with a server and obtained from the server by the second device (see Figure 4). The fourth aspect is characterised by authenticating a device comprising transmitting information to a server, the server categorising the information based on predictability; the server storing the categorised information into a knowledge base; the server later comparing further information received from the device with the stored categorised information; and authenticating the device by the server if the further information matches the stored categorised information to a defined threshold (see Figure 5). This aspect provides a system for authenticating devices using matching of evolving information of the device.

Description

A CRYPTOGRAPHY SYSTEM

Field of Invention

The present invention is in the field of cryptography. In particular, but not exclusively, the present invention relates to the authentication of devices and the encryption of data for transmission between devices.

Background

Communication between devices is a necessary aspect of the modern world.

Information is communicated between devices through a communications infrastructure, such as, the Internet, a mobile telecommunications network, or an amalgam of such networks.

The networks or devices may not be secure in that a third party to the communication may be able to intercept the communication.

Interception of communications is not desirable for certain information, such as personal information, financial information, or military information.

In order to prevent interception of communications, the information may be transmitted over a secure communications channel between the transmitting and recipient device.

Secure communications channels can be initiated using numerous protocols, such as HTTPS, and may use numerous encryption methodologies, such as Public Key Infrastructure (PKI) or using a shared encryption key.

However, existing protocols suffer from a common defect: the secure communications channel is vulnerable when the transmitting or recipient device is compromised. With most devices now connected to the Internet, there are numerous methods to compromise a connected device. These methods include spear phishing and accidental downloading of viruses or malware.

Therefore, there is a need for a cryptography system which provides for a secure/encrypted communications channel and which mitigates the risk of vulnerable devices.

It is an object of the present invention to provide a cryptography system which overcomes the disadvantages of the prior art, or at least provides a useful alternative.

Summary of Invention

According to a first aspect of the invention there is provided a method of creating a secure communication channel between a device and a server, including the steps of: i) a first server transmitting an encryption module selected from a plurality of different encryption modules to a device; ii) the device communicating with a second server and including an identifier for the encryption module; iii) the second server requesting a corresponding encryption module from the first server using the identifier; and iv) the second server and the device using the encryption modules to create a secure communication channel between the second server and the device.

According to a further aspect of the invention there is provided a method of generating a common encryption key, including the steps of: i) a device obtaining a key sequence and generating a first bit sequence; ii) the device combining the key sequence and first bit sequence using a first bitwise processing method to produce a first combined sequence; iii) the device transmitting the first combined sequence to a server; iv) the server generating a second bit sequence; v) the server transmitting the second bit sequence to the first device; vi) the device combining the first and second bit sequences using a third bitwise processing method to produce a third bit sequence; vii) if the mask size of the third bit sequence is less than a predefined threshold, repeating the steps from step (iv) until the mask size of the third bit sequence is at least meets the predefined threshold; viii) the server combining the first combined sequence and second bit sequence using second bitwise processing method to produce a second combined sequence; ix) the device transmitting the third bit sequence to the server; x) the device generating the common encryption key by applying the third bit sequence as a mask to the key sequence; and xi) the server generating the common encryption key by applying the third bit sequence as a mask to the second combined sequence.

According to a further aspect of the invention there is provided a method of transmitting encrypted data between a first and second device, including the steps of: i) a first device generating a common key with a server; ii) a second device obtaining the common key from the server; iii) the first device encrypting data using the common key and transmitting the encrypted data to the second device; and iv) the second device using the common key to decrypt the encrypted data.

According to a further aspect of the invention there is provided a method for authenticating a device, including: i) the device transmitting information to a server; ii) the server categorising the information based on predictability; iii) the server storing the categorised information into a knowledge base; iv) the server comparing further information received from the device with the stored categorised information; and v) the server authenticating the device if the further information matches the stored categorised information to a defined threshold.

Other aspects of the invention are described within the claims.

Brief Description of the Drawings

Embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings in which: Figure 1: shows a block diagram illustrating an overview of the authentication system.

Figure 2: shows a flow diagram illustrating a replaceable encryption modules method in accordance with an embodiment of the invention.

Figure 3: shows a flow diagram illustrating a common key generation method in accordance with an embodiment of the invention.

Figure 4: shows a flow diagram illustrating an encrypted transmission method in accordance with an embodiment of the invention.

Figure 5: shows a flow diagram illustrating a machine authentication method in accordance with an embodiment of the invention.

Figure 6: shows a block diagram illustrating an overview of the Lolla authentication system.

Figure 7: shows a block diagram illustrating a module replacement system in accordance with an embodiment of the invention.

Figures 8 and 9: show block diagrams illustrating the creation of a encrypted communications channel between a device and a server in accordance with an embodiment of the invention.

Figure 10: shows a block diagram illustrating a common key generation process in accordance with an embodiment of the invention.

Figure 11: shows a block diagram illustrating the creation of an encryption key from a common key in accordance with an embodiment of the invention.

Figure 12: shows a block diagram illustrating the creation and management of a secure communications channel between two devices by a server in accordance with an embodiment of the invention.

Figure 13: shows a block diagram illustrating a device authentication system in accordance with an embodiment of the invention.

Figure 14: shows a block diagram illustrating an implementation of an embodiment of the invention.

Detailed Description of Preferred Embodiments

The present invention provides a cryptography system for authenticating devices and for encrypting communications for transmission between devices.

Embodiments of the present invention deploy different components including different coding/decoding algorithms to devices periodically to help mitigate the damage caused by compromised devices.

Embodiments of the present invention use obfuscation of the executable code of the components to make it difficult for viruses or malware to read variables and important data within the component.

Embodiments of the present invention use an authentication system to fingerprint a device, to track the evolving state of the device, and to authenticate the device based on its evolving fingerprint.

Referring to Figure 1 an overview of the cryptography system 100 will be described.

The system 100 includes a first server 101 connected to a second server 102.

The two servers 101 and 102 may exist within the same physical architecture.

The servers 101 and 102 are connected via a communications infrastructure 103, such as the Internet or a mobile telecommunications infrastructure, to a plurality of devices 104.

The devices 104 may be any of mobile devices, mobile telephony devices, computing devices, or other device.

Each device 104 includes a network interface 105, a processor 106, and a memory 107.

Referring to Figure 2, a method according to an embodiment of the cryptography system of Figure 1 will be described.

This method relates to the deployment of different components to devices.

The first server 101 generates an encryption component including an encryption algorithm selected from a predefined list of algorithms. The encryption component is also generated with a randomised/pseudo-randomised key. The encryption component includes a component identifier.

The component may also include a generated asymmetric key pair. The generated encryption component may be obfuscated to inhibit hacking of the component.

In step 200, the first server 101 transmits the generated encryption component to one of the devices 104. Within a predefined time period or when triggered by a predefined event, the first server 101 may generate a replacement encryption component and transmit it to the device 104 in step 201. The device 104 may then replace its current encryption module with the new encryption module in step 202.

The transmission may be over a secure communications channel. For example, it may be over a PKI secured channel.

The device 104 may use the encryption component to communicate with the second server 102 in step 203. The identifier of the encryption component may be communicated by the device 104 to the second server 102. The second server 102 may use the identifier to extract the encryption component from the first server 101 in step 204. The second server 102 may use the extracted encryption component to create a secure communication channel to communicate with the device 104 in step 205. Communications over the secure communication channel can be encrypted using the encryption algorithm of the encryption component.

The device 104 and second server 102 may communicate to generate a common encryption key to use with the encryption component.

When the first device 104 and a second device wish to communicate over an encrypted channel, the second device may obtain the common encryption key from the second server.

The second device may also be provided with an encryption component by the first server 101, and the second device may communicate with the second server 102 using the encryption component to obtain the common encryption key.

The first and second device may then communicate using the common encryption key to encrypt/decrypt transmissions.

A potential advantage of providing generated encryption modules in accordance with the method is to produce a heterogeneous environment across the devices 104. Such an environment may reduce the impact of viruses or malware.

Referring to Figure 3, a method according to an embodiment of the cryptography system of Figure 1 will be described.

This method relates to the generation of a common key between a device 104 and server 102.

To generate a common key at the device 104 and the server 102, the device 104 generates a first bit sequence in step 300. Also in step 300, the device 104 combines the bit sequence with a key that is generated at the device 104 (randomly or via user input), received through another secure channel, or stored within the device 104.

The combined sequence is transmitted to the server 102 in step 301.

In step 302, the server 102 generates a second bit sequence, and transmits this to the device 104.

In step 303, the device 104 combines the second bit sequence with the first sequence and then inverts the result to produce a third bit sequence. In step 304, if the mask size of the third bit sequence is fails to meet a minimum size threshold then a new second bit sequence is requested from the server 102.

The purpose of testing for a minimum threshold is to ensure that the resulting common key generated is sufficiently long to meet encryption requirements.

Accordingly, the minimum size threshold will be set to the minimum key length that will meet those requirements such as 32-bit, 64-bit, 128-bit, or 256-bit encryption strength.

In step 305, the third bit sequence which meets the mask threshold size is transmitted to the server 102.

In step 306, the server 102 combines the initially received combined sequence with the second bit sequence and applies the third sequence as a mask to the result. The result of the mask application is a common key.

Also in step 305, the device 104 generates the common key by applying the third sequence as a mask to the original key.

Preferably the bit sequences are combined using a bitwise processing method such as XOR.

An example will now be given using one possible implementation of the above method, where D is the device 104 and S is the server 102: a) Dhas key 10100111 b) D generates bit sequence A 10001001 c) D combines key and bit sequence A using XOR to produce combined sequence X 00101110 d) D transmits combined sequence X to S e) S generates bit sequence B 00001111 f) S transmits bit sequence B to D g) D combines bit sequences A and B using XOR and then inverts the bits to produce mask 01111001 h) The mask size of 01111001 is five because there are five "1"s -the predefined minimum threshold is four i) D transmits the mask to S j) S combines combined sequence X and bit sequence B using XOR to produce combined sequence Y 00100001 k) S applies the mask to combined sequence Y to produce common key I) D applies the mask to the key to produce common key 01001 Communications between the device 104 and the server 102 may be conducted over a PKI secured channel. Preferably, communications between the device 104 and the server 102 are conducted using an secure communications channel created using the method shown in Figure 2.

A potential advantage of this method is that because both the device 104 and the server 102 are contributing random aspects to the common key generation process it is more difficult for a third party to simulate the random number generator and predict what the key might be.

Referring to Figure 4, a method according to an embodiment of the cryptography system of Figure 1 will be described.

This method relates to the use of a server 102 to manage the secure communication channel created between two devices 104.

In step 400, a first device 104 generates a common key with a server 102.

The key may be generated using the method shown in Figure 3.

In step 401, a second device may obtain the common key from the server 102. The second device may communicate with the server 102 using the method shown in Figure 2.

In step 402, the first and second device may communicate using the common key to encrypt/decrypt transmission data.

The first device 104 may periodically generate a new key with the server 102.

The second device may request the newly generated key from the server 102.

The first device 104 may switch between generated keys when communicating with the second device. Transmissions may include an identifier to enable the second device to select the correct key.

The first device 104 may use their received encryption component as shown in Figure 2 to encrypt data transmissions. The second device may request the encryption component of the first device 104 from the server 102 to enable the second device to decrypt the data transmissions.

A potential advantage of using a central server 102 to coordinate encrypted data transmissions between devices 104 according to this method is encryption keys can be renewed easily to inhibit the usefulness of a hacker stealing data or cloning a device.

Referring to Figure 5, a method according to an embodiment of the cryptography system of Figure 1 will be described.

This method relates to the authentication of devices 104 using a "fingerprint" of the device 104.

An authenticator module on a device 104 retrieves information about the device 104. Information may include evolving information such as the file system stored on the memory 107 of the device 104, GPS position, data on the SIM card and/or IP address, and static information such as IMEI or MAC address. For the file system, the information preferably includes "file/folder names" in conjunction with "file/folder creation/modification dates".

Alternatively, or in addition, other information such as the size of the file, the value of a specific byte or selection of bytes, or a hash function may be used.

In step 500, the information is transmitted to an authentication server which inserts the information into a learning engine for each device 104. The learning engine may be a knowledge base or neural net. The authentication server may reside on the server 102.

In step 501, the information is weighted based on its predictability. During initialization of the authentication system for a device predictability is estimated based upon characteristics of the information. For example, typically static operating system files and hardware IDs may be marked as low risk, operational operating system files that infrequently change (such as Program files folder) may be marked as medium risk, user documents would fall into high risk, and operational files that are continuing evolving (i.e. swap files) are marked as evolving.

The information forms an effective fingerprint for the device 104.

During authentication, the predictability of each information item in the learning engine is updated based on how frequently the information item has changed on the device. Frequency of change can be determined by comparing changes from previous authentication sessions. Therefore, the evolving fingerprint of the device is monitored by the authentication server.

To authenticate a device, the device 104 provides a machine identifier constructed from low risk information, a password formed from randomly selected information items covering low, medium and high risk predictability, an evolutionary key selected from the information items marked as evolving, and a selection of new information items in step 502.

The machine identifier may be constructed by forming a hash value from the low risk information in step 503.

In step 504, the device 104 is authenticated when the password matches the fingerprint of the device 104 within the learning engine to a specific threshold.

If the match is below the specific threshold then the device 104 is required to provide another password formed from another set of randomly selected information items. This process may be repeated for a set number of times. If the match is not only below the specific threshold but is below a further lower threshold or no password matches after the set number of times then the device may be marked as "Not Recognised".

In step 505, if the device 104 is authenticated, then information items whose details did not match exactly are updated within the learning engine. Also in step 505, information items that did not exist at all in learning engine are added to the learning engine.

If the device 104 is authenticated, then its evolution is tracked using information items marked as evolving. Dates extracted from the evolving information items provided by the device 104 are compared to the dates of the evolving information items stored in the learning engine. If the evolving information item is older than the stored evolving information item, the device 104 is marked as a device clone.

If the device 104 is marked as a clone, marker files are identified on the device to distinguish it amongst its clones. The markers are used to match the clone device to their own learning engine instead of their clone's.

Potential advantages of the authentication method above are that devices 104 can be authenticated through anonymiser services, cloned devices can be detected, and no secondary means, such as a user PIN, security dongle, or card and chip, are required to authenticate a device.

The architecture and components of an embodiment of the present invention will now be described with reference to Figures 6 to 13. This embodiment will be referred to as the Lolla system 600.

The Lolla system 600 operates on the data part of a transportation protocol to provide a secure communications channel 601. The transportation protocol is responsible for packet synchronization and other aspects.

The Lolla system 600 comprises the following components: Gahbee Gahbee is a virtual entity. There is no specific executable code for Gahbee, but each implementation of Gahbee includes a set of features as listed below and is called an Avatar of Gahbee. Each Avatar has different executable code and encryption parameters but has some common features.

Each Avatar of Gahbee has a counterpart stored on a Tess Server 602. For the remainder of this description, the Avatar that runs on the Client Side will be called the Gahbee Client and the Avatar on the server side will be called the Gahbee Server. The Gahbee Server is extracted from the Tess server 602 by the Lolla Server 603, and is used by the Lolla Server 603 to communicate with the equivalent Gahbee Client on the client side. The Gahbee Client is located at a device 604 or 605.

Each Gahbee Avatar includes the following features: * A hard coded Gahbee ID, referenced hereafter as Gahbee_ID. Each Gah bee_ID is unique to that Avatar.

* A variable to store a session ID, called Session_ID * A constant labelled KEY_DEFAULT * An implementation of an asymmetric algorithm, such as a Rivest-Shamir-Adleman (RSA) public key algorithm, or an Elliptic Curve Cryptography (ECC) algorithm. It is referenced as AA1 * A hard coded pair of asymmetric keys, referred to as KI and P2 on the Gahbee Client, and for use by AA1. The keys are previously calculated and hard coded in the Gahbee. The corresponding key pair on the Gahbee Server are referred to as P1 and K2 * Variables to store the values Ri and WI. These form asymmetric keys for a common key generation process (described later as the LTG protocol) * An implementation of the LTG protocol * An implementation of an asymmetric algorithm, such as RSA, or ECC, that uses Ri and Wi, and that will be called AA2 * An implementation of a symmetric algorithm, such as a Diffie-Hellman (DH) key agreement algorithm. It is referenced as ASi. The key generated by ASi is KSI. The parameter used to generate KS1 at the server side is KSS1 and the parameter used to generate KS1 at the client side is B * A bitwise symmetric encryption algorithm such as GSM, AES, or 2-Fish or any combination * Preferably, no third party libraries * A Connection Algorithm (described later) * Optionally, an implementation of a Machine Authentication Algorithm (described later) The code comprising the Avatars of Gahbee are preferably at least partially obfuscated. For example, ProGuardlM or KlassMasterlM may be used to obfuscate the code.

Obfuscation of the Avatars preferably follows the rules below: * The variables cannot occupy the same memory space * Variable names are always be different and not be easily interpretable by human beings * Variable names cannot be the same between Avatars * Variable content are split into memory spaces, like sub-variables of the same "variable" * Variables within LTG and Connection algorithms also follow the above rules * KEY_DEFAULT is different amongst Avatars * The keys are inserted into a String that is broken into pieces and spread through-out the code * Parameters P and Q that feed the algorithm to generate the asymmetric keys are different amongst Avatars * Parameters P and C that are part of the symmetric key algorithm are different amongst Avatars * Any parameters used on all other encryption algorithms on a Cahbee component are different amongst Avatars * Communications with the Lolla Server 603 (described below) are obfuscated Teresa: This is a modification of the Cahbee entity without the LTG algorithm. The Teresa entity will obtain the common key directly from the Lolla Server 603.

The Teresa entity can be used on one side of the encrypted communications channels between devices 604 and 605. The Teresa entity may be deployed to video, or other multimedia, servers. In addition, the Teresa entity may be deployed at the carrier end of a mobile telecommunications infrastructure to establish a secure communications channel between the carrier and the mobile devices.

Authenticator: The authenticator is the component that handles the machine authentication.

Briefly, the authenticator extracts previously defined information from the file system of the device 604 or 605. Some of the defined information is fixed, for example, the Windows directory date, some information is dynamic following a defined rule, some information is dynamic within following a rule and other information is generic.

The authenticator is also preferably obfuscated following the same rules as for Gahbee Avatar obfuscation.

Players: For some web applications like video streaming, e-books or payments, it may be desirable for the component or plug-in used in the application which shows the content is obfuscated.

In this case, for every request to the web application, a new Gahbee Avatar and Player component shall be generated. The Avatar and Player may be integrated or coupled. The Avatar may then establish a secure communications channel and feed decrypted data to the Player. Tess;

This is a server 602 which provides a repository 700 of Gabhee Clients and Gahbee Servers. Gahbee Clients are served by requests by Clients 701 under a typical Client-Server connection 702. Tess 602 also includes a database mapping Gahbee Clients to corresponding Gahbee Servers. For example, the database may provide a mapping between GAHBEE_lDs.

To increase the security of the environment, Gahbee Clients are replaced on devices with different Gahbee Clients periodically or driven by an internal/external event. The time period or events can be defined based on the level of security required. There may be more devices then there are Gahbee Avatars, in which some devices will have the same Avatars.

Lolla Server: The Lolla Server 603 is a server (preferably a web server such an HTTP server) that includes the following features: * Interacts with Tess Server 602 to obtain Gahbee Servers corresponding to the Gahbee Clients of devices 604, 605 with which it is communicating * Communicates with devices 604, 605 to generate a common encryption key * Communicates with devices 604, 605 to help create and maintain a secure communication channel 601 between them * Communicates with devices 604, 605 to authenticate them using the Authentication Process (described later) * Logs transactions for future reference * Is obfuscated under the same rules applied to Gahbee Avatars * Functions called by Gahbee Clients are obfuscated and, therefore, each Gahbee Server includes a mapping function, mapping Gahbee Client obfuscated calls to actual functions on the Lolla Server 603.

A method of an embodiment of the invention will now be described.

1. Download Gahbee from the Tess Server by Player or Application on a Client Device A Gahbee Client is generated or selected at the Tess Server 602 and downloaded by an application at a client device 604 or 605. The Gahbee Client may be replaced periodically with a different Gahbee Client.

Alternatively, the Tess Server 602 can replace the Gahbee Client via pushing the module to the device, or the device may pull the module.

Alternatively, or in addition, another service (such as a web service, or video service) may determine that the Gahbee Client should be replaced and drive replacement of the module.

2. Initialization of the Gahbee Client at the Client Device RI, Wi and KSSI variables are generated by the Gah bee Client at the Client Device 604 or 605.

3. Establish Communication Channel between the Client Device and the Lolla Server Referring to Figures 8 and 9, a communication channel is established between the Client Device 800 and the Lolla Server 801 to enable the Lolla Server 801 to communicate with the Client Device 800 securely to generate a common encryption key.

a) At the Client Device 800, a message is created formed of a time stamp + KSSI + WI + a control string (a control string is a value known to both device and server to verify the integrity of the message). The message is encrypted using Ki and then with P2 using AAI.

b) Gah bee_ID is added to the encrypted message 802.

c) Erase WI from the Client Device's memory.

d) The Client Device 800 transmits the message to the Lolla Server 801 e) The Lolla Server 801 uses the Gahbee_ID to retrieves the corresponding Gah bee Server 803 from the Tess Server.

f) The Lolla Server 801 uses the corresponding AAI in the Gahbee Server 803 to decrypt the data using K2 and P1.

g) The Lolla Server 801 checks the time stamp and the control string to validate the message. For example, if the time stamp is outside a predefined period then the message may be treated as invalid.

h) The Lolla Server 801 calculates KS1 and the parameter B using AS1.

i) The Lolla Server 801 stores Wi.

j) The Lolla Server 801 generates a unique connection session ID, Session_ID.

k) The Lolla Server 801 creates a message formed from time stamp + B + Session_ID + control string. The message is encrypted with K2, then with P1. The encrypted message 900 is transmitted back to the client device 800.

I) The Gahbee Client decrypts the message and verifies it, then calculates KS1 using B sent from the Lolla Server 801.

m) The Client Device 800 stores Session_ID.

4. Generation of the Base Key for the Common Encryption Key in accordance with the LTG protocol Referring to Figure 10, a common key is generated between the Lolla Server and the Client Device to facilitate future secure transmissions between the Client Device and a second device. The common key generation process is called the LTG protocol and uses principles inspired by Quantum Cryptography to create a common key whilst reducing the risk of a security attack on the Lolla Server.

Various sequences are generated at both Client Device and Lolla Server called POLl, POL2, and POL3. For the purposes of this description these sequences will be termed "polarizer sequences". The polarizer sequences are combined with an input sequence using a bitwise process that XORs each corresponding bits of the sequences. Therefore, the polarizer sequence will be understood to mean that a bit of 0 in the polarizer sequence will keep the bit of the input sequence and a bit of 1 in the polarizer sequence will inverse the bit of the input sequence.

a) At the Client Device, Gahbee Client generates a random (or, alternatively, a pseudo-random) sequence of bits Os and is called KEY 1000.

Alternatively, the KEY 1000 may be hard coded within the Gahbee Avatar.

b) Another random sequence of bits is generated called POLl 1001.

c) KEY 1000 is XOR'ed with POLl 1001 and stored in RES1 1002.

d) Gahbee Client encrypts the following message time stamp + RES1 + control string with KSI. Session_ID is added to the encrypted message.

e) This message is transmitted 1003 to the Lolla Server.

f) The Lolla Server retrieves the Gahbee Server corresponding to the Gah bee Client using the Session_ID.

g) The Lolla Server using the logic within the related Gah bee Server decrypts the encrypted message with the key KSI. The timestamp and control string are checked for validity.

h) The Lolla Server generates a randomly sequence of polarizers, POL2 1004.

i) The Lolla Server then XORs RES1 1002 using POL2 1004. The result, RES2 1005 is stored.

j) The Lolla Server forms a message from time stamp + POL2. The message is encrypted with WI, then KS1, and is then transmitted 1006 to the Gahbee Client at the Client Device.

k) The Gahbee Client decrypts the package with the corresponding keys. To decrypt Wi, it uses RI. The timestamp is checked for validity.

I) The Gahbee Client XORs POL2 1004 with POLl 1001, then inverts the bits. This results in sequence POL3 1007.

m) The Gahbee Client counts the I' bits from POL3. If more than 32, proceed. The following message POL3 + time stamp + control string, encrypted with KS1, is transmitted to the Lolla Server.

n) On the Lolla Server, POL3 1007 is compared with RES2 1005. For each bit I' in POL3 1007, the corresponding bit in RES2 1005 is stored in RES4 1008.

o) On the Client Device, the same comparison process occurs using POL3 1007 and KEY 1000, the result is stored in RES5 1009.

p) RES4 = RES5. Therefore, both Client Device and Lolla Server have a common key (KEY_LTG). The common key can be expanded in the next step to produce a larger encryption key which can eventually be used for encrypted transmissions.

q) In case the count on step (m) is less then 32 a message is sent to the server, encrypted with KSI. Then the server must repeat the steps (h) to (m) until either 32 is reached or if steps are repeated more than three times.

r) If the minimal length, 32, is not reached, the KEY_LTG will be set to KEY_DEFAULT common to both Gahbee Client and Gahbee Server.

At the end of the above process, both Lolla Server and the Client Device have a common encrypted key (KEY_LTG). The common key is preferably used as the base for another encryption key or can be used to encrypt transmissions between the Client Device and the Lolla Server. In a preferred embodiment, a second device is provided with the common key by the Lolla Server over a secure channel between the Lolla Server and the second device, and the Client Device can encrypt transmissions for reception by the second device.

5. Key Generation for the Encryption Algorithm using KEY_LTG Referring to Figure 11, and as discussed above, the common key (KEY_LTG) can be used to generate a longer key. The requirement for a longer key might be dictated by the encryption algorithm requiring the key. The generation process might utilise a numeric transformation to expand the key or, alternatively, the process of generating the common key may be repeated several times to construct a final encryption key comprised of several KEY_LTGs.

The encryption algorithm is preferably a bitwise algorithm. The requirements of the system will dictate the speed and encryption strength of the encrypt/decrypt functions of the algorithm -for example, lightweight functions for video streaming, lightweight functions for mobile encryption, and high security functions for military-grade security.

The encryption algorithm is the bitwise symmetric encryption algorithm defined within the Gah bee Avatar.

6. Establishing a Connection between two Devices Referring to Figure 12, a method used to encrypt/decrypt the data stream between two peers 1200, 1201 on two devices based on the encryption algorithm discussed above will be described. The method provides for the ability to ensure that the two devices can coordinate the encryption key and can replace the encryption key at any time.

The method will be used when the two peers 1200, 1201 want to establish a communications channel 1202 over any protocol PL, and both peers desire that the data part of the protocol is encrypted.

The peer 1200 that requests information from another peer 1201, and opens the channel is called the Master 1200. To communicate with the Lolla Server 1203, the Master 1200 establishes a communications channel 1204 in accordance with the method described above. The Master 1200 then generates a common key with the Lolla Server 1203 using the method described above, and generates an encryption key as described above.

These actions occur before the Master 1200 initiates communication with the other peer 1201. The peer 1201 which serves the data is called the Follower 1201.

Master 1200 is a Gahbee Avatar and Follower 1201 is a Teresa Avatar. In an alternative embodiment, the Follower 1201 is also a Gahbee Avatar.

The Master 1200 initiates the communication with the Lolla Server 1203 as described in method 3 and generates KEY_LTG as in method 4. The Lolla Server 1203 associates the KEY_LTG with the Master's ID on the protocol PL chosen. When completed, the Connection method proceeds as follows: 1. The Master 1200 opens channel through the protocol PL chosen with Follower 1201.

2. The Follower 1201 listens to port PT. At the moment of the connection, Follower 1201 obtains the Master ID.

3. The Follower 1201 asks the Lolla Server 1203 about KEY_LTG negotiated with the Master 1200, using the Master ID. The Follower 1201 creates a communications channel 1205 with the Lolla Server 1203 to transmit information using method 3 above.

4. Every Master 1200 is associated with at least one KEY_LTG, and every KEY_LTG is also associated with a Key number (KEY_#).

5. The Lolla Server 1203 will send the KEY_LTG back to the Follower 1201.

6. When the Follower 1201 receives the Key, it confirms receipt to the Lolla Server 1203.

7. The Lolla Server 1203 flags that the Follower 1201 received KEY_LTG and acknowledges confirmation to the Follower 1201.

8. The Follower 1201 requests from Lolla Server 1203 the encryption algorithm used by the Master 1200. LoIla Server 1203 extracts the encryption algorithm used by the Master 1200 using the Gahbee Server associated with the Master 1200. In one embodiment, the Lolla Server 1203 transmits an obfuscated version of the component to the Follower 1201. In an alternative embodiment, the Follower 1201 has some encryption algorithm components already cached. In this case, Lolla Server 1203 responds with a Component_ID which enables the Follower 1201 to construct the appropriate encryption algorithm used by the Master 1200. In yet a further alternative, the Follower 1201 and the Lolla Server 1203 share the same server, so no communications channel between the Follower 1201 and the Lolla Server 1203 is required.

9. The Follower 1201 then responds to the Master 1200 with a CONNECTION OK from protocol PL through port PT.

10.The Master 1200 checks with the Lolla Server 1203 to confirm that the Follower 1201 received the KEY_LTG. If the key is not received, a KEY_LTG default to all Masters and Followers can be used.

11. For each data package of protocol PL, the 1200 Master encrypts using its bitwise symmetric encryption algorithm. The Master 1200 includes a header with the KEY_#. The KEY_# is not encrypted.

12.The Follower 1201 listens to port PT. When a data package comes, the Follower 1201 checks KEY_#, and decrypts it using the associated Key.

13. If the Follower 1201 sends a package the same process works as above.

14.Both the Master 1200 and the Follower 1201 count how many encrypts and decrypts are performed with the same KEY_#. In one embodiment, for each count, a state of encryption parameters is also stored.

15.When a new KEY# is defined, a defined number of times T is randomly generated and stored with the KEY_#. The Follower 1201 can retrieve parameter T from the Lolla Server 1203 and associates it with the KEY_#.

16.When T number of encrypts/decrypts is reached, the Master 1200 generates a new KEY_LTG with the Lolla Server 1203, but retains the old Key with KEY_It.

17.On (T + 1) the Follower 1201 checks with the Lolla Server 1203, retrieves the new key and acknowledges receipt.

18.On (T+2) the Master 1200 confirms with the Lolla Server 1203 that the Follower 1201 received KEY_It.

19. From this time on, the Master 1200 can randomly choose which KEY_It it wants to use.

Machine ID Authentication (Authenticator) Referring to Figure 13, an authentication system will be described.

The Authenticator is an optional component of the Lolla system 600.

An Authenticator Client 1300 gathers data from the machine (the machine may exist on a user device such as a mobile smartphone or a computer) and will be a part of the Gahbee Client.

An Authenticator Server 1301 sits on the Lolla Server 603 and analyses the data provided by the Authenticator Client 1300.

If authentication of a device is required, it may occur after the communications channel is established between the device and the Lolla Server 603.

The Authenticator Server 1301 may use a Neural Network or similar system to analyse the provided data. For example, one possible Neural Network-type system made by Numenta lncTM utilises a Neural Network-type system modelled on the human cortex.

The Authentication process operates in accordance with the following steps: 1. The Authenticator Client 1300 detects the operating system that the machine is executing. The machine may be a virtual or real machine.

2. The Authenticator Client 1300 has access to the file system 1302 of the operating system. The file system includes information about the files and folders stored on in machine. Such information includes the name of the file/folder, the date of modification and creation date of the file/folder. For simplicity, in the remainder of this description, this information (the tuple <filename, date of modification/creation) will be referred to as a file.

3. Files are checked by the Authenticator Server 1301 using a risk analysis model 1303 based on the following risk factors: * Predictability of the file: The last creation (or modification) date of the file is compared with the creation (or modification) date stored in the system for the file being analyzed. For each match, the file is given a value 1, no match, zero. A mean of all values is calculated by using the data gathered on the last n periods of time. The number of n is predefined. The calculation process is given in step 11 below.

* Evolution of a file: When the dates and lengths for the file changes often. In other words when predictability tends to zero. Evolution = I -Predictability.

* Evolution of a Machine: The mean of all file Evolution values, a highly evolving machine has an Evolution close to 1.

All the information gathered about a file is stored in a Knowledge Base 1304. The risk factors determined above are also added to the Knowledge Base 1304.

In one embodiment, the length of the file and/or the value of a specific byte in the file are also added to the Knowledge Base 1304.

4. The Files are grouped in the following sets * Low Risk/Static Group: files with predictability between 0.9 and 1. A static file is when predictability is exactly 1.

* Medium Risk Group: predictability between 0.6 -0.9.

* High Risk Group: predictability between 0.4 -0.6.

* Evolving Group: predictability below 0.4.

5. When the machine is first initialised with the authentication system, all the files in the machine are grouped as follows: It is assumed that each operating system has its own particular set of files to be organized, different from each other. It is possible to set initial predictability factors to each file in the machine following the rules below: * Low Risk Group: Operating System static files -where dates are fixed and unique for each machine. Examples: o C:\Windows o /usr/etc folder o Content of C:\Windows\Fonts Observation: MAC, Hard Drive ID, CPU ID, and any other hardware coding markers can also be considered part of Low Risk Group and can be used in risk analysis.

* Medium Risk Group: Operational files used by the Operating System, which change infrequently. Examples: o Content of C:\Proqram Files folder o Content of C:\Windows\System folder * High Risk Group: Documents and files originating from a user(s).

o Images: jpg, .bmp, etc. o Videos: .mp4, .mpg, etc. o Sounds: .mp3, etc Documents, these are very high risk since they often change frequently: .doc, etc. o Database files: .db, etc. o All other file type without an initial predictability factor.

Evolving Group: Operational files used by the operating systems.

These are used to compare between machines with the same ID to confirm which one is the original/oldest in case of cloned machines.

o Operating System Database files.

o Operating System swap/temporary files.

6. After the initialisation, and during subsequent authentication sessions, the predictability of each file will be the factor to determine their location in the groups. So files can move between the groups in dependence on their change in predictability.

As it will be seen later, the only exception are files selected to analyze the Machine ID.

7. The Authenticator Server 1301 authenticates machines by gathering several files from the Authenticator Client 1300. The information for the files is extracted from the Knowledge Base 1304: * Machine ID: Five stable files, previously defined by the system. They will be the same for all machines. A hash will be made of the creation date of the files. This will form the Machine ID. If the Machine ID is new (i.e. if the hash is unique), the initialisation process will take over in accordance with step 8 below. If the Machine ID already exists, it will be considered an authentication process.

* Password: a group of randomly chosen files selected from the Knowledge Base 1304 to be analyzed. The group is selected as follows: * Four selected from Low Risk groups.

* Three selected from Medium Risk group.

* Two selected from High Risk group.

* Evolutionary: Six files are selected from the Evolving Group.

* Learning: Eight new files that were not already added to the Knowledge Base 1304 and were not previously analyzed. Roughly, and not mandatory, two of each risk group above. When the files are inserted into the Knowledge Base 1304, their Predictability are calculated as in the item 11.

8. If the Machine ID is new, only Machine ID and Learning files are extracted from the machine and added to the Knowledge Base 1304. In this case thirty files are selected for the learning process, following the proportion 4:3:2:1 to each risk group. Predictability for each file is determined in accordance with step 5.

9. Data Analysis and Authentication process: * When the Machine ID is new, only information about Learning files will be entered in the Knowledge Base 1304 as mentioned above. In case the machine is not a clone' the process will flow as below.

* If a Black Listed' machine is found, it is flagged that a black listed machine is being analyzed. So an out of scope workflow can be used.

This workflow can be a third party authentication method or any other method outside of Lolla system.

* If at least seven files out of Password files match, the machine is authenticated.

* If between three to six files out of Password files match, a new set of different files must be sent. This process must repeat three times.

* If the number of matches is below three in any of the cases or it reaches the third time without success, the machine is considered "Not Recognized". In this case, a third party authentication process can be used. For example, checking the SIM card, or the GPS position, in case of a mobile, or checking the IP Address in case of a web application. The machine will also be black listed', waiting for an administrator to delist the machine.

* In case of successful authentication, the files that have not matched during the whole process must be compared with their version in the Knowledge Base 1304.

o If the date on the computer is earlier than the date from the Knowledge Base 1304, a "collision" is found.

o If the date is older, then this date is set for the file within the Knowledge Base 1304.

o Old version of files are kept for future reference. This provides for the calculation of the predictability of the file must be calculated.

* Evolutionary Process: After authenticating the machine, its evolutionary process must be monitored. In this case, at least an E number of evolving files must have a date equal or greater than those recorded on the Knowledge Base 1304 otherwise a "collision" is found. E can be predefined. For example, for Windows-based machines it can be four.

* Stamping process: After the evolutionary process is analyzed and the process is completed, the machine must be "stamped".

a. A "stamp" is an encrypted file with a control string randomly generated by the Authentication Server 1301.

* The encryption method used is randomly chosen by the server 1301.

* The server 1301 records what the method was chosen.

* The control string can be anything.

b. The "stamp" is saved in a location on the machine randomly chosen by the server 1301.

* The server 1301 keeps track of where the file was saved.

c. Every time a "stamp" is verified using the information in the server, a new "stamp" is generated and the older one is erased.

However the server 1301 keeps a log of all "stamps" used. The control string and the location must match with those set previously by the server.

d. More than one "stamp" can be issued to a machine at the server's 1301 discretion.

e. The "stamps" on a machine can be checked by the server 1301 and if the verification of all "stamps" fail, a "collision" is found.

10. About Collisions: If a collision is found, the system can flag the collision. Marker files are created on the machine, and known only to the Authenticator Server 1301. The position and names of the files are stored in the Knowledge Base 1304. From time to time, new markers are created and the old markers are deprecated by the Knowledge Base 1304.

The "collision" machine and the other machine with the newer file will hereafter be considered a "clone". When a machine ID belongs to a cloned machine, a search for the markers will be performed before the authentication process to establish which machine is being communicated with.

Both the cloned machine and newer machine may be marked by the markers. Each one will have a different set of markers.

Files for "collision" machines are stored in the Knowledge Base 1304 and their predictability is calculated normally as if they belong to a different machine. They will have their own Knowledge Base 1304 entries distinct from the newer machine.

Virtual machine instances of real machines are an example of collided machines.

11. Calculating Predictability: All files that are inserted into the Knowledge Base 1304 for the first time have their predictability set to their original risk group calculated in step 5. For example, when a record about the C:\Windows folder is inserted for the first time, its predictability is initialized to 1.

From the second time to t time, where t is predefined, a mean is calculated. Given X(n), where 1 <= n <= t, and n is the n analysis, so X(n) will be: For all n <= m, where m is the actual match: * I if there is a match between the dates * 0 if no match between the dates For n> m, X(n) = 1.

Predictability of a file f is given by, when 1 <= n <= t: P(f) = EX(n) I (t + 0(g)). C(g) is the parameter related to each Risk Group from item 4 above, calculated as follows: * Given R(g) = t I (t + C(g), and where g is the group, so R(1) = 1 for group 1; * R(2) = 0.9 for group 2.

* R(3) = 0.6 for group 3.

* R(4)= 0.4forgroup4 Alternatively, a close estimation to the above can be used.

When n > t, then the mean P(f) = X(n) It can be calculated using the last previous t' data from the Knowledge Base 1304.

12. About Black List management: All files analyzed during the authentication process and belonging to a black-listed machine will be logged for future reference. Black listed machines are marked with Marker files on the machine. The process is similar to the collision' process.

The Lolla system 600 can delist the machine, in this case, the machine will be considered a collision'. Their files will be considered as such, and the markers will still stand.

The Lolla system 600 may be used to secure movie, music, or other media downloads. The Lolla system 600 may be used to secure financial transactions. The Lolla system 600 may be used to set up a gatekeeper system to manage access to a network or computer in a secure fashion.

Referring to Figure 14, a possible implementation of the Lolla system 600 will be described.

In this implementation, a mobile telecommunications core infrastructure 1400 includes Followers 1401 such as the Teresa entity or Gahbee Avatars. The Followers 1401 may be used to generate a secure communications channel 1402 with mobile devices 1403 on the telecommunications network. The mobile devices 1403 will include Masters 1404 such as a Gahbee Avatar. The Lolla and Tess Servers may be deployed by the mobile telecommunications carrier or may be available to the mobile devices 1403 and infrastructure 1400 through a connected network such as through the Internet.

A potential advantage of deploying Followers within the core infrastructure is that, if desired, a backdoor to the secure communications channel can be installed by the mobile telecommunications carrier for internal monitoring purposes or at the instigation of a government.

It will be appreciated that the present invention may be implemented as software executing on computer hardware or within hardware itself.

The applicant hereby discloses in isolation each individual feature or step described herein and any combination of two or more such features, to the extent that such features or steps or combinations of features and/or steps are capable of being carried out based on the present specification as a whole in the light of the common general knowledge of a person skilled in the art, irrespective of whether such features or steps or combinations of features and/or steps solve any problems disclosed herein, and without limitation to the scope of the claims. The applicant indicates that aspects of the present invention may consist of any such individual feature or step or combination of features and/or steps. In view of the foregoing description it will be evident to a person skilled in the art that various modifications may be made within the scope of the invention.

While the present invention has been illustrated by the description of the embodiments thereof, and while the embodiments have been described in considerable detail, it is not the intention of the applicant to restrict or in any way limit the scope of the appended claims to such detail. Additional advantages and modifications will readily appear to those skilled in the art.

Therefore, the invention in its broader aspects is not limited to the specific details, representative apparatus and method, and illustrative examples shown and described. Accordingly, departures may be made from such details without departure from the spirit or scope of applicant's general inventive concept.

Claims (52)

1. Claims 1. A method of creating a secure communication channel between a device and a server, including: i) a first server transmitting an encryption module selected from a plurality of different encryption modules to a device; ii) the device communicating with a second server and including an identifier for the encryption module; iii) the second server requesting a corresponding encryption module from the first server using the identifier; and iv) the second server and the device using the encryption modules to create a secure communication channel between the second server and the device.
2. 2. A method as claimed in claim 1, wherein each encryption module is obfuscated.
3. 3. A method as claimed in any one of the preceding claims, wherein the first server transmits a different encryption module selected from the plurality of encryption modules to the first device periodically.
4. 4. A method as claimed in any one of the preceding claims, wherein the encryption module is requested by the device.
5. 5. A method as claimed in any one of the preceding claims, wherein the encryption module is pushed by the first server to the device.
6. 6. A method as claimed in any one of the preceding claims, wherein the encryption module is requested by a third server for the device.
7. 7. A method as claimed in any one of the preceding claims, further including authenticating the device using the method of any one of claims 32 to 39.
8. 8. A method as claimed in any one of the preceding claims, further including: i) the device communicating with the second server over the secure communications channel to generate an encryption key; ii) the device using the encryption key to transmit encrypted data to a second device; iii) the second device communicating with the second server to obtain the generated encryption key; and iv) the second device using the encryption key to decrypt the encrypted data.
9. 9. A method as claimed in claim 8, wherein the device generates the encryption key with the second server using the method of any one of claims 13 to 22.
10. 10. A method as claimed in any one of claims 8 to 9, wherein the device uses the encryption key in conjunction with the encryption module to transmit encrypted data to the second device.
11. 11. A method as claimed in claim 10, further including the second device receiving information identifying the encryption module from the second server and the second device using the encryption key in conjunction with the identified encryption module to decrypt the encrypted data.
12. 12. A system for creating a secure communications channel between a device and a first server, including: A first server configured to extract an encryption module corresponding to the device from a second server using an encryption module identifier, and creating a secure communications channel with the device using the extracted encryption module; A second server configured to store a plurality of different encryption modules in a memory, each encryption module associated with an identifier, to select an encryption module from the plurality of different encryption modules, to transmit the selected encryption module to the device, to receive a request, including an identifier, for an encryption module from the first server, and to transmit the corresponding encryption module to the first server; and A device configured to receive an encryption module from the second server, and to create a secure communications channel with the first server using the received encryption module.
13. 13. A method of generating a common encryption key, including: i) a device obtaining a key sequence and generating a first bit sequence; ii) the device combining the key sequence and first bit sequence using a first bitwise processing method to produce a first combined sequence; iii) the device transmitting the first combined sequence to a server; iv) the server generating a second bit sequence; v) the server transmitting the second bit sequence to the first device; vi) the device combining the first and second bit sequences using a third bitwise processing method to produce a third bit sequence; vii) if the mask size of the third bit sequence is less than a predefined threshold, repeating the steps from step (iv) until the mask size of the third bit sequence at least meets the predefined threshold; viii) the server combining the first combined sequence and second bit sequence using second bitwise processing method to produce a second combined sequence; ix) the device transmitting the third bit sequence to the server; x) the device generating the common encryption key by applying the third bit sequence as a mask to the key sequence; and xi) the server generating the common encryption key by applying the third bit sequence as a mask to the second combined sequence.
14. 14. A method as claimed in claim 13, wherein the first and second bitwise processing methods include XOR.
15. 15. A method as claimed in claim 14, wherein said first and second bitwise processing methods include the step of XOR'ing both inputs to each bitwise method.
16. 16. A method as claimed in any one of claims 13 to 15, wherein the third bitwise processing method includes XOR and bit-inversion.
17. 17. A method as claimed in claim 16, wherein said third bitwise method includes XOR'ing both inputs to the method and then applies bit-inversion to the result of the XOR operation.
18. 18. A method as claimed in any one of claims 13 to 17, wherein the device obtains the key sequence by generating the key sequence.
19. 19. A method as claimed in claim 18 wherein the device generates the key sequence using a random or pseudo-random number generator.
20. 20. A method as claimed in any one of claims 13 to 17, wherein the device obtains the key sequence by loading the key sequence from memory.
21. 21. A method as claimed in any one of claims 13 to 20, wherein the device generaties the first bit sequence using a random or pseudo-random number generator.
22. 22. A method as claimed in any one of claims 13 to 21, wherein at least some of the transmissions between the device and the server are encrypted using an asymmetric key pair.
23. 23. A system for generating a common encryption key between a device and a server, including: A device configured to store a key sequence, to generate a first bit sequence, to combine the key sequence and first bit sequence using a first bitwise processing method to produce a first combined sequence, to transmit the first combined sequence to the server, to receive a second combined sequence from a server, to combine the first and second bit sequences using a third bitwise processing method to produce a third bit sequence, to request a replacement second bit sequence until the mask size of the third bit sequence at least meets a predefined threshold, to transmit the third bit sequence to the server, and to generate the common encryption key by applying the third bit sequence as a mask to the key sequence; and A server configured to generate a second bit sequence, to combine the first combined sequence and the second bit sequence using second bitwise processing method to produce a second combined sequence, to transmit the second bit sequence to the device, to receive the third bit sequence from the device, and to generate the common encryption key by applying the third bit sequence as a mask to the second combined sequence.
24. 24. A method of transmitting encrypted data between a first and second device, including: i) the first device generating a common key with a server; ii) the second device obtaining the common key from the server; iii) the first device encrypting data using the common key and transmitting the encrypted data to the second device; and iv) the second device using the common key to decrypt the encrypted data.
25. 25. A method as claimed in claim 24, wherein the first device generates the common key with the server over a secure communication channel created using the method of any one of claims 1 to 11.
26. 26. A method as claimed in any one of claims 24 to 25, wherein the second device obtains the common key from the server over a secure communication channel created using the method of any one of claims 1 to 11.
27. 27. A method as claimed in any one of claims 24 to 26, wherein the common key is generated using the common encryption key generation method of any one of claims 13 to 22.
28. 28. A method as claimed in any one of claims 24 to 27, wherein the common key is renewed periodically between the first device and the server.
29. 29. A method as claimed in claim 28, wherein the renewed common key is synchronised with the second device using the server.
30. 30. A method as claimed in any one of claims 24 to 29, wherein the first device uses the common key to encrypt the data only once confirmation is received from the server that the second device has obtained the common key.
31. 31. A system for transmitting encrypted data between a first device and a second device, including: A server configured to generate a common encryption key with the first device, to receive a request for the common encryption key from the second device, and to transmit the common encryption key to the second device; A first device configured to generate a common encryption key with the server, to encrypt data using the common encryption key, and to transmit the encrypted data to the second device; and A second device configured to request the common encryption key from the server, to receive encrypted data from the first device, and to decrypt the data using the common encryption key.
32. 32. A method for authenticating a device, including: i) the device transmitting information to a server; ii) the server categorising the information based on predictability; iii) the server storing the categorised information into a knowledge base; iv) the server comparing further information received from the device with the stored categorised information; and v) the server authenticating the device if the further information matches the stored categorised information to a defined threshold.
33. 33. A method as claimed in claim 32, wherein the server generates an identifier for the device using information with high predictability categorisation.
34. 34. A method as claimed in claim 33, wherein each knowledge base is associated with a device and wherein the method includes the step of selecting a knowledge base associated with the device using the identifier of the device.
35. 35. A method as claimed in any one of claims 32 to 34, including the step of the device extracting the information from a memory on the device.
36. 36. A method as claimed in claim 35, wherein the information is extracted from a file system on the memory.
37. 37. A method as claimed in any one of claims 32 to 36, wherein the information includes file information selected from one or more of the set of filename, date of modification, date of creation, and bit selection from the associated file.
38. 38. A method as claimed in any one of claims 32 to 37, wherein if the defined threshold is not met then yet further information is requested from the device and steps (iv) and steps (v) are repeated with the yet further information.
39. 39. A method as claimed in any one of claims 32 to 38, wherein the server compares the further information with the stored categorised information using a neural network.
40. 40. A system for authenticating a device, including: A device, including a memory, configured to extract data from the memory, and to transmit the data to the server; A server, including a memory, configured to receive data from a device, to categorise the received data based on predictability of the data, to store the categorised data in a knowledge base within the memory, and to authenticate a device by matching received data to previously categorised data to a defined threshold.
41. 41. A communications system including replacing communications modules selected from a plurality of different communications modules at a plurality of communications devices.
42. 42. A server for use in a system for creating a secure communications channel between a device and the server, said server configured to request an encryption module corresponding to the device from a second server using an encryption module identifier, and creating a secure communications channel with the device using the extracted encryption module.
43. 43. A server for use in a system for creating a secure communications channel between a device and a second server, said server configured to store a plurality of different encryption modules in a memory, each encryption module associated with an identifier, to select an encryption module from the plurality of different encryption modules, to transmit the selected encryption module to the device, to receive a request, including an identifier, for a encryption module from the second server, and to transmit the corresponding encryption module to the second server.
44. 44. A device for use in a system for creating a secure communications channel between the device and a first server, said device configured to receive an encryption module from a second server, and to create a secure communications channel with the first server using the encryption module.
45. 45. A device for use in system for generating a common encryption key between the device and a server, said device configured to store a key sequence, to generate a first bit sequence, to combine the key sequence and first bit sequence using a first bitwise processing method to produce a first combined sequence, to transmit the first combined sequence to the server, to receive a second combined sequence from a server, to combine the first and second bit sequences using a third bitwise processing method to produce a third bit sequence, to request a replacement second bit sequence from the server until the mask size of the third bit sequence exceeds a predefined size, to transmit the third bit sequence to the server, and to generate the common encryption key by applying the third bit sequence as a mask to the key sequence.
46. 46. A server for use in system for generating a common encryption key between the device and the server, said server configured to generate a second bit sequence, to receive a first combined sequence from the device, to combine the first combined sequence and the second bit sequence using second bitwise processing method to produce a second combined sequence, to transmit the second bit sequence to the device, to receive a third bit sequence from the device, and to generate the common encryption key by applying the third bit sequence as a mask to the second combined sequence.
47. 47. A server for use in a system for transmitting encrypted data between a first device and a second device, said server configured to generate a common encryption key with the first device, to receive a request for the common encryption key from the second device, and to transmit the common encryption key to the second device.
48. 48. A device for use in a system for transmitting encrypted data between the device and a second device, said device configured to generate a common encryption key with a server, to encrypt data using the common encryption key, and to transmit the encrypted data to the second device.
49. 49. A device for use in a system for transmitting encrypted data between a second device and the device, said device configured to request a common encryption key previously generated between the second device and a server from the server, to receive encrypted data from the second device, and to decrypt the data using the common encryption key.
50. 50. A server for use in a system for authenticating a device, said server including a memory and configured to receive data from the device, to categorise the received data based on predictability of the data, to store the categorised data in a knowledge base within the memory, and to authenticate a device by matching received data to previously categorised data to a defined threshold.
51. 51. Computer program configured for performing the method of any one of claims 1 to 13, claims 15 to 22, claims 24 to 30, and claims 32 to 39.
52. 52. Computer-readable medium configured for storing the computer program of claim 51.