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

Abstract

The present invention relates to a method for authenticating an individual for implementing 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 of 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 of said individual containing a secret key of 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. Fig. 1;

Description

Title of the invention: Method for authenticating an individual for implementing a transaction on a merchant terminal.

[0001] GENERAL TECHNICAL FIELD

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

[0003] STATE OF THE ART

[0004] Payment terminals used by merchants usually require secure communication by symmetric cryptography with a remote server, involving the prior sharing of a private key or cryptographic material allowing it to be derived. To avoid interception, the two participants must communicate in a secure environment, and in the case of a physical POS terminal, one possibility is to directly preload the private key at the factory.

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

[0006] A satisfactory solution is that all distributed applications have the same code base, and contain a toolbox implementing a "white box" type technology (in English "white box" securely hosting the same so-called initial secret key ("obfuscation" of the key in the code - white box cryptography makes it possible to guarantee the security of the keys even if the internal states of the application are visible).

[0007] 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.

[0008] This solution is not perfect since if the initial secret key were to be compromised (the white box remains inevitably piercable), all of the 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 content of its Toolbox.

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

[0010] 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.

[0011] The present invention improves the situation. PRESENTATION OF THE INVENTION

[0012] 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 (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) Receipt of a request for authentication of said individual issued 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) Establishment of a secure communication channel between the terminal client (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,

[0013] said secret key of the server (3) being 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), steps (d) and (e) being implemented by means of an application installed on said client terminal (1), said transport key being buried in the code of said application, step (c) causing the opening of said application if it is already installed, and otherwise its downloading from the network (20) then its installation, said authentication request of said individual further containing an authentication token, step (e) comprising the transmission of the token signed with the secret key of the server (3), said transaction being of the bank card payment type and the authentication request being a request to enter a bank card PIN code on an interface of said client terminal (1); and said authentication data being data derived from said PIN code, said proximity communication channel between the client terminal (1) and the merchant terminal (2) not being via the network (20), said proximity communication channel between the client terminal (1) and the merchant terminal (2) being an optical channel or a near-field radio channel, said method further comprising the implementation, by data processing means (21) of the merchant terminal (2) of prior steps of: - (a) establishment of a secure communication channel between the terminal merchant (2) and the server (3), called the first secure channel; - (b) Recovery from the server (3), via said first secure channel, of said secret key of the server (3).

[0014] 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.

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

[0016] Step (b) comprises determining by the data processing means of the merchant terminal that authentication of said individual is necessary based on said descriptive data of the transaction.

[0017] 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).

[0018] According to a third and a fourth 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 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. PRESENTATION OF FIGURES

[0019] 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:

[0020] [Fig.l] [Fig.l] is a diagram of a system for implementing the method according to the invention;

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

[0022] [Fig.3] [Fig.3] schematically represents the implementation of a preferred embodiment of the authentication method according to one aspect of the invention;

[0023] [Fig.4] [Fig.4] is a flowchart illustrating the steps of an embodiment of the method for implementing a transaction according to another aspect of the invention. DETAILED DESCRIPTION

[0024] Architecture

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

[0026] 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.

[0027] It is of the type payment by bank card at 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 a 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.

[0028] 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.

[0029] Conventionally, a bank card payment type 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 based on the private key, and the server 3 will be able to verify that this signature is valid, and authorize the transaction.

[0030] 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), having in particular a card reader.

[0031] As explained, there is also the validation server 3, typically a banking server, connected to the terminals 1 and 2 by the network 20.

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

[0033] Principle

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

[0035] Authentication of said individual may be requested for example: - Because the transaction amount exceeds the contactless payment threshold; - 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.

[0036] Conventionally, the user can authenticate himself 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 terminal 1 of the individual, in particular for questions of trust (the individual has confidence in his own terminal), confidentiality (he can discreetly type his code) or hygiene (no one other than him touches his terminal).

[0037] 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. In addition, said authentication can be strong authentication by verifying (in addition to the user's identity) that the client terminal 1 belongs to the individual via a unique identifier.

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

[0039] The present method avoids any need to bury a private key in the application code, at best we possibly have a transport key buried, which even if it were compromised would not jeopardize communications.

[0040] 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:

[0041] The private key (called the secret key of the 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.

[0042] Method - merchant terminal side

[0043] 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 [Fig.3]).

[0044] 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.

[0045] 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).

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

[0047] 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.

[0048] In all cases, step (b) advantageously comprises the transmission 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).

[0049] In response to this request, the data processing means 31 of the server 3 generate ((3) in [Fig.3]) the secret key and, where appropriate, 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).

