Patent Description:
OTPs are passwords which are valid only once. OTPs typically rely on complex calculation. At least two types of OTPs are widely used. The first type uses a mathematical algorithm to generate each new password based on a counter. Another implementation type is based on time-synchronization between the authentication server (OTP server) and the client generating the one-time-password (OTP client). In such a case, the OTP is valid during a preset time window only. It is also possible to mix both types, i.e. to derive the next password from a counter and from the current time (and possibly other parameters). OTPs have a number of constraints (such as synchronization between the OTP server and the OTP client), which are now well understood by those skilled in the art.

The OTP client may be embedded in a portable hardware device able to display or send the generated OTP. Such an OTP device may be in the form of a small device having a battery and at least one button. When such an OTP device is lost or stolen, a malevolent person may trigger the generation of a new OTP and used it for undue operation. Protecting access to the OTP client is important in order to guarantee that only a genuine user is able to get a new one-time-password.

There is need to solve the above-presented problem.

The invention aims at solving the above mentioned technical problem.

An object of the present invention is a method for providing a One-Time-Password by an OTP device.

Advantageously, the method may comprise the following steps before sending the request to get the cryptographic value:.

Advantageously, the method may comprise the step of checking by the OTP device that the identifier received in response to the command matches a preregistered identity data and sending the request to get the cryptographic value only in case of successful checking.

Advantageously, the method may comprise the previously executed steps:.

Advantageously, the identifier may be a serial number of the smart card.

Another object of the present invention is an OTP device which comprises a communication interface configured to exchange data with a smart card. The OTP device is configured to send to the smart card a request to get a cryptographic value computed from an identifier of the smart card. Upon receipt of the cryptographic value, the OTP device is configured to perform a verification of the cryptographic value by using a reference value. The OTP device is configured to provide the One-Time-Password only if said verification was successful.

Advantageously, the OTP device may be configured to retrieve the identifier of the smart card by sending to the smart card a command to get the identifier of the smart card before sending the request to get the cryptographic value.

Advantageously, the OTP device may be configured to check that the identifier received in response to said command matches a preregistered identity data and to send the request to get the cryptographic value only in case of successful checking.

Advantageously, the OTP device may be configured to check that the identifier received in response to said command complies with a predefined rule and to send the request to get the cryptographic value only in case of successful checking.

Advantageously, the OTP device may be configured to generate a result by assessing a security rule and to trigger the sending of the request only if said result reflects that provision of the One-Time-Password is conditioned by a biometric authentication of the user.

Advantageously, the OTP device may be configured to receive a challenge originated from a server, and the security rule may depend on the challenge.

Advantageously, the OTP device may be configured to generate the One-Time-Password by signing the challenge with a key preregistered in the OTP device.

Advantageously, the OTP device may be configured to display the One-Time-Password or to send the One-Time-Password to a remote apparatus.

Another object of the present invention is a system comprising a smart card and an OTP device according to the invention.

Other characteristics and advantages of the present invention will emerge more clearly from a reading of the following description of a number of preferred embodiments of the invention with reference to the corresponding accompanying drawings in which:.

The invention may apply to any type of device intended to provide One-Time-Passwords. For instance the OTP device may be a portable apparatus or a key fob embedding an OTP client. The OTP device may generate an OTP on-the-fly each time a request occurs or pre-generate one or several OTPs and provision an OTP each time a request occurs.

<FIG> shows an exemplary flow diagram to carry out a binding phase between an OTP device and a biometric card according to an embodiment of the invention.

In this example, the OTP device <NUM> may be a portable hardware device including a display, a battery, a real time clock (RTC) and a button to request provision of a new OTP. The OTP device comprises a communication interface configured to exchange data with a smart card. The communication interface may be a designed to exchanged data in contact mode or wireless mode. For instance, the communication interface may be compliant with ISO/IEC7816-<NUM> T=<NUM> or T=<NUM> protocols for contact mode or with ISO/IEC14443, ISO/IEC21481 or ISO/IEC18092 standards for contactless mode.

