WO2010127945A1 - Procede d'authentification - Google Patents

Procede d'authentification Download PDF

Info

Publication number
WO2010127945A1
WO2010127945A1 PCT/EP2010/055248 EP2010055248W WO2010127945A1 WO 2010127945 A1 WO2010127945 A1 WO 2010127945A1 EP 2010055248 W EP2010055248 W EP 2010055248W WO 2010127945 A1 WO2010127945 A1 WO 2010127945A1
Authority
WO
WIPO (PCT)
Prior art keywords
response
user
challenge
terminal
cryptographic device
Prior art date
Application number
PCT/EP2010/055248
Other languages
English (en)
Inventor
David-Olivier Jaquet-Chiffelle
Original Assignee
Haute Ecole Specialisee Bernoise
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 Haute Ecole Specialisee Bernoise filed Critical Haute Ecole Specialisee Bernoise
Priority to EP10716813A priority Critical patent/EP2427846A1/fr
Publication of WO2010127945A1 publication Critical patent/WO2010127945A1/fr
Priority to US13/289,591 priority patent/US8868918B2/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
    • G06Q10/00—Administration; Management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/34—User authentication involving the use of external additional devices, e.g. dongles or smart cards
    • 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/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • H04L63/0838—Network architectures or network communication protocols for network security for authentication of entities using passwords using one-time-passwords
    • 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2103—Challenge-response

