HK1208546B - Method and system for verifying an access request - Google Patents

Description

Method and system for authenticating access requests

Technical Field

The present invention relates to a method and system for authenticating access requests and is particularly, but not exclusively, suitable for authenticating requests for accessing data, services or assets.

Background

There is an increasing need to access confidential or user-specific data (or assets or services). For example, providing access to bank accounts and allowing transfers from the accounts should be limited to authorized users, e.g., account holders. Typically, a user is authenticated when access to data is requested by a credential identifying the person requesting access to the data. Remote access of data poses a particular problem because the individual requesting the data, asset or service is typically located in a different physical location than the location of the party responding to the request. As a result, it is very difficult for the party serving the request to know whether the entity making the request is a) a party of its own, b) has access to the device from which the request originates, and c) possesses the device from which the request originates.

Typically, when an account is established between an individual and a party (e.g., a data provider), the individual establishes the credentials described above for use by the data provider in identifying and authenticating the individual for future requests. Such credentials may include information that uniquely identifies the individual (e.g., Personally Identifiable Information (PII)) and a key (e.g., password) for verifying the identity of the individual. It is also now common for data providers to require individuals to register themselves as owners of devices used to access data. The association registered between the device and the device owner may be used by the data provider as an additional authentication factor. For example, where a data provider receives a request to access an account on behalf of a particular individual from a particular device (which is not a device registered for the individual), the data provider may determine that a request is made for the individual who is believed to be registered for the account.

An individual who wishes to access data of a data provider on behalf of another individual who has an account with the data provider can obtain his user credentials (i.e., PII, user ID, and password) relatively easily by purchasing the credentials from a criminal shadow online marketplace, and then fraudulently access the data of the other individual. In addition, devices can be accessed and controlled remotely, requesting data on behalf of registered owners of those devices. In general, it cannot be determined whether a request is made by a user who physically possesses the device or whether a request is made remotely by a user who remotely controls the device making the request using another device.

One-time passwords (OTP) are commonly used to reduce these problems: the authentication server uniquely assigns an OTP generation key to the registered owner of the device, the OTP generation key being used to generate and verify the OTP. The authentication server typically holds hundreds or thousands of OTP generation keys, each uniquely assigned to or registered for a different person. The authentication server configures the OTP token at times when the OTP generation key is taken up by the registered owner through its allocation. For example, the OTP tokens may use the OTP generation key to generate a different password each time the enrolled user requests a new password, or, as another example, may use the OTP generation key to generate a new password over a fixed time interval. The OTP token may additionally use an indication of the current world to generate an OTP to prevent storage and playback of the OTP at a later time.

To access the user-restricted data through the device, the user provides the OTP generated by the OTP token and credentials uniquely identifying the owner of the device to the data provider. Typically, the data provider then identifies the owner of the device and passes the received OTP to the authentication server. The authentication server looks at the OTP generation key associated with the identified person and uses this key and, if required, the current time to determine whether the received OTP corresponds to an OTP generated by an OTP token, which the owner of the device holds at the current time or at least for a predetermined period of the current time. The authentication server then indicates to the data provider whether the received OTP is valid. If the correct OTP is sent to the data provider, it can be determined that the user of the device possesses the OTP token. However, the authentication server is easily compromised, facilitating unauthorized distribution to other entities, and allowing (illegitimate) access to anyone who generates the key for the distributed OTP to access the data on behalf of the person associated with the key.

Disclosure of Invention

According to a first aspect of the present invention there is provided a system for verifying a request to access data, the system accessing a computing device configured to communicate with a first trusted indicator of time, the system comprising: a first module to access a second trusted indicator of time; and a second module having access to an untrusted indicator of time, wherein the first module is arranged to generate a password using at least the second trusted indicator of time; the second module is configured to: receiving a password associated with the request to access the data, the received password being verified using at least the untrusted indicator of time; and cause transmission of a message to the computing device, the message comprising data representing an untrusted indicator of time for verifying the received password, and the system being arranged to cause the computing device to generate data representing a comparison between the untrusted indicator of time and the first trusted indicator of time, wherein the generated data is for providing said access to the data.

In some cases, the second module may not have access to a trusted time indicator (no communication with external elements). Thus, modifying the untrusted time, the system can be opened to attack. The password is verified by using an untrusted indicator of time and then a message is caused to be transmitted to the computing device, wherein the untrusted time is compared to the trusted time to avoid the possibility of an attack. Furthermore, the amount of signalling for authentication is reduced, since only one message needs to be sent from the second module to the computing device or system.

In one embodiment, the system is arranged to cause the computing device to selectively provide the system with said access to the data based on the generated data. In this embodiment, the computing device facilitates access to the requested data.

Advantageously, the message transmitted to the computing device may comprise data representative of a verification of the received password by the second module using at least the untrusted indicator of time.

In one arrangement, the first module and the second module share a key uniquely assigned thereto, the first module being arranged to use the key to generate a password, and the second module being arranged to use the key to verify the received password. The shared secret may be stored within a secure component of the first module. Alternatively or additionally, the key may be stored within a secure component of the second module. In other embodiments, the first and second modules do not share a key for generating and verifying the password.

In one arrangement, the first module comprises tamper-proof hardware comprising a clock arranged to provide a second trusted indicator of time.

In some arrangements, the second module may be communicatively connected to a device having a clock arranged to provide an untrusted indicator of time.

Advantageously, in one arrangement, the system may be arranged to cause the computing device to transmit a message including the generated data to another computing device, thereby providing the system with said access to the data, and the other computing device may be arranged to provide said access to the data upon receipt of the generated data.

Alternatively, in an arrangement in which the requested data is stored at or generated by the computing device, the system may be arranged to cause the computing device to provide said access to the data based on the generated data.

In some arrangements, the first module may be arranged to receive a challenge code (challenge code) generated by the second module or computing device via an interface of the first module and generate a password using at least the challenge code.

In some arrangements, the first module may be arranged to generate a plurality of passwords, at least one of the plurality of passwords being different from another of the plurality of passwords, and to provide at least one of the generated passwords to the user through the interface of the first module.

Advantageously, the second module and the computing device may share another key for use in communications therebetween.

