Method for authenticating an individual for the execution of a transaction on a merchant terminal

Abstract

The present invention relates to a method for authenticating an individual for the execution of a transaction on a merchant terminal (2) connected, via a network (20), to a transaction validation server (3), wherein the method is characterised in that it comprises carrying out, by data processing means (12) for processing the data of a customer terminal (1) of the individual, also connected to the server (3) via the network (20), the steps of: (c) receiving an authentication request to authenticate the individual, transmitted by the merchant terminal (2) via a proximity communication channel between the customer terminal (1) and the merchant terminal (2), wherein the authentication request to authenticate the individual contains a secret key of the server (3); (d) establishing a secure communication channel between the customer terminal (1) and the server (3), referred to as the second secure channel, using the secret key of the server (3); (e) transmitting authentication data for the individual to the server (3), via the second secure channel, in response to the authentication request.

Description

[0001] Description

[0002] Title of the invention: Method for authenticating an individual for the implementation of a transaction on a merchant terminal.

[0003] GENERAL TECHNICAL FIELD

[0004] The present invention relates to the field of card payment. More specifically, it relates to a method for authenticating an individual for the implementation of a transaction on a merchant terminal connected via a network to a transaction validation server.

[0005] STATE OF THE ART

[0006] Payment terminals used by merchants typically require secure communication using symmetric cryptography with a remote server, which involves first sharing a private key or cryptographic material to derive it. To avoid interception, both parties must communicate in a secure environment, and in the case of a physical POS terminal, one option is to preload the private key directly at the factory.

[0007] Alternatively, it is now common to use consumer mobile devices, such as smartphones, as merchant payment terminals, notably by downloading and installing a payment application. It is then necessary to obtain the private key remotely.

