GB2529812A

GB2529812A - Method and system for mobile data and communications security

Info

Publication number: GB2529812A
Application number: GB1415246.6A
Authority: GB
Inventors: Lewis Daniels
Original assignee: KOPPER MOUNTAIN Ltd
Current assignee: KOPPER MOUNTAIN Ltd
Priority date: 2014-08-28
Filing date: 2014-08-28
Publication date: 2016-03-09
Also published as: WO2016030832A1; GB201415246D0

Abstract

Communications can only be sent or received when a token and a mobile computing device such as a smart phone or tablet are located within near or close proximity to each other. The hardware security token may comprise a secure processor which includes a random number generator. An application may be provided on the mobile device and is paired with the token so that the application cannot be accessed without the paired token. Any communication sent or received by the application is decrypted or encrypted by the secure processor. The user is required to successfully authenticate with the token and/or application prior to the communication being sent or received. The communication can be an instant message, voice message, text, image data. The invention can also be used for the secure storage of data on the mobile device. Thus, the invention provides enhanced security features for BYOD (bring your own device) technologies.

Description

Intellectual Property Office Application No. GB1415246.6 RTTVI Date:2 March 2015 The following terms are registered trade marks and should be read as such wherever they occur in this document: Skype Bluetooth WhatsApp WiFi Intellectual Property Office is an operating name of the Patent Office www.gov.uk/ipo Method and System For Mobile Data and Communications Security This invention relates generally to verification systems and methods, and secure communication systems. It may he suited br, hut not necessarfly limited to, systems and methods for the security of mobile communications. The invention is particularly suited for use in enabling the secure data transfer between two devices. It provides an enhanced verification technique which enables strong authentication and encryption of communications in a secure and convenient manner.

Bring your own device BYOD)-also called brng your own technology BYOT). bring your own phone (BYOP). and bring your own PC (BYOPC)-refers to the policy of permitting empthyees to bring personally owned mobile devices (laptops, tablets, and smart phones) to their workplace, and to use those devices to access privileged company information and applications.

BYOD is making significant inroads in the business world, with about 75% of employees in high growth markets such as Brazil and Russia and 44% in developed markets already using their own technology at work.

Various risks arise from BYOD. and agencies such as the UK Fraud Advisory Panel encourage organisations to consider these and adopt a BYOD policy.

BYOD security relates strongly to the end node problem. When a device is used to access both sensitive and risky networks and services, risk-averse organizations may issue devices spccifically for Intcrnet use (this is termed Jnvcrsc-BYOD).

BYOD has resulted in data breaches. For example, ib an employee uses a smartphone to access the company network and then loses that phone, untrusted parties could retrieve any unsecured data on the phone. Another type of security breach occurs when an employee leaves the company but they do not give back the device to the company. so company applications and other data may still be present on the device which they are no longer authorised to use.

Improved security for electronic devices is also necessary due to the increase in traffic of sensitive inlormation heing inputted, stored on or transferred between devices. This increase in traffic and potential vulnerability of sensitive information leads to significant potential reward for those who illegally access such information. This is particularly important in a number of fields such as, for example, in military applications where highly confidential information is transferred between or stored on a computing device.

One known security technique is to use a token implemented within a secure device carried by an individual so that the individual can verify his identity using the device. These may sometimes he referred to as hardware tokens', authentication tokens' or cryptographic tokens'. The security token serves as an electronic key to unlock access to the controlled resource. In addition to possession of the token, other forms of authentication may sometimes be required before the user is allowed to perform the operation such as password or PIN entry. or verification of biometric data associated with the user.

However, without access to the token the user is not able to authenticate with the client systemldevice.

During use, the token sends a key to the client system or device so that the client knows that the token can he trusted. The token is provided with hardware and/or software to enable it to communicate with the client. For example, some tokens might include a USB connector for physical connection to the client while others might include RFID capabilities or a Bluetooth interface so that the key sequence can he transmitted wirelessly to a locally provided client or to a ncarby access point.

Different types of proxy devices for securing the communication between two parties have been demonstrated: the US 2008/0282078 Al shows an S/MTME gateway for c-mail encryption, which acts as a proxy between a client device and an SMTP server arid provides encryption for the messages sent and received; EP 2 533 488 Al describes an external NEC-enabled device Ièr signing and encrypting c-mails, such that the respective keys need not be present at the computational platform used to access and transmit the messages.

EP2575298A1 describes a transparent proxy device, which analyses the entire data stream of a client, searches for specific user data (such as c-mails) and encrypts this data before passing it on to a similar device arranged at the other end of the transmission, which picks up the data stream, recognizes the encrypted e-mail and transparently decrypts it before passing it further on to the receiving chent.

Most mobile devices do not contain secure processors. and most are vulnerable to either brute force attacks or software (Cyher hacks). Thus, access to sensitive files or transmission olcommunications to/from such devices can he compromised.

