GB2523430A

GB2523430A - Method & system for enabling authenticated operation of a data processing device

Info

Publication number: GB2523430A
Application number: GB1419290.0A
Authority: GB
Inventors: Anastasios Chrysovoulos; Alexander Henry Gale Laurie
Original assignee: MOBBU Ltd
Current assignee: MOBBU Ltd
Priority date: 2014-02-24
Filing date: 2014-10-30
Publication date: 2015-08-26
Also published as: GB201403217D0; WO2015124798A2; GB201419290D0; GB201503065D0; WO2015124798A3; GB2525472A

Abstract

A method for providing authenticated operation of a first portable or hand-held data processing device (such as a smart phone) comprises; sending a request for an authentication message from the first device to a second portable data processing device; generating and presenting a coded authentication message by the second device; receiving and decoding the authentication message at said first device; inspecting said authentication message to determine whether authenticated operation of the first device should be provided. Subsequently, access to network resources or applications using the first device is allowed. The request sent by the first device might use wireless communication. The authentication message presented by the second device might be encoded as a Quick Response (QR) Code (RTM) that is captured by a camera of the first device. Encryption and encryption keys might be used to verify the authenticity of a request or the authentication message. The second device might be a wristwatch.

Description

Intellectual Property Office Application No. GB1419290.0 RTTVT Date:l4November 2014 The following terms are registered trade marks and should be read as such wherever they occur in this document: Grnail

RSA Rfl

Bluetooth QE. Code Intellectual Property Office is an operating name of the Patent Office www.ipo.govuk METHOD & SYSTEM FOR ENABLING AUTHENTICATED

OPERATION OF A DATA PROCESSING DEVICE

Field

This invention relates to methods and systems for enabling authenticated operation of a data processing device. In one particular implementation, the teachings of the invention relate to a method and system for enabling authenticated operation of a hand-holdable portable data processing device (such as a smartphone or laptop, for

example).

Background

In recent years it has become usual for users to interact with businesses and other users via the internet. For example, internet based email services such as Gmail have become a popular way for users to keep in touch with one another, and it is now commonplace for users to use internet based banking services to run their financial affairs. Unfortunately, this rise in use of the internet has been accompanied by a similar rise in cyber crime (for example, identity theft), and to counter this it is important to ensure that services are only provided to properly authorised users. This is particularly the case when the user is using such services on a portable data processing device as such devices are inherently more vulnerable to being lost or stolen.

A common way of restricting access to services is to provide authorised users with some sort of code that must be entered before access is provided. Typically such codes comprise a username and password, or a pin code and password combination.

For example, many mobile devices have a screenlock function that, once activated, requires the userto input a pin code before the device can be accessed. Some devices, like certain Blackberry mobile telephones, can be configured to require the user to input a first code when the device is turned on, and a second (optionally different) code that must be entered before the device can be used.

\M'dlst such arrangements can be effective, they are vulnerable if the mobile device should have been compromised by a nefarious third party, for example by means of inadvertently downloaded keylogging software. They are also vulnerable to "shoulder surfing" during which an individual surreptitiously observes the user whilst that user is inputting their password, and then notes the password for future use.

To guard against such eventualities it has previously been proposed to employ so-called two-factor authentication when authenticating a user of a service. In general terms, two-factor authentication is configured to authenticate a user on the basis of something they know (like a password, for example) and something they have (like a token or mobile telephone, for example).

One example of two-factor authentication is employed in the Gmail® internet mail system where a user may be asked to input their username and password into a webpage running on a terminal (such as a personal computer), and then subsequently be asked to input a one-time password (OTP); typically embodied as a numerical string; sent by SMS to a mobile telephone associated with that user's Gmail® account. Access to the account is only provided if the user can correctly input their password and username (the "something" that the user knows), and correctly enter the code sent to the mobile telephone (the "something" that the user has).

Another approach is to provide users with a fob, such as the RSA SecurlD® fob, which generates an OTF that is only valid for a predetermined period of time (typically less than a minute). A user can input the OTP (typically a numerical string) into a terminal that they are attempting to access to authenticate themselves, but a drawback of this approach is that it does require the user to correctly read the OTP generated by the FOB and to correctly input the code into the terminal. If a user should misread the code or enter an incorrect code, the user must wait for a new OTP to be generated and repeat the authentication process.

A similar approach, used by several banks, is to provide the user with a smartcard and a battery powered smartcard reader. When the user is prompted to authenticate themselves, typically after having already entered one or more codes into a terminal to access the service they are seeking to use, they must insert their smartcard into their reader, operate the reader to generate a code and then type that code (correctly) into the terminal. A major drawback of this approach is that the user must correctly read the code from the reader, and correctly input it into the terminal.

Another approach that addresses the issue of incorrectly reading or inputting codes into a terminal is to install software (for example, SecurEnvoy (see www.securenvoy.com)) on a user's smartphone that generates a OTP as a Quick Response (QR) code that can be read by a webcam attached to the terminal that the user is using. Whilst this approach avoids problems associated with incorrectly inputting OTPs into a terminal, it does not secure the smartphone on which the software is installed.

One approach to securing a smartphone was offered by Research in Motion (RIM) for use with their Blackberry® telephones. The RIM approach provided users with an authentication device that communicated with a Blackberry® handset by Bluetooth®.

When a user attempted to use an application on the handset a Bluetooth® message was sent to the authentication device, in response to which the authentication device generated a numerical code and displayed it on a small display. The user then had to input the displayed numerical code into the handset. Access to the application on the handset was only provided if both the code and the user's login credentials were inputted correctly. As a further security measure, the handset was configured to automatically lock the application to prevent it being accessed if the Bluetooth® link between the handset and the authentication device should be broken (for example if the handset should be stolen).

One drawback with this approach is that as the authentication device was of a similar size to a Blackberry handset it was inconvenient for the user to carry separately.

A consequence of this is that users tended to attach the authentication device to the handset so that both devices could be carried as one unit. Such an approach also avoided inadvertently breaking the Bluetooth® link, and having to repeat the authentication process. However, taping the authentication device to the handset defeated the above-mentioned auto-lock function and could enable access to be had to the application on the telephone by a third party who had the login credentials of the user. A further drawback is that if the user should incorrectly read or input the numerical code into the handset, the whole authentication process would have to be restarted Aspects of the present invention have been devised with the foregoing problems in mind.

