METHOD FOR AUTHENTICATING PAYMENT DATA, CORRESPONDING DEVICES AND PROGRAMS

Abstract

A method for authenticating at least one piece of data during a payment transaction taking place between a merchant's communications terminal and a user device of the type including transmission, by the communications terminal, of at least one piece of data to be signed, to the user device by using a near field communications wireless data link. The method includes: obtaining the piece of data to be signed; obtaining an identifier of the communications terminal; signing, within a secured processing unit of the communications terminal, by using a key of the communications terminal, the piece of data to be signed and the identifier of the communications terminal, delivering signed pieces of data; transmission of the signed pieces of data to the user device; and reception, from the user device, of a piece of encrypted data establishing the authentication of the signed pieces of data.

Claims

1. A method of authenticating at least one piece of data, implemented during a payment transaction taking place between a merchant's communications terminal and a user device, the method being of the type comprising transmission, by the communications terminal, of at least one piece of data to be signed to the user device by using a near field communications wireless data link, wherein the method comprises the following acts performed by the communications terminal: obtaining said piece of data to be signed; obtaining an identifier of said communications terminal; signing, within a secured processing unit of said communications terminal, by using a key of said communications terminal, said piece of data to be signed and said identifier of the communications terminal, delivering a pair of signed pieces of data; transmission of the pair of signed pieces of data to said user device; and reception, from said user device, of a piece of encrypted data establishing authentication of said pair of signed pieces of data.

2. The method of authentication according to claim 1, comprising, subsequently to said reception of the piece of encrypted data coming from said user device: decryption, by using the secured processing unit of said communications terminal, of said piece of encrypted data delivering a piece of signed data; verification of validity of said piece of signed data in relation to a piece of reference data.

3. The method of authentication according to claim 2, wherein said piece of reference data is equal to said piece of data to be signed.

4. The method of authentication according to claim 2, wherein subsequently to verification of the validity of said piece of signed data in relation to the piece of reference data, if a positive result is delivered, the method comprises transmission, by the communications terminal, of said piece of signed data to a payment transaction processing system.

5. The method of authentication according to claim 1, wherein said signing comprises: transmission of said piece of data to be signed and/or said identifier of the communications terminal to said secured processing unit of said communications terminal by a general processing unit of said communications terminal; signing, by said secured processing unit, using said key of the communications terminal, said piece of data to be signed and/or said identifier of the communications terminal, respectively delivering a piece of signed data and/or a signed identifier; transmission of said piece of signed data and/or of the signed identifier to said general processing unit of said communications terminal.

6. The method of authentication according to claim 1, wherein said key of the communications terminal is a private key belonging a {private key; public key} pair.

7. The method of authentication according to claim 1, comprising, within the user device, between the transmission of the pair of signed data and the reception of the piece of encrypted data: reception of the pair of signed data by the user device; verification, by using a key, of the signature of the data of the pair of pieces of signed data; and when the signature of the pair of pieces of signed data is correct: signing, by using a signature key, of at least one of the pieces of data previously received from the merchant's communication terminal, delivering a piece of signed data; encryption of said piece of signed data by using an encryption key delivering the piece of encrypted data; transmission of the piece of encrypted data to the merchant's communications terminal.

8. A communications terminal comprising: a general processing unit; a memory; a secured processing unit; a secured memory; at least one reconfigurable circuit formed by the general processing unit and the secured processing unit for processing payment transactions with a user terminal, comprising authentication of a piece of data, said reconfigurable circuit configuring the communications terminal to perform acts comprising: obtaining a piece of data to be signed; obtaining an identifier of said communications terminal; signing, within the secured processing unit of said communications terminal, by using a key of said communications terminal, said piece of data to be signed and said identifier of the communications terminal, delivering a pair of signed pieces of data; transmission of the pair of pieces of signed data to said user device; and reception, from said user device, of a piece of encrypted data establishing the authentication of said pair of signed data.

