EP3371760A1 - Procédé de verification d'identité lors d'une virtualisation - Google Patents

Procédé de verification d'identité lors d'une virtualisation

Info

Publication number
EP3371760A1
EP3371760A1 EP16809910.9A EP16809910A EP3371760A1 EP 3371760 A1 EP3371760 A1 EP 3371760A1 EP 16809910 A EP16809910 A EP 16809910A EP 3371760 A1 EP3371760 A1 EP 3371760A1
Authority
EP
European Patent Office
Prior art keywords
server
data
msisdn
user
verification
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
EP16809910.9A
Other languages
German (de)
English (en)
Inventor
Antoine DUMANOIS
Arnaud BELLEE
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.)
Orange SA
Original Assignee
Orange 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 Orange SA filed Critical Orange SA
Publication of EP3371760A1 publication Critical patent/EP3371760A1/fr
Ceased legal-status Critical Current

Links

Classifications

    • 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/08—Network architectures or network communication protocols for network security for authentication of entities
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/16—Payments settled via telecommunication systems
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3827—Use of message hashing
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/385—Payment protocols; Details thereof using an alias or single-use codes
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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

Definitions

  • the invention relates to the field of virtualization, or dematerialization (in English "tokenization") of objects related to the identity of a user.
  • the invention relates to the verification of identities performed during the virtualization of such objects.
  • the invention relates to the security and protection of customers' personal data of bank card virtualization methods.
  • the virtualization method used by these payment systems is as follows: the customer, or cardholder, enters the banking information recorded on his card in an application of the terminal controlled by an aggregator, or provider, of the payment service. For example, according to a known method, the wearer photographs his credit card and informs the security code which is on the back. Alternatively, it manually enters this information, essential to the identification of the cardholder during a transaction.
  • the bank that is responsible for the bank account associated with the card must validate the virtualization if it believes that the person who entered the information is actually the cardholder, or carrier.
  • the virtualization data corresponding to the card, or token are encrypted at the terminal using encryption keys known only by the bank organization responsible for the card (or by the organization managing the banking scheme in delegation of the banking institution responsible for the card) before being sent to a server of the service aggregator, which sends the data to the bank.
  • the bank receives the data, possibly encrypted, and possibly accompanied by secondary data such as the name of the terminal, its position, etc.
  • the bank has received the encrypted data, it has two well-known methods of verifying the identity of the cardholder (by verifying the identity of the cardholder means a mechanism to ensure that the credit card is that of the person who loads it in the terminal):
  • the invention offers a solution that does not have the drawbacks of the state of the art.
  • the subject of the invention is a method for managing the verification of the identity of a user of an object to be virtualized in a memory linked to a terminal of the user.
  • the object comprising at least one piece of data, called identification data, in relation to the identity of its bearer, said terminal being able to communicate with a server of virtualization of an aggregator of the virtualization service, said virtualization server being able to communicate with a verification server having control of the object, said method comprising the steps of:
  • the method according to the invention makes it possible, on the basis of data relating to the user and the bearer, known respectively to the service provider, or aggregator of contents, and to the entity in charge of the identification, typically a bank, to perform the identification reliably.
  • the knowledge of such data such as the phone number of the carrier, allows the implementation of a simple operation.
  • evaluation of a verification data on each side of each server if the verification data are identical, this means that the data relating to the user and that relating to the carrier respectively known to each of the two entities (the service provider and the bank) are the same, and therefore the user of the card (the one requesting the service) is the holder, or cardholder with the bank.
  • Obtaining means a simple operation allowing the server A (or B) to obtain the known data of the corresponding entity, typically by reading in the database of the entity, and which excludes the direct transmission from one entity to another.
  • object to be virtualized is meant here any type of object that can be virtualized, whether physical (electronic card type banking for example) or virtual (virtual payment token, etc.).
  • terminal is meant that the memory is in the mobile terminal or in an external memory, the latter may be a security element SIM card type, a secure memory area type" Trusted Execution Environment ", etc..
  • user is meant here the person providing the identification data. If this user is the cardholder, the identification should be successful. Otherwise, the check should fail.
  • virtualization service aggregator an entity that is capable of providing a virtualization-type client service for one of its objects (eg a payment card).
  • verification server (B) having control of the object is meant a server of the entity that has provided the object to the bearer and which has information on the identity of said carrier (for example, a server a banking institution, transport, etc.)
  • a method as described above is characterized in that the object to be virtualized is an electronic card and in that the method further comprises the steps of:
  • electronic card here we mean any type of physical card that can be virtualized (dematerialized): bank card (payment, credit, debit, etc.) but also transport card, loyalty, etc.
  • the actual virtualization that is to say the activation of the "token”
  • a method as described above is further characterized in that the aggregator, or service provider , is the mobile operator of the mobile terminal and in that the second data relating to the carrier and the first data relating to the user are the mobile terminal call number.
  • the telephone number is necessarily known to the mobile operator who controls the mobile terminal of the user; as this number is moreover very probably known by the entity that issued (the bearer's bank) the object to be virtualized, this knowledge common to both entities makes it possible to considerably simplify the identification process while maintaining a high level of security.
  • the personal data here, the phone number
  • a method as described above is further characterized in that it comprises the steps of:
  • a hazard is used in addition to the data relating to the carrier and / or user to generate the data of verification.
  • the hazard becomes a parameter of the generation function F.
  • a method as described above is further characterized in that it comprises a step of transmitting the function for generating verification data by the virtualization server to the validation server.
  • the generation function can be easily modified since its transmission implies that it is known to the two entities that control the two servers (for example, the mobile operator and the bearer's bank).
  • a method as described above is further characterized in that the generation function is injective and has a secret reciprocal function.
  • the invention also relates to a method of generating an identification element of an object to be virtualized in a memory linked to a terminal of the user, the object comprising at least one piece of data, known as identification data, in relation to the identity of its bearer, said terminal being able to communicate with a virtualization server of an aggregator of the virtualization service, said virtualization server being able to communicate with a verification server having control of the object, said method comprising on the virtualization server the steps of:
  • the invention also relates to a method of verifying the identity of a user of an object comprising at least one piece of data, called identification data, in relation to the identity of its bearer, on a verification server having control of the object, said method being characterized in that it comprises the steps of:
  • the invention also relates to a system for verifying the identity of a user of an object to be virtualized comprising at least one piece of data, called identification data, related to the identity of its bearer. , the system comprising:
  • a mobile terminal of a user comprising:
  • a module for storing virtualization data a communication module for communicating with a virtualization server,
  • a virtualization server of an aggregator of the virtualization service comprising:
  • a communication module for communicating with a verification server
  • a module for transmitting the identification data a module for obtaining a first data item relating to the user;
  • a verification server having control of the object comprising
  • a module for obtaining a second data relating to the carrier a module for generating a second verification datum based on the data obtained relative to the carrier; a comparison module of a first and a second verification data item;
  • module can correspond to a software component as well as a hardware component or a set of hardware and software components, a software component itself corresponding to one or more computer programs or subprograms, mobile (application in a mobile phone) or more generally to any element of a program capable of implementing a function or a set of functions as described for the modules concerned.
  • a hardware component corresponds to any element of a hardware set (or hardware) able to implement a function or a set of functions for the module concerned (integrated circuit, smart card, memory card, etc. .).
  • the invention also relates to a computer program adapted to be implemented in a management method for verifying the identity of a user as defined above, the program comprising code instructions. which, when the program is executed by a processor, performs the steps.
  • the invention also relates to a computer program capable of being implemented in a method of generating an identification element as defined above, the program comprising code instructions which, when the program is executed by a processor, performs the steps.
  • the invention also relates to a computer program capable of being implemented in a method of verifying the identity of a user as defined above, the program comprising code instructions which, when the program is executed by a processor, performs the steps.
  • the invention relates to a recording medium readable by a data processor on which is recorded a program comprising program code instructions for the execution of the steps of one of the defined methods. above.
  • FIG. 1 represents a system (S) illustrating an embodiment of an identity verification method during the virtualization of a bank card according to the invention.
  • FIG. 1 represents a system (S) illustrating an embodiment of an identity verification method during the virtualization of a bank card according to the invention.
  • the user C asks his cloud service provider, also called here service aggregator, the virtualization, or dematerialization, in his mobile terminal (M), of a bank card (CC ) associated with his bank account in a bank (B).
  • the token (token, T) resulting from the virtualization will be stored at the end of the transaction in a security element of the mobile terminal and optionally activated at the level of the infrastructure of the entity. B if the verification of the user has succeeded, that is to say if he is the card holder.
  • the token could alternatively be stored in the internal memory of the mobile terminal or any other external memory accessible by it.
  • the bank is represented here through a validation server (B). This representation is naturally very schematic.
  • the bank's validation server is generally linked to another server, responsible for carrying out what is called the "banking scheme" by the person skilled in the art, and which mediates between the virtualization server and the validation server. strictly speaking.
  • the validation servers and "banking diagram" are combined into a single server B associated with the bank.
  • the invention is based on the principle of a common knowledge, between the two entities (aggregator and bank) of a relative data on the one hand to the user, on the other hand to the bearer.
  • the steps of a method according to this embodiment are detailed below.
  • the user enters, during a step E10, the data of his bank card (DC) to dematerialize, via a graphical interface of a mobile application running in this example on his mobile terminal (M) under the control of the service aggregator. During this stage it is not yet known if the user is really the card holder.
  • DC bank card
  • M mobile terminal
  • the server A called the virtualization server, of the service aggregator, is responsible in this example for transmitting to a validation server (B) of the bank responsible for the card (CC) the virtualization request ⁇ Token requesf) for identification of the holder of the bank card.
  • the server A knows a data specific to the user.
  • the server A is the server of a mobile operator of the user and the data is the telephone number, or MSISDN, of his mobile terminal.
  • server A could depend on another type of entity (tax center, social security center, etc.), as well as server B.
  • the server A of the service aggregator transmits the request to the server B of the bearer's bank for identification of the bearer and validation of the virtualization.
  • the validation server of the bank B generally uses other entities, including at least one other server known as "banking scheme" by the skilled person, responsible in particular for the generation of tokens (T).
  • banking scheme a server known as "banking scheme” by the skilled person, responsible in particular for the generation of tokens (T).
  • T tokens
  • the validation server (B) of the bank receiving the request during a step E30, will have to make sure that the client of the server A, user of the mobile phone M, is the same individual as the one with the account bank card associated with the bank card and not another person who stolen it.
  • bank B has its own authentication and validation mechanisms. According to the state of the art, it identifies the carrier by a method known as "green path" (automatic validation of the cardholder, after receiving and analyzing data) or "yellow path” (validation with verification secondary, during which the holder provides other proof of identity).
  • the first method is without proof of the actual identity of the cardholder, since it does not include any active security mechanism beyond the simple data bank analysis received during the virtualization request.
  • the second is not absolutely reliable, increases the complexity of the banking system and slows the processing time of customer requests, which can be very penalizing especially if several requests must be processed simultaneously.
  • the request from the server A is enriched by information that can be controlled by the bank, thus avoiding it to apply a complex method of the "yellow path" type while guaranteeing the authentication of the carrier C of the CC card at the origin of the request.
  • the server A generates a random corresponding to the transaction.
  • a random is classically a randomly generated number. The fact of having a different random number with each transaction makes it possible to guarantee the respect of the legal obligations of management of the personal data of A (the MSISDN according to this example) while making sure, the data of verification generated being different with each setting. process, that third parties through which the communication passes will not be able to perform correlations that would reconstruct the profile of the wearer.
  • the exchanges between A and B are carried out in an encrypted session, according to a mechanism well known to those skilled in the art (for example on a TLS communication base with mutual authentication using certificates), which guarantees the following properties:
  • the server A also transmits to the operator B a function, called the verification function (F, HASH), to also apply to the random number.
  • this function may have been previously provided to the bank.
  • This data (random, function F) is received by the bank server during a step E31.
  • the server A retrieves a data relating to the user without his intervention.
  • the server A is the server of a mobile operator of the user and the data is the telephone number, or MSISDN, which he knows (without having to ask the user or a third party).
  • the server A During a step E24, the server A generates a verification data to be transmitted to the bank, taking into account this data of the user and the hazard, by using the generation function F, this verification data being noted.
  • Figure F MSISDN + ALEA
  • the generation consists in "chopping" the concatenated randomness with the telephone number.
  • a “hash” function is well known to those skilled in the art.
  • the function F is an injective function, that is to say that any result obtained by this function admits at most an antecedent.
  • the server A has a reciprocal function G of the function F such that the composition of the two functions (denoted by G ° F) makes it possible to recover the data of the bearer, here his MSISDN number that is say that we can write
  • the service aggregator in case of doubt or problem in the course of the procedure, to verify that the phone number he has transmitted to the bank (the MSISDN) is correct, that is to say that is, that of the wearer.
  • the two reciprocal functions must also use the same hazard in the same way (as a parameter of each of the functions) for proper operation.
  • the function G must be a secret function and impossible to deduce from F. It must be impossible to calculate this function G for anyone who has not participated in the definition of F, even if F is known, it is that is, the complexity necessary to identify a function G such that G ° F is the identity function must be sufficiently high (according to the knowledge of those skilled in the art) to avoid any possibility of being able to determine it practically.
  • such functions F and G may rely on asymmetric cryptographic functions, well known to those skilled in the art, to ensure that F can be a public function while ensuring that G remains secret.
  • the verification data resulting from the generation using the function F and / or the hazards are encrypted by a security key known only to the server A and the server B.
  • the validation server (B) of the bank receives the verification data during a step E32.
  • the server B looks for similar information relating to the bearer (the telephone number according to this example) possibly formatted according to previously agreed terms by the entities A and B (for example, telephone number international and non-national version).
  • the bearer is known to bank B since it has an account and a payment card.
  • the bank receiving the request, can use the random received in step E31 and the carrier data obtained in step E33, and execute the same injective function F as the server A on the E31. set of two values to obtain a second verification data. It will be recalled that the function F was obtained by the bank during a preliminary step, for example E31.
  • this second verification datum is compared with that received during step E32. If the comparison is positive (the result corresponds to that sent by A), then the bank B can be guaranteed that the two data relating respectively to the user and to the bearer (MSISDN and MSISDN ') are identical, and therefore that the user is the owner of the CC card and the associated bank account.
  • the carrier identification is validated. The "green path", or automatic validation, has been made in a reliable and verifiable way.
  • the validation server B then generates during a step E35 (or has generated by a server B 'responsible for the banking scheme'), according to a known method outside the scope of the invention, the corresponding virtualization data (T).
  • the token of the dematerialized card; the token (T) is transmitted to the virtualization server.
  • the token is generated and stored regardless of the outcome of the comparison, but will be activated only when the verification is successful, that is to say at the end of step E35.
  • This data is received by the virtualization server during a step E25, then transmitted and stored in the mobile terminal of the user (for example in a security element associated with it), during a step Eli. .
  • step E34 If, on the other hand, at the end of step E34, the comparison of the two verification data is negative, or if the bank is not able, during step E33, to retrieve the data relating to the bearer (because she does not know her phone number for example), the carrier identification is not validated.
  • the bank can conventionally apply the so-called "yellow path" method according to the state of the art, that is to say that it can ask the user of the mobile phone to provide additional data of identity verification.
  • the data exchanged between the server A and the server B can be encrypted.
  • MSISDN from the carrier, can be used.
  • a and B private information known by A and B (billing address, age, date of birth, etc.).
  • the method applies to other electronic cards than a payment card:

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)

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). Le procédé comporte les étapes de : - obtention (E20), par le serveur de virtualisation (A), de la donnée d'identification (CC_NUM) de l'objet fournie 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 (MSISDN'), 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.

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. II 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 œuvre 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 requesf) 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

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.
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.
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, MSISON7) du terminal mobile.
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.
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. 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. 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. 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 (MSISDN') ;
- 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.
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 (MSISDN') ; 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 (F(MSISDN')) 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. 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. 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. 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.
EP16809910.9A 2015-11-03 2016-10-20 Procédé de verification d'identité lors d'une virtualisation Ceased EP3371760A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1560536A FR3043232A1 (fr) 2015-11-03 2015-11-03 Procede de verification d'identite lors d'une virtualisation
PCT/FR2016/052712 WO2017077210A1 (fr) 2015-11-03 2016-10-20 Procédé de verification d'identité lors d'une virtualisation