Summary of the Invention

In accordance with a presently preferred embodiment of the present invention, there is provided a method of providing authenticated operation of a first hand-holdable data processing device, the method comprising the steps of: (i) controlling the first device to generate a request for an authentication message, (ii) sending said request to a second hand-holdable data processing device, (iU) generating, at said second device, a coded authentication message in reply to said received request, (iv) communicating the coded authentication message to said first device, (v) receiving said coded authentication message at said first device; (vi) decoding said received authentication message, and (vU) inspecting said decoded authentication message to determine whether authenticated operation of said first device should be provided.

An advantage of this implementation is that as the coded authentication message is communicated to the first device by the second, the user is freed from having to read codes off the second device and then correctly enter those codes into the first device.

In one implementation, said coded authentication message is machine-readable and unintelligible to a user of the first hand-holdable data processing device. An advantage of this arrangement is that a third party who manages to view the coded message cannot read it. It is also envisaged to encrypt the message before it is encoded. This would be advantageous as with such an arrangement a third party who managed to decode the coded authentication message would not be able to access the contents of that message.

Preferably said request is sent to said second device via a first means of communication, and said coded authentication message is communicated to said first device via a second means of communication different to said first. An advantage of this arrangement is that both means of communication would need to be compromised for the security of first device to be threatened.

The first means of communication may comprise a short-range wireless communications link. The second means of communication may comprise a visual communications link.

In a preferred arrangement, the coded authentication message is communicated to the first device semi-automatically. For example, steps (v) and (vi) further comprise displaying said coded authentication message on a screen of said second device, and operating a camera of said first device to capture an image of said coded authentication message. This arrangement provides a particularly easy way for the coded authentication message to be transferred from the second device to the first, whilst avoiding the possibility of the user incorrectly inputting a code into the first device.

The request for an authentication message may be encrypted. The encrypted request for an authentication message may include an encryption key. Preferably the method comprises operating the second device to verify the authenticity of a request received in step (iii). Preferably the method comprises decrypting said encrypted request to reveal said encryption key. In one implementation the second device may include a stack of encryption keys, and the method may comprise determining the request to be valid if the encryption key encrypted in said request matches an encryption key in the stack. Encrypting the link between the first and second devices further enhances the security of the system as a whole.

The coded authentication message may include an encrypted encryption key.

Step (vii) may comprise decoding said authentication message and decrypting said decoded message to reveal said encryption key. For example, the first device may include a stack of encryption keys, and the method may comprise determining said decoded and decrypted authentication message to be to valid if the encryption key encrypted and encoded in said authentication message matches an encryption key in the stack of the first device. Preferably the stack of encryption keys stored in said first device is symmetrical to the stack of encryption keys stored in said second device.

In another implementation, step (U) may comprise sending said request to said second device via a trusted third party. Preferably said first device and said trusted third party co-operate to verify each other's identity. The first device and said trusted third party may verify each other's identity by exchanging encryption keys and comparing a received key with a stored key. Preferably, said trusted third party and said second device co-operate to verify each other's identity. The trusted third party and said second device may verify each other's identity by exchanging encryption keys and comparing a received key with a stored key.

In a preferred implementation the first hand-holdable data processing device may comprise a device with an image capture module, for example a tablet computer, laptop computer or smartphone. The second hand-holdable data processing device may comprise a wearable computing device, such as a smartwatch.

Another aspect of the invention relates to computer software comprising one or more software modules operable, when executed in an execution environment, to implement the functionality of one or more of the steps of the method described herein.

In one implementation the computer software may comprise a first software component installable on a first hand-holdable data processing device, and a second software component installable on a second hand-holdable data processing device.

The first software component may comprise: a generator module for generating a request for an authentication message, a decoding module for decoding a received coded authentication message; and an inspection module for inspecting a decoded authentication message to determine whether authenticated operation of said first device should be provided.

The second software component may comprise: a generator module for generating a coded authentication message in reply to a received request for an authentication message, and a communications module operable to communicate said coded authentication message to said first device.

Another aspect of the invention relates to a wearable computing device, such as a smartwatch, including a second software component having the features specified above installed thereon. A further aspect of the invention relates to a hand-holdable data processing device, such as a smartphone, including a first software component having the features specified above installed thereon.

A further aspect of the invention relates to a system for providing authenticated operation of a first hand-holdable data processing device, the system comprising: (i) a first generator module operable to control the first device to generate a request for an authentication message, (ii) a communications module for sending said request to a second hand-holdable data processing device, (Hi) a second generator module operable to generate a coded authentication message in reply to said received request, (iv) a second communications module for communicating the coded authentication message to said first device, (v) a module for receiving said coded authentication message at said first device; (vi) a decoding module for decoding said received authentication message, and (vii) an inspection module operable to inspect said decoded authentication message to determine whether authenticated operation of said first device should be provided.

Brief Description of the Drawings

Various aspects of the teachings of the present invention, and arrangements embodying those teachings, will hereafter be described by way of illustrative example with reference to the accompanying drawings, in which: Fig. 1 is a diagrammatic representation of a smartphone and a smartwatch; Fig. 2 is a schematic representation of functional modules of a software module installed on the smartwatch; Fig. 3 is a schematic representation of functional modules of a software module installed on the smartphone; Fig. 4 is a diagram depicting the steps of a provisioning phase of an authentication process; Fig. 5 is a diagram depicting the steps of an authentication phase of the authentication process; Fig. 6 is a diagram depicting the steps of a provisioning phase of another authentication process; Fig. 7 is a diagram depicting the steps of an authentication phase of the process depicted in Fig. 6; Fig. 8 is a diagram depicting the steps of a provisioning phase of an authentication process; and Fig. 9 is a diagram depicting the steps of an authentication phase of the process depicted in Fig. 8.

Detailed Description of Preferred Embodiments

Preferred embodiments of the present invention will now be described with particular reference to a user with a smartphone and a smartwatch, and who wishes to be provided with authenticated access to applications installed on the smartphone.

It should be remembered, however, that these embodiments are merely illustrative of the teachings of the invention, and not intended to limit the scope of the present invention in any way. In particular, it should be remembered that the teachings of the present invention may be applied to the authenticated operation of other hand-holdable data processing devices (such as laptops or tablets) -for example to a user with a smartphone and a tablet, and who wishes to be provided with authenticated access to applications installed on the tablet (or indeed on the smartphone).

