FR3043232A1 - Procede de verification d'identite lors d'une virtualisation - Google Patents

Abstract

L'invention concerne un procédé de gestion de la vérification de l'identité d'un utilisateur d'un objet (CC) à virtualiser dans une mémoire liée à un terminal (M) de l'utilisateur. L'objet comporte au moins une donnée, dite donnée d'identification, en rapport avec l'identité de son porteur. Le terminal est apte à communiquer avec un serveur de virtualisation (A) d'un agrégateur du service de virtualisation, ledit serveur de virtualisation (A) étant apte à communiquer avec un serveur de vérification (B) ayant le contrôle de l'objet (CC). L'invention concerne aussi un procédé de vérification de l'identité d'un utilisateur d'un objet (CC).

Description

Procédé de vérification d'identité lors d'une virtualisation.

Domaine technique L'invention se rapporte au domaine de la virtualisation, ou dématérialisation (en anglais « tokenization ») d'objets liés à l'identité d'un utilisateur.

En particulier, l'invention se rapporte à la vérification d'identités effectuées lors de la virtualisation de tels objets.

Plus particulièrement, l'invention concerne la sécurité et la protection des données personnelles des clients des méthodes de virtualisation des cartes bancaires.

Etat de la technique

Des systèmes de paiement dits « dématérialisés » sont apparus récemment, pour effectuer des paiements grâce à une carte bancaire dématérialisée sur un support électronique, par exemple un terminal mobile, apte à effectuer des paiements à distance (« remote payment ») ou en proximité avec une borne de paiement, par exemple de type sans contact (NFC).

Dans la suite on parlera indifféremment de « dématérialisation » ou de « virtualisation » d'un objet.

Ces méthodes sont apparues dans un premier temps dans des pays qui ne se soucient pas de la protection des données personnelles.

La méthode de virtualisation utilisée par ces systèmes de paiement est la suivante : le client, ou porteur de la carte, entre les informations bancaires inscrites sur sa carte dans une application du terminal contrôlée par un agrégateur, ou fournisseur, du service de paiement. Par exemple, selon une méthode connue, le porteur photographie sa carte bancaire et renseigne le code de sécurité qui se situe au verso. Alternativement, il entre manuellement ces informations, essentielles à l'identification du porteur de la carte lors d'une transaction. La banque qui est responsable du compte bancaire associé à la carte doit valider la virtualisation si elle estime que la personne qui a rentré les informations est réellement le client titulaire de la carte, ou porteur. A cet effet, les données de virtualisation correspondant à la carte, ou jeton (en anglais, tokeri), sont chiffrées au niveau du terminal à l'aide de clés de chiffrage connues uniquement par l'organisme bancaire responsable de la carte (ou par l'organisme gérant le schéma bancaire en délégation de l'organisme bancaire responsable de la carte) avant d'être envoyées vers un serveur de l'agrégateur de service, qui renvoie les données vers la banque. La banque reçoit les données, éventuellement chiffrées, et, éventuellement accompagnées de données secondaires comme le nom du terminal, sa position, etc. Lorsque la banque a reçu les données chiffrées, elle dispose de deux méthodes bien connues de vérification de l'identité du porteur de la carte (par vérification de l'identité du porteur, on entend un mécanisme visant à s'assurer que la carte bancaire est bien celle de la personne qui la charge dans le terminal) : - une méthode de validation automatique du porteur de la carte, après consultation du contenu des données reçues. Cette méthode est aussi appelée le "green path" par l'homme du métier. Elle n'inclut aucun mécanisme de sécurité actif au-delà de la simple analyse par la banque de toutes les données reçue lors de la demande de virtualisation ; - une méthode de validation avec vérification secondaire, au cours de laquelle le porteur fournit une autre preuve de son identité pour s'assurer que l'enregistrement de la carte est bien faite par le porteur et non par une autre personne qui l'aurait dérobée. Cela peut être fait au moyen d'une interaction supplémentaire entre la banque et l'utilisateur pour obtenir une preuve supplémentaire : envoi d'un code par SMS, courrier électronique, appel téléphonique, etc. Cette méthode est appelée le "yellow path" par l'homme du métier. Ce procédé augmente la confiance liée à l'identification et la vérification du porteur de la carte mais souffre cependant d'un inconvénient : le niveau de sécurité additionnel apporté est très variable et est souvent dépendant de facteurs humains. Certaines banques ne réclament en effet comme preuve que quelques chiffres d'un numéro personnel tel le numéro de sécurité sociale, une information relativement aisée à obtenir par des malfaiteurs dans le but d'enregistrer des cartes dont ils ne sont pas porteurs afin de réaliser des achats frauduleux.

Il a donc été suggéré de complexifier encore le mécanisme de création d'une carte dématérialisée, pour s'assurer que la carte bancaire est bien celle de la personne qui la charge dans le téléphone : code d'autorisation supplémentaire de la banque envoyé par mail ou téléphone à l'utilisateur, injonction de la banque au porteur d'appeler un numéro de service client pour vérifier son identité via une série de questions sur ses achats récents, connexion au compte bancaire en ligne du client, etc.

