WO2015124798A2

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

Info

Publication number: WO2015124798A2
Application number: PCT/EP2015/053848
Authority: WO
Inventors: Anastasios CHRYSOVOULOS; Alexander Laurie
Original assignee: Mobbu Ltd
Priority date: 2014-02-24
Filing date: 2015-02-24
Publication date: 2015-08-27
Also published as: GB2525472A; GB2523430A; GB201403217D0; GB201419290D0; GB201503065D0; WO2015124798A3

Abstract

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.. Computer software and a system are also disclosed.

Description

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 user to 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.

Whilst 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 OTP 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, (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.

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 (ii) 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, (iii) 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 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 1 1 , of which there may be several, is a second software module of a two-module authentication software product. This second software module 1 1 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 1 1 also cooperates with the functional core 1 1 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 1 1 installed on the smartwatch 3.

The second software module 1 1 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 Bluetooth™ 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 SHA256, 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 AES256 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 Code™ (Quick Response Code) encoding module 35 that is operable to convert cryptographic keys generated by the key generator 31 into QR Code™ binary representations of those keys, and a message communication module 37 that renders the generated QR Code™ 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 QR Code™ 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 QR Code™ representations (each corresponding to a said key). It is also envisaged that coding schema other than QR Code™ 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 Blackberry™ 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 cooperates with the short-range transceiver 17 to enable communications via a short-range communications link (in this example, a Bluetooth™ 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 AES256 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 Code™ (Quick Response Code) decoding module 49 that is operable to convert QR 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 Bluetooth™ 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 smartwatch 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 Code™ and then displaying the QR Code™ 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 Code™, 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 smartphone/smartwatch 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 Bluetooth™ 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 Code™ 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 (SHA256) 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 QR Code™. The main application 23 then cooperates with the message communication module 37 in step 61 to display the following message as a QR Code™: SHA256(Time & Serial_No) = #TS

In step 63, the user activates the camera 19 on the smartphone 1 and captures an image of the QR Code™ 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 65 to decode the QR Code™ and retrieve #TS.

Once #TS has been retrieved the main application 39 then generates a provisioning message (PM) consisting of an application identifier (APPJD), and an application token (APP_TOK):

PM = [APPJD, 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-10000) as an encryption key, and thereby produce a cipher (PM-CIPHER) of the provisioning message (PM):

AES256_ENCRYPT( #TS-10000, 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

Bluetooth™ 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:

AES256_DECRYPT(#TS-10000, PM_CIPHER) = PM Next, in step 75, the main application 23 determines whether the PM-CIPHER message has been successfully decrypted using the #TS-10000 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 APPJD.

Next, in step 79, the main application 23 generates a provisioning response message (PRM) that contains an identifier for the second software module 1 1 (RBJD), and an application token (RB_APP_TOK), thus: PRM = [RBJD, 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

Bluetooth™ 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:

AES256_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_TOK 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 APPJD, APP_TOKEN, RBJD 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 APPJD.

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 = [APPJD, AC] and then co-operates with the communications module 41 , in step 93, to send the RAM to the smartwatch via the Bluetooth™ 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 Code™ displayed by the smartwatch.

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 APPJD at the start of the RAM.

If the smartwatch main application 23 has a stored record of the APPJD 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 APPJD 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 cooperates with the key generator to generate a COUNT-1 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-1 , #RB_APP_TOKEN)

The smartwatch main application 23 then co-operates with the encoding module 35 in step 107 to encode the AM as a QR Code™ (thereby generating a coded authentication message), and with the message communication module 37 to display the QR Code™ on the display 7.

The operator then controls the smartphone to capture an image of the displayed QR Code™ in step 109, whereupon the main application 39 of the smartphone cooperates with the QR decoder module 49 in step 1 1 1 to decode the captured QR Code™ image and thereby reveal the authentication message AM.

In step 1 13 the main application 39 co-operates with the key generator 45 to generate the #TS_C0UNT-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 1 15, 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 QR Code™ generated by the smartwatch that has previously been paired with the smartphone, and determines, in step 1 17, that the user has been correctly authenticated. The main application then sends, in step 1 19, 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 1 15, 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 the devices has an application that requires authentication. Advantageously, the process functions without a remote back-end system, without the user knowing what the AM is, and without the user (or another) being able to read the AM. 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, #TS_SALT. This arrangement would protect against situations where an attacker has sniffed #TS, as that attacker would not know #TS_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_AP P_TO KE N .

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.

One envisaged application of this arrangement relates to the enhancement of data storage security on hand-holdable portable data processing devices, such as smartphones.

Some currently available mobile applications and mobile operating systems are (or can be) configured to encrypt data stored on a smartphone using standard well known cryptography. However, irrespective of whether symmetric or asymmetric cryptography is used, the encryption keys used for data encryption need to be stored somewhere in order for the application or operating system to decrypt the data at a later point in time.

Some illustrative applications and operating systems encrypt data and then store the key(s) in an unprotected key store on the same device. Such an arrangement provides the possibility that an intruder who breaches the device can retrieve the key(s) and then decrypt the data. In such an arrangement, an attacker who takes or otherwise compromises the mobile device will have both the data and the keys required to decrypt that data.

To reduce the likelihood of such an attack being successful, it has previously been proposed to provide dedicated hardware which provides tamper-resistant data stores on certain mobile devices. A good example of such technology is the TrustZone™ technology offered by ARM™ (a UK Company having a place of business at: 1 10 Fulbourn Road, Cambridge CB1 9NJ, United Kingdom) that is currently implemented on several of their chipsets. This and other similar types of technology are used by a few device manufacturers, operating system vendors and application developers. However, the process for gaining access to such stores is still quite cumbersome and not readily available to all application developers.

Even with such hardware available, it is nevertheless the case that storing encryption keys on a device along with data encrypted with those keys is a potentially problematic arrangement. A better arrangement would be to store the encryption keys and encrypted data in different devices. With such an arrangement, if one device is compromised or stolen, the attacker only has access to one of the encrypted data or the encryption keys that enable it to be encrypted. If these keys are sufficiently strong, the time required to perform a brute force attack on the encrypted data would be unlikely to be realistic using currently available computing technology.

To implement such an arrangement, in one application of the teachings of the invention it is envisaged to authenticate two portable hand-holdable data processing devices (for example by means of the above described process), and then in a post- authentication step, to transfer encryption key(s) from one device for storage in the other.

For example, once a smartwatch and smartphone have been paired, the smartphone application instigating the authentication process may be configured to transfer an encryption key or keys to the smartwatch for storage therein (for example in memory that forms part of functional core 5). Subsequently, the smartphone may transmit a request for that key to the smartwatch with which it has been paired. In response to that request the smartwatch may then transmit the key to the smartphone for use in decrypting data stored on the smartphone.

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, AppJD, 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 1 1 receives the provisioning request message and extracts the application ID AppJD in step 131 , and then generates - in step 133 - its own public/private key pair [WKey, WKey_Pub] for the application ID, AppJD, included in the provisioning request message. The second software module 1 1 then encodes its public key \NKey_Pub as - in this illustrative example - a QR Code™ in step 135, and controls the display 7 - in step 137 - to display that QR Code™ 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 Code™, following which the first software module decodes the captured QR Code™ to reveal the second device's public key \NPub_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.

This action, which takes place with both the symmetric and asymmetric methods of provisioning, is quite unique. By making the user bring the two devices together in order to take a photo of one device's screen using the other's camera, the user establishes trust between the two devices through a non-digital communication channel, and thus it is reasonable to provision without a backend system or PKI infrastructure. In effect, the user is self-signing or self-authenticating the fact that they know these two devices are theirs.

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, AppJD, that has been encrypted with the public key of the second device \NKey_Pub, and signs the message with the first device's private key PKey. In step 145, the first software module sends the request for an authentication message to the second device over the Bluetooth™ link between them.

In step 147, the second software module 1 1 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 AppJD using the second device's private key WKey in step 151 .

Next, in step 153, the second device 3 generates an authentication message by encrypting the application identifier AppJD with the public key of the first device PKey_Pub, and signs the message using its private key W ey. The second software module 1 1 then encodes the message as a QR Code™ 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 Code™ displayed on the display 7 of the second device 3. The first software mode 21 then decodes that QR Code™ in step 161 , and authenticates - in step 163 - the digital signature of the message using the second device's public key \NKey_Pub. The first software module 21 then decrypts the application identifier AppJD using the first device's private key PKey in step 165.

If the first software module is able to decrypt the decoded QR Code™, the digital signature is verified and the AppJD 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 Bluetooth™ channel between the two devices - a secure key [NS ey} 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 NS ey 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 AppJD using the retrieved NS ey. The main application then sends this message to the second device via the Bluetooth™ 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 NS ey in 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 AppJD with its own stored version of the AppJD.

The second device then generates an authentication message by encrypting its stored version of the application identifier ID using its stored negotiated key NS ey in step 183, and encodes that message in step 185 as a QR Code™ The second device then controls its display to display the QR Code™ in step 187,

The first device activates the camera 19 and prompts the user to capture an image of the QR Code™ 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 in step 193 using its own stored version of the negotiated key NS ey. Once successfully decrypted the first device may signal the application that authentication was successful. In another implementation, the first device may compare the AppJD decrypted from the decoded message with its own stored version of the AppJD 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 better. 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 Bluetooth™ 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.

For example, in circumstances where one device is configured to store a unique user identifier (such as an asymmetric key or certificate, for example) on the other device, it will be apparent that such an identifier may have meaning not only to an application stored on the other device, but in a wider security context outside of the two devices the user owns. For example, a user may use the stored unique user identifier (such as a public key or certificate) to authenticate against a corporate network, create a VPN tunnel or to access information through a gateway or portal. Each of these scenarios would require the user to have some form of unique user identifier, which could be achieved through the implementation of a so-called Public Key Infrastructure (PKI) system.

The teachings of the invention may also be employed as part of a process where content created on one device (for example, the smartphone) can be verified as originating from a user of that device - effectively implementing a mechanism whereby a user can sign content created using their device.

In such an arrangement a user who wants to sign a document, for example, on their device or on a device they do not own, can use a unique user identifier (such as public and private keys or a certificate) stored on their other device (for example, a wearable device) or on a device they do own to sign that document.

This functionality could be implemented by third party developers with just the key storage functionality described above (where a user's unique identifier (for example, encryption keys or a certificate) is stored on one device and data encrypted by that identifier is stored on the other device). However, it would be easier and more secure to provide signing and PKI functionality (for example) as part of the processes and systems described herein. As with the above mentioned key storage implementation, where a function for key or data transfer may be called after a pair of devices have been authenticated, a "sign" or "verify" function may now be called that handles this mechanism for third party developers.

Illustrative ways of implementing this functionality will now be described, but persons skilled in the art will no doubt appreciate that the step of obtaining an identifier such as public/private key pairs from third party PKI systems may need to be designed at a custom level, as such functionality will more than likely be PKI implementation specific. This notwithstanding, there are in general two high-level approaches that could be taken.

Firstly, one device (for example the smartwatch) could be configured to create and store (for example in memory that forms part of functional core 5) its user's private key and share their public key with an external PKI system. This implementation is highly secure as only the watch will have ever seen the user's private key. Alternatively, a third party PKI system may generate the user's public/private key pair, the user may then receive or photograph the key, and then the user may send it to the watch for safe keeping. This implementation is less secure as several parties have now seen the user's private key, but is nonetheless practical for existing PKI systems where the user's identity has already been established and may be hard to update or exchange. In one envisaged implementation, a user presented with a document to sign on their smartphone would hash the document to produce a checksum - in effect a digital signature uniquely identifying that document. The smartphone then passes the checksum to the wearable device, for example over the Bluetooth™ or other short-range wireless communications link. The wearable device receives the checksum and computes a signature of the hash using the user's private key. The wearable device then generates an image (for example, a QR Code™) of the signature on the device's screen. The user then operates the smartphone to capture an image of the signature, whereupon the smartphone decodes the image and passes the signed checksum back to the application associated with the document that is to be signed. That application can now associate a signed checksum with the document, which checksum is not only unique to the document in question but also to the user, thereby enabling the user's identy to be be verified at a later date using the users public key (which is available to the public at large).

It is also envisaged that one device, for example the smartwatch, may be configured to store (for example in memory that forms part of functional core 5) user identifiers (such as public keys or certificates) belonging to third parties. In this way, digitally signed material sent to the other device (for example the smartphone) by someone purporting to be a user whose identifier is stored in the smartwatch may be verified as actually originating from that user by retrieving that person's identifier from the smartwatch, and attempting to verify the digital signature.

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. 1 12, 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. 1 12, par. 6.

Claims

1 . 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 (iii)

1 1 . 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 1 1 , 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 (ii) 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 received key with a stored key.

20. A method according to Claim 17 or 18, 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,

(ii) a communications module for sending said request to a second hand-holdable data processing device,

(iii) 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;

31 . A method for provisioning each of a first and a second hand-holdable data processing device with a stack of encryption keys, wherein each device includes a respective copy of the same encryption algorithm, the method comprising:

(i) sharing a secret between the first and second hold-data processing devices; (ii) operating the first hand-holdable data processing device to generate a stack of keys from said shared secret using the copy of the encryption algorithm stored in said first hand-holdable data processing device; and

(iii) operating the second hand-holdable data processing device to generate a stack of keys from said shared secret using the copy of the encryption algorithm stored in said second hand-holdable data processing device.

32. A method according to Claim 31 , comprising operating one of said first and second hand-holdable data processing devices to generate a secret for sharing with the other of said first and second hand-holdable data processing devices in step (i).

33. A method according to Claim 32, wherein said secret is encoded prior to being shared in step (i).

34. A method according to Claim 33, wherein said secret is encoded so as to be machine readable and unintelligible to a user of said first or second devices prior to being shared in step (i).

35. A method according to Claim 34, wherein said encoded secret is shared by means of a visual communications link.

36. A method according to Claim 35, wherein step (i) comprises displaying said encoded secret on a screen of one of said first and second devices, and operating image capture apparatus of the other of the first and second devices to capture an image of said encoded secret.

37. A method according to Claim 36, comprising the step of decoding the encoded secret.

38. A method according to any of Claims 31 to 37, comprising the steps of: operating the first hand-holdable data processing device to generate a token, encrypting the token using a key from said stack, and transmitting the token to the second data processing device for decryption.

39 A method according to Claim 38, wherein said first hand-holdable data processing device is configured to encrypt the decrypted token from the second hand- holdable data processing device, to store the encrypted token, and to discard the decrypted token.

40. A method according to any of Claims 31 to 39, comprising the steps of: operating the secpnd hand-holdable data processing device to generate a token, encrypting the token using a key from said stack, and transmitting the token to the first data processing device for decryption.

41 . A method according to Claim 40, wherein said second hand-holdable data processing device is configured to encrypt the decrypted token from the first hand- holdable data processing device, to store the encrypted token, and to discard the decrypted token.

42. A method according to any of Claims 1 to 23, comprising the steps of transferring a data encryption key used to encrypt data on one of said first and second hand- holdable data processing devices to the other of said first and second data processing devices for storage,, and deleting said data encryption key from the data processing device from which the encryption key was transferred.

43. A method according to any of Claims 1 to 23 and 42, comprising the step of storing a unique user identifier on said second data processing device.

44. A method according to Claim 38, comprising the step of utilising the unique user identifier stored on said second data processing device to digitally sign data on said first data processing device.

45. A method according to any of Claims 1 to 23 or 42 to 44, comprising the step of storing a unique user identifier that is associated with another user on said second data- processing device.

46. A method according to Claim 45, comprising the step of utilising the unique user identifier on said second data processing device to verify signed data sent to said first data processing device.

47. A system comprising a data-processing device and a smartphone, wherein the data-processing device and the smartphone each include a respective part of a two-part authentication system operable to authenticate the data-processing device to the smartphone and the smartphone to the data-processing device, wherein the data- processing device further comprises an encryption key store for storing encryption keys previously used to encrypt data on said smartphone and subsequently deleted from said smartphone following storage in said key store, said smartphone and data-processing device including respective parts of a communication system that enables encryption keys to be transferred from said smartphone to said data-processing device and keys to be retrieved from said key store by said smartphone as required to enable the decryption of data stored on said smartphone that has previously been encrypted with at least one said retrieved key.

48. A system comprising a data-processing device and a smartphone, wherein the data-processing device and the smartphone each include a respective part of a two-part authentication system operable to authenticate the data-processing device to the smartphone and the smartphone to the data-processing device, wherein the data- processing device further comprises storage for storing a unique user identifer, said smartphone and data-processing device including respective parts of a communication system that enables the unique user identifier stored on said second data processing device to be utilised for digitally signing data on said smartphone.

49. A system according to Claim 47 or 48, wherein said data-processing device comprises a wearable data-processing device, such as a smartwatch.