FR3053814A1 - METHOD FOR CONTROLLING AN ELECTRONIC DEVICE FOR PROCESSING A TRANSACTION - Google Patents

Abstract

The invention proposes a method for controlling an electronic device (T1), the method comprising, during a transaction being processed in cooperation with a terminal (T2), reception from the terminal (T2), an identifier of said terminal; consulting a list (LT) of terminal identifiers to determine if the received identifier is included in the list (LT); and processing the transaction based on the result of the consultation.

Description

® FRENCH REPUBLIC

NATIONAL INSTITUTE OF INDUSTRIAL PROPERTY © Publication number: 3,053,814 (to be used only for reproduction orders)

©) National registration number: 16 56622

COURBEVOIE © Int Cl ⁸ : G 06 Q 20/18 (2017.01), G 06 Q 20/34, 20/32

A1 PATENT APPLICATION

(§) Date of filing: 11.07.16. © Applicant (s): OBERTHUR TECHNOLOGIES (30) Priority: Public limited company - FR. @ Inventor (s): DE OLIVEIRA MARCO and CLIMEN BRUNO. (43) Date of public availability of the request: 12.01.18 Bulletin 18/02. (© List of documents cited in the report of preliminary research: Refer to end of present booklet (© References to other national documents @ Holder (s): OBERTHUR TECHNOLOGIES Company related: anonymous. ©) Extension request (s): © Agent (s): CABINET BEAU DE LOMENIE.

METHOD FOR CONTROLLING AN ELECTRONIC DEVICE FOR PROCESSING A TRANSACTION.

tg /) The invention proposes a method for controlling an electronic device (T1), the method comprising, during a transaction being processed in cooperation with a terminal (T2), the reception from the terminal ( T2), an identifier of said terminal; consulting a list (LT) of terminal identifiers to determine whether the identifier received is included in the list (LT); and processing the transaction based on the outcome of the consultation.

FR 3 053 814 - A1

Invention background

The present invention lies in the general field of electronic devices and relates more particularly to an electronic device, such as a smart card or a mobile terminal for example, configured to cooperate with an external terminal to carry out 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 ISO7816 standard. The invention also applies to terminals, in particular mobile terminals such as mobile telephones for example, configured to cooperate with an external terminal (or reader) to process a transaction.

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

Generally, a smart card is designed to communicate with a device external to this card, otherwise called a terminal or reader. These cards make it possible to carry out various types of transactions, such as, for example, payment transactions, direct debits or authentication of the bearer. Chip cards for banking applications (credit card, debit card, etc.), for example, are able to cooperate with payment terminals or automatic teller machines (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 carry out a transaction with an external terminal. A mobile solution consists, for example, of installing an application on a mobile terminal (a mobile telephone for example) to process a transaction similar to a smart card.

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

The EMV protocol was designed to reduce the risk of fraud during a payment transaction by allowing authentication of both the smart card and its holder. 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 code) by the card holder.

Depending on the type of card used, the situation, or even 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 behind the card, for example) in order to verify in particular that the transaction in progress is legitimate. On the other hand, if the EMV card operates in offline mode, it applies pre-recorded verification criteria to decide whether the transaction should be authorized or refused.

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

However, some payment terminals may have implementation weaknesses (unpredictable non-random number, unsupported signature, etc.) capable of being 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 intended to process a transaction as indicated above.

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

A need exists in particular to secure the processing of an offline transaction between an electronic device and a terminal at risk, insofar as the bank is not able to make specific checks to ensure the validity of the transaction.

Subject and summary of the invention / Summary

To this end, 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:

- reception, from the terminal, of an identifier of said terminal;

- consultation of a first list of at least one terminal identifier to determine whether 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 whether the terminal with which it cooperates during a transaction presents a particular security risk and, if so, to adapt the processing of the transaction accordingly in order, for example, to further secure the transaction.

