Method for managing a procedure for a back-up mode of a transaction, and associated device

DESCRIPTION

METHOD FOR MANAGING A PROCEDURE FOR A MODE OF COPYING

SECURITY OF A TRANSACTION AND ASSOCIATED DEVICE

Background of the invention

The present invention relates to the field of transactions executed by means of an electronic device and refers, more particularly, to a method for managing a procedure for a transaction backup mode, the method being activated in this case. of an attack or a failure of a transaction network.

As is well known, numerous banking transactions are carried out online via an electronic device through an electronic bank network.

The electronic banking network is a target for computer hackers with financial or political motives. In fact, a computer attack on an electronic banking network can have negative economic repercussions on a national scale. When the country is a developed country where most transactions are carried out electronically, such an attack can typically cripple the country's economy.

In addition to the financial cost, an attack or failure on computers in an electronic banking network has a negative impact on the experience of users of the banking network and on the reputation of a bank that uses the banking network.

There is, therefore, a need for a solution that makes it possible to improve the resilience of electronic banking networks by limiting the negative impact of a computer attack on users and the bank.

document US 2011/321173 describes a multimode retail system. EMV Integrated Circuit Card Specifications For Payment Systems Book 3 Application Specification Version 4.3 (XP055527907), published November 1, 2011, describes an integrated circuit board in the context of the EMV standard. Document US 2008/076425 describes a method for managing resources.

Purpose and summary of the invention

The present invention relates to a method for managing a backup procedure of a backup transaction mode that can be activated in case of a computer attack or a transaction network failure, implemented by a device. suitable for executing a transaction in normal mode or in backup mode, said method comprising the following steps:

• receiving an activation command to activate said backup mode procedure, comprising a procedure identifier and a first item of encrypted data, • verifying the activation command, comprising verifying said first item of encrypted data, • if the command verification is successful, activate the backup procedure.

Enabling a backup mode procedure, at which level the attack or failure procedure does not have an impact, makes it possible to improve the resilience of the transaction network. This activation makes it possible to limit the negative impact of a computer attack on users and the bank, as users can continue to perform operations through the backup procedure.

In a specific embodiment, the first encrypted data item is an authentication code calculated on the basis of a private key, said private key being obtained using the identifier of said procedure.

In a specific embodiment, the verification step comprises checking whether the value of the identifier of said procedure is greater than the value of a procedure identifier stored in the electronic device.

In a specific modality, the method comprises, after activating the backup procedure and after starting a transaction between the electronic device and a reader, a step of sending a message to said reader comprising a query request to consult a normal mode server of the transaction network.

In a specific embodiment, the method comprises, upon receiving a message indicating that the query from the normal mode server has failed, a step of sending a cryptogram to said reader, the cryptogram comprising at least one element of information about said procedure. from the following information elements:

• a start date for said procedure, • an end date for said procedure, • said identifier of said procedure, • an indication that said cryptogram is generated during the implementation of said procedure.

In a specific modality, said received message comprises a transaction date, the method comprising the following steps:

• check if the transaction date is between a procedure start date and a procedure end date, • if the transaction date is before the procedure start date or after the procedure end date, disable said procedure .

In a specific modality, the received message comprises the amount of the transaction, and the method comprises the following steps:

• increment a transaction number counter, • increment a transaction amount counter, • if the incremented transaction number counter is less than a transaction number limit value, and if the transaction amount counter is less than a limit value of the transaction amount, a transaction acceptance step.

In a specific embodiment, the method comprises a step of authenticating a user of the electronic device, the step of verifying the activation command is implemented if the authentication step is successful.

In a specific embodiment, the method comprises a step of deactivating said procedure by receiving a deactivation command to deactivate said procedure.

The invention further relates to an electronic device capable of implementing a method as described above.

In a specific embodiment, the different steps of the management method are determined by computer program instructions.

As a consequence, the invention also relates to a computer program on an information carrier (or recording medium), which program can be implemented by an electronic device or, more generally, on a computer. comprises proper instructions for implementing the steps of a management method as defined earlier in this document.

Such a program can use any programming language and be in the form of source code, object code or intermediate code between source code and object code, as in a particularly compiled form or in any other desired form.

The invention also relates to an information carrier (or recording medium) readable by an electronic device or, more generally, by a computer, and comprising computer program instructions, as mentioned earlier in this document.