[0008] A satisfactory solution is for all distributed applications to have the same code base, and contain a toolbox implementing a "white box" technology (in English "white box" securely hosting the same secret key called initial ("obfuscation" of the key in the code - white box cryptography allows the security of the keys to be guaranteed even if the internal states of the application are visible). This same initial key is used to establish an initial communication with the server, which allows the downloading of cryptographic material to derive other private keys, this time specific to each mobile terminal and to each instantiation of the application.

[0009] This solution is not perfect since if the initial secret key were to be compromised (the white box remains inevitably piercable), all initial communications would be compromised, to the extent that this key is virtually reused in all mobile terminals using the same application, but the security risk is limited by changing the initial key regularly, by updating the application and the contents of its Toolbox.

[0010] However, a so-called "personal PIN pad" configuration is now available in which, in addition to the merchant's mobile terminal, the user can use their own mobile terminal to implement at least part of the transaction, for example entering their PIN, particularly when the contactless payment threshold is exceeded. Such a configuration is very popular because the user has confidence in their terminal, and it improves the hygiene (not touching a third-party terminal) and security (entering their PIN discreetly) of the transaction.

[0011] However, this also involves installing an application on the client terminal and obtaining the private key. However, there are hundreds of times more client terminals than merchant terminals, so the risk of compromising the key existing in the previous solution (common secret key obfuscated in the code of all applications) becomes too high to be manageable by simple updates.

[0012] The present invention improves the situation.

[0013] PRESENTATION OF THE INVENTION

[0014] The present invention therefore relates, according to a first aspect, to a method for authenticating an individual for the implementation of a transaction on a merchant terminal connected via a network to a transaction validation server, the method being characterized in that it comprises the implementation, by data processing means of a client terminal of said individual also connected to the server via said network, of steps of:

[0015] (c) Receiving an authentication request from said individual issued by said merchant terminal via a proximity communication channel between the client terminal and the merchant terminal, said authentication request from said individual containing a secret key from said server;

[0016] (d) Establishment of a secure communication channel between the client terminal and the server, called the second secure channel, using said secret key of said server;

[0017] (e) Transmission of authentication data of said individual to the server, via said second secure channel, in response to said authentication request.

[0018] According to advantageous and non-limiting characteristics:

[0019] Said server secret key is encrypted with a transport key shared between the client terminal and the server, step (d) further comprising the prior decryption of said server secret key.

[0020] Steps (d) and (e) are implemented by means of an application installed on said client terminal, said transport key being buried in the code of said application.

[0021] Step (c) opens the application if it is already installed, and if not, downloads it from the network and then installs it.

[0022] Said authentication request from said individual further contains an authentication token, step (e) comprising the transmission of the token signed with the secret key of the server.

[0023] Said transaction is of the bank card payment type and the authentication request is a request to enter a bank card PIN code on an interface of said client terminal; and said authentication data is data derived from said PIN code.

[0024] Said proximity communication channel between the client terminal and the merchant terminal is not via the network. Said proximity communication channel between the client terminal and the merchant terminal is an optical channel or a near-field radio channel.

[0025] The method comprises the implementation, by data processing means of the merchant terminal, of prior steps of:

[0026] (a) establishing a secure communication channel between the merchant terminal and the server, called the first secure channel;

[0027] (b) Retrieval from the server, via said first secure channel, of said server secret key.

[0028] Step (b) also includes retrieving the authentication token from the server, and step (e) includes verifying by data processing means of the server said signed token.

[0029] Step (b) comprises transmitting to the server a request for a secret key for the client terminal, generating by data processing means of the server said secret key of the server, and if necessary, an authentication token.

[0030] Step (b) comprises encryption by the data processing means of the server with the transport key of said generated server secret key, step (b) preferably also comprises retrieving from the server an identifier of said transport key.

[0031] According to a second aspect, the invention relates to a method for implementing a transaction on a merchant terminal connected via a network to a transaction validation server, comprising the triggering of the transaction by an individual on said merchant terminal then the implementation of the method for authenticating said individual according to the first aspect, step (b) further comprising the transmission to said server of descriptive data of said transaction.

[0032] According to advantageous and non-limiting characteristics:

[0033] Step (b) comprises the determination by the data processing means of the merchant terminal that the authentication of said individual is necessary based on said descriptive data of the transaction. Said transaction is of the contactless bank card payment type, said bank card being dematerialized on the customer terminal, the same near-field radio channel being used for said triggering of the transaction and step (c).

[0034] According to a third aspect, the invention relates to a client terminal of an individual, connected via a network to a transaction validation server, characterized in that it comprises data processing means configured to:

[0035] - Receive, during a transaction on a merchant terminal also connected via the network to the transaction validation server, a request for authentication of said individual sent by the merchant terminal via a proximity communication channel between the client terminal and the merchant terminal, said request for authentication of said individual containing a secret key of said server;

[0036] - Establish a secure communication channel between the client terminal and the server, called the second secure channel, using said secret key of said server;

[0037] - Transmitting authentication data of said individual to the server, via said second secure channel, in response to said authentication request.

[0038] According to a fourth aspect, the invention relates to a set of at least one client terminal according to the third aspect and said merchant terminal, the merchant terminal comprising data processing means configured to:

[0039] - establish a secure communication channel between the merchant terminal and the server, called the first secure channel;

[0040] - Retrieve from the server, via said first secure channel, said secret key of the server. According to advantageous and non-limiting characteristics, the assembly further comprises said transaction validation server.

[0041] According to a fifth and a sixth aspect, the invention provides a computer program product comprising code instructions for executing a method according to the first aspect of authenticating an individual for implementing a transaction on a merchant terminal connected via a network to a transaction validation server or a method according to the second aspect of implementing a transaction on a merchant terminal connected via a network to a transaction validation server;and a storage means readable by computer equipment on which is recorded a computer program product comprising code instructions for the execution of a method according to the first aspect of authenticating an individual for the implementation of a transaction on a merchant terminal connected via a network to a transaction validation server or a method according to the second aspect of implementing a transaction on a merchant terminal connected via a network to a transaction validation server.;

[0042] PRESENTATION OF FIGURES

[0043] Other characteristics and advantages of the present invention will appear on reading the following description of a preferred embodiment. This description will be given with reference to the appended drawings in which:

[0044] [Fig. 1]Figure 1 is a diagram of a system for implementing the method according to the invention;

[0045] [Fig. 2]Figure 2 is a flowchart illustrating the steps of an embodiment of the authentication method according to one aspect of the invention;

[0046] [Fig. 3]Figure 3 schematically represents the implementation of a preferred embodiment of the authentication method according to one aspect of the invention; [Fig. 4]Figure 4 is a flowchart illustrating the steps of an embodiment of the method for implementing a transaction according to another aspect of the invention.

[0047] DETAILED DESCRIPTION

[0048] Architecture

[0049] The present invention relates to a method of authenticating an individual for implementing a transaction on a merchant terminal 2, in a system as represented in FIG. 1, and advantageously the method of implementing the transaction comprising said authentication method.

[0050] Said transaction is initiated by said individual, for the benefit of a merchant who owns the merchant terminal 2. In other words, it is a transaction between said individual and the merchant, validated by said server 3.

[0051] It is of the type of payment by bank card at the said merchant, i.e. a bank card or a mobile terminal (designated customer terminal 1) emulating a bank card (of the individual) is connected to the merchant terminal 2 ensuring the role of electronic payment terminal (EPT). This connection is increasingly often contactless (NFC), but it can still be by inserting the card into a reader.

[0052] The merchant terminal 2 is connected via a network 20 (in particular the Internet network) to a transaction validation server 3, in particular a banking server, generally remote.

[0053] Typically, a bank card payment transaction uses symmetric encryption, i.e. a private key is associated with the bank card (physical or dematerialized), the private key being on the one hand stored directly on the chip of the card if it is physical or in a memory of the terminal if it is dematerialized, and on the other hand stored by the validation server 3. Advantageously, descriptive data of the transaction are entered by the merchant on the merchant terminal 2, and sent to the card / terminal of said individual for affixing of said signature according to the private key, and the server 3 will be able to verify that this signature is valid, and authorize the transaction.

[0054] The customer terminal 1 and the merchant terminal 2 each have data processing means 11, 21 (typically a processor) and data storage means 12, 22 (a memory, for example flash). Each may further comprise an interface (for example a screen), proximity wireless communication means (for example NFC, see below), and a camera. Each of the terminals 1 and 2 (and in particular the merchant terminal) is advantageously a smartphone-type mobile terminal (and the preceding elements such as a camera are usual for any mobile terminal), even if alternatively or in addition the merchant terminal 2 may be a larger terminal (a conventional TPE), notably having a card reader.

[0055] As explained, we also have the validation server 3, typically a banking server, connected to terminals 1 and 2 by the network 20.

[0056] The server 3 also has data processing means 31 (typically a processor) and data storage means 32 (a memory, for example a hard disk).

[0057] Principle

[0058] Authentication means verifying that the individual wishing to carry out the transaction is who they claim to be, i.e. the holder of the card / terminal 1.

[0059] Authentication of said individual may be requested for example:

[0060] - Because the transaction amount exceeds the contactless payment threshold;

[0061] - Because he inserted his card into the merchant terminal 2 even for a smaller amount; - Or simply because the individual / merchant / transaction requires a higher level of protection.

[0062] In a conventional manner, the user can authenticate by entering his PIN code on the merchant terminal 2, but here we are in the context mentioned in the introduction where we wish to use the individual's terminal 1, in particular for questions of trust (the individual trusts his own terminal), confidentiality (he can discreetly type his code) or hygiene (no one other than him touches his terminal).

[0063] Thus, preferably, the authentication consists of entering said PIN code on the client terminal 1, but alternative authentication techniques may be used such as biometric authentication. Furthermore, said authentication may be strong authentication by verifying (in addition to the identity of the user) that the client terminal 1 belongs to the individual via a unique identifier.

[0064] To do this, and as explained, client terminal 1 preferentially uses a dedicated application, traditionally downloaded from a store.

[0065] This method avoids any need to bury a private key in the application code; at best, we may have a buried transport key, which, even if compromised, would not jeopardize communications.

[0066] The proposed solution is to exploit on the one hand the existence of a secure communication channel between the merchant terminal 2 and the server 3, called the first secure channel (by any method of the art including the private key buried in the code of the payment application of the merchant terminal 2 - which we recall is shared only between the merchant terminals 2, which are hundreds of times less numerous than the client terminals 1), and on the other hand the necessary proximity between the merchant terminal 2 and the client terminal 1 during a transaction:

[0067] The private key (called the secret key of server 3) necessary for establishing a secure communication channel between the client terminal 1 and the server 3, called the second secure channel, can thus be transmitted from the server 3 to the client terminal 1 first via the first secure channel, then via a proximity communication channel between the client terminal 1 and the merchant terminal 2, certainly not secure, but almost impossible to intercept since it is only local.

[0068] Process - merchant terminal side

[0069] With reference to figures 2 and 3, the present method begins with an optional preliminary step (a), implemented by the data processing means 21 of the merchant terminal 2, of establishing the secure communication channel between the merchant terminal 2 and the server 3, called the first secure channel (denoted (1) in figure 3).

[0070] This method can be implemented in any known manner, and it is noted that the channel can be established well in advance and that it is not necessary to establish a new first channel at each occurrence of the present method.

[0071] Then, in a step (b) also optional, the data processing means 21 of the merchant terminal 2 retrieve from the server 3 (and for the client terminal 1), via said first secure channel, said secret key of the server 3 which will be used for establishing the second secure channel. Preferably, an authentication token and / or a transport key identifier are retrieved at the same time (see below).

[0072] Note that this step (b) also remains optional, because it is possible that the merchant terminal occasionally retrieves packets of secret keys, or even generates them using cryptographic material provided by server 3.

[0073] According to a preferred embodiment, step (b) is implemented for each transaction requiring authentication and firstly comprises determining that authentication of said individual is necessary, in particular based on said descriptive data of the transaction, whether for example because he has exceeded the contactless payment threshold or because an additional level of security is required (for any reason: merchant policy, customer preference, “sensitive” purpose of the transaction, etc.). Note that authentication could be systematic.

[0074] In all cases, step (b) advantageously comprises the sending of a secret key request for the terminal 1, via said first secure channel, to the server 3 (denoted (2) in FIG. 3). This request can be combined with the usual transmission of descriptive data of said transaction (customer / merchant identifiers, amount, etc., see above).

[0075] In response to this request, the data processing means 31 of the server 3 generate ((3) in figure 3) the secret key and, if applicable, a client token which will, as we will see, be used to establish the second secure channel, potentially randomly (note that we can alternatively have a pre-generated stock of keys).

[0076] Preferably, a transport key is shared between the client terminal 1 and the server 3, in particular by being buried (i.e. stored in an obfuscated manner in accordance with the principles of white box cryptography) in the code of an application of the terminal 1. In this case, said secret key of the server 3 is encrypted by the data processing means 31 of the server 3 with said transport key (which is noted (4) in FIG. 3), which makes it possible to keep it protected and avoid a clear transfer between the merchant terminal 2 and the client terminal 1. Note that there may be several transport keys, hence the idea of ​​attaching an identifier of the transport key (for example a hash).

[0077] In summary, server 3 transfers:

[0078] - The advantageously encrypted secret key

[0079] - Optionally a client authentication token

[0080] - Optionally an identifier of the transport key used to encrypt the secret key.

[0081] Finally, step (b) can include the preparation of said data which has just been received, and in particular the generation of an authentication request for the individual (noted (5) in figure 3), we will see how below. Method - client terminal side

[0082] The main part of the method is then implemented by the data processing means 11 of the client terminal 1.

[0083] In a step (c), the authentication request of said individual issued by said merchant terminal 2 is transmitted via said proximity communication channel between the client terminal 1 and the merchant terminal 2, said authentication request of said individual containing a secret key of said server 3 and, where appropriate, the possible authentication token and / or transport key identifier.

[0084] As explained, we assume that the merchant terminal 2 has determined that the individual must authenticate himself, for example by entering his PIN, but on his own terminal 1. We note that the request has a dual use: it indicates to the client terminal 1 that it must carry out the authentication and it transports the secret key which will allow communication on this subject with the server 3.

[0085] By "proximity communication channel" is meant a short-range communication channel which takes advantage of the fact that the individual must be present and even access the merchant terminal 2 to initiate the transaction (for example by inserting his card), advantageously not passing via the network 20 (although each of the terminals 1 and 2 is for its part connected to the network 20).

[0086] Preferably, said proximity communication channel is a wireless channel in particular chosen from an optical channel and a near-field radio channel, but it could for example simply be a wired channel (by connecting the terminals 1 and 2 by a cable).

[0087] In the “optical channel” embodiment, the authentication request takes the form of a visual signal, in particular a 2D barcode, and in particular a QR code emitted by the merchant terminal 2 (displayed by a screen) and captured by a camera of the customer terminal 1. More precisely, the 2D barcode is displayed and the individual is invited to scan it with his terminal 1.

[0088] In the “near field radio channel” embodiment, the authentication request takes the form of a radio signal, in particular an NFC signal (but it could for example alternatively be Bluetooth, etc.), transferred between terminals 1 and 2 by placing them against each other.

[0089] In a particularly preferred embodiment, contactless payment is coupled with a dematerialized card on the terminal 1 and an authentication request using the same NFC channel:

[0090] - The user brings their terminal 1 close to the merchant terminal 2 to pay contactless (potentially even if the contactless payment limit is exceeded!);

[0091] - The merchant terminal 2 exchanges with the customer terminal 1 via the NFC channel so as to obtain and sign the transaction data in a conventional manner, and determines that authentication of the individual is necessary for this transaction;

[0092] - It implements steps (b) then (c) so as to retrieve the private key from server 3 and transfer the authentication request via the always open NFC channel: these steps were done in a fraction of a second while the two terminals 1 and 2 were close, so that the experience is not more complicated than usual and the user does not make the difference with an ordinary contactless payment.

[0093] Then, the method comprises a step (d) of establishing the secure communication channel between the client terminal 1 and the server 3, called the second secure channel, using said secret key of said server 3. Step (d) comprises in practice (before or after the establishment of the channel) the authentication of the individual (i.e. the processing of the request), as explained by asking him to enter the PIN, the verification of a biometric trait, etc.).