Smart cards are portable small devices comprising a memory, a microprocessor and an operating system for computing treatments. They may comprise services applications like payment applications. Such secure elements may comprise a plurality of memories of different types, like non-volatile memory and volatile memory. They are considered as tamper-resistant (or "secure") because they are able to control the access to the data they contain and to authorize or not the use of data by other machines. A smartcard may also provide computation services based on cryptographic components. In general, smartcards have limited computing resources and limited memory resources and they are intended to connect a host machine which provides them with electric power either in contact mode or contactless mode.

A biometric smart card contains at least one biometric sensor, like a fingerprint sensor, which can contribute to the authentication of the user of the smartcard.

In the example of <FIG>, the biometric smartcard <NUM> embeds a secure element (chip) comprising a hardware processing unit, memory and an operating system designed to contribute to bank services. The biometric card also comprises a reference biometric data which has been enrolled by the genuine user (i.e. bank customer). The biometric card <NUM> may use the reference biometric data to authenticate the cardholder by using a biometric data captured by its sensor.

At a first step, the OTP device <NUM> and the biometric card <NUM> establish a communication channel (i.e. a communication session is open).

At a second step, the OTP device <NUM> may request an identifier of the card by sending a specific command (Request ID or read Identifier).

At a third step, the OTP device <NUM> receives the identifier <NUM> of the card through the communication channel. The OTP device may store in its own memory the received card identifier as an identity data <NUM>. The stored identity data <NUM> may be used in further phases to check that the card has been registered by the OTP device.

It is to be noted that second and third steps are optional. The OTP device <NUM> may get the card identifier <NUM> by another way. For instance, the card identifier may be prerecorded in the OTP device <NUM> or may be provided by the cardholder through a man-machine interface like a keyboard or via another machine like a computer coupled to the OTP device.

The card identifier is assumed to be uniquely assigned to the card <NUM>. It may be a serial number of the card or a random value generated by the card. The card identifier may be a physical unclonable function (PUF) of the card computed from the chip, the memory component or any hardware component embedded in the card <NUM>. The card identifier may also be a value (preferably random) provided to the card by the OTP device.

At a fourth step, the OTP device <NUM> sends to the card <NUM> a binding request <NUM> to retrieve a reference value from the smart card <NUM>.

In some embodiments, the binding request <NUM> may comprise the card identifier <NUM>.

In some embodiments, the OTP device <NUM> may not manage the card identifier <NUM> (and may not store the identity data <NUM>) and the binding request <NUM> may be devoid of the card identifier <NUM>.

At a fifth step, upon receipt of the binding request, the card tries to authenticate the user via its biometric sensor. For convenience, the card (and/or the OTP device) may light up a led or provide another signal to guide the user. The authentication of the user (cardholder) is performed by way of comparison based on both the stored reference biometric data and the biometric data captured by the sensor.

At a sixth step, the card identifies a reference value <NUM> and automatically sends (to the OTP device) the reference value <NUM> only if the user has been authenticated through the captured biometric data.

In some embodiments, the card may generate the reference value <NUM> as the signature of the card identifier. Such a signature may be computed by using a pre-stored key or a key generated by the card itself.

In some embodiments, the card may generate the reference value <NUM> as the hash of the card identifier.

In some embodiments, the card may generate the reference value <NUM> as the result of a cryptographic function which takes the card identifier as input parameter.

At a seventh step, the OTP device <NUM> stores the received reference value <NUM> in its own non-volatile memory (NVM). In a preferred embodiment, the OTP device <NUM> may associate the reference value <NUM> with the card identifier.

In some embodiments, the card may send a message reflecting the failure of the user authentication in response to the binding request.

<FIG> shows a first exemplary flow diagram to trigger the provision of an OTP according to an embodiment of the invention.

In this example, the OTP device <NUM> is assumed to have been provisioned with the reference value <NUM> (and possibly the card identifier <NUM>) according to the method of <FIG>.