In one arrangement, the second module may be arranged to store the received password and to compare the received password with any previously stored received password, thereby to verify the received password.

In an alternative embodiment of the invention, the second module may be arranged to receive the generated data from the computing device and to use the received data to provide said access to the data. This embodiment may be contrasted with an embodiment in which the computing device is arranged to provide the system with said access to data based on the generated data, because, in this embodiment, the second module (rather than the computing device) facilitates access to the requested data.

In some arrangements, the first module and the second module may be communicatively disconnected. This has the advantage that the password generated by the first module cannot be accessed remotely through the second module. Therefore, in order for the user to be able to correctly enter the password generated by the first module into the second module, the user must possess the first module. In this arrangement, therefore, it can be determined whether the user possesses the first module. This may be advantageous, for example, to determine whether the user of the first module is an individual user.

In some arrangements, the data received from the computing device includes data representing whether the untrusted indicator of time is within a predetermined range of the first trusted indicator of time.

In some arrangements, the requested data may be maintained by a second module, and the second module may be configured to use the data received from the computing device to determine whether to provide access to the requested data.

The second trusted indicator of time may be a clock of the first module and the first trusted indicator of time may be a clock synchronized with the clock of the first module.

Advantageously, the computing device and the second module may be pre-configured with an encryption key for signing data sent therebetween, and the second module may be arranged to sign the message for transmission to the computing device and to verify that the computing device signed the data received from the computing device using the encryption key.

In some arrangements, the second module may be arranged to store the received password and to compare the received password with any previously stored received password, thereby to verify the received password.

According to a second aspect of the present invention there is provided a method of verifying a request for access to data by a system using a computing device, the computing device being arranged to communicate with a first trusted indicator of time, the method comprising: generating a password at the first module using at least the second trusted indicator of time; receiving a password associated with a request to access data; verifying the received password at the second module using at least the untrusted indicator of time; and causing transmission of a message to the computing device, the message including data representing an untrusted indicator of time for verifying the received password; wherein the system causes the computing device to generate data representing a comparison between an untrusted indicator of time and a first trusted indicator of time, wherein the generated data is used to provide the access to the data, and wherein the system comprises a first module and a second module.

Further features and advantages of the invention will become apparent from the following description of preferred embodiments of the invention, which is provided by way of example only with reference to the accompanying drawings.

Drawings

FIG. 1 shows a block diagram of a system according to an embodiment of the invention;

FIG. 2 schematically illustrates a method according to an embodiment of the invention; and

fig. 3 schematically shows a method according to a further embodiment of the invention.

Detailed Description

Embodiments of the present invention relate to determining whether requested data, assets or services can be accessed. FIG. 1 shows a block diagram of a system 10 according to an embodiment of the invention. The system 10 includes a first module 20 and a second module 30. The first module 20 is arranged to generate a password and the second module 30 is arranged to receive the password from a user of the system 10 and to verify the interpreted password. Represented by dashed line 15, in the embodiment shown in fig. 1, first module 20 is communicatively disconnected from second module 30. In other words, the system 10 is constructed and arranged such that there is no way of communicating between the two modules 20 and 30 (other than by an individual user). In a particular embodiment, modules 20 and 30 that are physically disconnected from each other prevent communication between the two modules 20 and 30. However, it is to be understood that the two modules 20 and 30 may be physically connected (i.e., integrated) while communicatively disconnected, for example, if the two modules do not share any common circuit or system interface or include any other way of exchanging information with one another.

In an alternative embodiment, the first and second modules 20, 30 may be communicatively disconnected.

The first module 20 comprises an interface 21 which may be a user interface. The interface 21 may comprise at least one input and/or output. For example, the input of the user interface of the device may be a button, keyboard, keypad, mouse, touch screen, microphone, or any other element that allows a user to provide input to the device. For example, the output of the user interface of the device may be a screen, a speaker, a braille encoder, or any other element capable of outputting information from the device to the user of the interface 21.

The first module 20 may also include a safety component 22. As described in more detail below, in some embodiments, the security component 22 may store keys assigned to the first and second modules. The security component 22 may also include a clock 23 capable of providing a trusted indicator of time (hereinafter also referred to as a "second trusted indicator of time"). The safety member 22 may be tamper proof; that is, the security component 22 may be configured to disable the alteration of the second trusted indicator of time, and thus, trust the second trusted indicator of time. Likewise, tamper-proof means that the stored key cannot be read, and therefore, using this key, there is no need to cooperate with the first module 20.

The second module 30 is shown as part of the device 35. The apparatus 35 may comprise an interface 31, which may be a user interface, which may comprise any or all of the features described above in relation to the interface 21. Further, the apparatus includes a clock capable of providing an indication of time. The second module 30 is able to communicate with the interface 31 and the clock 33 of the device and likewise with the user, in particular in order to receive a password provided by the user and to be able to access the time indication from the clock 33.

The second module 30 may itself contain a security component 32. As with the security component 22, in some embodiments, the security component 32 may store keys assigned to the first and second modules. In some embodiments, the second module and/or the safety component 32 may be removed from the device 35. Since the clock 33 of the device 35 is not part of the security component 32, the time indicator provided by the clock 33 is not trusted, since it can be changed by the user or by another party (e.g. a remote opponent).

The second module is communicatively connected to at least one other computing device or system, e.g., one or both computing devices 50 and 60. Such a computing device may be a server connected to the device 35 over a network. Alternatively, the computing device may be another form of computer, such as a desktop computer, for example, connected to the device 35 by the connection devices 51 and 61. The computing device may be a distributed system, i.e., a cloud computing system or similar system. Computing devices 50 and 60 may be connected by a connection device 52. As described in more detail below, the computing device 50 also includes a clock 53 that is capable of providing a first trusted indicator of time. The second module 30 may be paired with the computing device 50. For example, the second module 30 may be paired with the computing device 50 during a configuration process that assigns an encryption key to the second module 30 and the computing device 50 for secure communication therebetween.

As described above, in the present embodiment, the first and second modules are communicatively disconnected. Thus, during use, the interface 21 of the first module 20 is configured to provide the generated password to the user, shown as block 40, and the interface 31 accessible to the second module 30 is configured to receive the password from the user 40.