9. A non-transitory computer readable medium comprising a computer program product stored thereon, which comprises program code instructions for executing a method of authenticating at least one piece of data, when the instructions are executed by a merchant's communications terminal during a payment transaction taking place between the communications terminal and a user device, the method being of the type comprising transmission, by the communications terminal, of at least one piece of data to be signed to the user device by using a near field communications wireless data link, wherein the method comprises the following acts performed by the communications terminal: obtaining said piece of data to be signed; obtaining an identifier of said communications terminal; signing, within a secured processing unit of said communications terminal, by using a key of said communications terminal, said piece of data to be signed and said identifier of the communications terminal, delivering a pair of signed pieces of data; transmission of the pair of signed pieces of data to said user device; and reception, from said user device, of a piece of encrypted data establishing authentication of said pair of signed pieces of data.

Description

4. FIGURES

[0059] Other features and advantages of the invention shall appear more clearly from the following description of a preferred embodiment, given by way of a simple illustratory and non-exhaustive example and from the appended drawings, of which!

[0060] FIG. 1 is a block diagram of the proposed technique authenticating data transmitted between a merchant's communications terminal and a user device;

[0061] FIG. 2 is a block diagram of the proposed technique performing a signature of data within the merchant's communications terminal;

[0062] FIG. 3 is a schematic representation of the merchant's communications terminal according to the present invention;

[0063] FIG. 4 schematically describes a user device according to the present invention.

5. DESCRIPTION

5.1. General Principle

[0064] As explained here above, the general principle of the invention consists especially in integrating one or more additional constraints into the “challenge-response” scheme. The present invention proposes a protocol modification that makes it possible to withstand attacks by terminals comprising malicious software. Secondarily, this protocol modification also protects the terminals of the merchants themselves against unsolicited responses coming from other apparatuses (i.e. malicious apparatuses that might try to attack an authentic merchant's terminal). This protocol modification thus offers an additional layer of protection against other types of attacks (DoS or “Denial of Service”, Concurrency Attacks, etc.).

[0065] Thus, when a payment transaction is made between a merchant's terminal and a user device, a challenge-response type process is implemented so that the merchant's terminal identifies (authenticates) the user device (and vice versa). It is assumed that the merchant's terminal (it is a telephone, a tablet or a PC) is not secured as such but has securing resources. These securing resources can for example take the form of a “Secure Element—SE” or a “Trusted Execution Environment—TEE” or again another dedicated hardware or software component. It is assumed, for the explanations that follow, that the payment application of the merchant's terminal is called TPC and that it comprises a verification (identification) module called V (it is for example an SE, a TEE or more generally a secured processing unit). It is also assumed that there is a payment application on the user's device DU and that the user's device (DU) comprises a proof module (to confirm identity) called P (it is for example an SE, a TEE or more generally a secured processing unit). In another embodiment, the user device can be a classic payment card in which protocol and hardware modifications are made enabling the present technique to be implemented.

[0066] During the joint implementation of the payment applications TPC and DU, the method implemented is generally the following: [0067] the authentication data transmitted by V to P (i.e. the “challenge” data) are signed digitally by V itself. [0068] the response transmitted by P is encrypted in such a way that only V can verify its validity.

[0069] In order to enable such an implementation, it is enough to provide V with a (public) key that is known to P.

[0070] The underlying logic of this method is that P is purely and simply unaware of the signature requests that do not come directly from the secured part of V (i.e. for example from the “secure element” to which V has access or from the trusted environment to which V has access): it is assumed indeed that only this architecture is capable of carrying out a valid digital signature of the challenge before it is transmitted to P.

[0071] There is a reason for which this assumption is made: the inventors have had the idea of making the key (for example public key) of a signature (of V) directly accessible to the securing resources of the merchant's terminal. In one embodiment for example, the securing resources keep this key and they make it accessible to only a limited number of trusted applications (for example only one application: the payment application installed on the merchant's terminal). Besides, the “secure element” itself carries out the encryption operations on behalf of the payment application of the merchant's terminal. Thus, in the first step, before the transmission of the challenge to the user's communications terminal, the challenge is signed by the securing resources by using the key of V (the key of the payment application). According to one particular characteristic, this key is a public key.

[0072] In addition, the fact that the response transmitted by P is encrypted makes it possible to guard against situations in which a fraudulent individual will detect and re-play the valid authentication traces (known as attack by replay). The attack can be implemented as much by a malicious application installed on the merchant's device as by a malicious application installed on the customer's device.