Information carrier can be any entity or device capable of storing the program. For example, the medium can comprise a storage medium, such as a non-volatile rewritable memory (EEPROM or Flash NAND, for example), or as a ROM, for example, a CD ROM or a microelectronic circuit ROM, or even a ROM medium. magnetic recording, for example, a floppy disk or a hard disk.

Additionally, the information carrier can be a transmissible carrier, such as electrical or optical signals, which can be transmitted through an electrical or optical cable, by radio, or by other means. The program according to the invention can, in particular, be downloaded over a network of the Internet type.

Alternatively, the information carrier may be an integrated circuit in which the program is incorporated, which circuit is suitable for executing, or for being used in, the execution of the method in question.

Brief description of the drawings

Other features and advantages of the present invention will become apparent from the description given below, with reference to the accompanying drawings which illustrate a non-limiting embodiment. In the Figures:

- Figures 1 and 2 schematically show management systems according to exemplary embodiments of the invention;

- Figures 3 and 4 represent, in the form of a flowchart, the main stages of the stages of activation of management methods according to the exemplary embodiments of the invention;

Figure 5 shows, in the form of a flowchart, the main stages of a phase of payment of management methods according to exemplary embodiments of the invention;

Figure 6 shows, in the form of a flowchart, the main steps of a phase of deactivation of management methods according to exemplary embodiments of the invention;

Figure 7 schematically shows the data used during a cryptogram generation step of management methods according to exemplary embodiments of the invention.

Detailed description of various modalities

Figures 1 and 2 schematically show management systems 100 or 100' according to exemplary embodiments of the invention, capable of implementing management methods according to exemplary embodiments, for example, the method described with reference to Figures 2, 4 and 5 for system 100 of Figure 1, or the method described with reference to Figures 3, 4 and 5 for system 100' of Figure 2.

System 100, 100' comprises a first electronic device 110 having the conventional architecture of a computer. The first electronic device 110 comprises, in particular, a processor 112, a read-only memory 114 (ROM), a non-volatile rewritable memory 115 (EEPROM or Flash NAND, for example), a volatile rewritable memory 116 (RAM) and a communication interface 118.

In that example, read-only memory 114 constitutes an information (or recording) medium in accordance with a specific embodiment of the invention. A computer program PI is stored in read-only memory 114, enabling the first electronic device 110 to implement a management method in accordance with an exemplary embodiment of the invention, or at least part of that management method.

As a variant, computer program P1 is stored in non-volatile rewritable memory 115.

first electronic device 110 can perform a transaction according to a normal transaction mode or a backup transaction mode.

The expression transaction mode is used here to denote a set of rules applied during the execution of a transaction.

The normal transaction mode is the transaction mode used by the electronic device 110 under normal usage conditions. The set of rules applied when using normal mode is typically defined in a specification, for example, the EMV specification.

Backup transaction mode is a transaction mode used instead of normal transaction mode when normal transaction mode cannot be used, typically in the event of a computer attack or transaction network failure. The set of rules that can be applied when using backup mode is described below with reference to Figures 3 to 6.

To execute a transaction in normal mode or in backup mode, the first electronic device 110 may use an application to execute transactions, typically stored in the read-only memory 114 or in the non-volatile rewritable memory 115 of the first electronic device 110. Such an application is implemented, for example, by a transaction provider such as a bank, generally a bank that manages a bank account of the user of the first electronic device 110, which application can then be downloaded by the first electronic device 110 The application typically comprises the Pl program.

The application may comprise one or more data items associated with the backup mode from the following data items:

• an identifier of a backup mode procedure PMS, • a start date for that procedure PMS, • an end date for that procedure PMS, • a threshold value for various transactions that can be performed during said procedure PMS, • a limit value for a total transaction amount that can be debited during said procedure PMS, • a transaction number counter, • a transaction amount counter.

The application may further comprise a first key dedicated to the backup mode, a second key dedicated to the backup mode, and/or a backup mode indicator which may typically take the value 0 or 1.

As a variant, such data items are stored in read-only memory 114 or non-volatile rewritable memory 115 of the first electronic device 110, outside the application.

normal transaction mode and backup transaction mode are typically managed by separate servers from a transaction network 120, with the transaction network