Thus, it is desirable to be able to combine the convenience of use provided by a BYOD with the enhanced security of a hardware token. Such a solution would provide increased security and help to maintain the privacy of sensitive information on an electronic device.

by only permitting authorized access to the device and only when the token and mobile device are co-located. Communications between the mobile device and another device would ideally he secured by such a solution. It is desirable to provide a token scAution which is secure, convenient to use and overcomes the disadvantages associated with known technologies.

Such an improved solution has now heen devised.

Thus, in accordance with the present invention there is provided a method and corresponding systems as defined in the appended claims.

Thus, according to one aspect of the invention, there is provided a security system comprising: a security token comprising a secure processor; an application paired with the token and conhgured br execution on a mobile computing device such that any communication received by and/or sent from the application is decrypted or encrypted by the secure processor; and can only be received and/or sent while the token is co-Jocated with the mobile computing device.

The token and the mobile computing device may be co-located when they are within proximity to each other, or within a distance which enables them to communicate via a close, short or near range communication technology.

The system may be arnmgcd such that the co-location of the mobile computing device and the token is repeatedly monitored during execution of the application. Thus, there may be an ongoing check during execution of the application that the token and mobile device are within proximity to each other. Without co-location, the application may cease to operate partially or completely.

The mobile computing device may simply be referred to as a mobile device' hereafter for the sake of convenience.

The token may be viewed as a key for accessing the application on the mobile device.

Beneficially, the mobile device may he a portaffle computing device. The portable computing device may beneficially he a laptop, a tablet computer, or a mobile telephone for example. It may bc a handhcld device. Preferably, the mobile computing device is a BYOD. It may be an off-the-shelf consumer device. Preferably, it does not comprise a secure processor.

The secure processor may be a crypto processor. It may comprise a unique 64-bit serial number, tamper detection with rapid key/data destruction, secret key destruction on tamper events, permanent loader lockout option, proprietary code scrambling techniques using random keys, hardware accelerators for AES, RSA, DSA, ECDSA, DES, 3DES. SHA-l, SHA-224, SHA-256 and/or voltage and temperature sensors to detect attacks.

The token maybe configured to receive biometric user information. This is particu'arly beneficial for a number of reasons. Firstly, a third party cannot simply watch to learn a specific identification number. Furthermore, identification numbers can accidently be lost or unintentiona'ly provided to a third party.

The token may comprise means for generating electricity. The means for generating electricity may be photovoltaic means. The token may comprise photovoltaic (solar) cells arranged to produce electricity from sun light. This can he used to recharge a battery provided in or on the token. Thus, the security token may further comprise a battery arnmgcd to rcccivc clcctricity generated by the photovoltaic mcans.

