WO2006013258A1 - Procede d'authentification a distance d’un utilisateur - Google Patents

Procede d'authentification a distance d’un utilisateur Download PDF

Info

Publication number
WO2006013258A1
WO2006013258A1 PCT/FR2005/001684 FR2005001684W WO2006013258A1 WO 2006013258 A1 WO2006013258 A1 WO 2006013258A1 FR 2005001684 W FR2005001684 W FR 2005001684W WO 2006013258 A1 WO2006013258 A1 WO 2006013258A1
Authority
WO
WIPO (PCT)
Prior art keywords
user
provider
code
authentication
characters
Prior art date
Application number
PCT/FR2005/001684
Other languages
English (en)
Inventor
Anne Lise Buscaylet
François Moreau
Jean Bouffard
Original Assignee
Hsbc France
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 Hsbc France filed Critical Hsbc France
Priority to US11/630,794 priority Critical patent/US20070255944A1/en
Publication of WO2006013258A1 publication Critical patent/WO2006013258A1/fr
Priority to GB0700698A priority patent/GB2431268A/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/409—Device specific authentication in transaction processing
    • G06Q20/4097—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners
    • G06Q20/40975—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners using encryption therefor
    • 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/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • 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
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1016—Devices or methods for securing the PIN and other transaction-data, e.g. by encryption
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/12—Card verification