In some embodiments, the first module 20 and the second module 30 may be separate devices that may be collectively configured to determine whether a request to access data may originate from a user physically occupying the second module 30. As an example, the two modules 20 and 30 may be manufactured and sold together and in the possession of a particular user. In one example, the device 35 may be a communication device, such as a mobile phone or a bank card reader. Also, the second module may be a SIM card or a bank card that can be inserted into the device 35. In alternative embodiments, the first and second modules 20 and 30 may be elements of a single device.

The second module 30 can operate under the control of a user in possession of the second module 30 through the interface 31 of the device 35. However, the second module 30 may also operate under the control of a remote entity having a communication link with the second module 30. In this embodiment, since the first module 20 is communicatively disconnected from the second module 30, as described in more detail below, it cannot be controlled through the interface 31 of the second module 30 or by a telecommunication link.

The device 35 may store confidential data associated with a particular person. As a particular example, the second module 30 may store a user-limited encryption key for decrypting data. Additionally or alternatively, the second module 30 may provide or facilitate access to confidential data stored externally by a third party (e.g., on one or both of the computing devices 50 and 60). In the latter case, if it is determined that the data is provided to a particular person, i.e., the person physically occupying the first and second modules 20 and 30 (in other words, the data may be user-limited data), the third party may only allow access to the data. The third party may require the owner of the device to register an association between the device and the owner before the third party agrees to access the user-restricted data through the particular device. In this case, the third party may then only send data intended for receipt by a particular person to the device associated with that person. In a further embodiment, if the guidance to do so is received by the second module 30, the third party may take action, e.g. access confidential information and/or payment data, and send it to the fourth party. For example, computing device 50 may send the confidential information to computing device 60. Also, in this example, second module 30 may have a registered association with a particular person, and thus, second module 30 may be used to determine that this particular person (i.e., account holder) makes the request.

Where the second module 30 comprises a communications module, it will be appreciated that an unauthorized individual may connect with the second module 30 and remotely control the second module 30 to send a request to a third party. If the second module 30 can determine whether a request to access data is made by a user in possession of the second module 30 or a user remote from the second module 30, then appropriate reactive action can be taken, for example, disabling further use of the second module 30 upon determining that a request is made by a remote user.

Now, it is to be explained that embodiments provide a way to perform such a determination. The first module 20 includes circuitry and/or software that is constructed and arranged to generate a password based on the trusted indicator of time of the clock 23 (i.e., the second trusted indicator of time described above). This circuitry and/or software may be at least partially contained within the security component 23.

As described above, in one embodiment, the first and second modules 20, 30 may be configured with a shared key for generating and verifying passwords. In this embodiment, the first module 20 may be arranged to generate the password also based on the shared key. In one embodiment, the key may be uniquely assigned to the first and second modules 20, 30.

The key assigned to the first and second modules 20, 30 may be an OTP generation key, and thus, the key generated by the first module 20 is a one-time password (OTP). In this embodiment, the subsequent password generated by the first module 20 is different from the previously generated password, and each generated key is valid for only one authentication attempt. In one particular arrangement, the generated OTP is time dependent and valid for a predetermined period of time. In an alternative arrangement, the first module 20 may generate the password from the pre-generated password and the second trusted indicator of time using the OTP generation key.

The OTP is generated by the first module 20 based on the OTP generation key (i.e. the key) and the second trusted time indicator provided by the clock 23 of the first module 20. The OTP may be a cryptographic function of the OTP generation key and the current time. In the case where the first module 20 and the second module 30 are composite components of a single device, in addition, the OTP may be generated from a device ID uniquely associated with the device. Such a device ID may be, for example, a hash of the CPU IDA function, a hash function of the GPU ID of the device, or a combination thereof. In this case, the OTP may be a cryptographic function of the OTP generation key, the device ID and the second trusted time indicator. The value of the second trusted time indicator is referred to herein as the "generation time" T_GAnd it will be understood that the measurement is made relative to the clock 23 of the first module 20. In this case, if used to generate the time T_GThen the particular generated OTP may be used only to authenticate a request for access to the data. In this case, if the time T is_RUAt a generation time T located for generating a password at the first module 20_GWithin a predetermined time period before or after, the generated OTP can then be verified, where T is due to a time drift between the two time indicators_RUCan be located at T_GBefore.

It is to be understood that despite this name, the possibility that the OTP can be reused is low, but limited. However, the possibility that the previously generated password is valid at a later time is effectively the same as the possibility that the random password runs, again for the purposes of this document it is assumed that the prescribed password is valid only once during the lifetime of the module, and thus the password is an OTP. Furthermore, if the OTP is used twice within a predetermined time period of validity, the OTP is rejected, which prevents the password from being reused.

The second module 30 also includes circuitry and/or software that is structured and configured to determine whether the key received from the user 40 of the second module 30 matches the password generated by the first module 20 at the time indicated by the untrusted indicator of time of the clock 33 based on the untrusted indicator of time of the clock 33 (and optionally also based on the shared key if the second module 30 is so configured). Also, at least a portion of the circuitry and/or software may be contained within the security component 32.

In the particular embodiment shown in fig. 1, the keys are uniquely assigned to the first and second modules 20 and 30. In other words, the key may be associated with only the first and second modules 20 and 30. However, this is not an essential requirement. In an embodiment, the security components 22 and 32 of the first and second modules 20 and 30 are tamper proof, i.e. the keys and algorithms used to generate the passwords stored within the security components 22 and 32 cannot be changed.

As mentioned above, the password generated by the first device 20 is generated using a suitable algorithm and time indication, and is therefore an OTP. The time indication, i.e. the above-mentioned second trusted time indicator, may be, for example, an integer, wherein a positive number is increased by a predetermined frequency, e.g. every 30 seconds or every minute. The integer may have a value of zero corresponding to a known point in time in the past and may be set such that the integer does not roll over, i.e. does not reach the maximum value of the register storing the integer, returning to zero, during the lifetime of the device. This ensures that the second trusted time indicator has a unique value that is never repeated, and therefore any password generated using the second trusted indicator is not repeated. Notwithstanding the foregoing, it is clear that any other trusted time indicator may be used instead. A clock contained within the secure element 23 may generate a second trusted indicator of time.