Alternatively, the OTP device <NUM> may get the reference value <NUM> (and possibly the card identifier <NUM>) by another way. For instance, the reference value <NUM> may be prerecorded in the OTP device <NUM> during a personalization phase or may be provided by another apparatus like a computer coupled to the OTP device.

At a first step, the OTP device <NUM> and the biometric card <NUM> establish a communication session (i.e. a communication channel is open). For example, upon detection of card insertion, the OTP device may initiate establishment of the communication channel.

At a second step, the OTP device <NUM> may send a command <NUM> to get the card identifier <NUM>. For instance, the command may be a command aiming at reading a specific field in the card memory.

At a third step, the OTP device <NUM> receives the identifier of the card in response to the command <NUM> through the communication channel.

It is to be noted that second and third steps are optional. The OTP device <NUM> may have access to the card identifier by another way. For instance, the card identifier may be stored in the OTP device <NUM> during a previous stage or may be provided by the cardholder through a man-machine interface like a keyboard or via another machine like a computer coupled to the OTP device.

In some embodiments, the OTP device <NUM> may not access the card identifier.

At a fourth step, the OTP device <NUM> sends to the card <NUM> a request <NUM> to get a cryptographic value <NUM>. In some embodiments, the request may contain the card identifier <NUM> and the card may be assumed to generate the cryptographic value <NUM> by applying a cryptographic function to the received card identifier <NUM>.

In some embodiments, the request may not contain the card identifier <NUM> and the card may be assumed to retrieve the card identifier <NUM> from its own memory to use it as input parameter for generating the cryptographic value <NUM>.

At a fifth step, the card tries to authenticate the user via its biometric sensor. The receipt of the request <NUM> triggers starting of the capture of a biometric data by the sensor of the card. User authentication is performed by way of comparison based on both the stored reference biometric data and a biometric data captured by the biometric sensor.

At a sixth step, the card identifies a cryptographic value <NUM> and automatically sends it to the OTP device only if the user has been authenticated through the captured biometric data. Preferably, the card generates the cryptographic value <NUM> in the same way it generated the reference value <NUM>.

At a seventh step, the OTP device <NUM> performs a verification of the received cryptographic value <NUM> by using the stored reference value <NUM>. The verification may be based on a comparison or a more complex mathematical treatment.

At an eighth step, the OTP device <NUM> provides a new One-Time-Password only if the verification succeeded at seventh step. The OTP device <NUM> may generate the new OTP as soon as the verification succeeded or may retrieve a pre-computed OTP from its memory.

In some embodiments, the OTP device <NUM> may use the card identifier <NUM> received in response to the command <NUM> to check that the card <NUM> has been duly pre-enrolled by the OTP device. In particular, the OTP device may check that the identifier <NUM> received in response to the command <NUM> matches the preregistered identity data <NUM> and send the request <NUM> to get the cryptographic value <NUM> only in case of successful checking.

<FIG> shows a second exemplary flow diagram to trigger the provision of an OTP according to an embodiment of the invention.

The OTP device is connected to a server <NUM> which may be hosted in a local computer or a remote computer reachable through any relevant network. The server may be a hardware machine.

At a first step, the OTP device receives a challenge <NUM> originated from the server <NUM>. The challenge may be a random value generated by the server.

At a second step, the OTP device generates a result by assessing a security rule depending on the challenge.

Then the OTP device triggers the sending of the request <NUM> to get a cryptographic value <NUM> only if the result reflects that provision of the One-Time-Password is conditioned by a biometric authentication of the user. The security rule may be pre-stored in the OTP device or received from the server with the challenge. The security rule may allow to dynamically adapt the security level requirements according to the conditions, context or parameters of a transaction. For instance, provision of OTP may depends on biometric user authentication for payment transactions for an amount above a predefined threshold.

Then the flow continues in a manner similar to the sequence described at <FIG>.

The OTP device <NUM> may generate the one-time-password by signing the challenge <NUM> using a key pre-stored in the OTP device.