Definitions

  • the invention relates to a remote authentication method of a user by a provider.
  • Banks offer their customers to perform services remotely, via the Internet or telephone for example, without requiring customers to travel to meet a bank agent.
  • a customer To remotely access the services of the bank, a customer must first disclose his identity, for example by communicating an identifier of 11 characters, then provide a password normally known only to him and his bank.
  • the password is a sequence of five characters that the user knows by heart. The password is transmitted in its entirety to the bank.
  • the bank then checks in its databases if the password corresponds to the identifier provided. If this is not the case, an identity theft attempt is very likely and the service request is denied. If the password corresponds to the identifier provided, the bank authorizes the customer to access the desired service, for example to consult his accounts.
  • this goal is achieved by means of a method of remote authentication of a user by a provider comprising the following steps: a) transmission, from said user to said provider, of an identifier, b) determination, by said provider, a processing rule applicable to a code consisting of characters and available to said user and said provider, c) transmitting, from said provider to said user, said processing rule, d) processing said code by said user to means of said processing rule so as to obtain a first authentication data, e) transmission, from said user to said provider, of said first authentication data, and, independently of the steps b) to e), f) recovery, by said provider, said code, preferably from said identifier, g) processing said code by said provider by means of said processing rule so as to obtain a second authentication datum, and, after receiving said first authentication datum and determining said second authentication datum, h) comparing said
  • the code available to the user and the provider is therefore not transmitted. Only the result of a processing of this code, according to a treatment rule determined by the supplier, is transmitted to the supplier. Even by recovering this result, a third party can not determine the code.
  • the authentication procedure according to the invention thus ensures a very high security.
  • a very reliable authentication is therefore possible remotely.
  • To implement the method according to the invention only a code must be distributed to the user.
  • the method according to the invention is therefore advantageously very simple and inexpensive.
  • the said code is unique to the user.
  • the said code is in the form of a series of characters, preferably a series of figures, preferably printed on a card of the credit card type.
  • Said series of characters comprises at least 10 characters, preferably at least 15 characters, more preferably 16 characters.
  • Said treatment rule is modified at each implementation of the method according to the invention.
  • the treatment rule is determined randomly.
  • Said processing rule specifies how to select at least one of said characters constituting said code.
  • Said processing rule identifies said at least one character to be selected by providing a position of said at least one character in said code.
  • Said processing rule identifies a plurality of characters to be selected by providing their positions in said code.
  • Said processing rule indicates the order in which said selected characters are to be ordered to form said first authentication data.
  • said characters identified by their respective positions in. said code shall be extracted from said code and, said positions being provided in an orderly manner, said extracted characters shall be ordered according to the order of said positions.
  • step a) said user further transmits to the provider a password so that after receiving said password, said provider performs a prior authentication of said user by means of said password.
  • steps b) to h) are executed only if successful of said prior authentication.
  • the said supplier is a banking institution or a merchant offering articles or services on the Internet.
  • the communications between said provider and said user are made electronically, for example via the Internet, orally, for example via a telephone network, or by mail.
  • step h) if said first and second authentication data are different, said provider does not recognize said user as acceptable.
  • said provider refuses any further attempt by said user identified by said identifier.
  • FIG. 1 represents a support for an authentication code that can be used for the implementation of a method according to the invention
  • FIG. 2 diagrammatically represents the steps of an authentication method according to the invention.
  • a provider 1 for example a bank
  • a provider 1 proceeds to a first step of identifying the user 2 who issued the request.
  • the user 2 declines his identity, for example by communicating to the provider 1 an identifier Id, typically in the form of a sequence of 11 characters, usually numbers.
  • a confidential password M can also be requested from the user 2 so that the provider 1 can perform a prior authentication.
  • the provider 1 checks whether the password M received is the one provided for confidential to the person identified by the identifier Id. If this is not the case, the request of the user 2 is refused. Otherwise, the provider 1 implements the complementary authentication method according to the invention as follows.
  • a personalized code C Prior to the implementation of the method according to the invention, a personalized code C must have been communicated to the user, for example by unmarked mail.
  • the C code has a length that makes it difficult to memorize.
  • the code C contains at least 10, preferably at least 15, more preferably 16 ordered characters C 1 -C 16 . Since the code C is necessary for each occurrence of the authentication method according to the invention, it is preferably fixed on a support 12, for example on a card such as that represented in FIG. 1.
  • each user 2 has a card 12 carrying a unique code C.
  • This card is personal to him and he must not divulge the code C.
  • the provider 1 has knowledge of the code C and the link between the code C and the user 2.
  • the provider can maintain a database 20 containing all pairs of "code C - identifier Id" of its customers, a unique identifier Id being assigned to each client.
  • the provider 1 determines a processing rule R able to extract information "hidden" in the code C (step b)).
  • the treatment rule changes with each implementation of the method according to the invention, preferably in a random manner.
  • the modifications made to the processing rule are however minor, so as not to disorient the user 2.
  • the provider 1 transmits to the user 2 to authenticate the processing rule R, the user 2 to apply this rule to the code C that he holds so as to constitute a first authentication data A1 (step c)). If the user 2 has the code C, he then processes it according to the processing rule R (step d)) and informs the provider 1 of the result of this processing by means of a first valid authentication data item A1 (step e). )).
  • a "processing rule" R is a set of instructions specifying how, from the code C, to constitute valid authentication data.
  • a "valid authentication datum” is a datum carrying the "hidden” information extracted from the code C by means of the processing rule R.
  • the processing rule R provides the respective positions of a certain number of characters q of the code C, asks the user 2 to identify in the code C the corresponding characters q, then to associate them with said positions.
  • the processing rule R is then limited to an extraction, from the C code, of characters q designated by their positions pi in the code C. Only the person possessing the card 12 can determine the characters q thus designated.
  • the provider 1 may, for example, request that the third, twelfth and seventh characters of the code C be sent to it by sending the user 2 a dialogue box 30. containing three input areas 32, 34 and 36, denoted for example by "position No. 3", “position No. 12" and “position No. 7", respectively.
  • the user 2 locates on the code C of his card 12 the characters C 3 , C 12 and C 7 occupying these positions, namely "4", "0” and "2", respectively (see FIG. 1).
  • the user 2 then enters them in the input areas 32, 34 and 36, respectively, and then validates his entry.
  • the first authentication data A1 is then generated automatically, preferably encrypted and sent to the provider 1.
  • the first authentication data A1 carries the information that the character "4" is the character in third position. , the character "0" is the character in twelfth position, and the character "2" is the character in seventh position.
  • a valid authentication data is therefore an information specifying which characters correspond, in the code C, to the positions designated in the processing rule R sent by the provider 1 to the user 2 to authenticate it.
  • the sending of a dialog box comprising a set of input fields denoted by means of the positions of the characters that the user 2 must enter there is particularly simple.
  • such a dialog box makes it possible to order the positions pi, and therefore the sequence of characters q entered.
  • the processing rule R thus asks the user 2 not only to identify in the code C the characters q corresponding to the transmitted positions pi, but also to order them by entering them in the corresponding input fields. The probability that the user 2 can provide a valid authentication data A1 without knowing the code C is thus further reduced.
  • the first authentication data A1 can be simply provided by specifying orally that the characters at positions 3, 12 and 7 are "4", "0" and "2", respectively.
  • the treatment rule R is preferably modified at each execution of the method according to the invention (step b)).
  • the positions pi used to designate the characters to be extracted from the code C are modified, the number of characters to be extracted from the code C being constant.
  • the user 2 is thus always authenticated in a similar manner.
  • the aptitude of the authentication procedure to be accepted by the user is improved.
  • the number of different processing rules that can be built according to this model is even greater than the number of characters constituting the C code and the number of characters to be extracted are large.
  • the number of characters to be extracted from the code C is always less than 5, more preferably equal to 3.
  • the authentication procedure is thus faster.
  • the information on the pairs "character q - position pi of the character q in the code C" transmitted by the user 2 to the supplier 1 to the means of the first authentication data A1 are different from one implementation of the method to the next.
  • the knowledge of a first valid authentication data A1 resulting from a first implementation of the method according to the invention therefore does not allow to deduce what should be this data during a subsequent implementation of the invention.
  • the code C is normally never communicated in its entirety by the user 2 to the provider 1. Even if a third party would have had access to a first authentication data A1 valid, he could not deduce the code C.
  • Providing in an orderly fashion the characters c, of the code C designated by their respective positions pi in the code C is a particularly simple processing rule R which, advantageously, does not require any particular knowledge on the part of the user 2.
  • treatment rules are also possible.
  • the processing rule could be to extract the characters designated by a particular color, shape, or size, and order them according to their respective positions in the code.
  • the designation could also be achieved by the issuance of "abscissa - ordered" couples to find the characters in a printed chart on the map. More complex rules, for example involving operations between characters designated so as to provide other characters and then to form the first authentication data A1 are also conceivable.
  • the provider 1 After having identified the user 2, preferably by means of the identifier Id, the provider 1 retrieves the code C in the database 20, for example by means of the identifier Id entered by the user 2 (step T )). Then the provider 1 applies the processing rule R to the code C so as to determine a second authentication data A2 (step g)).
  • the determination of the second authentication data A2 is independent of that of the first authentication data A1 and can be done before sending the processing rule R by the provider 1, or during or after the determination and sending of the first authentication data A1 by the user 2.
  • the provider compares the first and second authentication data (step h)). If the first and second authentication data are identical, the first authentication data A1 is valid. The user 2 has therefore correctly provided the designated characters according to the processing rule R and the provider 1 considers that the authentication is successful. It therefore allows user 2 to access the requested service.
  • the provider 1 successively authorizes several authentication attempts according to the method of the invention, for example three attempts. If all the attempts are unsuccessful, the provider 1 considers that the failures are not read or input errors of the user 2, but that the user 2 does not have the code C. Consequently, the provider 1 refuses any subsequent authentication attempt, at less until the situation is cleared, for example by meeting with the user 2.
  • the invention is not limited to the embodiment described above.
  • the number of characters q of the code C, their nature (numbers and / or letters), the number of characters to be entered to authenticate, and the nature of the medium (card or other) may be different from those described.
  • Blocking after a number of unsuccessful attempts is also optional.
  • the preferred area of application is banking, but it is not limited to it. Any transaction requiring enhanced authentication may advantageously implement the method according to the invention.

