Method for authenticating payment data, corresponding devices and programs

Abstract

A method for authenticating data, implemented during a payment transaction between a merchant's communications terminal and a user device of the type including authentication by the communications terminal of at least one message generated by the user device, by using near field communications wireless data. The method includes the following acts by the user's device: obtaining an authentication code from the message, a piece of random data and a hash function; obtaining a first signature component from the message, the random piece of data, a public key of the communications terminal, a first private key of the user device and the authentication code; obtaining a second signature component from the message, the random piece of data, the public key of the communications terminal, a second private key of the user device and the authentication code; and transmitting the authentication code and of the two signature components to the communications terminal.

Claims

1. A method of authenticating at least one piece of data, implemented during a payment transaction taking place between a communications terminal and a user device of the type comprising authentication by the communications terminal of at least one message m generated by the user device, by using a near field communications wireless data link, the method comprising the following acts performed by the user device: calculating an authentication code S.sub.1 from the message m, a piece of random data t and a hash function H; calculating a first signature component S.sub.2 from the message m, the random piece of data t, a public key Z of the communications terminal, a first private key x of the user device and from the authentication code S.sub.1; calculating a second signature component S.sub.3 from the message m, the random piece of data t, the public key of Z of the communications terminal, a second private key y of the user device and from the authentication code S.sub.1; and transmitting, to the communications terminal, the authentication code S.sub.1 and the two signature components S.sub.2 and S.sub.3.

2. The method of authentication according to claim 1, comprising the following acts performed by the communications terminal: obtaining a first reference value denoted as U.sub.[r1] from the first signature component S.sub.2, a public key X of the user device, a private key z of the communications terminal and the authentication code S.sub.1; obtaining a second reference value denoted as U.sub.[r2] from the second signature component S.sub.3, a public key Y of the user device, the private key z, and the authentication code S.sub.1; and verifying that the first reference value U.sub.[r1] is equal to the second reference value U.sub.[r2]; and, when the two values are equal: verifying that the value H(U.sub.[r2]) and/or H(U.sub.[r1]) is equal to S.sub.1; and issuing an assertion of authentication when the preceding verification step is positive.

3. The method of authentication according to claim 2, comprising, for said communications terminal and prior to the communications terminal obtaining a first reference value, a phase of determining a set of encryption parameters performed by the communication terminal comprising: obtaining a Schnorr group (G) and a generator of this group (g); obtaining the private key (z), said private key being an element of the group G; computing, from the private key (z), of a public key Z such that Z is an exponentiation of the generator g by the private key z, Z=gz.

4. The method of authentication according to claim 3, wherein: the act of obtaining the first reference value U[r1] implements the following computation: U[r1]=s2Xzs1; the act of obtaining the second reference value U[r2] implements the following computation: U[r2]=s3Yzs1.

5. The method of authentication according to claim 1, comprising, for said user device, prior to the user device obtaining an authentication code, a phase of determining a set of encryption parameters performed by the user device comprising: obtaining a Schnorr group (G) and a generator of this group (g); obtaining the first private key (x), said private key being an element of the group G; obtaining the second private key (y), said private key being an element of the group G; computing, from the first private key (x), of a public key X such that X is an exponentiation of the generator g by the private key x, X=gx; computing, from the first private key (y), of a public key Y such that Y is an exponentiation of the generator g by the private key y, Y=gy.

6. The method of authentication according to claim 5, wherein: the act of obtaining the authentication code S.sub.1 implements the following computation: S.sub.1=H(mt), where is the concatenation operator; the act of obtaining the first signature component S.sub.2 implements the following computation: S2=(mt).Math.Z.Math.x.Math.S.sub.1; the act of obtaining the second signature component S.sub.3 implements the following computation: S.sub.3=(Mt).Math.Z.Math.y.Math.S.sub.1.

7. A user device comprising: a general processing unit; a memory; a secured processing unit; a secured memory; and at least one reconfigurable circuit formed by the general processing unit and the secured processing unit for processing payment transactions with a communications terminal, said reconfigurable circuit configuring the user device to perform acts comprising: calculating an authentication code S.sub.1 from the message m, a piece of random data t and a hash function H; calculating a first signature component S.sub.2 from the message m, the random piece of data t, a public key Z of the user terminal, a first private key x of the user device and the authentication code S.sub.1; calculating a second signature component S.sub.3 from the message m, the random piece of data t, the public key Z of the communications terminal, a second private key y of the user device and the authentication code S.sub.1; and transmitting, to the communications terminal, the authentication code S.sub.1, and the two signature components S.sub.2 and S.sub.3.

