FR2913551A1

FR2913551A1 - Methode d'authentification mutuelle et recurrente sur internet.

Info

Publication number: FR2913551A1
Application number: FR0701656A
Authority: FR
Inventors: Cyrille Rigault
Original assignee: Individual
Current assignee: Individual
Priority date: 2007-03-07
Filing date: 2007-03-07
Publication date: 2008-09-12

Abstract

Méthode d'authentification d'un utilisateur (100) référencé auprès d'un organisme et dont l'ordinateur (102) est connecté au réseau Internet (101). L'utilisateur désire avoir accès à au moins une page web (106) fournie par un serveur web (103) de l'organisme. L'ordinateur sur lequel est connecté un appareil d'authentification ou jeton (104) est adapté pour authentifier l'utilisateur auprès d'un serveur d'authentification (105) connecté au réseau Internet. La méthode est caractérisée en ce que, pour chacune des pages web demandée par l'utilisateur, elle consiste à faire authentifier le serveur d'authentification par le jeton et réciproquement. Selon une caractéristique essentielle de l'invention, l'authentification du serveur d'authentification (105) par le jeton (104) et réciproquement est effectuée par l'exécution d'un script de contrôle (107) enregistré dans l'ordinateur. Le script de contrôle (107) est soit enregistré dans l'ordinateur préalablement à la mise en oeuvre de la méthode, soit inclus dans chacune des pages web transmise par le serveur web, soit inclus dans la première page web transmise par le serveur web et enregistré dans l'ordinateur lorsque celui-ci reçoit la page web, soit intégré au navigateur web.

Description

DOMAINE TECHNIQUE L'invention concerne la sécurisation des transactions

sur Internet entre un utilisateur et le site auprès duquel il est référencé et sur lequel il désire se connecter, et concerne en particulier une méthode d'authentification mutuelle et récurrente sur Internet entre l'utilisateur et le site.

ETAT DE LA TECHNIQUE Lorsqu'un utilisateur consulte un site Internet, l'authentification est un enjeu majeur, afin de lutter contre les problèmes d'usurpation d'identité, et de présentation de site falsifié par des pirates dans le but qu'ils récupèrent des données confidentielles. L'authentification de l'utilisateur, sur un site auprès duquel il est référencé, c'est-à-dire auprès duquel il a fait l'objet d'une inscription préalable, est classiquement effectuée en entrant un identifiant d'utilisateur et un mot de passe. Cette technique est peu sécurisante car des logiciels espions existent afin de récupérer ces informations saisies.

Une autre technique consiste à utiliser un appareil d'authentification comme une clé USB tel que décrit dans la demande de brevet US 2001 045451, ou une carte à puce et son lecteur, capable de générer des mots de passe dynamiques à usage unique. Un serveur d'authentification, ou un module d'authentification sur le site visité, est capable de générer le même mot de passe, et donc de vérifier la validité de celui généré par l'appareil d'authentification. Cette technique est meilleure que la précédente, puisque le mot de passe varie au cours du temps, mais il ne protège que la connexion et non l'ensemble des pages visitées. Un pirate peut donc s'intercaler après la connexion pour récupérer des données confidentielles, ou aller sur le site sans passer par la connexion initiale (en récupérant une session existante par exemple).

L'authentification du site par l'utilisateur est un problème plus récent. Les systèmes mis en place concernent soit l'affichage sur chaque page web d'une phrase ou d'une image définie par l'utilisateur lors de son inscription tel que décrit dans la demande de brevet US 2006 230435, soit des listes de sites valides que l'utilisateur peut définir dans son navigateur. La première technique est insuffisante, car tout contenu d'une page web peut- être détournée et réutilisée par un pirate, et la seconde est peu pratique et exposée aux failles des navigateurs. Par ailleurs, les méthodes d'authentification entre un client et un serveur sont nombreuses. On peut citer, entres autres les documents US 2004 205344 qui propose une méthode basée sur des clés non dynamiques ; US 2004 230800 qui propose une méthode basée sur des données de challenge ; US 2004 255037 qui propose une méthode basée sur l'échange de certificats non dynamiques ou JP 2004 023662 et JP 11.340.969 qui décrivent une méthode basée sur une clé statique et des nombres aléatoires. Mais aucun des documents cidessus ne décrit de système complet permettant de faire une authentification mutuelle et récurrente, c'est à dire effectuée de façon itérative tout au long de la visite du site.

