EP3479518A1 - Procede d'authentification de donnees de paiement, dispositifs et programmes correspondants - Google Patents

Procede d'authentification de donnees de paiement, dispositifs et programmes correspondants

Info

Publication number
EP3479518A1
EP3479518A1 EP17733483.6A EP17733483A EP3479518A1 EP 3479518 A1 EP3479518 A1 EP 3479518A1 EP 17733483 A EP17733483 A EP 17733483A EP 3479518 A1 EP3479518 A1 EP 3479518A1
Authority
EP
European Patent Office
Prior art keywords
obtaining
user device
private key
communication terminal
authentication code
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.)
Ceased
Application number
EP17733483.6A
Other languages
German (de)
English (en)
Inventor
Rémi GERAUD
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
Ingenico Group SA
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 Ingenico Group SA filed Critical Ingenico Group SA
Publication of EP3479518A1 publication Critical patent/EP3479518A1/fr
Ceased legal-status Critical Current

Links

Classifications

    • 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/3278—RFID or NFC 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/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/3823—Payment protocols; Details thereof insuring higher security of transaction combining multiple encryption tools for a transaction
    • 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/409—Device specific authentication in transaction processing
    • G06Q20/4097—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners
    • G06Q20/40975—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners using encryption therefor
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H04L9/3066—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy involving algebraic varieties, e.g. elliptic or hyper-elliptic curves
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3218—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using proof of knowledge, e.g. Fiat-Shamir, GQ, Schnorr, ornon-interactive zero-knowledge proofs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3242—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/72—Signcrypting, i.e. digital signing and encrypting simultaneously