8. 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 user's device during a payment transaction taking place between a communications terminal and the user device of the type comprising authentication by the communications terminal of at least one message m generated by the user device, by using a near field communications wireless data link, the method comprising the following acts performed by the user device: calculating an authentication code S.sub.1 from the message m, a piece of random data t and a hash function H; calculating a first signature component S.sub.2 from the message m, the random piece of data t, a public key Z of the communications terminal, a first private key x of the user device and the authentication code S.sub.1; calculating a second signature component S.sub.3 from the message m, the random piece of data t, the public key of Z of the communications terminal, a second private key y of the user device and the authentication code S.sub.1; and transmitting, to the communications terminal, the authentication code S.sub.1 and the two signature components S.sub.2 and S.sub.3.

Description

4. FIGURES

(1) 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!

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

(3) FIG. 2 is a block diagram of the proposed technique performing a signature of data within the merchant's communications terminal;

(4) FIG. 3 is a schematic representation of the merchant's communications terminal according to the present invention;

(5) FIG. 4 schematically describes a user device according to the present invention.

5. DESCRIPTION

(6) 5.1. General Principle

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

(8) Conventionally, when a payment transaction is made between a merchant's terminal and a user device, a challenge/response type of process is implemented so that the merchant's terminal will identify (authenticate) the user device (and vice versa) by means of the exchange of a message m. The present technique makes it possible to do without a scheme of this kind. It is thus no longer necessary to carry out a challenge-response type process. The technique implemented is therefore not a challenge-response type technique (which is an interactive process); nor is it a new signature (which can be publicly verified); nor is it a message authentication code (which is not possible except in the case of the sharing of a secret key).

(9) More particularly, the approach chosen by the present technique is that of seeing to it that the user's device can prove that it has legitimately signed the message m (the data) to be authenticated without in any way thereby having to transmit this message (the message can for example be known on either side: by the merchant's terminal and by the user device). Thus, instead of signing the message conventionally and transmitting it (i.e. transmitting the signed message), a strategy of transmission of proof of signature of this message is adopted (this strategy can be complementary either to the transmission of this message or to the sharing of the knowledge of the message between the merchant's terminal and the user's device).

(10) 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 ElementSE or a Trusted Execution EnvironmentTEE 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 that can even be remote, i.e. not present in the terminal). It is also assumed that there is a payment application in 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.

(11) In general, the present technique combines the principle of Schnorr signatures and of the exchange of Diffie-Hellman keys (on the assumption of an absence of a computational solution). However, unlike in the case of Schnorr signatures (which comprise a pair of data), the technique implemented uses a signature comprising a triplet of data.

(12) The use of such a triplet, instead of a pair (as defined in the Schnorr signature), enables the creation (in a secured manner) of an additional restriction: only one particular intended recipient can verify the signature (except in the case of Schnorr signatures which are publicly verifiable).

(13) Besides, unlike in the conventional Schnorr method, the technique relies on the use of a pair of private keys and a pair of public keys, which are made available to the user device (and/or the proof module).

(14) Referring to FIGS. 1 and 2, we shall now describe the proposed technique authenticating data between a merchant's communications terminal and a user device.

(15) As explained here above, it is assumed that V and P each have, by their own means, obtained knowledge of the data to be authenticated (the message m). During the joint implementation of payment applications TPC and DU, the method implemented is on the whole the following: the module P computes (10) an authentication code S.sub.1 from the message m, a piece of random data t and a hash function H; the module P computes (20) a first signature component S.sub.2 from the message m, the piece of random data t, a public key Z of V, a first private key x of P and the authentication code S.sub.1; the module P computes (30) a second signature component S.sub.3 from the message m, the piece of random data t, the public key of V, a second private key of P and the authentication code S.sub.1; the module P transmits (40) the authentication code S.sub.1, and the two signature components S.sub.2 and S.sub.3 to the merchant's terminal (or to the module V).

(16) These steps, performed on the user device (or the module P), are implemented on the basis firstly of private keys (two private keys) available to the user device and one public key of the merchant's terminal. In this example, it is assumed that m is known on both sides beforehand and it is only the random value t that is transmitted, with (S.sub.1, S.sub.2, S.sub.3) that signs the message.