EXPOSE DE L'INVENTION C'est pourquoi le but de l'invention est de réaliser une méthode d'authentification entre un utilisateur du réseau Internet et le site sur lequel il se connecte, qui est mutuelle et récurrente et qui est basée sur des clés dynamiques et une signature de ces clés. L'invention a pour objet une méthode d'authentification d'un utilisateur référencé auprès d'un organisme et dont l'ordinateur est connecté au réseau Internet. L'utilisateur désire avoir accès à au moins une page web fournie par un serveur web de l'organisme de façon à effectuer la visualisation de ladite page web. Un appareil d'authentification, connecté à l'ordinateur de l'utilisateur, est adapté pour authentifier l'utilisateur auprès d'un serveur d'authentification connecté au réseau Internet. La méthode est caractérisée en ce que, pour chacune des pages web demandée par l'utilisateur, elle consiste à faire authentifier le serveur d'authentification par le jeton et réciproquement.

Selon une caractéristique essentielle de l'invention, l'authentification du serveur d'authentification par le jeton et réciproquement est effectuée par l'exécution d'un script de contrôle enregistré dans l'ordinateur. Le script de contrôle est soit enregistré dans l'ordinateur préalablement à la mise en oeuvre de la méthode, soit inclus dans chacune des pages web transmise par le serveur web, soit inclus dans la première page web transmise par le serveur web et enregistré dans l'ordinateur lorsque celui-ci reçoit la page web, soit intégré au navigateur web. De façon plus précise, la méthode selon l'invention consiste, pour toute demande d'une page web, à : - demander l'identifiant au jeton, - transmettre une requête de demande de session au serveur d'authentification, - transmettre la demande de session renvoyée par le serveur d'authentification au jeton, -vérifier par le jeton la validité de la demande de session, - transmettre la réponse de session dudit jeton au serveur d'authentification, -vérifier par le serveur d'authentification la réponse de session du jeton, envoyer au serveur web le résultat de l'authentification, et -recommencer les étapes précédentes lorsque, à l'issue d'une durée de valeur prédéterminée, la visualisation de la page web n'est pas terminée.

DESCRIPTION BREVE DES DESSINS Les buts, objets et caractéristiques de l'invention apparaîtront plus clairement à la lecture de la description qui suit faite en référence aux dessins dans lesquels : la figure 1 est un bloc diagramme montrant les principaux composants de l'invention, dans lesquels sont implémenté le procédé permettant une authentification mutuelle entre l'utilisateur et le serveur du site web visité, la figure 2 est un diagramme représentant le séquencement des messages échangés entre le serveur d'authentification et le jeton, ainsi que les données principales gérées par ces deux composants, la figure 3 est un diagramme représentant le séquencement principal des messages échangés entre les différents composants en vue de réaliser la méthode selon l'invention, la figure 4 est un bloc diagramme représentant le déploiement de l'invention lorsqu'il y a deux serveurs web attachés à un seul serveur d'authentification, la figure 5 est un bloc diagramme représentant le déploiement de l'invention lorsqu'il y a deux serveurs web attachés chacun à un serveur d'authentification spécifique, la figure 6 est un diagramme représentant le séquencement des messages échangés entre les différents composants en vue de réaliser la méthode selon l'invention dans un mode simplifié, où le serveur web et le serveur d'authentification sont regroupés.

DESCRIPTION DETAILLEE DE L'INVENTION La méthode de l'invention est mise en oeuvre dans un système illustré par le bloc diagramme de la figure 1. Dans un tel système, un utilisateur 100 qui est connecté au réseau Internet 101 au moyen d'un ordinateur 102 désire avoir accès à un serveur web 103 connecté au réseau Internet pour se procurer une ou plusieurs pages web. De façon classique, l'authentification de l'utilisateur est réalisée en utilisant un appareil d'authentification 104 (appelé jeton par la suite) connecté à l'ordinateur 102 et un serveur d'authentification 105 connecté au réseau Internet, et/ou par l'échange d'un identifiant et d'un mot de passe. A noter que l'appareil d'authentification à la disposition de l'utilisateur du fait que ce dernier est référencé auprès du site, est un dispositif qui se connecte sur l'ordinateur de l'utilisateur par l'une de ses prises d'interface (couramment la prise USB). Mais contrairement aux systèmes actuels, l'authentification est réalisée par l'intermédiaire de la page web 106 reçue du serveur web 103. La page web est constituée d'une part de l'ensemble des informations présentées à l'utilisateur, et spécifiques au site web visité, et d'autre part d'un script de contrôle 107. Le script de contrôle 107 est un module logiciel qui joue un élément central dans l'authentification. C'est par lui que sont mis en relation le jeton 104 via son logiciel d'interface (de préférence un contrôle ActiveX), le serveur d'authentification 105 et le serveur web 103. Dans le mode de réalisation préférentiel, les technologies utilisées pour implémenter le script de contrôle sont JavaScript et AJAX. JavaScript est un langage de programmation coté client web, et AJAX un ensemble de technologies permettant d'effectuer des requêtes transparentes à un serveur web. L'utilisation d'une autre technologie similaire ne changerait pas le principe de la présente invention.

