Method for 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 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 the steps of: (c) Receiving an authentication request 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) Establishing a secure communication channel between the client terminal (1) and the server (3), said 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 the implementation of a transaction on a merchant terminal.

[0001] GENERAL TECHNICAL FIELD

[0002] The present invention relates to the field of card payments. More specifically, it concerns 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.

[0003] STATE OF THE ART

[0004] Payment terminals used by merchants typically require secure communication via symmetric cryptography with a remote server, involving the prior sharing of a private key or cryptographic material enabling its derivation. To prevent interception, the two parties must communicate in a secure environment, and in the case of a physical POS terminal, one possibility is to preload the private key directly at the factory.

[0005] Alternatively, it is now common practice to use consumer mobile devices, such as smartphones, as merchant payment terminals, particularly by downloading and installing a payment application. This requires obtaining the private key remotely.

[0006] A satisfactory solution is for all distributed applications to have the same code base, and to contain a toolbox implementing a "white box" type technology (in English "whitebox" securely hosting the same 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 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 because if the initial secret key were to be compromised (the white box remains inevitably vulnerable), all initial communications would be compromised, since 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.

[0009] 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 complete at least part of the transaction, for example, entering their PIN, particularly when exceeding the contactless payment threshold. This configuration is highly valued because the user trusts their own terminal, and it improves the hygiene (avoiding contact with a third-party terminal) and security (entering the 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 key compromise in the previous solution (a common secret key obfuscated in the code of all applications) becomes too high to be managed by simple updates.

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

[0012] The present invention therefore relates, in 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 the following steps: - (c) Receipt of an authentication request for said individual issued by said merchant terminal (2) via a proximity communication channel between the customer 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 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 server (3), via said second secure channel, in response to said authentication request,

[0013] said server secret key (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 server secret key (3), steps (d) and (e) being implemented by means of an application installed on said client terminal (1), said transport key being embedded in the code of said application, step (c) resulting in the opening of said application if it is already installed, and otherwise its download 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 server's secret key (3), said transaction being a bank card payment and the authentication request being a request to enter a bank card PIN on an interface of said client terminal (1); and said authentication data being data derived from said 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 process further comprising the implementation, by data processing means (21) of the merchant terminal (2), of preliminary steps of: - (a) establishment of a secure communication channel between the terminal merchant (2) and the server (3), called the first secure channel; - (b) Retrieval from the server (3), via said first secure channel, of said server secret key (3).

[0014] According to a second aspect, the invention relates to a method of 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 and then the implementation of the authentication method of 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 features:

[0016] Step (b) includes the determination 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 type contactless bank card payment, 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 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 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; and a computer-readable storage means on which is stored a computer program product comprising code instructions for executing 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 process according to the second aspect of implementing a transaction on a merchant terminal connected via a network to a transaction validation server. PRESENTATION OF THE FIGURES

[0019] Other features and advantages of the present invention will become apparent from the following description of a preferred embodiment. This description will be given with reference to the accompanying drawings in which:

[0020] [Fig.1] [Fig.1] 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 process according to one aspect of the invention;

[0022] [Fig.3] [Fig.3] schematically represents the implementation of a preferred embodiment of the authentication process 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 as represented in [Fig.1], 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 in possession of 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 a payment method using a bank card at the merchant's premises, i.e., a bank card or a mobile terminal (referred to as customer terminal 1) emulating a bank card (belonging to the individual) is connected to the merchant terminal 2, which acts as an electronic payment terminal (EPT). This connection is increasingly contactless (NFC), but it can still be made 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 bank server, generally remote.

[0029] Typically, a bank card payment transaction uses symmetric encryption, meaning that a private key is associated with the bank card (physical or digital). This private key is stored, on the one hand, directly on the card's chip if it is physical, or in the terminal's memory if it is digital, and on the other hand, stored by the validation server. Advantageously, Descriptive transaction data is entered by the merchant on merchant terminal 2, and sent to the card / terminal of said individual for affixing of said signature according to the private key, and 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 (memory, for example flash). Each may also include an interface (for example a screen), wireless proximity 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 mobile terminal such as a smartphone (and the aforementioned elements such as a camera are common for any mobile terminal), although alternatively or in addition the merchant terminal 2 may be a larger terminal (a conventional POS terminal), notably equipped with a card reader.

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

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

[0033] Principle

[0034] Authentication means the verification that the individual wishing to carry out the transaction is indeed who he claims 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 merchant terminal 2 even for a smaller amount; - Or simply because the individual / merchant / transaction requires a higher level of protection.

[0036] In a conventional way, the user can authenticate by entering their PIN code on the merchant terminal 2, but here we are in the context mentioned in the introduction where we want to use the individual's terminal 1, in particular for reasons of trust (the individual trusts their own terminal), confidentiality (they can discreetly type their code) or hygiene (no one other than themselves touches their terminal).

[0037] Thus, preferably, 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 strong authentication can be achieved by verifying (in addition to the user's identity) that 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, downloaded conventionally from a store.

[0039] The present method avoids any need to embed a private key in the application code; at best, there may be an embedded transport key, 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, referred to as the first secure channel (using all available methods, including the private key embedded in the code of the payment application of the merchant terminal 2 - which, it should be noted, is shared only between the merchant terminals 2, which are hundreds of times fewer in number than the customer terminals 1), and on the other hand, the necessary proximity between the merchant terminal 2 and the customer terminal 1 during a transaction:

[0041] The private key (called the secret key of server 3) necessary for the establishment of 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, admittedly not secure, but virtually 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, referred to as the first secure channel (noted (1) in [Fig.3]).

[0044] This method can be implemented in any known way, 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] Next, in an optional step (b), 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 simultaneously (see below).

[0046] Note that this step (b) also remains optional, as it is possible that the merchant terminal may occasionally retrieve packets of secret keys, or even generate them using cryptographic hardware provided by server 3.

[0047] According to a preferred embodiment, step (b) is implemented for each transaction requiring authentication and first includes determining that authentication of the individual in question is necessary, particularly based on the transaction's descriptive data, for example, because they have exceeded the contactless payment threshold or because an additional level of security is required (for any reason: merchant policy, customer preference, sensitive nature of the transaction, etc.). It should be noted that authentication could be systematic.

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

[0049] In response to this request, the data processing means 31 of server 3 generate ((3) in [Fig.3]) the secret key and, where applicable, a client token which will, as we shall 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 obfuscated in accordance with the principles of white-box cryptography) in the code of an application on the terminal 1. In this case, the secret key of the server 3 is encrypted by the data processing means 31 of the server 3 with the transport key (which is noted (4) in [Fig. 3]), which keeps it protected and prevents a transfer in plaintext between the merchant terminal 2 and the client terminal 1. Note that there can 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 secret key, advantageously encrypted - Optionally, a customer authentication token - Optionally, an identifier of the transport key used to encrypt the secret key.

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

[0053] Method - customer terminal side

[0054] The main part of the process 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 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 applicable the 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 purpose: it indicates to the client terminal 1 that it must perform the authentication and it carries the secret key which will allow communication on this subject with the server 3.

[0057] By "proximity communication channel" we mean 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 their card), advantageously not passing through the network 20 (although each of the terminals 1 and 2 is on its side connected to the network 20).

[0058] Preferably, said proximity communication channel is a particular wireless channel chosen from an optical channel and a near-field radio channel, but it could, for example, simply be a wired channel (by connecting 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 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 specifically, the 2D barcode is displayed and the individual is invited to scan it with their 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 alternatively be Bluetooth, etc.), transferred between terminals 1 and 2 by placing them against each other.

[0061] In a particularly preferred embodiment, contactless payment with a dematerialized card on terminal 1 and authentication request are combined using the same NFC channel: - The user brings their terminal 1 close to the merchant terminal 2 to pay without contact (potentially even if the contactless payment limit is exceeded!); - Merchant terminal 2 exchanges with customer terminal 1 via the NFC channel in order to obtain and sign transaction data in a conventional manner, and determines that authentication of the individual is required 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 together, so that the experience is no more complicated than usual and the user does not notice the difference with an ordinary contactless payment.

[0062] Next, the process includes a step (d) of establishing the secure communication channel between the client terminal 1 and the server 3, referred to as the second secure channel, using said secret key of said server 3. Step (d) includes 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 (e) are implemented by means of an application installed on said client terminal 1, the possible transport key being, where appropriate, embedded in the code of said application.

[0064] Then (and this regardless of the proximity communication channel) step (c) advantageously automatically leads to the opening of said application if it is already installed, or at least its download from network 20 and then its installation (noted (6) on [Fig.3]).

[0065] Thus, to return to the full NFC embodiment presented, instead of having an end-of-transaction information, the application opens and displays an individual authentication interface (for example, displaying the keyboard for entering the PIN, or requesting face verification of the individual).

[0066] As regards the establishment of the second secure channel, it can be implemented in any known way using said secret key of server 3. For example, in the embodiment in which an authentication token is also transmitted in the request, step (d) can include signing the token with said private key of server 3 and transmitting the signed token to server 3 (noted (7) in [Fig. 3]). The latter verifies the signature and the token (by comparison with the key and token it transmitted - noted (8) in [Fig. 3]), and authorizes the establishment of the channel if the verification is successful (noted (9) in [Fig. 3]).

[0067] In all cases, step (d) may include prior decryption of said secret key of server 3 (with the transport key in particular embedded in the application - where appropriate identified with the possible transport key identifier transmitted in the authentication request).

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

[0069] Authentication data means any proof of said authentication required by 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 has been entered, etc.). Alternatively, it may be data guaranteeing that candidate biometric data coinciding with 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 of implementing a transaction on a merchant terminal 2 connected via a network 20 to a transaction validation server 3, as typically explained, a transaction of the type payment by bank card.