Fig. 2 schematically illustrates an exemplary method according to an embodiment of the present invention. In this approach, the user 40 makes a request to access data, represented by arrow 74. The request to access the data may be, for example, a request to access a restricted web page, a request to access confidential information, or a request to access data to enable access to a service. The request may be made on the device 35, and thus, through the second module 30, the user may make a request to either of the computing devices 50 and 60. In general, the data that the user 40 wishes to access may be data stored on or generated by any element of the system 10, or may be data stored at or generated by an entity (e.g., an external database or server) located outside of the system 10. The data that the user 35 of the second module 30 wishes to access may be, for example, a restricted web page hosted on a server located outside the system 10, and in such a case, sending the data to the server of the second module 30 may allow access to the web page. The information contained within the data transmitted by the second module 30 is explained in more detail below.

In response to the request to access data in step 74, the second module 30 prompts the user 40 to enter a password generated by the first module 20 in step 76. Then, in step 78, the user may cause the first module 20 to generate a password, for example, by pressing a button of the interface 21 of the first module, or otherwise indicating to the first module 20 that a password is required.

In step 80, the first module 20 uses the keys uniquely assigned to the first and second modules 20 and 30 and the second trusted indication of time provided by the clock 33 to generate a password which is then provided to the user 40 in step 82. For example, the generated password may be a series of numbers, a series of letters, a combination of letters, numbers, and other characters or images, and may be presented to the user 40, for example, on a screen of the interface 21.

Alternatively, the first module 20 may generate the password (from the shared key and the second trusted indicator of time) at fixed time intervals and may automatically present the most recently generated password on the interface 21 of the first module 20. In this case, step 78 is not required since the first module 20 presents the password without a request.

In either case, the user 40 may then provide the password generated by the first module 20 to the second module 30 in step 84. The user enters the password into the interface 31 of the device 35, through which the password is supplied to the second module 30, and may do so. In step 86, the second module 30 then verifies whether the password received from the user 40 is the same as the password generated by the first module 20, using the keys uniquely assigned to the first and second modules 20 and 30 and the untrusted indicator of time of the clock 33 of the device 35.

It will be appreciated that when a password generated by the first module 20 is entered into the second module 30, the password must be retrieved from the first module 20 in advance. In this embodiment, when the first module 20 is communicatively disconnected from the second module 30, the user 40 is most likely a person who possesses or at least accesses the first module 20 and the second module 30, and is therefore able to retrieve a password from the first module 20 and manually provide the password to the second module 30.

As described above, each of the first and second modules 20 and 30 may include respective security components 22 and 32 within which keys are stored. The passwords may be uniquely assigned to the first and second modules 20 and 30 and stored within the secure components 22 and 32. In other words, the keys uniquely assigned to the first and second modules 20 and 30 are stored within portions of the first and second modules 20 and 30 that are not accessible to the user (e.g., user 40) and any other party that may likewise grant access to the first and second modules 20 and 30.

In this case, the keys may be provided to the security components 22 and 32 of the first and second modules 20 and 30 at the time of manufacture. In one embodiment, the secure components 22 and 32 are manufactured separately into the other elements of the modules 20 and 30, and thus, any entity located outside the system 10 cannot know the association between the modules 20 and 30 and the keys stored on the secure components 22 and 32. Storing the keys in the secure elements 22 and 32 prevents any user accessing the modules 20 and 30 from finding the keys, thereby addressing the need to enter a password in the second module 30 in order to access the requested data. Any user is also prevented from modifying the algorithm that generates the password, which may therefore cause the first module 20 or the second module 30 to generate a false reaction. For example, the algorithm on the second module may change to accept any inputs that are valid.

A particular advantage of the present invention results from the fact that the key used to generate and verify the password is uniquely assigned to the first and second modules 20 and 30. More specifically, since there is a one-to-one mapping between the key and the module 30 that uses the key to verify the password, and also between the key and the module 30 that uses the key to generate the password, then if the key is compromised, then the modules 20 and 30 need only be reconfigured with the new key (again uniquely assigned to the modules 20 and 30). This may be achieved, for example, by replacing the secure components 22 and 32 of the modules 20 and 30 with new secure components having new keys stored thereon. Alternatively, in the case where the module is a lower cost item, for example, the telephone SIM (second module 30) and the associated password generator module (first module 20), both modules may be replaced.

This may be contrasted with known OTP systems described in the background section, where a specified OTP key is uniquely associated with a particular user (rather than a pair of modules 20 and 30). In this known system, there may be a one-to-many relationship between the OTP key and the means for generating a password using the OTP key. In this case, if the OTP key is compromised, then the data can be accessed on behalf of the user by any means using the OTP key. Since OTP keys are typically stored on multiple OTP tokens and are also sized on the authentication server, establishing a new OTP key can place a considerable burden on the authentication server, since the authentication service needs to re-assign a new OTP generation key to this user and configure a new set of OTP tokens with the new OTP generation key.

At a time within a predetermined time from the time the second module 30 receives the password, the second module 30 uses the untrusted time indicator of the clock 33 and the OTP generation key (i.e., the shared key) to determine whether the password is the same as the password generated by the first module 20. The value of the untrusted indicator of time at which the second module 30 receives the password is referred to herein as the "untrusted receive time" T_RU。

The method used by the second module 30 to verify the received password depends on the method used by the first module 20 to generate the password. Many such methods are known and the specific method is considered to be outside the scope of the present invention.

If at the receiving time T_RUFor a predetermined period of time T_GThe second module 30 determines that the received password matches the OTP generated by the first module 20/originally by the first module, then the second moduleBlock 30 verifies the received password.

However, this password may be generated by the first module 20 at an earlier time and played back to the second module 30. This may occur if the device 35 is compromised and, therefore, a password entered through the interface 31 can be intercepted. As described above, the password is a one-time password (OTP) generated using a time indication. Thus, the time delay between the generation of the password by the first module 20 and the reception by the second module 30 is typically long enough for the OTP to no longer be valid.

However, the second module 30 only has access to untrusted indicators of time. This is typically because the time indicator is provided by the clock 33 of the device 35. Also, for example, the clock may be fairly legally adjusted by tampering with the device 35 by a remote access device, or simply setting the clock 33 by a user preference. This means that the untrusted indicator of time may be adjusted to correspond to the time at which the password was generated by the first module 20, and thus to correspond to the time at which the password was intercepted earlier by the adversary. This in turn may cause the second module to erroneously determine that the replayed password is valid.

