Patent ID: 12229772

DETAILED DESCRIPTION

FIGS.1and2show two transaction systems performed via an open network, such as for example the Internet, using two-factor authentication. On these two figures, the same references correspond to the same elements or to similar elements. These two figures correspond to two-factor security transaction schemes as used in the prior art and according to the invention.

“Open network” means a communication network allowing interconnections between one or more computer machines accessible to any person wishing to do so. This type of network could be the Internet but could correspond to other types of network provided that the connection remains open to everyone. Open networks have the advantage of making it easier to connect people, thereby increasing the possibilities for commercial transactions between people connected to said network. A disadvantage of open networks is the risk of interacting with machines owned by malicious persons.

FIG.1corresponds to a bank transaction system allowing a user to perform transaction operations with their bank, such as for example to make a bank transfer or to purchase securities on line or any other type of operation for which the user transfers money from their bank account. On thisFIG.1, the user1interacts with a first terminal2connected to an open network3, such as for example the Internet, in order to communicate with a banking service server4to perform an operation corresponding to a bank transaction, in other words a money transfer from a bank account.

The first terminal2is for example a desktop computer or a laptop, 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 network3, a human-machine interface to view and enter information, such as for example a display screen, a touchscreen, a keyboard, a mouse or other. Amongst the programs stored in its memory, the first terminal has a program to navigate on the open network3, allowing it to connect to and interact with websites, in particular to consult web pages or to fill in and send forms corresponding to transaction requests. Alternatively, the first terminal2can have a specific program allowing it to connect via the open network3to the banking service server4.

The banking service server4is for example a computer having one or more processing units, at least one volatile and mass storage memory, and at least one communication interface allowing it to connect to the open network3. The mass storage memory stores in particular a database containing all the information relating to the bank accounts of the customers of the bank to which they belong. The banking service server4comprises programs stored in memory allowing it to provide to connected terminals, via the open network3, searchable web pages in order to interact with users via forms contained in said web pages. Once filled in and returned by the user, the forms are processed by the processing unit for validation.

When a user1wants to make transaction, they use the first terminal2to connect to the banking service server4. A web page is then transmitted to the first terminal2by the banking service server4. The web page may comprise information to be displayed on the first terminal2, as well as commands to be executed depending on the choice made by the user via the human-machine interface. Amongst the choices offered to the user1, a transaction, for example a bank transfer, can be made. If the user1chooses to make bank transfer, a transaction form is displayed, which can be included in the web page or transmitted by the banking service server4after receiving a message indicating the choice of the user1from the first terminal2. The user1then fills in the form with the information required for the transaction, which may include the identification of the bank account to be credited, the identification of the bank account to be debited and the transaction amount. Numerous other items of information may also be required, such as redundant identifiers of the user and/or of the bank account or of its holder, a secret known only to the bank and the holder, a transaction identifier or any other information related to the transaction. After filling in the form, the user1sends the filled in form to the banking service server4via the first terminal2. The form may be accompanied by the transmission date and time as well as identifiers specific to the first terminal2.

After receiving the filled in transaction form, the banking service server4checks the information contained in the form and in particular whether or not the requested transaction can be authorised. The banking service server4therefore queries its database to check whether the account to be debited is still in service and whether the account to be debited has sufficient credit to authorise the transaction. Optionally, the server can check the accuracy of redundant identifiers or of information concerning the bank account holder. This first verification corresponds to a first security factor. However, the transaction was transmitted by the open network3and, despite this first verification, this transaction could come from a misappropriation of the form and/or information concerning the bank account by a malicious third party.

Communications on the open network3may in fact be intercepted and possibly reused after being modified. To guarantee a minimum level of security, it is known to encrypt the sensitive messages between two machines, such as for example the terminal2and the banking service server4, using session keys or specific keys. However, any encrypted message can be decrypted after a certain period of time, making it possible to retrieve a form that has been exchanged and reuse the information it contains. In addition, the fact that the network is open allows malicious persons to spread viruses on the machines connected to it and in particular the first terminal2. Some viruses can intercept the information exchanged on the human-machine interfaces and send it to another machine, thereby disabling the confidentiality of encrypted messages.