Ces solutions sont cependant compliquées à mettre en œuvre pour la banque, les temps de traitement des informations et le coût de mise en œuvre étant augmentés par les interactions supplémentaires avec l'utilisateur, et pénibles pour le porteur car ce type de méthode nécessite de son côté une interaction supplémentaire avec la banque.

Il n'existe pas aujourd'hui de possibilité de virtualisation d'un tel objet, par exemple une carte bancaire, de manière sécurisée, fiable, respectant les contraintes juridiques éventuelles liées au partage des données personnelles du porteur, et peu complexe. L’invention offre une solution ne présentant pas les inconvénients de l’état de la technique. L’invention A cet effet, selon un aspect fonctionnel, l’invention a pour objet un procédé de gestion de la vérification de l'identité d'un utilisateur d'un objet à virtualiser dans une mémoire liée à un terminal de l'utilisateur, l'objet comportant au moins une donnée, dite donnée d'identification, en rapport avec l'identité de son porteur, ledit terminal étant apte à communiquer avec un serveur de virtualisation d'un agrégateur du service de virtualisation, ledit serveur de virtualisation étant apte à communiquer avec un serveur de vérification ayant le contrôle de l'objet, ledit procédé comportant les étapes de : - obtention, par le serveur de virtualisation, de la donnée d'identification de l'objet fournie par l'utilisateur ; - transmission, par le serveur de virtualisation, au serveur de validation, de la donnée d'identification ; caractérisé en ce qu'il comporte en outre les étapes de : - obtention, par le serveur de virtualisation, d'une donnée relative à l'utilisateur ; - génération par le serveur de virtualisation d'une première donnée de vérification fonction de la première donnée relative à l'utilisateur ; - transmission par le serveur de virtualisation au serveur de validation de la première donnée de vérification ; - obtention, par le serveur de validation, d'une seconde donnée relative au porteur ; - génération, par le serveur de validation, d'une seconde donnée de vérification fonction de la seconde donnée obtenue relative au porteur, ladite fonction étant identique à celle utilisée lors de l'étape de génération de la première donnée de vérification ; - comparaison de la première et de la seconde donnée de vérification ; - en fonction du résultat de la comparaison, validation de l'identité de l'utilisateur.

Avantageusement, le procédé selon l'invention permet, sur la base d'une donnée relative à l'utilisateur et au porteur, connue respectivement du fournisseur de services, ou agrégateur de contenus, et de l'entité en charge de l'identification, typiquement une banque, de réaliser l'identification de manière fiable. La connaissance d'une telle donnée, comme par exemple le numéro de téléphone du porteur, permet en effet la mise en œuvre d'une opération simple d'évaluation d'une donnée de vérification de part et d'autre, sur chacun des serveurs : si les données de vérification sont identiques, cela signifie que la donnée relative à l'utilisateur et celle relative au porteur, connues respectivement de chacune des deux entités (le fournisseur de services et la banque) est la même, et donc que l'utilisateur de la carte (celui qui demande le service) est bien le porteur, ou titulaire de la carte auprès de la banque.

Par « obtention », on entend une opération simple permettant au serveur A (ou B) de se procurer la donnée connue de l'entité correspondante, typiquement par une lecture dans la base de donnée de l'entité, et qui exclut la transmission directe d'une entité à l'autre.

Cela permet par conséquent de vérifier l'identité du porteur par une méthode de type « green path » sécurisée où la vérification que le porteur de l'objet et l'utilisateur du mobile sont une seule et même personne est prouvée automatiquement. Il n'est donc pas nécessaire, en utilisant ce mécanisme, de procéder ultérieurement à une vérification supplémentaire de l'identité du porteur (de type « yellow path »). La banque s'affranchit de cette manière d'une opération complexe et coûteuse, et le porteur d'une opération fastidieuse. Par ailleurs, on note que la banque n'a jamais eu à transmettre la donnée personnelle (MSISDN) à une entité tierce (le fournisseur de service), ce qui dans certaines législations serait parfois impossible dans le cadre des lois en vigueur sur la protection des données personnelles.

Par « objet à virtualiser » on entend ici tout type d'objet susceptible d'être virtualisé, qu'il soit physique (carte électronique de type bancaire par exemple) ou virtuel (jeton de paiement virtuel, etc.)

Par « mémoire liée au terminal » on entend que la mémoire est dans le terminal mobile ou dans une mémoire externe, celle-ci pouvant être un élément de sécurité de type carte SIM, une zone mémoire sécurisée de type « Trusted Execution Environment », etc.

Par « utilisateur » on entend ici la personne qui fournit la donnée d'identification. Si cet utilisateur est le porteur de la carte, l'identification devrait être réussie. Sinon, la vérification devrait échouer.

Par « donnée d'identification, en rapport avec l'identité de son porteur », on entend toute donnée qui peut servir à identifier le porteur de l'objet au cours d'une transaction, par exemple son numéro de carte dans le cas d'une carte bancaire.

Par « agrégateur du service de virtualisation » on entend une entité qui est capable d'offrir un service au client, de type virtualisation, pour l'un de ses objets (par exemple une carte de paiement).

