EP2979237A1 - Procédé de délivrance d'une assertion de localisation - Google Patents

Procédé de délivrance d'une assertion de localisation

Info

Publication number
EP2979237A1
EP2979237A1 EP14713484.5A EP14713484A EP2979237A1 EP 2979237 A1 EP2979237 A1 EP 2979237A1 EP 14713484 A EP14713484 A EP 14713484A EP 2979237 A1 EP2979237 A1 EP 2979237A1
Authority
EP
European Patent Office
Prior art keywords
location
address
assertion
user
server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
EP14713484.5A
Other languages
German (de)
English (en)
Inventor
Michel Leger
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Banks and Acquirers International Holding SAS
Original Assignee
Ingenico Group SA
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 Ingenico Group SA filed Critical Ingenico Group SA
Publication of EP2979237A1 publication Critical patent/EP2979237A1/fr
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4014—Identity check for transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/405—Establishing or using transaction specific rules
    • 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/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/108—Remote banking, e.g. home banking
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/105—Multiple levels of security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/52—Network services specially adapted for the location of the user terminal

Definitions

  • the invention relates to securing payments. More particularly, the invention relates to securing payments made online.
  • Online payments represent a growing share of payments made daily around the world. They can be made either through payment providers, such as Paypal TM, or by making use of traditional banking organizations.
  • This method suffers from two disadvantages: on the one hand it forces the customer to provide his telephone number to the bank before any transaction and in a secure manner (this is done mostly visually with a bank advisor); on the other hand, this method only works if the customer's bank is also the bank that manages the transaction on behalf of the merchant. This is rarely the case, especially abroad. Indeed, a large part of fraud is carried out abroad. Thus, the aforementioned method is not very effective in this case.
  • the method proposed by the inventors does not pose these problems of the prior art. Indeed, it is proposed a method of locating a user making a payment in CNP mode.
  • the invention relates to a method for providing a location assertion of a transactional device, having requested, from a server, via a communication network, an acceptance of a financial transaction involving the use of bank details.
  • this process comprises: a step of receiving a transactional request, resulting from said transactional device, comprising at least one identifier of a user to whom said bank details are associated;
  • the invention makes it possible to validate a bank transaction (such as an online payment) on the basis of the location of the terminal performing the transaction, by using the IP address of this terminal.
  • the proposed method is therefore much simpler and less restrictive to implement than authorization methods based on a MAC address.
  • said method further comprises: a step of obtaining a route taken by data packets to reach said IP address associated with said transactional device, issuing a list of borrowed IP addresses;
  • the invention makes it possible to trace the path taken by a data packet that wishes to join the IP address associated with the terminal. This provides additional data to protect against theft or theft of IP address.
  • said method further comprises:
  • the invention makes it possible to classify the locations at risk and to define thresholds below which transactions are not accepted.
  • said step of issuing the location assertion is performed when none of the transport locations is part of a prohibited location list.
  • said method further comprises: a step of obtaining a current location of a mobile terminal associated with said user;
  • the invention makes it possible to couple the location of the transaction terminal to the location of another device in the possession of the user. It is therefore a double control that is effective because in most cases, transactions are passed from the user's home. At this home, the probability that the user's mobile terminal is connected to the residential home gateway is strong. In this case, the location of the terminals will be identical and will be obtained very quickly.
  • the invention also relates to a server for providing a location assertion of a transactional device, which has requested, from a server, through a communication network, an acceptance of a financial transaction involving the use of bank details.
  • a server for providing a location assertion of a transactional device, which has requested, from a server, through a communication network, an acceptance of a financial transaction involving the use of bank details.
  • a server comprises:
  • the various steps of the methods according to the invention are implemented by one or more software or computer programs, comprising software instructions intended to be executed by a data processor of a relay module according to the invention. invention and being designed to control the execution of the various process steps.
  • the invention is also directed to a program that can be executed by a computer or a data processor, which program includes instructions for controlling the execution of the steps of a method as mentioned above.
  • This program can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other form desirable shape.
  • the invention also provides a data carrier readable by a data processor, and including instructions of a program as mentioned above.
  • the information carrier may be any entity or device capable of storing the program.
  • the medium may comprise storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording medium, for example a floppy disk or a disk. hard.
  • the information medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means.
  • the program according to the invention can be downloaded in particular on an Internet type network.
  • the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question.
  • the invention is implemented by means of software and / or hardware components.
  • module may correspond in this document as well to a software component, a hardware component or a set of hardware and software components.
  • a software component corresponds to one or more computer programs, one or more subroutines of a program, or more generally to any element of a program or software capable of implementing a function or a program. set of functions, as described below for the module concerned.
  • Such a software component is executed by a data processor of a physical entity (terminal, server, gateway, set-top-box, router, etc.) and is capable of accessing the hardware resources of this physical entity (memories, supports recording, communication bus, input / output electronic boards, user interfaces, etc.).
  • a hardware component corresponds to any element of a hardware set (or hardware) able to implement a function or a set of functions, as described below for the module concerned. It can be a programmable hardware component or with an integrated processor for executing software, for example an integrated circuit, a smart card, a memory card, an electronic card for executing a firmware, etc.
  • Figure 1 depicts an embodiment of the location assertion delivery method
  • Figure 2 depicts an embodiment derived from the location assertion delivery method
  • FIG. 3 depicts a complementary embodiment of the location assertion delivery method
  • FIG. 4 illustrates an architecture of a server able to implement a location assertion delivery method
  • FIG. 5 illustrates an architecture of a client capable of implementing a location assertion issuing method.
  • the purpose of the proposed method is to ensure that, when using credit card data in CNP mode, it is still possible to obtain information on the holder of the payment card.
  • the goal is to move from a CNP mode to a mode where the carrier map is located without changing the habits of the cardholder and in any discretion.
  • the IP address from which the transaction is initiated is obtained.
  • this IP address is compared to a list of allowed IP addresses, list maintained by the entity in charge of carrying out the payment transactions (it can be a bank, an institution or an intermediary institution, such as a payment service manager).
  • the IP address is not the data to validate the transaction.
  • the data validating or not the transaction is a location.
  • the IP address of the terminal from which the transaction is made is always obtained, but this IP address serves only as a means of obtaining a location.
  • the location becomes the information to deliver the transaction authorization (that is, to validate that a transaction can be performed).
  • This embodiment has several advantages. In the first place, this embodiment makes it possible to overcome the problems of address translations. Indeed, it is very common that the device that is used to perform a bank transaction be behind a gateway or a proxy. However, it can be complex to recover an IP address that is exploitable. In general, the IP address retrieved is the IP address of the gateway, but this is not assured.
  • this embodiment makes it possible not to limit the number of devices that can be used to carry out transactions. More specifically, unlike a MAC address, for example, an IP address is often shared by multiple devices (for example, the address of a home gateway is shared by all user devices connected to that home gateway. ). It is therefore not necessary to retrieve all the MAC addresses of the devices that can be used.
  • the location used is that of the city of the IP address. In other embodiments, the location may be more precise, like for example a street in the city. The accuracy obtained depends on the one hand on the available databases and on the other hand on the legal constraints in force in the geographical areas where the invention is implemented.
  • the IP address (@IP) of the terminal (Dt) from which the transaction is performed is used.
  • the terminal from which the transaction is made is not a payment terminal (in the sense of a terminal in which the bank card is inserted and in which a PIN code is entered). It is a terminal such as a computer or a tablet or a smartphone and not a payment terminal such as those installed at merchants.
  • the method implemented comprises:
  • a step of receiving (10) a transaction request (q), resulting from a transactional device (Dt), comprising at least one identifier (id) of a user; it is not necessary, in this embodiment, that the query in question includes the bank data (card number, transaction amount, etc.), or even that it comes directly from the transaction terminal.
  • LOCC current location
  • LOCAs authorized location
  • the location assertion (Al) is then provided to validate the bank transaction (this bank transaction validation is performed up to the other parameters and values entering the validation process, of course) to an entity.
  • This bank transaction validation is performed up to the other parameters and values entering the validation process, of course.
  • the entity in question may very well be one that implements the method just described.
  • the method makes it possible to compare the location of the IP address of the terminal that initiates the payment with an authorized location list.
  • These locations can be defined by the user's bank, automatically. Indeed, it is very traditional for users to connect to their online bank account management systems from several different locations. Among the favorite locations of users, two are extremely common: this is on the one hand the user's home and on the other hand his place of work.
  • the proposed method it is possible to retrieve the IP addresses of users when connecting to their online banking.
  • this recovery is not sufficient, as such. It is necessary, after an IP address retrieval, to obtain a more or less precise location of this address and to keep this location as an authorized location.
  • This conservation can be implemented according to several criteria. For example, when an identified location corresponds to more than twenty or thirty percent of all locations of the user (these percentages are given for information only), it can be considered that this location can be preserved.
  • this location when a location does not correspond to a usual location of the user, this location can be excluded from the locations authorized by the bank or the payment institution or the payment service manager. In this embodiment of the invention, the location is a country, a city or a street (or a combination of these data).
  • the current location of the transactional device is further completed by the implementation of a "trace route" type request.
  • a "trace route” type request makes it possible to follow the path taken by an IP packet to reach a given address.
  • at least some of the IP addresses obtained via the "trace route" request are used to obtain “intermediate” locations.
  • This embodiment of the invention although more or less significantly lengthening the delivery process of the location assertion, makes it possible to evaluate the path traversed by packets to reach the IP address of the transactional device. This gives a list of IP addresses at least some of which are associated with a location (for example country, city or street or a combination of these data). This list is ordered, in order to be able to evaluate the route taken by the packets.
  • the locations of the different IP addresses of the list are not in adequacy with the IP address as received from the transactional device (the location of the IP address of the transactional device indicates France while the list of successive locations are outside France such as in Russia, Bulgaria, India, China, etc.), it is possible to modulate the delivery of the location assertion.
  • This modulation can take several forms: either the location assertion is not delivered at all and the process is stopped, or a technique based on confidence coefficients is introduced.
  • countries or regions of a country or even cities and streets are assigned levels of trust. It is a coefficient less than or equal to the value 1.
  • Each location of the list of successive locations is assigned a coefficient.
  • the coefficients of the locations of the list are multiplied to obtain a level of confidence.
  • the confidence level is below a predetermined confidence level, the location assertion is not delivered.
  • This confidence threshold may for example be a function of the number of banking incidents linked to the user or also of the frequency with which the bank has found that the user was moving (according to the withdrawals made in different countries or in different cities).
  • the method therefore comprises:
  • security is enhanced. Indeed, in addition to the location of the place where the transaction is carried out (for example by using the IP address of the terminal from which this transaction is initiated), we use the locating a mobile terminal (for example a smartphone or tablet) in the possession of the user to determine the location of this terminal. In other words, in this embodiment, in addition to the location of the terminal from which the transaction is made, it also seeks to locate a mobile device that is in the possession of the user so as to correlate this location mobile device with that of the device from which the transaction is made.
  • a mobile terminal for example a smartphone or tablet
  • the location assertion is not provided and the transaction can not continue.
  • the method further comprises, in relation to FIG.
  • the step of obtaining a current location of a mobile terminal associated with said user may comprise, depending on the embodiments, a direct transmission of a location by the terminal itself, if the terminal is able to make this transmission (for example via a dedicated application - see below).
  • the obtaining of the location can also be implemented via the communication network to which the communication terminal is connected. As a general rule, this implies implementation through the intermediary of the telecommunication operator to which the user is subscribed (this can cause problems since the operators are generally reluctant to provide this kind of data, which they prefer to keep for their own purposes or for uses imposed by the laws of the Member States. different countries).
  • the method is implemented via a mobile terminal, which terminal is assumed to be in the possession of the user. Unlike known techniques, the method does not include transmitting information to the mobile terminal to verify that the cardholder has its terminal to perform the transaction. On the contrary, the method consists in obtaining information from the terminal, which on the one hand is more discreet and on the other hand makes it possible not to solicit the user unnecessarily.
  • the information obtained can be of several types.
  • the information can be a geographical position obtained via a geolocation module (GPS type, GLONASS, GALILEO, etc.).
  • the information can also be an IP address.
  • This IP address can be the IP address of the gateway to which the terminal is connected, for example in WiFi, when this terminal is at the user's home.
  • This IP address can be the one provided by an access provider in case of connection to the Internet via a 3G / 4G network.
  • the information can still be a base station identifier, to which the terminal is connected (for example on a 2G / 3G / 4G network).
  • this implementation is provided by a mobile application. More particularly, according to a preferred implementation, this application is the user's banking application. It is indeed very common for users to have an application allowing them to manage their account from their mobile terminal. In general, this type of application enjoys enhanced security. More specifically, this type of application often uses a session data encryption protocol (SSL or TLS), which ensures a certain confidentiality of the transmitted data.
  • SSL session data encryption protocol
  • the mobile application transmits, upon request, the data necessary for a bank server, which retransmits this data (or data transformed into location data) to the third party server (for example to the transactional server).
  • the method described is implemented via a transactional server, presented in connection with FIG. 4.
  • a transactional server may, as desired, be implemented by a banking organization, a payment service provider or provider acting as an intermediary between one or more banks or payment institutions.
  • Such a management server comprises a memory 41, a processing unit 42 equipped for example with a microprocessor, and driven by the computer program 43, implementing the method according to the invention.
  • the invention is implemented in the form of a bank server, a payment system.
  • a server includes:
  • connection interface means for receiving a transaction request, from said transactional device, comprising at least one identifier of a user to which said bank details are associated;
  • connection interface means for receiving a transaction request, from said transactional device, comprising at least one identifier of a user to which said bank details are associated;
  • These means can be embodied in the form of a connection interface (I) to one or more communication networks. They may be software interfaces or hardware interfaces (network card type or network communication hardware modules).
  • connection interface I
  • network card type or network communication hardware modules
  • means for determining a current location associated with said IP address means for comparing said current location with at least one authorized location, according to said identifier of said user;
  • These means can be embodied in the form of a connection interface to one or more communication networks. They may be software interfaces or hardware interfaces (network card type or network communication hardware modules).
  • such a server also comprises means for obtaining at least one piece of information coming from a mobile terminal that is supposed to be in the possession of the user whose transaction is to be validated.
  • this server may for example transmit a request to obtain this information to the mobile terminal.
  • it can implement several techniques, the first being for example the transmission of an SMS-type message to an application installed on the terminal (see Application and Mobile Terminal).
  • the server Upon receipt of the location information, the server performs a concordance check between the location previously obtained (that of the terminal to which the user is connected) and the location obtained via the mobile terminal. When these locations are not matched, the transactional server does not provide a location assertion and the transaction is rolled back.
  • a simplified architecture of a mobile device capable of transmitting its position is presented.
  • a mobile device comprises a memory 51, a processing unit 52 equipped for example with a microprocessor, and driven by the computer program 53, implementing the method according to the invention.
  • the invention is implemented in the form of a mobile application installed on a mobile device in the possession of the user.
  • a mobile device comprises:
  • connection interface I
  • networks may be software interfaces or hardware interfaces (network card type or network communication hardware modules);
  • transmission means said server, said at least one position.
  • These means can be embodied in the form of a connection interface to one or more communication networks. They may be software interfaces or hardware interfaces (network card type or network communication hardware modules).

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Finance (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention se rapporte à un procédé de fourniture d'une assertion de localisation d'un dispositif transactionnel (Dt), ayant sollicité, auprès d'un serveur, par l'intermédiaire d'un réseau de communication, une acceptation d'une transaction financière impliquant l'utilisation de coordonnées bancaires Selon l'invention un tel procédé comprend : - une étape de réception (10) d'une requête transactionnelle (Rq), issue dudit dispositif transactionnel (Dt), comprenant au moins un identifiant d'un utilisateur (id) auquel lesdites coordonnées bancaires sont associées; - une étape d'obtention (11) d'une adresse IP (@IP) associée audit dispositif transactionnel (Dt); - une étape de détermination (12) d'une localisation courante (LOCC) associée à ladite adresse IP (@IP); - une étape de comparaison (13) de ladite localisation courante (LOCC) avec au moins une localisation autorisée (LOCAs), en fonction dudit identifiant dudit utilisateur (Id); - une étape de fourniture (14), à une entité (Ent) d'une assertion de localisation (Al) lorsque ladite étape de comparaison est positive.

Description

Procédé de délivrance d'une assertion de localisation.
1. Domaine de l'invention
L'invention se rapporte à la sécurisation des paiements. Plus particulièrement, l'invention se rapporte à la sécurisation de paiements réalisés en ligne.
Les paiements en ligne représentent une part croissante des paiements réalisés quotidiennement à travers le monde. Ils peuvent être réalisés soit par l'intermédiaire de prestataires de paiement, tels que Paypal™, soit en faisant appels à des organismes bancaires traditionnels.
Cependant, le paiement en ligne est marqué par un taux de fraude relativement élevé. En France, on estime ainsi qu'environ cinq pour cent des paiements en ligne réalisés sur internet sont frauduleux. Ces cinq pour cent de paiements frauduleux représentent environ trente-trois pour cent du coût total des fraudes. Il est donc nécessaire de disposer de moyens d'une part d'identifier des tentatives de fraude et d'autre part de bloquer ces tentatives.
Majoritairement, les paiements en ligne sont effectués à l'aide d'une carte bancaire. Ces paiements nécessitent d'une part la saisie d'un numéro de carte bancaire, d'une date de validité de cette carte bancaire, d'un nom de titulaire et souvent d'un code de sécurité se trouvant au dos de cette carte. On conseille fréquemment au titulaire, pour s'assurer que ses informations ne soient pas volées, de réaliser des transactions sur des sites dits « sécurisés ». De tels sites sont dits sécurisés car ils mettent en œuvre au moins une technique de chiffrement des données de sessions qui protègent les données échangées. Malheureusement les attaques ne se réalisent pas souvent au moment du paiement effectué par le titulaire. Au contraire, une attaque standard consiste à viser soit le serveur de paiement indépendamment de toute transaction ou mieux encore le serveur du commerçant, quand le commerçant se place en interface entre le client et la banque. Ces serveurs sont moins sécurisés que ne l'est la session au cours de laquelle les données sont transmises. Ils sont donc plus faciles à pirater. Ainsi, en piratant ces serveurs, les attaquant disposent souvent d'une grande quantité de données bancaires, qu'ils monnaient par la suite à d'autres personnes. Ces personnes utilisent ensuite ces informations pour réaliser des transactions frauduleuses. L'une des problématiques, dans les transactions en ligne, est que ces transactions sont réalisées en mode « carte non présente » (soit CNP, pour « Card Not Présent » en Anglais »). Dans ce mode, comme il n'y a pas de dispositif en charge de la vérification de l'intégrité de la carte (comme par exemple un terminal de paiement), I n'est pas possible de vérifier que le porteur de la carte dispose du code PIN nécessaire pour valider une transaction.
2. Art Antérieur
Ainsi, pour tenter de sécuriser les transactions réalisées en mode CNP, des systèmes et des méthodes ont été proposés pour répondre à ces problèmes de fraude. Ces méthodes posent soit des problèmes de praticité pour l'utilisateur, soit d'autres problèmes de sécurité. Il s'agit par exemple de la méthode décrite dans la demande de brevet publiée sous le numéro WO2012053780. Dans cette demande de brevet, un système et une méthode de vérification sont décrits. Plus particulièrement, dans ce document, une méthode et un système utilisant des informations sur l'adresse MAC d'un terminal client est décrit. Au cours d'une transaction impliquant un paiement, un processus d'authentification renforcé est mis en œuvre, procédé au cours duquel l'adresse MAC du terminal utilisé par le client qui souhaite effectuer un paiement est comparée à une adresse MAC de référence, laquelle a été définie ou obtenue par le serveur bancaire qui doit autoriser un paiement ou une transaction.
Cette méthode, bien que potentiellement intéressante, n'en demeure pas moins peu pratique. En effet, d'une part cette méthode oblige le client à utiliser toujours le même dispositif pour effectuer un paiement (sauf à définir plusieurs dispositifs autorisés à réaliser une transaction). D'autre part, il existe de nombreuses méthodes permettant de falsifier une adresse MAC d'un dispositif. Plus particulièrement, la méthode décrite dans WO2012053780 se base sur l'obtention d'une adresse MAC à partir d'un navigateur WEB. Or, un pirate qui souhaiterait obtenir une adresse MAC d'un utilisateur n'aurait aucune difficulté pour obtenir cette adresse au moment où il s'empare des coordonnées de carte de paiement de l'utilisateur en question, par exemple en utilisant une méthode telle que décrite précédemment (en attaquant le serveur d'un commerçant). Ainsi, la méthode de WO2012053780 ne serait pas d'une grande utilité puisque l'information complémentaire (l'adresse MAC du dispositif transactionnel) serait aussi vulnérable que les autres. La méthode décrite n'aurait donc que peu de chance de sécuriser réellement la transaction.
D'autres méthodes sont également disponibles. Certaines consistent à fournir, à l'utilisateur, des numéros de cartes bancaires à usage unique. Ces numéros sont fournis en fonction des besoins du client. Cette méthode est intéressante mais n'ôte pas (heureusement) la possibilité pour le client d'utiliser ses propres informations de carte pour effectuer des transactions. D'autres méthodes, actuellement très utilisées, consistent à transmettre un message de type SMS au client qui effectue une transaction afin de s'assurer qu'il est bien le porteur de la carte. Le client doit saisir, au moment de la transaction, un mot de passe qui est transmis dans le SMS. Dès lors, la banque s'assurer avec une probabilité raisonnable que celui qui effectue la transaction est bien le client. Cette méthode souffre de deux inconvénients : d'une part cela oblige le client à fournir son numéro de téléphone à la banque avant toute transaction et de manière sécurisée (cela se fait la plupart du temps de visu avec un conseiller bancaire) ; d'autre part cette méthode ne fonctionne que si la banque du client est également la banque qui gère la transaction pour le compte du commerçant. Or, ceci est rarement le cas, plus particulièrement à l'étranger. En effet, une grande partie des fraudes est réalisée à l'étranger. Ainsi, la méthode précitée est peu efficace dans ce cas.
3. Résumé de l'invention
La méthode proposée par les inventeurs ne pose pas ces problèmes de l'art antérieur. En effet, il est proposé une méthode de localisation d'un utilisateur effectuant un paiement en mode CNP.
Plus particulièrement, l'invention se rapporte à un procédé de fourniture d'une assertion de localisation d'un dispositif transactionnel, ayant sollicité, auprès d'un serveur, par l'intermédiaire d'un réseau de communication, une acceptation d'une transaction financière impliquant l'utilisation de coordonnées bancaires. Selon l'invention ce procédé comprend : une étape de réception d'une requête transactionnelle, issue dudit dispositif transactionnel, comprenant au moins un identifiant d'un utilisateur auquel lesdites coordonnées bancaires sont associées ;
une étape d'obtention d'une adresse IP associée audit dispositif transactionnel ; une étape de détermination d'une localisation courante associée à ladite adresse IP ;
une étape de comparaison de ladite localisation courante avec au moins une localisation autorisée, en fonction dudit identifiant dudit utilisateur ;
une étape de fourniture, à une entité d'une assertion de localisation lorsque ladite étape de comparaison est positive.
Ainsi, l'invention permet de valider une transaction bancaire (tel qu'un paiement en ligne) sur la base de la localisation du terminal effectuant la transaction, en utilisant l'adresse IP de ce terminal. La méthode proposée est donc beaucoup plus simple et moins restrictive à mettre en œuvre que des méthodes d'autorisation basée sur une adresse MAC.
Selon un mode de réalisation particulier, ledit procédé comprend en outre : une étape d'obtention d'une route empruntée par des paquets de données pour atteindre ladite adresse IP associée audit dispositif transactionnel, délivrant une liste d'adresse IP empruntées ;
une étape d'association d'au moins une adresse IP de ladite liste d'adresses IP à au moins une localisation, dite localisation de transport ;
Ainsi, l'invention permet de tracer le chemin emprunté par un paquet de données qui souhaite rejoindre l'adresse IP associée au terminal. On obtient donc des données complémentaires permettant de se prémunir d'un vol ou d'une usurpation d'adresse IP.
Selon une caractéristique particulière, ledit procédé comprend en outre :
une étape de calcul d'un coefficient de confiance en fonction de coefficients associés à ladite au moins une localisation de transport ;
et en ce que ladite étape de délivrance de l'assertion de localisation tient compte d'un seuil de confiance associé audit utilisateur. Ainsi, l'invention permet de classifier les localisations à risque et de définir des seuils en deçà desquels les transactions ne sont pas acceptées.
Selon une caractéristique particulière, ladite étape de délivrance de l'assertion de localisation est réalisée lorsqu'aucune des localisations de transport ne fait partie d'une liste de localisation interdite.
Ainsi, il est possible d'interdire que les paquets de données transitent par l'intermédiaire de localisations interdites. Cela permet d'une part de réduire le taux de fraude et d'autre part d'éviter que des données ne soient interceptées, même lorsque la fraude n'est pas avérée.
Selon un mode de réalisation particulier, ledit procédé comprend en outre : une étape d'obtention d'une localisation courante d'un terminal mobile associé audit utilisateur ;
une étape de comparaison de la localisation courante du dispositif transactionnel avec la localisation courante du terminal mobile associé audit utilisateur ; et
lorsque l'une de ces deux localisations diffère de l'autre au-delà d'un paramètre de comparaison prédéterminé, une étape de sortie du processus de validation sans délivrance d'une assertion de localisation ;
lorsque ces deux localisations diffèrent en deçà d'un paramètre de comparaison prédéterminé, une étape de sortie du processus de validation avec délivrance d'une assertion de localisation.
Ainsi, l'invention permet de coupler la localisation du terminal transactionnel à la localisation d'un autre dispositif en possession de l'utilisateur. Il s'agit donc d'un double contrôle qui est efficace car dans la majorité des cas, les transactions sont passées depuis le domicile de l'utilisateur. A ce domicile, la probabilité que le terminal mobile de l'utilisateur soit connecté à la passerelle résidentielle du domicile est forte. Auquel cas, la localisation des terminaux sera identique et sera obtenue très rapidement.
Dans un autre mode de réalisation, l'invention se rapporte également à un serveur de fourniture d'une assertion de localisation d'un dispositif transactionnel, lequel ayant sollicité, auprès d'un serveur, par l'intermédiaire d'un réseau de communication, une acceptation d'une transaction financière impliquant l'utilisation de coordonnées bancaires. Selon l'invention un tel serveur comprend :
des moyens de réception d'une requête transactionnelle, en provenance dudit dispositif transactionnel, comprenant au moins un identifiant d'un utilisateur auquel lesdites coordonnées bancaires sont associées ;
des moyens d'obtention d'une adresse IP associée audit dispositif transactionnel ;
des moyens de détermination d'une localisation courante associée à ladite adresse IP ;
des moyens de comparaison de ladite localisation courante avec au moins une localisation autorisée, en fonction dudit identifiant dudit utilisateur ;
des moyens de fourniture, à une entité d'une assertion de localisation lorsque ladite comparaison est positive.
Selon une implémentation préférée, les différentes étapes des procédés selon l'invention sont mises en œuvre par un ou plusieurs logiciels ou programmes d'ordinateur, comprenant des instructions logicielles destinées à être exécutées par un processeur de données d'un module relais selon l'invention et étant conçu pour commander l'exécution des différentes étapes des procédés.
En conséquence, l'invention vise aussi un programme, susceptible d'être exécuté par un ordinateur ou par un processeur de données, ce programme comportant des instructions pour commander l'exécution des étapes d'un procédé tel que mentionné ci-dessus.
Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
L'invention vise aussi un support d'informations lisible par un processeur de données, et comportant des instructions d'un programme tel que mentionné ci-dessus. Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy dise) ou un disque dur.
D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.
Selon un mode de réalisation, l'invention est mise en œuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme "module" peut correspondre dans ce document aussi bien à un composant logiciel, qu'à un composant matériel ou à un ensemble de composants matériels et logiciels.
Un composant logiciel correspond à un ou plusieurs programmes d'ordinateur, un ou plusieurs sous-programmes d'un programme, ou de manière plus générale à tout élément d'un programme ou d'un logiciel apte à mettre en œuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Un tel composant logiciel est exécuté par un processeur de données d'une entité physique (terminal, serveur, passerelle, set-top-box, routeur, etc) et est susceptible d'accéder aux ressources matérielles de cette entité physique (mémoires, supports d'enregistrement, bus de communication, cartes électroniques d'entrées/sorties, interfaces utilisateur, etc).
De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware) apte à mettre en œuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Il peut s'agir d'un composant matériel programmable ou avec processeur intégré pour l'exécution de logiciel, par exemple un circuit intégré, une carte à puce, une carte à mémoire, une carte électronique pour l'exécution d'un micrologiciel (firmware), etc.
Chaque composante du système précédemment décrit met bien entendu en œuvre ses propres modules logiciels.
Les différents modes de réalisation mentionnés ci-dessus sont combinables entre eux pour la mise en œuvre de l'invention.
4. Figures
D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation préférentiel, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels :
la figure 1 décrit un mode de réalisation du procédé de délivrance d'assertion de localisation ;
la figure 2 décrit un mode de réalisation dérivé du procédé de délivrance d'assertion de localisation ;
la figure 3 décrit un mode de réalisation complémentaire du procédé de délivrance d'assertion de localisation ;
la figure 4 illustre une architecture d'un serveur apte à mettre en œuvre un procédé de délivrance d'assertion de localisation ;
la figure 5 illustre une architecture d'un client apte à mettre en œuvre un procédé de délivrance d'assertion de localisation.
5. Description d'un mode de réalisation
5.1. Rappel du principe de l'invention
Comme exposé préalablement, il a été constaté que les solutions actuelles ne permettaient pas forcément d'assurer que le paiement qui est réalisé est issu du porteur de la carte bancaire dont les informations sont utilisées. L'objet de la méthode proposée est de faire en sorte que, lors de l'utilisation de données de carte bancaire en mode CNP, on puisse tout de même obtenir une information sur le porteur de la carte de paiement. En résumé, l'objectif est de passer d'un mode CNP à un mode où le porteur de carte est localisé sans changer les habitudes du porteur de carte et en toute discrétion.
Pour ce faire, les étapes usuelles conduisant à la validation de la transaction sont modifiées. Dans au moins un mode de réalisation de la méthode proposée, on obtient, en sus des données bancaires, l'adresse IP à partir de laquelle la transaction est initiée. Dans un mode basique, cette adresse IP est comparée à un liste d'adresses IP autorisées, liste conservée par l'entité en charge de mener à bien les transactions de paiement (il peut s'agir d'une banque, d'un établissement de paiement ou d'un établissement intermédiaire, tel qu'un gestionnaire de service de paiement).
Dans un mode de réalisation plus évolué, l'adresse IP n'est pas la donnée permettant de valider la transaction. Dans ce mode de réalisation, la donnée validant ou non la transaction est une localisation. L'adresse IP du terminal à partir duquel la transaction est réalisée est toujours obtenue, mais cette adresse IP ne sert que de moyen d'obtention d'une localisation. La localisation devient l'information permettant de délivrer l'autorisation de transaction (c'est-à-dire de valider qu'une transaction peut être réalisée). Ce mode de réalisation présente plusieurs avantages. En premier lieu, ce mode de réalisation permet de s'affranchir des problématiques de translations d'adresse. En effet, il est très fréquent que le dispositif qui est utilisé pour réaliser une transaction bancaire se trouver derrière une passerelle ou un proxy. Or, il peut être complexe de récupérer une adresse IP qui soit exploitable. En règle générale, l'adresse IP que l'on récupère est l'adresse IP de la passerelle, mais cela n'est pas assuré. En second lieu, ce mode de réalisation permet de ne pas limiter le nombre de dispositifs qui peuvent être utilisés pour réaliser des transactions. Plus particulièrement, à la différence d'une adresse MAC, par exemple, une adresse IP est souvent partagée par plusieurs dispositifs (par exemple l'adresse d'une passerelle résidentielle est partagée par tous les dispositifs de l'utilisateur connectés à cette passerelle résidentielle). Il n'est donc pas nécessaire de récupérer toutes les adresses MAC des dispositifs susceptibles d'être utilisés.
Dans au moins un mode de réalisation, la localisation utilisée est celle de la ville de l'adresse IP. Dans d'autres modes de réalisation, la localisation peut être plus précise, comme par exemple une rue de la ville. La précision obtenue dépend d'une part des bases de données disponibles et d'autre part de contraintes légales en vigueur dans les zones géographiques ou l'invention est mise en œuvre.
On présente par la suite, une mise en œuvre du principe exposé précédemment. Cette mise en œuvre n'est nullement limitative et toute autre mise en œuvre comprenant les mêmes caractéristiques que celles qui sont exposées est envisageable.
5.2. Description d'un mode de réalisation.
Dans ce mode de réalisation, présenté en relation avec les figures 1 et 2, on utilise l'adresse IP (@IP) du terminal (Dt) à partir duquel la transaction est réalisée. Comme déjà indiqué préalablement, le terminal à partir duquel la transaction est réalisée n'est pas un terminal de paiement (au sens un terminal dans lequel la carte bancaire est inséré et dans lequel un code PIN est saisi). Il s'agit d'un terminal tel qu'un ordinateur ou une tablette ou un smartphone et non pas d'un terminal de paiement tels que ceux installés chez des commerçants.
Dans ce mode de réalisation, la méthode mise en œuvre comprend :
une étape de réception (10) d'une requête transactionnelle ( q), issue d'un dispositif transactionnel (Dt), comprenant au moins un identifiant (id) d'un utilisateur ; il n'est pas nécessaire, dans ce mode de réalisation, que la requête en question comprenne les données bancaires (numéro de carte, montant de la transaction, etc.), ni même qu'elle provienne directement du terminal transactionnel.
une étape d'obtention (11) d'une adresse IP (@IP) associée audit dispositif transactionnel (Dt) ;
une étape de détermination (12) d'une localisation courante (LOCC) associée à ladite adresse IP (@IP) ;
une étape de comparaison (13) de ladite localisation courante (LOCC) avec au moins une localisation autorisée (LOCAs), laquelle est obtenue à l'aide dudit identifiant dudit utilisateur (id) ; Lorsque ladite localisation courante (LOCC) correspond à au moins une localisation autorisée (LOCAs), une étape de délivrance (14) d'une assertion de localisation (Al) à une entité (Ent).
L'assertion de localisation (Al) est ensuite fournie pour valider la transaction bancaire (cette validation de transaction bancaire est réalisée à concurrence des autres paramètres et valeurs entrant dans le processus de validation, bien entendu) à une entité. On note que l'entité en question peut très bien être celle qui met en œuvre le procédé qui vient d'être décrit.
Ainsi, la méthode permet de comparer la localisation de l'adresse IP du terminal qui initie le paiement avec une liste de localisation autorisées. Ces localisations peuvent être définies par la banque de l'utilisateur, de manière automatique. En effet, il est très traditionnel que les utilisateurs se connectent à leurs systèmes de gestion de compte bancaires en ligne à partir de plusieurs localisations différentes. Parmi les localisations favorites des utilisateurs, deux sont extrêmement fréquentes : il s'agit d'une part du domicile de l'utilisateur et d'autre part de son lieu de travail.
Pour mettre en œuvre la méthode proposée, et plus particulièrement, pour permettre une utilisation discrète de la méthode proposée, il est donc possible de récupérer les adresses IP des utilisateurs lors de la connexion à leurs services bancaires en ligne. En revanche, dans ce mode de réalisation, cette récupération n'est pas suffisante, en tant que telle. Il est nécessaire, postérieurement à une récupération d'adresse IP, d'obtenir une localisation plus ou moins précise de cette adresse et de conserver cette localisation comme étant une localisation autorisée. Cette conservation peut être mise en œuvre selon plusieurs critères. Par exemple lorsque qu'une localisation identifiée correspond à plus de vingt ou trente pour cent de l'ensemble des localisations de l'utilisateur (ces pourcentages sont donnés à titre indicatif), on peut estimer que cette localisation peut être conservée. En revanche, lorsqu'une localisation ne correspond pas à une localisation habituelle de l'utilisateur, cette localisation peut être exclue des localisations autorisées par l'organisme bancaire ou l'organisme de paiement ou le gestionnaire de service de paiement. Dans ce mode de réalisation de l'invention, la localisation est un pays, une ville ou une rue (ou une combinaison de ces données).
Dans un mode de réalisation dérivé, la localisation courante du dispositif transactionnel est en outre complétée par la mise en œuvre d'une requête de type « trace route ». Une telle requête permet en effet de suivre le cheminement emprunté par un paquet IP pour rejoindre une adresse donnée. Dans ce mode de réalisation complémentaire, au moins certaines des adresses IP obtenues par l'intermédiaire de la requête « trace route » sont utilisées pour obtenir des localisations « intermédiaires ». Ce mode de réalisation de l'invention, bien qu'allongeant de manière plus ou moins significative le processus de délivrance de l'assertion de localisation, permet d'évaluer le chemin parcouru par des paquets pour atteindre l'adresse IP du dispositif transactionnel. On obtient ainsi, une liste d'adresses IP dont au moins certaines sont associées à une localisation (par exemple de type pays, ou ville ou rue ou une combinaison de ces données). Cette liste est ordonnée, afin de pouvoir évaluer le parcours effectué par les paquets.
Ainsi, par exemple, si les localisations des différentes adresses IP de la liste ne sont pas en adéquation avec l'adresse IP telle que reçue du dispositif transactionnel (la localisation de l'adresse IP du dispositif transactionnel indique la France alors que la liste des localisations successives sont en dehors de France tel qu'en Russie, en Albanie, en Inde, en Chine, etc.), il est possible de moduler la délivrance de l'assertion de localisation. Cette modulation peut prendre plusieurs formes : soit l'assertion de localisation n'est pas du tout délivrée et le processus est stoppé, soit on introduit une technique basée sur des coefficients de confiance.
Dans cette technique, des pays ou des régions d'un pays voire des villes et des rues, se voient attribués des niveaux de confiance. Il s'agit d'un coefficient inférieur ou égal à la valeur 1. Chaque localisation de la liste des localisations successives se voit attribuée un coefficient. Les coefficients des localisations de la liste sont multipliés afin d'obtenir un niveau de confiance. Lorsque le niveau de confiance est inférieur à un seuil de confiance prédéterminé, l'assertion de localisation n'est pas délivrée. Ce seuil de confiance peut par exemple être fonction du nombre d'incidents bancaires lié à l'utilisateur ou encore fonction de la fréquence à laquelle la banque a constaté que l'utilisateur se déplaçait (en fonction des retraits effectués dans différents pays ou dans différentes villes).
Dans ce mode de réalisation dérivé, la méthode comprend donc :
une étape d'obtention (11) d'une adresse IP (@IP) associée au dispositif transactionnel (Dt) ;
une étape de mise en œuvre (121) d'une requête d'obtention d'une route empruntée par des paquets de données pour atteindre ladite adresse IP (@IP) dudit dispositif transactionnel, délivrant une liste d'adresse IP empruntées
(L@IP) ;
une étape d'association (122) d'au moins une adresse IP de ladite liste d'adresses IP (L@IP) à au moins une localisation, dite localisation de transport (LOCT) ;
et
o soit une étape de calcul d'un coefficient de confiance en fonction de coefficients associés à ladite au moins une localisation de transport et une étape de délivrance de l'assertion de localisation en fonction d'un seuil de confiance associé audit utilisateur ;
o soit une étape de délivrance de l'assertion de localisation lorsqu'aucune des localisations de transport en fait partie d'une liste de localisation interdite.
Dans la description de la figure 2, les étapes précédemment présentés sont associées à une détermination préalable d'une localisation d'adresse IP du terminal. Ceci n'est qu'un mode de réalisation. Il est tout à fait envisageable de mettre en œuvre ces étapes de manière indépendante.
5.3. Description d'un deuxième mode de réalisation
Dans ce deuxième mode de réalisation, la sécurité est renforcée. En effet, en sus de la localisation du lieu où la transaction est réalisée (par exemple par l'utilisation de l'adresse IP du terminal à partir duquel cette transaction est initiée), on utilise la localisation d'un terminal mobile (par exemple un smartphone ou une tablette) en possession de l'utilisateur pour déterminer la localisation de ce terminal. En d'autres termes, dans ce mode de réalisation, en sus de la localisation du terminal à partir duquel la transaction est réalisée, on cherche également à localiser un dispositif mobile qui est en possession de l'utilisateur de manière à pouvoir corréler cette localisation de dispositif mobile avec celle du dispositif à partir duquel la transaction est réalisée.
Concrètement, lorsque les deux localisations obtenues ne sont pas cohérentes, l'assertion de localisation n'est pas fournie et la transaction ne peut pas se poursuivre.
Ainsi, par rapport au mode de réalisation précédent, la méthode comprend en plus, en relation avec la figure 3 :
une étape d'obtention (123) d'une localisation courante d'un terminal mobile associé audit utilisateur (LOCTm) ;
une étape de comparaison (124) de la localisation courante du dispositif transactionnel (LOCC) avec la localisation courante du terminal mobile associé audit utilisateur (LOCTm) ; et
lorsque l'une de ces deux localisations diffère de l'autre au-delà d'un paramètre de comparaison prédéterminé, une étape de sortie du processus de validation sans délivrance d'une assertion de localisation ;
lorsque ces deux localisations diffèrent en deçà d'un paramètre de comparaison prédéterminé, une étape de sortie du processus de validation avec délivrance d'une assertion de localisation.
Ainsi, deux localisations sont utilisées et corrélées pour permettre de délivrer l'assertion de localisation.
L'étape d'obtention d'une localisation courante d'un terminal mobile associé audit utilisateur peut comprendre, en fonction des modes de réalisation, une transmission directe d'une localisation par le terminal lui-même, si le terminal est en mesure de faire cette transmission (par exemple par l'intermédiaire d'une application dédiée - voir ci-après). L'obtention de la localisation peut également être mise en œuvre par l'intermédiaire du réseau de communication auquel le terminal de communication est connecté. En règle générale, ceci suppose une mise en œuvre par l'intermédiaire de l'opérateur de télécommunication auprès duquel l'utilisateur est abonné (ceci peut générer des problèmes puisque les opérateurs sont généralement peu enclins à fournir ce genre de données, qu'ils préfèrent conserver pour leurs usages propres ou pour des usages imposés par les législations des différents pays).
5.4. Application & Terminal Mobile
Comme évoqué préalablement, dans au moins un mode de réalisation, la méthode est mise en œuvre par l'intermédiaire d'un terminal mobile, lequel terminal est supposé être en possession de l'utilisateur. À la différence des techniques connues, la méthode ne consiste pas à transmettre une information au terminal mobile pour vérifier que le titulaire de la carte dispose de son terminal pour effectuer la transaction. Au contraire, la méthode consiste à obtenir de l'information de la part du terminal, ce qui d'une part est plus discret et d'autre part permet de ne pas solliciter l'utilisateur inutilement. L'information obtenue peut être de plusieurs types. L'information peut être une position géographique obtenue par l'intermédiaire d'un module de géolocalisation (de type GPS, GLONASS, GALILEO, etc.). L'information peut également être une adresse IP. Cette adresse IP peut être l'adresse IP de la passerelle à laquelle le terminal est connecté, par exemple en WiFi, lorsque ce terminal est au domicile de l'utilisateur. Cette adresse IP peut être celle fournie par un fournisseur d'accès en cas de connexion à internet par l'intermédiaire d'un réseau 3G/4G. L'information peut encore être un identifiant de station de base, auquel le terminal est connecté (par exemple sur un réseau 2G/3G/4G). Ainsi, on obtient, par l'intermédiaire du téléphone, une ou plusieurs informations permettant de réaliser une localisation du terminal.
Dans un mode de réalisation spécifique de l'invention, cette mise en œuvre est assurée par une application mobile. Plus particulièrement, selon une implémentation préférée, cette application est l'application bancaire de l'utilisateur. Il est en effet très courant que les utilisateurs disposent d'une application leur permettant de gérer leur compte depuis leur terminal mobile. En règle générale, ce type d'application bénéficie d'une sécurité renforcée. Plus particulièrement, ce type d'application utilise souvent un protocole de chiffrement de données de session (SSL ou TLS), ce qui permet d'assurer une certaine confidentialité des données transmises. Dans un mode de réalisation spécifique, dans lequel la méthode de délivrance de l'assertion de localisation est mise en œuvre par un tiers (c'est-à-dire pas par l'établissement bancaire de l'utilisateur), l'application mobile transmet, sur requête, les données nécessaires à un serveur bancaire, lequel retransmet ces données (ou des données transformées en données de localisation) au serveur tiers (par exemple au serveur transactionnel).
5.5. Serveur transactionnel
Dans au moins un mode de réalisation, la méthode décrite est mise en œuvre par l'intermédiaire d'un serveur transactionnel, présenté en relation avec la figure 4. Un tel serveur peut, au choix, être mis en œuvre par un organisme bancaire, un fournisseur de service de paiement ou un prestataire servant d'intermédiaire entre un ou plusieurs établissements bancaires ou établissements de paiements.
Un tel serveur de gestion comprend une mémoire 41, une unité de traitement 42 équipée par exemple d'un microprocesseur, et pilotée par le programme d'ordinateur 43, mettant en œuvre le procédé selon l'invention. Dans au moins un mode de réalisation, l'invention est mise en œuvre sous la forme d'un serveur bancaire, d'un système de paiement. Un tel serveur comprend :
des moyens de réception d'une requête transactionnelle, en provenance dudit dispositif transactionnel, comprenant au moins un identifiant d'un utilisateur auquel lesdites coordonnées bancaires sont associées ; Ces moyens peuvent se matérialiser sous la forme d'une interface de connexion (I) à un ou plusieurs réseaux de communication. Il peut s'agir d'interfaces logicielles ou d'interfaces matérielles (de type carte réseau ou modules matériels de communication réseau).
des moyens d'obtention d'une adresse IP associée audit dispositif transactionnel ; Ces moyens peuvent se matérialiser sous la forme d'une interface de connexion (I) à un ou plusieurs réseaux de communication. Il peut s'agir d'interfaces logicielles ou d'interfaces matérielles (de type carte réseau ou modules matériels de communication réseau) ;
des moyens de détermination d'une localisation courante associée à ladite adresse IP ; des moyens de comparaison de ladite localisation courante avec au moins une localisation autorisée, en fonction dudit identifiant dudit utilisateur ;
des moyens de fourniture, à une entité d'une assertion de localisation lorsque ladite comparaison est positive. Ces moyens peuvent se matérialiser sous la forme d'une interface de connexion à un ou plusieurs réseaux de communication. Il peut s'agir d'interfaces logicielles ou d'interfaces matérielles (de type carte réseau ou modules matériels de communication réseau).
Dans au moins un mode de réalisation, un tel serveur comprend également des moyens d'obtention d'au moins une information en provenance d'un terminal mobile qui est supposé être en possession de l'utilisateur dont on souhaite valider une transaction. Dans ce mode de réalisation, ce serveur peut par exemple transmettre une requête d'obtention de cette information au terminal mobile. Pour ce faire, il peut mettre en œuvre plusieurs techniques, la première étant par exemple la transmission d'un message de type SMS à destination d'une application installée sur le terminal (cf. Application et Terminal mobile).
À réception de l'information de localisation, le serveur effectue une vérification de concordance entre la localisation préalablement obtenue (celle du terminal auquel l'utilisateur est connecté) et la localisation obtenue par l'intermédiaire du terminal mobile. Lorsque ces localisations ne sont pas concordantes, le serveur transactionnel ne fournit pas d'assertion de localisation et la transaction est annulée.
Astucieusement, lorsque cela est possible, toutes les informations disponibles sont transmises (géolocalisation, adresse IP et identifiant de station de base) par l'application mobile au serveur transactionnel et un recoupement de ces informations est ensuite réalisé par le serveur transactionnel (auquel cette fonctionnalité de recoupement est ajoutée). Ce recoupement d'information est réalisé par ordre de fiabilité des informations reçues. Par exemple, on considère que l'identifiant de la station de base auquel le terminal mobile de l'utilisateur est connecté (réseau 2G, 3G, 4G) est plus fiable que la géolocalisation qui est elle-même plus fiable que l'adresse IP. Ainsi, lorsque la localisation obtenue par l'adresse IP est différente de celle obtenue par l'identifiant de station de base, on peut estimer que la localisation par l'adresse IP est vraisemblablement moins fiable que celle du réseau auquel le terminal est connecté. Dans ce cas, on peut par exemple décider de ne pas autoriser une transaction (il n'y a pas de délivrance d'assertion de localisation).
5.4. Dispositif pour la mise en œuvre de l'invention
On présente, en relation avec la figure 5, une architecture simplifiée d'un dispositif mobile apte à transmettre sa position. Un tel dispositif mobile comprend une mémoire 51, une unité de traitement 52 équipée par exemple d'un microprocesseur, et pilotée par le programme d'ordinateur 53, mettant en œuvre le procédé selon l'invention. Dans au moins un mode de réalisation, l'invention est mise en œuvre sous la forme d'une application mobile installée sur un dispositif mobile en possession de l'utilisateur. Un tel dispositif mobile comprend :
des moyens de réception d'une requête d'obtention de localisation en provenance d'un serveur. Ces moyens peuvent se matérialiser sous la forme d'une interface de connexion (I) à un ou plusieurs réseaux de communication. Il peut s'agir d'interfaces logicielles ou d'interfaces matérielles (de type carte réseau ou modules matériels de communication réseau) ;
des moyens de détermination d'une position, par exemple par l'intermédiaire d'une interface de positionnement global de type GPS ;
des moyens de transmission (T), audit serveur, de ladite au moins une position. Ces moyens peuvent se matérialiser sous la forme d'une interface de connexion à un ou plusieurs réseaux de communication. Il peut s'agir d'interfaces logicielles ou d'interfaces matérielles (de type carte réseau ou modules matériels de communication réseau).

