WO2018011514A1

WO2018011514A1 - Method for controlling an electronic device for processing a transaction

Info

Publication number: WO2018011514A1
Application number: PCT/FR2017/051897
Authority: WO
Inventors: Marco DE OLIVEIRA; Bruno Climen
Original assignee: Oberthur Technologies
Priority date: 2016-07-11
Filing date: 2017-07-11
Publication date: 2018-01-18
Also published as: FR3053814A1; FR3053814B1

Abstract

The invention relates to a method for controlling an electronic device (T1), said method comprising the following steps during transaction processing with the aid of a terminal (T2): receiving, from the terminal (T2), an identifier of said terminal; consulting a list (LT) of terminal identifiers in order to determine whether the identifier that was received is featured on said list (LT); and processing the transaction depending on the result of this consultation.

Description

Method of controlling an electronic device for processing a transaction

Background of the Invention

The present invention is in the general field of electronic devices and more particularly relates to an electronic device, such as a smart card or a mobile terminal for example, configured to cooperate with an external terminal to perform a transaction, in the banking field for example.

The invention applies more particularly, but not exclusively, to smart cards (or microcircuit cards), conforming for example to the IS07816 standard. The invention also applies to terminals, in particular mobile terminals such as mobile phones for example, configured to cooperate with an external terminal (or reader) to process a transaction.

The invention aims in particular to secure such an electronic device in the processing of a transaction according to the EMV protocol (for "Europay Mastercard Visa").

In general, a smart card is designed to communicate with a device external to this card, otherwise called terminal or reader. These cards make it possible to carry out various types of transactions, such as, for example, payment, debit or carrier authentication transactions. Smart cards for banking applications (credit card, debit card etc.), for example, are able to cooperate with payment terminals or ATMs to carry out various financial transactions.

Alternative solutions to the smart card have also been developed such as software solutions implemented on terminals to allow a user to perform a transaction with an external terminal. A mobile solution is for example to install an application on a mobile terminal (a mobile phone for example) to process a transaction similarly to a smart card.

EMV is the standardized protocol used today mainly in the world to secure particular payment transactions made by smart cards or mobile solutions.

The EMV protocol has been designed to reduce the risks of fraud during a payment transaction by allowing the authentication of both the card and the card. chip and its carrier. This authentication process uses a combination of cryptograms (or encrypted keys) and digital signatures and possibly requires the entry of a secret code (commonly called PIN) by the cardholder.

Depending on the type of card used, the situation, or the amount considered, an EMV card can work online or offline. In online mode, the EMV card can communicate, via the reader, with the corresponding issuing entity (the bank at the origin of the card, for example) to verify in particular that the current transaction is legitimate. On the other hand, if the EMV card is operating in offline mode, it applies prerecorded verification criteria to decide whether the transaction should be allowed or denied.

Many security mechanisms have recently been developed to secure as much as possible the increasing use of smart cards, EMV type in particular.

However, some payment terminals may have implementation weaknesses (non-random unpredictable number, unsupported signature, etc.) that may be misused by a third party or malicious entity to carry out a fraudulent transaction. These terminals are however functional and therefore constitute a high security risk for a smart card, or more generally for an electronic device for processing a transaction as indicated above.

These sensitive terminals in the sense of security, are generally known banks. However, there is currently no satisfactory solution to secure transactions between an electronic device, such as a smart card or a mobile terminal for example, and a sensitive terminal as described above.

In particular, a need exists to secure the processing of an off-line transaction between an electronic device and a risk terminal, since the bank is not able to make specific checks to ensure the validity of the transaction. the transaction. Object and Summary of the Invention / Summary

For this purpose, the present invention relates to a method for controlling an electronic device, said method comprising, during a transaction being processed in cooperation with a terminal, the following steps: receiving, from the terminal, an identifier of said terminal;

consulting a first list of at least one terminal identifier to determine if the identifier of said terminal is included in said first list; and

- processing of the transaction according to the result of said consultation.

The invention advantageously allows an electronic device to determine if the terminal with which it cooperates during a transaction presents a particular security risk and, if so, to adapt the transaction processing accordingly to, for example, to further secure the transaction.

According to a particular embodiment, the method comprises, prior to said consultation step, the recording of the first list of at least one terminal identifier in a memory of the electronic device. The electronic device thus has a list enabling it to identify the risk terminal or terminals with which it is likely to cooperate during a transaction.

According to a particular embodiment, said method comprises, prior to said consultation step:

- sending, to a remote server, data allowing the remote server to determine the location of the electronic device; and

receiving, in response to said sending, the first list of at least one terminal identifier, said first list being a function of said location of the electronic device.

The invention thus advantageously enables the electronic device to receive a list of terminals presenting a particular security risk, this list being adapted to the location of said electronic device. Advantageously, it is thus possible to send to the electronic device a list of limited size adapted to the geographical area in which the electronic device is located, which allows a gain in terms of memory space and resources used at the level of the device. electronic device. In addition, the invention makes it possible to ensure that the electronic device is capable of determining whether the terminals likely to be located in the vicinity present a particular risk or not.

According to a particular embodiment, said datum is a location datum representative of the location of the electronic device.

According to a particular embodiment, the method comprises, prior to its sending, the determination of said location data from at least one of: GPS coordinates representative of the geographical location of the electronic device; and

- Network data representative of the location of the electronic device in a communication network.

According to a particular embodiment, if it is determined during said consultation that the identifier of said terminal is included in the list of at least one terminal identifier, the step of processing the transaction includes triggering the less a predefined transaction securing operation.

According to a particular embodiment, wherein said at least one predefined security operation comprises at least one of:

- sending a request for online processing of the current transaction;

