EP4074004A1 - Procede et systeme, dispositif et terminal de paiement utilisant des donnees personnelles - Google Patents

Procede et systeme, dispositif et terminal de paiement utilisant des donnees personnelles

Info

Publication number
EP4074004A1
EP4074004A1 EP20845184.9A EP20845184A EP4074004A1 EP 4074004 A1 EP4074004 A1 EP 4074004A1 EP 20845184 A EP20845184 A EP 20845184A EP 4074004 A1 EP4074004 A1 EP 4074004A1
Authority
EP
European Patent Office
Prior art keywords
transaction
payment
personal information
payment terminal
condition
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP20845184.9A
Other languages
German (de)
English (en)
Inventor
David Naccache
Michel Leger
Elena Trichina
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Banks and Acquirers International Holding SAS
Original Assignee
Banks and Acquirers International Holding SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Banks and Acquirers International Holding SAS filed Critical Banks and Acquirers International Holding SAS
Publication of EP4074004A1 publication Critical patent/EP4074004A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/20—Point-of-sale [POS] network systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/20—Point-of-sale [POS] network systems
    • G06Q20/207—Tax processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • G06Q20/38215—Use of certificates or encrypted proofs of transaction rights
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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; CALCULATING OR 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/388—Payment protocols; Details thereof using mutual authentication without cards, e.g. challenge-response
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4014—Identity check for transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/405—Establishing or using transaction specific rules
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/102—Entity profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data
    • 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/3226—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 a predetermined code, e.g. password, passphrase or PIN
    • 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/3271—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 challenge-response
    • H04L9/3273—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 challenge-response for mutual authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/50—Secure pairing of devices