Claims

REVENDICATIONS
Procédé de fourniture d'une assertion de localisation d'un dispositif transactionnel (Dt), ayant sollicité, auprès d'un serveur, par l'intermédiaire d'un réseau de communication, une acceptation d'une transaction financière impliquant l'utilisation de coordonnées bancaires, le procédé comprenant, la réception (10) d'une requête transactionnelle ( q), issue du dispositif transactionnel (Dt), comprenant au moins un identifiant d'un utilisateur (id) associé aux coordonnées bancaires, l'obtention (11) d'une adresse IP (@IP) associée au dispositif transactionnel (Dt) ; la détermination (12) d'une localisation courante (LOCC) associée l'adresse IP (@IP) ; la comparaison (13) de la localisation courante (LOCC) avec au moins une localisation autorisée (LOCAs), en fonction dudit identifiant dudit utilisateur (Id) et la fourniture (14), à une entité (Ent) d'une assertion de localisation (Al) lorsque l'étape de comparaison est positive, le procédé étant caractérisé en ce qu'il comprend en outre :
une étape d'obtention (121) d'une route empruntée par des paquets de données pour atteindre ladite adresse IP (@IP) associée audit dispositif transactionnel (Dt), délivrant une liste d'adresse IP empruntées (L@IP) ;
une étape d'association (122) d'au moins une adresse IP de ladite liste d'adresses IP (L@IP) à au moins une localisation, dite localisation de transport (LOCT) ;
Procédé de fourniture d'une assertion de localisation selon la revendication 1, caractérisé en ce qu'il comprend en outre :
une étape de calcul d'un coefficient de confiance en fonction de coefficients associés à ladite au moins une localisation de transport ;
et en ce que ladite étape de délivrance de l'assertion de localisation tient compte d'un seuil de confiance associé audit utilisateur. Procédé de fourniture d'une assertion de localisation selon la revendication 1, caractérisé en ce que ladite étape de délivrance de l'assertion de localisation est réalisée lorsqu'aucune des localisations de transport en fait partie d'une liste de localisation interdite.
Procédé de fourniture d'une assertion de localisation selon la revendication 1, caractérisé en ce qu'il comprend en outre :
une étape d'obtention (123) d'une localisation courante d'un terminal mobile (LOCTm) associé audit utilisateur ;
une étape de comparaison (124) de la localisation courante du dispositif transactionnel (LOCC) avec la localisation courante du terminal mobile associé audit utilisateur (LOCTm) ; et
lorsque l'une de ces deux localisations diffère de l'autre au-delà d'un paramètre de comparaison prédéterminé, une étape de sortie du processus de validation sans délivrance d'une assertion de localisation ;
lorsque ces deux localisations diffèrent en deçà d'un paramètre de comparaison prédéterminé, une étape de sortie du processus de validation avec délivrance d'une assertion de localisation.
Serveur de fourniture d'une assertion de localisation d'un dispositif transactionnel (Dt), lequel ayant sollicité, auprès d'un serveur, par l'intermédiaire d'un réseau de communication, une acceptation d'une transaction financière impliquant l'utilisation de coordonnées bancaires, serveur comprenant :
des moyens de réception (10) d'une requête transactionnelle ( q), en provenance dudit dispositif transactionnel (Dt), comprenant au moins un identifiant d'un utilisateur (id) auquel lesdites coordonnées bancaires sont associées ;
des moyens d'obtention (11) d'une adresse IP (@IP) associée audit dispositif transactionnel (Dt) ; des moyens de détermination (12) d'une localisation courante (LOCC) associée à ladite adresse IP (@IP) ;
des moyens de comparaison (13) de ladite localisation courante (LOCC) avec au moins une localisation autorisée (LOCAs), en fonction dudit identifiant dudit utilisateur (Id) ;
des moyens de fourniture (14), à une entité (Ent) d'une assertion de localisation (Al) lorsque ladite comparaison est positive ;
serveur caractérisé en ce qu'il comprend :
des moyens d'obtention (121) d'une route empruntée par des paquets de données pour atteindre ladite adresse IP (@IP) associée audit dispositif transactionnel (Dt), délivrant une liste d'adresse IP empruntées (L@IP) ;
des moyens d'association (122) d'au moins une adresse IP de ladite liste d'adresses IP (L@IP) à au moins une localisation, dite localisation de transport (LOCT) ;
Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions de code de programme pour l'exécution d'un procédé de fourniture selon la revendication 1, lorsqu'il est exécuté sur un ordinateur.
EP14713484.5A 2013-03-28 2014-03-28 Procédé de délivrance d'une assertion de localisation Ceased EP2979237A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1352846A FR3003976B1 (fr) 2013-03-28 2013-03-28 Procede de delivrance d'une assertion de localisation
PCT/EP2014/056377 WO2014154902A1 (fr) 2013-03-28 2014-03-28 Procédé de délivrance d'une assertion de localisation

