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/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
  • G06Q20/326—Payment applications installed on the mobile devices
  • G06Q20/3263—Payment applications installed on the mobile devices characterised by activation or deactivation of payment capabilities
• • 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/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
  • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
  • G06Q20/3674—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes involving authentication
• • 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/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
  • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
  • G06Q20/3227—Aspects of commerce using mobile devices [M-devices] using secure elements embedded in M-devices
• • 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/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
  • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
  • G06Q20/3229—Use of the SIM of a M-device as secure element
• • 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/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes

Definitions

• the present invention relates to the field of transactions using mobile terminals.
• Dematerialized or “virtualized” appeared recently, to make transactions (especially payments) through a dematerialized bank card on an electronic medium, for example a mobile terminal, able to make a payment remote or in proximity with a payment terminal, for example of non-contact type (NFC).
• NFC non-contact type
• the virtualization method used by these payment systems is for example the following: the customer, or cardholder, between the billing information recorded on his card in an application of the terminal controlled by an aggregator, or provider, of the payment service .
• the wearer photographs his bank card and informs the visual cryptogram (the security code which is typically on the back).
• the visual cryptogram the security code which is typically on the back.
• the bank that is responsible for the bank account associated with the card validates the virtualization if it believes that the person who entered the information is actually the customer card holder, or carrier. If necessary, are loaded at the terminal virtualization data corresponding to the card, or token (in English "token"), encrypted using encryption keys known only by the bank responsible for the card ( or by the organization managing the banking scheme in delegation of the banking organization responsible for the card).
• token in English "token”
• Token transaction module data (bank card virtualization data) includes:
• Additional code (usually the visual cryptogram); - A PIN, that is to say a personal confidential code, usually 4 digits.
• the third must be known to the user, he will indeed be asked to validate any transaction using the dematerialized card (at least from a certain value).
• wallet To facilitate the management of a plurality of dematerialized cards, it has been proposed the use of unified electronic wallet applications, called “wallet”. Such an application is for example described in the document US2015235212. If the user wants to use one of his cards for a transaction, he just has to open the wallet as the only payment application, and the latter offers him to choose between the cards (and more particularly between the transaction modules of cards) he wants to use, he just has to enter the associated PIN. Wallets also provide additional features such as PIN code change.
• the number of PIN codes to be memorized can be quite high if it has dematerialized several cards.
• a single card can be associated with several modules of a token, it can become complex if the user wants to change PIN. The latter may inadvertently put different PIN codes for several modules associated with the same card, and not understand why his code no longer works if he makes a purchase for example via Visa instead of CB or vice versa.
• the present invention thus relates in a first aspect to a method for implementing a transaction from a mobile terminal comprising a data processing module and a security element on which a plurality of transaction modules are stored, each module transaction card associated with a card electronic, and adapted to authorize a transaction on behalf of said electronic card when activated on presentation of an associated PIN,
• a security element such as a subscriber identification card for the implementation of an authentication module that oversees the transaction modules makes it possible to keep the maximum level of security in place. free from the need for multiple PIN management.
• the data processing module implements a module for managing the transaction modules, step (b) comprising the reception by the authentication module of an activation request of the transaction module targeted by the request for transaction, said activation request being issued by said management module.
• the present method is used cleverly with a management module of the "wallet” type facilitating the implementation of transactions by the user.
• Step (b) comprises the prior transmission by the targeted transaction module, to the management module, of a request for presentation of the associated confidential code.
• the management module thus makes it possible to implement the authentication module as a "wallet companion" without having to modify the transaction modules.
• the management module is configured to request and obtain via the interface said authentication code.
• the management module can simply control the authentication module by replacing the request for presentation of the PIN with a request for presentation of the unique authentication code, and this completely transparent manner.
• Said activation request includes an identifier of the targeted transaction module, and the authentication code obtained via the interface;
• Step (c) comprises the transmission by the authentication module of the confidential code associated with the targeted transaction module in response to the activation request.
• Step (c) also comprises the reception by the targeted transaction module of the associated confidential code.
• the authentication module provides the confidential code to the targeted transaction module so as to simulate a conventional operation.
• Step (b) comprises the reception by the authentication module of an activation request of the transaction module targeted by the transaction request, said activation request being sent by said targeted transaction module.
• the authentication module is configured to request and obtain via the interface said authentication code.
• the authentication module and the transaction module communicate only within the security element, which physically prevents any attack to intercept the code requests.
• Step (b) comprises the transmission by the authentication module of an activation command of the targeted transaction module in response to the activation request.
• the authentication module completely controls the transaction module, which avoids the complexity (and therefore the security risks) associated with communication within the mobile OS.
• the transaction module concerned is associated with a bank card, the transaction request being received in step (a) from an electronic payment terminal in wireless communication with the terminal, the transaction authorization being issued to the step (c) to the electronic payment terminal.
• the method further comprises a step (d) of transmitting the transaction authorization to a bank server associated with said bank card via a network.
• a mobile terminal configured in NFC mode can simulate a bank card with the same functionality. It is sufficient for the user to put his terminal on the TPE to authorize a payment with the dematerialized card.
• the security element is chosen from a subscriber identification card and a secure execution space of the terminal's data processing module.
• the method comprises the prior implementation of a digitization of at least one electronic card, comprising the implementation of steps by the security element of:
• the method comprises prior to reception from the server of data representative of said electronic card:
• the invention relates to a security element on which a plurality of transaction modules are stored, each transaction module being associated with an electronic card, and adapted to authorize a transaction on behalf of said electronic card when it is activated on presentation of an associated PIN,
• the security element being configured to:
• an authentication module Receiving at the level of an authentication module also stored on the security element a valid single authentication code obtained via an interface of a terminal, the authentication module storing the confidential codes associated with each of the transaction modules, and itself being activatable upon presentation of said authentication code;
• the mobile terminal comprising a data processing module and the security element according to the second aspect.
• the invention relates to a computer program product comprising code instructions for executing a method according to the first aspect of the invention for implementing a transaction from a mobile terminal.
• the invention relates to a storage means readable by a computer equipment on which this computer program product is found.
• FIG. 1 is a diagram of a general network architecture for the implementation of the invention
• FIG. 2 represents an embodiment of implementation of a transaction via the method according to the invention
• FIG. 3 represents an embodiment of digitalization of an electronic card via the method according to the invention.
• the invention proposes a method for implementing a transaction from a mobile terminal 1, in particular a transaction using a dematerialized card on the terminal 1, ie a transaction reproducing the use of a a electronic card.
• a transaction using a dematerialized card on the terminal 1 ie a transaction reproducing the use of a a electronic card.
• the transaction is typically a payment transaction (that is, the dematerialized card on the terminal 1 is a bank card), in particular a proximity transaction initiated by an electronic payment terminal (EPT) 2 such as the it is found in most outlets (for example EFTPOS type).
• EPT electronic payment terminal
• the TPEs have near-field communication means (NFC) originally intended to interact with a physical bank card with this technology, but also allowing them to interact with the mobile terminal 1.
• NFC near-field communication means
• the TPE 2 is therefore advantageously on the one hand connected via a wireless link
• NFC NFC, but also Wi-Fi or Bluetooth
• a network 20 for example Internet
• the payment can be remote (ie no near-field communication with a TPE 2)
• the mobile terminal 1 can for example be connected via the Internet (through a mobile communication network, typically 4G) to a remote payment equipment .
• the present method is not limited to payment transactions, but may relate to any transaction reproducing the use of an electronic card on the terminal 1, and in particular teletransmissions of care sheets via a vital card, validations of medical procedures via Health Professional Card, secure transmission of documents online (for example filing of a patent application by an EPO agent's smart card), etc.
• the mobile terminal 1 can be of any type, in particular smartphone or touch tablets. It comprises a data processing module 11 (a processor), a data storage module 12, a user interface (HMI) 13 comprising, for example, input means and display means (for example a touch screen, we will see further alternatives).
• a data processing module 11 a processor
• a data storage module 12 a data storage module
• a user interface (HMI) 13 comprising, for example, input means and display means (for example a touch screen, we will see further alternatives).
• the terminal 1 further comprises a security element 12.
• a security element is an element adapted to allow a connection of the terminal 1 to a mobile communication network, in particular a subscriber identification card.
• subscriber identification card is meant any integrated circuit capable of performing the functions of identifying a subscriber to a network by means of data stored therein, and more particularly a "SIM” card (of the English “Subscriber Identity Module”), or a “e-UICC” card (for “(embedded) -Universal Integrated Circuit Card”) comprising data processing means in the form of a microcontroller and the "EEPROM” type memory (for "Electrically-Erasable Programmable Read -Only Memory "), or flash.
• SIM SIM
• e-UICC embedded
• EEPROM Electrically-Erasable Programmable Read -Only Memory
• flash Electrically-Erasable Programmable Read -Only Memory
• the security module 12 is a secure memory area of the mobile terminal such as a "TEE” (Trusted Execution Environment) component embedded in the data processing module 11, or a dedicated hardware element of the terminal 1 (for example a microcontroller, an "eSE” chip for "(embedded) -Secure Element” or any “Secure Component GP (GlobalPIatform)”), or even a removable microSD component ("SD” for Secure Digital).
• TEE Trusteon Environment
• eSE embedded in the data processing module 11
• a dedicated hardware element of the terminal 1 for example a microcontroller, an "eSE” chip for "(embedded) -Secure Element” or any “Secure Component GP (GlobalPIatform)"
• SD Secure Digital
• the server 3 of the network 20 designates a transaction management platform, and comprises a data processing module 31, for example a processor and a data storage module 32 such as a hard disk or, preferably, an HSM (for "Hardware Security Module”).
• a data processing module 31 for example a processor
• a data storage module 32 such as a hard disk or, preferably, an HSM (for "Hardware Security Module”).
• server 3 can encompass a plurality of separate banking servers connected and adapted to communicate together.
• a plurality of transaction modules are stored on the security element 12, each transaction module being associated with an electronic card (ie one or more transaction modules constituting a dematerialized version of the electronic card), and adapted to authorize a transaction on behalf of said electronic card when activated upon presentation of an associated PIN.
• the transaction modules are advantageously organized into one or more sets each representative of an electronic card. In other words, each set includes the transaction modules associated with the same electronic card.
• the electronic cards are bank cards, and the sets of transaction modules are "tokens" as mentioned, each token being thus representative of a bank card.
• tokens modules In the remainder of the present description, we will take the example of tokens modules.
• other types of electronic cards may be dematerialized, and generally any smart card allowing strong authentication, that is to say, whose possession associated with knowledge of a confidential code validates the identity of the user and his authorization to perform an action.
• a transaction module contains (among other things):
• an additional code for example the visual cryptogram, a confidential code.
• a transaction module part of a token once installed (see below) has a two-part application identifier: a prefix designating the origin of the instance (Visa®, CB®, Mastercard®, Amex®, etc. .) and a unique suffix.
• the present solution is distinguished in that is also stored on the security element 12 an authentication module storing the confidential codes associated with each of the transaction modules, and being itself activatable on presentation of a code of authentication.
• the authentication module is a "key ring" containing the confidential codes, which acts as a broker with respect to the transaction modules.
• the different confidential codes can have different lengths, different specifications, etc. .
• the authentication module can not be wrong code. If the user is mistaken for authentication code, then the authentication module can be blocked, it does not require redo the card (no transaction module is blocked): just for example to go to shop operator and present an ID to obtain this unlock in a very secure remote reset mode, well known to those skilled in the art.
• a security module such as a subscriber identification card is a physical device of confidence almost impossible to infect with a Trojan, because the installation of applications in these cards is limited to well identified entities, and controlled by the operator and / or the issuer of the service in relation to the manufacturer of the security element 12.
• the data processing module 1 1 (“non-secure" processor) of the terminal 1 implements a management module of "wallet” type, which very cleverly completes the authentication module 1 called then "wallet companion". We will see their interactions later.
• a first step (a) the security element 12 receives a transaction request for a transaction module of said plurality, for example transmitted from a TPE 2 in connection with the terminal 1, in particular once the user has reported wanting to implement a transaction via a dematerialized payment card he chose for example on his wallet.
• This step is referenced 1. in Figure 2.
• the TPE 2 can in this step query the matrix of active payment means, so as to select (using a filter) the instance (the transaction module) that will be in charge of the transaction. For example, assuming that the user has dematerialized an EMV card (Entropay MasterCard Visa) associated with the bank B3, it can have two associated transaction modules (referenced T3a / T3c), for example respectively associated with Visa® and CB ®. If the TPE 2 is a foreign terminal that only accepts Amex® and Visa®, it chooses the latter and targets the T3a module by issuing a GPO ("Get Processing Option") specifying the action it wants to use (here the payment of a given amount).
• GPO Get Processing Option
• the authentication module receives the valid unique authentication code obtained via an interface 13 of the terminal 1.
• This step can be the subject of several embodiments.
• a wallet that is to say a management module transaction modules
• this management module requests the authentication module by sending an activation request to the transaction module targeted by the transaction request.
• the communications between the management module and the authentication module are secure (encrypted) so as to prevent any interception or manipulation of the data exchanged.
• Step (b) then comprises a substep 2. prior transmission by the target transaction module of a request for presentation of the confidential code addressed to the management module (wallet), in a completely natural and usual manner.
• the management module instead of asking the user for the PIN associated with the transaction module that issued the request (as he would usually do), the management module requests the authentication code of the authentication module.
• the management module is configured to request and obtain via the interface 13 said authentication code.
• the code can be entered directly via a keyboard (in particular touch) of the interface 13, but that the code can also be generated following the verification of the identity of the user on the terminal 1, for example via a fingerprint reader, a voice recognition module, or other.
• the authentication code can be only a command in a secure form (for example a message containing a key), representative of the verified identity of the user, and therefore of the authorization to activate the module. 'authentication.
• the management module then generates said activation request, the latter advantageously comprising an identifier of the target transaction module (received from the latter via the request for presentation of its confidential code), and the authentication code obtained via the interface. 13.
• said activation request advantageously comprising an identifier of the target transaction module (received from the latter via the request for presentation of its confidential code), and the authentication code obtained via the interface. 13.
• the present embodiment allows the use of original transaction modules (as provided by a server 3 for example), they do not even know that they are controlled by an authentication module. Just configure the management module properly. As explained, this embodiment supports any requirements of the transaction modules, and in particular various PIN structures and lengths. No standardization is necessary.
• the transaction module and the authentication module can communicate directly, in particular within the secure element 12 (in other words, the authentication module receives the request for authentication).
• the authentication module receives the request for authentication.
• activating the transaction module targeted by the transaction request said activation request being sent by said target transaction module and replacing the presentation request of the associated confidential code
• hybrid configurations are possible using a management module through which only some of the requests pass (for example that of presentation of the confidential code associated with the targeted transaction module, while having the authentication module requiring its own authentication code).
• the authentication module On receipt of the valid authentication code (otherwise it returns an error message, and preferably hangs after three errors) the authentication module is activated, and in a step (c) it activates the module authentication of the targeted transaction module, so that the latter ultimately issues a transaction authorization in response to said transaction request.
• the authentication module transmits the confidential code associated with the targeted transaction module in response to the activation request, ie to the wallet management module which sends it back to the transaction module (under step 4. shown in Figure 2), either directly to the transaction module.
• the authentication module transmits an activation command of the targeted transaction module (rather than the code alone) in response to the activation request, which command optionally includes the associated confidential code, which further improves the security of a notch. Any interception of requests and manipulation of the security element 12 becomes impossible.
• the activated transaction module can then finish the implementation of the transaction in a conventional manner.
• the method further comprises a step (d) of transmitting the transaction authorization to a bank server 3 associated with said bank card via the network 20.
• the payment authorization is transferred to the TPE 2 so that the latter can report to the server 3 in a substep 6.
• the TPE 2 when the GPO was issued, the TPE 2 kept a context for the transaction and waited for a new presentation of the terminal 1 to complete the payment in progress;
• the user is invited to present the terminal 1 again to the TPE 2; - Recognizing the terminal 1, the TPE 2 emits again the same GPO that awaits the unlocked instance (the transaction module now activated). This double issue corresponds to official specifications to ensure the security of the transaction;
• the transaction module can then insert payment information and sign the set in its response to the TPE 2;
• the TPE 2 can then finish the transaction via the payment servers 3.
• the present invention also relates to a method of digitizing an electronic card advantageously implemented prior to the method of implementing a transaction as previously described.
• this second method can begin with a step 0. initialization by the management module of the authentication module. For example, the user defines his authentication code.
• the dematerialization of a card is advantageously initiated at the level of the management module, which requires from a server 3 the digitization of at least one electronic card, the associated request comprising at least one identifier of said electronic card.
• the destination server 3 is more particularly a "Token Requestor" TRQ, which can be for example of the SPS "Shared Payment Server” type, shared between several operators (hence the Shared). He plays the role of requiring tokens, namely that he is mandated by end customers to go to a banking organization to provide a virtualized payment technical means with features he specifies.
• TSP Transactional Service Provider
• the TSP is a Token Service Provider who is in charge of providing a virtualized technical payment method previously discussed with the requested features and a number of usage constraints relating to the security policy that it decides. He is also in charge of analyzing the legitimacy of the request since it is he who generates the virtualized payment method.
• the TRQ upon receipt of the request for digitizing the electronic card, the TRQ contacts the TSP corresponding to the type of card (step 2. of the figure 3). It helps the TSP to determine the legitimacy of the request, the latter if necessary accepts dematerialization, generates data representative of said electronic card, and returns them to the TRQ.
• the security element 12 of the terminal 1 implements steps of: - Reception from the server 3 (in this case the TRQ) data representative of said electronic card, said data comprising one or more code ( s) confidential (step 3), so as to install the appropriate transaction module (s) to authorize a transaction on behalf of said electronic card (ie the set of transaction modules) representative of the map);
• the authentication module is then configured for the implementation of the method of implementing a transaction via the mobile terminal 1, using the newly dematerialized card.
• the invention relates to the security element 12 for implementing the method according to the first aspect.
• each transaction module being associated with an electronic card (and the set of transaction modules associated with the same card being representative of said card), and adapted to authorize a transaction for the account of said electronic card when activated on presentation of an associated PIN.
• the security element 12 is configured to:
• an authentication module Receive at the level of an authentication module also stored on the security element 12 (within an activation request also comprising an identifier of the targeted transaction module) a valid unique authentication code obtained via an interface 13 of a terminal 1, the authentication module storing the confidential codes associated with each of the transaction modules, and being itself activatable upon presentation of said authentication code;
• the mobile terminal 1 comprising a data processing module 1 1 and such a security element 12, preferably in the form of a subscriber identification card, but also in the form of a TEE or an optionally removable external component, etc.
• the invention relates to a computer program product comprising code instructions for execution (in particular on the security element 12 of the terminal 1) of a method according to the first aspect of the invention implementation of a transaction from the mobile terminal 1, and storage means readable by a computer equipment (a memory of the security element 12) on which we find this product computer program.

Landscapes

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

Applications Claiming Priority (2)

Publications (1)

Family

ID=55862902

Family Applications (1)

Country Status (4)

Citations (12)

Family Cites Families (9)

• 2015
  • 2015-12-18 FR FR1562797A patent/FR3045896A1/fr not_active Withdrawn
• 2016
  • 2016-12-14 EP EP16826376.2A patent/EP3391316A1/de not_active Ceased
  • 2016-12-14 US US16/063,459 patent/US11429955B2/en active Active
  • 2016-12-14 WO PCT/FR2016/053437 patent/WO2017103484A1/fr active Application Filing

Patent Citations (12)

Non-Patent Citations (4)

Also Published As

Similar Documents

Legal Events