Definitions

  • FIG. 1 An example of a personal cryptographic device is illustrated schematically by way of example in FIG. 1. It comprises a challenge introduction system, for example a keyboard 10, or any other data input device. allowing to introduce a challenge in the device, a data restitution system, for example a screen 11, a speaker etc., to display the response to this challenge, and a not shown cryptographic processor to calculate this response.
  • a challenge introduction system for example a keyboard 10, or any other data input device.
  • a data restitution system for example a screen 11, a speaker etc.
  • Such devices are for example often used to authenticate users who want to access a telebanking server or other services or protected areas.
  • the challenge is for example generated in an authentication server and authorization and transmitted through a communication network to a user terminal that displays, for example on a Web page.
  • the user reads this challenge and introduces it himself into his personal cryptographic device that has been given to him by the server operator.
  • the cryptographic device calculates a response to this challenge and returns it to the user, who enters it manually on the keyboard of the terminal.
  • the response is then transmitted to the server via the communications network, and the server releases access to the requested data or services when the response received matches the expected response.
  • User authentication is based on proof of the possession of the personal cryptographic device; a user who does not have this device is unable to determine the expected response to the challenge. Since this device can be stolen or used by an unauthorized user, it is common to protect it with additional local authentication. For example, many devices require the user to enter a password or other proof of knowledge in the possession of the user. Other devices use a biometric verification, for example a fingerprint reader, to authenticate the authorized user and lock the system to all other users.
  • Personal cryptographic devices frequently offer additional functions, for example the possibility of storing other personal information of the user, including passwords and so on.
  • cryptographic devices intended to be used by several users in the same family, or to authenticate the user to several different systems, for example using several different keys.
  • the device cryptographic is generally made available to the user by the authentication and authorization server operator. This operator must indeed know a decryption key, or an algorithm that makes it possible to check if the response to the challenge provided by the device and introduced by the user is correct. Since the device may contain personal data to the user (for example, his password, his biometric fingerprint, data relating to other applications, etc.), the risk exists that a tampered device hides these data in the response. displayed in the challenge.
  • a personal cryptographic device could perfectly modify a few bits of the displayed response to transmit in coded form information for the server. As the user completely ignores the expected response to the challenge, this change can be made without the knowledge of the user. The operator of a server can thus obtain confidential information stored in the user's cryptographic device, without the user being able to suspect that the data he himself introduces into a terminal constitutes a security breach. .
  • the amount of data that can pass through this channel is certainly limited, but it is perfectly possible to transmit sensitive and significant data by changing one or more bits in several successive responses. This risk is in any case sufficient to dissuade some users from using personal cryptographic devices for certain sensitive applications.
  • EP1862948 relates to an IC card (for example a SIM card) which includes an application OTP (One Time Password) and which communicates with a device, for example a mobile phone, to display the OTP generated by the IC card.
  • the IC card includes a client OTP and an interface for communicating with a mobile phone.
  • the phone can connect to a communication network if it has been successfully authenticated through a "communication network key set" stored in a second IC card.
  • This second card also includes an interface for communicating with the phone. Both interfaces are compatible.
  • the use of two cards presents problems when the user does not have a device that allows him to insert both cards at the same time.
  • the application also describes a method of authentication with a server of a bank in which
  • the authentication data which includes the OTP, is sent to the bank's web server.
  • the OTP server checks the authentication data with a HSM ("Hardware security module").
  • An object of the present invention is therefore to provide an authentication method based on the proof of possession of an object that is free from the limitations and risks above.
  • this object is achieved in particular by means of a method enabling a user to verify the operation of a personal cryptographic device, the method comprising the following steps: a user submits an access request in a terminal ; a personal cryptographic device of the user calculates and returns a response to a challenge; instead of being authenticated by transmitting said response (for example to the terminal), the user verifies the operation of the personal cryptographic device when he wishes by asking the terminal to display the expected response to the challenge, this expected response to the challenge is restored by the terminal, the user compares the response returned by the personal cryptographic device with the response returned by the terminal.
  • This solution has the advantage over the prior art of allowing the user to check, when desired, if the response displayed by his personal cryptographic device corresponds to the response expected by the server and if it has not been falsified, for example for the purpose of concealing information.
  • the personal cryptographic device does not know if and when the user will request this verification, it can not with greatity to modify the answer that it restores in answer to a challenge, since the user always has the possibility of checking this answer and to thus discover the manipulation.
  • the terminal and the server obviously ignore the information that the cryptographic device seeks to transmit, and therefore can not simulate this response and display it instead of the correct answer to the challenge.
  • This method thus allows a user to periodically check if the response provided by its cryptographic device corresponds to what the server expects, and therefore to unmask with a very high probability devices that voluntarily or involuntarily provide another response.
  • FIG. 3 illustrates an example of a dialog box displayed by software implementing the method of the invention.
  • Figure 4 schematically illustrates different data streams during authentication according to the method of the invention.
  • Figure 5 schematically illustrates different data streams during the verification of the personal cryptographic device according to the method of the invention.
  • Figure 1 illustrates an example of a personal cryptographic device 1 according to the invention. It includes a keyboard 10 to turn on and off the device, to choose the operating mode and to introduce a challenge.
  • a screen 11 makes it possible to display instructions and the calculated response to a challenge calculated by a cryptographic processor (not shown), for example a processor integrated in the device 1 or in a chip card inserted removably in this device.
  • the cryptographic processor calculates a response to the challenge using a mathematical formula that depends on a secret key stored in the device, and / or using an individual secret algorithm and specific to each device.
  • a challenge can also be introduced into the personal cryptographic device by any data input means other than a keyboard; for example, a challenge can also be introduced using a microphone, a camera, a barcode reader, etc.
  • the personal cryptographic device 1 can also be used for different functions. For example, it can be programmed to check whether a password required of the user is correct, and to release access to the device or to certain applications of the device only if a correct password is entered. In another embodiment, the device 1 further makes it possible to check the user's biometric parameters, for example his fingerprints, before being used. It is also possible to store other user-dependent data in the personal cryptographic device, for example access data relating to other applications, passwords, account or credit card numbers, names or user data, access codes, etc.
  • FIG. 2 schematically illustrates an example of a system in which the method of the invention can be implemented.
  • an authentication and authorization server 4 verifies the identity of a user and decides whether this user should be allowed to access protected resources, for example protected data or applications available to a user. or multiple users 2.
  • the users 2 access these resources by means of a terminal 3, for example a computer, a mobile phone, a PDA, etc., connected to the server 4 via a telecommunication network 30, for example a packet network Internet or Intranet type.
  • the server 4 may for example be a web server, a VPN access controller, an appliance, or any server for controlling access to protected resources.
  • At least some users also have a personal cryptographic device 1, or token, capable of delivering responses to access resources protected by the server 4.
  • This cryptographic device 1 is typically made available to users by the operator of the authentication and authorization server 4 or of a protected application on this server.
  • the server 4 gives access to the protected resources only to the users 2 of terminals 3 capable of providing the expected answers.
  • the method of the invention can also be implemented in physical access control systems, for example access control systems to protected areas.
  • step 100 the user 2 enters an access request into his terminal. protected resources. This request can for example be introduced by typing or selecting a URL in a browser, or by any appropriate command in a graphical user interface or via a voice server.
  • step 101 the access request is then transmitted via a communication network 30 to an authentication and authorization server 4 responsible for authenticating and authorizing the users wishing to access protected resources.
  • the challenge (or expected response to a given challenge) may depend on a user identification performed previously, for example by asking the user to enter his user identity (USER ID), or by checking his email address (eg his IP address, Mac address, CLI caller number, etc.).
  • the transmission of the challenge can be encrypted and / or signed electronically.
  • the challenge received by the terminal is displayed or returned to the user 2 during step 103.
  • the challenge is displayed in a web window or in a dialog box 3000 such as that illustrated by way of example in Figure 3; in this example, the challenge 1233-4129 is displayed in an area 301 to the user "USER_X" (zone 300), and the dialog box allows the user to enter an answer to this challenge in the field of data entry 302.
  • the challenge can also be implicit, and correspond for example to the current time, or to a sequence of numbers or single-use codes and known both of the device 1 and the server 4.
  • the user 2 introduced during the step 104 this challenge in his personal cryptographic device 1 using the introduction means, for example by typing this challenge on the keyboard of the device .
  • the challenge can also be transmitted directly from the terminal to the cryptographic device, for example through an acoustic coupling involving a speaker in the terminal and a microphone in the cryptographic device 1, or by means of an optical coupling implementing an image sensor on the device 1 to capture a fixed or animated image, a barcode or a watermark returned by the terminal.
  • Other challenge introduction means from the terminal to the device can be envisaged.
  • the transmission of the challenge to the cryptographic device does not necessarily pass by the user. On the other hand, the transmission of the response from the device involves the user.
  • the cryptographic device 1 responds to the terminal during step 105 by displaying or returning the response to this challenge calculated by the cryptographic processor.
  • the display of the response may depend on a password or biometric parameters to block access to the cryptographic device 1 to all users other than the authorized user 2.
  • step 106 this response in the field 302 of the dialog box displayed on his terminal, or introduced this response in another way.
  • the response is then transmitted to the server 4 during the step 107, for example when the user selects the "connect" button on the graphical interface.
  • this transmission can be encrypted and / or electronically signed. It can be done via the transmission channel previously used to transmit the access request and / or the challenge, or via another communication network.
  • the server 4 checks in step 107 if the response received is the expected response, for example by comparing with the expected response, or using another cryptographic operation.
  • the data or other resources sought are transmitted during step 108 to the terminal 3 which returns them to the user 2.
  • the user 2 has no prior art in the art to ensure that the code returned by the cryptographic device 1 during step 105 corresponds only to the response to the expected challenge. , and that this code has not been modified to discreetly transmit confidential information or for another purpose. A fraudulent operator could thus distribute to the users cryptographic devices manipulated so as to modify one or more bits of the displayed responses according to the password of the user, or other confidential data.
  • this modification must be made in such a way as to allow a verification of the response introduced, and requires that this response contain redundant information, or in any case that several responses to the same challenge are accepted.
  • the method of the invention allows the user to check if the responses to the challenges provided by the personal cryptographic device 1 correspond to the expected answers and if they have not been manipulated.
  • the method allows the user to require the access server 4 to provide the expected response to the challenge, or in any case information to verify this response.
  • the user can select the button 303 (or perform another manipulation) to ask the server 4 to display the expected response in box 304. This operation interrupts the authentication process and therefore the user must not enter a response in the field 302.
  • FIG. 5 illustrates, by way of example, the data flow during this verification. Steps 100 to 105 are identical to the corresponding steps described in relation to FIG. 4.
  • user 2 however gives up providing the authentication and authorization server 4 with the response that the cryptographic device staff 1 has just provided him; instead, the user enters in his terminal 3 a request to display the response to the challenge, for example by clicking the button 303 on its graphical interface.
  • This request is transmitted to the server 4 during the step 111, which responds during step 112 by transmitting the expected response, or sufficient information to verify a response.
  • This information is then returned to the user during the step 113.
  • the user 2 can then use this response, for example the answer to the challenge expected by the authentication and authorization server 4, to check whether it corresponds to the response given by the cryptographic device 1 and if the latter has not been manipulated.
  • the method may advantageously be automatically interrupted following M consecutive requests to display the response by the terminal, M being a positive integer. This avoids the risk of a user trying to guess the algorithm or key needed to calculate the answer to a challenge, based on the observation of a large number of challenge-response pairs.
  • the number M may be predefined, or advantageously randomly drawn according to a Poisson law for example.
  • the invention also relates to a computer system (for example a server 4 or a computer) comprising means for generating a challenge, means for verifying a response to the audit challenge and to release access in case of correct response, and means for remotely transmitting the expected response to said challenge in response to a user request.
  • a computer system for example a server 4 or a computer
  • the invention also relates to a computer system (for example a server 4 or a computer) comprising means for generating a challenge, means for verifying a response to the audit challenge and to release access in case of correct response, and means for remotely transmitting the expected response to said challenge in response to a user request.