Publications (1)

Publication Number Publication Date
EP2979237A1 true EP2979237A1 (fr) 2016-02-03

Family

ID=48741370

Family Applications (1)

Application Number Title Priority Date Filing Date
EP14713484.5A Ceased EP2979237A1 (fr) 2013-03-28 2014-03-28 Procédé de délivrance d'une assertion de localisation

Country Status (8)

Country Link
US (1) US20160063495A1 (fr)
EP (1) EP2979237A1 (fr)
AU (1) AU2014242913A1 (fr)
BR (1) BR112015024761A2 (fr)
CA (1) CA2907630C (fr)
FR (1) FR3003976B1 (fr)
RU (1) RU2015146303A (fr)
WO (1) WO2014154902A1 (fr)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10708778B2 (en) * 2014-04-29 2020-07-07 Taliware, Inc. Method and system for authenticating an individual's geo-location via a communication network and applications using the same
US20170048815A1 (en) * 2015-08-12 2017-02-16 Cisco Technology, Inc. Location Awareness to Packet Flows using Network Service Headers
US9935961B2 (en) * 2015-09-11 2018-04-03 Bank Of America Corporation Controlling access to data
US10810571B2 (en) 2016-10-13 2020-10-20 Paypal, Inc. Location-based device and authentication system

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000022495A2 (fr) * 1998-10-15 2000-04-20 Liquid Audio, Inc. Determination territoriale de l'emplacement d'un ordinateur a distance dans un reseau longue distance en vue d'une remise conditionnelle de produits numerises
EP2287792A1 (fr) * 2009-08-19 2011-02-23 MasterCard International Incorporated Contrôles de localisation pour transactions par carte de paiement