To add a security level, a second security factor can be added by using a second communication channel to send a one-time code. The banking service server4therefore has a second communication interface designed to communicate via the second communication channel with a second terminal5which belongs to a bank account holder. The second terminal5is identified in the database of the banking service server4in relation with the bank account to be debited. Traditionally, the second terminal5may be a mobile phone of the bank account holder, but may also be any other type of device connected to a communication network, such as for example a box connected to a mobile phone network supplied by the bank or even a tablet or a computer connected to the Internet. The most important is that the second communication channel should be at least logically distinct from the first communication channel used to send the transaction form.

After having made the first verification, the banking service server4retrieves, from its database, the identifier of the second terminal5to send it a one-time verification code. The identifier of the second terminal5is, for example, a mobile phone number and the message is, for example, sent by an SMS (Short Message Service). The message can also indicate the transaction amount and/or the transaction beneficiary, so that the account holder can check that the current transaction corresponds to a required transaction.

In parallel, the banking service server4sends to the first terminal2a confirmation request requesting the one-time code. If the user1corresponds to the bank account holder, they can read the one-time code on the second terminal5and copy it into a response form attached to the confirmation request in order to return it to the banking service server4.

After receiving the response form, the banking service server4compares the code present in the form with the one-time code sent to the second terminal5. If the two codes are identical, the banking service server4validates the transaction and sends a message to the first terminal2indicating that the transaction has been accepted. If the two codes are different, the transaction is refused and the banking service server4sends a message to the first terminal indicating that the transaction has been refused. Optionally, the banking service server4can send another new one-time verification code to the second terminal5and a new request to the first terminal2.

FIG.2corresponds to a commercial transaction system allowing a user1to make a purchase on a merchant site6. The merchant site6is a server-type computer which is connected to the open network3in order to provide web pages proposing products and/or services to users connecting to it using a suitable terminal. The user1connects to the merchant site6using the first terminal2via the open network3. Once the user1has chosen products or services, the merchant site6sends a transaction form to the first terminal2. The transaction form is pre-filled in by the merchant site6with the vendor's identification and bank account as well as the transaction amount. The transaction form is displayed to the user1by the first terminal2, prompting the user to enter a bank account or bank card identification. Other information may also be required, such as for example the bank card supplier, the Cardholder Verification Value (CVV) code which is a redundant identifier of the card, the bank card holder identification or any other redundant information relating to the card or its holder. After filling in the form, the user1sends it to the merchant site6via the first terminal2. The form may be accompanied by the transmission date and time as well as identifiers specific to the first terminal2, such that for example its address on the open network3.

The merchant site6receives the form and sends it to a purchaser service server7which corresponds to its bank. The purchaser service server7is a computer having one or more processing units, at least one volatile and mass storage memory, at least one communication interface allowing it to connect to the merchant site6and at least one communication interface to connect to a secure network dedicated to the banking services. The communication interface communicating with the merchant site6can correspond to a specific secure link or to an open network implementing encrypted communication.

The purchaser service server7then sends the transaction form, via the secure network, to a debtor service server4′ which corresponds to the bank card issuer. The debtor service server4′ is similar to the banking service server4. The debtor service server4′ can be the cardholder's bank server or the server of a credit card issuer.

After receiving the transaction form, the debtor service server4′ checks the information contained in the form and in particular whether or not the requested transaction can be authorised. The debtor service server4′ therefore queries its database to check whether the bank account or the bank card is still in service, whether any redundant information matches the card or the bank account and whether the transaction amount corresponds to an authorised amount. After this first security level verification, the debtor service server4′ performs a verification according to a second security level similar to that described in relation toFIG.1with some differences.

The debtor service server4′ identifies in its database the second terminal5in relation to the bank card or the bank account to be debited and a second communication channel distinct, at least logically, from the communication channel communicating with the first terminal2. The debtor service server4′ sends a message with a one-time verification code to the second terminal5. The message can also indicate the transaction amount and/or the transaction beneficiary, so that the account holder can check that the current transaction corresponds to a required transaction.