Similarly, whilst particular reference will be made hereafter to certain encryption techniques, it will be appreciated by persons of ordinary skill in the art that such techniques are merely illustrative, and that any of a variety of known encryption techniques could instead be used without departing from the scope of the present invention.

Lastly, whilst the following embodiments concern the provision of authenticated access to applications installed on a smartphone, it will be appreciated that the teachings of the present invention may be applied to the provision of authenticated access to the smartphone (or other hand-holdable data processing device) itself For example, in one illustrative implementation a user may be unable to use any functions of the device without first having been authenticated.

With the above provisos in mind, reference will now be made to Fig. 1 of the accompanying drawings. Fig. 1 is a schematic, and purely illustrative, depiction of only those hardware components of a smartphone 1 and smartwatch 3 that are of relevance for a detailed understanding of the teachings of the present invention. As skilled persons will immediately appreciate, smartphones and smartwatches each include a variety of additional components, the identity and function of which are well understood and for brevity will not be described in detail herein. In this particular illustrative implementation, the smartphone comprises an iPhone® provided by Apple, Inc and the smartwatch comprises a Pebble® provided by Pebble Technology Inc. It will be appreciated, however, that the teachings of the invention may readily be applied to devices from other manufacturers.

As shown the smartwatch 3 comprises a functional core 5 that comprises core functional hardware components (such as a processor, memory, a power source and a charging controller) that cooperate with core functional software modules that are loaded onto the device and executed by the processor to enable the device to operate. The smartwatch also comprises a display 7 controllable by the processor and on which information (such as the date and time) can be displayed, and a short-range transceiver 9 (such as a Bluetooth® transceiver) that is also controllable by the processor to enable the smartwatch 3 to communicate with other hand-holdable data processing devices, such as the smartphone 1, that are equipped with a compatible short-range transceiver.

In general terms the core functional hardware components and the core S functional software modules cooperate to provide, inter alia, an operating environment in which additional functional software modules (often known as applications) can be executed. One such application 11, of which there may be several, is a second software module of a two-module authentication software product. This second software module 11 is configured to cooperate (in a manner that is later described in detail) with the functional core 5 to display information on the display 7. The second software module 11 also cooperates with the functional core 11 and the aforementioned short-range transceiver 9 for the transmission of information to and the receipt of information from a second hand-holdable data processing device, in this instance the aforementioned smartphone 1.

The smartphone 1 comprises a functional core 13 of core functional hardware components (such as a processor, memory, power source and charging controller) that cooperate with core functional software modules that are loaded onto the device and executed by the processor to enable the device to operate. The smartphone also comprises a long-range wireless transceiver 15 (for communicating with a wireless telephony network), a short-range wireless transceiver 17 (such as a Bluetooth® transceiver) that enables the smartphone 1 to communicate with other hand-holdable data processing devices, such as the smartwatch 3, that are equipped with a compatible short-range transceiver, a camera 19 for capturing images, and a user interface 21 (for example a touchscreen and/or keyboard).

In a similar manner to the smartwatch, the core functional hardware components and the core functional software modules of the smartphone cooperate to provide, inter alia, an operating environment in which additional functional software modules (often known as applications) can be executed. One such application, of which there may be several, is a first software module 21 of the aforementioned two-module authentication software product. This first software module 21 is configured to cooperate (in a manner that is later described in detail) with the functional core 13 to control the camera 19. The first software module 23 also cooperates with the functional core 13 and the aforementioned short-range transceiver 17 for the transmission of information to and the receipt of information from a second hand-holdable data processing device, in this instance the aforementioned smartwatch 3. Lastly, this first software module 21 is configured to be invokable by (in this particular example) other applications 22 so as to provide authenticated access to those applications.

Referring now to Fig. 2, there is depicted a schematic representation of the functional modules that together provide the functionality of the aforementioned second software module 11 installed on the smartwatch 3.

The second software module 11 includes a main application 23 that provides a user interface and interfaces with a variety of discrete functional modules that can be called by the main application, as required, to achieve a given function.

One such module comprises a communications module 25 that co-operates with the short-range transceiver 9 to enable communications via a short-range communications link (in this example, a BluetoothTM link) between the smartwatch 3 and smartphone 1. A data representation module 27 is configured to represent data appropriately for the particular application(s) on the smartphone that provide for authenticated operation, and a data storage interface 29 provides an interface whereby data relating to the smartphone application(s) can be stored between smartwatch restarts.

The second software module further comprises a key generator module 31 that is operable to generate cryptographic keys. In one illustrative implementation, the key generator module 31 is operable to implement a hashing algorthim, for example SHA2S6, to generate keys. A cipher module 33 is provided and utilises the keys generated by the key generator module 31 to encrypt messages for transmission via the short-range wireless link (in this example, an encrypted Bluetooth link) with the smartphone 1. The cipher module may, in one implementation, implement an AES2S6 encryption algorithm. In this particular embodiment of the invention, the cryptographic keys generated by the key generator 31 are each form the whole or part of an "authentication message" for transfer to the smartphone 1.

The second software module also comprises modules for encoding authentication messages and communicating coded authentication messages to the smartphone 3. In this particular example, this is implemented by means of a QR CodeTM (Quick Response Code) encoding module 35 that is operable to convert cryptographic keys generated by the key generator 31 into QR CodeTM binary representations of those keys, and a message communication module 37 that renders the generated QR CodeTM representations and controls the display 7 to display the rendered representations. As will be appreciated by persons skilled in the art, the teachings of the present invention are not limited to the transmission of keys, but could instead or additionally include the sending of messages (encrypted or otherwise) or groups of messages.

The above notwithstanding, in the particular implementation hereafter described, an authentication message comprises a cryptographic key, and an encoded authentication message comprises a single OR CodeTM binary representation of that key. In other envisaged implementations, the message could comprise a plurality of keys, and the encoded authentication message couple comprise a plurality of different OR CodeTM representations (each corresponding to a said key). It is also envisaged that coding schema other than OR CodeTM representations could readily be employed. For example, the encoder could convert the cryptographic keys into a bar code. In another envisaged implementation, the cryptographic key could be converted into an audio track that is communicated to the smartphone by means of a loudspeaker in the smartwatch driven by the message communication module.