Abstract

Procédé d'authentification à distance d'un utilisateur (2) par un fournisseur (1) comportant les étapes suivantes : a) transmission, de l'utilisateur (2) au fournisseur (1), d'un identifiant (Id), b) détermination, par le fournisseur (1), d'une règle de traitement (R) d'un code (C), le code (C) étant à disposition de l'utilisateur (2) et du fournisseur (1), c) transmission, du fournisseur (1) à l'utilisateur (2), de la règle de traitement (R) du code (C), d) traitement du code (C) par l'utilisateur (2) au moyen de la règle de traitement (R) de manière à obtenir une première donnée d'authentification (A1), e) transmission, de l'utilisateur (2) au fournisseur (1), de la première donnée d'authentification (A1), et, indépendamment des étapes c) à e) précédentes, f) traitement dudit code (C) par ledit fournisseur (1) au moyen de ladite règle de traitement (R) de manière à obtenir une deuxième donnée d'authentification (A2), g) comparaison desdites première (A1) et deuxième (A2) données d'authentification par ledit fournisseur (1).

Description

PROCÉDÉ D'AUTHENTIFICATION Â DISTANCE D'UN UTILISATEUR
L'invention concerne un procédé d'authentification à distance d'un utilisateur par un fournisseur.
Les banques proposent à leurs clients de réaliser des prestations à distance, via le réseau internet ou le téléphone par exemple, sans exiger que les clients ne se déplacent pour rencontrer un agent bancaire. Pour accéder à distance aux services de la banque, un client doit préalablement décliner son identité, par exemple en communiquant un identifiant de 11 caractères, puis fournir un mot de passe normalement connu de lui seul et de sa banque. Classiquement le mot de passe est une suite de cinq caractères que l'utilisateur connaît par cœur. Le mot de passe est transmis dans son intégralité à la banque.
La banque vérifie alors dans ses bases de données si le mot de passe correspond à l'identifiant fourni. Si ce n'est pas le cas, une tentative d'usurpation d'identité est très probable et la demande de service est refusée. Si le mot de passe correspond à l'identifiant fourni, la banque autorise le client à accéder au service désiré, par exemple à consulter ses comptes.
La procédure d'authentification et d'identification décrite ci-dessus n'est cependant pas à l'abri d'un accès frauduleux dans le cas où un tiers serait parvenu à découvrir le couple « identifiant - mot de passe ». Certains services ne peuvent donc être rendus accessibles à distance sans mesures de sécurisation supplémentaires.
Par exemple, pour pouvoir effectuer à distance un virement ouvert, par exemple depuis une première banque vers une deuxième banque, le client doit préalablement se déplacer auprès de la première banque pour y faire enregistrer le Relevé d'Identité Bancaire (RIB) du numéro du compte de destination du virement. Cette procédure n'est pas satisfaisante pour le client qui a fait le choix d'une banque à distance.- D'autant -moins- que la banque ne possède pas nécessairement d'établissement à proximité du client.
Pour éviter ce problème, les banques ont donc recours à des tests d'authentification complémentaires pouvant être effectués à distance. Par exemple, l'agent bancaire demande à son correspondant sa date ou son lieu de naissance. La confidentialité de telles informations est cependant très limitée. Le nombre de tests possible est également réduit. Le niveau de sécurité conféré par ces tests d'authentification complémentaires est donc faible.
Il existe donc un besoin pour un procédé d'authentification complémentaire simple à mettre en œuvre et fiable. Le but de l'invention est de satisfaire ce besoin. Selon l'invention, on atteint ce but au moyen d'un procédé d'authentification à distance d'un utilisateur par un fournisseur comportant les étapes suivantes : a) transmission, dudit utilisateur audit fournisseur, d'un identifiant, b) détermination, par ledit fournisseur, d'une règle de traitement applicable à un code constitué de caractères et à disposition dudit utilisateur et dudit fournisseur, c) transmission, dudit fournisseur audit utilisateur, de ladite règle de traitement, d) traitement dudit code par ledit utilisateur au moyen de ladite règle de traitement de manière à obtenir une première donnée d'authentification, e) transmission, dudit utilisateur audit fournisseur, de ladite première donnée d'authentification, et, indépendamment des étapes b) à e), f) récupération, par ledit fournisseur, dudit code, de préférence à partir dudit identifiant, g) traitement dudit code par ledit fournisseur au moyen de ladite règle de traitement de manière à obtenir une deuxième donnée d'authentification, et, après réception de ladite première donnée d'authentification et détermination de ladite deuxième donnée d'authentification, h) comparaison desdites première et deuxième données d'authentification par ledit fournisseur.
Le code à disposition de l'utilisateur et du fournisseur n'est donc pas transmis. Seul le résultat d'un traitement de ce code, selon une règle de traitement déterminée par le fournisseur, est transmis au fournisseur. Même en récupérant ce résultat, un tiers ne peut donc déterminer le code. La procédure d'authentification selon l'invention assure ainsi une très grande sécurité. Avantageusement, une authentification très fiable est donc possible à distance. Pour mettre en œuvre le procédé selon l'invention, seul un code doit être distribué à l'utilisateur. Le procédé selon l'invention est donc avantageusement très simple et peu coûteux.
Le procédé selon l'invention comporte encore les caractéristiques préférées suivantes :
- Ledit code est propre audit utilisateur.
- Ledit code se présente sous la forme d'une série de caractères, de préférence d'une série de chiffres, de préférence imprimée sur une carte du type carte de crédit. - Ladite série de caractères comporte au moins 10 caractères, de préférence au moins 15 caractères, de préférence encore 16 caractères.
- Ladite règle de traitement est modifiée à chaque mise en oeuvre du procédé selon l'invention. De préférence, la règle de traitement est déterminée de manière aléatoire. - Ladite règle de traitement précise comment sélectionner au moins un caractère parmi lesdits caractères constituant ledit code. Ladite règle de traitement identifie ledit au moins un caractère à sélectionner en fournissant une position dudit au moins caractère dans ledit code.
- Ladite règle de traitement identifie une pluralité de caractères à sélectionner en fournissant leurs positions dans ledit code.
- La ou lesdites positions indiquée(s) par ladite règle de traitement (est) sont modifiée(s) à chaque mise en œuvre du procédé selon l'invention, le nombre de positions étant de préférence constant .
Ladite règle de traitement indique l'ordre dans lequel lesdits caractères sélectionnés doivent être ordonnés pour former ladite première donnée d'authentification.
- Selon ladite règle de traitement, lesdits caractères identifiés par leurs positions respectives dans . ledit code doivent être extraits dudit code et, lesdites positions étant fournies de manière ordonnée, lesdits caractères extraits doivent être ordonnés conformément à l'ordre desdites positions.
- A l'étape a), ledit utilisateur transmet en outre au fournisseur un mot de passe de manière qu'après réception dudit mot de passe, ledit fournisseur opère une authentification préalable dudit utilisateur au moyen dudit mot de passe. De préférence les étapes b) à h) ne sont exécutées qu'en cas de succès de ladite authentification préalable.
Ledit fournisseur est un établissement bancaire ou un commerçant offrant des articles ou des prestations sur Internet. - Les communications entre ledit fournisseur et ledit utilisateur se font par voie électronique, par exemple via le réseau Internet, par voie orale, par exemple via un réseau téléphonique, ou par courrier.
- A l'étape h), si lesdites première et deuxième données d'authentification sont différentes, ledit fournisseur ne reconnaît pas ledit utilisateur comme acceptable.
- Après un nombre déterminé de tentatives d'authentification infructueuses, par exemple trois, ledit fournisseur refuse toute nouvelle tentative dudit utilisateur identifié par ledit identifiant.
- Toutes les communications entre le fournisseur et l'utilisateur sont cryptées.
D'autres caractéristiques et avantages de la présente invention apparaîtront à la lecture de la description qui va suivre et à l'examen de dessin annexé dans lequel
- la figure 1 représente un support d'un code d'authentification pouvant être utilisé pour la mise en œuvre d'un procédé selon l'invention ;
- la figure 2 représente schématiquement les étapes d'un procédé d'authentification selon l'invention.
On se reporte à présent à la figure 2. Sur cette figure, les lettres a) à h) correspondent aux étapes du procédé selon l'invention. Faisant suite à la réception d'une requête pour accéder à un service ou acheter un produit, un fournisseur 1 , par exemple une banque, procède à une première étape d'identification de l'utilisateur 2 ayant émis la requête. Au cours de cette première étape (étape a)), l'utilisateur 2 décline son identité, par exemple en communiquant au fournisseur 1 un identifiant Id, classiquement sous la forme d'une suite de 11 caractères, généralement des chiffres.
Un mot de passe confidentiel M, classiquement constitué d'une suite de cinq caractères mémorisée par l'utilisateur 2, peut être également demandé à l'utilisateur 2 afin que le fournisseur 1 puisse procéder à une authentification préalable. A cet effet, le fournisseur 1 vérifie si le mot de passe M reçu est bien celui fourni à titre confidentiel à la personne identifiée par l'identifiant Id. Si ce n'est pas le cas, la demande de l'utilisateur 2 est refusée. Sinon, le fournisseur 1 met en œuvre le procédé d'authentification complémentaire selon l'invention de la manière suivante.
Préalablement à la mise en œuvre du procédé selon l'invention, un code personnalisé C doit avoir été communiqué à l'utilisateur, par exemple par courrier banalisé. Comme on le verra plus en détail dans la suite de la description, plus le code C est long, plus le nombre de « questions », appelées par la suite « règles de traitement », différentes que le fournisseur 1 peut poser à l'utilisateur 2 pour l'authentifier est élevé. Pour que le nombre de ces règles soit élevé, et donc la sécurité de l'authentification très fiable, le code C a donc une longueur qui ne le rend que difficilement mémorisable. De préférence, le code C contient au moins 10, de préférence au moins 15, de préférence encore 16 caractères ordonnés C1-C16. Le code C étant nécessaire à chaque occurrence du procédé d'authentification selon l'invention, il est de préférence fixé sur un support 12, par exemple sur une carte telle que celle représentée sur Ia figure 1.
De préférence, chaque utilisateur 2 possède une carte 12 portant un code C unique. Cette carte lui est personnelle et il ne doit pas en divulguer le code C. Hormis l'utilisateur 2, seul le fournisseur 1 a connaissance du code C et du lien entre le code C et l'utilisateur 2. A cet effet, le fournisseur peut maintenir une base de données 20 contenant l'ensemble des couples « code C - identifiant Id» de ses clients, un identifiant Id unique étant affecté à chaque client.
En cas de succès de la procédure d'authentification préalable, optionnelle, le fournisseur 1 détermine une règle de traitement R apte à extraire une information « cachée » dans le code C (étape b)). De préférence, la règle de traitement change à chaque mise en œuvre du procédé selon l'invention, de préférence de manière aléatoire. De préférence, les modifications apportées à la règle de traitement sont cependant mineures, de manière à ne pas désorienter l'utilisateur 2.
Puis le fournisseur 1 transmet à l'utilisateur 2 à authentifier la règle de traitement R, l'utilisateur 2 devant appliquer cette règle au code C qu'il détient de manière à constituer une première donnée d'authentification A1 (étape c)). Si l'utilisateur 2 possède le code C, il le traite alors selon la règle de traitement R (étape d)) et informe le fournisseur 1 du résultat de ce traitement au moyen d'une première donnée d'authentification A1 valide (étape e)). Une « règle de traitement » R est un ensemble d'instructions précisant comment, à partir du code C, constituer une donnée d'authentification valide.
Une « donnée d'authentification valide » est une donnée portant l'information « cachée » extraite du code C au moyen de la règle de traitement R. De préférence, la règle de traitement R fournit les positions respectives d'un certain nombre de caractères q du code C, demande à l'utilisateur 2 d'identifier dans le code C les caractères q correspondants, puis de les associer aux dites positions. La règle de traitement R se limite alors à une extraction, à partir du code C, de caractères q désignés par leurs positions pi dans le code C. Seule la personne possédant la carte 12 peut déterminer les caractères q ainsi désignés.
Dans le cas d'une communication par Internet, comme représenté sur la figure 1 , le fournisseur 1 peut par exemple demander que lui soient transmis les troisième, douzième et septième caractères du code C en envoyant à l'utilisateur 2 une boîte de dialogue 30 contenant trois zones de saisie 32, 34 et 36, libellées par exemple par « position n°3 », « position n°12 » et « position n°7 », respectivement. L'utilisateur 2 repère alors sur le code C de sa carte 12 les caractères C3, C12 et C7 occupant ces positions, à savoir « 4 », « 0 » et « 2 », respectivement (voir figure 1). L'utilisateur 2 les saisit ensuite dans les zones de saisie 32, 34 et 36, respectivement, puis valide sa saisie. La première donnée d'authentification A1 est alors générée automatiquement, de préférence cryptée et envoyée au fournisseur 1. Si elle est valide, la première donnée d'authentification A1 porte l'information selon laquelle le caractère « 4 » est le caractère en troisième position, le caractère « 0 » est le caractère en douzième position, et le caractère « 2 » est le caractère en septième position. Dans le cas de la règle de traitement préférée, une donnée d'authentification valide est donc une information précisant quels sont les caractères correspondant, dans le code C, aux positions désignées dans règle de traitement R envoyée par le fournisseur 1 à l'utilisateur 2 en vue de procéder à son authentification. Avantageusement, l'envoi d'une boîte de dialogue comportant un ensemble de zones de saisie libellées au moyen des positions des caractères que l'utilisateur 2 doit y saisir est particulièrement simple. Avantageusement, encore, une telle boîte de dialogue permet d'ordonner les positions pi, et donc la suite de caractères q saisis. La règle de traitement R demande ainsi à l'utilisateur 2 non seulement d'identifier dans le code C les caractères q correspondant aux positions pi transmises, mais aussi de les ordonner en les saisissant dans les zones de saisie correspondantes. La probabilité que l'utilisateur 2 puisse fournir une donnée d'authentification A1 valide sans connaître le code C en est ainsi encore réduite.
Dans le cas d'une authentification effectuée par téléphone, la première donnée d'authentification A1 peut être simplement fournie en précisant oralement que les caractères aux positions 3, 12 et 7 sont « 4 », « 0 » et « 2 », respectivement.
Comme expliqué ci-dessus, la règle de traitement R est de préférence modifiée à chaque exécution du procédé selon l'invention (étape b)). De préférence, seules les positions pi utilisées pour désigner les caractères à extraire du code C sont modifiées, le nombre de caractères à extraire du code C étant constant.
Avantageusement, l'utilisateur 2 est ainsi toujours authentifié de manière similaire.
Avantageusement, l'aptitude de la procédure d'authentification à être acceptée par l'utilisateur en est améliorée. Le nombre de règles de traitement différentes qu'il est possible de construire selon ce modèle est d'autant plus grand que le nombre de caractères constituant le code C et le nombre de caractères à en extraire sont grands. De préférence cependant, le nombre de caractères à extraire du code C est toujours inférieur à 5, de préférence encore égal à 3. Avantageusement, la procédure d'authentification en est ainsi plus rapide.
Du fait de la modification de la règle de traitement R à chaque exécution du procédé selon l'invention, les informations sur les couples « caractère q - position pi du caractère q dans le code C » transmises par l'utilisateur 2 au fournisseur 1 au moyen de la première donnée d'authentification A1 sont différentes d'une mise en oeuvre du procédé à la suivante. Avantageusement, la connaissance d'une première donnée d'authentification A1 valide résultant d'une première mise en oeuvre du procédé selon l'invention ne permet donc pas de déduire quelle devrait être cette donnée lors d'une mise en oeuvre subséquente de l'invention.
Enfin, à la différence d'un mot de passe, le code C n'est normalement jamais communiqué dans son intégralité par l'utilisateur 2 au fournisseur 1. Quand bien même un tiers aurait-il eu accès à une première donnée d'authentification A1 valide, il ne pourrait en déduire le code C. Fournir de manière ordonnée les caractères c, du code C désignés par leurs positions respectives pi dans Ie code C est une règle de traitement R particulièrement simple qui, avantageusement, ne nécessite aucune connaissance particulière de la part de l'utilisateur 2. D'autres règles de traitement sont cependant également envisageables. Par exemple, la règle de traitement pourrait être d'extraire les caractères désignés par une couleur, une forme, ou une taille particulières, et de les ordonner selon leurs positions respectives dans le code. La désignation pourrait également être réalisée par la délivrance de couples « abscisse - ordonnée » permettant de retrouver les caractères dans un tableau imprimé sur la carte. Des règles plus complexes, par exemple impliquant des opérations entre des caractères désignés de manière à fournir d'autres caractères puis à former la première donnée d'authentification A1 sont également envisageables.
Après avoir identifié l'utilisateur 2, de préférence au moyen de l'identifiant Id, le fournisseur 1 récupère le code C dans la base de données 20, par exemple au moyen de l'identifiant Id saisi par l'utilisateur 2 (étape T)). Puis le fournisseur 1 applique la règle de traitement R au code C de manière à déterminer une deuxième donnée d'authentification A2 (étape g)). La détermination de la deuxième donnée d'authentification A2 est indépendante de celle de la première donnée d'authentification A1 et peut être faite avant envoi de la règle de traitement R par le fournisseur 1 , ou pendant ou après la détermination et l'envoi de la première donnée d'authentification A1 par l'utilisateur 2.
Le fournisseur compare alors les première et deuxième données d'authentification (étape h)). Si les première et deuxième données d'authentification sont identiques, la première donnée d'authentification A1 est valide. L'utilisateur 2 a donc correctement fourni les caractères désignés selon la règle de traitement R et le fournisseur 1 considère que l'authentification est réussie. Il autorise en conséquence l'utilisateur 2 à accéder au service demandé.
Dans le cas contraire, cet accès est refusé. De préférence, le fournisseur 1 autorise successivement plusieurs tentatives d'authentification selon le procédé de l'invention, par exemple trois tentatives. Si toutes les tentatives sont infructueuses, le fournisseur 1 considère que les échecs ne sont pas des erreurs de lecture ou de saisie de l'utilisateur 2, mais que l'utilisateur 2 ne possède pas le code C. En conséquence, le fournisseur 1 refuse toute tentative ultérieure d'authentification, au moins jusqu'à ce que la situation ne soit éclaircie, par exemple par une rencontre avec l'utilisateur 2.
Le code C n'étant jamais transmis dans son intégralité au cours de l'exécution du procédé selon l'invention, sa confidentialité ne peut être détruite par une telle exécution. Comme cela apparaît clairement à présent, l'invention fournit donc un procédé d'authentification simple à mettre en œuvre et fiable.
Bien entendu, l'invention n'est pas limitée au mode de réalisation décrit ci- dessus. En particulier, le nombre de caractères q du code C, leur nature (chiffres et/ou lettres), le nombre de caractères à saisir pour s'authentifier, et la nature du support (carte ou autre) peuvent être différents de ceux décrits.
Le blocage après un certain nombre d'essais infructueux est également optionnel.
De même, il est théoriquement possible de ne s'authentifier qu'au moyen du procédé selon l'invention décrit ci-dessus, sans avoir fourni préalablement un mot de passe lors d'une procédure d'authentification préalable.
Le domaine d'application préféré est le domaine bancaire, mais n'y est pas limité. Toute transaction nécessitant une authentification renforcée peut avantageusement mettre en œuvre le procédé selon l'invention.