[0072] This process includes triggering the transaction by an individual on said merchant terminal 2 (for example by inserting their card into the merchant terminal 2, or approaching it in contactless mode), then implementing the authentication process of said individual according to the first aspect.

[0073] In order to implement the transaction, step (b) further includes the transmission to said server 3 of descriptive data of said transaction.

[0074] If the authentication result is successful, the transaction is processed correctly on the server 3 side, and the process advantageously includes a step (f) of receiving a transaction confirmation notification from server 3 (via the client terminal 1 and / or the merchant terminal 2, preferably both). Of course, if no authentication data for the individual in question is transmitted to server 3 in step (e), or if the data is incorrect, server 3 rejects the transaction and a transaction failure notification is received. It is also assumed that if the transaction description data transmitted in step (b) is incorrect (for example, a forged signature indicating a counterfeit card) or if the transaction is impossible (for example, an insufficient account), the process proceeds directly to the transaction failure notification.

[0075] Preferably, step (b) includes the determination by the data processing means 21 of the merchant terminal that authentication of said individual is necessary based on said descriptive data of the transaction.

[0076] If this is indeed the case, then step (b) includes, as explained, sending the private key request for client terminal 1 to the server (in addition to the transaction data), and steps (c) to (e) of the process are implemented.

[0077] Otherwise (no authentication of the individual is necessary, for example because it is a simple contactless payment) we proceed directly to step (f) of receiving a notification confirming the transaction if everything is good (or of failure - see above).