[0073] Referring to FIG. 1, a description is given of the proposed technique authenticating data transmitted between a merchant's communications terminal and a user device. It may be recalled that it is sought to make sure that the user device signs only data coming legitimately from the merchant's communications terminal (acting as a payment terminal). The technique thus comprises: [0074] a step (10) for obtaining the data to be signed (DaS); [0075] a step (20) for obtaining an identifier of the communications terminal (UiD); [0076] a signing step (30), using a key (K) of the communications terminal, for signing the data to be signed (DaS) and the identifier of the communications terminal (UiD), delivering a pair of pieces of signed data (CDS); [0077] a step for transmitting (40) the pair of pieces of signed data (CDS) to the user device; and [0078] a step (50) for receiving, from the user device, a piece of encrypted data (DC) establishing the authentication of the pair of pieces of signed data.

[0079] Indeed, according to the present disclosure, the fact of receiving a piece of encrypted data coming from the user device endorses the fact that the pair of data signed has truly been authenticated by the user device. This is practical because it is not necessary to transmit an acknowledgement of reception or a specific confirmation of authentication. Thus the exchanges are reduced. If there is no response from the user device, it can be deduced that the data transmitted are erroneous (that there is an error of reception of the data transmitted for example). For its part, the user device verifies the signature of the data transmitted and transmits no response if there is no authentication.

[0080] If the user device responds, then the procedure continues with a verification of the data received from the user device, and it comprises: [0081] a step of decryption (60), by the secured processing unit of the communications terminal, of the encrypted data (DC), delivering a piece of signed data (DS); [0082] a step of verification (70) of the validity of the signed data (DS) relative to a piece of reference data (DR); [0083] a step of transmission (80), by the communications terminal, of the piece of signed data (DS) to a payment transaction processing system (SUP).

[0084] These three last steps enable the merchant's terminal not to be duped by data arbitrarily “replayed” by the user device that would itself be fraudulent.

[0085] Thus, the procured solution possesses the advantage of protecting the user's device (and the user himself) against fraudulent requests for signatures and of protecting the merchant against attempts at wrongful use received from the user device. The advantage is therefore twofold because of the bilateral protection.

[0086] Depending on the embodiments, the keys used for the signature and the encryption can be either pairs of public/private keys or symmetrical keys serving both for encryption and decryption.

[0087] Referring to FIG. 2, we now describe the proposed technique for carrying out a signing of data within the merchant's communications terminal. This technique comprises: [0088] a step of transmission (301), of said data to be signed (DaS) and/or said identifier of the communications terminal (UiD) to a secured processing unit (UTS) of said communications terminal by a general processing unit (UTG) of said communications terminal; [0089] a step of signing (302) by said secured processing unit, by means of said key of the communications terminal (K), of said data to be signed (Das) and/or of said identifier (UiD) of the communications terminal, respectively delivering a piece of signed data DS) and/or a signed identifier (UiD); [0090] a step of transmission (303) of said one piece of signed data (DS) and/or of the signed identifier (UiDs) to said one general processing unit of said communications terminal.

5.2. Description of One Embodiment