[0094] Preferably and as mentioned, steps (d) and as will be seen (e) are implemented by means of an application installed on said client terminal 1, the possible transport key being, where appropriate, buried in the code of said application. Then (and this whatever the proximity communication channel) step (c) advantageously automatically leads to the opening of said application if it is already installed, or at least its downloading from the network 20 then its installation (noted (6) in figure 3).

[0095] So, to return to the full NFC implementation presented, instead of having end-of-transaction information, the application opens and displays an interface for authenticating the individual (for example, displaying the keyboard for entering the PIN, or requesting verification of the individual's face).

[0096] As regards the establishment of the second secure channel, it may be implemented in any known manner using said secret key of the server 3. For example, in the embodiment in which an authentication token is also transmitted in the request, step (d) may comprise the signing of the token with said private key of the server 3 and the transmission of the signed token to the server 3 (denoted (7) in Figure 3). The latter verifies the signature and the token (by comparison with the key and the token that it transmitted - denoted (8) in Figure 3), and authorizes the establishment of the channel if the verification is conclusive (denoted 9) in Figure 3).

[0097] In any case, step (d) may comprise the prior decryption of said secret key of the server 3 (with the transport key in particular buried in the application - where appropriate identified with the possible transport key identifier transmitted in the authentication request).

[0098] Finally, the method comprises a step (e) of transmitting authentication data of said individual to the server 3, via said second secure channel, in response to said authentication request.