<FIG> depicts a diagram of architecture of a system comprising an OTP device and a biometric card according to an embodiment of the invention.

The system <NUM> comprises an OTP device <NUM> and a biometric smart card <NUM>.

The OTP device comprises a communication interface <NUM> which is configured to exchange data with the smart card <NUM>. The communication interface <NUM> may be configured to communicate with the card in contact mode according to the protocols defined by ISO/IEC <NUM> or USB for instance. It may be configured to communicate with the card in contactless mode according to a protocol complying with ISO/IEC <NUM>, Mifare®, Felica®, ISO/IEC <NUM> or NFC Forum Tag specifications for instance.

The OTP device is configured to send to the card <NUM> a request <NUM> to get a cryptographic value <NUM> computed from an identifier of the smart card <NUM>.

The OTP device is configured to perform a verification of the received cryptographic value <NUM> by using a reference value <NUM> stored in its memory upon receipt of the cryptographic value <NUM>.

The OTP device is configured to provide the One-Time-Password only if the verification was successful.

The OTP device comprises an OTP generator <NUM> able to compute new OTPs. The OTP generator <NUM> may be able to store a series of generated OTPs and to retrieve one element of the series when an OTP is to be provisioned.

The OTP generator <NUM> may comprise a RTC. The OTP generator <NUM> may store the reference value <NUM> bound to the card <NUM>. The OTP generator <NUM> may store a preregistered identity data <NUM> assigned to the card <NUM>.

Preferably, the OTP device comprises a battery.

In some embodiments, the OTP device may comprise a screen <NUM> to display the One-Time-Passwords.

In some embodiments, the OTP device may comprise a communication interface <NUM> to exchange data with a server as illustrated at <FIG>. The communication interface <NUM> may be adapted to exchange data according to any relevant wireless bearer like NFC, Wi-Fi, Bluetooth ® or BLE for instance) or through a wired link. The communication channel between the OTP device <NUM> and the remote server <NUM> may be based on any combination comprising a telecom network, the Internet or a private network for instance.

The OTP device may be configured to retrieve the identifier of the connected smart card by sending to the smart card a command <NUM> to get the card identifier before sending the request <NUM> to get a cryptographic value <NUM>.

The OTP device may be configured to check that the identifier received in response to the command <NUM> matches a preregistered identity data <NUM> and to send the request <NUM> to get a cryptographic value <NUM> only in case of successful checking.

The OTP device may be configured to check that the identifier received in response to the command <NUM> complies with a predefined rule and to send the request <NUM> only in case of successful checking. For instance, the predefined rule may specify that the identifier belongs to a specific range, reflects a specific card type or comply with a specific format.

The OTP device may be configured to generate a result by assessing a security rule and to trigger the sending of the request <NUM> only if the result reflects that provision of the One-Time-Password is conditioned by a biometric authentication of the user. The security rule may be pre-stored in the OTP device during a personalization phase.

The OTP device may be configured to receive a challenge <NUM> originated from a server <NUM> and to select the security rule depending on the challenge.

The OTP device may be configured to generate the One-Time-Password as the signature of the challenge <NUM> computed with a key preregistered in the OTP device. For instance the signature may be computed by using the RSA, the Digital Signature Algorithm (DSA), the ESIGN (Efficient digital SIGNature) or the Elliptic Curve Digital Signature Algorithm (ECDSA) algorithm. Algorithms based on symmetric keys or public-private keys pair may be used to generate the signature of the challenge <NUM>.

The OTP device may be configured to send the One-Time-Password to a remote appliance.

The OTP device <NUM> may be bound to several biometric cards.

In some embodiments the OTP device may be adapted to automatically perform the sequence of actions presented at <FIG>, <FIG> and/or <NUM>.

The biometric card <NUM> comprises a communication interface <NUM> adapted to exchange data in contact or contactless mode with the OTP device. For instance, the communication interface <NUM> may allow the card to communicate with the OTP device <NUM> through Bluetooth Low Energy ® (known as BLE).