[0091] In this purely illustratory embodiment, it is assumed, for greater simplicity, that RSA type signature and encryption mechanisms are being used (both on the merchant's terminal side and on the user device side). In this embodiment it is assumed that, prior to the implementation of the secured exchange protocol, two installation phases have been carried out: one on the merchant's terminal side and one on the user device side.

[0092] 5.2.1. Phase of Installation on the Merchant's Terminal Side

[0093] The merchant's terminal is provided with a private key sk. This provision of a private key can be done at any time. It is assumed that this private key sk is generated according to known prior art techniques and that it is placed within a secured resource of the merchant's terminal. Ideally, this private key is placed within a TEE (acting as a secured processing unit) of the merchant's terminal. A unique identifier (uid) is also available to the merchant's terminal. This unique identifier (uid) is generated and signed (for example by the operator of the payment application). The payment application is also installed on the merchant's terminal. These elements (payment application, private key sk and unique identifier uid) can ingeniously be installed at the same time on the merchant's terminal by means of a secured installation process (which can be implemented either online or on site by an accredited technician for example).

[0094] Ultimately, the public key pk (corresponding to the private key sk) is made available in a database, with the unique identifier uid in order to form a pair {public key pk; unique identifier uid}. The pair {pk; uid} is the object of a signature (for example by the operator of the payment application if it is this operator that has signed the unique identifier uid).

[0095] In one specific embodiment, the installation phase is carried out during the installation of a payment application on a merchant's communications terminal (of a smartphone, tablet or computer type), said communications terminal being equipped with a TEE and/or an SE (also called a module V). This embodiment has the advantage in that there is no need to communicate a private key sk to the communications terminal as such: this piece of data is communicated only to the SE or to the TEE. Thus, it is made sure that the communications terminal (and above all any fraudulent applications of this terminal) cannot have access to this private key.

[0096] 5.2.2 Phase of Installation on the User Device Side

[0097] The user device, which is for example a communications terminal of the smartphone or tablet type, is also equipped with an SE or a TEE (acting as a secured processing unit). It may be recalled that, in this embodiment, the customer wishes to make payment with his device. This device therefore has the data needed for making a payment. It may, in one specific embodiment, be bank card data (bearer's name, PAN card number, date of validity, verification code). It may also be other data, depending on the embodiment.

[0098] In the context of the present technique, the installation phase consists of the deposition, in the SE or the TEE of the user's device (also called the module P), of the signature key tk, that is used to do a signature of the signed data (data and uid) transmitted by the merchant's terminal after the user device has verified the validity of the signatures appended by the merchant's terminal.

[0099] This installation can typically be implemented by the installation of a payment application, as is the case with the payment application installed on the merchant's terminal.

[0100] One advantageous possibility is to install this signature key at the same time as a bank application: for example the customer's bank application. Indeed, with the development of bank applications (applications that enable the management of accounts from a smartphone or a tablet), a worthwhile solution both for the customer and for the bank can be to have a bank application that also enables the making of payments. In this case, the data needed for payment are not necessarily bank card data but can be data specifically prepared by the banking application of the bank, or even specifically prepared, at the time of payment, by the financial establishment itself (i.e. by a server to which the customer's bank application is connected).

[0101] To make a payment, in this particular case, the customer opens his bank application; selects the fact that he wishes to make a payment; enters a confidential code if any (or authenticates himself for example by biometric means) and places his device on the merchant's terminal. The bank application reacts to the requests from the merchant's terminal (as explained in the present application) and the payment is made. For the bank, as for the customer, the benefits are real both in terms of security of the transaction (made by the bank application) and in terms of loyalty of the customer (who is no longer required to make payment with a third-party application for which he does not have a guarantee, for example with regard to security and confidentiality of the data transmitted and processed).

[0102] 5.2.3. Execution of the Exchange of Authentication Data

[0103] In this embodiment, the authentication is implemented as follows: [0104] the merchant's terminal (or the module V) transmits the pair {[uid].sub.sk, [data].sub.sk} to the user's device (or the module P); the pair of data {[uid].sub.k, [data].sub.sk} includes [uid].sub.sk which is the unique identifier signed with the key sk and data [data].sub.sk also signed with the key sk; as an alternative, to shorten the processing time, the pair can be directly signed (with only one single signature instead of two signatures); [0105] the user's device (or the module P) uses the unique identifier uid to obtain the public key pk; for example it downloads this public key into a dedicated server or again it searches for this key in an internal database (for example a text file or an xml file) given by the payment application; [0106] the user's device (or the module P) uses the public key pk to verify the validity of the uid signature and data signature; in the event of an error on either of these signatures (for example uid unencrypted is not the uid possessed by the customer), then the customer stops the process (and does not respond to the merchant's terminal; [0107] when both signatures are correct (and when it can he deduced from this that they have been made by the merchant's terminal), the user's device continues the processing operation in signing the data [data] with the key tk and encrypting this signed data with the public key of the merchant's terminal pk: Enc.sub.pk([data].sub.tk); then it transmits this data to the merchant's terminal; [0108] the merchant's terminal takes delivery of the data coming from the user's device, then decrypts this data by means of its private key sk, and verifies the signature of the data. If the signature of the data is incorrect, then the process is stopped; if not the signature is transmitted to the payment processing network.

[0109] Thus, the authentication of data transmitted during a payment operation between a merchant's terminal and a user device in using near field communications (NFC) makes it possible to validate a transaction in a secured manner.

[0110] 5.3. Other Characteristics and Advantages

[0111] Referring to FIG. 3, we describe a communications terminal implemented to carry out an authentication of data in the context of a payment process according to the method described here above.

[0112] For example, the communications terminal, acting as a payment terminal, comprises a memory 31 comprising especially a buffer memory, a general processing unit 32 equipped for example with a microprocessor and managed by a computer program 33, and a secured processing unit 34 (denoted as V here above), managed by a computer program 35, these processing units implementing the method of authentication as described here above to make a payment with a merchant.

[0113] At initialization, the code instructions of the computer program 35 are for example loaded into a memory and then executed by the processor of the secured processing unit 34. The processing unit 34 inputs at least one piece of data to be authenticated. The microprocessor of the secured processing unit 34 implements the steps of the method of authentication according to the instructions of the computer program 35 to give the general processing unit 32 a piece of signed data and, if necessary, a piece of data representing the identifier of the communications terminal (which itself is also signed). The general processing unit 32 carries out a processing of this data to transmit it to a customer's device (for example a smartphone, a tablet) within the framework of a payment transaction.

[0114] To this end, the communications terminal comprises, in addition to the buffer memory 31, communications means such as network communications modules, data transmission means and data transmission circuits for transmission between the various components of the communications terminal.

[0115] These means can take the form of a particular processor implemented within the communications terminal. According to one particular embodiment, this device implements a specific application that is in charge of carrying out the transactions, this application being, for example, provided by the manufacturer of the processor in question in order to enable the use of said processor or by a provider of payment solutions for the “open” terminals. To this end, the processor comprises unique identification means. These unique identification means make it possible to ensure the authenticity of the processor.

[0116] Besides, the device furthermore comprises near field communications means, called NFC, and means of transmission and reception of data coming from the communications network. These means also take the form of communications interfaces enabling exchanges of data on communications networks, interrogation means and means of updating databases.

[0117] Referring to FIG. 4, we describe a user device implemented to carry out an authentication of data within the framework of a payment process, according to the method described here above.

[0118] For example, the user device comprises a memory 41, constituted by a buffer memory, a general processing unit 42, equipped for example with a microprocessor and managed by a computer program 43, and a secured processing unit 44 (denoted as P here above), managed by a computer program 45, these processing units implementing the method of authentication as described here above to make a payment to the merchant.

[0119] At initialization, the code instructions of the computer program 45 are for example loaded into a memory and then executed by the processor of the secured processing unit 44. The secured processing unit 44 inputs at least one piece of data to be authenticated (data signed by the communications terminal) coming from the general processing unit. The microprocessor of the secured processing unit 44 implements the steps of the authentication method, according to the instructions of the computer program 45 to provide the general processing unit 42 with at least one piece of non-signed data. The general processing unit 42 carries out a processing of this data in order to, on the one hand, compare reference data and the data coming from the removal of the signatures and then, if this data is correct, to transmit at least one amongst these pieces of data to the secured processing unit to make a signature of this piece of data with a signature key and encrypt this new piece of signed data with a key of the communications terminal. The secured processing unit transmits this data to the general processing unit which again transmits it to the merchant's communications terminal (for example a smartphone, a tablet).

[0120] To this end, the user device comprises, in addition to the buffer memory 41, communications means such as network communications modules, data transmission means and data transmission circuits for transmission of data between various components of the user device.

[0121] These means can take the form of a particular processor implemented within the user device. According to one particular embodiment, this device implements a specific application that is in charge of the performance of transactions, this application being provided for example by the manufacturer of the processor in question in order to enable the use of said processor or by a provider of payment solutions for “open” terminals. To this end, the processor comprises unique identification means. These unique identification means ensure the authenticity of the processor.

[0122] Besides, the device furthermore comprises near field communications means, called NFC, and means of transmission and reception of data coming from the communications networks. These means also take the form of communications interfaces enabling exchanges of data on the communications networks, interrogation means and means for updating databases.