Une caractéristique importante de l'invention réside dans le fait que l'authentification entre le serveur d'authentification et le jeton est basée sur : - une paire de clés cryptographiques par jeton et par serveur web, et générée par le serveur d'authentification, appelées aussi clés de session. Ces clés permettent de crypter les messages échangés entre le jeton et le serveur d'authentification.

L'utilisation d'une paire de clé permet de garantir qu'il existe toujours une clé commune entre le serveur d'authentification et le jeton, même lorsque la mise à jour de ces clés ne s'effectue pas correctement, par exemple suite à un problème de communication, - un identifiant de requête généré par le serveur web. Il s'agit d'un élément dynamique permettant de ne pas pouvoir réutiliser des messages déjà échangés entre le serveur web et le serveur d'authentification d'une part, et le serveur d'authentification et le jeton d'autre part. Chaque nouvel identifiant doit être une valeur unique pour un jeton donné (il peut s'agir d'un compteur, ou de la date et de l'heure indiquant une date absolue par rapport à un référentiel), - des signatures des demandes et des réponses entre le serveur web et le serveur d'authentification d'une part, et le serveur d'authentification et le jeton d'autre part. Ces signatures permettent de certifier la provenance des demandes et des réponses. Un jeton, qui permet d'authentifier un ou plusieurs serveurs web, contient en permanence les données suivantes, résumées sur la figure 2: - un identifiant unique, parmi l'ensemble des jetons, - des données relatives à chaque serveur web qu'il peut identifier, incluant notamment : -l'identifiant unique du serveur web, parmi l'ensemble des serveurs web, -l'identifiant de la dernière requête du serveur web, - une paire de clés cryptographiques dynamiques : la clé courante et la clé précédente. Ces données sont conservées dans le jeton de façon non volatile, par un dispositif tel qu'une mémoire Flash.

Le serveur d'authentification, dont les principales données sont résumées sur la figure 2, contient en permanence un enregistrement par serveur web et par jeton entre lesquels il y a authentification mutuelle possible, et comprenant : - l'identifiant unique du jeton, parmi l'ensemble des jetons, - l'identifiant unique du serveur web, parmi l'ensemble des serveurs web, pouvant identifier le jeton, - l'identifiant de la dernière requête du serveur web, - une paire de clés cryptographiques dynamiques : la clé courante et la nouvelle clé. Ces données sont conservées dans le serveur d'authentification sous forme non volatile, par un dispositif tel qu'une base de données.

Initialement, les valeurs des clés sont les suivantes : - la clé courante du serveur d'authentification et la clé courante du jeton sont identiques, - l'ancienne clé du jeton est identique à sa clé courante, - la nouvelle clé du serveur d'authentification est vide (non valide).

Dans l'invention, les algorithmes cryptographiques utilisés importent peu. Pour le cryptage, il peut s'agir de clés symétriques (DES, EDES, AES ou autres) ou asymétriques (RSA, DSA, ou autres), et pour les signatures d'algorithmes comme MD5, SHA-1, ou autres. L'invention utilise certains de ces algorithmes, mais la mise en oeuvre décrite ici est spécifique. Le mode de réalisation utilise un algorithme symétrique AES pour le cryptage, ce qui est suffisant sachant que la sécurité est basée sur le dynamisme des clés et l'unicité de ces clés entre les jetons, et utilise pour signer les messages échangés l'algorithme MD5. La méthode selon l'invention est maintenant décrite en référence à la figure 3. Lorsque l'utilisateur se connecte à un site Internet 301, une première page d'authentification peut lui être présentée en lui demandant son identifiant et son mot de passe. Cette première étape n'est pas indispensable, mais peut permettre un premier niveau d'authentification. Dans ce dernier cas, et si l'utilisateur n'est pas reconnu par le serveur web (identifiant inconnu ou mauvais mot de passe), la connexion n'est pas possible. Si l'utilisateur est reconnu, ou si l'étape précédente n'existe pas, le serveur web lui présente une première page web lui demandant de connecter son jeton à son ordinateur 302. Cette page contient les informations d'authentification dynamiques suivantes : - l'identifiant du serveur web, - un identifiant unique de requête, - une signature de la demande d'authentification.

