EP3465584A1 - Procédé de sécurisation d'un dispositif electronique, et dispositif electronique correspondant - Google Patents

Procédé de sécurisation d'un dispositif electronique, et dispositif electronique correspondant

Info

Publication number
EP3465584A1
EP3465584A1 EP17729524.3A EP17729524A EP3465584A1 EP 3465584 A1 EP3465584 A1 EP 3465584A1 EP 17729524 A EP17729524 A EP 17729524A EP 3465584 A1 EP3465584 A1 EP 3465584A1
Authority
EP
European Patent Office
Prior art keywords
transaction
electronic device
time
current
period
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
EP17729524.3A
Other languages
German (de)
English (en)
Inventor
Francis Chamberot
Marco DE OLIVEIRA
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Idemia France SAS
Original Assignee
Idemia France SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Idemia France SAS filed Critical Idemia France SAS
Publication of EP3465584A1 publication Critical patent/EP3465584A1/fr
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4016—Transaction verification involving fraud or risk level assessment in transaction processing
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/12—Card verification

Definitions

  • the present invention is in the general field of electronic devices and more particularly relates to an electronic device, such as a smart card 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 aims in particular to secure a smart card operating according to the EMV protocol (for "Europay Mastercard Visa").
  • a smart card 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.
  • EMV is the standardized protocol used today mainly in the world to secure payment transactions made by smart cards.
  • the EMV protocol has been designed to reduce the risk of fraud during a payment transaction by allowing in particular the 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) by the cardholder.
  • PIN secret code
  • an EMV card can work online or offline.
  • 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.
  • the EMV card is operating in offline mode, it applies prerecorded verification criteria to decide whether the transaction should be allowed or denied.
  • Figure 1 shows an example of implementation of an EMV-compliant payment transaction using an EMV 100 chip card.
  • the EMV protocol is divided into three phases, although variants are possible.
  • a first phase intended to authenticate the smart card 100 used
  • the terminal 110 and the card 100 exchange a certain number of messages including a RESET message (RST) at S2 and then an ATR response at S4.
  • RST RESET message
  • ATR response at S4.
  • the carrier of the card selects via the terminal 110 the desired transaction mode, thereby triggering the sending of a "SELECT" command to the card 100 to initiate the start of the EMV transaction.
  • the EMV protocol proceeds to an authentication phase (not shown) of the cardholder 100.
  • the terminal 110 determines the authentication method of the bearer to be applied and determines in particular if the transaction must be performed in code verification mode or in non-code verification mode. If the code verification mode is selected, the smart card 100 verifies the validity of the PIN entered by the bearer on the terminal 110. If, on the other hand, the mode without code verification is selected, no PIN check is performed. performed.
  • the EMV protocol initiates the verification phase of the transaction.
  • the terminal 110 sends (S8) to the smart card 100 a first APDU command called GENERATE AC or GAC (noted here GAC1).
  • GAC GENERATE AC
  • This well-known order includes information about the current transaction such as the amount of the transaction, the currency used, the type of transaction, and so on.
  • the EMV card then performs (S9) a verification of the transaction according to predefined verification criteria and sends (S10), in response to the GAC1, a cryptogram (or cryptographic certificate) comprising a message authentication code (or MAC for " Message Authentication Code ").
  • the response of the card 100 in the ARQC message depends in particular on the setting of the card made by the issuing entity 120 (called "issuer") of said card.
  • the smart card 100 S10 sends a message type ARCQ ("Authorization Request Cryptogram") indicating that the card 100 wishes to continue the transaction online with, for example, a remote server of the transmitter 120 (online mode).
  • the cryptogram ARQC is transmitted by the terminal 110 to the transmitter 120 which can thus perform (S13) a number of checks to ensure that the transaction is valid.
  • the transmitter 120 then sends (S14), in response to the received ARCQ message, an encrypted message of the ARPC type indicating the decision of the transmitter 120.
  • This ARPC message is transmitted by the terminal 110 to the card 100 at S16.
  • the card 100 determines whether or not it accepts the transaction from the ARPC response received at S16.
  • the card 100 If the card 100 accepts the transaction, the latter sends (S18) in response a cryptogram of TC type (accepted transaction) to the terminal 110. In the opposite case, the card 100 sends (S18) a cryptogram of AAC type indicating the refusal of the transaction.
  • the online implementation of a transaction therefore makes it possible to implement security mechanisms that make it possible to identify risk situations and to trigger an appropriate security response.
  • the issuer of the smart card can for example detect abnormal behavior during an online transaction and decline the transaction or trigger additional verification checks.
  • EMV cards are typically configured to be able to perform a number of offline transactions, so that it is not possible for the card issuing entity to perform remote security checks in the course of time. the offline transaction. For example, certain EMV cards are configured to work offline if the amount of the current transaction does not reach a pre-defined minimum amount.
  • Smart cards especially EMVs, are therefore particularly vulnerable to malicious (or abnormal) attacks and behavior when they work offline.
  • the author of the flight can then carry out multiple successive transactions, all of which are on moderate amounts so as not to trigger the online operation of the card and thus escape the vigilance of the customer. the issuer of the card.
  • the present invention relates to a method of securing implemented by an electronic device, said method comprising:
  • risk analysis based on at least one historization data item recorded in the log file in association with each selected transaction, for detecting whether an abnormal use of said electronic device has occurred during said predefined period of time;
  • the predefined period of time is here a slippery period of time ending at the current point in time.
  • the present invention advantageously makes it possible to effectively protect electronic devices, in particular smart cards (of EMV or other type), configured to cooperate with a terminal to implement a transaction (a banking or other transaction).
  • the invention makes it possible in particular to secure such electronic devices against abnormal or suspicious behavior occurring during offline transactions.
  • the current point in time comprises at least one of the current date and the current time of the current transaction.
  • the determination of the current point comprises receiving, from a terminal with which the electronic device cooperates, a time data representative of the current point in time.
  • said selection comprises a computation of the point in time of the beginning of the predefined period of time, starting from the current point in time and a predefined duration attributed to said predefined period of time,
  • each selected transaction being subsequent to the point in time of the beginning of the predefined period of time.
  • the electronic device during said selection, the electronic device:
  • said at least one predefined first condition comprises at least one of the following conditions: - the reference transaction is a so-called “online transaction” that has been carried out in cooperation with an entity issuing the electronic device; and
  • the reference transaction is an online transaction that has been successfully authenticated by the issuing entity of the electronic device.
  • the electronic device filters the transactions recorded in the log file to select only each transaction satisfying at least a second predefined condition.
  • the second predefined condition comprises a condition on the type of the terminal with which the electronic device cooperated during said transaction.
  • the electronic device detects whether an abnormal use of said electronic device has occurred during said predefined period of time starting from at least one of:
  • the electronic device detects that abnormal use has occurred during said predefined period of time if at least one of the following three predefined conditions is satisfied:
  • the cumulative amount of each transaction selected during said selection reaches a second predefined threshold value.
  • said at least one security operation comprises at least one of:
  • the electronic device is a smart card.
  • the various steps of the security method are determined by instructions of computer programs. Consequently, the invention also aims at a computer program on an information medium (or recording medium), this program being capable of being implemented in an electronic device such as a smart card, this program comprising instructions adapted to the implementation of the steps of a security method as defined above.
  • This program can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other form desirable shape.
  • the invention also provides a computer-readable information carrier (or recording medium), and including instructions of a computer program as mentioned above.
  • the information carrier may be any entity or device capable of storing the program.
  • the medium may comprise storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording medium, for example a floppy disk or a disk. hard.
  • the information medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means.
  • the program according to the invention can be downloaded in particular on an Internet type network.
  • the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question.
  • the invention also relates to an electronic device comprising:
  • a determination module for determining a current point in time during which a current transaction is or must be implemented by the electronic device
  • a selection module for selecting, in a log file in which at least one transaction is recorded, at least one (or each) transaction implemented by said electronic device in a predefined period of time ending at the current point in the weather ;
  • a risk analysis module for detecting, from at least one historization data item recorded in the log file in association with each selected transaction, whether an abnormal use of said electronic device occurred during said period predefined time; and a security module configured, in the event of a positive result of said detection by the risk analysis module, for triggering a security operation of the electronic device in response to said current transaction.
  • the predefined period of time is here a slippery period of time ending at the current point in time.
  • the invention is implemented by means of software and / or hardware components.
  • module may correspond in this document as well to a software component, a hardware component or a set of hardware and software components.
  • the electronic device is a chip card, of the EMV type for example.
  • the smart card is in accordance with the ISO 7816 standard.
  • the electronic device comprises a memory in which the log file is saved.
  • FIG. 1 already described represents, in a schematic manner, a transaction implemented according to the EMV protocol
  • FIGS. 2A and 2B schematically represent a first mechanism for securing an EMV chip card
  • FIG. 3 schematically shows the structure of a smart card according to a particular embodiment of the invention
  • FIG. 4 schematically represents modules implemented in the smart card of FIG. 3, according to a particular embodiment of the invention.
  • FIG. 5 represents, in the form of a flowchart, the steps of a security method according to a particular embodiment of the invention.
  • FIG. 6 represents a log file according to a particular embodiment of the invention.
  • FIG. 7 schematically shows transactions implemented over time by the smart card of Figure 3, according to a particular embodiment
  • - Figure 8 shows, in the form of a flowchart, the steps of a securing method according to a particular embodiment of the invention.
  • the present invention relates to electronic devices, such as smart cards for example, configured to cooperate with an external terminal to perform a transaction, in the banking field for example.
  • the invention relates more particularly to the security of the configured smart cards, in particular when they are configured to process an offline transaction as explained above.
  • FIGS. 2A and 2B illustrate a first mechanism for securing an EMV chip card 130.
  • the smart card 130 is configured to calculate the cumulative amount of TR transactions that it has successfully performed during a fixed period of time CL, called "cycle", and then to check whether this cumulative amount reaches a certain amount. maximum threshold value.
  • This period of time CL begins at a fixed position (or point) DRef in time, called reference position in time, corresponding for example to the date of a given transaction TRI.
  • the CL time period also ends at a fixed position DF in time.
  • the EMV card 130 verifies, during the transaction TR4, the cumulative amount of the transactions TR1, TR2 and TR3 carried out previously during the same cycle CL, as well as the amount of the transaction TR4. Classes. If this accumulated amount reaches at least the maximum threshold value, the card 130 asks for example to continue in online mode. Subsequently, when the card 130 detects that a new transaction occurs after the instant DF, it resets the reference point DRef in order to initiate a new time cycle CL also fixed in time.
  • FIG. 2B illustrates an example in which the card 130 performs the transactions TR1 and TR2 during a first cycle CL1 and then initiates a new cycle CL2 in which it performs the transactions TR3 - TR5.
  • transaction TR5 for example, smart card 130 checks the cumulative amount of transactions TR3, TR4 and TR5 included in the transaction.
  • cycle CL2 but does not take into account the transactions TRI and TR2 because these were carried out during the previous cycle CL1.
  • the time distribution of the TRI - TR5 transactions over two distinct cycles CL1 - CL2 thus increases the risks that these offline transactions are not identified by the card 130 as constituting abnormal or suspicious behavior.
  • the invention proposes to overcome these disadvantages in particular by means of a security mechanism making it possible to effectively detect abnormal or suspicious behaviors, even when the smart card is operating offline, so that an appropriate security response can be brought if necessary.
  • the method of the invention implemented by an electronic device such as a smart card for example, comprises the following steps: determining a current point in time during which a current transaction is or must be implemented by the electronic device; selecting, in a log file in which at least one transaction is recorded, each transaction implemented by said electronic device in a predefined period of time ending at the current point in time; risk analysis, from at least one historian data recorded in the log file in association with each selected transaction, for detecting whether abnormal use of said electronic device has occurred during said predefined period of time; and, if so, initiating a secure operation of the electronic device in response to said current transaction.
  • the invention also relates to such an electronic device capable of implementing a security method as defined above.
  • EMV chip card examples of implementations of the invention are described in relation to an EMV chip card. It is understood that the invention is not limited exclusively to EMV cards but more generally applies to any electronic device configured to implement a transaction, including devices other than smart cards, this device can use the standard EMV or other transaction standards.
  • the electronic device of the invention is a smart card in accordance with the ISO 7816 standard.
  • 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 the context of a payment card configured to perform banking transactions. We will understand that other types of transactions or operations are possible within the scope of the invention.
  • FIG. 3 schematically represents the structure of a CD chip card according to a particular embodiment of the invention.
  • the smart card CD is configured to cooperate with a terminal (or reader) T to perform a transaction TR, such as a financial transaction or bank (payment transaction or otherwise) in this case.
  • a transaction TR such as a financial transaction or bank (payment transaction or otherwise) in this case.
  • the terminal T is configured to interface between the smart card CD and a remote server SV.
  • the server SV is a server of the issuing entity EM (Le., A banking institution for example) of the smart card CD.
  • the card CD is able to communicate, via the terminal T, with the remote server SV in order to implement, according to the EMV protocol, a so-called "online" transaction, that is to say involving a exchange with the EM issuer as already explained above.
  • the smart card CD comprises in this example external contacts 4 able to cooperate with the reader T, at least one processor 6, a rewritable volatile memory (of the RAM type) 8 and a rewritable non-volatile memory 10 (of type Flash for example).
  • the memory 10 constitutes in this example a recording medium (or information medium) according to a particular embodiment, readable by the smart card C2, and on which is recorded a computer program PG corresponding to a particular embodiment.
  • This computer program PG includes instructions for executing the steps of a security method according to a particular embodiment. The main steps of this method are shown, in particular embodiments of the invention, in Figures 5 and 8 described later.
  • the smart card CD complies with the ISO 7816 standard.
  • the external contacts 4 have characteristics in accordance with this standard. standard.
  • the smart card CD can for example cooperate with the reader T in contactless mode via an RF antenna integrated in the CD card.
  • a log file LG also called "Log” in English
  • at least one criterion (or parameter) CR predefined are stored in the rewritable non-volatile memory 10 of the CD card.
  • At least one transaction TR implemented in the past by the smart card CD is recorded in the log file LG.
  • at least one DLG history data is recorded in the log file LG.
  • a DLG logging datum is for example a transaction datum characterizing the corresponding transaction TR.
  • LG log file in which TR transactions (and, more particularly, historization data associated with these transactions) are recorded
  • terminals T may be, for example, automatic ticket machines (ATMs) and payment terminals, other types of terminals being possible.
  • ATMs automatic ticket machines
  • payment terminals other types of terminals being possible.
  • the CR criterion or criteria stored in the memory 10 may comprise at least one selection criterion CRI and / or at least one analysis criterion CR2. Criteria for selection and analysis CRI, CR2 configure, if necessary, how the card implements the method of the invention, as explained later.
  • the criteria CR stored in the memory 10 comprise two predefined conditions CD1 and CD2 each constituting a selection criterion CRI, as well as a condition CD3 constituting an analysis criterion CR2.
  • CD1 and CD2 each constituting a selection criterion CRI
  • condition CD3 constituting an analysis criterion CR2.
  • other exemplary embodiments are possible within the scope of the invention, the number and the nature of the selection criteria and the analysis criteria in particular being able to vary according to the use case.
  • the criteria CR and the log file LOG will be described in more detail below according to a particular embodiment with reference to FIGS. 4-9.
  • the processor 6 controlled by the computer program PG implements a number of modules shown in FIG. 4, namely: a determination module MD2, a selection module MD4, a module d MD6 analysis and an MD8 security module.
  • the determination module MD2 is configured to determine a point (or position) running in time, denoted by PC, during which a current transaction is, or must be, implemented by the smart card CD.
  • current point in time is meant a given moment in time when a current transaction is, or must be, implemented by the smart card CD.
  • a point in time can be defined for example by a date and / or a time, and more generally by any temporal data making it possible to define a given position in time.
  • the determination module MD2 determines the current point PC in time from a received temporal data, for example from the terminal T.
  • the smart card CD comprises a communication unit. calculation of the current date and / or time.
  • the selection module MD4 is configured to select, in the log file LG in which is recorded at least one transaction TR passed, each (or at least one) transaction TR implemented by the smart card CD in a predefined period (or window) of time (denoted PD) ending at the current point in the PC time. Since the period of time PD has a fixed duration, it moves in time so that it always ends at the current point in the time PC determined by the determination module MD2.
  • the predefined time period PD is a sliding time period whose end terminal is defined by the current point PC in the time determined by the determination module MD2. Whenever a new current point PC in time is determined by the determining module MD2, the period of time PD slides in time so that it always ends with the current point PC. Examples of embodiments will be described later with reference in particular to FIG.
  • the selection module MD4 is configured to select, among the transactions TR recorded in the log file LG, all the transactions TR that have been implemented in the predefined period of time PD. In a particular example, the selection module MD4 is configured to select, among the transactions TR recorded in the log file LG, the transactions TR which have been implemented in the predefined period of time PD and which also comply with minus one predefined selection criterion (or condition) CRI. These selection criteria CRI are for example recorded in the memory 10 of the CD card. As already indicated, Fig. 3 represents a particular example where the CRI selection criteria comprise two conditions CD1 and CD2.
  • the risk analysis module MD6 is configured to detect, from at least one DLG history data item recorded in the log file LG in association with each transaction TR selected by the selection module MD4, whether a use abnormal (or suspicious) of said CD card occurred during said predefined period of time PD.
  • abnormal use is meant here any use of the smart card CD deemed, according to at least one predefined analysis criterion, to be potentially at risk, fraudulent or abnormal.
  • the security module MD8 is configured, in case of a positive result of the detection by the risk analysis module MD6 (that is to say if an abnormal use of the CD card is detected by the MD6 analysis module), for triggering at least one security operation of the CD chip card in response to the current transaction TR.
  • Each security operation is configured to secure the smart card CD in response to the current transaction TR. Examples of such operations are described hereinafter with reference to FIGS. 5-9.
  • the smart card CD executes the computer program PG.
  • the smart card CD has initiated, in cooperation with the terminal T, the processing of a transaction TR, called the current transaction.
  • the current transaction TR has not yet been initiated.
  • the transaction TR conforms to the EMV protocol.
  • the smart card CD determines a current point PC in the time in which the current transaction TR is, or must be, implemented by the smart card CD.
  • This current point PC comprises for example at least one of the date (called current date) and time (known as current time) of the current transaction.
  • the smart card CD selects, in the log file LG in which is recorded at least one transaction TR passed, each (or at least one) transaction TR implemented by the smart card CD in a period of predefined PD time ending at the current PC point in time.
  • this PD period is a sliding time window, of predefined duration, whose end terminal is defined by the current position in PC time.
  • the duration of the period of time PD can in particular be adapted according to the desired configuration in view of the type of events or behaviors that it is desired to monitor at the level of the smart card CD.
  • the smart card CD then carries out in S34 a risk analysis (or a transaction analysis), from at least one DLG historization data item recorded in the log file LG in association with each TR transaction selected in S32. , to detect whether abnormal (or suspicious) use of the CD chip card has occurred during the predefined time period PD.
  • the smart card CD detects for example whether abnormal use of said CD card has occurred during the predefined PD period from at least one of:
  • the smart card CD detects that abnormal use has occurred during the predefined period PD if at least one of the following predefined conditions is satisfied:
  • the number of transactions selected during the selection S32 reaches at least a first predefined threshold value
  • the cumulative amount of each TR transaction selected during the selection S32 reaches at least a second predefined threshold value.
  • the smart card CD triggers in S36 at least one operation of securing the smart card CD in response to the current transaction TR.
  • Each security operation aims at securing the CD chip card vis-à-vis the current transaction TR, and more generally, vis-à-vis the use of the smart card CD over the PD period of time.
  • the number and nature of these security operations may vary depending on the use case.
  • said at least one security operation S36 comprises at least one of:
  • an operation parameter PR configures the manner in which the smart card CD processes a transaction TR with an external terminal, such as the reader T in this example.
  • the operating parameter PR to be modified may, for example, be a counter stored in the smart card CD. Such a counter can for example represent a number of offline transactions already performed by the smart card CD, or the cumulative amount of offline transactions already made by the smart card CD.
  • the parameter PR can moreover relate to a threshold value of such a counter.
  • the modification of the PR parameter may constitute an update of the configuration of the CD chip card causing a change in the processing of TR transactions by the smart card CD.
  • the smart card CD implements an example of a security method by executing the computer program PG.
  • FIG. 7 represents, along a time line, TRI-TR5 transactions that have been successively implemented in the past by the EMV chip card.
  • Figure 6 shows the recording of these transactions TRI to TR5 in the LG historian file of the smart card CD. More specifically, DLG logging data is stored in the LG log file in association with each TRI-TR5 transaction. This DLG history data characterizes the TRI - TR5 transactions that have already been implemented by the CD chip card.
  • the DLG history data recorded in the log file LG includes, in association with each referenced transaction TR, a transaction identifier ID, a point in time PT (for example a date and / or a time) where the transaction was carried out and an amount MT of the transaction, and possibly at least one of: a log data DN1 indicating whether the transaction was performed online or offline, a log data DN2 indicating whether the online authentication (or validation) by the emitter EM has been successfully passed in the case of an online transaction, and a log data item DN3 indicating the type of terminal T cooperating with the card CD during the transaction.
  • the types of terminals T possible, there may be mentioned for example ATMs (or ATMs) and payment terminals, other types of terminals being conceivable.
  • the chip card CD has initiated, in cooperation with the terminal T, the processing according to the EMV protocol of a new transaction TR6, called current transaction.
  • the smart card CD is for example inserted in the terminal T to allow communication by contact.
  • the smart card CD has received a first GENERATE AC APDU command, denoted GAC1, as already explained above with reference to step S8 in FIG. 1, and that the smart card CD implements the security method according to a particular embodiment of the invention in response to this command GAC1.
  • the security method is implemented at another stage of the EMV protocol.
  • the smart card CD implements the security method whereas the processing of the current transaction TR according to the EMV protocol has not yet been initiated.
  • Steps A4, A6, A12 and A14 described hereinafter with reference to FIG. 8 respectively correspond to steps S30, S32, S34 and S36, represented in FIG. 5, implemented in a particular embodiment of the invention.
  • the terminal T sends a time data DNT to the chip card CD which receives it at A2.
  • the time data DNT is representative of a current point PC in time.
  • This time data DNT may have any appropriate format and here includes for example the current date DC and the current time HC.
  • the chip card CD determines, from the time data DNT received at A2, the current point in time PC during which the current transaction TR6 must be implemented.
  • the current point PC is defined by the current date DC and the current time HC at the time of initiation of the EMV protocol between the smart card DC and the terminal T to implement the current transaction TR6.
  • Other techniques for determining the current date and / or time are possible, however.
  • the chip card CD selects (A6), in the log file LG, each transaction TR implemented by the smart card CD in the predefined period of time PD ending at the current point PC in the time determined in A4.
  • the time period PD is a time window of a predefined duration DT.
  • the value of DT can be adapted according to the desired purpose as explained later.
  • the smart card CD determines in this example the reference point in time, denoted PRef, corresponding to the beginning of the predefined period of time PD ( Figure 7).
  • the chip card CD calculates the reference point PRef in time from the current point PC in time and the predefined duration DT assigned to the time period PD. More precisely, the chip card CD calculates PRef such that:
  • PRef PC - DT
  • the reference point PRef includes the date and time of the beginning of the period of time PD.
  • the reference point PRef in time can correspond to a transaction previously implemented by the smart card CD.
  • the smart card CD selects (A10) then each transaction TR, recorded in the log file LG, which is later than the reference point PRef in time.
  • the selection A10 includes the transaction TR implemented, if necessary, at the reference point PRef in time (no transaction is recorded at the point PRef in this example).
  • the CD smart card determines when it was implemented
  • PT includes for example the date and / or time of the corresponding transaction TR.
  • the smart card CD selects in A10 the transactions
  • the chip card CD additionally selects the current transaction TR6 in A10, although variants are possible in which the current transaction TR is not selected in A10.
  • the chip card CD can also be configured to apply at least one selection criterion CRI to refine the selection made in A10.
  • the chip card CD determines for example in A10, from the log file LG, as reference transaction TRef, the most recent transaction TR in the period of time PD that satisfies the first predefined condition CD1.
  • the chip card CD selects in A10 only each TR transaction implemented by said CD card after the reference transaction TRef in the predefined period of time PD.
  • the first condition CD1 comprises at least one of the following conditions:
  • the TRef reference transaction is an online transaction that has been conducted in cooperation with the EM issuer;
  • ⁇ CD12 the TRef reference transaction is an online transaction carried out in cooperation with the EM issuer that has been successfully authenticated (or validated) by the EM issuer.
  • the chip card CD determines, for each transaction TR whose point in the time PT is subsequent to the reference transaction TRef, and from the associated data DN1, if said transaction TR is an online transaction.
  • the CD chip card determines, for each online transaction whose point in time PT is subsequent to the reference transaction TRef, and from the corresponding data DN2 in the LG history file, if said TR transaction has been successfully authenticated (or validated) by the EM issuer.
  • the smart card CD applies the condition CDU but not the condition CD12 at A10.
  • the smart card CD applies the condition CD12 above.
  • the CD chip card selects the transactions TR4 and TR5 in accordance with condition CD12 at A10.
  • the smart card CD can be configured to apply at least one selection criterion CRI to refine the selection made in A10.
  • the number and nature of CRI selection criteria may vary from case to case.
  • the smart card CD filters the transactions TR recorded in the log file LG to select only each transaction TR satisfying at least a second predefined condition CD2.
  • the second predefined condition CD2 includes a condition on the type of the terminal T with which the smart card CD cooperated during said transaction TR.
  • the log file LG records as log data DN3, for each transaction TR, whether said transaction was carried out in cooperation with a terminal T according to a first type TY1 or according to a second type TY2.
  • the states TY1 and TY2 respectively indicate that the terminal T is an automatic cash dispenser (ATM) and a payment terminal (a mobile terminal for example). If, for example, the condition CD2 is applied, the smart card CD excludes from the selection A10 the transactions TR which are in the predefined period PD and but do not satisfy the state TY1 (the transaction TR5 is therefore excluded in this example).
  • the smart card CD it will be understood that it is possible to configure the smart card CD to apply at least a first condition CD1 and / or at least a second condition CD2 as explained above.
  • the smart card CD applies the condition CDU and selects accordingly at A10 the transactions TR4 and TR5.
  • the smart card CD (more particularly the risk analysis module MD6) performs a risk analysis (or transaction analysis), based on the recorded DLG history data. in the LG history file in association with each TR transaction selected in A6 (ie TR4 and TR5 in this example), to detect whether abnormal (or suspicious) use of the CD chip card occurred during the period predefined time PD.
  • the CD chip card detects whether abnormal use of said CD card has occurred during the predefined time period PD from at least one of:
  • the smart card CD detects whether abnormal (or suspect) use has occurred during the predefined period PD according to at least one criterion CR2, recorded in this example in the memory 10.
  • the smart card CD applies, as analysis criteria CR2, the following predefined conditions CD3:
  • the smart card CD detects that abnormal or suspect use has occurred during the predefined period of time PD if the conditions CD32 and CD32 are satisfied.
  • the values Lmaxl and Lmax2 are set according to the needs of the case.
  • only one of the predefined conditions CD31 and CD32 is applied by the chip card CD during the analysis A12.
  • the smart card CD resumes for example a normal processing of the transaction according to the EMV protocol.
  • the smart card CD triggers in A14 at least one operation of securing the smart card CD in response to the current transaction TR6.
  • Each security operation is configured to secure the CD chip card vis-à-vis the current transaction TR, and more generally, vis-à-vis the use made of the CD chip card over the PD period of time. The number and nature of these security operations may vary depending on the use case.
  • the smart card CD carries out in A14 at least one of the following security operations:
  • the terminal T may optionally transmit (B17) the message MSG1 to the remote server SV so that the sender SV is informed of the abnormal or suspicious use detected by the smart card CD;
  • a PR operation parameter configures how the CD chip card processes a TR transaction with the terminal T.
  • the CD chip CD sends for example a refusal message MSG2 which is received by the terminal T in B22.
  • a smart card according to the invention is thus capable of storing in memory memory data relating to transactions processed by said card over time. From this historization data, the smart card can then analyze the use that is made of the card in a relevant time window, namely a time window corresponding here to a period of time immediately preceding the transaction. In progress. It is thus possible to take into account all relevant transactions for each analysis made by the smart card, without there being a risk that certain transactions are excluded from the analysis as is the case for example in the mechanism security described above with reference to Figures 2A and 2B.
  • abnormal behavior of the authentic carrier for example a number and / or a cumulative amount of abnormal or suspicious expenditure
  • the invention makes it possible to better control the use of a smart card, of EMV type in particular, even when it operates offline.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Accounting & Taxation (AREA)
  • Theoretical Computer Science (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Computer Security & Cryptography (AREA)
  • Finance (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Telephone Function (AREA)

Abstract

L'invention propose un procédé de sécurisation mis en œuvre par un dispositif électronique (CD), le procédé comprenant : une détermination d'un point courant dans le temps au cours duquel une transaction courante est mise en œuvre; une sélection, dans un fichier d'historisation (LG) dans lequel est enregistrée au moins une transaction passée, de chaque transaction mise en œuvre par ledit dispositif électronique (CD) dans une période de temps prédéfinie terminant au point courant dans le temps; une analyse de risque, à partir d'au moins une donnée d'historisation enregistrée dans le fichier d'historisation en association avec chaque transaction sélectionnée, pour détecter si une utilisation anormale du dispositif électronique (CD) s'est produite pendant ladite période de temps prédéfinie; et dans l'affirmative, un déclenchement d'au moins une opération de sécurisation du dispositif électronique (CD) en réponse à ladite transaction courante.

Description

Procédé de sécurisation d'un dispositif électronique, et dispositif électronique correspondant.
Arrière-plan de l'invention
La présente invention se situe dans le domaine général des dispositifs électroniques et concerne plus particulièrement un dispositif électronique, tel qu'une carte à puce par exemple, configurée pour coopérer avec un terminal externe pour réaliser une transaction, dans le domaine bancaire par exemple.
L'invention s'applique plus particulièrement, mais de manière non exclusive, aux cartes à puce (ou cartes à microcircuit), conformes par exemple à la norme IS07816. L'invention vise notamment la sécurisation d'une carte à puce fonctionnant selon le protocole EMV (pour « Europay Mastercard Visa »).
De manière générale, une carte à puce est conçue pour communiquer avec un dispositif externe à cette carte, autrement appelé terminal ou lecteur. Ces cartes permettent d'effectuer divers types de transactions, telles que par exemple des transactions de paiement, de prélèvement ou encore d'authentification du porteur. Les cartes à puce pour applications bancaires (carte de crédit, carte de débit etc.), par exemple, sont aptes à coopérer avec des terminaux de paiement ou des distributeurs automatiques de billets (DAB) pour réaliser divers opérations financières.
EMV est le protocole standardisé utilisé aujourd'hui majoritairement dans le monde pour sécuriser notamment les transactions de paiement effectuées par des cartes à puce.
Le protocole EMV a été conçu pour diminuer les risques de fraudes lors d'une transaction de paiement en permettant notamment l'authentification à la fois de la carte à puce et de son porteur. Ce processus d'authentification fait appel à une combinaison de cryptogrammes (ou clés cryptées) et de signatures numériques et nécessite éventuellement la saisie d'un code secret (appelé communément code PIN) par le porteur de la carte.
Suivant le type de carte utilisé, la situation, ou encore le montant considéré, une carte EMV peut fonctionner en ligne ou hors ligne. En mode en ligne, la carte EMV peut communiquer, via le lecteur, avec l'entité émettrice correspondante (la banque à l'origine de la carte, par exemple) afin de vérifier en particulier que la transaction en cours est légitime. En revanche, si la carte EMV fonctionne en mode hors ligne, celle-ci applique des critères de vérification préenregistrés pour décider si la transaction doit être autorisée ou refusée. La figure 1 représente un exemple de mise en œuvre d'une transaction de paiement conforme au protocole EMV, à l'aide d'une carte à puce EMV 100. Certains aspects d'une transaction EMV ont été omis par souci de simplicité.
Lors de la mise en œuvre d'une transaction, le protocole EMV s'articule en trois phases, des variantes étant toutefois possibles. Lors d'une première phase destinée à authentifier la carte à puce 100 utilisée, le terminal 110 et la carte 100 s'échangent un certain nombre de messages dont un message RESET (RST) en S2 puis une réponse ATR en S4. En S6, le porteur de la carte sélectionne via le terminal 110 le mode de transaction souhaité, déclenchant ainsi l'envoi d'une commande « SELECT » à la carte 100 afin d'initier le début de la transaction EMV.
Une fois la phase d'authentification de carte achevée, le protocole EMV procède à une phase d'authentification (non représentée) du porteur de la carte 100. Le terminal 110 détermine le procédé d'authentification du porteur à appliquer et détermine en particulier si la transaction doit être effectuée en mode avec vérification de code ou en mode sans vérification de code. Si le mode avec vérification de code est sélectionné, la carte à puce 100 vérifie la validité du code PIN saisi par le porteur sur le terminal 110. Si en revanche le mode sans vérification de code est sélectionné, aucune vérification de code PIN n'est réalisée.
Une fois la phase d'authentification du porteur achevée, le protocole EMV initie la phase de vérification de la transaction. Pour ce faire, le terminal 110 envoie (S8) à la carte à puce 100 une première commande APDU dite GENERATE AC ou GAC (notée ici GAC1). Cette commande bien connue comprend des informations sur la transaction en cours telles que le montant de la transaction, la devise utilisée, le type de transaction, etc. La carte EMV réalise (S9) alors une vérification de la transaction selon des critères de vérification prédéfinis puis envoie (S10), en réponse au GAC1, un cryptogramme (ou certificat cryptographique) comprenant un code d'authentification de message (ou MAC pour « Message Authentification Code » en anglais). La réponse de la carte 100 dans le message ARQC dépend notamment du paramétrage de la carte effectué par l'entité émettrice 120 (dit « émetteur ») de ladite carte.
Si le mode en ligne est choisi, comme représenté dans l'exemple de la figure 1, la carte à puce 100 envoie en S10 un message de type ARCQ (« Autorisation Request Cryptogram ») indiquant que la carte 100 souhaite poursuivre la transaction en ligne avec, par exemple, un serveur distant de l'émetteur 120 (mode en ligne). Le cryptogramme ARQC est transmis par le terminal 110 à l'émetteur 120 qui peut ainsi réaliser (S13) un certain nombre de vérifications afin de s'assurer que la transaction est valide. L'émetteur 120 envoie (S14) ensuite, en réponse au message ARCQ reçu, un message crypté de type ARPC indiquant la décision de l'émetteur 120. Ce message ARPC est transmis par le terminal 110 à la carte 100 en S16. La carte 100 détermine si elle accepte ou non la transaction à partir de la réponse ARPC reçue en S16. Si la carte 100 accepte la transaction, celle-ci envoie (S18) en réponse un cryptogramme de type TC (transaction acceptée) au terminal 110. Dans le cas contraire, la carte 100 envoie (S18) un cryptogramme de type AAC indiquant le refus de la transaction.
La réalisation en ligne d'une transaction permet donc de mettre en œuvre des mécanismes de sécurité permettant d'identifier des situations à risque et de déclencher une réponse sécuritaire appropriée. L'émetteur de la carte à puce peut par exemple détecter un comportement anormal lors d'une transaction en ligne et décliner la transaction ou déclencher des contrôles de vérification supplémentaires.
Les cartes EMV actuelles sont généralement configurées de façon à pouvoir réaliser un certain nombre de transaction hors ligne, de sorte qu'il n'est pas possible pour l'entité émettrice de la carte d'effectuer de contrôle de sécurité à distance au cours de la transaction hors ligne. Certaines cartes EMV sont par exemple configurées pour fonctionner hors ligne si le montant de la transaction en cours n'atteint pas un montant minimum prédéfini.
Les cartes à puce, EMV notamment, sont donc particulièrement vulnérables aux attaques et comportement malveillants (ou anormaux) lorsqu'elles fonctionnent hors ligne. En cas par exemple de vol d'une carte EMV, l'auteur du vol peut alors réaliser de multiples transactions successives portant toutes sur des montants modérés de sorte à ne pas déclencher le fonctionnement en ligne de la carte et ainsi échapper à la vigilance de l'émetteur de la carte.
Il existe donc aujourd'hui un besoin pour un mécanisme de sécurité permettant de protéger efficacement les cartes à puce, par exemple de type EMV, contre les comportements anormaux et/ou suspects survenant notamment lors des transactions hors ligne. Une sécurisation renforcée est en particulier nécessaire pour protéger les cartes à puce contre les utilisations frauduleuses, en cas de vol par exemple. Un besoin existe plus généralement pour mieux contrôler l'utilisation d'un dispositif électronique tel qu'une carte à puce par exemple (de type EMV ou autre), y compris lorsque ce dispositif fonctionne hors ligne pour mettre en œuvre une transaction.
Objet et résumé de l'invention
A cet effet, la présente invention concerne un procédé de sécurisation mis en œuvre par un dispositif électronique, ledit procédé comprenant :
- détermination d'un point courant dans le temps au cours duquel une transaction courante est ou doit être mise en œuvre par le dispositif électronique ;
- sélection, dans un fichier d'historisation dans lequel est enregistrée au moins une transaction passée, d'au moins une (ou de chaque) transaction mise en œuvre par ledit dispositif électronique dans une période de temps prédéfinie terminant au point courant dans le temps ;
- analyse de risque, à partir d'au moins une donnée d'historisation enregistrée dans le fichier d'historisation en association avec chaque transaction sélectionnée, pour détecter si une utilisation anormale dudit dispositif électronique s'est produite pendant ladite période de temps prédéfinie ; et
- dans l'affirmative, déclenchement d'au moins une opération de sécurisation du dispositif électronique en réponse à ladite transaction courante
La période de temps prédéfinie est ici une période de temps glissante se terminant au point courant dans le temps.
La présente invention permet avantageusement de protéger de façon efficace les dispositifs électroniques, notamment les cartes à puce (de type EMV ou autre), configurés pour coopérer avec un terminal pour mettre en œuvre une transaction (une transaction bancaire ou autre).
L'invention permet en particulier de sécuriser de tels dispositifs électroniques contre les comportements anormaux ou suspects survenant lors des transactions hors ligne.
Selon un mode de réalisation particulier, le point courant dans le temps comprend au moins l'un parmi la date courante et l'heure courante de la transaction courante.
Selon un mode de réalisation particulier, la détermination du point courant comprend une réception, depuis un terminal avec lequel coopère le dispositif électronique, d'une donnée temporelle représentative du point courant dans le temps.
Selon un mode de réalisation particulier, ladite sélection comprend un calcul du point dans le temps du début de la période de temps prédéfinie, à partir du point courant dans le temps et d'une durée prédéfinie attribuée à ladite période de temps prédéfinie,
chaque transaction sélectionnée étant postérieure au point dans le temps du début de la période de temps prédéfinie.
Selon un mode de réalisation particulier, lors de ladite sélection, le dispositif électronique :
- détermine, à partir du fichier d'historisation, en tant que transaction de référence, la transaction la plus récente dans la période de temps prédéfinie qui satisfait au moins une première condition prédéfinie ; et
- sélectionne uniquement chaque transaction mise en œuvre par ledit dispositif électronique postérieurement à ladite transaction de référence dans la période de temps prédéfinie.
Selon un mode de réalisation particulier, ladite au moins une première condition prédéfinie comprend au moins l'une des conditions suivantes : - la transaction de référence est une transaction dite « en ligne » ayant été réalisée en coopération avec une entité émettrice du dispositif électronique ; et
- la transaction de référence est une dite transaction en ligne qui a été authentifiée avec succès par l'entité émettrice du dispositif électronique.
Selon un mode de réalisation particulier, lors de ladite sélection, le dispositif électronique filtre les transactions enregistrées dans le fichier d'historisation pour ne sélectionner que chaque transaction satisfaisant au moins une deuxième condition prédéfinie.
Selon un mode de réalisation particulier, la deuxième condition prédéfinie comprend une condition sur le type du terminal avec lequel le dispositif électronique a coopéré lors de ladite transaction.
Selon un mode de réalisation particulier, lors de ladite analyse de risque, le dispositif électronique détecte si une utilisation anormale dudit dispositif électronique s'est produite pendant ladite période de temps prédéfinie à partir d'au moins l'un parmi :
- le nombre de transactions sélectionnées ; et
- le montant cumulé de chaque transaction sélectionnée.
Selon un mode de réalisation particulier, dans lequel, lors de ladite analyse de risque, le dispositif électronique détecte qu'une utilisation anormale s'est produite pendant ladite période de temps prédéfinie si au moins l'une des troisièmes conditions prédéfinies suivantes est satisfaite :
- le nombre de transactions sélectionnées lors de ladite sélection atteint une première valeur seuil prédéfinie ; et
- le montant cumulé de chaque transaction sélectionnée lors de ladite sélection atteint une deuxième valeur seuil prédéfinie.
Selon un mode de réalisation particulier, ladite au moins une opération de sécurisation comprend au moins l'un parmi :
- envoi d'un message informant de ladite utilisation anormale détectée ;
- modification d'au moins un paramètre de fonctionnement du dispositif électronique ;
- enregistrement, dans le fichier d'historisation, d'une donnée de sécurité représentative de ladite utilisation anormale détectée ; et
- refus de mettre en œuvre ladite transaction courante.
Selon un mode de réalisation particulier, le dispositif électronique est une carte à puce.
Dans un mode particulier de réalisation, les différentes étapes du procédé de sécurisation sont déterminées par des instructions de programmes d'ordinateurs. En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations (ou support d'enregistrement), ce programme étant susceptible d'être mis en œuvre dans un dispositif électronique tel qu'une carte à puce, ce programme comportant des instructions adaptées à la mise en œuvre des étapes d'un procédé de sécurisation tel que défini ci-dessus.
Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
L'invention vise aussi un support d'informations (ou support d'enregistrement) lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus.
Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy dise) ou un disque dur.
D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.
L'invention concerne également un dispositif électronique comprenant :
- un module de détermination pour déterminer un point courant dans le temps au cours duquel une transaction courante est ou doit être mise en œuvre par le dispositif électronique ;
- un module de sélection pour sélectionner, dans un fichier d'historisation dans lequel est enregistrée au moins une transaction passée, au moins une (ou chaque) transaction mise en œuvre par ledit dispositif électronique dans une période de temps prédéfinie terminant au point courant dans le temps ;
- un module d'analyse de risque pour détecter, à partir d'au moins une donnée d'historisation enregistrée dans le fichier d'historisation en association avec chaque transaction sélectionnée, si une utilisation anormale dudit dispositif électronique s'est produite pendant ladite période de temps prédéfinie ; et - un module de sécurisation configuré, en cas de résultat positif de ladite détection par le module d'analyse de risque, pour déclencher une opération de sécurisation du dispositif électronique en réponse à ladite transaction courante.
La période de temps prédéfinie est ici une période de temps glissante se terminant au point courant dans le temps.
Selon un mode de réalisation particulier, l'invention est mise en œuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme « module » peut correspondre dans ce document aussi bien à un composant logiciel, qu'à un composant matériel ou à un ensemble de composants matériels et logiciels.
Selon un mode de réalisation particulier, le dispositif électronique est une carte à puce, de type EMV par exemple. Dans un exemple particulier, la carte à puce est conforme à la norme ISO 7816.
Selon un mode de réalisation particulier, le dispositif électronique comprend une mémoire dans laquelle est enregistré le fichier d'historisation.
On notera que les différents modes de réalisation mentionnés ci-avant en relation avec le procédé de sécurisation de l'invention ainsi que les avantages associés s'appliquent de façon analogue au dispositif électronique de l'invention.
Brève description des dessins
D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent des exemples de réalisation dépourvus de tout caractère limitatif. Sur les figures:
- la figure 1 déjà décrite représente, de manière schématique, une transaction mise en œuvre selon le protocole EMV ;
- les figures 2A et 2B représentent schématiquement un premier mécanisme de sécurisation d'une carte à puce EMV ;
- la figure 3 représente schématiquement la structure d'une carte à puce conforme à un mode de réalisation particulier de l'invention ;
- la figure 4 représente schématiquement des modules mis en œuvre dans la carte à puce de la figure 3, selon à un mode de réalisation particulier de l'invention ;
- la figure 5 représente, sous forme d'un organigramme, les étapes d'un procédé de sécurisation selon un mode de réalisation particulier de l'invention ;
- la figure 6 représente un fichier d'historisation selon un mode de réalisation particulier de l'invention ;
- la figure 7 représente schématiquement des transactions mises en œuvre au fil du temps par la carte à puce de la figure 3, selon un exemple de réalisation particulier ; et - la figure 8 représente, sous forme d'un organigramme, les étapes d'un procédé de sécurisation selon un mode de réalisation particulier de l'invention.
Description détaillée de plusieurs modes de réalisation
Comme indiqué précédemment, la présente invention concerne les dispositifs électroniques, tels que les cartes à puce par exemple, configurés pour coopérer avec un terminal externe pour réaliser une transaction, dans le domaine bancaire par exemple.
L'invention porte plus particulièrement sur la sécurisation des cartes à puce configurées, en particulier lorsque celles-ci sont configurées pour traiter une transaction hors ligne comme expliqué précédemment.
Les figures 2A et 2B illustrent un premier mécanisme de sécurisation d'une carte à puce 130 de type EMV. Dans cet exemple, la carte à puce 130 est configurée pour calculer le montant cumulé de transactions TR qu'elle a réalisées avec succès lors d'une période de temps fixe CL, appelée « cycle », puis pour vérifier si ce montant cumulé atteint une valeur seuil maximale. Cette période de temps CL débute à une position (ou point) fixe DRef dans le temps, dite position de référence dans le temps, correspondant par exemple à la date d'une transaction TRI donnée. La période de temps CL se termine également à une position fixe DF dans le temps.
Dans l'exemple illustré en figure 1A, la carte EMV 130 vérifie, au cours de la transaction TR4, le montant cumulé des transactions TRI, TR2 et TR3 réalisées précédemment au cours du même cycle CL, ainsi que le montant de la transaction TR4 en cours. Si ce montant cumulé atteint au moins la valeur seuil maximale, la carte 130 demande par exemple à poursuivre en mode en ligne. Par la suite, lorsque la carte 130 détecte qu'une nouvelle transaction se produit après l'instant DF, elle réinitialise le point de référence DRef afin d'initier un nouveau cycle de temps CL lui aussi fixe dans le temps.
Cette technique présente toutefois un inconvénient en ce qu'il n'est pas toujours possible de détecter notamment une augmentation importante, potentiellement anormale, des montants des transactions.
Comme illustré en figure 2B, on suppose par exemple que la carte à puce 130 est volée à l'instant V et que l'auteur du vol réalise des transactions successives TRI - TR5 dans un intervalle de temps relativement restreint. Dans l'hypothèse où le montant de chaque transaction reste inférieur au seuil maximal autorisé en mode hors ligne, il n'est pas certain que la carte 130 soit capable de détecter le comportement anormal résultant du vol, et ce malgré le mécanisme de sécurité décrit en référence à la figure 2A.
La figure 2B illustre un exemple dans lequel la carte 130 réalise les transactions TRI et TR2 lors d'un premier cycle CLl puis initie un nouveau cycle CL2 au cours duquel elle réalise les transactions TR3 - TR5. Au cours de la transaction TR5, par exemple, la carte à puce 130 vérifie le montant cumulé des transactions TR3, TR4 et TR5 incluses dans le cycle CL2 mais ne prend pas en compte les transactions TRI et TR2 du fait que ces dernières ont été réalisées lors du cycle précédent CL1. La distribution dans le temps des transactions TRI - TR5 sur deux cycles distincts CL1 - CL2 augmente ainsi les risques que ces transactions hors lignes ne soient pas identifiées par la carte 130 comme constituant un comportement anormal ou suspect.
L'invention propose de palier notamment ces inconvénients à l'aide d'un mécanisme de sécurité permettant de détecter efficacement des comportements anormaux ou suspects, y compris lorsque la carte à puce fonctionne en mode hors ligne, de sorte qu'une réponse sécuritaire appropriée puisse être apportée si nécessaire.
Selon différents modes de réalisation, le procédé de l'invention, mis en œuvre par un dispositif électronique tel qu'une carte à puce par exemple, comprend les étapes suivantes : détermination d'un point courant dans le temps au cours duquel une transaction courante est ou doit être mise en œuvre par le dispositif électronique ; sélection, dans un fichier d'historisation dans lequel est enregistrée au moins une transaction passée, de chaque transaction mise en œuvre par ledit dispositif électronique dans une période de temps prédéfinie terminant au point courant dans le temps ; analyse de risque, à partir d'au moins une donnée d'historisation enregistrée dans le fichier d'historisation en association avec chaque transaction sélectionnée, pour détecter si une utilisation anormale dudit dispositif électronique s'est produite pendant ladite période de temps prédéfinie ; et, dans l'affirmative, déclenchement d'une opération de sécurisation du dispositif électronique en réponse à ladite transaction courante.
L'invention porte également sur un tel dispositif électronique apte à mettre en œuvre un procédé de sécurisation comme défini ci-dessus.
D'autres aspects et avantages de la présente invention ressortiront des exemples de réalisation décrits ci-dessous en référence aux dessins mentionnés ci-avant.
Dans le présent exposé, des exemples de mises en œuvre de l'invention sont décrits en relation avec une carte à puce de type EMV. On comprend que l'invention ne se limite par exclusivement aux cartes EMV mais s'applique plus généralement à tout dispositif électronique configuré pour mettre en œuvre une transaction, y compris des dispositifs autre que des cartes à puce, ce dispositif pouvant utiliser le standard EMV ou d'autres standards de transaction.
Dans un exemple particulier, le dispositif électronique de l'invention est une carte à puce conforme à la norme ISO 7816.
A noter également que la notion de transaction est ici entendue au sens large et comprend par exemple, dans le domaine bancaire, aussi bien une transaction de paiement ou de transfert que d'une consultation d'un compte bancaire sur un terminal bancaire. Les divers modes de réalisation de l'invention sont ici décrits dans le cadre d'une carte de paiement configurée pour réaliser des transactions bancaires. On comprendra que d'autres types de transactions ou opérations sont envisageables dans le cadre de l'invention.
Sauf indications contraires, les éléments communs ou analogues à plusieurs figures portent les mêmes signes de référence et présentent des caractéristiques identiques ou analogues, de sorte que ces éléments communs ne sont généralement pas à nouveau décrits par souci de simplicité.
La figure 3 représente, de manière schématique, la structure d'une carte à puce CD, conforme à un mode de réalisation particulier de l'invention.
On comprendra que certains éléments généralement présents dans une carte à puce ont été volontairement omis car ils ne sont pas nécessaires à la compréhension de la présente invention. A noter également que la carte à puce CD représentée en figure 3 ne constitue qu'un exemple de réalisation, d'autres mises en œuvre étant possibles dans le cadre de l'invention. L'homme du métier comprendra en particulier que certains éléments de la carte à puce CD ne sont décrits ici que pour faciliter la compréhension de l'invention, ces éléments n'étant pas nécessaires pour mettre en œuvre l'invention.
La carte à puce CD est configurée pour coopérer avec un terminal (ou lecteur) T afin de réaliser une transaction TR, telle qu'une transaction financière ou bancaire (transaction de paiement ou autre) dans le cas présent.
Le terminal T est configuré pour faire l'interface entre la carte à puce CD et un serveur distant SV. Dans le cas présent, le serveur SV est un serveur de l'entité émettrice EM (Le., une institution bancaire par exemple) de la carte à puce CD. Dans cet exemple, la carte CD est apte à communiquer, via le terminal T, avec le serveur distant SV afin de mettre en œuvre, selon le protocole EMV, une transaction dite « en ligne », c'est-à-dire impliquant un échange avec l'émetteur EM comme déjà expliqué ci-avant.
Plus précisément, la carte à puce CD comprend dans cet exemple des contacts externes 4 aptes à coopérer avec le lecteur T, au moins un processeur 6, une mémoire volatile réinscriptible (de type RAM) 8 et une mémoire non volatile réinscriptible 10 (de type Flash par exemple).
La mémoire 10 constitue dans un cet exemple un support d'enregistrement (ou support d'informations) conforme à un mode de réalisation particulier, lisible par le la carte à puce C2, et sur lequel est enregistré un programme d'ordinateur PG conforme à un mode de réalisation particulier. Ce programme d'ordinateur PG comporte des instructions pour l'exécution des étapes d'un procédé de sécurisation selon un mode de réalisation particulier. Les principales étapes de ce procédé sont représentées, dans des modes de réalisation particuliers de l'invention, sur les figures 5 et 8 décrites ultérieurement.
Dans un exemple particulier, la carte à puce CD est conforme à la norme ISO 7816. Dans ce cas, les contacts externes 4 présentent des caractéristiques conformes à cette norme. On comprendra toutefois que d'autres modes de réalisation sont possibles. La carte à puce CD peut par exemple coopérer avec le lecteur T en mode sans contact via une antenne RF intégrée dans la carte CD.
Toujours dans l'exemple considéré ici, un fichier d'historisation LG (appelé aussi « Log » en anglais) et au moins un critère (ou paramètre) CR prédéfini sont enregistrés dans la mémoire non volatile réinscriptible 10 de la carte CD.
Dans cet exemple, au moins une transaction TR mise en œuvre dans le passé par la carte à puce CD est enregistrée dans le fichier d'historisation LG. En association avec chaque transaction TR, au moins une donnée d'historisation DLG est enregistrée dans le fichier d'historisation LG. Une donnée d'historisation DLG est par exemple une donnée de transaction caractérisant la transaction TR correspondante. Ce fichier d'historisation LG permet à la carte CD de garder en mémoire des données DLG utiles concernant les transactions qu'elle réalise, ces informations pouvant ensuite si besoin être consultées, traitées et/ou envoyées par la carte CD.
Un exemple particulier d'un tel fichier d'historisation LG dans lequel sont enregistrées des transactions TR (et, plus particulièrement, des données d'historisation associées à ces transactions) est décrit ultérieurement en référence à la figure 6. Les données d'historisation DLG pouvant être enregistrées dans le fichier d'historisation LG comprennent par exemple au moins l'un parmi : un identifiant de transaction ID, un point dans le temps PT (par exemple une date et/ou une heure) caractérisant à quel moment la transaction a été réalisée, un montant MT de la transaction, une donnée d'historisation DN1 indiquant si la transaction a été réalisée en ligne ou hors ligne, une donnée d'historisation DN2 indiquant si l'authentification (ou validation) en ligne par l'émetteur EM a été passée avec succès dans le cas d'une transaction en ligne, et une donnée d'historisation DN3 indiquant le type de terminal T ayant coopéré avec la carte CD lors de la transaction. Parmi les types de terminaux T possibles, on peut citer par exemple les distributeurs automatiques de billets (ou DAB) et les terminaux de paiement, d'autres types de terminaux étant possibles.
Par ailleurs, le ou les critères CR enregistrés dans la mémoire 10 peuvent comprendre au moins un critère de sélection CRI et/ou au moins un critère d'analyse CR2. Les critères de sélection et d'analyse CRI, CR2 configurent, le cas échéant, la manière dont la carte met en œuvre le procédé de l'invention, comme expliqué ultérieurement. Dans l'exemple représenté en figure 3, les critères CR enregistrés dans la mémoire 10 comprennent deux conditions prédéfinies CD1 et CD2 constituant chacune un critère de sélection CRI, ainsi qu'une condition CD3 constituant un critère d'analyse CR2. Comme déjà indiqué, d'autres exemples de réalisation sont possibles dans le cadre de l'invention, le nombre et la nature des critères de sélection et des critères d'analyse notamment pouvant varier selon le cas d'usage. Les critères CR et le fichier d'historisation LOG seront décrits plus en détail ci-après selon un exemple de réalisation particulier en référence aux figures 4-9.
Dans un mode de réalisation particulier, le processeur 6 piloté par le programme d'ordinateur PG, met en œuvre un certain nombre de modules représentés en figure 4, à savoir : un module de détermination MD2, un module de sélection MD4, un module d'analyse MD6 et un module de sécurisation MD8.
Dans cet exemple particulier, le module de détermination MD2 est configuré pour déterminer un point (ou position) courant dans le temps, noté PC, au cours duquel une transaction courante est, ou doit être, mise en œuvre par la carte à puce CD. Par « point courant dans le temps », on entend un instant donné dans le temps où une transaction courante est, ou doit être, mise en œuvre par la carte à puce CD. Un point dans le temps peut être défini par exemple par une date et/ou une heure, et plus généralement par toutes données temporelles permettant de définir une position donnée dans le temps.
Différentes méthodes peuvent être utilisées pour permettre à la carte CD de déterminer le point courant PC dans le temps au cours duquel une transaction courante est, ou doit être, mises en œuvre par la carte CD. Dans un exemple décrit plus en détail ultérieurement, le module de détermination MD2 détermine le point courant PC dans le temps à partir d'une donnée temporelle reçue, provenant par exemple du terminal T. En variante, la carte à puce CD comprend une unité de calcul de la date et/ou de l'heure courante.
Dans cet exemple particulier, le module de sélection MD4 est configuré pour sélectionner, dans le fichier d'historisation LG dans lequel est enregistrée au moins une transaction TR passée, chaque (ou au moins une) transaction TR mise en œuvre par la carte à puce CD dans une période (ou fenêtre) de temps prédéfinie (notée PD) terminant au point courant dans le temps PC. La période de temps PD ayant une durée fixe, elle se déplace dans le temps de sorte à ce qu'elle se termine toujours au point courant dans le temps PC déterminé par le module de détermination MD2. Autrement dit, la période de temps prédéfinie PD est une période de temps glissante dont la borne de fin est définie par le point courant PC dans le temps déterminé par le module de détermination MD2. A chaque fois qu'un nouveau point courant PC dans le temps est déterminé par le module de détermination MD2, la période de temps PD glisse dans le temps de sorte à ce qu'elle se termine toujours par le point courant PC. Des exemples de réalisation seront décrits ultérieurement en référence notamment à la figure 6.
Dans un exemple particulier, le module de sélection MD4 est configuré pour sélectionner, parmi les transactions TR enregistrées dans le fichier d'historisation LG, toutes les transactions TR qui ont été mises en œuvre dans la période de temps prédéfinie PD. Dans un exemple particulier, le module de sélection MD4 est configuré pour sélectionner, parmi les transactions TR enregistrées dans le fichier d'historisation LG, les transactions TR qui ont été mises en œuvre dans la période de temps prédéfinie PD et qui respectent en outre au moins un critère (ou condition) de sélection prédéfini CRI. Ces critères de sélection CRI sont par exemple enregistrés dans la mémoire 10 de la carte CD. Comme déjà indiqué, la figue 3 représente un exemple particulier où les critères de sélection CRI comprennent deux conditions CD1 et CD2.
Le module d'analyse de risque MD6 est configuré pour détecter, à partir d'au moins une donnée d'historisation DLG enregistrée dans le fichier d'historisation LG en association avec chaque transaction TR sélectionnée par le module de sélection MD4, si une utilisation anormale (ou suspecte) de ladite carte CD s'est produite pendant ladite période de temps prédéfinie PD.
On entend ici par « utilisation anormale », toute utilisation de la carte à puce CD jugée, selon au moins un critère d'analyse prédéfini, comme étant potentiellement à risque, frauduleuse ou anormale.
Toujours dans cet exemple, le module de sécurisation MD8 est configuré, en cas de résultat positif de la détection par le module d'analyse de risque MD6 (c'est-à-dire si une utilisation anormale de la carte CD est détectée par le module d'analyse MD6), pour déclencher au moins une opération de sécurisation de la carte à puce CD en réponse à la transaction courante TR. Chaque opération de sécurisation est configurée pour sécuriser la carte à puce CD en réponse à la transaction courante TR. Des exemples de telles opérations sont décrits ci-après en référence aux figures 5-9.
Les étapes réalisées par la carte à puce CD lors d'un procédé de sécurisation selon un mode de réalisation particulier sont à présent décrites en référence à la figure 5. Pour ce faire, la carte à puce CD exécute le programme d'ordinateur PG.
On suppose ici que la carte à puce CD a initié, en coopération avec le terminal T, le traitement d'une transaction TR, dite transaction courante. Selon une variante, la transaction TR courante n'a pas encore été initiée.
Dans cet exemple, la transaction TR est conforme au protocole EMV.
Au cours d'une étape S30 de détermination, la carte à puce CD détermine un point courant PC dans le temps au cours duquel la transaction courante TR est, ou doit être, mise en œuvre par la carte à puce CD. Ce point courant PC comprend par exemple au moins l'un parmi la date (dite date courante) et l'heure (dite heure courante) de la transaction courante.
En S32, la carte à puce CD sélectionne, dans le fichier d'historisation LG dans lequel est enregistrée au moins une transaction TR passée, chaque (ou au moins une) transaction TR mise en œuvre par la carte à puce CD dans une période de temps prédéfinie PD terminant au point courant PC dans le temps. Comme déjà indiqué, cette période PD est une fenêtre de temps glissante, de durée prédéfinie, dont la borne de fin est définie par la position courante dans le temps PC.
Dans un exemple particulier, le point courant PC dans le temps est défini par la date courante DC = [16 février 2016] et l'heure courante HC = [16.00], et la durée de la période de temps PD est fixée à 30 jours. Comme expliqué par la suite, la durée de la période de temps PD peut notamment être adaptée selon la configuration souhaitée au vu du type d'événements ou de comportements que l'on souhaite surveiller au niveau de la carte à puce CD.
La carte à puce CD réalise ensuite en S34 une analyse de risque (ou une analyse de transaction), à partir d'au moins une donnée d'historisation DLG enregistrée dans le fichier d'historisation LG en association avec chaque transaction TR sélectionnée en S32, pour détecter si une utilisation anormale (ou suspecte) de la carte à puce CD s'est produite pendant la période de temps prédéfinie PD. En S34, la carte à puce CD détecte par exemple si une utilisation anormale de ladite carte CD s'est produite pendant la période de temps PD prédéfinie à partir d'au moins l'un parmi :
- le nombre de transactions TR sélectionnées en S32 ; et
- le montant cumulé (c.-à-d. le total des montants MT) de chaque transaction TR sélectionnée en S32.
Par exemple, lors de cette analyse de risque S34, la carte à puce CD détecte qu'une utilisation anormale s'est produite pendant la période de temps prédéfinie PD si au moins l'une des conditions prédéfinies suivantes est satisfaite :
- le nombre de transactions sélectionnées lors de la sélection S32 atteint au moins une première valeur seuil prédéfinie ; et
- le montant cumulé de chaque transaction TR sélectionnée lors de la sélection S32 atteint au moins une deuxième valeur seuil prédéfinie.
Si une utilisation anormale est détectée en S34, la carte à puce CD déclenche en S36 au moins une opération de sécurisation de la carte à puce CD en réponse à la transaction TR courante.
Chaque opération de sécurisation vise à sécuriser la carte à puce CD vis-à-vis de la transaction courante TR, et plus généralement, vis-à-vis de l'utilisation faite de la carte à puce CD sur la période de temps PD. Le nombre et la nature de ces opérations de sécurisation peuvent varier selon le cas d'usage.
Selon un mode de réalisation particulier, ladite au moins une opération de sécurisation S36 comprend au moins l'un quelconque parmi :
- envoi d'un message (par exemple au terminal T et/ou au serveur SV) informant de ladite utilisation anormale détectée en S34 ;
- modification d'au moins un paramètre de fonctionnement de la carte à puce CD ; - enregistrement, dans le fichier d'historisation LG, d'une donnée de sécurité représentative de ladite utilisation anormale détectée en S34 ; et
- refus de mettre en œuvre la transaction TR courante.
La nature du ou des paramètres de fonctionnement PR à modifier le cas échéant en S36 peut varier selon le cas. D'une manière générale, un paramètre de fonctionnement PR configure la manière dont la carte à puce CD traite une transaction TR avec un terminal extérieur, tel que le lecteur T dans cet exemple. Le paramètre de fonctionnement PR à modifier peut, par exemple, être un compteur enregistré dans la carte à puce CD. Un tel compteur peut par exemple représenter un nombre de transactions hors ligne déjà réalisées par la carte à puce CD, ou encore le montant cumulé de transactions hors ligne déjà réalisées par la carte à puce CD. Le paramètre PR peut par ailleurs porter sur une valeur seuil d'un tel compteur. La modification du paramètre PR peut constituer une mise à jour de la configuration de la carte à puce CD causant un changement dans le traitement des transactions TR par la carte à puce CD.
Un mode de réalisation particulier est à présent décrit en référence aux figures 6-8.
Plus précisément, la carte à puce CD met en œuvre un exemple de procédé de sécurisation en exécutant le programme d'ordinateur PG.
La figure 7 représente, le long d'une ligne de temps, des transactions TRI - TR5 ayant été successivement mises en œuvre dans le passé par la carte à puce CD selon le protocole EMV.
La figure 6 représente l'enregistrement de ces transactions TRI à TR5 dans le fichier d'historisation LG de la carte à puce CD. Plus particulièrement, des données d'historisation DLG sont enregistrées dans le fichier d'historisation LG en association avec chaque transaction TRI - TR5. Ces données d'historisation DLG caractérisent les transactions TRI - TR5 qui ont été déjà mises en œuvre par la carte à puce CD. Dans cet exemple particulier, les données d'historisation DLG enregistrées dans le fichier d'historisation LG comprennent, en association avec chaque transaction TR référencée, un identifiant de transaction ID, un point dans le temps PT (par exemple une date et/ou une heure) où la transaction a été réalisée et un montant MT de la transaction, et éventuellement au moins l'une parmi : une donnée d'historisation DN1 indiquant si la transaction a été réalisée en ligne ou hors ligne, une donnée d'historisation DN2 indiquant si l'authentification (ou validation) en ligne par l'émetteur EM a été passée avec succès dans le cas d'une transaction en ligne, et une donnée d'historisation DN3 indiquant le type de terminal T ayant coopéré avec la carte CD lors de la transaction. Parmi les types de terminaux T possibles, on peut citer par exemple les distributeurs automatiques de billets (ou DAB) et les terminaux de paiement, d'autres types de terminaux étant envisageables.
Comme illustré en figure 7, on suppose à présent que la carte à puce CD a initié, en coopération avec le terminal T, le traitement selon le protocole EMV d'une nouvelle transaction TR6, dite transaction courante. La carte à puce CD est par exemple insérée dans le terminal T pour permettre la communication par contact. Dans un exemple particulier, on suppose que la carte à puce CD a reçu une première commande APDU de type GENERATE AC, notée GAC1, comme déjà expliqué ci-avant en référence à l'étape S8 en figure 1, et que la carte à puce CD met en œuvre le procédé de sécurisation selon un mode de réalisation particulier de l'invention en réponse à cette commande GAC1. Selon une variante, le procédé de sécurisation est mis en œuvre à un autre stade du protocole EMV. Selon encore une autre variante, la carte à puce CD met œuvre le procédé de sécurisation alors que le traitement de la transaction TR courante selon le protocole EMV n'a pas encore été initié.
Les étapes A4, A6, A12 et A14 décrites ci-après en référence à la figure 8 correspondent respectivement aux étapes S30, S32, S34 et S36, représentées en figure 5, mises en œuvre dans un mode de réalisation particulier de l'invention.
Au cours d'une étape d'envoi B2, le terminal T envoie une donnée temporelle DNT à la carte à puce CD qui la reçoit en A2. La donnée temporelle DNT est représentative d'un point courant PC dans le temps. Cette donnée temporelle DNT peut présenter un quelconque format approprié et comprend ici par exemple la date courante DC et l'heure courante HC.
En A4, la carte à puce CD détermine, à partir de la donnée temporelle DNT reçue en A2, le point courant dans le temps PC au cours duquel la transaction courante TR6 doit être mise en œuvre. Dans cet exemple, le point courant PC est défini par la date courante DC et l'heure courante HC au moment de l'initiation du protocole EMV entre la carte à puce DC et le terminal T pour mettre en œuvre la transaction courante TR6. D'autres techniques pour déterminer la date et/ou l'heure courantes sont toutefois possibles.
La carte à puce CD sélectionne (A6) ensuite, dans le fichier d'historisation LG, chaque transaction TR mise en œuvre par la carte à puce CD dans la période de temps prédéfinie PD terminant au point courant PC dans le temps déterminé en A4. Dans cet exemple, la période de temps PD est une fenêtre de temps d'une durée prédéfinie DT. La valeur de DT peut être adaptée selon le but recherché comme expliqué ultérieurement.
Plus spécifiquement, au cours de la sélection A6, la carte à puce CD (plus particulièrement le module de sélection MD4) détermine dans cet exemple le point de référence dans le temps, noté PRef, correspondant au début de la période de temps prédéfinie PD (figure 7). Pour ce faire, dans cet exemple particulier, la carte à puce CD calcule le point de référence PRef dans le temps à partir du point courant PC dans le temps et de la durée prédéfinie DT attribuée à la période de temps PD. Plus précisément, la carte à puce CD calcule PRef tel que :
PRef = PC - DT Dans cet exemple, le point de référence PRef comprend la date et l'heure du début de la période de temps PD.
Le point de référence PRef dans le temps peut correspondre à une transaction précédemment mise en œuvre par la carte à puce CD.
Toujours en A6, la carte à puce CD sélectionne (A10) ensuite chaque transaction TR, enregistrée dans le fichier d'historisation LG, qui est postérieure au point de référence PRef dans le temps. Selon un exemple particulier, la sélection A10 inclus la transaction TR mise en œuvre le cas échéant au point de référence PRef dans le temps (aucune transaction n'est enregistrée au point PRef dans cet exemple).
Dans cet exemple, la carte à puce CD détermine à quel moment a été mise en œuvre
(ou traitée) une transaction TR référencée dans le fichier d'historisation LG à partir du point dans le temps PT enregistré dans le fichier d'historisation LG en association avec la transaction TR concernée. PT comprend par exemple la date et/ou l'heure de la transaction TR correspondante.
Dans cet exemple particulier, la carte à puce CD sélectionne en A10 les transactions
TR2, TR3, TR4 et TR5 dont le point dans le temps PT (c.-à-d. la date et l'heure) est postérieur à la position de référence PRef dans le temps. La carte à puce CD sélectionne en outre en A10 la transaction TR6 en cours, bien que des variantes soient possibles dans lesquelles la transaction TR en cours n'est pas sélectionnée en A10.
La carte à puce CD peut en outre être configurée pour appliquer au moins un critère de sélection CRI pour affiner la sélection réalisée en A10. Selon une variante, la carte à puce CD détermine par exemple en A10, à partir du fichier d'historisation LG, en tant que transaction de référence TRef, la transaction TR la plus récente dans la période de temps PD qui satisfait la première condition prédéfinie CD1. On entend ici par « plus récente » la transaction TR dont le point dans le temps PT est le plus proche du point courant PC. La carte à puce CD sélectionne alors en A10 uniquement chaque transaction TR mise en œuvre par ladite carte CD postérieurement à la transaction de référence TRef dans la période de temps prédéfinie PD. Selon un exemple de réalisation particulier, la première condition CD1 comprend au moins l'une des conditions suivantes :
■ CDU : la transaction de référence TRef est une transaction en ligne ayant été réalisée en coopération avec l'émetteur EM ; et
■ CD12 : la transaction de référence TRef est une transaction en ligne réalisée en coopération avec l'émetteur EM et qui a été authentifiée (ou validée) avec succès par ledit émetteur EM.
Lorsque la condition CDU ci-dessus est appliquée, la carte à puce CD détermine, pour chaque transaction TR dont le point dans le temps PT est postérieur à la transaction de référence TRef, et à partir de la donnée DN1 associée, si ladite transaction TR est une transaction en ligne. Lorsque la condition CD12 ci-dessus est en outre appliquée, la carte à puce CD détermine, pour chaque transaction en ligne dont le point dans le temps PT est postérieur à la transaction de référence TRef, et à partir de la donnée DN2 correspondante dans le fichier d'historisation LG, si ladite transaction TR a été authentifiée (ou validée) avec succès par l'émetteur EM.
Dans un mode de réalisation particulier, la carte à puce CD applique la condition CDU mais pas la condition CD12 en A10. Selon l'exemple représenté en figure 6, la transaction TR3 constitue alors la transaction de référence TRef (DN1 = ON LINE) de sorte que la carte à puce CD sélectionne en A10, conformément à la condition CDU, les transactions TR4 et TR5.
Selon un autre mode de réalisation, la carte à puce CD applique la condition CD12 ci- dessus. Selon l'exemple représenté en figure 6, la transaction TR3 constitue alors également la transaction de référence TRef car la donnée DN2 associée indique que cette transaction en ligne a été authentifiée (ou validée) avec succès par l'émetteur EM (DN2 = OK). En conséquence, la carte à puce CD sélectionne en A10, conformément à la condition CD12, les transactions TR4 et TR5.
Comme déjà indiqué, la carte à puce CD peut être configurée pour appliquer au moins un critère de sélection CRI pour affiner la sélection réalisée en A10. Le nombre et la nature des critères de sélection CRI peut varier selon le cas. Selon un exemple particulier, lors de la sélection A10, la carte à puce CD filtre les transactions TR enregistrées dans le fichier d'historisation LG pour ne sélectionner que chaque transaction TR satisfaisant au moins une deuxième condition prédéfinie CD2.
Dans un exemple particulier, la deuxième condition prédéfinie CD2 comprend une condition sur le type du terminal T avec lequel la carte à puce CD a coopéré lors de ladite transaction TR. Dans l'exemple représenté en figure 6, le fichier d'historisation LG enregistre en tant que donnée d'historisation DN3, pour chaque transaction TR, si ladite transaction a été réalisée en coopération avec un terminal T selon un premier type TY1 ou selon un deuxième type TY2. Dans un exemple particulier, les états TY1 et TY2 indiquent respectivement que le terminal T est un distributeur automatique de billets (DAB) et un terminal de paiement (un terminal mobile par exemple). Si par exemple la condition CD2 est appliquée, la carte à puce CD exclut de la sélection A10 les transactions TR qui sont dans la période prédéfinies PD et mais ne satisfont par l'état TY1 (la transaction TR5 est donc exclus dans cet exemple).
On comprendra qu'il est possible de configurer la carte à puce CD pour qu'elle applique au moins une première condition CD1 et/ou au moins une deuxième condition CD2 comme expliqué ci-avant.
On supposera dans la suite de cet exemple que la carte à puce CD applique la condition CDU et sélectionne en conséquence en A10 les transactions TR4 et TR5. Au cours d'une étape d'analyse A12, la carte à puce CD (plus particulièrement le module d'analyse de risque MD6), réalise une analyse de risque (ou analyse de transaction), à partir des données d'historisation DLG enregistrées dans le fichier d'historisation LG en association avec chaque transaction TR sélectionnée en A6 (à savoir TR4 et TR5 dans cet exemple), pour détecter si une utilisation anormale (ou suspecte) de la carte à puce CD s'est produite pendant la période de temps prédéfinie PD.
Dans cet exemple de réalisation, lors de ladite analyse A12, la carte à puce CD détecte si une utilisation anormale de ladite carte CD s'est produite pendant la période de temps prédéfinie PD à partir d'au moins l'un parmi :
- le nombre de transactions TR sélectionnées en A6 ; et
- le montant cumulé de chaque transaction TR sélectionnée en A6.
On suppose dans cet exemple que le nombre de transactions TR sélectionnées en A6 et le montant cumulé de chaque transaction TR sélectionnée en A6 sont pris en compte par la carte à puce CD lors de l'analyse de risque A12. Dans l'exemple considéré ici et comme représenté en figure 6, deux transactions (TR4 et TR5) sont sélectionnées en A6 et le montant cumulé des transactions TR4 et TR5 s'élève à MT4 + MT5.
Selon un exemple particulier, lors de l'analyse de risque A12, la carte à puce CD détecte si une utilisation anormale (ou suspecte) s'est produite pendant la période de temps prédéfinie PD selon au moins un critère d'analyse CR2, enregistré dans cet exemple dans la mémoire 10. Dans cet exemple, lors de l'analyse A12, la carte à puce CD applique, en tant que critères d'analyse CR2, les conditions prédéfinies CD3 suivantes :
- CD31 : le nombre de transactions sélectionnées lors de ladite sélection A6 atteint au moins une première valeur seuil prédéfinie Lmaxl ; et
- CD32 : le montant cumulé (TR4 + TR5 dans cet exemple) de chaque transaction TR sélectionnée en A6 atteint au moins une deuxième valeur seuil prédéfinie Lmax2.
Autrement dit, lors de l'analyse A12, la carte à puce CD détecte qu'une utilisation anormale ou suspecte s'est produite pendant la période de temps prédéfinie PD si les conditions CD32 et CD32 sont satisfaites. Les valeurs Lmaxl et Lmax2 sont fixées selon les besoins du cas d'espèce.
Selon une variante, seule l'une parmi les conditions prédéfinies CD31 et CD32 est appliquée par la carte à puce CD lors de l'analyse A12.
Si aucune utilisation anormale n'est détectée lors de l'analyse A12, le procédé de sécurisation prend fin. Dans ce cas, la carte à puce CD reprend par exemple un traitement normal de la transaction selon le protocole EMV.
Si, en revanche, une utilisation anormale est détectée en A12, la carte à puce CD déclenche en A14 au moins une opération de sécurisation de la carte à puce CD en réponse à la transaction courante TR6. Chaque opération de sécurisation est configurée pour sécuriser la carte à puce CD vis-à-vis de la transaction courante TR, et plus généralement, vis-à-vis de l'utilisation faite de la carte à puce CD sur la période de temps PD. Le nombre et la nature de ces opérations de sécurisation peuvent varier selon le cas d'usage.
Dans cet exemple, la carte à puce CD réalise en A14 au moins l'une des opérations de sécurisation suivantes :
- envoi (A16) au terminal T d'un message MSG1 informant de ladite utilisation anormale ou suspecte détectée. Le terminal T peut le cas échéant transmettre (B17) le message MSG1 au serveur distant SV afin que l'émetteur SV soit informé de l'utilisation anormale ou suspecte détectée par la carte à puce CD ;
- modification d'au moins un paramètre de fonctionnement PR du dispositif électronique. Comme déjà indiqué, divers paramètres de fonctionnement PR de la carte à puce CD peuvent être modifiés selon les besoins. De manière générale, un paramètre de fonctionnement PR configure la manière dont la carte à puce CD traite une transaction TR avec le terminal T.
- enregistrement (A20), dans le fichier d'historisation LG, d'une donnée de sécurité DS représentative de ladite utilisation anormale ou suspecte détectée en A12 ; et
- refus (A22) d'autoriser la transaction courante. La carte CD à puce CD envoie par exemple un message de refus MSG2 qui est reçu par le terminal T en B22.
La présente invention permet avantageusement de protéger de façon efficace les cartes à puce, par exemple de type EMV, contre les comportements anormaux ou suspects survenant notamment lors des transactions hors ligne. Une carte à puce selon l'invention est ainsi capable de stocker en mémoire des données d'historisation relatives aux transactions traitées par ladite carte au fil du temps. A partir de ces données d'historisation, la carte à puce peut alors analyser l'utilisation qui est faite de la carte dans une fenêtre de temps pertinente, à savoir une fenêtre de temps correspondant ici à une période de temps qui précède immédiatement la transaction en cours. Il est ainsi possible de prendre en compte toutes les transactions pertinentes pour chaque analyse faite par la carte à puce, sans qu'il y ait un risque que certaines transactions soient exclues de l'analyse comme c'est le cas par exemple dans le mécanisme de sécurisation décrit précédemment en référence aux figures 2A et 2B.
Il est possible de fixer la durée DT de la période de temps PD en fonction du type d'utilisation anormale ou non autorisée que l'on cherche à détecter. Afin de pallier les problèmes de vol précédemment décrits, on peut par exemple fixer la durée DT telle que DT = 10 minutes (ou une quelconque valeur inférieure à 60 ou 10 minutes). Si, en revanche, on cherche à détecter un comportement anormal du porteur authentique (par exemple un nombre et/ou un montant cumulé de dépense anormal ou suspect), on peut par exemple régler la durée DT telle que DT = 30 jours. De cette manière, l'émetteur peut contrôler les habitudes de consommations du porteur authentique et, si besoin, contacter le porteur ou prendre toute autre mesure appropriée.
On peut ainsi configurer la carte à puce afin de déclencher une réponse sécuritaire adaptée à l'utilisation anormale détectée. Une sécurisation renforcée de la carte à puce contre les utilisations frauduleuses (en cas de vol par exemple) est par exemple possible.
De manière générale, l'invention permet de mieux contrôler l'utilisation d'une carte à puce, de type EMV notamment, y compris lorsque celle-ci fonctionne hors ligne.
Un homme du métier comprendra que les modes de réalisation et variantes décrits ci- avant ne constituent que des exemples non limitatifs de mise en œuvre de l'invention. En particulier, l'homme du métier pourra envisager une quelconque adaptation ou combinaison des modes de réalisation et variantes décrits ci-avant afin de répondre à un besoin bien particulier.

Claims

REVENDICATIONS 1. Procédé de sécurisation mis en œuvre par un dispositif électronique (CD), ledit procédé comprenant :
- détermination (S30 ; A4) d'un point courant dans le temps (PC) au cours duquel une transaction courante (TR) est ou doit être mise en œuvre par le dispositif électronique ;
- sélection (S32 ; A6), dans un fichier d'historisation (LG) dans lequel est enregistrée au moins une transaction (TR) passée, d'au moins une transaction mise en œuvre par ledit dispositif électronique dans une période de temps glissante d'une durée prédéfinie (PD), ladite période de temps glissante se terminant au point courant dans le temps ;
- analyse de risque (S34 ; A12), à partir d'au moins une donnée d'historisation
(DLG) enregistrée dans le fichier d'historisation en association avec chaque transaction (TR) sélectionnée, pour détecter si une utilisation anormale dudit dispositif électronique s'est produite pendant ladite période de temps glissante ; et
- dans l'affirmative, déclenchement (S36 ; A14) d'au moins une opération de sécurisation (A16-A22) du dispositif électronique en réponse à ladite transaction courante.
2. Procédé selon la revendication 1, dans lequel le point courant dans le temps comprend au moins l'un parmi la date courante et l'heure courante de la transaction courante.
3. Procédé selon la revendication 1 ou 2, dans lequel la détermination du point courant comprend une réception, depuis un terminal avec lequel coopère le dispositif électronique, d'une donnée temporelle représentative du point courant dans le temps.
4. Procédé selon l'une quelconque des revendications 1 à 3, dans lequel ladite sélection comprend un calcul du point dans le temps du début de la période de temps glissante, à partir du point courant dans le temps et de la durée prédéfinie attribuée à ladite période de temps glissante,
chaque transaction sélectionnée étant postérieure au point dans le temps du début de la période de temps glissante.
5. Procédé selon l'une quelconque des revendications 1 à 4, dans lequel, lors de ladite sélection, le dispositif électronique :
- détermine, à partir du fichier d'historisation, en tant que transaction de référence, la transaction la plus récente dans la période de temps glissante qui satisfait au moins une première condition prédéfinie ; et
- sélectionne uniquement chaque transaction mise en œuvre par ledit dispositif électronique postérieurement à ladite transaction de référence dans la période de temps glissante.
6. Procédé selon la revendication 5, dans lequel ladite au moins une première condition prédéfinie comprend au moins l'une des conditions suivantes :
- la transaction de référence est une transaction dite « en ligne » ayant été réalisée en coopération avec une entité émettrice du dispositif électronique ; et
- la transaction de référence est une dite transaction en ligne qui a été authentifiée avec succès par l'entité émettrice du dispositif électronique.
7. Procédé selon l'une quelconque des revendications 1 à 6, dans lequel, lors de ladite sélection, le dispositif électronique filtre les transactions enregistrées dans le fichier d'historisation pour ne sélectionner que chaque transaction satisfaisant au moins une deuxième condition prédéfinie.
8. Procédé selon la revendication 7, dans lequel la deuxième condition prédéfinie comprend une condition sur le type du terminal avec lequel le dispositif électronique a coopéré lors de ladite transaction.
9. Procédé selon l'une quelconque des revendications 1 à 8, dans lequel, lors de ladite analyse de risque, le dispositif électronique détecte si une utilisation anormale dudit dispositif électronique s'est produite pendant ladite période de temps glissante à partir d'au moins l'un parmi :
- le nombre de transactions sélectionnées ; et
- le montant cumulé de chaque transaction sélectionnée.
10. Procédé selon la revendication 9, dans lequel, lors de ladite analyse de risque, le dispositif électronique détecte qu'une utilisation anormale s'est produite pendant ladite période de temps glissante si au moins l'une des troisièmes conditions prédéfinies suivantes est satisfaite : - le nombre de transactions sélectionnées lors de ladite sélection atteint une première valeur seuil prédéfinie ; et
- le montant cumulé de chaque transaction sélectionnée lors de ladite sélection atteint une deuxième valeur seuil prédéfinie.
11. Procédé selon l'une quelconque des revendications 1 à 10, dans lequel ladite au moins une opération de sécurisation comprend au moins l'un parmi :
- envoi d'un message informant de ladite utilisation anormale détectée ;
- modification d'au moins un paramètre de fonctionnement du dispositif électronique ;
- enregistrement, dans le fichier d'historisation, d'une donnée de sécurité représentative de ladite utilisation anormale détectée ; et
- refus de mettre en œuvre ladite transaction courante.
12. Procédé selon l'une quelconque des revendications 1 à 11, dans lequel le dispositif électronique est une carte à puce.
13. Programme d'ordinateur (PGl) comportant des instructions pour l'exécution des étapes d'un procédé de sécurisation selon l'une quelconque des revendications 1 à 12 lorsque ledit programme est exécuté par un ordinateur.
14. Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur (PGl) comprenant des instructions pour l'exécution des étapes d'un procédé de sécurisation selon l'une quelconque des revendications 1 à 12.
15. Dispositif électronique comprenant :
- un module de détermination pour déterminer un point courant dans le temps au cours duquel une transaction courante est ou doit être mise en œuvre par le dispositif électronique ;
- un module de sélection pour sélectionner, dans un fichier d'historisation dans lequel est enregistrée au moins une transaction passée, au moins une transaction mise en œuvre par ledit dispositif électronique dans une période de temps glissante, d'une durée prédéterminée, terminant au point courant dans le temps ;
- un module d'analyse de risque pour détecter, à partir d'au moins une donnée d'historisation enregistrée dans le fichier d'historisation en association avec chaque transaction sélectionnée, si une utilisation anormale dudit dispositif électronique s'est produite pendant ladite période de temps glissante ; et un module de sécurisation configuré, en cas de résultat positif de ladite détection par le module d'analyse de risque, pour déclencher une opération de sécurisation du dispositif électronique en réponse à ladite transaction courante.
16. Dispositif électronique selon la revendication 15, comprenant une mémoire dans laquelle est enregistré le fichier d'historisation.
17. Dispositif électronique selon la revendication 15 ou 16, dans lequel le dispositif électronique est une carte à puce.
EP17729524.3A 2016-05-23 2017-05-22 Procédé de sécurisation d'un dispositif electronique, et dispositif electronique correspondant Ceased EP3465584A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1654572A FR3051579B1 (fr) 2016-05-23 2016-05-23 Procede de securisation d'un dispositif electronique, et dispositif electronique correspondant
PCT/FR2017/051254 WO2017203146A1 (fr) 2016-05-23 2017-05-22 Procede de securisation d'un dispositif electronique, et dispositif electronique correspondant

Publications (1)

Publication Number Publication Date
EP3465584A1 true EP3465584A1 (fr) 2019-04-10

Family

ID=57113448

Family Applications (1)

Application Number Title Priority Date Filing Date
EP17729524.3A Ceased EP3465584A1 (fr) 2016-05-23 2017-05-22 Procédé de sécurisation d'un dispositif electronique, et dispositif electronique correspondant

Country Status (4)

Country Link
US (1) US20200320535A1 (fr)
EP (1) EP3465584A1 (fr)
FR (1) FR3051579B1 (fr)
WO (1) WO2017203146A1 (fr)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3076027B1 (fr) * 2017-12-21 2021-08-20 Oberthur Technologies Securisation du traitement d'une transaction
FR3076026B1 (fr) * 2017-12-22 2019-11-29 Oberthur Technologies Sauvegarde de donnees d'historique dans un dispositif destine a traiter des transactions
FR3090959B1 (fr) * 2018-12-21 2020-12-11 Idemia France Traitement d’un service de tickets électroniques
FR3099272B1 (fr) * 2019-07-24 2021-07-02 Idemia France Procédé de sécurisation, et dispositif électronique associé
CN115982703B (zh) * 2023-03-22 2023-06-16 新兴际华集团财务有限公司 用户行为数据处理方法、装置、电子设备和计算机可读介质

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1955269A4 (fr) * 2005-12-02 2012-12-05 Welcome Real Time Pte Ltd Procédé et système pour retours autorisés
FR2958770B1 (fr) * 2010-04-13 2012-11-16 Oberthur Technologies Procede de controle d'un dispositif apte a fonctionner en mode avec ou sans verification de code pour effectuer une transaction
FR2984648B1 (fr) * 2011-12-20 2014-01-10 Oberthur Technologies Dispositif electronique individuel et procede de reponse par un dispositif electronique individuel a une sollicitation
FR3012645A1 (fr) * 2013-10-24 2015-05-01 Orange Procede d'execution d'une transaction entre un premier terminal et un deuxieme terminal
CA2934342C (fr) * 2013-12-18 2023-02-28 Capital One Financial Corporation Systemes et methodes pour generer des offres a partir de paiements sans contact mis en jetons
US10311439B2 (en) * 2014-10-15 2019-06-04 Paypal, Inc. Systems and methods for facilitating offline payments
US10366378B1 (en) * 2016-06-30 2019-07-30 Square, Inc. Processing transactions in offline mode

Also Published As

Publication number Publication date
WO2017203146A1 (fr) 2017-11-30
FR3051579A1 (fr) 2017-11-24
FR3051579B1 (fr) 2021-11-19
US20200320535A1 (en) 2020-10-08

Similar Documents

Publication Publication Date Title
EP3465584A1 (fr) Procédé de sécurisation d'un dispositif electronique, et dispositif electronique correspondant
EP3455812B1 (fr) Procédé de sécurisation d'un dispositif electronique, et dispositif electronique correspondant
FR2958770A1 (fr) Procede de controle d'un dispositif apte a fonctionner en mode avec ou sans verification de code pour effectuer une transaction
FR3021799A1 (fr) Methode d'identification, dispositif et programme correspondant
EP3234848B1 (fr) Procede d'envoi d'une information de securite et dispositif electronique apte a mettre en oeuvre un tel procede
EP3261014B1 (fr) Procédé d'envoi d'une information de sécurité
EP3343487A1 (fr) Procédé de contrôle d'habitudes d'utilisation et dispositif électronique apte à mettre en uvre un tel procédé
EP3579588B1 (fr) Procédé de gestion d'une procédure d'un mode de secours de transaction, et dispositif associé
EP3394812A1 (fr) Procédé d'authentification
EP3291188B1 (fr) Procédé de contrôle d'un dispositif électronique et dispositif électronique correspondant
EP3340098B1 (fr) Procédé pour la sécurité d'une opération électronique avec une carte à puce
EP3502997B1 (fr) Sauvegarde de donnees d'historique dans un dispositif destine a traiter des transactions
FR3062501A1 (fr) Procede pour la securite d'une operation electronique
EP4075358B1 (fr) Gestion de la mémoire dans un dispositif de traitement de transactions
FR3076027A1 (fr) Securisation du traitement d'une transaction
EP3836060A1 (fr) Traitement de transactions selon un profil opérationnel
FR3092412A1 (fr) Authentification d’un utilisateur d’un dispositif électronique
FR3099272A1 (fr) Procédé de sécurisation, et dispositif électronique associé
FR3084502A1 (fr) Securisation de transactions
FR3091945A1 (fr) Procédé de transaction avec une devise différente, et dispositif correspondant
FR3092413A1 (fr) Procede d’authentification d’un utilisateur et dispositif associe
WO2016097637A1 (fr) Procede de securisation d'un code pin avec des compteurs d'erreurs dans une carte a puce
EP2812864A2 (fr) Système de paiement, terminal de paiement de ce système, et procédé de paiement associé

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20181122

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20190905

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20201209