[0099] Authentication data means any evidence of said authentication required by the server 3, for example data derived from said PIN (whether the PIN itself, a hash or cipher of the PIN, proof that a correct PIN was entered, etc.). This may alternatively be data ensuring that a candidate biometric data coinciding with a reference biometric data has been acquired or any other data proving the identity of said individual, etc. Transaction

[0100] According to a second aspect, with reference to figure 4, the invention proposes the method of implementing a transaction on a merchant terminal 2 connected via a network 20 to a transaction validation server 3, as typically explained for a transaction of the bank card payment type.

[0101] This method comprises triggering the transaction by an individual on said merchant terminal 2 (for example by inserting his card into the merchant terminal 2, or approaching it contactlessly), then implementing the authentication method of said individual according to the first aspect.

[0102] For the purpose of implementing the transaction, step (b) further comprises transmitting to said server 3 descriptive data of said transaction.

[0103] If the authentication result is positive, the transaction is successfully processed on the server 3 side, and the method advantageously comprises a step (f) of receiving, from the server 3 (by the client terminal 1 and / or the merchant terminal 2, preferably both) a notification of confirmation of the transaction. Of course, if no authentication data from said individual to the server 3 is transmitted to the server 3 in step (e), or incorrect data, the server 3 rejects the transaction and a notification of failure of the transaction is received. It is also assumed that if the descriptive data of the transaction transmitted in step (b) are incorrect (for example, a false signature indicating a falsified card) or if the transaction is impossible (for example, an unfunded account), we go directly to the notification of failure of the transaction.

