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; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/38—Payment protocols; Details thereof
  • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
  • G06Q20/401—Transaction verification
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/08—Payment architectures
  • G06Q20/16—Payments settled via telecommunication systems
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
  • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/38—Payment protocols; Details thereof
  • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
  • G06Q20/3827—Use of message hashing
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/38—Payment protocols; Details thereof
  • G06Q20/385—Payment protocols; Details thereof using an alias or single-use codes
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/38—Payment protocols; Details thereof
  • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
  • G06Q20/401—Transaction verification
  • G06Q20/4014—Identity check for transactions

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)

Applications Claiming Priority (2)

Publications (1)

Family

ID=55361637

Family Applications (1)

Country Status (4)

Families Citing this family (1)

Family Cites Families (9)

• 2015
  • 2015-11-03 FR FR1560536A patent/FR3043232A1/fr active Pending
• 2016
  • 2016-10-20 WO PCT/FR2016/052712 patent/WO2017077210A1/fr active Application Filing
  • 2016-10-20 US US15/773,396 patent/US10812459B2/en active Active
  • 2016-10-20 EP EP16809910.9A patent/EP3371760A1/de not_active Ceased

Also Published As

Similar Documents

Legal Events