Family Cites Families (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7685311B2 (en) * 1999-05-03 2010-03-23 Digital Envoy, Inc. Geo-intelligent traffic reporter
US6757740B1 (en) * 1999-05-03 2004-06-29 Digital Envoy, Inc. Systems and methods for determining collecting and using geographic locations of internet users
US20020052841A1 (en) * 2000-10-27 2002-05-02 Guthrie Paul D. Electronic payment system
WO2002071227A1 (fr) * 2001-03-01 2002-09-12 Cyber Operations, Llc Systeme et procede anti-piratage de reseau
US20020194140A1 (en) * 2001-04-18 2002-12-19 Keith Makuck Metered access to content
CA2463891C (fr) * 2001-10-17 2012-07-17 Npx Technologies Ltd. Verification d'un code d'identification personnel recu en ligne
JP2003174443A (ja) * 2001-12-07 2003-06-20 Sony Corp 情報処理装置および方法、プログラム格納媒体、並びにプログラム
US20030172036A1 (en) * 2002-03-05 2003-09-11 Idan Feigenbaum Online financial transaction veracity assurance mechanism
US7752324B2 (en) * 2002-07-12 2010-07-06 Penn State Research Foundation Real-time packet traceback and associated packet marking strategies
US8248968B2 (en) * 2003-10-03 2012-08-21 Apple Inc. Method and apparatus for providing mobile inter-mesh communication points in a multi-level wireless mesh network
EP1664687A4 (fr) * 2003-09-12 2009-01-14 Rsa Security Inc Systeme et procede d'authentification apres evaluation des risques
US20050071417A1 (en) * 2003-09-29 2005-03-31 Jeffrey Taylor Method and apparatus for geolocation of a network user
US7760663B2 (en) * 2004-04-19 2010-07-20 Jds Uniphase Corporation Packet tracing using dynamic packet filters
US8059551B2 (en) * 2005-02-15 2011-11-15 Raytheon Bbn Technologies Corp. Method for source-spoofed IP packet traceback
US8418226B2 (en) * 2005-03-18 2013-04-09 Absolute Software Corporation Persistent servicing agent
US8656458B2 (en) * 2005-08-25 2014-02-18 Guy Heffez Method and system for authenticating internet user identity
EP1875653B1 (fr) * 2005-04-29 2018-12-12 Oracle International Corporation Système et procédé de contrôle et détection de fraude et authentification utilisateur à plusieurs niveaux
BRPI0615559A2 (pt) * 2005-07-20 2017-09-12 Verimatrix Inc sistema e método de autenticação de usúario de rede
US20070204033A1 (en) * 2006-02-24 2007-08-30 James Bookbinder Methods and systems to detect abuse of network services
EP2506184A1 (fr) * 2006-03-29 2012-10-03 The Bank of Tokyo-Mitsubishi UFJ, Ltd. Dispositif, procédé et programme de validation d'utilisateur
US7856494B2 (en) * 2006-11-14 2010-12-21 Fmr Llc Detecting and interdicting fraudulent activity on a network
GB2449510A (en) * 2007-05-24 2008-11-26 Asim Bucuk A method and system for the creation, management and authentication of links between people, entities, objects and devices
WO2008151321A2 (fr) * 2007-06-08 2008-12-11 The Trustees Of Columbia University In The City Of New York Systèmes, procédés, et supports pour la mise en œuvre d'une règle de sécurité dans un réseau comportant une pluralité de composants
US8983497B2 (en) * 2007-10-04 2015-03-17 Zos Communications, Llc Method for managing a geo-targeted campaign
US8793758B2 (en) * 2009-01-28 2014-07-29 Headwater Partners I Llc Security, fraud detection, and fraud mitigation in device-assisted services systems
US9392462B2 (en) * 2009-01-28 2016-07-12 Headwater Partners I Llc Mobile end-user device with agent limiting wireless data communication for specified background applications based on a stored policy
US20120254333A1 (en) * 2010-01-07 2012-10-04 Rajarathnam Chandramouli Automated detection of deception in short and multilingual electronic messages
US8381281B2 (en) * 2010-04-07 2013-02-19 International Business Machines Corporation Authenticating a remote host to a firewall
WO2012006098A2 (fr) * 2010-06-28 2012-01-12 Vivotech Inc. Procédés, systèmes et supports lisibles par ordinateur pour faciliter une commande et un paiement de biens et services en magasin ou à proximité d'un magasin au moyen d'une tape unique d'un dispositif de communication en champ proche (nfc)
US8566233B2 (en) * 2010-07-29 2013-10-22 Intel Corporation Device, system, and method for location-based payment authorization
KR101327434B1 (ko) 2010-10-20 2013-11-20 비씨카드(주) 고객 단말기의 맥 어드레스 정보를 이용한 결제 방법 및 시스템
US10373160B2 (en) * 2011-02-10 2019-08-06 Paypal, Inc. Fraud alerting using mobile phone location
US9380102B2 (en) * 2011-03-02 2016-06-28 Verizon Patent And Licensing Inc. Secure management of SIP user credentials
US9424603B2 (en) * 2011-09-13 2016-08-23 Visa International Service Association Mobile location notifications system and method
TWI439033B (zh) * 2012-04-06 2014-05-21 Anpec Electronics Corp 應用於靴帶電路之直流轉換器
US20130282523A1 (en) * 2012-04-20 2013-10-24 Howard Pfeffer Network service provider assisted payment fraud detection and mitigation methods and apparatus
US9853995B2 (en) * 2012-11-08 2017-12-26 AO Kaspersky Lab System and method for restricting pathways to harmful hosts in computer networks

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000022495A2 (fr) * 1998-10-15 2000-04-20 Liquid Audio, Inc. Determination territoriale de l'emplacement d'un ordinateur a distance dans un reseau longue distance en vue d'une remise conditionnelle de produits numerises
EP2287792A1 (fr) * 2009-08-19 2011-02-23 MasterCard International Incorporated Contrôles de localisation pour transactions par carte de paiement

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of WO2014154902A1 *

Also Published As

Publication number Publication date
AU2014242913A1 (en) 2015-11-12
FR3003976B1 (fr) 2016-08-26
US20160063495A1 (en) 2016-03-03
FR3003976A1 (fr) 2014-10-03
CA2907630C (fr) 2022-07-19
WO2014154902A1 (fr) 2014-10-02
BR112015024761A2 (pt) 2017-07-18
RU2015146303A (ru) 2017-05-04
CA2907630A1 (fr) 2014-10-02

Similar Documents

Publication Publication Date Title
EP3032799B1 (fr) Procédé d'authentification d'un utilisateur, serveur, terminal de communication et programmes correspondants
EP3857413A1 (fr) Procede de traitement d'une transaction, dispositif, systeme et programme correspondant
EP3163487B1 (fr) Procédé de sécurisation de traitement de données transactionnelles, terminal et programme d'ordinateur correspondant
EP2979237A1 (fr) Procédé de délivrance d'une assertion de localisation
EP1762037A2 (fr) Procede et systeme de certification de l'identite d'un utilisateur
FR3061971A1 (fr) Procede d'authentification en deux etapes, dispositif et programme d'ordinateur correspondant
EP3479518A1 (fr) Procede d'authentification de donnees de paiement, dispositifs et programmes correspondants
EP3588418A1 (fr) Procédé de réalisation d'une transaction, terminal, serveur et programme d ordinateur correspondant
FR2888691A1 (fr) Procede et dispositif d'autorisation de transaction
CA2973836A1 (fr) Procede de traitement de donnees par un dispositif electronique d'acquisition de donnees, dispositif et programme correspondant
EP3095223B1 (fr) Méthode de transmission de données chiffrées, méthode de réception, dispositifs et programmes d'ordinateur correspondants
WO2018002349A1 (fr) Procédé d'authentification de données de paiement, dispositifs et programmes correspondants.
EP3113094B1 (fr) Procédé de traitement de données transactionnelles, dispositif et programme correspondant
EP3570238B1 (fr) Procédé de réalisation d'une transaction, terminal, serveur et programme d'ordinateur correspondant
EP2897095B1 (fr) Procédé de sécurisation d'une transaction réalisée par carte bancaire
EP2911365B1 (fr) Procédé et système de sécurisation de transactions offertes par une pluralité de services entre un appareil mobile d'un utilisateur et un point d'acceptation
CA2946145C (fr) Procedes de traitement de donnees transactionnelles, dispositifs et programmes correspondants
WO2017077210A1 (fr) Procédé de verification d'identité lors d'une virtualisation
WO2017005644A1 (fr) Procédé et système de contrôle d'accès à un service via un média mobile sans intermediaire de confiance
FR3011111A1 (fr) Securisation d'une transmission de donnees d'identification
FR3031217A1 (fr) Procede de verification d'une requete de paiement comprenant la determination de la localisation du provisionnement d'un jeton de paiement
FR3031609A1 (fr) Procede de traitement d'une transaction a partir d'un terminal de communication

Legal Events

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

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20150917

AK Designated contracting states

Kind code of ref document: A1

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

AX Request for extension of the european patent

Extension state: BA ME

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

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20180917

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

Free format text: STATUS: EXAMINATION IS IN PROGRESS

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

Free format text: STATUS: EXAMINATION IS IN PROGRESS

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: BANKS AND ACQUIRERS INTERNATIONAL HOLDING

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

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

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20221128