According to a particular embodiment, the method comprises, prior to said consultation step, recording 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

reception, in response to said sending, of 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 allows 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 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 data is a location data 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 geographic 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 comprises triggering at minus a predefined transaction security operation.

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

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

- recording, in a history file, of a predefined history data; and

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

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

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

- reception, during the current transaction, of an order specifying a second list of at least one terminal identifier; and

- In response to said command, recording of 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 different steps of the control method are determined by instructions from computer programs.

Consequently, the invention also relates to a computer program on an information medium, this program being capable of being implemented in an electronic device such as a mobile terminal, or more generally in a computer, this program comprising instructions adapted to the implementation of the steps of a control process as defined above.

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

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

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

- determination of the location of the electronic device from said data;

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

- sending of 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 data received is one of:

- 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 different steps of the sending method are determined by instructions from 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 implementation implementing the steps of a sending process as defined above.

The invention also relates to a recording medium (or information medium) readable by a computer, and comprising 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 according to the result of the consultation of the first list by the consultation module.

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

The invention further relates to a server comprising:

- a reception 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 data;

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 different 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 to the electronic device and the server defined above.

Brief description of the drawings

Other characteristics and advantages of the present invention will emerge from the description given below, with reference to the accompanying drawings which illustrate exemplary embodiments thereof without any limiting character. In the figures:

- Figure 1 schematically shows a mobile terminal capable of cooperating with a remote server SV1 and with an external terminal T2, according to a particular embodiment of the invention;

- Figure 2 schematically represents modules implemented in the mobile terminal Tl and in the remote server SV1 shown in Figure 1, according to a particular embodiment of the invention;

- Figure 3 shows schematically control methods implemented respectively by the mobile terminal T1 and by the remote server SV1 shown in Figures 1 and 2, according to a particular embodiment of the invention;

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

- Figure 4b schematically shows an example of a list LT2 contained in the table TB shown in Figure 4a;

- Figure 5 shows, in the form of a diagram, the main steps of control methods implemented respectively by the mobile terminal Tl and by the remote server SV1 shown in Figures 1 and 2, according to a particular embodiment of the invention;

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

- Figures 7a and 7b schematically represent modules implemented in the CD chip card and in the remote server SV3 shown in Figure 6, according to a particular embodiment of the invention; and

FIG. 8 represents, in the form of a diagram, the main steps of control methods implemented respectively by the chip card CD and by the remote server SV3 represented in FIG. 6, according to a particular embodiment of the 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 carry out a transaction, in the banking sector for example.

The invention aims in particular to secure transactions carried out between an electronic device, such as a smart card or a mobile terminal for example, and an external terminal presenting a high security risk.

In the present description, examples of implementations of the invention are described in a nonlimiting 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 according to a transaction standard other than the EMV standard.

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

Unless otherwise indicated, the elements common or analogous to several figures bear the same reference signs and have identical or analogous 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 Tl 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 telephone, 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 in this example constitutes an electronic payment terminal.

It will be understood that certain elements generally present in a mobile telephone or in a server have been deliberately omitted because they are not necessary for the understanding of the present invention. It should also be noted that the mobile terminal T1 and the remote server SV1 represented in FIG. 1 constitute only examples of embodiment, other implementations being possible within the framework of the invention. Those skilled in the art will understand in particular that certain elements of the mobile terminal T1 and of the server SV1 are described here only to facilitate understanding of the invention, these elements not being essential for implementing the invention.