La signature permet de certifier que la demande provient effectivement du serveur web, et peut-être calculée de la façon suivante : signature = fonction( identifiant serveur web, identifiant requête, mot de passe entre le serveur web et le serveur d'authentification). Lorsque l'utilisateur a connecté son jeton et validé la demande, le script de contrôle 15 transmet une demande d'identifiant au jeton 303. Sur cette demande, le jeton renvoie simplement sont identifiant unique 304, permettant de le reconnaître parmi l'ensemble des jetons. Le script de contrôle demande alors au serveur d'authentification une requête de demande de session 305. Il s'agit d'une requête HTTP ou HTTPS contenant les 20 informations suivantes : - l'identifiant du serveur web, contenu dans la page web, - un identifiant de requête unique, contenu dans la page web, - la signature de la demande du serveur web, contenu dans la page web, - l'identifiant du jeton, lu précédemment. 25 Sur une requête de demande de session 305, le serveur d'authentification effectue les traitements suivants, en utilisant sa base cle données : - il vérifie l'existence du jeton, par son identifiant, - il vérifie l'existence du serveur web, par son identifiant, - il vérifie que ce serveur web peut utiliser ce jeton, 30 - il vérifie que l'identifiant de requête du serveur web n'a pas déjà pu être utilisé (par exemple en vérifiant qu'il est supérieur au dernier identifiant de requête de ce serveur web pour ce jeton), - il vérifie la signature de la requête du serveur web. Cette signature permet de certifier que seul ce serveur web a pu émettre la requête. Pour ce faire, il calcule lui même cette signature et il la compare avec la signature reçue. Si l'une des vérifications précédentes n'est pas valide, le serveur d'authentification renvoie une réponse 306 indiquant une erreur. Ce résultat négatif est alors envoyé par le script de contrôle au serveur web comme résultat d'authentification 313. Si l'ensemble des vérifications précédentes est valide, le serveur d'authentification crée une session HTTP permettant de conserver les données reçues jusqu'à la requête de vérification de session du jeton 310. Il crée une nouvelle clé de session si la valeur actuelle de cette clé est vide (non valide), et la met à jour dans sa base de données. Sinon, il utilise la valeur actuelle de cette clé. Il renvoie une réponse 306 contenant les données de demande de session suivantes : -l'identifiant du serveur web ayant demandé l'authentification, -l'identifiant de demande d'authentification du serveur web, - la nouvelle clé de session, - la signature de cette demande de session, qui peut-être calculée de la façon suivante : signature = fonction( identifiant serveur web, identifiant requête, identifiant jeton, clé courante, nouvelle clé), Toutes ces données, à l'exclusion de l'identifiant du serveur web, sont cryptées en utilisant la clé courante. Les clés manipulées sont celles associées au couple (jeton, serveur web). Sur réception de la réponse 306, le script de contrôle effectue une demande de session au jeton 307 avec les données de cette réponse 306. Sur une demande de session 307, le jeton vérifie la demande de session et effectue les traitements suivants 308 : -il recherche l'identifiant du serveur web parmi ceux qu'il possède. S'il ne trouve pas cet identifiant, il renvoie une erreur dans sa réponse 309. Sinon, il utilise par la suite les données associées à ce serveur web, il décrypte les autres données du message avec la clé courante, calcule la signature de la même façon que le serveur d'authentification, et compare la signature calculée avec celle reçue dans le message. Si les deux signatures sont différentes, il réitère l'opération en utilisant l'ancienne clé. Si les deux signatures sont à nouveau différentes, il renvoie une erreur dans sa réponse 309, - il vérifie que l'identifiant de requête du serveur web n'a pas déjà pu être utilisé (par exemple en vérifiant qu'il est supérieur au dernier identifiant de requête de ce serveur web qu'il a mémorisé). Si ce n'est pas le cas, il renvoie une erreur dans sa réponse 309.

Si l'ensemble des vérifications est valide, le jeton a correctement authentifié le serveur d'authentification. Il transfert la clé courante dans la clé précédente, puis la nouvelle clé contenue dans le message de demande de session, et décryptée avec succès, dans la clé courante, ces clés étant celles associées au serveur web ayant demandé l'authentification. Il renvoie une réponse de session 309 au script de contrôle, cette réponse étant signée de la même façon que dans la demande de session 307, et cryptée avec la nouvelle clé courante. La session du jeton devient à nouveau valide pendant une durée fixe (i.e. trente secondes), cette durée étant gérée par un temporisation au sein du jeton. Dans le mode de réalisation préférentiel, le jeton gère une LED verte permettant d'informer l'utilisateur de l'authentification du site visité. Le jeton informe l'utilisateur de la validité de la session en allumant la LED verte. Lorsque la session devient invalide, ou s'il n'y a pas de session, la LED verte est éteinte. Sur réception de la réponse de session 309, le script de contrôle envoie au serveur d'authentification une requête de vérification de session 310. Il s'agit d'une requête HTTP 20 ou HTTPS contenant les données de la réponse de session du jeton 309. Sur une requête de vérification de session 310, le serveur d'authentification récupère les données associées à la requête, grâce à la session HTTP qu'il a créée lors du traitement de la requête 305. Il vérifie la réponse de session du jeton, et effectue les traitements 311 suivants, en utilisant sa base de données, et les données associées au serveur web et au 25 jeton traités : - il vérifie que la signature du jeton est correcte, en calculant lui-même cette signature, puis en la cryptant avec la nouvelle clé, et en comparant cette signature cryptée avec celle renvoyée par le jeton, - si les signatures sont identiques, le jeton a correctement été authentifié. Le serveur 30 d'authentification transfert la nouvelle clé dans la clé courante, et invalide la nouvelle clé (sa valeur devient vide). Si l'une des vérifications n'est pas valide, le serveur d'authentification renvoie un résultat d'authentification indiquant une erreur 312.

Si l'ensemble des vérifications est valide, le serveur d'authentification renvoie un résultat d'authentification indiquant un résultat correct. Ce résultat correct est signé, afin de certifier les réponses positives du serveur d'authentification auprès du serveur web. La signature peut-être calculée de la façon suivante : signature = fonction( identifiant serveur web, identifiant jeton, identifiant requête, code réponse du serveur d'authentification, mot de passe entre le serveur web et le serveur d'authentification). Lorsque l'authentification est terminée, suite à une erreur ou à une authentification réussie, le script de contrôle envoie une requête de résultat d'authentification 313 au serveur web via une requête HTTP ou HTTPS. Cette requête contient les informations suivantes : -l'identifiant de requête du serveur web, qui était dans la page web, -l'identifiant du jeton, - le code résultat de l'authentification, - la signature de ce code résultat, quand le résultat est positif.

Lorsque le serveur web reçoit une requête de résultat d'authentification 313, suite à la connexion initiale de l'utilisateur, il effectue les actions suivantes, en utilisant sa base de données : si le résultat d'authentification est positif, il vérifie: - que le jeton est celui de l'utilisateur qui s'est identifié, en comparant l'identifiant du jeton avec celui possédé par l'utilisateur. S'il n'y a pas d'étape d'authentification de l'utilisateur préalable par identifiant utilisateur et mot de passe, cette vérification n'a pas lieu, - que la signature du résultat d'authentification du serveur d'authentification est correcte. Pour ce faire, il calcule lui-même cette signature de la même façon que le serveur d'authentification, et compare les deux signatures qui doivent être identiques, - que l'identifiant de requête correspond à l'identifiant de la dernière demande d'authentification effectuée par le serveur web. Si l'ensemble des vérifications est valide, le serveur web connecte l'utilisateur dans l'espace confidentiel et lui renvoie une page dans cet espace 314.

Si l'une des vérifications n'est pas valide, ou si le résultat d'authentification est négatif, le serveur web déconnecte l'utilisateur et lui renvoie une page indiquant une erreur 314.

Lorsque l'utilisateur est connecté dans l'espace confidentiel, après une première authentification réussie de son jeton, le serveur web lui présente une page web de l'espace confidentiel 314, qui contient les informations d'authentification dynamiques suivantes : - l'identifiant du serveur web, - un identifiant unique de requête, - une signature de la demande d'authentification, - l'URL que doit appeler le script de contrôle pour envoyer le prochain résultat d'authentification récurrent. Lorsque le chargement de la page web dans le navigateur de l'utilisateur est terminé 315, la procédure d'authentification entre le jeton et le serveur d'authentification décrite précédemment entre les étapes 303 et 312 est enclenchée automatiquement, grâce à un mécanisme standard HTML (window.onload), et de façon transparente pour l'utilisateur. Cette procédure s'étend de la demande d'identification du jeton 316, jusqu'au renvoie du résultat d'authentification du serveur d'authentification 320.

Lorsque la réponse 320 du serveur d'authentification est reçue, ou suite à une erreur dans les étapes d'authentifications, une requête HTTP ou HTTPS est envoyée au serveur web 321. L'URL de cette requête a été conservée dans le script de contrôle grâce au message 314. Les mêmes paramètres qu'en 313 sont ajoutés à cette URL, à savoir : - l'identifiant de requête du serveur web, qui était dans la page web, - l'identifiant du jeton, - le code résultat de l'authentification, - la signature de ce code résultat, quand le résultat est positif. Contrairement à l'étape 313, qui correspond à une demande de nouvelle page web au serveur web, suite par exemple à l'appui d'un bouton de l'utilisateur, le résultat 321 ne requiert pas de nouvelle page auprès du serveur web, ce qui serait visible pour l'utilisateur. Il s'agit d'une requête émise de façon transparente au serveur web, dont l'intention n'est pas de mettre à jour la page web actuelle, mais de rendre compte du résultat d'authentification. Lorsque le serveur web reçoit une requête de résultat d'authentification 321 suite à une demande d'authentification transparente, il effectue les mêmes actions de vérification qu'après réception d'un résultat d'authentification 313. Il vérifie de plus que l'utilisateur est déjà connecté. Si l'ensemble des vérifications est valide, le serveur web renvoie une réponse 322 à la requête 321 contenant : - le type action à entreprendre, qui est ici normalement une nouvelle demande d' authentification, - l'identifiant du serveur web, - un identifiant unique de requête, - une signature de la demande d'authentification, - la temporisation d'activation de la prochaine demande d'authentification dans le script de contrôle. Si l'une des vérifications n'est pas valide, ou si le résultat d'authentification est négatif, le serveur web clôture en principe la session HTTP de l'utilisateur, et renvoie une réponse 322 à la requête 321 contenant : le type action à entreprendre, qui est propre au serveur web, -d'éventuels paramètres additionnels, propres au serveur web. Lorsque le script de contrôle reçoit une réponse 322, il récupère l'action à entreprendre dans la réponse.

Si l'action à entreprendre est une demande d'authentification, le script de contrôle récupère les paramètres de l'action, et lance une temporisation 323 dont la durée est indiquée par l'un des paramètres de la demande 322. A l'issu de cette temporisation, une nouvelle identification démarre 324. La procédure est itérative, tant que l'authentification est un succès (étapes 316 à 323).

Le serveur web peut également, en cas d'erreur d'authentification, demander une nouvelle authentification. Ce n'est qu'après plusieurs échecs consécutifs que l'action sera de déconnecter l'utilisateur. Si l'action à entreprendre en 322 n'est pas une demande d'authentification, le script de contrôle récupère les paramètres de l'action, et appelle une procédure par défaut, que doit redéfinir le serveur web dans sa page web. Dans cette procédure, qui traite en principe d'une erreur d'authentification, la page web invoque une nouvelle page web qui indique normalement à l'utilisateur une erreur d'authentification. Pour les pages suivantes, la procédure d'authentification entre le jeton et le serveur d'authentification décrite précédemment (étapes 303 à 312) est démarrée automatiquement. Quand la réponse du résultat d'authentification de l'étape 312 est reçue du serveur d'authentification, la demande de la page web est envoyée au serveur web avec les données du résultat de l'authentification, comme à l'étape 313. Sur une telle demande de page web, le serveur web vérifie le résultat de l'authentification avant de servir la page web. Si le résultat est correct, il présente la nouvelle page demandée contenant les nouvelles informations d'authentification dynamiques comme à l'étape 314, sinon il présente une page d'erreur. La procédure se poursuit ensuite, comme expliqué à partir de l'étape 314. Lorsque, à l'issu d'une temporisation définie par le serveur web, ce dernier n'a pas reçu de résultat d'authentification, le serveur web clôture la session HTTP de l'utilisateur, et lui présente une page web indiquant une erreur d'authentification. Enfin, et pour permettre de fermer explicitement une session au niveau du jeton, une demande de clôture de session est disponible. Cette demande est envoyée par le script de contrôle au jeton lorsque l'utilisateur se déconnecte du site web visité.

Le déploiement de l'invention peut-être réalisé de plusieurs façons. Dans un premier mode de réalisation représenté sur la figure 4, un serveur d'authentification 105 est partagé par plusieurs serveurs web 401 et 402. Dans un second mode de réalisation représenté sur la figure 5, un serveur d'authentification est dédié à chaque serveur web. Le serveur d'authentification 503 est dédié au serveur web 501, et le serveur d'authentification 504 est dédié au serveur 502. A noter que, lorsqu'un serveur d'authentification est dédié à chaque serveur web, le serveurd'authentification peut faire partie intégrante du serveur web, sous forme d'un module logiciel, et non en tant que serveur spécifique ; dans cette situation, le serveur web et le serveur d'authentification sont confondus. Dans ce cas, un certain nombre de simplifications peuvent être apportées, et sont détaillées ci-après. Ces modifications concernent les données conservées dans le jeton et le serveur d'authentification d'une part, les messages échangés et leur contenu d'autre part. Le jeton peut n'être associé qu'a un seul serveur web ; l'identifiant du serveur web n'a donc plus de raison d'être géré et transmis. De même, il n'y a plus de raison non plus d'authentifier le serveur web auprès du serveur d'authentification. Le jeton ne conserve alors plus que les données suivantes : - son identifiant, - l'identifiant de la dernière requête, la clé courante, - l'ancienne clé. Le serveur d'authentification conserve un enregistrement par jeton contenant les données suivantes : -l'identifiant du jeton, - l'identifiant de la dernière requête, - la clé courante, - la nouvelle clé. Les messages transmis entre le serveur web, le script de contrôle et le jeton sont représentés sur la figure 6. Cette figure est une simplification de la figure 3 ; les principales différences sont les suivantes : - la requête de demande de session 305 est directement adressée au serveur web, - la requête de vérification de session 310 et la requête de résultat d'authentification 313 sont regroupées en une seule requête 310. Schématiquement sur le figure 6, le renvoie du résultat d'authentification 312 et la requête de résultat d'authentification 313 sont supprimés.

Claims

REVENDICATIONS

1. Méthode d'authentification d'un utilisateur référencé auprès d'un organisme et dont l'ordinateur (102) est connecté au réseau Internet (101) et désirant avoir accès à au moins une page web fournie par un serveur web (103) dudit organisme de façon à effectuer la visualisation de ladite page web, ledit ordinateur auquel est connecté un appareil d'authentification (104) étant adapté pour authentifier ledit utilisateur auprès d'un serveur d'authentification (105) connecté au réseau Internet ; ladite méthode étant caractérisée en ce que, pour chacune des pages web demandée par 10 l'utilisateur, elle consiste à faire authentifier ledit serveur d'authentification par ledit jeton et réciproquement.

2. Méthode selon la revendication 1, dans laquelle l'authentification dudit serveur d'authentification par ledit jeton et réciproquement est effectué par l'exécution d'un script de 15 contrôle dans ledit ordinateur.

3. Méthode selon la revendication 2, dans laquelle ledit script de contrôle est soit enregistré dans l'ordinateur préalablement à la mise en oeuvre de la méthode, soit inclus dans chacune des pages web transmise par le serveur web, soit inclus dans la première page web transmise 20 par le serveur web et enregistré dans l'ordinateur lorsque celui-ci reçoit la page web, soit intégré au navigateur web.

4. Méthode selon l'une des revendications 1 à 3, dans laquelle ledit serveur d'authentification est séparé dudit serveur web, ladite méthode comprenant les étapes consistant à, pour toute 25 demande d'une page web, - demander l'identifiant au jeton (303), - transmettre une requête de demande de session contenant l'identifiant dudit jeton audit serveur d'authentification (305), - transmettre la demande de session renvoyée par ledit serveur d'authentification audit jeton 30 (307), - vérifier par ledit jeton la validité de ladite demande de session (308), - transmettre la réponse de session dudit jeton par une requête de vérification de session audit serveur d'authentification (310),- vérifier par ledit serveur d'authentification la réponse de session dudit jeton, afin de l'authentifier (311), - envoyer le résultat de l'authentification par une requête audit serveur web (313), et - recommencer les étapes précédentes lorsque, à l'issue d'une durée de valeur prédéterminée, la visualisation de ladite page web n'est pas terminée.

5. Méthode selon l'une des revendications 1 à 3, dans laquelle ledit serveur d'authentification est intégré dans ledit serveur web, ladite méthode comprenant les étapes consistant à, pour toute demande d'une page web, - demander l'identifiant au jeton (303), - transmettre une requête de demande de session contenant l'identifiant dudit jeton audit serveur d'authentification (305), - transmettre la demande de session renvoyée par ledit serveur d'authentification audit jeton (307), - vérifier par ledit jeton la validité de ladite demande de session (308), - transmettre la réponse de session dudit jeton par une requête de vérification de session audit serveur d'authentification (310), - vérifier par ledit serveur d'authentification la réponse de session dudit jeton, afin de l'authentifier (311), et - recommencer les étapes précédentes lorsque, à l'issue d'une durée de valeur prédéterminée, la visualisation de ladite page web n'est pas terminée.

6. Méthode selon la revendication 4, dans laquelle la requête de demande de session envoyée audit serveur d'authentification contient également les données de la demande d'authentification dudit serveur web, à savoir : -l'identifiant dudit serveur web, - l'identifiant de demande d'authentification dudit serveur web, et - la signature de la demande d'authentification dudit serveur web.

7. Méthode selon la revendication 4, dans laquelle la requête de résultat d'authentification envoyée audit serveur web contient : - l'identifiant dudit jeton, - l'identifiant de la demande d'authentification dudit serveur web,- le résultat de l'authentification, et - la signature du résultat de l'authentification.

8. Méthode selon la revendication 4 ou 5, dans laquelle la demande de session renvoyée par ledit serveur d'authentification, et à destination dudit jeton, contient : - l'identifiant dudit serveur web ayant demandé l'authentification, - l'identifiant de demande d'authentification dudit serveur web, - la nouvelle clé de session, et - la signature de la demande de session.

9. Méthode selon la revendication 4 ou 5, dans laquelle la réponse de session renvoyée par ledit jeton, et contenue dans ladite requête de vérification de session envoyée audit serveur d'authentification, contient la signature de la réponse de session.

10. Méthode selon la revendication 4 ou 5, clans laquelle ledit jeton conserve en permanence des données incluant un identifiant unique parmi l'ensemble desdits jetons, et pour chacun desdits serveurs web avec lequel il peut être identifié : - l'identifiant dudit serveur web, -l'identifiant de ladite dernière demande d'authentification dudit serveur web, - la clé cryptographique courante, et - la clé cryptographique précédente.

11. Méthode selon la revendication 4 ou 5, dans laquelle ledit serveur d'authentification conserve en permanence une base de données contenant un enregistrement par serveur web et par jeton entre lesquels il y a authentification mutuelle possible, et qui contient : - l'identifiant dudit jeton, - l'identifiant dudit serveur web, - l'identifiant de ladite dernière demande d'authentification dudit serveur web, - la clé cryptographique courante, et - la nouvelle clé cryptographique.

12. Méthode selon la revendication 4 ou 5, dans laquelle ladite clé cryptographique courante et ladite clé cryptographique précédente dudit jeton sont initialisées aux mêmes valeurs que ladite clé cryptographique courante dudit serveur d'authentification, et la nouvelle clécryptographique dudit serveur d'authentification est initialisée à une valeur vide, ces initialisations ayant lieu pour un serveur web donné et lors d'une phase d'administration.

13. Méthode selon la revendication 4 ou 5, dans laquelle ledit serveur d'authentification génère une nouvelle clé cryptographique si celle-ci a une valeur vide, ou utilise la valeur actuelle de cette nouvelle clé dans le cas contraire, lorsqu'il envoie ladite demande de session à destination dudit jeton, cette clé correspondant à celle dudit serveur web et dudit jeton en cours d'authentification.

14. Méthode selon la revendication 4 ou 5, dans laquelle ledit jeton décrypte ladite demande de session avec ladite clé courante, et si ladite signature est correcte : il transfère ladite clé courante dans ladite clé précédente puis met à jour ladite clé courante avec ladite nouvelle clé contenue dans ladite demande de session, la clé courante et la clé précédente correspondant à celles dudit serveur web, et si ladite signature est incorrecte, il décrypte à nouveau ladite demande de session avec ladite clé précédente, et si la signature est correcte, il transfère ladite clé courante dans ladite clé précédente puis met à jour ladite clé courante avec ladite nouvelle clé contenue dans ladite demande de session, la clé courante et la clé précédente correspondant à celles dudit serveur web.

15. Méthode selon la revendication 4 ou 5 dans laquelle ledit serveur d'authentification décrypte ladite réponse de session du jeton avec ladite nouvelle clé, et si ladite signature est correcte, il transfère la valeur de ladite nouvelle clé cryptographique dans ladite clé courante, et réinitialise à une valeur vide ladite nouvelle clé cryptographique, ces clés correspondant à celles dudit serveur web et dudit jeton en cours d'authentification.