Abstract

Procédé permettant à un utilisateur de vérifier le fonctionnement d'un dispositif cryptographique personnel, comportant les étapes suivantes : a) un utilisateur (2) introduit une demande d'accès dans un terminal (3) (100), d) un dispositif cryptographique personnel (1) de l'utilisateur (2) calcule et affiche une réponse (105), g) l'utilisateur (2) vérifie le fonctionnement du dispositif cryptographique personnel (1) en demandant au terminal (3) d'afficher la réponse attendue au challenge (110), i) le terminal (3) affiche la réponse attendue au challenge (113), j) l'utilisateur (2) compare la réponse affichée par le dispositif cryptographique personnel avec la réponse affichée par le terminal.

Description

Procédé d'authentif ication
Domaine technique
[0001] La présente invention concerne un procédé d'authentification d'utilisateur à l'aide d'un dispositif cryptographique personnel.
Etat de la technique
[0002] On connaît dans l'art antérieur des procédés d'authentification d'utilisateurs basés sur la preuve de la possession d'un dispositif, par exemple d'une clé, d'une carte à puce ou d'un dispositif cryptographique personnel. Seul un utilisateur possédant ce dispositif est authentifié et peut accéder à des ressources ou à une zone protégée.
[0003] Dans un mode de réalisation, le dispositif est constitué par un dispositif cryptographique personnel (security token) capable de calculer et d'afficher une réponse à un challenge. La réponse au challenge est soit calculée à l'aide d'un algorithme confidentiel, ou basée sur une clé confidentielle mémorisée dans le dispositif. Les éléments confidentiels ne peuvent pas être déterminés à partir des couples de challenges et de réponses introduits et affichés, ni en ouvrant le dispositif. Le dispositif est ainsi pratiquement impossible à falsifier ou à dupliquer.
[0004] Un exemple de dispositif cryptographique personnel est illustré schématiquement à titre d'exemple sur la figure 1. Il comporte un système d'introduction de challenge, par exemple un clavier 10, ou n'importe quel autre dispositif d'introduction de données permettant d'introduire un challenge dans le dispositif, un système de restitution de données, par exemple un écran 11, un haut-parleur etc., pour afficher la réponse à ce challenge, et un processeur cryptographique non représenté pour calculer cette réponse. De tels dispositifs sont par exemple souvent utilisés pour authentifier des utilisateurs qui souhaitent accéder à un serveur de télébanking ou à d'autres services ou zones protégés.
[0005] Dans un exemple d'application, le challenge est par exemple généré dans un serveur d'authentification et d'autorisation et transmis au travers d'un réseau de communication à un terminal d'utilisateur qui l'affiche, par exemple sur une page web. L'utilisateur lit ce challenge et l'introduit lui-même dans son dispositif cryptographique personnel qui lui a été remis par l'opérateur du serveur. Le dispositif cryptographique calcule une réponse à ce challenge et la restitue à l'utilisateur, qui l'introduit manuellement sur le clavier du terminal. La réponse est ensuite transmise au serveur via le réseau de communications, et le serveur libère l'accès aux données ou services demandés lorsque la réponse reçue correspond à la réponse attendue.
[0006] L'authentification d'utilisateur est basée sur la preuve de la possession du dispositif cryptographique personnel ; un utilisateur qui ne possède pas ce dispositif est incapable de déterminer la réponse attendue au challenge. Comme ce dispositif peut être volé ou employé par un utilisateur non autorisé, il est fréquent de le protéger avec un moyen d'authentification local additionnel. Par exemple, de nombreux dispositifs demandent à l'utilisateur d'introduire un mot de passe ou une autre preuve de connaissance en possession de l'utilisateur. D'autres dispositifs utilisent une vérification biométrique, par exemple un système de lecture d'empreinte digitale, pour authentifier l'utilisateur autorisé et verrouiller le système à tous les autres utilisateurs.
[0007] Les dispositifs cryptographiques personnels offrent fréquemment des fonctions additionnelles, par exemple la possibilité de stocker d'autres informations personnelles de l'utilisateur, y compris des mots de passe etc. Il existe aussi des dispositifs cryptographiques destinés à être utilisés par plusieurs utilisateurs dans une même famille, ou pour authentifier l'utilisateur vers plusieurs systèmes différents, par exemple à l'aide de plusieurs clés différentes. Comme mentionné plus haut, le dispositif cryptographique est généralement mis à disposition de l'utilisateur par l'opérateur du serveur d'authentification et d'autorisation. Cet opérateur doit en effet connaître une clé de décryptage, ou un algorithme qui permet de vérifier si la réponse au challenge fournie par le dispositif et introduite par l'utilisateur est correcte. Comme le dispositif peut contenir des données personnelles à l'utilisateur (par exemple son mot de passe, son empreinte biométrique, des données relatives à d'autres applications etc.), le risque existe qu'un dispositif trafiqué dissimule ces données dans la réponse affichée au challenge.
[0008] Par exemple, un dispositif cryptographique personnel pourrait parfaitement modifier quelques bits de la réponse affichée afin de transmettre sous forme codée une information destinée au serveur. Comme l'utilisateur ignore complètement la réponse attendue au challenge, cette modification peut se faire à l'insu de l'utilisateur. L'opérateur d'un serveur peut ainsi obtenir des informations confidentielles stockées dans le dispositif cryptographique de l'utilisateur, sans que l'utilisateur ne puisse se douter que les données qu'il introduit lui-même dans un terminal constituent une brèche de sécurité.
[0009] La quantité de données qui peut transiter au travers de ce canal est certes limitée, mais il est parfaitement possible de transmettre des données sensibles et significatives en modifiant un ou plusieurs bits lors de plusieurs réponses successives. Ce risque est en tous les cas suffisant pour dissuader certains utilisateurs d'employer des dispositifs cryptographiques personnels pour certaines applications sensibles.
[0010] EP1862948 concerne une carte IC (par exemple une carte SIM) qui comprend une application OTP (One Time Password) et qui communique avec un dispositif, par exemple un téléphone portable, pour afficher la OTP générée par la carte IC. La carte IC comprend un OTP client et une interface pour communiquer avec un téléphone mobile. Le téléphone peut se connecter à un réseau de communication s'il a été authentiqué avec succès à travers un « communication network key set » mémorisé dans une seconde carte IC. Cette seconde carte comprend aussi une interface pour communiquer avec le téléphone. Les deux interfaces sont compatibles. Cependant l'utilisation de deux cartes présente des problèmes quand l'utilisateur n'a pas un dispositif qui lui permet d'insérer les deux cartes en même temps.
[0011] La demande décrit aussi un procédé d'authentification avec un serveur d'une banque dans lequel
- Une « OTP-SIM applet » dans la carte produit la OTP et l'affiche sur le display du dispositif. - L'utilisateur tape la OTP dans une fenêtre web générée par un site web du web server qui requit l'authentification.
- Les données d'authentification, qui comprennent la OTP, sont envoyées au web server de la banque.
- Le OTP server vérifie les donnés d'authentification avec un HSM (« Hardware security module »).
[0012] Ce document ne contient pas des moyens ou un procédé pour permettre de vérifier si la réponse affichée par le dispositif n'a pas été falsifiée, par exemple dans le but de dissimuler une information. Il n'y a aucune possibilité de s'assurer que le code restitué par le dispositif n'a pas été modifié pour transmettre discrètement des informations confidentielles ou dans un autre but.
[0013] Le document extrait du site Internet www.sas-
UJ< JIgIZf^ décrit un dispositif « RSA SecurlD
Aunthenticator » qui fonctionne comme une carte ATM et qui, utilisé avec un « RSA Authentication Manager », permet à un utilisateur de s'identifier avec deux facteurs, c'est-à-dire quelque chose que il connaît et quelque chose qu'il possède. Chaque utilisateur a un « RSA SecurlD Aunthenticator » qui génère un « one-time-use code ». L'utilisateur introduit dans le dispositif ce code avec un PIN. Encore une fois ce document ne contient pas des moyens ou un procédé pour permettre à l'utilisateur de vérifier, lorsqu'il le désire, si la réponse affichée par son dispositif n'a pas été falsifiée, par exemple dans le but de dissimuler une information. De même, il n'y a aucune possibilité de s'assurer que le code restitué par le dispositif n'a pas été modifié pour transmettre discrètement des informations confidentielles ou dans un autre but.
Bref résumé de l'invention
[0014] Un but de la présente invention est donc de proposer un procédé d'authentification basé sur la preuve de la possession d'un objet qui soit exempt des limitations et des risques ci-dessus.
[0015] Selon l'invention, ce but est atteint notamment au moyen d'un procédé permettant à un utilisateur de vérifier le fonctionnement d'un dispositif cryptographique personnel, le procédé comportant les étapes suivantes : un utilisateur introduit une demande d'accès dans un terminal ; un dispositif cryptographique personnel de l'utilisateur calcule et restitue une réponse à un challenge ; au lieu de s'authentifier en transmettant ladite réponse (par exemple au terminal), l'utilisateur vérifie lorsqu'il le désire le fonctionnement du dispositif cryptographique personnel en demandant au terminal d'afficher la réponse attendue au challenge, cette réponse attendue au challenge est restituée par le terminal, l'utilisateur compare la réponse restituée par le dispositif cryptographique personnel avec la réponse restituée par le terminal.
[0016] Cette solution présente notamment l'avantage par rapport à l'art antérieur de permettre à l'utilisateur de vérifier, lorsqu'il le désire, si la réponse affichée par son dispositif cryptographique personnel correspond à la réponse attendue par le serveur et si elle n'a pas été falsifiée, par exemple dans le but de dissimuler une information.
[0017] Comme le dispositif cryptographique personnel ne sait pas si et quand l'utilisateur va demander cette vérification, il ne peut pas impunément modifier la réponse qu'il restitue en réponse à un challenge, puisque l'utilisateur a toujours la possibilité de vérifier cette réponse et de découvrir ainsi la manipulation.
[0018] Le terminal et le serveur ignorent bien entendu l'information que le dispositif cryptographique cherche à transmettre, et ne peuvent donc pas simuler cette réponse et l'afficher à la place de la réponse correcte au challenge.
[0019] Ce procédé permet ainsi à un utilisateur de vérifier périodiquement si la réponse fournie par son dispositif cryptographique correspond à ce que le serveur attend, et donc de démasquer avec une très forte probabilité les dispositifs qui fournissent volontairement ou involontairement une autre réponse.
[0020] La sécurité est augmentée même si l'utilisateur ne vérifie que rarement, ou jamais, la réponse restituée par un dispositif cryptographique ; il suffit que la possibilité de vérification existe pour dissuader les fabricants ou distributeurs de dispositifs cryptographiques de tenter une manipulation.
Brève description des figures
[0021] Des exemples de mise en œuvre de l'invention sont indiqués dans la description illustrée par les figures annexées dans lesquelles :
[0022] La figure 1 déjà décrite illustre de manière schématique un dispositif cryptographique personnel pouvant être utilisé dans le procédé de l'invention.
[0023] La figure 2 illustre de manière schématique un système mettant en œuvre le procédé de l'invention. [0024] La figure 3 illustre un exemple de boîte de dialogue affichée par un logiciel mettant en œuvre le procédé de l'invention.
[0025] La figure 4 illustre de manière schématique différents flux de données lors de l'authentification selon le procédé de l'invention.
[0026] La figure 5 illustre de manière schématique différents flux de données lors de la vérification du dispositif cryptographique personnel selon le procédé de l'invention.
Exemple(s) de mode de réalisation de l'invention
[0027] La figure 1 illustre un exemple de dispositif cryptographique personnel 1 selon l'invention. Il comporte un clavier 10 permettant d'allumer et d'éteindre le dispositif, de choisir le mode de fonctionnement et d'introduire un challenge. Un écran 11 permet d'afficher des instructions et la réponse calculée à un challenge calculée par un processeur cryptographique (non illustré), par exemple un processeur intégré dans le dispositif 1 ou dans une carte à puce insérée de manière amovible dans ce dispositif. Le processeur cryptographique calcule une réponse au challenge à l'aide d'une formule mathématique qui dépend d'une clé secrète mémorisée dans le dispositif, et/ou à l'aide d'un algorithme secret individuel et propre à chaque dispositif.
[0028] Un challenge peut aussi être introduit dans le dispositif cryptographique personnel par des moyens d'introduction de données quelconques autres qu'un clavier ; par exemple, un challenge peut aussi être introduit à l'aide d'un microphone, d'une caméra, d'un lecteur de code-barre, etc.
[0029] Dans une variante, la réponse affichée par le dispositif 1 dépend également de l'heure en cours ; la réponse à un même challenge ne sera donc pas toujours la même, mais dépendra d'une horloge interne, qui doit être au moins approximativement synchronisée avec une horloge d'un serveur d'authentification et d'autorisation.
[0030] II est également possible d'utiliser cette horloge interne, ou une autre valeur unique connue à la fois du dispositif 1 et d'un serveur à distance, en tant que challenge. Par exemple, le dispositif cryptographique 1 et le serveur peuvent convenir d'une liste de codes à usage unique. Dans ce cas, le dispositif cryptographique personnel 1 peut être dépourvu de clavier 10 et l'introduction d'un challenge se résume à allumer le dispositif afin qu'il affiche une réponse dépendant uniquement de l'heure en cours, ou d'une autre valeur à usage unique.
[0031] Le dispositif cryptographique personnel 1 peut en outre être utilisé pour différentes fonctions. Par exemple, il peut être programmé pour vérifier si un mot de passe exigé de l'utilisateur est correct, et pour libérer l'accès au dispositif ou à certaines applications du dispositif uniquement en cas d'introduction d'un mot de passe correct. Dans un autre mode de réalisation, le dispositif 1 permet en outre de vérifier des paramètres biométriques de l'utilisateur, par exemple ses empreintes digitales, avant d'être utilisé. Il est également possible de stocker d'autres données dépendant de l'utilisateur dans le dispositif cryptographique personnel, par exemple des données d'accès relatives à d'autres applications, des mots de passe, des numéros de compte ou de carte de crédits, des noms ou données d'utilisateur, des codes d'accès, etc.
[0032] La figure 2 illustre de manière schématique un exemple de système dans lequel le procédé de l'invention peut être mis en œuvre. Dans cet exemple, un serveur d'authentification et d'autorisation 4 vérifie l'identité d'un utilisateur et décide si cet utilisateur doit être autorisé à accéder à des ressources protégées, par exemple des données ou des applications protégées à disposition d'un ou plusieurs utilisateurs 2. Les utilisateurs 2 accèdent à ces ressources au moyen d'un terminal 3, par exemple un ordinateur, un téléphone mobile, un PDA etc, relié au serveur 4 via un réseau de télécommunication 30, par exemple un réseau à paquets de type Internet ou Intranet. Le serveur 4 peut par exemple être un serveur web, un contrôleur d'accès VPN, une appliance, ou n'importe quel serveur permettant de contrôler un accès à des ressources protégées.
[0033] Au moins certains utilisateurs disposent en outre d'un dispositif cryptographique personnel 1, ou token, capable de délivrer des réponses permettant d'accéder aux ressources protégées par le serveur 4. Ce dispositif cryptographique 1 est typiquement mis à disposition des utilisateurs par l'opérateur du serveur d'authentification et d'autorisation 4 ou d'une application protégée sur ce serveur. Le serveur 4 donne l'accès aux ressources protégées uniquement aux utilisateurs 2 de terminaux 3 capables de fournir les réponses attendues.
[0034] Le procédé de l'invention peut aussi être mis en œuvre dans des systèmes de contrôle d'accès physiques, par exemple des systèmes de contrôle d'accès à des zones protégées.
[0035] Le flux de données lors du procédé d'authentification et d'autorisation est illustré à titre d'exemple sur la figure 4. Au cours de l'étape 100, l'utilisateur 2 introduit dans son terminal une demande d'accès à des ressources protégées. Cette demande peut par exemple être introduite en tapant ou sélectionnant une URL dans un navigateur, ou par n'importe quelle commande appropriée dans une interface graphique d'utilisateur ou par l'intermédiaire d'un serveur vocal. Au cours de l'étape 101, la demande d'accès est ensuite transmise via un réseau de communication 30 à un serveur d'authentification et d'autorisation 4 responsable d'authentifier et d'autoriser les utilisateurs souhaitant accéder à des ressources protégées.
[0036] Dans un autre mode de réalisation, le contrôle d'accès est effectué par une application appropriée directement dans le terminal 3, sans qu'aucune requête ne soit transmise à un serveur à distance. [0037] Le serveur d'authentification et d'autorisation 4 répond à cette demande d'accès en envoyant au terminal 3 un challenge (étape 102). Ce challenge peut être transmis via le réseau de communication déjà utilisé pour transmettre la demande d'accès, ou au travers d'un réseau différent.
[0038] Le challenge (ou la réponse attendue à un challenge donnée) peut dépendre d'une identification d'utilisateur effectuée préalablement, par exemple en demandant à l'utilisateur d'introduire son identité d'utilisateur (USER ID), ou en vérifiant son adresse électronique (par exemple son adresse IP, son adresse Mac, son numéro d'appelant CLI, etc). La transmission du challenge peut être encryptée et/ou signée électroniquement.
[0039] Le challenge reçu par le terminal est affiché ou restitué à l'utilisateur 2 au cours de l'étape 103. Dans un mode de réalisation, le challenge est affiché dans une fenêtre web ou dans une boîte de dialogue 3000 telle que celle illustrée à titre d'exemple sur la figure 3 ; dans cet exemple, le challenge 1233-4129 est affiché dans une zone 301 à l'utilisateur « USER_X » (zone 300), et la boîte de dialogue permet à l'utilisateur d'introduire une réponse à ce challenge dans le champ d'entrée de données 302.
[0040] Le challenge peut aussi être implicite, et correspondre par exemple à l'heure en cours, ou à une suite de nombres ou de codes à usage unique et connue à la fois du dispositif 1 et du serveur 4.
[0041] Afin de s'authentifier, l'utilisateur 2 introduit au cours de l'étape 104 ce challenge dans son dispositif cryptographique personnel 1 à l'aide des moyens d'introduction, par exemple en tapant ce challenge sur le clavier du dispositif.
[0042] Le challenge peut aussi être transmis directement depuis le terminal au dispositif cryptographique, par exemple au travers d'un couplage acoustique impliquant un haut parleur dans le terminal et un microphone dans le dispositif cryptographique 1, ou au moyen d'un couplage optique mettant en œuvre un capteur d'images sur le dispositif 1 pour saisir une image fixe ou animée, un code barre ou un watermark restitué par le terminal. D'autres moyens d'introduction de challenge depuis le terminal au dispositif peuvent être envisagés. La transmission du challenge au dispositif cryptographique ne passe donc pas nécessairement par l'utilisateur. En revanche, la transmission de la réponse depuis le dispositif implique l'utilisateur.
[0043] Le dispositif cryptographique 1 répond au terminal au cours de l'étape 105 en affichant ou restituant la réponse à ce challenge calculée par le processeur cryptographique. Comme mentionné plus haut, l'affichage de la réponse peut dépendre d'un mot de passe ou de paramètres biométriques permettant de bloquer l'accès au dispositif cryptographique 1 à tous les utilisateurs autres que l'utilisateur autorisé 2.
[0044] L'utilisateur introduit au cours de l'étape 106 cette réponse dans le champ 302 de la boîte de dialogue affichée sur son terminal, ou introduit cette réponse d'une autre manière. La réponse est ensuite transmise au serveur 4 au cours de l'étape 107, par exemple lorsque l'utilisateur sélectionne le bouton « connect » sur l'interface graphique. A nouveau, cette transmission peut être encryptée et/ou signée électroniquement. Elle peut être effectuée via le canal de transmission employé auparavant pour transmettre la demande d'accès et/ou le challenge, ou via un autre réseau de communication.
[0045] Le serveur 4 vérifie ensuite au cours de l'étape 107 si la réponse reçue est bien la réponse attendue, par exemple en comparant avec la réponse attendue, ou à l'aide d'une autre opération cryptographique. Lorsque la réponse est correcte, les données ou autres ressources recherchées sont transmises au cours de l'étape 108 au terminal 3 qui les restitue à l'utilisateur 2. [0046] Comme mentionné plus haut, l'utilisateur 2 n'a dans l'art antérieur aucune possibilité de s'assurer que le code restitué par le dispositif cryptographique 1 au cours de l'étape 105 correspond uniquement à la réponse au challenge attendue, et que ce code n'a pas été modifié pour transmettre discrètement des informations confidentielles ou dans un autre but. Un opérateur frauduleux pourrait ainsi distribuer aux utilisateurs des dispositifs cryptographiques manipulés de manière à modifier un ou plusieurs bits des réponses affichées en fonction du mot de passe de l'utilisateur, ou d'autres données confidentielles. Bien entendu, cette modification doit être effectuée de manière à permettre malgré tout une vérification de la réponse introduite, et nécessite que cette réponse contienne des informations redondantes, ou en tout cas que plusieurs réponses à un même challenge soient acceptées.
[0047] Afin de limiter ce risque, et de rendre les manipulations détectables, le procédé de l'invention permet à l'utilisateur de vérifier si les réponses aux challenges fournies par le dispositif cryptographique personnelles 1 correspondent aux réponses attendues et si elles n'ont pas été manipulées. Dans ce but, le procédé permet à l'utilisateur d'exiger du serveur d'accès 4 qu'il fournisse la réponse prévue au challenge, ou en tout cas des informations permettant de vérifier cette réponse. Dans la boîte de dialogue affichée à titre d'exemple sur la figure 3, l'utilisateur peut sélectionner le bouton 303 (ou effectuer une autre manipulation) pour demander au serveur 4 de lui afficher dans la zone 304 la réponse attendue. Cette opération interrompt le procédé d'authentification et l'utilisateur ne doit donc pas introduire de réponse dans le champ 302.
[0048] La figure 5 illustre à titre d'exemple le flux de données au cours de cette vérification. Les étapes 100 à 105 sont identiques aux étapes correspondantes décrites en relation avec la figure 4. Au cours de l'étape 110, l'utilisateur 2 renonce cependant à fournir au serveur d'authentification et d'autorisation 4 la réponse que le dispositif cryptographique personnel 1 vient de lui fournir ; au lieu de cela, l'utilisateur introduit dans son terminal 3 une demande d'afficher la réponse au challenge, par exemple en cliquant le bouton 303 sur son interface graphique.
[0049] Cette demande est transmise au serveur 4 au cours de l'étape 111 , qui y répond au cours de l'étape 112 en transmettant la réponse attendue, ou des informations suffisantes pour vérifier une réponse. Ces informations sont ensuite restituées à l'utilisateur au cours de l'étape 113. L'utilisateur 2 peut ensuite utiliser cette réponse, par exemple la réponse au challenge attendue par le serveur d'authentification et d'autorisation 4, pour vérifier si elle correspond à la réponse donnée par le dispositif cryptographique 1 et si cette dernière n'a pas été manipulée.
[0050] Si la réponse affichée par le dispositif 1 est correcte, et si l'utilisateur souhaite s'authentifier et se connecter au serveur 4, il doit recommencer le processus et demander au serveur de lui fournir un nouveau challenge. Le nombre entier positif N de tentatives d'accès au serveur est de préférence limité afin de réduire le risque d'attaque par « force brute » ; cependant, l'introduction d'une demande de challenge puis d'une demande de réponse à ce challenge ne compte de préférence pas comme une tentative d'accès et ne réduit donc pas le nombre de tentatives d'accès ultérieurs autorisés.
[0051] Le procédé peut avantageusement être automatiquement interrompu suite à M demandes consécutives de faire afficher la réponse par le terminal, M étant un nombre entier positif. Ceci permet d'éviter le risque qu'un utilisateur ne tente de deviner l'algorithme ou la clé nécessaire pour calculer la réponse à un challenge, en se basant sur l'observation d'un nombre important de couples challenges - réponses. Le nombre M peut être prédéfini, ou avantageusement tiré au hasard selon une loi de Poisson par exemple.
[0052] L'invention concerne également un système informatique (par exemple un serveur 4 ou un ordinateur) comportant des moyens pour générer un challenge, des moyens pour vérifier une réponse audit challenge et pour libérer un accès en cas de réponse correcte, ainsi que des moyens pour transmettre à distance la réponse attendue audit challenge en réponse à une demande d'utilisateur. Ces différents moyens sont avantageusement constituées par des supports informatiques contenant des portions de code informatiques exécutables par un système de traitement de données afin de lui faire exécuter le procédé décrit ci-dessus lorsque ce code est exécuté.

