FR2978851A1 - Procede "non-kerkhoffsien" d'authentification d'un utilisateur - Google Patents
Procede "non-kerkhoffsien" d'authentification d'un utilisateur Download PDFInfo
- Publication number
- FR2978851A1 FR2978851A1 FR1102429A FR1102429A FR2978851A1 FR 2978851 A1 FR2978851 A1 FR 2978851A1 FR 1102429 A FR1102429 A FR 1102429A FR 1102429 A FR1102429 A FR 1102429A FR 2978851 A1 FR2978851 A1 FR 2978851A1
- Authority
- FR
- France
- Prior art keywords
- user
- authentication
- technique
- algorithm
- authentication system
- 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.)
- Pending
Links
Classifications
-
- 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
-
- 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/36—User authentication by graphic or iconic representation
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Storage Device Security (AREA)
Abstract
Le procédé selon l'invention concerne une méthode d'authentification d'un usager caractérisée en ce que pour chaque usager la technique exacte d'authentification et le type de secret associé à cette technique font partis d'un ensemble de choix qu'il aura personnalisé, de telle sorte qu'un attaquant ne peut connaître la technique d'authentification choisie ou utilisée pour un usager. Le but de l'invention est de contrer les attaques existantes sur l'ensemble des schémas d'authentification d'usagers en prévenant tout attaquant de savoir comment se faire passer pour un utilisateur après avoir observé cet utilisateur sur une ou plusieurs authentifications réussies, de manière simplifiée : prévenir les vols de PIN code (authentifications multiples auprès d'un même service sur une même technique et basée sur la même connaissance d'un secret unique suivant le principe de Kerckhoffs.). La diversité des méthodes, des techniques et des secrets d'authentification disponibles pour un usager rend très difficile les attaques sur le service d'authentification proposée par l'invention.
Description
-1-
Le domaine de l'invention est celui de la l'authentification des usagers de services ou de manière plus générale des êtres humains.
Dans l'état de la technique, l'authentification d'un être humain consiste généralement à lui demander un «PIN Code» en général constitué d'environ quelques digits qu'il doit retenir (Par exemple 4 digits pour sa carte bancaire, ou pour le digicode devant un porte d'entrée). Cette technique a de nombreux défauts, ainsi quelqu'un qui observe une authentification découvre immédiatement le secret et peut par la suite se faire passer pour une autre personne en réutilisant ce secret. Plusieurs techniques pour tenter d'améliorer l'authentification humaine ont été proposées ces dernières années, mais elles ont eu peu de succès. Elles conservent en général ce que l'on nomme le «principe de Kerckhoffs» c'est-à-dire que l'on suppose qu'un adversaire connaît tout du système a part la valeur des clés secrètes. Ce principe a également été reformulé par Claude Shannon: «l'adversaire connaît le système». Du fait de la capacité de calcul très limitée des êtres humains, et de leurs goûts divers, il est en fait très difficile de trouver un algorithme universel d'authentification simple et sûr.
Dans notre invention, nous proposons un procédé d'authentification humaine qui abandonne le principe de Kerckhoffs. Ceci peu paraître surprenant tant ce principe est bien établi en cryptographie, et du fait que l'histoire de la cryptographie possède de très nombreux exemples de problèmes de sécurités qui sont apparus lorsque ce principe avait été abandonné (pour référence : « The codebreakers » de David Kahn, « Histoire des codes secrets » de Simon Singh).
Plus précisément, le procédé selon l'invention concerne une méthode d'authentification d'un usager caractérisée en ce que pour chaque usager la technique exacte d'authentification et le type de secret associé à cette technique font partis d'un ensemble de choix qu'il aura personnalisé, de telle sorte qu'un attaquant ne peut connaître la technique d'authentification choisie ou utilisée pour un usager.
Le but de l'invention est de contrer les attaques existantes sur l'ensemble des schémas d'authentification d'usagers en prévenant tout attaquant de savoir comment se faire passer pour un utilisateur après avoir observé cet utilisateur sur une ou plusieurs authentifications réussies, de manière simplifiée : prévenir les vols de PIN code (authentifications multiples auprès d'un même service sur une même technique et basée sur la même connaissance d'un secret unique suivant le principe de Kerckhoffs.). La diversité des méthodes, des techniques et des secrets d'authentification disponibles pour un usager rend très difficile les attaques sur le service d'authentification proposée par l'invention.
Dans l'invention on résout ce problème d'attaque sur les procédés d'authentification par la mise en oeuvre d'une multiplicité d'algorithmes d'authentifications, combiné à une multiplicité de représentations possibles des challenges et des réponses. Dans une variante de l'invention, la -2-
variabilité des algorithmes et représentations des challenges et réponses est complexifiée par l'origine du secret qui peut être imposé par le système d'authentification ou l'usager lui-même pour tout ou un sous ensemble des algorithmes d'authentification du système d'authentification.
L'invention a donc pour objet un procédé d'authentification d'un utilisateur, non conforme au principe de Kerckhoffs (procédé dit « non- Kerckhoffsien »), caractérisé en ce que la technique exacte d'authentification et le type de secret associé font partis d'un vaste ensemble de possibilités personnalisables par l'utilisateur de telle sorte qu'un attaquant ne peut pas connaître la technique d'authentification choisie par le système d'authentification et en ce qu'il comporte les étapes suivantes : Une étape de configuration du procédé d'authentification par chacun des utilisateurs, Une étape d'authentification des utilisateurs.
Dans une variante de l'invention, le système d'authentification peut faire évoluer sa liste d'algorithmes d'authentification disponibles et chacun de leur paramétrage générique.
Dans une variante de l'invention, lors de l'étape de configuration l'utilisateur peut choisir au moins un algorithme d'authentification parmi la liste de ceux autorisés par le système d'authentification et le configurer pour son usage propre. Dans une variante de l'invention, l'étape de configuration d'un algorithme spécifique par un utilisateur comporte une phase d'apprentissage durant laquelle l'utilisateur associe à des d'images, des symboles ou tout autres contenus multimédia un ou plusieurs sens ou conventions secrètes, connus du système d'authentification. 25 Dans une-variante de l'invention, l'étape de configuration d'un algorithme spécifique par un utilisateur comporte une phase d'apprentissage durant laquelle l'utilisateur reçoit du système d'authentification des images, des symboles ou des contenus multimédia et donne en sortie des lettres, des chiffres, des symboles ou des opérations faisables sur son téléphone portable ou tout 30 ordinateur personnel portable pouvant constituer par la suite une réponse à un défi lié à ces images, symboles ou contenus multimédia.
Dans le mode de réalisation préférée de l'invention, l'utilisateur peut faire évoluer sa liste ou ses configurations d'algorithmes d'authentification, lorsqu'il le souhaite. L'invention sera mieux comprise à la lecture de la description qui suit et à l'examen des figures qui l'accompagnent. Celles-ci sont présentées à titre indicatif et nullement limitatif de l'invention. Les figures montrent : 35 2978851 -3-
Figure la et lb : schéma générique d'authentification d'un utilisateur lors d'un accès à un service, ce schéma correspond à l'état de l'art actuel., deux cas sont décrits l'hébergement par le fournisseur de service du système d'authentification et l'usage par le fournisseur de service d'un système d'authentification externe.
Figure 2a et 2b : schémas de principe de l'invention,
Figure 3a : algorithme d'authentification basé sur 4 digits évoluant avec l'heure Figure 3b : algorithme d'authentification basé sur des images avec une action associée 10 Figure 3c : algorithme d'authentification basé sur un usage de symboles propres à l'utilisateur Figure 3d : algorithme d'authentification basé sur une usage d'un PIN secret sur 4 digits, d'une convention spécifique dont la source de variabilité est externe au système d'authentification et enfin du challenge émis par le système d'authentification.
15 Figure 4a : description de l'étape de configuration du serveur d'authentification par un utilisateur Figure 4b : description de l'étape d'authentification d'un utilisateur auprès du serveur d'authentification Figure 4c : description de l'étape d'authentification d'un utilisateur auprès d'un fournisseur de service via le serveur d'authentification 20 La figure 1 décrit un schéma générique d'authentification tel que réalisé aujourd'hui au niveau de l'état de l'art. La figure 1 montre un système composé d'un utilisateur (101), d'un fournisseur de service (102), d'un serveur d'authentification (103) et d'une base de données(104) contenant les secrets d'authentification (105) des utilisateurs. La figure (1) illustre par exemple l'accès d'un utilisateur (101) à un service délivré sur internet par un fournisseur de service (102). Pour ce faire, l'utilisateur (101) peut accéder au travers de la combinaison d'une pluralité de moyens de communication et de transports de communication audit fournisseur de service (102). Cette pluralité de moyens pouvant être, par exemple, la combinaison d'un accès wifi via un équipement portable à un système connecté à un réseau de type xDSL, lui-même interconnecté via un fournisseur d'accès à internet à internet sous le protocole IP ou dans un autre exemple un équipement doté d'un accès radio mobile de type GSM 2G/3G ou 4G connecté via un opérateur de téléphonie mobile en IP sur Internet ou un réseau lan IP privé.
L'utilisateur (101) accède au fournisseur de service (102) lors d'une étape de navigation (200), au cours de cette navigation dans les services proposés par le fournisseur de service, un service spécifique (106) est sélectionné par l'utilisateur, lequel service est soumis à un contrôle d'accès par le fournisseur de service, contrôle d'accès requérant une authentification de l'utilisateur (101). Au niveau de la technique, deux modes d'implémentation sont généralement mis en oeuvre, soit le fournisseur de service (102) relaie (étape 201) vers un serveur d'authentification (103) interne le -4-
besoin d'authentification, soit le fournisseur de service re-route (étape 202) l'utilisateur(101) vers un serveur d'authentification(101) externe.
Dans le cas du relayage (étape 201), le serveur d'authentification présente une mire (107) de saisie d'un Identifiant et d'un PIN Code à l'utilisateur, via le fournisseur de service (étape 202). L'utilisateur saisit son Identité et son PIN dans la mire présentée (étape 203). Le serveur d'authentification (étape 204) fait une requête dans sa base de données (105) pour l'entrée Identifiant présentée (étape 203) et contrôle la validité du PIN présentée (étape 205). Si les valeurs stockées en base et les valeurs présentées correspondent, généralement après un ou plusieurs calculs cryptographiques appliqués aux données PIN présenté et PIN issus de la base de données, l'utilisateur est déclaré authentifié par le serveur d'authentification. Ledit serveur d'authentification remonte le vers le fournisseur de service le résultat de l'authentification réalisée (étape 206).
Dans le cas du re-routage (étape 202) de l'utilisateur vers le serveur d'authentification par le fournisseur de service (102), le fournisseur de service fournit à l'utilisateur l'adresse du serveur d'authentification et optionnellement en paramètres (108) des données l'identifiant (par exemple une URL ou une adresse IP, un cookies de session, un identifiant de télécommunication), et le service spécifique requis (106) par l'utilisateur. Le serveur d'authentification à la réception des données présentées et transportées par l'utilisateur(108) lui présente la mire de saisie (107). L'utilisateur saisit son Identité et son PIN dans la mire présentée (étape 203). Le serveur d'authentification (étape 204) fait une requête dans sa base de données (105) pour l'entrée Identifiant présentée (étape 203) et contrôle la validité du PIN présentée (étape 205). Si les valeurs stockées en base et les valeurs présentées correspondent, généralement après un ou plusieurs calculs cryptographiques appliqués aux données PIN présenté et PIN issus de la base de données, l'utilisateur est déclaré authentifié par le serveur d'authentification. Ledit serveur d'authentification re-route alors l'utilisateur vers le fournisseur de service sur la base des données collectées (108) et transmet en paramètre le résultat de l'authentification réalisée (étape 206). Cette technique de re-routage est utilisée par les méthodes de SSO (Single Sign One) et à l'usage de cookies d'authentification (en navigation web). On remarque l'asynchronisme entre l'accès au service et l'authentification de l'utilisateur. En particulier la phase d'authentification peut, par exemple, être antérieure à l'accès au service, l'information d'authentification réussie étant alors véhiculée par le cookies d'authentification.
Dans les figures 2x, on présente une architecture générique du procédé selon l'invention. Dans la figure 2a, on représente le concept de challenge/réponse selon l'invention. Ce challenge se compose d'un ensemble de paramètres (400) issus du serveur d'authentification et d'une identification de l'algorithme (401) à utiliser. Cette identification (401) peut aussi bien être un numéro, un nom, une image ou un symbole figé par le serveur d'authentification et connu de l'utilisateur, qu'un numéro, un nom, une image ou un symbole imposé comme une convention au serveur d'authentification par l'utilisateur lors de l'étape de configuration dudit algorithme par l'utilisateur auprès du serveur d'authentification. L'information d'identification (401) permet à l'utilisateur de savoir -5-
quel est l'algorithme d'authentification à utiliser et il peut ainsi prendre en compte les valeurs des paramètres (400) présentées comme le challenge (étape 210) auquel il doit se soumettre. L'identification (401) et tout ou partie des paramètres (400) peuvent être collectés par le serveur d'authentification (103) directement dans la base de données qui lui est rattachée (104). Ici on observe un premier intérêt de l'invention, un attaquant (110) observant la communication d'un utilisateur (étape 212) ne peut savoir le type d'algorithme utilisé puisque cette information est basée sur l'usage d'une convention partagée entre le serveur et l'utilisateur.
10 L'utilisateur répond au challenge (400) reçu avec l'algorithmie requise (401) et produit sa réponse (402) vers le serveur d'authentification (étape 211).
A la réception de la réponse (402) au challenge (400), le serveur d'authentification procède à la vérification du résultat, à l'instar des modes d'authentification génériques des étapes (203, 204, 205 et 15 206).
Ici on observe un second intérêt de l'invention, un attaquant (110) observant la communication d'un utilisateur (étape 212) ne peut connaitre l'algorithme utilisé, ni la façon dont l'algorithme a été personnalisé par l'utilisateur. De même, une observation de plusieurs clairs/chiffrés ou challenges 20 (400) / réponses (402) ne lui permettra pas de casser ou deviner ni l'algorithme ni les secrets d'authentification de l'utilisateur du fait du trop grand nombre de possibilités à investiguer. Nous sommes typiquement dans une mise en oeuvre d'un procédé d'authentification non-conforme au principe de Kerckhoffs, puisque l'attaquant ne peut deviner ni connaître tout du système a part la valeur des clés secrètes des utilisateurs. 25 Dans la figure 2b, on présente une architecture interne de la base de données (104) associée au serveur d'authentification. Cette base de données est présentée comme externe au serveur d'authentification, pour des raisons de clarté, mais elle peut aussi être intégrée au serveur d'authentification sans altérer le procédé de notre invention. Dans la figure 2b on définit le système d'authentification (120) comme l'ensemble composé du serveur d'authentification (103) et du contenu de la base de données (104).
La base de données (104) du serveur d'authentification (103) comporte au moins 2 tables suivant 35 le procédé selon l'invention. La première table (300) contient le descriptif de l'ensemble des algorithmes d'authentification connus du serveur d'authentification (301 et l'ensemble des 302i et 303i, par convention l'indice 'i' ajouté à l'item 302 correspond au 'i-eme' algorithme parmi l'ensemble des 'Nombres d'algorithmes' (301) algorithmes installés dans la base des données(104) ), la seconde table (309) contient le descriptif de l'ensemble des utilisateurs (101) du serveur d'authentification ainsi 40 que la configuration de l'ensemble des algorithmes qu'ils souhaitent utiliser. Ces deux tables (300) et 30 -6-
(309) ne sont pas figées et peuvent être enrichies ou modifiées au niveau des algorithmes (302 et 303) et de leurs paramétrisations (304) utilisables sur le serveur d'authentification (103) et de la même façon au niveau des utilisateurs (101) actifs sur le serveur d'authentification et de leurs configurations personnelles des algorithmes (320, 321 et 322) qu'ils ont décidé d'utiliser.
La table d'Algorithmes (300) est composée des items suivants : - nombre d'algorithmes (301) : nombre d'algorithmes configurés et disponibles pour procéder aux authentifications des utilisateurs. Cette valeur évolue en fonction des instanciations d'algorithmes (indice 'i' des items ci-dessous) sur le système d'authentification constitué du serveur d'authentification (103) et de la based de données (104). algorithme_Idi (302i) : Identifiant du 'i-ème' algorithme instancié dans le système d'authentification - code d'éxécution (303i) : code exécutable du 'i-ème' algorithme instancié dans le système d'authentification. De façon non limitative de l'invention ce code peut être stocké dans la base de données (104) ou être directement instancié au sein du serveur d'authentification (103). - paramètres spécifiques de l'algorithme_Idi (304i) : paramétrisation du 'i-ème' algorithme instancié dans le système d'authentification. Cette paramétrisation est générique pour l'ensemble du système d'authentification. Des exemples de ces paramétrisations sont données à titre d'exemples non limitatifs de l'invention dans la suite de la description détaillée du procédé selon l'invention (confere 50x).
La table d'Utilisateurs (309) est composée des items suivants : - Nombre d'utilisateurs (310) : nombre d'utilisateurs (101) configurés et provisionnés dans le système d'authentification, pouvant utiliser les services d'authentifications du serveur d'authentification (103). Cet item évolue dans le temps en fonction des enregistrements de nouveaux utilisateurs ou des résiliations d'utilisateurs sur le système d'authentification - Table de l'utilisateur_k (311k) : table de données relatives 'k-ème' utilisateur instancié dans le système d'authentification. - Identité de l'utilisateur_k (312k) : identité du 'k-ème' utilisateur. - nombre d'algorithmes (320k) : nombre d'algorithmes configurés par le 'k-iéme' utilisateur parmi la liste des algorithmes disponibles sur le système d'authentification (ce nombre (320k) ne peut être supérieur au 'nombre d'algorithmes' (301) du système d'authentification). - Algorithme_Idi (321ki) : Identifiant du 'i-éme' algorithme configuré par le 'k-iéme' utilisateur (l'indice 1' ne peut être supérieur à la valeur (320k)).
Paramétres spécifiques à l'utilisateur 'k' de l'algorithme_Idi (322ki) : ces paramètres contiennent la configuration par l'utilisateur 'k' de l'algorithme_Idi qu'il a sélectionné. Ces paramétres de l'instanciation de l'algorithme_Idi(302i) peuvent être constitués, de manière non limitative de l'invention, d'images, de symboles ou tout autres contenus multimédia. Ces paramètres peuvent aussi de façon non limitative de l'invention contenir les conventions et sens secrets associés aux images, symboles et contenus multimédia renseignés par -7-
l'utilisateur pour un usage de l'algorithme_Idi et de la même façon les conventions et sens secrets délivrés par le système d'authentifcation à l'utilisateur 'k' pour l'algorithme_Idi(302i). Des exemples de ces paramétrisations spécifiques à l'utilisateur 'k' sont données à titre d'exemples non limitatifs de l'invention dans la suite de la description détaillée du procédé selon l'invention (confère 50x). On note que les secrets d'authentification (105) sont des valeurs dispatchées pour chaque utilisateur (101 et 312k) et chaque algorithme (321ki) configuré par ledit utilisateur dans les paramètres spécifiques audit utilisateur (322ki : paramétres spécifiques à l'utilisateur 'k' de l'algorithme_Idi).
Dans les figures 3x sont présentés à titre d'exemple des algorithmes d'authentification pouvant être mis en oeuvre au sein du système d'authentification. De nombreux utilisateurs sont en effet prêts a utiliser une application personnalisable d'authentification, et à en apprendre le fonctionnement, du moment que cette application leur paraisse amusante, ou bien fasse appel à des connaissances qu'ils apprécient. Le très grand nombre de possibilité d'algorithmes et de personnalisations possibles permet ainsi d'obtenir un bon niveau de sécurité pour les personnes qui le souhaitent (ainsi même si un adversaire/attaquant observerait une ou quelques authentifications, il ne serait pas capable de se faire passer pour un utilisateur légitime) tout en permettant aux utilisateurs réfractaires à ces nouvelles technique de choisir une technique classique, par exemple de type Pin Code.
Dans la figure 3a est présenté un algorithme simple d'authentification basé sur une dérivation de la valeur d'un code secret à 4 digits. Dans ce 1er exemple, l'utilisateur(101) qui doit s'authentifier a toujours un code secret de 4 digits (322ki), par exemple 2195, mais au lieu de taper 2195, il doit taper 4 digits dépendant de l'heure. Par exemple, si il est 19 h 54, il tapera 3049, (addition modulo 10 digit à digit : 2195 + 1954 = 3049).
Un item (404) est introduit, il représente une source de variabilité accessible à l'utilisateur, non émise par le système d'authentification dans les champs (400) et (401) lors de l'émission du challenge. Dans le cas de l'exemple présent, il est courant que l'heure apparaisse sur le contenu d'une page web et de plus cette information est partagée sur internet. Nous avons donc une convention imposée par l'algorithme choisi, convention qui implique que le système d'authentification accède de même à la valeur de cette heure sur internet au moment de la saisie par l'utilisateur.
Dans la figure 3b est décrit un algorithme simple d'authentification sur une base de 4 digits, mais cette fois ci au travers de l'usage de données personnelles (322ki) caractérisant l'usage de l'algorithme pour un utilisateur 'k' (312k).
Dans ce second exemple, le code secret est toujours par exemple 2195, mais l'utilisateur qui souhaite s'authentifier reçoit 10 images sur son écran. Sur chaque image, il y a de nombreux chiffres et symboles. II doit taper le chiffre en bas à droite (par exemple) des images correspondant à son PIN code, c'est à dire la 2ème image, puis de la 1ère image, puis de la 9ème image, puis de la Sème image. 2978851 -8-
Dans la figure 3c est décrit un algorithme simple d'authentification basé sur l'usage d'images personnelles (322ki) associé à des actions et conventions secrètes. Dans cet exemple, l'utilisateur accepte de procéder à une phase de personnalisation un peu longue. On lui présente une série de 100 photos (par exemple) et pour certaines de ces photos de son 5 choix, il associe un code de 4 digits, ou un mot. Par la suite, lors d'une authentification, plusieurs photos sont envoyées, dont au moins une des photos choisies, et il devra répondre le code de 4 digits ou le mot associé.
Dans la figure 3d est décrit un algorithme simple d'authentification basé sur un usage d'un PIN 10 secret sur 4 digits, d'une convention spécifique (404) dont la source de variabilité est externe au système d'authentification (dans l'exemple présent on reprend l'heure internet) et enfin du challenge (400) émis par le système d'authentification. L'ensemble de ces trois sources d'information indépendantes doivent être combinées par l'utilisateur. Pour ce faire, l'algorithme impose de réaliser une addition digit à digit modulo dix des valeurs des digits de ces sources de variabilités avec les 15 valeurs des digits du PIN code de l'utilisateur.
En fait l'invention n'est pas liée à une de ces méthodes particulières d'authentification, mais au fait que l'utilisateur(101) se voit proposer un catalogue (301 et 302i) possédant de très nombreuses façons différentes de s'authentifier, et qu'il en choisit une ou plusieurs (320k) en fonction de ses goûts. 20 La très grande diversité des méthodes possibles rend en général très difficile pour un attaquant (110) de savoir comment se faire passer pour un utilisateur après avoir observé cet utilisateur(101) si une ou quelques authentifications. Et le système est compatible avec des utilisateurs rétifs à toute innovation et qui souhaitent volontairement garder (au moins pour un temps) le système classique du code fixe à 4 digits. Plusieurs variantes simples de ces systèmes leur seront proposées, mais s'ils 25 souhaitent ne rien changer, ils le pourront, bien que cela leur soit déconseillé pour la sécurité.
Dans la figure 4a : on décrit une étape de configuration du serveur d'authentification par un utilisateur (description non limitative de l'invention et donnée uniquement à titre indicatif). Cette configuration du serveur d'authentification par un utilisateur est elle-même mise en oeuvre 30 au travers de 5 étapes : - L'utilisateur accède système d'authentification (que ce soit de manière directe par un accès internet ou directement en se déplaçant physiquement dans les locaux du prestataire d'authentification ou via un relayage depuis un fournisseur de service vers le prestataire d'authentification dont il utilise les services). 35 - Le système d'authentification procède à l'enregistrement du nouvel utilisateur, collecte son identité et s'assure de sa qualité (en particulier, le prestataire peut s'inspirer des procédures d'enregistrement mises en oeuvre par les organismes financiers ou les Assurances pour la collecte de l'identité de l'utilisateur, ou de manière identique s'inspirer des procédures d'enrôlement mises en oeuvre par les organisations délivrant des Signatures Electroniques) . 2978851 -9-
- Le système d'authentification crée une instance pour l'utilisateur (311k) au sein de la table d'utilisateur(309) et renseigne le champ 'Identité de l'utilisateur k' (312k). - Le système d'authentification présente à l'utilisateur enregistré l'ensemble des algorithmes référencés. L'utilisateur effectue son choix et positionne une paramétrisation spécifique pour chacun des algorithmes choisis (320ki et 322ki) (cette paramétrisation peut être absente ou se cantonner à la paramétrisation par défaut du système d'authentification pour ledit algorithme). - Le système d'authentification finalise la configuration de la table d'utilisateur (en particulier 310 et 320k). En général, un borderau de fin de configuration est remis à l'utilisateur, récapitulant les configurations mises en oeuvres). 10 Dans la figure 4b : on décrit une phase d'apprentissage et de personnalisation de l'étape de configuration d'un algorithme d'authentification sélectionné par un utilisateur (description non limitative de l'invention et donnée uniquement à titre indicatif).. Cette phase d'apprentissage est composée de 3 étapes distinctes suivant les types d'algorithmes : 15 Soit l'utilisateur sélectionne un ensemble d'information personnelles (de type images, symboles ou tout autres contenus multimédia) et les associe à un ou plusieurs sens ou conventions secrètes pour un algorithme spécifique (322ki). Soit l'utilisateur reçoit du système d'authentification (103, 104 et 304i) un ensemble de contenus (de type images, symboles ou des contenus multimédia) et donne en sortie des 20 lettres, des chiffres, des symboles ou des opérations faisables sur son téléphone portable ou tout ordinateur personnel portable pouvant constituer par la suite une réponse à un défi lié à ces contenus - Soit la phase d'apprentissage de l'algorithme spécifique combine les mécanismes d'apprentissage des 2 étapes précédentes (ci-dessus). 25 Dans la figure 4c : on décrit l'étape d'authentification d'un utilisateur (description non limitative de l'invention et donnée uniquement à titre indicatif). Cette étape d'authentification est elle-même mise en oeuvre au travers de 5 étapes : - L'utilisateur (312k) accède à un service spécifique (106) d'un fournisseur de service (103) 30 requérant une authentification. - Le système d'authentification sélectionne un algorithme d'authentification parmi la liste des algorithmes de l'utilisateur (320k et 321ki), et calcule un challenge en fonction des paramètres spécifiques (304i) et des paramètres spécifiques de l'utilisateur (322ki) . - Le système d'authentification soumet à l'utilisateur le challenge calculé (400 et 401, étape 35 210). Dans cette étape, il est nécessaire de présenter un identifiant de l'algorithme utilisé dans le cas ou l'utilisateur aurait sélectionné plusieurs algorithmes d'authentification (la valeur 320k indique plusieurs algorithmes sélectionnés). Cet identifiant d'algorithme peut être explicite, basé sur une convention secrète ou un symbole (positionné par le système d'authentification ou fourni par l'utilisateur), établi entre l'utilisateur et le système d'authentification (dans ce cas 40 précis cette information est stockée dans le champ 322ki). Pour illustrer de façon simple le 2978851 -10-
propos, nous prenons pour exemple un utilisateur ayant configuré 4 algorithmes d'authentification différents, cet utilisateur pourrait les reconnaître en imposants une identification au travers de la présentation d'un symbole graphique de type 'coeur', 'carreau', 'pique', 'tréfle'. 5 - L'utilisateur répond au challenge en fournissant sa réponse pour l'algorithme et le challenge présentés (402 étape 211). - Le système d'authentification vérifie la réponse reçue et qualifie l'authentification réalisée.
Le procédé d'authentification selon l'invention est donc caractérisé en ce que la technique exacte 10 d'authentification (302i, 304i et 322ki) et le type de secret associé (322ki) font partis d'un vaste ensemble de possibilités (301, 312k et 322ki) personnalisables par l'utilisateur(101) de telle sorte qu'un attaquant(110) ne peut pas connaître la technique d'authentification choisie par le système d'authentification.
15 Le procédé selon l'invention est aussi caractérisé en ce que l'utilisateur (101) peut choisir au moins un protocole d'authentification (320k) parmi la liste de ceux autorisés par le prestataire (301, 302i), ces protocoles ayant été développés par le prestataire ou par une autre société.
Le procédé selon l'invention est aussi caractérisé en ce que l'utilisateur (101) a une phase 20 d'apprentissage et de personnalisation (figure 4b) plus ou moins longue durant laquelle l'utilisateur associe à des d'images, des symboles ou tout autres contenus multimédia un sens secret, connu du système d'authentification (premiers item de la figure 4b).
Le procédé selon l'invention est aussi caractérisé en ce que l'utilisateur a une phase 25 d'apprentissage et de personnalisation (figure 4b) d'un algorithme spécifique durant laquelle il reçoit du système d'authentification (103, 104 et 304i) des images, des symboles ou des contenus multimédia et donne en sortie des lettres, des chiffres, des symboles ou des opérations faisables sur son téléphone portable ou tout ordinateur personnel portable pouvant constituer par la suite une réponse à un défi lié à ces images, symboles ou contenus multimédia (deuxième items de la figure 30 4b).
Le procédé selon l'invention est aussi caractérisé en ce que l'utilisateur (101) peut faire évoluer sa liste (320k et 321 ki) ou ses configurations de protocole d'authentification (322ki) lorsqu'il le souhaite. De façon identique, le procédé selon l'invention est aussi caractérisé en ce que le système 35 d'authentification (120) peut faire évoluer sa liste d'algorithmes d'authentification disponibles (301, 302i et 303i) et chacun de leur paramétrage générique (304i).
Dans une mise en oeuvre alternative de l'invention, le procédé d'authentification est utilisable par des machines munies de microprocesseurs, dès lors que les phases de configuration ont été réalisées 40 au préalable. Une machine étant capable de reconnaître l'usage d'une convention sur un écran ou au -11-
sein d'une trame présentée et donc a même de dérouler le bon algorithme pour répondre au challenge soumis.
Claims (6)
- REVENDICATIONS1) Procédé d'authentification caractérisé en ce que la technique exacte d'authentification et le type de secret associé font partis d'un vaste ensemble de possibilités personnalisables par l'utilisateur de telle sorte qu'un attaquant ne peut pas connaître la technique d'authentification choisie par le système d'authentification.
- 2) Procédé selon la revendication 1 caractérisé le système d'authentification peut faire évoluer sa liste d'algorithmes d'authentification disponibles et chacun de leur paramétrage générique.
- 3) Procédé selon les revendications 1 à 2 caractérisé en ce que l'utilisateur peut choisir au moins un algorithme d'authentification parmi la liste de ceux autorisés par le système d'authentification et le configurer pour son usage propre. 15
- 4) Procédé selon les revendications 1 à 3 caractérisé en ce que l'utilisateur a une phase d'apprentissage et de personnalisation d'un algorithme spécifique durant laquelle il associe à des d'images, des symboles ou tout autres contenus multimédia un ou plusieurs sens ou conventions secrètes, connus du système d'authentification. 20
- 5) Procédé selon les revendications 1 à 4 caractérisé en ce que l'utilisateur a une phase d'apprentissage et de personnalisation d'un algorithme spécifique durant laquelle il reçoit du système d'authentification des images, des symboles ou des contenus multimédia et donne en sortie des lettres, des chiffres, des symboles ou des opérations faisables sur son téléphone portable ou tout ordinateur personnel portable pouvant constituer par la suite une réponse à un 25 défi lié à ces images, symboles ou contenus multimédia.
- 6) Procédé selon les revendications 1 à 5 caractérisé en ce que l'utilisateur peut faire évoluer sa liste ou ses configurations d'algorithmes d'authentification. 30
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1102429A FR2978851A1 (fr) | 2011-08-02 | 2011-08-02 | Procede "non-kerkhoffsien" d'authentification d'un utilisateur |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1102429A FR2978851A1 (fr) | 2011-08-02 | 2011-08-02 | Procede "non-kerkhoffsien" d'authentification d'un utilisateur |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| FR2978851A1 true FR2978851A1 (fr) | 2013-02-08 |
Family
ID=45563079
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR1102429A Pending FR2978851A1 (fr) | 2011-08-02 | 2011-08-02 | Procede "non-kerkhoffsien" d'authentification d'un utilisateur |
Country Status (1)
| Country | Link |
|---|---|
| FR (1) | FR2978851A1 (fr) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10764029B1 (en) | 2019-04-02 | 2020-09-01 | Carey Patrick Atkins | Asymmetric Encryption Algorithm |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1475721A1 (fr) * | 2002-02-13 | 2004-11-10 | Hideharu Ogawa | Procede et systeme d'authentification de l'utilisateur |
| US20050005119A1 (en) * | 2003-07-02 | 2005-01-06 | Yissum Research Development Company Of The Hebrew University Of Jerusalem | Imprinting an identification certificate |
| US20080109874A1 (en) * | 2006-11-07 | 2008-05-08 | Fmr Corp. | Life cycle management of authentication rules for service provisioning |
| US20080235784A1 (en) * | 2007-03-22 | 2008-09-25 | Chascom, Inc. | Gateway log in system with user friendly combination lock |
| US20110004921A1 (en) * | 2009-07-01 | 2011-01-06 | Fiserv, Inc. | Personalized security management |
-
2011
- 2011-08-02 FR FR1102429A patent/FR2978851A1/fr active Pending
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1475721A1 (fr) * | 2002-02-13 | 2004-11-10 | Hideharu Ogawa | Procede et systeme d'authentification de l'utilisateur |
| US20050005119A1 (en) * | 2003-07-02 | 2005-01-06 | Yissum Research Development Company Of The Hebrew University Of Jerusalem | Imprinting an identification certificate |
| US20080109874A1 (en) * | 2006-11-07 | 2008-05-08 | Fmr Corp. | Life cycle management of authentication rules for service provisioning |
| US20080235784A1 (en) * | 2007-03-22 | 2008-09-25 | Chascom, Inc. | Gateway log in system with user friendly combination lock |
| US20110004921A1 (en) * | 2009-07-01 | 2011-01-06 | Fiserv, Inc. | Personalized security management |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10764029B1 (en) | 2019-04-02 | 2020-09-01 | Carey Patrick Atkins | Asymmetric Encryption Algorithm |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20210271357A1 (en) | Virtual teller systems and methods | |
| EP2619941B1 (fr) | Procede, serveur et systeme d'authentification d'une personne | |
| US9660995B2 (en) | Methods, systems, and computer readable media for combating device theft with user notarization | |
| EP1095491B1 (fr) | Procede, systeme, serveur et dispositif pour securiser un reseau de communication | |
| EP3264305A1 (fr) | Procede de transaction securisee a partir d'un terminal non securise | |
| FR3041195A1 (fr) | Procede d'acces a un service en ligne au moyen d'un microcircuit securise et de jetons de securite restreignant l'utilisation de ces jetons a leur detenteur legitime | |
| US9882719B2 (en) | Methods and systems for multi-factor authentication | |
| EP3665600B1 (fr) | Procédé de signature électronique d'un document par une pluralité de signataires | |
| WO2009019298A1 (fr) | Système d'information et procédé d'identification par un serveur d'application d'un utilisateur | |
| EP2386977A1 (fr) | Système permettant l'affichage d'un fichier informatique privé sur un écran d'un terminal de télécommunications et procédé correspondant | |
| FR3075534A1 (fr) | Dispositif de stockage de cles numeriques pour signer des transactions sur une chaine de blocs | |
| FR3013541A1 (fr) | Procede et dispositif pour la connexion a un service distant | |
| EP3022867A1 (fr) | Procéde d'authentification forte | |
| EP2756626A2 (fr) | Procede d'echanges securises de donnees, dispositif et systeme de communication le mettant en oeuvre | |
| CN108885656A (zh) | 账户访问 | |
| EP2360889B1 (fr) | Création et utilisation d'un lien de télécommunication entre deux utilisateurs d'un réseau de télécommunication | |
| WO2018104599A1 (fr) | Procede d'authentification d'un equipement terminal, dispositif, equipement serveur et programme d'ordinateur associes | |
| FR2978851A1 (fr) | Procede "non-kerkhoffsien" d'authentification d'un utilisateur | |
| Reimair et al. | WebCrySIL-web cryptographic service interoperability layer | |
| FR2819967A1 (fr) | Procede et systeme de communication d'un certificat entre un module de securisation et un serveur | |
| EP1455290A1 (fr) | Procédé de gestion d'une configuration d'une passerelle par un utilisateur de la passerelle | |
| FR3032292A1 (fr) | Element securise et procede mis en œuvre dans un tel element securise | |
| FR2913551A1 (fr) | Methode d'authentification mutuelle et recurrente sur internet. | |
| Radke | Security ceremonies: including humans in cryptographic protocols | |
| WO2007006921A1 (fr) | Dispositif et procede de controle d'acces |