The biometric card <NUM> comprises a biometric sensor <NUM> and a secure element <NUM> configured to verify that a biometric data captured by the sensor matches with a preregistered reference value (reference template) stored in the card. The biometric sensor <NUM> may be designed to capture fingerprint data for instance. The biometric card <NUM> may comprise a controller <NUM> of the biometric sensor. Such a controller may be implemented as a MCU for instance.

The biometric card <NUM> comprises its own identifier <NUM>. The biometric card <NUM> may comprise a key <NUM>. The secure element may be configured to apply a preset cryptographic function to the identifier <NUM>. The cryptographic function may require the use of the key <NUM> as input parameter.

In some embodiments, the card <NUM> may be a conventional biometric smartcard adapted to return the computed cryptographic value <NUM> only if the user has been successfully authenticated through a capture biometric data.

In some embodiments, the card <NUM> may be adapted to compute a cryptographic value <NUM> by applying the cryptographic function to the card identifier <NUM> upon receipt of a request <NUM> (to get a cryptographic value <NUM>) devoid of card identifier and received from the OTP device <NUM>.

The biometric card <NUM> may be bound to several OTP devices.

The biometric card <NUM> may store several biometric references assigned to as many different users.

In some embodiments, the communication channel established between the card and the OTP device may be a secure channel so as to guarantee confidentiality of exchanged data or to avoid replay attacks. The communication session may be secured by using one or several shared keys. The secure channel may rely on the secure messaging mechanism as defined by ISO/IEC7816 part <NUM>.

Thanks to some embodiments of the invention, the provision of One-Time-passwords by the OTP device cannot be done without agreement of the genuine user of the card bound to the OTP device.

According to some embodiments of the invention, neither the OTP device nor the server hold the biometric data (captured data and reference template) which remain into the card. Thus privacy and security may be guaranteed to the user who wants to use the OTP device.

According to some embodiments of the invention, the OTP device does not need to be personalized (with credentials or biometric reference specific to the user) before being supplied to the user.

The invention is not limited to the described embodiments or examples. In particular, the described examples and embodiments may be combined.

In some embodiments, the OTP device may be replaced by an apparatus providing features different from One-Time-passwords (i.e. an apparatus that does not handle OTP. ) In such a case, the binding phase may be carried out in a way similar to the sequence of <FIG> and the releasing of a new OTP (as describes at <FIG> and <FIG>) may be replaced by the provision of a service or a feature specific to the appliance. Such embodiments allow to protect access to a service or function provided by a hardware device. For instance, a toaster can start heating only if the user has been successfully authenticated through the biometric sensor of its associated card. For instance, the successful authentication of a user through biometric data captured by the card associated to a device may be a necessary condition to be fulfilled for a vehicle to start, a television to change the channel, a water cooler to deliver liquid, a drink dispenser to dispense a bottle or a glass, a printer to print, a lock to unlock, a safe to open, a door to open, a machine to load parameters, a screen to display data or a laptop to unlock.

The invention is not limited to Banking smart cards and applies to any biometric smart cards allocated to at least one user. For example, the smart card may be an access badge providing access to a physical building, room or a logical area.

Claim 1:
A method for providing a One-Time-Password by an OTP device (<NUM>) that is a hardware device, characterized in that the method comprises the steps:
- establishing a communication session between the OTP device and a smart card (<NUM>) embedding a biometric sensor (<NUM>), said smart card being separate from the OTP device,
- sending, from the OTP device to the smart card, a request (<NUM>) to get a cryptographic value (<NUM>) computed from an identifier (<NUM>) of the smart card,
- in response to receiving the request, trying to authenticate a user by using said biometric sensor and automatically releasing the cryptographic value only if the user was successfully authenticated,
- sending said cryptographic value from the smart card to the OTP device,
- performing by the OTP device a verification of the cryptographic value by using a reference value (<NUM>), and
- providing the One-Time-Password by the OTP device only if said verification was successful.