Claims

Revendications
1. Procédé comportant les étapes suivantes : a) un utilisateur (2) introduit une demande d'accès dans un terminal (3) (100), d) un dispositif cryptographique personnel (1) de l'utilisateur (2) calcule et restitue une réponse (105) à un challenge, e) ladite réponse est transmise par l'utilisateur (2), f) une vérification de la réponse est effectuée (107), l'utilisateur (2) étant authentifié uniquement si la réponse introduite est correcte, caractérisé en ce que l'utilisateur (2) vérifie le fonctionnement du dispositif cryptographique personnel (1) en remplaçant lorsqu'il le désire les étapes e) à f) par les étapes h) à j) suivantes : h) l'utilisateur (2) demande audit terminal (3) d'afficher la réponse attendue audit challenge (110), i) le terminal (3) restitue la réponse attendue au challenge (113), j) l'utilisateur (2) compare la réponse restituée par le dispositif cryptographique personnel avec la réponse restituée par le terminal (3).
2. Le procédé de la revendication 1, dans lequel l'exécution des étapes h) à j) ne conduit pas à l'authentification de l'utilisateur.
3. Le procédé de la revendication 2, dans lequel les étapes d) à f) sont répétées à la suite des étapes h) à j), afin d'authentifier l'utilisateur (2) avec un nouveau challenge et une nouvelle réponse.
4. Le procédé de l'une des revendications 1 à 3, dans lequel ladite réponse est une réponse à un challenge restitué (103) par ledit terminal (3) suite à ladite demande d'accès, ledit challenge étant ensuite transmis audit dispositif cryptographique personnel (1), ladite réponse calculée par le dispositif cryptographique personnel dépendant dudit challenge.
5. Le procédé de l'une des revendications 1 à 4, dans lequel ladite réponse dépend de l'heure en cours.
6. Le procédé de l'une des revendications 1 à 5, dans lequel le terminal (3) restitue un nouveau challenge lorsqu'une réponse incorrecte a été transmise au cours de l'étape e), et interrompt le procédé d'authentification suite à N introductions consécutives de réponses erronées, N étant un nombre entier positif.
7. Le procédé de l'une des revendications 1 à 6, dans lequel le procédé est automatiquement interrompu suite à M demandes consécutives de faire afficher la réponse par le terminal (3), M étant un nombre entier positif.
8. Le procédé de l'une des revendications 1 à 7, dans lequel ledit dispositif cryptographique personnel (1) demande à l'utilisateur de s'authentifier avec un mot de passe ou une donnée biométrique, et refuse de restituer une dite réponse si l'authentification a échoué.
9. Le procédé de l'une des revendications 4 à 8, dans lequel ledit terminal (3) effectue une identification d'utilisateur, ledit challenge et/ou ladite réponse dépendant de ladite identification.
10. Système informatique (4) comportant : des moyens pour générer un challenge, des moyens pour vérifier une réponse audit challenge, et pour libérer un accès en cas de réponse correcte, des moyens pour transmettre à distance la réponse attendue audit challenge en réponse à une demande d'utilisateur.
1 1. Le système de la revendication 10, constitué par un serveur informatique (4) connecté à un réseau de communication (30), ledit serveur (4) étant arrangé pour envoyer ledit challenge et ladite réponse attendue à travers ledit réseau de communication (30), et pour recevoir ladite réponse.
12. Support de données informatique contenant un programme informatique arrangé pour permettre à un serveur (4) exécutant ledit programme de générer un challenge, de vérifier une réponse d'utilisateur (2) audit challenge, de libérer un accès en cas de réponse correcte, et d'afficher la réponse attendue audit challenge en réponse à une demande d'utilisateur (2).
PCT/EP2010/055248 2009-05-07 2010-04-21 Procede d'authentification WO2010127945A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP10716813A EP2427846A1 (fr) 2009-05-07 2010-04-21 Procede d'authentification
US13/289,591 US8868918B2 (en) 2009-05-07 2011-11-04 Authentication method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CH711/09 2009-05-07
CH00711/09A CH701050A1 (fr) 2009-05-07 2009-05-07 Procédé d'authentification.

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US13/289,591 Continuation US8868918B2 (en) 2009-05-07 2011-11-04 Authentication method