In parallel, the debtor service server4sends to the first terminal2a confirmation request requesting the one-time code. This request can be sent to the first terminal2via the purchaser service server7and the merchant site6via the open network3or directly by the debtor service server4′ via the open network3. If the user1corresponds to the bank card or bank account holder, they can read the one-time code on the second terminal5and copy it into a response form attached to the confirmation request in order to return it to the debtor service server4′ using the same communication channel.

After receiving the response form, the debtor service server4′ compares the code present in the form with the one-time code sent to the second terminal5. If the two codes are identical, the banking service server4validates the transaction and sends a message to the purchaser service server7which stores the transaction and sends a validated payment message to the merchant site6. The merchant site6then informs the first terminal2that the payment has been accepted and delivers the service or initiates a product delivery procedure which will not be detailed in this document. If the two codes are different, the transaction is refused and the debtor service server4′ sends a message to the purchaser service server7which is forwarded to the merchant site6, then to the first terminal2indicating that the transaction has been refused and therefore not performed. Optionally, the debtor service server4′ can send another new one-time verification code to the second terminal5and a new request to the first terminal2via one of the paths indicated previously.

The invention aims to improve transaction verifications using two security factors as indicated previously and in particular using a second communication channel to communicate with the bank account or bank card holder.FIGS.3and4therefore illustrate steps of the transaction methods performed according to the invention respectively on the transaction systems described in relation withFIGS.1and2. The flowchart ofFIG.5details the steps of the transaction verification method performed according to the invention by the banking service server4or the debtor service server4′ during the exchanges made in accordance withFIG.3orFIG.4. The common steps betweenFIGS.3,4and5have the same references andFIG.5is described at the same time asFIGS.3and4. In order to emphasise the invention, the steps performed before the user1chooses a transaction are not detailed onFIGS.3and4which start after a transaction decision, corresponding to making a payment, has been validated by the user1of the first terminal2.

OnFIG.3, once the user1has chosen the transaction, the banking service server4sends to the first terminal2a transaction form corresponding to the choice of the user1in a first step301of the transaction method. In a second step302of the transaction method, the user1reads the form received by the first terminal2, for example using a display screen of the first terminal2. The user fills in the form with the information requested during a third step303of the transaction method, for example using a keyboard of the first terminal2. After filling in the form, the user validates the form to send it.

A fourth step304of the transaction method corresponds to the first terminal2sending the form to the banking service server4via the open network3. This fourth step304of the transaction method corresponds to a first verification step501of the banking service server4. The banking service server4receives an incoming message R1arriving via the first communication channel. The incoming message R1contains information concerning a bank account identification ID and a transaction amount TA. The identification information ID includes at least the bank account number, but may include redundant information such as for example one or more elements selected from a password, a PIN code, one or more items of information concerning the identity of the bank account holder. The identification information ID may also include parameters specific to the transaction, such as for example the date and time or the location of the first terminal2, as well as an identifier of said first terminal2.

In a second verification step502, the banking service server4checks that the bank account exists and that it is not blocked. Optionally, other verifications can be performed to make sure that any redundant information matches that corresponding to the bank account. In addition, the banking service server4may also check that the amount to be debited matches an authorised debit from the bank account.

After performing this preliminary bank account verification, the banking service server4then calculates a verification code length L in a third verification step503where the length L corresponds to a number of digits of said code. Preferably, the length L is determined according to the transaction amount TA, so that the verification code takes into account the transaction amount as a risk factor. As a simple example, the following formula can be used:
L=A*TA+B[Math 1]

The parameters A and B can be set arbitrarily by the bank according to a risk acceptance. If A=0.1 and B=2 with the result L rounded to the nearest integer, a payment of one euro will result in a code L of two digits very easy to copy for a sum representing a minimum risk. Using the same parameters, a payment of ten euros corresponds to a three-digit code and a payment of one hundred euros corresponds to a twelve-digit code.

Preferably, identification information ID can be taken into account when determining the number of digits. For example, the parameters A and B can be stored in the database of the bank service server4and accessed using the account number identification. Thus, the parameters A and B can be defined according to a risk accepted by the user or by their account manager, B corresponding to a minimum number of digits and A being determined according to an amount for which a financial risk seems acceptable. To avoid having codes that are too long, it is also possible to set a maximum number of digits.

