FR3003976A1

FR3003976A1 - Procede de delivrance d'une assertion de localisation

Info

Publication number: FR3003976A1
Application number: FR1352846A
Authority: FR
Inventors: Michel Leger
Original assignee: Compagnie Industrielle et Financiere dIngenierie Ingenico SA
Current assignee: Banks and Acquirers International Holding SAS
Priority date: 2013-03-28
Filing date: 2013-03-28
Publication date: 2014-10-03
Anticipated expiration: 2033-03-28
Also published as: CA2907630C; WO2014154902A1; BR112015024761A2; AU2014242913A1; US20160063495A1; RU2015146303A; CA2907630A1; EP2979237A1; FR3003976B1

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 PaypalTM, 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 oeuvre 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 Present » 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 W02012053780. 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 oeuvre, 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 W02012053780 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 W02012053780 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 oeuvre 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 oeuvre 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 disc) 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 oeuvre 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 oeuvre 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 oeuvre 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 oeuvre ses propres modules logiciels.

Les différents modes de réalisation mentionnés ci-dessus sont combinables entre eux pour la mise en oeuvre 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 oeuvre un procédé de délivrance d'assertion de localisation ; la figure 5 illustre une architecture d'un client apte à mettre en oeuvre 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 oeuvre. On présente par la suite, une mise en oeuvre du principe exposé précédemment.

Cette mise en oeuvre n'est nullement limitative et toute autre mise en oeuvre 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 oeuvre comprend : une étape de réception (10) d'une requête transactionnelle (Rq), 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 (AI) à une entité (Ent). L'assertion de localisation (AI) 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 oeuvre 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 oeuvre 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 oeuvre 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 oeuvre 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 oeuvre (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 oeuvre 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 oeuvre 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 oeuvre 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 oeuvre 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 oeuvre 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 oeuvre 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 oeuvre 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 oeuvre 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 oeuvre le procédé selon l'invention. Dans au moins un mode de réalisation, l'invention est mise en oeuvre 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 oeuvre 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 (c.f.

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 oeuvre 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 oeuvre le procédé selon l'invention. Dans au moins un mode de réalisation, l'invention est mise en oeuvre 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).25

Claims

REVENDICATIONS1. 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, procédé caractérisé en ce qu'il 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 (AI) lorsque ladite étape de comparaison est positive.
2. 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 (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) ;30
3. Procédé de fourniture d'une assertion de localisation selon la revendication 2, 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.
4. Procédé de fourniture d'une assertion de localisation selon la revendication 2, 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.
5. 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.
6. 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'unetransaction financière impliquant l'utilisation de coordonnées bancaires, serveur caractérisé en ce qu'il comprend : - des moyens de réception (10) d'une requête transactionnelle (Rq), 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 (AI) lorsque ladite comparaison est positive.
7. 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.