Definitions

  • the present invention relates to a method, a system, a device and a payment terminal using personal data. More generally, the invention relates to an improvement in secure electronic payments.
  • An electronic transaction allows the sale or purchase of goods or services using electronic means of payment.
  • This document relates more particularly to transactions initiated at a point of sale and carried out on a device having means to secure such transactions.
  • a payment device stores payment identifiers, such as a bank card (magnetic, contact or contactless), a mobile phone or a smart watch, in order to be presented to a payment terminal which verifies the authenticity of the means of payment and validates the transaction.
  • payment identifiers such as a bank card (magnetic, contact or contactless), a mobile phone or a smart watch
  • the EMV protocol (derived from the initials of the founding companies Europay international, MasterCard international and Visa international) specifies the interoperability between bank cards and payment terminals by authorizing numerous implementation variants: with or without contact, with cash or credit payment, with or without PIN code, with varying security levels depending on the type of transaction or the card issuer, etc.
  • payment conditions may be conditioned according to certain personal data of a purchaser and certain transactions may also be legally prohibited according to such personal data. When they exist, these transaction conditions are generally verified. by a seller when purchasing. Non-resident consumers may wish not to pay certain taxes imposed on the sale of products, such as, for example, VAT (Value Added Tax in France). To do this, they must justify their condition or make a request for zero-rating after a purchase. A buyer's age check may be required to obtain a price reduction or purchase authorization. This type of control is only achievable if a seller is present or, if such a purchase is made on a vending machine, trusting the data that is indicated by the buyer. In addition, a seller may fail to verify such personal data or be deceived by a malicious buyer, just like a vending machine.
  • a payment device comprises at least one personal item of information which is presented in a certified manner to a payment terminal.
  • the payment terminal is suitable for implementing a transaction policy which takes into account one or more personal information to authorize or refuse to finalize a transaction.
  • the invention proposes an electronic transaction method between a payment device associated with a bank account of a user and a payment terminal associated with an acquiring bank account in which the payment device and the payment terminal perform at at least one cryptographic key exchange before performing a transaction step during which the transaction is validated or rejected.
  • the payment device comprises at least one personal information relating to the user.
  • the payment terminal includes at least one transaction policy including a condition relating to at least one personal information.
  • the method includes a verification step, prior to the transaction step, to verify the condition of the transaction policy relating to personal information in a secure manner using the cryptographic key.
  • the verification step can consist in that the payment device sends the personal information accompanied by a cryptographic signature made using the personal information and the cryptographic key in order to to authenticate personal information.
  • the payment terminal can check the condition of the transaction policy after authenticating personal information.
  • the payment terminal prior to sending the personal information, can send a request to the payment device to cause the sending of the personal information by the latter.
  • the verification step can consist in that the payment terminal sends a request to verify the transaction policy to the payment device, the request being signed using the cryptographic key .
  • the verification of the condition of the transaction policy can be carried out by the payment device, after having authenticated the request using the cryptographic key, which generates and transmits a validation or invalidation message to the payment terminal by depending on condition and personal information.
  • the amount of the transaction can be modified by the payment terminal depending on the result of the verification step.
  • the cryptographic key exchange can be carried out during a mutual authentication step.
  • the invention also proposes an electronic transaction method implemented by a microprocessor of a payment device associated with a bank account of a user intended to cooperate with a payment terminal associated with an acquiring bank account in order to carry out a step of transaction during which the transaction is validated or rejected, said method comprising a step for exchanging at least one cryptographic key with the payment terminal.
  • the payment device comprises at least one personal information relating to the user recorded in a data memory.
  • the method comprises a step of verifying a condition of a transaction policy relating to the personal information is verified in a secure manner using the cryptographic key.
  • the verification step may include sending a message containing personal information accompanied by a cryptographic signature made using the personal information and the cryptographic key in order to authenticate said personal information.
  • the step of verifying the condition of the transaction policy may include a preliminary step for authenticating a request sent by the payment terminal containing the condition of the transaction policy, the request being signed using the cryptographic key, and a step of sending a validation or invalidation message depending on the condition and personal information.
  • the invention provides an electronic transaction method implemented by a microprocessor of a payment terminal, associated with an acquiring bank account, intended to cooperate with a payment device associated with a bank account of an user.
  • Said method comprises a step for exchanging at least one cryptographic key with the payment device and a transaction step during which the transaction is validated or rejected.
  • the payment terminal includes at least one transaction policy including a condition relating to at least one personal information relating to the user of the payment device.
  • the method includes a verification step for requesting verification of the condition of the personal information transaction policy using the cryptographic key, and the transaction step is carried out if and only if the condition is verified.
  • the method may include a step for receiving a message including personal information accompanied by a cryptographic signature made using the personal information and the cryptographic key and a step to verify the condition of the transaction policy after having authenticated the personal information using the cryptographic key.
  • the method may include a step for developing and transmitting a request to the payment device in order to obtain personal information.
  • the verification step may consist in developing and transmitting a request for verifying the transaction policy to the payment device, the request being signed using the cryptographic key.
  • the method may include a step for modifying the amount of the transaction as a function of the result of the verification of the condition prior to the validation of the transaction.
  • the invention provides an electronic transaction system comprising a payment device associated with a bank account of a user and payment terminal associated with an acquiring bank account in which the payment device and the terminal payments are configured to perform an exchange of at least one cryptographic key before performing a transaction step during which the transaction is validated or rejected.
  • the payment device includes at least one personal information relating to the user and the payment terminal includes at least one transaction policy including a condition relating to at least one personal information.
  • the device and the payment terminal are configured to perform a verification step between the cryptographic key exchange step and the transaction step during which the condition of the transaction policy relating to personal information is verified. securely using the cryptographic key.
  • the payment device can be configured to transmit to the payment terminal a message containing the personal information signed using the personal information and the key cryptographic to authenticate the personal information and the payment terminal can be configured to verify the condition after authenticating the personal information using the cryptographic key.
  • the payment terminal can be configured to develop and transmit a request to the payment device in order to obtain personal information.
  • the payment terminal can be configured to generate and transmit to the payment device a request for verifying the condition of the transaction policy signed using the cryptographic key.
  • the payment device can be configured to authenticate said request using the cryptographic key before verifying the condition in response to the verification request and to return a validation or invalidation message to the payment terminal as a function of the condition and personal information.
  • the payment terminal can be configured to modify the amount of the transaction depending on the result of the verification step.
  • the invention proposes a payment device associated with a bank account of a user intended to cooperate with a payment terminal to carry out an electronic transaction, said payment device being configured to exchange at least one cryptographic key with the payment terminal.
  • the payment device includes at least one personal information relating to the user, and the payment device is configured to perform a step of verifying a condition of a transaction policy relating to personal information in a secure manner at the same time. 'using the cryptographic key
  • the payment device can be configured to send the personal information to the payment terminal in a signed message using the personal information and the cryptographic key in order to authenticate the payment.
  • the payment device can be configured to check the condition of the transaction policy in response to the receipt of a verification request containing the condition, said request being signed and transmitted by the payment terminal using the cryptographic key, and to develop and transmit a validation or invalidation message to the payment terminal in function condition and personal information.
  • the payment device can be a device included in the following list: smart card conforming to the IS07816 standard and / or to the 14443 standard, mobile phone or tablet comprising a secure payment capability, smart watch comprising payment functions, secure computer comprising a communication interface with or without contact and comprising a secure payment capability.
  • the invention provides a payment terminal associated with an acquiring bank account intended to cooperate with a payment device associated with a bank account of a user to carry out an electronic transaction in which the payment terminal is configured. to exchange at least one cryptographic key with the payment device before implementing a transaction step during which the transaction is validated or rejected.
  • the payment terminal includes at least one transaction policy comprising a condition relating to at least one personal information stored in a memory of the payment device, said personal information relating to the user.
  • the payment terminal is configured to perform a verification step, prior to the transaction step, in which the condition of the personal information transaction policy is securely verified using the cryptographic key.
  • the payment terminal can be configured to receive a message containing the personal information signed using the personal information and the cryptographic key by the payment device.
  • the payment terminal can be configured to check the condition after authenticating the personal information using the cryptographic key.
  • the payment terminal can be configured to develop and transmit a request to the payment device in order to obtain personal information.
  • the payment terminal can be configured to generate and transmit to the payment device a request for verifying the condition of the transaction policy signed using the cryptographic key.
  • the payment terminal can be configured to complete the transaction following a validation or invalidation message returned by the payment device depending on the condition and personal information.
  • the payment terminal can be configured to modify the amount of the transaction depending on the result of the verification step.
  • said payment terminal can be included in the following list of devices: point of sale terminal for chip card, mobile phone or tablet comprising a secure payment recording capacity, cash register comprising a capacity for secure payment registration.
  • FIG.1 illustrates an electronic payment system concerned by the invention
  • FIG.2 illustrates a smart card according to the invention
  • FIG.3 illustrates a mobile phone used as a means of payment according to the invention
  • FIG.4 illustrates a payment terminal according to the invention
  • FIG.5 shows a modified payment scheme according to a first embodiment of the invention
  • FIG.6 shows a modified payment scheme according to a second exemplary embodiment of the invention.
  • FIG. 1 illustrates a secure electronic payment system used according to the state of the art and used to implement the invention.
  • the system of FIG. 1 comprises a payment terminal 1 capable of communicating on the one hand with a bank server 2 and on the other hand with a payment device 3 or 4.
  • This type of system is commonly used to perform payment operations. payment from a point of sale, as defined in many payment service standards, for example in the EMV standard which is the most widely used and which has many possibilities of implementation.
  • the payment terminal 1 may be required to carry out “offline” or “online” transactions, that is to say in a disconnected or connected manner with the banking server 2.
  • the payment device 3 is conventionally a smart card.
  • a mobile phone 4 or even any other electronic device capable of emulating the operation of a smart card in a secure manner, such as for example a smart watch which is an extension of a mobile phone in the form of a watch bracelet, or any type of computer with the same capacities or functions.
  • FIG. 2 functionally illustrates a bank card 3, or smart card, which comprises a microprocessor 31 controlling a central bus 32 for exchanging data with a memory 33, a crypto-processor 34, a contact communication interface 35 and a contactless communication interface 36.
  • the contact communication interface 35 is for example compatible with the IS07816 standard.
  • the contactless communication interface 36 is for example a near-field communication interface, of the NFC type (standing for Near Field Contactless) compatible with the IS014443 standard.
  • NFC type standing for Near Field Contactless
  • the memory 33 can be segmented into volatile memory of RAM type (standing for Random Access Memory), in non-writable program memory of ROM type (standing for Read-Only Memory) and in non-volatile memory of EEPROM (Electrically-Erasable Programmable Read-Only Memory) or Flash type.
  • RAM Random Access Memory
  • ROM Read-Only Memory
  • EEPROM Electrically-Erasable Programmable Read-Only Memory
  • Flash type Flash type.
  • a secure operating system is implemented by the microprocessor 31 to guarantee the security of the information stored in the memory 33 of the smart card 3.
  • the microprocessor 31 can authorize read or write access to certain areas. from the memory to commands coming from one of the communication interfaces 35 or 36.
  • Other areas of the memory 33 can only be accessible to the microprocessor 31 or to the crypto-processor 34. Certain data can be made accessible by the microprocessor 31 from the outside conditionally.
  • personal information PI is stored in the non-volatile part of the memory 33 during the personalization of the smart card concomitantly with data relating to a bank account with which the smart card is associated.
  • Personal PI information relates to the holder of the bank account. It can relate to his age, his date of birth, his place of residence or consist of any other personal information which can be used during a transaction according to the invention.
  • the personal information PI can be stored in a memory area which can be read directly from one of the communication interfaces 35 or 36 while being write-protected so that it cannot be altered after personalization by an unauthorized person. .
  • the personal information PI is stored in an area of the memory 33 which is not directly accessible from one of the communication interfaces 35 or 36.
  • the personal information PI is not at all accessible from the outside. The use of this personal PI information will be described later in this description.
  • FIG. 3 functionally illustrates a portable telephone 4 which can be used as a payment device.
  • the portable telephone 4 is a portable telephone of the intelligent type, commonly called under the Anglo-Saxon name “smartphone”, which comprises a microprocessor 41 connected through a central bus 42 to a volatile memory 43, a non-volatile memory 44, a user interface 45, a SIM card 46, a radio communication interface 47, a proximity interface 48 and a secure element 49.
  • Other elements can also be part of the mobile phone 4 but are not shown because they do not directly relate to the invention.
  • these other elements can comprise a microphone, a loudspeaker, a vibrator, a camera, a memory card reader, a wired communication interface, for example of the USB type, a battery or even any other integrated element. in a cell phone.
  • the mobile telephone 4 described with the aid of FIG. 3 corresponds to a non-limiting preferred type of telephone.
  • the mobile telephone 4 does not include the secure element 49 or the SIM card 46.
  • the microprocessor 41 is the "heart" of the mobile telephone 4 which manages all of the elements constituting it via the central bus 42 from programs stored in the non-volatile memory 44 using the volatile memory 43 as working memory .
  • the non-volatile memory 44 is for example composed of memory of ROM type and of electrically erasable memory of EEPROM type or of Flash type.
  • the operating system of the mobile telephone 4 makes it possible to manage the different functionalities by calling on specific programs which make it possible to produce different commands intended for the different elements of the telephone 4.
  • the operating system is not secure as such because the securing of sensitive data and operations can be done in the SIM card 46 and / or in the secure element 49.
  • the user interface 45 is preferably a touch screen that can also include a fingerprint reader.
  • the user interface can be limited to a display screen and a keyboard. Many other variations are also possible for a person skilled in the art without limiting the scope of the invention.
  • the SIM card 46 (from the English Subscriber Identity Module) is commonly used to store access identifiers to a mobile telephone network (not shown) and to secure access to said network.
  • the SIM card 46 is a smart card used to authenticate the telephone on the telephone network according to one of the telephony standards, such a card for example conforms to the IS07816 standard and to the ETSI TS 102221 standard.
  • the SIM card 46 only fulfills its role of communication with the mobile telephone network.
  • the radio communication interface 47 is a programmable multi-frequency radio interface having modulation, demodulation, encoding and decoding circuits that can be configured in different ways in order to communicate on a frequency band and according to a protocol.
  • the proximity interface 48 is a CLF type interface (from English
  • the mobile telephone 4 can emulate the operation of a contactless smart card or of a contactless smart card reader.
  • This proximity interface is controlled by means of the central bus 42 or by a specific communication port intended to be directly connected to a SIM card as defined in the ETSI TS 102613 standard.
  • Secure element 49 is an independent integrated circuit that contains a secure processor, runtime memory, and tamper-proof storage like a smart card.
  • the secure element 49 comprises a first communication port linked to the central bus 42 and a second communication port linked to the specific communication port of the proximity interface 48.
  • the secure element 49 can be switched off. supplied directly by the proximity interface 48 from the electromagnetic field used for communication.
  • Secure element 49 can securely store data and programs. It can also run them safely.
  • This secure element 49 can contain and execute secure programs identical to those executable by the chip card 3 described above, in particular for carrying out payment transactions.
  • the secure element contains personal PI information.
  • the SIM card 46 can be a multi-application card integrating a banking application and personal information PI.
  • the SIM card can comply with the ETSI TS 102 613 standard and have a direct link with the proximity interface 48 via its specific communication port or perform data exchanges with the payment terminal 1 via the 'radiocommunication interface 47.
  • the SIM card 46 can thus replace the secure element 49 and provide in its place the various functions described above.
  • the mobile phone 4 does not have a secure element 49 or a SIM card 46.
  • the phone 4 has a secure operating system, an application program banking and the personal information PI is stored in a protected area of the non-volatile memory 44.
  • the mobile telephone 4 can be replaced by any other electronic device comprising a microprocessor having all or part of the elements described in relation to FIG. 3.
  • a device can be a tablet, smart watch, or laptop.
  • the electronic device should have a read, write and execute security capability for programs and data to be able to receive a secure payment application and a contact or contactless communication interface that allows communication with the customer. payment terminal 1.
  • FIG. 4 functionally illustrates a payment terminal 1 intended to receive payments in the form of electronic transactions.
  • the payment terminal 1 can be a secure point-of-sale or POS terminal (standing for Point Of Sale), that is to say integrated in a structurally reinforced box against any malicious attempt to undermine its integrity. but can also be placed in an automatic product dispenser or be improper in a store cash register, or even be emulated on an intelligent portable telephone of the “smartphone” type.
  • the payment terminal 1 comprises a microprocessor 101 connected through a central bus 102 to a volatile memory 103, a non-volatile memory 104, a screen 105, a keyboard 106, a SAM card 107, a printer 108, a communication interface 109 with and / or without contact, a smart card reader 110 with contact, a proximity communication interface 111.
  • Other elements can also form part of the payment terminal 1 but are not shown because they do not directly relate to the invention.
  • these other elements may comprise a battery, a SIM card, a memory card reader or even any other element which can be integrated into a payment terminal.
  • the payment terminal 1 described corresponds to a terminal of the non-limiting preferred POS type.
  • the payment terminal 1 it is possible for the payment terminal 1 to be simplified or emulated on a secure mobile telephone and not to include proximity communication interface 111, smart card reader 110, printer 108 or SAM card 107.
  • the screen 105 and the keyboard 106 can be replaced by a touch screen or any other type of display. man-machine interface allowing interaction with a user.
  • the microprocessor 101 is the heart of the payment terminal 1 which manages all of the elements constituting it via the central bus 102 from programs stored in the non-volatile memory 104 using the volatile memory 103 as working memory.
  • the non-volatile memory 104 is for example composed of a ROM type memory and an electrically erasable memory of the EEPROM type or of the Flash type.
  • EEPROM electrically erasable memory
  • the microprocessor 101 we can cite a secure operating system implemented by the microprocessor 101 to guarantee the security of the information stored in the memory 104. Thus, access in reading and / or in writing to certain memory areas is only possible under the control of the microprocessor 101 from one of the communication interfaces 109.
  • the non-volatile memory 104 also includes programs executable by the microprocessor 101 intended for carrying out banking transactions. These programs include a certain number of subroutines capable of supporting different transaction options which depend on the type of bank card, on the issuer of the bank card, and also on particular parameters which can for example be defined by a merchant who uses said bank card.
  • payment terminal 1. Some may relate respectively to transaction policies (in English Transaction Policies) which define particular payment conditions, for example electronic verifications to be carried out according to the type of card, a threshold of payment beyond which the bank must be contacted to authorize or refuse the transaction, conditions relating to the entry or entry of a verification code or to additional verifications that can be configured by the merchant having said terminal 1.
  • transaction policies in English Transaction Policies
  • the screen 105 allows the users of the payment terminal 1 to view information during the execution of a transaction.
  • the keyboard 106 allows its user to indicate to the payment terminal 1 payment information.
  • transaction such as for example the amount of the transaction or the entry of a personal identification code or PIN (standing for Personal Identification Number).
  • the printer 108 is used to print a transaction receipt intended for the debtor and / or the merchant. In a variant, the printer 108 is not present and the transaction receipt can be sent in the form of an electronic message to each of the parties to the transaction or to another machine connected to the payment terminal 1 which will perform the transaction. 'edition instead of said terminal 1.
  • the SAM 107 (from the English Secure Access Module) card is a secure access module or secure application module.
  • the SAM card guarantees the security of the transaction and the sensitive information of the payment terminal 1.
  • the SAM 107 card can store and produce cryptographic keys and / or implement cryptographic calculation algorithms necessary for the implementation of a security policy, for example to carry out a strong authentication process carried out during a transaction.
  • the SAM 107 card is a chip card inserted into an internal reader (not shown) of the payment terminal 1.
  • the SAM card 107 can be replaced by a secure element or by the microprocessor 101 if the latter comprises a cryptographic processor. and a secure operating system to ensure sufficient security of sensitive information.
  • the communication interface 109 allows the terminal to communicate with the bank server 2.
  • a communication interface 109 conventionally supports so-called "wired" communications, for example according to the protocol. Internet and / or communications of radiocommunication type, for example according to a 3G or 4G radiotelephony protocol.
  • the encryption of the communications carried out via the communication interface 109 is preferably carried out by the SAM card 107.
  • a communication between a payment device 4 and the payment terminal 1 can be carried out via the intermediary. of the communication interface 109.
  • the smart card reader 110 is a smart card reader conforming to the IS07816 standard in order to receive a bank card 3 and to communicate with it by electrical contacts.
  • the proximity interface 111 is a contactless card reader conforming to the IS014443 standard which makes it possible to communicate with a bank card 3 or any other contactless payment device 4 having a proximity interface compatible with said IS014443 standard.
  • the memory 104 of the payment terminal 1 comprises one or more subroutines corresponding to one or more transaction policies Pol (PI) in order to take into consideration the personal information PI stored in the payment device 3 or 4.
  • Such transaction policies may be justified from a legal point of view or from a commercial point of view.
  • Each Pol (PI) transaction policy includes a condition relating to personal PI information which conditions the completion of a transaction depending on whether or not said condition is verified by said personal PI information.
  • the payment terminal 1 makes it possible to avoid having to justify the veracity of this information to a seller by producing example an identity document.
  • a first transaction policy Pol may relate to a minimum age of the bearer of the payment device in order to be able to carry out a transaction on a legally restricted product. For example, a sale may be refused to a minor.
  • This first policy allows, for example, a distributor of cigarettes or alcoholic beverages to verify the age of the customer without having to resort to a person to carry out said verification.
  • a second Pol (PI) transaction policy may relate to a commercial discount according to the age of the person as part of a commercial promotion to favor a young or senior clientele.
  • the payment terminal 1 can verify the personal information PI corresponding to the age of the holder of the device. payment and calculate a ten percent discount on a transaction amount.
  • a third Pol (PI) transaction policy may consist of zero-rating foreign persons in order to avoid subsequent zero-rating operations. With this third policy, the payment terminal 1 can, for example, verify personal information PI corresponding to the country of residence of the bearer of the payment device and deduct the amount of taxes if the personal information PI corresponds to a country for which the zero-rating is applicable.
  • the address can also be used commercially in a fourth Pol (PI) transaction policy that causes trade discounts to people residing in trade promotion geographies.
  • the terminal verifies personal information PI corresponding to the address or postal code of the bearer of the payment device and then calculates a commercial discount if the address of residence corresponds to a geographical area of commercial promotion.
  • Many other policies can be considered as long as certain personal information is present in the payment device. Very many variants are possible since a transaction can be conditioned by personal information PI.
  • Verifying the conformity of personal PI information with the condition of the Pol (PI) transaction policy can be done in different ways. According to the invention, the authenticity of the personal information PI is verified prior to the verification of compliance with said condition.
  • Figures 5 and 6 illustrate two verification techniques. For these two FIGS. 5 and 6, the payment terminal 1 and the bank server 2 are considered jointly. Indeed, for certain authentication operations, the payment terminal 1 becomes “transparent” and only serves as a relay or gateway between a payment device 3 or 4 and the bank server 2.
  • FIGS. 5 and 6 we consider a payment terminal 1 of the chip card reader type, in conjunction with a payment device 3 of the bank card type. However, all the variants of banking terminal or payment device 3 or 4 can replace the system described.
  • FIG. 5 and 6 illustrate two verification techniques. For these two FIGS. 5 and 6, the payment terminal 1 and the bank server 2 are considered jointly. Indeed, for certain authentication operations, the payment terminal 1 becomes “transparent” and only serves as a relay or gateway between a payment device 3 or 4 and the bank server
  • a first example of a method of using personal information is described.
  • the payment terminal 1 and the payment device 3 implement their respective transaction programs including the subroutines relating to the various steps of the method which will be described and in particular the subroutines relating to the implementation of the transaction policies.
  • Pol PI
  • the payment terminal 1 and the payment device 3 perform a mutual authentication step 500, as defined in a bank payment protocol, for example the EMV protocol.
  • the payment device 3 and the payment terminal 1 can exchange public keys, certificates, a secret, carry out a challenge, determine a session key and, optionally, exchange a PIN code.
  • the purpose of the authentication step 500 is to allow, on the one hand, the payment terminal 1 to verify that the payment device 3 is an authorized payment device and, on the other hand, the payment device 3 to verify that the payment terminal 1 is an authorized payment terminal and, optionally, that the holder of the payment device validates the transaction on the payment terminal 1.
  • the payment terminal 1 to verify that the payment device 3 is an authorized payment device
  • the payment device 3 to verify that the payment terminal 1 is an authorized payment terminal and, optionally, that the holder of the payment device validates the transaction on the payment terminal 1.
  • any transaction standard can replace the EMV standard and it is not necessary to have mutual authentication when at least one cryptographic key is exchanged between the payment terminal 1 and payment device 3.
  • a transaction step 501 comes after the mutual authentication step 500.
  • the payment terminal 1 and the payment device 3 exchange the transaction data, such as for example the amount of the transaction, and executes each of the offline risk analysis subroutines, possibly supplemented by an online risk analysis by communicating with the bank server 2 then finalize the transaction either by refusing the transaction or by accepting it and memorizing the transaction carried out on both sides.
  • a step of verifying the personal information PI is added between the mutual authentication step 500 and the transaction step 501.
  • the application of the transaction policy Pol (PI) can then be executed before or at the time of the transaction step 501.
  • the payment terminal 1 sends a request 510 requesting one or more personal information PI to the payment device 3.
  • the payment device 3 sends back a response 520 containing the information.
  • the payment terminal 1 verifies the authentication data of the personal information PI in a step 530 and, if the latter is authenticated, verifies that the personal information complies with the condition of the transaction policy Pol (PI).
  • the transaction policy Pol (PI) is then applied according to the verification before or during the transaction step 501.
  • the 510 request can be sent in several ways, or even sent implicitly. According to a first embodiment conforming to the EMV protocol, the request 510 is not sent.
  • the mutual authentication step 500 information relating to the possibilities of the payment terminal 1 can be sent to the payment device 3 so that the latter is informed of the protocol to be applied with respect to the payment terminal 1 .
  • the payment terminal 1 indicates that personal data PI is required to finalize the transaction.
  • the payment terminal 1 performs a hot reset of the payment device 3, also known by the English terminology “Hot Reset”.
  • the payment device 3 sends a response 520 which corresponds to an ATR type message (standing for Answer To Reset) completed by the personal information PI and by a signature Sig (PI) of personal PI information.
  • the Sig (PI) signature is a cryptographic signature of the personal data PI, for example a signature as defined in the PKCS # 1 standard using a cryptographic key which can be a common encryption key, or an encryption structure to public key, shared by the payment device 3 and the payment terminal 1.
  • MAC for English Message Authentication Code
  • HMAC Keyed-Hashing for Message Authentication
  • the important thing is that the cryptographic key used by the payment device 3 allows the payment terminal 1 to ensure the authenticity of the personal data PI during step 530.
  • the personal information PI being considered authentic , the payment terminal checks whether said personal information PI complies with the condition of the transaction policy Pol (PI).
  • the payment terminal 1 sends a request 510 in the form of an APDU type command (standing for Application Protocol Data Unit) defined in the IS07816 standard to read personal information.
  • APDU type command standing for Application Protocol Data Unit
  • the commands GET_DATA, READ_BINARY and READ_RECORD make it possible to read information in a payment device 3.
  • the payment device In response to the one of these commands identifying the personal PI information or an area containing said PI information, the payment device responds by sending a response message 520 containing the personal PI information accompanied by a certificate or a cryptographic signature Sig (PI ) to allow the payment terminal to authenticate said personal information PI during step 530.
  • the certificate or the cryptographic signature is produced for example according to one of the techniques described above. Since personal PI information is considered authentic, the payment terminal checks whether said personal PI information complies with the condition of the Pol (PI) transaction policy.
  • FIG. 6 illustrates a second example of a method of using personal information PI.
  • the payment terminal 1 and the payment device 3 implement their respective transaction programs including the subroutines relating to the different steps of the method which will be described and in particular the subroutines relating to the implementation of the transaction policies.
  • Pol PI
  • the payment terminal 1 and the payment device 3 perform a mutual authentication step 500 and a transaction step 501, as previously defined according to an electronic payment protocol.
  • a verification of the personal information PI is added between the mutual authentication step 500 and the step transaction 501 before applying the transaction policy prior to or at the time of transaction step 501.
  • any transaction standard can replace the EMV standard and it is not necessary to have mutual authentication as soon as at least one cryptographic key is exchanged between the payment terminal 1 and payment device 3.
  • the payment terminal 1 sends a request 610 for verifying the personal information PI to the payment device 3 indicating a condition to be verified with respect to the personal information PI in order to apply the policy Pol (PI) transaction.
  • the payment device 3 verifies that the personal information PI corresponds to the condition sent in the request 610.
  • the payment device 3 sends a response 630 to the payment terminal 1 containing the result of the verification. .
  • the payment terminal 1 then applies the transaction policy Pol (PI) as a function of the result of the verification before or during the transaction step 501.
  • the personal information PI can remain confidential because the only information given is that the personal PI information satisfies the condition of the transaction policy.
  • the verification request 610 can be sent using a VERIFY type APDU which has a number of data fields which specify the personal PI information to be verified and the condition of the transaction policy. Pol (PI).
  • the request 610 can also include a signature made using a cryptographic key shared by the payment terminal 1 and the payment device 3. The signature is carried out for example. on all the bits of the request that correspond to the condition.
  • the condition can include a value and a relationship between the value and the personal PI information.
  • the value can be the age or the cut-off date of birth and the relation can be a comparison to this age or date of birth of the type "Lower" or "higher". If the personal information is a place of residence, for example a country, a postal code or an address, the relation can be of the type "equal" or "different".
  • the payment device 3 On receipt of the request 610, the payment device 3 implements a verification subroutine during step 620. Thus the payment device checks that the signature of the request 610 complies with the condition requested. This first check makes it possible to ensure that the request is indeed sent by the payment terminal 1 which is considered to be a device authorized to perform such a check. Once the request has been verified successfully, the microprocessor 31 of the payment device 3 reads from its memory 33 the personal information PI specified in the request 610. Then, the payment device 3 performs the requested comparison of the information. personal PI with the specified value. Once the comparison has been made, the payment device will then prepare and send back a response 630 corresponding to the result of said comparison.
  • the result is binary, ie the condition is verified or the condition is not verified and the response 630 may correspond to a response message to the VERIFY command validating or invalidating the comparison carried out in a secure manner.
  • the response can also be signed using the cryptographic key.
  • the payment terminal 1 then applies the transaction policy Pol (PI) according to the result of the verification, before or during the transaction step 501.
  • PI transaction policy Pol
  • the second example of implementation of the invention also makes it possible to store personal information PI in the payment device. This keeps personal PI information confidential, which may be sensitive information, such as the holder's address, for example.
  • PI Pol
  • several personal information can be present in the payment device 3 and several Pol (PI) transaction policies can be used during the same transaction.
  • PI Pol
  • the APDUs used must be defined both in the payment device 3 and in the payment terminal 1.
  • those skilled in the art will understand that it is necessary to codify and standardize such functionalities in order to be able to use them.
  • the transaction can be done using a radiofrequency communication protocol, for example conforming to the IEEE 802.11 standard better known under the name of Wifi.
  • Securing the transaction can be done by using, for example, an encrypted channel using a transaction method similar to that described above.
  • the embodiments described with the aid of FIGS. 5 and 6 can be applied in a similar manner while taking into account that the messages exchanged between the payment terminal 1 and the mobile telephone 4 will be made according to another exchange protocol. data that does not necessarily use APDUs.
  • the use of a certification of personal information PI helps to guarantee at the transaction level that the information is authentic.
  • the personal information PI is stored in the payment device 3 by an authorized third party, such as for example a banking establishment, and the certification carried out by the payment device constitutes certification by the authorized third party.

Landscapes

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

Abstract

L'invention concerne un procédé de transaction électronique pour un système comprenant un dispositif de paiement 3 ou 4 associé à utilisateur et un terminal de paiement 1. Le dispositif de paiement 3 ou 4 et le terminal de paiement 1 réalisent un échange de clef cryptographique 500 avant de réaliser une étape de transaction 501. Le dispositif de paiement comporte une information personnelle PI relative à l'utilisateur. Le terminal de paiement comporte une politique de transaction comportant une condition relative à l'information personnelle PI. Le procédé comporte une étape de vérification 510, 520, 530, préalablement à l'étape de transaction 501, pour vérifier la condition de la politique de transaction relative à l'information personnelle de manière sécurisée en utilisant la clef cryptographique.

Description

Description
Titre de l'invention : PROCEDE ET SYSTEME, DISPOSITIF ET TERMINAL DE PAIEMENT UTILISANT DES DONNEES
PERSONNELLES
[0001] Domaine Technique
[0002] La présente invention se rapporte à un procédé, un système, un dispositif et un terminal de paiement utilisant des données personnelles. Plus généralement, l’invention se rapporte à une amélioration de paiements électroniques sécurisés.
[0003] Arrière-Plan Technologique
[0004] Une transaction électronique permet la vente ou l'achat de biens ou de services en utilisant des moyens de paiement électroniques. Le présent document se rapporte plus particulièrement aux transactions initiées sur un point de vente et réalisées sur un appareil disposant de moyens pour sécuriser de telles transactions. Pour mettre en œuvre ce type de transaction, un dispositif de paiement mémorise des identifiants de paiement, tel qu'une carte bancaire (magnétique, à contact ou sans contact), un téléphone mobile ou une montre intelligente, afin d’être présenté à un terminal de paiement qui vérifie l’authenticité du moyen de paiement et valide la transaction. Dans les transactions actuelles, seules l’authentification des moyens de paiement et la capacité de paiement sont vérifiés. De nombreux protocoles de paiement existent. A titre d’exemple non limitatif, le protocole EMV (issu des initiales des sociétés fondatrices Europay international, MasterCard international et Visa international) spécifie l’interopérabilité entre des cartes bancaires et des terminaux de paiement en autorisant de nombreuses variantes de mise en œuvre : avec ou sans contact, avec paiement comptant ou à crédit, avec ou sans code PIN, avec des niveaux de sécurité variables suivant le type de transaction ou selon l’émetteur de la carte, etc.
[0005] Par ailleurs, des conditions de paiement peuvent être conditionnées selon certaines données personnelles d’un acheteur et certaines transactions peuvent également être légalement interdites selon de telles données personnelles. Lorsqu’elles existent, ces conditions de transaction sont généralement vérifiées par un vendeur lors de l’achat. Des consommateurs non résidants peuvent être désireux de ne pas payer certaines taxes imposées sur la vente de produits, tel que par exemple la TVA (Taxe sur la Valeur Ajoutée en France). Pour cela, ils doivent justifier de leur état ou faire une demande de détaxation postérieure à un achat. Un contrôle de l’âge de l’acheteur peut être requis pour obtenir une réduction de tarif ou une autorisation d’achat. Ce type de contrôle n’est réalisable que si un vendeur est présent ou, si un tel achat est réalisé sur un distributeur automatique, en faisant confiance aux données qui sont indiquées par l’acheteur. Un vendeur peut en outre omettre de vérifier de telles données personnelles ou se faire tromper par un acheteur mal intentionné, tout comme un distributeur automatique.
[0006] Il existe un besoin pour réaliser des transactions conditionnées par des données personnelles d’un titulaire de moyen de paiement afin d’appliquer un tarif approprié ou d’autoriser une transaction de manière sure et automatisée en fonction de données personnelles d’un acheteur muni de moyens de paiement électroniques.
[0007] Résumé de l’Invention
[0008] L’invention propose d’améliorer les transactions électroniques sur un point de vente en vérifiant de manière sécurisée l’authenticité d’une ou plusieurs informations personnelles d’un acheteur sans que celui-ci n’ait à produire de justificatif à un vendeur. A cet effet, un dispositif de paiement comporte au moins une information personnelle qui est présentée de manière certifiée à un terminal de paiement. Le terminal de paiement est adapté pour mettre en œuvre une politique de transaction qui prend en compte une ou plusieurs informations personnelles pour autoriser ou refuser de finaliser une transaction.
[0009] L’invention propose un procédé de transaction électronique entre un dispositif de paiement associé à un compte bancaire d’un utilisateur et un terminal de paiement associé à un compte bancaire acquéreur dans lequel le dispositif de paiement et le terminal de paiement réalisent au moins un échange de clef cryptographique avant de réaliser une étape de transaction au cours de laquelle la transaction est validée ou rejetée. Le dispositif de paiement comporte au moins une information personnelle relative à l’utilisateur. Le terminal de paiement comporte au moins une politique de transaction comportant une condition relative à l’au moins une information personnelle. Le procédé comporte une étape de vérification, préalablement à l’étape de transaction, pour vérifier la condition de la politique de transaction relative à l’information personnelle de manière sécurisée en utilisant la clef cryptographique.
[0010] Selon un premier mode de réalisation, l’étape de vérification peut consister en que le dispositif de paiement envoie l’information personnelle accompagnée d’une signature cryptographique réalisée à l’aide de l’information personnelle et de la clef cryptographique afin d’authentifier l’information personnelle. Le terminal de paiement peut vérifier la condition de la politique de transaction après avoir authentifier l’information personnelle.
[0011] Selon une variante de ce premier mode de réalisation, préalablement à l’envoi de l’information personnelle, le terminal de paiement peut envoyer une requête au dispositif de paiement pour provoquer l’envoi de l’information personnelle par ce dernier.
[0012] Selon un deuxième mode de réalisation, l’étape de vérification peut consister en ce que le terminal de paiement envoie une requête de vérification de la politique de transaction au dispositif de paiement la requête étant signée à l’aide de la clef cryptographique. La vérification de la condition de la politique de transaction peut être réalisée par le dispositif de paiement, après avoir authentifier la requête à l’aide de la clef cryptographique, qui élabore et transmet un message de validation ou d’invalidation au terminal de paiement en fonction de la condition et de l’information personnelle.
[0013] Selon un mode particulier, le montant de la transaction peut être modifié par le terminal de paiement en fonction du résultat de l’étape de vérification.
[0014] Préférentiellement, l’échange de clef cryptographique peut être réalisé lors d’une étape d’authentification mutuelle.
[0015] L’invention propose également un procédé de transaction électronique mis en œuvre par un microprocesseur d’un dispositif de paiement associé à un compte bancaire d’un utilisateur destiné à coopérer avec un terminal de paiement associé à un compte bancaire acquéreur afin de réaliser une étape de transaction au cours de laquelle la transaction est validée ou rejetée, ledit procédé comportant une étape pour échanger avec le terminal de paiement au moins une clef cryptographique. Le dispositif de paiement comporte au moins une information personnelle relative à l’utilisateur enregistrée dans une mémoire de données. Le procédé comporte une étape de vérification d’une condition d’une politique de transaction relative à l’information personnelle est vérifiée de manière sécurisée en utilisant la clef cryptographique.
[0016] Selon un premier mode de réalisation, l’étape de vérification peut comporter l’envoi d’un message contenant l’information personnelle accompagnée d’une signature cryptographique réalisée à l’aide de l’information personnelle et de la clef cryptographique afin d’authentifier ladite information personnelle.
[0017] Selon un deuxième mode de réalisation, l’étape de vérification de la condition de la politique de transaction peut comporter une étape préalable pour authentifier une requête émise par le terminal de paiement contenant la condition de la politique de transaction, la requête étant signée à l’aide de la clef cryptographique, et une étape d’envoi d’un message de validation ou d’invalidation en fonction de la condition et de l’information personnelle.
[0018] En outre, l’invention propose un procédé de transaction électronique mis en œuvre par un microprocesseur d’un terminal de paiement, associé à un compte bancaire acquéreur, destiné à coopérer avec un dispositif de paiement associé à un compte bancaire d’un utilisateur. Ledit procédé comporte une étape pour échanger au moins une clef cryptographique avec le dispositif de paiement et une étape de transaction au cours de laquelle la transaction est validée ou rejetée. Le terminal de paiement comporte au moins une politique de transaction comportant une condition relative à au moins une information personnelle relative à l’utilisateur du dispositif de paiement. Le procédé comporte une étape de vérification pour requérir la vérification de la condition de la politique de transaction relative à l’information personnelle en utilisant la clef cryptographique, et l’étape de transaction est mise en œuvre si et seulement si la condition est vérifiée.
[0019] Selon un premier mode de réalisation, au cours de l’étape de vérification, le procédé peut comporter une étape pour recevoir un message incluant l’information personnelle accompagnée d’une signature cryptographique réalisée à l’aide de l’information personnelle et de la clef cryptographique et une étape pour vérifier la condition de la politique de transaction après avoir authentifié l’information personnelle à l’aide de la clef cryptographique.
[0020] Selon une variante de ce premier mode de réalisation, le procédé peut comporter une étape pour élaborer et transmettre une requête au dispositif de paiement afin d’obtenir l’information personnelle.
[0021] Selon un deuxième mode réalisation, l’étape de vérification peut consister à élaborer et transmettre une requête de vérification de la politique de transaction au dispositif de paiement, la requête étant signée à l’aide de la clef cryptographique.
[0022] Selon un mode de réalisation particulier, le procédé peut comporter une étape pour modifier le montant de la transaction en fonction du résultat de la vérification de la condition préalablement à la validation de la transaction.
[0023] Selon un autre aspect, l’invention propose un système de transaction électronique comprenant un dispositif de paiement associé à un compte bancaire d’un utilisateur et terminal de paiement associé à un compte bancaire acquéreur dans lequel le dispositif de paiement et le terminal de paiement sont configurés pour réaliser un échange d’au moins une clef cryptographique avant de réaliser une étape de transaction au cours de laquelle la transaction est validée ou rejetée. Le dispositif de paiement comporte au moins une information personnelle relative à l’utilisateur et le terminal de paiement comporte au moins une politique de transaction comportant une condition relative à l’au moins une information personnelle. Le dispositif et le terminal de paiement sont configurés pour réaliser une étape de vérification entre l’étape d’échange de clef cryptographique et l’étape de transaction au cours de laquelle la condition de la politique de transaction relative à l’information personnelle est vérifiée de manière sécurisée à l’aide de la clef cryptographique.
[0024] Selon un premier mode de réalisation, le dispositif de paiement peut être configuré pour transmettre au terminal de paiement un message contenant l’information personnelle signé à l’aide de l’information personnelle et de la clef cryptographique afin d’authentifier l’information personnelle et le terminal de paiement peut être configuré pour vérifier la condition après avoir authentifier l’information personnelle à l’aide de la clef cryptographique.
[0025] Selon une variante de ce premier mode de réalisation, le terminal de paiement peut être configuré pour élaborer et transmettre une requête au dispositif de paiement afin d’obtenir l’information personnelle.
[0026] Selon un deuxième mode de réalisation, le terminal de paiement peut être configuré pour élaborer et transmettre au dispositif de paiement une requête de vérification de la condition de la politique de transaction signée à l’aide de la clef cryptographique. Le dispositif de paiement peut être configuré pour authentifier ladite requête à l’aide de la clef cryptographique avant de vérifier la condition en réponse à la requête de vérification et pour renvoyer un message de validation ou d’invalidation au terminal de paiement en fonction de la condition et de l’information personnelle.
[0027] Selon un mode de réalisation particulier, le terminal de paiement peut être configuré pour modifier le montant de la transaction en fonction du résultat de l’étape de vérification.
[0028] Également, l’invention propose un dispositif de paiement associé à un compte bancaire d’un utilisateur destiné à coopérer avec un terminal de paiement pour réaliser une transaction électronique, ledit dispositif de paiement étant configuré pour échanger au moins une clef cryptographique avec le terminal de paiement. Le dispositif de paiement comporte au moins une information personnelle relative à l’utilisateur, et le dispositif de paiement est configuré pour réaliser une étape de vérification d’une condition d’une politique de transaction relative à l’information personnelle de manière sécurisée à l’aide de la clef cryptographique
[0029] Selon un premier mode de réalisation, le dispositif de paiement peut être configuré pour envoyer au terminal de paiement l’information personnelle dans un message signé à l’aide de l’information personnelle et de la clef cryptographique afin d’authentifier l’information personnelle
[0030] Selon un deuxième mode de réalisation, le dispositif de paiement peut être configuré pour vérifier la condition de la politique de transaction en réponse à la réception d’une requête de vérification contenant la condition, ladite requête étant signée et transmise par le terminal de paiement à l’aide de la clef cryptographique, et pour élaborer et transmettre un message de validation ou d’invalidation au terminal de paiement en fonction de la condition et de l’information personnelle.
[0031] Préférentiellement, le dispositif de paiement peut être un dispositif compris dans la liste suivante : carte à puce conforme à la norme IS07816 et/ou à la norme 14443, téléphone portable ou tablette comprenant une capacité de paiement sécurisé, montre intelligente comprenant des fonctionnalités de paiement, ordinateur sécurisé comprenant une interface de communication avec ou sans contact et comprenant une capacité de paiement sécurisé.
[0032] En outre, l’invention propose un terminal de paiement associé à un compte bancaire acquéreur destiné à coopérer avec un dispositif de paiement associé à un compte bancaire d’un utilisateur pour réaliser une transaction électronique dans lequel le terminal de paiement est configuré pour échanger au moins une clef cryptographique avec le dispositif de paiement avant de mettre en œuvre une étape de transaction au cours de laquelle la transaction est validée ou rejetée. Le terminal de paiement comporte au moins une politique de transaction comprenant une condition relative à au moins une information personnelle enregistrée dans une mémoire du dispositif de paiement, ladite information personnelle étant relative à l’utilisateur. Le terminal de paiement est configuré pour mettre en œuvre une étape de vérification, avant l’étape de transaction, au cours de laquelle la condition de la politique de transaction relative à l’information personnelle est vérifiée de manière sécurisée à l’aide de la clef cryptographique.
[0033] Selon un premier mode de réalisation, le terminal de paiement peut être configuré pour recevoir un message contenant l’information personnelle signé à l’aide de l’information personnelle et de la clef cryptographique par le dispositif de paiement. Le terminal de paiement peut être configuré pour vérifier la condition après avoir authentifier l’information personnelle à l’aide de la clef cryptographique. [0034] En variante du premier mode de réalisation, le terminal de paiement peut être configuré pour élaborer et transmettre une requête au dispositif de paiement afin d’obtenir l’information personnelle.
[0035] Selon un deuxième mode de réalisation, le terminal de paiement peut être configuré pour élaborer et transmettre au dispositif de paiement une requête de vérification de la condition de la politique de transaction signée à l’aide de la clef cryptographique. Le terminal de paiement peut être configuré pour terminer la transaction suite à un message de validation ou d’invalidation renvoyé par le dispositif de paiement en fonction de la condition et de l’information personnelle.
[0036] Selon un mode de réalisation particulier, le terminal de paiement peut être configuré pour modifier le montant de la transaction en fonction du résultat de l’étape de vérification.
[0037] Préférentiellement, ledit terminal de paiement peut être compris dans la liste de dispositifs suivante : terminal de point de vente pour carte à puce, téléphone portable ou tablette comprenant une capacité d’enregistrement de paiement sécurisé, caisse enregistreuse comprenant une capacité d’enregistrement de paiement sécurisé.
[0038] Brève Description des figures
[0039] L’invention sera mieux comprise et d’autres caractéristiques et avantages de celle-ci apparaîtront à la lecture de la description suivante de modes de réalisation particuliers de l’invention, donnés à titre d’exemples illustratifs et non limitatifs, et faisant référence aux dessins annexés, parmi lesquels :
[0040] [Fig.1] illustre un système de paiement électronique concerné par l’invention,
[0041] [Fig.2] illustre une carte à puce selon l’invention,
[0042] [Fig.3] illustre un téléphone portable utilisé comme moyen de paiement selon l’invention,
[0043] [Fig.4] illustre un terminal de paiement selon l’invention,
[0044] [Fig.5] représente un schéma de paiement modifié selon un premier exemple de réalisation de l’invention, [0045] [Fig.6] représente un schéma de paiement modifié selon un deuxième exemple de réalisation de l’invention.
[0046] Description détaillée
[0047] La figure 1 illustre un système de paiement électronique sécurisé utilisé selon l’état de la technique et utilisé pour mettre en œuvre l’invention. Le système de la figure 1 comporte un terminal de paiement 1 capable de communiquer d’une part avec un serveur bancaire 2 et d’autre part avec un dispositif de paiement 3 ou 4. Ce type de système est communément utilisé pour effectuer des opérations de paiement depuis un point de vente, tel que défini dans de nombreuses normes de services de paiement, par exemple dans la norme EMV qui est la plus largement utilisée et qui comporte de nombreuses possibilités de mise en œuvre. Le terminal de paiement 1 peut être amené à réaliser des transactions « hors ligne » ou « en ligne » c’est-à-dire de manière déconnectée ou connectée avec le serveur bancaire 2. Le dispositif de paiement 3 est classiquement une carte à puce 3 ou un téléphone portable 4, voire tout autre dispositif électronique capable d’émuler le fonctionnement d’une carte à puce de manière sécurisée, tel que par exemple une montre intelligente qui est une extension d’un téléphone portable sous forme d’une montre bracelet, ou encore tout type d’ordinateur ayant les mêmes capacités ou fonctionnalités.
[0048] A titre d’exemple, la figure 2 illustre fonctionnellement une carte bancaire 3, ou carte à puce, qui comporte un microprocesseur 31 contrôlant un bus central 32 pour échanger des données avec une mémoire 33, un crypto-processeur 34, une interface de communication à contact 35 et une interface de communication sans contact 36. L’interface de communication à contact 35 est par exemple compatible avec la norme IS07816. L’interface de communication sans contact 36 est par exemple une interface de communication en champ proche, de type NFC (de l’anglais Near Field Contactless) compatible avec la norme IS014443. Bien que de nombreuses cartes de paiement disposent de ces deux types d’interface de communication 35 et 36, certaines cartes ne disposent que d’une seule interface de communication avec ou sans contact. Pour l’invention, l’important est que la carte à puce 3 dispose d’au moins une interface de communication avec ou sans contact. [0049] La mémoire 33 peut être segmentée en mémoire volatile de type RAM (de l’anglais Random Access Memory), en mémoire de programme non inscriptible de type ROM (de l’anglais Read-Only Memory) et en mémoire non volatile de type EEPROM (de l’anglais Electrically-Erasable Programmable Read-Only Memory) ou Flash. Un système d’exploitation sécurisé est mis en œuvre par le microprocesseur 31 pour garantir la sécurité des informations mémorisées dans la mémoire 33 de la carte à puce 3. Ainsi, le microprocesseur 31 peut autoriser l’accès en lecture ou en écriture de certaines zones de la mémoire à des commandes provenant de l’une des interfaces de communication 35 ou 36. D’autres zones de la mémoire 33 ne peuvent être accessibles qu’au microprocesseur 31 ou au crypto-processeur 34. Certaines données peuvent être rendues accessibles par le microprocesseur 31 depuis l’extérieur de manière conditionnelle.
[0050] De nombreuse variantes d’architecture de carte à puce sont connues et l’homme du métier peut à loisir utiliser une architecture différente ou similaire de celle décrite sur la figure 2. Néanmoins, l’homme du métier prendra soin de n’utiliser que des architectures de carte sécurisées de manière suffisante pour l’application aux services bancaires et notamment conforme aux spécifications d’une norme de transaction bancaire, telle que par exemple et non limitativement la norme EMV.
[0051] Selon l’invention, une information personnelle PI est stockée dans la partie non volatile de la mémoire 33 lors de la personnalisation de la carte à puce concomitamment à des données relatives à un compte bancaire auquel la carte à puce est associée. L’information personnelle PI est relative au titulaire du compte bancaire. Elle peut être relative à son âge, à sa date de naissance, à son lieu de résidence ou consister en tout autre information personnelle qui peut être utilisée lors d’une transaction selon l’invention. L’information personnelle PI peut être stockée dans une zone de mémoire accessible en lecture directement depuis l’une des interfaces de communication 35 ou 36 tout en étant protégée en écriture afin qu’elle ne puisse être altérée après la personnalisation par une personne non autorisée. Cependant, de manière préférée, l’information personnelle PI est stockée dans une zone de la mémoire 33 qui n’est pas directement accessible depuis l’une des interfaces de communication 35 ou 36. Dans une variante, l’information personnelle PI n’est pas du tout accessible depuis l’extérieur. L’utilisation de cette information personnelle PI sera décrite plus loin dans la présente description.
[0052] La figure 3 illustre de manière fonctionnelle un téléphone portable 4 utilisable comme dispositif de paiement. A titre d’exemple, le téléphone portable 4 est un téléphone portable de type intelligent, communément nommé sous l’appellation anglo-saxonne « smartphone », qui comporte un microprocesseur 41 relié à travers un bus central 42 à une mémoire volatile 43, une mémoire non volatile 44, une interface utilisateur 45, une carte SIM 46, une interface de radiocommunication 47, une interface de proximité 48 et un élément sécurisé 49. D’autres éléments peuvent également faire partie du téléphone portable 4 mais ne sont pas représentés car ils ne concernent pas directement l’invention. A titre d’exemple, ces autres éléments peuvent comprendre un microphone, un haut- parleur, un vibreur, une caméra, un lecteur de carte mémoire, une interface de communication filaire par exemple de type USB, une batterie ou encore tout autre élément intégrable dans un téléphone portable. De plus, le téléphone portable 4 décrit à l’aide la figure 3 correspond à un type de téléphone préféré non limitatif. Notamment, en variante, il est possible que le téléphone portable 4 ne comporte pas l’élément sécurisé 49 ni la carte SIM 46.
[0053] Le microprocesseur 41 est le « cœur » du téléphone portable 4 qui gère l’intégralité des éléments le constituant via le bus central 42 à partir de programmes enregistrés dans la mémoire non volatile 44 en utilisant la mémoire volatile 43 comme mémoire de travail. La mémoire non volatile 44 est par exemple composée de mémoire de type ROM et de mémoire électriquement effaçable de type EEPROM ou de type Flash. Parmi les programmes mémorisés, le système d’exploitation du téléphone portable 4 permet de gérer les différentes fonctionnalités en faisant appel à des programmes spécifiques qui permettent de produire différentes commandes à destination des différents éléments du téléphone 4. Dans le mode de réalisation préféré selon la figure 3 qui inclue la carte SIM 46 et l’élément sécurisé 49, le système d’exploitation n’est pas sécurisé en tant que tel car la sécurisation de données et d’opérations sensibles peut se faire dans la carte SIM 46 et/ou dans l’élément sécurisé 49. Selon une variante qui ne comporte pas de carte SIM 46, ni d’élément sécurisé 49, il est nécessaire d’avoir un système d’exploitation sécurisé qui permet de restreindre les accès en lecture, écriture et exécution à certaines zones de la mémoire afin de garantir la sécurisation de certains programmes et notamment les programmes de transactions bancaires.
[0054] L’interface utilisateur 45 est préférentiellement un écran tactile pouvant également inclure un lecteur d’empreinte digitale. Dans une variante minimaliste, l’interface utilisateur peut se limiter à un écran d’affichage et un clavier. De nombreuses autres variantes sont également possibles pour un homme du métier sans que cela limite la portée de l’invention.
[0055] La carte SIM 46 (de l’anglais Subscriber Identity Module) est communément utilisée pour mémoriser des identifiants d’accès à un réseau de téléphonie mobile (non représenté) et pour sécuriser l’accès audit réseau. Typiquement la carte SIM 46 est une carte à puce servant à authentifier le téléphone sur le réseau de téléphonie selon l’une des normes de téléphonie, une telle carte est par exemple conforme à la norme IS07816 et à la norme ETSI TS 102221. Selon le mode préféré de réalisation, la carte SIM 46 assure uniquement son rôle de communication avec le réseau de téléphonie mobile. [0056] L’interface de radiocommunication 47 est une interface radio programmable multi fréquences disposant de circuits de modulation, de démodulation, d’encodage et de décodage pouvant se configurer de différentes manières afin de communiquer sur une bande de fréquence et selon un protocole de communication choisi par le microprocesseur 41 en fonction d’informations contenue dans la carte SIM 46. Cette interface est compatible avec plusieurs standards de radio téléphonie, tel que 2G, 3G, 4G et/ou avec des standards de communication radio de plus courte portée tel que, par exemple les standards WiFi ou Bluetooth. Par cette interface de radiocommunication, il est possible d’échanger de la voix et des données. [0057] L’interface de proximité 48 est une interface de type CLF (de l’anglais
Contactless Front-End) tel que défini dans la norme ETSI TS 102613, afin de permettre au téléphone portable de réaliser des communications en champ proche de type NFC, qui sont compatibles avec la norme IS014443. Grâce à cette interface le téléphone portable 4 peut émuler le fonctionnement d’une carte à puce sans contact ou d’un lecteur de carte à puce sans contact. Le contrôle de cette interface de proximité se fait par l’intermédiaire du bus central 42 ou par un port de communication spécifique destiné à être directement relié à une carte SIM comme défini dans la norme ETSI TS 102613.
[0058] L’élément sécurisé 49 est un circuit intégré indépendant qui contient un processeur sécurisé, une mémoire d’exécution et un stockage inviolable à l’instar d’une carte à puce. L’élément sécurisé 49 comporte un premier port de communication relié au bus central 42 et un deuxième port de communication relié au port de communication spécifique de l’interface de proximité 48. Lorsque le téléphone 4 est éteint, l’élément sécurisé 49 peut être alimenté directement par l’interface de proximité 48 à partir du champ électromagnétique servant à la communication. L’élément sécurisé 49 peut mémoriser des données et des programmes de manière sécurisé. Il peut également les exécuter en toute sécurité. Cet élément sécurisé 49 peut contenir et exécuter des programmes sécurisés à l’identique de ceux exécutable par la carte à puce 3 décrite précédemment, notamment pour réaliser des opérations de paiement. Selon un mode de réalisation préféré, l’élément sécurisé contient l’information personnelle PI.
[0059] Selon une variante dans laquelle le téléphone portable 4 ne dispose pas d’élément sécurisé 49, la carte SIM 46 peut être une carte multi-applications intégrant une application bancaire et l’information personnelle PI. A cet effet, la carte SIM peut être conforme à la norme ETSI TS 102613 et disposer d’une liaison directe avec l’interface de proximité 48 via son port de communication spécifique ou effectuer des échanges de données avec le terminal de paiement 1 via l’interface de radiocommunication 47. La carte SIM 46 peut ainsi remplacer l’élément sécurisé 49 et assurer à sa place les différentes fonctions décrites précédemment. [0060] Selon une autre variante, le téléphone portable 4 ne dispose pas d’élément sécurisé 49 ni de carte SIM 46. Selon cette variante, le téléphone 4 dispose d’un système d’exploitation sécurisé, d’un programme d’application bancaire et l’information personnelle PI est stockée dans une zone protégée de la mémoire non volatile 44.
[0061] De manière alternative, le téléphone portable 4 peut être remplacé par tout autre dispositif électronique comportant un microprocesseur disposant de tout ou partie des éléments décrits en relation avec la figure 3. A titre d’exemple non limitatif, un tel dispositif peut être une tablette, une montre intelligente, ou un ordinateur portable. Il convient toutefois que le dispositif électronique dispose d’une capacité de sécurisation en lecture, en écriture et en exécution des programmes et des données pour pouvoir recevoir une application de paiement sécurisée et une interface de communication avec ou sans contact qui permette de communiquer avec le terminal de paiement 1 .
[0062] La figure 4 illustre de manière fonctionnelle un terminal de paiement 1 destiné à recevoir des paiements sous la forme de transactions électroniques. Le terminal de paiement 1 peut être un terminal de point de vente ou terminal POS (de l’anglais Point Of Sale) sécurisé, c’est-à-dire intégré dans un boîtier structurellement renforcé contre toute tentative malveillante d’atteinte à son intégrité mais peut également être placé dans un distributeur automatique de produit ou être indu dans une caisse enregistreuse de magasin, ou encore être émulé sur un téléphone portable intelligent de type « smartphone ».
[0063] A titre d’exemple non limitatif, le terminal de paiement 1 comporte un microprocesseur 101 relié à travers un bus central 102 à une mémoire volatile 103, une mémoire non volatile 104, un écran 105, un clavier 106, une carte SAM 107, une imprimante 108, une interface de communication 109 avec et/ou sans contact, un lecteur de carte à puce 110 à contact, une interface de communication de proximité 111. D’autres éléments peuvent également faire partie du terminal de paiement 1 mais ne sont pas représentés car ils ne concernent pas directement l’invention. A titre d’exemple, ces autres éléments peuvent comprendre une batterie, une carte SIM, un lecteur de carte à mémoire ou encore tout autre élément intégrable dans un terminal de paiement. De plus, le terminal de paiement 1 décrit correspond à un terminal de type POS préféré non limitatif. Notamment, en variante, il est possible que le terminal de paiement 1 soit simplifié ou émulé sur un téléphone portable sécurisé et ne pas comporter d’interface de communication de proximité 111 , de lecteur de carte à puce 110, d’imprimante 108 ou de carte SAM 107. En outre, l’écran 105 et le clavier 106 peuvent être remplacés par un écran tactile ou tout autre type d’interface homme machine permettant d’interagir avec un utilisateur.
[0064] Le microprocesseur 101 est le cœur du terminal de paiement 1 qui gère l’intégralité des éléments le constituant via le bus central 102 à partir de programmes mémorisés dans la mémoire non volatile 104 en utilisant la mémoire volatile 103 comme mémoire de travail. La mémoire non volatile 104 est par exemple composée de mémoire de type ROM et de mémoire électriquement effaçable de type EEPROM ou de type Flash. Parmi les programmes enregistrés dans la mémoire non volatile 104, nous pouvons citer un système d’exploitation sécurisé mis en œuvre par le microprocesseur 101 pour garantir la sécurité des informations mémorisées dans la mémoire 104. Ainsi, l’accès en lecture et/ou en écriture à certaines zones de mémoire n’est possible que sous le contrôle du microprocesseur 101 à partir de l’une des l’interfaces de communication 109.
[0065] La mémoire non volatile 104 comporte également des programmes exécutables par le microprocesseur 101 destinés à la réalisation de transactions bancaires. Ces programmes comportent un certain nombre de sous programmes capables de supporter différentes options de transaction qui dépendent du type de carte bancaire, de l’émetteur de la carte bancaire, et aussi de paramètres particuliers qui peuvent par exemple être définis par un marchand qui utilise ledit terminal de paiement 1. Parmi les sous programmes, certains peuvent être respectivement relatif à des politiques de transaction (en anglais Transaction Policies) qui définissent des conditions particulières de paiement, par exemple des vérifications électroniques à effectuer suivant le type de carte, un seuil de paiement au-delà duquel la banque doit être contactée pour autoriser ou refuser la transaction, des conditions relatives à l’entrée ou saisie d’un code de vérification ou à des vérifications complémentaires paramétrables par le marchand disposant dudit terminal 1.
[0066] L’écran 105 permet aux utilisateurs du terminal de paiement 1 de visualiser des informations lors de l’exécution d’une transaction. Le clavier 106 permet à son utilisateur d’indiquer au terminal de paiement 1 des informations de transaction tel que par exemple le montant de la transaction ou l’entrée d’un code d’identification personnel ou PIN (de l’anglais Personnal Identification Number). L’imprimante 108 sert à éditer un reçu de transaction à destination du débiteur et/ou du marchand. Dans une variante, l’imprimante 108 n’est pas présente et le reçu de transaction peut être envoyé sous la forme d’un message électronique à chacune des parties à la transaction ou à une autre machine reliée au terminal de paiement 1 qui effectuera l’édition en lieu et place dudit terminal 1.
[0067] La carte SAM 107 (de l’anglais Secure Access Module) est un module d’accès sécurisé ou module d’application sécurisé. La carte SAM garantie une sécurisation de la transaction et des informations sensibles du terminal de paiement 1. La carte SAM 107 peut mémoriser et produire des clefs cryptographique et/ou mettre en œuvre des algorithmes de calculs cryptographiques nécessaires pour la mise en œuvre d’une politique de sécurité, par exemple pour réaliser un processus d’authentification forte réalisé lors d’une transaction. La carte SAM 107 est une carte à puce insérée dans un lecteur interne non représenté du terminal de paiement 1. Selon une variante, la carte SAM 107 peut être remplacée par un élément sécurisé ou par le microprocesseur 101 si celui-ci comporte un processeur cryptographique et un système d’exploitation sécurisé permettant de garantir une sécurisation suffisante des informations sensibles.
[0068] L’interface de communication 109 permet au terminal de communiquer avec le serveur bancaire 2. Suivant le type de terminal de paiement 1 , une telle interface de communication 109 supporte classiquement des communications dites « filaires » par exemple suivant le protocole d’internet et/ou des communication de type radiocommunication, par exemple selon un protocole de radiotéléphonie 3G ou 4G. Le chiffrage des communications effectuée par l’intermédiaire de l’interface de communication 109 est préférentiellement effectué par la carte SAM 107. Selon une variante, une communication entre un dispositif de paiement 4 et le terminal de paiement 1 peut être réalisée par l’intermédiaire de l’interface de communication 109.
[0069] Le lecteur de carte à puce 110 est un lecteur de carte à puce conforme à la norme IS07816 afin de recevoir une carte bancaire 3 et de communiquer avec elle par contacts électriques. L’interface de proximité 111 est un lecteur de carte sans contact conforme à la norme IS014443 qui permet de communiquer avec une carte bancaire 3 ou tout autre dispositif de paiement 4 sans contact disposant d’une interface de proximité compatible avec ladite norme IS014443.
[0070] Selon un mode préféré de l’invention, la mémoire 104 du terminal de paiement 1 comporte un ou plusieurs sous-programmes correspondant à une ou plusieurs politiques de transaction Pol(PI) afin de prendre en considération l’information personnelle PI mémorisée dans le dispositif de paiement 3 ou 4. De telles politiques de transaction peuvent être justifiée d’un point de vue légal ou d’un point de vue commerciale. Chaque politique de transaction Pol(PI) comporte une condition relative à une information personnelle PI qui conditionne la réalisation d’une transaction suivant que ladite condition soit vérifiée ou non par ladite information personnelle PI. En vérifiant la conformité de l’information personnelle PI à la condition de la politique de transaction Pol(PI), le terminal de paiement 1 permet d’éviter d’avoir à justifier auprès d’un vendeur la véracité de ces informations en produisant par exemple une pièce d’identité. Ainsi, il est possible de réaliser des transactions conditionnées par des informations personnelles sans que la présence d’un vendeur soit nécessaire et donc de réaliser ce type de transaction à l’aide de machines de distribution.
[0071] A titre d’exemple non limitatif, quelques politiques de vérification d’information personnelles sont indiquées. Une première politique de transaction Pol(PI) peut être relative à un âge minimum du porteur du dispositif de paiement pour pouvoir effectuer une transaction sur un produit à distribution restreinte légalement. Par exemple, une vente peut être refusée à un mineur. Cette première politique permet, par exemple, à un distributeur de cigarettes ou de boissons alcoolisées de vérifier l’âge du client sans qu’il soit nécessaire d’avoir recours à une personne pour effectuer ladite vérification. Une deuxième politique de transaction Pol(PI) peut être relative à une remise commerciale en fonction de l’âge de la personne dans le cadre d’une promotion commerciale pour favoriser une clientèle jeune ou séniore. Par exemple, si le titulaire de la carte à moins de vingt-cinq ans ou plus de soixante-cinq ans, le terminal de paiement 1 peut vérifier l’information personnelle PI correspondant à l’âge du porteur du dispositif de paiement et calculer une remise de dix pour cent sur un montant d’une transaction. Une troisième politique de transaction Pol(PI) peut consister à détaxer les personnes étrangères afin d’éviter des opérations postérieures de détaxation. Avec cette troisième politique, le terminal de paiement 1 peut, par exemple, vérifier une information personnelle PI correspondant au pays de résidence du porteur du dispositif de paiement et déduire le montant des taxes si l’information personnelle PI correspond à un pays pour lequel la détaxation est applicable. L’adresse peut également être utilisée à titre commercial dans une quatrième politique de transaction Pol(PI) qui provoque des remises commerciales à des personnes résidant dans des zones géographiques de promotion commerciales. Selon cette quatrième politique, le terminal vérifie une information personnelle PI correspondant à l’adresse ou au code postal du porteur du dispositif de paiement puis calcule une remise commerciale si l’adresse de résidence correspond à une zone géographique de promotion commerciale. De nombreuses autres politiques peuvent être envisagées dès lors que certaines informations personnelles sont présentes dans le dispositif de paiement. De très nombreuses variantes sont envisageables dès lors qu’une transaction peut être conditionnée par une information personnelle PI.
[0072] La vérification de la conformité de l’information personnelle PI à la condition de la politique de transaction Pol(PI) peut se faire de différente manière. Selon l’invention, l’authenticité de l’information personnelle PI est vérifiée préalablement à la vérification de la conformité à ladite condition. Les figure 5 et 6 illustrent deux techniques de vérification. Pour ces deux figures 5 et 6, on considère conjointement le terminal de paiement 1 et le serveur bancaire 2. En effet, pour certaines opérations d’authentification, le terminal de paiement 1 devient « transparent » et ne sert que de relai ou passerelle entre un dispositif de paiement 3 ou 4 et le serveur bancaire 2. Pour les descriptions des figures 5 et 6, on considère un terminal de paiement 1 de type lecteur de carte à puce, en liaison avec un dispositif de paiement 3 de type carte bancaire. Néanmoins, toutes les variantes de terminal bancaire ou de dispositif de paiement 3 ou 4 peuvent se substituer au système décrit. [0073] Sur la figure 5, un premier exemple de procédé d’utilisation de l’information personnelle est décrit. Le terminal de paiement 1 et le dispositif de paiement 3 mettent en œuvre leurs programmes de transaction respectifs incluant les sous- programmes relatifs aux différentes étapes du procédé qui va être décrit et notamment les sous-programmes relatifs à la mise en œuvre des politiques de transaction Pol(PI). Dans ce premier exemple, le terminal de paiement 1 et le dispositif de paiement 3 réalisent une étape d’authentification mutuelle 500, tel que défini dans un protocole de paiement bancaire, par exemple le protocole EMV. Au cours de cette étape d’authentification mutuelle 500, le dispositif de paiement 3 et le terminal de paiement 1 peuvent s’échanger des clefs publiques, des certificats, un secret, réaliser un challenge, déterminer une clef de session et, éventuellement, échanger un code PIN. Le but de l’étape d’authentification 500 est de permettre, d’une part, au terminal de paiement 1 de vérifier que le dispositif de paiement 3 est un dispositif de paiement autorisé et, d’autre part, au dispositif de paiement 3 de vérifier que le terminal de paiement 1 est un terminal de paiement autorisé et, éventuellement, que le titulaire du dispositif de paiement valide la transaction sur le terminal de paiement 1. Pour plus de détails, l’homme du métier se reportera aux différentes normes de transaction de paiement existantes. Dans le cadre de l’invention, toute norme de transaction peut se substituer à la norme EMV et il n’est pas nécessaire d’avoir une authentification mutuelle dès lors qu’au moins une clef cryptographique soit échangée entre le terminal de paiement 1 et dispositif de paiement 3.
[0074] Selon l’état de la technique, une étape de transaction 501 vient après l’étape d’authentification mutuelle 500. Au cours de l’étape de transaction 501 , le terminal de paiement 1 et le dispositif de paiement 3 échangent les données de transaction, tel que par exemple le montant de la transaction, et exécute chacune des sous-programme d’analyse de risque hors ligne, éventuellement complétée par une analyse de risque en ligne en communiquant avec le serveur bancaire 2 puis finalisent la transaction soit en refusant la transaction soit en l’acceptant et en mémorisant de part et d’autre la transaction réalisée.
[0075] Selon l’invention, une étape de vérification de l’information personnelle PI est ajoutée entre l’étape d’authentification mutuelle 500 et l’étape de transaction 501. L’application de la politique de transaction Pol(PI) peut ensuite être exécutée préalablement à ou au moment de l’étape de transaction 501 . Dans l’exemple de la figure 5, le terminal de paiement 1 envoie une requête 510 demandant une ou plusieurs informations personnelles PI au dispositif de paiement 3. Suite à cette requête 510, le dispositif de paiement 3 renvoie une réponse 520 contenant l’information personnelle PI demandée accompagnée d’une donnée d’authentification Sig(PI) de l’information personnelle PI. Puis, le terminal de paiement 1 , vérifie la donnée d’authentification de l’information personnelle PI dans une étape 530 et, si celle-ci est authentifiée, vérifie que l’information personnelle est conforme à la condition de la politique de transaction Pol(PI). La politique de transaction Pol(PI) est ensuite appliquée en fonction de la vérification préalablement ou au cours de l’étape de transaction 501 .
[0076] La requête de 510 peut être envoyée de plusieurs manières, voire envoyée de manière implicite. Selon un premier mode de réalisation conforme au protocole EMV la requête 510 n’est pas envoyée. Lors de l’étape d’authentification mutuelle 500, Des informations relatives aux possibilités du terminal de paiement 1 peuvent être envoyées au dispositif de paiement 3 de sorte que ce dernier soit informé du protocole à appliquer vis-à-vis du terminal de paiement 1 . Parmi les informations envoyées, le terminal de paiement 1 indique qu’une donnée personnelle PI est requise pour finaliser la transaction. A l’issue de l’étape d’identification mutuelle 500, le terminal de paiement 1 effectue une remise à zéro à chaud du dispositif de paiement 3, également connu sous la terminologie anglaise « Hot Reset ». Suite au signal de remise à zéro, le dispositif de paiement 3 émet une réponse 520 qui correspond à un message de type ATR (de l’anglais Answer To Reset) complété par l’information personnelle PI et par une signature Sig(PI) de l’information personnelle PI. Préférentiellement la signature Sig(PI) est une signature cryptographique de la donnée personnelle PI, par exemple une signature telle que définie dans la norme PKCS#1 en utilisant une clef cryptographique qui peut être une clef de chiffrement commune, ou une structure de chiffrement à clef publique, partagée par le dispositif de paiement 3 et le terminal de paiement 1 . De très nombreux types de signatures sont possibles, à titre d’exemple complémentaire non limitatif, un MAC (de l’anglais Message Authentication Code) tel que défini dans la publication RFC 2104 : « HMAC : Keyed-Hashing for Message Authentication » peut également être utilisé. L’important est que la clef cryptographique utilisée par le dispositif de paiement 3 permette au terminal de paiement 1 de s’assurer de l’authenticité de la donnée personnelle PI au cours de l’étape 530. L’information personnelle PI étant considérée authentique, le terminal de paiement vérifie si ladite information personnelle PI est conforme à la condition de la politique de transaction Pol(PI).
[0077] Selon un deuxième mode de réalisation, le terminal de paiement 1 envoie une requête 510 sous la forme d’une commande de type APDU (de l’anglais Application Protocole Data Unit) définie dans la norme IS07816 pour lire l’information personnelle PI. Parmi les commandes APDU utilisables pour la requête 510, l’homme du métier peut utiliser, à titre d’exemple non limitatif, les commandes GET_DATA, READ_BINARY et READ_RECORD permettent de lire une information dans un dispositif de paiement 3. En réponse à l’une de ces commandes identifiant l’information personnelle PI ou une zone contenant ladite information PI, le dispositif de paiement répond en envoyant un message de réponse 520 contenant l’information personnelle PI accompagnée d’un certificat ou d’une signature cryptographique Sig(PI) pour permettre au terminal de paiement d’authentifier ladite information personnelle PI au cours de l’étape 530. Le certificat ou la signature cryptographique est réalisé(e) par exemple selon l’une des techniques décrites précédemment. L’information personnelle PI étant considérée authentique, le terminal de paiement vérifie si ladite information personnelle PI est conforme à la condition de la politique de transaction Pol(PI).
[0078] La figure 6 illustre un deuxième exemple de procédé d’utilisation de l’information personnelle PI. Le terminal de paiement 1 et le dispositif de paiement 3 mettent en œuvre leurs programmes de transaction respectifs incluant les sous-programmes relatifs aux différentes étapes du procédé qui va être décrit et notamment les sous-programmes relatifs à la mise en œuvre des politiques de transaction Pol(PI). Dans ce deuxième exemple, le terminal de paiement 1 et le dispositif de paiement 3 réalisent une étape d’authentification mutuelle 500 et une étape de transaction 501 , tel que précédemment défini selon un protocole de paiement électronique. Une vérification de l’information personnelle PI, est rajoutée entre l’étape d’authentification mutuelle 500 et l’étape de transaction 501 avant d’appliquer la politique de transaction préalablement à ou au moment de l’étape de transaction 501. Dans le cadre de l’invention, toute norme de transaction peut se substituer à la norme EMV et il n’est pas nécessaire d’avoir une authentification mutuelle dès lors qu’au moins une clef cryptographique soit échangée entre le terminal de paiement 1 et dispositif de paiement 3.
[0079] Dans ce deuxième exemple, le terminal de paiement 1 envoie une requête 610 de vérification de l’information personnelle PI au dispositif de paiement 3 indiquant une condition à vérifier vis-à-vis de l’information personnelle PI pour appliquer la politique de transaction Pol(PI). Au cours d’une étape 620, le dispositif de paiement 3 vérifie que l’information personnelle PI correspond à la condition envoyée dans la requête 610. Le dispositif de paiement 3 renvoie une réponse 630 au terminal de paiement 1 contenant le résultat de la vérification. Le terminal de paiement 1 applique ensuite la politique de transaction Pol(PI) en fonction du résultat de la vérification préalablement ou au cours de l’étape de transaction 501. Ainsi, l’information personnelle PI peut rester confidentielle car la seule information donnée est que l’information personnelle PI satisfait la condition de la politique de transaction.
[0080] La requête 610 de vérification peut être envoyé à l’aide d’une APDU de type VERIFY qui dispose d’un certain nombre de champs de données qui spécifient l’information personnelle PI à vérifier et la condition de la politique de transaction Pol(PI). En outre, afin de garantir une confidentialité des données personnelles, la requête 610 peut comporter également une signature réalisée à l’aide d’une clef cryptographique partagée par le terminal de paiement 1 et le dispositif de paiement 3. La signature est réalisée par exemple sur la totalité des bits de la requête qui correspondent à la condition. La condition peut comporter une valeur et une relation entre la valeur et l’information personnelle PI. A titre d’exemple, pour une information personnelle PI correspondant à un âge ou une date de naissance, la valeur peut être l’âge ou la date de naissance limite et la relation peut être une comparaison à cet âge ou date de naissance du type « inférieur » ou « supérieur ». Si l’information personnelle est un lieu de résidence, par exemple un pays, un code postal ou une adresse, la relation peut être du type « égal » ou « différent ».
[0081] A la réception de la requête 610, le dispositif de paiement 3 met en œuvre un sous-programme de vérification au cours de l’étape 620. Ainsi le dispositif de paiement contrôle que la signature de la requête 610 est conforme à la condition demandée. Cette première vérification permet de s’assurer que la requête est bien émise par le terminal de paiement 1 qui est considéré comme un dispositif autorisé à faire une telle vérification. Une fois la vérification de la requête effectuée avec succès, le microprocesseur 31 du dispositif de paiement 3 lit dans sa mémoire 33 l’information personnelle PI spécifiée dans la requête 610. Puis, le dispositif de paiement 3 effectuer la comparaison demandée de l’information personnelle PI avec la valeur indiquée. La comparaison effectuée, le dispositif de paiement va ensuite préparer et renvoyer une réponse 630 correspondant au résultat de ladite comparaison. Le résultat est de type binaire à savoir la condition est vérifiée ou la condition n’est pas vérifiée et la réponse 630 peut correspondre à un message de réponse à la commande VERIFY validant ou invalidant la comparaison effectuée de manière sécurisée. De manière optionnelle la réponse peut également être signée à l’aide de la clef cryptographique. Le terminal de paiement 1 applique ensuite la politique de transaction Pol(PI) en fonction du résultat de la vérification, préalablement ou au cours de l’étape de transaction 501.
[0082] L’homme du métier peut remarquer que le deuxième exemple de mise en œuvre de l’invention permet en outre de conserver l’information personnelle PI dans le dispositif de paiement. Cela permet de garder confidentiel l’information personnelle PI qui peut être une information sensible, tel que par exemple l’adresse du titulaire.
[0083] Dans d’autres modes de réalisation, plusieurs informations personnelles peuvent être présentes dans le dispositif de paiement 3 et plusieurs politiques de transaction Pol(PI) peuvent être utilisées lors d’une même transaction. Selon un mode particulier de mise en œuvre, il est possible de répéter les étapes 510 à 530 ou 610 à 630 autant de fois qu’il est nécessaire. Selon un autre exemple de mise en œuvre, il est possible d’utiliser des commandes plus complexes adressant plusieurs informations personnelles et/ou plusieurs conditions de manière simultanée.
[0084] Dans les exemples des figures 5 et 6, les APDU utilisées doivent être définies aussi bien dans le dispositif de paiement 3 que dans le terminal de paiement 1. A cet effet, l’homme du métier comprendra qu’il est nécessaire de codifier et normaliser de telles fonctionnalités pour pouvoir les utiliser.
[0085] Selon une variante, il est possible de ne pas utiliser d’interfaces de communication conforme aux normes IS07816 ou IS014443. C’est notamment le cas lorsque le dispositif de paiement correspond au téléphone portable 4.
Dans ce cas, la transaction peut se faire en utilisant un protocole de communication radiofréquence, par exemple conforme à la norme IEEE 802.11 plus connue sous le nom de Wifi. La sécurisation de la transaction peut se faire en utilisant, par exemple, un canal encrypté en utilisant un procédé de transaction similaire à celui décrit précédemment. Les exemples de réalisation décrit à l’aide des figures 5 et 6 peuvent s’appliquer de manière similaire tout en prenant en compte que les messages échangés entre le terminal de paiement 1 et le téléphone portable 4 seront fait selon un autre protocole d’échange de données qui n’utilise pas nécessairement des APDU.
[0086] Quel que soit le mode de réalisation mis en œuvre, l’utilisation d’une certification de l’information personnelle PI permet de garantir au niveau de la transaction que l’information est authentique. A cet effet, l’information personnelle PI est mémorisée dans le dispositif de paiement 3 par un tiers autorisé, tel que par exemple un établissement bancaire, et la certification effectuée par le dispositif de paiement vaut certification par le tiers autorisé.

Claims

Revendications
[Revendication 1] procédé de transaction électronique entre un dispositif de paiement (3, 4) associé à un compte bancaire d’un utilisateur et un terminal de paiement (1) associé à un compte bancaire acquéreur dans lequel le dispositif de paiement (3, 4) et le terminal de paiement (1) réalisent au moins un échange de clef cryptographique (500) avant de réaliser une étape de transaction (501) au cours de laquelle la transaction est validée ou rejetée, caractérisé en ce que :
- le dispositif de paiement comporte au moins une information personnelle (PI) relative à l’utilisateur ;
- le terminal de paiement comporte au moins une politique de transaction (Pol(PI)) comportant une condition relative à l’au moins une information personnelle (PI) ; et en ce que le procédé comporte une étape de vérification (510, 520, 530, 610, 620, 630), préalablement à l’étape de transaction (501), pour vérifier la condition de la politique de transaction relative à l’information personnelle de manière sécurisée en utilisant la clef cryptographique.
[Revendication 2] Procédé selon la revendication 1 pour lequel, l’étape de vérification consiste en que le dispositif de paiement (3, 4) envoie (520) l’information personnelle accompagnée d’une signature cryptographique (Sig(PI)) réalisée à l’aide de l’information personnelle et de la clef cryptographique afin d’authentifier l’information personnelle et en ce que le terminal de paiement (1) vérifie (530) la condition de la politique de transaction après avoir authentifier l’information personnelle.
[Revendication 3] Procédé selon la revendication 2 pour lequel, préalablement à l’envoi (520) de l’information personnelle (PI), le terminal de paiement (1) envoie (510) une requête au dispositif de paiement pour provoquer l’envoi de l’information personnelle (PI) par ce dernier.
[Revendication 4] Procédé selon la revendication 1 pour lequel, l’étape de vérification consiste en ce que le terminal de paiement (1) envoie (610) une requête de vérification de la politique de transaction (Pol(PI)) au dispositif de paiement (3, 4) la requête étant signée à l’aide de la clef cryptographique, et en ce que la vérification (620) de la condition de la politique de transaction est réalisée par le dispositif de paiement (3, 4), après avoir authentifier la requête à l’aide de la clef cryptographique, qui élabore et transmet (630) un message de validation ou d’invalidation au terminal de paiement en fonction de la condition et de l’information personnelle (PI).
[Revendication 5] Procédé selon l’une des revendications 1 à 4, dans lequel le montant de la transaction est modifié par le terminal de paiement en fonction du résultat de l’étape de vérification.
[Revendication 6] Procédé selon l’une des revendications 1 à 5, dans lequel l’échange de clef cryptographique est réalisé lors d’une étape d’authentification mutuelle.
[Revendication 7] Procédé de transaction électronique mis en œuvre par un microprocesseur d’un dispositif de paiement (3, 4) associé à un compte bancaire d’un utilisateur destiné à coopérer avec un terminal de paiement (1) associé à un compte bancaire acquéreur afin de réaliser une étape de transaction (501) au cours de laquelle la transaction est validée ou rejetée, ledit procédé comportant une étape pour échanger avec le terminal de paiement (1) au moins une clef cryptographique (500), caractérisée en ce que le dispositif de paiement comporte au moins une information personnelle (PI) relative à l’utilisateur enregistrée dans une mémoire de données, et en ce que le procédé comporte une étape de vérification (510, 520, 530, 610, 620, 630) d’une condition d’une politique de transaction relative à l’information personnelle est vérifiée de manière sécurisée en utilisant la clef cryptographique.
[Revendication 8] Procédé selon la revendication 7 pour lequel, l’étape de vérification comporte l’envoi (520) d’un message contenant l’information personnelle accompagnée d’une signature cryptographique (Sig(PI)) réalisée à l’aide de l’information personnelle et de la clef cryptographique afin d’authentifier ladite information personnelle.
[Revendication 9] Procédé selon la revendication 7 pour lequel, l’étape de vérification (620) de la condition de la politique de transaction comporte une étape préalable pour authentifier une requête émise par le terminal de paiement (1) contenant la condition de la politique de transaction, la requête étant signée à l’aide de la clef cryptographique, et une étape d’envoi (630) d’un message de validation ou d’invalidation en fonction de la condition et de l’information personnelle (PI).
[Revendication 10] Procédé de transaction électronique mis en œuvre par un microprocesseur d’un terminal de paiement (1), associé à un compte bancaire acquéreur, destiné à coopérer avec un dispositif de paiement (3, 4) associé à un compte bancaire d’un utilisateur, ledit procédé comportant une étape pour échanger au moins une clef cryptographique (500) avec le dispositif de paiement (3, 4), une étape de transaction (501) au cours de laquelle la transaction est validée ou rejetée, caractérisée en ce que le terminal de paiement comporte au moins une politique de transaction (Pol(PI)) comportant une condition relative à au moins une information personnelle (PI) relative à l’utilisateur du dispositif de paiement, en ce que le procédé comporte une étape de vérification (510, 520, 530, 610, 620, 630) pour requérir la vérification de la condition de la politique de transaction relative à l’information personnelle en utilisant la clef cryptographique, et en ce que l’étape de transaction est mise en œuvre si et seulement si la condition est vérifiée.
[Revendication 11] Procédé selon la revendication 10 dans lequel, au cours de l’étape de vérification, le procédé comporte une étape pour recevoir (520) un message incluant l’information personnelle accompagnée d’une signature cryptographique (Sig(PI)) réalisée à l’aide de l’information personnelle et de la clef cryptographique et une étape pour vérifier (530) la condition de la politique de transaction après avoir authentifié l’information personnelle à l’aide de la clef cryptographique.
[Revendication 12] Procédé selon la revendication 10 ou 11 , le procédé comportant une étape pour élaborer et transmettre (510) une requête au dispositif de paiement afin d’obtenir l’information personnelle (PI).
[Revendication 13] Procédé selon la revendication 10 dans lequel, l’étape de vérification consiste à élaborer et transmettre (610) une requête de vérification de la politique de transaction (Pol(PI)) au dispositif de paiement (3, 4), la requête étant signée à l’aide de la clef cryptographique.
[Revendication 14] Procédé selon l’une des revendications 10 à 13, le procédé comportant une étape pour modifier le montant de la transaction en fonction du résultat de la vérification de la condition préalablement à la validation de la transaction.
[Revendication 15] Système de transaction électronique comprenant un dispositif de paiement (3, 4) associé à un compte bancaire d’un utilisateur et terminal de paiement (1 ) associé à un compte bancaire acquéreur dans lequel le dispositif de paiement (3, 4) et le terminal de paiement (1) sont configurés pour réaliser un échange d’au moins une clef cryptographique (500) avant de réaliser une étape de transaction (501) au cours de laquelle la transaction est validée ou rejetée, caractérisée en ce que le dispositif de paiement (3,4) comporte au moins une information personnelle (PI) relative à l’utilisateur et le terminal de paiement (1) comporte au moins une politique de transaction (Pol(PI)) comportant une condition relative à l’au moins une information personnelle (PI), et en ce que le dispositif et le terminal de paiement sont configurés pour réaliser une étape de vérification (510, 520, 530, 610, 620, 630) entre l’étape d’échange de clef cryptographique (500) et l’étape de transaction (501) au cours de laquelle la condition de la politique de transaction (Pol(PI)) relative à l’information personnelle (PI) est vérifiée de manière sécurisée à l’aide de la clef cryptographique.
[Revendication 16] Système selon la revendication 15, dans lequel le dispositif de paiement (3, 4) est configuré pour transmettre au terminal de paiement (520) un message contenant l’information personnelle (PI) signé (Sig(PI)) à l’aide de l’information personnelle et de la clef cryptographique afin d’authentifier l’information personnelle (PI) et dans lequel le terminal de paiement (1) est configuré pour vérifier (530) la condition après avoir authentifier l’information personnelle à l’aide de la clef cryptographique.
[Revendication 17] Système selon la revendication 16, dans lequel le terminal de paiement est configuré pour élaborer et transmettre (510) une requête au dispositif de paiement afin d’obtenir l’information personnelle.
[Revendication 18] Système selon la revendication 15, dans lequel le terminal de paiement (1) est configuré pour élaborer et transmettre (610) au dispositif de paiement (3, 4) une requête de vérification de la condition de la politique de transaction (Pol(PI)) signée à l’aide de la clef cryptographique et dans lequel le dispositif de paiement (3, 4) est configuré pour authentifier ladite requête à l’aide de la clef cryptographique avant de vérifier (620) la condition en réponse à la requête de vérification et pour renvoyer (630) un message de validation ou d’invalidation au terminal de paiement (1) en fonction de la condition et de l’information personnelle.
[Revendication 19] Système selon l’une des revendications 15 à 18, dans lequel le terminal de paiement (1) est configuré pour modifier le montant de la transaction en fonction du résultat de l’étape de vérification.
[Revendication 20] Dispositif de paiement (3, 4) associé à un compte bancaire d’un utilisateur destiné à coopérer avec un terminal de paiement (1) pour réaliser une transaction électronique, ledit dispositif de paiement (3, 4) étant configuré pour échanger au moins une clef cryptographique (500) avec le terminal de paiement (1), caractérisée en ce que le dispositif de paiement (3, 4) comporte au moins une information personnelle (PI) relative à l’utilisateur, et en ce que le dispositif de paiement (3,4) est configuré pour réaliser une étape de vérification (510, 520, 530, 610, 620, 630) d’une condition d’une politique de transaction (Pol(PI)) relative à l’information personnelle (PI) de manière sécurisée à l’aide de la clef cryptographique.
[Revendication 21] Dispositif selon la revendication 11 , dans lequel le dispositif de paiement (3,4) est configuré pour envoyer au terminal de paiement (1) l’information personnelle (PI) dans un message signé (Sig(PI)) à l’aide de l’information personnelle (PI) et de la clef cryptographique afin d’authentifier l’information personnelle.
[Revendication 22] Dispositif selon la revendication 20, dans lequel le dispositif de paiement est configuré pour vérifier (620) la condition de la politique de transaction (Pol(PI)) en réponse à la réception d’une requête de vérification contenant la condition, ladite requête étant signée et transmise par le terminal de paiement (1) à l’aide de la clef cryptographique, et pour élaborer et transmettre (630) un message de validation ou d’invalidation au terminal de paiement (1) en fonction de la condition et de l’information personnelle.
[Revendication 23] Dispositif selon l’une des revendications 20 à 22, dans lequel le dispositif de paiement (3,4) est un dispositif compris dans la liste suivante : carte à puce conforme à la norme IS07816 et/ou à la norme 14443, téléphone portable ou tablette comprenant une capacité de paiement sécurisé, montre intelligente comprenant des fonctionnalités de paiement, ordinateur sécurisé comprenant une interface de communication avec ou sans contact et comprenant une capacité de paiement sécurisé.
[Revendication 24] Terminal de paiement (1) associé à un compte bancaire acquéreur destiné à coopérer avec un dispositif de paiement (3,4) associé à un compte bancaire d’un utilisateur pour réaliser une transaction électronique dans lequel le terminal de paiement (1 ) est configuré pour échanger au moins une clef cryptographique (500) avec le dispositif de paiement avant de mettre en œuvre une étape de transaction (501) au cours de laquelle la transaction est validée ou rejetée, caractérisée en ce que le terminal de paiement (1) comporte au moins une politique de transaction (Pol(PI)) comprenant une condition relative à au moins une information personnelle (PI) enregistrée dans une mémoire du dispositif de paiement, ladite information personnelle (PI) étant relative à l’utilisateur, et en ce que le terminal de paiement (1) est configuré pour mettre en œuvre une étape de vérification (510, 520, 530, 610, 620, 630), avant l’étape de transaction (501), au cours de laquelle la condition de la politique de transaction relative à l’information personnelle est vérifiée de manière sécurisée à l’aide de la clef cryptographique.
[Revendication 25] Terminal selon la revendication 24, dans lequel le terminal de paiement (1) est configuré pour recevoir un message contenant l’information personnelle (PI) signé (Sig(PI)) à l’aide de l’information personnelle et de la clef cryptographique par le dispositif de paiement et dans lequel le terminal de paiement (1) est configuré pour vérifier (530) la condition après avoir authentifier l’information personnelle à l’aide de la clef cryptographique.
[Revendication 26] Terminal selon la revendication 25, dans lequel le terminal de paiement (1) est configuré pour élaborer et transmettre (510) une requête au dispositif de paiement (3, 4) afin d’obtenir l’information personnelle (PI).
[Revendication 27] Terminal selon la revendication 24, dans lequel le terminal de paiement (1) est configuré pour élaborer et transmettre (610) au dispositif de paiement (3, 4) une requête de vérification de la condition de la politique de transaction (Pol(PI)) signée à l’aide de la clef cryptographique, et dans lequel le terminal de paiement (1 ) est configuré pour terminer la transaction suite à un message de validation ou d’invalidation renvoyé par le dispositif de paiement en fonction de la condition et de l’information personnelle.
[Revendication 28] Terminal selon l’une des revendications 24 à 27, dans lequel le terminal de paiement (1) est configuré pour modifier le montant de la transaction en fonction du résultat de l’étape de vérification.
[Revendication 29] Terminal selon l’une des revendications 24 à 28, dans lequel ledit terminal de paiement (1) est compris dans la liste de dispositifs suivante : terminal de point de vente pour carte à puce, téléphone portable ou tablette comprenant une capacité d’enregistrement de paiement sécurisé, caisse enregistreuse comprenant une capacité d’enregistrement de paiement sécurisé.
EP20845184.9A 2019-12-13 2020-12-11 Procede et systeme, dispositif et terminal de paiement utilisant des donnees personnelles Pending EP4074004A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1914352A FR3104779B1 (fr) 2019-12-13 2019-12-13 Procede et systeme, dispositif et terminal de paiement utilisant des donnees personnelles
PCT/FR2020/052395 WO2021116625A1 (fr) 2019-12-13 2020-12-11 Procede et systeme, dispositif et terminal de paiement utilisant des donnees personnelles

Publications (1)

Publication Number Publication Date
EP4074004A1 true EP4074004A1 (fr) 2022-10-19

Family

ID=70456862

Family Applications (1)

Application Number Title Priority Date Filing Date
EP20845184.9A Pending EP4074004A1 (fr) 2019-12-13 2020-12-11 Procede et systeme, dispositif et terminal de paiement utilisant des donnees personnelles

Country Status (5)

Country Link
US (1) US20230004965A1 (fr)
EP (1) EP4074004A1 (fr)
CA (1) CA3161315A1 (fr)
FR (1) FR3104779B1 (fr)
WO (1) WO2021116625A1 (fr)

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008096273A2 (fr) * 2007-02-09 2008-08-14 Business Intelligent Processing Systems, Plc Système et procédé de réalisation de transactions de paiement, de vérification de l'âge, de vérification de l'identité et de gestion des taxes
US20130185206A1 (en) * 2012-01-16 2013-07-18 International Business Machines Corporation Real-Time System for Approving Purchases Made with a Mobile Phone
FR3012645A1 (fr) * 2013-10-24 2015-05-01 Orange Procede d'execution d'une transaction entre un premier terminal et un deuxieme terminal
US10699274B2 (en) * 2015-08-24 2020-06-30 Samsung Electronics Co., Ltd. Apparatus and method for secure electronic payment
US20180005235A1 (en) * 2016-06-29 2018-01-04 Ca, Inc. Electronic transaction risk assessment based on digital identifier trust evaluation

Also Published As

Publication number Publication date
CA3161315A1 (fr) 2021-06-17
FR3104779A1 (fr) 2021-06-18
WO2021116625A1 (fr) 2021-06-17
FR3104779B1 (fr) 2024-03-29
US20230004965A1 (en) 2023-01-05

Similar Documents

Publication Publication Date Title
EP2455922B1 (fr) Procédé et système de transaction NFC
EP1014317B1 (fr) Procédé de paiement sécurisé
EP0818763B1 (fr) Procédé de contrôle de transactions sécurisées independantes utilisant un dispositif physique unique
US20130041831A1 (en) Secure and shareable payment system using trusted personal device
US20150056957A1 (en) Biometric authentication of mobile financial transactions by trusted service managers
WO2014009646A1 (fr) Entite electronique securisee pour l'autorisation d'une transaction
FR2964285A1 (fr) Protection d'un canal de communication d'un dispositif de telecommunication couple a un circuit nfc contre un deroutement
CN106296174A (zh) 一种基于hce技术的小额支付卡装置及其实现方法
CA2946143A1 (fr) Procede de traitement de donnees transactionnelles, dispositif et programme correspondant
FR2757661A1 (fr) Procede de transfert securise de donnees par un reseau de communication
FR2923635A1 (fr) Systeme pour des transactions de commerce electronique, dispositif electronique portatif, reseau de communication, produit programme d'ordinateur et methode correspondants.
EP3479518A1 (fr) Procede d'authentification de donnees de paiement, dispositifs et programmes correspondants
EP4074004A1 (fr) Procede et systeme, dispositif et terminal de paiement utilisant des donnees personnelles
EP1323140B1 (fr) Procede pour fournir des donnees d'identification d'une carte de paiement a un usager
EP2824625B1 (fr) Méthode de réalisation de transaction, terminal et programme d'ordinateur correspondant
EP1354288B1 (fr) Procede utilisant les cartes de paiement electroniques pour securiser les transactions
EP3291188B1 (fr) Procédé de contrôle d'un dispositif électronique et dispositif électronique correspondant
WO2020128240A1 (fr) Traitement d'un service de tickets electroniques
KR20060127215A (ko) 컨텐츠에 대한 전자 지불
FR2927454A1 (fr) Procede de detection de cartes a microprocesseur non authentiques, carte a microprocesseur, terminal lecteur de carte et programmes correspondants
EP3358493A1 (fr) Procédé pour la sécurité d'une opération électronique
CA2325895C (fr) Procede de paiement securise
CA2946145A1 (fr) Procedes de traitement de donnees transactionnelles, dispositifs et programmes correspondants
EP0979495A1 (fr) Procede de certification d'un cumul dans un lecteur
FR2967513A1 (fr) Serveur de transaction nfc

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: 20220706

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

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)