As a variant, it is also possible to have a non-linear growth in the number of digits to avoid having to limit the number of digits. For example, the following formula can also be used:
L=A*log10(TA)+B[Math 2]

A logarithmic function can be used to obtain a growth of length L of the verification code that is proportional to the number of digits of the transaction amount. For example, if A=0.3 and B=3, an amount of less than ten euros produces a three-digit verification code, an amount of one hundred euros corresponds to a six-digit code and an amount of one thousand euros corresponds to a nine-digit code.

After determining the verification code length L, the banking service server4calculates a verification code AC during a fourth verification step504. The verification code AC can be generated in different ways, preferably using a random or pseudo-random number generated by the processing unit of the banking service server4. As a simple example, the following formula can be used to determine the verification code:
AC=Seed modL[Math 3]

where Seed corresponds to a random or pseudo-random number generated by the processing unit of the banking service server4, mod to the modulo function and L to the code length calculated during the third verification step503. Numerous variants are possible by including the transaction amount TA and one or more items of transaction identification information ID, such as for example the transaction date or time. For example, the following formula can also be used:
AC=H(Seed,TA,ID)modL[Math 4]

where H corresponds to a cryptographic hash function, for example a SHA-3 performed on the concatenation of the random number Seed, the transaction amount TA and one or more items of identification information ID.

After calculating the verification code AC, a fifth verification step505is performed by the banking service server4. The fifth verification step505consists in sending an outgoing message S1, via the first communication channel, to the first terminal2, the outgoing message containing a request Req asking the user1of the first terminal2to return a verification code in a response form.

In parallel with the fifth verification step505, in other words before or after this fifth step505, the banking service server4performs a sixth verification step506. The sixth verification step506consists in sending an outgoing message S2via the second communication channel to the second terminal5. Prior to sending, the second terminal5is identified in the database of the banking service server4in relation with the bank account to be debited. The outgoing message S2contains the verification code AC calculated during the fourth verification step.

The fifth verification step505corresponds to a fifth step305of the transaction method and the sixth verification step506corresponds to a sixth step306of the transaction method.

Once the request Req has been received by the first terminal2, it is displayed to the user1during a seventh step307of the transaction method, and the user1must fill in the response form. In parallel with the seventh step307, in other words before or after this seventh step307, an eighth step308of the transaction method consists in displaying the verification code AC on the second terminal5to the user1.

The user1, having the verification code AC, fills in the response form by copying the verification code AC into the form during a ninth step309of the transaction method. The copied verification code AC′ is sent to the banking service server4in a tenth step310of the transaction method. The tenth step310of the transaction method corresponds to a seventh verification step507performed by the banking service server4. The banking service server4receives an incoming message R1arriving via the first communication channel containing the copied code AC′. An eighth verification step508then consists in comparing the copied code AC′ with the verification code AC calculated during the fourth verification step504.

If the copied verification code AC′ is identical to the verification code AC, the banking service server4performs a ninth verification step509during which it validates and saves the execution of the transaction. Then, a tenth verification step510is performed to send an outgoing message S1via the first communication channel to the first terminal2to indicate that the transaction has been performed.

If the copied verification code AC′ is not identical to the verification code AC, the banking service server4performs an eleventh step511during which it cancels the transaction. If, during the second verification step502, the banking service server4has not found the bank account or has found the bank account but it is blocked, or if other verifications have shown that some redundant information does not match that corresponding to the bank account, the second verification step502can lead directly to the eleventh verification step511and also cancel the transaction. After the eleventh verification step511, a twelfth verification step512is performed to send an outgoing message S1via the first communication channel to the first terminal2to indicate that the transaction has been cancelled.

The tenth verification step510or the twelfth verification step512corresponds to an eleventh step311of the transaction method in which the first terminal2receives the outgoing message S1to display it to the user1during a twelfth step312of the transaction method. Thus, the user1is informed that the requested transaction has been performed or cancelled.