Par « serveur de vérification (B) ayant le contrôle de l'objet » on entend un serveur de l'entité qui a fourni l'objet au porteur et qui dispose d'informations sur l'identité dudit porteur (par exemple, un serveur d'une institution bancaire, de transport, etc.)

Selon un premier mode de mise en oeuvre particulier de l’invention, un procédé tel que décrit ci-dessus est caractérisé en ce que l'objet à virtualiser est une carte électronique et en ce que le procédé comporte en outre les étapes de : - génération d'un jeton représentatif de la carte électronique de l'utilisateur ; - livraison du jeton au terminal mobile par le serveur de virtualisation ; - stockage du jeton dans la mémoire liée au terminal mobile de l'utilisateur. - après la validation de l'identité du porteur, activation du jeton.

Par carte électronique, on entend ici tout type de carte physique susceptible d'être virtualisée (dématérialisée) : carte de bancaire (de paiement, de crédit, de débit, etc.) mais aussi carte de transport, de fidélité, etc.

Avantageusement selon ce mode de réalisation, la virtualisation effective, c'est-à-dire l'activation du « token », est effectuée seulement si l'identification du porteur a réussi. On notera que la génération du « token » et sa mémorisation peuvent être effectuées préalablement, le jeton ne devenant effectivement actif qu'après la validation de l'identification.

Selon un second mode de mise en œuvre particulier de l’invention, qui pourra être mis en œuvre alternativement ou cumulativement avec le précédent, un procédé tel que décrit ci-dessus est en outre caractérisé en ce que l'agrégateur, ou fournisseur de service, est l'opérateur mobile du terminal mobile et en en ce que la seconde donnée relative au porteur et la première donnée relative à l'utilisateur sont le numéro d'appel du terminal mobile.

Avantageusement selon ce mode, le numéro de téléphone est forcément connu de l'opérateur mobile qui contrôle le terminal mobile de l'utilisateur ; comme ce numéro est par ailleurs très probablement connu de l'entité qui a émis (la banque du porteur) l'objet à virtualiser, cette connaissance commune aux deux entités permet de simplifier considérablement le processus d'identification tout en conservant une sécurité élevée. De surcroît les données personnelles (ici, le numéro de téléphone) restent protégées car il n'y a pas d'échange de telles données entre les deux entités.

Selon un troisième mode de mise en œuvre particulier de l’invention, qui pourra être mis en œuvre alternativement ou cumulativement avec les précédents, un procédé tel que décrit ci-dessus est en outre caractérisé en ce que qu'il comporte les étapes de : - génération d'un aléa par le serveur de virtualisation ; - transmission de l'aléa par le serveur de virtualisation au serveur de validation ; et en ce que les générations d'une première et d'une seconde donnée de vérification sont fonction de l'aléa.

Avantageusement selon ce mode, un aléa est utilisé en plus de la donnée relative au porteur et/ou utilisateur pour générer la donnée de vérification. L'aléa devient un paramètre de la fonction F de génération. L'utilisation d'une telle valeur aléatoire, différente pour chaque opération de virtualisation, et connue uniquement des deux entités responsables des deux serveurs, permet d'augmenter le degré de sécurité de l'identification et de garantir une meilleure protection des données personnelles du client en ce que, la donnée de vérification générée étant différente à chaque mise en œuvre du procédé (même pour le même MSISDN), les entités tierces par lesquelles passe la communication ne seront pas capable d'effectuer des corrélations qui permettraient de cerner le profil du porteur (âge, préférences, etc.)

Selon un quatrième mode de mise en œuvre particulier de l’invention, qui pourra être mis en œuvre alternativement ou cumulativement avec les précédents, un procédé tel que décrit ci-dessus est en outre caractérisé en ce qu'il comporte une étape de transmission de la fonction pour la génération d'une donnée de vérification par le serveur de virtualisation au serveur de validation .

Avantageusement selon ce mode, la fonction de génération peut être modifiée facilement puisque sa transmission implique qu'elle est connue des deux entités qui contrôlent les deux serveurs (par exemple, l'opérateur mobile et la banque du porteur).

Selon un cinquième mode de mise en œuvre particulier de l’invention, qui pourra être mis en œuvre alternativement ou cumulativement avec les précédents, un procédé tel que décrit ci-dessus est en outre caractérisé en ce que la fonction de génération est injective et possède une fonction réciproque secrète.

Par « secrète », on entend que la fonction réciproque (G) doit rester en possession de la première entité (A). Elle est typiquement déterminée par A au moment de la création de la fonction de génération (F).

Avantageusement selon ce mode, la fonction réciproque permet de prouver que l'on a bien transmis la bonne donnée relative à l'utilisateur (MSISDN), en cas de contestation.