In very general terms the encoding module is configured to convert any binary data, both key and message material (which each comprise a string of alphanumeric characters) that can be read by a human into a form that cannot readily be read and/or understood by a human, but can be automatically read and decoded by a data-processing device. This is in contrast to previously proposed devices (such as the aforementioned BlackberryTM device) where coded messages comprised a string of characters that could be read by a human and had to be typed into the device Referring now to Fig. 3, there is depicted a schematic representation of the functional modules that together provide the functionality of the aforementioned first software module 21 installed on the smartphone 1. In general terms, these modules mirror those of the second module installed on the smartwatch.

The first software module 21 includes a main application 39 that provides a user interface and interfaces with a variety of discrete functional modules that can be called by the main application, as required, to achieve a given function.

The first software module comprises a communications module 41 that co-operates with the short-range transceiver 17 to enable communications via a short-range communications link (in this example, a BluetoothTM link) between the smartwatch 3 and smartphone 1. The main application 39 is configured to represent data appropriately for the particular application(s) 23 on the smartphone that provide for authenticated operation, to interface with those applications to generate requests for authenticated messages when called to do so by the application(s) 23, and to co-operate with the communications module 41 to send those requests to the smartwatch 3.

The first software module also comprises a key generator module 45 that is operable to generate cryptographic keys, and is complementary to the key generator module 31 in the second software module on the smartwatch. In one illustrative implementation, the key generator module 45 is operable to implement the same hashing algorthim, for example SHA256, as the complementary module 31 in the smartwatch to generate a stack of keys. A cipher module 47 is provided and is operable to utilise the keys generated by the key generator module 45 to encrypt messages for transmission via the short-range wireless link (in this example, an encrypted Bluetooth link) with the smartwatch 3 via the aforementioned communications module 41. The cipher module may, in one implementation, implement an AES2SO encryption algorithm.

The second software module also comprises a module for decoding coded authentication messages received from the smartwatch 3. In this particular example, the decoding module is implemented by means of a QR CodeTM (Quick Response Code) decoding module 49 that is operable to convert OR code images captured by the camera 19 into the corresponding cryptographic key. As will be appreciated by persons of ordinary skill in the art, the decoding module must be configured to operate with hardware that is suitable for receiving the encoded authentication message from the smartwatch, and to decode that message. Thus where the message comprises an audio message, for example, the decoding module operates in concert with a microphone, for example, to receive the audio message and be capable of converting a received audio message into the corresponding cryptographic key.

Regardless of implementation, it is an advantage of the present invention that the decoding module 49 operates in concert with smartphone hardware to automatically capture an encoded authentication message communicated by the smartwatch. This relieves the user from having to type in a code to the smartphone, avoids the potential for a user to incorrectly input a code, avoids the possibility of a nefarious third party intercepting and understanding the coded authentication message, and enables larger amounts of data to be quickly transferred (thereby enhancing the authentication process).

In a preferred implementation of the teachings of the invention, the first and second software modules co-operate to establish a short-range communications link between themselves, and are each configured so that a break of the link (for example, because one device has moved out of range of the other) terminates the association of one device with the other and requires the authentication process (described below) to be repeated. This is an important security feature of the teachings of the invention, as if the user's smartphone should be stolen (for example), then access to any applications that require authentication will automatically cease when the smartphone moves out of range of the smartwatch. In another envisaged implementation that utilises features of certain versions of the BluetoothTM communications protocol, the proximity of the two devices is determinable, and each device may be configured to break the communications link (thereby requiring the authentication process to be repeated) if the devices should be separated by more than a predetermined distance.

Having described the hardware and software in functional terms above, details of an illustrative authentication process will now be described. The particular process to be described is based upon the basic concept of using one-time encryption keys (that is to say, keys that can only be used once) for every authentication request made by the application on the smartphone that requires authentication. Such an application could comprise, for example, a messaging application (such as an email client) on the smartphone that is configured to only provide appropriately authorised persons with access to the messages stored in the application.

This authentication process has two basic components, a provisioning phase where keys are generated by the smartwatch and smartphone, and an authentication phase where generated keys are utilised for authentication.

In order to generate the aforementioned one-time keys it is necessary for a secret to be shared between the smartwatch and the smartphone. In one implementation this is achieved by controlling the smariwatch to generate a secret that is then shared with the smartphone. The secret could comprise, for example, a hash of a static numeric or alphanumeric string (such as a serial number of the smartwatch) and a variable numeric string (such as the current smartwatch system time).

In an envisaged implementation, the secret is shared with the smartphone by encoding the secret as a QR CodeTM and then displaying the QR CodeTM on the watch display 7. Once the smartphone 1 has been operated to control the camera 19 to capture an image of the displayed QR CodeTM, the secret generated by the smartwatch -once decoded -has effectively been shared with the smartphone. In addition to sharing the secret, in one embodiment the smartphone and smartwatch cooperate to share information that allows the smartphone to identify the specific application on the smartwatch, and information that allows the smartwatch to identify the specific application on the smartphone.

As will be appreciated, in a modification of this arrangement the secret could instead be generated by the smartphone and then shared with the smartwatch, although such an implementation would be less preferred (at least in the context of this particular smartphonelsmartwatch implementation) as the secret would need -in the absence of a camera on the smartwatch -to be transmitted to the smartwatch via the short-range communications link and thus could potentially be intercepted.

In an envisaged implementation, once the provisioning phase has been completed, the smartwatch and smartphone each generate a stack of keys from the shared secret, using the same hashing algorithm, to use every time they want to authenticate with each other in the authentication phase of the process. The stacks are burnt downwards, and as it is computationally hard to calculate the input to a hashing algorithm any attacker who manages to capture an encrypted key sent between the smartwatch and smartphone, can never use that same key to replay or mimic the phone or watch. Another key feature of the design is as the stack burns down, it will naturally expire. This might not be ideal in all scenarios however, and in a modification re-provisioning (resupplying the smartwatch and smartphone with keys once a stack has been completely burnt) could instead be done transparently in the background (i.e. without the user having to specifically invoke the provisioning phase of the process).