FIG.4discloses a transaction method performed from the merchant site6. Once the user has chosen to make a purchase, the merchant site6sends to the first terminal2a transaction form in a first step401of the transaction method. In a second step402of the transaction method, the user1reads the form received by the first terminal2. The user1fills in the form with the information requested during a third step403of the transaction method. The form contains information concerning a bank card or bank account identification ID and a transaction amount TA. The identification information ID includes at least the bank card or bank account number, but may include redundant information such as for example one or more elements selected from a password, a PIN code, a CVV code, one or more items of information concerning the identity of the account holder. The identification information ID may also include parameters specific to the transaction, such as for example the date, time or location of the first terminal2, or an identifier of said first terminal2. After filling in the form, the user1validates the form to send it.

A fourth step404of the transaction method corresponds to the first terminal2sending the form to the merchant site6via the open network3. The merchant site6then forwards the form to the purchaser service server7during a fifth step405of the transaction method. Using the bank card or bank account identification information ID, the purchaser service server7determines a corresponding debtor service server4′, to forward the form to it during a sixth step406of the transaction method.

This sixth step406of the transaction method corresponds to the first verification step501, performed by the debtor service server4′, corresponding to the reception of the incoming message R1arriving from the first communication channel. The debtor service server4′ then performs the second verification step502, to check that the bank account or the bank card exists and that it is not blocked. Optionally, other verifications can be performed to make sure that any redundant information matches that corresponding to the bank account or the bank card. In addition, the debtor service server4′ may also check that the amount to be debited matches an authorised debit from the bank account or bank card.

The debtor service server4′ performs the third verification step503and calculates a length L of verification code AC corresponding to a number of digits of said code. The length L is determined according to the transaction amount TA, so that the verification code AC takes into account the transaction amount as a risk factor, as described previously.

In addition, since the transaction is performed on a merchant site and not on a bank server, the risk is greater. The length L of the verification code may also include other risk factors such as a transaction time and/or a number of transactions recently performed. For example, including such risk factors may result in the following formula:
L=A*log2(Nb)*R(T)*log10(TA)+B[Math 5]

where Nb represents the number of transactions performed during the last twenty-four hours with the same account number or the same bank card, T represents the transaction time and R (T) is a risk coefficient depending on the time T, the coefficient R (T) is for example read in a mapping table produced from statistics on the times when fraudulent transactions are made.

The debtor service server4′ then calculates the verification code AC during the fourth verification step504as described previously. The fifth and sixth verification steps505and506are then performed in parallel. The fifth verification step505consists in sending an outgoing message S1, via the first communication channel, to the first terminal2, the outgoing message containing a request Req asking the user1of the first terminal2to return a verification code in a response form. The sixth verification step506consists in sending an outgoing message S2via the second communication channel, to the second terminal5, the second terminal5having been previously identified using the database of the debtor service server4′ in relation with the bank account or bank card to be debited. The outgoing message S2contains the verification code AC calculated during the fourth verification step504.

The fifth verification step505corresponds to a seventh step407of the transaction method. During the seventh step407, the debtor service server4′ transfers an outgoing message containing the request S1(Req) to the purchaser service server7. The purchaser service server7transfers this message to the merchant site6during an eighth step408of the transaction method. The merchant site6then forwards the request to the first terminal2in a ninth step409of the transaction method.

The sixth verification step506corresponds to a tenth step410of the transaction method during which the second terminal5receives the verification code AC.

Once the request Req has been received by the first terminal2, it is displayed to the user1during an eleventh step411of the transaction method, and the user1must fill in the response form. In parallel with the eleventh step411, a twelfth step412of the transaction method consists in displaying the verification code AC on the second terminal5to the user1.

The user1, having the verification code AC, fills in the response form by copying the verification code AC into the response form during a thirteenth step413of the transaction method. The copied verification code AC′ is sent to the merchant site6in a fourteenth step414of the transaction method. During a fifteenth step415of the transaction method, the merchant site6forwards the response form to the purchaser service server7. In a sixteenth step416of the transaction method, the purchaser service server7sends the filled in form to the debtor service server4′.

