WO2017103484A1 - Procédé de sécurisation d'une transaction depuis un terminal mobile - Google Patents

Procédé de sécurisation d'une transaction depuis un terminal mobile Download PDF

Info

Publication number
WO2017103484A1
WO2017103484A1 PCT/FR2016/053437 FR2016053437W WO2017103484A1 WO 2017103484 A1 WO2017103484 A1 WO 2017103484A1 FR 2016053437 W FR2016053437 W FR 2016053437W WO 2017103484 A1 WO2017103484 A1 WO 2017103484A1
Authority
WO
WIPO (PCT)
Prior art keywords
transaction
module
authentication
request
electronic card
Prior art date
Application number
PCT/FR2016/053437
Other languages
English (en)
Inventor
Arnaud BELLEE
Antoine DUMANOIS
Original Assignee
Orange
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 Orange filed Critical Orange
Priority to EP16826376.2A priority Critical patent/EP3391316A1/fr
Priority to US16/063,459 priority patent/US11429955B2/en
Publication of WO2017103484A1 publication Critical patent/WO2017103484A1/fr

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/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)

Abstract

La présente invention concerne un procédé de mise en œuvre d'une transaction depuis un terminal mobile (1 ) comprenant un module de traitement de données (1 1 ) et un élément de sécurité (12) sur lequel sont stockés une pluralité de modules de transaction, chaque module de transaction étant associé à une carte électronique, et adapté pour autoriser une transaction pour le compte de ladite carte électronique lorsqu'il est activé sur présentation d'un code confidentiel associé, Le procédé étant caractérisé en ce qu'il comprend la mise en œuvre par l'élément de sécurité (12) d'étapes de : (a) réception d'une requête de transaction visant un module de transaction de ladite pluralité; (b) réception par un module d'authentification également stocké sur l'élément de sécurité (12) d'un code d'authentification unique valide obtenu via une interface (13) du terminal (1 ), le module d'authentification stockant les codes confidentiels associés à chacun des modules de transaction, et étant lui-même activable sur présentation dudit code d'authentification; (c) Activation par le module d'authentification du module de transaction visé, et émission d'une autorisation de transaction en réponse à ladite requête de transaction.

Description