Definitions

  • the invention relates to the field of securing data exchanged via a contactless data transmission protocol.
  • the technique relates more particularly to the transmission of NFC type data, in which a transmission is carried out between a first device and a second device separated by a distance of the order of ten centimeters or less.
  • the technique does not apply and is not intended to apply in the context of data transmission techniques such as WiFi, WiMax, LTE, whose transmission technologies are different.
  • NFC near field
  • RFID refers to means of identification by radio frequency. Both use radio signals for all sorts of tracking and tracking purposes, sometimes replacing barcodes. Both use short-range data transmission means.
  • contactless payment devices have appeared. These are, for example, contactless payment cards which make it possible to make a payment (the amount of which is generally capped) by affixing (or reconciling) the payment card of a compatible payment terminal. It is also the communication terminals, which also integrate contactless “chips”: these chips (also called “contactless chip”) and which offer data exchange capabilities to communication terminals, capacities that can be used to make payments, as if the communication terminal imitated the behavior of a contactless payment card.
  • the device implements an authentication protocol with the terminal (for example a payment terminal, a terminal of a merchant, or any other appropriate device).
  • the terminal checks that the authentication phase has succeeded and otherwise refuses the transaction or triggers an alert, or implements any other behavior deemed appropriate in such a situation.
  • the terminal performing these checks is a secure device (such as a payment terminal). It has been designed to prevent most types of intrusions, both hardware and software. But if the payment terminal is a third-party device (tablet, smartphone, screen communication terminal), then the security of this communication terminal (third party) can not be guaranteed any more than the origin of the applications installed on this terminal (by the trader himself). If the merchant is not vigilant, it is possible that the applications installed on this terminal are fraudulent.
  • V the verifier (for example the merchant's terminal or device)
  • P the prover (user's device: smartphone, tablet).
  • V asks P to digitally sign data.
  • P signs the data, as requested by V and transmits the signed data to V.
  • This signature is verified by V, and if it is correct, then the transaction is accepted and transferred to the rest of the processing chain. payments.
  • Such a procedure is called a "challenge response" and is used for example by the EMV specifications.
  • V works on an unsecured device (ie a terminal of the tablet, PC or other type, which has been added payment features) that is infected by malicious software (installed by the merchant or by a malicious third party), then this software can abuse the terminal of the client P.
  • malicious software installed by the merchant or by a malicious third party
  • Such an abuse can for example take the form of a succession of (invisible) transactions. This can be done for example when the merchant terminal forces the user device to sign arbitrary messages. The device of the user, in "slave" position, is then obliged to sign these data.
  • the malware installed on the merchant's terminal then uses this signed data to create fraudulent transactions.
  • the invention does not pose these problems of the prior art. More particularly, the invention provides a simple solution to the previously identified problem. This solution is fully compatible with existing hardware devices.
  • a method of authenticating at least one piece of data a method implemented during a payment transaction occurring between a merchant's terminal and a user device, a method which includes the creation of an authentication triplet, comprising an authentication code and two components of signature, this triplet being constructed by the user device and being verifiable only by the merchant's terminal.
  • a method for authenticating at least one piece of data a method implemented during a payment transaction occurring between a merchant's communication terminal and a user device, a method of the type comprising the authentication by the communication terminal of at least one message m generated by the user device, via a near-field wireless data link, characterized in that it comprises, at within the user device:
  • Such a method makes it possible to create a triplet which can be transmitted to the communication terminal to enable a blind verification of the validity (and of the knowledge) by the user device of the message m.
  • an authentication method which comprises, within the communication terminal:
  • the method comprises, for said user device, prior to said step of obtaining an authentication code, a phase of determining a set of encryption parameters, comprising:
  • a step of calculating, from the first private key (x), a public key such that X is an exponentiation of the generator g by the private key x, X g *;
  • a step of calculating, from the first private key (y), a public key / such that Y is an exponentiation of the generator g by the private key y, Y g y .
  • the method comprises, for said merchant's communication terminal, prior to said step of obtaining a first reference value, a phase of determining a set of encryption parameters, comprising:
  • a step of calculating, from the private key (z), a public key Z such that Z is an exponentiation of the generator g by the private key z, Z g z .
  • a user device comprising a general processing unit, a memory, a device comprising a secure processing unit and a secure memory and at least one reconfigurable payment transaction processing circuit with a terminal communication device comprising in particular an authentication of a piece of data, said user device comprising:
  • Such a user device is generally in the form of a smart phone type communication terminal.
  • a merchant terminal comprising a general processing unit, a terminal memory characterized comprising a secure processing unit and a secure memory and at least one reconfigurable payment transaction processing circuit with a device user including an authentication of a data
  • said merchant terminal comprising:
  • Such a merchant terminal may be in the form of a smartphone or tablet type terminal. Such a terminal may also be in the form of a payment terminal to which the means described above are added.
  • the various steps of the methods according to the invention are implemented by one or more software or computer programs, comprising software instructions intended to be executed by a data processor of a relay module according to the invention. invention and being designed to control the execution of the various process steps.
  • the invention is also directed to a program that can be executed by a computer or a data processor, which program includes instructions for controlling the execution of the steps of a method as mentioned above.
  • This program can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other form desirable shape.
  • the invention also provides a data carrier readable by a data processor, and including instructions of a program as mentioned above.
  • the information carrier may be any entity or device capable of storing the program.
  • the medium may comprise storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording medium, for example a floppy disk or a disk. hard.
  • the information medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means.
  • the program according to the invention can be downloaded in particular on an Internet type network.
  • the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question.
  • the invention is implemented by means of software and / or hardware components.
  • module may correspond in this document as well to a software component, a hardware component or a set of hardware and software components.
  • a software component corresponds to one or more computer programs, one or more subroutines of a program, or more generally to any element of a program or software capable of implementing a function or a program. set of functions, as described below for the module concerned.
  • Such a software component is executed by a data processor of a physical entity (terminal, server, gateway, router, etc.) and is capable of accessing the hardware resources of this physical entity (memories, recording media, bus communication cards, input / output electronic cards, user interfaces, etc.).
  • a hardware component corresponds to any element of a hardware set (or hardware) able to implement a function or a set of functions, as described below for the module concerned. It may be a hardware component that is programmable or has an integrated processor for executing software, for example an integrated circuit, a smart card, a memory card, an electronic card for executing a firmware ( firmware), etc. Each component of the previously described system naturally implements its own software modules.
  • Figure 1 shows a block diagram of the proposed technique for the creation of signature elements to the merchant terminal
  • FIG. 2 presents a block diagram of the proposed technique for verifying signature elements received from a user device
  • FIG. 3 schematically represents a communication terminal of the merchant according to the present
  • Figure 4 depicts schematically a user device according to the present.
  • the general principle of the invention consists in particular in integrating, in addition to a "challenge-response” scheme (or in place of this scheme), one or more additional operations.
  • the present invention proposes a protocol modification that makes it possible to resist attacks from terminals comprising malicious software.
  • this protocol modification also makes it possible to protect the terminals of the merchants themselves against unsolicited responses from other devices (that is to say, malicious devices that would attempt to attack an authentic merchant terminal).
  • This protocol modification offers an additional layer of protection against other types of attacks (DoS "Dismeai of Serverce", Concurency Attacks).
  • a "challenge / response" process is implemented so that the terminal the trader identifies (authenticates) the user device (and vice versa) through the exchange of a message m.
  • the present technique makes it possible to dispense with a scheme of this type. It is thus no longer necessary to carry out a "challenge response" type process.
  • the technique used is therefore not a “challenge-response” technique (which is an interactive process); nor is it a new signature (which is publicly verifiable); it is also not a message authentication code (which is only possible when sharing a secret key).
  • the approach adopted by the present technique is to ensure that the device of the user can prove that he has legitimately signed the message "m" (the data) to authenticate, without having to transmit this message (the message can for example be known from both sides: by the merchant terminal and by the user device, so instead of traditionally signing the message and transmitting it (ie ie to transmit the signed message), we adopt a strategy of transmitting proof of signature of this message (which may be complementary to either the transmission of this message or to the sharing of the knowledge of the message between the merchant terminal and the user device).
  • the merchant's terminal is not secure as such (it is a phone, a tablet or a PC), but that it has security resources.
  • security resources can for example take the form of a "secure element - SE” (secure element in French), a “Trusted Execution Environment - TEE” (secure execution environment in French) or a other hardware component or dedicated software.
  • TPC the payment application of the merchant's terminal
  • V the verification module (identification) called V (it is for example an SE, a TEE or more generally a secure processing unit, which may even be remote, that is to say, not present in the terminal).
  • the user device includes a proof module (of identity confirmation) called P (it is by example of an SE, a TEE or more generally a secure processing unit).
  • P a proof module (of identity confirmation)
  • the user device may be a conventional payment card, in which protocol and material modifications to implement this technique.
  • the present technique combines the principles of Schnorr signatures and Diffie-Hellman key exchange (for the hypothesis of absence of computational solution). However, unlike the Schnorr signatures (which includes a couple of data), the technique used uses a signature comprising a data triple.
  • the technique relies on the use of a private key pair and a public key pair, which is made available to the user device (and / or of the proof module).
  • the module P calculates (10), from the message m, a random datum f and a hash function H, an authentication code Sj;
  • the module P calculates (20), from the message m, the random data t, a public key Z of V, a first private key x of P and the authentication code Sj, a first component of signature S 2 ;
  • the module P calculates (30), from the message m, the random data t, the public key of V, a second private key of P and the authentication code S lt a second signature component S 3 ;
  • the module P transmits (40) to the merchant terminal (or module V), the authentication code S lt and the two signature components S 2 and S 3 .
  • the public key of the merchant terminal is either transmitted by the merchant terminal to the initialization of the payment transaction, or obtained, for example from a database, accessible from the user device.
  • the random datum f is, for its part, unilaterally chosen by the user device. It goes without saying that this public key should, according to good practice, be certified by a recognized authority. However this is not necessary for the operation of the invention, and is not even useful in some applications.
  • the public key used for the recipient of the signature is not necessarily the public key of the merchant terminal. It could be for example that of the payment processor (the module V), the terminal only relaying the information.
  • the merchant terminal From the data received ⁇ SS 2 and S 3 ), the merchant terminal (or the module V, or a remote recipient), will verify (by performing a calculation on these data) that they are synonymous with the knowledge ( by the user device or by P) of the message m.
  • the merchant terminal (or module V):
  • the method issues an authentication assertion. Based on the result of this verification the method transmits a step (90), by the communication terminal, of transaction validation data to a payment transaction processing system (STTP).
  • STTP payment transaction processing system
  • this hash function H this hash function is used by the module P to calculate the first authentication code Sj and by the module V to verify that the hash of U [r2] is equal to the first authentication code Sj;
  • the module V and the module P thus share the knowledge of this function of Hash;
  • the message m is determined by the merchant's terminal and by the user device;
  • the message authentication code Si may, depending on the embodiment, take the place of the authentication codes conventionally used in the payment protocols, and more particularly in the payment protocols implemented within the framework of the EMV specifications.
  • the proposed technique consists, in particular in a modification of the Schnorr signatures, adapted for two users (merchant terminal and user device).
  • the security of the proposed technique is based in particular on the Diffie-Hellman Decisional Hypothesis (DDH) which is a hypothesis of computation hardness based on cyclic groups (“Decisional Diffie-Hellman Assumption").
  • DDH Diffie-Hellman Decisional Hypothesis
  • the proposed technique is implemented based on a group G suitable for the Schnorr signature problem, with a generator g.
  • a group of Schnorr is a subgroup of Z the multiplicative group of integers modulos p for a prime number p.
  • the generator g of this group the following method is applied:
  • This group has a size and a size.
  • the size of this group and its other parameters are typically determined beforehand.
  • the size of the group G is of the order of 2 1024 (number 2 raised to the power 1024): this means that the size of the prime number p is of the order of 2 1024 .
  • the group G and the generator g corresponding have been the subject of a prior configuration, both in the device of the customer in the merchant terminal.
  • This pre-setting may have been done for example before the installation of the payment application on the side of the merchant or the payment application on the In other embodiments, this setting is made during the payment transaction.
  • the merchant terminal and the user device agree on the parameters of the group. In this case, considering that the group is renegotiated with each transaction, the size of this group can be reduced, for example by half ( 2,512 ) or more ( 2,256 ).
  • the device of the user which is for example a smartphone-type communication terminal, a tablet, is also equipped with an SE or a TEE (acting as a secure processing unit).
  • SE electronic book reader
  • TEE electronic book reader
  • the customer wants to adjust with his device.
  • This device therefore has the necessary data to make a payment. It may be, in a specific embodiment, credit card data (bearer name, PAN card number, validity date, verification code). It can also act other data, depending on the embodiments.
  • the installation phase thus consists in depositing, in the SE or the TEE of the user's device (also called module P), the private keys x and y used to construct the elements of the device. signatures.
  • This installation can typically be implemented by the installation of a payment application, as is the case of the payment application installed on the merchant's terminal.
  • the user device obtains or generates a private key comprising two prime integers (x, y) and, based on this private key, calculates a public key (X, Y), in which :
  • the two prime integers (x, y) each constitute a private key of the user device while the two integers X and Y each constitute the public key corresponding to these two private keys.
  • the two private key / public key pairs have been pre-parameterized in the client device.
  • This pre-setting can have been done for example before the installation of the payment application on the side of the user device.
  • the selection of these keys is performed during the payment transaction.
  • the user device selects its pairs ⁇ private keys / public keys ⁇ , based on the group G and the generator g.
  • the sizes of these parameters can advantageously be reduced, because of the relative uniqueness of the parameters themselves: they are used only for a transaction, which significantly limits the chances of fraud on the part of an attacker.
  • An advantageous possibility is to install these keys (and group parameters) at the same time as a banking application: for example the customer's banking application.
  • a banking application for example the customer's banking application.
  • the data required for payment are not necessarily credit card data, but may be data specifically prepared by the bank's banking application, or even specifically prepared, at the time of payment, by the financial institution itself. -even by a server to which the client's banking application is connected.
  • the customer opens his banking application; selects the fact that he wishes to make a payment; enter a possible confidential code (or authenticate for example by biometric means); and affixes its device on the merchant's terminal.
  • the banking application responds to the requests of the merchant's terminal (as explained herein) and the payment is made.
  • the benefits are real, both in terms of the security of the transaction (made by the banking application), and in terms of customer loyalty (which is no longer obliged to perform a payment with a third party application, for which it has no guarantee, for example as regards the security and confidentiality of the data transmitted and processed).
  • the user device provides these keys when the transaction, the merchant terminal is able to obtain these keys from a trusted third party.
  • the user device has a unique identifier (Uid), which is associated, with the trusted third party, two public keys X and Y.
  • the merchant terminal wishes to obtain these public keys, it transmits, to the trusted third party, a request for obtaining the keys based on the identifier (Uid) of the user device.
  • the user device Prior to this transmission, the user device transmitted its unique identifier to the merchant terminal (for example during the initialization of the transaction).
  • the pair of private key / public key has been the subject of a prior configuration in the merchant terminal.
  • This preliminary setting may have been done for example before the installation of the payment application on the side of the merchant terminal.
  • the selection of these keys can be performed during the payment transaction.
  • the user device acquires the public key Z of the merchant terminal. Either the merchant terminal transmits this key directly to the customer device, or the customer device uses a unique identifier of the merchant terminal (Cid) to obtain this public key from a trusted third party.
  • Cid unique identifier of the merchant terminal
  • the installation phase is performed during the installation of a payment application on a communication terminal (smartphone, tablet, or computer type) of the merchant, said communication terminal being equipped with a TEE and / or an SE (also called module V).
  • a communication terminal smarttphone, tablet, or computer type
  • said communication terminal being equipped with a TEE and / or an SE (also called module V).
  • This embodiment has the advantage of not having to communicate the private key z to the communication terminal as such: this data is only communicated to the SE or to the TEE. Thus, it is ensured that the communication terminal (and especially any fraudulent applications of this terminal), can not have access to this private key. 5.2.3. Run of Authentication
  • the authentication is implemented as follows:
  • the module P performs a transformation of the message m, in a digital form, so that this message m corresponds to an element of the group G: to do this, the message m is transformed into binary (binary representation of the message m) and the binary form is used to obtain a numerical form, the numerical form corresponding to an element of the group G; other methods may be conceivable depending on the applications;
  • the module P selects randomly (or pseudo randomly) an element f of the group G;
  • the module P calculates, from the message m, the random data f and the hash function H, an authentication code Sj according to the following formula:
  • the module P calculates, from the message m, the random data t, the public key Z, the first private key x of P and the authentication code S lt the first signature component S 2 , according to the following formula:
  • the module P calculates, from the message m, the random data t, the public key Z, the second private key y P and the authentication code S lt the second signature component S 3 ;
  • the module P transmits, to the merchant terminal (or module V), the authentication code S lt and the two signature components S 2 and S 3 .
  • the user device has not transmitted the message m, or even a signed version thereof because it is concatenated with a hazard (f), before being chopped to produce Sj. Therefore, an attacker, who would intercept for example the authentication code S lt could not, from it, infer the content of the message m.
  • S 2 and S 3 are quantities created from these three pieces of information and the message m. Exponentiation guarantees the protection of private keys, and the multiplication of the message by the exponentiated quantity protects its contents.
  • the merchant terminal receives the data S lt S 2 and S 3 . On the basis of these data, it will determine (with reasonable doubt) that these data correspond to the results of calculations made on the basis of the message m.
  • the merchant terminal implements the following steps:
  • H U [r2]
  • the merchant terminal has information of sufficient certainty to estimate that the user device is in possession of the message m and that the it is authentic. Therefore, the merchant's terminal can terminate the transaction (for example, he can send Sj to the payment system for validation of the transaction).
  • the merchant terminal makes the following calculations:
  • NFC Near Field Communication
  • the communication terminal acting as a payment terminal, comprises a memory 31 comprising in particular a buffer memory, a general processing unit 32, equipped for example with a microprocessor, and driven by a computer program 33, and a secure processing unit 34 (noted previously V), driven by a computer program 35, these processing units implementing the authentication method as described above to make a payment from the merchant.
  • the code instructions of the computer program 35 are for example loaded into a memory before being executed by the processor of the secure processing unit 34.
  • the processing unit 34 receives as input at least an authentication code and two signature elements.
  • the microprocessor of the secure processing unit 34 implements the steps of the authentication method, according to the instructions of the computer program 35, to supply, to the general processing unit 32, a representative data of transaction validation and where appropriate, transmit a transaction validation data to a processing system.
  • the general processing unit 32 performs a processing of these data to transmit them to a device of a customer (for example a smartphone, a tablet) as part of a payment transaction.
  • the communication terminal comprises, in addition to the buffer memory 31, communication means, such as network communication modules, data transmission means and data transmission circuits between the various components of the communication terminal.
  • communication means such as network communication modules, data transmission means and data transmission circuits between the various components of the communication terminal.
  • These means may be in the form of a particular processor implemented within the communication terminal.
  • this device implements a specific application that is in charge of carrying out the transactions, this application being for example provided by the manufacturer of the processor in question in order to allow the use of said processor or by a provider. payment solution for "open" terminals.
  • the processor comprises unique identification means. These unique identification means make it possible to ensure the authenticity of the processor.
  • the device further comprises the near-field communication means, referred to as NFC, and means for transmitting and receiving data from communication networks.
  • NFC near-field communication means
  • These means are also presented as communication interfaces for exchanging data on communication networks, interrogation means and database update.
  • the user device comprises a memory 41 consisting of a buffer memory, a general processing unit 42, equipped for example with a microprocessor, and driven by a computer program 43, and a secure processing unit. 44 (noted P, previously), driven by a computer program 45, these processing units implementing the authentication method as described above to make a payment from the merchant.
  • the code instructions of the computer program 45 are for example loaded into a memory before being executed by the processor of the secure processing unit 44.
  • the secure processing unit 44 receives as input, a message m of which it is necessary to prove the knowledge.
  • the microprocessor of the secure processing unit 44 implements the steps of the authentication method, according to the instructions of the computer program 45 to supply, to the general processing unit 42, at least one authentication code and two signature elements to be transmitted to a merchant terminal.
  • the general processing unit 42 carries out the transmission of these data.
  • the user device comprises, in addition to the buffer memory 41, communication means, such as network communication modules, data transmission means and data transmission circuits between the various components of the device. user.
  • these means may be in the form of a particular processor implemented within the user device.
  • this device implements a specific application that is in charge of carrying out the transactions, this application being for example provided by the manufacturer of the processor in question in order to allow the use of said processor or by a provider. payment solution for "open" terminals.
  • the processor comprises unique identification means. These unique identification means make it possible to ensure the authenticity of the processor.
  • the device further comprises the near-field communication means, referred to as NFC, and means for transmitting and receiving data from communication networks.
  • NFC near-field communication means
  • These means are also presented as communication interfaces for exchanging data on communication networks, interrogation means and database update.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Accounting & Taxation (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Signal Processing (AREA)
  • Finance (AREA)
  • Algebra (AREA)
  • Mathematical Physics (AREA)
  • Pure & Applied Mathematics (AREA)
  • Computing Systems (AREA)
  • Mathematical Optimization (AREA)
  • Mathematical Analysis (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Power Engineering (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention se rapporte à un procédé d'authentification d'au moins une donnée, procédé mis en œuvre lors d'une transaction de paiement intervenant entre un terminal de communication d'un commerçant et un dispositif d'utilisateur, procédé du type comprenant l'authentification par le terminal de communication d'au moins un message m générée par le dispositif d'utilisateur, par l'intermédiaire d'une liaison de données sans fils en champs proche. Un tel procédé comprend, au sein du dispositif d'utilisateur : - une étape d'obtention (10), à partir du message m, d'une donnée aléatoire t et d'une fonction de hachage H, d'un code d'authentification S1; - une étape d'obtention (20), à partir du message m, de la donnée aléatoire t, d'une clé publique Z du terminal de communication, d'une première clé privée x du dispositif d'utilisateur et du code d'authentification S1, d'un premier composant de signature S2; - une étape d'obtention (30), à partir du message m, de la donnée aléatoire t, de la clé publique de Z du terminal de communication, d'une deuxième clé privée y du dispositif d'utilisateur et du code d'authentification S1, d'un deuxième composant de signature S3; - une étape de transmission (40), au terminal de communication, du code d'authentification S1, et des deux composants de signature S2 et S3.

Description

Procédé d'authentification de données de paiement, dispositifs et programmes correspondants.
1. Domaine
L'invention se rapporte au domaine de la sécurisation des données échangées par l'intermédiaire d'un protocole de transmission de données sans contact. La technique se rapporte plus particulièrement à la transmission de données de type NFC, dans laquelle on effectue une transmission entre un premier dispositif et un deuxième dispositif séparés d'une distance de l'ordre d'une dizaine de centimètre au plus. La technique ne s'applique pas et n'est pas destinée à s'appliquer dans le cadre de techniques de transmission de données de type WiFi, WiMax, LTE, dont les technologies de transmission sont différentes.
2. Art Antérieur
De nombreux dispositifs de la vie quotidienne sont aptes à communiquer et à échanger des données entre eux. Une part croissante de dispositifs utilisent, pour ce faire, des protocoles d'échange de données dit "en champ proches" ou encore NFC. Parfois, ces techniques de transmission de données sont également appelées FID. Cette appellation n'est pas correcte puisque NFC signifie communication en champ proche, tandis que RFID se rapporte à des moyens d'identification par fréquence radio. Les deux utilisent des signaux radio pour toutes sortes de fins de repérage et de suivi, en remplaçant parfois des codes à barres. Toutes deux utilisent des moyens de transmission de données à courte portée.
Or, l'utilisation de ce type de technologie suscite encore des craintes et des interrogations de la part des utilisateurs. Nombreux sont ceux qui n'accordent pas ou peu confiance à ces technologies, plus particulièrement lorsqu'il s'agit de les utiliser à des fins de traitement de données personnelles et/ou confidentielles. C'est par exemple le cas du paiement. Relativement récemment, des dispositifs de paiement sans contact ont fait leur apparition. Il s'agit par exemple des cartes de paiement sans contact qui permettent d'effectuer un paiement (dont le montant est généralement plafonné) en apposant (ou en rapprochant) la carte de paiement d'un terminal de paiement compatible. Il s'agit également des terminaux de communication, qui intègrent également des "puces" sans contact : ces puces (également appelées "contactless chip") et qui offrent des capacités d'échange de données aux terminaux de communication, capacités qui peuvent être utilisées pour effectuer des paiements, un peu comme si le terminal de communication imitait le comportement d'une carte de paiement sans contact. De nombreuses rumeurs, souvent infondées, laissent entendre qu'une communication ou qu'un paiement réalisé sans contact serait peu sûr. Il est également souvent rapporté que les dispositifs seraient peu sécurisés et qu'il serait possible de récupérer les données qui sont contenus dans ces dispositifs à l'insu de l'utilisateur. Bien que ces rumeurs soient souvent sans fondement, il existe cependant des risques lors de la transmission de données entre les dispositifs et notamment lors de la transmission de données de paiement. Les risques, cependant, ne proviennent pas de la technologie employée, en elle- même (NFC), mais généralement de l'utilisateur lui-même. Ainsi par exemple, dans le cas d'un terminal de communication utilisant l'interface NFC pour effectuer un paiement, il est possible que l'utilisateur ait installé une application peu sure, voire une application malveillante, dont l'objectif est d'utiliser des données de paiement à des fins de fraudes. La situation est la même du côté du terminal du commerçant.
Par exemple, dans le cadre d'une communication entre un dispositif d'utilisateur (un terminal de communication de type smartphone) et un terminal de paiement, notamment en utilisant des protocoles NFC pour le paiement, il est nécessaire que le dispositif et le terminal authentifie des données. À cette fin, le dispositif met en œuvre un protocole d'authentification avec le terminal (par exemple un terminal de paiement, une borne d'un marchand, ou tout autre dispositif approprié). Le terminal contrôle que la phase d'authentification a réussi et dans le cas contraire refuse la transaction ou déclenche une alerte, ou met en œuvre tout autre comportement jugé approprié dans une telle situation.
Dans les scénarios typiques, le terminal effectuant ces contrôles est, un dispositif sécurisé (comme un terminal de paiement). Il a été conçu pour prévenir la plupart des types possibles d'intrusion, tant matérielles que logicielles. Mais si le terminal de paiement est un dispositif tiers (terminal de communication de type tablette, smartphone, écran), alors la sécurité de ce terminal de communication (tiers) ne peut pas être garantie, pas plus que l'origine des applications installées sur ce terminal (par le commerçant lui-même). Si le commerçant n'est pas vigilant, il se peut que les applications installées sur ce terminal soient frauduleuses.
On présente ci-après un cas de dysfonctionnement possible, mis en œuvre lors d'un paiement entre un terminal de communication et un dispositif d'utilisateur. On appelle "V" le vérificateur (par exemple le terminal ou l'appareil du marchand) et "P" le prouveur (dispositif de l'utilisateur : smartphone, tablette).
Les protocoles de paiement travaillent habituellement de la façon suivante, au cours de la transaction : V demande à P de signer numériquement des données. P signe les données, conformément à ce qui est demandé par V et transmet les données signées à V. Cette signature est vérifiée par V, et si elle est correcte, alors la transaction est acceptée et transférée dans le reste de la chaîne de traitement des paiements. Une telle procédure est appelée un "défi-réponse" (challenge response) et est utilisée par exemple par les spécifications EMV.
Le problème auquel il est proposé de remédier est le suivant : si V fonctionne sur un dispositif non sécurisé (i.e. un terminal de type tablette, PC ou autre, auquel on a adjoint des fonctionnalités de paiement) qui est infecté par un logiciel malveillant (installé par le commerçant ou par un tiers mal intentionné), alors ce logiciel peut abuser le terminal du client P. Un tel abus peut par exemple prendre la forme d'une succession de transactions (invisibles). Ceci peut être réalisé par exemple lorsque le terminal du commerçant force le dispositif de l'utilisateur à signer des messages arbitraires. Le dispositif de l'utilisateur, en position « d'esclave », est alors obligé de signer ces données. Le logiciel malveillant installé sur le terminal du commerçant se sert ensuite de ces données signées pour créer des transactions frauduleuses.
C'est le paradoxe de ces traitements cryptographiques : il est certain que les traitements réalisés sont bons (car ils mettent en œuvre des traitements cryptographiques), en revanche, l'utilisation qui est faite des résultats de ces traitements cryptographiques ne peut pas être garantie.
3. Résumé
L'invention ne pose pas ces problèmes de l'art antérieur. Plus particulièrement, l'invention apporte une solution simple à la problématique préalablement identifiée. Cette solution est entièrement compatible avec les dispositifs matériels existants.
Plus particulièrement, il est proposé un procédé d'authentification d'au moins une donnée, procédé mis en œuvre lors d'une transaction de paiement intervenant entre un terminal d'un commerçant et un dispositif d'utilisateur, procédé qui comprend la création d'un triplet d'authentification, comprenant un code d'authentification et deux composants de signature, ce triplet étant construit par la dispositif d'utilisateur et n'étant vérifiable que par le terminal du commerçant.
Pour ce faire, il est divulgué un procédé d'authentification d'au moins une donnée, procédé mis en œuvre lors d'une transaction de paiement intervenant entre un terminal de communication d'un commerçant et un dispositif d'utilisateur, procédé du type comprenant l'authentification par le terminal de communication d'au moins un message m générée par le dispositif d'utilisateur, par l'intermédiaire d'une liaison de données sans fils en champs proche, procédé caractérisé en ce qu'il comprend, au sein du dispositif d'utilisateur :
une étape d'obtention, à partir du message m, d'une donnée aléatoire f et d'une fonction de hachage H, d'un code d'authentification Sj ;
une étape d'obtention, à partir du message m, de la donnée aléatoire t, d'une clé publique Z du terminal de communication, d'une première clé privée x du dispositif d'utilisateur et du code d'authentification Slt d'un premier composant de signature S2 ; une étape d'obtention, à partir du message m, de la donnée aléatoire t, de la clé publique de Z du terminal de communication, d'une deuxième clé privée y du dispositif d'utilisateur et du code d'authentification Slt d'un deuxième composant de signature
S3 ;
une étape de transmission, au terminal de communication, du code d'authentification Sj, et des deux composants de signature S2 et S3.
Un tel procédé permet de créer un triplet qui peut être transmis au terminal de communication pour permettre une vérification, en aveugle, de la validité (et de la connaissance) par le dispositif d'utilisateur, du message m.
Selon un autre aspect, il est également divulgué un procédé d'authentification qui comprend, au sein du terminal de communication :
- une étape d'obtention, à partir du premier composant de signature S2, d'une clé publique X du dispositif d'utilisateur, d'une clé privée z du terminal de communication, et du code d'authentification Slt d'une première valeur de référence, notée U^; une étape d'obtention, à partir du deuxième composant de signature S3, d'une clé publique Y du dispositif d'utilisateur, de la clé privée z, et du code d'authentification Sj, d'une deuxième valeur de référence, notée U[r2] ; une étape de vérification que la première valeur de référence U[rl] est égale à la deuxième valeur de référence U[r2] ; et, lorsque les deux valeurs sont égales :
une étape de vérification que la valeur H(U[r2]) et/ou H(U[rll) est égale à Sj.
une étape de délivrance d'une assertion d'authentification lorsque l'étape de vérification précédente est positive.
Ainsi, sans avoir fait référence au message, il est possible de vérifier la validité du triplet reçu.
Selon un mode de réalisation particulier, le procédé comprend, pour ledit dispositif d'utilisateur, préalablement à ladite étape d'obtention d'un code d'authentification, une phase de détermination d'un ensemble de paramètres de chiffrement, comprenant :
une étape d'obtention d'un groupe de Schnor (G) et d'un générateur de ce groupe (g) ; une étape d'obtention de la première clé privée (x), ladite clé privée étant un élément du groupe G ;
une étape d'obtention de la deuxième clé privée (y), ladite clé privée étant un élément du groupe G ;
une étape de calcul, à partir de la première clé privée (x), d'une clé publique telle que X est une exponentiation du générateur g par la clé privée x, X=g* ;
une étape de calcul, à partir de la première clé privée (y), d'une clé publique / telle que Y est une exponentiation du générateur g par la clé privée y, Y=gy.
Selon un mode de réalisation particulier, le procédé comprend, pour ledit terminal de communication du commerçant, préalablement à ladite étape d'obtention d'une première valeur de référence, une phase de détermination d'un ensemble de paramètres de chiffrement, comprenant :
une étape d'obtention d'un groupe de Schnor (G) et d'un générateur de ce groupe (g) ; une étape d'obtention de la clé privée (z), ladite clé privée étant un élément du groupe
G ;
une étape de calcul, à partir de la clé privée (z), d'une clé publique Z telle que Z est une exponentiation du générateur g par la clé privée z, Z=gz.
Selon un mode de réalisation particulier :
l'étape d'obtention du code d'authentification Sj met en œuvre le calcul suivant : Sj = H(m | | t), ou I I est l'opérateur de concaténation ; l'étape d'obtention du premier composant de signature S2 met en œuvre le calcul suivant : S2 = (ml lt)Z*sl ; l'étape d'obtention du deuxième composant de signature S3 met en œuvre le calcul suivant : S3 = (m/ /t) 51.
Selon un mode de réalisation particulier :
l'étape d'obtention de la première valeur de référence U[rl] met en œuvre le calcul suivant : U[rl] = s2X"zsl ;
l'étape d'obtention de la deuxième valeur de référence U[r2] met en œuvre le calcul suivant U[r2] = s3Y"zsl.
Selon un autre aspect, il est également divulgué un dispositif d'utilisateur comprenant une unité de traitement général, une mémoire, dispositif comprenant une unité de traitement sécurisé et une mémoire sécurisée et au moins un circuit reconfigurable de traitement de transaction de paiement avec un terminal de communication comprenant notamment une authentification d'une donnée, ledit dispositif d'utilisateur comprenant :
- des moyens d'obtention, à partir du message m, d'une donnée aléatoire f et d'une fonction de hachage H, d'un code d'authentification Sj ;
des moyens d'obtention, à partir du message m, de la donnée aléatoire t, d'une clé publique Z du terminal de communication, d'une première clé privée x du dispositif d'utilisateur et du code d'authentification Slt d'un premier composant de signature S2 ; - des moyens d'obtention, à partir du message m, de la donnée aléatoire t, de la clé publique de Z du terminal de communication, d'une deuxième clé privée y du dispositif d'utilisateur et du code d'authentification S d'un deuxième composant de signature S3 ;
des moyens de transmission, au terminal de communication, du code d'authentification Slt et des deux composants de signature S2 et S3.
Un tel dispositif d'utilisateur se présente généralement sous la forme d'un terminal de communication de type téléphone intelligent.
Selon un autre aspect, il est également divulgué un terminal de commerçant comprenant une unité de traitement général, une mémoire, terminal caractérisé comprenant une unité de traitement sécurisé et une mémoire sécurisée et au moins un circuit reconfigurable de traitement de transaction de paiement avec un dispositif d'utilisateur comprenant notamment une authentification d'une donnée, ledit terminal de commerçant comprenant :
des moyens d'obtention, à partir du premier composant de signature S2, d'une clé publique X du dispositif d'utilisateur, d'une clé privée z du terminal de communication, et du code d'authentification Slt d'une première valeur de référence, notée U^ ; des moyens d'obtention, à partir du deuxième composant de signature S3, d'une clé publique Y du dispositif d'utilisateur, de la clé privée z, et du code d'authentification Sj, d'une deuxième valeur de référence, notée U[r2] ;
des moyens de vérification que la première valeur de référence U[rl] est égale à la deuxième valeur de référence U[r2] ; et, lorsque les deux valeurs sont égales :
des moyens de vérification que la valeur H(U[r2]) et/ou H(U[rll) est égale à Sj.
des moyens de délivrance d'une assertion d'authentification lorsque l'étape de vérification précédente est positive.
Un tel terminal de commerçant peut se présenter sous la forme d'un terminal de type smartphone ou tablette. Un tel terminal peut également se présenter sous la forme d'un terminal de paiement auquel on adjoint les moyens précédemment décrits.
Selon une implémentation préférée, les différentes étapes des procédés selon l'invention sont mises en œuvre par un ou plusieurs logiciels ou programmes d'ordinateur, comprenant des instructions logicielles destinées à être exécutées par un processeur de données d'un module relais selon l'invention et étant conçu pour commander l'exécution des différentes étapes des procédés.
En conséquence, l'invention vise aussi un programme, susceptible d'être exécuté par un ordinateur ou par un processeur de données, ce programme comportant des instructions pour commander l'exécution des étapes d'un procédé tel que mentionné ci-dessus.
Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
L'invention vise aussi un support d'informations lisible par un processeur de données, et comportant des instructions d'un programme tel que mentionné ci-dessus. Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy dise) ou un disque dur.
D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.
Selon un mode de réalisation, l'invention est mise en œuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme "module" peut correspondre dans ce document aussi bien à un composant logiciel, qu'à un composant matériel ou à un ensemble de composants matériels et logiciels.
Un composant logiciel correspond à un ou plusieurs programmes d'ordinateur, un ou plusieurs sous-programmes d'un programme, ou de manière plus générale à tout élément d'un programme ou d'un logiciel apte à mettre en œuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Un tel composant logiciel est exécuté par un processeur de données d'une entité physique (terminal, serveur, passerelle, routeur, etc.) et est susceptible d'accéder aux ressources matérielles de cette entité physique (mémoires, supports d'enregistrement, bus de communication, cartes électroniques d'entrées/sorties, interfaces utilisateur, etc.).
De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware) apte à mettre en œuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Il peut s'agir d'un composant matériel programmable ou avec processeur intégré pour l'exécution de logiciel, par exemple un circuit intégré, une carte à puce, une carte à mémoire, une carte électronique pour l'exécution d'un micrologiciel (firmware), etc. Chaque composante du système précédemment décrit met bien entendu en œuvre ses propres modules logiciels.
Les différents modes de réalisation mentionnés ci-dessus sont combinables entre eux pour la mise en œuvre de l'invention.
4. Dessins
D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation préférentiel, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels :
la figure 1 présente un synoptique de la technique proposée pour la création d'éléments de signature à destination du terminal du commerçant ;
la figure 2 présente un synoptique de la technique proposée pour la vérification d'éléments de signature reçus d'un dispositif d'utilisateur ;
la figure 3 représente schématiquement un terminal de communication du commerçant selon la présente ;
la figure 4 décrit représente schématiquement un dispositif d'utilisateur selon la présente.
5. Description
5.1. Principe général
Comme explicité précédemment, le principe général de l'invention consiste notamment à intégrer, en plus d'un schéma de "défi-réponse" (ou à la place de ce schéma), une ou plusieurs opérations additionnelles. La présente invention propose une modification protocolaire qui permet de résister aux attaques des terminaux comprenant des logiciels malveillants. À titre secondaire, cette modification protocolaire permet également de protéger les terminaux des commerçants eux-mêmes contre des réponses non sollicités provenant d'autres appareils (c'est à dire des appareils malveillants qui tenteraient d'attaquer un terminal de commerçant authentique). Cette modification protocolaire offrant ainsi une couche supplémentaire de protection contre d'autres types d'attaques (DoS "Déniai of Serverce", Concurency Attacks - attaques par concurrence d'accès aux ressources-).
Classiquement, lorsqu'une transaction de paiement est effectuée entre un terminal d'un commerçant et un dispositif d'utilisateur, un processus de type "challenge/response" ( "défi/réponse" en français) est mis en œuvre afin que le terminal du commerçant identifie (authentifie) le dispositif d'utilisateur (et vice versa) par l'intermédiaire de l'échange d'un message m. La présente technique permet de se passer d'un schéma de ce type. Il n'est ainsi plus nécessaire de réaliser un processus de type « défi réponse ». La technique mise en œuvre n'est donc pas une technique de type « défi-réponse » (qui est un processus interactif) ; il ne s'agit pas non plus d'une nouvelle signature (qui est vérifiable publiquement) ; il ne s'agit pas non plus d'un code d'authentification de message (qui n'est possible qu'en cas de partage d'une clé secrète).
Plus particulièrement, l'approche retenue par la présente technique est de faire en sorte que le dispositif de l'utilisateur puisse prouver qu'il a légitimement signé le message « m » (les données) à authentifier, sans pour autant avoir à transmettre ce message (le message peut par exemple être connu de part et d'autre : par le terminal du commerçant et par le dispositif d'utilisateur. Ainsi, au lieu de signer de manière traditionnelle le message et de le transmettre (c'est-à-dire de transmettre le message signé), on adopte une stratégie de transmission de preuve de signature de ce message (qui peut être complémentaire soit à la transmission de ce message, soit au partage de la connaissance du message entre le terminal du commerçant et le dispositif d'utilisateur).
On suppose que le terminal du commerçant n'est pas sécurisé en tant que tel (il s'agit d'un téléphone, d'une tablette ou d'un PC), mais qu'il dispose de ressources de sécurisation. Ces ressources de sécurisation peuvent par exemple prendre la forme d'un "secure élément - SE" (élément sécurisé en français), d'un "Trusted Execution Environment - TEE" (environnement d'exécution sécurisé en français) ou encore d'un autre composant matériel ou logiciel dédié. On suppose, pour les explications qui vont suivre, que l'application de paiement du terminal du commerçant s'appelle TPC, et qu'elle comprend un module de vérification (d'identification) appelé V (il s'agit par exemple d'un SE, d'un TEE ou plus généralement d'une unité de traitement sécurisée, qui peut même être distante, c'est-à-dire non présente dans le terminal). On suppose également qu'il existe une application de paiement sur le dispositif d'utilisateur DU, et que le dispositif de l'utilisateur (DU) comprend un module de preuve (de confirmation d'identité) appelé P (il s'agit par exemple d'un SE, d'un TEE ou plus généralement d'une unité de traitement sécurisée). Dans un autre mode de réalisation, le dispositif d'utilisateur peut être une carte de paiement classique, dans laquelle on a effectué des modifications protocolaires et matérielles permettant de mettre en œuvre la présente technique.
D'une manière générale, la présente technique combine les principes de signatures de Schnorr et d'échange de clés Diffie-Hellman (pour l'hypothèse d'absence de solution calculatoire). Toutefois, à la différence des signatures de Schnorr (qui comprend un couple de données), la technique mise en œuvre utilise une signature comprenant un triplet de données.
L'utilisation d'un tel triplet, en lieu et place d'un couple (tel que défini dans la signature de Schnorr) permet de de créer (de manière sécurisée) une restriction supplémentaire : seul un destinataire particulier peut vérifier la signature (à la différence des signatures de Schnorr qui sont publiquement vérifiables).
Par ailleurs, à la différence du procédé classique de Schnorr, la technique repose sur l'utilisation d'un couple de clé privées et d'un couple de clé publiques, qui est mis à la disposition du dispositif d'utilisateur (et/ou du module de preuve).
On décrit, en relation avec les figures 1 et 2, la technique proposée authentifiant des données entre un terminal de communication d'un commerçant et un dispositif d'utilisateur.
Comme explicité précédemment, on suppose que V et P ont chacun, par leurs propres moyens, obtenus la connaissance des données à authentifier (le message m). Lors de la mise en œuvre conjointe des applications de paiement TPC et DU, le procédé mis en œuvre est le globalement le suivant :
le module P calcule (10), à partir du message m, d'une donnée aléatoire f et d'une fonction de hachage H, un code d'authentification Sj ;
le module P calcule (20), à partir du message m, de la donnée aléatoire t, d'une clé publique Z de V, d'une première clé privée x de P et du code d'authentification Sj, un premier composant de signature S2 ;
le module P calcule (30), à partir du message m, de la donnée aléatoire t, de la clé publique de V, d'une deuxième clé privée de P et du code d'authentification Slt un deuxième composant de signature S3 ;
le module P transmet (40), au terminal du commerçant (ou au module V), le code d'authentification Slt et les deux composants de signature S2 et S3.
Ces étapes, effectuées sur le dispositif d'utilisateur (ou le module P) sont mises en œuvre sur la base d'une part de clés privées (deux) à disposition du dispositif d'utilisateur et d'une clé publique du terminal du commerçant. Dans cet exemple, on suppose que m est connu de part et d'autre avant, et c'est juste l'aléa f qui est transmis, avec (Sj, S¾ S3) qui « signe » le message.
La clé publique du terminal du commerçant est soit transmise par le terminal du commerçant à l'initialisation de la transaction de paiement, soit obtenue, par exemple à partir d'une base de données, accessible depuis le dispositif d'utilisateur. La donnée aléatoire f est, quant à elle, unilatéralement choisie par le dispositif d'utilisateur. Il va de soi que cette clé publique devrait, selon les bonnes pratiques, être certifiée par une autorité reconnue. Toutefois cela n'est pas nécessaire au fonctionnement de l'invention, et n'est même pas utile dans certaines applications. La clé publique utilisée pour le destinataire de la signature n'est pas nécessairement la clé publique du terminal commerçant. Ce pourrait être par exemple celle du processeur de paiement (le module V), le terminal ne faisant que relayer l'information.
À partir des données reçues {S S2 et S3 ), le terminal du commerçant (ou le module V, ou un destinataire distant), va vérifier (en réalisant un calcul sur ces données) qu'elles sont bien synonymes de la connaissance (par le dispositif d'utilisateur ou par P) du message m.
Pour ce faire, le terminal du commerçant (ou le module V) :
calcule (50), à partir du premier composant de signature S2, de la clé publique X
(correspondant à la clé privée x), de sa propre clé privée z, et du code d'authentification Slt une première valeur de référence, notée U[rl]
calcule (60), à partir du deuxième composant de signature S3, de la clé publique Y
(correspondant à la clé privée y), de sa propre clé privée z, et du code d'authentification Slt une deuxième valeur de référence, notée U[r2] ;
vérifie (70) que la première valeur de référence U[rl] est égale à la deuxième valeur de référence U[r2] ; et, lorsque les deux valeurs sont égales :
vérifie (80) que la valeur H(U[r2]) est égale à Sj.
Lorsque l'étape de vérification (80) est positive, le procédé délivre une assertion d'authentification. En fonction du résultat de cette vérification le procédé une étape de transmission (90), par le terminal de communication, d'une donnée de validation de transaction à un système de traitement de transaction de paiement (STTP).
Ainsi, lorsque les deux vérifications précédentes sont vraies, on en déduit que le dispositif d'utilisateur (ou le module P) connaît le message m. Pour mettre en œuvre le procédé tel que décrit précédemment, dans le cadre d'une opération de paiement intervenant entre le dispositif d'utilisateur et le terminal du commerçant, selon la présente, il n'est nécessaire de ne disposer (en commun) que deux éléments :
la fonction de hachage H : cette fonction de hachage est utilisée par le module P pour calculer le premier code d'authentification Sj et par le module V pour vérifier que le hachage de U[r2] est égal au premier code d'authentification Sj ; Le module V et le module P partage donc la connaissance de cette fonction de Hachage ;
des paires de {clés publiques ; clés privées} qui sont utilisées pour créer les éléments de signatures ;
- le message m : le message m est déterminé par le terminal du commerçant et par le dispositif d'utilisateur ;
À l'aide de la technique proposé, il n'est pas nécessaire que le dispositif d'utilisateur transmette la valeur de ce message m au terminal du commerçant : il suffit qu'il transmette la preuve qu'il en a connaissance. Comme le message m ne transite pas par le réseau, il ne peut pas être intercepté et modifié. Il n'est donc pas possible de modifier les composantes de la transaction de paiement.
Par ailleurs, à l'aide de cette technique, seul le terminal du commerçant (ou le module V) est en mesure de vérifier la validité des données transmises par le dispositif d'utilisateur (ou le module P). De plus, il n'est même pas nécessaire que le terminal du commerçant (ou le module V), dispose du message m. En effet, dans la technique proposée, le message m n'est pas utilisé par le commerçant : seul le code d'authentification Si est utilisé. Dès lors, le code d'authentification Si peut être utilisé comme preuve de la validité de la transaction de paiement, sans qu'il soit nécessaire, pour le terminal du commerçant, d'avoir connaissance de ce message. Ainsi, le code d'authentification de message Si peut, en fonction de mode de réalisation, prendre la place des codes d'authentification traditionnellement utilisés dans les protocoles de paiement, et plus particulièrement dans les protocoles de paiement mis en œuvre dans la cadre des spécifications EMV. On comprend, à lecture de ce qui précède, que les procédés mis en œuvre tant dans le terminal du commerçant que dans le dispositif d'utilisateur, sont indépendants. On comprend également que le terminal du commerçant et le dispositif d'utilisateur sont indépendant l'un de l'autre. Dès lors, il est possible de mettre en œuvre les procédés et dispositifs décrits dans un système qui comprendra un dispositif d'utilisateur et un terminal de commerçant effectuant une transaction de paiement.
5.2. Mode de réalisation
Dans ce mode de réalisation purement illustratif, la technique proposée consiste, notamment en une modification des signatures de Schnorr, adaptée pour deux utilisateurs (terminal du commerçant et dispositif d'utilisateur). La sécurité de la technique proposée est notamment basée sur l'hypothèse Décisionnelle Diffie-Hellman (DDH) qui est une hypothèse de dureté de calcul basée sur des groupes cycliques (« Decisional Diffie-Hellman assumption » en anglais).
Dans ce mode de réalisation, préalablement à la mise en œuvre du protocole d'échange sécurisé, on suppose que deux phases d'installation ont été réalisées : une du côté du terminal du commerçant et une du côté du dispositif de l'utilisateur.
En premier lieu, la technique proposée est mise en œuvre en se basant sur un groupe G convenant à la problématique des signatures de Schnorr, avec un générateur g.
Un groupe de Schnorr est un sous-groupe de Z le groupe multiplicatif des entiers modulos p pour un nombre premier p. Pour générer un tel groupe, on génère p, q, et r tels que p=qr+l, avec p et q étant des nombres premiers. Pour obtenir le générateur g de ce groupe, on applique la méthode suivante :
pour chaque entier h strictement supérieur à 1 et strictement inférieur à p :
■ si hr≡ 1 (mod p) alors passer à l'entier suivant ;
■ sinon, la valeur g = hr (mod p) est un générateur sous-groupe de Z d'ordre q ;
Ce groupe possède une ainsi une taille donnée. La taille de ce groupe et ses autres paramètres sont typiquement déterminés préalablement. Dans un mode de réalisation particulier, la taille du groupe G est de l'ordre de 21024 (nombre 2 élevé à la puissance 1024) : cela signifie que la taille du nombre premier p est de l'ordre de 21024.
Dans ce mode de réalisation, le groupe G et le générateur g correspondant ont fait l'objet d'un paramétrage préalable, tant dans le dispositif du client que dans le terminal du commerçant. Ce paramétrage préalable peut avoir été fait par exemple avant l'installation de l'application de paiement du côté du commerçant ou de l'application de paiement du côté du Dans d'autres modes de réalisation, ce paramétrage est réalisé lors de la transaction de paiement. Le terminal du commerçant et le dispositif d'utilisateur s'entendent sur les paramètres du groupe. Dans ce cas, compte tenu du fait que le groupe est renégocié à chaque transaction la taille de ce groupe peut être réduite, par exemple de moitié (2512) ou plus (2256).
5.2.1. Phase d'installation du côté du dispositif de l'utilisateur
Le dispositif de l'utilisateur, qui est par exemple un terminal de communication de type smartphone, une tablette, est également équipé d'un SE ou d'un TEE (agissant comme une unité de traitement sécurisé). On rappelle que dans ce mode de réalisation, le client souhaite régler avec son dispositif. Ce dispositif dispose donc des données nécessaires à la réalisation d'un paiement. Il peut s'agir, dans un mode de réalisation spécifique, de données de carte bancaire (nom du porteur, numéro de Carte PAN, date de validité, code de vérification). Il peut également d'agir d'autres données, en fonction des modes de réalisation.
Dans le cadre de la présente technique, la phase d'installation consiste ainsi notamment à déposer, dans le SE ou le TEE du dispositif de l'utilisateur (appelé également module P), les clés privées x et y utilisée pour construire les éléments de signatures.
Cette installation peut typiquement être mise en œuvre par l'installation d'une application de paiement, comme cela est le cas de l'application de paiement installée sur le terminal du commerçant.
Sur la base de ce groupe G et du générateur sélectionné g :
le dispositif d'utilisateur (ou le module de preuve P) obtient ou génère une clé privée comprenant deux nombres entiers premiers (x,y) et, sur la base de cette clé privée, calcule une clé publique (X,Y), dans laquelle :
x = gx ;
■ Y = gv ;
Ainsi, dans ce mode de réalisation, les deux nombres entiers premiers (x,y) constituent chacun une clé privée du dispositif d'utilisateur tandis que les deux nombres entiers X et Y constituent chacun la clé publique correspondant à ces deux clés privées.
Dans ce mode de réalisation, les deux paires de clés privées/clé publiques ont fait l'objet d'un paramétrage préalable dans le dispositif du client. Ce paramétrage préalable peut avoir été fait par exemple avant l'installation de l'application de paiement du côté du dispositif d'utilisateur.
Dans d'autres modes de réalisation, la sélection de ces clés est réalisée lors de la transaction de paiement. Avant d'initier la transaction de paiement, le dispositif d'utilisateur effectue le choix de ses couples {clés privées/clés publiques}, sur la base du groupe G et du générateur g. Lorsque l'ensemble des paramètres est négocié au moment de la transaction (Groupe G, générateur g, clés publiques et privées) les tailles de ces paramètres peuvent avantageusement être réduites, du fait de la relative unicité des paramètres en eux-mêmes : ils ne sont en effet utilisés que pour une transaction, ce qui limite de manière importante les possibilités de fraude de la part d'un attaquant.
Une possibilité avantageuse est d'installer ces clés (et paramètres de groupes) en même temps qu'une application bancaire : par exemple l'application bancaire du client. En effet, avec le développement des applications bancaires (application qui permettent de gérer ses comptes depuis un smartphone o une tablette), une solution intéressante, tant pour le client que pour la banque, peut consister à disposer d'une application bancaire qui permette également de réaliser des paiements. Dans ce cas, les données nécessaires au paiement ne sont pas nécessairement des données de carte bancaire, mais peuvent être des données spécifiquement préparées par l'application bancaire de la banque, voire spécifiquement préparée, au moment du paiement, par l'établissement financier lui-même (c'est à dire par un serveur auquel l'application bancaire du client est connectée).
Pour effectuer un paiement, dans ce cas particulier, le client ouvre son application bancaire; sélectionne le fait qu'il souhaite effectuer un paiement; saisit un éventuel code confidentiel (ou s'authentifie par exemple par voie biométrique); et appose son dispositif sur le terminal du commerçant. L'application bancaire réagit aux requêtes du terminal du commerçant (comme explicité dans la présente) et le paiement est effectué. Pour la banque, comme pour le client, les bénéfices sont réels, tant en termes de sécurité de la transaction (faite par l'application bancaire), qu'en termes de fidélisation du client (qui n'est plus obligé d'effectuer un paiement avec une application tierce, dont il n'a pas de garantie, par exemple au niveau de la sécurité et de la confidentialité des données transmises et traitées).
Pour la mise en œuvre de cette technique, il importe que le terminal du commerçant ait connaissance des clés publiques X et Y : soit le dispositif d'utilisateur fournit ces clés lors de la transaction, soit le terminal du commerçant est à même d'obtenir ces clés auprès d'un tiers de confiance. Dans ce dernier cas, selon la présente, le dispositif d'utilisateur dispose d'un identifiant unique (Uid), lequel est associé, auprès du tiers de confiance, au deux clés publiques X et Y. Lorsque le terminal du commerçant souhaite obtenir ces clés publiques, il transmet, au tiers de confiance, une requête d'obtention des clés en se basant sur l'identifiant (Uid) du dispositif d'utilisateur. Préalablement à cette transmission, le dispositif d'utilisateur a transmis son identifiant unique au terminal du commerçant (par exemple lors de l'initialisation de la transaction).
5.2.2. Phase d'installation du côté du terminal du commerçant
Sur la base de ce groupe G et du générateur sélectionné g :
le terminal du commerçant (ou le module de vérification V) obtient ou génère une clé privée z, (nombre premier entier aléatoire) et sur la base de cette clé privée, calcule une clé publique Z, telle que : Z = gz ;
Dans ce mode de réalisation, la paire de clé privée/clé publique a fait l'objet d'un paramétrage préalable dans le terminal du commerçant. Ce paramétrage préalable peut avoir été fait par exemple avant l'installation de l'application de paiement du côté du terminal du commerçant.
Comme précédemment, dans d'autres modes de réalisation, la sélection de ces clés peut être réalisée lors de la transaction de paiement.
De même, comme précédemment, le dispositif d'utilisateur prend connaissance de la clé publique Z du terminal du commerçant. Soit le terminal du commerçant transmet cette clé directement au dispositif du client, soit le dispositif du client utilise un identifiant unique du terminal du commerçant (Cid) pour obtenir cette clé publique auprès d'un tiers de confiance.
Dans un mode de réalisation spécifique, la phase d'installation est réalisée lors de l'installation d'une application de paiement sur un terminal de communication (de type smartphone, tablette, ou ordinateur) du commerçant, ledit terminal de communication étant équipé d'un TEE et/ou d'un SE (également appelé module V). Ce mode de réalisation présente l'avantage de ne pas avoir à communiquer la clé privée z au terminal de communication en tant que tel : cette donnée n'est communiquée qu'au SE ou au TEE. Ainsi, on assure que le terminal de communication (et surtout les éventuelles applications frauduleuse de ce terminal), ne puisse pas avoir accès à cette clé privée. 5.2.3. Déroulé de l'authentification
Dans ce mode de réalisation, l'authentification est mise en œuvre de la manière suivante :
le module P effectue une transformation du message m, sous une forme numérique, afin que ce message m corresponde à un élément du groupe G : pour ce faire, le message m est transformé en binaire (représentation binaire du message m) et la forme binaire est utilisée pour obtenir une forme numérique, la forme numérique correspondant à un élément du groupe G ; d'autres méthodes peuvent être envisageables en fonctions des applications ;
- le module P sélectionne aléatoirement (ou pseudo aléatoirement) un élément f du groupe G ;
le module P calcule, à partir du message m, de la donnée aléatoire f et de la fonction de hachage H, un code d'authentification Sj selon la formule suivante :
o Sj = H(m | | t), ou I | est l'opérateur de concaténation ;
- le module P calcule, à partir du message m, de la donnée aléatoire t, de la clé publique Z, de la première clé privée x de P et du code d'authentification Slt le premier composant de signature S2, selon la formule suivante :
o S2 = (ml lt)Z*sl
le module P calcule, à partir du message m, de la donnée aléatoire t, de la clé publique Z, de la deuxième clé privée y de P et du code d'authentification Slt le deuxième composant de signature S3 ;
o S3 = lmUt)?sl
le module P transmet, au terminal du commerçant (ou au module V), le code d'authentification Slt et les deux composants de signature S2 et S3.
Ainsi, le dispositif d'utilisateur n'a pas transmis le message m, ni même une version signée de celui-ci car ce dernier se trouve être concaténé avec un aléa (f), avant d'être haché pour produire Sj. Dès lors, un attaquant, qui intercepterait par exemple le code d'authentification Slt ne pourrait pas, à partir de celui-ci, inférer le contenu du message m.
Les méthodes de calcul des valeurs Slt S2 et S3 utilisent x et y (qui sont privées et donc connues du signataire seul, c'est-à-dire le dispositif d'utilisateur), et de Z (qui est la clé publique du destinataire, c'est-à-dire le terminal de paiement). Essentiellement, S2 et S3 sont des quantités créées à partir de ces trois informations et du message m. L'exponentiation garantit la protection des clés privées, et la multiplication du message par la quantité exponentiée protège son contenu.
De son côté, le terminal du commerçant reçoit les données Slt S2 et S3. Sur la base de ces données, il va déterminer (avec un doute raisonnable), que ces données correspondent bien aux résultats de calculs effectués sur la base du message m.
Pour ce faire, le terminal du commerçant met en œuvre les étapes suivantes :
calcule, à partir du premier composant de signature S2, de la clé publique X (correspondant à la clé privée x), de sa propre clé privée Z, et du code d'authentification Slt une première valeur de référence, notée U[rl]
o U[rl] = s2X zsl
calcule, à partir du deuxième composant de signature S3, de la clé publique Y (correspondant à la clé privée y), de sa propre clé privée Z, et du code d'authentification Slt une deuxième valeur de référence, notée U[r2] ;
o iyir2; = s3Y zsl
vérifie que la première valeur de référence U[rl] est égale à la deuxième valeur de référence U[r2] ; et, lorsque les deux valeurs sont égales :
vérifie que la valeur H(U[r2]) est égale à Sj.
Si la valeur de H(U[r2]) est égale à Slt alors le terminal du commerçant dispose d'une information d'une certitude suffisante pour estimer que le dispositif d'utilisateur est bien en possession du message m et que celui-ci est authentique. Dès lors, le terminal du commerçant peut terminer la transaction (par exemple il peut transmettre Sj au système de paiement pour validation de la transaction).
Explicité autrement, Le terminal du commerçant effectue les calculs suivants :
o U[rl] = s2X"zsl = (m I I t)ZA(x SI) ΧΛ(-ζ SI) =
(m | | t)gA(z x Sl) gA(- z x Sl) =
(m | | t)
et
o U[r2] = s3Y zsl = (m I I t)Z*(y SI) ΥΛ(-ζ SI) =
[m | | t)g*(yz Sl) g*(-yz Sl) =
(m | | t) Ainsi, l'authentification des données transmises, lors d'une opération de paiement, entre un terminal d'un commerçant et un dispositif d'utilisateur, en utilisant une communication en champs proche (NFC), permet de valider une transaction de manière sécuritaire.
5.3. Autres caractéristiques et avantages
On décrit, en relation avec la figure 3, un terminal de communication mis en œuvre pour réaliser une authentification de données dans le cadre d'un processus de paiement, selon le procédé décrit préalablement.
Par exemple, le terminal de communication, faisant office de terminal de paiement, comprend une mémoire 31 comprenant notamment une mémoire tampon, une unité de traitement général 32, équipée par exemple d'un microprocesseur, et pilotée par un programme d'ordinateur 33, et une unité de traitement sécurisée 34 (notée V précédemment), pilotée par un programme d'ordinateur 35, ces unités de traitement mettant en œuvre le procédé d'authentification tels que décrit précédemment pour effectuer un paiement auprès du commerçant.
À l'initialisation, les instructions de code du programme d'ordinateur 35 sont par exemple chargées dans une mémoire avant d'être exécutées par le processeur de l'unité de traitement sécurisée 34. L'unité de traitement 34 reçoit en entrée au moins un code d'authentification et deux éléments de signature. Le microprocesseur de l'unité de traitement sécurisée 34 met en œuvre les étapes du procédé d'authentification, selon les instructions du programme d'ordinateur 35 pour fournir, à l'unité de traitement générale 32, une donnée représentative de validation de transaction et le cas échéant transmettre, à un système de traitement, une donnée de validation de transaction. L'unité de traitement générale 32 effectue un traitement de ces données pour les transmettre à un dispositif d'un client (par exemple un smartphone, une tablette) dans le cadre d'une transaction de paiement.
Pour cela, le terminal de communication comprend, outre la mémoire tampon 31, des moyens de communications, tels que des modules de communication réseau, des moyens de transmission de donnée et des circuits de transmission de données entre les divers composants du terminal de communication. Ces moyens peuvent se présenter sous la forme d'un processeur particulier implémenté au sein du terminal de communication. Selon un mode de réalisation particulier, ce dispositif met en œuvre une application spécifique qui est en charge de la réalisation des transactions, cette application étant par exemple fournie par le fabricant du processeur en question afin de permettre l'utilisation dudit processeur ou par un fournisseur de solution de paiement pour des terminaux "ouverts". Pour ce faire, le processeur comprend des moyens d'identification uniques. Ces moyens d'identification uniques permettent d'assurer l'authenticité du processeur.
Par ailleurs, le dispositif comprend en outre les moyens de communication en champs proches, dits NFC et des moyens de transmission et de réception de données en provenance de réseaux de communications. Ces moyens se présentent également comme des interfaces de communications permettant d'échanger des données sur des réseaux de communication, des moyens d'interrogations et de mise à jour de base de données.
On décrit, en relation avec la figure 4, un dispositif d'utilisateur mis en œuvre pour réaliser une authentification de données dans le cadre d'un processus de paiement, selon le procédé décrit préalablement.
Par exemple, le dispositif d'utilisateur comprend une mémoire 41 constituée d'une mémoire tampon, une unité de traitement général 42, équipée par exemple d'un microprocesseur, et pilotée par un programme d'ordinateur 43, et une unité de traitement sécurisée 44 (notée P, précédemment), pilotée par un programme d'ordinateur 45, ces unités de traitement mettant en œuvre le procédé d'authentification tels que décrit précédemment pour effectuer un paiement auprès du commerçant.
À l'initialisation, les instructions de code du programme d'ordinateur 45 sont par exemple chargées dans une mémoire avant d'être exécutées par le processeur de l'unité de traitement sécurisée 44. L'unité de traitement sécurisée 44 reçoit en entrée, un message m dont il est nécessaire de prouver la connaissance. Le microprocesseur de l'unité de traitement sécurisée 44 met en œuvre les étapes du procédé d'authentification, selon les instructions du programme d'ordinateur 45 pour fournir, à l'unité de traitement générale 42, au moins un code d'authentification et deux éléments de signature à transmettre à un terminal de commerçant. L'unité de traitement générale 42 effectue la transmission de ces données. Pour cela, le dispositif d'utilisateur comprend, outre la mémoire tampon 41, des moyens de communications, tels que des modules de communication réseau, des moyens de transmission de donnée et des circuits de transmission de données entre les divers composants du dispositif d'utilisateur.
Ces moyens peuvent se présenter sous la forme d'un processeur particulier implémenté au sein du dispositif d'utilisateur. Selon un mode de réalisation particulier, ce dispositif met en œuvre une application spécifique qui est en charge de la réalisation des transactions, cette application étant par exemple fournie par le fabricant du processeur en question afin de permettre l'utilisation dudit processeur ou par un fournisseur de solution de paiement pour des terminaux "ouverts". Pour ce faire, le processeur comprend des moyens d'identification uniques. Ces moyens d'identification uniques permettent d'assurer l'authenticité du processeur.
Par ailleurs, le dispositif comprend en outre les moyens de communication en champs proches, dits NFC et des moyens de transmission et de réception de données en provenance de réseaux de communications. Ces moyens se présentent également comme des interfaces de communications permettant d'échanger des données sur des réseaux de communication, des moyens d'interrogations et de mise à jour de base de données.

Claims

Revendications
Procédé d'authentification d'au moins une donnée, procédé mis en œuvre lors d'une transaction de paiement intervenant entre un terminal de communication d'un commerçant et un dispositif d'utilisateur, procédé du type comprenant l'authentification par le terminal de communication d'au moins un message m générée par le dispositif d'utilisateur, par l'intermédiaire d'une liaison de données sans fils en champs proche, procédé caractérisé en ce qu'il comprend, au sein du dispositif d'utilisateur :
une étape d'obtention (10), à partir du message m, d'une donnée aléatoire f et d'une fonction de hachage H, d'un code d'authentification Sj ;
une étape d'obtention (20), à partir du message m, de la donnée aléatoire t, d'une clé publique Z du terminal de communication, d'une première clé privée x du dispositif d'utilisateur et du code d'authentification Slt d'un premier composant de signature S2 ; une étape d'obtention (30), à partir du message m, de la donnée aléatoire t, de la clé publique de Z du terminal de communication, d'une deuxième clé privée y du dispositif d'utilisateur et du code d'authentification S d'un deuxième composant de signature S3 ;
une étape de transmission (40), au terminal de communication, du code d'authentification Slt et des deux composants de signature S2 et S3.
Procédé d'authentification selon la revendication 1, caractérisé en ce qu'il comprend, au sein du terminal de communication :
une étape d'obtention (50), à partir du premier composant de signature S2, d'une clé publique X du dispositif d'utilisateur, d'une clé privée z du terminal de communication, et du code d'authentification Slt d'une première valeur de référence, notée U[rl]; une étape d'obtention (60), à partir du deuxième composant de signature S3, d'une clé publique Y du dispositif d'utilisateur, de la clé privée z, et du code d'authentification Slt d'une deuxième valeur de référence, notée U[r2] ;
une étape de vérification (70) que la première valeur de référence U[rl] est égale à la deuxième valeur de référence U[r2] ; et, lorsque les deux valeurs sont égales : une étape de vérification (80) que la valeur H(U[r2]) et/ou H(U[rl]) est égale à Sj.
une étape de délivrance d'une assertion d'authentification lorsque l'étape de vérification précédente est positive.
3. Procédé d'authentification selon la revendication 1, caractérisé en ce qu'il comprend, pour ledit dispositif d'utilisateur, préalablement à ladite étape d'obtention (10) d'un code d'authentification, une phase de détermination d'un ensemble de paramètres de chiffrement, comprenant :
une étape d'obtention d'un groupe de Schnor (G) et d'un générateur de ce groupe (g) ; une étape d'obtention de la première clé privée (x), ladite clé privée étant un élément du groupe G ;
une étape d'obtention de la deuxième clé privée (y), ladite clé privée étant un élément du groupe G ;
une étape de calcul, à partir de la première clé privée (x), d'une clé publique telle que X est une exponentiation du générateur g par la clé privée x, X=g* ;
une étape de calcul, à partir de la première clé privée (y), d'une clé publique / telle que Y est une exponentiation du générateur g par la clé privée y, Y=gy.
4. Procédé d'authentification selon la revendication 2, caractérisé en ce qu'il comprend, pour ledit terminal de communication du commerçant, préalablement à ladite étape d'obtention (50) d'une première valeur de référence, une phase de détermination d'un ensemble de paramètres de chiffrement, comprenant :
une étape d'obtention d'un groupe de Schnor (G) et d'un générateur de ce groupe (g) ; une étape d'obtention de la clé privée (z), ladite clé privée étant un élément du groupe G ;
une étape de calcul, à partir de la clé privée (z), d'une clé publique Z telle que Z est une exponentiation du générateur g par la clé privée z, Z=gz.
5. Procédé d'authentification selon la revendication 3, caractérisé en ce que :
l'étape d'obtention (10) du code d'authentification Sj met en œuvre le calcul suivant : Sj = H(m | | t), ou I I est l'opérateur de concaténation ; l'étape d'obtention (20) du premier composant de signature S2 met en œuvre le calcul suivant S2 = (ml lt)Z*sl ; l'étape d'obtention (30) du deuxième composant de signature S3 met en œuvre le calcul suivant : S3 = (m\ lt)^sl.
Procédé d'authentification selon la revendication 4, caractérisé en ce que :
l'étape d'obtention (50) de la première valeur de référence U[rl] met en œuvre le calcul suivant : U[rl] = s2X"zsl ;
l'étape d'obtention (60) de la deuxième valeur de référence U[r2] met en œuvre le calcul suivant U[r2] = s3Y"zsl.
Dispositif d'utilisateur comprenant une unité de traitement générale, une mémoire, dispositif caractérisé en ce qu'il comprend une unité de traitement sécurisée et une mémoire sécurisée et au moins un circuit reconfigurable de traitement de transaction de paiement avec un terminal de communication comprenant notamment une authentification d'une donnée, ledit Dispositif d'utilisateur comprenant :
des moyens d'obtention, à partir du message m, d'une donnée aléatoire f et d'une fonction de hachage H, d'un code d'authentification Sj ;
des moyens d'obtention, à partir du message m, de la donnée aléatoire t, d'une clé publique Z du terminal de communication, d'une première clé privée x du dispositif d'utilisateur et du code d'authentification Slt d'un premier composant de signature S2 ; des moyens d'obtention, à partir du message m, de la donnée aléatoire t, de la clé publique de Z du terminal de communication, d'une deuxième clé privée y du dispositif d'utilisateur et du code d'authentification S d'un deuxième composant de signature S3 ;
des moyens de transmission, au terminal de communication, du code d'authentification Slt et des deux composants de signature S2 et S3.
Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions de code de programme pour l'exécution d'un procédé d'authentification selon la revendication 1, lorsqu'il est exécuté sur un ordinateur.
EP17733483.6A 2016-06-30 2017-06-30 Procede d'authentification de donnees de paiement, dispositifs et programmes correspondants Ceased EP3479518A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1656240A FR3053549B1 (fr) 2016-06-30 2016-06-30 Procede d'authentification de donnees de paiement, dispositifs et programmes correspondants.
PCT/EP2017/066365 WO2018002351A1 (fr) 2016-06-30 2017-06-30 Procede d'authentification de donnees de paiement, dispositifs et programmes correspondants

Publications (1)

Publication Number Publication Date
EP3479518A1 true EP3479518A1 (fr) 2019-05-08

Family

ID=57583156

Family Applications (1)

Application Number Title Priority Date Filing Date
EP17733483.6A Ceased EP3479518A1 (fr) 2016-06-30 2017-06-30 Procede d'authentification de donnees de paiement, dispositifs et programmes correspondants

Country Status (5)

Country Link
US (1) US10922679B2 (fr)
EP (1) EP3479518A1 (fr)
CA (1) CA3029154A1 (fr)
FR (1) FR3053549B1 (fr)
WO (1) WO2018002351A1 (fr)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109347635A (zh) * 2018-11-14 2019-02-15 中云信安（深圳）科技有限公司 一种基于国密算法的物联网安全认证系统及认证方法
CN111639187B (zh) * 2019-03-01 2023-05-16 上海数眼科技发展有限公司 一种基于知识图谱的知识问答验证码生成系统及方法
US12293164B2 (en) * 2021-09-01 2025-05-06 Capital One Services, Llc Devices and techniques to perform entropy-based randomness via a contactless card
CN119585734A (zh) * 2022-07-15 2025-03-07 惠普发展公司，有限责任合伙企业 数字签名
WO2024015076A1 (fr) 2022-07-15 2024-01-18 Hewlett-Packard Development Company, L.P. Signature numérique

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8700729B2 (en) * 2005-01-21 2014-04-15 Robin Dua Method and apparatus for managing credentials through a wireless network
US8290433B2 (en) * 2007-11-14 2012-10-16 Blaze Mobile, Inc. Method and system for securing transactions made through a mobile communication device
US20140032345A1 (en) * 2012-07-30 2014-01-30 Bank Of America Corporation Authentication Using Transaction Codes on a Mobile Device
FR3030828A1 (fr) * 2014-12-22 2016-06-24 Orange Procede de securisation de transactions sans contact

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
BENOÃ T LIBERT ET AL: "Efficient Signcryption with Key Privacy from Gap Diffie-Hellman Groups", 26 February 2004, PUBLIC KEY CRYPTOGRAPHY - PKC 2004; [LECTURE NOTES IN COMPUTER SCIENCE;;LNCS], SPRINGER-VERLAG, BERLIN/HEIDELBERG, PAGE(S) 187 - 200, ISBN: 978-3-540-21018-4, XP019002835 *
MICHAL RJAÅ KO ET AL: "On Designated Verifier Signature Schemes", IACR, INTERNATIONAL ASSOCIATION FOR CRYPTOLOGIC RESEARCH, vol. 20100629:123923, 29 June 2010 (2010-06-29), pages 1 - 15, XP061004146 *
See also references of WO2018002351A1 *
WIKIPEDIA: "Contactless payment", 16 June 2016 (2016-06-16), XP093001470, Retrieved from the Internet <URL:https://en.wikipedia.org/w/index.php?title=Contactless_payment&oldid=725528699> [retrieved on 20221123] *

Also Published As

Publication number Publication date
FR3053549B1 (fr) 2018-07-27
US20190228402A1 (en) 2019-07-25
FR3053549A1 (fr) 2018-01-05
CA3029154A1 (fr) 2018-01-04
WO2018002351A1 (fr) 2018-01-04
US10922679B2 (en) 2021-02-16

Similar Documents

Publication Publication Date Title
EP3032799B1 (fr) Procédé d&#39;authentification d&#39;un utilisateur, serveur, terminal de communication et programmes correspondants
EP2545721B1 (fr) Protection contre un deroutement d&#39;un canal de communication d&#39;un circuit nfc
EP2545722B1 (fr) Detection d&#39;un deroutement d&#39;un canal de communication d&#39;un dispositif de telecommunication couple a un circuit nfc
CN104240074B (zh) 基于身份认证的预付卡联机支付系统及其支付方法
EP3238150B1 (fr) Procédé de sécurisation de transactions sans contact
EP3479518A1 (fr) Procede d&#39;authentification de donnees de paiement, dispositifs et programmes correspondants
EP1908215A1 (fr) Procédé de contrôle de transactions sécurisées mettant en oeuvre un dispositif physique unique à bi-clés multiples, dispositif physique, système et programme d&#39;ordinateur correspondants
FR2973909A1 (fr) Procede d&#39;acces a une ressource protegee d&#39;un dispositif personnel securise
WO2007012583A1 (fr) Procede de controle de transactions securisees mettant en oeuvre un dispositif physique unique, dispositif physique, systeme, et programme d&#39;ordinateur correspondants
EP2306668B1 (fr) Système et procédé de transaction sécurisée en ligne
EP3479325B1 (fr) Procédé d&#39;authentification de données de paiement, dispositifs et programmes correspondants.
EP3273398B1 (fr) Procédé de traitement de données par un dispositif électronique d&#39;acquisition de données, dispositif et programme correspondant
EP3095223B1 (fr) Méthode de transmission de données chiffrées, méthode de réception, dispositifs et programmes d&#39;ordinateur correspondants
FR3070516A1 (fr) Procede d&#39;authentification d&#39;un utilisateur aupres d&#39;un serveur d&#39;authentification
EP3029878B1 (fr) Procédé de transmission de secret à durée de vie limitée pour réaliser une transaction entre un terminal mobile et un équipement
EP3570238B1 (fr) Procédé de réalisation d&#39;une transaction, terminal, serveur et programme d&#39;ordinateur correspondant
CA3029152C (fr) Procede d&#39;authentification de donnees de paiement, dispositifs et programmes correspondants
EP3371760A1 (fr) Procédé de verification d&#39;identité lors d&#39;une virtualisation
EP4014466A1 (fr) Procede de transmission d&#39;une information numerique
WO2014154961A1 (fr) Procédé de délivrance de billets électroniques

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20181219

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

RIN1 Information on inventor provided before grant (corrected)

Inventor name: GERAUD, REMI

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20201119

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: BANKS AND ACQUIRERS INTERNATIONAL HOLDING

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20221116