The sixteenth step416of the transaction method corresponds to the seventh verification step507performed by the debtor service server4′. The debtor service server4′ receives an incoming message R1arriving via the first channel containing the copied code AC′. During an eighth verification step508, the debtor service server4′ compares the copied code AC′ with the verification code AC calculated during the fourth verification step504.

If the copied verification code AC′ is identical to the verification code AC, the debtor service server4′ performs the ninth step509during which it validates and saves the execution of the transaction. Then, the tenth verification step510is performed to send an outgoing message S1via the first communication channel to the first terminal2to indicate that the transaction has been performed.

If the copied verification code AC′ is not identical to the verification code AC, the debtor service server4′ performs the eleventh step511during which it cancels the transaction. If, during the second verification step502, the debtor service server4′ has found that the bank account or the bank card is blocked, or if other verifications have shown that some redundant information does not match that corresponding to the bank account or the bank card, the second verification step502can lead directly to the eleventh verification step511and also cancel the transaction. After the eleventh verification step511, a twelfth verification step512is performed to send an outgoing message S1via the first communication channel to the first terminal2to indicate that the transaction has been cancelled.

The tenth verification step510or the twelfth verification step512corresponds to a seventeenth step417of the transaction method in which the purchaser service server7receives the outgoing message S1. The purchaser service server7saves the execution or cancellation of the transaction and sends the outgoing message to the merchant site6during an eighteenth step418of the transaction method. The merchant site6finds that the transaction has been validated or cancelled. If the transaction is validated, the merchant site6delivers the service or triggers the delivery of the purchased product. During a nineteenth step419, the merchant site6sends a message confirming or cancelling the transaction to the first terminal2. The first terminal2displays the confirmation message to the user1during a twentieth step420of the transaction method. Thus, the user1is informed that the purchase has been executed or cancelled.

Numerous alternative embodiments are possible while remaining within the scope of the verification method according to the invention. For example, the seventh to ninth steps407to409of the transaction method described in relation toFIG.4can be replaced by a first alternative step421which sends the confirmation code request from the debtor service server4′ directly to the first terminal2via the open network3. Also, a second alternative step422can replace the fourteenth to sixteenth steps414to416of the transaction method to send the copied verification code AC′ from the first terminal2directly to the debtor service server4′.

In this document, the first terminal2is a computer connected to the Internet and the second terminal5is a mobile phone. As indicated previously in the description, the first and second terminals2and5can be any type of connected device which can exchange data with a remote server. According to a variant, the first and second terminals2and5can be one and the same physical terminal. The most important is that the first and second communication channels should be at least logically distinct from each other so that malicious interception of the first channel does not automatically lead to malicious interception of the second channel.

For example, the first and second terminals can be one and the same personal computer with a first communication channel comprising Internet browsing software and a second communication channel comprising messaging software, the second communication channel being identified using an email address. In this example, the first and second communication channels are logically distinct from each other, although the physical connection of the terminals uses the same communication interface, in other words the same network connection board. However, the verification code sent by the second channel cannot be accessed directly by the navigation software and the user must use a human-machine interface of the personal computer to display and copy said code. Thus, only software that intercepts actions performed on the human-machine interface can intercept the verification code. However, this type of interception can also occur when the two communication channels are physically distinct and consequently the logical differentiation forms the same security level as a physical differentiation of the communication channels.

FIGS.2and4describe a debtor service server4′ and a purchaser service server7. Typically, an electronic transaction is performed between two bank accounts belonging to two different holders who have two different banks, each with its own server. However, the vendor and the purchaser could each have a bank account in the same bank. In this case, the debtor4′ and purchaser7service servers are the same server, which reduces the number of exchanges.

Inversely, one or more intermediate service providers can also be inserted between the debtor4′ and purchaser7service servers. This is particularly the case when credit cards are used. The link is not made directly from bank to bank, but goes through a card provider which can replace the cardholder's bank or simply act as an intermediary during an online transaction.

Similarly, the banking4, debtor4′ and purchaser7service servers can be distributed servers. In view of the volume of banking data and the number of transaction requests, several independent computers connected to a network can perform the role of each of the banking4, debtor4′ and purchaser7service servers. Each computer forming one of the servers can perform all or some of the transaction operations, the various transaction operations being performed on different computers.