Selon un autre aspect fonctionnel, l’invention concerne également un procédé de génération d'un élément d'identification d'un objet à virtualiser dans une mémoire liée à un terminal de l'utilisateur, l'objet comportant au moins une donnée, dite donnée d'identification, en rapport avec l'identité de son porteur, le dit terminal étant apte à communiquer avec un serveur de virtualisation d'un agrégateur du service de virtualisation, ledit serveur de virtualisation étant apte à communiquer avec un serveur de vérification ayant le contrôle de l'objet, ledit procédé comportant sur le serveur de virtualisation les étapes de : - obtention de la donnée d'identification de l'objet fournie par l'utilisateur ; - transmission au serveur de validation de la donnée d'identification ; caractérisé en ce qu'il comporte en outre les étapes de : - obtention d'une première donnée relative à l'utilisateur ; - génération d'une première donnée de vérification fonction de la première donnée relative à l'utilisateur ; - transmission au serveur de validation de la première donnée de vérification ;

Selon un autre aspect fonctionnel, l’invention concerne également un procédé de vérification de l'identité d'un utilisateur d'un objet comportant au moins une donnée, dite donnée d'identification, en rapport avec l'identité de son porteur, sur un serveur de vérification ayant le contrôle de l'objet, ledit procédé étant caractérisé en ce qu'il comporte les étapes de : - réception d'une première donnée de vérification ; - obtention d'une seconde donnée relative au porteur ; - génération d'une seconde donnée de vérification fonction de la donnée obtenue relative au porteur; - comparaison de la première et de la seconde donnée de vérification ; - en fonction du résultat de la comparaison, validation de l'identité du porteur.

Selon un autre aspect matériel, l’invention concerne également un système de vérification de l'identité d'un utilisateur d'un objet à virtualiser comportant au moins une donnée, dite donnée d'identification, en rapport avec l'identité de son porteur, le système comportant : - un terminal mobile d'un l'utilisateur comportant : o un module pour fournir la donnée d'identification ; o un module pour stocker les données de virtualisation ; o un module de communication pour communiquer avec un serveur de virtualisation, - un serveur de virtualisation d'un agrégateur du service de virtualisation, comportant : o un module de communication pour communiquer avec un serveur de vérification ; o un module d'obtention de la donnée d'identification de l'objet fournie par l'utilisateur ; o un module de transmission de la donnée d'identification; o un module d'obtention d'une première donnée relative à l'utilisateur; o un module de génération d'une première donnée de vérification fonction de la première donnée relative à l'utilisateur; o un module de transmission de la première donnée de vérification, - un serveur de vérification ayant le contrôle de l'objet comportant o un module d'obtention d'une seconde donnée relative au porteur; o un module de génération d'une seconde donnée de vérification fonction de la donnée obtenue relative au porteur; o un module de comparaison d'une première et d'une seconde donnée de vérification ; o un module de validation, en fonction du résultat de la comparaison, de l'identité du porteur.

Le terme module peut correspondre aussi bien à un composant logiciel qu'à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d'ordinateur, de mobile (application dans un téléphone mobile) ou de manière plus générale à tout élément d'un programme apte à mettre en œuvre une fonction ou un ensemble de fonctions telles que décrites pour les modules concernés. 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 pour le module concerné (circuit intégré, carte à puce, carte à mémoire, etc.).

Selon un autre aspect matériel, l’invention concerne également un programme d’ordinateur apte à être mis en œuvre dans un procédé de gestion de la vérification de l'identité d'un utilisateur tel que défini précédemment, le programme comprenant des instructions de code qui, lorsque le programme est exécuté par un processeur, en réalise les étapes.

Selon un autre aspect matériel, l’invention concerne également un programme d’ordinateur apte à être mis en œuvre dans un procédé de génération d'un élément d'identification tel que défini précédemment, le programme comprenant des instructions de code qui, lorsque le programme est exécuté par un processeur, en réalise les étapes.

Selon un autre aspect matériel, l’invention concerne également un programme d’ordinateur apte à être mis en œuvre dans un procédé de vérification de l'identité d'un utilisateur tel que défini précédemment, le programme comprenant des instructions de code qui, lorsque le programme est exécuté par un processeur, en réalise les étapes.

Selon encore un autre aspect matériel, l'invention a trait à un support d’enregistrement lisible par un processeur de données sur lequel est enregistré un programme comprenant des instructions de code de programme pour l’exécution des étapes de l'un des procédés définis ci-dessus. L’invention sera mieux comprise à la lecture de la description qui suit, donnée à titre d’exemple et faite en référence aux dessins annexés.

Les figures:

La figure 1 représente un système (S) illustrant un mode de réalisation d'un procédé de vérification d'identité lors de la virtualisation d'une carte bancaire selon l'invention.

Description détaillée d’un exemple de réalisation illustrant l’invention

La figure 1 représente un système (S) illustrant un mode de réalisation d'un procédé de vérification d'identité lors de la virtualisation d'une carte bancaire selon l'invention.

Selon ce mode de réalisation de l'invention, l'utilisateur C demande à son fournisseur de services dématérialisés, aussi appelé ici agrégateur de services, la virtualisation, ou dématérialisation, dans son terminal mobile (M), d'une carte bancaire (CC) associé à son compte bancaire dans une banque (B). Selon ce mode de réalisation de l'invention, le jeton (token, T) résultant de la virtualisation sera mémorisé à la fin de la transaction dans un élément de sécurité du terminal mobile et optionnellement activé au niveau de l'infrastructure de l'entité B si la vérification de l'utilisateur a réussi, c'est-à-dire s'il est bien le porteur de la carte.