Publications (1)

Publication Number Publication Date
WO2010127945A1 true WO2010127945A1 (fr) 2010-11-11

Family

ID=41057548

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2010/055248 WO2010127945A1 (fr) 2009-05-07 2010-04-21 Procede d'authentification

Country Status (4)

Country Link
US (1) US8868918B2 (fr)
EP (1) EP2427846A1 (fr)
CH (1) CH701050A1 (fr)
WO (1) WO2010127945A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2505678A (en) * 2012-09-06 2014-03-12 Visa Europe Ltd Authenticating and validating an access request
CN116137574A (zh) * 2021-11-18 2023-05-19 北京小米移动软件有限公司 外设认证方法、装置电子设备及存储介质

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9172546B2 (en) * 2012-01-25 2015-10-27 Cisco Technology, Inc. Network mediated multi-device shared authentication
US9654466B1 (en) * 2012-05-29 2017-05-16 Citigroup Technology, Inc. Methods and systems for electronic transactions using dynamic password authentication
DE102013102092B4 (de) * 2013-03-04 2015-08-20 Christian Palm Verfahren und Vorrichtung zum Authentifizieren von Personen
CN105095705B (zh) * 2015-05-19 2018-04-10 努比亚技术有限公司 一种信息处理方法及装置
US10805291B2 (en) * 2015-09-11 2020-10-13 Comcast Cable Communications, Llc Embedded authentication in a service provider network
JP6436363B2 (ja) * 2016-11-11 2018-12-12 本田技研工業株式会社 通信装置、通信システム、通信方法、及びプログラム
US10728230B2 (en) * 2018-07-05 2020-07-28 Dell Products L.P. Proximity-based authorization for encryption and decryption services
JP7322732B2 (ja) * 2020-02-03 2023-08-08 トヨタ自動車株式会社 認証システム

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050033995A1 (en) * 2003-08-08 2005-02-10 Paul Lin System and method for utilizing information in publicly broadcast signals for shared secret purposes
GB2434663A (en) * 2006-01-13 2007-08-01 Deepnet Technologies Ltd Mutual authentication using a pair of one-time passwords
EP1862948A1 (fr) 2006-06-01 2007-12-05 Axalto SA Carte CI avec client OTP
US20080034216A1 (en) * 2006-08-03 2008-02-07 Eric Chun Wah Law Mutual authentication and secure channel establishment between two parties using consecutive one-time passwords
US20080168544A1 (en) * 2007-01-05 2008-07-10 Ebay Inc. Token device re-synchronization through a network solution

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5668876A (en) * 1994-06-24 1997-09-16 Telefonaktiebolaget Lm Ericsson User authentication method and apparatus
US7194765B2 (en) * 2002-06-12 2007-03-20 Telefonaktiebolaget Lm Ericsson (Publ) Challenge-response user authentication
US8195940B2 (en) * 2002-04-05 2012-06-05 Qualcomm Incorporated Key updates in a mobile wireless system
JP4311174B2 (ja) * 2003-11-21 2009-08-12 日本電気株式会社 認証方法、移動体無線通信システム、移動端末、認証側装置、認証サーバ、認証代理スイッチ及びプログラム
EP1987627B1 (fr) * 2006-02-03 2016-11-16 Mideye AB Système, agencement et procédé d'authentification d'utilisateur final
US20080235778A1 (en) * 2007-03-21 2008-09-25 Motorola, Inc. Communication network, an access network element and a method of operation therefor
US8621210B2 (en) * 2008-06-26 2013-12-31 Microsoft Corporation Ad-hoc trust establishment using visual verification
JP5374090B2 (ja) * 2008-08-13 2013-12-25 株式会社日立製作所 認証連携システム、端末装置、記憶媒体、認証連携方法および認証連携プログラム

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050033995A1 (en) * 2003-08-08 2005-02-10 Paul Lin System and method for utilizing information in publicly broadcast signals for shared secret purposes
GB2434663A (en) * 2006-01-13 2007-08-01 Deepnet Technologies Ltd Mutual authentication using a pair of one-time passwords
EP1862948A1 (fr) 2006-06-01 2007-12-05 Axalto SA Carte CI avec client OTP
US20080034216A1 (en) * 2006-08-03 2008-02-07 Eric Chun Wah Law Mutual authentication and secure channel establishment between two parties using consecutive one-time passwords
US20080168544A1 (en) * 2007-01-05 2008-07-10 Ebay Inc. Token device re-synchronization through a network solution

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP2427846A1 *

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2505678A (en) * 2012-09-06 2014-03-12 Visa Europe Ltd Authenticating and validating an access request
US8806600B2 (en) 2012-09-06 2014-08-12 Visa Europe Limited Method and system for verifying an access request
GB2505678B (en) * 2012-09-06 2014-09-17 Visa Europe Ltd Method and system for verifying an access request
US9830447B2 (en) 2012-09-06 2017-11-28 Visa Europe Limited Method and system for verifying an access request
US10282541B2 (en) 2012-09-06 2019-05-07 Visa Europe Limited Method and system for verifying an access request
US10929524B2 (en) 2012-09-06 2021-02-23 Visa Europe Limited Method and system for verifying an access request
CN116137574A (zh) * 2021-11-18 2023-05-19 北京小米移动软件有限公司 外设认证方法、装置电子设备及存储介质
CN116137574B (zh) * 2021-11-18 2024-04-09 北京小米移动软件有限公司 外设认证方法、装置电子设备及存储介质

