[go: up one dir, main page]

WO2025125562A1 - Procédé d'authentification d'un individu pour la mise en œuvre d'une transaction sur un terminal marchand - Google Patents

Procédé d'authentification d'un individu pour la mise en œuvre d'une transaction sur un terminal marchand Download PDF

Info

Publication number
WO2025125562A1
WO2025125562A1 PCT/EP2024/086204 EP2024086204W WO2025125562A1 WO 2025125562 A1 WO2025125562 A1 WO 2025125562A1 EP 2024086204 W EP2024086204 W EP 2024086204W WO 2025125562 A1 WO2025125562 A1 WO 2025125562A1
Authority
WO
WIPO (PCT)
Prior art keywords
server
transaction
individual
terminal
merchant terminal
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
PCT/EP2024/086204
Other languages
English (en)
Inventor
Maxime SCHADKOWSKI
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Banks and Acquirers International Holding SAS
Original Assignee
Banks and Acquirers International Holding SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Banks and Acquirers International Holding SAS filed Critical Banks and Acquirers International Holding SAS
Publication of WO2025125562A1 publication Critical patent/WO2025125562A1/fr
Pending legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/42—User authentication using separate channels for security data
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/20—Point-of-sale [POS] network systems
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G06Q20/3276—Short range or proximity payments by means of M-devices using a pictured code, e.g. barcode or QR-code, being read by the M-device
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/352—Contactless payments by cards
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3825—Use of electronic signatures
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4012—Verifying personal identification numbers [PIN]
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/42—Confirmation, e.g. check or permission by the legal debtor of payment
    • G06Q20/425—Confirmation, e.g. check or permission by the legal debtor of payment using two different networks, one for transaction and one for security confirmation
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/0873—Details of the card reader
    • G07F7/088—Details of the card reader the card reader being part of the point of sale [POS] terminal or electronic cash register [ECR] itself
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/0873—Details of the card reader
    • G07F7/0893—Details of the card reader the card reader reading the card in a contactless manner
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1016—Devices or methods for securing the PIN and other transaction-data, e.g. by encryption
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1025—Identification of user by a PIN code
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/18—Network architectures or network communication protocols for network security using different networks or channels, e.g. using out of band channels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/80—Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication

Definitions

  • Title of the invention Method for authenticating an individual for the implementation of a transaction on a merchant terminal.
  • 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.
  • 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.
  • consumer mobile devices such as smartphones
  • merchant payment terminals notably by downloading and installing a payment application.
  • the present invention improves the situation.
  • the present invention therefore relates, according to a first aspect, to a method of authenticating an individual for the implementation of a transaction on a merchant terminal connected via a network to a validation server.
  • transaction 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:
  • 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.
  • 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.
  • Step (c) opens the application if it is already installed, and otherwise downloads it from the network and then installs it.
  • 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.
  • 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.
  • the said proximity communication channel between the customer terminal and the merchant terminal is not via the network.
  • the said proximity communication channel between the customer terminal and the merchant terminal is an optical channel or a near-field radio channel.
  • the method comprises the implementation, by data processing means of the merchant terminal, of prior steps of:
  • 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.
  • 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.
  • 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.
  • 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.
  • Step (b) includes determining by the data processing means of the merchant terminal that authentication of said individual is necessary based on said transaction descriptive data.
  • 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).
  • 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:
  • 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:
  • the assembly further comprises said transaction validation server.
  • 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.
  • Figure 1 is a diagram of a system for implementing the method according to the invention.
  • Figure 2 is a flowchart illustrating the steps of an embodiment of the authentication method according to one aspect of the invention.
  • FIG. 3 Figure 3 schematically represents the implementation of a preferred embodiment of the authentication method according to one aspect of the invention
  • 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.
  • the present invention relates to a method of authenticating an individual for implementing a transaction on a merchant terminal 2, in a system such as represented in FIG. 1, and advantageously the method of implementing the transaction comprising said authentication method.
  • the said transaction is initiated by the said individual, for the benefit of a merchant who owns the merchant terminal 2.
  • it is a transaction between the said individual and the merchant, validated by the said server 3.
  • bank card 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).
  • EPT electronic payment terminal
  • This connection is increasingly often contactless (NFC), but it can still be by inserting the card into a reader.
  • 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.
  • a network 20 in particular the Internet network
  • a transaction validation server 3 in particular a banking server, generally remote.
  • 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.
  • 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.
  • 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 also include 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.
  • validation server 3 typically a banking server, connected to terminals 1 and 2 by the network 20.
  • the server 3 also has data processing means 31 (typically a processor) and data storage means 32 (a memory, for example a hard disk).
  • data processing means 31 typically a processor
  • data storage means 32 a memory, for example a hard disk.
  • 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.
  • Authentication of said individual may be requested for example:
  • 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).
  • the authentication consists of entering said PIN code on the client terminal 1, but alternative authentication techniques may be used such as biometric authentication.
  • 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.
  • client terminal 1 preferentially uses a dedicated application, typically downloaded from a store.
  • 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.
  • 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:
  • 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 terminal customer 1 first via the first secure channel, then via a proximity communication channel between customer terminal 1 and merchant terminal 2, certainly not secure, but almost impossible to intercept since it is only local.
  • 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).
  • 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.
  • 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.
  • said secret key of the server 3 which will be used for establishing the second secure channel.
  • an authentication token and/or a transport key identifier are retrieved at the same time (see below).
  • 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.
  • 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” transaction purpose, etc.). Note that authentication could be systematic.
  • 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 Figure 3).
  • This request can be combined with the usual transmission of descriptive data of said transaction (customer/merchant identifiers, amount, etc., see above).
  • the data processing means 31 of the server 3 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).
  • 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.
  • 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.
  • transport key which is noted (4) in FIG. 3
  • server 3 transfers:
  • 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.
  • the main part of the method is then implemented by the data processing means 11 of the client terminal 1.
  • 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 applicable, the possible authentication token and/or transport key identifier.
  • the merchant terminal 2 has determined that the individual must authenticate himself, for example by entering his PIN, but on his own terminal 1.
  • 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.
  • 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 his card), advantageously not passing via the network 20 (although each of the terminals 1 and 2 is in turn connected to the network 20).
  • 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).
  • 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.
  • 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.
  • a radio signal in particular an NFC signal (but it could alternatively be Bluetooth, etc.)
  • contactless payment is coupled with a dematerialized card on the terminal 1 and an authentication request using the same NFC channel:
  • 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;
  • steps (b) then (c) so as to retrieve the private key from server 3 and transfer the authentication request via the NFC channel which is always open: these steps were done in a fraction of a second while the two terminals 1 and 2 were close, so that the experience is no more complicated than usual and the user does not make the difference with an ordinary contactless payment.
  • 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.).
  • 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.
  • 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 figure 3).
  • 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).
  • step (d) may comprise signing the token with said private key of the server 3 and transmitting 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).
  • step (d) may include 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).
  • 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.
  • 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.). Alternatively, it may 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.
  • 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.
  • 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.
  • step (b) further comprises transmitting to said server 3 descriptive data of said transaction.
  • 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.
  • the server 3 rejects the transaction and a notification of failure of the transaction is received.
  • 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 account not funded), we go directly to the notification of failure of the transaction.
  • 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 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.
  • 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.
  • the invention relates to the client terminal 1 for implementing the method according to the first aspect (authentication).
  • 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).
  • the data processing means 11 are configured to implement steps consisting of:
  • the invention proposes an assembly comprising at least one customer terminal 1 according to the third aspect and the merchant terminal 2.
  • 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.
  • the data processing means 21 are configured to implement steps consisting of:
  • Said assembly may further comprise said transaction validation server 3.
  • 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
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Accounting & Taxation (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Finance (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • Computing Systems (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Computer And Data Communications (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

La présente invention concerne un procédé d'authentification d'un individu pour la mise en œuvre d'une transaction sur un terminal marchand (2) connecté via un réseau (20) à un serveur de validation de transaction (3), le procédé étant caractérisé en ce qu'il comprend la mise en œuvre, par des moyens de traitement de données (12) d'un terminal client (1) dudit individu également connecté au serveur (3) via ledit réseau (20), d'étapes de : (c) Réception d'une requête d'authentification dudit individu émise par ledit terminal marchand (2) via un canal de communication de proximité entre le terminal client (1) et le terminal marchand (2), ladite requête d'authentification dudit individu contenant une clé secrète dudit serveur (3); (d) Etablissement d'un canal de communication sécurisé entre le terminal client (1) et le serveur (3), dit second canal sécurisé, en utilisant ladite clé secrète dudit serveur (3); (e) Transmission de données d'authentification dudit individu au serveur (3), via ledit second canal sécurisé, en réponse à ladite requête d'authentification.

Description

Description
Titre de l'invention : Procédé d’authentification d’un individu pour la mise en œuvre d’une transaction sur un terminal marchand.
DOMAINE TECHNIQUE GÉNÉRAL
La présente invention se rapporte au domaine du paiement par carte. Plus précisément, elle concerne un procédé d’authentification d’un individu pour la mise en œuvre d’une transaction sur un terminal marchand connecté via un réseau à un serveur de validation de transaction.
ETAT DE L’ART
Les terminaux de paiement utilisés par les marchands requièrent habituellement une communication sécurisée par cryptographie symétrique avec un serveur distant, impliquant le partage préalable d’une clé privée ou de matériel cryptographique permettant de la dériver. Pour éviter toute interception, les deux participants doivent communiquer dans un environnement sécurisé, et dans le cas d’un terminal physique de type POS, une possibilité est de précharger directement la clé privée en usine.
Alternativement, il est aujourd’hui courant d’utiliser des terminaux mobiles grand public, tels que des smartphones, comme terminaux de paiement de marchands, notamment en téléchargeant et installant une application de paiement. Il est alors nécessaire d’obtenir la clé privée à distance.
Une solution apportant satisfaction est que toutes les applications distribuées aient la même base de code, et contiennent une toolbox mettant en œuvre une technologie de type « boite blanche » (en anglais « whitebox » hébergeant de manière sécurisée une même clé secrète dite initiale (« obfuscation » de la clé dans le code - la cryptographie boite blanche permet de garantir la sécurité des clés même si les états internes de l’application sont visibles). Cette même clé initiale est utilisée pour établir une communication initiale avec le serveur, qui permet le téléchargement de matériel cryptographique pour dériver d’autres clés privées, cette fois propres à chaque terminal mobile et à chaque instanciation de l’application.
Cette solution n’est pas parfaite puisque si la clé secrète initiale venait à être compromise (la boite blanche reste inéluctablement perçable), l’intégralité des communications initiales viendrait à être compromise, dans la mesure cette clé est virtuellement réutilisée dans tous les terminaux mobiles utilisant la même application, mais on limite le risque de sécurité en changeant la clé initiale régulièrement, en mettant à jour l’application et le contenu de sa Toolbox.
Cependant, il est maintenant proposé une configuration dite « personnel PIN pad » dans laquelle, en complément du terminal mobile du marchand, l’utilisateur peut utiliser son propre terminal mobile pour mettre en œuvre au moins une partie de la transaction, par exemple la saisie de son PIN, notamment lorsqu’on dépasse le seuil de paiement sans contact. Une telle configuration est très appréciée car l’utilisateur a confiance dans son terminal, et cela permet d’améliorer l’hygiène (ne pas toucher un terminal tiers) et la sécurité (faire son PIN de manière discrète) de la transaction
Cependant, cela implique également l’installation d’une application sur le terminal client et l’obtention de la clé privée. Cependant il y a des centaines de fois plus de terminaux client que de terminaux marchands, de sorte que le risque de compromission de la clé existant dans la solution précédente (clé secrète commune obfusquée dans le code de toutes les applications) devient trop élevé pour être gérable par des simples mises à jour.
La présente invention vient améliorer la situation.
PRÉSENTATION DE L’INVENTION
La présente invention se rapporte donc selon un premier aspect à un procédé d’authentification d’un individu pour la mise en œuvre d’une transaction sur un terminal marchand connecté via un réseau à un serveur de validation de transaction, le procédé étant caractérisé en ce qu’il comprend la mise en œuvre, par des moyens de traitement de données d’un terminal client dudit individu également connecté au serveur via ledit réseau, d’étapes de :
(c) Réception d’une requête d’authentification dudit individu émise par ledit terminal marchand via un canal de communication de proximité entre le terminal client et le terminal marchand, ladite requête d’authentification dudit individu contenant une clé secrète dudit serveur ;
(d) Etablissement d’un canal de communication sécurisé entre le terminal client et le serveur, dit second canal sécurisé, en utilisant ladite clé secrète dudit serveur ;
(e) Transmission de données d’authentification dudit individu au serveur, via ledit second canal sécurisé, en réponse à ladite requête d’authentification.
Selon des caractéristiques avantageuses et non limitatives :
Ladite clé secrète du serveur est chiffrée avec une clé de transport partagée entre le terminal client et le serveur, l’étape (d) comprenant en outre le déchiffrement préalable de ladite clé secrète du serveur.
Les étapes (d) et (e) sont mises en œuvre au moyen d’une application installée sur ledit terminal client, ladite clé de transport étant enfouie dans le code de ladite application.
L’étape (c) entraîne l’ouverture de ladite application si elle est déjà installée, et sinon son téléchargement depuis le réseau puis son installation.
Ladite requête d’authentification dudit individu contient en outre un jeton d’authentification, l’étape (e) comprenant la transmission du jeton signé avec la clé secrète du serveur.
Ladite transaction est de type paiement par carte bancaire et la requête d’authentification est une requête de saisie d’un code PIN de carte bancaire sur une interface dudit terminal client ; et lesdites données d’authentification sont des données dérivées dudit code PIN.
Ledit canal de communication de proximité entre le terminal client et le terminal marchand n’est pas via le réseau. Ledit canal de communication de proximité entre le terminal client et le terminal marchand est un canal optique ou un canal radio en champ proche.
Le procédé comprend la mise en œuvre, par des moyens de traitement de données du terminal marchand d’étapes préalables de :
(a) établissement d’un canal de communication sécurisé entre le terminal marchand et le serveur, dit premier canal sécurisé ;
(b) Récupération depuis le serveur, via ledit premier canal sécurisé, de ladite clé secrète du serveur.
L’étape (b) comprend également la récupération depuis le serveur du jeton d’authentification, et l’étape (e) comprend la vérification par des moyens de traitement de données du serveur dudit jeton signé.
L’étape (b) comprend la transmission au serveur d’une requête de clé secrète pour le terminal client, la génération par des moyens de traitement de données du serveur de ladite clé secrète du serveur, et si nécessaire, d’un jeton d’authentification.
L’étape (b) comprend le chiffrement par les moyens de traitement de données du serveur avec la clé de transport de ladite clé secrète du serveur généré, l’étape (b) comprend de préférence également la récupération depuis le serveur d’un identifiant de ladite clé de transport.
Selon un deuxième aspect, l’invention concerne un procédé de mise en œuvre d’une transaction sur un terminal marchand connecté via un réseau à un serveur de validation de transaction, comprenant le déclenchement de la transaction par un individu sur ledit terminal marchand puis la mise en œuvre du procédé d’authentification dudit individu selon le premier aspect, l’étape (b) comprenant en outre la transmission audit serveur de données descriptives de ladite transaction.
Selon des caractéristiques avantageuses et non limitatives :
L’étape (b) comprend la détermination par les moyens de traitement de données du terminal marchand que l’authentification dudit individu est nécessaire en fonction desdites données descriptives de la transaction. Ladite transaction est de type paiement par carte bancaire sans contact, ladite carte bancaire étant dématérialisée sur le terminal client, un même canal radio en champ proche étant utilisé pour ledit déclenchement de la transaction et l’étape (c).
Selon un troisième aspect, l’invention concerne un terminal client d’un individu, connecté via un réseau à un serveur de validation de transaction, caractérisé en ce qu’il comprend des moyens de traitement de données configurés pour :
- Recevoir, lors d’une transaction sur un terminal marchand également connecté via le réseau au serveur de validation de transaction, une requête d’authentification dudit individu émise par le terminal marchand via un canal de communication de proximité entre le terminal client et le terminal marchand, ladite requête d’authentification dudit individu contenant une clé secrète dudit serveur ;
- Etablir un canal de communication sécurisé entre le terminal client et le serveur, dit second canal sécurisé, en utilisant ladite clé secrète dudit serveur ;
- Transmettre des données d’authentification dudit individu au serveur, via ledit second canal sécurisé, en réponse à ladite requête d’authentification.
Selon un quatrième aspect, l’invention concerne un ensemble d’au moins un terminal client selon le troisième aspect et dudit terminal marchand, le terminal marchand comprenant des moyens de traitement de données configurés pour :
- établir un canal de communication sécurisé entre le terminal marchand et le serveur, dit premier canal sécurisé ;
- Récupérer depuis le serveur, via ledit premier canal sécurisé, ladite clé secrète du serveur. Selon des caractéristiques avantageuses et non limitatives, l’ensemble comprend en outre ledit serveur de validation de transaction.
Selon une cinquième et un sixième aspects, l’invention propose un produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon le premier aspect d’authentification d’un individu pour la mise en œuvre d’une transaction sur un terminal marchand connecté via un réseau à un serveur de validation de transaction ou d’un procédé selon le deuxième aspect de mise en œuvre d’une transaction sur un terminal marchand connecté via un réseau à un serveur de validation de transaction ; et un moyen de stockage lisible par un équipement informatique sur lequel est enregistré un produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon le premier aspect d’authentification d’un individu pour la mise en œuvre d’une transaction sur un terminal marchand connecté via un réseau à un serveur de validation de transaction ou d’un procédé selon le deuxième aspect de mise en œuvre d’une transaction sur un terminal marchand connecté via un réseau à un serveur de validation de transaction.
PRÉSENTATION DES FIGURES
D’autres caractéristiques et avantages de la présente invention apparaîtront à la lecture de la description qui va suivre d’un mode de réalisation préférentiel. Cette description sera donnée en référence aux dessins annexés dans lesquels :
[Fig. 1 ]la figure 1 est un schéma d’un système pour la mise en œuvre du procédé selon l’invention ;
[Fig. 2]la figure 2 est un logigramme illustrant les étapes d’un mode de réalisation du procédé d’authentification selon un aspect de l’invention ;
[Fig. 3]la figure 3 représente schématiquement la mise en œuvre d’un mode de réalisation préféré du procédé d’authentification selon un aspect de l’invention ; [Fig. 4]la figure 4 est un logigramme illustrant les étapes d’un mode de réalisation du procédé de mise en œuvre d’une transaction selon un autre aspect de l’invention.
DESCRIPTION DÉTAILLÉE
Architecture
La présente invention concerne un procédé d’authentification d’un individu pour la mise en œuvre d’une transaction sur un terminal marchand 2, dans un système tel que représenté sur la figure 1, et avantageusement le procédé de mise en œuvre de la transaction comprenant ledit procédé d’authentification.
Ladite transaction est initiée par ledit individu, au profit d’un marchand possesseur du terminal marchand 2. Entre d’autres termes il s’agit d’une transaction entre ledit individu et le marchand, valisée par ledit serveur 3.
Elle est de type paiement par carte bancaire chez ledit marchand, i.e. une carte bancaire ou un terminal mobile (désigné terminal client 1 ) émulant une carte bancaire (de l’individu) est connecté au terminal marchand 2 assurant un rôle de terminal de paiement électronique (TPE). Cette connexion est de plus en plus souvent sans-contact (NFC), mais elle peut toujours être par insertion de la carte dans un lecteur.
Le terminal marchand 2 est connecté via un réseau 20 (en particulier le réseau internet) à un serveur de validation de transaction 3, en particulier un serveur bancaire, généralement distant.
De manière classique une transaction de type paiement par carte bancaire utilise un chiffrement symétrique, c’est-à-dire qu’une clé privée est associé à la carte bancaire (physique ou dématérialisée), la clé privée étant d’une part stockée directement sur la puce de la carte si elle est physique ou dans une mémoire du terminal si elle est dématérialisée, et d’autre part stockée par le serveur de validation 3. Avantageusement, des données descriptives de la transaction sont saisies par le marchand sur le terminal marchand 2, et envoyées à la carte/terminal dudit individu pour apposition de ladite signature en fonction de la clé privée, et le serveur 3 pourra vérifier que cette signature est valide, et autoriser la transaction.
Le terminal client 1 et le terminal marchand 2 disposent chacun de moyens de traitement de données 11 , 21 (typiquement un processeur) et de moyens de stockage de données 12, 22 (une mémoire, par exemple flash). Chacun peut en outre comporter une interface (par exemple un écran), des moyens de communication sans-fil de proximité (par exemple NFC, voir plus loin), et une caméra. Chacun des terminaux 1 et 2 (et en particulier le terminal marchand) est avantageusement un terminal mobile de type smartphone (et les éléments précédents tel qu’une caméra sont habituels pour tout terminal mobile), même si alternativement ou en complément le terminal marchand 2 peut être un terminal plus imposant (un TPE classique), disposant notamment d’un lecteur de carte.
Comme expliqué, on a en outre le serveur de validation 3, typiquement un serveur bancaire, connecté aux terminaux 1 et 2 par le réseau 20.
Le serveur 3 dispose également de moyens de traitement de données 31 (typiquement un processeur) et de moyens de stockage de données 32 (une mémoire, par exemple un disque dur).
Principe
Par authentification, on entend la vérification que l’individu souhaitant la transaction est bien celui qu’il prétend être, i.e. le possesseur de la carte/du terminal 1 .
Une authentification dudit individu peut être demandée par exemple :
- Parce que le montant de la transaction dépasse le seuil de paiement sans contact ;
- Parce qu’il a inséré sa carte dans le terminal marchand 2 même pour un montant plus faible ; - Ou simplement parce que l’individu/le marchand/la transaction exige un niveau de protection plus élevé.
De manière classique, l’utilisateur peut s’authentifier en saisissant son code PIN sur le terminal marchand 2, mais on se place ici dans le contexte évoqué dans l’introduction où l’on souhaite utiliser le terminal 1 du l’individu, notamment pour des questions de confiance (l’individu a confiance en son propre terminal), de confidentialité (il peut taper discrètement son code) ou d’hygiène (personne d’autre que lui ne touche son terminal).
Ainsi, de manière préférée, l’authentification consiste la saisie dudit code PIN sur le terminal client 1 , mais des techniques d’authentification alternatives pourront être utilisées comme une authentification biométrique. En outre ladite authentification peut être une authentification forte en vérifiant (outre l’identité de l’utilisateur) que le terminal client 1 appartient bien à l’individu via un identifiant unique.
Pour ce faire, et comme expliqué, le terminal client 1 utilise préférentiellement une application dédiée, téléchargée classiquement depuis un store.
Le présent procédé évite toute nécessité d’enfouir une clé privée dans le code de l’application, au mieux on a éventuellement une clé de transport enfouie, qui même si elle était compromise ne mettrait pas en péril les communications.
La solution proposée est d’exploiter d’une part l’existence d’un canal de communication sécurisé entre le terminal marchand 2 et le serveur 3, dit première canal sécurisé (par la toute méthode de l’art y compris la clé privée enfouie dans le code de l’application de paiement du terminal marchand 2 - dont on rappelle qu’elle est partagée seulement entre les terminaux marchand 2, qui sont des centaines de fois moins nombreux que les terminaux client 1 ), et d’autre part la proximité nécessaire entre le terminal marchand 2 et le terminal client 1 lors d’une transaction :
La clé privée (dite clé secrète du serveur 3) nécessaire à l’établissement d’un canal de communication sécurisée entre le terminal client 1 et le serveur 3, dit second canal sécurisé, peut ainsi être transmise du serveur 3 au terminal client 1 d’abord via le premier canal sécurisé, puis via un canal de communication de proximité entre le terminal client 1 et le terminal marchand 2, certes non sécurisé, mais quasiment impossible à intercepter puisque uniquement local.
Procédé - coté terminal marchand
En référence aux figures 2 et 3, le présent procédé commence par une étape préalable optionnelle (a), mis en œuvre par les moyens de traitement de données 21 du terminal marchand 2, d’établissement du canal de communication sécurisé entre le terminal marchand 2 et le serveur 3, dit premier canal sécurisé (notée (1 ) sur la figure 3).
Cette méthode peut être mise en œuvre de toute manière connue, et on note que le canal peut être établi bien avant et qu’il n’est pas nécessaire d’établir un nouveau premier canal à chaque occurrence du présent procédé.
Ensuite, dans une étape (b) également optionnelle, les moyens de traitement de données 21 du terminal marchand 2 récupérèrent depuis le serveur 3 (et pour le terminal client 1 ), via ledit premier canal sécurisé, ladite clé secrète du serveur 3 qui sera utilisée pour l’établissement du second canal sécurisé. De manière préférée, sont récupérés en même temps un jeton d’authentification et/ou un identifiant de clé de transport (voir plus loin).
A noter que cette étape (b) reste également optionnelle, car il est possible que le terminal marchand récupère occasionnellement des paquets de clés secrètes, voire les génère grâce à du matériel cryptographique fournie par le serveur 3.
Selon un mode de réalisation préférée, l’étape (b) est mise en œuvre à chaque transaction nécessitant une authentification et comprend tout d’abord la détermination que l’authentification dudit individu est nécessaire, en particulier en fonction desdites données descriptives de la transaction, que ce soit par exemple parce qu’il a dépassé le seuil de paiement sans contact ou parce qu’un niveau supplémentaire de sécurité est requis (pour une raison quelconque : politique du marchand, préférence du client, objet de la transaction « sensible », etc.). A noter que l’authentification pourrait être systématique.
Dans tous les cas, l’étape (b) comprend avantageusement l’émission d’une requête de clé secrète pour le terminal 1 , via ledit premier canal sécurisé, auprès du serveur 3 (notée (2) sur la figure 3). Cette requête peut être conjointe avec la transmission habituelle de données descriptives de ladite transaction (identifiants client/marchand, montant, etc., voir plus haut).
En réponse à cette requête les moyens de traitement 31 de données du serveur 3 génèrent ((3) dans la figure 3) la clé secrète et le cas échéant un jeton du client qui sera comme l’on verra utilisé pour établir le second canal sécurisé, potentiellement aléatoirement (à noter qu’on peut alternativement avoir un stock pré-généré de clés).
De manière préférée, une clé de transport est partagée entre le terminal client 1 et le serveur 3, en particulier en étant enfouie (i.e. stockée de manière obfusquée conformément aux principes de cryptographie boite blanche) dans le code d'une application du terminal 1 . Dans ce cas, ladite clé secrète du serveur 3 est chiffrée par les moyens de traitement de données 31 du serveur 3 avec ladite clé de transport (ce qui est noté (4) sur la figure 3), ce qui permet garder protégée et d’éviter un transfert en clair entre le terminal marchand 2 et le terminal client 1 . A noter qu’il peut y avoir plusieurs clés de transports, d’où l’idée de joindre un identifiant de la clé de transport (par exemple un haché).
En résumé, le serveur 3 transfère :
- La clé secrète avantageusement chiffrée
- Optionnellement un jeton d’authentification du client
- Optionnellement un identifiant de la clé de transport utilisée pour chiffrer la clé secrète.
Enfin l’étape (b) peut comprendre la préparation desdits données qui viennent d’être reçues, et en particulier la génération d’une requête d’authentification de l’individu (notée (5) sur la figure 3), on verra comment plus bas. Procédé - coté terminal client
La partie principale du procédé est alors mise en œuvre par les moyens de traitement de données 11 du terminal client 1 .
Dans une étape (c), est transmise la requête d’authentification dudit individu émise par ledit terminal marchand 2 via ledit canal de communication de proximité entre le terminal client 1 et le terminal marchand 2, ladite requête d’authentification dudit individu contenant une clé secrète dudit serveur 3 et le cas échéant le jeton les éventuels jeton d’authentification et/ou identifiant de clé de transport.
Comme expliqué, on suppose que le terminal marchand 2 a déterminé que l’individu devait s’authentifier par exemple en saisissant son PIN, mais sur son propre terminal 1. On note que la requête a un double usage : elle indique au terminal client 1 qu’il doit réaliser l’authentification et elle transporte la clé sécrète qui va permettre de communiquer à ce sujet avec le serveur 3.
Par « canal de communication de proximité » on entend un canal de communication à courte portée qui tire parti du fait que l’individu doit être présent et même accéder au terminal marchand 2 pour initier la transaction (par exemple en insérant sa carte), avantageusement ne passant via le réseau 20 (bien que chacun des terminaux 1 et 2 soit de son côté connecté au réseau 20).
De manière préférée, ledit canal de communication de proximité est un canal sans fil en particulier choisi parmi un canal optique et un canal radio en champ proche, mais ce pourrait être par exemple simplement un canal filaire (en connectant les terminaux 1 et 2 par un câble).
Dans le mode de réalisation « canal optique », la requête d’authentification prend la forme d’un signal visuel, en particulier un code barre 2D, et en particulier un QR code émis par le terminal marchand 2 (affiché par un écran) et capté par une caméra du terminal client 1. Plus précisément, le code barre 2D s’affiche et l’individu est invité à le scanner avec son terminal 1 .
Dans le mode de réalisation « canal radio en champ proche », la requête d’authentification prend la forme d’un signal radio, en particulier un signal NFC (mais ce pourrait par exemple alternativement être du Bluetooth, etc.), transféré entre les terminaux 1 et 2 en les mettant l’un contre l’autre.
Dans un mode de réalisation particulièrement préféré, on couple paiement sans contact avec une carte dématérialisée sur le terminal 1 et requête d’authentification en utilisant un même canal NFC :
- L’utilisateur approche son terminal 1 du terminal marchand 2 pour payer sans contact (potentiellement même si l’on dépasse la limite du paiement sans contact !) ;
- Le terminal marchand 2 échange avec le terminal client 1 via le canal NFC de sorte à obtenir et signer les données de transaction de manière classique, et détermine qu’une authentification de l’individu est nécessaire pour cette transaction ;
- Il met en œuvre les étapes (b) puis (c) de sorte à récupérer la clé privée du serveur 3 et transférer la requête d’authentification via le canal NFC toujours ouvert : ces étapes se sont faites en une fraction de seconde pendant que les deux terminaux 1 et 2 étaient proches, de sorte que l’expérience n’est pas plus compliquée que d’habitude et l’utilisateur ne fait pas la différence avec un paiement sans contact ordinaire.
Ensuite, le procédé comprend une étape (d) d’établissement du canal de communication sécurisé entre le terminal client 1 et le serveur 3, dit second canal sécurisé, en utilisant ladite clé secrète dudit serveur 3. L’étape (d) comprend en pratique (avant ou après l’établissement du canal) l’authentification de l’individu (i.e. le traitement de la requête), comme expliqué en lui demandant la saisie du PIN, la vérification d’un trait biométrique, etc.).
De manière préférée et comme évoqué, les étapes (d) et comme on verra (e) sont mises en œuvre au moyen d’une application installée sur ledit terminal client 1 , l’éventuelle clé de transport étant le cas échéant enfouie dans le code de ladite application. Alors (et ce quel que soit le canal de communication de proximité) l’étape (c) entraîne avantageusement automatiquement l’ouverture de ladite application si elle est déjà installée, ou du moins son téléchargement depuis le réseau 20 puis son installation (notée (6) sur la figure 3).
Ainsi, pour revenir sur le mode de réalisation full NFC présenté, au lieu d’avoir une information de fin de transaction, l’application s’ouvre et affiche une interface d’authentification de l’individu (par exemple affichage du clavier pour la saisie du PIN, ou demande de vérification du visage de l’individu).
En ce qui concerne l’établissement du deuxième canal sécurisé, il pourra être mis en œuvre de toute façon connue en utilisant ladite clé secrète du serveur 3. Par exemple, dans le mode de réalisation dans lequel un jeton d’authentification est transmis également dans la requête, l’étape (d) peut comprendre la signature du jeton avec ladite clé privée du serveur 3 et la transmission du jeton signé au serveur 3 (notée (7) sur la figure 3). Ce dernier vérifie la signature et le jeton (par comparaison avec la clé et le jeton qu’il a transmis - notée (8) sur la figure 3), et autorise l’établissement du canal si la vérification est concluante (notée 9) sur la figure 3).
Dans tous les cas, l’étape (d) peut comprendre le déchiffrement préalable de ladite clé secrète du serveur 3 (avec la clé de transport en particulier enfouie dans l’application - le cas échéant identifiée avec l’éventuel identifiant de clé de transport transmis dans la requête d’authentification).
Enfin, le procédé comprend une étape (e) de transmission de données d’authentification dudit individu au serveur 3, via ledit second canal sécurisé, en réponse à ladite requête d’authentification.
Par données d’authentification on entend toute preuve de ladite authentification nécessaire au serveur 3, par exemple des données dérivées dudit code PIN (que ce soit le code PIN en lui-même, un haché ou un chiffré du code PIN, une preuve qu’un code PIN correct a été saisi, etc.). Ce peut être alternativement une donnée garantissant qu’une donnée biométrique candidate coïncidant avec une donnée biométrique de référence a été acquise ou toute autre donnée prouvant l’identité dudit individu etc. Transaction
Selon un deuxième aspect, en référence à la figure 4, l’invention propose le procédé de mise en œuvre d’une transaction sur un terminal marchand 2 connecté via un réseau 20 à un serveur de validation de transaction 3, comme expliqué typiquement une transaction de type paiement par carte bancaire.
Ce procédé comprend le déclenchement de la transaction par un individu sur ledit terminal marchand 2 (par exemple en insérant sa carte dans le terminal marchand 2, ou l’approchant en sans-contact), puis la mise en œuvre du procédé d’authentification dudit individu selon le premier aspect.
Dans le but de mettre en œuvre la transaction, l’étape (b) comprend en outre la transmission audit serveur 3 de données descriptives de ladite transaction.
Si le résultat de l’authentification est positif, la transaction est bien traitée du coté serveur 3, et le procédé comprend avantageusement une étape (f) de réception, de la part du serveur 3 (par le terminal client 1 et/ou le terminal marchand 2, préférentiellement les deux) d’une notification de confirmation de la transaction. Bien entendu, si aucune donnée d’authentification dudit individu au serveur 3 n’est transmise au serveur 3 à l’étape (e), ou des données incorrectes, le serveur 3 rejette la transaction et une notification d’échec de la transaction est reçue. On suppose également que si les données descriptives de la transaction transmises à l’étape (b) sont incorrectes (par exemple signature fausse qui témoigne d’une carte falsifiée) ou si la transaction est impossible (par exemple compte non provisionné), on passe directement à la notification d’échec de la transaction.
De manière préférée, l’étape (b) comprend la détermination par les moyens de traitement de données 21 du terminal marchand que l’authentification dudit individu est nécessaire en fonction desdites données descriptives de la transaction. Si c’est bien le cas, alors l’étape (b) comprend comme expliqué l’envoi au serveur de la requête de clé privée pour le terminal client 1 (outre les données de la transaction), et les étapes (c) à (e) du procédé sont mises en œuvre.
Sinon (pas d’authentification de l’individu nécessaire, par exemple car paiement simple sans contact) on passe directement à l’étape (f) de réception d’une notification de confirmation de la transaction si tout est bon (ou d’échec - voir avant).
De manière particulièrement préférée, comme déjà évoqué, si ladite transaction est de type paiement par carte bancaire sans contact et ladite carte bancaire étant dématérialisée sur le terminal client 1 (i.e. la transaction est déclenchée en approchant le terminal client 1 du terminal marchand 2), un même canal radio en champ proche (NFC) est utilisé pour ledit déclenchement de la transaction et l’étape (c), de sorte que l’utilisateur se voie automatiquement demandé sur le terminal client 1 l’authentification.
Terminaux
Selon un troisième aspect, l’invention concerne le terminal client 1 pour la mise en œuvre du procédé selon le premier aspect (d’authentification).
Ainsi, ce terminal 1 comprend comme expliqué au moins des moyens de traitement de données 1 1 et une mémoire 12, et avantageusement une caméra et/ou des moyens de communication en champ proche. Il s’agit typiquement d’un terminal mobile de type smartphone de l’individu à l’origine de la transaction (le porteur de la carte bancaire).
Les moyens de traitement de données 1 1 sont configurés pour mettre en œuvre des étapes consistant à :
- Recevoir, lors d’une transaction sur un terminal marchand 2 également connecté via le réseau 20 au serveur de validation de transaction 3, une requête d’authentification dudit individu émise par le terminal marchand 2 via un canal de communication de proximité entre le terminal client 1 et le terminal marchand 2, ladite requête d’authentification dudit individu contenant une clé secrète dudit serveur 3 ;
- Etablir un canal de communication sécurisé entre le terminal client 1 et le serveur 3, dit second canal sécurisé, en utilisant ladite clé secrète dudit serveur 3 ;
- Transmettre des données d’authentification dudit individu au serveur 3, via ledit second canal sécurisé, en réponse à ladite requête d’authentification.
Selon un quatrième aspect, l’invention propose un ensemble comprenant au moins un terminal client 1 selon le troisième aspect et le terminal marchand 2.
Ce terminal 2 comprend également comme expliqué au moins des moyens de traitement de données 21 et une mémoire 22, et avantageusement des moyens d’affichage et/ou des moyens de communication en champ proche, potentiellement en outre un lecteur de carte. Il peut s’agir également d’un terminal mobile de type smartphone du marchand, ou de tout TPE.
Les moyens de traitement de données 21 sont configurés pour mettre en œuvre des étapes consistant à :
- établir un canal de communication sécurisé entre le terminal marchand 2 et le serveur 3, dit premier canal sécurisé ;
- Récupérer depuis le serveur 3, via ledit premier canal sécurisé, ladite clé secrète du serveur 3.
Ledit ensemble peut en outre comprendre ledit serveur de validation de transaction 3.
Cet ensemble, et en particulier les moyens de traitement de données 11 , 21 des terminaux 1 , 2, sont avantageusement également pour la mise en œuvre du procédé selon le deuxième aspect (de mise en œuvre de la transaction), i.e. les moyens de traitement de données 21 du terminal marchand 2 sont également configurés pour autoriser le déclenchement de la transaction par un individu sur ledit terminal marchand 2. Produit programme d’ordinateur
Selon un cinquième et un sixième aspects, l’invention concerne un produit programme d’ordinateur comprenant des instructions de code pour l’exécution (sur les moyens de traitement de donnés 11 , 21 des terminaux 1 et 2) d’un procédé selon le premier aspect d’authentification d’un individu pour la mise en œuvre d’une transaction sur un terminal marchand 2 connecté via un réseau 20 à un serveur de validation de transaction 3, ou d’un procédé selon le deuxième aspect de mise en œuvre d’une transaction sur un terminal marchand 2 connecté via un réseau 20 à un serveur de validation de transaction 3 ; ainsi que des moyens de stockage lisibles par un équipement informatique (par exemple les moyens de stockage de données 11 , 22 des terminaux 1 et 2) sur lequel on trouve ce produit programme d’ordinateur.

Claims

REVENDICATIONS
1. Procédé d’authentification d’un individu pour la mise en œuvre d’une transaction sur un terminal marchand (2) connecté via un réseau (20) à un serveur de validation de transaction (3), le procédé étant caractérisé en ce qu’il comprend la mise en œuvre, par des moyens de traitement de données (12) d’un terminal client (1 ) dudit individu également connecté au serveur (3) via ledit réseau (20), d’étapes de :
(c) Réception d’une requête d’authentification dudit individu émise par ledit terminal marchand (2) via un canal de communication de proximité entre le terminal client (1 ) et le terminal marchand (2), ladite requête d’authentification dudit individu contenant une clé secrète dudit serveur (3) ;
(d) Etablissement d’un canal de communication sécurisé entre le terminal client (1 ) et le serveur (3), dit second canal sécurisé, en utilisant ladite clé secrète dudit serveur (3) ;
(e) Transmission de données d’authentification dudit individu au serveur (3), via ledit second canal sécurisé, en réponse à ladite requête d’authentification.
2. Procédé selon la revendication 1 , dans lequel ladite clé secrète du serveur (3) est chiffrée avec une clé de transport partagée entre le terminal client (1 ) et le serveur (3), l’étape (d) comprenant en outre le déchiffrement préalable de ladite clé secrète du serveur (3).
3. Procédé selon la revendication 2, dans lequel les étapes (d) et (e) sont mises en œuvre au moyen d’une application installée sur ledit terminal client (1 ), ladite clé de transport étant enfouie dans le code de ladite application.
4. Procédé selon la revendication 3, dans lequel l’étape (c) entraîne l’ouverture de ladite application si elle est déjà installée, et sinon son téléchargement depuis le réseau (20) puis son installation.
5. Procédé selon l’une des revendications 1 à 4, dans lequel ladite requête d’authentification dudit individu contient en outre un jeton d’authentification, l’étape (e) comprenant la transmission du jeton signé avec la clé secrète du serveur (3).
6. Procédé selon l’une des revendications 1 à 5, dans lequel ladite transaction est de type paiement par carte bancaire et la requête d’authentification est une requête de saisie d’un code PIN de carte bancaire sur une interface dudit terminal client (1 ) ; et lesdites données d’authentification sont des données dérivées dudit code PIN.
7. Procédé selon l’une des revendications 1 à 6, dans lequel ledit canal de communication de proximité entre le terminal client (1 ) et le terminal marchand (2) n’est pas via le réseau (20).
8. Procédé selon la revendication 7, dans lequel ledit canal de communication de proximité entre le terminal client (1 ) et le terminal marchand
(2) est un canal optique ou un canal radio en champ proche.
9. Procédé selon l’une des revendications 1 à 8, comprenant la mise en œuvre, par des moyens de traitement de données (21 ) du terminal marchand (2) d’étapes préalables de :
(a) établissement d’un canal de communication sécurisé entre le terminal marchand (2) et le serveur (3), dit premier canal sécurisé ;
(b) Récupération depuis le serveur (3), via ledit premier canal sécurisé, de ladite clé secrète du serveur (3).
10. Procédé selon les revendications 5 et 9 en combinaison, dans lequel l’étape (b) comprend également la récupération depuis le serveur
(3) du jeton d’authentification, et l’étape (e) comprend la vérification par des moyens de traitement de données (31 ) du serveur (3) dudit jeton signé.
11. Procédé selon l’une des revendication 9 et 10, dans lequel l’étape (b) comprend la transmission au serveur (3) d’une requête de clé secrète pour le terminal client (1 ), la génération par des moyens de traitement de données (31 ) du serveur (3) de ladite clé secrète du serveur (3), et si nécessaire, d’un jeton d’authentification.
12. Procédé de mise en œuvre d’une transaction sur un terminal marchand (2) connecté via un réseau (20) à un serveur de validation de transaction (3), comprenant le déclenchement de la transaction par un individu sur ledit terminal marchand (2) puis la mise en œuvre du procédé d’authentification dudit individu selon l’une des revendications 9 à 11 , l’étape (b) comprenant en outre la transmission audit serveur (3) de données descriptives de ladite transaction.
13. Terminal client (1 ) d’un individu, connecté via un réseau (20) à un serveur de validation de transaction (3), caractérisé en ce qu’il comprend des moyens de traitement de données (1 1 ) configurés pour :
- Recevoir, lors d’une transaction sur un terminal marchand (2) également connecté via le réseau (20) au serveur de validation de transaction (3), une requête d’authentification dudit individu émise par le terminal marchand (2) via un canal de communication de proximité entre le terminal client (1 ) et le terminal marchand (2), ladite requête d’authentification dudit individu contenant une clé secrète dudit serveur (3) ;
- Etablir un canal de communication sécurisé entre le terminal client (1 ) et le serveur (3), dit second canal sécurisé, en utilisant ladite clé secrète dudit serveur (3) ;
- Transmettre des données d’authentification dudit individu au serveur (3), via ledit second canal sécurisé, en réponse à ladite requête d’authentification.
14. Ensemble d’au moins un terminal client (1 ) selon la revendication 13 et dudit terminal marchand (2), le terminal marchand (2) comprenant des moyens de traitement de données (21 ) configurés pour :
- établir un canal de communication sécurisé entre le terminal marchand (2) et le serveur (3), dit premier canal sécurisé ;
- Récupérer depuis le serveur (3), via ledit premier canal sécurisé, ladite clé secrète du serveur (3).
15. Ensemble selon la revendication 14, comprenant en outre ledit serveur de validation de transaction (3).
16. Produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon l’une des revendications 1 à 11 d’authentification d’un individu pour la mise en œuvre d’une transaction sur un terminal marchand (2) connecté via un réseau (20) à un serveur de validation de transaction (3) ou d’un procédé selon la revendication 12 de mise en œuvre d’une transaction sur un terminal marchand (2) connecté via un réseau (20) à un serveur de validation de transaction (3), lorsque ledit programme est exécuté sur un ordinateur.
17. Moyen de stockage lisible par un équipement informatique sur lequel est enregistré un produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon l’une des revendications 1 à 11 d’authentification d’un individu pour la mise en œuvre d’une transaction sur un terminal marchand (2) connecté via un réseau (20) à un serveur de validation de transaction (3) ou d’un procédé selon la revendication 12 de mise en œuvre d’une transaction sur un terminal marchand (2) connecté via un réseau (20) à un serveur de validation de transaction (3).
PCT/EP2024/086204 2023-12-15 2024-12-13 Procédé d'authentification d'un individu pour la mise en œuvre d'une transaction sur un terminal marchand Pending WO2025125562A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FRFR2314252 2023-12-15
FR2314252A FR3156957A1 (fr) 2023-12-15 2023-12-15 Procédé d’authentification d’un individu pour la mise en œuvre d’une transaction sur un terminal marchand.

Publications (1)

Publication Number Publication Date
WO2025125562A1 true WO2025125562A1 (fr) 2025-06-19

Family

ID=90810184

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2024/086204 Pending WO2025125562A1 (fr) 2023-12-15 2024-12-13 Procédé d'authentification d'un individu pour la mise en œuvre d'une transaction sur un terminal marchand

Country Status (2)

Country Link
FR (3) FR3156957A1 (fr)
WO (1) WO2025125562A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110125638A1 (en) * 1999-07-22 2011-05-26 Visa International Service Association Internet Payment, Authentication And Loading System Using Virtual Smart Card
US20150134538A1 (en) * 2012-05-21 2015-05-14 Ju Han Kim Application for using mobile communication terminal as payment terminal, and application service provider system and method
US20150278811A1 (en) * 2013-03-08 2015-10-01 Commonwealth Bank Of Australia Systems and Methods for Facilitating Authorisation of Payment
US20170228726A1 (en) * 2016-02-04 2017-08-10 American Express Travel Related Services Company, Inc. Systems and methods for secure transactions
US20230096124A1 (en) * 2021-09-24 2023-03-30 Sayves Llc Systems and methods for secure digital transactions

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110125638A1 (en) * 1999-07-22 2011-05-26 Visa International Service Association Internet Payment, Authentication And Loading System Using Virtual Smart Card
US20150134538A1 (en) * 2012-05-21 2015-05-14 Ju Han Kim Application for using mobile communication terminal as payment terminal, and application service provider system and method
US20150278811A1 (en) * 2013-03-08 2015-10-01 Commonwealth Bank Of Australia Systems and Methods for Facilitating Authorisation of Payment
US20170228726A1 (en) * 2016-02-04 2017-08-10 American Express Travel Related Services Company, Inc. Systems and methods for secure transactions
US20230096124A1 (en) * 2021-09-24 2023-03-30 Sayves Llc Systems and methods for secure digital transactions

Also Published As

Publication number Publication date
FR3156957A1 (fr) 2025-06-20
FR3157960A3 (fr) 2025-07-04
FR3157959A3 (fr) 2025-07-04

Similar Documents

Publication Publication Date Title
EP3221815B1 (fr) Procédé de sécurisation d'un jeton de paiement.
EP2820795B1 (fr) Procede de verification d'identite d'un utilisateur d'un terminal communiquant et systeme associe
FR2854303A1 (fr) Procede de securisation d'un terminal mobile et applications de procede, l'execution d'applications necessitant un niveau de securite eleve
EP2614458B1 (fr) Procede d'authentification pour l'acces a un site web
EP2619941A1 (fr) Procede, serveur et systeme d'authentification d'une personne
FR2997525A1 (fr) Procede de fourniture d’un service securise
EP1815638A1 (fr) Procede de securisation d'un terminal de telecommunication connecte a un module d'identification d'un utilisateur du terminal
EP3743871A1 (fr) Système sécurisé de transactions entre terminaux
FR2922669A1 (fr) Dispositif electronique portable pour l'echange de valeurs et procede de mise en oeuvre d'un tel dispositif
EP2053553A1 (fr) Procédé et dispositif pour l'échange de valeurs entre entités électroniques portables personnelles
WO2007012583A1 (fr) Procede de controle de transactions securisees mettant en oeuvre un dispositif physique unique, dispositif physique, systeme, et programme d'ordinateur correspondants
EP3588418A1 (fr) Procédé de réalisation d'une transaction, terminal, serveur et programme d ordinateur correspondant
EP2614491A1 (fr) Procede simplifie de personnalisation de carte a puce et dispositif associe
EP2813962B1 (fr) Méthode de contrôle d'accès à un type de services spécifique et dispositif d'authentification pour le contrôle de l'accès à un tel type de services.
WO2025125562A1 (fr) Procédé d'authentification d'un individu pour la mise en œuvre d'une transaction sur un terminal marchand
FR3053548A1 (fr) Procede d'authentification de donnees de paiement, dispositifs et programmes correspondants.
EP3899765B1 (fr) Réinitialisation d'un secret applicatif au moyen du terminal
FR3081239A1 (fr) Systeme et procede d'authentification utilisant un jeton a usage unique de duree limitee
EP2084679A1 (fr) Entite electronique portable et procede de blocage, a distance, d'une fonctionnalite d'une telle entite electronique portable
WO2017005644A1 (fr) Procédé et système de contrôle d'accès à un service via un média mobile sans intermediaire de confiance
FR3154209A1 (fr) Procédé de mise en œuvre d’une transaction entre un premier équipement de preuve et un deuxième équipement de vérification.
WO2025083096A1 (fr) Protocole niable a apport de connaissance nulle
FR3099974A1 (fr) Procédé de transmission d’une information numérique
FR2971350A1 (fr) Procede et dispositif de connexion a un service distant depuis un dispositif hote

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 24824759

Country of ref document: EP

Kind code of ref document: A1