[0104] Preferably, step (b) comprises the determination by the data processing means 21 of the merchant terminal that the authentication of said individual is necessary based on said descriptive data of the transaction. If this is indeed the case, then step (b) comprises, as explained, sending to the server the private key request for the client terminal 1 (in addition to the transaction data), and steps (c) to (e) of the method are implemented.

[0105] Otherwise (no authentication of the individual is necessary, for example because it is a simple contactless payment) we go directly to step (f) of receiving a notification of confirmation of the transaction if everything is correct (or failure - see before).

[0106] In a particularly preferred manner, as already mentioned, if said transaction is of the contactless bank card payment type and said bank card is dematerialized on the client terminal 1 (i.e. the transaction is triggered by bringing the client terminal 1 close to the merchant terminal 2), the same near-field radio channel (NFC) is used for said triggering of the transaction and step (c), so that the user is automatically asked for authentication on the client terminal 1.

[0107] Terminals

[0108] According to a third aspect, the invention relates to the client terminal 1 for implementing the method according to the first aspect (authentication).

[0109] Thus, this terminal 1 comprises, as explained, at least data processing means 11 and a memory 12, and advantageously a camera and / or near-field communication means. It is typically a smartphone-type mobile terminal of the individual at the origin of the transaction (the bank card holder).

