FR3011964A1 - Procede automatise d'authentification forte multifacteur - Google Patents
Procede automatise d'authentification forte multifacteur Download PDFInfo
- Publication number
- FR3011964A1 FR3011964A1 FR1359970A FR1359970A FR3011964A1 FR 3011964 A1 FR3011964 A1 FR 3011964A1 FR 1359970 A FR1359970 A FR 1359970A FR 1359970 A FR1359970 A FR 1359970A FR 3011964 A1 FR3011964 A1 FR 3011964A1
- Authority
- FR
- France
- Prior art keywords
- user terminal
- application server
- result
- user
- stimulation
- 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.)
- Granted
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
- H04L63/0884—Network architectures or network communication protocols for network security for authentication of entities by delegation of authentication, e.g. a proxy authenticates an entity to be authenticated on behalf of this entity vis-à-vis an authentication entity
-
- 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/388—Payment protocols; Details thereof using mutual authentication without cards, e.g. challenge-response
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
- H04L9/3242—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
- H04L9/3273—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response for mutual authentication
-
- 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
- H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
-
- 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/18—Network architectures or network communication protocols for network security using different networks or channels, e.g. using out of band channels
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Power Engineering (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
L'invention vise un procédé d'authentification de transaction entre deux utilisateurs dudit procédé, un premier utilisateur étant doté d'un serveur informatique dit "serveur client", un second utilisateur étant doté d'un ordinateur dit "ordinateur utilisateur" ou d'un terminal mobile, les deux utilisateurs étant préalablement identifiés sur un serveur applicatif mettant en œuvre le procédé. Le procédé comporte des étapes suivantes : 101 - le serveur client (10) émet à destination du serveur applicatif (13) une demande de vérification d'identité (requête) comportant une première stimulation (challenge 1), 104 - une demande de vérification d'identité est échangée entre le terminal utilisateur (11) et le serveur applicatif (13), 105 - le serveur applicatif (13) envoie au terminal utilisateur (11) une seconde stimulation (challenge2), 106 - le terminal utilisateur (11) résout cette seconde stimulation et renvoie le résultat au serveur applicatif (13), 107 - si le résultat est vérifié comme correct, le serveur applicatif (13) transmet au serveur client (10) le résultat de la première stimulation, 108 - la transaction est validée ou refusée selon la comparaison des résultats.
Description
La présente invention relève du domaine des procédés d'authentification d'identité, mis en oeuvre lors de transmission d'informations entre systèmes distants.
Préambule et art antérieur Il existe à ce jour divers procédés d'authentification d'un utilisateur lors d'une transaction de type paiement par carte de crédit, par exemple durant un achat sur un site de e-commerce. Un des plus couramment utilisés à ce jour est le procédé dans lequel, une fois une transaction effectuée et le paiement requis en ligne par l'utilisateur sur un site de e-commerce, ledit utilisateur reçoit de la part de sa banque un code sous forme de SMS sur son téléphone mobile. L'utilisateur doit alors entrer ce code sur l'interface utilisateur de paiement de sa transaction pour authentifier celle-ci. Le fait que la personne effectuant la transaction dispose du téléphone mobile du titulaire du compte bancaire est considéré comme une preuve suffisante de l'identité de ce titulaire. On connaît également les transactions autorisées par procédure dite stimulation / réponse (également connue de l'homme du métier sous la terminologie "challenge / response"). Un tel procédé comporte usuellement des étapes suivantes : 1. Un client transmet son login au serveur. 2. Le serveur génère aléatoirement un nombre de N octets (le Challenge) et le transmet au client. 3. Le client chiffre le Challenge reçu grâce au mot de passe password, puis transmet le résultat au serveur. Le mot de passe lui-même n'est jamais transféré. 4. Le serveur interroge une base SAM pour obtenir le bon mot de passe. 5. Le serveur chiffre le Challenge avec le bon mot de passe. 6. Les 2 résultats chiffrés sont comparés. 7. S'ils sont égaux, c'est que le mot de passe saisi est correct. Dans ce cas, un jeton local est créé, permettant la continuation d'une transaction. De façon générale, les divers procédés actuellement envisagés sont complexes, ou manquent de sécurité. C'est typiquement le cas des procédés stimulation / réponse. La présente invention vise à remédier à tout ou partie de ces inconvénients.
Exposé de l'invention L'invention vise à cet effet en premier lieu un procédé d'authentification de transaction entre deux utilisateurs dudit procédé, un premier utilisateur étant doté d'un serveur informatique dit "serveur client", un second utilisateur étant doté d'au moins un terminal informatique, les deux utilisateurs étant préalablement identifiés sur un serveur applicatif mettant en oeuvre le procédé. On entend par terminal informatique notamment un ordinateur de type PC, mais aussi un téléphone mobile de type smartphone (le cas de figure où deux terminaux informatique distincts sont employés est plus sécurisé car il augmente le nombre de routes utilisées pour faire transiter les informations), ou un ordinateur tablette. Le procédé comporte des étapes suivantes : 101 - le serveur client émet à destination du serveur applicatif une demande de vérification d'identité comportant une première stimulation, 104 - une demande de vérification d'identité est échangée entre le terminal utilisateur et le serveur applicatif, 105 - le serveur applicatif envoie au terminal utilisateur une seconde stimulation, 106 - le terminal utilisateur résout cette seconde stimulation et renvoie le résultat au serveur applicatif, 107 - si le résultat est vérifié comme correct, le serveur applicatif transmet au serveur client le résultat de la première stimulation, 108 - la transaction est validée ou refusée selon la comparaison des résultats.
Selon divers modes de mise en oeuvre, éventuellement utilisés en conjonctions selon toutes les combinaisons techniquement réalisables : - dans l'étape 104, le terminal utilisateur envoie au serveur applicatif son identifiant unique et demande une vérification d'identité, - dans l'étape 104, le serveur applicatif émet à destination du terminal utilisateur une demande de vérification d'identité comportant une deuxième stimulation, - dans l'étape 101, le serveur client envoie également au serveur applicatif un premier paramètre d'authentification (checksum1), - le procédé comportant également une étape 102 dans laquelle le serveur applicatif recalcule le premier paramètre d'authentification et compare le résultat avec le premier paramètre reçu, et, dans le cas favorable, génère la seconde stimulation et calcule son résultat, - le premier paramètre d'authentification checksuml est le résultat du hachage non réversible de plusieurs éléments indispensables à identifier la requête, - dans l'étape 102, dans le cas favorable, le serveur applicatif envoie au serveur client un identifiant de requête (token), - l'étape 107 est divisée en deux sous-étapes dans lesquelles : 107a - si le résultat est vérifié comme correct, le serveur applicatif envoie au terminal utilisateur le résultat de la première stimulation, 107b - le terminal utilisateur envoie ce résultat de la première stimulation au serveur client. Dans ce cas, dans une mise en oeuvre plus particulière, le procédé comporte une étape 103 dans laquelle le serveur client envoie au terminal utilisateur notamment un second paramètre d'authentification, ce paramètre d'identification étant retourné au serveur client dans l'étape 107b de transmission de la première stimulation. Dans le cas où le second utilisateur dispose d'un premier terminal utilisateur et d'au moins un second terminal utilisateur: - dans l'étape 104, la demande de vérification d'identité est effectuée par un second terminal utilisateur, - dans l'étape 105, le serveur applicatif envoie à ce second terminal utilisateur une seconde stimulation, - dans l'étape 106, ce second terminal utilisateur résout cette seconde stimulation et renvoie le résultat au serveur applicatif. Dans un mode particulier de réalisation, à la fin de l'étape 102, le stockage de contexte est effectué sur le premier terminal utilisateur. Dans un mode particulier de réalisation, l'étape 107 est divisée en deux sous-étapes dans lesquelles : 107a - si le résultat est vérifié comme correct, le serveur applicatif envoie au premier terminal utilisateur le résultat de la première stimulation challenge 1, 107b - le premier terminal utilisateur envoie ce résultat de la première stimulation challenge1 au serveur client.
Dans un mode particulier de réalisation, la première stimulation est définie par un nombre pseudo-aléatoire comportant un algorithme de hachage choisi parmi une liste prédéfinie, la réponse à la stimulation consistant à hacher la concaténation d'éléments identifiant le serveur client, et une clé secrète utilisateur.
Dans un mode particulier de réalisation, la première stimulation est définie par un nombre pseudo-aléatoire comportant trois éléments : 1/ un numéro définissant l'algorithme choisi parmi une liste prédéfinie, 2/ sait (élément ajouté au bout du mot à hacher, lors d'une procédure de hachage, pour améliorer la sécurité du nombre généré), 3/ N : nombre d'itérations à effectuer, la réponse à la stimulation consistant à hacher N fois la concaténation d'éléments identifiant le serveur client, et une clé secrète utilisateur avec le paramètre sait via l'algorithme choisi.
Préférentiellement, pour améliorer la sécurité du procédé, les paramètres sait et de nombre d'itérations sont des valeurs aléatoires et sont déterminés pour chaque demande.
Dans une variante de mise en oeuvre, la concaténation d'élément à hacher comprend également un élément identifiant le terminal utilisateur. L'invention vise sous un second aspect un terminal de paiement, un téléphone mobile ou un serveur d'authentification, mettant en oeuvre un procédé tel qu'exposé. Présentation des figures Les caractéristiques et avantages de l'invention seront mieux appréciés grâce à la description qui suit, description qui expose les caractéristiques de l'invention au travers d'un exemple non limitatif d'application. La description s'appuie sur les figures annexées qui représentent : Figure 1: un schéma des étapes du procédé, dans une mise en oeuvre particulière impliquant deux terminaux utilisateurs, dont un terminal d'identification utilisateur dédié, Figure 2: un schéma des étapes du procédé, dans une mise en oeuvre impliquant un seul terminal utilisateur, Figure 3: un schéma des étapes du procédé, dans une variante de mise en oeuvre, Figure 4: un schéma des étapes du procédé, dans une autre variante de mise en oeuvre, Figure 5: un schéma des étapes du procédé, dans une autre variante de mise en oeuvre.
Description détaillée d'un mode de réalisation de l'invention Comme on le voit sur la figure 1, l'invention trouve sa place dans le cadre d'une transaction entre un serveur client 10, et un utilisateur détenant un terminal utilisateur principal 11a (par exemple un ordinateur de type PC) et un terminal mobile de type smartphone ou tablette 11b.
L'invention met également en oeuvre un serveur applicatif central 13. Ces divers éléments sont dotés de moyens de calcul, de moyens de mémorisation de données et d'applications logicielles, de moyens de communication via un réseau, filaire ou non, notamment de type réseau TCP/IP ou GSM, tous ces moyens étant connus en soi. L'invention est destinée à être mise en oeuvre sous forme logicielle. Ledit logiciel est installé, dans le présent exemple non limitatif de mise en oeuvre, pour une première partie (application client) dans le serveur client 10, pour une seconde partie (application utilisateur) dans un terminal utilisateur (dans le cas ou 2 terminaux utilisateurs sont utilisés, un seul des 2 sert de terminal d'authentification ; il est donc le seul sur lequel il est nécessaire d'avoir préalablement installé l'application utilisateur), par exemple le terminal utilisateur mobile 11 b et pour une troisième partie (application de traitement) dans le serveur applicatif central 13. Dans une phase préliminaire, un client 10 demande à être identifié pour les besoins d'utilisation du procédé : le client référence son application client sur le serveur applicatif 13. Le serveur applicatif génère un identifiant et une clé secrète que le client reporte manuellement dans l'application client sur le serveur client 10. De même, dans une phase préliminaire, un utilisateur doté de terminaux utilisateur 11 a, 11 b demande à être identifié pour les besoins d'utilisation du procédé. Il ouvre pour ce faire l'application utilisateur sur le terminal utilisateur 11b, laquelle envoie une requête à l'application de traitement exécutée sur le serveur applicatif central 13. Cette étape se répète à chaque fois qu'un utilisateur se connecte pour la première fois sur un serveur client 10. Dans ce cas, dans la mise en oeuvre décrite ici à titre d'exemple non limitatif, le serveur applicatif 13 transmet, entre autres, au serveur client 10 un code d'identification. Ce code est affiché sur le terminal utilisateur 11 a. L'utilisateur saisit ce code dans l'application utilisateur du terminal llb et l'envoie avec son identifiant unique au serveur applicatif 13. Le serveur applicatif 13 génère une clé secrète (ici une clé secrète symétrique, par opposition aux procédés mettant en oeuvre une clé secrète et une clé publique) et la transmet au terminal utilisateur 11 b. On comprend que, dans la pratique, de nombreux clients et utilisateurs vont s'identifier au cours du temps sur le serveur applicatif central 13. Dès lors que l'un au moins des serveurs clients et l'un au moins des serveurs utilisateurs sont identifiés, ils peuvent passer en phase d'utilisation, pendant que d'autres utilisateurs ou clients sont en phase d'identification.
Dans le présent exemple de mise en oeuvre du procédé, donné ici à titre nullement limitatif, celui-ci comporte les étapes suivantes : Dans une première étape 101, l'application client installée sur le serveur client 10 envoie au serveur applicatif central 13 une demande de vérification d'identité d'un utilisateur (associé à au moins un terminal utilisateur 11a, 11b).
Les informations fournies dans cette requête sont les suivantes : website id : identifiant du serveur client 10, fourni par le serveur applicatif central 13 lors de la phase préliminaire de création du compte client par le serveur client 10, website user id : identifiant de l'utilisateur (identifiant utilisateur sur l'environnement client, généré par le client par exemple lorsque l'utilisateur a créé son compte), créé et fourni par le client. challengel : nombre pseudo-aléatoire comportant trois éléments : 1/ un numéro définissant l'algorithme choisi parmi une liste prédéfinie (par défaut on utilise un algorithme de type SHA1, - Secure Hach Algorithm - fonction de hachage cryptographique, destinée à produire des nombres pseudo-aléatoires de 160 bits, connue en soi), 2/ sait (256 bits) (c'est à dire un élément ajouté au bout du mot (de la clé secrète) à hacher, lors d'une procédure de hachage, pour améliorer la sécurité du nombre généré), 3/ itérations : nombre d'itérations à effectuer [compris entre 16 et 256].
La réponse au challenge correspond au résultat de la fonction de dérivation "Password-Based Key Derivation Function 2" (PBKDF2), le challenge consiste à hacher N fois (N = itérations) la concaténation de website id, website user id, secretKey avec ce paramètre sait via l'algorithme choisi.
II est à noter que, dans la présente mise en oeuvre du procédé, les paramètres sait et itérations sont des valeurs aléatoires et sont déterminés pour chaque demande. Les variables aléatoires sait et itérations font parties du challenge et sont transmises lors de la requête. Le challenge pourrait être complexifié en choisissant de rendre aléatoire l'algorithme de hachage parmi une liste prédéterminée. Dans une autre variante, le challenge1 lui-même est crypté pour améliorer la sécurité de la transaction.
Ces éléments (numéro d'algorithme, sait et itérations) constituent un premier nombre pseudo-aléatoire nommé challenge) dans la suite de la description, ce nombre (la stimulation) devant servir au serveur client 10 et au serveur applicatif 13 à hacher, dans une étape ultérieure du procédé, des éléments identiques et à vérifier ainsi leurs identités réciproques. checksum1 : résultat du hachage par l'algorithme SHA256 de la concaténation de website id, website user id, algorithme, sait, itérations, secretKey (le paramètre de clé secrète secretKey est fourni par le serveur applicatif central 13 lors de la création du compte de l'application client 10). En d'autres termes, ce nombre checksum1 est le résultat du hachage non réversible de plusieurs éléments indispensables à identifier la requête. La fonction de ce nombre checksum1 est de permettre de s'assurer de l'identité du demandeur et que sa requête n'a pas été altérée ni modifiée. Pour cela, le serveur applicatif central 13 calcule à son tour le hach unique checksuml_verif basé sur les paramètres de la requête (non altération) et la clé secrète (connue uniquement de l'application client et du serveur applicatif (lors de la phase d'identification). Les valeurs checksum1 et checksuml_verif doivent être égales. Si ce n'est pas le cas, la requête est rejetée.
Dans une seconde étape 102, l'application de traitement, exécutée sur le serveur applicatif central 13 analyse et traite la requête du serveur client 10 créée dans l'étape 101. L'application de traitement vérifie préalablement la présence des paramètres entrants requis et valide le nombre reçu checksum1. Pour ce faire, il reproduit le hachage des éléments website id, website user id, algorithme, sait, itérations, secretKey avec le même algorithme SHA256 et compare le résultat obtenu avec le nombre checksum1 reçu. En cas de paramètre manquant ou de différence sur la valeur du checksuml reçu, la requête est rejetée. Deux cas se présentent alors pour le résultat de cette validation : 1/ Si le couple website id, website user id est connu (c'est à dire présent dans une base de données ad hoc préalablement crée au sein du serveur applicatif central 13 et recensant les identifiants des divers serveurs clients 10 et terminaux utilisateurs 11a, 11b inscrits pour l'utilisation du système), l'application de traitement effectue les opérations suivantes : - Définition d'un second nombre pseudo-aléatoire nommé dans la suite de la description challenge2 (selon le même principe que la stimulation challenge1, c'est à dire choix de l'algorithme et génération de deux nombres pseudo-aléatoires salt2 et itérations2 ...), calcul de son résultat (c'est à dire du hachage de la clé secrète en fonction des paramètres définis pour la stimulation challenge2 : la stimulation challenge2 consiste à hacher N fois (N = itérations) la concaténation de website id, website user id, clé secrète avec ce paramètre sait via l'algorithme choisi (PBKDF2). Dans une variante de mise en oeuvre, on ajoute à cette chaîne à hacher l'identifiant du terminal utilisateur. - Stockage temporaire des éléments de la requête et de la stimulation challenge2. Ces données ont pour clé (critère de recherche) l'identifiant unique du terminal utilisateur qui sera utilisé pour confirmer l'identification. Il est à noter que l'utilisateur peut posséder plusieurs terminaux d'authentification. Dans ce cas, les données sont dupliquées pour pouvoir être retrouvées avec chacun des identifiants uniques de terminal. 2/ Si le couple website id, website user id n'existe pas dans la base de données associée à l'application de traitement du serveur applicatif central 13, l'application de traitement lance une étape d'association du couple website id / website user id avec le terminal utilisateur 11a, 11 b de l'utilisateur final. Il s'agit de l'étape préliminaire décrite plus haut ou le terminal utilisateur se connecte pour la première fois à l'application client. Comme on l'a dit plus haut, dans ce cas, dans la mise en oeuvre décrite ici à titre d'exemple non limitatif, le serveur applicatif 13 transmet, entre autres, au serveur client 10 un code d'identification. Ce code est affiché sur le terminal utilisateur 11a.
Les informations retournées au serveur client 10 par le serveur applicatif 13 à la fin de cette seconde étape 102 comportent : - Un jeton (token) (un token est un identifiant unique à durée de vie limitée, associé à la requête en cours. Il permet au terminal utilisateur principal 11 a d'informer le serveur applicatif 13 de la requête concernée). Ce jeton sera utilisé lors de la création d'un second nombre checksum2, - Un message d'information à afficher sur le terminal utilisateur principal 11 a LE-MESSAGE.
Dans une troisième étape 103, le serveur client 10 demande au terminal utilisateur principal 11a de se mettre en attente d'une réponse du serveur applicatif central 13. Le serveur client 10 génère une page web, comportant un formulaire avec le contexte de la requête en cours et le message d'information (LE- MESSAGE). La page web est envoyée sur le terminal utilisateur principal 11a. L'application exécutée sur le terminal utilisateur principal lla affiche la page et ouvre une transaction selon le protocole websocket SSL sur le serveur applicatif central 13 (dans le présent exemple de mise en oeuvre, l'application prend en compte des serveurs web).
Cette étape 103 est également exécutée dans le cas d'un seul terminal utilisateur. Les éléments mentionnés ci-dessous représentent le contexte de la requête d'authentification en cours et sont passés par le serveur client 10. Les informations stockées dans ce formulaire web comprennent 25 notamment, dans le présent exemple : - challenge1 : algorithme, sait, nombre d'itérations (éventuellement crypté, par exemple par l'algorithme AES 256) - Login de l'utilisateur : pour pouvoir rechercher son identifiant (website user id) par la suite, 30 - Timestamp : Heure (du serveur client 10) à partir duquel la réponse est rejetée, - Checksum2 : hachage par sha256 de la concaténation des éléments suivants : Timestamp + token + challenge1 + cryptage sha256 de la clé secrète (secretKey) du serveur client 10 + website id + website user id + url de redirection + login utilisateur. Dans une étape suivante 104, une demande de vérification d'identité est échangée entre le terminal utilisateur et le serveur applicatif. Dans la présente mise en oeuvre, c'est l'utilisateur qui initie cette demande d'approbation d'identité. Dans l'étape 104, l'utilisateur lance la procédure d'identification via son terminal mobile 11 b. Pour ce faire, il lance l'application utilisateur mettant en oeuvre le procédé sur terminal mobile 11b. Cette application utilisateur se connecte au serveur applicatif central 13 et demande si une authentification est en attente. Cette séparation des étapes 103 et 104 se justifie dans le cas où l'utilisateur dispose effectivement de deux (ou plus) terminaux utilisateurs (11a, 11 b sur la figure 1) : l'utilisateur s'authentifie depuis un logiciel client installé sur un ordinateur personnel 11a et confirme son identité depuis un smartphone 11b. Dans ce cas, le smartphone 11 b ne sait pas si une authentification est en attente de confirmation. Le terminal mobile 11b envoie au serveur applicatif central 13 son identifiant unique. Dans une cinquième étape 105, l'application de traitement exécutée sur le serveur applicatif central 13 recherche si une authentification est en attente de confirmation. Pour cela elle utilise l'identifiant unique du terminal mobile utilisateur 11 b et parcoure son stockage temporaire. Si une authentification est en attente, la seconde stimulation challenge2 est retournée à l'application utilisateur exécutée sur le terminal mobile 11b. Dans une sixième étape 106, l'application utilisateur exécutée sur le 30 terminal mobile 11b résout la stimulation challenge2 (avec l'algorithme PBKDF2 sur la concaténation de website id, website user id, la clé secrète utilisateur) et renvoie le résultat au serveur applicatif central 13.
L'application résout la stimulation challenge2 en appliquant le hach PBKDF2 sur la concaténation de website id, website user id et la clé secrète (website secretKey) de l'utilisateur pour ce site client 10 (on utilise en effet dans le procédé une clé secrète distincte par compte utilisateur et par serveur client 10). Dans une variante de mise en oeuvre, un autre algorithme de hachage peut être utilisé. Le procédé utilise ici PBKDF2 pour les paramètres aléatoires qu'il propose et donc son résultat fort. Les informations envoyées au serveur applicatif central 13 par l'application utilisateur comprennent notamment : l'identifiant unique du terminal mobile 11b de l'utilisateur, utilisé comme identifiant de la requête d'identification en cours. la réponse à la stimulation challenge2, sous forme d'une chaîne hexadécimale.
Dans une étape 107a, l'application de traitement, exécutée sur le serveur applicatif central 13, vérifie la réponse à la stimulation challenge2 reçue du terminal utilisateur mobile 11 b dans l'étape 106. Pour ce faire, l'application de traitement, exécutée sur le serveur applicatif central 13, recherche dans son stockage temporaire, via l'identifiant unique du terminal utilisateur mobile 11b, les données de la requête en cours, compare son résultat de la stimulation challenge2 (stocké en mémoire lors de l'étape 102) avec celui fournit par l'application utilisateur dans l'étape 106. Une confirmation (ou infirmation) est envoyée par le serveur applicatif central 13 au terminal utilisateur principal 11a.
Si la réponse à la stimulation challenge2 fournie par le terminal utilisateur mobile 11b était la bonne, ce qui signifie que le couple client / utilisateur correspondant à une transaction spécifique est authentifié par le serveur applicatif, le serveur applicatif central 13 calcule la réponse à la stimulation challenge1 (PBKDF2 sur la concaténation de website id, website user id et la clé secrète du client) et envoie cette réponse vers le terminal principal 11 a de l'utilisateur. Celui-ci est en effet alors considéré comme authentifié.
Si la réponse à la stimulation challenge2 n'était pas la bonne (ou arrivée hors délai), un code erreur est envoyé à la place de la réponse à la stimulation challenge 1.
Dans une étape suivante 107b, le logiciel client exécute sur le terminal utilisateur principal 11a envoie le résultat du challenge) (ou le code erreur) sur le serveur client 10. La réponse (à la stimulation challenge1) est reçue sur le terminal principal 11a de l'utilisateur (par une opération push sur websocket), insérée dans le formulaire (voir étape 103) puis soumis sur le serveur client 10. Le serveur client 10 recalcule le paramètre de vérification checksum2 et le compare à celui fournit via le formulaire (dans l'étape 103). Si la comparaison est correcte, le serveur client 10 résout le challenge) (c'est à dire effectue une opération de hachage de PBKDF2 sur la concaténation de website id, website user id, secretKey (secretKey) et le compare à celui fourni par le serveur applicatif central 13 via le formulaire, et enfin si l'égalité est obtenue, authentifie l'utilisateur. La transaction est ainsi finalement autorisée ou refusée (selon que l'authentification est confirmée) dans une étape 108. Avantages du procédé décrit Le procédé tel que décrit est plus : Sûr : 1 - les échanges d'informations sont tous cryptés (contrairement à un code de vérification envoyé par SMS transite en clair et peut être intercepté), 2 - le procédé est un deuxième verrou totalement indépendant du système d'authentification client. Sa mise en oeuvre ne nécessite pas la connaissance, à priori comme à posteriori, des données d'authentification utilisateurs (login, mot de passe). Pirater la base de données liée au Procédé ne fragilise pas le système informatique du Client. Rapide : l'utilisateur n'a pas besoin de ressaisir un code de vérification, ni d'attendre un SMS, Robuste : il ne repose pas sur le réseau d'un tiers (ie : opérateur téléphonique pour un code envoyé par SMS, Universel : car il peut être utilisé via tout support informatique disposant d'un accès au réseau internet (ordinateur de bureau, mobile, tablette, serveur, automate). Variantes Dans une première variante de mise en oeuvre (illustrée par la figure 2), l'utilisateur 11 dispose d'un seul terminal 11 (au lieu des terminaux principaux et mobiles 11a, 11b), par exemple de type PC, téléphone mobile ou tablette PC. Dans ce cas, l'étape 103 (connexion et mise en attente par le terminal utilisateur principal 11a) est remplacée par une étape 103', et les opérations des étapes 104, 105 et 106 sont réalisées par le terminal utilisateur unique 11.
De même, la réponse à la première stimulation challenge) est renvoyée par le serveur applicatif au terminal utilisateur unique 11, lequel renvoie ladite réponse au serveur client 10. De façon plus détaillée, dans l'étape 103', le terminal utilisateur 11 se met en attente d'une réponse du serveur applicatif central 13 : le serveur client 10 affiche sur le terminal utilisateur 11 un message d'information (passé par le serveur applicatif 13 ci-dessus LE-MESSAGE) et le met en attente passive d'une réponse du serveur applicatif central 13 (cette réponse étant constituée du résultat du challenge 1 ou d'un code erreur).
La variante principale, dans laquelle deux terminaux utilisateurs sont mis en oeuvre, contrairement à la variante décrite ci-dessus, réduit la possibilité d'interception et d'usurpation des informations échangées lors des transactions, comme ce pourrait être le cas dans l'attaque de l'homme du milieu (Man In The Middle). La variante principale est plus sûre car elle utilise un plus grand nombre de chemins distincts pour faire transiter les transactions. Dans une seconde variante de mise en oeuvre, simplifiée, illustrée par la figure 3, le procédé s'affranchit des paramètres checksums et le résultat de la première stimulation challenge1 est renvoyé par le serveur applicatif 13 directement au serveur client 10 (sans passer par le terminal utilisateur 11). Plus précisément, le procédé comporte alors notamment les étapes suivantes : 101 - le serveur client 10 émet à destination du serveur applicatif 13 une demande de vérification d'identité d'un terminal utilisateur 11 comportant une première stimulation (challenge1), 104' - le terminal utilisateur 11 émet à destination du serveur applicatif une demande d'approbation d'identité, 105 - le serveur applicatif 13 transmet à destination du terminal utilisateur 11 une seconde stimulation (challenge2), 106 - le terminal utilisateur 11 résout cette seconde stimulation et envoie le résultat au serveur applicatif 13, 107 - si le résultat est vérifié comme correct, le serveur applicatif 13 envoie au serveur client 10 le résultat de la première stimulation, cette étape remplace alors les étapes 107a, 107b de la mise en oeuvre décrite plu haut 108 - la transaction est validée ou refusée selon la comparaison des résultats.
Une troisième variante, illustrée par la figure 4, est identique à la variante ci-dessus, mais en conservant les étapes 107a et 107b, c'est-à-dire un retour du résultat de la première stimulation challenge1 par le serveur applicatif 13 au serveur client 10 en passant par le terminal utilisateur 11.
Dans une quatrième variante de mise en oeuvre, illustrée par la figure 5, les différences sont les mêmes que la mise en oeuvre ci-dessus mais ici c'est le serveur applicatif 13 qui contacte le terminal utilisateur 11 dans l'étape 104. On a alors les étapes suivantes : 101 - le serveur client 10 émet à destination du serveur applicatif 13 une demande de vérification d'identité d'un terminal utilisateur 11 comportant une première stimulation (challenge1), 104 - le serveur applicatif 13 émet à destination du terminal utilisateur 11 une demande de vérification d'identité comportant une deuxième stimulation (challenge2), 106 - le terminal utilisateur 11 résout cette seconde stimulation et renvoie le résultat au serveur applicatif 13, 107 - si le résultat est vérifié comme correct, le serveur applicatif 13 envoie au serveur client 10 le résultat de la première stimulation, 108 - la transaction est validée ou refusée selon la comparaison des résultats.
Claims (13)
- REVENDICATIONS1. Procédé d'authentification de transaction entre deux utilisateurs dudit procédé, un premier utilisateur étant doté d'un serveur informatique dit "serveur client" (10), un second utilisateur étant doté d'au moins un terminal utilisateur (11), les deux utilisateurs étant préalablement identifiés sur un serveur applicatif (13) mettant en oeuvre le procédé, caractérisé en ce que le procédé comporte des étapes suivantes : 101 - le serveur client (10) émet à destination du serveur applicatif (13) une demande de vérification d'identité (requête) comportant une première stimulation (challengel), 104 - une demande de vérification d'identité est échangée entre le terminal utilisateur (11) et le serveur applicatif (13), 105 - le serveur applicatif (13) envoie au terminal utilisateur (11) une seconde stimulation (challenge2), 106 - le terminal utilisateur (11) résout cette seconde stimulation et renvoie le résultat au serveur applicatif (13), 107 - si le résultat est vérifié comme correct, le serveur applicatif (13) transmet au serveur client (10) le résultat de la première stimulation, 108 - la transaction est validée ou refusée selon la comparaison des résultats.
- 2. Procédé selon la revendication 1, caractérisé en ce que, dans l'étape 104, le terminal utilisateur (11) envoie au serveur applicatif (13) son identifiant unique et demande une vérification d'identité,
- 3. Procédé selon la revendication 1, caractérisé en ce que dans l'étape 104, le serveur applicatif émet à destination du terminal utilisateur une demande de vérification d'identité comportant une deuxième stimulation (challenge2),
- 4. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que :- dans l'étape 101, le serveur client (10) envoie également au serveur applicatif (13) un premier paramètre d'authentification (checksuml), - le procédé comportant également une étape 102 dans laquelle le serveur applicatif (13) recalcule le premier paramètre d'authentification et compare le résultat avec le premier paramètre reçu (checksuml), et, dans le cas favorable, génère la seconde stimulation (challenge2) et calcule son résultat.
- 5. Procédé selon la revendication 4, caractérisé en ce que le premier paramètre d'authentification checksuml est le résultat du hachage non réversible de plusieurs éléments indispensables à identifier la requête.
- 6. Procédé selon l'une quelconque des revendications 1 à 5, caractérisé en ce que l'étape 107 est divisée en deux sous-étapes dans lesquelles : 107a - si le résultat est vérifié comme correct, le serveur applicatif envoie au terminal utilisateur (11) le résultat de la première stimulation challenge 1, 107b - le terminal utilisateur (11) envoie ce résultat de la première stimulation challenge) au serveur client (10).
- 7. Procédé selon la revendication 6, caractérisé en ce qu'il comporte une étape 103 dans laquelle le serveur client (10) envoie au terminal utilisateur (11) notamment un second paramètre d'authentification (checksum2), ce paramètre d'identification étant retourné au serveur client (10) dans l'étape 107b de transmission de la première stimulation challenge1.
- 8. Procédé selon l'une quelconque des revendications 1 à 7, caractérisé en ce que le second utilisateur dispose d'un premier terminal utilisateur (11a) et d'au moins un second terminal utilisateur (11b), et en ce que : - dans l'étape 104, la demande de vérification d'identité est effectuée par un second terminal utilisateur (11b), - dans l'étape 105, le serveur applicatif (13) envoie à ce second terminal utilisateur (11b) une seconde stimulation (challenge2),- dans l'étape 106, ce second terminal utilisateur (11b) résout cette seconde stimulation et renvoie le résultat au serveur applicatif (13).
- 9. Procédé selon les revendications 4 et 8, caractérisé en ce que, à la fin 5 de l'étape 102, le stockage de informations caractérisant la requête d'authentification en cours (le contexte) est effectué sur le premier terminal utilisateur (11a).
- 10. Procédé selon les revendications 6 et 8, caractérisé en ce que l'étape 10 107 est divisée en deux sous-étapes dans lesquelles : 107a - si le résultat est vérifié comme correct, le serveur applicatif envoie au premier terminal utilisateur (11a) le résultat de la première stimulation challengel, 107b - le premier terminal utilisateur (11a) envoie ce résultat de la 15 première stimulation challengel au serveur client (10).
- 11. Procédé selon l'une quelconque des revendications 1 à 10, caractérisé en ce que la première stimulation (challengel) est définie par un nombre pseudo-aléatoire comportant trois éléments : 1/ un numéro définissant 20 l'algorithme choisi parmi une liste prédéfinie, 2/ sait (c'est à dire un élément ajouté au bout du mot (de la clé secrète) à hacher, lors d'une procédure de hachage, pour améliorer la sécurité du nombre généré), 3/ N : nombre d'itérations à effectuer, la réponse à la stimulation consistant à hacher N fois la concaténation d'éléments identifiant le serveur client (10) : website id, et une 25 clé secrète utilisateur : secretKey avec le paramètre sait via l'algorithme choisi.
- 12. Procédé selon la revendication 11, les paramètres sait et itérations sont des valeurs aléatoires et sont déterminés pour chaque demande. 30
- 13. Procédé selon l'une quelconque des revendications 11 à 12, caractérisé en ce que la concaténation d'élément à hacher comprend également un élément identifiant le terminal utilisateur (11) : terminal id,
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1359970A FR3011964B1 (fr) | 2013-10-14 | 2013-10-14 | Procede automatise d'authentification forte multifacteur |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1359970A FR3011964B1 (fr) | 2013-10-14 | 2013-10-14 | Procede automatise d'authentification forte multifacteur |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR3011964A1 true FR3011964A1 (fr) | 2015-04-17 |
| FR3011964B1 FR3011964B1 (fr) | 2017-02-10 |
Family
ID=50289738
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR1359970A Expired - Fee Related FR3011964B1 (fr) | 2013-10-14 | 2013-10-14 | Procede automatise d'authentification forte multifacteur |
Country Status (1)
| Country | Link |
|---|---|
| FR (1) | FR3011964B1 (fr) |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20110276492A1 (en) * | 2000-04-17 | 2011-11-10 | Verisign, Inc. | Authenticated payment |
| WO2012167941A1 (fr) * | 2011-06-09 | 2012-12-13 | Gemalto Sa | Procédé pour valider une transaction entre un utilisateur et un fournisseur de services |
| US20130104213A1 (en) * | 2011-10-23 | 2013-04-25 | Gopal Nandakumar | Authentication method |
-
2013
- 2013-10-14 FR FR1359970A patent/FR3011964B1/fr not_active Expired - Fee Related
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20110276492A1 (en) * | 2000-04-17 | 2011-11-10 | Verisign, Inc. | Authenticated payment |
| WO2012167941A1 (fr) * | 2011-06-09 | 2012-12-13 | Gemalto Sa | Procédé pour valider une transaction entre un utilisateur et un fournisseur de services |
| US20130104213A1 (en) * | 2011-10-23 | 2013-04-25 | Gopal Nandakumar | Authentication method |
Also Published As
| Publication number | Publication date |
|---|---|
| FR3011964B1 (fr) | 2017-02-10 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN108496382B (zh) | 用于个人身份认证的安全信息传输系统和方法 | |
| EP2820795B1 (fr) | Procede de verification d'identite d'un utilisateur d'un terminal communiquant et systeme associe | |
| EP2811708B1 (fr) | Système et méthode pour l'authentification d'un utilisateur | |
| EP2619941B1 (fr) | Procede, serveur et systeme d'authentification d'une personne | |
| EP3174241B1 (fr) | Méthode d'établissement d'une communication sécurisée de bout en bout entre le terminal d'un utilisateur et un objet connecté | |
| FR2919974A1 (fr) | Systeme d'information et procede d'identification par un serveur d'application d'un utilisateur | |
| EP1911194A1 (fr) | Procede de controle de transactions securisees mettant en oeuvre un dispositif physique unique, dispositif physique, systeme, et programme d'ordinateur correspondants | |
| EP3790223A1 (fr) | Génération d'un portefeuille contextuel multi-utilisateur de clés privées et utilisation d'un tel portefeuille | |
| EP3991381B1 (fr) | Procédé et système de génération de clés de chiffrement pour données de transaction ou de connexion | |
| WO2017081208A1 (fr) | Procede de securisation et d'authentification d'une telecommunication | |
| EP2509025A1 (fr) | Procédé d'accès à une ressource protégée d'un dispositif personnel sécurisé | |
| FR3011964A1 (fr) | Procede automatise d'authentification forte multifacteur | |
| EP2016700B1 (fr) | Procede d'activation d'un terminal | |
| EP3673633B1 (fr) | Procédé d'authentification d'un utilisateur auprès d'un serveur d'authentification | |
| WO2004017269A1 (fr) | Procede et systeme de securisation de transmission d'informations sur des reseaux de telecommunication | |
| EP3402157B1 (fr) | Procédé de sécurisation en vue d'un appairage hors bande dans la bande | |
| FR3029318A1 (fr) | Procede et dispositif pour securiser les operations bancaires electroniques | |
| EP3863219A1 (fr) | Procédé et dispositif d'évaluation de correspondance d'ensembles de données structurées protégées par le chiffrement | |
| EP3146745A1 (fr) | Authentification ubiquitaire | |
| FR3146219A1 (fr) | Procédé de délivrance d'une autorisation d'accès pour un individu et procédé de vérification | |
| EP4014466A1 (fr) | Procede de transmission d'une information numerique | |
| WO2012022856A1 (fr) | Procédé d'authentification d' un utilisateur du réseau internet | |
| FR2814622A1 (fr) | Procede de transaction en ligne comportant une pluralite d'etapes d'echanges de messages entre un emetteur, un destinataire et un serveur de validation | |
| FR3027427A1 (fr) | Systeme et procede de securisation et de mise a disposition de courriels | |
| FR2988248A1 (fr) | Procede d'echange securise de donnees entre un serveur et un terminal comprenant des moyens de communication mettant en oeuvre un protocole sms |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 3 |
|
| PLFP | Fee payment |
Year of fee payment: 4 |
|
| PLFP | Fee payment |
Year of fee payment: 5 |
|
| TP | Transmission of property |
Owner name: AURA EQUIPEMENTS, FR Effective date: 20180517 |
|
| PLFP | Fee payment |
Year of fee payment: 6 |
|
| PLFP | Fee payment |
Year of fee payment: 7 |
|
| PLFP | Fee payment |
Year of fee payment: 8 |
|
| ST | Notification of lapse |
Effective date: 20220605 |