Claims

REVENDICATIONS
1. Procédé d'authentification à distance d'un utilisateur (2) par un fournisseur (1) comportant les étapes suivantes : a) transmission, dudit utilisateur (2) audit fournisseur (1), d'un identifiant
(Id)1 b) détermination, par ledit fournisseur (1), d'une règle de traitement (R) applicable à un code (C) constitué de caractères (C1) et à disposition dudit utilisateur (2) et dudit fournisseur (1), c) transmission, dudit fournisseur (1) audit utilisateur (2), de ladite règle de traitement (R), d) détermination, par ledit utilisateur (2), d'au moins un caractère (q) dudit code C identifiable par sa position (pθ dans ledit code C, ladite position (Pi) étant fournie par ladite règle de traitement (R) de manière à obtenir une première donnée d'authentification (A1), e) transmission, dudit utilisateur (2) audit fournisseur (1), de ladite première donnée d'authentification (A1), et, indépendamment des étapes b) à e), f) récupération, par ledit fournisseur (1), dudit code (C), g) traitement dudit code (C) par ledit fournisseur (1) au moyen de ladite règle de traitement (R) de manière à obtenir une deuxième donnée d'authentification (A2), et, après réception de ladite première donnée d'authentification (A1) et détermination de ladite deuxième donnée d'authentification (A2), h) comparaison desdites première (A1) et deuxième (A2) données d'authentification par ledit fournisseur (1).
2. Procédé selon la revendication 1 , caractérisé en ce que, à l'étape c), ladite règle de traitement (R) est déterminée de manière aléatoire.
3. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que ledit code (C) est fixé sur un support (12).
4. Procédé selon la revendication 3, caractérisé en ce que ledit code (C) est imprimé sur une carte type carte de crédit.
5. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que ladite règle de traitement (R) identifie une pluralité de caractères (q) à
5 sélectionner en fournissant leurs positions (p,) dans ledit code (C).
6. Procédé selon la revendication 5, caractérisé en ce que, selon ladite règle de traitement (R), lesdits caractères (Cj) identifiés par leurs positions respectives (pi) dans ledit code (C) doivent être extraits dudit code (C) et, lesdites positions (p,) étant fournies de manière ordonnée, lesdits caractères extraits (Cj) doivent être
10 ordonnés conformément à l'ordre desdites positions (pi).
7. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'à l'étape a), ledit utilisateur (2) transmet en outre au fournisseur (1) un mot de passe (M) de manière qu'après réception dudit mot de passe (M), ledit fournisseur (1) opère une authentification préalable dudit utilisateur (2) au moyen
15 dudit mot de passe (M).
8. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que les communications entre ledit fournisseur (1) et ledit utilisateur (2) se font par voie électronique, par voie orale ou par courrier.
9. Procédé selon l'une quelconque des revendications précédentes, caractérisé en 20 ce qu'après un nombre déterminé de tentatives d'authentification infructueuses, ledit fournisseur (1) refuse toute nouvelle tentative dudit utilisateur (2) identifié par ledit identifiant (Id).
10. Utilisation d'un procédé selon l'une quelconque des revendications précédentes pour l'authentification à distance d'un utilisateur (2) par un établissement bancaire
-25 ou un commerçant offrant des articles ou des prestations sur internet.
PCT/FR2005/001684 2004-07-02 2005-07-01 Procede d'authentification a distance d’un utilisateur WO2006013258A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US11/630,794 US20070255944A1 (en) 2004-07-02 2005-07-01 Method for Remotely Authenticating a User
GB0700698A GB2431268A (en) 2004-07-02 2007-01-15 Method for remotely authenticating a user

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0407367 2004-07-02
FR0407367A FR2872652B1 (fr) 2004-07-02 2004-07-02 Procede d'authentification d'un utilisateur a distance