recording, in a log file, of a predefined logging datum; and

- Configuration of at least one operating parameter of the electronic device.

According to a particular embodiment, the current transaction is EMV type. The identifier of the terminal is for example received in an EMV transaction message GAC type.

According to a particular embodiment, the method comprises the following steps:

receiving, during the current transaction, a command specifying a second list of at least one terminal identifier; and

in response to said command, recording said second list in a memory of the electronic device in replacement of said first list. The invention thus advantageously makes it possible to update the list held by the electronic device.

In a particular embodiment, the various steps of the control method are determined by computer program instructions.

Accordingly, the invention also relates to a computer program on an information carrier, this program being capable of being implemented in an electronic device such as a mobile terminal, or more generally in a computer, this program with instructions adapted to the implementation of the steps of a control method as defined above. The invention also relates to a recording medium (or information carrier) readable by a computer, and including instructions of a computer program as mentioned above.

The invention also relates to a sending method implemented by a server, comprising the following steps:

- Receiving data from an electronic device configured to cooperate with a terminal to implement a transaction;

determining the location of the electronic device from said datum;

selecting, from the location of the electronic device, a list of at least one terminal identifier; and

sending said list to the electronic device so as to configure the processing, by the electronic device, of a transaction.

According to a particular embodiment, the received data is one of:

a location data representative of the location of the electronic device; and

an identifier of a terminal with which the electronic device cooperates to process a transaction in progress.

According to a particular embodiment, the server sends the list of at least one terminal identifier to the electronic device in an EMV transaction message.

In a particular embodiment, the various steps of the sending method are determined by instructions of computer programs.

Consequently, the invention also relates to a computer program on an information medium, this program being capable of being implemented in a server, or more generally in a computer, this program comprising instructions adapted to the setting implementation of the steps of a sending method as defined above.

The invention also relates to a recording medium (or information carrier) readable by a computer, and including instructions of a computer program as mentioned above.

The invention also relates to an electronic device comprising, during a transaction in progress with a terminal, the following steps:

a reception module configured to receive, during a transaction in progress with a terminal, an identifier of said terminal; a determination module configured to consult a first list of at least one terminal identifier to determine whether the identifier of said terminal is included in said first list; and

- A processing module configured to process the transaction based on the result of the consultation of the first list by the consultation module.

The electronic device is for example a mobile terminal such as an intelligent mobile phone configured to cooperate with an external terminal to perform a transaction (eg EMV type). The electronic device can also be a smart card, of the EMV type for example.

The invention further relates to a server comprising:

- A receiving module configured to receive data from an electronic device, said device being configured to cooperate with a terminal to implement a transaction;

a determination module configured to determine the location of the electronic device from said datum;

a selection module configured to select, from the location of the electronic device, a list of at least one terminal identifier; and

a sending module configured to send said list to the electronic device so as to configure the processing, by the electronic device, of a transaction.

Note that the various embodiments defined above in relation to the control method, on the one hand, and with the sending method, on the other hand, as well as the advantages associated with these methods, apply. by analogy with the electronic device and the server defined above.

Brief description of the drawings

Other features and advantages of the present invention will emerge from the description given below, with reference to the accompanying drawings which illustrate embodiments having no limiting character. In the figures:

- Figure 1 shows schematically a mobile terminal adapted to cooperate with a remote server SV1 and with an external terminal T2, according to a particular embodiment of the invention; FIG. 2 schematically represents modules implemented in the mobile terminal T1 and in the remote server SV1 shown in FIG. 1, according to one particular embodiment of the invention;

FIG. 3 diagrammatically shows control methods implemented respectively by the mobile terminal T1 and by the remote server SV1 represented in FIGS. 1 and 2, according to one particular embodiment of the invention;

FIG. 4a schematically represents an example of a table TB containing LT lists of at least one terminal identifier, in association with a geographical area;

FIG. 4b schematically represents an example of a list LT2 contained in the table TB represented in FIG. 4a;

FIG. 5 represents, in the form of a diagram, the main steps of control methods implemented respectively by the mobile terminal T1 and by the remote server SV1 represented in FIGS. 1 and 2, according to a particular embodiment of the invention. invention;

- Figure 6 schematically shows a smart card adapted to cooperate with a remote server SV3 via an external terminal T3, according to a particular embodiment of the invention;

FIGS. 7a and 7b schematically represent modules implemented in the smart card CD and in the remote server SV3 shown in FIG. 6, according to one particular embodiment of the invention; and

FIG. 8 represents, in the form of a diagram, the main control process steps implemented respectively by the CD chip card and by the remote server SV3 represented in FIG. 6, according to a particular embodiment of FIG. invention.

Detailed description of several embodiments

As previously indicated, the present invention relates to electronic devices, such as smart cards or mobile terminals for example, configured to cooperate with an external terminal to perform a transaction, in the banking field for example. The invention aims in particular to secure transactions between an electronic device, such as a smart card or a mobile terminal for example, and an external terminal with a high security risk.

In the present description, examples of implementations of the invention are described in a non-limiting manner in relation to a transaction in accordance with the EMV protocol. It will be understood that the invention applies more generally to any electronic device configured to implement a transaction, including a transaction standard other than the EMV standard.

It should also be noted that the notion of transaction is understood here in a broad sense and includes, for example, in the banking field, both a payment or transfer transaction and a consultation of a bank account on a bank terminal. The various embodiments of the invention are here described in a non-limiting manner in the context of a payment transaction in the banking field, other types of transaction being possible within the scope of the invention.

Unless otherwise indicated, the elements common or similar to several figures bear the same reference signs and have identical or similar characteristics, so that these common elements are generally not described again for the sake of simplicity.