120 it uses a telecommunications network 126 and is typically an electronic banking network.

An electronic banking network typically uses a private telecommunications network 126, used by at least one banking transaction provider, with each banking transaction provider being either a bank or a service provider (which provides interbank clearance, for example). Visa or MasterCard networks are examples of electronic banking networks.

The backup transaction mode is in particular managed by at least one backup mode server 122 of the transaction network, while the normal transaction mode is in particular managed by a normal mode server 124 of the transaction network.

A transaction is also executed by means of a reader 130 associated with another part of the transaction (in addition to the user of the first electronic device 110). Typically, reader 130 is a mobile phone, for example, a smart phone, a digital tablet, or a personal computer.

System 100 or 100' may thus further comprise backup mode server 122, normal mode server 124 and/or reader 130.

Backup mode server 122, normal mode server 124 and/or reader 130 may thus have the conventional architecture of a computer and may then each comprise, in particular, a processor, a read-only memory (ROM), a non-volatile rewritable memory (EEPROM or Flash NAND, for example), a volatile rewritable memory (RAM) and a communication interface.

Each read-only memory may constitute a recording medium in accordance with an exemplary embodiment of the invention, which is readable by the associated processor and on which a computer program in accordance with an exemplary embodiment of the invention is recorded. As a variant, the computer program is stored in associated non-volatile rewritable memory. 0 computer program can enable the implementation of at least part of the management method according to an exemplary embodiment of the invention.

As shown in Figure 1, the first electronic device 110 is, for example, a fixed or mobile terminal such as a mobile phone, for example a smart phone, a digital tablet or a personal computer.

The first electronic device 110 is therefore capable of communicating with the backup mode server 122 via a first telecommunications network 140, which first telecommunications network 140 is typically a long-range network such as a network. network, a WiFi network, or a fixed or mobile telephone network (3G, 4G etc.).

The first electronic device 110 and the reader 130 are further able to communicate with each other via the first telecommunications network 140 or a second telecommunications network 150. The second telecommunications network 150 is typically a short-range network such as a network. NFC (near field communication).

In addition, reader 130, normal mode server 124 and/or backup mode server 122 can communicate with each other via telecommunications network 126 used by transaction network 120, which telecommunications network 126 is called, from this point on in this document, the third telecommunications network 126.

As a variant, as shown in Figure 2, the first electronic device 110 may be an integrated circuit board (typically a bank board), for example, of ID-1 format as specified in the ISO/IEC 7810 standard, which has the dimensions 85.6mm by 53.98mm by 0.76mm.

The system 100' may then further comprise a second electronic device 160, said second electronic device 160 being a fixed or mobile terminal such as a mobile phone, for example a smart phone, a digital tablet or a personal computer.

The first electronic device 110 and the second electronic device 160 can communicate with each other via a fourth telecommunications network 170, which fourth telecommunications network 170 is typically a short-range network, such as an NEC network. The fourth telecommunications network 170 may be the same network as the second telecommunications network 150, or a separate network.

Additionally, the second electronic device 160 is capable of communicating with the backup mode server 122 via the first telecommunications network 140. The second electronic device 160 may comprise an application associated with the transaction provider.

first electronic device 110 and reader 130 are further able to communicate with each other via the first telecommunications network 140, the second telecommunications network 150, or directly via contacts when the first electronic device 110 is inserted into the reader 130.

Furthermore, the reader 130, the normal mode server 124 and/or the backup mode server 122 are capable of communicating with each other via the third telecommunications network 126.

Figures 3, 5 and 6 and Figures 4, 5 and 6 show methods for managing a procedure for a backup transaction mode in accordance with exemplary embodiments of the invention.

Figure 3 shows an activation phase of a management method according to an exemplary embodiment of the invention, and this activation phase makes it possible to activate a PMS backup procedure from the backup mode, typically in case of an attack per computer to the transaction network or a transaction network failure.

In the remainder of the description of Figure 3, it is considered that said activation phase is implemented by the management system 100 of Figure 1.

However, the method can be implemented by any management system that comprises a terminal capable of executing a transaction according to the normal transaction mode or the backup transaction mode.

In a step 310, a computer attack or a transaction network failure 120 is detected (typically at the normal mode server 124).