Le jeton pourrait alternativement être mémorisé dans la mémoire interne du terminal mobile ou toute autre mémoire externe accessible par celui-ci.

La banque est représentée ici par le biais d'un serveur (B) de validation. Cette représentation est naturellement très schématique. Le serveur de validation de la banque est généralement lié à un autre serveur, chargé de réaliser ce qui est appelé le « schéma bancaire » par l'homme du métier, et qui sert d'intermédiaire entre le serveur de virtualisation et le serveur de validation à proprement parler. Dans ce mode de réalisation de l'invention, pour des raisons de simplicité, les serveurs de validation et de « schéma bancaire » sont confondus en un seul serveur B associé à la banque. L'invention repose sur le principe d'une connaissance commune, entre les deux entités (agrégateur et banque) d'une donnée relative d'une part à l'utilisateur, d'autre part au porteur.

Les étapes d'un procédé selon ce mode de réalisation sont détaillées dans la suite. L'utilisateur entre, lors d'une étape E10, les données de sa carte bancaire (CC) à dématérialiser, via une interface graphique d'une application mobile s'exécutant dans cet exemple sur son terminal mobile (M) sous contrôle de l'agrégateur de service. Lors de cette étape on ne sait pas encore si l'utilisateur est véritablement le porteur de la carte.

Le serveur A, dit serveur de virtualisation, de l'agrégateur de services, est chargé dans cet exemple de transmettre à un serveur de validation (B) de la banque responsable de la carte (CC) la requête de virtualisation (Token request) pour identification du porteur de la carte bancaire. Selon ce mode de réalisation, le serveur A connaît une donnée spécifique à l'utilisateur. Dans cet exemple, le serveur A est le serveur d'un opérateur mobile de l'utilisateur et la donnée est le numéro de téléphone, ou MSISDN, de son terminal mobile. Naturellement le serveur A pourrait dépendre d'un autre type d'entité (centre des impôts, centre de sécurité sociale, etc.), ainsi que le serveur B.

Lors d'une étape E21, le serveur A de l'agrégateur de service transmet la requête au serveur B de la banque du porteur pour identification du porteur et validation de la virtualisation.

On notera que, comme expliqué auparavant, le serveur de validation de la banque B fait généralement appel à d'autres entités, dont au moins un autre serveur connu sous le nom de « schéma bancaire » par l'homme du métier, responsable notamment de la génération des jetons (T). Pour des raisons de simplicité, un seul serveur B est ici représenté en association avec la banque.

Le serveur de validation (B) de la banque, recevant la requête au cours d'une étape E30, va devoir s'assurer que le client du serveur A, utilisateur du téléphone mobile M, est bien le même individu que celui disposant du compte bancaire associé à la carte bancaire CC et non une autre personne qui l'aurait dérobée. Comme expliqué auparavant, la banque B dispose de mécanismes d'authentification et de validation qui lui sont propres. Selon l'état de l'art, elle identifie le porteur par une méthode connue sous le nom de « green path » (validation automatique du porteur de la carte, après réception et analyse des données) ou « yellow path » (validation avec vérification secondaire, au cours de laquelle le porteur fournit une autre preuve de son identité). La première méthode est sans preuve sur l'identité réelle du porteur de la carte, dans la mesure où elle n'inclut aucun mécanisme de sécurité actif au-delà de la simple analyse par la banque des données reçue lors de la demande de virtualisation. La seconde n'est pas absolument fiable, augmente la complexité du système bancaire et ralentit le temps de traitement des requêtes des clients, ce qui peut être très pénalisant notamment si plusieurs requêtes doivent être traitées simultanément.

Selon ce mode de réalisation de l'invention, la requête du serveur A est enrichie par des informations qui peuvent être contrôlées par la banque, lui évitant ainsi d'appliquer une méthode complexe de type « yellow path » tout en garantissant l'authentification du porteur C de la carte CC à l'origine de la requête.

Lors d'une étape E22, le serveur A génère un aléa correspondant à la transaction. Un aléa est classiquement un nombre généré aléatoirement. Le fait d'avoir un nombre aléatoire différent à chaque transaction permet de garantir le respect des obligations légales de gestion des données personnelles de A (le MSISDN selon cet exemple) en s'assurant, la donnée de vérification générée étant différente à chaque mise en œuvre du procédé, que des entités tierces par lesquelles passe la communication ne seront pas capable d'effectuer des corrélations qui permettraient de reconstruire le profil du porteur.

Selon une variante, les échanges entre A et B sont effectués dans une session chiffrée, selon un mécanisme bien connu de l'homme du métier (par exemple sur une base de communication de type TLS avec authentification mutuelle en utilisant des certificats), qui garantit les propriétés suivantes : • authentification mutuelle forte entre A et B ; • confidentialité des échanges ; • intégrité des échanges.

En combinaison avec le respect des obligations légales de A, cela permet d'assurer une sécurité maximale des échanges pour B en évitant en particulier les attaques par un mécanisme dit « de rejeux » (réémission de données déjà échangées à des fins de fraude, pour simuler une requête légitime).