[0110] The data processing means 11 are configured to implement steps consisting of:

[0111] - Receive, during a transaction on a merchant terminal 2 also connected via the network 20 to the transaction validation server 3, a request for authentication of said individual sent by the merchant terminal 2 via a proximity communication channel between the client terminal 1 and the merchant terminal 2, said request for authentication of said individual containing a secret key of said server 3;

[0112] - Establish a secure communication channel between the client terminal 1 and the server 3, called the second secure channel, using said secret key of said server 3;

[0113] - Transmitting authentication data of said individual to server 3, via said second secure channel, in response to said authentication request.

[0114] According to a fourth aspect, the invention proposes an assembly comprising at least one customer terminal 1 according to the third aspect and the merchant terminal 2.

[0115] This terminal 2 also comprises, as explained, at least data processing means 21 and a memory 22, and advantageously display means and / or near-field communication means, potentially also a card reader. It may also be a mobile terminal of the merchant's smartphone type, or any EFT.

[0116] The data processing means 21 are configured to implement steps consisting of:

[0117] - establish a secure communication channel between the merchant terminal 2 and the server 3, called the first secure channel;

[0118] - Retrieve from server 3, via said first secure channel, said secret key of server 3.

[0119] Said assembly may further comprise said transaction validation server 3.

[0120] This assembly, and in particular the data processing means 11, 21 of the terminals 1, 2, are advantageously also suitable for implementing the method according to the second aspect (of implementing the transaction), i.e. the data processing means 21 of the merchant terminal 2 are also configured to authorize the triggering of the transaction by an individual on said merchant terminal 2. Computer program product

[0121] According to a fifth and a sixth aspect, the invention relates to a computer program product comprising code instructions for the execution (on the data processing means 11, 21 of the terminals 1 and 2) of a method according to the first aspect of authenticating an individual for the implementation of a transaction on a merchant terminal 2 connected via a network 20 to a transaction validation server 3, or of a method according to the second aspect of implementing a transaction on a merchant terminal 2 connected via a network 20 to a transaction validation server 3; as well as storage means readable by computer equipment (for example the data storage means 11, 22 of the terminals 1 and 2) on which this computer program product is found.

Claims

CLAIMS 1. Method for authenticating an individual for the implementation of a transaction on a merchant terminal (2) connected via a network (20) to a transaction validation server (3), the method being characterized in that it comprises the implementation, by data processing means (12) of a client terminal (1) of said individual also connected to the server (3) via said network (20), of steps of: (c) Receiving an authentication request from said individual sent by said merchant terminal (2) via a proximity communication channel between the client terminal (1) and the merchant terminal (2), said authentication request from said individual containing a secret key from said server (3); (d) Establishing a secure communication channel between the client terminal (1) and the server (3), called the second secure channel, using said secret key of said server (3); (e) Transmission of authentication data of said individual to the server (3), via said second secure channel, in response to said authentication request.