The backup mode server 122 may then, in a step E320, activate the backup mode procedure PMS at the backup mode server 122, typically after having requested activation authorization from one or more persons responsible for such activation.

Backup mode procedure is a procedure implemented for a predetermined period of time during which normal transaction mode cannot be used, due to failure or attack. Each procedure activated in step E320 is thus associated with a single failure or attack detected in step 310.

Backup mode server 122 can then determine a CA wake command to activate the backup mode procedure PMS (step E330). The CA activation command is typically a command similar to the script commands defined by the EMV standard, the activation command parameters are typically defined by the ISO 7816 standard. This CA activation command comprises a procedure PMS identifier and a first encrypted data item.

The procedure PMS identifier makes it possible to identify the backup mode procedure PMS from one or more other optional backup mode procedures (associated with other failures or attacks). In fact, a new backup mode procedure is activated after each detection of a new computer attack or a new transaction network failure, and therefore after each new step implementation.

310. Thus, the procedure PMS identifier is typically a number, incremented with each new implementation of step 310.

The first item of encrypted data is typically an authentication code calculated on the basis of a private key, said private key being obtained using the identifier of the procedure PMS.

For example, the authentication code is a message authentication code (MAC). The MAC code can be calculated using a session key derived from the first key dedicated to the backup mode, the procedural PMS identifier being used as a derivation value. The first key is typically a symmetric key used to calculate all the CA activation command data.

The CA activation command may additionally comprise one or more data items related to the PMS backup procedure, from the following data items:

• a start date for the procedure PMS, • an end date for the procedure PMS, • a cut-off value for various transactions that can be performed during that procedure PMS, • a cut-off value for a total amount of the transaction that can be debited during the mentioned procedure PMS.

CA activation command comprises, for example, a CLA field that defines the class of the instruction, an INS field that defines the instruction (this instruction being the PMS activation of the backup mode procedure PMS), the Pl and fields. P2 which define parameters of the instruction, an LC field which defines the length of the CA activation command, a DATA field which comprises the identifier of the backup procedure PMS and, optionally, one or more of the aforementioned data items relating to the PMS of the backup procedure, and a field MAC comprising the first encrypted data item.

backup mode server 122 can then send, in a step E340, a first message M1 comprising the CA activation command to the first electronic device 110 (typically for the application of the first electronic device 110) via the first telecommunication network 140.

The first message M1 may further comprise an information message intended for the user of the first electronic device 110, which typically indicates that the PMS of the backup mode procedure can be activated in the first electronic device 110.

Upon receiving the F340 of the first message M1, the first electronic device 110 can display the information message. The first electronic device 110 may also authenticate the user of the first electronic device 110 (step F350). User authentication is, for example, implemented by means of an authentication code or a user biometric data item.

In a step F360, the first electronic device 110 checks the received CA activation command, which step E360 is typically implemented if the user is authenticated. This F360 verification step comprises verifying the first encrypted data item.

Typically, the first electronic device 110 calculates a second encrypted data item, then compares that second encrypted data item with the first encrypted data item. If the second encrypted data item is identical to the first encrypted data item, the first encrypted data item is checked. Thus, the second item of encrypted data is typically an authentication code calculated based on a private key, said private key being obtained using the procedure PMS identifier, such as the MAC code, calculated using a session key derived from the first key dedicated to the backup mode, the procedure PMS identifier being used as a derivation value.

Additionally, the verification step F360 may comprise checking that the identifier value of said procedure PMS is greater than the procedure identifier value stored in the first electronic device 110, which corresponds, at this stage of the method, to the previous detection 310 of computer attack or transaction network failure.

The F360 verification step may also comprise verifying that the procedural PMS has not yet been activated.

More specifically, the first electronic device 110 checks that the backup mode indicator does not have the value 1. This check makes it possible to avoid a possible attack on the first electronic device 110. In fact, as described below, the activation of the procedure PMS may comprise resetting one or more data items associated with the backup mode, for example the total transaction amount. Checking the backup mode indicator makes it possible to prevent several successive malicious resets of this data.

If the verification of the AC enable command is successful, the first electronic device 110 activates the backup procedure PMS in the first electronic device 110 (step F370) .

Such activation step F370 may comprise initializing or resetting one or more data items stored by electronic device 110 and associated with the backup mode. For example:

• the procedure PMS start and end dates stored by the electronic device 110 can be updated based on the procedure PMS start and end dates received in step F340, • the transaction number counter and the amount counter of the transaction can be reset to zero, • the limit value of multiple transactions and the limit value of a total transaction amount that are stored by the electronic device 110 can be updated based on the limit value of multiple transactions and the limit value of a total transaction amount that are received in step F340, and/or • the backup mode procedure identifier stored by the electronic device can be updated based on the procedure identifier received in step F340, and/or • the backup mode indicator is set to the value 1 .

Figure 4 shows a variant of the activation phase implemented by the system 100' of Figure 2, or by any other management system comprising an integrated circuit card capable of executing a transaction according to the normal transaction mode or the transaction mode. backup transaction.

This activation phase variant differs from the activation phase described with reference to Figure 3 in that the backup mode server 122 sends, in step E440, the first message M1 to the second electronic device 160 (e.g., to the application of the second electronic device 160) via the first telecommunications network 140. Steps E320 and/or E330 described above with reference to Figure 3 can thus be implemented by the backup mode server 122 after step 310 and before step E440.

Upon receiving G440 of the first message M1, the second electronic device 160 can display the information message and/or authenticate the user of the first electronic device 110 (step G450), typically by means of an authentication code or a biometric data item of the user.

The second electronic device 160 may then issue a notification requesting the user to position the first electronic device 110 close to the second electronic device 160 so that they can communicate through the third telecommunications network 170.

The second electronic device 160 transmits the AC activation command in a step G455, through the fourth telecommunications network 170, to the first electronic device 110, which step G455 is typically implemented when the user is authenticated. The first electronic device 110 then implements steps F360 and F370, previously described with reference to Figure 3.

Figure 5 shows a payment phase of management methods according to exemplary embodiments of the invention. Said payment phase can be implemented by system 100 of Figure 1 or by system 100' of Figure 2, after the activation phase of the backup mode procedure PMS of Figure 3 or Figure 4.

In a step H510, reader 130 sends a first CT1 transaction command, which first CT1 command is typically a Generate CA command. The first CT1 transaction command is typically sent via the second telecommunications network 150.

Various other commands can be exchanged between the reader 130 and the first electronic device 110 before sending the first CT1 Generate CA command. The first CT1 command, Generate CA, makes it possible to execute the transaction and provide a result.

Step H510 is implemented when the user of the first electronic device 110 wants to execute a transaction with the user of the reader 130 and thus, after initializing a transaction, it is sent between the first electronic device 110 and the reader 130.

After F510 receipt of the first transaction command

CT1, the first electronic device 110 executes said first transaction command CT1 in a step F520.

With the backup mode procedure PMS activated, the first electronic device 110 sends, during the execution of the first transaction command CT1, a second message M2 comprising an inquiry request RQ from the normal transaction mode server 124. The second message M2 can be sent to the reader 130 via the second telecommunications network 150.

The reader 130 receives the second message M2 (step H520) then attempts to connect to the normal mode server 124 by sending the normal mode server 124 the RQ inquiry request of the message M2 (step H530) via the third telecommunication network 126 .

With the backup mode procedure PMS enabled, the normal mode server 124 does not respond to the RQ inquiry request, and the attempt of the reader 130 to connect to the normal mode server 124 fails.

The reader 130 then sends a third message M3 comprising a second transaction command and possibly comprising at least one transaction data item (step H540) to the first electronic device 110, typically via the second telecommunications network 150. The second command is typically a Generate CA command and indicates that the connection to the normal mode server 124 has failed.

On receiving the F540 of the third message M3, in a step F550, the first electronic device 110 executes the second command by performing at least one check linked to the transaction (step F550).

Each check is typically based on a transaction data item from the third message M3, the data item being, for example, a transaction date or a transaction amount.

For example, the first electronic device 110 checks whether the transaction date is between the start date of the procedure PMS and the end date of the procedure PMS, which dates are stored in the first electronic device 110.

If the transaction date is before the start date or after the end date of the procedure PMS, the first electronic device 110 disables said procedure PMS, typically setting the backup mode indicator to 0. transaction is subsequently processed in normal mode.

The first electronic device 110 may also increment the transaction number counter by one.

Then, the first electronic device 110 can check whether the incremented transaction number counter is less than the transaction number limit value.