(17) The public key of the merchant's terminal is either transmitted by the merchant's terminal at the initialization of the payment transaction or obtained for example from a database accessible from the user device. The piece of random data t is, for its part, unilaterally chosen by the user device. It goes without saying that this public key should, according to good practice, be certified by a recognized authority. However, this is not necessary for the operation of the invention and is not even useful in certain applications. The public key used for the intended recipient of the signature is not necessarily the public key of the merchant's terminal. It could for example be that of the payment processor (the module V), and then the terminal would only relay the information.

(18) From the data received (S.sub.1, S.sub.2 and S.sub.3), the merchant's terminal (or the module V, or a remote intended recipient), will verify (in carrying out a computation on this data) that it is truly synonymous with knowledge (by the user device or by P) of the message m.

(19) To this end, the merchant's terminal (or the module V): computes (50) a first reference value denoted as U.sub.[r1] from the first signature component S.sub.2, the public key X (corresponding to the private key x), its own private key z, and the authentication code S.sub.1; computes (60) a first reference value denoted as U.sub.[r1] from the second signature component S.sub.3, the public key Y (corresponding to the private key y), its own private key z, and the authentication code S.sub.1; verifies (70) the first reference value U.sub.[r1] is equal to the second reference value U.sub.[r2];

(20) and, when the two values are equal: verifies (80) that the value H(U.sub.[r2]) is equal to S.sub.1.

(21) When the verification step (80) is positive, the method delivers an assertion of authentication. Depending on the result of this verification, the communications terminal transmits (90) a piece of transaction validation data to the payment transaction processing system (STTP).

(22) Thus, when the two previous verifications are true, it is deduced therefrom that the user device (or the module P) knows the message m. To implement the method as described here above, in the context of a payment operator acting between the user device and the merchant's terminal, according to the present invention, only two elements need to be available (in common): the hash function H: this hash function is used by the module P to compute the first authentication code S.sub.1 and by the module V to verify that the hashing of U.sub.[r2] is equal to the first authentication code S.sub.1; the module V and the module P therefore share knowledge of this hash function; pairs of {public keys; private keys} that are used to create the signature elements; the message m: the message m is determined by the merchant's terminal and y the user's device.

(23) Using the proposed technique, it is not necessary for the user device to transmit the value of this message m to the merchant's terminal: it is enough for the user device to transmit proof that it has knowledge of this message. Since the message m does not travel through the network, it cannot be intercepted and modified. It is therefore not possible to modify the components of the payment transaction.

(24) Besides, through this technique, only the merchant's terminal (or the module V) is capable of verifying the validity of the data transmitted by the user device (or the module P). In addition, it is not even necessary for the merchant's terminal (or the module V) to have the message m available. Indeed, in the proposed technique, the message m is not used by the merchant: only the authentication code S.sub.1 is used. This means that the authentication code S.sub.1 can be used as proof of the validity of the payment transaction without the merchant's terminal needing to know this message. Thus, depending on the embodiment, the message authentication code S.sub.1 takes the position of the authentication codes conventionally used in payment protocols and more particularly in payment protocols implemented in the context of EMV specifications. It will be understood, on reading the above, that the methods implemented both in the merchant's terminal and in the user device are independent. It will also be understood that the merchant's terminal and the user device are independent of one another. This means that it is possible to implement the methods and devices described in a system that will include a user device and a merchant's terminal carrying out a payment transaction.

(25) 5.2 Embodiment

