EP4348459A1 - Procédé de traitement d'une transaction, dispositif et programme correspondant - Google Patents

Procédé de traitement d'une transaction, dispositif et programme correspondant

Info

Publication number
EP4348459A1
EP4348459A1 EP22734521.2A EP22734521A EP4348459A1 EP 4348459 A1 EP4348459 A1 EP 4348459A1 EP 22734521 A EP22734521 A EP 22734521A EP 4348459 A1 EP4348459 A1 EP 4348459A1
Authority
EP
European Patent Office
Prior art keywords
transaction
user
dton
communication device
terminal
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP22734521.2A
Other languages
German (de)
English (en)
Inventor
Pierre Quentin
Arnaud DUBREUIL
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 EP4348459A1 publication Critical patent/EP4348459A1/fr
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security

Definitions

  • the invention relates to the field of securing computer processing.
  • the field of the invention relates more specifically to the securing of processing carried out at least in part by means of two separate computer devices, respectively owned by two equally separate entities.
  • the invention aims more particularly to secure the implementation of a processing of confidential data, for example during a transaction carried out between a device initiating the transaction and a device for executing, at least partially, the transaction.
  • the transactions referred to herein may be of various types, such as electronic signatures, access validations, payment transactions, data validation transactions.
  • a transaction when a transaction must be carried out for a beneficiary (i.e. merchant, notary, etc.), who is often a professional, this beneficiary requires the use, by a person (often a natural person), of a dedicated terminal to the deal.
  • This terminal is used by the person to confirm the transaction that is carried out, for example by affixing a signature to this terminal or by entering a secret code, and this, often, after the insertion, in this dedicated terminal, of a transaction device owned by the user (payment card, access card).
  • the document US10147094B2 pursues the objective of proposing a payment method based on the connectivity of a communication network to which a communication terminal of a user is connected, to allow this user to validate a transaction by entering a code personal identification associated with his communication terminal.
  • the problem with this method is that it does not allow the use of a means of payment (eg credit card) to carry out the transaction with the professional (eg the merchant).
  • the document US10127532B1 for its part, describes a method of carrying out a payment transaction in which the user's communication terminal is used to detect a payment intention and to implement the transaction.
  • this method of transaction completion is based solely on the user's ability to want to initiate a payment transaction.
  • the present disclosure relates to a method of executing a transaction between a professional's transaction implementation terminal and a user communication device which is located near the transaction implementation terminal.
  • professional transaction comprises a step of preparing the transaction to be executed within the professional's transaction implementation terminal, delivering at least one intermediate transaction execution datum; a step of transmitting said at least one intermediate transaction execution datum to the user communication device; and a step of executing the transaction by the user communication device using said at least one intermediate transaction execution datum and at least one personal datum of the user who holds the user communication, said execution delivering an execution result transmitted to the transaction implementation terminal of a professional.
  • the professional is able to verify, during the construction, implementation and execution of the transaction, that the user has the capacity to and the means to complete this transaction.
  • the user is able to ensure that the professional's terminal does not come into possession of personal information, in particular for example digitized signatures or passwords or confidential codes.
  • the step of executing the transaction by the user communication device using said at least one intermediate transaction execution datum and at least one personal datum of the user which holds the user communication device comprises a step of obtaining, by the user communication device, at least one datum originating from an additional transactional device in the possession of the user.
  • the user is able to use his payment card directly on his communication terminal, in front of the merchant, who is able to verify that his customer is making a payment using this payment card.
  • the step of obtaining, by the user communication device, said at least one datum coming from the additional transactional device in the possession of the user comprises: a step of sending, by the device for user communication, of a request for obtaining transactional data, said transmitting step using a near-field communication interface of the user communication device; a step of reception, by the user communication device, of a response to said request for obtaining transactional data via the near-field communication interface of the user communication device.
  • the user's communication terminal plays an active role in the implementation of the transaction, by itself requesting the transactional data.
  • the step of executing the transaction by the user communication device using said at least one intermediate transaction execution datum and at least one personal datum of the user which holds the user communication device comprises: a step of receiving said at least one intermediate transaction execution datum by the user communication device; a step of dynamic configuration of the user communication device, as a function of said at least one intermediate execution datum, said step of dynamic configuration step comprising a step of execution, within a dedicated memory space of said device user communication, a validation application for the entering said at least one personal datum of the user who owns the user communication device; a step of reception, by the validation application, of at least one datum entered by said user; a validation step, by the validation application, of the transaction according to said at least one datum entered by said user and said intermediate data, delivering a validation result.
  • the user is able to enter the PIN code of his bank card, directly on his communication terminal.
  • the method comprises: a step of transmitting said data intermediates and said validation result, to a transactional server to which the user communication device is connected via the validation application, a step of validation, by the transactional server, of said intermediate data and of said validation result , comprising a verification of the validation cryptographic operations carried out by said validation application; a step of transmitting, to the transaction implementation terminal of a professional, said transaction validation result, when verification of the validation cryptographic operations delivers a positive result.
  • the transaction is processed in complete security, for example via the banking server corresponding to the user's bank or that of the merchant, and this transaction can be processed immediately, without delay.
  • the step of preparing the transaction to be executed within the professional's transaction implementation terminal comprises: a step of obtaining, from an additional transactional device in the possession of the user, at least one encryption key intended to be transmitted to the user communication device; and a step of inserting, within said at least one intermediate execution datum, said at least one encryption key obtained.
  • the user can also choose to insert his bank card into the merchant's payment terminal, when possible. The entry of the pin code of the bank card is still carried out on the user's communication terminal from data from his bank card, transmitted from the merchant's payment terminal, which is technically reassuring for the trader.
  • the step of transmitting said at least one intermediate transaction execution datum to the user communication device comprises: a step of activating a communication interface of the transaction implementation terminal d a professional, for transmission via a main channel; a step of transmitting, via the communication interface, a file comprising said at least one intermediate datum.
  • the communication interface activated for the transmission of the file comprising said at least one intermediate datum belongs to the group comprising: a sound interface, configured to transmit the file previously encoded in the form of an ultrasonic signal; a screen of a professional's transaction implementation terminal, configured to display the file previously encoded in the form of a two-dimensional code; a data transmission interface via a communication network, configured to transmit the previously encoded file in the form of a message.
  • the invention also relates to a system for executing a transaction, the system comprising a transaction implementation terminal of a professional and a user communication device which is located close to the professional's transaction implementation terminal.
  • Such a system comprises means for preparing the transaction to be executed implemented within the professional's transaction implementation terminal, delivering at least one intermediate transaction execution datum; means for transmitting said at least one intermediate transaction execution datum to the user communication device; and means for executing the transaction implemented within the user communication device using said at least one intermediate transaction execution datum and at least one personal datum of the user who holds the user communication device, said execution delivering an execution result and means for transmitting the execution result to the transaction implementation terminal of a professional.
  • the various steps of the methods according to the invention are implemented by one or more software or computer programs, comprising software instructions intended to be executed by a data processor of an execution device according to the invention and being designed to control the execution of the various steps of the methods, implemented at the level of a communication terminal, of an electronic execution device and/or of a control device, within the framework a distribution of the processing to be performed and determined by a scripted source code and/or a compiled code.
  • the invention also relates to programs capable of being executed by a computer or by a data processor, these programs comprising instructions for controlling the execution of the steps of the methods as mentioned above.
  • a program may use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in partially compiled form, or in any other desirable form.
  • the invention also relates to an information medium readable by a data processor, and comprising instructions of a program as mentioned above.
  • the information carrier can be any entity or device capable of storing the program.
  • the medium may include a storage medium, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or else a magnetic recording medium, for example a mobile medium (memory card) or a hard drive or SSD.
  • the information medium can be a transmissible medium such as an electrical or optical signal, which can be conveyed via an electrical or optical cable, by radio or by other means.
  • the program according to the invention can in particular be downloaded from an Internet-type network.
  • the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question.
  • the invention is implemented by means of software and/or hardware components.
  • module may correspond in this document both to a software component, to a hardware component or to a set of hardware and software components.
  • a software component corresponds to one or more computer programs, one or more sub-programs of a program, or more generally to any element of a program or software capable of implementing a function or a set of functions, as described below for the module concerned.
  • Such a software component is executed by a data processor of a physical entity (terminal, server, gateway, set-top-box, router, etc.) and is likely to access the hardware resources of this physical entity (memories, recording media, communication bus, electronic input/output cards, user interfaces, etc.).
  • a hardware component corresponds to any element of a hardware assembly (or hardware) able to implement a function or a set of functions, according to what is described below for the module concerned. It can be a hardware component that can be programmed or has an integrated processor for executing software, for example an integrated circuit, a smart card, a memory card, an electronic card for executing firmware ( firmware), etc
  • FIG. 1 depicts a system in which the disclosure can be implemented
  • FIG. 1 [fig 2] figure 2 describes the general principle of the method that is the subject of the disclosure
  • FIG. 3 illustrates an architecture of a professional electronic terminal capable of implementing a method that is the subject of the disclosure.
  • the disclosure describes a method consisting in requiring, from a communication device of a user, the at least partial implementation of a transaction which must be carried out on behalf of an initiator (he can be a merchant, a notary, a delivery person, an access validation device, etc.), which has or implements a user communication device (payment device, signature, access control terminal, etc.), considered for various reasons as involving a security issue.
  • an initiator here can be a merchant, a notary, a delivery person, an access validation device, etc.
  • a user communication device (payment device, signature, access control terminal, etc.)
  • a transaction execution dissociation technique is proposed: the transaction is initialized on a terminal of a professional and is completed (executed, finalized) on a terminal of a user, so that the latter ci can securely enter the confidential data used to validate this transaction.
  • the method consists of using a communication terminal of the user (typically his smartphone or tablet type mobile communication terminal) to execute a portion of the transaction initiated by the professional's terminal.
  • the professional's terminal transmits specific data to the user's terminal, allowing the user terminal to continue the execution of the transaction.
  • This continuation of the execution of the transaction can consist of a validation of the latter (for example by performing a signature operation and/or one or more cryptographic operations), or even in a verification of the validation of confidential data.
  • the main problem in the proposed protocol modification consists in particular of: ensuring the security of the data exchanged (in order to avoid their interception); to ensure the non-repudiation of the data exchanged (in order to avoid any unwanted modification, both on the side of the professional's terminal and on the user's terminal). Indeed, it is essential that the protocol modification does not induce a security breach allowing the transaction to be modified.
  • FIG. 1 describes a system in which the proposed technique can be implemented.
  • a system SystET
  • TProf professional's terminal
  • TProf terminal
  • DTon user communication device
  • DTon user communication device
  • This system may also include, depending on the embodiment, a transactional server (ServT).
  • ServT transactional server
  • the transactional server is in this case at least accessible via a communication network for the professional terminal (TProf) and/or the user communication device (DTon).
  • the system also comprises an additional transactional device (DTa) (access card, credit card) in particular when the implementation of the transaction requires the use of such an additional transactional device (transaction to access premises, payment transaction by bank card, credit card).
  • DTa additional transactional device
  • the method for performing a transaction comprises: a step for preparing (A10) the transaction, implemented within the professional's terminal (TProf); this transaction preparation step includes, in particular, obtaining a (unique) identifier for the professional's terminal; this unique identifier serves as the basis for initializing the transaction (it is stored/obtained within the professional's terminal (TProf), or transmitted to the professional's terminal (TProf) via the transactional server (ServT)); this step of preparing the transaction can also include obtaining data from an additional transactional device (DTa) when such a device is necessary for carrying out the transaction (this step of obtaining data includes for example inserting a card in the user's possession into the professional's terminal or obtaining contactless data between this card in the user's possession and the professional's terminal); the preparation of the transaction may also include the generation of a unique (pre)transaction identifier, making it possible to trace and locate it; the set ⁇ “(unique)
  • the user communication device (DTon) of the user communicates (A40) this validation information (InfoVal) to the professional's terminal (TProf), either directly, by transmitting validation data in direction to it, or indirectly, via the transactional server (ServT) which then communicates the validation data to the professional's terminal.
  • TProf professional's terminal
  • validation includes a step of transmitting intermediate data and the validation result to the transactional server to which the user communication device (Dton) is connected via the validation application (AppVT), then a step of validation, by the transactional server, of the intermediate data and of the validation result, comprising a verification of the cryptographic validation operations carried out by said validation (AppVT) and a step of transmitting, to a professional's transaction implementation terminal (TProf), the transaction validation result, when verification of the validation cryptographic operations delivers a positive result.
  • AppVT validation application
  • TProf professional's transaction implementation terminal
  • a professional electronic terminal comprises a first electronic module comprising a memory 31, a processing unit 32 equipped for example with a microprocessor, and controlled by a computer program 33.
  • the professional electronic terminal can also comprise a second electronic module comprising a secure memory 34, which can be merged with the memory 31 (as indicated in dotted lines, in this case the memory 31 is a secure memory), a secure processing unit 35 equipped for example with a secure microprocessor and physical measurement protection (physical protection around the chip, by trellis, vias, etc.
  • the present technique is implemented in the form of a set of programs installed in part or in whole on this secure portion of the transaction processing or initialization terminal.
  • the present technique is implemented in the form of a dedicated component (CpX) capable of processing data from the processing units and installed in part or in whole on the secure portion of the electronic terminal of professional.
  • CpX dedicated component
  • the professional electronic terminal also comprises means of communication (CIE) for example in the form of network components (WiFi, 3G/4G/5G, wired) which allow the professional electronic terminal to receive data ( I) from entities connected to one or more communication networks and to transmit processed data (T) to such entities.
  • CIE means of communication
  • Such a professional electronic terminal comprises, depending on the embodiments: means for obtaining data from transactional devices presented to users (access card, transaction card, etc.; these means may be presented, for example, in the form of a smart card reader, or even contactless card readers of the NFC type or of the RFID type); input means, allowing the professional to input one or more data for the implementation of the transaction, when necessary (physical input keyboard, screen, virtual input keyboard); means for processing the data obtained by the means for obtaining data from the transactional devices and means for processing the data entered by the professional; these means are materialized for example in the form of a specific component; means for processing a transaction, comprising means for initializing the transaction; means for supplying data to one or more transactional servers connected to the electronic professional terminal: these means are typically in the form of network communication interfaces, of the wired interface type (RTC, Ethernet) or wireless interface (3G/ 4G, Wi-Fi); means for supplying data to a device for implementing a transaction, belonging to a user (eg smartphone, tablet): these means
  • these means are implemented by means of modules and/or components, for example, but not necessarily secured. They thus make it possible to ensure the security of the transactions carried out while guaranteeing greater maintainability of the device.
  • the user communication device for its part, is generally presented as a mobile-type communication terminal (ie smartphone, tablet) which is in the possession of the user at the time of carrying out the transaction in the presence of the professional.
  • Such device comprises, in addition to the usual means, means for implementing a transaction, according to the method previously described.
  • These means are in the form of an application executed on the terminal, giving it the quality of user communication device (DTon).
  • this application is an application configured dynamically on the user's terminal. More particularly, this application is configured dynamically upon receipt, on the transaction implementation device, of intermediate data comprising the unique identifier of the professional's terminal and the unique (pre)transaction identifier and; when necessary, instantiation data. Upon receipt of this data, the application is dynamically configured and executed. It displays, for the user, the data relating to the transaction (such as for example an identifier or a name of the professional concerned or other as described in the following embodiments).
  • Example of embodiment 1 delivery of a package by a deliverer
  • the execution of a separate transaction in the context of a delivery of a parcel made by a deliverer (professional) to an individual (user) is described.
  • the deliverer is equipped with an electronic delivery terminal (this is the professional's terminal).
  • the administrative steps i.e. verification of the user's identity by the delivery person, in particular, inspection of the state of the package by the user
  • the dissociated transaction processing process is implemented, according to the steps previously described in relation to Figure 2.
  • the preparation of the transaction by the terminal of the professional comprises obtaining the identifier of the terminal within a memory of this terminal of the professional and the preparation, by the processor processing, a transaction identifier;
  • data representative of a location address (on the communication network or in an application store) of an instant application to be instantiated on the user's communication device (ie the mobile terminal or the tablet) of the user is obtained, for example within the memory of the professional's terminal, forming the set of intermediate data;
  • a step for protecting at least some of these data is implemented: the identifier of the terminal and the transaction identifier are encrypted;
  • a transmission file of these data is built ;
  • the file for transmitting these data can take the form: of an image file, comprising a QR Code or ink of a modulated ultrasound sequence;
  • the image file is displayed on the professional's terminal; the ultrasonic sequence is emitted from the professional's terminal (it should be noted that these two forms of transmission of information to the
  • the user's communication device (the mobile terminal or the tablet) of the user receives the intermediate data file from the professional's terminal (either by reading the QR-Code, or by receiving the ultrasound sequence);
  • the data is decoded (depending on the data encoding format used) and the user's user communication device (DTon) is configured (dynamic configuration): a request is transmitted by the user's device to the the location address of an instant application with the identifier data of the professional's terminal and transaction identifier as parameters; the instant application is immediately downloaded and executed on the user communication device (DTon);
  • This instant application displays a user interface including: parcel information, obtained from a transactional server (ServT) of the delivery company (or another transactional server) and a signature zone (allowing the user to sign with his finger or with a stylus on the touch screen of his terminal) and a triplet of buttons (“cancellation”, “correction”, “validation”); This completes the end of the dynamic configuration of the user device;
  • a transactional server (ServT)
  • validation step of the transaction consisting of the user signing on the screen of his device (with a finger or with a stylus), then validating this entry by selecting the "validation" button. ; A message is displayed to the user to inform him of the entry;
  • the instant application performs a validation of the transaction by calculating a hash of the user's signature, encoding the image of the signature using a key , obtained for example from the hash produced, then by adding this data (hash of the signature, image of the signature) to the data intermediaries;
  • the resulting data set is transmitted to the transactional server (ServT), and the instant application is uninstalled;
  • the transactional server (ServT) receives the data transmitted by the instantaneous application and sends a message to the deliverer's terminal informing it of the validation of the transaction.
  • the user was able to receive his package, while avoiding on the one hand entering sensitive information on the professional's terminal and on the other hand by securing the transmission of this data. , notably by means of encryption, to the transactional server.
  • the user also did not need to come into physical contact with the professional's terminal, preserving health security.
  • no application is permanently installed on the user's device, the instantaneous application residing only in the volatile memory of the user's device.
  • Example of embodiment 2 access to premises protected by an access terminal
  • This example of embodiment describes the execution of a dissociated transaction in the context of access to protected premises, via a an access terminal (professional terminal) with card, by a person wishing to access these premises (user).
  • the professional's terminal is equipped with a smart card reader, which is used by the user to access the premises.
  • the access terminal can be connected to a communication network (for example a mobile network) and it has data relating to the user (in particular a telephone number, which it can use to transfer a notification to the terminal of the 'user).
  • the dissociated transaction processing process is implemented, according to the steps previously described in relation to FIG. 2, after the request for access to the premises made by the user (for example by inserting his access card into the reader of the access terminal, or by any means usable on the access terminal, such as a physical button for example): the preparation of the transaction by the access terminal includes obtaining the identifier of the terminal access within a memory of this terminal and the preparation, by the processing processor, of a transaction identifier; In addition, if not already done, an access card insertion message is displayed to the user; the latter then inserts his access card into the smart card reader; the preparation of the transaction then continues with an interrogation of the access card by the access terminal, in order to obtain a public key of the access card in particular; this public key is inserted into the intermediate data set; the intermediate data set, after possible additional control operations (in particular control of the validity of the access card), is then encrypted using a private key of the access terminal; a file for transmitting these encrypted intermediate data is constructed, and the file is transmitted to the
  • the transaction validation step consisting of the user entering the PIN code on the screen of his device, then validating this entry by selecting the “validation” button; A message is displayed to the user to inform him of the entry;
  • the application validates the transaction by performing an operation of encrypting the PIN code entered using the public key of the card present in the intermediate data received; this encrypted PIN is added to the decrypted intermediate data initially received and encryption of the whole is then carried out with the public key of the access terminal; All of the resulting data is transmitted to the access terminal, for example via an SMS type message, and the PIN code entry application is stopped;
  • the access terminal receives the data transmitted by the application, decrypts it using its private key, verifies that the intermediate data is correct and transmits the encrypted PIN code to the smart card inserted in the card reader.
  • the user's smart card decrypts the PIN code using its private key and checks its validity: if the PIN code entered is valid, the smart card can form a certificate intended for the terminal d access in response to the validation request; the access terminal receives this certificate, verifies it and authorizes access to the premises.
  • the user was able to access the premises protected by the access terminal, while on the one hand avoiding entering sensitive information on the access terminal itself. and on the other hand by securing the transmission of these data, in particular by means of encryption, to the access terminal.
  • the user also did not need to come into physical contact with the access terminal, preserving health security.
  • a first variant consists in installing the public key of the access terminal when configuring the user's communication terminal: this configuration can be carried out by the authority which manages access to the premises protected by the access terminal. .
  • This public key can be registered within a certificate which is installed in a protected memory area of the user's communication terminal.
  • a second variant consists in broadcasting the public key of the access terminal at the time of the implementation of the dissociated transaction.
  • the public key of the access terminal is transmitted to the communication terminal of the user using a transmission channel different from that used for the transmission of the intermediate data.
  • This transmission channel is called an auxiliary channel and it is used to secure the transmission of this public key.
  • This auxiliary transmission channel can typically take the form of a modulated ultrasonic signal, the signal encoding a data record comprising on the one hand the public key of the access terminal (this public key can be a session key, temporary) and on the other hand a conformity verification data item.
  • the method for transmitting this public key is as follows: when the user inserts his access card into the card reader of the access terminal, the access terminal, during the transaction preparation step, broadcasts, using the auxiliary channel (ie by ultrasound), the data record comprising the public key of the access terminal.
  • This dissemination is only carried out after the access card has been inserted into the reader of the access terminal and the access terminal has checked the validity of this access card (for example that it not part of a banned list, or not disabled - too old).
  • the user's communication terminal picks up this broadcast and acquires the data record comprising the public key of the access terminal and the compliance verification data.
  • This broadcasting, by the access terminal can be cyclical (that is to say be repeated), until the transmission, by the access terminal, of the intermediate data of the transaction to the communication terminal of the user (via the main channel, ie SMS or other type of transmission on the communication network).
  • the advantage of this implementation is that it allows the access terminal to define temporary keys whose use is limited to a single transaction: in fact, the public key of the terminal is then a session key and the corresponding private key is also a session key. Moreover, the transmission of this key being initiated only from the moment when the user's access card is inserted in the reader of the access terminal, this key can be specifically dedicated to the access card. user access.
  • the main channel may be the ultrasonic channel, used to transmit the intermediate transaction data and the secondary channel may be the communication network, used to transmit the public key of the access terminal.
  • Example of realization 3 payment using a payment terminal
  • the professional's terminal (payment terminal) is generally equipped with a chip card reader, the use of which is not necessary in the context of this embodiment.
  • the payment terminal is connected to a communication network (for example a mobile network or the commercial communication network, eg Wifi network, Ethernet) and it may have data relating to the user (in particular a telephone number, in as part of a loyalty account, for example).
  • the insertion of the user's payment card into the payment terminal may be required: in which case, the processing implemented are identical to the second exemplary embodiment and the chip of the payment card is used in the chip card reader of the payment terminal to carry out a payment transaction instead of an access transaction.
  • the insertion of the payment card into the payment terminal is not necessary: the payment card is used by the communication terminal of the Dton user, as described below. .
  • the dissociated transaction processing process is implemented, according to the steps previously described in relation to FIG. 2, after the payment request made by the merchant (for example by requesting payment for goods or services from the user ): the preparation of the transaction by the payment terminal includes obtaining the identifier of the payment terminal (within a memory of this terminal or via the transactional server to which the payment terminal is connected, described below) and the preparation, by the secure processing processor of the payment terminal, of a transaction identifier; the preparation of the transaction also includes the addition, to the intermediate data, of purchase amount data, date, time, etc.
  • the set of intermediate data after any additional control operations, is then encrypted using a private key of the payment terminal; a file for transmitting these encrypted intermediate data is constructed, and the file is transmitted to the user's Dton terminal via the communication network to which the payment terminal is connected;
  • the communication network represents the main transmission channel for intermediate data; the user's Dton device receives the intermediate data file from the payment terminal, for example via an SMS or another message transmitted over the communication network;
  • the file data is decrypted using the public key of the payment terminal (this public key was transmitted to the Dton device moreover, as explained in the second embodiment) and the user communication device (DTon ) of the user is dynamically configured: a payment transaction validation application (for example the user's banking application, preinstalled on his terminal), with as a parameter the data identifying the terminal of the payment terminal and pre- transaction identifier is executed on the user communication device (DTon); This application displays the transaction data to the user, as if the user were viewing the payment terminal screen;
  • This input application for example
  • Affix his payment card to the back of his communication terminal which in this embodiment is a contactless card (NFC); this affixing leads to the reading of the bank card data on the user's communication terminal (card number, date, CVV, name) and triggers the display of a PIN code entry user interface comprising: the information relating to access, obtained from intermediate data and a PIN code entry zone (allowing the user to enter the confidential code of his payment card) and a triplet of buttons ("cancellation", "correction” , “validation”);
  • the application validates the transaction by generating a transaction certificate using the bank card data, and depending on the number of times the card has been affixed to the back of the user's communication terminal; the transaction data and the transaction certificate are then transmitted to the transactional server;
  • the transactional server validates the transaction received from the user's communication terminal and transmits transaction confirmation data to the merchant's payment terminal;
  • the payment terminal receives the data transmitted by the transactional server: the merchant is then informed of the validation of the transaction.
  • the user was able to make payment for his purchases, while on the one hand avoiding entering sensitive information on the payment terminal itself (which as was mentioned above can be a simple communication terminal comprising payment functions for the merchant, such as communication terminals with additional card readers of the SquareTM type, plugging into the communication terminal) and on the other hand securing the transmission of this data, in particular by means of encryption, directly to the transactional server, without going through the merchant's terminal.
  • the user also did not need to come into physical contact with the merchant's terminal, preserving health security.
  • Example of embodiment 4 payment using a payment terminal
  • the principle here again is to dissociate the execution of the transaction by using three separate entities, as explained previously.
  • the method is again intended to make it possible to make a payment between a physical merchant (i.e. being in a shop) and a customer (user), who is also physically in the merchant's shop and who wishes to make a payment for goods or of the services it purchases.
  • the dissociated transaction processing process is implemented, according to the steps previously described, after the payment request made by the merchant (for example by requesting payment for goods or services from the user)
  • the payment terminal obtains, from the transactional server, data relating to the banking establishment with which the merchant is registered, in particular, an identifier linked to the payment terminal, from an account of the merchant;
  • the merchant's payment terminal transmits, to the Dton device, at least "one secure activation key" (or an activation key pair) which form the intermediate data, obtained in particular from the identifier linked to the payment terminal ;
  • the transmission of this key is carried out, according to a first exemplary embodiment, via a signal transmitted from the merchant's payment terminal to the Dton device, which is physically next to the merchant (and his payment) (ie QR-Code or Ultrasound or “cloud transactional proxy, transactional server”, ie data transmission network); o
  • This (these) key(s), acting as intermediate data leads to the activation of the AppV application on the user's communication terminal.
  • This application is pre-installed by the user, or it is the application of his bank, or it is a single-use instant application, as in the case of the receipt of a package presented previously;
  • the AppV application of the user's communication terminal receives "the merchant's parameters", to be used to carry out the transaction (which include, for example, a "floor limit” ); o
  • a "floor limit” is an amount, for example in euros, above which credit card transactions must be authorized (i.e. be authorized by the bank card network ). o in this embodiment, the transaction is required to be authorized by the network;
  • An acquisition mechanism operates the transaction from a transactional merchant account server (therefore coming from the bank) in connection with the user's communication terminal and the AppV application, such as previously explained;
  • a clearing service identifies, from the transaction data obtained, a method that allows the transaction to be validated; the status of the transaction is communicated to the merchant's (payment) terminal and the credit (i.e. the amount of money) is posted to the merchant's bank account; This compensation mechanism is operated from a transactional server of the merchant's bank;
  • the merchant's terminal receives, from the transactional server that executed the transaction (i.e. the server implementing the compensation mechanism), a result of this transaction (in the form of an encrypted message).
  • the result of the transaction is secured by the use of the activation key(s) which have been transmitted to the communication terminal by the payment terminal.
  • a (prior) subscription step is implemented by the merchant (optional for the user, in particular for Instant App on the client side);
  • the merchant selects the appropriate payment method on the payment terminal (and enters or receives the amount to be paid from the cash register); depending on the operational implementation conditions, the user can insert his card into the payment terminal (ie for example depending on the amount of the transaction to be executed); the mechanism implemented allows the customer to enter his PIN on his communication terminal;
  • the payment terminal receives information from the transactional server, in particular the identifier of the transaction and the key(s) for the transaction validation process; it requests this data from the transactional server;
  • the user's communication terminal application is activated (and downloaded or if it is an instant application) - the activation can be manual (start by the user or automatic (notification, i.e. application in background, with the data network of the communication terminal) or be subsequent to the transmission of information by the merchant's payment terminal (QR scanned by the user, on payment terminal screen ultrasound emitted from the buzzer payment terminal and received by the communication terminal, NFC).
  • the user's communication terminal application receives the transaction identifier and the key(s). (s) (either from the merchant's payment terminal or from the transactional server: when it is the transactional server, the latter is informed of the communication terminal via the identifier of the communication terminal of the user (for example his telephone number).
  • the user's communication terminal Based on the transaction identifier and the key (or keys), the user's communication terminal transmits a request for obtaining transaction data and payment parameters (from the merchant) to the payment mechanism. acquisition (in order to receive the floor limit in particular) of the transactional server; o The Dton device then has the amount to be paid and the identification of the merchant: this ensures that the information displayed on the merchant's terminal (and/or the cash register) is identical to that displayed on the communication terminal of the user; o
  • the transactional server comprises means for determining the transaction identifier and means for generating the key to be able to exchange data in a secure manner with the communication terminal of the user on behalf of the merchant and has a backup of the merchant's settings, as associated with the latter's payment terminal; the additional advantage provided is that the merchant's terminal can be devoid of complex transaction processing functions, these complex functions being managed at the level of the transactional server on the one hand and of the user's communication terminal on the other hand;
  • the application of the communication terminal carries out the implementation of the transaction (as explained in the second and third example embodiments).
  • the communication terminal application and the transactional server complete the EMV transaction.
  • the transactional server transmits a transaction completion message to the clearing mechanism (which is responsible for transferring the amount of the transaction to the merchant's account); - The clearing mechanism transmits the transaction completion message to the merchant's payment terminal;
  • the transactional server also informs the application of the communication terminal that the transaction is completed.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Technology Law (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Debugging And Monitoring (AREA)

Abstract

L'invention se rapporte à un procédé d'exécution d'une transaction entre un terminal de mise en œuvre de transaction (TProf) et un dispositif de communication (Dton) qui est situé à proximité du terminal de mise en œuvre de transaction (TProf). Un tel procédé comprend une étape de préparation (A10) de la transaction à exécuter au sein terminal de mise en œuvre de transaction (TProf), délivrant un ensemble de données intermédiaires d'exécution de transaction; une étape de transmission (A20) des données intermédiaires d'exécution de transaction au dispositif de communication (Dton); et une étape d'exécution (A30) de la transaction par le dispositif de communication (Dton) à l'aide de ladite au moins une donnée intermédiaire d'exécution de transaction et d'au moins une donnée personnelle (Sgn, PIN) de l'utilisateur qui détient le dispositif de communication (Dton), ladite exécution délivrant un résultat d'exécution transmis (A40) au terminal de mise en œuvre de transaction (TProf).

Description

DESCRIPTION
Titre : procédé de traitement d'une transaction, dispositif et programme correspondant.
1. Domaine de l'invention
L'invention se rapporte au domaine de la sécurisation de traitements informatiques. Le domaine de l'invention concerne plus précisément à la sécurisation de traitement réalisés au moins en partie par l'intermédiaire de deux dispositifs informatiques distincts, possédés respectivement par deux entités également distinctes. L'invention vise plus particulièrement à sécuriser la mise en oeuvre d'un traitement de données confidentielles, par exemple au cours d'une transaction menée entre un dispositif initiateur de la transaction et un dispositif d'exécution, au moins partielle, de la transaction. Les transactions visées par la présente peuvent être de divers types, comme par exemple des signatures électroniques, des validations d'accès, des transactions de paiement, des transactions de validation de données.
2. Art antérieur
Antérieurement, lorsqu'une transaction doit être menée pour un bénéficiaire (i.e. commerçant, notaire, etc.), qui souvent est un professionnel, ce bénéficiaire requiert l'utilisation, par une personne (souvent une personne physique), d'un terminal dédié à la transaction. Ce terminal est utilisé par la personne pour confirmer la transaction qui est menée, par exemple en apposant une signature sur ce terminal ou encore en saisissant un code secret, et ce, souvent, postérieurement à l'insertion, dans ce terminal dédié, d'un dispositif transactionnel possédé par l'utilisateur (carte de paiement, carte d'accès).
Cette manière de mettre en oeuvre des transactions pose problème. D'une part elle pose un problème de sécurité des données traitées : il existe peu de terminaux réellement en mesure de garantir la sécurité des données fournies par l'utilisateur : tant celles fournies par le dispositif transactionnel (carte de paiement, carte d'accès) lorsque celui-ci est inséré dans le terminal du bénéficiaire professionnel, que celles saisies par l'utilisateur lui-même pour confirmer son autorisation ou son authentification, confirmation nécessaire à la mise en oeuvre de la transaction. Parmi les terminaux qui garantissent cette sécurité on peut principalement penser aux terminaux de paiement conformes aux normes PCI.
Cependant, à cause notamment de la numérisation, tant de l'économie que des actions réalisées dans la vie courante, de plus en plus d'actes et de transactions sont réalisées sur des terminaux qui ne sont pas nécessairement sécurisés d'une part et qui à la base ne sont pas des terminaux prévus ou pensés pour réaliser de telles transactions d'autre part. Par exemple, pour la signature d'actes notariés, il est de plus en plus fréquent d'utiliser des signatures numérisées, effectuées par l'utilisateur sur une tablette de saisie (de type Wacom™ par exemple) directement connectée à l'ordinateur du notaire. De même, pour la livraison de colis, il est fréquent de devoir apposer sa signature sur un terminal du livreur pour valider la bonne réception du colis ou du pli qui est livré, et ce sans que l'utilisateur n'ait conscience ou connaissance du degré de sécurisation du terminal qui lui est présenté. Ceci est d'autant plus vrai que l'arrivée massive de terminaux à bas coûts, en provenance de pays de production peu regardant sur la qualité de fabrication ou de sécurisation (logicielle et matérielle) des terminaux vendus, expose de plus en plus de personnes à des tentatives de fraude, d'escroquerie de la part d'individus mal intentionnés : ces individus profitent de la faiblesse sécuritaire des terminaux en circulation pour y injecter des applications malveillantes, dans l'objectif d'obtenir des données personnelles ou confidentielles.
A ces problèmes de sécurité des données, on peut également ajouter les problèmes récents liés à la sécurité sanitaire : l'utilisation de dispositifs fournis par les bénéficiaires professionnels nécessitent que ces derniers mettent en place des protocoles pour assurer la sécurité des personnes. Ces protocoles sont souvent lourds et augmentent le temps nécessaire à la mise en oeuvre de la transaction. Par exemple, dans le cas d'un notaire, celui-ci est obligé d'effectuer un nettoyage du stylet utilisé pour la signature avant utilisation par tout signataire. De même, le professionnel disposant d'un terminal de paiement, ou d'un terminal de signature pour la livraison de pli ou de colis, a théoriquement l'obligation d'appliquer une solution désinfectante sur le terminal entre chaque client. Dans les faits, ces obligations ne sont pas nécessairement remplies et elles ajoutent un sentiment d'insécurité sanitaire à la présence réelle d'une certaine insécurité de transaction, en fonction des situations rencontrées.
Il existe donc un besoin de fournir aux utilisateurs une méthode de réalisation de transaction qui permette de répondre aux problématiques posées, tout en assurant une sécurisation des données échangées.
Des solutions ont été proposées, notamment dans le domaine du paiement. Par exemple le document US10147094B2 poursuit l'objectif de proposer une méthode de paiement basée sur la connectivité d'un réseau de communication auquel un terminal de communication d'un utilisateur est connecté, pour permettre à cet utilisateur de valider une transaction en saisissant un code d'identification personnel associé à son terminal de communication. Le problème de cette méthode est qu'elle ne permet pas d'utiliser un moyen de paiement (e.g. carte de crédit) pour effectuer la transaction chez le professionnel (e.g. le commerçant). Le document US10127532B1, pour sa part, décrit une méthode de réalisation d'une transaction de paiement dans laquelle le terminal de communication de l'utilisateur est utilisé pour détecter une intention de paiement et mettre en oeuvre la transaction. Cependant, cette méthode de réalisation de transaction est basée uniquement sur la capacité de l'utilisateur à vouloir engager une transaction de paiement.
Aucune de ces solutions cependant ne résout à la fois le problème de sécurisation de la mise en oeuvre de la transaction du point de vue du professionnel bénéficiaire (notamment, pour reprendre l'exemple du paiement, pour que le commerçant personne physique s'assure que l'utilisateur dispose de la capacité à mener la transaction) tout en garantissant à cet utilisateur que le dispositif utilisé par le professionnel bénéficiaire n'est pas inutilement mis en connaissance de données confidentielles (e.g. signatures numérisées, codes confidentiels, etc.).
3. Résumé de l'invention
L'invention a été réalisée en tenant compte de ces problèmes de l'art antérieur. Plus particulièrement, la présente divulgation porte sur un procédé d'exécution d'une transaction entre un terminal de mise en oeuvre de transaction d'un professionnel et un dispositif de communication d'utilisateur qui est situé à proximité du terminal de mise en oeuvre de transaction du professionnel. Un tel procédé comprend une étape de préparation de la transaction à exécuter au sein terminal de mise en oeuvre de transaction du professionnel, délivrant au moins une donnée intermédiaire d'exécution de transaction ; une étape de transmission de ladite au moins une donnée intermédiaire d'exécution de transaction au dispositif de communication d'utilisateur ; et une étape d'exécution de la transaction par le dispositif de communication d'utilisateur à l'aide de ladite au moins une donnée intermédiaire d'exécution de transaction et d'au moins une donnée personnelle de l'utilisateur qui détient le dispositif de communication d'utilisateur, ladite exécution délivrant un résultat d'exécution transmis au terminal de mise en oeuvre de transaction d'un professionnel.
Ainsi, à la différence de l'art antérieur, le professionnel est en mesure de vérifier, lors de la construction, de la mise en oeuvre et de l'exécution de la transaction, que l'utilisateur dispose de la capacité à et des moyens pour réaliser cette transaction. De son côté, l'utilisateur est en mesure de s'assurer que le terminal du professionnel n'entre pas en possession d'informations personnelles, notamment par exemple des signatures numérisées ou des mots de passe ou des codes confidentiels. Selon une caractéristique particulière l'étape d'exécution de la transaction par le dispositif de communication d'utilisateur à l'aide de ladite au moins une donnée intermédiaire d'exécution de transaction et d'au moins une donnée personnelle de l'utilisateur qui détient le dispositif de communication d'utilisateur comprend une étape d'obtention, par le dispositif de communication d'utilisateur, d'au moins une donnée en provenance d'un dispositif transactionnel additionnel en possession de l'utilisateur.
Ainsi, l'utilisateur est en mesure d'utiliser sa carte de paiement directement sur son terminal de communication, devant le marchand, qui est en mesure de vérifier que son client effectue un paiement à l'aide de cette carte de paiement.
Selon une caractéristique particulière, l'étape d'obtention, par le dispositif de communication d'utilisateur, de ladite au moins une donnée en provenance du dispositif transactionnel additionnel en possession de l'utilisateur comprend : une étape d'émission, par le dispositif de communication d'utilisateur, d'une requête d'obtention de données transactionnelles, ladite étape d'émission utilisant une interface de communication en champs proche du dispositif de communication d'utilisateur ; une étape de réception, par le dispositif de communication d'utilisateur, d'une réponse à ladite requête d'obtention de données transactionnelles par l'intermédiaire de interface de communication en champs proche du dispositif de communication d'utilisateur.
Ainsi, le terminal de communication de l'utilisateur joue un rôle actif dans la mise en oeuvre de la transaction, en requérant de lui-même les données transactionnelles.
Selon une caractéristique particulière l'étape d'exécution de la transaction par le dispositif de communication d'utilisateur à l'aide de ladite au moins une donnée intermédiaire d'exécution de transaction et d'au moins une donnée personnelle de l'utilisateur qui détient le dispositif de communication d'utilisateur comprend : une étape de réception de ladite au moins une donnée intermédiaire d'exécution de transaction par le dispositif de communication d'utilisateur ; une étape de configuration dynamique du dispositif de communication d'utilisateur, en fonction de ladite au moins une donnée intermédiaire d'exécution, ladite étape de étape de configuration dynamique comprenant une étape d'exécution, au sein d'un espace mémoire dédié dudit dispositif de communication d'utilisateur, d'une application de validation pour la saisie de la dite au moins une donnée personnelle de l'utilisateur qui détient le dispositif de communication d'utilisateur ; une étape de réception, par l'application de validation, d'au moins une donnée saisie par ledit utilisateur ; une étape de validation, par l'application de validation, de la transaction en fonction de ladite au moins une donnée saisie par ledit utilisateur et desdites données intermédiaires, délivrant un résultat de validation.
Ainsi, l'utilisateur est en mesure de saisir le code PIN de sa carte bancaire, directement sur son terminal de communication.
Selon une caractéristique particulière, postérieurement à l'étape de validation, par l'application de validation, de la transaction en fonction de ladite au moins une donnée saisie par ledit utilisateur et desdites données intermédiaires, le procédé comprend : une étape de transmission desdites données intermédiaires et dudit résultat de validation, à un serveur transactionnel auquel le dispositif de communication d'utilisateur est connecté par l'intermédiaire de l'application de validation, une étape de validation, par le serveur transactionnel, desdites données intermédiaires et dudit résultat de validation, comprenant une vérification des opérations cryptographiques de validation effectuées par ladite l'application de validation ; une étape de transmission, au terminal de mise en oeuvre de transaction d'un professionnel, dudit résultat de validation de transaction, lorsque la vérification des opérations cryptographiques de validation délivre un résultat positif.
Ainsi, la transaction est traitée en toute sécurité, par exemple par l'intermédiaire du serveur bancaire correspondant à la banque de l'utilisateur ou de celui du commerçant, et cette transaction peut être immédiatement traitée, sans délai.
Selon une caractéristique particulière l'étape étape de préparation de la transaction à exécuter au sein terminal de mise en oeuvre de transaction du professionnel comprend : une étape d'obtention, à partir d'un dispositif transactionnel additionnel en possession de l'utilisateur, d'au moins une clé de chiffrement destinée à être transmise au dispositif de communication d'utilisateur ; et une étape d'insertion, au sein de ladite au moins une donnée intermédiaire d'exécution, de ladite au moins une clé de chiffrement obtenue. Ainsi, l'utilisateur peut également choisir d'insérer sa carte bancaire dans le terminal de paiement du commerçant, lorsque c'est possible. La saisie du code pin de la carte bancaire s'éffectuant tout de même sur le terminal de communication de l'utilisateur à partir de données de sa carte bancaires, transmises à partir du terminal de paiement du commerçant, ce qui est techniquement rassurant pour le commerçant.
Selon une caractéristique particulière l'étape de transmission de ladite au moins une donnée intermédiaire d'exécution de transaction au dispositif de communication d'utilisateur comprend : une étape d'activation d'une interface de communication du terminal de mise en oeuvre de transaction d'un professionnel, pour la transmission par l'intermédiaire d'un canal principal ; une étape de transmission, par l'intermédiaire de l'interface de communication, d'un fichier comprenant ladite au moins une donnée intermédiaire.
Selon une caractéristique particulière l'interface de communication activée pour la transmission du fichier comprenant ladite au moins une donnée intermédiaire appartient au groupe comprenant : une interface sonore, configurée pour émettre le fichier préalablement encodé sous la forme d'un signal ultrasonore ; un écran du terminal de mise en oeuvre de transaction d'un professionnel, configurée pour afficher le fichier préalablement encodé sous la forme d'un code bidimensionnel ; une interface de transmission de données par l'intermédiaire d'un réseau de communication, configurée pour transmettre le fichier préalablement encodé sous la forme d'un message. Selon un autre aspect, l'invention se rapporte également à un système d'exécution d'une transaction, système comprenant un terminal de mise en oeuvre de transaction d'un professionnel et un dispositif de communication d'utilisateur qui est situé à proximité du terminal de mise en oeuvre de transaction du professionnel. Un tel système comprend des moyens de préparation de la transaction à exécuter implémentés au sein terminal de mise en oeuvre de transaction du professionnel, délivrant au moins une donnée intermédiaire d'exécution de transaction ; des moyens de transmission de ladite au moins une donnée intermédiaire d'exécution de transaction au dispositif de communication d'utilisateur ; et des moyens d'exécution de la transaction implémentés au sein du dispositif de communication d'utilisateur à l'aide de ladite au moins une donnée intermédiaire d'exécution de transaction et d'au moins une donnée personnelle de l'utilisateur qui détient le dispositif de communication d'utilisateur, ladite exécution délivrant un résultat d'exécution et des moyens de transmission du résultat d'exécution au terminal de mise en oeuvre de transaction d'un professionnel.
Selon une implémentation préférée, les différentes étapes des procédés selon l'invention sont mises en oeuvre par un ou plusieurs logiciels ou programmes d'ordinateur, comprenant des instructions logicielles destinées à être exécutées par un processeur de données d'un dispositif d'exécution selon l'invention et étant conçu pour commander l'exécution des différentes étapes des procédés, mis en oeuvre au niveau d'un terminal de communication, d'un dispositif électronique d'exécution et/ou d'un dispositif de contrôle, dans le cadre d'une répartition des traitements à effectuer et déterminés par un code source scripté et/ou un code compilé.
En conséquence, l'invention vise aussi des programmes, susceptibles d'être exécutés par un ordinateur ou par un processeur de données, ces programmes comportant des instructions pour commander l'exécution des étapes des procédés tel que mentionnés ci-dessus.
Un programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
L'invention vise aussi un support d'informations lisible par un processeur de données, et comportant des instructions d'un programme tel que mentionné ci-dessus.
Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple un support mobile (carte mémoire) ou un disque dur ou un SSD.
D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.
Selon un exemple de réalisation, l'invention est mise en oeuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme "module" peut correspondre dans ce document aussi bien à un composant logiciel, qu'à un composant matériel ou à un ensemble de composants matériels et logiciels.
Un composant logiciel correspond à un ou plusieurs programmes d'ordinateur, un ou plusieurs sous-programmes d'un programme, ou de manière plus générale à tout élément d'un programme ou d'un logiciel apte à mettre en oeuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Un tel composant logiciel est exécuté par un processeur de données d'une entité physique (terminal, serveur, passerelle, set-top-box, routeur, etc.) et est susceptible d'accéder aux ressources matérielles de cette entité physique (mémoires, supports d'enregistrement, bus de communication, cartes électroniques d'entrées/sorties, interfaces utilisateur, etc.).
De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware) apte à mettre en oeuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Il peut s'agir d'un composant matériel programmable ou avec processeur intégré pour l'exécution de logiciel, par exemple un circuit intégré, une carte à puce, une carte à mémoire, une carte électronique pour l'exécution d'un micrologiciel (firmware), etc.
Chaque composante du système précédemment décrit met bien entendu en oeuvre ses propres modules logiciels.
Les différents modes de réalisation mentionnés ci-dessus sont combinables entre eux pour la mise en oeuvre de l'invention.
4. Brève description des figures
D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un exemple de réalisation préférentiel, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels :
[fig 1] la figure 1 décrit un système dans lequel la divulgation peut être mise en oeuvre ;
[fig 2] la figure 2 décrit le principe général de la méthode objet de la divulgation ;
[fig 3] la figure 3 illustre une architecture d'un terminal électronique professionnel apte à mettre en oeuvre un procédé objet de la divulgation.
5. Description d'un exemple de réalisation Comme indiqué précédemment, la divulgation décrit une méthode consistant à requérir, auprès d'un dispositif de communication d'un utilisateur, la mise en oeuvre au moins partielle d'une transaction qui doit être menée pour le compte d'un initiateur (il peut s'agir d'un commerçant, d'un notaire, d'un livreur, d'un dispositif de validation d'accès, etc.), qui dispose ou implémente un dispositif de communication d'utilisateur (dispositif de paiement, dispositif de signature, terminal de contrôle d'accès, etc.), considéré pour diverses raisons comme impliquant une problématique de sécurité. En d'autres termes, il est proposé une technique de dissociation d'exécution de transaction : la transaction est initialisée sur un terminal d'un professionnel et est complétée (exécutée, finalisée) sur un terminal d'un utilisateur, pour que celui-ci puisse saisir, en toute sécurité, les données confidentielles permettant de valider cette transaction.
Ainsi, afin de permettre au professionnel de s'assurer de la capacité de l'utilisateur à effectuer la transaction tout en permettant à l'utilisateur de ne pas fournir au professionnel des données personnelles et/ou confidentielles, la méthode consiste à mettre à contribution un terminal de communication de l'utilisateur (typiquement son terminal de communication mobile de type smartphone ou tablette) pour exécuter une portion de la transaction initiée par le terminal du professionnel. Pour ce faire, selon la présente divulgation, le terminal du professionnel transmet au terminal de l'utilisateur, des données particulières, permettant au terminal utilisateur de poursuivre l'exécution de la transaction. Cette poursuite de l'exécution de la transaction peut consister en une validation de celle-ci (par exemple en effectuant une opération de signature et/ou une ou plusieurs opérations cryptographiques), ou bien encore en une vérification de validation de données confidentielles.
Quoi qu'il en soit, le problème principal dans la modification protocolaire proposée, consiste notamment : à assurer la sécurité des données échangées (afin d'éviter leur interception) ; à assurer la non répudiation des données échangées (afin d'éviter toute modification non souhaitée, tant du côté du terminal du professionnel que du terminal d'utilisateur). En effet, il est indispensable que la modification protocolaire n'induise pas de faille de sécurité permettant de modifier la transaction.
La figure 1 décrit un système dans lequel la technique proposée peut être mise en oeuvre. Un tel système (SystET) comprend un terminal d'un professionnel (TProf), le terminal du professionnel comprenant des moyens d'exécution de transaction. Un tel terminal (TProf) est décrit en relation avec la figure 3. Un tel système comprend également un dispositif de communication d'utilisateur (DTon), dispositif physique appartenant à un utilisateur, et prenant généralement la forme d'une tablette ou d'un smartphone, ce dispositif étant portable et à dispositif de l'utilisateur lorsqu'il se trouve physiquement chez ou en présence du professionnel qui utilise le terminal de professionnel (TProf). Ce système peut également comprendre, en fonction des réalisations, un serveur transactionnel (ServT). Le serveur transactionnel est dans ce cas à minima accessible par l'intermédiaire d'un réseau de communication pour le terminal de professionnel (TProf) et/ou le dispositif de communication d'utilisateur (DTon). En fonction des modes de réalisation, le système comprend également un dispositif transactionnel additionnel (DTa) (carte d'accès, carte de crédit) notamment lorsque la mise en oeuvre de la transaction nécessite l'utilisation d'un tel dispositif transactionnel additionnel (transaction pour accéder à des locaux, transaction de paiement par carte bancaire, carte de crédit).
La figure 2 décrit le principe général de la méthode objet de la divulgation. Plus particulièrement, la méthode de réalisation de transaction comprend : une étape de préparation (A10) de la transaction, mise en oeuvre au sein du terminal du professionnel (TProf) ; cette étape de préparation de la transaction comprend, notamment l'obtention d'un identifiant (unique) du terminal du professionnel ; cet identifiant unique sert de base à l'initialisation de la transaction (il est stocké/obtenu au sein du terminal du professionnel (TProf), ou transmis au terminal du professionnel (TProf) par l'intermédiaire du serveur transactionnel (ServT)) ; cette étape de préparation de la transaction peut également comprendre l'obtention de données en provenance d'un dispositif transactionnel additionnel (DTa) lorsqu'un tel dispositif est nécessaire à la réalisation de la transaction (cette étape d'obtention de données comprend par exemple l'insertion d'une carte en possession de l'utilisateur dans le terminal du professionnel ou bien l'obtention de données sans contact entre cette carte en possession de l'utilisateur et le terminal du professionnel) ; la préparation de la transaction peut comprendre également la génération d'un (pré)identifiant unique de transaction, permettant de tracer et localiser celle-ci ; l'ensemble {« identifiant (unique) du terminal du professionnel » ; « (pré)identifiant unique de transaction »} forme des données intermédiaires (IntDat) ; elles peuvent être sécurisées par l'intermédiaire d'un chiffrement ; la préparation de la transaction comprend également, en fonction de la mise en oeuvre opérationnelle, d'autres étapes, comme exposé dans les modes de réalisation par la suite, pouvant comprendre la mise en oeuvre d'autres données à transmettre au dispositif de communication d'utilisateur (DTon), ces autres données étant ajoutées à l'ensemble des données intermédiaires (IntDat) ; les données intermédiaires (IntDat) peuvent être reçues, par le dispositif de communication d'utilisateur (DTon), soit de la part du terminal de professionnel (TProf) ou par l'intermédiaire du serveur transactionnel (ServT) ; une fois la transaction préparée (à divers degrés, en fonction de la mise en oeuvre opérationnelle), le dispositif de communication d'utilisateur (DTon) de l'utilisateur est dynamiquement configuré (A20), à l'aide de l'ensemble des données intermédiaires (IntDat), reçues sur le dispositif de communication d'utilisateur (DTon) de l'utilisateur ; pour ensuite valider (A30) cette transaction (e.g. exécuter/clôturer celle-ci) ; la validation de la transaction comprend, pour l'utilisateur, l'interaction avec une application de validation de transaction AppVT installée sur son terminal : cette interaction peut comprendre notamment, la saisie d'une ou de plusieurs données confidentielles sur l'application de validation de la transaction (signature numérisée Sgn, code confidentiel PIN, etc.) et/ou l'utilisation sur le dispositif de communication d'utilisateur (DTon), du dispositif transactionnel additionnel (DTa) pour obtenir des données en provenance de celui-ci, lorsqu'un tel dispositif est nécessaire à la réalisation de la transaction (que ce dispositif transactionnel additionnel (DTa), lorsqu'un tel dispositif est nécessaire à la réalisation de la transaction, ait été ou non utilisé pour préparer la transaction) ; l'application de validation de transaction AppVT installée sur le terminal est préférentiellement exécutée dans un espace sécurisé de la mémoire du dispositif de communication d'utilisateur (DTon) et préférentiellement, cette application est téléchargée à partir d'un réseau de communication uniquement sur demande, en fonction des données intermédiaires reçues (i.e. les données intermédiaires reçues déterminent au moins en partie la configuration et l'exécution de l'application de validation de transaction AppVT) et est exécutée immédiatement après téléchargement dans la mémoire vive du dispositif de communication d'utilisateur (DTon) ; selon une variante, lorsque l'application de validation de transaction AppVT est déjà présente (pré-téléchargée par l'utilisateur), celle-ci est configurée en fonction des données intermédiaires reçues ; préférentiellement, cette application de validation de transaction AppVT bloque l'utilisation du dispositif de communication d'utilisateur (DTon) en obtenant un accès exclusif aux ressources d'exécution du dispositif de communication d'utilisateur (DTon) et limite l'utilisation de celui-ci à des saisie sur l'écran tactile et optionnellement, à l'obtention de données par l'intermédiaire d'une interface de communication en champs proches, lorsqu'une telle interface est nécessaire à l'exécution (validation) de la transaction ; la configuration de l'application de validation de transaction AppVT est effectuée en fonction des données intermédiaire reçues : les données intermédiaires permettent de construire une structure de données chargée en mémoire vive qui contraint l'exécution de l'application de validation de transaction, notamment en termes d'interfaces de communication à utiliser (ultrasonore, caméra, champs proche, WAN, WLAN) : le fonctionnement de l'application est simple et direct et permet la saisie, la validation, la correction et l'annulation - l'annulation par exemple provoque la fermeture de l'application et la déchargement des données de la mémoire vive ; l'application de validation de transaction AppVT est construite par le fabricant du terminal de professionnel (TProf) (ou un affilié ou un partenaire) pour répondre aux besoins spécifiques de validation que ce fabricant souhaite adresser : l'application ne sera bien entendu pas la même pour une validation de réception de colis ou pour une validation de transaction d'accès ou une transaction de paiement ; L'application met en oeuvre des opération cryptographiques (qui sont décrites par la suite) et notamment un chiffrement des données saisies par l'utilisateur en fonction des données intermédiaires (qui peuvent comprendre des clés de chiffrement) ou en fonction des clés contenues dans la configuration de l'application lorsque celle-ci est téléchargée et exécutée à la volée par le terminal de communication.
Une fois la transaction validée, le dispositif de communication d'utilisateur (DTon) de l'utilisateur communique (A40) cette information de validation (InfoVal) au terminal du professionnel (TProf), soit directement, en transmettant une donnée de validation en ce sens à celui-ci, soit indirectement, par l'intermédiaire du serveur transactionnel (ServT) qui se charge de communiquer ensuite la donnée de validation au terminal du professionnel. Lorsqu'un serveur transactionnel est utilisé (ce qui n'a pas de caractère obligatoire), la validation comprend une étape de transmission des données intermédiaires et du résultat de validation, au serveur transactionnel auquel le dispositif de communication d'utilisateur (Dton) est connecté par l'intermédiaire de l'application de validation (AppVT), puis une étape de validation, par le serveur transactionnel, des données intermédiaires et du résultat de validation, comprenant une vérification des opérations cryptographiques de validation effectuées par ladite l'application de validation (AppVT) et une étape de transmission, au terminal de mise en oeuvre de transaction d'un professionnel (TProf), du résultat de validation de transaction, lorsque la vérification des opérations cryptographiques de validation délivre un résultat positif. Ces quatre étapes, mises en œuvre de façon ordonnée au sein du système présenté en figure 1, permettent d'assurer à la fois la sécurité des données saisies par l'utilisateur (ces données ne sont pas fournies en tant que telles au professionnel), tout en assurant au professionnel, présent au moment de la mise en œuvre de ces étapes, que l'utilisateur est bien en capacité de réaliser cette transaction (i.e. qu'il possède la capacité de le faire et éventuellement les outils nécessaires, i.e. le du dispositif transactionnel additionnel (DTa)). De plus, dans un contexte sanitaire sensible, cette mise en œuvre permet d'éviter à l'utilisateur d'entrer en contact avec le matériel du professionnel.
On présente, en relation avec la figure 3, une architecture simplifiée d'un terminal électronique de professionnel (TProf) apte à effectuer le traitement d'initiation de transaction tel que présenté précédemment. Un terminal électronique de professionnel comprend un premier module électronique comprenant une mémoire 31, une unité de traitement 32 équipée par exemple d'un microprocesseur, et pilotée par un programme d'ordinateur 33. Le terminal électronique de professionnel peut comprendre également un deuxième module électronique comprenant une mémoire sécurisée 34, qui peut être fusionnée avec la mémoire 31 (comme indiqué en pointillés, dans ce cas la mémoire 31 est une mémoire sécurisée), une unité de traitement sécurisée 35 équipée par exemple d'un microprocesseur sécurisée et de mesure physiques de protection (protection physique autour de la puce, par treillis, vias, etc. et protection sur les interfaces de transmission de données), et pilotée par un programme d'ordinateur 36 spécifiquement dédié à cette unité de traitement sécurisée 35, ce programme d'ordinateur 36 mettant en œuvre toute ou partie du procédé de traitement d'une transaction tel que précédemment décrit. Le groupe composé de l'unité de traitement sécurisée 35, de la mémoire sécurisée 34 et du programme d'ordinateur dédié 36 constitue le module sécurisé (PS) du dispositif électronique. Dans au moins un exemple de réalisation, la présente technique est mise en œuvre sous la forme d'un ensemble de programmes installé en partie ou en totalité sur cette portion sécurisée du terminal de traitement ou d'initialisation de transaction. Dans au moins un autre exemple de réalisation, la présente technique est mise en œuvre sous la forme d'un composant dédié (CpX) pouvant traiter des données des unités de traitement et installé en partie ou en totalité sur la portion sécurisée du terminal électronique de professionnel. Par ailleurs, le terminal électronique de professionnel comprend également des moyens de communication (CIE) se présentant par exemple sous la forme de composants réseaux (WiFi, 3G/4G/5G, filaire) qui permettent au terminal électronique de professionnel de recevoir des données (I) en provenance d'entités connectées à un ou plusieurs réseaux de communication et des transmettre des données traitées (T) à de telles entités. Un tel terminal électronique de professionnel comprend, en fonction des modes de réalisation : des moyens d'obtention de données en provenance de dispositifs transactionnels présentés des utilisateurs (carte d'accès, carte de transaction, etc. ; ces moyens peuvent se présenter, par exemple, sous la forme de lecteur de cartes à puces, ou encore de lecteurs de cartes sans contact de type NFC ou de type RFID) ; des moyens de saisie, permettant au professionnel de saisir une ou plusieurs données pour la mise en oeuvre de la transaction, lorsque cela est nécessaire (clavier de saisie physique, écran, clavier de saisie virtuel) ; des moyens de traitement des données obtenues par les moyens d'obtention de données en provenance des dispositifs transactionnels et des moyens de traitement des données saisies par le professionnel ; ces moyens sont matérialisés par exemple sous la forme d'un composant spécifique ; des moyens de traitement d'une transaction, comprenant des moyens d'initialisation de transaction ; des moyens de fourniture de données à un ou plusieurs serveurs transactionnels connectés au terminal électronique de professionnel : ces moyens se présentent typiquement sous la forme d'interfaces de communication réseau, de type interface filaire (RTC, Ethernet) ou interface sans fil (3G/4G, Wifi) ; des moyens de fourniture de données à un dispositif de mise en oeuvre de transaction, appartenant à un utilisateur (e.g. smartphone, tablette) : ces moyens de fourniture de données peuvent se présenter, par exemple, sous la forme d'un écran, sur lequel ces données sont affichées, ou encore d'un composant d'émission d'ultrasons (buzzer ultrasonore), ou encore d'un composant d'émission de données radio en champ proche ;
Comme explicité précédemment, ces moyens sont mis en oeuvre par l'intermédiaire de modules et/ou de composants, par exemple, mais non nécessairement sécurisés. Ils permettent ainsi d'assurer la sécurité des transactions réalisées tout en garantissant une plus grande maintenabilité du dispositif.
Le dispositif de communication d'utilisateur (DTon), pour sa part, se présente généralement comme un terminal de communication de type mobile (i.e. smartphone, tablette) qui est en possession de l'utilisateur au moment de la réalisation de la transaction en présence du professionnel. Un tel dispositif comprend outre les moyens usuels, des moyens de mise en oeuvre de transaction, selon le procédé précédemment décrit. Ces moyens se présentent sous la forme d'une application exécutée sur le terminal, lui conférant la qualité de dispositif de communication d'utilisateur (DTon). Dans un exemple de réalisation particulier, cette application est une application configurée dynamiquement sur le terminal de l'utilisateur. Plus particulièrement, cette application est configurée dynamiquement à la réception, sur le dispositif de mise en oeuvre de transaction, des données intermédiaires comprenant l'identifiant unique du terminal du professionnel et le (pré)identifiant unique de transaction et ; lorsque nécessaire, une donnée d'instanciation. A réception de ces données, l'application est dynamiquement configurée et exécutée. Elle affiche, à destination de l'utilisateur, les données relatives à la transaction (comme par exemple un identifiant ou un nom du professionnel concerné ou autre comme décrit dans les modes de réalisation suivants).
Plusieurs exemples de réalisation de la méthode objet de la divulgation sont décrits par la suite Exemple de réalisation 1 : liyraison d'un colis par un liyreur
On décrit, dans cet exemple de réalisation, l'exécution d'une transaction dissociée dans le cadre d'une livraison d'un colis réalisée par un livreur (professionnel) chez un particulier (utilisateur). Le livreur est équipé d'un terminal électronique de livraison (il s'agit du terminal du professionnel). Dans cet exemple de réalisation, une fois les étapes administratives effectuées (i.e. vérification de l'identité de l'utilisateur par le livreur, notamment, inspection de l'état du colis par l'utilisateur), le processus de traitement de transaction dissociée est mis en oeuvre, selon les étapes précédemment décrites en relation avec la figure 2.
Plus particulièrement, dans cet exemple de réalisation : la préparation de la transaction par le terminal du professionnel (livreur) comprend l'obtention de l'identifiant du terminal au sein d'une mémoire de ce terminal du professionnel et la préparation, par le processeur de traitement, d'un identifiant de transaction ; En plus, une donnée représentative d'une adresse de localisation (sur le réseau de communication ou dans une boutique applicative) d'une application instantanée à instancier sur le dispositif de communication d'utilisateur (i.e. le terminal mobile ou la tablette) de l'utilisateur est obtenue, par exemple au sein de la mémoire du terminal du professionnel, formant l'ensemble des données intermédiaires ; Une étape de protection d'au moins certaines de ces données est mise en oeuvre : l'identifiant du terminal et l'identifiant de transaction sont chiffrés ; À partir de l'ensemble des données intermédiaires, un fichier de transmission de ces données est construit ; le fichier de transmission de ces données peut prendre la forme : d'un fichier image, comprenant un QR Code ou encre d'une séquence ultrasonore modulée ; Le fichier image est affiché sur le terminal du professionnel ; la séquence ultrasonore est émise à partir du terminal du professionnel (on note que ces deux formes de transmission de l'information au dispositif de communication d'utilisateur peuvent être mise en oeuvre simultanément) ; La préparation de la transaction est ainsi finalisée ; Dans cet exemple de réalisation, le QR-Code ou la séquence ultrasonore modulée représente le canal de transmission principal des données intermédiaires ;
Le dispositif de communication d'utilisateur (le terminal mobile ou la tablette) de l'utilisateur reçoit le fichier des données intermédiaires en provenance du terminal du professionnel (soit par lecture du QR-Code, soit par réception de la séquence ultrasonore) ; Les données sont décodées (en fonction du format de codage de données utilisé) et le dispositif de communication d'utilisateur (DTon) de l'utilisateur est configuré (configuration dynamique) : une requête est transmise par le dispositif de l'utilisateur à l'adresse de localisation d'une application instantanée avec en paramètre les données identifiant du terminal du professionnel et identifiant de transaction ; l'application instantanée est immédiatement téléchargée et exécutée sur le dispositif de communication d'utilisateur (DTon) ; Cette application instantanée affiche une interface utilisateur comprenant : les informations relatives au colis, obtenues à partir d'un serveur transactionnel (ServT) de la société de livraison (ou d'un autre serveur transactionnel) et une zone de signature (permettant à l'utilisateur de signer avec le doigt ou avec un stylet sur l'écran tactile de son terminal) et un triplet de boutons (« annulation », « correction », « validation ») ; Ceci achève la fin de la configuration dynamique du dispositif d'utilisateur ;
S'ensuit l'étape de validation de la transaction, consistant pour l'utilisateur à effectuer sa signature sur l'écran de son dispositif (avec un doigt ou avec un stylet), puis à valider cette saisie en sélectionnant le bouton « validation » ; Un message est affiché à destination de l'utilisateur pour l'informer la saisie ;
Une fois cette saisie/validation effectuée par l'utilisateur, l'application instantanée effectue une validation de la transaction en calculant un hachage de la signature de l'utilisateur, en codant l'image de la signature à l'aide d'une clé, obtenue par exemple à partir du hachage réalisé, puis en ajoutant ces données (hash de la signature, image de la signature) aux données intermédiaires ; L'ensemble des données résultantes est transmis au serveur transactionnel (ServT), et l'application instantanée est désinstallée ; Le serveur transactionnel (ServT) réceptionne les données transmises par l'application instantanée et transmet un message à destination du terminal du livreur l'informant de la validation de la transaction.
Ainsi, grâce à cette mise en oeuvre, l'utilisateur a été en mesure de réceptionner son colis, tout en évitant d'une part de saisir des informations sensibles sur le terminal du professionnel et d'autre part en sécurisant la transmission de ces données, par voie de chiffrement notamment, au serveur transactionnel. L'utilisateur n'a pas non plus eu besoin d'entrer en contact physique avec le terminal du professionnel, préservant la sécurité sanitaire. Également, aucune application n'est définitivement installée sur le dispositif de l'utilisateur, l'application instantanée résidant uniquement en mémoire volatile du dispositif de l'utilisateur.
Exemple de réalisation 2 : accès à des locaux protégés par un terminal d'accès On décrit, dans cet exemple de réalisation, l'exécution d'une transaction dissociée dans le cadre d'un accès à des locaux protégés, par l'intermédiaire d'un terminal d'accès (terminal du professionnel) à carte, par une personne souhaitant accéder à ces locaux (utilisateur). Le terminal du professionnel est équipé d'un lecteur de cartes à puce, qui est utilisé par l'utilisateur pour accéder aux locaux. Le terminal d'accès peut être connecté à un réseau de communication (par exemple un réseau mobile) et il dispose de données relatives à l'utilisateur (notamment un numéro de téléphone, qu'il peut utiliser pour transférer une notification au terminal de l'utilisateur).
Le processus de traitement de transaction dissociée est mis en oeuvre, selon les étapes précédemment décrites en relation avec la figure 2, postérieurement à la demande d'accès aux locaux formulée par l'utilisateur (par exemple en insérant sa carte d'accès dans le lecteur du terminal d'accès, ou bien par tout moyen utilisable sur le terminal d'accès, comme un bouton physique par exemple) : la préparation de la transaction par le terminal d'accès comprend l'obtention de l'identifiant du terminal d'accès au sein d'une mémoire de ce terminal et la préparation, par le processeur de traitement, d'un identifiant de transaction ; En plus, si n'est déjà fait, un message d'insertion de carte d'accès est affiché à destination de l'utilisateur ; celui-ci insère alors sa carte d'accès au sein du lecteur de cartes à puce ; la préparation de la transaction se poursuit alors par une interrogation de la carte d'accès par le terminal d'accès, afin d'obtenir une clé publique de la carte d'accès notamment ; cette clé publique est insérée dans l'ensemble de données intermédiaires ; l'ensemble de données intermédiaires, après d'éventuelles opérations de contrôles complémentaires (notamment contrôle de la validité de la carte d'accès), est alors chiffré en utilisant une clé privée du terminal d'accès ; un fichier de transmission de ces données intermédiaires chiffrées est construit, et le fichier est transmis au terminal de l'utilisateur par l'intermédiaire du réseau de communication auquel le terminal d'accès est connecté ; Dans cet exemple de réalisation, le réseau de communication représente le canal de transmission principal des données intermédiaires ; le dispositif DTon de l'utilisateur reçoit le fichier des données intermédiaires en provenance du terminal d'accès, par exemple par l'intermédiaire d'un SMS ou d'un autre message transmis sur le réseau de communication ; Les données du fichier sont déchiffrées à l'aide de la clé publique du terminal d'accès (cette clé publique a été transmise au dispositif Dton par ailleurs, comme explicité plus loin) et le dispositif de communication d'utilisateur (DTon) de l'utilisateur est dynamiquement configuré : une application de saisie de code PIN, avec en paramètre les données identifiant du terminal du terminal d'accès et identifiant de transaction est exécutée sur le dispositif de communication d'utilisateur (DTon) ; Cette application affiche une interface utilisateur de saisie de code PIN comprenant : les informations relatives à l'accès, obtenues à partir des données intermédiaires et une zone de saisie de code PIN (permettant à l'utilisateur de saisir le code confidentiel de la carte d'accès qu'il a inséré dans le terminal d'accès) et un triplet de boutons (« annulation », « correction », « validation ») ; Cette application de saisie est par exemple préinstallée par l'utilisateur ou bien disponible nativement sur le dispositif de communication d'utilisateur (DTon) ; Ceci achève la configuration dynamique du dispositif d'utilisateur ;
S'ensuit l'étape de validation de la transaction, consistant pour l'utilisateur à effectuer la saisie du code PIN sur l'écran de son dispositif, puis à valider cette saisie en sélectionnant le bouton « validation » ; Un message est affiché à destination de l'utilisateur pour l'informer la saisie ; Une fois cette saisie/validation effectuée par l'utilisateur, l'application effectue une validation de la transaction en effectuant une opération de chiffrement du code PIN saisi à l'aide de la clé publique de la carte présente dans les données intermédiaires reçues ; ce PIN chiffré est ajouté aux données intermédiaires déchiffrées initialement reçues et un chiffrement de l'ensemble est ensuite réalisé avec la clé publique du terminal d'accès ; L'ensemble des données résultantes est transmis au terminal d'accès par exemple par l'intermédiaire d'un message de type SMS, et l'application de saisie de code PIN est arrêtée ; Le terminal d'accès réceptionne les données transmises par l'application, les déchiffre à l'aide de sa clé privée, vérifie que les données intermédiaire sont correctes et transmet le code PIN chiffré à la carte à puce insérée dans le lecteur de cartes à puce du terminal d'accès ; la carte à puce de l'utilisateur déchiffre le code PIN à l'aide de sa clé privée et vérifie la validité de celui- ci : si le code PIN saisi est valide, la carte à puce peut former un certificat à destination du terminal d'accès en réponse à la requête de validation ; le terminal d'accès réceptionne ce certificat le vérifie et autorise l'accès aux locaux.
Ainsi, grâce à cette mise en oeuvre, l'utilisateur a été en mesure d'accéder aux locaux protégés par le terminal d'accès, tout en évitant d'une part de saisir des informations sensibles sur le terminal d'accès lui-même et d'autre part en sécurisant la transmission de ces données, par voie de chiffrement notamment, au terminal d'accès. L'utilisateur n'a pas non plus eu besoin d'entrer en contact physique avec le terminal d'accès, préservant la sécurité sanitaire.
Pour cette mise en oeuvre, on suppose que le terminal de l'utilisateur dispose de la clé publique du terminal d'accès, clé qui lui est communiquée séparément. Pour ce faire, plusieurs variantes sont envisagées. Une première variante consiste à installer la clé publique du terminal d'accès lors de la configuration du terminal de communication de l'utilisateur : cette configuration peut être réalisée par l'autorité qui gère l'accès aux locaux protégés par le terminal d'accès. Cette clé publique peut être inscrite au sein d'un certificat qui est installé dans une zone mémoire protégée du terminal de communication de l'utilisateur. L'avantage de cette mise en oeuvre est qu'elle permet, pour l'autorité qui gère l'accès aux locaux protégés, d'assurer que chaque terminal d'utilisateur est identifié et que la clé publique du terminal d'accès ne circule pas inutilement.
Une deuxième variante consiste à diffuser la clé publique du terminal d'accès au moment de la mise en oeuvre de la transaction dissociée. Dans ce cas de figure, la clé publique du terminal d'accès est transmise au terminal de communication de l'utilisateur en utilisant un canal de transmission différent de celui utilisé pour la transmission des données intermédiaires. Ce canal de transmission est appelé canal auxiliaire et il est utilisé pour sécuriser la transmission de cette clé publique. Ce canal de transmission auxiliaire peut typiquement prendre la forme d'un signal ultrasonore modulé, le signal codant un enregistrement de données comprenant d'une part la clé publique du terminal d'accès (cette clé publique peut être une clé de session, temporaire) et d'autre part une donnée de vérification de conformité. Dans cette deuxième variante, le procédé de transmission de cette clé publique est la suivant : lorsque l'utilisateur insère sa carte d'accès dans le lecteur de carte du terminal d'accès, le terminal d'accès, lors l'étape de préparation de la transaction, diffuse, en utilisant le canal auxiliaire (i.e. par voie ultrasonore), l'enregistrement de données comprenant la clé publique du terminal d'accès. Cette diffusion n'est réalisée qu'après l'insertion de la carte d'accès dans le lecteur du terminal d'accès et que le terminal d'accès a vérifié la validité de cette carte d'accès (par exemple qu'elle ne fait pas partie d'une liste de cartes bannies, ou qu'elle n'est pas désactivée - trop ancienne). Le terminal de communication de l'utilisateur capte cette diffusion et acquiert l'enregistrement de données comprenant la clé publique du terminal d'accès et la donnée de vérification de conformité. Cette diffusion, par le terminal d'accès, peut être cyclique (c'est-à-dire être répétée), jusqu'à la transmission, par le terminal d'accès, des données intermédiaires de la transaction au terminal de communication de l'utilisateur (par l'intermédiaire du canal principal, i.e. SMS ou autre type de transmission sur le réseau de communication). L'avantage de cette mise en oeuvre est qu'elle permet au terminal d'accès de définir des clés temporaires dont l'usage est limité à une seule transaction : en effet, la clé publique du terminal est alors une clé de session et la clé privée correspondante est également une clé de session. Qui plus est, la transmission de cette clé n'étant initiée qu'à partir du moment ou la carte d'accès de l'utilisateur est insérée dans le lecteur du terminal d'accès, cette clé peut être spécifiquement dédiée à la carte d'accès de l'utilisateur.
En fonction des variantes de réalisation, il peut être envisagé d'inverser les rôles des canaux de communication : le canal principal peut être le canal ultrasonore, utilisé pour transmettre les données intermédiaires de transaction et le canal secondaire peut être le réseau de communication, utilisé pour transmettre la clé publique du terminal d'accès.
Exemple de réalisation 3 : paiement à l'aide d'un terminal de paiement
On décrit, dans cet exemple de réalisation, l'exécution d'une transaction dissociée dans le cadre d'un paiement, par l'intermédiaire d'un terminal de paiement (terminal du professionnel) à carte, par une personne souhaitant effectuer un paiement de biens ou de services (utilisateur) chez un commerçant. Le terminal du professionnel (terminal de paiement) est généralement équipé d'un lecteur de cartes à puce, dont l'utilisation n'est pas nécessaire dans le cadre de cet exemple de réalisation. Le terminal de paiement est connecté à un réseau de communication (par exemple un réseau mobile ou le réseau de communication du commerce, e.g. réseau Wifi, Ethernet) et il peut disposer de données relatives à l'utilisateur (notamment un numéro de téléphone, dans le cadre d'un compte de fidélité par exemple). En fonction des variantes, l'insertion de la carte de paiement de l'utilisateur dans le terminal de paiement peut être requise : auquel cas, les traitements mis en oeuvre sont identiques au deuxième exemple de réalisation et la puce de la carte de paiement est utilisée dans le lecteur de cartes à puce du terminal de paiement pour effectuer une transaction de paiement à la place d'une transaction d'accès. Dans ce troisième exemple de réalisation, l'insertion de la carte de paiement dans le terminal de paiement n'est pas nécessaire : la carte de paiement est utilisée par le terminal de communication de l'utilisateur DTon, comme cela est décrit par la suite.
Le processus de traitement de transaction dissociée est mis en oeuvre, selon les étapes précédemment décrites en relation avec la figure 2, postérieurement à la demande de paiement formulée par le commerçant (par exemple en requérant le paiement des biens ou des services à l'utilisateur) : la préparation de la transaction par le terminal de paiement comprend l'obtention de l'identifiant du terminal de paiement (au sein d'une mémoire de ce terminal ou par l'intermédiaire du serveur transactionnel auquel le terminal de paiement est connecté, décrit par la suite) et la préparation, par le processeur de traitement sécurisé du terminal de paiement, d'un identifiant de transaction ; la préparation de la transaction comprend également l'ajout, aux données intermédiaires, des données de montant des achats, date, heure, etc. ; l'ensemble de données intermédiaires, après d'éventuelles opérations de contrôles complémentaires, est alors chiffré en utilisant une clé privée du terminal de paiement ; un fichier de transmission de ces données intermédiaires chiffrées est construit, et le fichier est transmis au terminal Dton de l'utilisateur par l'intermédiaire du réseau de communication auquel le terminal de paiement est connecté ; Dans cet exemple de réalisation, le réseau de communication représente le canal de transmission principal des données intermédiaires ; le dispositif DTon de l'utilisateur reçoit le fichier des données intermédiaires en provenance du terminal de paiement, par exemple par l'intermédiaire d'un SMS ou d'un autre message transmis sur le réseau de communication ; Les données du fichier sont déchiffrées à l'aide de la clé publique du terminal de paiement (cette clé publique a été transmise au dispositif Dton par ailleurs, comme explicité dans le deuxième exemple de réalisation) et le dispositif de communication d'utilisateur (DTon) de l'utilisateur est dynamiquement configuré : une application de validation de transaction de paiement (par exemple l'application bancaire de l'utilisateur, préinstallée sur son terminal), avec en paramètre les données identifiant du terminal du terminal de paiement et pré-identifiant de transaction est exécutée sur le dispositif de communication d'utilisateur (DTon) ; Cette application affiche les données de la transaction à destination de l'utilisateur, comme si l'utilisateur visualisait l'écran du terminal de paiement; Cette application de saisie est par exemple préinstallée par l'utilisateur ou bien disponible nativement sur le dispositif de communication d'utilisateur (DTon) ; Ceci achève la configuration dynamique du dispositif d'utilisateur ;
S'ensuit l'étape de validation de la transaction, consistant pour l'utilisateur à :
Apposer sa carte de paiement au dos de son terminal de communication, qui dans cet exemple de réalisation est une carte sans contact (NFC) ; cette apposition entraîne la lecture des données de la carte bancaire sur le terminal de communication de l'utilisateur (numéro de carte, date, cvv, nom) et déclenche l'affichage d'une interface utilisateur de saisie de code PIN comprenant : les informations relatives à l'accès, obtenues à partir des données intermédiaires et une zone de saisie de code PIN (permettant à l'utilisateur de saisir le code confidentiel de sa carte de paiement) et un triplet de boutons (« annulation », « correction », « validation ») ;
Effectuer la saisie du code PIN sur l'écran de son dispositif, puis à valider cette saisie en sélectionnant le bouton « validation » ; Un message est affiché à destination de l'utilisateur pour l'informer la saisie ;
Optionnellement, apposer à nouveau sa carte de paiement au dos de son terminal de communication, afin que la carte vérifie la validité du code PIN saisit et fournisse un certificat de transaction.
Une fois cette saisie/validation effectuée par l'utilisateur, l'application effectue une validation de la transaction en générant un certificat de transaction à l'aide des données de la carte bancaire, et en fonction du nombre de fois où la carte a été apposée au dos du terminal de communication de l'utilisateur ; les données de transaction et le certificat de transaction sont alors transmis au serveur transactionnel ;
Le serveur transactionnel valide la transaction reçue de la part du terminal de communication de l'utilisateur et transmet, au terminal de paiement du commerçant des données de confirmation de la transaction ;
Le terminal de paiement réceptionne les données transmises par le serveur transactionnel : le commerçant est alors informé de la validation de la transaction. Ainsi, grâce à cette mise en œuvre, l'utilisateur a été en mesure de réaliser le paiement de ses achats, tout en évitant d'une part de saisir des informations sensibles sur le terminal de paiement lui- même (qui comme cela a été rappelé précédemment peut être un simple terminal de communication comprenant des fonction de paiement pour le commerçant, comme par exemple des terminaux de communication avec des lecteurs de carte additionnels de type Square™, se branchant sur le terminal de communication) et d'autre part en sécurisant la transmission de ces données, par voie de chiffrement notamment, au serveur transactionnel directement, sans passer par le terminal du commerçant. L'utilisateur n'a pas non plus eu besoin d'entrer en contact physique avec le terminal du commerçant, préservant la sécurité sanitaire.
Exemple de réalisation 4 : paiement à l'aide d'un terminal de paiement Comme dans le précédent exemple de réalisation, le principe est ici encore de dissocier la réalisation de la transaction en utilisant trois entité distinctes, comme explicité précédemment. La méthode est à nouveau destinée à permettre de réaliser un paiement entre un marchand physique (i.e. se trouvant dans une boutique) et un client (utilisateur), qui est également physiquement dans la boutique du marchand et qui souhaite réaliser un paiement pour des biens ou des services qu'il achète.
Le processus de traitement de transaction dissociée est mis en œuvre, selon les étapes précédemment décrites, postérieurement à la demande de paiement formulée par le commerçant (par exemple en requérant le paiement des biens ou des services à l'utilisateur)
Le terminal de paiement obtient, en provenance du serveur transactionnel, des données relatives à l'établissement bancaire auprès duquel le commerçant est enregistré, notamment, un identifiant lié au terminal de paiement, à partir d'un compte du commerçant ;
Le terminal de paiement du commerçant transmet, au dispositif Dton, d'au moins « une clé d'activation sécurisée » (ou une paire de clé d'activation) qui forment les données intermédiaires, obtenue notamment à partir de l'identifiant lié au terminal de paiement ; La transmission de cette clé est réalisée, selon un premier exemple de réalisation, par l'intermédiaire d'un signal transmis du terminal de paiement du commerçant à destination du dispositif Dton, qui se trouve physiquement à côté du commerçant (et de son terminal de paiement) (i.e. QR-Code ou Ultrason ou « proxy transactionnel cloud, serveur transactionnel », i.e. réseau de transmission de données) ; o La réception de cette (ces) clé(s), faisant office de données intermédiaires, entraîne l'activation de l'application AppV sur le terminal de communication de l'utilisateur. Cette application est préinstallée par l'utilisateur, ou encore il s'agit de l'application de sa banque, ou alors il s'agit d'une application instantanée à usage unique, comme dans le cas de la réception d'un colis présenté précédemment ;
En plus de la réception de la clé d'activation sécurisée, l'application AppV du terminal de communication de l'utilisateur reçoit « les paramètres du marchand », à utiliser pour effectuer la transaction (qui comprennent notamment par exemple une « limite plancher ») ; o Une « limite plancher » est un montant, par exemple en euros, au-dessus duquel les transactions par carte de crédit doivent être autorisées (c'est-à-dire faire l'objet d'une autorisation par le réseau de carte bancaire). o dans cet exemple de réalisation, on oblige à ce que la transaction soit autorisée par le réseau ;
Un mécanisme d'acquisition (« acquiring service ») opère la transaction à partir d'un serveur transactionnel de comptes marchands (donc en provenance de la banque) en lien avec le terminal de communication de l'utilisateur et l'application AppV, comme explicité précédemment ;
Un mécanisme de compensation (« clearing service ») identifie, à partir des données transactionnelles obtenues, une méthode qui permette de valider la transaction ; le statut de la transaction est communiqué au terminal (de paiement) du marchand et le crédit (i.e. la somme d'argent) est inscrit sur le compte bancaire du marchand ; Ce mécanisme de compensation est opéré à partir d'un serveur transactionnel de la banque du marchand ;
Le terminal du marchand reçoit, en provenance du serveur transactionnel qui a exécuté la transaction (i.e le serveur mettant en oeuvre le mécanisme de compensation), un résultat de cette transaction (sous la forme d'un message chiffré). Le résultat de la transaction est sécurisé par l'utilisation de la (ou des) clé d'activation qui ont été transmises au terminal de communication par le terminal de paiement.
Ainsi, dans cet exemple de réalisation, le procédé consolidé mis en oeuvre est le suivant :
Une étape (préalable) de souscription est mise en oeuvre par le marchand (optionnelle pour l'utilisateur, notamment pour instant App côté client) ;
Le marchand sélectionne la méthode de paiement idoine sur le terminal de paiement (et saisit ou reçoit le montant à payer à partie de la caisse enregistreuse) ; en fonction des conditions de mise en oeuvre opérationnelles, l'utilisateur peut insérer sa carte dans le terminal de paiement (i.e. par exemple en fonction du montant de la transaction à exécuter) ; le mécanisme mis en œuvre permet au client de saisir son PIN sur son terminal de communication ;
Le terminal de paiement reçoit une information de la part du serveur transactionnel, notamment l'identifiant de la transaction et la (ou les) clé(s) pour le processus de validation de transaction ; il requiert ces données auprès du serveur transactionnel ;
L'application du terminal de communication de l'utilisateur est activée (et téléchargée au s'il s'agit d'une application instantanée) - l'activation peut être manuelle (démarrage par l'utilisateur ou automatique (notification, i.e. application en arrière-plan, avec réseau de données du terminal de communication) ou bien être subséquente à la transmission d'une information par le terminal de paiement du marchand (QR scanné par l'utilisateur, sur écran terminal de paiement ultrasons émis à partir du buzzer du terminal de paiement et reçus par le terminal de communication, NFC). o En même temps qu'elle est activée, l'application du terminal de communication de l'utilisateur reçoit l'identifiant de la transaction et la (ou les) clé(s) (soit de la part du terminal de paiement du marchand, soit de la part du serveur transactionnel : lorsqu'il c'est le serveur transactionnel, celui-ci est informé du terminal de communication par l'intermédiaire de l'identifiant du terminal de communication de l'utilisateur (par exemple son numéro de téléphone).
Sur la base de l'I'identifiant de transaction et de la clé (ou des clés) le terminal de communication de l'utilisateur transmet une requête d'obtention de données de transaction et de paramètres de paiement (du marchand) au mécanisme d'acquisition (pour recevoir la limite plancher notamment) du serveur transactionnel ; o Le dispositif Dton dispose alors du montant à régler et de l'identification du marchand : cela permet d'assurer que les informations affichées sur le terminal du marchand (et/ou la caisse enregistreuse) sont identiques à celles visualisées sur le terminal de communication de l'utilisateur ; o En d'autres termes, le serveur transactionnel comprend des moyens de détermination d'I'identifiant de transaction et des moyens de génération de clé pour pouvoir échanger des données de manière sécurisée avec le terminal de communication de l'utilisateur pour le compte du marchand et il dispose d'une sauvegarde des paramètres du marchand, tels qu'associés au terminal de paiement de celui-ci ; l'avantage complémentaire procuré est que le terminal du commerçant peut être dénué de fonctions complexes de traitement de transaction, ces fonctions complexes étant gérées au niveau du serveur transactionnel d'une part et du terminal de communication de l'utilisateur d'autre part ;
Ensuite, l'application du terminal de communication procède à la mise en oeuvre de la transaction (comme explicité dans les deuxièmes et troisièmes exemples de réalisation). L'application du terminal de communication et le serveur transactionnel complètent la transaction EMV.
Ensuite, un traitement de réseau de paiement est mis en oeuvre (card network) : le serveur transactionnel transmet un message de complétion de la transaction au mécanisme de compensation (qui se charge de transférer le montant de la transaction sur le compte du marchand) ; - Le mécanisme de compensation transmet le message de complétion de la transaction au terminal de paiement du marchand ;
Le serveur transactionnel informe également l'application du terminal de communication que la transaction est complétée.

Claims

REVENDICATIONS
1. Procédé d'exécution d'une transaction entre un terminal de mise en oeuvre de transaction d'un professionnel (TProf) et un dispositif de communication d'utilisateur (Dton) qui est situé à proximité du terminal de mise en oeuvre de transaction du professionnel (TProf), procédé caractérisé en ce qu'il comprend une étape de préparation (A10) de la transaction à exécuter au sein terminal de mise en oeuvre de transaction du professionnel (TProf), délivrant au moins une donnée intermédiaire d'exécution de transaction ; une étape de transmission (A20) de ladite au moins une donnée intermédiaire d'exécution de transaction au dispositif de communication d'utilisateur (Dton) ; et une étape d'exécution (A30) de la transaction par le dispositif de communication d'utilisateur (Dton) à l'aide de ladite au moins une donnée intermédiaire d'exécution de transaction et d'au moins une donnée personnelle (Sgn, PIN) de l'utilisateur qui détient le dispositif de communication d'utilisateur (Dton), ladite exécution délivrant un résultat d'exécution transmis (A40) au terminal de mise en oeuvre de transaction du professionnel (TProf).
2. Procédé selon la revendication 1, caractérisé en ce que l'étape d'exécution (A30) de la transaction par le dispositif de communication d'utilisateur (Dton) à l'aide de ladite au moins une donnée intermédiaire d'exécution de transaction et d'au moins une donnée personnelle (Sgn, PIN) de l'utilisateur qui détient le dispositif de communication d'utilisateur (Dton) comprend une étape d'obtention, par le dispositif de communication d'utilisateur (Dton), d'au moins une donnée en provenance d'un dispositif transactionnel additionnel (DTa) en possession de l'utilisateur.
3. Procédé selon la revendication 2, caractérisé en ce que l'étape d'obtention, par le dispositif de communication d'utilisateur (Dton), de ladite au moins une donnée en provenance du dispositif transactionnel additionnel (DTa) en possession de l'utilisateur comprend : une étape d'émission, par le dispositif de communication d'utilisateur (Dton), d'une requête d'obtention de données transactionnelles, ladite étape d'émission utilisant une interface de communication en champs proche (NFC) du dispositif de communication d'utilisateur (Dton) ; une étape de réception, par le dispositif de communication d'utilisateur (Dton), d'une réponse à ladite requête d'obtention de données transactionnelles par l'intermédiaire de interface de communication en champs proche (NFC) du dispositif de communication d'utilisateur (Dton).
4. Procédé selon la revendication 1, caractérisé en ce que l'étape d'exécution (A30) de la transaction par le dispositif de communication d'utilisateur (Dton) à l'aide de ladite au moins une donnée intermédiaire d'exécution de transaction et d'au moins une donnée personnelle (Sgn, PIN) de l'utilisateur qui détient le dispositif de communication d'utilisateur (Dton) comprend : une étape de réception de ladite au moins une donnée intermédiaire d'exécution de transaction par le dispositif de communication d'utilisateur (Dton) ; une étape de configuration dynamique du dispositif de communication d'utilisateur (Dton), en fonction de ladite au moins une donnée intermédiaire d'exécution, ladite étape de étape de configuration dynamique comprenant une étape d'exécution, au sein d'un espace mémoire dédié dudit dispositif de communication d'utilisateur (Dton), d'une application de validation (AppVT) pour la saisie de la dite au moins une donnée personnelle (Sgn, PIN) de l'utilisateur qui détient le dispositif de communication d'utilisateur (Dton) ; une étape de réception, par l'application de validation (AppVT), d'au moins une donnée saisie par ledit utilisateur ; une étape de validation, par l'application de validation (AppVT), de la transaction en fonction de ladite au moins une donnée saisie par ledit utilisateur et desdites données intermédiaires, délivrant un résultat de validation.
5. Procédé d'exécution selon la revendication 4, caractérisé en ce que postérieurement à l'étape de validation, par l'application de validation (AppVT), de la transaction en fonction de ladite au moins une donnée saisie par ledit utilisateur et desdites données intermédiaires, le procédé comprend : une étape de transmission desdites données intermédiaires et dudit résultat de validation, à un serveur transactionnel auquel le dispositif de communication d'utilisateur (Dton) est connecté par l'intermédiaire de l'application de validation (AppVT), une étape de validation, par le serveur transactionnel, desdites données intermédiaires et dudit résultat de validation, comprenant une vérification des opérations cryptographiques de validation effectuées par ladite l'application de validation (AppVT) ; une étape de transmission, au terminal de mise en oeuvre de transaction d'un professionnel (TProf), dudit résultat de validation de transaction, lorsque la vérification des opérations cryptographiques de validation délivre un résultat positif.
6. Procédé d'exécution selon la revendication 1, caractérisé en ce que l'étape étape de préparation (A10) de la transaction à exécuter au sein terminal de mise en oeuvre de transaction du professionnel (TProf) comprend : une étape d'obtention, à partir d'un dispositif transactionnel additionnel (DTa) en possession de l'utilisateur, d'au moins une clé de chiffrement destinée à être transmise au dispositif de communication d'utilisateur ; et une étape d'insertion, au sein de ladite au moins une donnée intermédiaire d'exécution, de ladite au moins une clé de chiffrement obtenue.
7. Procédé d'exécution selon la revendication 1, caractérisé en ce que l'étape de transmission (A20) de ladite au moins une donnée intermédiaire d'exécution de transaction au dispositif de communication d'utilisateur (Dton) comprend : une étape d'activation d'une interface de communication du terminal de mise en oeuvre de transaction d'un professionnel (TProf), pour la transmission par l'intermédiaire d'un canal principal ; une étape de transmission, par l'intermédiaire de l'interface de communication, d'un fichier comprenant ladite au moins une donnée intermédiaire.
8. Procédé d'exécution selon la revendication 7, caractérisé en ce que l'interface de communication activée pour la transmission du fichier comprenant ladite au moins une donnée intermédiaire appartient au groupe comprenant : une interface sonore, configurée pour émettre le fichier préalablement encodé sous la forme d'un signal ultrasonore ; un écran du terminal de mise en œuvre de transaction d'un professionnel (TProf), configurée pour afficher le fichier préalablement encodé sous la forme d'un code bidimensionnel ; une interface de transmission de données par l'intermédiaire d'un réseau de communication, configurée pour transmettre le fichier préalablement encodé sous la forme d'un message.
9. Système d'exécution d'une transaction, système comprenant un terminal de mise en œuvre de transaction d'un professionnel (TProf) et un dispositif de communication d'utilisateur (Dton) qui est situé à proximité du terminal de mise en œuvre de transaction du professionnel (TProf), système caractérisé en ce qu'il comprend des moyens de préparation de la transaction à exécuter implémentés au sein terminal de mise en œuvre de transaction du professionnel (TProf), délivrant au moins une donnée intermédiaire d'exécution de transaction ; des moyens de transmission de ladite au moins une donnée intermédiaire d'exécution de transaction au dispositif de communication d'utilisateur (Dton) ; et des moyens d'exécution de la transaction implémentés au sein du dispositif de communication d'utilisateur (Dton) à l'aide de ladite au moins une donnée intermédiaire d'exécution de transaction et d'au moins une donnée personnelle (Sgn, PIN) de l'utilisateur qui détient le dispositif de communication d'utilisateur (Dton), ladite exécution délivrant un résultat d'exécution et des moyens de transmission du résultat d'exécution au terminal de mise en œuvre de transaction du professionnel (TProf).
10. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions de code de programme pour l'exécution d'un procédé d'exécution d'une transaction selon l'une des revendications 1 à 8, lorsqu'il est exécuté sur un ordinateur.
EP22734521.2A 2021-06-04 2022-06-03 Procédé de traitement d'une transaction, dispositif et programme correspondant Pending EP4348459A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2105933A FR3123741A1 (fr) 2021-06-04 2021-06-04 procédé de traitement d’une transaction, dispositif et programme correspondant.
PCT/EP2022/065178 WO2022254002A1 (fr) 2021-06-04 2022-06-03 Procédé de traitement d'une transaction, dispositif et programme correspondant.

Publications (1)

Publication Number Publication Date
EP4348459A1 true EP4348459A1 (fr) 2024-04-10

Family

ID=77913177

Family Applications (1)

Application Number Title Priority Date Filing Date
EP22734521.2A Pending EP4348459A1 (fr) 2021-06-04 2022-06-03 Procédé de traitement d'une transaction, dispositif et programme correspondant

Country Status (4)

Country Link
EP (1) EP4348459A1 (fr)
CA (1) CA3220060A1 (fr)
FR (1) FR3123741A1 (fr)
WO (1) WO2022254002A1 (fr)

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9953311B2 (en) * 2013-09-25 2018-04-24 Visa International Service Association Systems and methods for incorporating QR codes
FR3023640B1 (fr) * 2014-07-10 2016-08-12 Roam Data Inc Procede de gestion d'une transaction, serveur, produit programme d'ordinateur et medium de stockage correspondants.
US10147094B2 (en) 2014-12-17 2018-12-04 Mastercard International Incorporated Method to enable consumers to make purchases at point of sale devices using their mobile number
US10127532B1 (en) 2015-08-19 2018-11-13 Square, Inc. Customized transaction flow
US20190066089A1 (en) * 2017-08-25 2019-02-28 Mastercard International Incorporated Secure transactions using digital barcodes

Also Published As

Publication number Publication date
CA3220060A1 (fr) 2022-12-08
FR3123741A1 (fr) 2022-12-09
WO2022254002A1 (fr) 2022-12-08

Similar Documents

Publication Publication Date Title
WO2015103971A1 (fr) Procédé et système pour vérifier des transactions à l'aide d'une carte intelligente
EP3163487B1 (fr) Procédé de sécurisation de traitement de données transactionnelles, terminal et programme d'ordinateur correspondant
EP3857413A1 (fr) Procede de traitement d'une transaction, dispositif, systeme et programme correspondant
EP3349160B1 (fr) Procédé de transmission de données, dispositif et programme correspondant
WO2016207715A1 (fr) Gestion securisee de jetons électroniques dans un telephone mobile.
EP3991381B1 (fr) Procédé et système de génération de clés de chiffrement pour données de transaction ou de connexion
EP3588418A1 (fr) Procédé de réalisation d'une transaction, terminal, serveur et programme d ordinateur correspondant
EP3542335B1 (fr) Procédé de traitement de données transactionnelles, terminal de communication, lecteur de cartes et programme correspondant
EP2824625B1 (fr) Méthode de réalisation de transaction, terminal et programme d'ordinateur correspondant
EP4348459A1 (fr) Procédé de traitement d'une transaction, dispositif et programme correspondant
WO2021116627A1 (fr) Procede, serveur et systeme d'authentification de transaction utilisant deux canaux de communication
FR2810759A1 (fr) Procede pour effectuer une transaction commerciale en ligne par l'intermediaire d'un reseau de communication et dispositif electronique pour passer des commandes commerciales en ligne
EP3570238B1 (fr) Procédé de réalisation d'une transaction, terminal, serveur et programme d'ordinateur correspondant
FR2985148A1 (fr) Methode d'appairage d'equipements electroniques
EP3349161A1 (fr) Procédé de traitement d'une transaction de paiement, borne de paiement et programme correspondant
WO2017005644A1 (fr) Procédé et système de contrôle d'accès à un service via un média mobile sans intermediaire de confiance
EP4016427A1 (fr) Procede pour la creation d'un instrument de paiement au profit d'un tiers beneficiaire
WO2017077210A1 (fr) Procédé de verification d'identité lors d'une virtualisation
FR2976385A1 (fr) Procede pour definir une transaction a effectuer au moyen d'un serveur
FR2912579A1 (fr) Procede de transfert securise via un reseau de communication d'un flux monetaire, systeme de transfert et produit programme correspondants

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

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