If the incremented transaction number counter is greater than the transaction number limit value, the first electronic device 110 disables the backup mode procedure PMS, typically by adjusting the backup mode flag. security as 0, and the transaction is subsequently processed in normal mode.

first electronic device 110 may also increment the transaction amount counter by the transaction amount of the third message M3, then check whether the incremented transaction number counter is less than the transaction number threshold than the transaction amount counter is less than a transaction amount limit.

If the incremented transaction amount counter is greater than the transaction amount threshold, the first electronic device 110 disables the backup mode procedure PMS by typically adjusting the backup mode flag as 0, and the transaction is subsequently processed in normal mode.

If the verification(s) performed is(are) successful, the first electronic device 110 can accept the transaction.

Upon receipt of the third message M3, generally after performing the verification(s), the first electronic device 110 can generate a cryptogram CR in a step F560, said cryptogram CR being generated by means of the second key dedicated to the mode backup, said second key being typically symmetric.

The generated CR cryptogram comprises at least one information element about the backup mode procedure PMS from the following information elements about the backup mode procedure PMS:

• the start date for said procedure PMS, • the end date for said procedure PMS, the identifier of said procedure (PMS), • an indication by which said cryptogram (CR) is generated during the implementation of the referred to procedural PMS.

CR cryptogram is generated in the case where the transaction is accepted, but also in the case where the transaction is rejected.

Figure 7 represents an example of data items D1 to Dll used to generate the cryptogram. Data items D1 through D8 originating from reader 130, and data items D9 through Dll are data items of the first electronic device 110, as defined in document EMV 4.3, Book 2, 8.1.1.

Data item Dll, related to the application of the first electronic device 110, comprises 32 bytes, with bytes 18 to 32 being reserved for the transaction provider that implemented the application, as defined in document EMV 4.3, Book 3, C7.2. These bytes 18 to 32 comprise one or more information elements from the information elements about the procedural PMS, as described above.

In addition, bytes 4 to 8 of the CVR (Card Verification Results) field of data item Dll may comprise an information element about the cryptogram type, an information element according to which the transaction is rejected (data item AAC), an information element through which the transaction is accepted (data item TC), an indication that said cryptogram CR is generated during the implementation of said procedure PMS etc. Typically, the RFU value in the CVR Byte 1 field of the CVR field may comprise an information element by which the transaction is accepted in backup mode.

first electronic device 110 then sends a fourth message M4, which comprises the cryptogram CR and possibly further comprises an information element according to which the transaction occurred during the backup mode procedure PMS, to the reader 130, typically via the first network 140 or the second network 150 (step F570).

The reader 130 receives the fourth message M4 (step H570) and records the cryptogram CR (step H580). If the transaction is validated, the reader 130 transmits elements of information about the transaction after disabling the backup mode procedure PMS to the transaction network 120 (typically to the normal mode server 124), so that the server normally 124 can process the transaction after the transaction network 120 is again able to operate normally. The normal mode server 124 then checks the cryptogram CR.

As shown in Figure 6, after processing the failure or attack, when the transaction network 120 is again able to operate normally, the backup mode server 122, in a step E610, disables the copy mode procedure PMS of security.

Normal mode server 124 is then able to respond to query requests like the RQ query request sent by reader 130 in step H530.

Thus, upon receiving the 1630 of the RQ inquiry request sent in step H530, the normal mode server 124 sends, to the reader 130, a command for CDA deactivation of the backup mode procedure PMS, typically through the third telecommunications network 126 (step 1640), reader 130 transmits (step H640) said CDA disable command to the first electronic device 110, typically via the second telecommunications network 150 .

The first electronic device 110 receives the F640, the CDA disable command then executes it to disable the backup mode procedure PMS (step F650). The transaction is then subsequently processed in normal mode.

The CDA disable command is typically a script command similar to the script commands defined by the EMV standard.

As a variant, when the backup mode server 122 disables the backup mode procedure PMS, the backup mode server 122 sends the CDA disable command to the first electronic device 110, typically via of the first telecommunications network 140. The CDA deactivation command can be sent upon receipt of the RQ inquiry request or it can be sent after deactivation of the procedure PMS by the backup mode server 122, even if no transaction related to the first electronic device 110 is in progress.