FR 2937204 A1 20100416 FR 0856997 A 20081015 SYSTEME D'AUTHENTIFICATION. La présente invention concerne un système d'authentification de service à distance. Actuellement, de nombreux services à distance sur internet ou sur les réseaux informatiques et de télécommunication en général utilisent des moyens pour authentifier leurs utilisateurs. Le plus souvent, cette authentification a lieu au moyen d'un identifiant et d'un mot de passe à saisir par l'utilisateur dans un formulaire d'accueil. Cependant cette solution simple et bien acceptée par les utilisateurs est réputée offrir un niveau de sécurité faible. Par exemple, les mots de passe choisis par les utilisateurs sont faciles à deviner et des logiciels spécialisés sont capables de trouver le mot de passe utilisé en quelques minutes pour de trop nombreux utilisateurs. Aussi différentes solutions ont été proposées pour obtenir une authentification sécurisée adaptée à des services ayant de forts enjeux comme, par exemple, l'accès à des opérations bancaires. Une large majorité de ces solutions se base sur l'utilisation d'un dispositif de sécurité particulier, le plus souvent une carte à puce ou carte à microprocesseur capable de jouer un rôle de coffre-fort électronique pour stocker des clés cryptographiques secrètes et effectuer certains calculs de cryptographie. Cette solution a pour inconvénient d'obliger l'utilisateur à transporter un objet supplémentaire. De plus, il devient nécessaire de prévoir un dispositif d'interfaçage pour permettre à la carte à puce de communiquer avec le service demandant cette authentification forte. Il serait donc particulièrement avantageux d'obtenir un niveau de sécurité équivalent à celui qui est procuré par une carte à puce en utilisant des objets déjà en possession de l'utilisateur tels que, par exemple, son téléphone mobile, son ordinateur de poche ou PDA, voire son ordinateur personnel. Pour résoudre un ou plusieurs des inconvénients cités précédemment, le système d'authentification d'un utilisateur possède un moyen d'authentification auprès d'une entité d'authentification, ledit moyen d'authentification comportant des moyens de stockage d'au moins une variable d'état et un générateur d'un code d'accès à usage unique actionnable à la demande de l'utilisateur, ledit code d'accès étant transmis à l'entité d'authentification pour validation, cette validation authentifiant l'utilisateur auprès de l'entité d'authentification. Ledit générateur est adapté pour calculer ledit code d'accès en utilisant ladite au moins une variable d'état et celle-ci est mise à jour de façon aléatoire lors de chaque génération d'un nouveau code d'accès. Des caractéristiques ou des modes de réalisation particuliers sont : • chaque variable d'état est mis à jour par une fonction Fx à sens unique ayant comme paramètres d'entrée au moins un secret propre audit moyen d'authentification. • au moins un premier et un deuxième niveau d'authentification utilisables tels que le code d'accès est calculé selon le premier ou le deuxième niveau, le deuxième niveau comportant la saisie par l'utilisateur d'un code secret utilisé comme paramètre d'entrée de la fonction Fx. • le moyen d'authentification comporte une pluralité de variables d'état mises à jour par la fonction Fx, ladite fonction Fx étant composée d'une pyramide de sous-fonctions ayant comme paramètres d'entrée lesdites variables d'état de telle sorte qu'une variable d'état mise à jour par une des sous-fonctions de Fx n'est pas utilisée par celle-ci comme paramètre d'entrée. • il comporte un premier, un deuxième et un troisième niveau d'authentification, le nombre de variables d'état mises à jour variant en fonction du niveau d'authentification mis en oeuvre de telle sorte que : • dans le premier niveau d'authentification : une variable d'état est mise à jour, les deux autres variables d'état servant de paramètres d'entrée à la sous fonction de Fx ; • dans le deuxième niveau d'authentification : deux variables d'état sont mises à jour, le troisième servant de variable d'entrée, et • dans le troisième niveau d'authentification : les trois variables d'état sont mises à jour et aucune des variables d'état n'est utilisée en variable d'entrée. • il comporte en outre un client d'authentification et le troisième niveau d'authentification utilisant ce client, ledit client d'authentification comportant un secret et étant adapté pour générer un second code d'accès à partir du code d'accès généré par le moyen d'authentification, ledit second code d'accès étant adapté pour authentifier l'utilisateur auprès de l'entité d'authentification. • le générateur comporte des moyens de génération d'un premier nombre à partir d'une fonction Gx à sens unique dont les paramètres d'entrée comportent la au moins une variable d'état mise à jour. • le générateur comporte : • une fonction Ex à sens unique pour générer un second nombre et comportant comme paramètres d'entrée : • le secret du moyen d'authentification ; • le nombre aléatoire, • une fonction possédant une fonction inverse adaptée pour combiner le premier et le second nombre générés par les fonctions Gx et Ex, le nombre combiné représentant le code d'accès et la fonction inverse étant adaptée pour générer le premier nombre et le second nombre à partir du code d'accès. • l'entité d'authentification est adaptée pour vérifier la validité du second nombre et la validité du premier nombre de façon distincte. • lors de la vérification de validité, l'entité d'authentification met à jour des états internes. • au moins un paramètre d'entrée de la fonction Gx est une variable d'état non mise à jour. • le moyen d'authentification et l'entité d'authentification comportent chacun une horloge, et le moyen d'authentification est adapté pour utiliser un intervalle de temps entre un temps de référence et le temps de son horloge dans le calcul du code d'accès et l'entité d'authentification est adaptée pour ne valider un code d'accès que si elle l'a reçu dans une plage de temps déterminé par rapport au temps de génération dudit code d'accès. • le système permettant l'authentification de l'utilisateur à une pluralité de services, un code d'accès est généré par le moyen d'authentification en utilisant un code spécifique à un service donné de telle sorte que sa validation par l'entité d'authentification ne donne accès qu'audit service. • le moyen d'authentification est adapté pour calculer un premier code d'accès en utilisant au moins un code spécifique au service, au moyen d'authentification et un intervalle de temps et l'entité d'authentification est adaptée pour calculer un second code d'accès spécifique au service , au moyen d'authentification et le transmettre à l'utilisateur pour que celui-ci puisse le comparer au premier code d'accès et identifier de façon sûre ainsi le service, lesdits premier et second code d'accès n'étant identique que si le calcul du premier code d'accès par le moyen d'authentification est réalisé dans une plage de temps déterminée par rapport au temps de calcul du second code secret par l'entité d'authentification et les codes spécifiques au service et au moyen d'authentification utilisés sont les mêmes. L'invention sera mieux comprise à la lecture de la description qui suit, 25 faite uniquement à titre d'exemple, et en référence aux figures en annexe dans lesquelles : - la figure 1 est une vue schématique d'un système d'authentification selon un mode de réalisation de l'invention ; - les figures 2A, 2B et 2C sont des vues schématiques du 30 fonctionnement selon trois options différentes du système de la figure 1 ; - la figure 3 est un ordinogramme du calcul d'un code d'accès par un moyen d'authentification du système de la figure 1 ; - la figure 4 est un ordinogramme du calcul d'un code d'accès par un client d'authentification du système de la figure 1 ; et - la figure 5 est un ordinogramme de la vérification d'un code d'accès par une entité d'authentification du système de la figure 1. En référence à la figure 1, un système d'authentification comporte une entité d'authentification 1 faisant fonction de serveur d'authentification, un ou plusieurs moyens d'authentification 3 ainsi qu'un ou plusieurs clients d'authentification 5. Les moyens 3 et les clients 5 d'authentification sont détenus par des utilisateurs du système. Un serveur 7 joue le rôle de gestionnaire d'authentification pour implémenter les interfaces et fonctionnalités nécessaires pour une utilisation sûre et multiservice des moyens, clients et entité d'authentification, ces derniers étant éventuellement tiers à cette description. L'entité d'authentification 1 et le gestionnaire d'authentification 7 15 peuvent être regroupés ou non sur un même serveur physique. Les moyens 3 d'authentification comportent des moyens 9 de calcul et d'interface utilisateur programmables. L'interface utilisateur comporte en particulier des moyens de saisie d'un code secret, par exemple un clavier numérique, et des moyens de visualisation et/ou de transmission d'un code M 20 d'accès. En effet, le code d'accès M est transmis à l'entité d'authentification soit directement par une liaison de données, soit visualisé par l'utilisateur sur un écran des moyens d'authentification puis saisi par cet utilisateur dans une fenêtre d'authentification ou transmis oralement, ou par modulation de fréquence DTMF, à un serveur vocal, par exemple. Les moyens 25 d'authentification comportent en outre des moyens 11 de stockage d'une ou plusieurs variables d'état i, j, k ainsi que d'un secret K1 unique pour chaque moyen. Par exemple, les moyens 3 d'authentification sont programmables dans un téléphone mobile ayant des moyens d'exécution de programme tels qu'une machine virtuelle Java. 30 Les clients 5 comportent également des moyens 13 de calcul et d'interface utilisateur programmable et des moyens 15 de transmission de données avec l'entité d'authentification 1, par exemple via le réseau internet. En particulier, les clients 5 comportent des moyens de stockage 17 d'un secret unique K3 pour chaque client, ce secret pouvant prendre la forme d'une paire de clé privée/publique (pK3, sK3) d'un algorithme cryptographique à clé publique. Les clients 5 sont typiquement implémentés sur des ordinateurs tels que des ordinateurs de bureau, des ordinateurs portables ou de poche ou des téléphones mobiles. Le gestionnaire d'authentification 7 est une interface intelligente entre les moyens d'authentification 3 et l'entité d'authentification 1. Cette interface est transparente au niveau du protocole d'authentification décrit ci-dessous et est donc facultative dans la mise en oeuvre de celui-ci. Cependant, dans un environnement réel, le gestionnaire d'authentification apporte les fonctionnalités nécessaires à un fonctionnement ergonomique et efficace du système d'authentification dans son environnement c'est-à-dire ses utilisateurs et les services utilisant le système d'authentification pour donner accès à leurs prestations aux utilisateurs. Ainsi le gestionnaire d'authentification 7 apporte notamment les fonctionnalités suivantes : • contrôle d'accès d'entité gestionnaire des services utilisant le système d'authentification : répartition de charge, authentification, gestion et sécurisation des connexions et requêtes ; • traitement des demandes d'authentification à ces services émanant de ces entités : routage, enrichissement par des données statiques ou dynamiques, réponse ; • traitement des demandes de gestion ou d'administration émanant de ces entités, qu'il s'agisse de demandes concernant le système ou les utilisateurs finaux : création et activation sécurisées d'un compte pouvant mettre en oeuvre , par exemple, un algorithme de type Diffie-Hellmann pour la transmission sécurisée de secrets générés par le moyen d'authentification initialement � inerte �, ajout et suppression d'un service tels que service à distance, utilisation à distance d'une carte de paiement ou de fidélisation, gestion des droits, etc. ; • contrôle d'accès des clients d'authentification : authentification, répartition de charge, gestion et sécurisation des connexions et requêtes ; • traitement des demandes de gestion des comptes des utilisateurs finaux émanant des clients d'authentification : gestion des droits, requêtes de service, ajout, suppression ou gestion de moyens ou clients d'authentification/ d'identification, ajout ou gestion de moyens de restauration du compte ; • contrôle d'accès et traitement des requêtes effectuées en ligne (notamment liées à la restauration des comptes utilisateurs) : authentification, répartition de charge, traitement des requêtes ; et • fonctions d'administration du système d'authentification. L'entité d'authentification 1 comporte, outre des moyens 20 de calcul, des moyens 22 de stockage, pour chaque moyen et chaque client d'authentification, du secret K1, du secret K3 ou, dans la version à cryptographie à clé publique, la clé publique pK3, des variables d'état ii, jj, kk symétriques des variables d'état i, j, k du moyen d'authentification, un secret constant correspondant au code secret de l'utilisateur sous une forme hachée, des compteurs d'erreurs et, préférentiellement, une pile de données n. Le fonctionnement du système d'authentification et du protocole d'authentification va maintenant être expliqué en relation avec les figures 2A, 2B et 2C. L'authentification d'un utilisateur auprès d'un service est réalisée par la transmission d'un code d'accès CA qui est vérifié par l'entité d'authentification 1. Si ce code est valide, l'entité d'authentification autorise l'utilisateur à accéder au service demandé. Le système d'authentification comporte trois modes de 25 fonctionnement se traduisant par trois options A, B et C de génération de code d'accès par le moyen d'authentification. Les options A et B génèrent un code d'accès pour l'authentification à un service utilisant le système d'authentification. L'option A, figure 2A, permet une authentification à 1 facteur basé sur le secret K1 détenu par le moyen 30 d'authentification. L'option B, figure 2B, permet une authentification à 2 facteurs : le secret K1 détenu par le moyen d'authentification et un secret c saisi par le titulaire. L'option C, figure 2C, génère un code d'accès GAI pour la connexion au client d'authentification qui effectue l'opération de transmission du code d'accès CA2 à l'entité d'authentification, code d'accès différent de celui calculé par le moyen d'authentification. L'option C permet une authentification à 3 facteurs : le secret K1 détenu par le moyen d'authentification et un secret c saisi par le titulaire comme pour l'option B et le secret K3, ou le couple sK31pK3, détenu par le client d'authentification. Le choix de l'option à utiliser pour s'authentifier est, en règle générale, laissé à l'appréciation de l'utilisateur puisque C n'a pas la même fonction que A et B : C sert, du point de vue du titulaire, à la connexion au client d'authentification, tandis que A et B servent à l'authentification auprès d'un service utilisant le système. Le choix d'utiliser A plutôt que B ou l'inverse est également le fait du titulaire. L'option A génère un code d'accès uniquement lié au moyen d'authentification aussi un attaquant se procurant ce moyen peut se faire passer pour le titulaire. L'option B génère un code d'accès lié au moyen d'authentification et à un secret personnel que le titulaire saisit pour obtenir un code d'accès. Le secret personnel du titulaire n'est pas stocké dans le moyen d'authentification mais le code d'accès généré ne sera exact que si le secret personnel saisi par l'utilisateur l'est également. Cependant certaines conditions du système peuvent obliger l'utilisateur à utiliser une option plutôt qu'une autre. En particulier, le moyen d'authentification effectue plusieurs contrôles liés aux usages synchrone et asynchrone des différentes options, et peut le cas échéant sur la base de ces contrôles forcer la saisie du code personnel du titulaire en imposant l'utilisation de l'option B au lieu de l'option A. Ces conditions seront explicitées plus loin, en relation en particulier avec la gestion des erreurs par le système. La génération du code d'accès par le moyen d'authentification pour l'option x comporte, figure 3, les étapes suivantes : • Génération, étape S30, d'un nombre pseudo-aléatoire randX ; • calcul, étape S32, d'un premier nombre Ml,X par une fonction EX ayant comme paramètres d'entrée une des variables d'état k, le secret KI et le nombre aléatoire randX, soit : Ml,X = EX(k, KI, randX) (équation 1) • calcul, étape S34, de nouvelles valeurs inew, jnew, knew pour les variables d'état i, j, k par une fonction FX ayant comme paramètres d'entrée les variables d'état j, k, le secret KI, le nombre aléatoire rand, et un nombre CODE omis dans l'option A, ainsi qu'éventuellement une fonction de numéro de série SN() liée au moyen d'authentification, soit : (inew, inew, knew) = F,(j, k, KI, CODE, SN(), randx) (équation 2) • calcul, étape S36, d'un second nombre M2,x par une troisième fonction G, ayant comme paramètres d'entrée les variables d'état nouvellement calculées inew, inew, knew et le résultat d'une fonction temporelle p d'un intervalle de temps At entre un temps de référence et le temps d'exécution du calcul du code d'accès, soit : M2,x = Gx(inew, inew, knew, p(At)) (équation 3) • calcul, étape S38, du code d'accès par une fonction concatx(M1,x, M2,x, randx) permettant de générer M1,x, M2,x, randx à partir du code d'accès. concatx est une fonction bijective de concaténation de ses paramètres d'entrée, dont l'inverse est la fonction notée separex. concatx peut, de façon optionnelle, posséder des propriétés cryptographiques telles que la mise en oeuvre d'un algorithme de cryptage à clé symétrique si l'analyse de sécurisation faite dans le cadre d'une implémentation le recommande. D'autre part, concatx peut éventuellement procéder à la concaténation de ses paramètres d'entrée par entrelacement de bits, et ce afin qu'avantageusement, une erreur de saisie du code d'accès par le titulaire n'impacte pas un paramètre d'entrée indépendamment des autres. L'indice x symbolise l'option A, B ou C ainsi Ea correspond à la version de la fonction E utilisée pour l'option A. De façon générale, les fonctions Ex, Fx et Gx sont des fonctions à sens unique c'est-à-dire que la connaissance du résultat ne permet pas de remonter aux paramètres d'entrée. Les fonctions de hachage sont des exemples de fonction à sens unique bien connus en cryptographie. Les fonctions Ex, Fx et Gx ne sont pas secrètes (elles sont notamment connues du moyen d'authentification et de l'entité d'authentification). Les fonctions Ex servent en particulier à vérifier que l'émetteur du code d'accès dispose bien du moyen d'authentification. Chaque étape va maintenant être décrite en détail, en particulier dans ses particularités de fonctionnement en fonction du type d'option choisi. Pour l'équation 1, Ea et Eb ne sont fonction ni de i ni de j, Ec n'est fonction d'aucune des variables d'état, c'est-à-dire ni de i ni de j ni de k. Il est à noter que si Ea ou Eb étaient fonction de j, il serait possible, après une tentative d'attaque infructueuse sur l'option B, de faire une attaque en force brute du secret personnel du titulaire, par itération multiple sur l'état interne initial. Cette attaque ne serait pas détectable par l'entité d'authentification puisque, j ayant été mis à jour par l'entité d'authentification suite à la première tentative infructueuse comme il sera vu par la suite, MM1 est inexact tant que le secret personnel utilisé pour l'attaque est inexact. D'autre part, si Ea était fonction de j, la désynchronisation de cet état interne serait dommageable à l'usage du titulaire (risque de perte d'une étape). De même, si Ec était fonction de k, la désynchronisation de cet état interne serait dommageable à l'usage du titulaire (risque de perte d'une étape). A contrario, il n'est pas gênant que Ec ne soit pas fonction de k, puisque • pour que MM1 soit exact pour l'option C en cas de transmission via le client d'authentification, il faut que ce soit le client d'authentification du titulaire ; et • il n'est pas possible pour un attaquant de tester une valeur du secret personnel du titulaire avec l'option C sans disposer du client d'authentification du titulaire. Pour l'équation 2, les fonctions FX servent à la mise à jour des états internes i, j et k avec la particularité suivante. Fa renvoie une valeur simple et ne met à jour que l'état interne i. Fb renvoie un couple de valeurs et ne met à jour que i et j. Fc renvoi un triplet de valeurs et met à jour i, j et k. Par ailleurs, Fa n'est pas fonction de i et Fb n'est fonction ni de i ni de j, Fc n'est fonction ni de i, ni de j, ni de k. Autrement dit, les fonctions FX n'ont pas en paramètre d'entrée la(es) variable(s) d'état qu'elles mettent à jour. Il est avantageux que la mise à jour ait lieu avant le calcul du code d'accès afin de minimiser les conséquences d'une désynchronisation pour le titulaire. Comme on le verra ci-dessous, le moyen d'authentification met à jour ses états internes inconditionnellement lors de chaque génération de code d'accès, alors que l'entité d'authentification ne met à jour, en général, les états internes correspondants que si l'authentification est réussie. Le nombre CODE correspond à une constante e ou à une valeur hachée du code secret c saisi par l'utilisateur lors de l'utilisation des modes B ou C. Il est à noter qu'avec l'option A, la fonction Fa n'utilise pas nécessairement e comme paramètre. La mise à jour des états internes se fait donc à la fois • d'une façon aléatoire (usage de randX) observable via le code d'accès transmis ; • d'une façon déterministe mais secrète par l'usage des secrets K1 et c, voire j et k, mais non-observable via le code d'accès transmis Ainsi, • la mise à jour correcte de i avec l'option A nécessite la connaissance de j, k et K1 (les arguments secrets de Fa) ; • la mise à jour correcte de i et j avec l'option B nécessite la connaissance de k, K1 et c ; • la mise à jour correcte de i, j et k avec l'option C nécessite la connaissance de K1, K3 et c. Concernant l'équation 3, les fonctions GX sont à sens unique et dépendent toutes des mêmes arguments inew, Jnew, knew et p(At). La seule contrainte supplémentaire portant sur le choix des fonctions FX et GX est que leur composition multiple Gx(n) o FX(n) o GX(n_1) o FX(n_l) o ... ne converge pas vers un point fixe (ou un cycle) quelle que soit la suite (x(n), x(n-1), ...) sélectionnée par les usages du titulaire. Cette contrainte n'en est pas vraiment une si on utilise des fonctions de hachage sûres (éventuellement tronquées) en tant que fonctions à sens unique, telles que MD5, SHA256, etc. Il convient d'ailleurs de noter que les arguments de ces fonctions ne convergent pas sur un sous-ensemble quelconque car on introduit un nombre aléatoire randX à chaque génération d'un code d'accès, et donc que les résultats de ces fonctions n'ont guère de risque de converger sur une valeur ou sur un cycle de valeurs si la composition des fonctions ne converge pas elle-même au sens fonctionnel. La valeur At est définie comme l'intervalle de temps séparant une demande de code d'accès précédente tref et la demande actuelle t. La fonction p est une fonction de At définie à partir d'une seconde fonction À de la façon suivante : À(At)=E(At/62) mod N2 (équation 4) p(At)=À(At) si À(At) yM, et p(At)=À(At)+6 sinon (équation 5) où yM, 62, N2 et a sont des entiers strictement positifs. 62 est le pas de codage et 62.N2 est la pseudo période de À. En pratique, N2 peut être choisi arbitrairement grand, par exemple comme le plus grand entier représentable par le moyen d'authentification, et peut donc être omis dans les calculs ci-dessous. E() désigne ici l'arrondi à l'entier inférieur. a est choisi arbitrairement et suffisamment grand, c'est-à-dire supérieur à yM+R, où yM et R sont des entiers strictements positifs définis précisément dans la suite de cette description. Au vu des équations 1 à 3, on conçoit qu'au plus 4 paramètres sont mis à jour à chaque demande de code d'accès : i, j, k et tref qui prend comme valeur le temps correspondant à cette demande de code d'accès. Aussi, si le moyen d'authentification détecte que le code d'accès n'a pas été utilisé, par exemple parce que l'utilisateur a appuyé sur une touche d'annulation, ces 4 paramètres sont maintenus dans leur état antérieur à la demande de code d'accès. Dans le cas de l'option C, figure 4,le code d'accès généré par le moyen d'authentification est transféré au client d'authentification. Le client d'authentification calcule, étape S40, les nombres (MI ; M2 ; rand) en appliquant la fonction separec au code d'accès, puis calcule les nombres : • M'1, étape S42, comme valant Ed(K3 ; Ml,,), c'est-à-dire Ed(k ; K~ ; K3 ; randc) si le code d'accès a été saisi correctement et qu'il s'agit bien du client d'authentification du titulaire ; • M'2, étape S44, comme valant Gd(K3 ; M2,c), c'est-à-dire Gd(inew ; jnew ; knew ; K3 ; p(At)) sous les mêmes conditions. Le code d'accès CA2 transmis par le client d'authentification est alors concatc(M'i ; M'2 ; rand) , étape S46. K3 est le secret associé au client d'authentification. Le code d'accès étant transmis par des moyens électroniques à l'entité d'authentification, il n'y a pas de limitation contraignante sur la taille du code d'accès calculé et transmis par le client d'authentification. De ce fait, les fonctions Gd et Ed peuvent être, selon les implémentations de l'invention, soit des fonctions à sens unique connues à la fois du client d'authentification et de l'entité d'authentification, soit des fonctions de signature du message M'1, respectivement M'2 , avec une méthode de cryptographie asymétrique où K3 joue le rôle de clé privée sK3. Dans ce second cas, l'entité d'authentification possède la clé publique pK3 associée à sK3 afin de vérifier la validité des signatures, c'est-à-dire ici, celle du code d'accès transmis. L'avantage de la cryptographie asymétrique, par rapport à l'emploi de fonctions à sens unique et de secrets connus du client d'authentification et de l'entité d'authentification, réside dans le fait qu'il est sûr même en cas de compromission de l'entité d'authentification (l'entité d'authentification n'a pas les moyens de générer M'l ni M'2, mais uniquement de vérifier qu'ils sont corrects). Moyennant la sécurisation adéquate mais classique du gestionnaire d'authentification, on peut donc faire reposer sur l'authentification par l'option C des opérations très sensibles pour la sécurité globale du système (par exemple, changement du code secret personnel du titulaire, gestion du moyen d'authentification du titulaire, etc.). L'utilisation de la cryptographie asymétrique peut être étendue aux options A et B dans des implémentations de l'invention où le code d'accès généré par le moyen d'authentification est transmis à l'entité d'authentification sans saisie ni dictée par le titulaire, ou avec des méthodes de signature jugées suffisamment courtes dans le cadre d'une implémentation pour que le code d'accès généré puisse être transmis à l'entité d'authentification par le titulaire. L'entité d'authentification vérifie, figure 5, le code d'accès reçu en effectuant les étapes suivantes : • mesure, étape S50, du temps courant de l'horloge système de l'entité d'authentification et on note tt sa valeur ; • boucle, étape S52, sur le type d'option sachant que si le code d'accès a été transmis par le client d'authentification, la boucle se réduit à l'option C. Sinon, l'entité teste l'option B, puis A, puis C. o détermination, étape S54, de CODE en fonction de l'option. Pour l'option A, CODE n'est pas utilisé ou est une constante et pour les autres options c'est la valeur hachée du code secret ; o calcul, étape S56, des nombres (MM1,,, MM2,X, rrandx) en appliquant la fonction separex au code d'accès ; o calcul, étape S58, des valeurs MM'1 X, MM'2,, en utilisant les fonctions EX et G, et les secrets détenus par l'entité d'authentification, secrets symétriques de ceux détenus par le moyen d'authentification et, pour l'option C, le client d'authentification. On utilise également l'intervalle de temps Att entre un temps de référence possible ttref de l'entité d'authentification et le temps tt et on calcule les nouvelles variables d'état ii, jj et kk avec la fonction FX , o vérification, étapes S60, S62, que MM1,X, MM2,X et MM'1,X, MM'2,X correspondent. Cette étape et la précédente correspondent classiquement à la vérification d'un code dans de la cryptographie symétrique à clé secrète ; o si le code d'accès est validé, outre l'accès au service, l'entité d'authentification met à jour, étape S64, ses variables internes ii, jj, kk et ttref de façon à rester synchronisée avec le moyen d'authentification. On conçoit qu'un élément particulièrement sensible du système est le maintien de la synchronisation des moyens d'authentification avec l'entité d'authentification. Pour cela, sera expliqué dans un premier temps le problème de la synchronisation des horloges et donc des temps tref, ttref, t et tt permettant d'obtenir un intervalle de temps ayant une valeur commune entre les deux. En particulier, il est avantageux que le système soit robuste à des décalages entre les horloges. Soient • Pmin le délai minimum de transmission d'un code d'accès à l'entité d'authentification soit le temps de saisie par le titulaire plus le délai de transmission, dans une implémentation où le titulaire doit saisir le code d'accès ; • Pval le délai pendant lequel un code d'accès généré est considéré comme valide ; • Pmax le délai, supérieur à Pval, au-delà duquel il est raisonnable de penser que le titulaire ne transmettra pas le code d'accès s'il ne l'a pas fait auparavant, sachant que ce code n'est plus valide ; • tm le délai minimal, et tM le délai maximal où il est raisonnable de penser que le titulaire fera une seconde tentative d'authentification si la première a échoué. Notons • a = E((Pval - Pmin) / 62) ; • 13 = E((Pmax - Pmin) / 62); • ym = E(tm / 62); • yM = E(tm / b2) On a At = Att + Ao- At, où At = tt ù t et Ao = ttref ù tref. On en déduit que À(Èt) = À(Ètt) + E(È), où A = (r + Ao- At) / 62 et 0 r On suppose Pmin yM+R, la troisième situation examinée ci-dessus est parfaitement distinguable des deux autres. Si cette condition n'était pas remplie, deux des situations ci-dessus pourraient ne pas être distinguables dans certains cas, amenant ainsi l'entité d'authentification à décider arbitrairement si le code d'accès est valide quoi que non synchronisé ou bien saisi hors délai donc non valide, et donc également à décider arbitrairement d'effectuer ou non la correction de ttref. La précision absolue de l'horloge du moyen d'authentification est inutile, puisque l'on ne s'intéresse qu'à des différences de temps ; de même, le déphasage entre les horloges du moyen d'authentification et de l'entité d'authentification n'a pas d'importance puisqu'il se simplifie dans tous les calculs de différence. La précision relative de l'horloge du moyen d'authentification sur des durées longues n'est pas non plus nécessaire, car soit le titulaire aura utilisé le moyen d'authentification dans cet intervalle, soit - au pire - le premier code d'accès ne sera pas reconnu comme authentique. Il est en revanche important que la précision relative de l'horloge du moyen d'authentification sur une période de l'ordre de celle de l'utilisation � normale � du moyen d'authentification par le titulaire garantisse que le déphasage maximal introduit entre les horloges du moyen d'authentification et de l'entité d'authentification soit au maximum de l'ordre de P,,,,. En pratique, cela ne met aucune contrainte véritable sur cette horloge. Outre les problèmes liés à la synchronisation des horloges résolus par les moyens présentés précédemment, on conçoit que dans un environnement de production, le système doit être également robuste aux erreurs de manipulation et aux tentatives d'attaque qui génèrent des désynchronisations des variables d'état i, j, k tout en préservant la sécurité du code d'accès. Pour cela, dans le mode de réalisation présenté, on utilise un mélange des options A, B et C, la conservation des historiques d'utilisation des codes d'accès et la mise à jour des états i, j, k selon certaines conditions. Le moyen d'authentification possède un drapeau optionB. Si les options B ou C sont employées, le drapeau optionB est mis à la valeur FAUX. Si le moyen d'authentification a connaissance du fait que la tentative d'authentification utilisant le code d'accès généré a échoué pour l'option A (par exemple, le titulaire peut disposer d'une option sur le moyen d'authentification pour indiquer que la tentative d'authentification a échoué), l'état interne optionB est mis à la valeur VRAI. L'option B est forcée (se substituant ainsi à l'option A choisie par le titulaire) dans plusieurs cas : • Echec d'une tentative d'authentification avec l'option A : si la cause de cet échec était une désynchronisation de l'état interne j entre le moyen d'authentification et l'entité d'authentification, l'emploi de l'option B permet la resynchronisation. Ce cas n'est pas contrôlé par l'entité d'authentification (pas de rejet d'un code d'accès généré avec l'option A après un échec d'authentification quelle que soit l'option) ; • Nombre d'usages consécutifs de l'option A excédant un seuil fixé à la conception du système. Cela vise à limiter le nombre de codes d'accès valides qu'il est possible de générer sans saisir le secret personnel du titulaire, notamment en cas de vol du moyen d'authentification. Optionnellement et en complément, l'accès au moyen d'authentification peut être restreint par un mot de passe simple. Un second but de ce contrôle est de garantir un rythme de rafraîchissement minimal pour l'état interne j. Un contrôle similaire est effectué par l'entité d'authentification, avec un seuil légèrement moins contraignant afin de ne pas provoquer d'échec de l'authentification au cas où l'option B ne serait pas forcée assez tôt du côté du moyen d'authentification ; • Nombre d'usages consécutifs de l'option A dans un laps de temps fixé supérieur à un seuil fixé à la conception du système. Le but est similaire, ce contrôle visant plus spécifiquement à bloquer le � stockage préventif � de codes d'accès avec l'option A en cas de vol du moyen d'authentification. Ce contrôle est également réalisé par l'entité d'authentification qui vérifie que le nombre de tentatives d'authentification consécutives faites avec des codes d'accès authentiques générés pour l'option A tels que ÀE [y,,, ; yM] n'excède pas un seuil fixé à la conception du système. En cas d'échecs successifs û et en nombre suffisant û de l'option B qui ne peuvent résulter que d'erreurs répétées sur la saisie de l'identifiant du titulaire ou d'un blocage de l'option B, le moyen d'authentification propose au titulaire de régénérer les secrets du moyen d'authentification de façon à débloquer l'option B. Le nombre de possibilités de déblocages avec 2 facteurs d'authentification (moyen d'authentification et code secret personnel du titulaire) est lui aussi contrôlé par l'entité d'authentification grâce à l'état interne erreurcodeB et limité à une valeur légèrement supérieure à celle de seuilcodeB. Au-delà de cette valeur, l'option B ne peut plus être débloquée grâce au seul moyen d'authentification, le titulaire doit pour ce faire utiliser l'option C et le client d'authentification. Les contrôles présentés ci-dessus permettent en particulier - ce n'est pas leur seul objectif û de contrôler le rythme de rafraîchissement des états internes. Il faut de plus veiller à ce que la probabilité qu'un code d'accès déjà généré puisse être de nouveau généré par le moyen d'authentification soit infime, et à le rejeter si un tel code est proposé pour une authentification car il s'agira de façon presque sûre d'une tentative d'attaque. Pour l'option C, le nombre de triplets (i,j,k) possibles - c'est-à-dire le nombre de codes d'accès en supposant KI, c, À(At) fixés - est égal, si la fonction Gc et la génération des nombres aléatoires randc sont bien implémentées, à Randc le nombre de mots aléatoires randc possibles. Les implémentations doivent donc, d'une part choisir Randc suffisamment grand, d'autre part contrôler au niveau du client d'authentification que la fréquence de renouvellement du code secret c est suffisante, par exemple en forçant un renouvellement de c après un nombre de connexions au client d'authentification égal à Randc / Pc, où Pc est un seuil à fixer à la conception du système. Si le moyen d'authentification ne stocke pas les valeurs de randc utilisées entre deux renouvellements de c, Pc devra être fixé de telle sorte que la probabilité de générer un deuxième fois la même valeur de randc soit infime. Le � théorème des anniversaires � indique que ce seuil est faible, aussi, dans des implémentations où Randc est lui-même relativement faible, et pour éviter une fréquence de renouvellement trop rapide de c, on préfèrera utiliser pour la génération de randc un générateur pseudo-aléatoire dont les caractéristiques garantissent que l'on peut générer une grande partie des Randc valeurs de randc possibles sans risque de collision. L'entité d'authentification stocke alors les codes d'accès générés avec l'option C (ou les mots aléatoires randc) entre deux renouvellements de c et refuse un code d'accès déjà utilisé (ou un code d'accès généré avec un mot aléatoire randc déjà utilisé). Pour l'option B, le nombre de couples (i,j) possibles - c'est-à-dire le nombre de codes d'accès en supposant k, K1, c, À(At) fixés - est égal, si la fonction Gb et la génération des nombres aléatoires randB sont bien implémentées, à RandB le nombre de mots aléatoires randB possibles. Les implémentations doivent donc, d'une part choisir RandB suffisamment grand, d'autre part contrôler que la fréquence de renouvellement de k û a minima - est suffisante. L'entité d'authentification stocke alors les codes d'accès générés avec l'option B (ou les mots aléatoires randB) entre deux renouvellements de k et refuse un code d'accès déjà utilisé (ou un code d'accès généré avec un mot aléatoire randB déjà utilisé). Pour l'option A, le nombre d'états internes i possibles - c'est-à-dire le nombre de codes d'accès en supposant j, k, K1, c, À(At) fixés - est égal, si la fonction Ga et la génération des nombres aléatoires randA sont bien implémentées, à RandA le nombre de mots aléatoires randA possibles. Les implémentations choisissent donc, d'une part RandA suffisamment grand, et contrôlent d'autre part que la fréquence de renouvellement de j û a minima - est suffisante, ce qui est fait ci-dessus par un des mécanismes de contrôle forçant l'emploi de l'option B. L'entité d'authentification stocke les codes d'accès générés avec l'option A (ou les mots aléatoires randA) entre deux renouvellement de j et refuse un code d'accès déjà utilisé (ou un code d'accès généré avec un mot aléatoire randA déjà utilisé). Ainsi, la synchronisation des états internes i, j, k et tref entre le moyen d'authentification et l'entité d'authentification est assurée par plusieurs moyens : • Le passage à une option �supérieure�, par exemple de l'option A vers l'option B (c'est-à-dire resynchronisant davantage d'états internes parmi i, j, k) en cas d'échec de l'authentification ; • Le stockage par l'entité d'authentification dans une pile de données fl des instants de réception de codes d'accès pour les quels M1 est correct mais M2 est faux ; • La détection de codes d'accès authentiques mais reçus hors délai par l'entité d'authentification, ou ne correspondant pas à l'option nécessaire; • La mise à jour des états internes par l'entité d'authentification conditionnée à la fourniture d'un code d'accès authentique ; • L'autorisation limitée de codes d'accès pour lesquels ÀE [ym ; yM], c'est-à-dire générés tout de suite après un autre code d'accès pour tenir compte du cas où ce premier code d'accès n'a pas été reçu par l'entité d'authentification. Cette palette de moyens permet d'éviter toute désynchronisation en cas d'erreur de manipulation unitaire par le titulaire, à savoir • la non transmission d'un code d'accès généré quand le titulaire l'indique au moyen d'authentification, si une telle option existe ; • la transmission incorrecte du code d'accès généré ou de l'identifiant du titulaire pour le service requérant l'authentification. Dans ces cas, l'entité d'authentification ne reçoit pas le code d'accès, ou ne le reconnaît pas comme émanant du titulaire. • la saisie d'un code personnel incorrect pour l'emploi des options B, ou C • la transmission hors délai d'un code d'accès • l'emploi d'une option erronée En cas de désynchronisation résultant d'une erreur de manipulation multiple, la resynchronisation est garantie, dans le pire cas, lors de la seconde tentative d'authentification correcte réalisée par le titulaire. Cette palette de moyens permet d'autre part d'éviter toute désynchronisation du fait d'une tentative d'accès • si l'attaquant possède le moyen d'authentification ou un duplicata, mais pas le secret personnel du titulaire ou le client d'authentification du titulaire, y compris pour l'option A car la pile de données fl n'est pas vidée en cas de réussite de l'authentification avec l'option A ; et a fortiori • si l'attaquant ne possède pas le moyen d'authentification. On conçoit cependant qu'une désynchronisation éventuelle ainsi que la protection contre les attaques font que, du côté de l'entité d'authentification, l'algorithme de vérification du code d'accès est modifié pour prendre en compte ces aléas. On fait varier x, n, À dans des boucles algorithmiques concentriques (la plus profonde étant celle sur x, puis sur n, puis sur À) dans leur ensemble de définition respectif : • x désigne l'option de génération de code d'accès, parmi la seule option C si le code d'accès a été transmis par le client d'authentification, et successivement B, A, C, sinon ; • l'indice n de Attn = tt-ttn,n pour chaque valeur ttn,n stockée dans Fi, en commençant par la valeur stockée le plus récemment (désignée jusqu'ici comme ttref); • À avec les valeurs entières positives ou nulles successives parmi o [6+À(Attn)-a ; 6+À(Attn)+a+1 ] o [Ym ; YM] pour les options B et C o [6+À(Attn)+a+2 ; 6+À(Attn)+13] uniquement dans le cas où une correction de ttref a été effectuée lors de l'une des deux tentatives d'authentification précédentes où le code d'accès a été reconnu authentique o [6+À(Attn)- 13 ; 6+À(Attn)-a-1 ] Malgré la complexité apparente, le nombre de calculs effectués par l'entité d'authentification reste très limité en pratique pour un usage normal du moyen d'authentification : • 1 à 3 calculs de MM1,X pour déterminer l'option x employée pour générer le code d'accès car on ne regarde pas les options suivantes dès lors qu'une concordance pour MM1,,a été trouvée ; • 1 à 2a+1 calculs de MM2,x,n,À pour déterminer la valeur correcte de À (un choix de paramètres tels que a=1 est possible et de ce fait pertinent) Les calculs peuvent être plus nombreux : • en cas de saisie hors délai du code d'accès : jusqu'à 13-a calculs de MM2,,,n,À supplémentaires, c'est-à-dire 2 pour un choix typique des paramètres ; • en cas d'utilisation du moyen d'authentification par l'attaquant pour générer des codes d'accès successifs avec l'option A : jusqu'à (2a+1)*seuilA calculs supplémentaires où seuilA est le nombre maximal de code d'accès successifs générés avec l'option A acceptés par l'entité d'authentification ; • en cas de tentatives d'attaques après vol du moyen d'authentification, ou en cas de saisie incorrecte du code secret personnel par le titulaire : jusqu'à (2a+1)*(seuilcodeA+seuilcodeB) calculs supplémentaires, voire (2a+1)*(seuilcodeA+seuilcodeB+seuilcodec) si l'utilisateur, attaquant ou titulaire, dispose également du client d'authentification du titulaire. seuilcodex désigne le nombre maximal d'erreurs consécutives (au sein de l'option x) acceptées par l'entité d'authentification avant de bloquer l'usage de cette option ; Ces nombres se multiplient lorsque les causes se cumulent, mais comme elles sont indépendantes les unes des autres, la probabilité d'occurrence de tels cumuls est faible. En tout état de cause, la seule cause de calculs supplémentaires pouvant être directement induite par un attaquant disposant du moyen d'authentification du titulaire est celle conduisant à réaliser dans le pire cas (2a+1)*(seuilcodeA+seuilcodeB) calculs supplémentaires, ce qui est insuffisant pour mener une attaque en déni de service sur le système d'authentification objet de cette invention s'il est correctement dimensionné. A l'intérieur de ces boucles, on effectue les étapes suivantes : • CODE prend la valeur e pour l'option A, et H(cc), la valeur hachée du code secret, pour les options B et C. • On calcule les nombres (MM1,X ; MM2,X ; rrandX) en appliquant la fonction separex au code d'accès. Lorsque le code d'accès est obtenu par l'entité d'authentification via le client d'authentification, la fonction separec fournit MM'1 et MM'2 ; Mn et MM2 sont alors calculés à partir respectivement de MM'1 et MM'2 en utilisant la méthode de cryptographie asymétrique et la clé publique pK3 ou le secret symétrique K3. • Un nombre entier noté MM'1,, est calculé comme valant EX(kk ; K~ ; rrandX) • Vérification de la validité de MM1,X. o seuil est initialisé à seuilmin ; o si tt - ttlast Le premier point résulte principalement de l'arrangement des fonctions EX, F, et GX, du principe de mise à jour des états internes avant le calcul de M2, de l'utilisation de la pile de données n, et de quelques mécanismes optionnels du point de vue de la sécurité mais améliorant nettement la simplicité pour le titulaire tels que les options de confirmation de saisie sur le moyen d'authentification, l'emploi forcé de l'option B, la distinction entre code d'accès authentique et authentification valide, etc. Le second point s'analyse en plusieurs temps : • un attaquant n'ayant pas eu accès au moyen d'authentification du titulaire, de par l'arrangement et les caractéristiques � à sens unique � des fonctions EX, F, et GX, ne peut déduire absolument aucune information sur les états internes et secrets nécessaires à une authentification ou une tentative d'attaque. Même en se concentrant sur une option unique, et, toutes choses égales par ailleurs c'est-à-dire que le titulaire ne fait aucun usage du moyen d'authentification, il manque toujours à l'attaquant 3 variables, dont au moins 2 peuvent avoir des tailles arbitrairement grandes. Par ailleurs, l'attaque par force brute nécessite une interaction avec l'entité d'authentification qui est seule à même de fournir de l'information sur la validité d'un code d'accès. Or il est possible pour celle-ci de limiter arbitrairement voire complètement la fréquence de ses réponses sans pénaliser pour autant le titulaire du compte ; • un attaquant ayant réalisé un � reverse engineering � du moyen d'authentification a, moyennant quelques difficultés pratiques car il est peu probable que cela puisse se faire à l'insu du titulaire du moyen d'authentification dans la plupart des implémentations de l'invention, accès à l'option A, du moins tant qu'il ne fait pas de tentatives avec l'option B ou que les mécanismes forçant l'emploi de l'option B ne s'activent pas. Les tentatives avec l'option C ne bloquent pas l'accès à l'option A, mais elles n'ont aucune chance d'aboutir puisqu'il manque également K3 à l'attaquant. Le contrôle strict permis par les fonctions EX empêche toute tentative d'attaque par force brute du code secret du titulaire, amenant au pire l'attaquant à bloquer û définitivement pour lui, temporairement pour le titulaire û le compte du titulaire. Par ailleurs, l'évolution des états internes du moyen d'authentification est rendue pour l'attaquant à la fois non déterministe grâce à l'emploi d'une valeur aléatoire rand, et non calculable dû à l'emploi de secrets qu'il ne connaît pas et ne peut attaquer ; • un attaquant ayant réalisé un � reverse engineering � du moyen d'authentification et connaissant le code secret personnel du titulaire du fait d'une négligence importante de celui-ci a accès à toutes les ressources auxquelles a normalement accès le titulaire, hormis celles nécessitant l'authentification au client d'authentification. L'utilisation par le titulaire de l'option C, s'il dispose toujours du moyen d'authentification, permet toutefois, si cela a encore un sens, de rendre définitivement inopérant le duplicata réalisé par l'attaquant ; • une hypothèse importante utilisée pour l'analyse en termes de sécurité faite ici est que le � reverse engineering � du moyen d'authentification du titulaire nécessite que l'attaquant vole ou emprunte temporairement ledit moyen d'authentification à sa victime, ce qui rend cette opération peu fréquente. Les implémentations de l'invention doivent analyser si cette condition est réalisée ou non dans le cadre de l'implémentation, et le cas échéant y apporter des parades (par exemple, installation de logiciel de sécurité de type pare-feu de la plate-forme du moyen d'authentification). Le non-respect de cette hypothèse rend d'une part plus probable la réalisation de � reverse engineering �, et conduit d'autre part à des risques de blocage/déblocage des comptes des titulaires concernés, mais pas à des situations où la sécurité du compte du titulaire est en jeu. L'invention a été illustrée et décrite en détail dans les dessins et la description précédente. Celle-ci doit être considérée comme illustrative et donnée à titre d'exemple et non comme limitant l'invention à cette seule description. De nombreuses variantes de réalisation sont possibles. Dans une première variante, le système comporte une option B' similaire dans son fonctionnement à l'option B. En cas de désynchronisation de k, on ne peut pas demander à l'utilisateur d'utiliser l'option C car elle n'est pas faite pour cela et on ne peut pas non plus le faire de façon � masquée � puisqu'il faut pouvoir distinguer les options du côté de l'entité d'authentification. L'option B' est alors implémentée par le moyen et l'entité d'authentification comme une option similaire à c en particulier pour les mises à jour de variables mais utilisée comme une option B, c'est-à-dire avec saisie d'un code secret par le titulaire, mais sans le client d'authentification. En cas d'échec de l'authentification avec l'option B, si le moyen d'authentification en obtient l'information, l'usage de l'option B' est forcée. L'option B' est également forcée pour garantir un rythme de rafraîchissement minimal de l'état interne k. Par ailleurs, l'entité d'authentification contrôle que l'usage de l'option B' est justifié. Dans une deuxième variante, les fonctions GX utilisées pour le calcul du mot M2 sont en outre fonction des états internes non mis à jour. Plus précisément, • Gb est fonction de j (en plus de inew, inew et knew) • Gb, est fonction de k (en plus de inew, inew et knew) • Gc est fonction de j et de k (en plus de inew, inew et knew) Le but de cette variante est que le code secret personnel d'un utilisateur ne puisse pas faire l'objet d'une attaque en force brute, même en cas de � reverse engineering � du moyen d'authentification par l'attaquant. Supposons en effet que ce reverse engineering ait eu lieu, l'attaquant connaît donc notamment KI, SN, et (i, j, k) à un moment donné. Si l'attaquant parvient par la suite à s'emparer d'un code d'accès valide calculé par le titulaire avec l'option C, il peut en théorie facilement réaliser une attaque par force brute du code secret personnel du titulaire, puisque le code d'accès recueilli ne dépend que de KI et SN (obtenus par reverse engineering), randc (contenu dans le code d'accès), p(At) (sur lequel il peut faire des hypothèses) et H(c). L'attaque consiste à essayer de reproduire la valeur du code d'accès en faisant varier c et p(Èt), sans transmission à l'entité d'authentification û ni donc de contrôle possible par celle-ci. Si en revanche le code d'accès est - quelque soit l'option employée - fonction d'un ou plusieurs états internes non transmis dans le code d'accès et ne dépendant pas uniquement des valeurs constantes accessibles par reverse engineering, l'attaquant devra de plus les prendre en compte dans son attaque en force brute. Dans une implémentation réelle, le produit du nombre de valeurs possibles de deux états internes par le nombre de codes secrets personnels possibles est beaucoup plus grand (typiquement 21\50 fois plus grand !) que le nombre de codes d'accès (hors éventuellement le mot randX) possibles, ce qui revient à dire que l'attaque en force brute fournira de nombreux résultats (valeurs des états internes et valeurs plausibles de p(Èt)) pour toutes les valeurs possibles de code secret personnel, rendant ainsi sa vraie valeur indiscernable par l'attaquant. Cela est également vrai si l'attaquant fait l'hypothèse que le code d'accès qu'il a recueilli a été généré juste après l'opération de reverse engineering, c'est-à-dire fait une attaque en faisant varier les mots randX (plus petits que les états internes inconnus) ; dans des implémentations typiques de cette variante, au bout de 2 à 3 étapes de génération de code d'accès après le reverse engineering, le code secret personnel devient indiscernable, une attaque par force brute produisant de nombreux résultats pour chaque valeur possible du code secret personnel. Si les fonctions FX utilisées sont � suffisamment injectives �, il est même assez probable que dès la première étape, l'attaque par force brute produise trop de résultats (typiquement 5) pour être directement utilisable par l'attaquant. La seule possibilité d'attaque par force brute restante consiste donc à ce que l'attaquant intercepte le premier code d'accès calculé par le titulaire après le reverse engineering ou, de façon équivalente, à ce qu'il intercepte tous les codes d'accès (les mots randX) générés entre le reverse engineering et l'attaque par force brute, chacune de ces situations étant possible techniquement mais peu réaliste. Enfin, l'emploi des états internes non mis à jour tel que présenté ne conduit pas à des situations de désynchronisation entre le moyen d'authentification et l'entité d'authentification lorsqu'il est couplé à un système où l'option B est forcée en cas d'échec de l'authentification avec l'option A, et l'option B' est forcée en cas d'échec de l'authentification avec l'option B. Dans une troisième variante, le moyen d'authentification peut générer soit un code d'accès dédié à un service s et uniquement valide pour l'authentification à celui-ci, soit un code d'accès commun valide pour l'ensemble des services ne requérant pas un code d'accès dédié. Le nombre entier ms est défini ou calculé comme : • la constante e dans le cas où le titulaire a fait le choix par défaut d'un code d'accès commun, cette constante pouvant être omise, • l'entier cs dans le cas où le titulaire a fait le choix d'un code d'accès dédié au service s. Dans cette variante, l'algorithme de vérification de l'entité d'authentification comporte une boucle intermédiaire supplémentaire entre la boucle des options et la boucle des intervalles de temps basée sur les valeurs possibles de ms où s est l'indice désignant un service utilisant le système d'authentification, en commençant par le service dont émane le code d'accès en cours d'analyse, c'est-à-dire e, ..., ~s,.... Ainsi le nombre de calculs peut augmenter jusqu'à (2a+1)*S calculs supplémentaires en cas d'erreur sur le choix du service pour lequel un code d'accès dédié doit être fourni, S étant le nombre de tels services déclarés dans le compte du titulaire. Si, après avoir vérifié que et M'2,X sont valides, s ne correspond pas au service dont émane le code d'accès, l'authentification est rejetée, mais l'entité d'authentification met à jour ses états internes comme si l'authentification était correcte, de façon à rester synchronisée avec le moyen d'authentification. Cela est notamment possible si l'entier ms est utilisé par les fonctions GX mais pas par les fonctions F. Dans une quatrième variante, pour un service dédié, l'entité d'authentification lui fournit un code temporaire, propre au service et au moyen d'authentification du titulaire, que le titulaire peut comparer à celui s'affichant sur son moyen d'authentification avant de fournir un code d'accès. L'entité d'authentification calcule Att comme tt - ttref où tt désigne la valeur mesurée par l'horloge interne de l'entité d'authentification et ttref la valeur stockée le plus récemment dans la pile de données n. Le code d'authentification mutuelle fourni au titulaire pour le service s est calculé comme D(jj ; kk ; K~ ; SN ; ms ; p(Att)). Le moyen d'authentification peut alors afficher un code devant reproduire de façon exacte celui qui est fourni par le service s requérant l'authentification, notamment lorsque s requiert un code d'accès dédié, et ce afin que le titulaire du moyen d'authentification obtienne la certitude qu'il s'authentifie sur s et non sur un service cherchant à imiter s. Pour cela, on calcule, de façon parallèle au calcul de l'entité d'authentification, At comme t - tref où t désigne la valeur mesurée par 15 l'horloge interne du moyen d'authentification et le code d'authentification mutuelle affiché par le moyen d'authentification pour le service s comme D(j ; k ; K1 ; SN() ; ms ; p(At)). D est une fonction à sens unique. p est une fonction de codage de At définie ainsi : p(At) est l'unique 20 nombre de la forme q.n6M+6' dans l'intervalle [At ; At+n6M[, où • q est un nombre entier positif ou nul ; • n est un nombre positif ou nul choisi à la conception du système ; • bM = Qval+Pval , bm = Qmin+Pmin , bQ = Qval-Amin , bP = Pval-Pmin ; • 0 On a ttref ù tref =9-F(Q0 et tùtt =-(p+(pt où (poE [Pmin ; Pval], (ptE [Qmin ; Qval], et (p est le déphasage quelconque, supposé constant, mais pouvant varier sporadiquement, entre les horloges de l'entité d'authentification et du moyen d'authentification. On en déduit que At-AU= (po+(pt donc At-Me [6m; 6M]. Pour (pot= (po+ (Pt donné, la probabilité p((pot) que p(Att) et p(At) soient différents est égale à (pot /n6M. En supposant (po et (pt équi-répartis sur leur domaine de définition respectif, la probabilité que p(Att) et p(At) soient différents est égale à l'intégrale sur [Pmin ; Pval]x[Qmin ; Qval] de p((pot)/(6p.6Q), c'est-à-dire (1 +bm/6M)/2n. Ce résultat est sous-estimé pour un individu donné, puisque après une période d'adaptation au fonctionnement du moyen d'authentification, le comportement tend à devenir davantage répétitif (les écarts (po et (pt ne sont plus équi-répartis) et la probabilité que p(Att) et p(At) soient différents est plus faible que celle qui a été calculé ci-dessus. Un choix de n élevé améliore la probabilité que le code d'authentification mutuelle soit correct ; il augmente également la période durant laquelle ce code est constant. Ce n'est pas un problème réel car d'une part, il s'agit de quelques minutes pour obtenir des probabilités supérieures à 0,95 que les codes d'authentification mutuelle affiché et fourni soient identiques, d'autre part parce qu'un service cherchant à imiter s ne peut savoir à l'avance que le titulaire va chercher à s'authentifier dans une période donnée de quelques minutes. L'alternative radicale pour contourner ce résultat probable et non certain consiste à ce que le code d'authentification mutuelle ait, comme le code d'accès, une partie aléatoire (� challenge �), et qu'il soit saisi par le titulaire sur le moyen d'authentification, qui l'accepte ou non. Le procédé est sûr, mais il est beaucoup plus complexe pour le titulaire, nécessitant d'abord une saisie sur le moyen d'authentification, puis sur le service requérant l'authentification, probablement trop complexe pour une application grand public. Lorsque les codes d'authentification mutuelle fourni par le service s et affiché par le moyen d'authentification sont identiques, le titulaire peut saisir le code d'accès lui permettant de s'identifier auprès du service s. Lorsque ce n'est pas le cas (probabilité inférieure à (1+b,,,/6M)/2n ou désynchronisation du moyen d'authentification et de l'entité d'authentification), le titulaire a le choix entre • � rafraîchir � les codes fourni par le service et affiché par le moyen d'authentification. De nouveaux codes sont calculés et fourni/affiché avec d'une part une � phase � 6' inversée, d'autre part, comme temps de référence pour le calcul de At et Att, l'instant de calcul du premier code d'authentification mutuelle car ce temps de référence ne change pas en cas de nouveau rafraîchissement des codes. Cette opération permet de régler le cas d'une désynchronisation de At entre le moyen d'authentification et l'entité d'authentification, ainsi que le cas où p(Att) et p(At) sont différents bien qu'il n'y ait pas de désynchronisation. Dans ce dernier cas, le problème peut subsister avec une probabilité (1+b,,,/6M)/2n puisque At et Att ont été mis à jour. Une nouvelle opération de rafraîchissement û changeant la phase mais ne changeant plus les temps de référence û résoudra le problème de façon certaine ; cette opération ne résout en revanche pas le cas d'un désynchronisation d'états internes (j, k ou 6') entre le moyen d'authentification et l'entité d'authentification, le titulaire doit donc s'en remettre à l'option ci-dessous si la différence entre codes d'authentification fourni/affiché persiste lors de rafraîchissements successifs : au-delà du premier rafraîchissement, ces codes alternent entre 2 valeurs • obtenir un code d'accès factice affiché par le moyen d'authentification, généré avec une option B" similaire à B', ne permettant pas de réussir l'authentification, mais resynchronisant les états internes entre le moyen d'authentification et l'entité d'authentification (b' est par exemple resynchronisé avec la parité de randB,,, alors que At, j et k sont resynchronisés par l'option B" du protocole d'authentification sous réserve de la saisie correcte du secret personnel du titulaire) et permettant par là même de fournir/afficher des codes d'authentification mutuelle identiques. La prise en compte de B" par l'entité d'authentification est identique en tout point à celle de B' sauf pour la décision d'accepter l'authentification en cas de code authentique. Dans une cinquième variante, le moyen d'authentification peut afficher un code fonction • d'un argument saisi par le titulaire ; • des états internes i, j, k ; • de SN() ; • du secret K1, voire de H(c) s'il est de nouveau saisi par le titulaire. Ce code peut posséder différentes fonctions et formats d'affichage, le format d'affichage pouvant lui-même être choisi parmi plusieurs formats prédéfinis grâce une information contenue dans l'argument saisi par l'utilisateur, ou obtenue à partir de calculs sur celui-ci. Par exemple, après une authentification réussie auprès d'un service, le service peut, pour protéger une opération particulièrement sensible contre une attaque � Man ln The Middle � potentiellement déjà réussie mais indétectable, fournir au titulaire une adresse IP qui aura été préalablement codée et changée de format grâce à un masque. Ce masque est fourni par l'entité d'authentification et est une fonction à sens unique des états internes et secrets propres au titulaire et à son moyen d'authentification. Le moyen d'authentification affiche alors � en clair � au titulaire l'adresse IP qu'il doit saisir dans son navigateur afin de poursuivre l'opération, une nouvelle authentification pouvant être requise par le service, puisqu'il s'agit a priori d'une nouvelle session. Le moyen d'authentification possède, sans qu'il soit nécessaire de lui transmettre d'information qui serait susceptible d'être interceptée par l'attaquant, tous les éléments lui permettant de calculer le masque ou son inverse, et donc de l'appliquer sur l'argument saisi afin de retrouver l'information originelle. Alternativement, si l'attaque � Man in The Middle � est plus générale et touche les routeurs d'un fournisseur d'accès et pas uniquement un � cache DNS � utilisé par le titulaire, le code multifonction affiché par le moyen d'authentification peut être utilisé pour mettre en oeuvre une session cryptée entre le navigateur web du titulaire et le site du fournisseur de service. Dans une sixième variante, le secret K3 (ou le couple pK3/sK3) stocké dans le client d'authentification est crypté grâce à une clé connue de l'entité d'authentification, mise à jour à chaque authentification réussie du client d'authentification, et fournie au client d'authentification si et seulement si le code d'accès (en général, généré avec l'option C) transmis est correct. Il est à noter que l'implémentation présentée repose sur un canal de transmission transparent pour le code d'accès : une donnée en entrée est fournie au destinataire dans son état initial, quelque soit les transformations qu'elle ait pu subir lors de son transport. L'homme du métier sait, sans difficulté, adapter cette implémentation à un canal semi-transparent tel que l'utilisation du mode d'authentification http-digest du protocole http. Dans les revendications, le mot � comprenant � n'exclut pas d'autres éléments et l'article indéfini � un/une � n'exclut pas une pluralité. REVENDICATIONS1. Système d'authentification d'un utilisateur possédant un moyen d'authentification (3) auprès d'une entité d'authentification (1), ledit moyen d'authentification comportant des moyens de stockage (11) d'au moins une variable d'état et un générateur (9) d'un code d'accès à usage unique actionnable à la demande de l'utilisateur, ledit code d'accès étant transmis à l'entité d'authentification pour validation, cette validation authentifiant l'utilisateur auprès de l'entité d'authentification, caractérisé en ce que ledit générateur est adapté pour calculer ledit code d'accès en utilisant ladite au moins une variable d'état et celle-ci est mise à jour de façon aléatoire lors de chaque génération d'un nouveau code d'accès. 2. Système d'authentification selon la revendication 1, caractérisé en ce que chaque variable d'état est mise à jour par une fonction Fx à sens unique ayant comme paramètres d'entrée au moins un secret propre audit moyen d'authentification. 3. Système d'authentification selon la revendication 2, caractérisé en ce qu'il comporte au moins un premier et un deuxième niveau d'authentification utilisables tels que le code d'accès est calculé selon le premier ou le deuxième niveau, le deuxième niveau comportant la saisie par l'utilisateur d'un code secret utilisé comme paramètre d'entrée de la fonction Fx. 4. Système selon la revendication 3, caractérisé en ce que le moyen d'authentification comporte une pluralité de variables d'état mises à jour par la fonction Fx, ladite fonction Fx étant composée d'une pyramide de sous-fonctions ayant comme paramètre d'entrée lesdites variables d'état de telle sorte qu'une variable d'état mise à jour par une des sous-fonctions de Fx n'est pas utilisée par celle-ci comme paramètre d'entrée. 5. Système selon la revendication 4, caractérisé en ce qu'il comporte un premier, un deuxième et un troisième niveau d'authentification, le nombrede variables d'état mises à jour variant en fonction du niveau d'authentification mis en oeuvre de telle sorte que : • dans le premier niveau d'authentification : une variable d'état est mise à jour, les deux autres variables d'état servant de paramètres d'entrée à la sous fonction de Fx ; • dans le deuxième niveau d'authentification : deux variables d'état sont mises à jour, le troisième servant de variable d'entrée, et • dans le troisième niveau d'authentification : les trois variables d'état sont mises à jour et aucune des variables d'état n'est utilisée en variable d'entrée. 6. Système selon la revendication 5, caractérisé en ce qu'il comporte en outre un client d'authentification (5) et le troisième niveau d'authentification utilisant ce client, ledit client d'authentification comportant un secret et étant adapté pour générer un second code d'accès à partir du code d'accès généré par le moyen d'authentification, ledit second code d'accès étant adapté pour authentifier l'utilisateur auprès de l'entité d'authentification. 7. Système d'authentification selon l'une quelconque des revendications précédentes, caractérisé en ce que le générateur comporte des moyens de génération d'un premier nombre (MM2,X) à partir d'une fonction Gx à sens unique dont les paramètres d'entrée comportent la au moins une variable d'état mise à jour. 8. Système selon la revendication 7, caractérisé en ce que le générateur comporte : • une fonction Ex à sens unique pour générer un second nombre (MM1,X) et comportant comme paramètres d'entrée : • le secret du moyen d'authentification ; ^ le nombre aléatoire, • une fonction possédant une fonction inverse adaptée pour combiner le premier et le second nombre générés par les fonctions Gx et Ex, le nombre combiné représentant le code d'accès et la fonction inverseétant adaptée pour générer le premier nombre et le second nombre à partir du code d'accès. 9. Système selon la revendication 8, caractérisé en ce que l'entité 5 d'authentification est adaptée pour vérifier la validité du second nombre (MM1,,) et la validité du premier nombre (MM2,X) de façon distincte. 10. Système selon la revendication 9, caractérisé en ce que, lors de la vérification de validité, l'entité d'authentification met à jour des états internes. 11. Système selon la revendication 7, caractérisé en ce qu'au moins un paramètre d'entrée de la fonction Gx est une variable d'état non mise à jour. 12. Système selon l'une quelconque des revendications précédentes, 15 caractérisé en ce que le moyen d'authentification et l'entité d'authentification comportent chacun une horloge, et le moyen d'authentification est adapté pour utiliser un intervalle de temps entre un temps de référence et le temps de son horloge dans le calcul du code d'accès et l'entité d'authentification est adaptée pour ne valider un code d'accès que si elle l'a reçu dans une plage 20 de temps déterminé par rapport au temps de génération dudit code d'accès. 13. Système selon l'une quelconque des revendications précédentes, caractérisé en ce que ledit système permettant l'authentification de l'utilisateur à une pluralité de services, un code d'accès est généré par le moyen 25 d'authentification en utilisant un code spécifique à un service donné de telle sorte que sa validation par l'entité d'authentification ne donne accès qu'audit service. 14. Système selon la revendication 13, caractérisé en ce que le moyen 30 d'authentification est adapté pour calculer un premier code d'accès en utilisant au moins un code spécifique au service, au moyen d'authentification et un intervalle de temps et l'entité d'authentification est adaptée pour calculer un second code d'accès spécifique au service, au moyen d'authentification et le transmettre à l'utilisateur pour que celui-ci puisse le comparer au premier 10code d'accès et identifier de façon sûre ainsi le service, lesdits premier et second code d'accès n'étant identiques que si le calcul du premier code d'accès par le moyen d'authentification est réalisé dans une plage de temps déterminée par rapport au temps de calcul du second code secret par l'entité d'authentification et que les codes spécifiques au service, au moyen d'authentification utilisés sont les mêmes.