Selon cet exemple, le serveur A transmet également à l'opérateur B une fonction, dite fonction de vérification (F, HASH), à appliquer aussi au nombre aléatoire. Naturellement, cette fonction peut avoir été fournie auparavant à la banque.

Ces données (aléa, fonction F) sont reçues par le serveur de la banque au cours d'une étape E31.

Lors d'une étape E23, le serveur A récupère une donnée relative à l'utilisateur, sans son intervention. Selon cet exemple, le serveur A est le serveur d'un opérateur mobile de l'utilisateur et la donnée est le numéro de téléphone, ou MSISDN, qu'il connaît forcément (sans avoir à la demander à l'utilisateur ou à une entité tierce).

Lors d'une étape E24, le serveur A génère une donnée de vérification à transmettre à la banque, tenant compte de cette donnée de l'utilisateur et de l'aléa, en utilisant la fonction de génération F, cette donnée de vérification étant notée sur la figure F(MSISDN+ ALEA).

Selon un mode de réalisation, la génération consiste à « hacher » l'aléa concaténé avec le numéro de téléphone. Une telle fonction de « hachage » est bien connue de l'homme du métier.

Selon un autre mode de réalisation, la fonction F est une fonction injective, c'est-à-dire que tout résultat obtenu par cette fonction admet au plus un antécédent. Dans ce cas, selon une variante, le serveur A possède une fonction G réciproque de la fonction F telle que la composition des deux fonctions (notée G°F) permet de récupérer la donnée du porteur, ici son numéro MSISDN c'est-à-dire que l'on peut écrire MSISDN =GoF (MSISDN)

Ceci permet à l'agrégateur de service, en cas de doute ou de problème dans le déroulement de la procédure, de vérifier que le numéro de téléphone qu'il a transmis à la banque (le MSISDN) est correct, c'est-à-dire qu'il s'agit bien de celui du porteur. On notera que les deux fonctions réciproques doivent utiliser de plus le même aléa de la même manière (en tant que paramètre de chacune des fonctions) pour un fonctionnement correct.

On notera aussi que la fonction G doit être une fonction secrète et impossible à déduire de F. Il doit être impossible de calculer cette fonction G pour quiconque n'a pas participé à la définition de F, même si F est connue, c'est-à-dire que la complexité nécessaire à l'identification d'une fonction G telle que G°F soit la fonction identité doit être suffisamment élevée (selon les connaissances de l'homme du métier) pour éviter toute possibilité de pouvoir la déterminer pratiquement.

Par exemple, de telles fonctions F et G peuvent s'appuyer sur des fonctions cryptographiques de type asymétrique, bien connues de l'homme du métier, pour s'assurer que F peut être une fonction publique tout en assurant que G reste secrète.

Optionnellement, la donnée de vérification résultant de la génération à l'aide de la fonction F et/ou les aléas sont chiffrés par une clé de sécurité connue seulement du serveur A et du serveur B.

Le serveur de validation (B) de la banque reçoit la donnée de vérification lors d'une étape E32.

Lors d'une étape E33, le serveur B recherche de son côté une information similaire relative au porteur (le numéro de téléphone selon cet exemple) éventuellement formatée selon des modalités agréées préalablement par les entités A et B (par exemple, numéro de téléphone en version internationale et non nationale). On notera que, conformément à ce mode de réalisation, le porteur est connu de la banque B puisqu'il y possède un compte et une carte de paiement. De surcroît, toujours selon cet exemple, la banque B a un fort intérêt commercial à posséder le numéro de téléphone correct du porteur pour le bon déroulement de certaines opérations d'autorisation de paiement. Il est donc très probable que la banque B connaît le numéro de téléphone correct du porteur (c'est-à-dire que (MSISDN' = MSISDN)).

Si c'est le cas, la banque, recevant la requête, peut utiliser l'aléa reçu à l'étape E31 et la donnée du porteur obtenue à l'étape E33, et exécuter la même fonction injective F que le serveur A sur l'ensemble des deux valeurs pour obtenir une seconde donnée de vérification. On rappelle que la fonction F a été obtenue par la banque lors d'une étape préalable, par exemple E31.

Lors d'une étape E34, cette seconde donnée de vérification est comparée à celle reçue lors de l'étape E32. Si la comparaison est positive (le résultat correspond bien à celui envoyé par A), alors la banque B peut avoir la garantie que les deux données relatives respectivement à l'utilisateur et au porteur (MSISDN et MSISDN') sont identiques, et donc que l'utilisateur est bien le propriétaire de la carte CC et du compte bancaire associé. L'identification du porteur est validée. Le « green path », ou validation automatique, vient d'être réalisé de manière fiable et vérifiable.

Le serveur de validation B génère alors au cours d'une étape E35 (ou fait générer par un serveur B' responsable du schéma bancaire »), selon un procédé connu sortant du cadre de l'invention, les données de virtualisation (T) correspondant au jeton de la carte dématérialisée ; le jeton (T) est transmis au serveur de virtualisation.

Selon un autre mécanisme possible, le jeton est généré et mémorisé quelle que soit l'issue de la comparaison, mais ne sera activé que lorsque la vérification est réussie, c'est-à-dire à l'issue de l'étape E35.