FIG. 1 represents, according to a particular embodiment, a terminal (or electronic device) T1 configured to cooperate with a remote server SV1 and an external terminal (or reader) T2. The terminal T2 is configured to interface between the terminal T1 and a remote server SV2. In a particular example, the servers SV1 and SV2 form a single server.

It is assumed here that the terminal T1 is a mobile terminal, for example a mobile phone, configured to process EMV transactions in cooperation with the terminal T2, other examples of terminals (mobile or fixed) being however possible within the framework of the 'invention. The terminal T1 is in this example an electronic payment terminal.

It will be understood that certain elements generally present in a mobile phone or in a server have been deliberately omitted because they are not necessary for the understanding of the present invention. Note also that the mobile terminal Tl and the remote server SVl shown in Figure 1 are only exemplary embodiments, other implementations being possible within the scope of the invention. The man Of particular interest in the art will be that certain elements of the mobile terminal T1 and the server SV1 are only described here to facilitate understanding of the invention, these elements not being indispensable for implementing the invention.

More specifically, the mobile terminal T1 comprises in this example a processor 2, a volatile memory 4 (RAM type), a rewritable non-volatile memory 6, a first communication interface 8a and a second communication interface 8b.

The rewritable non-volatile memory 6 here constitutes a recording medium according to a particular embodiment, readable by the terminal T1, on which is recorded a computer program PG1 according to a particular embodiment. This computer program PG1 includes instructions for carrying out the steps of a control method according to a particular embodiment.

The memory 6 is furthermore configured to contain a list LT of at least one terminal identifier. As explained in more detail later, this list allows the mobile terminal T1 to identify terminals presenting a particular security risk. From this list LT, the terminal T1 can thus determine if the terminal T2, with which it communicates to process an EMV transaction, is a risk terminal or not.

The interfaces 8a, 8b enable the mobile terminal T1 to communicate respectively with the remote server SV1 and with the external terminal T2, as explained hereinafter.

Moreover, the server SV1 comprises in this example a processor 20, a rewritable non-volatile memory 22 and a communication interface 24.

The rewritable non-volatile memory 22 here constitutes a recording medium according to a particular embodiment, readable by the server SVl, and on which is recorded a computer program PG2 according to a particular embodiment. This computer program PG2 includes instructions for executing the steps of a control method according to a particular embodiment.

The memory 22 is furthermore configured to contain a table TB containing at least one list LT in association with a given geographical area, each list LT containing at least one terminal identifier, as explained later in a particular example with reference to FIGS. 4b. According to a variant, the table TB is stored in a memory (for example a database) located outside the server SV1 and searchable by the latter. As explained hereinafter with reference to FIG. 2, the terminal T1 is configured to cooperate with the external terminal T2 to implement an EMV transaction. When the processing of this EMV transaction is done online, the terminal T2 is configured to cooperate with the remote server SV2 to enable the latter to verify and validate the current transaction EMV.

In the example considered here, the servers SV1 and SV2 are servers controlled by the transmitter (for example a bank) of an AP2 banking application installed in the terminal T1, as illustrated hereinafter in FIG.

As represented in FIGS. 1 and 2, the processor 2 of the mobile terminal T1 driven by the computer program PG1 here implements a number of modules, namely: a first determination module MD2, a sending module MD4, a first reception module MD6, a second reception module MD8, a second determination module MD10 and a processing module MD12.

In this example, the sending module MD4 and the receiving module MD6 are implemented by a first application API installed in the terminal T1 and executable by the processor 2. Similarly, the receiving module MD8, the determination module MD10 and the processing module MD12 are implemented by another application AP2 installed in the terminal T1 and executable by the processor 2. In this example, the API and AP2 applications are banking applications.

More specifically, the determining module MD2 is configured to determine a location data item DN representative of the location of the mobile terminal T1 at a given instant. In the example considered here, the determination module MD2 is configured to obtain geographical coordinates (for example GPS coordinates) indicating the geographical position of the mobile terminal T1, other implementation examples being conceivable.

According to one variant, the determination module MD2 is able to determine network data representative of the location of the mobile terminal T2 in a communication network, such as a mobile telephone network, for example. According to this variant, the module MD2 for example identifies at least two access points (relay antennas for example) to the communication network, these access points being close to the mobile terminal Tl. From the access points thus identified, the determination module MD2 is configured to determine the location data DN, for example using a well-known triangulation tracking technique. The sending module MD4 is configured to send the location data DN to the server SV1.

The reception module D6 is configured to receive, in response to the DN data sent by the sending module MD4, a list LT of at least one terminal identifier.

The reception module MD8 is configured to receive, during a current EMV transaction with the external terminal T2, an identifier IDX2 of said terminal T2.

The second determination module MD10 is configured to consult the list LT received by the first reception module MD6 to determine whether the identifier IDX2 received by the second reception module MD8 is included in said list LT. In a particular example, the reception module MD6 is further configured to store the list LT in a memory of the mobile terminal T1 (in the memory 6 in this example).

The processing module D12 is configured to process the current EMV transaction based on the result of the consultation of the list LT by the second determination module MD10. In a particular example, if the determining module MD10 determines that the identifier IDX2 of the terminal T2 is included in the list LT, the processing module MD12 is configured to trigger at least one predefined operation for securing the current EMV transaction. For example, the processing module MD12 is configured to trigger, as a security operation, the sending of an RGAC message requesting the continuation of the transaction in online mode, so that the remote server SV2 of the bank can carry out the necessary checks.

Moreover, as represented in FIGS. 1 and 2, the processor 20 of the server SV1 controlled by the computer program PG2 here implements a certain number of modules, namely: a reception module MD20, a determination module MD22, an MD24 selection module and an MD26 sending module.