Also Published As

Publication number Publication date
US8868918B2 (en) 2014-10-21
EP2427846A1 (fr) 2012-03-14
US20120272067A1 (en) 2012-10-25
CH701050A1 (fr) 2010-11-15

Similar Documents

Publication Publication Date Title
EP2427846A1 (fr) Procede d&#39;authentification
US7904946B1 (en) Methods and systems for secure user authentication
EP1368930B1 (fr) Authentification cryptographique par modules ephemeres
EP2619941B1 (fr) Procede, serveur et systeme d&#39;authentification d&#39;une personne
EP2614458B1 (fr) Procede d&#39;authentification pour l&#39;acces a un site web
EP1549011A1 (fr) Procédé et système de communication entre un terminal et au moins un équipment communicant
EP3022867B1 (fr) Procéde d&#39;authentification forte
EP1813052B1 (fr) Procédé de sécurisation de transactions effectuées à distance sur un réseau de communication ouvert
EP3729307B1 (fr) Procédés et dispositifs pour l&#39;enrôlement et l&#39;authentification d&#39;un utilisateur auprès d&#39;un service
CA2611549C (fr) Methode et systeme permettant d&#39;obtenir une ouverture de session protegee au moyen de mots de passe a usage unique
EP2813962B1 (fr) Méthode de contrôle d&#39;accès à un type de services spécifique et dispositif d&#39;authentification pour le contrôle de l&#39;accès à un tel type de services.
WO2004082354A2 (fr) Dispositif d’authentification a mot de passe a usage unique : otp et dispositif generateur de mot de passe associe
EP3732604A1 (fr) Contrôle d&#39;intégrité d&#39;un dispositif électronique
WO2012116944A1 (fr) Procede d&#39;authentification d&#39;un utilisateur
EP2071799B1 (fr) Procédé et serveur pour l&#39;accès a un coffre-fort électronique via plusieurs entités
EP3842970B1 (fr) Procédé de vérification du mot de passe d&#39;un dongle, programme d&#39;ordinateur, dongle et terminal utilisateur associés
EP1868316B1 (fr) Procédé et dispositif d&#39;authentification d&#39;un utilisateur
EP3570518B1 (fr) Systeme et procede d&#39;authentification utilisant un jeton a usage unique de duree limitee
FR2984047A1 (fr) Procede d&#39;echange de donnee chiffree entre un terminal et une machine
WO2014135519A1 (fr) Système et procédé de gestion d&#39;au moins une application en ligne, objet portable utilisateur communiquant par un protocole radioélectrique et dispositif distant du système
EP2630746B1 (fr) Procede et systeme d&#39;authentification
FR3003058A1 (fr) Systeme et procede de gestion d’au moins une application en ligne, objet portable utilisateur usb et dispositif distant du systeme
WO2012022856A1 (fr) Procédé d&#39;authentification d&#39; un utilisateur du réseau internet
FR2980012A1 (fr) Systeme et procede d&#39;authentification par code personnel

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 10716813

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

REEP Request for entry into the european phase

Ref document number: 2010716813

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2010716813

Country of ref document: EP