With reference to Fig. 4, the aforementioned provisioning phase will now be described in more detail. It is assumed, for the purposes of the following description, that the smartphone 1 and smartwatch 3 have already been paired with one another and that a live BluetoothTM communications channel has been set-up between them. The process by which such a channel is established is known in the art and will not further be described herein.

In a first step, 51, the user selects and executes the application on the smartphone that can be paired with a smartwatch to provide two-factor authentication.

Using the normal login process for that application, the user activates two-factor authentication. The steps for doing this will be dependent on the application. Some applications may have a menu item, others might require the user to setup two-factor authentication as part of the application installation process. In response to activation of the two-factor authentication option, the smartphone activates its camera -in step 53 -in readiness for capturing an image of the QR CodeTM that will be displayed by the smartwatch.

The user then selects and executes, in step 55, the authentication application on the smartwatch, and selects a "provision" option from a menu of options available to them. In response to selection of the provision option by the user, the main application 23 and key generator module 31 co-operate to generate, in step 57, a one-time hash (SF-1A256) of a secret for transmission to the smartphone. The secret may comprise, for example, a serial number (Serial_No) of the smartwatch and a current system time (Time) of the smartwatch. In step 59, once the encrypted secret has been generated the main application 23 invokes the encoding module 19 and encodes the encrypted secret as a OR CodeTM. The main application 23 then cooperates with the message communication module 37 in step Olto display the following message as a QR CodeTM: SHA256(Time & SeriaLNo) = #TS In step 63, the user activates the camera 19 on the smartphone 1 and captures an image of the OR CodeTM displayed on the display 7 of the smartwatch 3. The main application 39 on the smartphone then co-operates with the decoding module 49 in step to decode the OR CodeTM and retrieve #TS.

Once #TS has been retrieved the main application 39 then generates a provisioning message (PM) consisting of an application identifier (APP_ID), and an application token (APP_TOK): PM = [APP_ID, APP_TOK] where the application identifier contains unique properties about the application (for example an application id) and the application token is based on several unique values, such as the application identifier, current system time, and #TS, etc. Next, in Step 69, the main application 39 co-operates with the key generator module 45 to hash #TS a predetermined number of times (in this example, ten thousand times). The main application 39 then co-operates with the cipher module 47 to encrypt the provisioning message (PM) using the ten thousandth hash of #TS (#TS-1 0000) as an encryption key, and thereby produce a cipher (FM-CIPHER) of the provisioning message (PM): AES2S6_ENCRYPT( #TS-1 0000, PM) = PM_CIPHER The main application 39 then co-operates with the communications module 41 to send the encrypted provisioning message PM_CIPHER to the smartwatch 3 over the BluetoothTM channel in step 71.

In step 73, the main application 23 of the smartwatch co-operates with the key generator to generate a ten thousandth hash of the secret #TS, and then with the cipher module 33 to attempt to decrypt the PM-CIPHER message using the #TS-10000 key with the aim of revealing the provisioning message PM, thus: AE5256_DECRYPT(#TS-1 0000, PM_CIPHER) = PM Next, in step 75, the main application 23 determines whether the PM-CIPHER message has been successfully decrypted using the #TS-1 0000 key. If decryption is not successful, the provisioning phase terminates in Step 75. If the PM-CIPHER message is successfully decrypted, the main application 23 determines that the smartphone has received #TS, and is therefore authenticated. The main application 23 then unpacks the provisioning message PM in step 77 and retrieves the application token APP_TOK and application identifier APP_ID.

Next, in step 79, the main application 23 generates a provisioning response message (PRM) that contains an identifier for the second software module 11 (RB_ID), and an application token (RB_APP_TOK), thus: PRM = [RB_ID, RB_APP_TOK] The main application 23 then co-operates with the cipher module 33, in step 81, to encrypt the provisioning message using a hash of #TS one less than the hash #TS- 10000 used by the smartphone (which hash has been discarded), namely #TS-9999.