More precisely, the reception module MD20 is configured to receive the location data DN sent by the sending module MD4 of the mobile terminal T1.

The determination module MD22 is configured to determine the location, denoted LOC, of the mobile terminal T1 from the received location data DN. The location data DN may be in any suitable format that can be interpreted by the determination module MD22 of the server SV1.

The selection module MD24 is configured to select, according to the location LOC of the mobile terminal T1, a corresponding list LT, that is to say a list LT of at least one terminal identifier, this list being thus adapted to the geographical position of the mobile terminal T1. As explained below, the invention advantageously allows the terminal T1 to determine if the external terminal or terminals T2 with which it is likely to cooperate present a particular security risk and, if so, tailor the treatment of a transaction accordingly.

The sending module MD26 of the server SV1 is configured to send the list LT, selected by the selection module MD24, to the mobile terminal T1. In this way, it is possible to configure the way in which the mobile terminal T1 processes a terminal. or subsequent EMV transactions.

The operation of the modules MD2-D12 of the mobile terminal T1 and the modules

MD20-MD26 of the remote server SV1 will appear more precisely in the exemplary embodiments described hereinafter with reference to FIGS. 3, 4a, 4b and 5.

It will be understood that the MD2-MD26 modules as represented in FIG. 2 represent only one example of non-limiting implementation of the invention.

Particular embodiments are now described with reference to FIGS. 3-5. More specifically, the mobile terminal T1 and the remote server SV1 shown in FIGS. 1 and 2 each implement a control method by executing respectively the computer programs PG1 and PG2.

As represented in FIGS. 1 and 4a, three lists LT (denoted LT1, LT2 and LT3) are here recorded in the memory 22 of the server SV1 in association with a respective geographic area RG (denoted RG1, RG2 and RG3). This record is here in the form of a TB table although other representations or arrangements are possible.

Each geographical area may correspond to a territory, a region or an appropriate site. In a particular example, a geographical area corresponds to a country, a city or even a zone of any perimeter. The issuing bank may, for example, define the size and the locations of the geographical zones according to criteria of its choice (postal address of the domicile of the carrier of the mobile terminal T1, etc.).

More precisely, in the example considered here, the table TB contains the lists LT1, LT2 and LT3 in association with respective identifiers IDR1, IDR2, IDR3 (collectively referred to as IDR) corresponding to the geographical areas RG1, RG2, RG3. Each IDR1-IDR3 ID identifies a corresponding RG geographic area, in association with an LT list.

FIG. 4b diagrammatically represents the list LT2 containing for example here the IDT identifiers denoted IDT1 to IDT4, each IDT identifier corresponding to a respective external terminal (or reader) capable of cooperating with the mobile terminal T1 to process an EMV transaction.

As represented in FIG. 3, the mobile terminal T1 determines, during a step A2, a location data item DN representative of the location LOC of the mobile terminal T1. In the example described here, this item DN is determined from GPS coordinates obtained by the determination module MD2, these GPS coordinates being representative of the geographical position of the mobile terminal 2. As already explained, other techniques are possible to determine the location data DN. The format of the DN location data may vary depending on the case. In a particular example, the location data DN comprises physical coordinates (for example the GPS coordinates) of the mobile terminal T1.

In A4, the mobile terminal T1 sends the location data DN to the server SV1 which receives it at B6.

The server SV1 determines (B8) then, from the received location data DN, the LOC location of the mobile terminal T1.

In B10, the server SV1 consults its table TB and selects, from the localization

LOC (or directly from the DN location data), the corresponding LT list. To do this, the server SV1 determines for example in which region RG specified in the table TB is the mobile terminal T1 and deduces the associated list LT. It is assumed in this example that the server SV1 determines, from the location LOC of the mobile terminal T1, that said terminal T1 is in the geographical area RG2 and, consequently, selects (B10) the associated list LT2, illustrated in FIG. 4b.

In B12, the server SV1 then sends the mobile terminal T1 the list LT2 selected in B10. The mobile terminal T1 receives this list LT2 at A12. In a particular example, the server SV1 sends in B12 the list LT2 in encrypted form (or encrypted). The mobile terminal T1 is then able to decrypt the list LT2 from a cryptographic key which it has.

In A14, the mobile terminal T1 saves the list LT2 in its memory 6. At the end of the control processes represented in FIG. 3, the mobile terminal T1 thus has in its memory a list of at least one terminal (or reader) presenting a particular security risk, this list being adapted to the location of the mobile terminal T1. Advantageously, it is thus possible to send to the mobile terminal T1 a list of limited size adapted to the geographical area in which said terminal T1 is located, which allows a gain in terms of memory space and In addition, the invention makes it possible to ensure that the mobile terminal T1 is able to determine whether the external terminals T2 located nearby present a particular risk or not.

The invention also makes it possible to update if necessary a list LT already contained in memory in the mobile terminal T1. Various embodiments can be envisaged to update this list LT.

According to a particular example, prior to step A2 shown in FIG. 3, the mobile terminal T1 already contains a list LT in memory, for example the list LT1. In A14, the mobile terminal T1 is then configured to erase the existing list LT1 and to record, as a new list, the list LT2 received at A12. In this way, it is possible to limit the necessary memory space in the mobile terminal T1 to store the IDT IDs of risk terminals. The mobile terminal T1 thus has the identifiers of the external terminals that it is likely to encounter in its vicinity.