Publications (1)

Publication Number Publication Date
WO2006013258A1 true WO2006013258A1 (fr) 2006-02-09

Family

ID=34947415

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2005/001684 WO2006013258A1 (fr) 2004-07-02 2005-07-01 Procede d'authentification a distance d’un utilisateur

Country Status (4)

Country Link
US (1) US20070255944A1 (fr)
FR (1) FR2872652B1 (fr)
GB (1) GB2431268A (fr)
WO (1) WO2006013258A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2445181A (en) * 2006-12-23 2008-07-02 George Evans Partial PIN entry for authorisation

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2450537A (en) * 2007-06-28 2008-12-31 Symbian Software Ltd Identity verification using a subset of identification symbols
CN102104484A (zh) * 2009-12-22 2011-06-22 鸿富锦精密工业（深圳）有限公司 电子设备及密码保护方法
DE102011085538A1 (de) * 2011-11-01 2013-05-02 Bundesdruckerei Gmbh Dokument, Verfahren zur Authentifizierung eines Benutzers, insbesondere zur Freischaltung einer Chipkartenfunktion, und Computersystem

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0292247A2 (fr) * 1987-05-19 1988-11-23 THE GENERAL ELECTRIC COMPANY, p.l.c. Autentificateur
US5410642A (en) * 1989-08-23 1995-04-25 Dai Nippon Printing Co., Ltd. ID card issuing system
DE19523466C1 (de) * 1995-06-28 1997-04-03 Informatikzentrum Der Sparkass Verfahren zur gegenseitigen Authentifikation von elektronischen Partnern mit einem Rechnersystem
US20030229598A1 (en) * 2002-06-05 2003-12-11 Sun Microsystems, Inc., A Delaware Corporation Method and apparatus for protecting against side channel attacks against personal identification numbers

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5276314A (en) * 1992-04-03 1994-01-04 International Business Machines Corporation Identity verification system resistant to compromise by observation of its use
US6246769B1 (en) * 2000-02-24 2001-06-12 Michael L. Kohut Authorized user verification by sequential pattern recognition and access code acquisition

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0292247A2 (fr) * 1987-05-19 1988-11-23 THE GENERAL ELECTRIC COMPANY, p.l.c. Autentificateur
US5410642A (en) * 1989-08-23 1995-04-25 Dai Nippon Printing Co., Ltd. ID card issuing system
DE19523466C1 (de) * 1995-06-28 1997-04-03 Informatikzentrum Der Sparkass Verfahren zur gegenseitigen Authentifikation von elektronischen Partnern mit einem Rechnersystem
US20030229598A1 (en) * 2002-06-05 2003-12-11 Sun Microsystems, Inc., A Delaware Corporation Method and apparatus for protecting against side channel attacks against personal identification numbers

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
FERREIRA R C: "THE SMART CARD: A HIGH SECURITY TOOL IN EDP", PHILIPS TELECOMMUNICATION REVIEW, PHILIPS TELECOMMUNICATIE INDUSTRIE N.V. HILVERSUM, NL, vol. 47, no. 3, 1 September 1989 (1989-09-01), pages 1 - 19, XP000072642 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2445181A (en) * 2006-12-23 2008-07-02 George Evans Partial PIN entry for authorisation