The second module 30 may only have access to times that are not trusted, since it is impractical to provide security and therefore trusted times for the second module 32 or its secure components 32. For example, where the security component is a SIM or bank card, power may be removed from the second module 30 and, as such, any clock running on that module may be delayed. This enables the second module 30 to rely on the clock 33 of the untrusted device 35 as described above.

Likewise, once the second module 30 uses the untrusted indicator of time T_RUHaving verified the received password, the second module 30 sends a message to the computing device 50 in step 88. The message contains a time indicator (i.e., an untrusted timestamp T) representing a time for verifying the received password_RU) The data of (1). The message may also contain data representing the verification of the password (using an untrusted time) received by the second module 30.

As described above, the computing device 50 accesses the first trusted indicator of time, e.g., via the clock 53. This clock 53 may be synchronized with the clock 23 of the first module 20. Here, synchronous means that the computing device 50 has access to the time T used at the first module 20 to generate the password_GIs within a predetermined range (allowed to drift between clocks) of a time indicator (T'_G). Moreover, trust may be established between the computing device 50 and the second module 30 by sharing an encryption key used to sign and thereby authenticate messages sent therebetween, as discussed in more detail below.

Upon receiving a message including an untrusted indicator of time, computing device 50 compares the untrusted indicator of time indicated within the received message to a first trusted indicator of time, T ', determined by clock 53 of computing device 50'_G. If an untrusted time T is determined_RUAt a first trusted time T'_GAnd the message indicates that the password received by the second module 30 is valid, then the computing device 50 determines that the user 40 is trusted to access the first and second modules 20 and 30. Accordingly, the computing device 50 may generate data representing this comparison and use the generated data to provide the data access initially requested in step 74.

This is because if the second module 30 uses the timestamp T_RUPositively verifies the received password, then the user 40 must be near T_RUTrust time of T_GThe password generated by the first module 20 is provided. Then, it follows that if T_RUProximity to a trusted time T 'determined by computing device 50'_GThen T_GMust also be near the current time, therefore, it can be determined that T 'is near'_GA certain time T of the current time of the representation, i.e. within a predetermined range of the current time_GThe user 40 must provide the password generated by the first module 20/originally by the first module. Thus, the user 40 may now possess or at least access the first module 20. Since the password generated by the first module 20 is not automatically transmitted to the second module 30In this way, it is highly likely that the person possessing the second module 30 will also possess the first module 20, so that the password generated by the first module 20 can be manually transmitted to the second module 30.

Advantageously, if the computing device 50 determines an untrusted timestamp T_RUIs not at trusted time T'_GAnd thus from a time source that is not synchronized with the clock of the first module 20, then the computing device 50 may deny access to the data.

Thus, as shown at step 92, the computing device 50 may communicate with other components of the system to enable accessing data to use the data generated by the above comparison. For example, computing device 50 may send a message to indicate time T_RWhether it is within a predetermined time frame. If time T_RWithin a predetermined time frame, the second module 30 may then allow access to the requested data. Or, if time T_ROutside of the predetermined time range, the second module may deny access to the requested data.

The user 40 may request access to data maintained outside by the computing device 50. In this case, the computing device 50 may respond by sending the requested data to the second module 30 or by denying access.

Alternatively, in further examples, computing device 50 may allow computing device 60 to access data stored on either or both of computing device 50 or second module 30. In still further examples, successful verification may be used to allow computing device 50 and/or second module 30 to access data on computing device 60.

In the above example, the second module 30 may store the previously received OTP and may invalidate any OTP previously received. Access to the second module 30 is simultaneously by a remote adversary and a user in possession of the first and second modules 20 and 30 (i.e., the local user 40). Assuming that the remote user attempts to access the data by copying the OTP previously entered by the local user 40 into the second module 30, the second module 30 refuses to copy the OTP as a copy. In one arrangement, the second module 30 may store a limited number of previously received OTPs to enable rejection of duplicates. The number of stored copies may be such that if a particular OTP is copied that is no longer stored by the second module 30, then this OTP may be rejected by the third party 100 because it is associated with a timestamp that is outside of the predetermined range of the current time.

Containing an untrusted timestamp T used by the second module 30 for verifying the received password_RUMay be signed by the second module 30 (e.g., using an encryption key associated with the second module 30 and the computing device 50), thereby allowing the computing device 50 to verify the origin of the message. This means that if the remote user attempts to change the message sent by the second module 30 containing an untrusted time, the computing device 50 recognizes that the message was changed because the message did not contain the correct signing of the second module and denies access to the associated requested data. Likewise, the replayed message (i.e. the message previously sent by the second module 30 re-sent to the computing means 50) contains an indicator of time T that was not trusted in the past_RUAnd therefore reject these messages.

Also, if the computing device 50 is configured to send a message to the second module 30 indicating whether the received timestamp is valid, the message may also be signed. This allows the second module 30 to identify messages sent to the second module 30 by a party other than the computing device 50 that may not be trusted.

The above may be contrasted with a system in which the second module 30 retrieves timestamps from a third party. In such a system, the remote user may be able to view the OTP entered by the user 40 in possession of the first and second modules 20 and 30 and may also view the timestamp received from the third party. At some later time, this remote user may provide the observed time stamp and the observed OTP to the second module 30. In this case, the second module 30 may verify the password of the remote user. However, in a system configured in accordance with the above embodiment, where the second module 30 sends a timestamp for authenticating the password to the computing device 50, the computing device 50 can determine that any timestamp is outdated and deny access to the requested data accordingly.

The system configured according to the above embodiment has the following advantages: the second module can take the first step in verifying the provided password without accessing the remote timestamp. This speeds up the time for authentication, since only one message needs to be transmitted for the system as a whole (step 88) to complete authentication. By contrast, a system that provides a trusted timestamp to the second module 30 requires at least two messages, a request for a trusted time, and a response.

Fig. 3 schematically illustrates one exemplary method for sharing a temporary encryption key between a banking service provider, which may be a computing device 50, and the second module 30 as a way of providing data access. In this example, banking service provider 50 has a temporary encryption key shared with another service provider, which may be associated with computing device 60. The encryption key shared with the service provider 60 and the encryption key shared with the second module 30 are used together to authenticate and/or encrypt/decrypt messages sent between the second module 30 and the service provider 60, as discussed in more detail below.

The second module 30 and the banking provider 50 already have a pre-assigned encryption key for encrypting and authenticating messages sent therebetween, as described above. Also, the banking service provider 50 may store an association between the second module 30 and a particular bank account holder.

As described above, the second module 30 does not have a clock synchronized with the clock of the first module 20. However, the banking provider 50 has a clock that is synchronized with the clock of the first module 20 (e.g., both clocks may run according to world time, or the banking provider 50 can obtain a timestamp on the first module 20).

In this particular example, the user 40 requests the temporary encryption key from the banking service provider 50 via the second module 30 and the device 35 in step 96. Upon requesting access to the temporary encryption key, the user 40 may provide information to the second module 30 and/or device 35 identifying the particular bank account holder about which the user 40 wants to obtain the temporary encryption key.

Upon receiving the request for the temporary encryption key (i.e., the request for data), the second module 30 sends a message (step 98) to the banking service provider 50 indicating that the user 40 made the request to access the temporary encryption key and that the modules 20 and 30 are available to generate and verify passwords. This message (sent in step 98) informs the banking service provider 50 whether the request to access the temporary encryption key (in step 98) originates from a user who physically owns the first and second modules 20 and 30.

Thus, as shown at step 74', the banking provider 50 may request that the second module provide an indication that the correct password was provided. In this embodiment, the method proceeds generally as described above with reference to steps 76 to 88, requesting a password from the first module and verifying the password by the second module.

In addition, however, the challenge code may be used to provide further security. In step 74', the challenge code may be generated by the second module 30 or may be received by the second module 30 from the banking service provider 50. In step 76, the query code is provided to the user 40, and in step 78, the user 40 provides the query code to the first module 20. In step 80, the challenge code is used by the first module 20 when generating the password 80 and then, in step 86, when the second module verifies the password.

In an additional step (not referenced), the user 40 may be requested to enter credentials (e.g., username and PIN or password) that are pre-set between the banking service provider 50 and the bank account holder (i.e., user 40). This has the following advantages: banking service provider 50 is able to verify that user 40 of second module 30 is the identified bank account holder or that the user is a different person (e.g., the person may steal modules 20 and 30).

As described above, the second module 30 determines whether the password received from the user 40 is valid based on the untrusted indication of time available to the second module 30, and if appropriate any challenge code that may be provided, in step 86, and then the second module 30 sends a message providing an untrusted indication of time to verify this received OTP, in step 88. The message may additionally contain data indicating that the received OTP was found to be valid and that the correct challenge code was used to generate the password. For example, the response may be encrypted and/or signed using an encryption key shared between the second module 30 and the computing device 50. The response also contains any user name, password, etc. provided by the user 40.

On the other hand, if the second module 30 does not successfully verify the received password, the second module 30 may send a signing message to the banking service provider 50 indicating that the received OTP was found to be invalid.

If the message sent in step 88 indicates that the received OTP is valid, banking service provider 50 may compare the time indicated in the untrusted timestamp sent in step 88 with the first trusted indicator of time. This step may include any other form of authentication, for example, verifying a username and password as described above. If the banking provider 50 determines that the untrusted time (provided in step 88) is within the predetermined time interval and, if desired, that any other authentication credentials (i.e., username and password) are valid, then the banking provider 50 may send (in step 100) the temporary encryption key that is locked for autumn to the second module 30 and then store in that module.

In an alternative example, the banking service provider 50 does not generate and distribute a temporary encryption key, which may be generated by the service provider 60 and transmitted to the banking service provider 50, and then determines whether to share the encryption key with the second module 30 as in the case where the temporary encryption key is generated by the banking service provider 50. Alternatively, the temporary encryption key may be generated by the second module 30 and may be sent to the banking service provider 50, for example, in message 88. In this arrangement, the banking service provider 50 may share the temporary encryption key with the service provider 60.

As described above, the second module 30 is registered with the banking service provider 50 as being owned by a particular bank account holder. The banking service provider 50 shares the temporary encryption key with the second module 30 and the service provider 60. The service provider 60 may already know that the bank account holder is the registered owner of the second module 30 and in this case, when sharing the temporary encryption keys with the service provider 60, determine that the bank account holder associated with those encryption keys is the service provider 60. Alternatively, if the service provider 60 does not already know the bank account holder, the banking service provider 50 may provide the service provider 60 with information identifying and providing the service to the bank account holder while sharing the associated temporary encryption key.

In this example, the user 40 may request (step 102) access to a further service provider 60 for payment from the bank account holder's account or transfer of funds.

In some embodiments, rather than receiving a request to access data from user 40 at any of second module 30, computing device 50, or computing device 60, any of second module 30, computing device 50, or computing device 60 may also generate a request to access data without user input. For example, a third party operating computing device 50 may wish to determine whether user 40 of second module 30 is in physical possession of second module 30, such that computing device 50 sends a message indicative thereof to second module 30. Upon receipt of this message, the second module 30 prompts the user 40 of the second module 30 to enter the password generated by the first module 20 into the second module 30, and the method proceeds as described above.

Embodiments of the present invention may be compared to a system in which the second module 30 does not know the key used by the first module 20 to generate the password, but shares the key between the authentication server (e.g., computing device 50) and the first module 20. Although in such an embodiment the second module 30 does not require an indication of the access time, whether trusted or untrusted, the system may lose the security of uniquely sharing a key between the first and second modules because the key is then shared between the first module 20 and the computing device 50. In fact, if the computing device 50 is hacked, many keys may be exposed, in contrast to the above system, where only one key may be exposed by the hacked first or second module.

As described above, the first and second modules 20 and 30 may be composite components of the same device and may be communicatively disconnected from each other within the device. In these embodiments, the only (indeed possible) way that the user 40 can retrieve the password from the first module 20 and enter it into the second module 30 is whether the user 40 has possession of the first module 20. It follows therefore that in this case the user 40 is very likely to possess the device and, therefore, be an individual user. Thus, if the second module 30 verifies the password received from the user 40, the second module 30 can confidently determine that the request to access the data originated from a person in possession of the device (and thus is not a remote entity). The ability to access the requested data may include allowing access to restricted data maintained on the device, or in the case where a third party (e.g., computing device 50) maintains the requested data, may include transmitting the data to the third party for enabling access to the requested data.

It is to be understood that, as described above, the user 40 may not be a single physical person, and as such, the first user may provide a password to the second user, from which the interface 31 receives the password.

As mentioned above, the interface 21 of the first module 20 and the interface 31 of the device 35 may be user interfaces. However, in some embodiments, the interface may provide an input/output interface to connect to a suitable user interface. This may be done to enable distribution of the first module 30 or the means 35 so that user interfaces through which the password is provided may be physically separated.

The above embodiments are to be understood as illustrative examples of the invention. Further embodiments of the invention are envisaged. For example, the second module 30 may be used to allow access to data, assets, or services maintained or provided by a plurality of third parties (e.g., computing devices 50 and 60) as well as other systems not shown. It is to be understood that while in many of the embodiments described above the first and second modules are described as being communicatively connected, this feature is not an essential feature of the present invention and in other embodiments the first and second modules 20 and 30 may be communicatively connected. Also, although advantageous, the first and second modules 20 and 30 do not require a shared key for generating and verifying the password. It is to be understood that any feature described in relation to any one embodiment may be used alone, or in combination with other features described, and may also be used in combination with one or more features of any other of the embodiments, or any combination of any other of the embodiments. Furthermore, equivalents and modifications not described above may also be employed without departing from the scope of the invention, which is defined in the accompanying claims.

The following numbered clauses set forth the preferred embodiments of the present invention:

1. a system for verifying a request to access data, the system accessing a computing device configured to communicate with a first trusted indicator of time, the system comprising:

a first module to access a second trusted indicator of time; and

a second module that accesses an untrusted indicator of time, wherein,

the first module is arranged to generate a password using at least the second trusted indicator of time;

the second module is configured to:

receiving a password associated with the request to access the data, the received password being verified using at least the untrusted indicator of time; and is

Causing transmission of a message to the computing device, the message including data representing an untrusted indicator of time for verifying the received password; and is

The system is arranged to cause a computing device to:

generating data representing a comparison between the untrusted indicator of time and the first trusted indicator of time, and

selectively providing the system with the access to the data based on the generated data.

2. The system of clause 1, wherein the message transmitted to the computing device includes data representing a verification of the received password by the second module using at least the untrusted indicator of time.

3. The system of clause 1 or 2, wherein the first module and the second module share a key uniquely assigned thereto, the first module being arranged to use the key to generate a password, and the second module being arranged to use the key to verify the received password.

4. The system of clause 3, wherein the key is stored within a secure component of the first module.

5. The system of any of clauses 1-4, wherein the key is stored within a secure component of the second module.

6. The system of any of clauses 1-5, wherein the first module comprises tamper-proof hardware comprising a clock arranged to provide a second trusted indicator of time.

7. The system of any of clauses 1-6, wherein the second module is communicatively connected to a device having a clock configured to provide an untrusted indicator of time.

8. The system of any of clauses 1 to 7, wherein the computing device is arranged to send a message including the generated data to another computing device to provide the system with the access to the data, the other computing device being arranged to provide the access to the data upon receipt of the generated data.

9. The system of any of clauses 1 to 7, wherein the requested data is stored at or generated by a computing device, and the computing device is arranged to provide the access to the data based on the generated data.

10. The system of any of clauses 1 to 9, wherein the first module is configured to receive a challenge code generated by a second module or computing device through an interface of the first module and generate a password using at least the challenge code.

11. The system of any of clauses 1-10, wherein the first module is configured to generate a plurality of passwords, at least one of the plurality of passwords being different from another of the plurality of passwords, and to provide at least one of the generated passwords to the user through the interface of the first module.

12. The system of any of clauses 1-11, wherein the second module and the computing device share another key for use in communication therebetween.

13. The system of any of clauses 1 to 12, wherein the second module is arranged to store the received password and compare the received password with any previously stored received password, thereby to verify the received password.

14. A system for verifying a request to access data, the system comprising:

a first module to access a second trusted indicator of time; and

a second module that accesses an untrusted indicator of time, wherein,

the first module is arranged to generate a password using at least the second trusted indicator of time;

the second module is configured to:

a password associated with a request to access data is received,

verifying the received password using at least an untrusted indicator of time, and

causing transmission of a message to the computing device, the message including data representing an untrusted indicator of time for verifying the received password; and is

Receiving from the computing device data representing a comparison between an untrusted indicator of time and a further trusted indicator of time, and

using the received data to provide said access to the data,

wherein the first and second modules are communicatively disconnected.

15. The system of clause 14, wherein the data received from the computing device includes data representing whether the untrusted indicator of time is within a predetermined range of the first trusted indicator of time.

16. The system of clause 14 or 15, wherein the requested data is maintained by a second module, and the second module is configured to use the data received from the computing device to determine whether to provide access to the requested data.

17. The system of any of clauses 14 to 16, wherein the trusted indicator of time accessed by the first module is a clock of the first module and the further trusted indicator of time accessed by the computing device is a clock synchronized with the clock of the first module.

18. The system of any of clauses 14 to 17, wherein the computing device and the second module are preconfigured with an encryption key for signing data sent therebetween, and wherein the second module is arranged to sign the message for transmission to the computing device and to verify that the computing device signed the data received from the computing device using the encryption key.

19. The system of any of clauses 14 to 18, wherein the second module is arranged to store the received password and to compare the received password with any previously stored received password, thereby to verify the received password.

Claims (40)

1. A system for verifying a request for access to data, the system accessing a computing device configured to communicate with a first trusted indicator of time, the system comprising:

a first module to access a second trusted indicator of time; and

a second module that accesses an untrusted indicator of time, wherein,

the first module is arranged to generate a password using at least the second trusted indicator of time;

the second module is configured to:

receiving a password associated with the request for access to data, the received password being verified using at least the untrusted indicator of time; and is

Causing a message to be transmitted to the computing device, the message including data representing the untrusted indicator of time used to verify the received password, and

the system is arranged to cause the computing device to generate data representing a comparison between the untrusted indicator of time and the first trusted indicator of time, wherein the generated data is used to provide the access to the data.

2. A system according to claim 1, wherein the system is arranged to cause the computing device to selectively provide the system with said access to data based on the generated data.

3. The system of claim 1, wherein the message transmitted to the computing device includes data representing a verification of the received password by the second module using at least the untrusted indicator of time.

4. A system according to claim 1, wherein the first and second modules share a key uniquely assigned thereto, the first module being arranged to use the key to generate the password and the second module being arranged to use the key to verify the received password.

5. The system of claim 4, wherein the key is stored within a secure component of the first module.

6. A system according to claim 4 or 5, wherein the key is stored within a secure component of the second module.

7. The system of claim 1, wherein the first module comprises tamper-proof hardware including a clock arranged to provide the second trusted indicator of time.

8. The system of claim 1, wherein the second module is communicatively connected to a device having a clock arranged to provide the untrusted indicator of time.

9. A system according to claim 1, wherein the system is arranged to cause the computing device to transmit a message including the generated data to another computing device to provide the system with the access to the data, the other computing device being arranged to provide the access to the data upon receipt of the generated data.

10. The system of claim 2, wherein the requested data is stored at or generated by the computing device, and the computing device is arranged to provide the access to the data based on the generated data.

11. The system of claim 1, wherein the first module is configured to receive a challenge code generated by the second module or the computing device through an interface of the first module and generate the password using at least the challenge code.

12. The system of claim 1, wherein the first module is configured to generate a plurality of passwords, at least one of the plurality of passwords being different from another of the plurality of passwords, and to provide at least one of the generated passwords to a user through an interface of the first module.

13. The system of claim 1, wherein the second module and the computing device share another key for use in communications therebetween.

14. The system of claim 1, wherein the second module is arranged to store the received password and compare the received password with any previously stored received password to verify the received password.

15. The system of claim 1, wherein the first module and the second module are communicatively disconnected and the second module is configured to receive the generated data from the computing device and use the received data to provide the access to the data.

16. The system of claim 15, wherein the data received from a computing device comprises data representing whether the untrusted indicator of time is within a predetermined range of the first trusted indicator of time.

17. The system of claim 15, wherein the requested data is maintained by the second module, and the second module is configured to use the data received from the computing device to determine whether to provide access to the requested data.

18. The system of claim 15, wherein the second trusted indicator of time is a clock of the first module and the first trusted indicator of time is a clock synchronized with the clock of the first module.

19. The system of claim 15, wherein the computing device and the second module are preconfigured with an encryption key for signing data transmitted therebetween, and wherein the second module is configured to sign the message for transmission to the computing device and verify that the computing device signed the data received from the computing device using the encryption key.

20. The system of claim 15, wherein the second module is configured to store the received password and compare the received password to any previously stored received password to verify the received password.

21. A method of verifying, by a system, a request for access to data using a computing device configured to communicate with a first trusted indicator of time, the method comprising:

generating a password at the first module using at least the second trusted indicator of time;

receiving a password associated with a request for access to data;

verifying the received password at the second module using at least the untrusted indicator of time; and is

Causing a message to be transmitted to the computing device, the message including data representing the untrusted indicator of time used to verify the received password;

wherein the content of the first and second substances,

the system causes the computing device to generate data representing a comparison between the untrusted indicator of time and the first trusted indicator of time, wherein the generated data is used to provide the access to the data, and

wherein the system comprises the first module and the second module.

22. The method of claim 21, wherein the system causes the computing device to selectively provide the system with the access to data based on the generated data.

23. The method of claim 21, wherein the message transmitted to the computing device includes data representing a verification of the received password by the second module using at least the untrusted indicator of time.

24. The method of claim 21, wherein the first module and the second module share a key uniquely assigned thereto for generating the password and for verifying the received password.

25. The method of claim 24, wherein the key is stored within a secure component of the first module.

26. The method of claim 24, wherein the key is stored within a secure component of the second module.

27. The method of claim 21, comprising retrieving the second trusted time indicator from a clock within damage prevention hardware of the first module.

28. The method of claim 21, comprising receiving the untrusted indicator of time from a clock communicatively connected with the second module.

29. A method according to claim 21, wherein the system causes the computing device to transmit a message comprising the generated data to another computing device to provide the system with the access to the data, the other computing device being arranged to provide the access to the data upon receipt of the generated data.

30. The method of claim 21, wherein the requested data is stored at or generated by the computing device, and the computing device is arranged to provide the access to the data based on the generated data.

31. The method of claim 21, comprising receiving, through an interface of a first module, a challenge code generated by the second module or the computing device, and generating the password using at least the challenge code.

32. The method of claim 21, comprising generating a plurality of passwords, at least one of the plurality of passwords being different from another of the plurality of passwords, and providing at least one of the generated passwords to a user through an interface of the first module.

33. The method of claim 21, wherein the second module and the computing device share another key for use in communications therebetween.

34. The method of claim 21, wherein the method comprises storing the received password at the second module and comparing the received password to any previously stored received password to thereby verify the received password.

35. The method of claim 21, wherein the first module and the second module are communicatively disconnected and the system causes the computing device to provide the generated data to the second module, the method comprising providing, by the second module, the access to data using the received generated data.

36. The method of claim 35, wherein the data received from the computing device includes data representing whether the untrusted indicator of time is within a predetermined range of the first trusted indicator of time.

37. The method of claim 35, wherein the requested data is maintained by the second module, and the method comprises using, by the second module, the data received from the computing device to determine whether to provide access to the requested data.

38. The method of claim 35, wherein the second trusted indicator of time is a clock of the first module and the first trusted indicator of time is a clock synchronized with the clock of the first module.

39. A method according to claim 35, wherein the computing device and the second module are pre-configured with an encryption key for signing data sent therebetween, and wherein the method comprises signing the message transmitted to the computing device and verifying that the computing device signed the data received from the computing device using the encryption key.

40. A method as claimed in claim 35, wherein the method comprises storing the received password at the second module and comparing the received password with any previously stored received password, thereby to verify the received password.