More specifically, the mobile terminal T1 comprises in this example a processor 2, a volatile memory 4 (of 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 conforming to a particular embodiment, readable by the terminal T1, and on which is recorded a computer program PG1 conforming to a particular embodiment. This computer program PG1 includes instructions for the execution of the steps of a control method according to a particular embodiment.

The memory 6 is also configured to contain a list LT of at least one terminal identifier. As explained in more detail below, 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 whether the terminal T2, with which it communicates to process an EMV transaction, is a terminal at risk or not.

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

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

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

The memory 22 is further 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. 4a and 4b. According to a variant, the table TB is saved in a memory (for example a database) located outside the server SV1 and can be consulted by the latter.

As explained below 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 allow the latter to verify and validate the EMV transaction in progress.

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

As shown in FIGS. 1 and 2, the processor 2 of the mobile terminal Tl controlled by the computer program PG1 here implements a certain 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 API application installed in the terminal T1 and executable by the processor 2. Likewise, the receiving module MD8, the determination module MD10 and the MD12 processing module are implemented by another application AP2 installed in the terminal T1 and executable by the processor 2. In this example, the applications API and AP2 are banking applications.

More specifically, the determination module MD2 is configured to determine location data DN representative of the location of the mobile terminal Tl at a given time. In the example considered here, the determination module MD2 is configured to obtain geographic coordinates (for example GPS coordinates) indicating the geographic position of the mobile terminal T1, other examples of implementation being however possible.

According to a 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 identifies for example at least two access points (relay antennas for example) to the communication network, these access points being located near the mobile terminal T1. From the access points thus identified, the determination module MD2 is configured to determine the location data DN, for example by using a well-known location technique of triangularization.

The sending module MD4 is configured to send the location data DN to the server SV1.

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

The reception module MD8 is configured to receive, during an EMV transaction in progress 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 Tl (in memory 6 in this example).

The processing module MD12 is configured to process the transaction EMV in progress according to the result of the consultation of the list LT by the second determination module MD10. In a particular example, if the determination 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 transaction EMV in progress. The processing module MD12 is for example 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.

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

More specifically, the reception module MD20 is configured to receive the location data DN transmitted by the sending module MD4 of the mobile terminal Tl.

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

The selection module MD24 is configured to select, as a function of 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 thus being adapted to the geographical position of the mobile terminal Tl. As explained below, the invention advantageously allows the terminal Tl to determine whether the external terminal or terminals T2 with which it is likely to cooperate present a particular security risk and, if so, to adapt the processing 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 Tl. In this way, it is possible to configure the way in which the mobile terminal Tl processes a or subsequent EMV transactions.

The operation of the modules MD2-MD12 of the mobile terminal T1 and of the modules MD20-MD26 of the remote server SV1 will appear more precisely in the embodiments described below with reference to FIGS. 3, 4a, 4b and 5.

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

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

As shown 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 recording is presented here in the form of a TB table although other representations or arrangements are possible.

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

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

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

As shown in FIG. 3, the mobile terminal Tl determines, during a step A2, a datum of localization DN representative of the localization LOC of the mobile terminal Tl. In the example described here, this datum DN is determined from GPS coordinates obtained by the MD2 determination module, these GPS coordinates being representative of the geographic position of the mobile terminal 2. As already explained, other techniques are possible for determining the location datum 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 Tl.

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

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

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

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

In A14, the mobile terminal Tl stores the list LT2 in its memory 6.

At the end of the control methods represented in FIG. 3, the mobile terminal Tl 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 Tl. Advantageously, it is thus possible to send to the mobile terminal Tl a list of limited size adapted to the geographical area in which said terminal Tl is located, which allows a gain in terms of memory space and resources used at the level of the mobile terminal T1. In addition, the invention makes it possible to ensure that the mobile terminal T1 is capable of determining whether the external terminals T2 located nearby present a particular risk or not.

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

According to a particular example, prior to step A2 shown in FIG. 3, the mobile terminal T1 already contains in memory a list LT, 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 in A12. In this way, it is possible to limit the memory space required in the mobile terminal T1 to store the identifiers IDT of terminals at risk. The mobile terminal Tl 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, data DRG2 representative of the geographic area RG2 associated with the list LT2 selected (B12) by the server SV1. This DRG2 data defines the boundaries of the DRG2 geographic area. In A14, the mobile terminal T1 records the DRG2 data in association with the list LT2. The mobile terminal Tl then periodically compares, and / or on receipt of an order, the current position of the mobile terminal Tl with the limits of the geographic area RG2 defined by the data DRG2. The mobile terminal Tl 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 geographic area RG2. This update request includes, for example, a location data item DN representative of the new position of the mobile terminal T1. The updating of the list LT2 can be carried out in the same way as the control methods illustrated in FIG. 3 for retrieve and store the list LT2 in the memory of the mobile terminal T1. This embodiment advantageously makes it possible to limit the resources of the network and of the server SV1 necessary for updating the list LT insofar as the geographic zones are pre-established and the mobile terminal Tl sends an update request only if it detects that it is positioned outside the geographical area associated with its list LT.

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

According to a particular exemplary embodiment, it is assumed that after step A14 of registering the list LT2 as illustrated in FIG. 3, the mobile terminal Tl begins the processing of an EMV transaction denoted TRI, as illustrated in FIG. 5. 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 standardized EMV transaction messages such as, for example, the well known RST (“Reset”), ATR (“Answer to Reset”), SELECT FILE or 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 at C20 in a transaction message MSG1 of the "GENERATE AC" (GAC) type 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 in A20 then consults in A22 the list LT2, previously received in A12 (FIG. 3), to determine whether the identifier IDX2 is included in said list LT2.

The mobile terminal Tl 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 Tl deduces therefrom that the external terminal T2 presents a high security risk and adapts its processing A24 of the TRI transaction accordingly in order to secure the TRI transaction.

According to a 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 Tl comprises the triggering of at least one operation predefined security for the TRI transaction. The mobile terminal Tl 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 the processing in online mode of the transaction TRI in progress. In this particular example, the MSG2 request is an ARQC type 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 in 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 Tl records, in a history file (not shown), a predefined history data item noted here DNH. This DNH datum is for example stored in a memory of the mobile terminal T1. In a particular example, this DNH historization datum 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 risky transactions processed with a sensitive external terminal. This DNH historical data can if necessary be consulted later by the bank.

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

The present invention advantageously allows an electronic device (here the mobile terminal T1) 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 whether this external terminal is a terminal at risk during an offline transaction, that is to say without the intervention of the remote server SV2 of the transmitter. 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 transaction in progress. If necessary, the electronic device can request 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 makes it possible to ensure that the electronic device is capable of determining whether the external terminals T2 with which it is capable of cooperating present a particular security risk or not.

In addition, the identity of payment terminals, for example, having a weak security can constitute sensitive information that banks wish to protect. The invention advantageously makes it possible to limit the number of sensitive terminals which 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 Tl receives the appropriate list LT outside the framework of a transaction, of the EMV type for example, with an external terminal. It is thus possible to update the list LT of terminal identifiers of the mobile terminal without extending the processing time of an EMV or other transaction.

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 chip card CD and a remote server SV3, in particular when an EMV transaction is processed online. In the example considered here, the server SV3 is controlled by the issuer (the bank for example) of the CD chip card.

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

More specifically, the CD chip card in this example comprises 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 conforming to a particular embodiment, readable by the chip card CD, and on which is recorded a computer program PG3 conforming to a particular embodiment. This computer program PG3 includes instructions for the execution of the steps of a control method according to a particular embodiment, as described below.

In a particular example, the CD chip card complies with ISO standard 7816. In this case, the external contacts 32 have characteristics which comply with this standard. It will however be understood that other embodiments are possible. The CD chip card 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. 1.

Still with reference to FIG. 6, the server SV3 has 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 rewritable non-volatile memory 42 and interface communication 44.

The memory 42 here constitutes a recording medium conforming to a particular embodiment, readable by the server SV3, and on which a computer program PG4 conforming to a particular embodiment is recorded. This PG4 computer program includes instructions for the execution of 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 FIGS. 4a, 4b. In the example considered here, the table TB thus contains the lists LT1 to LT3 in association with the respective geographic zones RG1 to RG3 (or more particularly, in association with the identifiers of zones IDR1 to IDR3). According to a variant, the table TB is saved in a memory (for example a database) outside the server SV3 and can be consulted by the latter.

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

Furthermore, the processor 30 of the CD card, controlled by the computer program PG3, here implements a certain number of modules represented in FIG. 7a, namely: a first reception module MD40, a determination module MD42, a processing module MD44, a sending module MD46 and a second receiving module MD48.

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

The determination module MD42 is configured to consult the list LT, present in the memory 34, to determine whether 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 as a function of 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 transaction EMV in progress. The MD44 processing module is for example configured to trigger a predefined security operation in an identical manner to the MD12 processing module illustrated in FIG. 1.

The sending module MD46 is configured to send, for example in an EMV transaction message, the identifier IDX3 from 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, coming from the server SV3.

Furthermore, the processor 40 of the server SV3, controlled by the computer program PG4, here implements a certain number of modules represented in FIG. 7b, namely: a reception module MD60, a determination module MD62, a module selection module and an MD66 sending module. The modules MD60 to MD66 of the server SV3 respectively operate in a similar manner to the modules MD20 to MD26 of the server SV1, as shown in FIG. 2.

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

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

The MD64 selection module is configured to select, from the LOC location of the CD chip card, a corresponding LT list, that is to say a LT list of at least one terminal IDT identifier, this list being adapted to the geographical position of the CD chip card. As indicated below, this list then allows the CD chip card to identify the external terminal or terminals T3 located 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 the way in which the CD chip card processes one or more subsequent EMV transactions.

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

It will be understood that the modules MD40-MD48 of the chip card CD and the modules MD60-MD66 of the remote server SV3, as represented in FIGS. 7a and 7b, constitute only one example of non-limiting implementation of the invention.

A particular embodiment is now described with reference to FIG. 8. More specifically, the smart card CD and the remote server SV3 represented in FIG. 6 each implement a control method by executing respectively the computer programs PG3 and PG4.

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

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

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

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

The chip card CD receives the identifier IDX3 from the external terminal T3 at A40 and then consults at A42 the list LT2, in a manner analogous to the consultation A22 represented in FIG. 5, to determine whether the identifier IDX3 is included in said list LT2.

The CD chip card then processes (A43) the transaction TR2 in progress 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 chip card CD deduces therefrom that the external terminal T3 presents a high security risk and adapts its processing of the transaction TR2 accordingly in order to secure the transaction TR2, in a similar manner to step A24 represented in FIG. 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 comprises the triggering of at least one predefined operation for securing the transaction TR2, such as for example at least one of the operations A26 , A28 and A30 shown in Figure 5.

The invention here allows the smart card CD to determine, without the help of the remote server SV3 of the transmitter (offline), whether 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 chip card CD has determined, during the consultation A42, that the identifier iDX3 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 found, is in this example an EMV transaction message of ARPC type (for “authorization response cryptogram”) indicating the bank's decision.

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

The terminal T3, here acting as the interface between the chip card CD and the server SV3, receives the identifier IDX3 in C44 and transmits it to the server SV3 in 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 CD chip card is capable of determining, from the identifier IDX3, the geographical position of the terminal T3, and therefore of the CD chip card located nearby.

In B50, the server SV3 then consults its table TB illustrated in FIG. 4a and selects, from the location LOC of the chip 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 deduces therefrom the associated list LT. It is assumed in this example that the server SV3 determines, from the LOC location of the CD chip card, that the chip card

CD is now in the geographic area RG3 and therefore selects (B50) the associated LT3 list.

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

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

In A56, the chip card CD stores the new list LT3 in its memory 34. In this example, the chip card CD also deletes (A56) the old list LT2 which was previously stored in memory 34.

At the end of the control methods represented in FIG. 8, the CD chip card 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 CD chip card a list of limited size adapted to the geographical area in which the CD chip card is located, which allows a gain in terms of memory space and resources used at the CD chip card level. In addition, the invention makes it possible to ensure that the CD chip card 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 presentation, the list LT supplied to the electronic device by the remote server is a "black" list in the sense that it identifies the external terminal or terminals presenting a particular security risk. As a variant, 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 or terminals presenting no particular security risk. According to other variants, the list LT identifies both terminals as terminals at risk, and other terminals as trusted terminals.

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

It should also be noted 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 identifier IDT contained in a list LT can correspond to a group of at least two terminals (IDT identifies for example a type or model of terminal). An IDT identifier can for example correspond to the name of the merchant involved in a payment transaction.

A person skilled in the art will understand that the embodiments and variants described above only constitute nonlimiting examples of implementation of the invention. In particular, a person skilled in the art can envisage any adaptation or combination of the embodiments and variants described above in order to meet a very specific need.

Claims (15)

1. Method for controlling an electronic device (Tl; CD), said method comprising, during a transaction (TRI; TR2) being processed in cooperation with a terminal (T2; T3), the following steps: - reception (A20; A40), from the terminal, of an identifier (IDX2; IDX3) of said terminal; - consultation (A22; A42) of a first list (LT) of at least one terminal identifier (ID) to determine whether the identifier of said terminal (T2; T3) is included in said first list; and - processing (A24; A43) of the 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 recording 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 step (A22; A42) of consultation: - sending (A4; A44), to a remote server (SV1; SV3), of a data item (DN; IDX3) allowing the remote server to determine the location (LOC) of the electronic device; and - reception (A12; A54), in response to said sending, of 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 data 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 geographic 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 terminal is included in the list (LT2; LT3) d 'at least one terminal identifier, the processing step (A24; A43) of the transaction comprises the triggering of at least one predefined operation for securing the transaction. 7. Control method according to claim 6, in which said at least one predefined security operation comprises at least any one of: - sending (A26) of a request requesting the online processing of the current transaction; - recording (A38), in a history file, of a predefined history data; 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, in which the transaction (TRI; TR2) in progress is of EMV type and the identifier (IDX2; IDX3) of the terminal (T2; T3) is received in a GAC type EMV transaction message. 9. Control method according to claim 8, comprising: - reception (A12; A54), during the transaction in progress, of an order 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. Sending method implemented by a server (SV1; SV3), comprising the following steps: - reception (B6; B46) of a data (DN; IDX3) coming from an electronic device (Tl; CD) configured to cooperate with a terminal (T2; T3) to implement a transaction; - determination (B8; B48) of the location of the electronic device from said data; - selection (ΒΙΟ; B50), from the location of the electronic device, of a list (LT) of at least one terminal identifier (IDT); and - sending (B12; B52) of said list to the electronic device so as to configure the processing, by the electronic device, of a transaction. 11. The sending method according to claim 10, in which the data received is one of: - location data (DN) representative of the location of the electronic device; and - an identifier (IDX3) of a terminal with which the electronic device cooperates to process a transaction in progress. 12. Sending method according to 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. Computer program (PG1; PG2) comprising instructions for the execution of 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 (Tl; CD) comprising, during a transaction in progress with a terminal, the following steps: - a reception module (MD8) configured to receive, during a transaction in progress with a terminal, an identifier of said terminal; - a determination module (MD10) 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 (MD12) configured to process the transaction according to the result of the consultation of the first list by the consultation module. 15. Server (SV3) including: - a reception module (MD60) configured to receive data from an electronic device, said device being configured to cooperate with a terminal to implement a transaction; - a determination module (MD62) configured to determine the location of the electronic device from said data; - a selection module (MD64) 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 5 electronic device so as to configure the processing, by the electronic device, of a transaction. 1/5