[0050] 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).

[0051] In summary, server 3 transfers: - The advantageously encrypted secret key - Optionally a client authentication token - Optionally an identifier of the transport key used to encrypt the secret key.

[0052] Finally, step (b) can comprise the preparation of said data which has just been received, and in particular the generation of an authentication request for the individual (denoted (5) in [Fig.3]), we will see how below.

[0053] Method - client terminal side

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

[0055] In a step (c), the authentication request of said individual is transmitted, issued by said merchant terminal 2 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.

[0056] As explained, it is assumed 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. It is noted 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.

[0057] 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).

[0058] 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).

[0059] In the “optical channel” embodiment, the authentication request takes the form of a visual signal, in particular a 2D bar code, 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 bar code is displayed and the individual is invited to scan it with his terminal 1.

[0060] 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 the terminals 1 and 2 by placing them against each other.

[0061] 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: - The user brings their terminal 1 close to the merchant terminal 2 to pay contactless (potentially even if the contactless payment limit is exceeded!); - 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; - 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 the experience is no more complicated than usual and the user does not differentiate it from an ordinary contactless payment.

[0062] 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.).

[0063] 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.

[0064] Then (and whatever the proximity communication channel) step (c) advantageously automatically results in 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 [Fig.3]).

[0065] Thus, to return to the full NFC embodiment 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).

[0066] 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 [Fig. 3]). The latter verifies the signature and the token (by comparison with the key and the token that it transmitted - denoted (8) in [Fig. 3]), and authorizes the establishment of the channel if the verification is conclusive (denoted 9) in [Fig. 3]).

[0067] In all cases, 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).

[0068] 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.

[0069] Authentication data means any proof of said authentication required by the server 3, for example data derived from said PIN code (whether the PIN code itself, a hash or an encrypted version of the PIN code, proof that a correct PIN code has been entered, etc.). This may alternatively be data guaranteeing 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.

[0070] Transaction

[0071] According to a second aspect, with reference to [Fig.4], the invention proposes the method for 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.

[0072] This method comprises the triggering of 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 the implementation of the authentication method of said individual according to the first aspect.

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

[0074] If the result of the authentication 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 false signature which indicates a falsified card) or if the transaction is impossible (for example unfunded account), we go directly to the notification of failure of the transaction.

[0075] 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.

[0076] 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.

[0077] 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).

[0078] 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.

[0079] Terminals

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

[0081] 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).

[0082] The data processing means 11 are configured to implement steps consisting of: - 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 server 3, via said second secure channel, in response to said authentication request.

[0083] 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.

[0084] 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.

[0085] The data processing means 21 are configured to implement steps consisting of: - establish a secure communication channel between the merchant terminal 2 and the server 3, called the first secure channel; - Retrieve from server 3, via said first secure channel, said secret key of server 3.

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

[0087] This assembly, and in particular the data processing means 11, 21 of the terminals 1, 2, are advantageously also for the implementation of the method according to the second aspect (of implementation of 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.

[0088] Computer program product

[0089] According to a fourth and a fifth 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

1. Claims 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) Receipt of a request for authentication of said individual issued by said merchant terminal (2) via a 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); - (d) Establishment of 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, said secret key of the server (3) being 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), steps (d) and (e) being implemented by means of an application installed on said client terminal (1), said transport key being buried in the code of said application, step (c) causing the opening of said application if it is already installed, and otherwise its downloading from the network (20) then its installation, said authentication request from said individual further containing an authentication token, step (e) comprising the transmission of the token signed with the secret key of the server (3), said transaction being of the bank card payment type and the authentication request being a request to enter a bank card PIN code on an interface of said client terminal (1);and said authentication data being data derived from said code; PIN, said proximity communication channel between the client terminal (1) and the merchant terminal (2) not being via the network (20), said proximity communication channel between the client terminal (1) and the merchant terminal (2) being an optical channel or a near-field radio channel, said method further 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) Recovering from the server (3), via said first secure channel, said secret key of the server (3).

2. Method for implementing a transaction on a merchant terminal (2) connected via a network (20) to a transaction validation server (3), comprising triggering the transaction by an individual on said merchant terminal (2) then implementing the method for authenticating said individual according to claim 1, step (b) further comprising transmitting to said server (3) descriptive data of said transaction.

3. Computer program product comprising code instructions for executing a method according to claim 1 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 2 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.

4. 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 claim 1 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 of a method according to claim 2 for implementing a transaction on a merchant terminal (2) connected via a network (20) to a transaction validation server (3).

Images