According to a particular embodiment, the server SV1 also sends, at B12 (FIG. 3), to the mobile terminal T1, DRG2 data representative of the geographical area RG2 associated with the selected list LT2 (B12) by the server SV1. These DRG2 data define the boundaries of the DRG2 geographic area. In A14, the mobile terminal T1 stores the data DRG2 in association with the list LT2. The mobile terminal T1 then periodically compares, and / or upon receipt of a command, the current position of the mobile terminal T1 with the boundaries of the geographical area RG2 defined by the data DRG2. The mobile terminal T1 sends the server SV1 a request to update its list LT2 contained in its memory if it detects that its current position is outside the associated geographical area RG2. This update request comprises, for example, a location data item DN representative of the new positon of the mobile terminal T1. The updating of the list LT2 can be done in the same way as the control methods illustrated in FIG. retrieve and store the list LT2 in the memory of the mobile terminal Tl. This embodiment advantageously makes it possible to limit the resources of the network and the server SV1 necessary for the updating of the list LT insofar as the geographical areas are pre-established and the mobile terminal Tl sends an update request only if it detects that it is positioned outside the geographic area associated with its LT list.

According to another variant of the control method represented in FIG. 3, the mobile terminal T1 defines, as the reference position PRef, the position of said mobile terminal T1 corresponding to the location data DN sent in A4. After the reception A12 of the list LT1, the mobile terminal T1 is then configured to periodically evaluate, and / or in response to a command received, the distance between the current position of the mobile terminal T1 and the reference position PRef. The mobile terminal T1 sends the server SV1 a request to update its list LT if it detects that its current position is at a distance D greater than or equal to a predefined limit distance Dlim vis-à-vis the position of reference PRef. The updating of the list LT2 can be carried out in the same manner as the control methods illustrated in FIG. 3 to retrieve and store the list LT2 in the memory of the mobile terminal T1. This embodiment makes it possible to limit the resources required. at the mobile terminal T1 if it is not necessary for the mobile terminal T1 to determine the boundaries of the geographical area associated with its current list LT, or to compare these limits with its current position to determine whether a update of its LT list is necessary.

According to a particular exemplary embodiment, it is assumed that after the registration step A14 of the list LT2 as illustrated in FIG. 3, the mobile terminal T1 starts the processing of an EMV transaction denoted TRI, as illustrated in FIG. To do this, the mobile terminal T1 cooperates with the external terminal T2 in a known manner according to the EMV protocol. The mobile terminal T1 and the external terminal T2 exchange various standard EMV transaction messages such as, for example, the RST ("Reset"), ATR ("Answer to Reset"), SELECT FILE or even the well-known SELECT APPLICATION messages. of the skilled person.

As illustrated in FIG. 5, the terminal T2 sends (C20) to the mobile terminal T1 an identifier IDX2 of the terminal T2. In the example considered here, the identifier IDX2 is sent in C20 in a transaction message MSG1 type "GENERATE AC" (GAC) well known to those skilled in the art. The GAC command contains information such as, for example, the amount of the current transaction, the currency used and / or the type of transaction, etc. The mobile terminal T1 receives the identifier IDX2 from the external terminal T2 at A20 and then consults at A22 the list LT2, previously received at A12 (FIG. 3), to determine whether the identifier IDX2 is included in said list LT2.

The mobile terminal T1 then processes (A24) the transaction TRI according to the result of the consultation A22. In the example considered here, if it is detected in A22 that the identifier IDX2 is contained in the list LT2 present in the memory 6, the mobile terminal T1 deduces that the external terminal T2 presents a high security risk and adapts its A24 processing of the TRI transaction accordingly in order to secure the TRI transaction.

According to one particular example, if it is determined during said consultation A22 that the identifier IDX2 of the terminal T2 is included in the list LT2, the processing A24 of the transaction by the mobile terminal T1 comprises the triggering of at least one operation predefined security of the TRI transaction. The mobile terminal T1 performs for example at least one of the security operations A26, A28 and A30 as described below.

In A26, the mobile terminal T1 sends a request MSG2 to the terminal T2 requesting online processing of the current transaction TRI. In this particular example, the request MSG2 is an ARQC request (for "Authorization Request Cryptogram") according to the EMV protocol, well known to those skilled in the art. The terminal T2 receives the request MSG2 in C26, then transmits it to the remote server SV2 at C28. Once the MSG2 request has been received (B28), the remote server SV2 can then authenticate the TRI transaction and perform the appropriate security checks.

In A28, the mobile terminal T1 saves, in a log file (not shown), a predefined logging datum noted here DNH. This DNH data is for example stored in a memory of the mobile terminal T1. In a particular example, this historization data DNH indicates that a transaction TRI has been processed in cooperation with the external terminal T2 presenting a high security risk. It is thus possible to keep a history, in the mobile terminal T1, of the risk transactions to be processed with a sensitive external terminal. This DNH history data may be consulted later by the bank.

In A30, the mobile terminal T1 configures at least one operating parameter PR of the mobile terminal T1. Each operating parameter defines the manner in which the mobile terminal Tl processes an EMV transaction. Thus, the mobile terminal Tl modifies by a counter or the threshold threshold of the latter.

The present invention advantageously allows an electronic device (here the mobile terminal Tl) to determine whether an external terminal, with which it cooperates to process a transaction in progress, presents a particular security risk. Advantageously, the electronic device can check if this external terminal is a risk terminal during an offline transaction, that is to say without the intervention of the remote server SV2 of the issuer. Depending on whether the external terminal in question is identified as being at risk or not, the electronic device is then able to adapt its processing of the current transaction. If necessary, the electronic device may require the continuation of the online transaction with the help of the remote server SV2.

In a particular example, the list LT of at least one terminal identifier available to the electronic device is adapted to the position of said electronic device (as described above with reference to FIG. 3). This advantageously ensures that the electronic device is able to determine whether the external terminals 12 with which it is likely to cooperate present a particular security risk or not.