The main application 23 and cipher module 33 generate the following encrypted provisioning response message: AES256_ENCRYPT(#TS9999,PRM) = PRM_CIPHER The main application 23 then co-operates with the communications module 25 in step 83 to send the encrypted provisioning response message PRM_CIPHER across the BluetoothlM channel to the smartphone 1.

The main application 39 of the first module is configured to expect the provisioning response message to be encrypted with a hash one less than the original message, i.e. #TS-9999. In step 85, the main application 39 co-operates with the key generator 45 to generate #TS-9999, and with the cipher module 47 to decrypt the encrypted provisioning response message! thus: AES2S6_DECRYPT(#TS-9999, PMR_CIPHER) = PMR The main application 39 then unpacks the provisioning message PM in step 87 and retrieves the application token RB_APP_bK and application identifier RB_APP_ID.

The watch and phone applications have now completed the provisioning phase and the authentication system is in a provisioned state ready for the authentication phase of the process.

At this stage the smartwatch and smartphone applications each have APP_ID, APP_TOKEN, RB_ID and RB_APP_TOKEN. However, in a preferred implementation, each device will not keep each other's token as it was received. Instead, both devices keep a hash of each other's token so that discovery of the token on either device would not enable a third party to mimic the other, and vice versa. In particular, the watch holds #APP_TOKEN, and the phone application holds #RB_APP_TOKEN. The original tokens are discarded from each device at this stage. The tokens are each stored with the shared encryption token #TS, along with a counter that monitors how many times a key or message needs to be hashed in order to encrypt/decrypt messages to/from the devices. In an envisaged arrangement, the main application 39, 23 of each device may cooperate with their associated data storage module 43,29 to store these data items.

Once the above described provisioning phase of the process has been completed, each device is capable (in this embodiment) of instigating the authentication phase of the process, and in the particular example described below we shall assume that an application installed on the smartphone instigates the authentication process with the smartwatch.

Referring now to Fig. 5, in a first step 89 an application 23 on the smartphone instigates the authentication phase of the process, and in response to this the main application 39 generates a request for an authentication message (RAM) for transmission to the smartwatch. The request for an authentication message comprises, as will be described below, an Authentication Challenge (AC) and the APP_ID.

To generate the AC, the main application 39 co-operates. in step 91, with the key generator module 45 to hash, a predetermined number of times (COUNT), the stored shared secret #TS. If we assume that this authentication phase occurs immediately after the above described provisioning phase, COUNT would be 9998. The main application 39 then co-operates with the cipher module 47 to encrypt the output of this hashing process and the stored application token #APP_TOKEN, so that the Application Challenge message comprises: AC = AES_ENCRYPT(#TS_COUNT, #APP_TOKEN) The main application 39 then constructs, in step 92, a request for an authentication message (RAM) that comprises the Application Challenge AC and the APP_ID, thus: RAM = [APP_ID, AC] and then co-operates with the communications module 41, in step 93, to send the RAM to the smartwatch via the BluetoothTM communications link between the smartwatch and the smartphone. The main application 39 then instructs the smartphone to activate the camera, ready for capture of a QR CodeTM displayed by the smartwatch.

S In step 95, the smartwatch main application 23 co-operates with the communications module 25 to receive the RAM. The main application 23 then attempts, in step 97, to identify the application 23 on the smartphone that has initiated the authentication phase by means of the APP_ID at the start of the RAM.

If the smartwatch main application 23 has a stored record of the APP_ID in the RAM, the main application 23 co-operates with the cipher module 33 to decrypt (in step 99) the rest of the message to reveal the #APP_TOKEN using a #TS_COUNT key generated by the key generator module 31, thus: #APP_TOKEN = AES_DECRYPT(#TS-COUNT, AC) If the main application 23 has no stored record to the APP_ID or cannot decrypt the message, the authentication phase of the process terminates.

The smartwatch main application compares its stored #APP_TOKEN with the #APP_TOKEN in step 101, to determine if the tokens match. If a match occurs the main application 23, in step 103, decreases COUNT by one (in this case to 9997) and co-operates with the key generator to generate a COUNT-i hash of #TS. The main application then co-operates in step 105 with the cipher module 33 to encrypt #TS_COUNT-1 and the stored #RB_APP_TOKEN to generate an Authentication Message for transmission to the smartphone, thus: AM = AES_ENCRYPT(#TS-COUNT-i, #RB_APP_TOKEN) The smartwatch main application 23 then co-operates with the encoding module in step 107 to encode the AM as a QR CodeTM (thereby generating a coded authentication message), and with the message communication module 37 to display the OR CodeTM on the display 7.

The operator then controls the smartphone to capture an image of the displayed OR CodeTM in step 109, whereupon the main application 39 of the smartphone co-operates with the OR decoder module 49 in step lii to decode the captured OR CodeTM image and thereby reveal the authentication message AM.

In step 113 the main application 39 co-operates with the key generator 45 to generate the #TS_COUNT-1 (in this example, COUNT would now be 9997) encryption key, and subsequently with the cipher module 47 to decrypt the authentication message using the generated #TS_COUNT-1 key and reveal the #RB_APP_TOKEN, thus: #RB_APP_TOKEN = AES_DECRYPT(#TS-COUNT-1 AM) In step 115, the main application 39 attempts to match the #RB_APP_TOKEN derived from the authentication message AM with the stored #RB_APP_TOKEN. If the two tokens are determined to match, then the main application determines that an image has been captured of a OR CodeTM generated by the smariwatch that has previously been paired with the smartphone, and determines, in step 117, that the user has been correctly authenticated. The main application then sends, in step 119, a message to the application 23 that initiated the authentication phase of the process to advise the application that the user has been authenticated, whereupon the application 23 proceeds to instigate its usual application login process in step 121.

If the main application 39 should determine that the two tokens do not match in step 115, the user is determined not to have been authenticated -in step 123-and the application 23 is advised accordingly.

As will be appreciated by persons skilled in the art, the above described process provides a robust means of implementing two-factor authentication between two hand-holdable data processing devices, where at least one of devices has an application that requires authentication. As mentioned previously, the techniques described herein could also, additionally or alternatively, be utilised to control access to such devices.

The techniques described above will likely provide more than adequate levels of security for most users. However, for those users who require even more security, it is possible modify the techniques described to implement a one time salt (for example, a four digit code) that is entered into the devices separately that could be subsequently added to #TS, in order to generate a new encryption key, #TSfiALT. This arrangement would protect against situations where an attacker has sniffed #TS, as that aftacker would not know #TQ.SALT, and if they attempted to decrypt sniffed bluetooth communications they would be required to brute force AES256 in order to get APP_TOKEN and RB_APP_TOKEN.

In this arrangement it is preferred that the salt code should not be entered by standard keyboard input, as this could be captured by malicious software on a device.

Instead it is preferred to implementing a custom input pad that users touch to enter the salt, and the "keys" of that pad could be randomly arranged on the screen of the device.

The implementation described above utilises, as the skilled person will appreciate, symmetric keys to provide authentication. In a modification of the techniques described, the two devices could utilise asymmetric encryption and authenticate via a trusted third party. Communications between a smartwatch and a trusted third party could be provided by directing messages from the smartwatch to the trusted third party via the smartphone. If the smartwatch is provided with its own mobile network transceiver, then the smartwatch could communicate directly with the trusted third party.

It is also anticipated that asymmetric ciphers could be embedded in the devices, in particular in the smartwatch, in order to extend the functionality of the techniques described to work and establish trust with other systems. It is also anticipated that the system described could be modified to store not only an application authentication token, but also an encryption key for the application's data. This key would be requested in the same way as described above, and to implement this functionality it would only be necessary to identify different requests from a device application, for example by means of a suitable identifier.

Another embodiment of the invention (utilising a different cryptographic method), will now be described with reference to Fig. 6 of the accompanying drawings, in which the steps of a provisioning phase of an authentication process are depicted.

In a first step 125, a user initiates a provisioning process by selecting and executing the first software module 21 on the first device 1, in this instance a smartphone. The software module 21 then generates, in step 127, a public/private key pair (using any of a number of different cryptographic techniques, for example the technique known as "Elliptic Curve Cryptography") [PKey, PKey_Pub]. The first software module, in step 129, then generates a provisioning request message comprising an identifier (such as an ID, App_ID, for an application on the first device for which authentication is required) and its public key, PKey_Pub, and sends that message to the second device over the BluetoothTM link between the first and second devices in step 130.

The second software module 11 receives the provisioning request message and extracts the application ID App_ID in step 131, and then generates in step 133 its own public/private key pair [WKey, WKey_Pub] for the application ID, App_ID, included in the provisioning request message. The second software module 11 then encodes its public key WKey_Pub as in this illustrative example a OR CodeTM in step 135, and controls the display 7 in step 137 -to display that OR CodeTM on the display of the second device. In step 139 the first software module then cooperates with the camera 19 to capture an image of the displayed QR CodeTM, following which the first software module decodes the captured QR CodeTM to reveal the second device's public key WPub_Key. At this point in the process, the two devices have shared their respective public keys, and thus can authenticate each other's identity when necessary Referring now to Fig. 7 of the drawings, there is depicted an authentication phase of the authentication process.

In step 143, the first software module 21 generates a request for an authentication message comprising an application identifier, App_ID,that has been encrypted with the public key of the second device WKey_Pub, and signs the message with the first device's private key P/Key. In step 145, the first software module sends the request for an authentication message to the second device over the BluetoothTM link between them.

In step 147, the second software module 11 of the second device 3 receives the request for an authentication message from the first device 1 and authenticates -in step 149 -the digital signature of the message using the first device's public key PKey_Pub.

The second software module then decrypts the application identifier App_ID using the second device's private key WKeyin step 151.

Next, in step 153, the second device 3 generates an authentication message by encrypting the application identifier App_ID with the public key of the first device PKey_Pub, and signs the message using its private key WKey. The second software module 11 then encodes the message as a QR CodeTM in step 155, and controls the display 7 to display that coded message in step 157.

In step 159, the first software module 21 cooperates with the camera 19 of the first device 1 and captures an mage of the QR CodeTM displayed on the display 7 of the second device 3. The first software mode 21 then decodes that QR CodeTM in step 161, and authenticates in step 163 the digital signature of the message using the second device's public key WKey_Pub. The first software module 21 then decrypts the application identifier App_ID using the first device's private key PKey in step 165.

If the first software module is able to decrypt the decoded QR CodeTM, the digital signature is verified and the App_ID matches that sent to the second device, then the authentication process has been successfully completed.

Another embodiment of the invention (utilising a slightly different cryptographic method), will now be described with reference to Fig. 8 of the accompanying drawings.

In this embodiment of the invention, the provisioning phase of the authentication process proceeds as in steps 125 to 139 of Fig. 6. However, once the first and second devices have shared their public keys, the first and second devices (in step 167) use any of a number of well known secure key exchange techniques, such as the Diffie-Hellman algorithm for example, to negotiate -for example over the BluetoothlM channel between the two devices -a secure key [NSKey}that can then be used for all subsequent communications between the first and second devices. The secure key (which is a symmetric key) is stored by each device in step 169 and may be used to encrypt messages sent between the devices. As the two devices have also shared their respective public keys, they can authenticate each other's identity when necessary.

In a preferred arrangement the negotiated secret key is configured to expire. For example the key may be configured to expire after a predetermined period of time, after a predetermined number of uses, or at the end of a given session. In this arrangement, a periodic check is made, to determine if the key is still valid. If the key is found not to be valid, then processing can revert to step 167 (Fig. 8) and a new key can be negotiated. More preferably, processing can revert to step 127 of Fig. 6 and the provisioning process described therein can be repeated, that process ultimately terminating with the negotiation of a new secret key.

Fig 9 is a schematic depiction of the steps of an authentication phase of the process depicted in Fig. 8. In step 171 an application 22 on the first device 1 signals the main application 39 to request authentication. The main application retrieves the stored secret key NSKey and determines, in step 173, whether the key is still valid or whether it has expired. If the key has expired, processing reverts to step 127 (Fig. 6) or 167 as explained above.

If the key has not expired, the main application generates a request for an authentication message in step 175 by encrypting an identifier for the application requesting authentication App_ID using the retrieved NSKCy. The main application then sends this message to the second device via the BluetoothTM link between the devices in step 177.

The second device receives the request for an authentication message in step 179 and decrypts the message using its own stored version of the negotiated secret key NSKeyin step 181. Optionally, the second device may be configured to conduct its own check of the validty of the key before using it to decrypt the request, and may also compare the decrypted App_ID with its own stored version of the App_ID.

The second device then generates an authentication message by encrypting its stored version of the application identifier ID using its stored negotiated key NSKey in step 183, and encodes that message in step 185 as a OR CodeTM The second device then controls its display to display the OR CodeTM in step 187, The first device activates the camera 19 and prompts the user to capture an image of the OR CodeTM displayed on the display of the second device in step 189. The first device then decodes the message in step 191, and attempts to decrypt the message instep 193 using its own stored version of the negotiated key NSKey. Once successfully decrypted the first device may signal the application that authentication was successful.

In another implementation, the first device may compare the App_ID decrypted from the decoded message with its own stored version of the App_ID before determining whether to signal the application that authentication was successful.

One advantage of the process described with reference to Fig. 9, as compared with the public/private authentication process of Fig. 6, is that symmetric key cryptography tends to be faster than asymmetric key cryptography and less processor intensive.

In particular arrangements described above, the key generators are configured to generate keys as and when required. This is advantageous as it avoids having to calculate a number of keys at the start of the process, but may compromise speed somewhat by having to generate multiple hashes when required. In another envisaged implementation the entire stack of keys could be calculated at the start of the process, stored and then retrieved as required. This would speed the authentication part of the process, but would slow the start of the process.

It will also be appreciated that the process described above provides the potential for bi-directional authentication (i.e. either device can contact the other, where hardware permits, to implement the aforementioned process). If it is determined that uni-directional authentication is adequate, then one of the devices need only hold one of the hashed tokens.

In the embodiment described above with reference to Figs. 4 and 5, the secret was comprised of a serial number of the smartwatch and a current system time, but it will be appreciated that other variable may instead be employed. Equally, it will be appreciated that the more random the nature of the parameters on which the secret is based, the belier. Thus, the aforementioned secret could be generated from any pseudo-random number generator embodied in the watch hardware. For example, the secret could be generated from data derived from a gyro, microphone, a compass or even from BluetoothTM static. Certain device manufactuers are known to provide hardware based random number generators that already link one, some or all of these peripherals in order to provide easily accessible random data with a high degree of entropy.

Although a detailed description of embodiments has been provided above, it will be apparent to persons skilled in the art that the teachings of the invention provide in general terms -a system and method for authentication, whereby messages are sent between devices via two different communications channels, one of which allows the message to be encoded so that it cannot be read by a human.

Persons skilled in the art will appreciate that the particular processes described above are merely illustrative, and that additional or different encryption/decryption and validation steps may be employed without departing from the scope of the present invention.

It will also be appreciated that whilst various aspects and embodiments of the present invention have heretofore been described, the scope of the present invention is not limited to the particular arrangements set out herein and instead extends to encompass all arrangements, and modifications and alterations thereto, which fall within the scope of the appended claims. It should also be noted that whilst the accompanying claims set out particular combinations of features described herein, the scope of the present invention is not limited to the particular combinations hereafter claimed, but instead extends to encompass any combination of features herein disclosed.

In addition, that whilst embodiments of the present invention have been described above in the context of software modules that are executable by a processor, it should be noted that the scope of the present invention is not limited to an implementation of the teachings of the invention in software. Rather, the skilled person will immediately appreciate that the functionality described herein may equally be implemented in hardware (for example, by means of a plurality of application specific integrated circuits (ASICS)) or, indeed, by a mix of hardware and software.

Finally, it should be noted that any element in a claim that does not explicitly state "means for" performing a specified function, or "steps for" performing a specific function, is not to be interpreted as a "means" or "step" clause as specified in 35 u.s.c.

Sec. 112, par. 6. In particular, the use of "step of' in the claims appended hereto is not intended to invoke the provisions of 35 U.S.C. Sec. 112, par. 6.

Claims

CLAIMS1. A method of providing authenticated operation of a first hand-holdable data processing device, the method comprising the steps of (i) controlling the first device to generate a request for an authentication message, (ii) sending said request to a second hand-holdable data processing device, (iii) generating, at said second device: a coded authentication message in reply to said received request, (iv) communicating the coded authentication message to said first device, (v) receiving said coded authentication message at said first device; (vi) decoding said received authentication message, and (vii) inspecting said decoded authentication message to determine whether authenticated operation of said first device should be provided.
2. A method according to Claim 1, wherein said coded authentication message is machine-readable and unintelligible to a user of the first hand-holdable data processing device.
3. A method according to Claim 1 or 2, wherein said request is sent to said second device via a first means of communication, and said coded authentication message is communicated to said first device via a second means of communication different to said first.
4. A method according to Claim 3, wherein said first means of communication comprises a short-range wireless communications link.
5. A method according to Claim 3 or 4, wherein said second means of communication comprises a visual communications link.
6. A method according to Claim 5, wherein the coded authentication message is communicated to the first device semi-automatically.
7. A method according to Claim 5 or 6, wherein steps (v) and (vi) further comprise displaying said coded authentication message on a screen of said second device, and operating a camera of said first device to capture an image of said coded authentication message,
8. A method according to any preceding claim, wherein said request for an authentication message is encrypted.
9. A method according to Claim 8, wherein said encrypted request for an authentication message includes an encryption key.
10. A method according to any preceding claim, comprising operating the second device to verify the authenticity of a request received in step (Hi)
11. A method according to Claim 10 when dependent on Claim 9, comprising decrypting said encrypted request to reveal said encryption key.
12. A method according to Claim 11, wherein the second device includes a stack of encryption keys, and the method comprises determining the request to be valid if the encryption key encrypted in said request matches an encryption key in the stack.
13. A method according to any preceding claim, wherein said coded authentication message includes an encrypted encryption key.
14. A method according to Claim 13, wherein step (vii) comprises decoding said authentication message and decrypting said decoded message to reveal said encryption key.
15. A method according to Claim 14, wherein the first device includes a stack of encryption keys, and the method comprises determining said decoded and decrypted authentication message to be to valid if the encryption key encrypted and encoded in said authentication message matches an encryption key in the stack of the first device.
16. A method according to Claim 12 and 15, wherein the stack of encryption keys stored in said first device is symmetrical to the stack of encryption keys stored in said second device.
17. A method according to Claim 1, wherein step (H) comprises sending said request to said second device via a trusted third party.
18. A method according to Claim 17, wherein said first device and said trusted third party co-operate to verify each other's identity.
19. A method according to Claim 18, wherein said first device and said trusted third party verify each other's identity by exchanging encryption keys and comparing a S received key with a stored key.
20. A method according to Claim 17 0118, wherein said trusted third party and said second device co-operate to verify each other's identity.
21. A method according to Claim 20, wherein said trusted third party and said second device verify each other's identity by exchanging encryption keys and comparing a received key with a stored key.
22. A method according to any preceding claim wherein said first hand-holdable data processing device comprises a device with an image capture module, for example a tablet computer or smartphone.
23. A method according to any preceding claim, wherein said second hand-holdable data processing device comprises a wearable computing device, such as a smartwatch.
24. Computer software comprising one or more software modules operable, when executed in an execution environment, to implement the functionality of one or more of the steps of the method of any preceding claim.
25. Computer software according to Claim 24, comprising a first software component installable on a first hand-holdable data processing device, and a second software component installable on a second hand-holdable data processing device.
26. Computer software according to Claim 25, wherein said first software component comprises: a generator module for generating a request for an authentication message, a decoding module for decoding a received coded authentication message; and an inspection module for inspecting a decoded authentication message to determine whether authenticated operation of said first device should be provided.
27. Computer software according to Claim 25 or 26, wherein said second software component comprises: a generator module for generating a coded authentication message in reply to a received request for an authentication message, and a communications module operable to communicate said coded authentication message to said first device.
28. A wearable computing device, such as a smartwatch, including a second software component having the features specified in Claim 27 installed thereon.
29. A hand-holdable data processing device, such as a smartphone, including a first software component having the features specified in Claim 26 installed thereon.
30. A system for providing authenticated operation of a first hand-holdable data processing device, the system comprising: (i) a first generator module operable to control the first device to generate a request for an authentication message, (U) a communications module for sending said request to a second hand-holdable data processing device, (iU) a second generator module operable to generate a coded authentication message in reply to said received request, (iv) a second communications module for communicating the coded authentication message to said first device, (v) a module for receiving said coded authentication message at said first device; (vi) a decoding module for decoding said received authentication message, and (vii) an inspection module operable to inspect said decoded authentication message to determine whether authenticated operation of said first device should be provided