2. Method according to claim 1, wherein said secret key of the server (3) is encrypted with a transport key shared between the client terminal (1) and the server (3), step (d) further comprising the prior decryption of said secret key of the server (3).

3. Method according to claim 2, wherein steps (d) and (e) are implemented by means of an application installed on said client terminal (1), said transport key being buried in the code of said application.

4. Method according to claim 3, in which step (c) causes the opening of said application if it is already installed, and otherwise its downloading from the network (20) then its installation.

5. Method according to one of claims 1 to 4, wherein said authentication request of said individual further contains an authentication token, step (e) comprising the transmission of the token signed with the secret key of the server (3).

6. Method according to one of claims 1 to 5, in which said transaction is of the bank card payment type and the authentication request is a request to enter a bank card PIN code on an interface of said client terminal (1); and said authentication data is data derived from said PIN code.

7. Method according to one of claims 1 to 6, wherein said proximity communication channel between the client terminal (1) and the merchant terminal (2) is not via the network (20).

8. Method according to claim 7, wherein said proximity communication channel between the client terminal (1) and the merchant terminal (2) is an optical channel or a near-field radio channel.

9. Method according to one of claims 1 to 8, comprising the implementation, by data processing means (21) of the merchant terminal (2) of prior steps of: (a) establishing a secure communication channel between the merchant terminal (2) and the server (3), called the first secure channel; (b) Retrieving from the server (3), via said first secure channel, said secret key of the server (3).

10. The method of claims 5 and 9 in combination, wherein step (b) also comprises retrieving from the server (3) of the authentication token, and step (e) comprises the verification by data processing means (31) of the server (3) of said signed token.

11. Method according to one of claims 9 and 10, in which step (b) comprises the transmission to the server (3) of a request for a secret key for the client terminal (1), the generation by data processing means (31) of the server (3) of said secret key of the server (3), and if necessary, of an authentication token.

12. Method for implementing a transaction on a merchant terminal (2) connected via a network (20) to a transaction validation server (3), comprising the triggering of the transaction by an individual on said merchant terminal (2) then the implementation of the method for authenticating said individual according to one of claims 9 to 11, step (b) further comprising the transmission to said server (3) of descriptive data of said transaction.

13. Client terminal (1) of an individual, connected via a network (20) to a transaction validation server (3), characterized in that it comprises data processing means (11) configured to: - Receive, during a transaction on a merchant terminal (2) also connected via the network (20) to the transaction validation server (3), a request for authentication of said individual sent by the merchant terminal (2) via a proximity communication channel between the client terminal (1) and the merchant terminal (2), said request for authentication of said individual containing a secret key of said server (3); - Establish a secure communication channel between the client terminal (1) and the server (3), called the second secure channel, using said secret key of said server (3); - Transmitting authentication data of said individual to the server (3), via said second secure channel, in response to said authentication request.

14. Set of at least one customer terminal (1) according to claim 13 and said merchant terminal (2), the merchant terminal (2) comprising data processing means (21) configured to: - establish a secure communication channel between the merchant terminal (2) and the server (3), called the first secure channel; - Retrieve from the server (3), via said first secure channel, said secret key of the server (3).

15. An assembly according to claim 14, further comprising said transaction validation server (3).

16. Computer program product comprising code instructions for executing a method according to one of claims 1 to 11 for authenticating an individual for implementing a transaction on a merchant terminal (2) connected via a network (20) to a transaction validation server (3) or a method according to claim 12 for implementing a transaction on a merchant terminal (2) connected via a network (20) to a transaction validation server (3), when said program is executed on a computer.

17. Storage means readable by computer equipment on which is recorded a computer program product comprising code instructions for the execution of a method according to one of claims 1 to 11 for authenticating an individual for the implementation of a transaction on a merchant terminal (2) connected via a network (20) to a transaction validation server (3) or a method according to claim 12 for implementing a transaction on a merchant terminal (2) connected via a network (20) to a transaction validation server (3).

Images