In addition, the identity of payment terminals, for example, with a security weakness may constitute sensitive information that the banks wish to protect. The invention advantageously makes it possible to limit the number of sensitive terminals that are identified in the list transmitted to the electronic device of the invention, so as to minimize the risks in the event of interception by a third party or a malicious entity.

Note that, in this embodiment, the mobile terminal T1 receives the appropriate LT list out of the scope of a transaction, such EMV for example, with an external terminal. It is thus possible to update the LT list of terminal identifiers of the mobile terminal without lengthening the processing time of an EMV transaction or other.

As already indicated, the implementation of the invention is not limited to a mobile terminal and can be applied to various electronic devices configured to process a transaction, of the EMV type for example, with an external terminal (or reader) .

FIG. 6 represents, according to another embodiment, an EMV chip card denoted CD, this CD card being configured to cooperate with an external terminal T3 to process an EMV transaction. The terminal T3 is configured to interface between the smart card CD and a remote server SV3, especially when an EMV transaction is processed online. In the example considered here, the server SV3 is controlled by the transmitter (the bank for example) of the smart card CD.

It will be understood here also that certain elements generally present in a smart card or in a bank server have been deliberately omitted because they are not necessary for the understanding of the present invention. Note also that the smart card CD and the remote server SV3 shown in Figure 6 are only exemplary embodiments, other implementations being possible within the scope of the invention. Those skilled in the art will understand in particular that certain elements of the CD card and the SV3 server are described here only to facilitate the understanding of the invention, these elements not being indispensable for implementing the invention.

More specifically, the CD chip card comprises in this example a processor 30, external contacts 32 configured to cooperate with the reader T3 and a rewritable non-volatile memory 34.

The memory 34 constitutes in this example a recording medium according to a particular embodiment, readable by the smart card CD, and on which is recorded a computer program PG3 according to a particular embodiment. This computer program PG3 includes instructions for performing the steps of a control method according to a particular embodiment, as described below.

In a particular example, the CD chip card is in accordance with ISO 7816.

In this case, the external contacts 32 have characteristics in accordance with this standard. However, it will be understood that other embodiments are possible. The smart card CD can for example cooperate with the reader T3 in contactless mode via an RF antenna integrated in the CD card.

Still in the example considered here, the memory 34 is configured to contain a list LT of at least one terminal identifier, in the same way as the memory 6 represented in FIG.

Still with reference to FIG. 6, the server SV3 presents in this example a structure similar to that of the server SV1 illustrated in FIG. 1. More particularly, the server SV2 comprises in this example a processor 40, a non-volatile rewritable memory 42 and an interface of communication 44.

The memory 42 here constitutes a recording medium according to a particular embodiment, readable by the server SV3, and on which a program is recorded. PG4 computer according to a particular embodiment. This PG4 computer program includes instructions for executing the steps of a control method according to a particular embodiment.

The memory 42 is further configured to contain a table TB identical to that described above with reference to Figures 4a, 4b. In the example considered here, the table TB thus contains the lists LT1 to LT3 in association with the respective geographical areas RG1 to RG3 (or more particularly, in association with the identifiers of zones IDR1 to IDR3). According to a variant, the table TB is stored in a memory (for example a database) outside the server SV3 and searchable by the latter.

The interface 44 allows the server SV3 to communicate with the external terminal T3.

Moreover, the processor 30 of the CD card, driven by the computer program PG3, implements a number of modules shown in FIG. 7a, namely: a first reception module MD40, a determination module MD42, an MD44 processing module, an MD46 sending module and a second receiving module MD48.

The first reception module MD40 is configured to receive an identifier IDX3 of the external terminal T3, for example in an EMV transaction message. In a particular example, the reception module MD40 is further configured to record the identifier IDX3 received in the memory 34 of the smart card CD.

The determination module MD42 is configured to consult the list LT, present in the memory 34, to determine if the identifier IDX3 received by the first reception module MD40 is included in said list LT.

The processing module MD44 is configured to process an EMV transaction in progress based on the result of the consultation of the list LT by the determination module MD42. In a particular example, if the determination module MD42 determines that the identifier IDX3 of the terminal T3 is included in the list LT, the processing module MD12 is configured to trigger at least one predefined operation for securing the current EMV transaction. The processing module MD44 is for example configured to trigger a predefined security operation identical to the processing module MD12 illustrated in FIG.

The sending module MD46 is configured to send, for example in an EMV transaction message, the identifier IDX3 of the terminal T3 to the server SV3. The reception module MD48 is configured to receive, in response to the identifier IDX3 sent by the sending module MD46, a new list LT of at least one terminal identifier. This new list LT is for example received in a command, called script command, from the server SV3.

Moreover, the processor 40 of the SV3 server, controlled by the computer program

PG4 implements a number of modules shown in FIG. 7b, namely: a reception module MD60, a determination module MD62, a selection module MD64 and a sending module MD66. The modules MD60 to MD66 of the server SV3 respectively operate in a similar way to the modules MD20 to MD26 of the server SV1, as represented in FIG.

More precisely, the reception module MD60 is configured to receive the identifier IDX3, of the terminal T3, coming from the smart card CD.

The determination module MD62 is configured to determine the location, denoted LOC, of the smart card CD from the IDX3 ID received. Knowing which terminal T3 cooperates with the CD card, the server SV3 is indeed able to deduce the position of the CD card.

The selection module MD64 is configured to select, from the location LOC of the smart card CD, a corresponding list LT, that is to say a list LT of at least one terminal IDT, this list being adapted to the geographical position of the smart card CD. As indicated below, this list then enables the smart card CD to identify the external terminal or terminals T3 in its vicinity, and presenting a particular security risk.