Ces données sont reçues par le serveur de virtualisation au cours d'une étape E25, puis transmises et mémorisées dans le terminal mobile de l'utilisateur (par exemple dans un élément de sécurité qui lui est associé), au cours d'une étape Eli.

Si au contraire, à l'issue de l'étape E34, la comparaison des deux données de vérification est négative, ou si la banque n'est pas capable, lors de l'étape E33, de récupérer la donnée relative au porteur (parce qu'elle ne connaît pas son numéro de téléphone par exemple), l'identification du porteur n'est pas validée. La banque pourra appliquer de manière classique la méthode dite du « yellow path » conformément à l'état de l'art, c'est-à-dire qu'elle pourra demander à l'utilisateur du téléphone mobile de fournir une donnée complémentaire de vérification d'identité.

On comprend aisément que la connaissance commune d'une donnée relative à l'utilisateur et au porteur (le numéro de téléphone dans cet exemple, qui est forcément connu de l'opérateur mobile et très probablement connu de la banque) et d'une fonction à lui appliquer (dans cet exemple, la fonction F associée à l'aléa) permet de simplifier considérablement le processus de vérification d'identité, en ce qu'il ne demande aucune intervention de la part de l'utilisateur, tout en offrant une sécurité élevée et en assurant la confidentialité des données personnelles associées au client (MSISDN, etc.)

Il va de soi que le mode de réalisation qui a été décrit ci-dessus a été donné à titre purement indicatif et nullement limitatif, et que de nombreuses modifications peuvent être facilement apportées par l'homme de l'art sans pour autant sortir du cadre de l'invention.

Notamment, comme il a été décrit précédemment, les données échangées entre le serveur A et le serveur B peuvent être chiffrées.

Selon une variante, d'autres éléments que le numéro de téléphone, ou MSISDN, du porteur, peuvent être utilisés.

Par ailleurs d'autres éléments peuvent être utilisés de manière complémentaire, en utilisant des mécanismes équivalents de protection des données personnelles et de sécurité : - éléments liés au mobile de l'utilisateur (nom de mobile, type de mobile, type d'OS, version d'OS, « user Agent » du mobile, IMEI, etc.) ; - éléments liés à la géolocalisation de l'utilisateur ; - informations privées connues par A et B (adresse de facturation, âge, date de naissance, etc.).

Selon une autre variante, le procédé s'applique à d'autres cartes électroniques qu'une carte de paiement : - carte de fidélité ; - carte de transport (aérien, métro, train, bus...).

Claims (12)

1. Revendications

   1. Procédé de gestion de la vérification de l'identité d'un utilisateur d'un objet (CC) à virtualiser dans une mémoire liée à un terminal (M) de l'utilisateur, l'objet comportant au moins une donnée, dite donnée d'identification, en rapport avec l'identité de son porteur, ledit terminal étant apte à communiquer avec un serveur de virtualisation (A) d'un agrégateur du service de virtualisation, ledit serveur de virtualisation (A) étant apte à communiquer avec un serveur de vérification (B) ayant le contrôle de l'objet (CC), ledit procédé comportant les étapes de : - obtention (E20), par le serveur de virtualisation (A), de la donnée d'identification (CC_NUM) de l'objet fournie (E10) par l'utilisateur ; - transmission (E21), par le serveur de virtualisation (A), au serveur de validation (B), de la donnée d'identification (CC_NUM) ; caractérisé en ce qu'il comporte en outre les étapes de : - obtention (E23), par le serveur de virtualisation (A), d'une première donnée relative à l'utilisateur (MSISDN) ; - génération (E23) par le serveur de virtualisation (A) d'une première donnée de vérification (F(MSISDN)) fonction de la première donnée relative à l'utilisateur (MSISDN) ; - transmission (E24) par le serveur de virtualisation (A) au serveur de validation (B) de la première donnée de vérification ; - obtention (E33), par le serveur de validation (B), d'une seconde donnée relative au porteur (MSISDN') ; - génération (E33), par le serveur de validation (B), d'une seconde donnée de vérification fonction de la seconde donnée obtenue relative au porteur (MSISDN7), ladite fonction étant identique à celle utilisée lors de l'étape de génération de la première donnée de vérification ; - comparaison (E34) de la première (F(MSISDN)) et de la seconde (F(MSISDN')) donnée de vérification ; - en fonction du résultat de la comparaison, validation (E35) de l'identité de l'utilisateur.
2. 2. Procédé de gestion selon la revendication 1, caractérisée en ce que l'objet est une carte électronique (CC) et en ce que le procédé comporte en outre, les étapes de : - génération (E35) d'un jeton (T) représentatif de la carte électronique (CC) de l'utilisateur ; - livraison du jeton au terminal mobile par le serveur de virtualisation (A) ; - stockage (Eli) du jeton (T) dans la mémoire liée au terminal mobile (M) de l'utilisateur. - après la validation de l'identité du porteur (E35), activation du jeton.
3. 3. Procédé de gestion selon la revendication 1, caractérisé en ce que l'agrégateur de service est l'opérateur mobile du terminal mobile et en en ce que la seconde donnée relative au porteur et la première donnée relative à l'utilisateur sont le numéro d'appel (MSISDN, MSISDN') du terminal mobile.
4. 4. Procédé de gestion selon la revendication 1, caractérisé en ce qu'il comporte en outre les étapes de : - génération (E22) d'un aléa (ALEA) par le serveur de virtualisation (A) ; - transmission (E22) de l'aléa (ALEA) par le serveur de virtualisation (A) au serveur de validation (B) ; et en ce que les générations (E33) d'une première et d'une seconde donnée de vérification sont fonction de l'aléa.
5. 5. Procédé de gestion selon la revendication 1, caractérisé en ce qu'il comporte en outre une étape de transmission (E22) de la fonction (F) pour la génération d'une donnée de vérification (F(MSISDN+ALEA)) par le serveur de virtualisation (A) au serveur de validation (B).
6. 6. Procédé de gestion selon la revendication 1, caractérisé en ce que la fonction de génération (F) est injective et possède une fonction réciproque (G) secrète.
7. 7. Procédé de génération d'un élément d'identification d'un objet (CC) à virtualiser dans une mémoire liée à un terminal (M) de l'utilisateur, l'objet comportant au moins une donnée, dite donnée d'identification, en rapport avec l'identité de son porteur, le dit terminal étant apte à communiquer avec un serveur de virtualisation (A) d'un agrégateur du service de virtualisation, ledit serveur de virtualisation (A) étant apte à communiquer avec un serveur de vérification (B) ayant le contrôle de l'objet (CC), ledit procédé comportant sur le serveur de virtualisation les étapes de : - obtention (E20) de la donnée d'identification (CC_NUM) de l'objet fournie par l'utilisateur ; - transmission (E21), au serveur de validation (B), de la donnée d'identification (CC_NUM) ; caractérisé en ce qu'il comporte en outre les étapes de : - obtention (E23) d'une première donnée relative à l'utilisateur (MSISDN) ; - génération (E23) d'une première donnée de vérification (F(MSISDN)) fonction de la première donnée relative à l'utilisateur (MSISDN) ; - transmission (E24) au serveur de validation (B) de la première donnée de vérification.
8. 8. Procédé de vérification de l'identité d'un utilisateur d'un objet (CC) comportant au moins une donnée, dite donnée d'identification, en rapport avec l'identité de son porteur, sur un serveur de vérification (B) ayant le contrôle de l'objet (CC), ledit procédé étant caractérisé en ce qu'il comporte les étapes de : - réception (E32) d'une première donnée de vérification ; - obtention (E33) d'une seconde donnée relative au porteur (MSISDN7) ; - génération (E33) d'une seconde donnée de vérification fonction de la donnée obtenue relative au porteur (F(MSISDN')) ; - comparaison (E34) de la première (F(MSISDN)) et de la seconde (F(MSISDN')) donnée de vérification ; - en fonction du résultat de la comparaison, validation (E35) de l'identité du porteur.
9. 9. Système de vérification de l'identité d'un utilisateur d'un objet (CC) à virtualiser comportant au moins une donnée, dite donnée d'identification, en rapport avec l'identité de son porteur, le système comportant : - un terminal mobile (M) d'un l'utilisateur comportant : o un module pour fournir la donnée d'identification ; o un module pour stocker les données de virtualisation ; o un module de communication pour communiquer avec un serveur de virtualisation, - un serveur de virtualisation (A) d'un agrégateur du service de virtualisation, comportant : o un module de communication pour communiquer avec un serveur de vérification ; o un module d'obtention (E20 de la donnée d'identification (CC_NUM) de l'objet fournie par l'utilisateur ; o un module de transmission (E21) de la donnée d'identification (CC_NUM) ; o un module d'obtention (E23) d'une première donnée relative à l'utilisateur (MSISDN) ; o un module de génération (E23) d'une première donnée de vérification (F(MSISDN)) fonction de la première donnée relative à l'utilisateur (MSISDN) ; o un module de transmission (E24) de la première donnée de vérification ; - un serveur de vérification (B) ayant le contrôle de l'objet comportant o un module d'obtention (E33) d'une seconde donnée relative au porteur (MS^ON7) ; o un module de génération (E33) d'une seconde donnée de vérification fonction de la donnée obtenue relative au porteur (F(MSISDN')) ; o un module de comparaison (E34) d'une première (F(MSISDN)) et d'une seconde (FCMSISDN7)) donnée de vérification ; o un module de validation (E35), en fonction du résultat de la comparaison, de l'identité du porteur.
10. 10. Programme d'ordinateur comportant des instructions de code pour la mise en œuvre du procédé de gestion conforme à la revendication 1, lorsque celle-ci est exécutée par un processeur.
11. 11. Programme d'ordinateur comportant des instructions de code pour la mise en œuvre du procédé de génération d'un élément d'identification conforme à la revendication 7, lorsque celle-ci est exécutée par un processeur.
12. 12. Programme d'ordinateur comportant des instructions de code pour la mise en œuvre du procédé de vérification conforme à la revendication 8, lorsque celle-ci est exécutée par un processeur.