WO2016030832A1 - Procédé et système de données mobile et sécurité de communication - Google Patents

Procédé et système de données mobile et sécurité de communication Download PDF

Info

Publication number
WO2016030832A1
WO2016030832A1 PCT/IB2015/056462 IB2015056462W WO2016030832A1 WO 2016030832 A1 WO2016030832 A1 WO 2016030832A1 IB 2015056462 W IB2015056462 W IB 2015056462W WO 2016030832 A1 WO2016030832 A1 WO 2016030832A1
Authority
WO
WIPO (PCT)
Prior art keywords
token
application
communication
computing device
mobile computing
Prior art date
Application number
PCT/IB2015/056462
Other languages
English (en)
Inventor
Daniels LEWIS
Original Assignee
Kopper Mountain Limited
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Kopper Mountain Limited filed Critical Kopper Mountain Limited
Publication of WO2016030832A1 publication Critical patent/WO2016030832A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/34—User authentication involving the use of external additional devices, e.g. dongles or smart cards
    • G06F21/35—User authentication involving the use of external additional devices, e.g. dongles or smart cards communicating wirelessly
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/602—Providing cryptographic facilities or services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/107—Network architectures or network communication protocols for network security for controlling access to devices or network resources wherein the security policies are location-dependent, e.g. entities privileges depend on current location or allowing specific operations only from locally connected terminals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2107—File encryption