Publications (1)

Publication Number Publication Date
EP3371760A1 true EP3371760A1 (fr) 2018-09-12

Family

ID=55361637

Family Applications (1)

Application Number Title Priority Date Filing Date
EP16809910.9A Ceased EP3371760A1 (fr) 2015-11-03 2016-10-20 Procédé de verification d'identité lors d'une virtualisation

Country Status (4)

Country Link
US (1) US10812459B2 (fr)
EP (1) EP3371760A1 (fr)
FR (1) FR3043232A1 (fr)
WO (1) WO2017077210A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US12149516B2 (en) * 2020-06-02 2024-11-19 Flex Integration, LLC System and methods for tokenized hierarchical secured asset distribution

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150006529A1 (en) * 2013-06-28 2015-01-01 Ben Kneen Multi-identifier user profiling system

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003003321A2 (fr) * 2001-06-26 2003-01-09 Enterprises Solutions, Inc. Systeme de verification de transaction et procede correspondant
FR2867585A1 (fr) * 2004-03-15 2005-09-16 France Telecom Dispositif de transaction a efficacite amelioree
US7430607B2 (en) * 2005-05-25 2008-09-30 Microsoft Corporation Source throttling using CPU stamping
US20080155019A1 (en) * 2006-12-20 2008-06-26 Andrew Wallace System, apparatus and method to facilitate interactions between real world and proprietary environments
JP5133659B2 (ja) * 2007-11-19 2013-01-30 株式会社エヌ・ティ・ティ・ドコモ 仮想端末サーバ、移動通信端末、通信制御システム、及び通信制御方法
FR2960675B1 (fr) * 2010-05-27 2015-05-22 Christian Rene Marie Soulez Procede et systeme de teletransmission securisee
US20150310680A1 (en) * 2010-06-01 2015-10-29 Peter Lablans Method and Apparatus for Wirelessly Activating a Remote Mechanism
US20150032625A1 (en) * 2013-07-24 2015-01-29 Matthew Dill Systems and methods for communicating risk using token assurance data
US9794341B2 (en) * 2014-06-30 2017-10-17 Sandisk Technologies Llc Data storage verification in distributed storage system

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150006529A1 (en) * 2013-06-28 2015-01-01 Ben Kneen Multi-identifier user profiling system