PROCEDE DE SECURISATION D'UNE TRANSACTION DEPUIS UN TERMINAL
MOBILE
DOMAINE TECHNIQUE GENERAL
La présente invention concerne le domaine des transactions au moyen de terminaux mobiles.
Plus précisément, elle concerne un procédé pour la mise en œuvre d'une transaction depuis un premier terminal mobile sur lequel est dématérialisée une carte électronique.
ETAT DE L'ART
Des systèmes de paiement dits « dématérialisés » (ou « virtualisés ») sont apparus récemment, pour effectuer des transactions (en particulier des paiements) grâce à une carte bancaire dématérialisée sur un support électronique, par exemple un terminal mobile, apte à effectuer un paiement à distance ou en proximité avec une borne de paiement, par exemple de type sans contact (NFC).
La méthode de virtualisation utilisée par ces systèmes de paiement est par exemple la suivante : le client, ou porteur de la carte, entre les informations bancaires inscrites sur sa carte dans une application du terminal contrôlée par un agrégateur, ou fournisseur, du service de paiement. Par exemple, selon une méthode connue, le porteur photographie sa carte bancaire et renseigne le cryptogramme visuel (le code de sécurité qui se situe typiquement au verso). Alternativement, il entre manuellement ces informations, essentielles à l'identification du porteur de la carte lors d'une transaction.
La banque qui est responsable du compte bancaire associé à la carte valide la virtualisation si elle estime que la personne qui a rentré les informations est réellement le client titulaire de la carte, ou porteur. Le cas échéant, sont chargées au niveau du terminal des données de virtualisation correspondant à la carte, ou jeton (en anglais « token »), chiffrées à l'aide de clés de chiffrage connues uniquement par l'organisme bancaire responsable de la carte (ou par l'organisme gérant le schéma bancaire en délégation de l'organisme bancaire responsable de la carte).
On note que pour une carte bancaire dématérialisée, peuvent être disponibles plusieurs modules de transaction dans le token, en particulier si cette carte est associée en même temps à plusieurs réseaux de paiement, par exemple Visa® et CB® en France, tout comme pour une carte bancaire physique. Les données d'un module de transaction d'un token (données de virtualisation d'une carte bancaire) comprennent :
Un identifiant,
Un code supplémentaire (en général le cryptogramme visuel) ; - Un PIN, c'est-à-dire un code confidentiel personnel, en général à 4 chiffres.
Le troisième doit être connu de l'utilisateur, il lui sera en effet demandé pour valider toute transaction utilisant la carte dématérialisée (en tous cas à partir d'une certaine valeur).
Pour faciliter la gestion d'une pluralité de cartes dématérialisées, il a été proposé l'utilisation d'applications de portefeuille électronique unifié, appelées « wallet ». Une telle application est par exemple décrite dans le document US2015235212. Si l'utilisateur souhaite utiliser l'une de ses cartes pour une transaction, il lui suffit d'ouvrir le wallet comme seule application de paiement, et ce dernier lui propose de choisir entre les cartes (et plus particulièrement entre les modules de transactions des cartes) celle qu'il souhaite utiliser, il n'a plus qu'à saisir le code PIN associé. Les wallets permettent également des fonctions supplémentaires telle que le changement de code PIN.
On constate que le nombre de codes PIN à mémoriser peut être assez élevé s'il a dématérialisé plusieurs cartes. De plus, comme une seule carte peut être associée à plusieurs modules d'un token, cela peut devenir complexe si l'utilisateur veut changer de code PIN. Ce dernier peut par mégarde mettre des codes PIN différents pour plusieurs modules associés à la même carte, et ne pas comprendre pourquoi son code ne marche plus s'il réalise un achat par exemple via Visa au lieu de CB ou inversement.
C'est d'autant plus critique que si l'utilisateur se trompe trois fois de code PIN cela bloque le module associé (et donc bloque partiellement sa carte, ce qui peut être très troublant pour l'utilisateur), et il est alors nécessaire de recommencer toute une procédure de génération de données cryptographique après vérification de l'identité du client (ce dernier doit en général se déplacer à la banque).
Il serait par conséquent souhaitable de disposer d'une nouvelle solution de contrôle des modules des tokens permettant de faciliter la gestion des codes PIN.
PRESENTATION DE L'INVENTION
La présente invention se rapporte ainsi selon un premier aspect à un procédé de mise en œuvre d'une transaction depuis un terminal mobile comprenant un module de traitement de données et un élément de sécurité sur lequel sont stockés une pluralité de modules de transaction, chaque module de transaction étant associé à une carte électronique, et adapté pour autoriser une transaction pour le compte de ladite carte électronique lorsqu'il est activé sur présentation d'un code confidentiel associé,
Le procédé étant caractérisé en ce qu'il comprend la mise en œuvre par l'élément de sécurité d'étapes de :
(a) réception d'une requête de transaction visant un module de transaction de ladite pluralité ;
(b) réception par un module d'authentification également stocké sur l'élément de sécurité d'un code d'authentification unique valide obtenu via une interface du terminal, le module d'authentification stockant les codes confidentiels associés à chacun des modules de transaction, et étant lui-même activable sur présentation dudit code d'authentification ;
(c) Activation par le module d'authentification du module de transaction visé, et émission d'une autorisation de transaction en réponse à ladite requête de transaction.
L'utilisation d'un élément de sécurité tel qu'une carte d'identification d'abonné pour la mise en d'œuvre d'un module d'authentification qui chapeaute les modules de transaction permet de garder le niveau de sécurité maximal en s'affranchissant de la nécessité de gestion de PINs multiple.
De plus on évite le risque de blocage de modules d'un token en cas de mauvaise saisie d'un code confidentiel, et on évite des failles de sécurité liées à l'utilisateur : ce dernier ne connaît plus nécessairement le ou les codes confidentiel, qui restent donc secrets, et qui prévient des vols de carte. Selon d'autres caractéristiques avantageuses et non limitatives :
• le module de traitement de données met en œuvre un module de gestion des modules de transaction, l'étape (b) comprenant la réception par le module d'authentification d'une requête d'activation du module de transaction visé par la requête de transaction, ladite requête d'activation étant émise par ledit module de gestion.
Le présent procédé s'utilise astucieusement avec un module de gestion de type « wallet » facilitant la mise en œuvre de transactions par l'utilisateur.
• l'étape (b) comprend l'émission préalable par le module de transaction visé, à destination du module de gestion, d'une requête de présentation du code confidentiel associé.
Le module de gestion permet ainsi la mise en œuvre du module d'authentification en tant que « wallet companion » sans avoir à modifier les modules de transaction. • le module de gestion est configuré pour requérir et obtenir via l'interface ledit code d'authentification.
En particulier, le module de gestion peut simplement contrôler le module d'authentification en remplaçant la requête de présentation du code confidentiel par une requête de présentation du code unique d'authentification, et ce de façon complètement transparente.
• ladite requête d'activation comprend un identifiant du module de transaction visé, et le code d'authentification obtenu via l'interface ;
• l'étape (c) comprend l'émission par le module d'authentification du code confidentiel associé au module de transaction visé en réponse à la requête d'activation.
· l'étape (c) comprend également la réception par le module de transaction visé du code confidentiel associé.
Dans ce premier mode, le module d'authentification fournit le code confidentiel au module de transaction visé de sorte à simuler un fonctionnement classique.
• l'étape (b) comprend la réception par le module d'authentification d'une requête d'activation du module de transaction visé par la requête de transaction, ladite requête d'activation étant émise par ledit module de transaction visé.
• le module d'authentification est configuré pour requérir et obtenir via l'interface ledit code d'authentification.
Dans ce deuxième mode, le module d'authentification et le module de transaction communiquent uniquement au sein de l'élément de sécurité, ce qui prévient physiquement toute attaque visant à intercepter les requêtes de codes.
• l'étape (b) comprend l'émission par le module d'authentification d'une commande d'activation du module de transaction visé en réponse à la requête d'activation.
Dans ce troisième mode, le module d'authentification contrôle complètement le module de transaction, ce qui permet d'éviter la complexité (et donc les aléas de sécurité) associés à une communication au sein de l'OS mobile.
• le module de transaction visé est associé à une carte bancaire, la requête de transaction étant reçue à l'étape (a) depuis un terminal de paiement électronique en communication sans fil avec le terminal, l'autorisation de transaction étant émise à l'étape (c) à destination du terminal de paiement électronique.
• Le procédé comprend en outre une étape (d) de transmission de l'autorisation de transaction à un serveur bancaire associé à ladite carte bancaire via un réseau.
Un terminal mobile configuré en mode NFC peut simuler une carte bancaire disposant de la même fonctionnalité. Il suffit à l'utilisateur de poser son terminal sur le TPE pour autoriser un paiement avec la carte dématérialisée. • l'élément de sécurité est choisi parmi une carte d'identification d'abonné et un espace d'exécution sécurisé du module de traitement de données du terminal.
Ces éléments de sécurité sont très communs sur les terminaux mobiles, et très fiables.
• le procédé comprend la mise en œuvre préalable d'une digitalisation d'au moins une carte électronique, comprenant la mise en œuvre d'étapes par l'élément de sécurité de :
Réception depuis un serveur de données représentatives de ladite carte électronique, lesdites données comprenant un code confidentiel par module de transaction, de sorte à installer le(s) module(s) de transaction adapté(s) pour autoriser une transaction pour le compte de ladite carte électronique ;
- Réception par le module d'authentification depuis le serveur dudit code confidentiel et d'un identifiant du module de transaction installé ;
- Association par le module d'authentification du code confidentiel audit module de transaction installé, et stockage.
Une telle digitalisation est fiable et ne nécessite aucune intervention de l'utilisateur. Ce dernier peut alors directement utiliser le module d'authentification.
• le procédé comprend préalablement à la réception depuis le serveur de données représentatives de ladite carte électronique :
L'émission par le module de gestion à destination du serveur d'une requête de digitalisation d'au moins une carte électronique comprenant au moins un identifiant de ladite carte électronique ;
La génération par le serveur des données représentatives de ladite carte électronique.
Dans le mode de réalisation utilisant un module de gestion de type wallet, celui-ci peut se charger de la configuration automatique du wallet companion, avec une sécurité optimale.
Selon un deuxième aspect, l'invention concerne un élément de sécurité sur lequel sont stockés une pluralité de modules de transaction, chaque module de transaction étant associé à une carte électronique, et adapté pour autoriser une transaction pour le compte de ladite carte électronique lorsqu'il est activé sur présentation d'un code confidentiel associé,
L'élément de sécurité étant configuré pour :
Recevoir une requête de transaction visant un module de transaction de ladite pluralité ;
Recevoir au niveau d'un module d'authentification également stocké sur l'élément de sécurité un code d'authentification unique valide obtenu via une interface d'un terminal, le module d'authentification stockant les codes confidentiels associés à chacun des modules de transaction, et étant lui-même activable sur présentation dudit code d'authentification ;
- activer au moyen du module d'authentification le module de transaction visé, et pour émission d'une autorisation de transaction en réponse à ladite requête de transaction.
Selon d'autres caractéristiques avantageuses et non limitatives est proposé le terminal mobile comprenant un module de traitement de données et l'élément de sécurité selon le deuxième aspect.
Selon un troisième aspect, l'invention concerne un produit programme d'ordinateur comprenant des instructions de code pour l'exécution d'un procédé selon le premier aspect de l'invention de mise en œuvre d'une transaction depuis un terminal mobile.
Selon un quatrième aspect, l'invention concerne un moyen de stockage lisible par un équipement informatique sur lequel on trouve ce produit programme d'ordinateur.
PRESENTATION DES FIGURES
D'autres caractéristiques et avantages de la présente invention apparaîtront à la lecture de la description qui va suivre d'un mode de réalisation préférentiel. Cette description sera donnée en référence aux dessins annexés dans lesquels :
- la figure 1 est un schéma d'une architecture générale de réseau pour la mise en œuvre de l'invention ;
- la figure 2 représente un mode de réalisation de mise en œuvre d'une transaction via le procédé selon l'invention ;
- la figure 3 représente un mode de réalisation de digitalisation d'une carte électronique via le procédé selon l'invention.
DESCRIPTION DETAILLEE
Architecture
En référence à la figure 1 , l'invention propose un procédé pour la mise en œuvre d'une transaction depuis un terminal mobile 1 , en particulier une transaction utilisant une carte dématérialisée sur le terminal 1 , i.e. une transaction reproduisant l'utilisation d'une carte électronique. On verra également plus loin le procédé préalable associé de dématérialisation de la carte électronique sur le terminal 1 .
La transaction est typiquement une transaction de paiement (c'est-à-dire que la carte dématérialisée sur le terminal 1 est une carte bancaire), en particulier une transaction de proximité initiée par un terminal de paiement électronique (TPE) 2 tel que l'on trouve dans la plupart des points de vente (par exemple de type EFTPOS). Les TPE possèdent en effet pour la plupart des moyens de communication en champ proche (NFC) à l'origine destinés à interagir avec une carte bancaire physique disposant de cette technologie, mais leur permettant également d'interagir avec le terminal mobile 1 .
Le TPE 2 est donc avantageusement d'une part connecté via une liaison sans-fil
(NFC, mais aussi Wi-Fi ou Bluetooth) au terminal mobile 1 , et d'autre part connecté à au moins un serveur bancaire 3 via un réseau 20 (par exemple Internet).
Alternativement, le paiement peut être à distance (i.e. pas de communication en champ proche avec un TPE 2), le terminal mobile 1 pouvant par exemple être connecté via internet (grâce un réseau de communication mobile, typiquement 4G) à un équipement de paiement éloigné.
On comprendra toutefois que le présent procédé n'est pas limité à des transactions de paiement, mais peut concerner toute transaction reproduisant l'utilisation d'une carte électronique sur le terminal 1 , et notamment des télétransmissions de feuilles de soins via Carte Vitale, des validations d'actes médicaux via Carte de Professionnel de Santé, des transmission sécurisée de documents en ligne (par exemple dépôt d'une demande de brevet par carte à puce de mandataire OEB), etc.
Dans la suite de la présente demande, on prendra l'exemple de la transaction de paiement, et l'homme du métier saura transposer à d'autres applications.
Le terminal mobile 1 peut être de n'importe quel type, en particulier smartphone ou des tablettes tactiles. Il comprend un module de traitement de données 1 1 (un processeur), un module de stockage de données 12, une interface utilisateur (IHM) 13 comprenant par exemple des moyens de saisie et des moyens d'affichage (par exemple un écran tactile, on verra plus loin d'autres alternatives).
Le terminal 1 comprend en outre un élément de sécurité 12. De façon préférée, il s'agit d'un élément adapté pour autoriser une connexion du terminal 1 à un réseau de communication mobile, en particulier une carte d'identification d'abonné. Par « carte d'identification d'abonné », on entend tout circuit intégré capable d'assurer les fonctions d'identification d'un abonné à un réseau via des données qui y sont stockées, et tout particulièrement une carte « SIM » (de l'anglais « Subscriber Identity Module »), ou une carte « e-UICC » (pour « (embedded)-Universal Integrated Circuit Card ») comprenant des moyens de traitement de données sous la forme d'un microcontrôleur et de la mémoire de type « EEPROM » (pour « Electrically-Erasable Programmable Read-Only Memory »), ou flash. L'invention n'est pas limitée à ce type de module de sécurité. Ainsi, dans un autre exemple de réalisation, le module de sécurité 12 est une zone mémoire sécurisée du terminal mobile tel un composant « TEE » (de l'anglais « Trusted Execution Environment ») embarqué dans le module de traitement de données 1 1 , ou un élément matériel dédié du terminal 1 (par exemple un microcontrôleur, une puce « eSE » pour « (embedded)-Secure Elément » ou n'importe quel « Secure Component GP (GlobalPIatform) »), voire un composant amovible de type microSD (« SD » pour Secure Digital).
Le serveur 3 du réseau 20 désigne une plateforme de gestion des transactions, et comprend un module de traitement de données 31 , par exemple un processeur et un module de stockage de données 32 tel qu'un disque dur ou de façon préférée un HSM (pour « Hardware Security Module »).
Comme l'on verra plus loin, on comprendra que la notion de « serveur 3 » peut englober une pluralité de serveurs bancaires distincts connectés et adaptés pour communiquer ensemble.
Elément de sécurité
De façon connue, sont stockés sur l'élément de sécurité 12 une pluralité de modules de transaction, chaque module de transaction étant associée à une carte électronique (i.e. un ou plusieurs modules de transaction constituent une version dématérialisée de la carte électronique), et adapté pour autoriser une transaction pour le compte de ladite carte électronique lorsqu'il est activé sur présentation d'un code confidentiel associé. Plus précisément, les modules de transaction sont avantageusement organisés en un ou plusieurs ensembles chacun représentatif d'une carte électronique. En d'autres termes, chaque ensemble regroupe les modules de transaction associés à la même carte électronique.
Dans le cas de transactions de paiement, les cartes électroniques sont des cartes bancaires, et les ensembles de modules de transaction constituent des « tokens » comme évoqué, chaque token étant ainsi représentatif d'une carte de bancaire. Dans la suite de la présente description, on prendra l'exemple de modules de tokens. Dans le cas d'autres types de transactions, d'autres types de cartes électroniques peuvent être dématérialisées, et de façon générale toute carte à puce permettant une authentification forte, c'est-à-dire dont la possession associée à la connaissance d'un code confidentiel permet de valider l'identité de l'utilisateur et son autorisation à réaliser une action.
De façon générale, un module de transaction contient (entre autres):
- un identifiant de la carte dématérialisée,
- le cas échéant un code supplémentaire (par exemple le cryptogramme visuel), un code confidentiel.
Un module de transaction partie d'un token, une fois installé (voir plus loin) présente un identifiant applicatif en deux parties : un préfixe désignant l'origine de l'instance (Visa®, CB®, Mastercard®, Amex®, etc.) et un suffixe unique.
La présente solution se distingue en ce qu'est également stocké sur l'élément de sécurité 12 un module d'authentification stockant les codes confidentiels associés à chacun des modules de transaction, et étant lui-même activable sur présentation d'un code d'authentification.
Plus précisément, le module d'authentification est un « porte-clé » contenant les codes confidentiels, qui agit comme broker vis-à-vis des modules de transaction. Comme on va le voir, cela permet en toute sécurité de gérer une pluralité de modules de transaction avec une clé unique, y compris des modules de transactions avec des fonctionnements différents : les différents codes confidentiels peuvent avoir des longueurs différentes, des spécifications différentes, etc. De plus il permet d'éviter par exemple tout risque de bloquer un module de transaction en cas de trois faux codes : en effet, le module d'authentification ne peut pas se tromper de code. Si l'utilisateur se trompe de code d'authentification, alors le module d'authentification peut être bloqué, cela n'impose pas de refaire la carte (aucun module de transaction n'est bloqué) : il suffit par exemple d'aller en boutique de l'opérateur et de présenter une pièce d'identité pour obtenir ce déblocage selon un mode très sécurisé de réinitialisation à distance, bien connu de l'homme du métier.
On note par ailleurs qu'un module de sécurité, tel qu'une carte d'identification d'abonné est un dispositif physique de confiance quasi-impossible à infecter par un Cheval de Troie, car l'installation d'applications dans ces cartes est limitée à des entités bien identifiées, et contrôlées par l'opérateur et/ou ou l'émetteur du service en lien avec le fabricant de l'élément de sécurité 12. Dans un mode de réalisation préféré, le module de traitement de données 1 1 (processeur « non-sécurisé ») du terminal 1 met en œuvre un module de gestion de type « wallet », que complète très astucieusement le module d'authentification 1 appelé alors « wallet companion ». On verra plus loin leurs interactions.
Procédé de mise en œuvre de la transaction
En référence à la figure 2 va être décrit un exemple de réalisation du présent procédé selon l'invention. On comprendra que cet exemple, dans lequel un utilisateur a dématérialisé trois cartes pour un total de six modules de transaction, n'est qu'illustratif.
Dans une première étape (a), l'élément de sécurité 12 reçoit une requête de transaction visant un module de transaction de ladite pluralité, par exemple émise depuis un TPE 2 en connexion avec le terminal 1 , en particulier une fois que l'utilisateur ait signalé vouloir mettre en œuvre une transaction via une carte de paiement dématérialisée qu'il a choisi par exemple sur son wallet. Cette étape est référencée 1 . sur la figure 2.
On note que le TPE 2 peut dans cette étape interroger la matrice des moyens de paiement actifs, de sorte à sélectionner (à l'aide d'un filtre) l'instance (le module de transaction) qui sera en charge de la transaction. Par exemple, à supposer que l'utilisateur ait dématérialisé une carte EMV (Entropay MasterCard Visa) associée à la banque B3, il peut disposer de deux modules de transaction associés (référencés T3a/T3c), par exemple respectivement associés à Visa® et CB®. Si le TPE 2 est un terminal étranger n'acceptant que Amex® et Visa®, il choisit ce dernier et vise le module T3a en émettant une GPO (« Get Processing Option ») précisant l'action qu'il souhaite utiliser (ici le paiement d'un montant donné).
Dans une étape (b), le module d'authentification reçoit le code d'authentification unique valide obtenu via une interface 13 du terminal 1 . Cette étape peut faire l'objet de plusieurs modes de réalisation.
Dans un premier mode conforme à la figure 2 où est installé sur le terminal 1 (et exécuté via son module de traitement classique 1 1 ) un wallet, c'est-à-dire un module de gestion des modules de transaction, c'est ce module de gestion qui sollicite le module d'authentification en lui envoyant une requête d'activation du module de transaction visé par la requête de transaction. De façon préférée, les communications entre le module de gestion et le module d'authentification (et de façon générale les communications entre le module de gestion et tous les modules présents sur l'élément de sécurité 12) sont sécurisées (chiffrées) de sorte à prévenir toute interception ou manipulation des données échangées.
L'étape (b) comprend alors une sous-étape 2. préalable d'émission par le module de transaction visé d'une requête de présentation du code confidentiel adressée au module de gestion (wallet), de façon totalement naturelle et habituelle.
Toutefois, au lieu de demander à l'utilisateur le code confidentiel associé au module de transaction ayant émis la requête (comme il le ferait habituellement), le module de gestion demande le code d'authentification du module d'authentification. En d'autres termes, le module de gestion est configuré pour requérir et obtenir via l'interface 13 ledit code d'authentification. Il est à noter que le code peut être saisi directement via un clavier (notamment tactile) de l'interface 13, mais qu'également le code peut être généré suite à la vérification de l'identité de l'utilisateur sur le terminal 1 , par exemple via un lecteur d'empreintes digitales, un module de reconnaissance vocale, ou autre. A ce titre, le code d'authentification peut être seulement une commande sous une forme sécurisée (par exemple un message contenant une clé), représentative de l'identité vérifiée de l'utilisateur, et donc de l'autorisation à activer le module d'authentification.
Le module de gestion génère alors ladite requête d'activation, cette dernière comprenant avantageusement un identifiant du module de transaction visé (reçu depuis ce dernier via la requête de présentation de son code confidentiel), et le code d'authentification obtenu via l'interface 13. Il s'agit de la sous-étape 3. représentée sur la figure 2.
On note que le présent mode de réalisation permet d'utiliser des modules de transactions d'origine (tel que fournis par un serveur 3 par exemple), ces derniers ne sachant même pas qu'ils sont contrôlés par un module d'authentification. Il suffit juste de configurer adéquatement le module de gestion. Comme expliqué, ce mode de réalisation supporte n'importe quelles exigences des modules de transaction, et en particulier des structures et des longueurs variées de codes confidentiels. Aucune normalisation n'est nécessaire.
Alternativement, dans un second mode de réalisation, le module de transaction et le module d'authentification peuvent communiquer en direct, en particulier au sein de l'élément sécurisé 12 (en d'autres termes le module d'authentification reçoit la requête d'activation du module de transaction visé par la requête de transaction, ladite requête d'activation étant émise par ledit module de transaction visé et remplaçant la requête de présentation du code confidentiel associé), cela impliquant que le module d'authentification soit lui-même configuré pour requérir et obtenir via l'interface 13 ledit code d'authentification. On note que sont possibles des configurations hybrides utilisant un module de gestion par lequel ne transitent que certaines des requêtes (par exemple celle de présentation du code confidentiel associé au module de transaction visé, tout en ayant le module d'authentification requérant lui-même son code d'authentification).
Sur réception du code d'authentification valide (sinon il renvoie un message d'erreur, et de façon préférée se bloque au bout de trois erreurs) le module d'authentification s'active, et dans une étape (c) il active le module d'authentification du module de transaction visé, de sorte que ce dernier émette in fine une autorisation de transaction en réponse à ladite requête de transaction.
Dans le premier mode de réalisation, le module d'authentification émet le code confidentiel associé au module de transaction visé en réponse à la requête d'activation, soit à destination du module de gestion de type wallet qui le renvoie au module de transaction (sous-étape 4. représenté à la figure 2), soit directement au module de transaction.
Alternativement (en particulier dans le second mode de réalisation où le module de transaction et le module d'authentification communiquent directement de sorte qu'il n'y a pas nécessairement de requête de présentation d'un code), le module d'authentification émet d'une commande d'activation du module de transaction visé (plutôt que le code seul) en réponse à la requête d'activation, commande qui comprend le cas échéant le code confidentiel associé, ce qui permet d'améliorer encore la sécurité d'un cran. Toute interception de requêtes et manipulation de l'élément de sécurité 12 devient impossible.
Le module de transaction activé peut alors finir la mise en œuvre de la transaction de manière classique. De façon préférée, dans le cas de paiements, le procédé comprend à ce titre en outre une étape (d) de transmission de l'autorisation de transaction à un serveur bancaire 3 associé à ladite carte bancaire via le réseau 20. Typiquement, dans la sous-étape 5. l'autorisation de paiement est transférée au TPE 2 de sorte que ce dernier puisse rapporter auprès du serveur 3 dans une sous-étape 6.
Plus précisément, il est généralement prévu que :
- lors de l'émission de la GPO, le TPE 2 a gardé un contexte pour la transaction et s'est mis en attente d'une nouvelle présentation de du terminal 1 pour terminer le paiement en cours ;
- suite à l'entrée du code d'authentification, l'utilisateur est invité à présenter le terminal 1 à nouveau au TPE 2 ; - reconnaissant le terminal 1 , le TPE 2 émet à nouveau la même GPO qu'attend l'instance déverrouillée (le module de transaction visé à présent activé). Cette double émission correspond à des spécifications officielle pour s'assurer de la sûreté de la transaction ;
- le module de transaction peut alors insérer des informations de paiement et signer l'ensemble dans sa réponse vers le TPE 2 ;
- le TPE 2 peut ensuite finir la transaction via les serveurs de paiement 3.
Procédé de digitalisation d'une carte électronique
En référence à la figure 3, la présente invention concerne également un procédé de digitalisation d'une carte électronique avantageusement mis en œuvre préalablement au procédé de mise en œuvre d'une transaction tel que précédemment décrit.
Si c'est la première carte dématérialisée au niveau du terminal 1 , ce deuxième procédé peut commencer par une étape 0. d'initialisation par le module de gestion du module d'authentification. Par exemple, l'utilisateur défini son code d'authentification.
La dématérialisation d'une carte est avantageusement initiée au niveau du module de gestion, qui requiert auprès d'un serveur 3 la digitalisation d'au moins une carte électronique, la requête associée comprenant au moins un identifiant de ladite carte électronique.
Dans le cas des cartes bancaires, cette étape est bien connue : on peut par exemple prendre en photo la carte physique. Le serveur destinataire 3 est plus particulièrement un TRQ « Token Requestor », qui peut être par exemple de type SPS « Shared Payment Server », partagé entre plusieurs opérateurs (d'où le Shared). Il joue le rôle de requérir des tokens, à savoir qu'il est mandaté par des clients finaux pour aller demander à un organisme bancaire de lui fournir un moyen technique virtualisé de paiement avec des caractéristiques qu'il précise.
Pour cela il contacte un TSP (étape 1 . de la figure 3) qui est lui-même en communication avec les serveurs bancaires évoqués précédemment. Le TSP est un Token Service Provider qui est lui en charge de fournir un moyen technique de paiement virtualisé précédemment discuté avec les caractéristiques demandées et un certain nombre de contraintes d'utilisation relatives à la politique de sécurité qu'il décide. Il est aussi en charge d'analyser la légitimité de la demande puisque c'est lui qui génère le moyen de paiement virtualisé.
Plus précisément, sur réception de la requête de digitalisation de la carte électronique, le TRQ contacte le TSP correspondant au type de carte (étape 2. de la figure 3). Il aide le TSP à déterminer la légitimité de la demande, ce dernier le cas échéant accepte la dématérialisation, génère des données représentatives de ladite carte électronique, et les renvoie au TRQ.
A partir de là l'élément de sécurité 12 du terminal 1 met en œuvre des étapes de : - Réception depuis le serveur 3 (en l'espèce le TRQ) des données représentatives de ladite carte électronique, lesdites données comprenant un ou plusieurs code(s) confidentiel(s) (étape 3.), de sorte à installer le(s) module(s) de transaction adapté(s) pour autoriser une transaction pour le compte de ladite carte électronique (i.e. l'ensemble des modules de transaction représentatifs de la carte) ;
Réception par le module d'authentification depuis le serveur 3 desdit code(s) confidentiel(s) et d'un identifiant du/des module(s) de transaction installé(s) (étape 4.) ; et
- Association par le module d'authentification du/des code(s) confidentiel(s) au(x)dit(s) module(s) de transaction installé(s), et stockage.
Le module d'authentification est alors configuré pour la mise en œuvre du procédé de mise en œuvre d'une transaction via le terminal mobile 1 , en utilisant la carte nouvellement dématérialisée.
Elément de sécurité et terminal
Selon un deuxième aspect, l'invention concerne l'élément de sécurité 12 pour la mise en œuvre du procédé selon le premier aspect.
Sur ce dernier sont stockés une pluralité de modules de transaction, chaque module de transaction étant associé à une carte électronique (et l'ensemble de modules de transaction associés à une même carte étant représentatif de ladite carte), et adapté pour autoriser une transaction pour le compte de ladite carte électronique lorsqu'il est activé sur présentation d'un code confidentiel associé.
L'élément de sécurité 12 est configuré pour :
Recevoir une requête de transaction visant un module de transaction de ladite pluralité (et le cas échéant émettre depuis le module de transaction visé une requête de présentation du code confidentiel associé) ;
Recevoir au niveau d'un module d'authentification également stocké sur l'élément de sécurité 12 (au sein d'une requête d'activation comprenant également un identifiant du module de transaction visé) un code d'authentification unique valide obtenu via une interface 13 d'un terminal 1 , le module d'authentification stockant les codes confidentiels associés à chacun des modules de transaction, et étant lui- même activable sur présentation dudit code d'authentification ;
- activer au moyen du module d'authentification le module de transaction visé, et pour émission d'une autorisation de transaction en réponse à ladite requête de transaction.
Est également proposé le terminal mobile 1 comprenant un module de traitement de données 1 1 et un tel élément de sécurité 12, avantageusement sous la forme d'une carte d'identification d'abonné, mais également sous la forme d'un TEE ou d'un composant externe éventuellement amovible, etc.
Produit programme d'ordinateur Selon un troisième et un quatrième aspects, l'invention concerne un produit programme d'ordinateur comprenant des instructions de code pour l'exécution (en particulier sur l'élément de sécurité 12 du terminal 1 ) d'un procédé selon le premier aspect de l'invention de mise en œuvre d'une transaction depuis le terminal mobile 1 , ainsi que des moyens de stockage lisibles par un équipement informatique (une mémoire de l'élément de sécurité 12) sur lequel on trouve ce produit programme d'ordinateur.

Claims

REVENDICATIONS
1. Procédé de mise en œuvre d'une transaction depuis un terminal mobile (1 ) comprenant un module de traitement de données (1 1 ) et un élément de sécurité (12) sur lequel sont stockés une pluralité de modules de transaction, chaque module de transaction étant associé à une carte électronique, et adapté pour autoriser une transaction pour le compte de ladite carte électronique lorsqu'il est activé sur présentation d'un code confidentiel associé,
Le procédé étant caractérisé en ce qu'il comprend la mise en œuvre par l'élément de sécurité (12) d'étapes de :
(a) réception d'une requête de transaction visant un module de transaction de ladite pluralité ;
(b) réception par un module d'authentification également stocké sur l'élément de sécurité (12) d'un code d'authentification unique valide obtenu via une interface (13) du terminal (1 ), le module d'authentification stockant les codes confidentiels associés à chacun des modules de transaction, et étant lui-même activable sur présentation dudit code d'authentification ;
(c) Activation par le module d'authentification du module de transaction visé, et émission d'une autorisation de transaction en réponse à ladite requête de transaction.
2. Procédé selon la revendication 1 , dans lequel le module de traitement de données (1 1 ) met en œuvre un module de gestion des modules de transaction, l'étape (b) comprenant la réception par le module d'authentification d'une requête d'activation du module de transaction visé par la requête de transaction, ladite requête d'activation étant émise par ledit module de gestion.
3. Procédé selon la revendication 2, dans lequel l'étape (b) comprend l'émission préalable par le module de transaction visé, à destination du module de gestion, d'une requête de présentation du code confidentiel associé.
4. Procédé selon la revendication 3, dans lequel le module de gestion est configuré pour requérir et obtenir via l'interface (13) ledit code d'authentification.
5. Procédé selon la revendication 4, dans lequel ladite requête d'activation comprend un identifiant du module de transaction visé, et le code d'authentification obtenu via l'interface (13).
6. Procédé selon l'une des revendications 2 à 5, dans lequel l'étape (c) comprend l'émission par le module d'authentification du code confidentiel associé au module de transaction visé en réponse à la requête d'activation.
7. Procédé selon la revendication 6, dans lequel l'étape (c) comprend également la réception par le module de transaction visé du code confidentiel associé.
8. Procédé selon la revendication 1 , dans lequel l'étape (b) comprend la réception par le module d'authentification d'une requête d'activation du module de transaction visé par la requête de transaction, ladite requête d'activation étant émise par ledit module de transaction visé.
9. Procédé selon la revendication 8, dans lequel le module d'authentification est configuré pour requérir et obtenir via l'interface (13) ledit code d'authentification.
10. Procédé selon l'une des revendications 2 à 5 et 8 à 9, dans lequel l'étape (b) comprend l'émission par le module d'authentification d'une commande d'activation du module de transaction visé en réponse à la requête d'activation.
11. Procédé selon l'une des revendications 1 à 10, dans lequel le module de transaction visé est associé à une carte bancaire, la requête de transaction étant reçue à l'étape (a) depuis un terminal de paiement électronique (2) en communication sans fil avec le terminal (1 ), l'autorisation de transaction étant émise à l'étape (c) à destination du terminal de paiement électronique (2).
12. Procédé selon la revendication 1 1 , comprenant en outre une étape (d) de transmission de l'autorisation de transaction à un serveur bancaire (3) associé à ladite carte bancaire via un réseau (20).
13. Procédé selon l'une des revendications 1 à 12, dans lequel l'élément de sécurité (12) est choisi parmi une carte d'identification d'abonné et un espace d'exécution sécurisé du module de traitement de données (1 1 ) du terminal (1 ).
14. Procédé selon l'une des revendications 1 à 13, dans lequel ladite pluralité de modules de transaction est organisée en un ou plusieurs ensembles tels que tous les modules de transaction d'un ensemble sont associés à la même carte électronique, de sorte que chaque ensemble de modules de transaction est représentatif de ladite carte électronique.
15. Procédé selon l'une des revendications 1 à 13, comprenant la mise en œuvre préalable d'une digitalisation d'au moins une carte électronique, comprenant la mise en œuvre d'étapes par l'élément de sécurité (12) de :
Réception depuis un serveur (3) de données représentatives de ladite carte électronique, lesdites données comprenant un ou plusieurs codes confidentiels, de sorte à installer le ou les modules de transaction adaptés pour autoriser une transaction pour le compte de ladite carte électronique ;
- Réception par le module d'authentification depuis le serveur (3) dudit code confidentiel et d'un identifiant du module de transaction installé ;
- Association par le module d'authentification du code confidentiel audit module de transaction installé, et stockage.
16. Procédé selon la revendication 15 en combinaison avec la revendication 2, comprenant préalablement à la réception depuis le serveur (3) de données représentatives de ladite carte électronique :
L'émission par module de gestion à destination du serveur (3) d'une requête de digitalisation d'au moins une carte électronique comprenant au moins un identifiant de ladite carte électronique ;
La génération par le serveur (3) des données représentatives de ladite carte électronique.
17. Elément de sécurité (12) sur lequel sont stockés une pluralité de modules de transaction, chaque module de transaction étant associé à une carte électronique, et adapté pour autoriser une transaction pour le compte de ladite carte électronique lorsqu'il est activé sur présentation d'un code confidentiel associé, l'élément de sécurité (12) étant configuré pour :
Recevoir une requête de transaction visant un module de transaction de ladite pluralité ; Recevoir au niveau d'un module d'authentification également stocké sur l'élément de sécurité (12) un code d'authentification unique valide obtenu via une interface (13) d'un terminal (1 ), le module d'authentification stockant les codes confidentiels associés à chacun des modules de transaction, et étant lui-même activable sur présentation dudit code d'authentification ;
- activer au moyen du module d'authentification le module de transaction visé, et pour émission d'une autorisation de transaction en réponse à ladite requête de transaction.
18. Terminal mobile (1 ) comprenant un module de traitement de données (1 1 ) et un élément de sécurité selon la revendication 17.
19. Produit programme d'ordinateur comprenant des instructions de code pour l'exécution d'un procédé selon l'une des revendications 1 à 16 de mise en œuvre d'une transaction depuis un terminal mobile (1 ), lorsque ledit programme est exécuté par un ordinateur.
20. Moyen de stockage lisible par un équipement informatique sur lequel un produit programme d'ordinateur comprend des instructions de code pour l'exécution d'un procédé selon l'une des revendications 1 à 16 de mise en œuvre d'une transaction depuis un terminal mobile (1 ).
PCT/FR2016/053437 2015-12-18 2016-12-14 Procédé de sécurisation d'une transaction depuis un terminal mobile WO2017103484A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP16826376.2A EP3391316A1 (fr) 2015-12-18 2016-12-14 Procédé de sécurisation d'une transaction depuis un terminal mobile
US16/063,459 US11429955B2 (en) 2015-12-18 2016-12-14 Method for securing a transaction from a mobile terminal

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1562797A FR3045896A1 (fr) 2015-12-18 2015-12-18 Procede de securisation d'une transaction depuis un terminal mobile
FR1562797 2015-12-18

Publications (1)

Publication Number Publication Date
WO2017103484A1 true WO2017103484A1 (fr) 2017-06-22

Family

ID=55862902

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2016/053437 WO2017103484A1 (fr) 2015-12-18 2016-12-14 Procédé de sécurisation d'une transaction depuis un terminal mobile

Country Status (4)

Country Link
US (1) US11429955B2 (fr)
EP (1) EP3391316A1 (fr)
FR (1) FR3045896A1 (fr)
WO (1) WO2017103484A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013092796A1 (fr) * 2011-12-21 2013-06-27 Morpho Procédé de routage au sein d'un terminal mobile émulant une carte de paiement sans contact
CN104602224A (zh) * 2014-12-31 2015-05-06 浙江融创信息产业有限公司 一种基于nfc手机swp-sim卡的空中开卡方法

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5589855A (en) * 1992-08-14 1996-12-31 Transaction Technology, Inc. Visually impaired customer activated terminal method and system
US6598032B1 (en) * 2000-03-10 2003-07-22 International Business Machines Corporation Systems and method for hiding from a computer system entry of a personal identification number (pin) to a smart card
US7374079B2 (en) * 2003-06-24 2008-05-20 Lg Telecom, Ltd. Method for providing banking services by use of mobile communication system
US20070206743A1 (en) * 2006-02-23 2007-09-06 Industrial Technology Research Institute System and method for facilitating transaction over a communication network
US9734498B2 (en) * 2011-05-11 2017-08-15 Riavera Corp Mobile image payment system using short codes
DE102012108645A1 (de) * 2012-09-14 2014-03-20 Paschalis Papagrigoriou Vorrichtung zur Absicherung elektronischer Transaktionen mit sicheren elektronischen Signaturen
CA3126471A1 (fr) 2012-10-17 2014-04-17 Royal Bank Of Canada Virtualisation et traitement securise de donnees

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013092796A1 (fr) * 2011-12-21 2013-06-27 Morpho Procédé de routage au sein d'un terminal mobile émulant une carte de paiement sans contact
CN104602224A (zh) * 2014-12-31 2015-05-06 浙江融创信息产业有限公司 一种基于nfc手机swp-sim卡的空中开卡方法

Also Published As

Publication number Publication date
EP3391316A1 (fr) 2018-10-24
US20180374084A1 (en) 2018-12-27
FR3045896A1 (fr) 2017-06-23
US11429955B2 (en) 2022-08-30

Similar Documents

Publication Publication Date Title
EP3243177B1 (fr) Méthode de traitement d'une autorisation de mise en oeuvre d'un service, dispositifs et programme d'ordinateur correspondant
EP3113099B1 (fr) Conteneur de paiement, procédé de création, procédé de traitement, dispositifs et programmes correspondants
US9049194B2 (en) Methods and systems for internet security via virtual software
WO2014009646A1 (fr) Entite electronique securisee pour l'autorisation d'une transaction
EP3241137B1 (fr) Procede mis en oeuvre dans un document d'identite et document d'identite associe
US20180039988A1 (en) Methods for controlling access to a financial account
FR2987199A1 (fr) Securisation d'une transmission de donnees.
FR3021799A1 (fr) Methode d'identification, dispositif et programme correspondant
EP3163487A1 (fr) Procédé de sécurisation de traitement de données transactionnelles, terminal et programme d'ordinateur correspondant
FR3020167A1 (fr) Dispositif de traitement de donnees en provenance de carte a memoire sans contact, methode et programme d'ordinateur correspondant
EP3542335A1 (fr) Procédé de traitement de données transactionnelles, terminal de communication, lecteur de cartes et programme correspondant
WO2017103484A1 (fr) Procédé de sécurisation d'une transaction depuis un terminal mobile
EP3113094B1 (fr) Procédé de traitement de données transactionnelles, dispositif et programme correspondant
EP2407920A1 (fr) Serveur, terminal et procédé de transaction sécurisée
WO2018024980A1 (fr) Procédé de mise en œuvre d'une transaction depuis un moyen de transaction électronique
EP4078495A1 (fr) Procédé et dispositif de gestion d'une autorisation d'accès à un service de paiement fourni à un utilisateur
WO2023274979A1 (fr) Procédé d'authentification de transaction utilisant deux canaux de communication
FR3140688A1 (fr) Procédé de gestion de données d’authentification permettant l’accès à un service d’un utilisateur depuis un terminal
WO2018229089A1 (fr) Procédé de gestion d'identifiants de fidélité, procédé de traitement de données de fidélité, serveur, dispositif de transaction et programmes correspondants
FR3031609A1 (fr) Procede de traitement d'une transaction a partir d'un terminal de communication
FR3031608A1 (fr) Methode de traitement d'une autorisation de mise en œuvre d'un service, dispositifs et programme d'ordinateur correspondant
FR2994006A1 (fr) Procede et dispositif pour conduire une transaction aupres d'un distributeur automatique
FR3031610A1 (fr) Procede de traitement d'une transaction a partir d'un terminal de communication
FR2998398A1 (fr) Procede d'activation d'un service en ligne a partir d'un equipement mobile
FR2967513A1 (fr) Serveur de transaction nfc

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16826376

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2016826376

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2016826376

Country of ref document: EP

Effective date: 20180718