[0078] In a particularly preferred manner, as already mentioned, if said transaction is of the type contactless bank card payment and said bank card being dematerialized on the customer terminal 1 (i.e. the transaction is triggered by bringing the customer 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 on the customer terminal 1 for authentication.

[0079] Terminals

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

[0081] Thus, this terminal 1 comprises, as explained, at least data processing means 11 and memory 12, and advantageously a camera and / or near-field communication means. It is typically a mobile terminal such as a smartphone belonging to the individual initiating the transaction (the cardholder).

[0082] The data processing means 11 are configured to implement steps consisting of: - To receive, during a transaction on a merchant terminal 2 also connected via network 20 to the transaction validation server 3, an authentication request for said individual issued by the merchant terminal 2 via a proximity communication channel between the client terminal 1 and the merchant terminal 2, said authentication request for said individual containing a secret key for said server 3; - Establish a secure communication channel between client terminal 1 and server 3, called the second secure channel, using said secret key of said server 3; - Transmit 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 includes, as explained above, at least data processing means 21 and memory 22, and advantageously display means and / or near-field communication means, potentially also a card reader. It may also be a mobile terminal such as a merchant's smartphone, or any POS terminal.

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

[0086] Said assembly may further include 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 process 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 allow 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 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 computer-readable storage means (for example the data storage means 11, 22 of terminals 1 and 2) on which this computer program product is found.

Claims

1. Demands 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 the following steps: - (c) Receipt of an authentication request from said individual issued by said merchant terminal (2) via a proximity communication channel between the customer 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 server secret key (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 server secret key (3), steps (d) and (e) being implemented by means of an application installed on said client terminal (1), said transport key being embedded in the code of said application, step (c) entailing the opening of said application if it is already installed, and otherwise its download from the network (20) and 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 server secret key (3), said transaction being of the type payment by bank card 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 customer terminal (1) and the merchant terminal (2) not being via the network (20), said proximity communication channel between the customer terminal (1) and the merchant terminal (2) being an optical channel or a near field radio channel, said process 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 merchant terminal (2) and the server (3), said first secure channel; - (b) Retrieval from the server (3), via said first secure channel, of said server (3) secret key.

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

3. Product computer program comprising code instructions for executing a method according to claim 1 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 a method according to claim 2 of 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. Computer-readable storage means on which is recorded a computer program product comprising code instructions for the execution of a method according to claim 1 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 claim 2 of implementing a transaction on a merchant terminal (2) connected via a network (20) to a transaction validation server (3).

Images