Definitions

  • This invention relates generally to verification systems and methods, and secure communication systems. It may be suited for, but not necessarily 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
  • Bring your own device also called bring your own technology (BYOT), bring your own phone (BYOP), and bring your own PC (BYOPC)— refers to the policy of permitting employees 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 bring your own device
  • BYOT bring your own technology
  • BYOP bring your own phone
  • BYOPC bring your own PC
  • 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.
  • Inverse-BYOD BYOD security
  • BYOD has resulted in data breaches. For example, if 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 information being 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 be 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.
  • 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.
  • the token sends a key to the client system or device so that the client knows that the token can be 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 be transmitted wirelessly to a locally provided client or to a nearby access point.
  • the US 2008/0282078 Al shows an S/MIME gateway for e-mail encryption, which acts as a proxy between a client device and an SMTP server and provides encryption for the messages sent and received;
  • EP 2 533 488 Al describes an external NFC-enabled device for signing and encrypting e-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 e-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 client.
  • specific user data such as e-mails
  • 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 be received and/or sent while the token is co-located 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 arranged 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.
  • the mobile device may be a portable computing device.
  • the portable computing device may beneficially be a laptop, a tablet computer, or a mobile telephone for example. It may be a handheld device.
  • 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-1, SHA-224, SHA-256 and/or voltage and temperature sensors to detect attacks.
  • the token may be configured to receive biometric user information. This is particularly 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 unintentionally 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 be used to recharge a battery provided in or on the token.
  • the security token may further comprise a battery arranged to receive electricity generated by the photovoltaic means.
  • the system is arranged such that the communication can only be sent from and/or received by the application when the token and the mobile computing device are located within near or close proximity to each other.
  • This enhances security.
  • This also distinguishes the invention from prior art arrangements which perform a one-time open or access of the mobile device.
  • the invention provides a solution which performs a continuous search for the token.
  • the application may be 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).
  • the application may be 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 the mobile device and is able to receive 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.
  • the invention is novel over smart card or NFC type authentication tokens by continuously monitoring the 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
  • the token may transmit identification data (e.g. a token ID) to the mobile device over a short range wireless network such as Bluetooth®.
  • identification data e.g. a token ID
  • Other close proximity technologies may be used such as iBeacons, RFID technology etc.
  • 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.
  • 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 be referred to as a 'key' .
  • the key may be stored securely on the token. It may be 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 application may not be opened, used and/or executed without successful verification of the token.
  • the application may only be used and/or accessed upon:
  • 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 may be 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.
  • the token is portable. It may be implemented as a key fob or smart card.
  • it is a separate device from the mobile computing device.
  • the token may comprise a sealed housing. This may prevent the ingress 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 touchscreen, and/or keypad.
  • the application is only able to receive and/or send the communication if the mobile computing device is determined to be within a pre-determined geographical location or area.
  • the location of the mobile device may be determined. This may be performed using a GPS mechanism provided on the mobile device.
  • the location data may then be used to determine whether access to a remote device eg server is permitted. Location information may be provided by an IP address for example.
  • 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.
  • the communication may be conducted between a plurality 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 be able to communicate.
  • the electronic record may be referred to as a 'vCard'.
  • a vCard may be created for each mobile device.
  • the vCard 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.
  • 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.
  • the communication may be conducted between a mobile device at one end and a server at the other.
  • 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:
  • 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 may also comprise the step of repeatedly monitoring the co-location of the mobile computing device and the token during execution of the application.
  • the method may provide that the communication is allowed or able to be 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 comprise the step of:
  • 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 mobile computing device may be a mobile phone, tablet computer, or laptop computer.
  • the mobile computing device and the token may be configured for wireless
  • 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 determining whether the mobile computing device is within a pre-determined geographical location or area.
  • vCard may be exchanged between a plurality of mobile computing devices to enable them to
  • 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 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 received and/or sent while the token is co-located with the mobile computing device.
  • the application may be arranged such that it is only able to operate (fully or partially) when the token is determined to be 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.
  • 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.
  • 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.
  • Figure 1 illustrates an overview of exemplary embodiment of the invention.
  • Figure 2 illustrates an example of an architecture which may be used in relation to an embodiment of the physical device ("Token").
  • Figure 3 illustrates an example of an architecture which may be used in relation to the communication between token and mobile 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 the device and token are 'known' to each other and able to identify one another.
  • the token 103 and the mobile device 102 are able to communicate with each other via a secure wireless 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
  • the mobile device 102 is provided with a Bluetooth® 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 be 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.
  • the application 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.
  • the data cannot be saved/retrieved by the application without the required 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.
  • 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.
  • FIG. 2 shows a more detailed illustration of the token 103 of figure 1.
  • 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 because it enhances the security of the invention.
  • the token's memory stores the encryption algorithm which is accessed and executed by the secure processor 402.
  • the secure processor may be AES encrypted or may employ other security mechanisms instead or in addition.
  • the token comprises a true random number generator (not shown in Figures) which is used by the invention to generate unique identifiers 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 specifically for the secure storage of highly sensitive electronic media and communications.
  • 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.
  • 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
  • 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 be 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 the token to be compromised. It also prevents the ingress of moisture and/or dirt which could comprise the functionality of the token.
  • the token may comprise a SIM card to enable the token to be used for location based authentication or remote kill.
  • the SIM card number or IMEI (International Mobile Station Equipment Identity) details could be used for identification purposes.
  • Perturbation malfunctioning or destruction of the secure processor, e.g. by violent access to the token, renders access to the encrypted 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.
  • FIG 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.
  • 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 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.
  • the further device 105 also has the app 108a 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.
  • Figure 5 illustrates a perspective of figure 4 whereby the mobile device 102 uses the token device 103 to retrieve data/communications from a server device 503.
  • FIG 6 shows a variant of token 103 wherein the token is implemented within a wearable case or housing such as a Bluetooth enabled headset, smart watch, wristband, or intelligent glasses.
  • 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.
  • communications/data storage application is installed on the user's mobile device.
  • the user then opens and registers with the application so that a user profile can be created and the user can be linked with the token.
  • more than one user may register with a given token although more typically one token will be associated with only one user.
  • 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 be 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 ID'.
  • the user ID may take any suitable form of identification data such as a PIN number or access code, password etc or combination thereof.
  • the user ID may comprise biometric data, which may be captured by a suitable reader device such as a finger print scanner.
  • the user 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 then connects with the token over a
  • Bluetooth connection and sends its unique identifier (eg IMEI) to the token.
  • IMEI unique identifier
  • a pairing process then matches the token with the application on the mobile device.
  • the token generates a random number which will hereafter be referred to as the 'token key' .
  • the secure processor applies an algorithm 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 unlock 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 (but 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.
  • the token 103 and the mobile device 102 have the necessary hardware and software, to enable them to communicate with each other wirelessly. 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 are 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, or RFID technology etc.
  • Any form of close range, near range or localised communication protocol may be used.
  • the protocol enables the communication channel to be encrypted.
  • the token 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 he 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 application 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 user 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.
  • 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 (and/or 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.
  • the 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.
  • the application continually monitors for the presence of the paired token. As long as the token can be detected within range, the application can continue to operate. Once the token's presence can no longer be 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.
  • the user 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. Alternatively, 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).
  • IMEI the devices' unique identifier
  • 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 IMEI and the stored token key should be 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.
  • the other mobile device 105 To transfer secure communications, the other mobile device 105 must be paired with its own token 106 and have the application 108a installed on it. Thus, the other device has its own instance of the corresponding application installed on it.
  • the system comprises two mobile devices with respective paired tokens at each end of the communication.
  • the devices 102, 105 must be 'known' to each other before a session can be initiated.
  • 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 vCard is an electronic record or contact which includes information relating to the user.
  • the vCard also includes a secret, unique identifier which may be referred to as a 'PIN' or 'key' .
  • a 'PIN' or 'key' To generate the vCard PIN the token 103 generates a random number. 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 number.
  • the user's vCard is stored securely in the encrypted portion of the mobile device's memory, and cannot be accessed without the paired token. A copy of the user's vCard will be 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.
  • 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.
  • both tokens 103, 102 must be powered 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. If it does not then the session request is denied.
  • 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.
  • 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.
  • a communication can be transmitted using simply the mobile device identifier (eg phone number).
  • the mobile device identifier eg phone number
  • 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.
  • 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 be 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.
  • each outgoing communication flows from the application 108 to its paired token 103 via the wireless protocol 403 e.g. Bluetooth.
  • 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 be software encrypted prior to sending it from the application to the token.
  • the Bluetooth channel is also encrypted.
  • 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 forwarding to the other device.
  • 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.
  • 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.
  • the user 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.
  • 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.
  • 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 number and applies an encryption algorithm to that number along with the device identifier.
  • This operation produces a token ID which can be sent to the mobile device.
  • the application will only able to send/receive 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 completed, the user will be able to use the application if (and only if) the following conditions are fulfilled:
  • #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 verified by the token.
  • the token When the user wishes to send/receive a communication (eg Call over VoiP, instant message or encrypted SMS/MMS, email) the token is brought into proximity with the mobile device.
  • a communication eg Call over VoiP, instant message or encrypted SMS/MMS, email
  • the token and the mobile device communicate via a secure, wireless, close proximity connection eg Bluetooth.
  • 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 previously generated token ID.
  • the user authenticates with the application (e.g. by providing the previously specified 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 registration/pairing 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
  • the invention may be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer.
  • a device claim enumerating several means several of these means may be 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Telephone Function (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne un système de sécurité et un procédé correspondant pour assurer la sécurité des communications envoyées et/ou reçues en provenance d'un dispositif mobile grand public tel qu'un téléphone intelligent ou d'une tablette. Le système comprend un jeton de sécurité matériel comprenant un processeur sécurisé qui comporte un générateur de nombre aléatoire. Une application est fournie sur le dispositif mobile et est appariée avec le jeton, de telle sorte que l'application n'est pas accessible sans le jeton apparié. Toute communication envoyée ou reçue par l'application est déchiffrée ou chiffrée par le processeur sécurisé. Le système est agencé de sorte que la communication peut uniquement être envoyée et/ou reçue par l'application lorsque le jeton et le dispositif informatique mobile sont situés à proximité proche ou immédiate l'un de l'autre. L'utilisateur doit s'authentifier avec succès à l'aide du jeton et/ou de l'application avant l'envoi ou la réception de a communication. La communication peut être un message instantané, un message vocal, un texte, des données d'image. L'invention peut également être utilisé pour le stockage sécurisé de données sur le dispositif mobile. Ainsi, l'invention concerne des caractéristiques de sécurité améliorées pour des technologies PAP (prenez vos appareils personnels).
PCT/IB2015/056462 2014-08-28 2015-08-26 Procédé et système de données mobile et sécurité de communication WO2016030832A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB1415246.6A GB2529812A (en) 2014-08-28 2014-08-28 Method and system for mobile data and communications security
GB1415246.6 2014-08-28

Publications (1)

Publication Number Publication Date
WO2016030832A1 true WO2016030832A1 (fr) 2016-03-03

Family

ID=51752273

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2015/056462 WO2016030832A1 (fr) 2014-08-28 2015-08-26 Procédé et système de données mobile et sécurité de communication

Country Status (2)

Country Link
GB (1) GB2529812A (fr)
WO (1) WO2016030832A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
IT201800011156A1 (it) * 2018-12-18 2020-06-18 Archimedetech Srl Procedura di autenticazione di utenti con software di intelligenza artificiale e due dispositivi elettronici

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2614568A (en) * 2022-01-07 2023-07-12 Renavato Corp Security device

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040250074A1 (en) * 2003-06-05 2004-12-09 Roger Kilian-Kehr Securing access to an application service based on a proximity token
WO2009022333A2 (fr) * 2007-08-13 2009-02-19 Aladdin Knowledge Systems Ltd. Jeton virtuel pour l'installation automatique transparente d'un environnement de sécurité
US20110314539A1 (en) * 2010-06-18 2011-12-22 At&T Intellectual Property I, L.P. Proximity Based Device Security

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070150742A1 (en) * 2005-12-22 2007-06-28 Cukier Johnas I Secure data communication for groups of mobile devices
US9264231B2 (en) * 2008-01-24 2016-02-16 Intermec Ip Corp. System and method of using RFID tag proximity to grant security access to a computer
US8249556B2 (en) * 2010-07-13 2012-08-21 Google Inc. Securing a mobile computing device
GB201221433D0 (en) * 2012-11-28 2013-01-09 Hoverkey Ltd A method and system of providing authentication of user access to a computer resource on a mobile device
US9262620B2 (en) * 2013-03-13 2016-02-16 Brian Eli Berl Illion Secure communications kit and client device for securely communicating using the same

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040250074A1 (en) * 2003-06-05 2004-12-09 Roger Kilian-Kehr Securing access to an application service based on a proximity token
WO2009022333A2 (fr) * 2007-08-13 2009-02-19 Aladdin Knowledge Systems Ltd. Jeton virtuel pour l'installation automatique transparente d'un environnement de sécurité
US20110314539A1 (en) * 2010-06-18 2011-12-22 At&T Intellectual Property I, L.P. Proximity Based Device Security

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
IT201800011156A1 (it) * 2018-12-18 2020-06-18 Archimedetech Srl Procedura di autenticazione di utenti con software di intelligenza artificiale e due dispositivi elettronici

Also Published As

Publication number Publication date
GB2529812A (en) 2016-03-09
GB201415246D0 (en) 2014-10-15

Similar Documents

Publication Publication Date Title
US20210350013A1 (en) Security systems and methods for continuous authorized access to restricted access locations
ES2596308T3 (es) Método y disposición para autenticación segura
US9380058B1 (en) Systems and methods for anonymous authentication using multiple devices
US8763097B2 (en) System, design and process for strong authentication using bidirectional OTP and out-of-band multichannel authentication
US8543091B2 (en) Secure short message service (SMS) communications
US11245526B2 (en) Full-duplex password-less authentication
EP2879421B1 (fr) Procédé de confirmation de l'identité d'un terminal et d'authentification d'un service, système et terminal
US20220116385A1 (en) Full-Duplex Password-less Authentication
CN106878245A (zh) 图形码信息提供、获取方法、装置及终端
CN111512608A (zh) 基于可信执行环境的认证协议
US20210256102A1 (en) Remote biometric identification
KR101358375B1 (ko) 스미싱 방지를 위한 문자메시지 보안 시스템 및 방법
KR101680536B1 (ko) 기업용 모바일 업무데이터 보안 서비스 방법 및 그 시스템
WO2016030832A1 (fr) Procédé et système de données mobile et sécurité de communication
KR20110128371A (ko) 모바일 클라이언트 보안인증시스템과 중앙제어시스템 및 그 동작방법
WO2015124798A2 (fr) Procédé et système autorisant une opération validée par authentification pour un dispositif de traitement de données
Nishimura et al. Secure authentication key sharing between personal mobile devices based on owner identity
Kilani et al. Mobile authentication with NFC enabled smartphones
KR101298216B1 (ko) 복수 카테고리 인증 시스템 및 방법
Batyuk et al. Multi-device key management using visual side channels in pervasive computing environments
Saidi Secure Text Transfer Via Bluetooth Using Hybrid Encryption
WO2017151080A1 (fr) Système d'identification personnelle

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15771269

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC ( EPO FORM 1205A DATED 06/07/2017 )

122 Ep: pct application non-entry in european phase

Ref document number: 15771269

Country of ref document: EP

Kind code of ref document: A1