CH701050A1

CH701050A1 - Procédé d'authentification.

Info

Publication number: CH701050A1
Application number: CH00711/09A
Authority: CH
Inventors: David-Olivier Jaquet-Chiffelle
Original assignee: Haute Ecole Specialisee Bernoise Technique Inf
Priority date: 2009-05-07
Filing date: 2009-05-07
Publication date: 2010-11-15
Also published as: US8868918B2; WO2010127945A1; US20120272067A1; EP2427846A1

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 calcule et affiche une réponse (105), 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 compare la réponse affichée par le dispositif cryptographique personnel avec la réponse affichée par le terminal. 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.

Description


  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 fig. 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.

  

[0008]    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.

  

[0009]    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é.

  

[0010]    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.

Bref résumé de l'invention

  

[0011]    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.

  

[0012]    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.

  

[0013]    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.

  

[0014]    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.

  

[0015]    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.

  

[0016]    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.

  

[0017]    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

  

[0018]    Des exemples de mise en oeuvre de l'invention sont indiqués dans la description illustrée par les figures annexées dans lesquelles:

  

[0019]    La fig. 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.

  

[0020]    La fig. 2 illustre de manière schématique un système mettant en oeuvre le procédé de l'invention.

  

[0021]    La fig. 3 illustre un exemple de boîte de dialogue affichée par un logiciel mettant en oeuvre le procédé de l'invention.

  

[0022]    La fig. 4 illustre de manière schématique différents flux de données lors de l'authentification selon le procédé de l'invention.

  

[0023]    La fig. 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

  

[0024]    La fig. 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.

  

[0025]    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.

  

[0026]    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.

  

[0027]    Il 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.

  

[0028]    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.

  

[0029]    La fig. 2 illustre de manière schématique un exemple de système dans lequel le procédé de l'invention peut être mis en oeuvre. 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.

  

[0030]    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.

  

[0031]    Le procédé de l'invention peut aussi être mis en oeuvre 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.

  

[0032]    Le flux de données lors du procédé d'authentification et d'autorisation est illustré à titre d'exemple sur la fig. 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 103 à un serveur d'authentification et d'autorisation 4 responsable d'authentifier et d'autoriser les utilisateurs souhaitant accéder à des ressources protégées.

  

[0033]    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.

  

[0034]    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.

  

[0035]    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.

  

[0036]    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 30 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.

  

[0037]    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.

  

[0038]    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.

  

[0039]    Le challenge peut aussi être transmis directement depuis le terminal au dispositif cryptographique, par exemple au travers d'un couplage acoustique impliquant un hautparleur dans le terminal et un microphone dans le dispositif cryptographique 1, ou au moyen d'un couplage optique mettant en oeuvre 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.

  

[0040]    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.

  

[0041]    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.

  

[0042]    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 correct, 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.

  

[0043]    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.

  

[0044]    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.

  

[0045]    La fig. 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.

  

[0046]    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.

  

[0047]    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 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.

  

[0048]    Le procédé peut avantageusement être automatiquement interrompu suite à M demandes consécutives de faire afficher la réponse par le terminal. 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.

  

[0049]    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

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 calcule et restitue une réponse (105) à un challenge,

e) ladite réponse est transmise par l'utilisateur,

f) une vérification de la réponse est effectuée (107), l'utilisateur é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 compare la réponse restituée par le dispositif cryptographique personnel avec la réponse restituée par le terminal.

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é introduite 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).

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.

11. Le système de la revendication 10, constitué par un serveur informatique connecté à un réseau de communication (30), ledit serveur é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 exécutant ledit programme de générer un challenge, de vérifier une réponse d'utilisateur 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.