Also Published As

Publication number Publication date
WO2017077210A1 (fr) 2017-05-11
US20180324163A1 (en) 2018-11-08
FR3043232A1 (fr) 2017-05-05
US10812459B2 (en) 2020-10-20

Similar Documents

Publication Publication Date Title
EP2441207B1 (fr) Procédé cryptographique d'authentification anonyme et d'identification séparée d'un utilisateur
FR3031613A1 (fr) Procede de traitement d'une transaction a partir d'un terminal de communication.
FR3162089A1 (fr) Partage sécurisé d'informations de justificatif d'identité
WO2017182747A1 (fr) Procédé d'obtention par un terminal mobile d'un jeton de sécurité
EP3857413B1 (fr) Procede de traitement d'une transaction, dispositif, systeme et programme correspondant
WO2013021107A1 (fr) Procede, serveur et systeme d'authentification d'une personne
EP2950256B1 (fr) Méthode d'identification, dispositif et programme correspondant
FR2975855A1 (fr) Systeme et procede de securisation d'echanges de donnees entre un module client et un module serveur
EP2824625A1 (fr) Méthode de réalisation de transaction, terminal et programme d'ordinateur correspondant
WO2007012584A1 (fr) Procédé de contrôle de transactions sécurisées mettant en oeuvre un dispositif physique unique à bi-clés multiples, dispositif physique, système et programme d'ordinateur correspondants
EP3163487B1 (fr) Procédé de sécurisation de traitement de données transactionnelles, terminal et programme d'ordinateur correspondant
WO2007012583A1 (fr) Procede de controle de transactions securisees mettant en oeuvre un dispositif physique unique, dispositif physique, systeme, et programme d'ordinateur correspondants
EP3588418A1 (fr) Procédé de réalisation d'une transaction, terminal, serveur et programme d ordinateur correspondant
WO2016207715A1 (fr) Gestion securisee de jetons électroniques dans un telephone mobile.
FR3054055B1 (fr) Procede de traitement d'au moins une donnee de moyen de paiement, terminal de paiement et programme d'ordinateur correspondant
EP2954449B1 (fr) Authentification de signature manuscrite numérisée
EP3371760A1 (fr) Procédé de verification d'identité lors d'une virtualisation
FR3053548B1 (fr) Procede d'authentification de donnees de paiement, dispositifs et programmes correspondants.
WO2022254002A1 (fr) Procédé de traitement d'une transaction, dispositif et programme correspondant.
WO2017005644A1 (fr) Procédé et système de contrôle d'accès à un service via un média mobile sans intermediaire de confiance
FR3031609A1 (fr) Procede de traitement d'une transaction a partir d'un terminal de communication
CA2946145A1 (fr) Procedes de traitement de donnees transactionnelles, dispositifs et programmes correspondants
FR3081246A1 (fr) Procede de realisation d'une transaction, terminal, serveur et programme d'ordinateur correspondant
FR3031217A1 (fr) Procede de verification d'une requete de paiement comprenant la determination de la localisation du provisionnement d'un jeton de paiement
FR3008516A1 (fr) Methode de realisation de transaction, terminal et programme d'ordinateur correspondant.

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

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

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

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

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

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20180202

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

DAV Request for validation of the european patent (deleted)
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: 20190812

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

Owner name: ORANGE

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

Owner name: ORANGE

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: 20211219