The sending module MD66 of the server SV3 is configured to send the list LT, selected by the selection module MD64, to the smart card CD. It is thus possible to configure how the CD chip card processes one or more subsequent EMV transactions.

The operation of the MD40-MD48 modules of the CD chip card and the MD60-D66 modules of the remote server SV3 will appear more precisely in the exemplary embodiments described hereinafter with reference to FIG. 8.

It will be understood that the MD40-MD48 modules of the CD chip card and the modules

MD60-MD66 SV3 remote server, as shown in Figures 7a and 7b, is only one example of non-limiting implementation of the invention. A particular embodiment is now described with reference to FIG. 8. Specifically, the CD chip card and the remote server SV3 shown in FIG. 6 each implement a control method by respectively executing the PG3 computer programs. and PG4.

In an initial state, it is assumed that the list LT2 as represented in FIG. 4b is stored in the memory 34 of the smart card CD. This list LT2 is for example recorded during a personalization phase of the chip card CD or during a subsequent update of the smart card CD.

As already indicated, the table TB of the server SV3 contains the lists LT1, LT2 and LT3 (collectively referred to as LT) in association with respectively the geographical areas RG1, RG2 and RG3 (collectively referred to as RG).

As illustrated in FIG. 8, it is assumed that the chip card CD initiated the processing of an EMV transaction denoted TR2 with the external terminal T3. For this purpose, the smart card CD cooperates with the external terminal T3 in a known manner according to the EMV protocol. The smart card CD and the external terminal T3 exchange, in particular, normalized transaction messages EMV that are well known to the man. such as RST, ATR SELECT FILE etc. as already explained with reference to the TRI transaction in FIG.

During a sending step C40, the external terminal T3 sends the identifier IDX3 of said terminal T3 to the smart card CD. The message MSG4, in which the identifier IDX3 is sent to C40, is in this example a GAC message conforming to the EMV standard.

The smart card CD receives the identifier IDX3 of the external terminal T3 at A40 and then looks at A42 list LT2, similar to the consultation A22 shown in Figure 5, to determine whether the identifier IDX3 is included in said list LT2.

The smart card CD processes (A43) then the current transaction TR2 according to the result of the consultation A42. In the example considered here, if it is detected in A42 that the identifier IDX3 is contained in the list LT2 present in the memory 34, the smart card CD deduces that the external terminal T3 presents a high and adapted security risk. its processing transaction TR2 accordingly to secure transaction TR2, similarly to step A24 shown in Figure 5. According to a particular example, if it is determined during said consultation A42 that the identifier IDX3 of the terminal T3 is included in the list LT2, the processing (A43) of the transaction by the smart card CD includes triggering at least one predefined operation of securing the transaction T 2, such as at least one of the operations A26, A28 and A30 shown in FIG.

The invention here allows the chip card CD to determine, without the help of the remote server SV3 of the transmitter (offline), if the external terminal T3 is sensitive in terms of security and thus to adapt the processing of the EMV transaction as already explained above.

In a particular example, it is now assumed that the smart card CD has determined, during the consultation A42, that the identifier ÏDX3 of the terminal T3 is not present in the list LT2. During a sending step A44, the smart card CD sends the identifier IDX3 to the remote server SV3. The message MSG5, in which the identifier IDX3 of the terminal T3 is located, is in this example an EMV transaction message type ARPC (for "authorization response cryptogram") indicating the decision of the bank.

It should be noted that the smart card CD does not have here means for determining its location. Also, it is not able to provide a DN location data as described above in steps A2-A4 shown in Figure 3. As indicated later, this is the identifier IDX3 of the terminal T3 provided by the smart card CD that allows the server SV3 to determine a list LT adapted to the position of the smart card CD.

The terminal T3, which interfaces here between the smart card CD and the server SV3, receives the identifier IDX3 at C44 and sends it to the server SV3 at C46.

The server SV1 then evaluates (B48), from the identifier IDX3 of the terminal T3 received, the location LOC of the smart card CD. To do this, the server SV3 uses for example a table (not shown) indicating the geographic area RG associated with the external terminal T3. In the present example, it is assumed that the bank issuing the smart card CD is able to determine, from the identifier IDX3, the geographical position of the terminal T3, and therefore of the CD chip card in the vicinity.

In B50, the server SV3 then consults its TB table illustrated in FIG. 4a and selects, from the location LOC of the smart card CD, the corresponding list LT. To do this, the server SV3 determines for example in which geographical area RG specified in the table TB is the terminal T3 (and therefore the smart card CD) and derives the associated list LT. It is assumed in this example that the server SV3 determines, from the location LOC of the smart card CD, that the smart card CD is now in the geographical area RG3 and, therefore, selects (B50) the associated list LT3.

In B52, the server SV3 then sends to the smart card CD the list LT3 selected in B50. In this example, the SG6 message in which the LT3 list is sent in B52, is a script command conforming to the EMV standard, this command requiring the update of the CD chip card from the LT3 list.

The smart card CD receives in A54 the MSG6 command containing the new list LT3 of at least one terminal identifier.

In A56, the smart card CD saves the new list LT3 in its memory 34. In this example, the smart card CD deletes (A56) in addition the old list LT2 which was hitherto stored in the memory 34.

At the end of the control methods shown in FIG. 8, the smart card CD thus has in its memory a list of at least one terminal (or reader) presenting a particular security risk, this list being adapted to the location of said CD card. Advantageously, it is thus possible to send to the smart card CD a list of limited size adapted to the geographical area in which the smart card CD is located, which allows a gain in terms of memory space and resources used at the level of the smart card CD. In addition, the invention makes it possible to ensure that the smart card CD is capable of determining whether the external terminals T2 located nearby present a particular risk or not.

