WO2023274979A1 - Procédé d'authentification de transaction utilisant deux canaux de communication - Google Patents
Procédé d'authentification de transaction utilisant deux canaux de communication Download PDFInfo
- Publication number
- WO2023274979A1 WO2023274979A1 PCT/EP2022/067612 EP2022067612W WO2023274979A1 WO 2023274979 A1 WO2023274979 A1 WO 2023274979A1 EP 2022067612 W EP2022067612 W EP 2022067612W WO 2023274979 A1 WO2023274979 A1 WO 2023274979A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- terminal
- channel
- message
- code
- transaction
- Prior art date
Links
- 238000004891 communication Methods 0.000 title claims abstract description 29
- 238000000034 method Methods 0.000 title claims abstract description 26
- 238000012795 verification Methods 0.000 claims abstract description 54
- 230000004044 response Effects 0.000 claims abstract description 22
- 238000004590 computer program Methods 0.000 claims description 4
- 238000001514 detection method Methods 0.000 claims description 2
- 238000012546 transfer Methods 0.000 description 6
- 238000010200 validation analysis Methods 0.000 description 6
- 241000700605 Viruses Species 0.000 description 3
- 230000008901 benefit Effects 0.000 description 3
- 230000006870 function Effects 0.000 description 3
- 238000009434 installation Methods 0.000 description 3
- 230000008569 process Effects 0.000 description 3
- 238000012545 processing Methods 0.000 description 3
- 238000012790 confirmation Methods 0.000 description 2
- 238000004519 manufacturing process Methods 0.000 description 2
- 230000009471 action Effects 0.000 description 1
- 230000004913 activation Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000004883 computer application Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 230000035755 proliferation Effects 0.000 description 1
- 238000009877 rendering Methods 0.000 description 1
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/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/325—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks
- G06Q20/3255—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks using mobile network messaging services for payment, e.g. SMS
-
- 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/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
- G06Q20/401—Transaction verification
-
- 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/42—Confirmation, e.g. check or permission by the legal debtor of payment
- G06Q20/425—Confirmation, e.g. check or permission by the legal debtor of payment using two different networks, one for transaction and one for security confirmation
Definitions
- the present invention relates to a transaction authentication method using two communication channels. More particularly, the invention relates to the use of a second communication channel to secure a transaction carried out from a first communication channel.
- the electronic payment transactions covered by this document concern payment transactions carried out online.
- An online payment is made when goods or services are sold or purchased, whether by businesses, households, individuals, governments or other organizations, public or private, on interconnected networks of computers, such as the internet. Goods and services are ordered on these networks, but payment and final delivery of the good or service can be done online or offline.
- bank customers regularly carry out wire transfer payment transactions using Internet banking. More and more consumers are using e-commerce to search for and purchase goods and services over electronic networks such as, for example, the Internet. Payment is usually made by entering a debit and/or credit or bank card number or other financial information into the respective fields of a form on the merchant's website. line.
- Transactions may also be made using online or mobile payment service providers, such as those offered by, for example, PayPal, Inc., of San Jose, California.
- electronic payment systems often use agglomerated security solutions such as those identified by the marks “3Dsecure”, “Verified by Visa”, or other.
- Such payment services and payment security solutions can make transactions easier and/or safer for the parties involved. Buying with the help of a payment service provider from a portable mobile terminal is one of the main reasons why online and mobile shopping is growing very quickly.
- the use of a short message has a drawback when the transaction is carried out entirely on an intelligent telephony device of the smartphone or ordiphone type. Indeed, the user cannot view the short message when entering the authentication code on the internet browser because he cannot view this message on his screen simultaneously in his messaging system and the transaction web page, he must switch from one application to another. The user must therefore memorize the authentication code, which constitutes a source of an input error which can cause the user to abandon the transaction. To avoid a memorization error, the user can copy the character string corresponding to the authentication code from the short message and then copy it again (or "paste") into the browser.
- the use of "copy and paste" functions on a smartphone is not mastered by all users and can sometimes be confusing.
- an e-mail has the same drawbacks when the terminal is a telephone or a tablet which does not make it possible to simultaneously view the messaging application and Internet browsing.
- a personal computer user who is not familiar with computer applications may also find it difficult to copy the code from his e-mail to an Internet browser.
- the present invention aims to remedy the inconveniences mentioned above when using an authentication code in a procedure with two security factors when the transaction is carried out on the terminal which receives the message containing the authentication code.
- the subject of the invention is a method for the two-factor authentication of a banking transaction, in which, a terminal of a user being connected to at least one banking transaction server via first and second communication, the second channel being a mobile telephony short message service, the two channels being logically distinct from each other, the terminal comprising within it a mobile application, the following steps are implemented: beforehand:
- the mobile application asks the operating system of the terminal to be alerted in the event of a message received by the short message service
- the mobile application asks the operating system of the terminal for the possibility of reading the messages received by the short message service, then:
- the server determines a transaction verification code
- the server sends, to the mobile application and via the second channel, a message containing the verification code
- - the server sends, to the terminal and via the first channel, a request asking the terminal to resend the verification code via the first channel
- the terminal receives the request on the first channel
- the mobile application automatically detects the receipt of the message on the second channel, - the mobile application automatically identifies the transaction verification code in the message, and to automatically identify the verification code in the message, the mobile application first automatically identifies in the message a predetermined character string, distinct from the verification code, certifying that the message includes a verification code, - the terminal sends back, to the server and via the first channel, a response to the request comprising the identified code.
- the terminal avoids the user having to switch from the first channel to the second, for example from his web browser to his messaging service, and having to memorize or manually copy and paste the code from his second channel to the first.
- the two-factor authentication is therefore carried out as securely as in the state of the art, via the two channels, but without requiring any restrictive manipulation on the part of the user. The risk of error and the probability of abandonment of the transaction are therefore reduced.
- the message includes a "flag", i.e. a string of characters indicating that the message includes a verification code.
- This flag can be specific to a particular transaction protocol (for example “3D Secure”). Its predetermined knowledge can also make it possible to know the format of the code to be identified and its position in the message.
- any mobile terminal of the smartphone or ordiphone type having two logically distinct communication channels, can implement this process.
- a personal computer comprising two logically distinct communication channels, for example the presence of an Internet browser on one side and an e-mail system on the other, is also a terminal capable of executing the method without it being necessary to modify it.
- the invention is therefore easily implemented within an existing architecture.
- the first channel is an Internet browser
- the second channel is a mobile telephone short message service or email messaging.
- the verification code is provided by sms or by e-mail. Its identification and automatic copy saves the user from having to switch from his Internet browser to his mobile phone or e-mail messaging service and remember the code sent there to copy it into the browser.
- the terminal automatically copies the code, from the message received on the first channel, to the response to the request on the second channel.
- the terminal which, without user intervention, reproduces the code in the response to be sent to the server, for example in a field provided for this purpose in the web page of the request.
- the terminal automatically copies the code, from the message received on the first channel, to a buffer memory, - the user copies the code, from the buffer memory, to the response to the request on the second channel.
- the terminal automatically copies the code to the memory, but it is the user who performs the "paste" operation, i.e. the manipulation consisting in copying from the buffer the code to the query response.
- the request comprising a field to be filled in with the verification code
- the response to the request comprises the request with the field filled in.
- the request appears for example on a web page following the transaction request.
- the banking server receives the code provided in the field, via the first channel which is an Internet browser in this example, and compares it with the code sent via the second channel.
- the mobile application asks the operating system of the terminal for the possibility of reading the messages received by the short message service, then: - reception of a request, on a first communication channel of the terminal, requesting the return of a transaction verification code,
- the mobile application first automatically identifies in the message a string of predetermined character, distinct from the verification code, certifying that the message includes a verification code
- the application also asks the operating system of the terminal beforehand for the possibility of deleting the messages received by the short message service
- the application deletes the message, received by the short message service, including the transaction verification code.
- the application automatically deletes the text message containing the verification code, which is therefore removed from the memory of the terminal, this code having become useless.
- a computer program for a mobile terminal comprising instructions which, when the program is executed by a mobile terminal, lead it to implement the steps of the method as described above.
- This program corresponds in particular to the mobile application itself.
- FIG. 1 shows a prior art two-factor authentication business transaction system
- FIG. 2 shows a commercial transaction system with two authentication factors according to the invention
- FIG. 3 illustrates a mobile phone implementing the invention
- FIG. 4 shows an operating flowchart of the method of the invention.
- FIGS. 1 and 2 show two transaction systems carried out through an open network, such as for example the Internet, using two-factor authentication.
- the same references correspond to the same or similar items.
- These two figures correspond to transaction schemes with two security factors as used in the state of the art and according to the invention.
- Open network By “open network”, it is necessary to understand a communication network allowing interconnections between one or more computer machines accessible to anyone wishing to do so.
- This type of network can be the Internet but could correspond to other types of networks as long as the connection remains open to everyone.
- Open networks have the advantage of facilitating the connection of people, thus increasing the possibilities of commercial transactions between people connected to said network.
- a disadvantage of open networks is the risk of interacting with machines belonging to malicious people.
- FIG. 1 corresponds to a banking transaction system allowing a user to carry out transaction operations with his bank, such as for example to carry out a bank transfer or to carry out a purchase of securities online or any other type of operation for which the user makes a money transfer from his bank account.
- the user 1 interacts with a first terminal 2 connected to an open network 3, such as for example the Internet, in order to communicate with a banking services server 4 to carry out an operation corresponding to a banking transaction, that is i.e. a transfer of money from a bank account.
- the first terminal 2 is for example a fixed or portable personal computer, a tablet or a smartphone having a processing unit, at least one volatile and/or non-volatile memory, a communication interface allowing it to connect to the open network 3, a man-machine interface for viewing and entering information, such as for example a display screen, a touch screen, a keyboard, a mouse or other.
- the first terminal has a navigation program on the open network 3, allowing it to connect to and interact with web sites, in particular to consult web pages or to fill in and send forms corresponding to transaction requests.
- the first terminal 2 may have a specific program enabling it to connect through the open network 3 to the banking services server 4.
- the banking services server 4 which will also be called in the following without distinction “banking server” or “banking transaction server”, is for example a computer having one or more processing units, at least one volatile memory and mass, and at least one communication interface allowing it to connect to the open network 3.
- the mass memory stores between others a database containing all the information relating to the bank accounts of the customers of the bank to which it belongs.
- the banking services server 4 includes programs stored in memory allowing it to make available to connected terminals, through the open network 3, searchable web pages which allow interaction with users via forms contained in said web pages. The forms, once completed and returned by the user, are then processed by the processing unit for validation.
- a transaction When a transaction is desired by a user 1, the latter uses the first terminal 2 to connect to the banking services server 4. A web page is then transmitted to the first terminal 2 by the banking services server 4.
- the web page may include information to be displayed on the first terminal 2, as well as commands to be executed according to choices made by the user via the man-machine interface.
- a transaction for example a bank transfer, can be carried out.
- a transaction form By choosing to make a transfer, a transaction form is presented to the user 1, the form can be included in the web page or transmitted by the banking services server 4 after reception of a message indicating the user's choice 1 from the first terminal 2.
- the user 1 then fills out the form with the information necessary for the transaction which may include the identification of the bank account to be credited, the identification of the bank account to be debited, the amount of the transaction. Many other pieces of information may also be required, such as redundant identifiers of the user and/or the bank account or its holder, a secret known only to the bank and the holder, a transaction identifier or any other information that is in connection with the transaction.
- the user 1 sends the completed form to the banking services server 4 via the first terminal 2.
- the form can be accompanied by the time and date of sending and also identifiers specific to the first terminal 2.
- the banking services server 4 verifies the information contained in the form and in particular whether the requested transaction can be authorized or not. To this end, the banking services server 4 interrogates its database to check whether the account to be debited is still in service and whether the credit of the account to be debited can enable the transaction to be authorized. Optionally, the server can verify the correctness of redundant identifiers or information on the holder of the bank account. This first verification corresponds to a first safety factor. However, the transaction was transmitted by the open network 3 and, despite this first verification, it is possible that this transaction comes from misappropriation of the form and/or information relating to the bank account by a malicious third party.
- the communications on the open network 3 can be intercepted and possibly replayed in a modified manner.
- any encrypted message can be decrypted after a certain time, which makes it possible to recover an exchanged form and reuse the information it contains.
- the fact that the network is open allows malicious people to spread viruses on the machines which are connected to it and in particular the first terminal 2. Among the viruses, some can intercept the information exchanged on the man-machine interfaces and send them to another machine also rendering the confidentiality of encrypted messages inoperative.
- a second security factor can be added by using a second communication channel to send a one-time code.
- the banking services server 4 has a second communication interface capable of communicating via the second communication channel with a second terminal 5 which belongs to a bank account holder.
- the second terminal 5 is identified in the database of the banking services server 4 in relation to the bank account to be debited.
- the second terminal 5 can be, conventionally, a mobile telephone of the holder of the bank account, but can also be any other type of device connected to a communication network, such as, for example, a box connected to a mobile telephone network provided by the bank or even a tablet or a computer connected to the Internet.
- the important thing is that the second communication channel is at least logically distinct from the first communication channel used to send the transaction form.
- the banking services server 4 recovers, in its database, the identifier of the second terminal 5 to send it a single-use verification code.
- the identifier of the second terminal 5 is, for example, a mobile telephone number and the message is, for example, sent by a short message of the SMS type (Short Message Service).
- SMS Short Message Service
- the message may also indicate the amount of the transaction and/or the beneficiary of the transaction, so that the account holder can verify that the transaction in progress conforms to a desired transaction.
- SMS messaging short messaging service
- the banking services server 4 sends the first terminal 2 a confirmation request requesting the single-use code.
- User 1 if corresponds to the holder of the bank account, can then read the single-use code on the second terminal 5 and copy it into a response form attached to the confirmation request in order to send it back to the banking services server 4.
- the banking services server 4 Upon receipt of the response form, the banking services server 4 compares the code present in the form with the single-use code sent to the second terminal 5. If the two codes are identical, then the banking services server 4 validates the transaction and sends a message to the first terminal 2 to inform it of the acceptance of the transaction. If the two codes are different, then the transaction is refused and the banking services server 4 sends a message to the first terminal indicating that the transaction is refused.
- the banking services server 4 can reiterate sending a new single-use verification code to the second terminal 5 and a request to the first terminal 2.
- This two-factor authentication the second factor of which is the code provided to the user by a second channel and having to be sent back to the server by the first, makes it possible to improve the security of the transactions.
- the disadvantage is that the user must have both his terminal 2 and his smartphone 5 to validate the transaction. He must copy, via the interface of terminal 2, a code read on smartphone 5, which can be a source of error. These constraints can cause the user to abandon the transaction.
- Figure 2 illustrates elements of a transaction according to the invention that are similar. Instead of using terminal 2 and a smartphone 5 in FIG. 1, the user performs the entire transaction on one and the same smartphone 8, which combines the steps carried out on terminals 2 and 5 of the figure 1.
- the terminal 8 a smartphone, has classic components of any smartphone, as illustrated in FIG. 3. Thus, it has a microprocessor 81 controlling a central bus 87 to exchange data with a memory 84, of the EEPROM type (of the English “Electrically-Erasable Programmable Read-Only Memory”) flash, or else of the ROM type (from the English “Read-Only Memory”) as well as with a volatile memory 83 of the RAM type (from the English “Random Access Memory») It also communicates with the user interface 82 of the terminal 8, comprising in particular a touch screen, and possibly one or more buttons, or even a keyboard.
- the terminal also includes a SIM card 86 and a radio antenna 85 to communicate without contact with the outside, in particular by Internet, by e-mail or by sms.
- An operating system that is to say a computer program, is implemented by the microprocessor 81 to manage all the components of the terminal 8. In particular, this operating system can authorize the read or write access to certain areas of the memory to commands from mobile applications installed on the smartphone 8.
- smartphone 8 is connected by two logically distinct communication channels to the banking services server 4.
- the first channel is the Internet browser, which allows the user of the smartphone 8 to request and then validate the transaction in the same way than on terminal 2 in figure 1. In other words, where user 1 in figure 1 performed the transaction on a computer 2, user 1 in figure 2 performs it on his ordiphone 8, but always online.
- the second channel is, as for the smartphone 5 in FIG. 1, the short message service of the SMS type managed by the operating system of this smartphone 8. It could alternatively be an e-mail system.
- the banking services server 4 always performs the same operations for it: when the user orders a transaction and after verification of a first authentication factor, the server 4 sends to the terminal 8 and via the first channel, i.e. ie here by Internet, a request asking to return a verification code.
- the server 4 produces a single-use verification code which it sends to the smartphone 8 via the second channel, that is to say here by SMS.
- the user 1 is therefore presented on the smartphone 8, on the one hand with a web page where he is asked to provide a verification code to validate the transaction he has initiated, and on the other hand, an sms on his SMS messaging including the code.
- the user manipulating the ordiphone 8
- he could attempt to use the smartphone's copy/paste function for this purpose. In both cases, the process is cumbersome, error-prone and can lead the user to abandon the transaction.
- the ordiphone 8 includes within it a specific mobile application 6, illustrated schematically in FIG. 2, recorded in the memory 83 of the terminal and installed via the operating system of the terminal 8. Once activated, and requested to authenticate a transaction, this mobile application 6 leads the terminal 8 to implement the steps of the flowchart of FIG. 4.
- This mobile application 6 is in the form of a a computer program provided specifically for a mobile terminal. It can be downloaded and installed on any mobile device such as a smartphone or smart phone. In the following, we will describe, by means of figure 4, the steps implemented by the terminal 8 thanks to this application 6.
- the first authentication factor is verified.
- the second is the production, by the banking services server 4, of the verification code, sent by SMS to the terminal 8.
- the application 6 is activated.
- the application 6 listens to the messaging service managed by the operating system of the terminal 8. If and when an SMS is received on the messaging service, an alert is issued at step 102 (an “INTERRU PT” type signal) so as to allow the application 6 to read the received sms, at step 103.
- the sms includes a string of predetermined character attesting that the sms relates to a banking transaction.
- the character string can for example refer to the banking service associated with the transaction, or to a predetermined authentication protocol, for example with the string "3D Secure” which corresponds to the protocol of the same name described in 2017 (“3DSecure2.0 Specification by EMVCo”). Any type of flag can be recognized by the mobile application, from the moment its identification has been provided for in the mobile application, before its installation or during an update. If this string is identified, the mobile application 6 identifies the verification code automatically in step 104.
- this type of sms being known, it is easy to identify a code for example by calculating the position of its first character with respect to the Flag, position which can always be the same.
- This code is then "copied", in step 105, into a buffer memory, for example the RAM memory 83 of the terminal 8.
- the mobile application 6 then provides in step 106 to "paste" the code, that is that is to say, to reproduce this code from the buffer, to automatically place it in the field of the request on the web browser, thus performing a copy-paste operation.
- these steps 101 to 106 lead to the automatic production of the response to the request from the banking service by automatically detecting, identifying and reproducing the code provided by sms in the web page of the transaction and particularly in the corresponding field.
- the user is asked to validate the provision of the code. All he has to do is press the button corresponding to the validation. Conversely, he can also cancel the transaction.
- the banking services server 4 will check in step 108 the conformity of the code received with the code provided, to validate or not the transaction. It should be noted that during all the steps 101 to 106, the user did not have to manipulate the ordiphone 8.
- the monitoring of the sms, the identification of a relevant sms, the identification of the code of verification in the text message, and its copy in the field of the web page were carried out automatically by the mobile application 6, the user having only to validate the provision of this code.
- the mobile application 6 automatically deletes from the messaging system of the terminal 8 the SMS containing the code.
- the code is no longer stored in the memory of the terminal.
- the code can be copied not directly into the field of the web request, but into a separate field, for example within a specific window appearing at the appropriate time (a "pop-up") .
- This “pop-up” displays to the user the code copied from the buffer memory (and therefore before that from the messaging system), and a button allowing the user to validate or not the sending of this code. If it validates, then the application 6 copies the code into the appropriate field of the request, and it adds to the code the characters ' ⁇ r ⁇ , which is interpreted by the browser as the use of the "enter" key or validation.
- the mobile application 6 For the mobile application 6 to be able to carry out the steps described above, it must have the appropriate accesses. This is why, in preliminary steps not illustrated, during the installation of the mobile application 6 on the terminal 8, the latter asks the operating system of the terminal 8 for access to reading the sms (access type "READ") of the messaging service. It also asks for the possibility of being alerted in the event of reception of an sms, and finally the possibility of deleting an sms. It is once these accesses have been accepted, by the user or automatically depending on how the terminal 8 is configured, that the activation can operate as described above.
- READ access type
- This invention therefore makes it possible to copy and paste the verification code received by a second channel, in this case by sms, in order to send it via a first channel, in this case by Internet, in response to a requester requesting this code to validate two-factor authentication. It allows this to be done automatically, avoiding the user having to switch from the browser to their messaging service and vice versa to memorize or manually copy and paste the code received by sms. It reduces the risk of the user abandoning the transaction due to second factor authentication constraints. Another advantage is that it does not require changes to existing systems. Thus, the bank server remains identical. In addition, on the terminal side, the operating system remains identical, there is no need to adapt or update it. The only modified element is the presence of the mobile application installed on the terminal.
- this mobile application can be compatible with any operating system and any bank server, as well as with any payment protocol using two-factor authentication.
- the invention is not limited to the embodiments shown and other embodiments will be apparent to those skilled in the art.
- the two-factor authentication method can be carried out within the framework of the “3D Secure” payment protocol but is not limited to such a type of protocol.
- the communication channels may be different from those mentioned, the invention being applicable to any type of channel accessible by a mobile application, if necessary after requesting access to the operating system.
Landscapes
- Business, Economics & Management (AREA)
- Engineering & Computer Science (AREA)
- Accounting & Taxation (AREA)
- General Business, Economics & Management (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Finance (AREA)
- Computer Networks & Wireless Communication (AREA)
- Computer Security & Cryptography (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Telephonic Communication Services (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
L'invention concerne un procédé (100) d'authentification à deux facteurs. Un terminal est relié à un serveur de transaction bancaire via des premier et deuxième canaux de communication logiquement distincts l'un de l'autre. Il met en œuvre les étapes suivantes: - le serveur détermine un code de vérification de la transaction et envoie, au terminal et via le deuxième canal, un message contenant le code, - le serveur envoie, au terminal et via le premier canal, une requête demandant au terminal de renvoyer le code via le premier canal, - le terminal réceptionne la requête sur le premier canal, - le terminal détecte (102) automatiquement la réception du message sur le deuxième canal et identifie (104) automatiquement le code de vérification de la transaction dans le message, - le terminal renvoie (108), au serveur et via le premier canal, une réponse à la requête comprenant le code identifié.
Description
Description
Titre de l’invention : Procédé d’authentification de transaction utilisant deux canaux de communication La présente invention se rapporte à un procédé d’authentification de transaction utilisant deux canaux de communication. Plus particulièrement, l’invention se rapporte à l’utilisation d’un deuxième canal de communication pour sécuriser une transaction réalisée à partir d’un premier canal de communication.
Les transactions de paiement électronique faisant l’objet de ce document concernent les opérations de paiement réalisées en ligne. Un paiement en ligne est réalisé lors de la vente ou l’achat de biens ou de services, aussi bien par des entreprises, des ménages, des particuliers, des gouvernements ou d’autres organisations, publiques ou privées, sur des réseaux interconnectés d’ordinateurs, tel que par exemple internet. Les biens et services sont commandés sur ces réseaux, mais le paiement et la livraison finale du bien ou du service peuvent être effectués en ligne ou hors ligne. De plus, les clients des banques effectuent régulièrement des opérations de paiement par virement en utilisant les services bancaires par Internet. De plus en plus de consommateurs utilisent le commerce électronique, pour rechercher et acheter des biens et des services sur des réseaux électroniques tels que, par exemple, Internet. Le paiement s'effectue généralement par la saisie d'un numéro de carte de débit et/ou de crédit, ou carte bancaire, ou à l’aide d'autres informations financières dans les champs respectifs d’un formulaire du site du commerçant en ligne. Les transactions peuvent également être effectuées à l'aide de fournisseurs de services de paiement en ligne ou mobiles, tels que ceux proposés par exemple par la société PayPal, Inc., de San José, en Californie. Pour assurer une meilleure sécurité, les systèmes de paiement électronique utilisent souvent des solutions de sécurité agglomérées telles que celle identifiées par les marques « 3Dsecure », « Verified by Visa », ou autre. De tels services de paiement et solutions de sécurité de paiement peuvent rendre les transactions plus faciles et/ou plus sûres pour les parties impliquées. Acheter avec l'aide d'un fournisseur de services de paiement depuis un terminal mobile portable est l'une des principales raisons pour lesquelles les achats en ligne et sur mobile se développent très rapidement.
Les systèmes de paiement en ligne traditionnels exposent les utilisateurs à des risques de sécurité. Par exemple, taper des numéros d’un identifiant de carte de crédit dans un champ d'un formulaire de paiement en ligne expose un utilisateur au vol de ce numéro par une tierce personne qui regarde son écran, par un virus informatique de journalisation de frappe, etc. Bien que le stockage des numéros de carte de crédit par
un détaillant en ligne puisse éviter d’obliger l’utilisateur à saisir manuellement à chaque achat les informations au cours de la transaction de paiement, il expose le détaillant en ligne à ses propres risques et responsabilités en matière de sécurité. Les informations sur les cartes de crédit peuvent également être capturées par des moyens simples, par exemple, en prenant une photo d'une carte exposée par inadvertance, sans oublier que des cartes de crédit peuvent être perdues ou volées, ce qui permet à une personne malintentionnée d’en faire un mauvais usage.
Afin d’améliorer la sécurité des transactions électroniques, les systèmes de paiement électroniques modernes utilisent souvent une procédure dite d'authentification à deux facteurs de sécurité, ci-après désigné 2FA. Les premières procédures 2FA ont utilisé des mots de passe supplémentaires. Sur les terminaux de paiement bancaire, cela s’est traduit par l’utilisation d’un code PIN (de l’anglais « Personal Identification Number») vérifié sur la puce d’une carte bancaire. Pour les transactions bancaires par Internet, l'une des formes les plus anciennes d'authentification à deux facteurs de sécurité, une méthode consiste à émettre aux clients titulaires de carte, avec la carte bancaire, une liste numérotée de nombres d’authentification de transaction, communément nommée TAN (de l’anglais « Transaction Authentication Numbers »), afin que, lors d’une transaction, la banque puisse demander à l'utilisateur de saisir manuellement un nombre d’authentification correspondant à un numéro choisi aléatoirement parmi la liste TAN. Le développement des transactions sur internet et la prolifération des téléphones portables a conduit à la généralisation d’une procédure 2FA utilisant le téléphone mobile comme deuxième canal communication pour envoyer un code d’authentification, de type mot de passe à usage unique ou OTP (de l’anglais « One-Time Password »), par message court ou SMS (de l’anglais « Short Message Service »). En variante, le code d’authentification peut être transmis par courriel.
L’utilisation d’un message court présente cependant un inconvénient lorsque la transaction est réalisée intégralement sur un appareil de téléphonie intelligent de type smartphone ou ordiphone. En effet, l’utilisateur ne peut pas visualiser le message court lors de la saisie du code d’authentification sur le navigateur internet car il ne peut pas visualiser sur son écran simultanément ce message dans sa messagerie et la page web de transaction, il doit passer d’une application à l’autre. L’utilisateur doit donc mémoriser le code d’authentification, ce qui constitue une source d’une erreur de saisie qui peut entraîner l’utilisateur à abandonner la transaction. Pour éviter une erreur de mémorisation, l’utilisateur peut copier la chaîne de caractères correspondant au code d’authentification depuis le message court pour ensuite la recopier (ou « coller ») dans le navigateur. Cependant l’utilisation des fonctions « copier-coller » sur un smartphone n’est pas maîtrisée par tous les utilisateurs et peut parfois être déroutante.
L’utilisation d’un courriel présente les mêmes inconvénients lorsque le terminal est un téléphone ou une tablette qui ne permet pas de visualiser simultanément l’application de messagerie et de navigation sur internet. De plus, un utilisateur d’ordinateur personnel qui n’est pas familier avec les applications informatiques peut également se trouver en difficulté pour recopier le code à partir de sa messagerie vers un navigateur internet.
La présente invention vise à remédier aux désagréments évoqués précédemment lors de l’utilisation de code d’authentification dans une procédure à deux facteurs de sécurité lorsque la transaction est réalisée sur le terminal qui reçoit le message contenant le code d’authentification. A cet effet, l’invention a pour objet un procédé d’authentification à deux facteurs d’une transaction bancaire, dans lequel, un terminal d’un utilisateur étant relié à au moins un serveur de transaction bancaire via des premier et deuxième canaux de communication, le deuxième canal étant un service de message court de téléphonie mobile les deux canaux étant logiquement distincts l’un de l’autre, le terminal comprenant en son sein une application mobile, on met en œuvre les étapes suivantes : au préalable :
- l’application mobile demande au système d’exploitation du terminal à être alertée en cas de message reçu par le service de message court,
- l’application mobile demande au système d’exploitation du terminal la possibilité de lire les messages reçus par le service de message court, ensuite :
- le serveur détermine un code de vérification de la transaction,
- le serveur envoie, à l’application mobile et via le deuxième canal, un message contenant le code de vérification, - le serveur envoie, au terminal et via le premier canal, une requête demandant au terminal de renvoyer le code de vérification via le premier canal,
- le terminal réceptionne la requête sur le premier canal,
- l’application mobile détecte automatiquement la réception du message sur le deuxième canal, - l’application mobile identifie automatiquement le code de vérification de la transaction dans le message, et pour identifier automatiquement le code de vérification dans le message, l’application mobile identifie d’abord automatiquement dans le message une chaîne de caractère prédéterminée, distincte du code de vérification, attestant que le message comprend un code de vérification, - le terminal renvoie, au serveur et via le premier canal, une réponse à la requête comprenant le code identifié.
Ainsi, en détectant automatiquement le code de vérification sur le deuxième canal et en le renvoyant via le premier canal, le terminal évite à l’utilisateur de devoir passer du premier canal au deuxième, par exemple de son navigateur web à son service de messagerie, et de devoir mémoriser ou copier-coller manuellement le code depuis son deuxième canal jusqu’au premier. L’authentification à deux facteurs est donc réalisée de manière aussi sûre que dans l’état de la technique, via les deux canaux, mais sans nécessiter de manipulation contraignante de la part de l’utilisateur. Les risques d’erreur et les probabilités d’abandon de la transaction sont donc diminués.
De plus, le message comprend un « flag », c’est-à-dire une chaîne de caractères indiquant que le message comprend un code de vérification. Ce flag peut être propre à un protocole de transaction particulier (par exemple « 3D Secure »). Sa connaissance prédéterminée peut également permettre de connaître le format du code à identifier et sa position dans le message.
En outre, en particulier lors de l’installation de l’application mobile, celle-ci demande les accès nécessaires à son fonctionnement au système d’exploitation du terminal. Ces accès peuvent être acceptés automatiquement ou sur simple validation de l’utilisateur.
Par ailleurs, vis-à-vis des solutions de l’état de la technique, le seul changement concerne les étapes suivies par le terminal. Il n’est en particulier pas nécessaire de modifier la programmation ou les composants du serveur bancaire. Il n’est pas nécessaire non plus de modifier les composants matériels du terminal, tout terminal mobile de type smartphone ou ordiphone, disposant de deux canaux de communication logiquement distincts, pouvant implémenter ce procédé. Un ordinateur personnel comprenant deux canaux de communication logiquement distincts, par exemple la présence d’un navigateur Internet d’un côté et d’une messagerie de courriels de l’autre, est également un terminal apte à exécuter le procédé sans qu’il soit nécessaire de le modifier. L’invention est donc facilement mise en place au sein d’une architecture existante.
Avantageusement, le premier canal est un navigateur internet, et le deuxième canal est un service de message court de téléphonie mobile ou une messagerie de courriel. Ainsi, tandis que la requête demandant le code est fournie sur une page web, par exemple dans un champ destiné à recevoir le code, le code de vérification est fourni par sms ou par e-mail. Son identification et copie automatique évite à l’utilisateur d’avoir à passer de son navigateur Internet à sa messagerie de téléphonie mobile ou de courriel et à retenir le code qui y a été envoyé pour le recopier dans le navigateur. De préférence, après avoir identifié automatiquement le code de vérification dans le message et avant de renvoyer la réponse au serveur, le terminal copie automatiquement
le code, depuis le message reçu sur le premier canal, vers la réponse à la requête sur le deuxième canal.
Ainsi, c’est le terminal qui, sans intervention de l’utilisateur, reproduit le code dans la réponse à envoyer au serveur, par exemple dans un champ prévu à cet effet dans la page web de la requête.
Alternativement, après avoir identifié le code de vérification dans le message et avant de renvoyer la réponse au serveur :
- le terminal copie automatiquement le code, depuis le message reçu sur le premier canal, vers une mémoire tampon, - l’utilisateur copie le code, depuis la mémoire tampon, vers la réponse à la requête sur le deuxième canal.
Ainsi, dans ce cas, le terminal copie automatiquement le code vers la mémoire, mais c’est l’utilisateur qui réalise l’opération de « collage », c’est-à-dire la manipulation consistant à copier depuis la mémoire tampon le code vers la réponse à la requête. De préférence, la requête comportant un champ à remplir avec le code de vérification, la réponse à la requête comporte la requête avec le champ rempli.
Ainsi, la requête apparaît par exemple sur une page web succédant à la demande de transaction. Une fois le champ rempli avec le code et cette réponse validée, le serveur bancaire reçoit le code fourni dans le champ, via le premier canal qui est un navigateur Internet dans cet exemple, et le compare avec le code envoyé via le deuxième canal.
On prévoit également selon l’invention un procédé d’authentification à deux facteurs d’une transaction bancaire par un terminal mobile, dans lequel le terminal comprend en sein une application mobile mettant en œuvre les étapes suivantes : au préalable : - l’application mobile demande au système d’exploitation du terminal à être alertée en cas de message reçu par le service de message court,
- l’application mobile demande au système d’exploitation du terminal la possibilité de lire les messages reçus par le service de message court, ensuite : - réception d’une requête, sur un premier canal de communication du terminal, demandant le renvoi d’un code de vérification de la transaction,
- détection automatique de la réception d’un message, sur un deuxième canal de communication du terminal logiquement distinct du premier, le deuxième canal étant un service de message court de téléphonie mobile, - identification automatique d’un code de vérification de la transaction dans le message, dans laquelle, pour identifier automatiquement le code de vérification dans le message, l’application mobile identifie d’abord automatiquement dans le message une chaîne de
caractère prédéterminée, distincte du code de vérification, attestant que le message comprend un code de vérification,
- envoi, via le deuxième canal, d’une réponse à la requête comprenant le code identifié.
Ainsi, c’est l’application mobile installée sur le terminal qui met en œuvre les étapes de l’invention. Il n’est donc pas nécessaire de modifier le système d’exploitation du terminal ou d’autres éléments, il suffit d’installer et d’activer l’application, qui peut être implémentée avec tout type de terminal pourvu qu’il ait la capacité à communiquer sur deux canaux de communication logiquement distincts.
Avantageusement : - l’application demande également au préalable au système d’exploitation du terminal la possibilité de supprimer les messages reçus par le service de message court,
- si un utilisateur du terminal invalide la transaction via le premier canal, l’application supprime le message, reçu par le service de message court, comprenant le code de vérification de la transaction. Ainsi, si l’utilisateur annule la transaction, alors l’application supprime automatiquement le sms contenant le code de vérification, qui est donc retiré de la mémoire du terminal, ce code étant devenu inutile.
On prévoit également selon l’invention un programme d'ordinateur pour terminal mobile comprenant des instructions qui, lorsque le programme est exécuté par un terminal mobile, conduisent celui-ci à mettre en œuvre les étapes du procédé tel que décrit ci-avant. Ce programme correspond en particulier à l’application mobile elle- même.
Brève description des figures
L’invention sera mieux comprise et d’autres caractéristiques et avantages de celle-ci apparaîtront à la lecture de la description suivante de modes de réalisation particuliers de l’invention, donnés à titre d’exemples illustratifs et non limitatifs, et faisant référence aux dessins annexés, parmi lesquels :
[Fig. 1] montre un système de transaction commerciale à deux facteurs d’authentification selon l’état de la technique, [Fig. 2] montre un système de transaction commerciale à deux facteurs d’authentification selon l’invention,
[Fig. 3] illustre un téléphone portable mettant en œuvre l’invention,
[Fig. 4] montre un logigramme de fonctionnement du procédé de l’invention.
Description détaillée Les figures 1 et 2 montrent deux systèmes de transaction réalisée au travers d’un réseau ouvert, tel que par exemple internet, en utilisant une authentification à deux facteurs d’authentification. Sur ces deux figures, les mêmes références correspondent
aux mêmes éléments ou à des éléments similaires. Ces deux figures correspondent à des schémas de transaction à deux facteurs de sécurité tel qu’utilisés dans l’état de la technique et selon l’invention.
Par « réseau ouvert », il faut comprendre un réseau de communication permettant des interconnexions entre une ou plusieurs machines informatiques accessible à tout personne souhaitant le faire. Ce type de réseau peut être internet mais pourrait correspondre à d’autres types de réseaux dès lors que la connexion reste ouverte à tout le monde. Les réseaux ouverts ont l’avantage de faciliter une mise en relation des personnes permettant ainsi d’augmenter les possibilités de transactions commerciales entre personnes connectées audit réseau. Un inconvénient des réseaux ouverts est le risque d’interaction avec des machines appartenant à des personnes malveillantes.
La figure 1 correspond à un système de transaction bancaire permettant à un utilisateur de réaliser des opérations de transaction auprès de sa banque, tel que par exemple pour réaliser un virement bancaire ou pour réaliser un achat de titres en ligne ou tout autre type d’opération pour laquelle l’utilisateur réalise un transfert d’argent depuis son compte bancaire. Sur cette figure 1, l’utilisateur 1 interagit avec un premier terminal 2 connecté à un réseau ouvert 3, tel que par exemple internet, afin de communiquer avec un serveur de services bancaires 4 pour réaliser une opération correspondant à une transaction bancaire c’est-à-dire un transfert d’argent depuis un compte bancaire.
Le premier terminal 2 est par exemple un ordinateur personnel fixe ou portable, une tablette ou un smartphone disposant d’une unité de traitement, d’au moins une mémoire volatile et/ou non volatile, d’une interface de communication lui permettant de se connecter au réseau ouvert 3, d’une interface homme-machine permettant de visualiser et de rentrer des informations, tel que par exemple un écran de visualisation, un écran tactile, un clavier, une souris ou autre. Parmi les programmes stockés dans sa mémoire, le premier terminal dispose d’un programme de navigation sur le réseau ouvert 3, lui permettant de se connecter sur et d’interagir avec des sites web, notamment pour consulter des pages web ou pour remplir et envoyer des formulaires correspondant à des requêtes de transaction. De manière alternative, le premier terminal 2 peut disposer d’un programme spécifique lui permettant de se connecter au travers du réseau ouvert 3 au serveur de services bancaires 4.
Le serveur de services bancaires 4, qu’on appellera dans la suite également indifféremment « serveur bancaire » ou « serveur de transaction bancaire », est par exemple un ordinateur disposant d’une ou plusieurs unités de traitement, d’au moins une mémoire volatile et de masse, et d’au moins une interface de communication lui permettant de se connecter au réseau ouvert 3. La mémoire de masse mémorise entre
autres une base de données contenant toutes les informations relatives aux comptes bancaires des clients de la banque à laquelle il appartient. Le serveur de services bancaires 4 comporte des programmes stockés en mémoire lui permettant de mettre à disposition de terminaux connectés, au travers du réseau ouvert 3, des pages web consultables qui permettent d’interagir avec des utilisateurs via des formulaires contenus dans lesdites pages web. Les formulaires, une fois remplis et renvoyés par l’utilisateur, sont ensuite traités par l’unité de traitement pour validation.
Lorsqu’une transaction est souhaitée par un utilisateur 1, celui-ci utilise le premier terminal 2 pour se connecter au serveur de services bancaires 4. Une page web est alors transmise au premier terminal 2 par le serveur de services bancaires 4. La page web peut comporter des informations à visualiser sur le premier terminal 2, ainsi que des commandes à exécuter en fonction de choix fait par l’utilisateur par l’intermédiaire de l’interface homme-machine. Parmi les choix offerts à l’utilisateur 1, une transaction, par exemple un virement bancaire, peut être réalisée. En choisissant de réaliser un virement, un formulaire de transaction est présenté à l’utilisateur 1, le formulaire pouvant être inclus dans la page web ou transmis par le serveur de services bancaires 4 après réception d’un message indiquant le choix de l’utilisateur 1 provenant du premier terminal 2. L’utilisateur 1 remplit alors le formulaire avec les informations nécessaires à la transaction qui peuvent comprendre l’identification du compte bancaire à créditer, l’identification du compte bancaire à débiter, le montant de la transaction. De nombreuses autres informations peuvent également être requises, telles que des identifiants redondants de l’utilisateur et/ou du compte bancaire ou de son titulaire, un secret connu uniquement de la banque et du titulaire, un identifiant de transaction ou toute autre information qui soit en relation avec la transaction. Une fois le formulaire rempli, l’utilisateur 1 envoie le formulaire rempli au serveur de services bancaires 4 via le premier terminal 2. Le formulaire peut être accompagné de l’heure et de la date d’envoi et également d’identifiants propres au premier terminal 2.
Ayant reçu le formulaire de transaction rempli, le serveur de services bancaires 4 vérifie les informations contenues dans le formulaire et notamment si la transaction demandée peut être autorisée ou non. A cet effet, le serveur de services bancaires 4 interroge sa base de données pour vérifier si le compte à débiter est toujours en service et si le crédit du compte à débiter peut permettre d’autoriser la transaction. Eventuellement, le serveur peut vérifier la justesse d’identifiants redondants ou d’informations sur le titulaire du compte bancaire. Cette première vérification correspond à un premier facteur de sécurité. Cependant, la transaction a été transmise par le réseau ouvert 3 et, malgré cette première vérification, il est possible que cette transaction
provienne d’un détournement du formulaire et/ou des informations relatives au compte bancaire par un tiers malveillant.
En effet, les communications sur le réseau ouvert 3 peuvent être interceptées et rejouées éventuellement de manière modifiée. Afin de garantir un minimum de sécurité, il est connu d’encrypter les messages sensibles entre deux machines, tel que par exemple le terminal 2 et le serveur de services bancaires 4, à l’aide de clefs de sessions ou de clefs spécifiques. Cependant, tout message encrypté peut être décrypté au bout d’un certain temps, ce qui permet de récupérer un formulaire échangé et de réutiliser les informations qu’il contient. De plus, le fait que le réseau soit ouvert permet à des personnes malintentionnées de diffuser des virus sur les machines qui y sont connectées et notamment le premier terminal 2. Parmi les virus, certains peuvent intercepter les informations échangées sur l’interfaces homme-machine et les renvoyer vers une autre machine rendant également inopérante la confidentialité de messages encryptés.
Afin de rajouter un niveau de sécurité, un deuxième facteur de sécurité peut être rajouté en utilisant un deuxième canal de communication pour envoyer un code à usage unique. A cet effet, le serveur de services bancaires 4 dispose d’une deuxième interface de communication apte à communiquer via le deuxième canal de communication avec un deuxième terminal 5 qui appartient à un titulaire de compte bancaire. Le deuxième terminal 5 est identifié dans la base de données du serveur de services bancaires 4 en relation avec le compte bancaire à débiter. Le deuxième terminal 5 peut être, classiquement, un téléphone mobile du titulaire du compte bancaire, mais peut également être tout autre type de dispositif connecté à un réseau de communication, tel que, par exemple, un boîtier connecté à un réseau de téléphonie mobile fourni par la banque ou encore une tablette ou un ordinateur relié à internet. L’important est que le deuxième canal de communication soit au moins logiquement distinct du premier canal de communication utilisé pour l’envoi du formulaire de transaction.
Après avoir fait la première vérification, le serveur de services bancaires 4 récupère, dans sa base de données, l’identifiant du deuxième terminal 5 pour lui envoyer un code de vérification à usage unique. L’identifiant du deuxième terminal 5 est, par exemple, un numéro de téléphone mobile et le message est, par exemple, envoyé par un message court de type SMS (de l’anglais Short Message Service). Le message peut également indiquer le montant de la transaction et/ou le bénéficiaire de la transaction, de sorte que le titulaire du compte puisse vérifier que la transaction en cours est conforme à une transaction désirée. Il est à noter que le service de messagerie court (messagerie SMS) est géré par le système d’exploitation de l’ordiphone 5.
En parallèle, le serveur de services bancaires 4 envoie au premier terminal 2 une requête de confirmation demandant le code à usage unique. L’utilisateur 1, s’il
correspond au titulaire du compte bancaire, peut alors lire le code à usage unique sur le deuxième terminal 5 et le recopier dans un formulaire de réponse joint à la requête de confirmation afin de le renvoyer au serveur de services bancaires 4.
A réception du formulaire de réponse, le serveur de services bancaires 4 compare le code présent dans le formulaire avec le code à usage unique envoyé au deuxième terminal 5. Si les deux codes sont identiques, alors le serveur de services bancaires 4 valide la transaction et envoie un message au premier terminal 2 pour l’informer de l’acceptation de la transaction. Si les deux codes sont différents, alors la transaction est refusée et le serveur de services bancaires 4 envoie un message au premier terminal indiquant que la transaction est refusée. De manière optionnelle, le serveur de services bancaires 4 peut réitérer l’envoi d’un nouveau code de vérification à usage unique au deuxième terminal 5 et d’une requête au premier terminal 2. Cette authentification à deux facteurs, dont le deuxième facteur est le code fourni à l’utilisateur par un deuxième canal et devant être renvoyé au serveur par le premier, permet d’améliorer la sécurité des transactions. L’inconvénient est que l’utilisateur doit disposer à la fois de son terminal 2 et de son ordiphone 5 pour valider la transaction. Il doit recopier, via l’interface du terminal 2, un code lu sur l’ordiphone 5, ce qui peut être source d’erreur. Ces contraintes peuvent pousser l’utilisateur à abandonner la transaction.
La figure 2 illustre des éléments d’une transaction selon l’invention qui sont similaires. Au lieu d’utiliser le terminal 2 et un l’ordiphone 5 de la figure 1, l’utilisateur réalise l’intégralité de la transaction sur un seul et même ordiphone 8, qui regroupe les étapes réalisées sur les terminaux 2 et 5 de la figure 1.
Le terminal 8, un smartphone, présente des composants classiques de tout ordiphone, comme illustré à la figure 3. Ainsi, il présente un microprocesseur 81 contrôlant un bus central 87 pour échanger des données avec une mémoire 84, de type EEPROM (de l’anglais « Electrically-Erasable Programmable Read-Only Memory ») flash, ou encore de type ROM (de l’anglais « Read-Only Memory») ainsi qu’avec une mémoire 83 volatile de type RAM (de l’anglais « Random Access Memory») Il communique également avec l’interface utilisateur 82 du terminal 8, comprenant en particulier un écran tactile, et éventuellement un ou plusieurs boutons, voire un clavier. Le terminal comprend également une carte SIM 86 et une antenne radioélectrique 85 pour communiquer sans contact avec l’extérieur, en particulier par Internet, par e-mail ou par sms. Un système d’exploitation, c’est-à-dire un programme d’ordinateur, est mis en œuvre par le microprocesseur 81 pour gérer l’ensemble des composants du terminal 8. En particulier, ce système d’exploitation peut autoriser l’accès en lecture ou en écriture de certaines zones de la mémoire à des commandes provenant d’applications mobiles installées sur le smartphone 8. Bien sûr, de nombreuses variantes d’architecture de
téléphone intelligent sont connues et l’homme du métier peut à loisir utiliser une architecture différente ou similaire de celle décrite sur la figure 3. Néanmoins, l’homme du métier prendra soin de n’utiliser que des architectures comprenant la possibilité de communiquer par au moins deux canaux de communications logiquement distincts. Ainsi, cet ordiphone 8 est relié par deux canaux de communication logiquement distincts au serveur de services bancaires 4. Le premier canal est le navigateur Internet, qui permet à l’utilisateur de l’ordiphone 8 de requérir puis valider la transaction de la même manière que sur le terminal 2 de la figure 1. En d’autres termes, là où l’utilisateur 1 de la figure 1 réalisait la transaction sur un ordinateur 2, l’utilisateur 1 de la figure 2 la réalise sur son ordiphone 8, mais toujours par Internet. Le deuxième canal est, comme pour l’ordiphone 5 de la figure 1, le service de message court de type SMS géré par le système d’exploitation de cet ordiphone 8. Ce pourrait être alternativement une messagerie de courriels. Le serveur de services bancaires 4 lui réalise toujours les mêmes opérations : lorsque l’utilisateur commande une transaction et après la vérification d’un premier facteur d’authentification, le serveur 4 envoie au terminal 8 et par le premier canal, c’est-à-dire ici par Internet, une requête demandant de renvoyer un code de vérification. Il s’agit d’afficher à l’écran, via le navigateur web de l’ordiphone 8, la requête avec un champ à remplir destiné à ce code. Parallèlement, le serveur 4 produit un code de vérification à usage unique qu’il envoie à l’ordiphone 8 via le deuxième canal, c’est-à-dire ici par SMS. L’utilisateur 1 se voit donc présenter sur le smartphone 8, d’une part une page web où il lui est demandé de fournir un code de vérification pour valider la transaction qu’il a initié, et d’autre part, un sms sur sa messagerie SMS comprenant le code.
A ce stade, dans une transaction selon l’état de l’art, l’utilisateur, manipulant l’ordiphone 8, aurait alors à quitter son navigateur internet pour ouvrir son application de messagerie, à lire le code de vérification du sms reçu et à revenir au navigateur pour remplir, de mémoire, le champ destiné au code de vérification dans la page web où la requête correspondante apparaît. Alternativement, il pourrait tenter d’utiliser la fonction copier/coller de l’ordiphone à cet effet. Dans les deux cas, le processus est contraignant, source d’erreurs et peut conduire l’utilisateur à abandonner la transaction.
C’est pourquoi, à la différence de l’ordiphone 5 de la figure 1 , l’ordiphone 8 comprend en son sein une application mobile 6 spécifique, illustrée schématiquement à la figure 2, enregistrée dans la mémoire 83 du terminal et installée via le système d’exploitation du terminal 8. Une fois activée, et sollicitée pour authentifier une transaction, cette application mobile 6 conduit le terminal 8 à mettre en œuvre les étapes du logigramme de la figure 4. Cette application mobile 6 se présente sous la forme d’un programme d’ordinateur prévu spécifiquement pour un terminal mobile. Elle peut être téléchargée et
installée sur tout terminal mobile de type ordiphone ou téléphone intelligent. Dans la suite, on décrira, au moyen de la figure 4, les étapes mises en œuvre par le terminal 8 grâce à cette application 6.
Rappelons que le contexte est le suivant : l’utilisateur 1 commande une transaction sur Internet via son terminal 8. Le premier facteur d’authentification est vérifié. Le deuxième est la production, par le serveur de services bancaires 4, du code de vérification, envoyé par sms au terminal 8. On considère que l’application 6 est activée. Alors, dans une première étape 101, l’application 6 est à l’écoute du service de messagerie géré par le système d’exploitation du terminal 8. Si et lorsqu’un sms est reçu sur le service de messagerie, une alerte est émise à l’étape 102 (un signal de type « INTERRU PT ») de manière à permettre à l’application 6 de lire le sms reçu, à l’étape 103. A cette étape, il est déterminé si le sms comprend une chaîne de caractère prédéterminée attestant que le sms concerne une transaction bancaire. Si ce n’est pas le cas, rien n’est effectué et le procédé renvoie à l’étape 101, en attente du prochain sms. La chaîne de caractère, appelée « Flag », peut par exemple faire référence au service bancaire associé à la transaction, ou à un protocole d’authentification prédéterminé, par exemple avec la chaîne « 3D Secure » qui correspond au protocole du même nom décrit en 2017 (« 3DSecure2.0 Spécification by EMVCo »). Tout type de flag peut être reconnu par l’application mobile, à partir du moment où son identification a été prévue dans l’application mobile, avant son installation ou au cours d’une mise à jour. Si cette chaîne est identifiée, l’application mobile 6 identifie le code de vérification automatiquement à l’étape 104. En particulier, le format de ce type de sms étant connu, il est aisé d’identifier un code par exemple en calculant la position de son premier caractère vis-à-vis du Flag, position qui peut être toujours la même. Ce code est alors « copié », à l’étape 105, dans une mémoire tampon, par exemple la mémoire RAM 83 du terminal 8. L’application mobile 6 prévoit alors à l’étape 106 de « coller » le code, c’est-à-dire de reproduire ce code à partir de la mémoire tampon, pour le placer automatiquement dans le champ de la requête sur le navigateur web, réalisant ainsi une opération de copier-coller. En résumé, ces étapes 101 à 106 conduisent à produire automatiquement la réponse à la requête du service bancaire en détectant, identifiant et reproduisant automatiquement le code fourni par sms dans la page web de la transaction et particulièrement dans le champ correspondant. A l’étape 107, il est demandé à l’utilisateur de valider la fourniture du code. Il lui suffit d’appuyer sur le bouton correspondant à la validation. A l’inverse, il peut également annuler la transaction. En cas de validation et de manière classique, non propre à l’invention, le serveur de services bancaires 4 vérifiera à l’étape 108 la conformité du code reçu avec le code prévu, pour valider ou non la transaction.
II est à noter que durant toutes les étapes 101 à 106, l’utilisateur n’a pas eu à manipuler l’ordiphone 8. Ainsi, la surveillance des sms, l’identification d’un sms pertinent, l’identification du code de vérification dans le sms, et sa copie dans le champ de la page web, ont été réalisées automatiquement par l’application mobile 6, l’utilisateur n’ayant qu’à valider la fourniture de ce code. A l’inverse, comme on l’a dit, il peut aussi l’annuler à l’étape 107. Dans ce cas, à l’étape 109, ou même si l’utilisateur annule la transaction plus tôt mais après avoir reçu le code de vérification par sms, l’application mobile 6 supprime automatiquement de la messagerie du terminal 8 le sms contenant le code. Ainsi, le code n’est plus stocké dans la mémoire du terminal. Alternativement, on peut tout à fait prévoir de renvoyer le code sans même demander la validation à l’utilisateur. Dans ce cas, l’utilisateur ne réalise plus aucune action à partir du moment où il a commandé la transaction avant l’étape 101, tout le processus correspondant au second facteur étant réalisé automatiquement sans intervention de sa part. Alternativement, on peut prévoir que le code est copié non pas directement dans le champ de la requête web, mais dans un champ distinct, par exemple au sein d’une fenêtre spécifique apparaissant à l’instant approprié (une « pop-up »). Cette « pop -up » affiche à l’utilisateur le code copié depuis la mémoire tampon (et donc avant cela depuis la messagerie), et un bouton permettant à l’utilisateur de valider ou non l’envoi de ce code. S’il valide, alors l’application 6 copie le code dans le champ approprié de la requête, et elle ajoute au code les caractères ‘\rï, ce qui est interprété par le navigateur comme l’emploi de la touche « entrée » ou une validation. Ainsi, il n’est pas redemandé à l’utilisateur de valider ce code puisqu’il l’a déjà fait lorsqu’il a été affiché dans la « pop- up ». Alternativement encore, on peut prévoir que le code est copié depuis la messagerie dans la mémoire tampon, mais qu’au lieu de le coller dans le champ de la page web ou dans une « pop-up » automatiquement, c’est à l’utilisateur de réaliser manuellement cette fonction de « collage » dans le champ de la page web.
Pour que l’application mobile 6 puisse réaliser les étapes décrites ci-avant, il est nécessaire qu’elle dispose des accès appropriés. C’est pourquoi, dans des étapes préalables non illustrées, lors de l’installation de l’application mobile 6 sur le terminal 8, celle-ci demande au système d’exploitation du terminal 8 l’accès à la lecture des sms (accès de type « READ ») du service de messagerie. Elle demande également la possibilité d’être alertée en cas de réception d’un sms, et enfin la possibilité de supprimer un sms. C’est une fois que ces accès ont été acceptés, par l’utilisateur ou automatiquement en fonction de la manière dont le terminal 8 est configuré, que l’activation peut fonctionner comme décrit plus haut.
Cette invention permet donc de copier-coller le code de vérification reçu par un deuxième canal, en l’espèce par sms, afin de l’envoyer via un premier canal, en l’espèce par Internet, en réponse à une requêtant demandant ce code pour valider l’authentification à deux facteurs. Elle permet de faire cela automatiquement, évitant à l’utilisateur de passer du navigateur à son service de messagerie et vice versa pour mémoriser ou copier-coller manuellement le code reçu par sms. Elle réduit le risque de voir l’utilisateur abandonner la transaction du fait des contraintes liées au second facteur d’authentification. L’un des autres avantages est qu’elle ne nécessite pas de modifier les systèmes en vigueur. Ainsi, le serveur bancaire reste identique. En outre, du côté du terminal, le système d’exploitation reste identique, il n’est pas nécessaire de l’adapter ou de le mettre à jour. L’unique élément modifié est la présence de l’application mobile installée sur le terminal. En outre, cette application mobile peut être compatible avec tout système d’exploitation et tout serveur bancaire, de même qu’avec tout protocole de paiement utilisant une authentification à deux facteurs. L'invention n'est pas limitée aux modes de réalisation présentés et d'autres modes de réalisation apparaîtront clairement à l'homme du métier. En particulier, le procédé d’authentification à deux facteurs peut être réalisé dans le cadre du protocole de paiement « 3D Secure » mais n’est pas limité à un tel type de protocole. De même, les canaux de communication peuvent être différents de ceux mentionnés, l’invention pouvant s’appliquer à tout type de canaux accessible par une application mobile, si nécessaire après demande d’accès au système d’exploitation.
Claims
[Revendication 1] Procédé (100) d’authentification à deux facteurs d’une transaction bancaire, dans lequel, un terminal (8) d’un utilisateur étant relié à au moins un serveur de transaction bancaire (4) via des premier et deuxième canaux de communication, le deuxième canal étant un service de message court de téléphonie mobile les deux canaux étant logiquement distincts l’un de l’autre, le terminal comprenant en son sein une application mobile, on met en œuvre les étapes suivantes : au préalable :
- l’application mobile (6) demande au système d’exploitation du terminal (8) à être alertée en cas de message reçu par le service de message court,
- l’application mobile (6) demande au système d’exploitation du terminal (8) la possibilité de lire les messages reçus par le service de message court, ensuite :
- le serveur (4) détermine un code de vérification de la transaction,
- le serveur (4) envoie, à l’application mobile et via le deuxième canal, un message contenant le code de vérification,
- le serveur (4) envoie, au terminal (8) et via le premier canal, une requête demandant au terminal (8) de renvoyer le code de vérification via le premier canal,
- le terminal réceptionne la requête sur le premier canal,
- l’application mobile (6) détecte (102) automatiquement la réception du message sur le deuxième canal,
- l’application mobile (6) identifie (104) automatiquement le code de vérification de la transaction dans le message, et pour identifier (104) automatiquement le code de vérification dans le message, l’application mobile (6) identifie d’abord (103) automatiquement dans le message une chaîne de caractère prédéterminée, distincte du code de vérification, attestant que le message comprend un code de vérification,
- le terminal renvoie (108), au serveur et via le premier canal, une réponse à la requête comprenant le code identifié.
[Revendication 2] Procédé (100) selon la revendication précédente, dans lequel le premier canal est un navigateur internet, et le deuxième canal est un service de message court de téléphonie mobile ou une messagerie de courriel.
[Revendication 3] Procédé (100) selon l’une quelconque des revendications précédentes, dans lequel, après avoir identifié (104) automatiquement le code de vérification dans le message et avant de renvoyer (108) la réponse au serveur, le terminal (8) copie (105) automatiquement le code, depuis le message reçu sur le premier canal, vers (106) la réponse à la requête sur le deuxième canal.
[Revendication 4] Procédé (100) selon l’une quelconque des revendications 1 à 2, dans lequel, après avoir identifié (104) le code de vérification dans le message et avant de renvoyer (108) la réponse au serveur :
- le terminal (8) copie (105) automatiquement le code, depuis le message reçu sur le premier canal, vers une mémoire tampon,
- l’utilisateur copie le code, depuis la mémoire tampon, vers la réponse à la requête sur le deuxième canal.
[Revendication 5] Procédé (100) selon l’une des revendications précédentes, dans lequel, la requête comportant un champ à remplir avec le code de vérification, la réponse à la requête comporte la requête avec le champ rempli.
[Revendication 6] Procédé (100) d’authentification à deux facteurs d’une transaction bancaire par un terminal mobile (8), dans lequel le terminal (8) comprend en sein une application mobile (6) mettant en œuvre les étapes suivantes : au préalable :
- l’application mobile (6) demande au système d’exploitation du terminal (8) à être alertée en cas de message reçu par le service de message court,
- l’application mobile (6) demande au système d’exploitation du terminal (8) la possibilité de lire les messages reçus par le service de message court, ensuite :
- réception d’une requête, sur un premier canal de communication du terminal (8), demandant le renvoi d’un code de vérification de la transaction,
- détection automatique (102) de la réception d’un message, sur un deuxième canal de communication du terminal (8) logiquement distinct du premier, le deuxième canal étant un service de message court de téléphonie mobile,
- identification automatique (104) d’un code de vérification de la transaction dans le message, dans laquelle, pour identifier (104) automatiquement le code de vérification dans le message, l’application mobile (6) identifie d’abord (103) automatiquement dans le message une chaîne de caractère prédéterminée, distincte du code de vérification, attestant que le message comprend un code de vérification,
- envoi (108), via le deuxième canal, d’une réponse à la requête comprenant le code identifié.
[Revendication 7] Procédé (100) selon la revendication précédente, dans lequel :
- l’application (6) demande également au préalable au système d’exploitation du terminal (8) la possibilité de supprimer les messages reçus par le service de message court,
- si un utilisateur du terminal (8) invalide la transaction via le premier canal, l’application (6) supprime (109) le message, reçu par le service de message court, comprenant le code de vérification de la transaction.
[Revendication 8] Programme d'ordinateur (6) pour terminal mobile comprenant des instructions qui, lorsque le programme est exécuté par un terminal mobile (8), conduisent celui-ci à mettre en œuvre les étapes des revendications 6 à 7.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
FRFR2106947 | 2021-06-28 | ||
FR2106947A FR3124624B1 (fr) | 2021-06-28 | 2021-06-28 | Procédé d’authentification de transaction utilisant deux canaux de communication |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2023274979A1 true WO2023274979A1 (fr) | 2023-01-05 |
Family
ID=78049307
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/EP2022/067612 WO2023274979A1 (fr) | 2021-06-28 | 2022-06-27 | Procédé d'authentification de transaction utilisant deux canaux de communication |
Country Status (2)
Country | Link |
---|---|
FR (1) | FR3124624B1 (fr) |
WO (1) | WO2023274979A1 (fr) |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20070037591A1 (en) * | 2005-08-12 | 2007-02-15 | Samsung Electronics Co.; Ltd | Method for automatically recognizing approval number for electronic commerce through SMS message in DMB terminal |
EP2405684A2 (fr) * | 2010-07-05 | 2012-01-11 | Lg Electronics Inc. | Terminal mobile et procédé de commande du fonctionnement du terminal mobile |
US20190385143A1 (en) * | 2018-06-19 | 2019-12-19 | McNabb Technologies, LLC a/k/a TouchCR | System and method for confirmation of credit transactions |
-
2021
- 2021-06-28 FR FR2106947A patent/FR3124624B1/fr active Active
-
2022
- 2022-06-27 WO PCT/EP2022/067612 patent/WO2023274979A1/fr unknown
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20070037591A1 (en) * | 2005-08-12 | 2007-02-15 | Samsung Electronics Co.; Ltd | Method for automatically recognizing approval number for electronic commerce through SMS message in DMB terminal |
EP2405684A2 (fr) * | 2010-07-05 | 2012-01-11 | Lg Electronics Inc. | Terminal mobile et procédé de commande du fonctionnement du terminal mobile |
US20190385143A1 (en) * | 2018-06-19 | 2019-12-19 | McNabb Technologies, LLC a/k/a TouchCR | System and method for confirmation of credit transactions |
Also Published As
Publication number | Publication date |
---|---|
FR3124624A1 (fr) | 2022-12-30 |
FR3124624B1 (fr) | 2023-09-01 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP3113099B1 (fr) | Conteneur de paiement, procédé de création, procédé de traitement, dispositifs et programmes correspondants | |
EP2619941B1 (fr) | Procede, serveur et systeme d'authentification d'une personne | |
WO2002065414A1 (fr) | Procede et systeme de telepaiement | |
EP3991381B1 (fr) | Procédé et système de génération de clés de chiffrement pour données de transaction ou de connexion | |
WO2016207715A1 (fr) | Gestion securisee de jetons électroniques dans un telephone mobile. | |
EP2813962B1 (fr) | Méthode de contrôle d'accès à un type de services spécifique et dispositif d'authentification pour le contrôle de l'accès à un tel type de services. | |
WO2023274979A1 (fr) | Procédé d'authentification de transaction utilisant deux canaux de communication | |
EP4074005A1 (fr) | Procede, serveur et systeme d'authentification de transaction utilisant deux canaux de communication | |
EP2824625B1 (fr) | Méthode de réalisation de transaction, terminal et programme d'ordinateur correspondant | |
WO2001073706A1 (fr) | Systeme de paiement permettant de ne pas divulguer d'information bancaire sur le reseau public et quasi-public | |
FR2922395A1 (fr) | Procede de transmission d'un code confidentiel, terminal lecteur de cartes, serveur de gestion et produits programme d'ordinateur correspondants | |
WO2024079144A1 (fr) | Procédé de gestion de données d'authentification permettant l'accès à un service d'un utilisateur depuis un terminal | |
FR3060171B1 (fr) | Procede de securisation de saisie de donnees, terminal de communication et programme correspondant. | |
WO2023001846A1 (fr) | Procédé de transaction entre un organisme et un établissement sur une chaîne de blocs | |
WO2022254002A1 (fr) | Procédé de traitement d'une transaction, dispositif et programme correspondant. | |
FR3115625A1 (fr) | Transactions sans présence de la carte avec une valeur de vérification de carte choisie par le titulaire de la carte | |
OA19018A (en) | Procédé de sélection d'au moins un service de paiement par porte-monnaie électronique proposé par un établissement financier. | |
FR2741219A1 (fr) | Procede de realisation de transfert securise de donnees sur un reseau a serveurs multiples | |
EP3223219A1 (fr) | Procédé de transfert de transaction, procédé de transaction et terminal mettant en oeuvre au moins l'un d'eux | |
FR2831361A1 (fr) | Jeton informatique | |
FR3021791A1 (fr) | Procede de delegation d'une mise en œuvre de transactions, dispositifs et programmes correspondants |
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: 22741189 Country of ref document: EP Kind code of ref document: A1 |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
32PN | Ep: public notification in the ep bulletin as address of the adressee cannot be established |
Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 31.05.2024) |