Preferably. the system is arranged such that the communication can only he sent from and/or received by (lie application when the token and the mohfle computing device are located within near or close proximity to each other. This cnhanccs security. This also distinguishes the invention from prior art arrangements which perform a one-time open or access of the mobile device. By contrast, the invention provides a solution which performs a continuous search for the token. The application may he repeatedly monitoring for the presence of the paired token. If the token cannot be detected, because the device goes too far from token or vice versa, the application may be killed (ceases to execute or function fully). Thus, the application maybe arranged to send a signal or request to the token at periodic intervals. The request may comprise the mobile device identifier. If the token is in proximity to thc mobilc devicc and is able to rcccivc the request, the token may return the token ID to the mobile device. This may enable the application to monitor the continued presence of the paired token.

Thus, the invention is novel over smart card or NFC type authentication tokens by continuously monitonng (lie proximity and presence of the token in addition to encrypting the data through the token over the communication channel of the mobile device.

The mobile computing device and the token may be configured for wireless communication via a near, short range or close proximity communication protocol such as Bluetooth. NEC, or WiFi. The token may transmit identification data (e.g. a token ID) to die mobile device over a short range wireless network such as Bluetooth®. Other close proximity technologies may be used such as iBeacons, REID technology etc. Prelerably. a user is required to successlully authenticate with the token and/or appfication prior to the communication being sent or received by the mobile computing device. This authentication may be performed by requiring the user to input an identifier such as a password. code or biometric data which is then compared with a previously stored version of the user's identifier.

The application may be paired with the token using a unique identifier which comprises a mobile computing device identifier and a random number generated by the token. The random number may he referred to as a key'. The key may he stored securely on the token. It may he kept secret in that the key is only stored on the token and never copied or transmitted to another device. The device identifier may be. for example, an IMEI. It may be any identifier which is used to identify the mobile computing device.

The token may apply an encryption algorithm to the device identifier and the random number to produce a unique identifier which may be referred to as a token ID'. The token ID may be stored on the mobile device and/or token. The token ID may be used for verification of the token before a user is able to access or use the application. Therefore.

the apphcation may not he opened, used and/or executed without successful verification of the token.

In a preferred embodiment, the application may only he used and/or accessed upon: successful verification of the user via the application; successful verification of the (paired) token with the application; and/or the token being (continuously) colocated with the mobile computing device The communication may be any type of transmission sent between devices. It may comprise, for example, instant message, voice message, text, image data.

The token maybe provided in, on or in association with a wearable device. The wearable device may be a smart watch, wristband, glasses or any other form of wearable device.

Preferably the token is portable. It may be implemented as a key fob or smart card.

Prelerably. it is a separate device from the mobile computing device.

Beneficially, there are no external data ports in the token. The token may comprise a sealed housing. This may prevent the iness or moisture or dirt. A lack of external ports or interfaces may enhance security by preventing a physical connection to the processor.

Charging of the token may be achieved by induction charging or/and solar charge. User input may be achieved via a biometric scanner and/or touehscreen, and/or keypad.

Preferably, the application is only able to receive and/or send the communication ii the mobile computing device is determined to be within a pre-determined geographical location or area. This provides further security. The location of the mobile device may be determined. This may be performed using a UPS mechanism provided on ihe mobile device. The location data may then he used to determine whether access to a remote device eg server is permitted. Location information may be provided by an IP address for

example.

Preferably. the communication is sent to or received from a further mobile computing device comprising a further application paired with a further token having a further secure processor, the further application being configured for execution on the further mobile computing device such that any communication received by/sent from the further application is decrypted/encrypted by the further secure processor.

Thus, the communication maybe conducted between a p'urality of mobile computing devices, wherein each mobile device is paired with its own token. An appropriately configured application is installed for execution on each mobile device.

The mobile devices may be required to exchange electronic records or contacts in order for them to he able to communicate. The electronic record maybe referred to as a vCard'. A vCard may he created!èr each mobile device. The Card may comprise a unique identifier for identification of the user. This may be referred to as a PIN. The PIN may be generated by the token. It may comprise a random number generated by the token, in combination with a mobile device identifier such as an IMEI. The secure processor may apply an encryption algorithm to the PIN and the mobile device identifier.

In some embodiments, the communication is sent. to or received from a server having a secure processor. and the communication is required to pass through the secure processor for encryption and/or decryption of the communication. Thus, the communication may he conducted between a mobile device at one end and a server at the other.

According to the invention, there is provided a security method corresponding to the system features described above. Thus, all of the features and embodiment described iii relation to the system above may also apply in relation to the method and vice versa.

The method may be described as a method of securing a communication sent to and/or received by a BYOD mobile computing device.

The method may comprise the step of: pairing a security token comprising a secure processor with an application on a mobile computing device such that any communication received by/sent from the application is decrypted/encrypted by the secure processor; and can only be received and/or sent while the token is co-located with the mobile device.

It niay also comprise the step of repeatedly monitoring the co-location of the mobile computing device and the token during execution of the application.

Thus, the method may provide that the communication is allowed or able to he sent from and/or received by the application only when the token and the mobile computing device are located within near or close proximity to each other.

It may also compnse the step of: requiring a user to successfully authenticate with the token and/or application prior to the communication being sent or received by the mobile computing device.

The application may be paired with the token using a unique identifier which comprises a mobile computing device identifier and a random number generated by the token.

The communication may be an instant message, voice message. text, image data.

The mohfle computing device may he a mobile phone, tablet computer, or laptop computer.

The mobile computing device and the token may be configured for wireless communication via a near or close proximity communication protocol such as Bluetooth, NFC. or WiFi. Any other form of near, close or short range communication technology may be used.

The token may be provided in, on or in association with a wearable device.

The method may also comprise the step of: determining whether the mobile computing device is within a pre-determined geographical location or area.

It may also comprisc the step of: only allowing the application to receive andior send the communication if and only if the mobile computing device is within a pre-determined geographical location or area.

It may also comprise the step of: storing an electronic contact on the mobile device, the mobile device comprising a unique identifier. The electronic contact may he referred to as a vCard. vCards may he exchanged between a plurality of mobile computing devices to enable them to communicate with each other via the application.

-1 0-Also in accordance with the invention there may he provided a security syslem comprising: a security token comprising a sccurc processor; an application paired with the token and configured for execution on a mobile computing device such that any data saved to and/or retrieved from memory on the mohile computing device via the application is decrypted or encrypted by the secure processor; and can only be received and/or sent while the token is co-located with the mobile computing device.

As with described above with respect to other embodiments or aspects of the invention, the application may he arranged such that it is only able to operate (fully or partially) when the tokcn is dctcrmincd to bc within close, near or short range of the mobile device upon which the application is installed. The application may be arranged to continuously search for and monitor the presence of the token.

Thus, this embodiment of the invention may comprise any or all of the features described above in relation to the first aspect of the invention, but according to this aspect the application may be configured for data storage and/or manipulation rather than for the transmission of communications.

The system may be arranged such that the data can only be saved to or retrieved from the device's memory by the application when the token and the mobile computing device are located within near or close proximity to each other.

The user may be required to successfully authenticate with the token and/or application prior to the data being saved or retrieved by the application.

There arc numerous applications for such an invention. These will he described in detail in the specific description. Such a method however minimizes the potential of unauthorized access through the claimed steps and would be particularly advantageous where the information transmitted is extremely sensitive and requires secure transference. -Il-

These and other aspects ci the present invention will he apparent from and elucidated with reference to, the embodiment described herein.

An embodiment of the present invention will now he described, hy way of examp'e only, and with reference to the accompany drawings, in which: Figure 1 illustrates an overview of exemplary embodiment of the invention.

Figure 2 illustrates an example of an architecture which may he used in rdation to an embodiment of the physical device ("Token").

Figure 3 illustrates an example of an architecture which may he used in rdation to the communication between token and mohile device.

Figure 4 illustrates an example architecture and functionality in accordance with an embodiment of the invention.

Figure 5 provides an alternative illustration of the functionality of an embodiment of the invention.

Figure 6 illustrates an example architecture in relation to an embodiment of the token which is implemented in a headset form.

Figure 7 shows an overview of the system in use wherein communications are sent between two mobile devices via a communications tower and/or server.

The present invention provides an authenticating and encrypting system and corresponding method. The invention provides secure transfer, storage and handling of data, digital media and communications. This communication is preferably, but not limited to, communication between mobile telephones and other portable devices which possess computing and communications capabilities.

An overview of a preferred embodiment is shown in Figure 1. Figure 1 shows a security token 103 which is paired with a mobile device 102 so that thc devicc and token are known' to each other and able to identify one another. The token 103 and the mobile device 102 are ahe to communicate with each other via a secure wirdess connection 202, 203. The token and the mobile device (phone) are physically distinct, separate devices.

The mobile device 102 is an off-the-shelf consumer device and comprises known hardware and software functionality to enable it to communicate with other devices 105 via a wireless connection 205, 204. In order to provide the wireless, close proximity communication capability, thc mobile dcvicc 102 is providcd with a Bluctooth® component.. The wireless connection is a secured channel 204 and enables the mobile device 102 to send long range (encrypted) communications 205. The mobile device 102 is also provided with a GSM/SIM card.

An application (program) 108 is installed and configured for execution on the mobile device. The application may be referred to as an app'. The application is arranged and configured to enable a communication session to he established and conducted between the mobile device 102 and one or more further devices 105. The application may handle any type of electronic communication e.g. email. Instant Message. SMS message, MMS message or VOIP communication.

In somc embodimcnts, in addition to or instead of sending communications the application is configured to enable data files to be saved and/or retrieved from the device's memory.

In such embodiments, the data cannot he saved/retrieved by the application without the rcquired paired token, such that the data stored in the memory on the mobile device is accessible only through the encryption functionality of the secure processor on the token.

For the sake of convenience, the description hereafter will refer to embodiments which enable the securing of communications between devices rather than the securing of data storage on the mobile device.

Figure 2 shows a more detailed illustration of the token 103 of figure 1. Figure 2 shows some of the internal components of the token device 103 which comprises a secure processor 402 and a Bluetootli® component 403. It shouki he noted that other communication protocols may bc used instead of or as well as Bluctooth®.

Thus, the token 103 comprises a secure processor 402 and associated memory (not shown in Figures). The secure processor may be a crypto processor. This secure processor is important bccausc it enhances thc security of thc invcntion. The tokcn' s mcniory storcs the encryption algorithm which is accessed and executed by the secure processor 402. The sccurc proccssor may he AES encryptcd or may employ other security mechanisms instead or in addition. The token comprises a true random number generator (not shown in Figurcs) which is uscd by the invcntion to gcnerate uniquc identificrs as discussed below.

Secure processors are not typically found in consumer devices such as smartphones, tablet computers etc which are general purpose devices and not designed specilically for the secure storage of highly sensitive electronic media and conmiunications. By contrast, the token part of the invention is a dedicated device which is configured for the storage and transfer of secure electronic media and communications, and for verification of identification data.

Thus, the invention provides enhanced security hardware and software capabilities which are not provided with off-the-shelf computing devices for public consumers. These security mechanisms enable users to use their own mobile phones for secure communication and storage of data. The datalcommunieation may only be accessed by an authorised user who has the key and token to open it and unlock it.

In sonic embodiments the security token 103 comprises photovoltaic means (solar cells) for generating electricity. These are not shown in the figures. The solar cells are used to recharge a battery which powers the token. This provides the advantage that the token can he self-sufficient in terms of energy source and can avoid the need for a cabled re-charging arrangement to keep the battery energised.

The token comprises a fluid-tight housing which is completely sealed. Therefore, it is devoid of external ports. sockets or interfaces which could possibly allow the security of die token to he compromised. It also prevents the ingress of moisture and/or dirt which could comprise thc functionality of thc tokcn.

In some embodiments, the token may comprise a SIM card to enable the token to he used for location based authentication or remote kill. lii such embodiments, the S1M card number or IMEI (International Mobile Station Equipment identity) details could be uscd for identification purposes.

Pcrturhation, malfunctioning or destruction of the secure processor, e.g. by violent access to the tokcn, rcndcrs access to thc cncrypted memory virtually impossible. The secure processor is preferably unique in that read access to the data is available only through the exact same secure processor that has been paired.

Figure 3 shows in more detail the token device 103 communicating to a mobile device 102.

The token and the device 102 are co-located i.e. near to each other and so the token 103 is able to a send command 202 at close proximity (Bluetooth connection 403). Data is also shown coming back to the token 103 before being passed through the secure processor 402 within the token for encryption to be applied. This is also illustrated in figure 7.

Figure 4 illustrates a mobile device 102 authenticating with the token device 103 and sending data over a channel at close proximity 202. The data is then sent through the secure channel 204 which could also be long range secured 205 to a router or server 502.

A second mobile device 105 then retrieves the data, passes it to a second token 106 paired to that mobile device 105 over its channels 202, 203. The second token decrypts the data and passes it back to the second mobile device.

As shown in ligure 4, the further device 105 also has the app lOSa installed on it, and is also paired with its own token 106. The further device also comprises communications capabilities as described above for the first mobile device 102. The further token 106 also comprises a secure processor and associated memory (not shown) as per the first token 103.

FigureS illustrates a perspective of figure 4 whereby the mobile device 102 uses the token device 103 to retrieve dataleommunications from a server device 503.

Figure 6 shows a variant of token 103 wherein the token is implemented within a wearaffle case or housing such as a Bluetooth enabled headset, smart watch, wristband, or intelligent glasses. The skilled person will readily appreciate that the token 103, 106 may be implemented in a variety of physical forms; for example, within or on a key fob or a smart card.

An installation or initial set up procedure is performed to configure the system prior to first use. During this procedure, a token is provided to the user. The secure communications/data storage application is instafled on the user's mobile device. The user then opens and registers with the application so that a user profile can he created and the user can be linked with the token. In some embodiments, more than one user may register with a given token although more typically one token will be associated with only one user.

During the registration process, data relating to the user is captured so that the user profile can be created. This might include data such as username, phone number, country of residence etc. The data may he captured in a variety of ways e.g. inputted by the user via a screen, speech recognition and/or keyboard.

A user identifier is also inputted or otherwise generated so that this identifier can be stored for user authentication purposes in subsequent use of the system. This user identifier will be referred to hereafter as the user D'. The user ID may take any suitable form of identification data such as a PIN number or access code, password etc or combination thereol In some embodiments, the user ID may comprise biometric data, which may he captured by a suitable reader device such as a finger print scanner.

The user then clicks on or otherwise selects a connect token' option to pair the token with the app on the user's mobile device. The token information is entered. This may be done by entry via a touchscreen. The mobile device (lien connects with the token over a Bluetooth connection and sends its unique identifier (eg IMEI) to the token.

A pairing process then matches the token with the application on the mobile device. To do this, the token generates a random number which will hereafter be referred to as the token key'. The secure processor applies an a'gorithm to the token key and the IMEI to a unique identifier hereinafter referred to as a token ID'. The token key is stored securely on the token, and acts as a secret key to unthck access to the application. The token key does not change -if the user changes the token, a new token key is generated. The token ID (hut not the key) is sent to the mobile device where it is stored for future reference. In future use, when the user wishes to access the application, the application will be able to verify the token using the stored token ID.

Thus, while the mobile device stores the user's information such as the phone number.

email address etc, the secret key is stored on the secure token. Therefore, the token is required in order to unlock' the application for use. This avoids security issues which could arise if the key was stored on the relatively insecure BYO, off-the-shelf mobile device.

Both the token 103 and the mobile device 102 have the necessary hardware and software, to enaffle them to communicate with each other wirdcssly. Such communication protocols are commonly provided as standard functionality on general purpose mobile devices such as tablets, smart phones etc. Communication between the token and the mobile device is only possible when they are within proximity to each other. In other words, the token can only communicate with the mobile device when they arc physically located within a certain localised distance or range of each other. Such communication may be conducted via Bluetooth® connectivity, iBeacons, Near Field Communication (NFC) techniques, wiFi direct, orRFID technology etc. Any form of close range, near range or loealised communication protocol may be used. Preferably, the protocol enables the communication channel to be encrypted.

As the token is unable to communicate with the device 102 via any wide area or long distance protocol, the token must be in the same locality as the mobile device in order to communicate with it. This enhances security because if the token/device is lost or stolen, an unauthorised party cannot use the token/device unless lie is also in the vicinity of the device/token.

A second layer of security is provided by pairing the token and the mobile device so that the apphcation is only able to provide its functionality when the device is connected to the user's pre-assigned token. Security is even further enhanced by requiring authentication of the uscr prior to permitting a communication channel to be opened between the application and the token. Security is even further enhanced by the encryption capabilities provided by the secure processor housed within the token.

Thus, in order for an unauthorised person to use the application on the user's device, the unauthorised person would need to have access to the user's phone, the user's token and also know the user's ID (eg password). The application on the mobile device may only send/receive communications (andlor store data) if the mobile device is connected with the paired token during use. This pairing can take a variety of forms, but essentially the token 103 is only able to communicate with the mobile device 102 if it can be established that the token is the same one which was associated with the user's device during set-up.

hi this mLmncr, thc token, the mobile device and the user are logically linked in that the token is registered for use by the user, the mobile device is associated with the user, and both the user and the mobile device are known' to the token.

During use, the application continually monitors for the presence of the paired token. As long as the token can he detected within range, the apphcation can continue to operate.

Once the token's presence can no longer he detected, the application is killed.

A server may act as an intermediary through which the communication and associated data may flow between the token and a number of paired (other users') mobile devices, as shown in Figures 4 and 5. In this way, the server 503, 502 may function as a buffer between the additional mobile devices 105 and the token 103. Therefore, the user's mobile device 102 does not communicate directly with the additional mobile devices 105 other than through tokens 103, 106 provided at each end of the communication, each token 102, 106 being paired with its respective mobile device 102, 105. Again, this provides enhanced security because the identification data for each user needs only to be known to the respective token.

When the user wants to use the application to send/receive messages (or store/access data from the mobile device), the user is required to verify his identity. The user enters his user ID (eg password) and this is compared with the version stored during the registration process. If the inputted user ID matches the stored version, the user's identity has been verified and the user is able to gain access to the application. Mternatively, if there is no match then the user is deemed unauthorised and cannot access the application.

Upon successful verification of the user, the application attempts to connect with the token.

A request to connect is sent from the application to the token, the request including the devices' unique identifier (e.g. IMEI). Tn response, the token uses its secure processor to apply the same algorithm that it used during the set up process on the IMEI and the stored token key. This produces a token ID. If the same IMEI was received, the token ID generated by operating on the IMEL and the stored token key should he the same token ID that was sent to the mobile device during set up. The token ID is sent from the token to the application which checks it against the version of the token ID previously stored on the mobile device. If there is a match then the application knows that it is talking to' the correct token, the token and the device are paired, and the user can proceed with the attempted communication. However, if the token ID is not verified then the application and token cannot connect. No communications can be sent or received.

To transfer secure communications, the other mobile device 105 must he paired with its own token 106 and have the application 108a installed on it. Thus, the other device has its own instance of the colTesponding application installed on it. Thus, the system comprises two mobile devices with respective paired tokens at each end of the communication.

The devices 102, 105 must he known' to each other before a session can he initiated. To achieve this, each user generates an electronic contact or record (which may be referred to as a vCard') which can be sent to other mobile devices to securely identify the user's device. The Card is an electronic record or contact which includes information relating to the user. Some of the data contained in the vCard is obtained from the user during the set-up process described above (eg name, email address etc). The vCard also includes a secret, unique identifier which may be referred to as a PIN' or key'. To generate the vCard PIN the token 103 generates a random nuniher. It then applies an encryption algorithm to that random number in conjunction with some form of user-related identifier such as the mobile device's IMEI numbcr. Thc user's vCard is storcd securely in thc encrypted portion of thc mobile device's memory, and cannot be accessed without the paired token. A copy of the user's vCard will he sent via the application to each other user with whom the user wishes to communicate. Therefore, users exchange their respective vCards, each vCard comprising a unique vCard PIN.

Without each other's vCards, the applications 108a on the devices are unable to communicate with each other. Thus, each user builds a contact list of other users with whom they may communicate. Each user's unique PIN is not visible to other users, who are only able to see the username provided by the user during registration.

After vCards have been exchanged, it is possihk to set up a communication session. In order to actually initiate a scssion, both tokcns 103, 102 must be powcrcd on, both mobile devices 102, 105 must be paired with and communicating with their respective tokens 103, 106 and both users must have successfully authenticated. A session request is then sent from one user's device 102 to another 105. The session request includes the user's secret vCard PIN. The receiving device 105 checks to see if the PIN it has received matches the PIN stored in the caller's vCard stored on the device 105. hit does not then the session request is denied. If there is a match, however, the receiving device 105 sends its own PIN back to the first (calling) device 102 which checks that it matches the secret PIN stored in the vCard for the other user. If it does, and both secret PINs have been exchanged and verified, the session request can proceed.

Thus, the invention differs from existing third party communication applications such as WhatsApp, Skype etc. because additional PIN entry pairing is used rather than a simple phone number or email search. With known applications, a communication can be transmitted using simply the mobile device identifier (eg phone number). Thus, if a user knows another user's phone number they can send a message to that 00cr user. In accordance with the invention, however, communications can only be sent between users who have exchanged their secret PINs or codes, and after those PINs have been verified prior to each session.

Moreover. thc alTangement of the invcntion requires that all communications flowing out from or into the application pass through the secure processor where they are encryptedldecrypted. The outgoing communications flow from the app on (lie mobile device to the token's secure processor and hack again to the device for onward transmission.

Each token 103, 106 then generates a unique session identifier (which may be called a session ID', a key' or pin'). The session ID can he generated according to any format.

For example, it could be a QR code. In some embodiments, it is produced by combining the mobile device's identifier eg IMEI number with a random number generated by the secure processor on the token. This session ID is sent to the other device 105 so that both devices 102. 105 can perform a handshake operation and establish a session with each other. Thus, in order for the two devices to communicate they need to exchange session keys. At the end of the session the session IDs will be erased.

Once the session is underway, each outgoing communication flows from the application 108 to its paired token 103 via the wireless protocol 403 e.g. Bluetooth. At the token 103, the communication is encrypted by the secure processor 402 before being sent to the other mobile device 105 via its respective token 106. The communication may also he software encrypted prior to sending it from the application to the token. The Bluetooth channel is also encrypted. In some embodiments the communication flows from the application on the mobile device 102 to the token 103, where it is encrypted, then back to the mobile device 102 where it is sent on to the other mobile device 105.

Therefore, the communication flows from the device to the token where it is encrypted before being sent back to the device and from there on to a server or communications tower for lorwarding to the other device.

Upon receipt, the secure processor in the other token 106 decrypts the communication which is then passed to the application 108a on the other mobile device 105 and presented (e.g. displayed) to the other user.

hi usc, an embodiment of the present invention can be summarised as follows.

Prior to first use, the user registers with the system by filling out a user credential form.

providing information such as, for example, email address. phone number, chosen user name, country of residence. The user provides user ID details (e.g. PIN, password, biometric data), which are stored for future reference so that the application on the mobile device can subsequently verify the user's identity.

An application is installed and set-up by the user on a first mobile device eg mobile phone.

The application on the device is paired with a secure token using a unique device identifier e.g. the mobile device's IMEI number combined with a random number which is generated by the token. This is performed by the secure processor of the token, which generates the random numbcr and applies an encryption algorithm to that numbcr along with thc device identifier. This operation produces a token ID which can be sent to the mobile device.

Subsequently. the application will only able to sendlreceive communications upon detection of that previously paired token.

A vCard is created for the user and stored in the encrypted portion of the device. The vCard includes a secret PIN or code which is generated by the token using a mobile device identifier and a random number which are fed into an encryption algorithm. The user exchanges this vCard with other others so as to build up a list of authorised' contacts.

After this initial set up has been comp'eted. the user will he able to use the application if (and only if) the following conditions are fulfilled: *thc token is recognised by the application as the one with which it was paired *the token is within range of (close proximity to) the mobile device; and *the user's identity is successfully verified by the application; verification may be performed by the user entering the user ID which was stored in step 1 *the user's identity is successfully yen lied by the token.

When the user wishes to send/receive a conmiunication (eg Call over VoiP. instant message or encrypted SMS/MMS, email) the token is brought into proximity with the mobile device. The token and the mobile device communicate via a secure, wireless, close proximity connection eg Bluetooth.

When the mobile device detects the presence of the token, a verification process is performed to ensure that the token is the same one which was previously paired with the application on the mobile device. This verification process is performed using the prcviou sly generated tokcn ID.

The user authenticates with the application (e.g. by providing the previously speci fled user ID eg password). The user may also authenticate with the token.

The user attempts to initiate a communication session with a second user.

The communication session is given some form of unique session ID. This could include a random number which is generated by the secure processor in the token. It could be a QR code.

The application, via the token, sends the session ID to the other mobile device where the reverse of these steps are performed. (The other user's mobile device has the application installed on it. and the same registrationlpairing set up process has been performed with the other user's device and token).

A verification check is performed by the second user's token to ensure that the communication session has been requested by someone authorised to make contact. i.e. checks whether the second user has a vCard for the first user in the contact list.

The respective tokens check whether the verification was successful. if the verification fails, the mobile device tells the user that the session request has failed; if the verification is successful, the communication session can be established -the two users can communicate with each other in a secure environment.

It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be capable of designing many alternative embodiments without departing from the scope of the invention as defined by the appended daims. In the claims, any reference signs placed in parentheses shall not he construed as limiting the claims. The word "comprising" and "comprises', and the like, does not exclude the presence of elements or steps other than those listed in any claim or the specification as a whole. In the present specification, "comprises" means "includes or consists of' and "comprising" means "including or consisting of'. The singular reference of an element does not exclude the plural reference of such elements and vice-versa. The invention may be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In a device claim enumerating several means, several of these means may he embodied by one and the same item of hardware.

The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

Claims

CLAIMS: 1. A security system comprising: a security token comprising a secure processor; an application paired with the token and configured for execution on a mobile computing device such that: any communication received by and/or sent from the application is decrypted or encrypted by the secure processor: and can only he received and/or sent while the token is co-located with the mobile device.
2. A system according to claim 1 wherein the system is arranged such that the co-location of the mobile computing device and the token is repeatedly monitored during execution of the application.
3. A system according to claim 1 or 2 wherein a user is required to successfully authenticate with the token and/or application prior to the communication being sent or received by the mobile computing device.
4. A system according to any preceding claim wherein the application is paired with the token using a unique identifier which comprises a mobile computing device identifier and a random number generated by the token.
5. A system according to any preceding claim wherein the communication is an instant message, voice message, text, image data.
6. A system according to any preceding claim wherein the mobile computing device is a mobile phone, tablet computer, or laptop computer.
7. A system according to any preceding claim wherein the mobile computing device and the token are configured for wireless communication via a near or close proximity communication protocol such as Bluetooth. NFC. or WiFi.
8. A system according to any preceding claim wherein the token is provided in, on or in association with a wearable device.
9. A system according to any preceding claim wherein the application is only able to receive and/or send the communication if the mobile computing device is determined to bc within a prc-dctcrnnncd gcographical location or arca.
10. A system according to any preceding daim wherein the communication is sent to or received from a further a further mobile computing device comprising a further application paired with a further token having a further secure processor, the further application being configured for execution on the further mobile computing device such that any communication received by/sent from the further apphcation is decrypted/encrypted by the further secure processor.
11. A system according to any preceding claim wherein the communication is sent to or received from a server having a secure processor and the communication is required to pass through the secure processor for encryption and/or decryption of the communication.
12. A security method comprising the step: pairing a security token comprising a secure processor with an application on a mobile computing device; and the application being arranged such that any communication received by/sent from the application is decrypted/encrypted by the secure processor; and can only he received and/or sent while the token is co-located with the mobile device.
13. A method according to claim 12 comprising the step: repeatedly monitoring the co-location of the mobile computing device and the during execution of the application.
14. A method according to claim 12 or 13 and lurther comprising the step: requiring a user to successfully authenticate with the token and/or application prior to the communication being sent or received by the mobile computing device.
15. A method according to claims 12 to 14 wherein the application is paired with the token using a unique identifier which comprises a mobile computing device identifier and a random number generated by the token.
16. A method according to claims 12 to 15 wherein the communication is an instant message, voice message, text, image data.
17. A method according to claims 12 to 16 wherein the mohfle computing device is a mobile phone, tablet computer, or laptop computer.
18. A method according to claims 12 to 17 wherein the mobile computing device and the token are configured for wireless communication via a near or close proximity communication protocol such as Bluetooth. NFC, or Wifi.
19. A method according to claims 12 to 18 wherein the token is provided in, on or in association with a wearalie device.
20. A method according to claims 12 to 19 comprising the step: determining whether the mobile computing device is within a pre-determined geographical location or area.
21. A method according to claim 20 and comprising the step: only allowing the application to receive and/or send the communication ii and offly ii the mobile computing device is within apre-determined geographical location or area.
22. A method according to claims 12 to 21 comprising the step: storing an electronic contact on the mobile device, the mobile device comprising a unique identifier.
23. A security system comprising: a security token comprising a secure processor; an applicalion paired with the token and configured for execution on a mobile computing device such that any data saved to and/or retrieved from memory on the mobile computing device via the application is decrypted or encrypted by the secure processor; and can only be saved and/or retreived while the token is co-located with the mobile device.
24. A systcm according to claim 23 wherein thc systcm is arranged such that thc co-location of the mobile computing device and the token is repeatedly monitored during execution of the application.
25. A system according to claim 23 or 24 wherein a user is required to successfully authenticate with the token and/or application prior to the data being saved or retrieved by the application.
26. A system according to claims 23 to 25 wherein the application is paired with the token using a unique identifier which comprises a mobile computing device identifier and a random number generated by the token.