In the embodiments and variants described in this disclosure, the LT list provided to the electronic device by the remote server is a "black" list in the sense that it identifies the external terminal (s) presenting a particular security risk. Alternatively, it is possible to envisage other implementations in which the LT list is a "white" list in the sense that it identifies the external terminal (s) presenting no particular security risk. According to other variants, the LT list identifies both terminals as risk terminals, and other terminals as trusted terminals.

According to a particular embodiment, in addition to the first list LT varying according to the position of the electronic device, the latter may contain in memory a second list LT of at least one terminal identifier which does not vary according to the position of the electronic device. This second list LT is for example associated with a geographical area where the carrier of the electronic device is likely to be found frequently (near his home, a privileged place of his choice, etc.). The electronic device is then configured to consult the first and second lists LT during steps A22 and A42 previously described.

Note also that, in the embodiments and variants described above, each terminal IDT identifier corresponds to a single external terminal capable of interacting with the electronic device of the invention. As a variant, an IDT identifier contained in a list LT may correspond to a group of at least two terminals (IDT identifies for example a type or model of terminal). For example, an IDT identifier may correspond to the name of the merchant involved in a payment transaction.

Those skilled in the art will understand that the embodiments and variants described above are only non-limiting examples of implementation of the invention. In particular, those skilled in the art may consider any adaptation or combination of the embodiments and variants described above to meet a particular need.

Claims

1. A method for controlling an electronic device (Tl; CD), said method comprising, during a payment transaction (TRI; TR2) being processed in cooperation with a payment terminal (T2; T3), the following steps :

receiving (A20, A40), from the payment terminal, an identifier (IDX2; IDX3) of said payment terminal;

consulting (A22; A42) a first list (LT) of at least one terminal identifier (ID) for determining whether the identifier of said payment terminal (T2; T3) is included in said first list; and

- processing (A24; A43) of the payment transaction according to the result of said consultation.

2. Control method according to claim 1, comprising, prior to said step (A22; A42) of consultation, the registration of the first list of at least one terminal identifier in a memory of the electronic device.

3. Control method according to claim 1 or 2, said method comprising, prior to said consultation step (A22; A42):

sending (A4; A44) to a remote server (SV1; SV3) data (DN; IDX3) enabling the remote server to determine the location (LOC) of the electronic device; and

receiving (A12; A54), in response to said sending, the first list (LT2; LT3) of at least one terminal identifier (IDT), said first list being a function of said location of the electronic device.

4. Control method according to claim 3, wherein said datum is a location data (DN) representative of the location of the electronic device.

5. Control method according to claim 4, said method comprising, prior to its sending (A4), the determination of said location data (DN) from at least one of:

GPS coordinates representative of the geographical location of the electronic device; and - Network data representative of the location of the electronic device in a communication network.

6. Control method according to any one of claims 1 to 5, wherein, if it is determined during said consultation (A22; A42) that the identifier of said payment terminal is included in the first list (LT2; LT3) of at least one terminal identifier, the processing step (A24; A43) of the payment transaction includes triggering at least one predefined transaction for securing the payment transaction.

The checking method according to claim 6, wherein said at least one predefined security operation comprises at least one of:

sending (A26) a request requesting online processing of the current payment transaction;

recording (A38), in a log file, of a predefined logging datum; and

- configuration (A30) of at least one operating parameter of the electronic device.

8. Control method according to any one of claims 1 to 7, wherein the current payment transaction (TRI; TR2) is of the EMV type and the identifier (IDX2; IDX3) of the payment terminal (T2; T3 ) is received in an EMV transaction message of type GAC.

9. Control method according to claim 8, comprising:

receiving (A12; A54), during the current payment transaction, a command specifying a second list (LT) of at least one terminal identifier; and

in response to said command, recording (A14; A56) of said second list in a memory of the electronic device in replacement of said first list.

10. Method of sending implemented by a server (SV1; SV3), comprising the following steps: receiving (B6; B46) data (DN; IDX3) from an electronic device (Tl; CD) configured to cooperate with a payment terminal (T2; T3) for implementing a payment transaction;

determining (B8; B48) the location of the electronic device from said datum;

selecting (B10; B50), from the location of the electronic device, a list (LT) of at least one terminal identifier (IDT); and

sending (B12; B52) said list to the electronic device so as to configure the processing, by the electronic device, of a payment transaction.

The method of sending according to claim 10, wherein the received data is one of:

a location data item (DN) representative of the location of the electronic device; and

an identifier (IDX3) of a payment terminal with which the electronic device cooperates to process a payment transaction in progress.

The sending method of claim 10 or 11, wherein the server sends the list (LT) of at least one terminal identifier to the electronic device in an EMV transaction message.

13. A computer program (PG1; PG2) comprising instructions for executing the steps of a method according to any one of claims 1 to 12 when said program is executed by a computer.

14. Electronic device (T1, CD) comprising, during a payment transaction; T3) in progress with a payment terminal, the following steps:

a reception module (MD8) configured to receive, during a payment transaction in progress with a payment terminal, an identifier of said payment terminal;

a determination module (MD10) configured to consult a first list of at least one terminal identifier to determine whether the identifier of said payment terminal is included in said first list; and - A processing module (MD12) configured to process the payment transaction based on the result of the consultation of the first list by the consultation module.

15. Server (SV3) comprising:

- a receiving module (D60) configured to receive data from an electronic device, said device being configured to cooperate with a payment terminal to implement a payment transaction;

a determination module (MD62) configured to determine the location of the electronic device from said datum;

a selection module (D64) configured to select, from the location of the electronic device, a list of at least one terminal identifier; and

- A sending module (MD66) configured to send said list to the electronic device so as to configure the processing, by the electronic device, of a payment transaction.