Also Published As

Publication number Publication date
FR2872652B1 (fr) 2007-03-30
GB0700698D0 (en) 2007-02-21
US20070255944A1 (en) 2007-11-01
FR2872652A1 (fr) 2006-01-06
GB2431268A (en) 2007-04-18

Similar Documents

Publication Publication Date Title
EP1730704B1 (fr) Procede de controle d'identification de personnes pour la delivrance de droits et systeme pour la mise en oeuvre du procede
EP1875446B1 (fr) Dispositif, procede et systeme de securite pour transactions financieres, reposant sur l'identification d'un individu grâce a son profil bio-metrique, et utilisant une carte a microprocesseur
EP0250309A1 (fr) Procédé pour faire authentifier par un milieu extérieur un objet portatif tel qu'une carte à mémoire accouplée à ce milieu
FR2919974A1 (fr) Systeme d'information et procede d'identification par un serveur d'application d'un utilisateur
EP0606792B1 (fr) Procédé d'authentification d'un ensemble informatique par un autre ensemble informatique
WO2000062262A1 (fr) Procede et systeme de securisation de l'utilisation de cartes comportant des moyens d'identification et/ou d'authentification
WO2006013258A1 (fr) Procede d'authentification a distance d’un utilisateur
EP3707669A1 (fr) Procédé d'obtention d'une identité numérique de niveau de sécurité élevé
EP3262553B1 (fr) Procede de transaction sans support physique d'un identifiant de securite et sans jeton, securise par le decouplage structurel des identifiants personnels et de services
EP0829831B1 (fr) Méthode d'authentification de cartes
EP1142193A1 (fr) Procede de chargement securise de donnees entre des modules de securite
FR2816736A1 (fr) Procede et installation de securisation de l'utilisation de supports associes a des identifiants et a des dispositifs electroniques
EP1634220B1 (fr) Procede et dispositif d'identification biometrique adaptes a la verification sur carte a puce
FR2730076A1 (fr) Procede d'authentification par un serveur du porteur d'un objet portatif a microprocesseur, serveur et objet portatif correspondants
EP1269431B1 (fr) Procede de protection d'une puce electronique contre la fraude
EP1301910B1 (fr) Procede pour securiser une transaction via un reseau de telecommunication, et systeme de mise en oeuvre du procede
FR2861482A1 (fr) Procede de securisation d'une donnee biometrique d'authentification et procede d'authentification d'un utilisateur a partir d'une donnee biometrique d'authentification
FR2802685A1 (fr) Systeme de comparaison de numero personnel d'identification (pin) pour une carte dotee d'un affichage variable
WO2018029564A1 (fr) Systeme et procede d'authentification sans mot de passe d'un utilisateur d'un systeme applicatif par un serveur central
EP3284209B1 (fr) Procédés de génération et de vérification d'une clé de sécurité d'une unité monétaire virtuelle
EP3395042B1 (fr) Serveur d'authentification pour le contrôle d'accès a un service
WO2021249950A1 (fr) Procede de revelation digitale d'au moins une donnee securitaire d'une carte a puce et utilisations de ce procede
EP3863219A1 (fr) Procédé et dispositif d'évaluation de correspondance d'ensembles de données structurées protégées par le chiffrement
FR3011111A1 (fr) Securisation d'une transmission de donnees d'identification
FR3101182A3 (fr) Procédé de transmission chiffrée

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NG NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU LV MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

WWE Wipo information: entry into national phase

Ref document number: 11630794

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

WWW Wipo information: withdrawn in national office

Country of ref document: DE

WWE Wipo information: entry into national phase

Ref document number: 0700698.4

Country of ref document: GB

Ref document number: 0700698

Country of ref document: GB

121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase
WWP Wipo information: published in national office

Ref document number: 11630794

Country of ref document: US