WO2018115641A1 - Sécurisation de transaction - Google Patents

Sécurisation de transaction Download PDF

Info

Publication number
WO2018115641A1
WO2018115641A1 PCT/FR2017/053542 FR2017053542W WO2018115641A1 WO 2018115641 A1 WO2018115641 A1 WO 2018115641A1 FR 2017053542 W FR2017053542 W FR 2017053542W WO 2018115641 A1 WO2018115641 A1 WO 2018115641A1
Authority
WO
WIPO (PCT)
Prior art keywords
terminal
transaction
server
stream
user
Prior art date
Application number
PCT/FR2017/053542
Other languages
English (en)
Inventor
Fabrice JEANNE
Patrick Leroy
Christopher GEORGET
Original Assignee
Orange
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 Orange filed Critical Orange
Priority to EP17822409.3A priority Critical patent/EP3555829A1/fr
Priority to US16/470,825 priority patent/US20190311349A1/en
Priority to CN201780073985.2A priority patent/CN110383312B/zh
Publication of WO2018115641A1 publication Critical patent/WO2018115641A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/12—Payment architectures specially adapted for electronic shopping systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3223—Realising banking transactions through M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/102—Bill distribution or payments
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G06Q20/3272—Short range or proximity payments by means of M-devices using an audio code
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G06Q20/3274—Short range or proximity payments by means of M-devices using a pictured code, e.g. barcode or QR-code, being displayed on the M-device
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/385—Payment protocols; Details thereof using an alias or single-use codes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists

Definitions

  • the invention relates to the field of data exchange security during transactions.
  • OTP One Time Password
  • OTPs have a short validity period, of the order of a few minutes, and become obsolete after a single use.
  • OTPs are transmitted through an intermediary, often the customer's banking organization, by texting on a customer's phone, or SMS for "Short Message Service" in English.
  • OTP makes it possible to exempt the customer from entering a code durably linked to his means of payment, for example a PIN code (PIN for "Personal Identification Number" in English) of a smart card or a registered cryptogram. on a payment card.
  • PIN code PIN for "Personal Identification Number” in English
  • the sending of an OTP to the customer is triggered only upon receipt of a request from the merchant to the intermediary. To be established, such a request requires the customer to provide the merchant with sensitive data such as the identity of his bank, an identifier of the means of payment, a name, a first name, etc.
  • sensitive data such as the identity of his bank, an identifier of the means of payment, a name, a first name, etc.
  • the customer must often provide other sensitive data such as personal data: physical delivery address, billing address, email, telephone numbers, delivery information such as digicodes, hours of presence at home etc.
  • the Applicant proposes a method of transaction security initialized between a first communication terminal available and a transaction device via a server.
  • the method comprises:
  • the comparison triggering in case of correspondence between the two code sequences, associating the second terminal, the second user and the transaction, making it possible to issue authorization for the continuation of the transaction between the second terminal and the transaction device associated with the server.
  • Such a method allows a first user to initiate a transaction with the transaction device, for example a command of an object to be delivered, on the first terminal.
  • the first terminal and / or a part of the network used may not be secure, be poorly secured or have an unknown level of security on the part of the first user.
  • the user may nevertheless prefer to use a computer of an Internet café for a better comfort of navigation rather than to use a smartphone whose screen is smaller ("smartphone" is used here in the sense of "ordiphone” in French).
  • the smartphone can be used as the second terminal. It is then useless for the user to enter sensitive data, including banking and personal data, on the first terminal. In other words, the transaction is possible without the sensitive data passing through the first terminal or a portion of network whose security is unknown.
  • the applicant proposes a server for securing an initialized transaction between a first communication terminal and a transaction device, the server being able to communicate with a second communication terminal and with the transaction device, the server comprising:
  • a comparator a first sequence of codes transmitted with a first data stream associated with the transaction, by a transmitter from the server to the transaction device, the data of the first stream comprising the first series of codes derived from a private key associated with the second user, and
  • the comparator being able, in case of correspondence between the two code sequences, to associate the second terminal, the transaction device and the transaction, triggering
  • a device for authorizing the continuation of the transaction between the second terminal and the associated transaction device, via the server a device for authorizing the continuation of the transaction between the second terminal and the associated transaction device, via the server.
  • the Applicant proposes an initialized transaction validation method between a first communication terminal and a transaction device, implemented by a second communication terminal.
  • the method includes: inserting into a second data stream a second code sequence in response to a receipt of a first code sequence associated with the transaction by the transaction device in a first data stream from a server; second sequence of codes being taken from a private key associated with the transaction device, the second stream being adapted to be transmitted from the second terminal to the server.
  • the Applicant proposes a communication terminal capable of communicating with a server and comprising a validation device.
  • the validation device comprises:
  • the Applicant proposes a computer program comprising instructions for the implementation of one and / or the other of the processes when this program is executed by a processor.
  • the following features may optionally be implemented. They can be implemented independently of each other or in combination with each other: -
  • the first stream is transmitted continuously in response to a request from the transaction device sent to the server, and is interrupted at the closing of the transaction .
  • the continuous transmission of the first stream containing the first sequence of codes makes it possible to repeat the comparison until a sufficient level of correspondence is detected between a first transmitted sequence and a second received sequence.
  • the first code sequence of the first stream takes the form of multimedia content.
  • the second terminal is equipped with a sensor, it will be useless to connect the first terminal 11 and the second terminal 12 to each other via a physical or wireless connection so that a first user having the first terminal and the second terminal, reading the first received code sequence seize on its second terminal a second sequence of code that will be transmitted in a second stream.
  • the comparison of the first code sequence and the second code sequence comprises: verifying that the correspondence level of the second sequence with the first sequence is greater than a predefined matching threshold value and less than 100%.
  • the authorization of the continuation of the transaction includes:
  • the second stream includes data for capturing multimedia content via at least one sensor of the second terminal, the second series of codes being included in the capture data of the multimedia content.
  • the validation method further comprises: capturing a multimedia content contained in the first stream, received by the first terminal of the transaction device, and reproduced by the first terminal, the capture being performed via at least one sensor of the second terminal, the multimedia content including the first series of codes.
  • the first terminal receives the first sequence of code in a multimedia content that it reproduces, it will be useless to connect the first terminal and the second terminal to one another via a physical or wireless connection so that a first user reading the first code sequence received on its first terminal enters on its second terminal a second sequence of code that will be transmitted in a second stream.
  • the capture of the multimedia content reproduced by the first terminal comprises at least one of the following operations:
  • photographing and / or filming by means of an optical sensor of the second terminal, a display screen of the first terminal displaying a succession of still or moving images, or a video;
  • Optical sensors and microphones are generally present on known devices available to users, including smart phones. It is then useless for the first user to acquire a terminal or dedicated equipment.
  • the validation process furthermore comprises, between the capture of the multimedia content and the transmission of the at least part of the first series of codes, an operation of deciphering the codes contained in the multimedia content captured by the second terminal, the second stream capable of being transmitted comprising the second sequence of codes in decrypted form and taken from the captured multimedia content. The amount of data to be transmitted from the second terminal is then reduced.
  • FIG. 1 shows a system for implementing a method according to one or more embodiments of the invention
  • FIG. 2 shows a diagram illustrating a set of proposed methods according to one or more embodiments of the invention.
  • FIG. 1 represents interactions between three distinct entities and generally distant from each other: a client system 11, 12, a transaction device 20 and a server 30.
  • a first user 1 has the client system 11-12 composed of a first communication terminal 11 and a second communication terminal 12.
  • a second user 2 has the unit 20, also known as transaction.
  • a third entity 3 has a server 30.
  • the three separate entities are the first user 1, the second user 2 and the third entity 3.
  • the system comprises the following elements: the terminals 11, 12, the unit 20 and the server 30.
  • the aforementioned elements implement respective methods.
  • the processes can therefore essentially be implemented by computer means.
  • the methods are then described as a whole in order to better understand how the elements interact in operation.
  • Those skilled in the art understand that the distinct elements above are intended to work together and having links between them. It is the same for the process aspects of the invention.
  • the first user 1 is a person wishing to purchase an article via the Internet and have it delivered to the home.
  • the second user 2 is a merchant managing a point of sale, for example via a commercial website, and wishing to sell an article to the first user 1.
  • the third entity 3 is distinct from the first user 1 and the second user 2.
  • the third entity 3 acts as a trusted third party between the first user 1 and the second user 2.
  • the third entity 3 may, for example, be a bank.
  • the term "bank” refers generally to a commercial and / or financial intermediary and should not be equated with a particular legal or regulatory status.
  • the first terminal 11 designates a terminal by which the first user 1 does not want to pass data that he considers sensitive, for example when he has doubts about the good security data that have entered.
  • the first terminal 11 may be loaned to the first user 1 or be connected to a public Wi-Fi type network whose first user 1 does not control the security features.
  • the second terminal 12 designates, on the contrary, a trusted terminal for the first user 1.
  • the second terminal 12 may be a telephone or a personal computer of the first user 1 and be connected to a trusted network.
  • trust are here understood in their relative sense by comparison with the first terminal 11, it being understood that no connected terminal can ensure absolute security of the data entered therein.
  • the first terminal 11 is a computer while the second terminal 12 is a smartphone ("smartphone” being here equivalent to “ordiphone” or “smart phone”).
  • the terminals 1, 2 are of another type.
  • the first terminal 11 comprises communication means, also called transaction transmitter, able to put the first terminal 11 into communication with the unit 20, for example via the Internet network.
  • the means of communication involve packet data transfer protocols (such as for example the IP protocol (in English, "Internet Protocol”)).
  • the first terminal 11 furthermore comprises several input / output interfaces, such as a graphic interface including a screen 111, and a loudspeaker 112.
  • the input / output interfaces can be integrated in the first terminal 1 or be deported , for example by means of peripherals connected to the first terminal 11.
  • the second terminal 12 comprises communication means capable of placing the second terminal 12 in communication with the server 30, for example via the Internet network.
  • the means of communication involve packet data transfer protocols.
  • the second terminal 12 further comprises communication means compatible with a telecommunications network of the mobile telephony type, for example compatible GSM, GPRS, EDGE, 3G, 4G or LTE. Other means may be considered.
  • the second terminal 12 also comprises input / output interfaces, here sensors, for example an optical sensor 121 and a microphone 122.
  • the input / output interfaces can be integrated in the second terminal 12 or be remote, for example by means of devices communicating with the second terminal 12.
  • Each of the first terminal 11 and the second terminal 12 includes several devices, or units, among which respectively a transaction interface 115 and a validation device 125, each including one or more processors that control the operations of the first terminal 11, respectively the second terminal 12, as a central processing unit (CPU) or another hardware processor, and a memory associated (for example, a random access memory (RAM), a read only memory (ROM), a cache memory and / or a flash memory, or any other storage medium capable of storing software code in the form of instructions executable by a processor or data structures accessed by a processor) operatively coupled to the processor (s).
  • Each of the first terminal 11 and the second terminal 12 includes an operating system and programs, components, modules, applications in the form of software executed by the processor (s), which can be, in one or more modes of realization, stored in a non-volatile memory.
  • the unit 20 and the server 30 each include one or more processors, such as a central processing unit (CPU) or other hardware processor, and an associated memory (for example, a random access memory (RAM), a read only memory (ROM), a cache memory and / or a flash memory, or any other storage medium capable of storing software code in the form of instructions executable by a processor or of data structures accessible by a processor) operatively coupled to the processor (s) (s).
  • the unit 20 and the server 30 each include an operating system and programs, components, modules, software applications executed by the processor (s), which may be in one or more embodiments , stored in a non-volatile memory.
  • the unit 20 comprises means of communication with the server 30 of the third party entity 3 on the one hand and with the first terminal 11 on the other hand.
  • the server 30 includes a transmitter enabling the transmission of the first stream 100 between the server 30.
  • the unit 20 comprises a first transmitter capable of receiving the first stream 100 from the transmitter of the server 30.
  • the unit 20 further comprises a second transmitter, said transaction transmitter, allowing the exchanges between the unit 20 and the first terminal 11.
  • the first stream 100 will be received from the server 30 by the first transmitter unit 20 and, eventually, issued by the second transmitter from the unit to the first terminal 11.
  • the unit 20 includes a background portion (or "back-end” in English) including the processor (s) and the means of communication with the server 30 of the third party entity 3.
  • the unit 20 includes a portion in frontal (or "front-end” in English).
  • the front part includes, here, a website accessible via the Internet by the first user 1, that is to say a user interface.
  • the server 30 comprises means of communication with the second terminal 12 of the first user 1 on the one hand and with the unit 20 of the second user 2 on the other hand.
  • the server 30 comprises a receiver able to wait for the reception of data from the second terminal 12 of the first user 1 (in particular the second stream 200 of written after), and a transmitter able to transmit data to the second terminal 12, l issuer that may be distinct or common to the issuer mentioned above.
  • the communication channels between the server 30 of the third party entity 3 and the second terminal 12 of the first user 1, as well as the communication channels between the server 30 (or first transmitter) of the entity third 3 and the background portion of the unit 20 of the second user 2, are secured.
  • the transaction device 20 comprises a comparator of code sequences comparing a first sequence of codes transmitted in a first stream of the transaction device from a server, in particular from the third party entity, to a second sequence of code received in a second stream received from a second terminal, in particular from the first user.
  • the transaction device 20 comprises, in particular, a first transmitter transmitting the first stream to the server, in particular the third party entity, and / or a receiver receiving the second stream.
  • the transaction device 20 comprises, in particular, an authorization device allowing the continuation of the transaction between the second terminal and the transaction device via the server, that is to say, in particular, the continuation of the transaction between the first user and the second user through the third party entity.
  • the transaction device 20 includes a user interface allowing the first user through his first terminal to initiate a transaction with the second user, such as a website.
  • the comparison of the codes and / or the authorization is carried out by the transaction device 20 rather than by the server 30, in particular of the third party entity 3.
  • the methods begin when a transaction is started beforehand.
  • the first user 1 as a client of the transaction device 20, in particular the second user 2, selects on the website a set of one or more items he wishes to acquire.
  • This set usually called “basket”, includes a set of information considered as non-sensitive. For example, item IDs, item quantities, availability dates, delivery dates possible and / or price of items.
  • the basket does not include any banking or personal information relating to the first user 1.
  • the first user 1 is not identified and is substantially anonymous from the point of view of the unit 20 and the user.
  • second user 2. No sensitive data has passed through the first terminal 11 and the communication channels connecting the first terminal 11 to the unit 20, potentially unsecured.
  • the first user 1 can accept to transmit personal data, for example by identifying with the website of the transaction device 20, including the second user 2.
  • This may, for example, allow the unit 20, especially the second user 2, to adapt to the first user 1 by adapting the navigation on the website to pre-recorded preferences or by suggesting articles according to the preferences of the first user 1.
  • some personal data such as an identifier and a password can be entered on the first terminal 11. Nevertheless, the bank data of the first user 1 are not entered there.
  • the transaction is started.
  • This initial state corresponds to the operation referenced 1001 in FIG. 2.
  • the operation 1001 is implemented as soon as the basket is validated.
  • the transaction device 20, in particular the second user 2 can propose to a first terminal 11, in particular the first user 1, the implementation of the system according to the invention as a choice among other methods of transactions. for example known methods in themselves.
  • the first user 1 can choose the level of security of his data, for example according to his confidence for the first terminal 11.
  • the operation 1001 is implemented when the first User 1 selected a method according to the invention.
  • the transaction is initialized by the operation 1001.
  • the unit 20 transmits to the server 30 a request comprising an identifier of the initialized transaction and an identifier of the unit 20.
  • the identifier of the unit 20 may to be integrated in the identifier of the transaction, for example by means of a unique transaction number of which a portion corresponds to an identifier of the unit 20.
  • the identifier of the transaction allows in particular to distinguish, later, two simultaneous transactions from the same unit 20.
  • the request may also be accompanied by the provision of data relating to the current transaction, for example the price to be paid.
  • the server 30 stores the data relating to the current transaction in order to call them later to confirm or cancel the transaction.
  • the data relating to the current transaction may be transmitted from the unit 20 to the server 30 during a subsequent operation.
  • the request may also include a list of data types that the transaction device 20 requires, such as the second user 2 wishes to obtain.
  • a list may include a classification of the type of data desired.
  • the obtaining by the transaction device 20, especially the second user 2 of a delivery address can be classified as a mandatory data type, that is, in the absence of which the unit 20 will not confirm the transaction. In the case where a delivery address is not obtained, the transaction can not succeed. On the contrary, obtaining a telephone number of the first user 1 can be classified as optional.
  • the request has no list of desired data.
  • Such a list can be established generally for any transaction, for example when the transaction device is subscribed, in particular the second user 2, to the services of the server 30, in particular of the third party entity 3, or subsequently at the time of the transaction. verification of the transaction. Such a list may also not be established.
  • the server 30 In an operation 1003, the server 30 generates a first sequence 101 of codes specific to the transaction.
  • the server 30 thus comprises a code generator.
  • the first sequence 101, or series, of codes is generated for each transaction.
  • the code generator is a pseudo-random number generator (or PRNG for "PseudoRandom Number Gêner ator" in English).
  • PRNG pseudo-random number generator
  • the generator implements an algorithm capable of generating dynamic codes derived from a seed specific to each transaction device 20, in particular to each second user 2.
  • the seed is derived from a private key of the transaction device 20, in particular a private key of the second user 2.
  • the code generator can generate an almost infinite number and substantially continuously consisting of a series of codes.
  • the code sequence can also be seen as a dynamic code.
  • the code sequence can for example be generated substantially continuously throughout the duration of the transaction.
  • the code generation operation 1003 starts upon receipt of the request from the unit 20 and can continue until the end of the transaction and concurrently with the operations described below. Generating a sequence of codes continuously, or a dynamic code makes it difficult to decode by a malicious third party. But the code becomes useless at the end of the transaction. It is enough that the code remains indecipherable the time of the transaction.
  • code generators may be implemented to generate a first sequence of codes.
  • the server 30 transmits to the unit 20 the first sequence 101 of codes.
  • the first sequence 101 is transmitted in a first stream 100 of data transmitted from the server 30 to the unit 20.
  • the first stream 100 passes through a secure channel between the server 30 and the unit 20.
  • the first stream 100 is substantially continuous (in the form of "streaming" in English) until the end of the transaction, defects and errors in the communication between the server 30 and the unit 20. In other words, depending on the quality of the communication, portions of the first suite 101 may be missing upon receipt by the unit 20.
  • the first suite 101 is further stored by the server 30.
  • the first suite 101 is registered associated with data identifying the transaction.
  • the unit 20 transmits to the first terminal 11 the first stream 100 received from the unit 20, including the first suite 101.
  • the unit 20 acts as a relay between the server 30 and the first terminal 11.
  • the first stream 100 is also substantially continuous between the server 30 and the unit 20. Faultes and errors in the communication between the server 30 and the unit 20 and between the unit 20 and the first terminal 11 can cause problems. losses between the first sequence 101 generated by the server 3 and the first suite 101 received by the first terminal 11. Such losses can be considered negligible. Nevertheless, the possibility of such losses will be taken into account later.
  • the first terminal 11 upon receipt of the first stream 100 by the first terminal 11, the first terminal 11 is arranged to broadcast a multimedia content 130 including at least a portion of the first sequence 101 of codes.
  • Multimedia content 130 may include, for example, sound, still images, motion pictures, videos, or a combination of such mediums.
  • the multimedia content 130 is broadcast via the screen 111 and / or the loudspeaker 112 of the first terminal 11.
  • the first suite 101 is encoded into a multimedia content 130 by the server 30 itself after the generation of the codes and before transmission to the unit 20.
  • the first suite 101 is present in the form of multimedia content 130 as soon as it is transmitted to the unit 20, in particular the second user 2, in the first stream 100.
  • the multimedia content 130 is streamed by the server 30 to the first terminal 11 via the unit 20.
  • the first sequence 101 may be encoded into a multimedia content 130 a posteriori, for example by the unit 20 before being transmitted to the first terminal 11.
  • the multimedia content 130 broadcast by the first terminal 11 is captured by the second terminal 12.
  • the capture comprises:
  • the display screen 111 of the first terminal 11 displaying a succession of still or moving images, or a video, and / or
  • the microphone 122 of the second terminal 12 by means of the microphone 122 of the second terminal 12, the sound emitted by the speaker 112 of the first terminal 11.
  • the sensors of the second terminal 12 contributed are selected compatible with the type of multimedia content 130 (sounds, images stills, moving pictures, videos or combinations of the preceding forms).
  • the first user 1 uses his smartphone 12 to capture the content broadcast by the computer of the cybercafe.
  • the multimedia content 130 picked up by the second terminal 12 is stored at least temporarily in a memory of the terminal 12, for example a buffer memory.
  • the second terminal 12 transmits to the server 30, including the third entity 3, a second stream 200 of data.
  • the second terminal 12 comprises a transmitter capable of transmitting, from the terminal 12 to the server 30, the second stream 200.
  • the transmission can be carried out continuously (streaming mode).
  • the second data stream 200 comprises a second code sequence 201.
  • the second code suite 201 is derived from the multimedia content 130 as captured by the second terminal 12.
  • the second code suite 201 at least partially comprises the first code string 101.
  • the differences between the first sequence 101 and the second sequence 201 correspond to the successive information losses, namely here the information losses due to the communication failures between the server 30 and the unit 20, the communication defects between the unit 20 and the first terminal 11 and the loss of information due to the passage of the multimedia content 130 from the first terminal 11 to the second terminal 12 by capture-diffusion.
  • the second suite 201 can therefore be seen as part of a sequence of codes taken from the multimedia content 130 picked up by the sensors 121 and / or 122, and validated by the validation device 125 of the second terminal 12.
  • the validation device 125 comprises a flow generator inserting in the second stream 200 of data the second series of codes 201 in response to the reception of the first suite 101.
  • the transmission of data by broadcasting and capturing multimedia content can generate a substantial loss of information. Nevertheless, it is unnecessary to connect the first terminal 11 and the second terminal 12 to each other via a physical or wireless connection.
  • the first user 1 can thus ensure that the first terminal 11 and the second terminal 12 do not communicate by computer. The risk to the security of the second terminal 12 and the data to which it is possible to access via the second terminal 12 is thus reduced.
  • the second terminal 12 transmits no information to the first terminal 11.
  • the capture-diffusion transmission is one-way.
  • the transmission-capture transmission of multimedia content requires components and software generally available on the usual terminals (speaker, screen, microphone, optical sensor and corresponding software).
  • the second sequence 201 of codes is extracted from the multimedia content 130.
  • the multimedia content 130 is decrypted, totally or partially, so as to obtain the second sequence 201 of codes.
  • the operation 1009 is implemented, at least in part, by the second terminal 12, before the implementation of the operation 1008, before the transmission of the second suite 201 to the server 30.
  • the second terminal 12 is equipped with a decryption module, also called decryption device or decryptor.
  • the decryptor can take the form of an application or software installed on the second terminal 12.
  • Such a decryptor can, for example, be implemented in the validation device 125 or, according to the embodiment, implemented by the validation device 125 the second terminal 12 and via an application previously installed on the second terminal 12.
  • existing terminals can be made to conform to the second terminal 12 according to the invention by a software modification ("software") without which it is necessary to intervene physically on the terminal (“hardware").
  • Such applications may be provided by the third party entity providing the service.
  • the decryption is partial.
  • the amount of data transmitted to the server 3 is low and the complete decryption remains centralized on the server 30.
  • the second stream 200 may comprise the second suite 201 in at least partially decrypted form.
  • the transmission can be carried out via a secure channel between the second terminal 12 and the server 30.
  • the amount of data transmitted from the second terminal 12 to the server 30 is small, which may be particularly desirable, for example. example when the amount of data received and / or transmitted affects the costs incurred by the second user 2, for example in the context of a mobile phone subscription.
  • the operation 1009 is implemented by the server 30, after the implementation of the operation 1008 and on receiving the second stream 200 from the second terminal 12.
  • the second terminal 12 may be devoid of decipherer.
  • the second stream 200 may comprise for example the multimedia content 130 in a raw form, not decrypted, as captured by the second terminal 12.
  • the second stream 200 includes capture data of the multimedia content 130.
  • the server 30 comprises a decryptor.
  • the computing power of the validation device 125, the second terminal 12 is not used for decryption and therefore remains available for other uses.
  • the decryptor can be located centrally on the server 30. By centralizing the decryption module on the server 30, coding characteristics of the multimedia content can remain partly secret, accessible only to the third party entity 3, this which makes the task of malicious third parties more complex.
  • operation 1010 is implemented.
  • the first code sequence 101 and the second code sequence 201 are compared with each other.
  • the server 30 comprises a comparison module, also called comparison device or comparator.
  • the comparator may take the form of an application or software installed on the server 30. Such a comparator may, for example, be implemented in the server 30 or implemented by the server 30 via a server. application previously installed on the server 30.
  • the server 30 verifies that the correspondence level of the second suite 201 with the first suite 101 is greater than a threshold value C of predefined correspondence, for example expressed as a percentage .
  • the threshold value C is selected so as to detect a theoretical identity of the codes of the second sequence 201 and the codes of the first sequence 101 while taking into account the transmission errors that may occur between the transmission of the first stream 100 to the unit 20, in particular the second user 2, (operation 1004) and the reception of the second stream 200 (operation 1008) from the second terminal 12, in particular from the first user 1.
  • the threshold value C can be selected equal to (100 - X)%, where the value of X is selected as a function of the quality of the communication means implemented, for example proportional to the sum of the percentages of losses by transmission error.
  • the server 30 may implement, for example prior to the operation 1010, a verification of the validity of the second sequence 200 of codes received, for example according to the pseudo-random generation rules.
  • a code analysis makes it possible to check whether the codes are compatible with the pseudo-arbitrary generation rules implemented at the generation of the codes. An incompatibility indicates on the contrary a corruption of the transaction. Security measures can be taken accordingly, including the end of the transaction if it can be identified later (operation 1020). Thus, security against fraud is further improved.
  • the operation 1010 is repeated until a sufficient level of correspondence is detected between a first sequence 101 transmitted (operation 1004) and a second sequence 201 received (operation 1008).
  • This is particularly advantageous in combination with continuous operation of the method: when the code sequence is generated substantially continuously, the first stream 100 and the second stream 200 can also be transmitted substantially continuously (in "streaming" mode). A temporary break in the transmission circuit of the code sequence does not interrupt the process.
  • the process for the second received stream 200 may be terminated.
  • the process for the corresponding transaction can be terminated.
  • the transactions initialized at the server 30 (operation 1003) and the second stream 200 received by the server 30 (operation 1008) are not yet associated with each other by the server 3 (subsequent operation 1011 ). In such cases, stopping the comparison iterations (operation 1010) and stopping the transaction (operations 1003 and 1004) are treated separately.
  • the stop condition of the iterations and the end of the process may for example be based on an assumed validity period. For example, a timer is started upon receipt of the second stream 200 (operation 1008). If the elapsed time exceeds a predetermined time, then the comparison process (operation 1010) is terminated. The second stream 200 is then ignored. In this case at least, the server 30 is equipped with a clock. Operation 1015 can also limit the number of iterations, for example by means of an iteration counter. Other conditions can be implemented during the operation 1015. Preferably, an error message and / or interruption of the transaction is sent in response to the second terminal 12 at the origin of the second stream 200 .
  • a stopwatch can also be started (operations 1003 and 1004). If the elapsed time exceeds a predetermined time, then the code generation and transmission processes of the first stream (100) are terminated (operations 1003 and 1004).
  • the server 30 is equipped with a clock.
  • an error message and / or interruption of the transaction is sent in response to the unit 20 at the origin of the request (operation 1002).
  • the server 3 waits for a return of a second device 12 (not yet identified) in response to the transaction. In the absence of a satisfactory response (a second series 201 of codes corresponding to the first series 101), the transaction is terminated (operation 1020).
  • the second terminal 12, the transaction device 20 and the current transaction are associated (In particular, the first user 1, the second user 2, and the current transaction are associated).
  • the server 30 identifies the second terminal 12, in particular the first user 1, as being the client of the transaction device 20, in particular the second user 2, in the current transaction.
  • the server in particular of the third party entity 3, can act as a trusted intermediary between the second terminal 12 and the transaction device 20, in particular the first user 1 and the second user 2, in the context of the transaction.
  • the server 30 may receive an identifier of the first user 1 transmitted by the second terminal 12, for example included in the second stream 200 of data.
  • the continuation of the transaction is authorized between the second terminal 12 and the transaction device 20, in particular between the first user 1 and the second user 2, via the server 30, and therefore, in particular, the third entity 3.
  • the authorization is implemented by the server 30.
  • the server 30 includes an authorization device allowing the continuation of the transaction between the second terminal 12 and the transaction device 20 , in particular between the first user 1 and the second associated user 2, via the third party entity 3.
  • the transaction authorization authorization operation 1012 comprises the transmission of data from the second terminal 12, in particular the first user 1, to the unit 20, in particular the second user 2, through the server 30 acting relay.
  • the first user 1 can transmit sensitive data, for example bank and / or personal, without going through the first potentially unsecured terminal 1.
  • the server 30 transmits sensitive data relating to the first user 1 to the unit 20 at least partially automatically.
  • the server 30 may have access to at least some of the sensitive data of the first user 1.
  • the first user 1 may have provided the third party 3 some of the sensitive data prior to the transaction, for example during a subscription to the service by the first user 1.
  • the first user may have provided the third party with a default delivery address and bank details.
  • Such data is stored on one or more databases accessible to the server 30.
  • the first user 1 may also have given prior authorization to the server 30 to transmit said data in such a way that Automated as soon as a transaction is authorized. In this case, the server 30 may be exempted from requesting additional confirmation from the first user 1 at each transaction.
  • the authorization of the continuation of the transaction may comprise: sending sensitive data relating to the first user 1 to the unit 20, in particular the second user 2, from the server 30, in particular from the third entity 3.
  • Such embodiments are particularly advantageous when the third party 3 controlling the server 30 is an organization such as a usual banking organization of the first user 1. Often for regulatory reasons, the banking organizations have at least some banking information and in the case of the first user 1. In such cases, the server 30 may, rather than transmit the bank details to the unit 20, transmit a confirmation of the transaction to the unit 20.
  • the financial exchanges can then be carried out a posteriori: the third entity 3 made then also function of financial intermediary.
  • the third-party entity 3 can substitute the first user 1 as the payer with respect to the second user 2 and group the payments of several transactions of several first users into a single payment, for example by a periodic payment. of all transactions confirmed during a previous period.
  • the server 30 can bill each first user 1 by grouping several transactions of the same first user 1.
  • the server 30 can transmit to the second terminal 12, in particular the first user 1, a request for confirmation of the transaction.
  • a request may comprise, for example, a reference of the transaction, a price corresponding to the transaction and optionally requests for additional information from the transaction device, in particular the second user 2 as described herein. before (email, phone number, etc.).
  • the server 30 can in turn transmit a confirmation of the transaction to the unit 20, in particular the second user 2, optionally accompanied by data provided by the first user 1 via the second terminal 12.
  • the server 30 may optionally transmit a confirmation of the transaction to the second terminal 12, and therefore, in particular to the first user 1 via the second terminal 12.
  • the process is terminated in operation 1020.
  • Operation 1020 indicates the end of the process, whether the transaction is finally completed or canceled.
  • the server 30 may, at any time, receive a refusal of confirmation, ie a reversal, of the transaction by the second terminal 12, in particular the first user 1 and / or on the part of the transaction device, in particular the second 2.
  • the process is terminated by the operation 1020, optionally after transmitting cancellation messages of the transaction to the second terminal 12, in particular the first user 1 and / or the transaction device, particular of the second user 2.
  • the first stream 100 is transmitted continuously in response to a request from the transaction device 20 addressed to the server 3, and is interrupted at the closing of the transaction.
  • closing the transaction here means either a realization or a cancellation of the transaction.
  • the stored codes can be erased.
  • the comparisons of the operation 1010 may be limited to the active transactions to associate each second stream 200 received by the server 30 to an active transaction.
  • a transaction security method initialized between a first communication terminal available to a first user and a transaction device of a second user via a server of a third entity comprises:
  • a first code sequence transmitted with a first data flow associated with the transaction, from the server of the third party entity to the second user's transaction device, the data of the first stream comprising the first series of codes taken from a private key; associated with the second user, and
  • Such a method allows the first user to initiate a transaction with the second user, for example a command of an object to be delivered, on the first terminal.
  • the first terminal and / or a part of the network used may not be secure, be poorly secured or have an unknown level of security on the part of the first user.
  • the user may nevertheless prefer to use a computer of an Internet café for a better comfort of navigation rather than to use a smartphone whose screen is smaller ("smartphone” is used here in the sense of "ordiphone” in French).
  • the smartphone can be used as the second terminal. It is then useless for the user to enter sensitive data, including banking and personal data, on the first terminal. In other words, the transaction is possible without the sensitive data passing through the first terminal or a portion of network whose security is unknown.
  • the applicant proposes a server of a third entity to secure a transaction initiated between a first communication terminal available to a first user and a transaction device of a second user, the server being able to communicate with a second communication terminal available to the first user and with the transaction device of the second user, the server comprising:
  • a first code sequence transmitted with a first data stream associated with the transaction, by a sender from the server of the third party entity to the second user's transaction device, the data of the first stream comprising the first series of codes drawn; a private key associated with the second user, and
  • the comparator being adapted, in case of correspondence between the two code sequences, to associate the first user, the second user and the transaction, triggering
  • a device for authorizing the continuation of the transaction between the first user and the second associated user, via the third party entity a device for authorizing the continuation of the transaction between the first user and the second associated user, via the third party entity.
  • the Applicant proposes an initialized transaction validation method between a first communication terminal available to a first user and a transaction device of a second user, implemented by a second communication terminal available. of the first user.
  • the method comprises: inserting in a second data stream a second code sequence in response to a receipt of a first code sequence associated with the transaction by the second user's transaction device in a first data stream from a server of a third entity, the second code sequence being derived from a private key associated with the second user, the second stream being adapted to be transmitted from the second terminal to the server of the third party entity.
  • the Applicant proposes a communication terminal capable of communicating with a server and comprising a validation device.
  • the validation device comprises:
  • a flow generator inserting in a second data stream a second sequence of codes in response to a receipt of a first code sequence associated with the transaction by the second user's transaction device in a first data stream from a server of a third entity, the second code sequence being derived from a private key associated with the second user, the second stream being adapted to be transmitted by a transmitter of the second terminal to the server of the third party entity.
  • the Applicant proposes a computer program comprising instructions for the implementation of one and / or the other of the processes when this program is executed by a processor.
  • the following features may optionally be implemented. They can be implemented independently of each other or in combination with each other: -
  • the first stream is transmitted continuously in response to a request from the transaction device sent to the server, and is interrupted at the closing of the transaction .
  • the continuous transmission of the first stream containing the first sequence of codes makes it possible to repeat the comparison until a sufficient level of correspondence is detected between a first transmitted sequence and a second received sequence.
  • the first code sequence of the first stream takes the form of multimedia content.
  • the second terminal is equipped with a sensor, it will be useless to connect the first terminal 11 and the second terminal 12 to each other via a physical or wireless connection so that the first user reading the first code string received on his second terminal a second sequence of code that will be transmitted in a second stream.
  • the comparison of the first code sequence and the second code sequence comprises: verifying that the correspondence level of the second sequence with the first sequence is greater than a predefined matching threshold value and less than 100%. This makes it possible to identify a correspondence between the first and second code sequences despite transmission errors that may occur between the transmission of the first stream to the second user's transaction device and the receipt of the second stream from the second user's first terminal. .
  • the first stream and / or the second stream are each transmitted via a secure channel, respectively between the server of the third party entity and the transaction device of the second user, respectively between the second terminal of the first user and the server of the third party entity.
  • the authorization of the continuation of the transaction includes:
  • the second stream includes data for capturing multimedia content via at least one sensor of the second terminal, the second series of codes being included in the capture data of the multimedia content.
  • the validation method further comprises: capturing a multimedia content contained in the first stream, received by the first terminal of the transaction device, and reproduced by the first terminal, the capture being performed via at least one sensor of the second terminal, the multimedia content including the first series of codes.
  • the first terminal receives the first sequence of code in a multimedia content that it reproduces, it will be useless to connect the first terminal and the second terminal to one another via a physical or wireless connection so that the first user reading the first code sequence received seize on his second terminal a second sequence of code that will be transmitted in a second stream.
  • the capture of the multimedia content reproduced by the first terminal comprises at least one of the following operations:
  • photographing and / or filming by means of an optical sensor of the second terminal, a display screen of the first terminal displaying a succession of still or moving images, or a video;
  • Optical sensors and microphones are generally present on known devices available to users, including smart phones. It is then useless for the first user to acquire a terminal or dedicated equipment.
  • the validation process furthermore comprises, between the capture of the multimedia content and the transmission of the at least part of the first series of codes, an operation of deciphering the codes contained in the multimedia content captured by the second terminal, the second stream capable of being transmitted comprising the second sequence of codes in decrypted form and taken from the captured multimedia content. The amount of data to be transmitted from the second terminal is then reduced.

Landscapes

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

Abstract

Un procédé de sécurisation de transaction entre un terminal (11), notamment d'un premier utilisateur (1), et un dispositif (20), notamment d'un second utilisateur (2), par l'intermédiaire d'un serveur (30), notamment d'une entité tierce (3). Le procédé comprend : comparer : - une première suite de codes (101) tirés d'une clé privée associée au dispositif de transaction (20) transmise du serveur (30) au dispositif de transaction (20), et - une seconde suite de codes (201) reçue par le serveur (30) depuis un terminal (12), notamment du premier utilisateur (1), la comparaison déclenchant, en cas de correspondance entre les deux suites de codes (101; 201) associer le deuxième terminal (12), le dispositif de transaction (20) et la transaction, permettant de délivrer une autorisation de la poursuite de la transaction entre le deuxième terminal (12) et le dispositif de transaction (20) associés par le serveur (30).

Description

Sécurisation de transaction
L'invention relève du domaine de la sécurité des échanges de données au cours de transactions.
Pour renforcer la sécurité, il est connu de multiplier les vérifications lors de transactions distantes. Par exemple, un client souhaitant payer en ligne une commande à un marchand peut devoir entrer un code à usage unique, ou OTP pour « One Time Password » en anglais, pour confirmer une transaction. Généralement, de tels OTP ont une durée de validité courte, de l'ordre de quelques minutes, et deviennent obsolètes après une seule utilisation. Les OTP sont transmis par un intermédiaire, souvent l'organisme bancaire du client, au moyen d'un texto sur un téléphone du client, ou SMS pour « Short Message Service » en anglais.
L'usage des OTP permet de dispenser le client d'entrer un code lié durablement à son moyen de paiement, par exemple un code du type code PIN (PIN pour « Personal Identification Number » en anglais) de carte à puce ou un cryptogramme inscrit sur une carte de paiement. Ainsi, même si un tiers ou le marchand lui-même a accès aux données transmises, ces dernières sont insuffisantes pour utiliser le moyen de paiement. Cependant, l'envoi d'un OTP au client n'est déclenché qu'à réception d'une requête de la part du marchand à l'intermédiaire. Pour être établie, une telle requête nécessite au préalable que le client fournisse au marchand des données sensibles telles que l'identité de son organisme bancaire, un identifiant du moyen de paiement, un nom, un prénom, etc. Outre les informations bancaires, le client doit souvent fournir d'autres données sensibles telles que des données personnelles : adresse physique de livraison, adresse postale de facturation, courriel, numéros de téléphone, informations de livraison telles que des digicodes, heures de présence au domicile, etc.
L'usage d'un OTP ne protège pas contre l'interception de la plupart des données sensibles généralement fournies au cours d'une transaction.
En particulier, lorsque le client utilise un ordinateur ou une connexion non sécurisés pour passer sa commande, la protection des données sensibles ne peut être assurée. L'invention vient améliorer la situation. La demanderesse propose un procédé de sécurisation de transaction initialisée entre un premier terminal de communication à disposition et un dispositif de transaction par l'intermédiaire d'un serveur. Le procédé comprend :
comparer :
- une première suite de codes transmise avec un premier flux de données associé à la transaction, du serveur au dispositif de transaction, les données du premier flux comprenant la première suite de codes tirés d'une clé privée associée au dispositif de transaction, et
- une seconde suite de codes reçue avec un second flux de données par le serveur depuis un deuxième terminal de communication, ledit deuxième terminal transmettant le second flux en réponse à la réception du premier flux,
la comparaison déclenchant, en cas de correspondance entre les deux suites de codes, associer le deuxième terminal, le second utilisateur et la transaction, permettant de délivrer une autorisation de la poursuite de la transaction entre le deuxième terminal et le dispositif de transaction associés par le serveur.
Un tel procédé permet à un premier utilisateur d'entamer une transaction avec le dispositif de transaction, par exemple une commande d'un objet à livrer, sur le premier terminal. Le premier terminal et/ou une partie du réseau utilisé peuvent ne pas être sécurisés, être mal sécurisés ou avoir un niveau de sécurité inconnu de la part du premier utilisateur. L'utilisateur peut néanmoins préférer utiliser un ordinateur d'un cybercafé pour un meilleur confort de navigation plutôt que d'utiliser un smartphone dont l'écran est plus petit (« smartphone » est utilisé ici au sens de « ordiphone » en français). Ainsi, le smartphone peut être utilisé en tant que deuxième terminal. Il est alors inutile pour l'utilisateur d'entrer les données sensibles, notamment les données bancaires et personnelles, sur le premier terminal. Autrement dit, la transaction est possible sans que les données sensibles ne transitent via le premier terminal ou une portion de réseau dont la sécurisation est inconnue.
Selon un autre aspect, la demanderesse propose un serveur pour sécuriser une transaction initialisée entre un premier terminal de communication et un dispositif de transaction, le serveur étant apte à communiquer avec un deuxième terminal de communication et avec le dispositif de transaction, le serveur comportant :
- un comparateur : - d'une première suite de codes transmise avec un premier flux de données associé à la transaction, par un émetteur du serveur au dispositif de transaction, les données du premier flux comprenant la première suite de codes tirés d'une clé privée associée au second utilisateur, et
- d'une seconde suite de codes reçue avec un second flux de données par un récepteur du serveur depuis un deuxième terminal de communication, ledit deuxième terminal transmettant le second flux en réponse à la réception du premier flux,
le comparateur étant apte, en cas de correspondance entre les deux suites de codes, à associer le deuxième terminal, le dispositif de transaction et la transaction, déclenchant
- un dispositif d'autorisation de la poursuite de la transaction entre le deuxième terminal et le dispositif de transaction associés, par l'intermédiaire du serveur.
Selon un autre aspect, la demanderesse propose un procédé de validation de transaction initialisée entre un premier terminal de communication et un dispositif de transaction, mis en œuvre par un deuxième terminal de communication. Le procédé comprend : insérer dans un second flux de données une seconde suite de codes en réponse à une réception d'une première suite de codes associée à la transaction par le dispositif de transaction dans un premier flux de données provenant d'un serveur, la seconde suite de codes étant tirée d'une clé privée associée au dispositif de transaction, le second flux étant apte à être transmis depuis le deuxième terminal au serveur.
Selon un autre aspect, la demanderesse propose un terminal de communication apte à communiquer avec un serveur et comprenant un dispositif de validation. Le dispositif de validation comporte :
un générateur de flux insérant dans un second flux de données une seconde suite de codes en réponse à une réception d'une première suite de codes associée à la transaction par le dispositif de transaction dans un premier flux de données provenant d'un serveur, la seconde suite de codes étant tirée d'une clé privée associée au dispositif de transaction, le second flux étant apte à être transmis par un transmetteur du deuxième terminal au serveur. Selon un autre aspect, la demanderesse propose un programme informatique comportant des instructions pour la mise en œuvre de l'un et/ou l'autre des procédés lorsque ce programme est exécuté par un processeur. Les caractéristiques suivantes peuvent, optionnellement, être mises en œuvre. Elles peuvent être mises en œuvre indépendamment les unes des autres ou en combinaison les unes avec les autres : - Le premier flux est transmis en continue en réponse à une requête du dispositif de transaction adressée au serveur, et est interrompue à la clôture de la transaction. La transmission en continue du premier flux contenant la première suite de codes permet de répéter la comparaison jusqu'à détecter un niveau de correspondance suffisant entre une première suite transmise et une seconde suite reçu.
- La première suite de codes du premier flux prend la forme d'un contenu multimédia. Ainsi, si le second terminal est doté de capteur, il sera inutile de connecter le premier terminal 11 et le second terminal 12 l'un à l'autre via une connexion physique ou sans fil pour qu'un premier utilisateur disposant du premier terminal et du deuxième terminal, lisant la première suite de code reçu saisisse sur son deuxième terminal une deuxième suite de code qui sera transmise dans un deuxième flux.
- La comparaison de la première suite de codes et de la seconde suite de codes comprend : vérifier que le niveau de correspondance de la seconde suite avec la première suite est supérieur à une valeur seuil de correspondance prédéfinie et inférieure à 100%. Ceci permet d'identifier une correspondance entre la première et la deuxième suites de codes malgré des erreurs de transmission pouvant avoir lieu entre la transmission du premier flux au dispositif de transaction et la réception du second flux depuis le second terminal. - Le premier flux et/ou le second flux sont chacun transmis via un canal sécurisé, respectivement entre le serveur et le dispositif de transaction, respectivement entre le deuxième terminal et le serveur. Cette précaution supplémentaire permet de complexifier les tentatives d'un tiers mal intentionné. En ralentissant suffisamment l'interception et l'interprétation des échanges par un tel tiers, il devient probable que la transaction soit clôturé avant que le tiers puisse utiliser les données interceptées. Or, à la clôture de la transaction, les données échangées deviennent inutilisables.
- L' autorisation de la poursuite de la transaction comprend :
- envoyer une demande de confirmation de la transaction au deuxième terminal depuis le serveur, - réceptionner une confirmation de la transaction sur le serveur depuis le deuxième terminal,
- envoyer une confirmation de la transaction au dispositif de transaction depuis le serveur. Ceci permet par exemple d'éviter de transmettre des données bancaires propres au premier utilisateur des premier et deuxième terminaux, au dispositif de transaction. Les conséquences éventuelles pour le premier utilisateur d'une mauvaise sécurisation des données stockées et/ou échangées par le dispositif de transaction sont limitées.
- Le second flux comprend des données de capture d'un contenu multimédia via au moins un capteur du deuxième terminal, la seconde suite de codes étant incluse dans les données de capture du contenu multimédia. Ainsi, si le premier terminal reçoit la première suite de code dans un contenu multimédia qu'il reproduit, il sera inutile de connecter le premier terminal et le second terminal l'un à l'autre via une connexion physique ou sans fil pour qu'un premier utilisateur lisant la première suite de code reçu sur son premier terminal saisisse sur son deuxième terminal une deuxième suite de code qui sera transmise dans un deuxième flux.
- Le procédé de validation comprend en outre : capturer un contenu multimédia contenu dans le premier flux, reçu par le premier terminal du dispositif de transaction, et reproduit par le premier terminal, la capture étant réalisée via au moins un capteur du deuxième terminal, le contenu multimédia incluant la première suite de codes. Ainsi, si le premier terminal reçoit la première suite de code dans un contenu multimédia qu'il reproduit, il sera inutile de connecter le premier terminal et le second terminal l'un à l'autre via une connexion physique ou sans fil pour qu'un premier utilisateur lisant la première suite de code reçu sur son premier terminal saisisse sur son deuxième terminal une deuxième suite de code qui sera transmise dans un deuxième flux.
- La capture du contenu multimédia reproduite par le premier terminal comprend l'une au moins des opérations suivantes :
- photographier et/ou filmer, au moyen d'un capteur optique du deuxième terminal, un écran d'affichage du premier terminal affichant une succession d'images fixes ou animées, ou une vidéo ;
- capter, au moyen d'un microphone du deuxième terminal, du son émis par un haut-parleur du premier terminal.
Les capteurs optiques et microphones sont généralement présents sur les appareils connus à disposition des utilisateurs, notamment les téléphones intelligents. Il est alors inutile pour le premier utilisateur d'acquérir un terminal ou des équipements dédiés. - Le procédé de validation comprend en outre, entre la capture du contenu multimédia et la transmission de l'au moins une partie de la première suite de codes, une opération de déchiffrage des codes contenus dans le contenu multimédia capturé par le deuxième terminal, le second flux apte à être transmis comprenant la seconde suite de codes sous forme déchiffrée et tirée du contenu multimédia capturé. La quantité de données à transmettre depuis le deuxième terminal est alors réduite.
D'autres caractéristiques, détails et avantages de l'invention apparaîtront à la lecture de la description détaillée ci-après, et à l'analyse des dessins annexés, sur lesquels :
- la figure 1 montre un système pour la mise en œuvre d'un procédé selon un ou plusieurs modes de réalisation de l'invention, et
- la figure 2 montre un diagramme illustrant un ensemble de procédés proposés selon un ou plusieurs modes de réalisation de l'invention.
Les dessins et la description ci-après contiennent, pour l'essentiel, des éléments de caractère certain. Ils pourront donc non seulement servir à mieux faire comprendre la présente invention, mais aussi contribuer à sa définition, le cas échéant. Dans la description détaillée ci-après de modes de réalisation de l'invention, de nombreux détails spécifiques sont présentés pour apporter une compréhension plus complète. Néanmoins, l'homme du métier peut se rendre compte que des modes de réalisation peuvent être mis en pratique sans ces détails spécifiques. Dans d'autres cas, des caractéristiques bien connues ne sont pas décrites en détail pour éviter de compliquer inutilement la description.
On entend ici par « réseau » une ou plusieurs liaisons permettant le transport de données entre des systèmes informatiques, des terminaux et/ou tous types d'équipement électroniques ou informatiques. La figure 1 représente des interactions entre trois entités distinctes et généralement distantes les unes des autres : un système client 11,12, un dispositif de transaction 20 et un serveur 30. En particulier, un premier utilisateur 1 dispose du système client 11-12 composé d'un premier terminal 11 de communication et d'un deuxième terminal 12 de communication. Eventuellement, un second utilisateur 2 dispose de l'unité 20, aussi appelée dispositif de transaction. Et, notamment, une entité tierce 3 dispose d'un serveur 30. Par abus de langage, les trois entités distinctes sont le premier utilisateur 1, le second utilisateur 2 et l'entité tierce 3.
Le système comprend les éléments suivants : les terminaux 11, 12, l'unité 20 et le serveur 30. Les éléments précités mettent en œuvre des procédés respectifs. Les procédés peuvent donc pour l'essentiel être mis en œuvre par des moyens informatiques. Dans un souci de cohérence et de clarté, les procédés sont décrits ensuite dans leur ensemble afin de mieux appréhender la manière dont les éléments interagissent en fonctionnement. L'homme du métier comprend que les éléments bien distincts ci-avant sont prévus pour fonctionner ensembles et présentant des liens entre eux. Il en est de même pour les aspects procédé de l'invention.
Dans l'exemple d'application prévu ici, le premier utilisateur 1 est une personne souhaitant acheter un article via Internet et se faire livrer à domicile. Le second utilisateur 2 est un commerçant gérant un point de vente, par exemple via un site internet commercial, et souhaitant vendre un article au premier utilisateur 1. L'entité tierce 3 est distincte du premier utilisateur 1 et du second utilisateur 2. L'entité tierce 3 assure le rôle de tiers de confiance entre le premier utilisateur 1 et le second utilisateur 2. L'entité tierce 3 peut, par exemple, être une banque. Dans le présent contexte, le terme « banque » s'entend au sens général d'intermédiaire commercial et/ou financier et ne doit pas être assimilé à un statut légal ou réglementaire particulier.
Dans le contexte de l'invention, le premier terminal 11 désigne un terminal par lequel le premier utilisateur 1 ne souhaite pas faire transiter des données qu'il considère sensibles, par exemple lorsqu'il a des doutes quant à la bonne sécurisation des données qui y sont entrées. Par exemple, le premier terminal 11 peut être prêté au premier utilisateur 1 ou être connecté à un réseau du type Wifi public dont le premier utilisateur 1 ne maîtrise pas les caractéristiques de sécurité. Le deuxième terminal 12 désigne, au contraire, un terminal de confiance pour le premier utilisateur 1. Par exemple, le deuxième terminal 12 peut être un téléphone ou un ordinateur personnel du premier utilisateur 1 et être relié à un réseau de confiance. Les termes « de confiance » se comprennent ici dans leur sens relatif par comparaison avec le premier terminal 11, étant entendu qu'aucun terminal connecté ne peut assurer une sécurité absolue des données qui y sont entrées.
Dans l'exemple illustré par la figure 1, le premier terminal 11 est un ordinateur tandis que le deuxième terminal 12 est un smartphone (« smartphone » étant ici équivalent à « ordiphone », ou « téléphone intelligent »). En variante, les terminaux 1, 2 sont d'un autre type. Le premier terminal 11 comprend des moyens de communication, aussi nommé transmetteur de transactions, aptes à mettre en communication le premier terminal 11 avec l'unité 20, par exemple via le réseau Internet. Les moyens de communication impliquent des protocoles de transferts de données par paquets (comme par exemple le protocole IP (en anglais, « Internet Protocol »)).
Le premier terminal 11 comprend en outre plusieurs interfaces d'entrée/sortie, tel qu'une interface graphique incluant un écran 111, et un haut-parleur 112. Les interfaces d'entrée/sortie peuvent être intégrées au premier terminal 1 ou être déportés, par exemple au moyen de périphériques reliés au premier terminal 11.
Le deuxième terminal 12 comprend des moyens de communication aptes à mettre en communication le deuxième terminal 12 avec le serveur 30, par exemple via le réseau Internet. Les moyens de communication impliquent des protocoles de transferts de données par paquets. Le deuxième terminal 12 comprend en outre des moyens de communication compatibles avec un réseau de télécommunication du type téléphonie mobile, par exemple compatibles GSM, GPRS, EDGE, 3G, 4G ou LTE. D'autres moyens pourront être envisagés. Le deuxième terminal 12 comprend aussi des interfaces d'entrée/sortie, ici des capteurs, par exemple un capteur optique 121 et un microphone 122.
Les interfaces d'entrée/sortie peuvent être intégrées au deuxième terminal 12 ou être déportés, par exemple au moyen de dispositifs communicants avec le deuxième terminal 12. Chacun du premier terminal 11 et du deuxième terminal 12 inclut plusieurs dispositifs, ou unités, parmi lesquels respectivement une interface de transaction 115 et un dispositif de validation 125, chacun incluant un ou plusieurs processeurs qui commandent les opérations du premier terminal 11, respectivement du deuxième terminal 12, comme une unité centrale (CPU) ou un autre processeur matériel, et une mémoire associée (par exemple, une mémoire vive (RAM), une mémoire morte (ROM), une mémoire cache et/ou une mémoire flash, ou tout autre médium de stockage apte au stockage de code logiciel sous forme d'instructions exécutables par un processeur ou de structures de données accessibles par un processeur) couplée de manière opérationnelle au(x) processeur(s). Chacun du premier terminal 11 et du deuxième terminal 12 inclut un système d'exploitation et des programmes, composants, modules, applications sous forme de logiciels exécutés par le(s) processeur(s), qui peuvent être, dans un ou plusieurs modes de réalisation, stockés dans une mémoire non- volatile.
L'homme du métier peut se rendre compte que bien que le système proposé soit décrit dans ses différents modes de réalisation avec le premier terminal 1 de type ordinateur et le deuxième terminal 12 de type smartphone, différents modes de réalisation du système proposé peuvent être mis en œuvre en utilisant différentes combinaisons de types de terminaux de communication, notamment incluant des tablettes.
L'unité 20 et le serveur 30 incluent chacun un ou plusieurs processeurs, comme une unité centrale (CPU) ou un autre processeur matériel, et une mémoire associée (par exemple, une mémoire vive (RAM), une mémoire morte (ROM), une mémoire cache et/ou une mémoire flash, ou tout autre médium de stockage apte au stockage de code logiciel sous forme d'instructions exécutables par un processeur ou de structures de données accessibles par un processeur) couplée de manière opérationnelle au(x) processeur(s). L'unité 20 et le serveur 30 incluent chacun un système d'exploitation et des programmes, composants, modules, applications sous forme de logiciels exécutés par le(s) processeur(s), qui peuvent être, dans un ou plusieurs modes de réalisation, stockés dans une mémoire non-volatile.
L'unité 20 comprend des moyens de communication avec le serveur 30 de l'entité tierce 3 d'une part et avec le premier terminal 11 d'autre part. Ainsi, le serveur 30 comprend un émetteur permettant la transmission du premier flux 100 entre le serveur 30. L'unité 20 comprend un premier transmetteur apte à recevoir le premier flux 100 depuis l'émetteur du serveur 30. L'unité 20 comprend en outre un deuxième transmetteur, dit transmetteur de transactions, permettant les échanges entre l'unité 20 et le premier terminal 11. Ainsi, le premier flux 100 sera reçu du serveur 30 par le premier transmetteur de l'unité 20 puis, éventuellement, émis par le deuxième transmetteur de l'unité vers le premier terminal 11.
L'unité 20 comprend une partie en arrière -plan (ou « back-end » en anglais) incluant le(s) processeur(s) et les moyens de communication avec le serveur 30 de l'entité tierce 3. L'unité 20 comprend une partie en frontale (ou «front-end » en anglais). La partie frontale inclut, ici, un site web accessible via Internet par le premier utilisateur 1, c'est-à-dire une interface utilisateur. Le serveur 30 comprend des moyens de communication avec le deuxième terminal 12 du premier utilisateur 1 d'une part et avec l'unité 20 du second utilisateur 2 d'autre part. Ainsi, le serveur 30 comprend un récepteur apte à attendre la réception de données depuis le deuxième terminal 12 du premier utilisateur 1 (notamment le second flux 200 d'écrit après), et un émetteur apte à transmettre des données au deuxième terminal 12, l'émetteur pouvant distinct ou commun à l'émetteur mentionné ci-avant.
Dans l'exemple décrit ici, les canaux de communication entre le serveur 30 de l'entité tierce 3 et le deuxième terminal 12 du premier utilisateur 1, ainsi que les canaux de communication entre le serveur 30 (ou premier transmetteur) de l'entité tierce 3 et la partie arrière-plan de l'unité 20 du second utilisateur 2, sont sécurisés.
Dans un mode de réalisation particulier, le dispositif de transaction 20 comporte un comparateur de suites de codes comparant une première suite de codes transmise dans un premier flux du dispositif de transaction depuis un serveur, notamment de l'entité tierce, à une seconde suite de code reçue dans un second flux reçu depuis un deuxième terminal, notamment du premier utilisateur. Le dispositif de transaction 20 comporte, en particulier, un premier transmetteur émettant le premier flux au serveur, notamment de l'entité tierce, et/ou un récepteur recevant le second flux. Le dispositif de transaction 20 comporte, notamment, un dispositif d'autorisation autorisant la poursuite de la transaction entre le deuxième terminal et le dispositif de transaction par l'intermédiaire du serveur, c'est-à-dire, notamment, la poursuite de la transaction entre le premier utilisateur et le second utilisateur par l'intermédiaire de l'entité tierce. Éventuellement, le dispositif de transaction 20 comporte une interface utilisateur permettant au premier utilisateur au moyen de son premier terminal d'initialiser une transaction avec le second utilisateur, tel qu'un site web. Dans ce mode de réalisation particulier, par comparaison aux modes de réalisation décrits ci-après, la comparaison des codes et/ou l'autorisation sont réalisées par le dispositif de transaction 20 plutôt que par le serveur 30, notamment de l'entité tierce 3. En référence à la figure 2, les procédés débutent lorsqu'une transaction est préalablement entamée. Par exemple, le premier utilisateur 1 , en tant que client du dispositif de transaction 20, notamment du second utilisateur 2, sélectionne sur le site internet un ensemble de un ou plusieurs articles qu'il souhaite acquérir. Cet ensemble, habituellement appelé « panier », comprend un ensemble d'informations considérées comme non sensibles. Par exemple, des identifiants d'articles, des quantités d'articles, des dates de disponibilité, des dates de livraison possibles et/ou des prix d'articles. Ici, le panier ne comprend pas d'information bancaire ou personnelle relatives au premier utilisateur 1. Autrement dit, à ce stade, le premier utilisateur 1 n'est pas identifié et est sensiblement anonyme du point de vue de l'unité 20 et du second utilisateur 2. Aucune donnée sensible n' a transité par le premier terminal 11 et les canaux de communication reliant le premier terminal 11 à l'unité 20, potentiellement non sécurisés.
En variante, le premier utilisateur 1 peut accepter de transmettre des données personnelles, par exemple en s 'identifiant auprès du site internet du dispositif de transaction 20, notamment du second utilisateur 2. Ceci peut, par exemple, permettre à l'unité 20, notamment du second utilisateur 2, de s'adapter au premier utilisateur 1 en adaptant la navigation sur le site internet à des préférences préenregistrées ou en suggérant des articles en fonction de préférences du premier utilisateur 1. Dans ce cas, quelques données personnelles telles qu'un identifiant et un mot de passe peuvent être entrées sur le premier terminal 11. Néanmoins, les données bancaires du premier utilisateur 1 n'y sont pas entrées.
Lorsque le panier est validé, c'est-à-dire que le premier utilisateur 1 indique qu'il souhaite maintenant régler ses achats, la transaction est entamée. Cet état initial correspond à l'opération référencée 1001 en figure 2. Dans l'exemple d'application proposé ici, l'opération 1001 est mise en œuvre dès la validation du panier. En variante, le dispositif de transaction 20, en particulier du second utilisateur 2, peut proposer à un premier terminal 11, notamment du premier utilisateur 1, la mise en œuvre du système selon l'invention comme un choix parmi d'autres méthodes de transactions, par exemple des méthodes connues en elles-mêmes. Ainsi, le premier utilisateur 1 peut choisir le niveau de sécurisation de ses données, par exemple en fonction de sa confiance pour le premier terminal 11. En cas de choix possible dans les méthodes transaction, l'opération 1001 est mise en œuvre lorsque le premier utilisateur 1 choisi une méthode selon l'invention.
La transaction est initialisée par l'opération 1001. Dans une opération 1002, l'unité 20 transmet au serveur 30 une requête comprenant un identifiant de la transaction initialisée et un identifiant de l'unité 20. L'identifiant de l'unité 20 peut être intégré à l'identifiant de la transaction, par exemple au moyen d'un numéro unique de transaction dont une portion correspond à un identifiant de l'unité 20. L'identifiant de la transaction permet notamment de distinguer, par la suite, deux transactions simultanées issues d'une même unité 20. La requête peut en outre être accompagnée de la fourniture de données relatives à la transaction en cours, par exemple le prix à payer. Dans ce cas, le serveur 30 mémorise les données relatives à la transaction en cours afin de les appeler ultérieurement pour confirmer ou infirmer la transaction. En variante, les données relatives à la transaction en cours peuvent être transmises de l'unité 20 au serveur 30 au cours d'une opération ultérieure.
La requête peut aussi comprendre une liste de type de données que le dispositif de transaction 20 requiert, notamment que le second utilisateur 2 souhaite obtenir. Une telle liste peut comprendre une classification du type de données souhaitées. Par exemple, l'obtention par le dispositif de transaction 20, notamment le second utilisateur 2 d'une adresse de livraison peut être classée comme un type de données impératif, c'est-à-dire en l'absence de laquelle l'unité 20 ne confirmera pas la transaction. Dans le cas où une adresse de livraison n'est pas obtenue, la transaction ne peut pas aboutir. Au contraire, l'obtention d'un numéro de téléphone du premier utilisateur 1 peut être classée comme facultative. En variante, la requête est dépourvue de liste de données souhaitées. Une telle liste peut être établie à titre général pour toute transaction, par exemple lors de la souscription du dispositif de transaction, en particulier du second utilisateur 2, aux services du serveur 30, notamment de l'entité tierce 3, ou ultérieurement lors de la vérification de la transaction. Une telle liste peut aussi ne pas être établie. Dans une opération 1003, le serveur 30 génère une première suite 101 de codes propre à la transaction. Le serveur 30 comprend donc un générateur de codes.
Dans l'exemple décrit ici, la première suite 101, ou série, de codes est générée pour chaque transaction. Le générateur de codes est un générateur de nombres pseudo-aléatoires (ou PRNG pour « PseudoRandom Number Gêner ator » en anglais). Le générateur met en œuvre un algorithme apte à générer des codes dynamiques issus d'une graine propre à chaque dispositif de transaction 20, notamment à chaque second utilisateur 2. La graine est tirée d'une clé privée du dispositif de transaction 20, notamment une clé privée du second utilisateur 2. Le générateur de codes peut générer un nombre quasi-infini et sensiblement en continu composé d'une suite de codes. Ainsi, la suite de codes peut aussi être vue comme un code dynamique. La suite de codes peut par exemple être générée sensiblement en continu pendant toute la durée de la transaction. Ainsi, l'opération 1003 de génération de suite de codes débute à réception de la requête depuis l'unité 20 et peut se poursuivre jusqu'à la fin de la transaction et concurremment aux opérations décrites ci-après. Générer une suite de codes en continu, ou un code dynamique permet de complexifier le décodage par un tiers mal intentionné. Or le code devient inutile à l'issu de la transaction. Il suffit donc que le code reste indéchiffrable le temps de la transaction.
En variante, d'autres types de générateurs de codes peuvent être mis en œuvre pour générer une première suite 101 de codes.
Dans une opération 1004, le serveur 30 transmet à l'unité 20 la première suite 101 de codes. Ici, la première suite 101 est transmise dans un premier flux 100 de données transmis du serveur 30 à l'unité 20. Le premier flux 100 transite par un canal sécurisé entre le serveur 30 et l'unité 20. Le premier flux 100 est sensiblement continu (sous forme de « streaming » en anglais) jusqu'à la fin de la transaction, aux défauts et erreurs près dans la communication entre le serveur 30 et l'unité 20. Autrement dit, en fonction de la qualité de la communication, des parties de la première suite 101 peuvent être manquantes à réception par l'unité 20. La première suite 101 est en outre mémorisée par le serveur 30. La première suite 101 est enregistrée associée à des données identifiant la transaction.
Dans une opération 1005, l'unité 20 transmet au premier terminal 11 le premier flux 100 reçu de l'unité 20, incluant la première suite 101. Autrement dit, l'unité 20 fait office de relais entre le serveur 30 et le premier terminal 11. Le premier flux 100 est aussi sensiblement continu entre le serveur 30 et l'unité 20. Des défauts et erreurs dans la communication entre le serveur 30 et l'unité 20 et entre l'unité 20 et le premier terminal 11 peuvent entraîner des pertes entre la première suite 101 générée par le serveur 3 et la première suite 101 réceptionnée par le premier terminal 11. De telles pertes peuvent être considérées comme négligeables. Néanmoins, l'éventualité de telles pertes sera prise en compte dans la suite.
Dans une opération 1006, à réception du premier flux 100 par le premier terminal 11, le premier terminal 11 est agencé pour diffuser un contenu multimédia 130 incluant au moins une partie de la première suite 101 de codes. Le contenu multimédia 130 peut comprendre, par exemple, du son, des images fixes, des images animées, des vidéos ou une combinaison de tels médiums. Dans l'exemple décrit ici, le contenu multimédia 130 est diffusé via l'écran 111 et/ou le haut- parleur 112 du premier terminal 11.
Dans l'exemple décrit ici, la première suite 101 est encodée en un contenu multimédia 130 par le serveur 30 lui-même après la génération des codes et avant transmission à l'unité 20. Ainsi, la première suite 101 est présente sous forme de contenu multimédia 130 dès sa transmission à l'unité 20, notamment du second utilisateur 2, dans le premier flux 100. Le contenu multimédia 130 est diffusé en streaming par le serveur 30 jusqu'au premier terminal 11 en passant par l'unité 20. En variante, la première suite 101 peut être encodée en un contenu multimédia 130 a posteriori, par exemple par l'unité 20 avant d'être transmis au premier terminal 11.
Dans une étape 1007, le contenu multimédia 130 diffusé par le premier terminal 11 est capturé par le deuxième terminal 12. Dans l'exemple décrit ici, la capture comprend :
- photographier et/ou filmer, au moyen du capteur optique 121 du deuxième terminal 12, l'écran d'affichage 111 du premier terminal 11 affichant une succession d'images fixes ou animées, ou une vidéo, et/ou
- capter, au moyen du microphone 122 du deuxième terminal 12, du son émis par le haut-parleur 112 du premier terminal 11. Les capteurs du deuxième terminal 12 mis à contribution sont choisis compatibles avec le type de contenu multimédia 130 (sons, images fixes, images animées, vidéos ou combinaison des formes précédentes).
Dans l'exemple d'application décrit ci-avant, le premier utilisateur 1 utilise son smartphone 12 pour capter le contenu diffusé par l'ordinateur du cybercafé.
Optionnellement, le contenu multimédia 130 capté par le deuxième terminal 12 est stocké au moins temporairement dans une mémoire du terminal 12, par exemple une mémoire tampon. Dans une opération 1008, le deuxième terminal 12 transmet au serveur 30, notamment de l'entité tierce 3, un second flux 200 de données. Le deuxième terminal 12 comprend un transmetteur apte à transmettre, depuis le terminal 12 au serveur 30, le second flux 200. La transmission peut être réalisée en continu (mode streaming). Le second flux 200 de données comprend une seconde suite 201 de codes. La seconde suite 201 de code est tirée du contenu multimédia 130 tel que capté par le deuxième terminal 12. La seconde suite 201 de codes comprend au moins partiellement la première suite de code 101. Les différences entre la première suite 101 et la seconde suite 201 correspondent aux pertes d'informations successives, à savoir ici les pertes d'information dues aux défauts de communication entre le serveur 30 et l'unité 20, aux défauts de communication entre l'unité 20 et le premier terminal 11 et à la perte d'information due au passage du contenu multimédia 130 du premier terminal 11 au deuxième terminal 12 par diffusion-capture. La seconde suite 201 peut donc être vue comme une partie d'une suite de codes tirée du contenu multimédia 130 capté par les capteurs 121 et/ou 122, et validée par le dispositif de validation 125 du deuxième terminal 12. Le dispositif de validation 125 comporte un générateur de flux insérant dans le second flux 200 de données la seconde suite de codes 201 en réponse à la réception de la première suite 101.
En effet, la transmission des données par diffusion et capture d'un contenu multimédia peut générer une perte d'information substantielle. Néanmoins, il est inutile de connecter le premier terminal 11 et le deuxième terminal 12 l'un à l'autre via une connexion physique ou sans fil. Le premier utilisateur 1 peut ainsi s'assurer que le premier terminal 11 et le deuxième terminal 12 ne communiquent pas informatiquement. Le risque pour la sécurité du deuxième terminal 12 et celle des données auxquelles il est possible d'accéder par l'intermédiaire du deuxième terminal 12 est ainsi réduit. Le deuxième terminal 12 ne transmet aucune information au premier terminal 11. La transmission par diffusion-capture est à sens unique. En outre, la transmission par transmission-capture d'un contenu multimédia nécessite des composants et logiciels généralement disponibles sur les terminaux usuels (haut-parleur, écran, microphone, capteur optique et logiciels correspondants). Les risques d'incompatibilité entre le premier terminal 11 et le deuxième terminal 12, notamment les moyens de connexion, sont aussi réduits. Dans une opération 1009, la seconde suite 201 de codes est extraite du contenu multimédia 130. Autrement dit, le contenu multimédia 130 est déchiffré, totalement ou partiellement, de manière à obtenir la seconde suite 201 de codes.
Dans des modes de réalisation, l'opération 1009 est mise en œuvre, au moins en partie, par le deuxième terminal 12, avant la mise en œuvre de l'opération 1008, soit avant la transmission de la seconde suite 201 au serveur 30. Dans ce cas au moins, le deuxième terminal 12 est équipé d'un module de déchiffrage, aussi nommé dispositif de déchiffrage ou déchiffreur. Le déchiffreur peut prendre la forme d'une application ou d'un logiciel installés sur le deuxième terminal 12. Un tel déchiffreur peut, par exemple, être implémenté dans le dispositif de validation 125 ou, selon le mode de réalisation, mis en œuvre par le dispositif de validation 125 du deuxième terminal 12 et par l'intermédiaire d'une application préalablement installée sur le deuxième terminal 12. Ainsi, des terminaux existants peuvent être rendus conformes au deuxième terminal 12 selon l'invention par une modification logicielle (« software ») sans qu'il soit nécessaire d'intervenir matériellement sur le terminal (« hardware »). En outre, des améliorations peuvent être apportées par des mises à jour du logiciel. De telles applications peuvent être fournies par l'entité tierce 3 fournissant le service. De préférence, lorsqu'un déchiffrage est effectué par le deuxième terminal 12, le déchiffrage est partiel. Ainsi, la quantité de données transmises au serveur 3 est faible et le déchiffrage complet reste centralisé sur le serveur 30.
Ensuite, lors de la mise en œuvre de l'opération 1008 de transmission du second flux 200 au serveur 30, le second flux 200 peut comprendre la seconde suite 201 sous forme au moins partiellement déchiffrée. La transmission peut être réalisée via un canal sécurisé entre le deuxième terminal 12 et le serveur 30. Dans de tels modes de réalisation, la quantité de données transmise depuis le deuxième terminal 12 au serveur 30 est faible, ce qui peut être particulièrement souhaitable, par exemple lorsque la quantité de données reçue et/ou transmise influe sur les coûts supportés par le second utilisateur 2, par exemple dans le cadre d'un abonnement de téléphonie mobile. Dans des modes de réalisation, l'opération 1009 est mise en œuvre par le serveur 30, après la mise en œuvre de l'opération 1008 et à réception du second flux 200 depuis le deuxième terminal 12. Dans ce cas, le deuxième terminal 12 peut être dépourvu de déchiffreur. Le second flux 200 peut comprendre par exemple le contenu multimédia 130 sous une forme brute, non déchiffrée, telle que captée par le deuxième terminal 12. Le second flux 200 comprend des données de capture du contenu multimédia 130. Le serveur 30 comprend un déchiffreur. Dans de tels modes de réalisation, la puissance de calcul du dispositif de validation 125, du deuxième terminal 12 n'est pas utilisée pour le déchiffrage et reste donc disponible pour d'autres usages. En outre, le déchiffreur peut être localisé de manière centralisée sur le serveur 30. En centralisant le module de déchiffrage sur le serveur 30, des caractéristiques de codage du contenu multimédia peuvent rester en partie secrètes, accessibles seulement à l'entité tierce 3, ce qui complexifie la tâche de tiers mal intentionnés.
Après les opérations 1008 et 1009, l'opération 1010 est mise en œuvre. Dans l'opération 1010, la première suite 101 de codes et la seconde suite 201 de codes sont comparées l'une à l'autre. Le serveur 30 comprend un module de comparaison, aussi nommé dispositif de comparaison ou comparateur. Le comparateur peut prendre la forme d'une application ou d'un logiciel installés sur le serveur 30. Un tel comparateur peut, par exemple, être implémenté dans le serveur 30 ou mis en œuvre par le serveur 30 par l'intermédiaire d'une application préalablement installée sur le serveur 30. Dans l'exemple décrit ici, le serveur 30 vérifie que le niveau de correspondance de la seconde suite 201 avec la première suite 101 est supérieur à une valeur seuil C de correspondance prédéfinie, par exemple exprimée en pourcentage. La valeur seuil C est sélectionnée de manière à détecter une identité théorique des codes de la seconde suite 201 et des codes de la première suite 101 tout en tenant compte des erreurs de transmission pouvant avoir lieu entre la transmission du premier flux 100 à l'unité 20, en particulier du second utilisateur 2, (opération 1004) et la réception du second flux 200 (opération 1008) depuis le deuxième terminal 12, notamment du premier utilisateur 1. Autrement dit, l'utilisation d'une valeur seuil C inférieure à 100%, qui correspondrait à une identité parfaite, permet de tenir compte des pertes d'information décrites ci-avant. La valeur seuil C peut être sélectionnée égale à (100 - X) %, où la valeur de X est sélectionnée en fonction de la qualité des moyens de communication mis en œuvre, par exemple proportionnelle à la somme des pourcentages de pertes par erreur de transmission de chacune des transmission depuis la transmission du premier flux 100 à l'unité 20, en particulier du second utilisateur 2, jusqu'à la réception du second flux 200 depuis le second terminal 12, notamment du premier utilisateur 1. Lorsque le niveau de correspondance est suffisant, ici supérieur à la valeur seuil C, alors une opération 1011 est mise en œuvre.
Optionnellement, le serveur 30 peut mettre en œuvre, par exemple préalablement à l'opération 1010, une vérification de la validité de la seconde suite 200 de codes reçue, par exemple en fonction des règles de génération pseudo-aléatoire. Même avant d' avoir identifié la transaction et l'unité 20 correspondant au second flux 200 reçu, une analyse des codes permet de vérifier si les codes sont compatibles avec les règles de génération pseudo-arbitraires mises en œuvre à la génération des codes. Une incompatibilité indique au contraire une corruption de la transaction. Des mesures de sécurité peuvent être prises en conséquence, notamment la fin de la transaction si cette dernière peut être identifiée par la suite (opération 1020). Ainsi, la sécurité contre les fraudes est encore améliorée.
Dans l'exemple représenté en figure 2, l'opération 1010 est répétée jusqu'à ce qu'à détecter un niveau de correspondance suffisant entre une première suite 101 transmise (opération 1004) et une seconde suite 201 reçu (opération 1008). Ceci est particulièrement avantageux en combinaison avec un fonctionnement en continu du procédé : lorsque la suite de codes est générée de manière sensiblement continue, le premier flux 100 ainsi que le second flux 200 peuvent aussi être transmis sensiblement en continu (en mode « streaming »). Une rupture temporaire du circuit de transmission de la suite de codes n'interrompt pas le processus.
Dans des modes de réalisation, lorsqu' aucune correspondance suffisante d'une seconde série 201 n'est atteinte avec une première série 101, il peut être mis fin au processus pour le second flux 200 reçu. De même, lorsqu'aucune correspondance suffisante d'une première série 101 n'est atteinte avec une seconde série 201, il peut être mis fin au processus pour la transaction correspondante. Dans l'exemple décrit ici, les transactions initialisées au niveau du serveur 30 (opération 1003) et les second flux 200 reçus par le serveur 30 (opération 1008) ne sont pas encore associés les uns aux autres par le serveur 3 (opération ultérieure 1011). Dans de tels cas, l'arrêt des itérations de comparaisons (opération 1010) et l'arrêt de la transaction (opérations 1003 et 1004) sont traités de manière distincte.
Dans l'opération 1015 représentée en figure 2, la condition d'arrêt des itérations et de la fin du processus peut par exemple être basée sur une durée de validité présumée. Par exemple, un chronomètre est lancé à réception du second flux 200 (opération 1008). Si la durée écoulée dépasse une durée prédéterminée, alors il est mis fin au processus de comparaison (opération 1010). Le second flux 200 est alors ignoré. Dans ce cas au moins, le serveur 30 est équipé d'une horloge. L'opération 1015 peut aussi limiter le nombre d'itérations, par exemple au moyen d'un compteur d'itérations. D'autres conditions peuvent être mises en œuvre au cours de l'opération 1015. De préférence, un message d'erreur et/ou d'interruption de la transaction est envoyé en réponse au deuxième terminal 12 à l'origine du second flux 200.
Lors de l'initialisation de la transaction par le serveur 3, un chronomètre peut aussi être lancé (opérations 1003 et 1004). Si la durée écoulée dépasse une durée prédéterminée, alors il est mis fin aux processus de génération de codes et de transmission du premier flux (100) (opérations 1003 et 1004). Dans ce cas au moins, le serveur 30 est équipé d'une horloge. De préférence, un message d'erreur et/ou d'interruption de la transaction est envoyé en réponse à l'unité 20 à l'origine de la requête (opération 1002). Ainsi, après initialisation de la transaction, le serveur 3 attend un retour d'un deuxième appareil 12 (non encore identifié) en réponse à la transaction. En cas d'absence de réponse satisfaisante (une seconde série 201 de codes correspondant à la première série 101), il est mis fin à la transaction (opération 1020). Dans l'opération 1011, le deuxième terminal 12, le dispositif de transaction 20 et la transaction courante sont associées (En particulier, le premier utilisateur 1, le second utilisateur 2, et la transaction courante sont associés). Le serveur 30 identifie le deuxième terminal 12, en particulier le premier utilisateur 1, comme étant le client du dispositif de transaction 20, notamment du second utilisateur 2, dans la transaction courante. Par cette association, le serveur, notamment de l'entité tierce 3, peut assurer le rôle d'intermédiaire de confiance entre le deuxième terminal 12 et le dispositif de transaction 20, notamment le premier utilisateur 1 et le second utilisateur 2, dans le cadre de la transaction. Afin d'identifier le premier utilisateur 1, le serveur 30 peut recevoir un identifiant du premier utilisateur 1 transmis par le deuxième terminal 12, par exemple inclus dans le second flux 200 de données.
Dans une opération 1012, la poursuite de la transaction est autorisée entre le deuxième terminal 12 et le dispositif de transaction 20, notamment entre le premier utilisateur 1 et le second utilisateur 2, par l'intermédiaire du serveur 30, et donc, notamment, de l'entité tierce 3. Dans des modes de réalisation, l'autorisation est mise en œuvre par le serveur 30. Le serveur 30 comporte un dispositif d'autorisation autorisant la poursuite de la transaction entre le deuxième terminal 12 et le dispositif de transaction 20, notamment entre le premier utilisateur 1 et le second utilisateur 2 associés, par l'intermédiaire de l'entité tierce 3. Dans de premiers modes de réalisation, l'opération 1012 d'autorisation de poursuite de la transaction comprend la transmission de données depuis le deuxième terminal 12, en particulier du premier utilisateur 1, jusqu'à l'unité 20, notamment du second utilisateur 2, en passant par le serveur 30 faisant office de relai. Ainsi, le premier utilisateur 1 peut transmettre des données sensibles, par exemple bancaires et/ou personnelles, sans passer par le premier terminal 1 potentiellement non sécurisé.
Dans de seconds modes de réalisation, le serveur 30 transmet des données sensibles relatives au premier utilisateur 1 à l'unité 20 de manière au moins partiellement automatique. Par exemple, le serveur 30 peut avoir accès à certaines au moins des données sensibles du premier utilisateur 1. Le premier utilisateur 1 peut avoir fourni à l'entité tierce 3 certaines des données sensibles préalablement à la transaction, par exemple lors d'une souscription au service par le premier utilisateur 1. Par exemple, le premier utilisateur peut avoir fourni à l'entité tierce une adresse de livraison par défaut et des coordonnées bancaires. De telles données sont stockées sur une ou plusieurs bases de données accessibles au serveur 30. Le premier utilisateur 1 peut aussi avoir donné une autorisation préalable au serveur 30 de transmettre lesdites données de manière automatisée dès qu'une transaction est autorisée. Dans ce cas, le serveur 30 peut être dispensé de demander une confirmation supplémentaire au premier utilisateur 1 à chaque transaction. L' autorisation de la poursuite de la transaction peut comprendre : envoyer des données sensibles relatives au premier utilisateur 1 à l'unité 20, notamment du second utilisateur 2, depuis le serveur 30, en particulier de l'entité tierce 3.
De tels modes de réalisation sont particulièrement avantageux lorsque l'entité tierce 3 contrôlant le serveur 30 est un organisme tel qu'un organisme bancaire habituel du premier utilisateur 1. Souvent pour des raisons réglementaires, les organismes bancaires disposent de certaines au moins des informations bancaires et personnelles relatives au premier utilisateur 1. Dans de tels cas, le serveur 30 peut, plutôt que de transmettre les coordonnées bancaires à l'unité 20, transmettre une confirmation de la transaction à l'unité 20. Les échanges financiers peuvent alors être réalisés a posteriori : l'entité tierce 3 faits alors en outre fonction d'intermédiaire financier. Par exemple, l'entité tierce 3 peut se substituer au premier utilisateur 1 en tant que payeur vis-à-vis du second utilisateur 2 et regrouper les paiements de plusieurs transactions de plusieurs premiers utilisateurs en un paiement unique, par exemple par un paiement périodique de l'ensemble des transactions confirmées durant une période antérieure. De même, le serveur 30 peut facturer chaque premier utilisateur 1 en regroupant plusieurs transactions d'un même premier utilisateur 1.
Dans de troisièmes modes de réalisation, le serveur 30 peut transmettre au deuxième terminal 12, notamment du premier utilisateur 1, une demande de confirmation de la transaction. Une telle demande peut comprendre, par exemple, une référence de la transaction, un prix correspondant à la transaction et optionnellement des demandes d'informations complémentaires de la part du dispositif de transaction, en particulier du second utilisateur 2 telle que cela a été décrit ci-avant (courriel, numéro de téléphone, etc.). À réception de la confirmation de la transaction depuis le deuxième terminal 12, notamment du premier utilisateur 1, le serveur 30 peut à son tour transmettre une confirmation de la transaction à l'unité 20, en particulier du second utilisateur 2, optionnellement accompagnées de données complémentaires fournies par le premier utilisateur 1 via le deuxième terminal 12.
Dans tous les cas, le serveur 30 peut optionnellement transmettre une confirmation de la transaction au deuxième terminal 12, et donc, en particulier au premier utilisateur 1 via le deuxième terminal 12. Il est mis fin au processus dans l'opération 1020. L'opération 1020 indique la fin du processus, que la transaction soit finalement réalisée ou annulée.
Le serveur 30 peut, à tout moment, recevoir un refus de confirmation, soit une infirmation, de la transaction de la part du deuxième terminal 12, notamment du premier utilisateur 1 et/ou de la part du dispositif de transaction, en particulier du second utilisateur 2. Dans ce cas, il est mis fin au processus par l'opération 1020, optionnellement après avoir transmis des messages d'annulation de la transaction au deuxième terminal 12, notamment du premier utilisateur 1 et/ou au dispositif de transaction, en particulier du second utilisateur 2.
Lorsqu'une transaction se termine (opération 1020), quelle que soit son issue, la génération de codes et la transmission des flux peuvent être stoppées. Ainsi, le premier flux 100 est transmis en continue en réponse à une requête du dispositif de transaction 20 adressée au serveur 3, et est interrompue à la clôture de la transaction. Par clôture de la transaction, on entend ici soit une réalisation, soit une annulation de la transaction. Les codes mémorisés peuvent être effacés. Ainsi, les comparaisons de l'opération 1010 peuvent être limitées aux transactions actives pour associer chaque second flux 200 reçu par le serveur 30 à une transaction active.
Un procédé de sécurisation de transaction initialisée entre un premier terminal de communication à disposition d'un premier utilisateur et un dispositif de transaction d'un second utilisateur par l'intermédiaire d'un serveur d'une entité tierce comprend :
comparer :
- une première suite de codes transmise avec un premier flux de données associé à la transaction, du serveur de l'entité tierce au dispositif de transaction du second utilisateur, les données du premier flux comprenant la première suite de codes tirés d'une clé privée associée au second utilisateur, et
- une seconde suite de codes reçue avec un second flux de données par le serveur de l'entité tierce depuis un deuxième terminal de communication à disposition du premier utilisateur, ledit deuxième terminal transmettant le second flux en réponse à la réception du premier flux, la comparaison déclenchant, en cas de correspondance entre les deux suites de codes, associer le premier utilisateur, le second utilisateur et la transaction, permettant de délivrer une autorisation de la poursuite de la transaction entre le premier utilisateur et le second utilisateur associés par l'entité tiers. Un tel procédé permet au premier utilisateur d'entamer une transaction avec le second utilisateur, par exemple une commande d'un objet à livrer, sur le premier terminal. Le premier terminal et/ou une partie du réseau utilisé peuvent ne pas être sécurisés, être mal sécurisés ou avoir un niveau de sécurité inconnu de la part du premier utilisateur. L'utilisateur peut néanmoins préférer utiliser un ordinateur d'un cybercafé pour un meilleur confort de navigation plutôt que d'utiliser un smartphone dont l'écran est plus petit (« smartphone » est utilisé ici au sens de « ordiphone » en français). Ainsi, le smartphone peut être utilisé en tant que deuxième terminal. Il est alors inutile pour l'utilisateur d'entrer les données sensibles, notamment les données bancaires et personnelles, sur le premier terminal. Autrement dit, la transaction est possible sans que les données sensibles ne transitent via le premier terminal ou une portion de réseau dont la sécurisation est inconnue.
Selon un autre aspect, la demanderesse propose un serveur d'une entité tierce pour sécuriser une transaction initialisée entre un premier terminal de communication à disposition d'un premier utilisateur et un dispositif de transaction d'un second utilisateur, le serveur étant apte à communiquer avec un deuxième terminal de communication à disposition du premier utilisateur et avec le dispositif de transaction du second utilisateur, le serveur comportant :
- un comparateur :
- d'une première suite de codes transmise avec un premier flux de données associé à la transaction, par un émetteur du serveur de l'entité tierce au dispositif de transaction du second utilisateur, les données du premier flux comprenant la première suite de codes tirés d'une clé privée associée au second utilisateur, et
- d'une seconde suite de codes reçue avec un second flux de données par un récepteur du serveur de l'entité tierce depuis un deuxième terminal de communication à disposition du premier utilisateur, ledit deuxième terminal transmettant le second flux en réponse à la réception du premier flux,
le comparateur étant apte, en cas de correspondance entre les deux suites de codes, à associer le premier utilisateur, le second utilisateur et la transaction, déclenchant
- un dispositif d'autorisation de la poursuite de la transaction entre le premier utilisateur et le second utilisateur associés, par l'intermédiaire de l'entité tiers.
Selon un autre aspect, la demanderesse propose un procédé de validation de transaction initialisée entre un premier terminal de communication à disposition d'un premier utilisateur et un dispositif de transaction d'un second utilisateur, mis en œuvre par un deuxième terminal de communication à disposition du premier utilisateur. Le procédé comprend : insérer dans un second flux de données une seconde suite de codes en réponse à une réception d'une première suite de codes associée à la transaction par le dispositif de transaction du second utilisateur dans un premier flux de données provenant d'un serveur d'une entité tierce, la seconde suite de codes étant tirée d'une clé privée associée au second utilisateur, le second flux étant apte à être transmis depuis le deuxième terminal au serveur de l'entité tierce.
Selon un autre aspect, la demanderesse propose un terminal de communication apte à communiquer avec un serveur et comprenant un dispositif de validation. Le dispositif de validation comporte :
un générateur de flux insérant dans un second flux de données une seconde suite de codes en réponse à une réception d'une première suite de codes associée à la transaction par le dispositif de transaction du second utilisateur dans un premier flux de données provenant d'un serveur d'une entité tierce, la seconde suite de codes étant tirée d'une clé privée associée au second utilisateur, le second flux étant apte à être transmis par un transmetteur du deuxième terminal au serveur de l'entité tierce.
Selon un autre aspect, la demanderesse propose un programme informatique comportant des instructions pour la mise en œuvre de l'un et/ou l'autre des procédés lorsque ce programme est exécuté par un processeur.
Les caractéristiques suivantes peuvent, optionnellement, être mises en œuvre. Elles peuvent être mises en œuvre indépendamment les unes des autres ou en combinaison les unes avec les autres : - Le premier flux est transmis en continue en réponse à une requête du dispositif de transaction adressée au serveur, et est interrompue à la clôture de la transaction. La transmission en continue du premier flux contenant la première suite de codes permet de répéter la comparaison jusqu'à détecter un niveau de correspondance suffisant entre une première suite transmise et une seconde suite reçu.
- La première suite de codes du premier flux prend la forme d'un contenu multimédia. Ainsi, si le second terminal est doté de capteur, il sera inutile de connecter le premier terminal 11 et le second terminal 12 l'un à l'autre via une connexion physique ou sans fil pour que le premier utilisateur lisant la première suite de code reçu saisisse sur son deuxième terminal une deuxième suite de code qui sera transmise dans un deuxième flux. - La comparaison de la première suite de codes et de la seconde suite de codes comprend : vérifier que le niveau de correspondance de la seconde suite avec la première suite est supérieur à une valeur seuil de correspondance prédéfinie et inférieure à 100%. Ceci permet d'identifier une correspondance entre la première et la deuxième suites de codes malgré des erreurs de transmission pouvant avoir lieu entre la transmission du premier flux au dispositif de transaction du second utilisateur et la réception du second flux depuis le second terminal du premier utilisateur. - Le premier flux et/ou le second flux sont chacun transmis via un canal sécurisé, respectivement entre le serveur de l'entité tierce et le dispositif de transaction du second utilisateur, respectivement entre le deuxième terminal du premier utilisateur et le serveur de l'entité tierce. Cette précaution supplémentaire permet de complexifier les tentatives d'un tiers mal intentionné. En ralentissant suffisamment l'interception et l'interprétation des échanges par un tel tiers, il devient probable que la transaction soit clôturé avant que le tiers puisse utiliser les données interceptées. Or, à la clôture de la transaction, les données échangées deviennent inutilisables.
- L' autorisation de la poursuite de la transaction comprend :
- envoyer une demande de confirmation de la transaction au deuxième terminal du premier utilisateur depuis le serveur de l'entité tierce,
- réceptionner une confirmation de la transaction sur le serveur de l'entité tierce depuis le deuxième terminal du premier utilisateur,
- envoyer une confirmation de la transaction au dispositif de transaction du second utilisateur depuis le serveur de l'entité tierce.
Ceci permet par exemple d'éviter de transmettre des données bancaires propres au premier utilisateur, au second utilisateur. Les conséquences éventuelles pour le premier utilisateur d'une mauvaise sécurisation des données stockées et/ou échangées par le second utilisateur sont limitées.
- Le second flux comprend des données de capture d'un contenu multimédia via au moins un capteur du deuxième terminal, la seconde suite de codes étant incluse dans les données de capture du contenu multimédia. Ainsi, si le premier terminal reçoit la première suite de code dans un contenu multimédia qu'il reproduit, il sera inutile de connecter le premier terminal et le second terminal l'un à l'autre via une connexion physique ou sans fil pour que le premier utilisateur lisant la première suite de code reçu saisisse sur son deuxième terminal une deuxième suite de code qui sera transmise dans un deuxième flux.
- Le procédé de validation comprend en outre : capturer un contenu multimédia contenu dans le premier flux, reçu par le premier terminal du dispositif de transaction, et reproduit par le premier terminal, la capture étant réalisée via au moins un capteur du deuxième terminal, le contenu multimédia incluant la première suite de codes. Ainsi, si le premier terminal reçoit la première suite de code dans un contenu multimédia qu'il reproduit, il sera inutile de connecter le premier terminal et le second terminal l'un à l'autre via une connexion physique ou sans fil pour que le premier utilisateur lisant la première suite de code reçu saisisse sur son deuxième terminal une deuxième suite de code qui sera transmise dans un deuxième flux.
- La capture du contenu multimédia reproduite par le premier terminal comprend l'une au moins des opérations suivantes :
- photographier et/ou filmer, au moyen d'un capteur optique du deuxième terminal, un écran d'affichage du premier terminal affichant une succession d'images fixes ou animées, ou une vidéo ;
- capter, au moyen d'un microphone du deuxième terminal, du son émis par un haut-parleur du premier terminal.
Les capteurs optiques et microphones sont généralement présents sur les appareils connus à disposition des utilisateurs, notamment les téléphones intelligents. Il est alors inutile pour le premier utilisateur d'acquérir un terminal ou des équipements dédiés.
- Le procédé de validation comprend en outre, entre la capture du contenu multimédia et la transmission de l'au moins une partie de la première suite de codes, une opération de déchiffrage des codes contenus dans le contenu multimédia capturé par le deuxième terminal, le second flux apte à être transmis comprenant la seconde suite de codes sous forme déchiffrée et tirée du contenu multimédia capturé. La quantité de données à transmettre depuis le deuxième terminal est alors réduite.
En fonction des modes de réalisation choisis ou des combinaisons de modes de réalisation, certains actes, actions, événements ou fonctions de chacune des méthodes et procédés décrits dans le présent document peuvent être effectués ou se produire selon un ordre différent de celui dans lequel ils ont été décrits, ou peuvent être ajoutés, fusionnés ou bien ne pas être effectués ou ne pas se produire, selon le cas. En outre, dans certains modes de réalisation, certains actes, actions ou événements sont effectués ou se produisent concurremment et non pas successivement.
Sauf mention contraire ou incompatibilité manifeste, les caractéristiques de chacun des modes de réalisation et variantes décrits ci-dessus peuvent être mises en œuvre ensemble, ou séparément, ou bien se substituer les uns aux autres.
La présente description divulgue un ensemble de possibilités techniques sans considération d'ordre réglementaire. Bien entendu, la mise en œuvre de l'invention est adaptée aux réglementations applicables. Par conséquent, la présente description ne saurait être interprétée comme une quelconque admission ou incitation au non-respect d'une réglementation, en particulier des réglementations applicables dans les domaines bancaires, financiers et fiscaux et dans les domaines de la conservation et de la transmission de données. L'invention ne se limite pas aux exemples de procédés, serveurs, terminaux, systèmes et programmes décrits ci-avant, seulement à titre d'exemple.

Claims

Revendications
1. Procédé de sécurisation de transaction initialisée entre un premier terminal (11) de communication et un dispositif de transaction (20) par l'intermédiaire d'un serveur (30), le procédé comprenant :
comparer :
- une première suite de codes (101) transmise avec un premier flux (100) de données associé à la transaction, du serveur (30) au dispositif de transaction (20), les données du premier flux (100) comprenant la première suite de codes (101) tirés d'une clé privée associée au dispositif de transaction (20), et
- une seconde suite de codes (201) reçue avec un second flux (200) de données par le serveur (30) depuis un deuxième terminal (12) de communication, ledit deuxième terminal (12) transmettant le second flux (200) en réponse à la réception du premier flux (100),
la comparaison déclenchant, en cas de correspondance entre les deux suites de codes (101 ; 201) associer le deuxième terminal (12), le dispositif de transaction (20) et la transaction, permettant de délivrer une autorisation de la poursuite de la transaction entre le deuxième terminal (12) et le dispositif de transaction (20) associés par le serveur (30).
2. Procédé selon la revendication 1, dans lequel le premier flux (100) est transmis en continue en réponse à une requête du dispositif de transaction (20) adressée au serveur (3), et est interrompue à la clôture de la transaction.
3. Procédé selon l'une des revendications précédentes, dans lequel la première suite de codes (101) du premier flux (100) prend la forme d'un contenu multimédia (130).
4. Procédé selon l'une des revendications précédentes, dans lequel la comparaison de la première suite de codes (101) et de la seconde suite de codes (201) comprend :
- vérifier que le niveau de correspondance de la seconde suite (201) avec la première suite (101) est supérieur à une valeur seuil (C) de correspondance prédéfinie et inférieure à 100%.
5. Procédé selon l'une des revendications précédentes, dans lequel le premier flux (100) et/ou le second flux (200) sont chacun transmis via un canal sécurisé, respectivement entre le serveur (30) de l'entité tierce (3) et le dispositif de transaction (20), respectivement entre le deuxième terminal (12) et le serveur (30).
6. Procédé selon l'une des revendications précédentes, dans lequel l'autorisation de la poursuite de la transaction comprend :
- envoyer une demande de confirmation de la transaction au deuxième terminal (12) depuis le serveur (30),
- réceptionner une confirmation de la transaction sur le serveur (30) depuis le deuxième terminal (12),
- envoyer une confirmation de la transaction au dispositif de transaction (20) depuis le serveur (30).
7. Procédé selon l'une des revendications précédentes, dans lequel le second flux (200) comprend des données de capture d'un contenu multimédia (130) via au moins un capteur (121, 122) du deuxième terminal (12), la seconde suite de codes (201) étant incluse dans les données de capture du contenu multimédia (130).
8. Programme informatique comportant des instructions pour la mise en œuvre du procédé selon l'une des revendications 1 à 7, lorsque ce programme est exécuté par un processeur.
9. Serveur (30) pour sécuriser une transaction initialisée entre un premier terminal (11) de communication et un dispositif de transaction (20), le serveur (30) étant apte à communiquer avec un deuxième terminal (12) de communication à disposition du premier utilisateur (1) et avec le dispositif de transaction (20), le serveur (30) comportant :
- un comparateur :
- d'une première suite de codes (101) transmise avec un premier flux (100) de données associé à la transaction, par un émetteur du serveur (30) au dispositif de transaction (20), les données du premier flux (100) comprenant la première suite de codes (101) tirés d'une clé privée associée au dispositif de transaction, et
- d'une seconde suite de codes (201) reçue avec un second flux (200) de données par un récepteur du serveur (30) depuis un deuxième terminal (12) de communication, ledit deuxième terminal (12) transmettant le second flux (200) en réponse à la réception du premier flux (100), le comparateur étant apte, en cas de correspondance entre les deux suites de codes (101 ; 201), à associer le deuxième terminal (12), le dispositif de transaction (20) et la transaction, déclenchant
- un dispositif d'autorisation de la poursuite de la transaction entre le deuxième terminal (12) et le second utilisateur (2) associés, par l'intermédiaire du serveur (30).
10. Procédé de validation de transaction initialisée entre un premier terminal (11) de communication et un dispositif de transaction (20), mis en œuvre par un deuxième terminal (12) de communication, le procédé comprenant : insérer dans un second flux (200) de données une seconde suite de codes (201) en réponse à une réception d'une première suite de codes (101) associée à la transaction par le dispositif de transaction (20) dans un premier flux de données (100) provenant d'un serveur (30), la seconde suite de codes (201) étant tirée d'une clé privée associée au dispositif de transaction(20), le second flux (200) étant apte à être transmis depuis le deuxième terminal (12) au serveur (30).
11. Procédé selon la revendication 10 comprenant en outre :
- capturer un contenu multimédia (130) contenu dans le premier flux (100), reçu par le premier terminal (11) du dispositif de transaction (20), et reproduit par le premier terminal (11), la capture étant réalisée via au moins un capteur (121, 122) du deuxième terminal (12), le contenu multimédia (130) incluant la première suite de codes (101).
12. Procédé selon la revendication 11, dans lequel la capture du contenu multimédia (130) reproduite par le premier terminal (11) comprend l'une au moins des opérations suivantes :
- photographier et/ou filmer, au moyen d'un capteur optique (121) du deuxième terminal (12), un écran d'affichage (111) du premier terminal (11) affichant une succession d'images fixes ou animées, ou une vidéo ;
- capter, au moyen d'un microphone (122) du deuxième terminal (12), du son émis par un haut- parleur (112) du premier terminal (11).
13. Procédé selon l'une des revendications 11 et 12, comprenant en outre, entre la capture du contenu multimédia (130) et la transmission de l'au moins une partie de la première suite de codes (101), une opération de déchiffrage des codes contenus dans le contenu multimédia (130) capturé par le deuxième terminal (12), le second flux (200) apte à être transmis comprenant la seconde suite de codes (201) sous forme déchiffrée et tirée du contenu multimédia (130) capturé.
14. Programme informatique comportant des instructions pour la mise en œuvre du procédé selon l'une des revendications 10 à 13, lorsque ce programme est exécuté par un processeur.
15. Terminal (12) de communication apte à communiquer avec un serveur (30) et comprenant un dispositif de validation (125) comportant : un générateur de flux insérant dans un second flux (200) de données une seconde suite de codes (201) en réponse à une réception d'une première suite de codes (101) associée à la transaction par le dispositif de transaction (20) dans un premier flux de données (100) provenant d'un serveur (30), la seconde suite de codes (201) étant tirée d'une clé privée associée au dispositif de transaction (20), le second flux (200) étant apte à être transmis par un transmetteur du deuxième terminal (12) au serveur (30).
PCT/FR2017/053542 2016-12-19 2017-12-13 Sécurisation de transaction WO2018115641A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
EP17822409.3A EP3555829A1 (fr) 2016-12-19 2017-12-13 Sécurisation de transaction
US16/470,825 US20190311349A1 (en) 2016-12-19 2017-12-13 Securing transactions
CN201780073985.2A CN110383312B (zh) 2016-12-19 2017-12-13 实现交易安全的方法和系统

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1662729 2016-12-19
FR1662729A FR3060818A1 (fr) 2016-12-19 2016-12-19 Securisation de transaction

Publications (1)

Publication Number Publication Date
WO2018115641A1 true WO2018115641A1 (fr) 2018-06-28

Family

ID=58314470

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2017/053542 WO2018115641A1 (fr) 2016-12-19 2017-12-13 Sécurisation de transaction

Country Status (5)

Country Link
US (1) US20190311349A1 (fr)
EP (1) EP3555829A1 (fr)
CN (1) CN110383312B (fr)
FR (1) FR3060818A1 (fr)
WO (1) WO2018115641A1 (fr)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005107849A (ja) * 2003-09-30 2005-04-21 Nec Corp 決済支援システムおよび決済支援方法

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005001670A2 (fr) * 2003-06-30 2005-01-06 Selvanathan Narainsamy Systeme de verification de transaction
FR2959896B1 (fr) * 2010-05-06 2014-03-21 4G Secure Procede d'authentification d'un utilisateur requerant une transaction avec un fournisseur de service
CN103944734A (zh) * 2014-04-25 2014-07-23 天地融科技股份有限公司 数据安全交互方法

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005107849A (ja) * 2003-09-30 2005-04-21 Nec Corp 決済支援システムおよび決済支援方法

Also Published As

Publication number Publication date
US20190311349A1 (en) 2019-10-10
CN110383312B (zh) 2023-05-16
CN110383312A (zh) 2019-10-25
EP3555829A1 (fr) 2019-10-23
FR3060818A1 (fr) 2018-06-22

Similar Documents

Publication Publication Date Title
WO2012160318A1 (fr) Procede de paiement a distance, a partir d'un dispositif utilisateur, d'un panier d'achat sur un serveur marchand et systeme associe
FR3031613A1 (fr) Procede de traitement d'une transaction a partir d'un terminal de communication.
EP3168769B1 (fr) Procédé d'aide à l'authentification d'un utilisateur, serveur et programme d'ordinateur correspondants
EP3857413A1 (fr) Procede de traitement d'une transaction, dispositif, systeme et programme correspondant
FR3003976A1 (fr) Procede de delivrance d'une assertion de localisation
WO2018115641A1 (fr) Sécurisation de transaction
EP1064777A1 (fr) Systeme de telephonie mobile avec carte de prepaiement
FR2940580A1 (fr) Procede et systeme de controle d'acces a un service
WO2021116627A1 (fr) Procede, serveur et systeme d'authentification de transaction utilisant deux canaux de communication
EP3107023A1 (fr) Procédé, dispositif et programme d'authentification sans fil d'un terminal de payment
EP2897095B1 (fr) Procédé de sécurisation d'une transaction réalisée par carte bancaire
EP4348459A1 (fr) Procédé de traitement d'une transaction, dispositif et programme correspondant
WO2018029564A1 (fr) Systeme et procede d'authentification sans mot de passe d'un utilisateur d'un systeme applicatif par un serveur central
EP1965342A1 (fr) Procédé pour effectuer une transaction entre un module de paiement et un module de sécurité
EP2172896A1 (fr) Méthode de gestion d'une valeur dans un dispositif à prépaiement
WO2022214768A1 (fr) Méthode de contrôle d'accès à un bien ou service distribué par un réseau de communication de données
WO2021044102A1 (fr) Procédé pour activer des droits d'accès à un service auquel a souscrit un abonné
FR3011111A1 (fr) Securisation d'une transmission de donnees d'identification
EP3900293A1 (fr) Procédé et système de sécurisation d'opérations, et poste utilisateur associé
FR2945140A1 (fr) Procede de suspension et d'activation d'un service dans un reseau mobile
FR2945173A1 (fr) Procede d'authentification d'un terminal de communication mobile lors d'un acces a une plateforme de services via un reseau mobile
EP3223219A1 (fr) Procédé de transfert de transaction, procédé de transaction et terminal mettant en oeuvre au moins l'un d'eux
EP3062538A1 (fr) Procédé d'authentification, procédé d'autorisation d'accès, terminal, serveur, composant radio-étiquette, produit, produit programme d'ordinateur et support de stockage correspondant
EP2425388A1 (fr) Procede de taxation et d'acces a un service depuis un terminal de communication mobile
FR3031608A1 (fr) Methode de traitement d'une autorisation de mise en œuvre d'un service, dispositifs et programme d'ordinateur correspondant

Legal Events

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

Ref document number: 17822409

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2017822409

Country of ref document: EP