(26) In this purely illustratory embodiment, the proposed technique consists especially of a modification of the Schnorr signatures adapted for two users (merchant's terminal and user device). The security of the proposed technique is especially based on the Decisional Diffie-Hellman Assumption (DDH) which is an assumption on the hardness of computation based on cyclic groups.

(27) In this embodiment, prior to the implementing of the secured exchange protocol, it is assumed that two installation phases have been carried out: one on the merchant's terminal side and one on the user's device side.

(28) To begin with, the proposed technique is implemented on the basis of a group G suited to the problems and issues related to Schnorr signatures, with a generator g.

(29) A Schnorr group is a sub-group of Z.sub.p.sup.x, the multiplier group of integers modulo p for a prime number p. To generate such a group, we generate p, q, and r such that p=qr+1, with p and q being prime numbers. To obtain the generator g of this group, the following method is applied: For each integer h strictly greater than 1 and strictly smaller than p: if h.sup.r1 (mod p) then go to the next integer; else, the value g=h.sup.r (mod p) is a generator that is a sub-group of Z.sub.p.sup.x of order q;

(30) This group thus possesses a given size. The size of this group and its other parameters are typically determined beforehand. In one particular embodiment, the size of the group G is of the order of 2.sup.1024 (number 2 to the power of 1024): this means that the size of the prime number p is of the order of 2.sup.1024.

(31) In this embodiment, the group G and the corresponding generator g has undergone a preliminary parameter-setting both in the customer's device and in the merchant's terminal. This preliminary parameter-setting can have been done for example before the installation of the payment application on the merchant's terminal side or of the payment application on the customer's device side.

(32) In other embodiments, this parameter-setting is carried out during the payment transaction. The merchant's terminal and the user's device agree on the parameters of the group. In this case, given the fact that the group is renegotiated at each transaction, the size of this group may be reduced or limited for example by half (2.sup.512) or more (2.sup.256).

(33) 5.2.1 Phase of Installation on the User Device Side

(34) 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 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.

(35) 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 private keys x and y, used to construct the signatures elements.

(36) 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.

(37) From this group G and the selected generator g: the user device (or the proof module P) obtains or generates a private key comprising two prime integer numbers (x,y) and, on the basis of this private key, computes a public key (X,Y), in which: X=g.sup.x; Y=g.sup.y;

(38) Thus, in this embodiment, the two prime integer numbers (x,y) each constitute a private key of the user device while the two integer numbers X and Y each constitute the public key corresponding to these two private keys.

(39) In this embodiment, the two pairs of private keys/public keys have undergone a preliminary parameter-setting operation in the customer's device. This preliminary parameter-setting operation can have taken place for example before the installation of the payment application on the user device side.

(40) In other embodiments, the selection of these keys is done during the payment transaction. Before initiating the payment transaction, the user device chooses its pairs {private keys/public keys}, on the basis of the group G and the generator g. When the set of parameters is negotiated at the time of the transaction (Group G, generator g, public keys and private keys), the sizes of these parameters can advantageously be reduced because of the relative uniqueness of these parameters in themselves: indeed they are used only for a transaction, thus substantially limiting the possibilities of fraud on the part of an attacker.

(41) One advantageous possibility is to install these keys (and group parameters) 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 pieces of 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).

(42) 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 document) 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 fostering the 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 the security and confidentiality of the data transmitted and processed).

(43) For implementing this technique, it is important that the merchant's terminal should have knowledge of the public keys X and Y: either the user device provides these keys during the transaction or the merchant's terminal is capable of obtaining these keys from a trusted third party. In the latter case, according to the present invention, the user's device has available an unique identifier (Uid), which is associated, for the trusted third party, with two public keys X and Y. When the merchant's terminal wishes to obtain these public keys, it sends the trusted third party a request for obtaining keys on the basis of the identifier (Uid) of the user's device. Prior to this transmission, the user device has transmitted its unique identifier to the merchant's terminal (for example during the initializing of the transaction).

(44) 5.2.2 Phase of Installation on the Merchant's Terminal Side

(45) From this group G and the selected generator g: the merchant's terminal (or the verification module V) obtains or generates a private key z, (random integer prime number) and on the basis of this private key, computes a public key Z, such that: Z=g.sup.z;

(46) In this embodiment, the private key/public key pair has undergone a preliminary parameter-setting operation in the merchant's terminal. This preliminary parameter-setting operation can have been carried out for example before the installation of the payment application on the merchant's terminal side.

(47) As above, in other embodiments, the selection of these keys can be done during the payment transaction.

(48) In the same way, as above, the user device can obtain knowledge of the public key Z of the merchant's terminal. Either the merchant's terminal transmits this key directly to the customer device or the customer device uses a unique identifier of the merchant's terminal (Cid) to obtain this public key from a trusted third party.

(49) In one specific embodiment, the installation phase is carried out during the installation of a payment application on a communications terminal (of the smartphone, tablet or computer type) of the merchant, said communications terminal being equipped with a TEE and/or a SE (also called a module V). This embodiment has the advantage of not needing to communicate the private key z 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 the fraudulent applications, if any, of this terminal) cannot have access to this private key.

(50) 5.2.3. Running of the Authentication

(51) In this embodiment, the authentication is implemented as follows: the module P carries out a conversion of the message m into numerical form so that this message m corresponds to an element of the group G: to this end, the message m is converted into binary form (binary representation of the message m) and the binary form is used to obtain a digital form corresponding to an element of the group G; other methods can be envisaged depending on applications; the module P randomly (or pseudo-randomly) selects an element t of the group G; the module P computes an authentication code S.sub.1 from the message m, the piece of random data t and the hash function H according to the following formula:
S.sub.1=H(mt), where is the concatenation operator; the module P computes the first signature component S.sub.2 from the message m, the random data t, the public key Z, the first private key x of P and the authentication code S.sub.1, according to the following formula:
S.sub.2=(mt)Z.sup.xs1 the module P computes the second signature component S.sub.3 from the message m, the random data t, the public key Z, the second private key y of P and the authentication code S.sub.1;
S.sub.3=(mt)Z.sup.ys1 the module P transmits the authentication code S.sub.1, and the two signature components S.sub.2 and S.sub.3 to the merchant's terminal (or the module V).

(52) Thus, the user device has not transmitted the message m, or even a signed version of this message m because this message m has been concatenated with a random value (t), before being hashed to produce S.sub.1. This means that a hacker who might intercept for example the authentication code S.sub.1 cannot, on the basis of this code, infer the content of the message m.

(53) The methods for computing the values S.sub.1, S.sub.2 and S.sub.3 use x and y (which are private and therefore known to the signing party alone, i.e. the user device) and Z (which is the public key of the intended recipient, i.e. the payment terminal). Essentially, S.sub.2 and S.sub.3 are quantities created from these three pieces of information and the message m. The exponentiation ensures the protection of the private keys and the multiplication of the message by the exponentiated quantity protects its content.

(54) For its part, the merchant's terminal receives the data S.sub.1, S.sub.2 and S.sub.3. From these pieces of data, it will determine (with reasonable doubt) that they truly correspond to the results of computations made on the basis of the message m.

(55) To this end, the merchant's terminal implements the following steps: computing a first reference value denoted as U.sub.[r1] from the first signature component S.sub.2, the public key X (corresponding to the private key x), its own private key Z, and the authentication code S.sub.1
U.sub.[r1]=s.sub.2X.sup.zs1 Computing a second reference value denoted as U.sub.[r2 from the second signature component S.sub.3, the public key Y (corresponding to the private key y), its own private key Z, and the authentication code S.sub.1,];
U.sub.[r2]=s.sub.3Y.sup.zs1 verifying that the first reference value U.sub.[r2] is equal to the second reference value U.sub.[r2];

(56) and, when the two values are equal: verifying that the value H(U.sub.[r2]) is equal to S.sub.1.

(57) If the value of H(U.sub.[r2]) is equal to S.sub.1, then the merchant's terminal has information of sufficient certitude available to estimate that the user's device is truly in possession of the message m and that this message is authentic. This means that the merchant's terminal can terminate the transaction (for example it can transmit S.sub.1 to the payment system to validate the transaction).

(58) Explained in another way, the merchant's terminal carries out the following computations:
U.sub.[r1]=s.sub.2X.sup.zs1=(mt)Z{circumflex over ()}(x S1)X{circumflex over ()}(z S1)=(mt)g{circumflex over ()}(z x S1)g{circumflex over ()}(z x S1)=(mt)
and
U.sub.[r2]=s.sub.3Y.sup.zs1=(mt)Z{circumflex over ()}(y S1)=[mt)g{circumflex over ()}(yz S1)g{circumflex over ()}(yz S1)=(mt)

(59) Thus, the authentication of the 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.

(60) 5.3. Other Characteristics and Advantages

(61) 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.

(62) 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 to a merchant.

(63) 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 secured processing unit 34 inputs at least one authentication code and two signature elements. 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 data representing the validation of transaction and, as the case may be, to transmit a piece of transaction validation data to a processing system. The general processing unit 32 processes this data and transmits it to a customer's device, for example a smartphone, a tablet) in the context of a payment transaction.

(64) 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.

(65) 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.

(66) Besides, the device furthermore comprises near field communications means, called NFC means, 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.

(67) Referring to FIG. 4, we describe a user device implemented to carry out an authentication of data in the context of a payment process according to the method described here above.

(68) For example, the user device comprises a memory 41 comprising especially 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 a merchant.

(69) 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 a message m of which it is necessary to prove knowledge. The microprocessor of the secured processing unit 44 implements the steps of the method of authentication according to the instructions of the computer program 45 to give the general processing unit 42, at least one authentication code and two signature elements to be transmitted to a merchant's terminal. The general processing unit 42 carries out the transmission of this data.

(70) 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 between the various components of the communications terminal.

(71) 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 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 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.

(72) Besides, the device furthermore comprises near field communications means, called NFC means, 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