AUTHENTIFICATION EN TOUTE CONFIANCE D'UN UTILISATEUR PAR UN

SERVEUR

L'objet de la présente description est, d'une part, d'analyser la problématique de l'authentification d'un utilisateur par un serveur accédé via Internet et, d'autre part, de proposer une solution innovante susceptible de répondre à cette problématique.

I) Le problème posé L'authentification d'un utilisateur à travers le réseau Internet n'est pas un problème nouveau et de multiples mécanismes d'authentification sont d'ores et déjà utilisés, couramment ou non, pour tenter de répondre à ce besoin.

Le mécanisme le plus basique et parmi les moins sécurisés et pourtant le plus utilisé est celui où le serveur demande à l'utilisateur de s'identifier par un identifiant, ID, et à s'authentifier en fournissant en complément un mot de passe, PW.

Ce mécanisme est très souvent complété par la mise en œuvre au préalable d'une session SSL ou TLS entre le poste utilisateur et le serveur. Cette solution est censée, d'une

part, permettre à l'utilisateur d'authentifier le serveur et, d'autre part, mettre en place un canal de communication sécurisé entre l'utilisateur et le serveur. De cette façon, l'utilisateur et le serveur pourront échanger en toute confiance des informations confidentielles au cours de la session, à commencer par la communication par l'utilisateur de son identifiant (ID) et de son mot de passe (PW) à titre d'authentification.

Bien évidemment, la seule utilisation d'un mot de passe pour authentifier un utilisateur reste a priori une solution fragile puisque la simple compromission du mot de passe permettra à un tiers d'usurper l'identité de l'utilisateur en question.

Il s'agit ainsi d'un mécanisme d'authentification à facteur simple, le mot de passe mémorisé par l'utilisateur. II existe des mécanismes d'authentification à facteurs multiples, d'autres facteurs d'authentification venant en général en complément du mot de passe :

- quelque chose que possède l'utilisateur comme par exemple une carte à puce - une caractéristique propre à l'utilisateur, concrètement un facteur biométrique, comme par exemple son empreinte digitale.

Mais ces mécanismes sont presque toujours coûteux à mettre en œuvre et peuvent s'avérer excessivement contraignants pour les utilisateurs, nomades ou non. C'est pourquoi, on se limite à la recherche de solutions ne nécessitant la mise en œuvre d'aucun matériel additionnel à celui constitué par un poste utilisateur de base (par exemple un PC sous « Windows ») .

La solution idéale recherchée correspond au meilleur compromis possible entre sécurité et ergonomie. C'est pourquoi, on écarte du champ de la présente demande la piste des certificats logiciels (sans support matériel) .

II) Analyse critique de l'état de l'art

On analyse ci-après les risques de compromission d'un mot de passe destiné à l'authentification sur Internet d'un utilisateur : - sur le serveur, sans aborder la question de son intégrité (supposée maîtrisée) , par essai systématique de mots de passe plausibles (attaque par dictionnaire) , sur le réseau, - sur le poste utilisateur.

Le serveur doit à l'évidence pouvoir vérifier que l'utilisateur connaît le PW.

La solution la plus simple consiste donc pour le serveur à se faire communiquer le PW saisi par l'utilisateur et à le comparer au PW connu du serveur. Dans ce contexte, une attaque consiste à obtenir une copie du fichier des mots de passe.

Le serveur sera bien sûr protégé contre ce type d'attaque mais il est difficile de l'exclure tout à fait et c'est pourquoi une meilleure solution consiste à ne pas conserver sur le serveur le PW mais seulement des informations permettant de vérifier que l'utilisateur a bien saisi le bon PW. Pour éviter les attaques par dictionnaire, il faut : rendre impossible des tests systématiques du mot de passe ou au minimum rendre de tels tests impraticables . Si le seul moyen de tester un PW est de tenter un accès au serveur, il est clair qu'une première parade consiste à limiter le nombre de tentatives qu'acceptera le serveur avant de bloquer le compte utilisateur en question. Il faut faire de même concernant un même PW testé contre un trop grand nombre de comptes utilisateurs.

Si en revanche, le risque existe qu'un tiers ait pu obtenir une information calculée à partir du PW et d'autres informations non protégées, alors l'attaque par dictionnaire est

possible sans avoir besoin de faire intervenir le serveur. La seule solution pour faire échouer ce type d'attaque est alors d'avoir imposé un mot de passe suffisamment fort pour que l'attaque par dictionnaire ne puisse pas aboutir avant un délai suffisamment long. Mais un utilisateur ne pourra jamais mémoriser un tel mot de passe et en fait, il faut alors protéger au moins une autre information entrant dans le calcul de 1 ' information divulguée (par exemple un aléa de force suffisante) . Pour éviter la compromission du PW sur le réseau, une première solution consiste à utiliser un canal de communication sécurisé, dont les informations échangées sont chiffrées. D'où l'intérêt d'utiliser une session SSL qui est supportée en standard par tous les navigateurs sérieux. Mais l'utilisation du protocole SSL n'élimine pas pour autant tous les risques, notamment celui d'être en communication avec un faux site se faisant passer pour le site légitime. On analyse les faiblesses de l'authentification par ID / PW dans une session SSL : Ces faiblesses proviennent essentiellement d'une gestion trop laxiste des navigateurs du marché. La situation s'améliore petit à petit, au fur et à mesure des évolutions des principaux navigateurs du marché, à commencer par « Internet Explorer » de Microsoft et « Firefox » de la fondation Mozilla. En fait, l'utilisateur va se baser sur les indications fournies par le navigateur utilisé pour accepter ou non de saisir son PW. Autrement dit, un navigateur constitue une "application de confiance" puisque c'est le navigateur qui met en œuvre le protocole SSL pour le compte de l'utilisateur. Mais la vigilance de l'utilisateur peut trop facilement être trompée : l'utilisateur ne verra pas forcément qu'il manque le cadenas qui symbolise l'existence d'une session SSL, il ne s'aperçoit pas toujours qu'il n'est pas sur le bon site serveur,

il ne vérifie pas en général le certificat du serveur et il n'a que rarement la compétence pour savoir si un certificat est valide ou non, le navigateur alerte en principe l'utilisateur si le certificat n'a pas été émis par une Autorité de

Certification (AC) de confiance mais il ne bloque pas, l'utilisateur répondant souvent mécaniquement par la positive à la question posée de savoir s'il fait ou non confiance à cette AC, et la non- révocation du certificat est rarement vérifiée, enfin, une AC est considérée comme étant de confiance s'il en a été ainsi déclaré au préalable, ce qu'un utilisateur a pu faire sans se douter de la portée de cette déclaration ou pire, qu'un tiers ayant eu accès au poste utilisateur a pu faire à l'insu de l'utilisateur légitime.

On rappelle qu'on s'intéresse à tous types d'utilisateurs dont les particuliers et pas seulement aux utilisateurs à titre professionnel à partir de leur bureau. Les particuliers sont en général administrateurs de leur poste utilisateur et ils ont par définition tous les droits d'administration sans forcément en faire un usage prudent, sans compter leurs enfants, encore moins prudents, ce qui constitue à l'évidence un facteur d'aggravation des risques. II reste enfin le risque de compromission du mot de passe sur le poste utilisateur.

On peut identifier quatre volets à ce risque : l'écoute de la saisie du PW par un « keylogger » ou autre « spyware » (espions locaux) , - l'interception des données des scripts échangés avec le serveur, juste avant leur chiffrement SSL, dont le PW ou une donnée dont il est possible de déduire le PW, l'utilisation à l'insu de l'utilisateur d'une session SSL après authentification réussie de l'utilisateur,

la compromission d'une application de confiance à l'exemple du navigateur qui a pu être soit modifié pour divulguer le PW, soit substitué par un spyware. Il existe des solutions logicielles anti-spyware mais comme en matière de solutions anti-virus et de « firewall » : leur mise en œuvre est laissée à la seule initiative des utilisateurs, les logiciels en question ne sont pas toujours gratuits, - ils ne sont pas nécessairement à jour, et ils ne sont pas toujours efficaces contre toutes les menaces qui émergent.

De façon synthétique, on constate que les risques de compromission des mots de passe ne sont que rarement et imparfaitement contrés par des mesures qui restent parfois à imaginer et à développer : keylogging et autres formes de spyware sur le poste utilisateur,

« phishing » passif via de faux sites, - phishing actif par intermédiation via de faux sites ou par emprunt de session SSL sur le poste utilisateur.

IH) Solution proposée

La question est de savoir comment authentifier un utilisateur par mot de passe en limitant sérieusement le risque de compromission de ce mot de passe.

L'analyse montre que l'un des principaux risques est que l'utilisateur finisse par divulguer librement son mot de passe entre des mains malintentionnées ayant réussi à tromper sa confiance .

La question devient donc de savoir comment permettre à un utilisateur de reconnaître le serveur légitime auprès de qui il pourra dès lors s'authentifier en toute confiance.

La solution selon l'invention répond à ce risque principal ainsi qu'aux autres risques identifiés.

Tout d'abord, il convient d'écarter la fausse bonne idée d'une reconnaissance du serveur légitime par présentation à l'utilisateur d'un signe de reconnaissance convenu à l'avance (phrase ou image) .

Il est en effet impossible de présenter un tel signe de reconnaissance à l'utilisateur sans qu'un spyware ne puisse à cette occasion prendre connaissance de ce secret. Il faut bien au moins afficher le signe de reconnaissance et il est alors au minimum possible pour un spyware de faire à ce moment-là une copie d'écran.

Le secret qu'est censé être le signe de reconnaissance est dès lors compromis, sans que l'utilisateur puisse le soupçonner. Lors d'un prochain accès, il devient alors possible d'utiliser le signe de reconnaissance pour se faire passer pour le serveur légitime et l'utilisateur saisira en toute confiance son PW qui se trouve alors à son tour compromis .

On a déjà signalé que les navigateurs sont des "applications de confiance". En fait, il semble clair que la solution passe nécessairement par l'utilisation d'une telle application de confiance.

On peut choisir d'attendre que les éditeurs des navigateurs résolvent le problème de l'authentification en toute confiance ou adopter une position plus volontariste : imaginer et concevoir une application de confiance venant temporairement en renfort des navigateurs actuels espérer que les éditeurs des navigateurs adoptent la solution selon l'invention et finissent par l ' intégrer directement dans les navigateurs .

En attendant l ' intégration des fonctions de confiance directement dans les navigateurs, la solution transitoire passe par la définition d'une extension au navigateur (bien entendu, son implémentation dépendra du navigateur cible mais notre

propos est ici d'en décrire les fonctions, pas 1' implémentation) .

Selon l'invention, on fait appel à une solution voisine de la technique « PwdHash » développée par l'Université de Stanford. Il s'agit d'une extension qui vient renforcer le navigateur dans sa dimension de confiance relative à l'authentification des utilisateurs.

On rappelle que Pwdhash est une extension qui remplace le PW saisi par l'utilisateur par le hash (fonction de hachage) du PW et du nom de domaine du serveur tel qu'observé du poste utilisateur. De ce fait, si l'utilisateur est victime d'un faux site, il ne lui divulgue pas pour autant : ni son PW ni même une information réutilisable par le faux site vis à vis du site légitime.

Cette solution a un grand mérite mais ne répond pas complètement au problème posé. En fait, cette solution reste partielle mais surtout elle est à la main de chaque utilisateur qui souhaite se protéger contre les risques de compromission de son PW; la solution restant tout à fait transparente vis à vis des serveurs . Or la problématique est en réalité à peu près inverse : c'est au serveur de protéger les données privatives qu'il renferme et en cas d'ordres en ligne, c'est encore le serveur qui a besoin de vérifier que l'ordre émane bien de son client. Le client appréciera d'autant plus les services rendus par le serveur que celui-ci est capable de le protéger contre ces soucis d'usurpation d'identité.

Cela dit, il est évident qu'aucune sécurité n'est possible en cas de comportement non responsable des utilisateurs. Mais il incombe au serveur d'expliquer à ses utilisateurs ce qui est attendu d'eux et sans leur attribuer des responsabilités hors de portée ou déraisonnables.

La solution recherchée n'a nullement besoin d'être transparente vis à vis des serveurs . Mais il est néanmoins souhaitable de limiter les impacts sur le serveur dont on veut

renforcer la sécurité des accès; d'où l'idée d'un impact limité à la fonction d'authentification laissant inchangés les traitements à proprement parler du serveur.

On retire encore de Pwdhash l'idée d'une activation explicite et volontaire de l'extension de confiance par l'utilisateur. La frappe d'une touche fonction ("F2" par exemple) signale ainsi à l'extension de confiance qu'une séquence d'authentification est demandée pour la fenêtre du navigateur qui a le focus . L'extension ouvre alors une nouvelle fenêtre, "popup", dédiée au processus d'authentification en toute confiance.

Un peu de redondance ne fait pas de mal en matière de sécurité et l'extension commence par demander à l'utilisateur le nom du domaine auquel il souhaite accéder. A priori, c'est une information redondante puisque l'utilisateur s'est déjà rendu sur le site auquel il entend accéder, au moyen des mécanismes de son navigateur, dont : la saisie de l'URL, voire directement de l'adresse

- la sélection d'un favori, ou encore par le click souris sur un lien. Mais ces mécanismes ne garantissent pas que l'utilisateur soit arrivé sur le site qu'il croit. La saisie du nom de domaine (par exemple celui de sa Banque en Ligne "lcl.fr") introduit une redondance qui permet des contrôles avec les données du site réellement accédé : existence d'une session SSL, correspondance du certificat du serveur accédé avec le nom de domaine saisi, - validité du certificat en question.

L'extension de confiance effectue ces contrôles sans le laxisme habituel des navigateurs : la liste des AC racine ne sera pas modifiable par l'utilisateur (ce sera au serveur de s'y adapter),

un certificat expiré ou révoqué ne pourra pas être admis (on ne pose même pas la question à l'utilisateur) .

Ce n'est qu'après ces contrôles que l'utilisateur sera sollicité pour saisir son ID et son PW, ce qu'il peut alors faire en confiance dans le popup de l'extension.

L'extension intègre une fonction permettant d'empêcher les keyloggers et autres spywares d'écouter la saisie, notamment du PW. Différentes solutions existent pour réaliser cette fonction anti-keylogger avec néanmoins des efficacités variables selon les solutions .

L'utilisateur saura par ailleurs que la saisie de son PW n'est autorisée que dans cette séquence précise : accès au serveur réalisé - frappe de la touche fonction retenue ouverture d'un popup saisie du nom de domaine saisie de I ¹ ID et du PW.

A noter qu'il peut être judicieux d'afficher entre la saisie de I ¹ ID et celle du PW, un message d'accueil en provenance du serveur du type "bonjour M. Ulrik BERGSTEN, votre dernier accès date de telle heure tel jour". Cela n'est pas critique mais ne peut que contribuer à une vigilance accrue de l'utilisateur en vue de la saisie cruciale de son PW. Toujours inspiré de Pwdhash, la communication avec le serveur se fait via la fenêtre initiale et donc via les scripts transmis par le serveur. Mais dans la mesure où l'interface homme - machine est localisée dans le popup de l'extension de confiance, les champs de ces scripts n'ont pas à être visualisés.

Ces champs sont lus par l'extension pour les informations transmises par le serveur à l'intention de l'extension de confiance et sont renseignés par l'extension de confiance pour leur communication au serveur (le "post" étant également déclenché par l'extension de confiance) .

Un spyware pourra observer ces champs et c'est pourquoi, il convient de n'échanger par ce biais que des données non secrètes. Il faut en effet rappeler que même s'il y a bien mise en œuvre du protocole SSL, celui-ci est un protocole de niveau transport des données et non pas de niveau applicatif (le chiffrement des données échangées n'intervient qu'après leur envoi applicatif par le "post" et on a le même problème en réception) .

Par ailleurs, on a déjà rappelé qu'il ne faut pas communiquer le PW lui-même au serveur pour limiter les possibilités d'attaques au niveau du serveur.

On voit ici qu' il convient de mettre en œuvre une authentification en « zéro knowledge » (ou « divulgation nulle ») . La solution « SRP » (version 6a) de l'Université de

Stanford est particulièrement bien adaptée à cette partie de notre problème.

Voici donc en substance la nature des échanges entre l'extension de confiance et le serveur, après confirmation qu'on est bien au contact du serveur légitime :

Extension de confiance Serveur

Saisie ID Transmission ID Préparation message d'accueil (ID) Recherche s et v (ID) Tirage aléa b Calcul B (b, v)

Affichage message d'accueil ^- Transmission message d'accueil + s + B

Saisie PW

Tirage aléa a

Calcul A (a)

Calcul MKl (a, B, s, PW)

Calcul AUTl (A, B, MKl)

Transmission A + AUTl -> Calcul MK2 (A, b, s, v) Calcul AUT2 (A, B, MK2) Contrôle d'accès OK (si AUTl == AUT2)

Quelques explications :

v est le vérificateur connu du serveur et correspondant au PW de l'utilisateur identifié par

ID, s est un sel choisi lors du calcul de v à partir du

PW, c'est-à-dire un nombre choisi à l'initialisation du compte,

A est calculé à partir de a de telle façon que la connaissance de A ne permette pas de retrouver a,

B est calculé à partir de b mais aussi à partir de A et de v, toujours de telle façon que la connaissance de B ne permette pas de retrouver b (ni v) , MK est une clé calculée de deux façons différentes, d'une part du côté de l'extension de confiance MKl et d'autre part du côté serveur MK2 ; si le PW utilisé par l'extension de confiance correspond bien au vérificateur v utilisé côté serveur alors MKl == MK2, AUT est l'authentifiant permettant au serveur de reconnaître l'utilisateur ; il est calculé des deux côtés à partir respectivement de MKl et de MK2 et si MKl == MK2 alors AUTl == AUT2.

Pour plus de détails, on peut consulter le site "srp.stanford.edu".

Les informations échangées sont en définitive les suivantes :

- ID

Message d'accueil + s + B A + AUTl.

L'interception possible de ces données ne révèle rien de véritablement secret, ne permet pas de déduire les secrets à proprement parler (a, b, v , MK ou PW) et ne sont pas réutilisables pour un nouvel accès au serveur.

Une fois que le serveur a reconnu l'utilisateur de cette façon, il n'a plus qu'à ouvrir l'accès à l'utilisateur via la fenêtre initiale (l'envoi de ces données permet à l'extension de confiance de constater que son rôle est terminé et elle pourra fermer le popup) .

IV) Extensions envisageables

La solution de base peut faire l'objet d'extensions et en particuliers les suivantes : empêcher l'emprunt par un parasite d'une session valablement ouverte, valider des transactions en ligne, renforcer l'authentification par un second facteur d'ordre biométrique.

Extension pour résister aux parasites

Une fois que le serveur a reconnu l'utilisateur, il suffit, dans cette variante, de continuer à s'appuyer sur l'extension de confiance jusqu'à la fermeture de l'accès au serveur.

L'extension de confiance intercepte chaque « post » émanant de la fenêtre ayant fait l'objet de l'authentification pour ajouter aux données transmises un sceau. Ce sceau pourrait typiquement être le hash de MKl et du hash des données applicatives, l'extension de confiance ayant gardé en mémoire la valeur de MKl .

Le serveur sait si le sceau est exigé ou non; cela peut d'ailleurs être son choix, soit pour l'ensemble des requêtes en provenance de l'utilisateur soit pour celles où il l'aura demandé. Le serveur aura également gardé en mémoire la valeur de MK2 de façon à pouvoir vérifier le cas échéant la présence effective d'un sceau et sa validité.

De cette façon, un éventuel parasite greffé au navigateur ne pourra pas emprunter la session ouverte pour accéder en parallèle au serveur au nom de l'utilisateur mais à son insu.

Extension pour valider des transactions en ligne

Le serveur souhaite que l'utilisateur valide formellement une transaction en saisissant une nouvelle fois son PW au vu des données de la transaction ; celle-ci étant faite en ligne à travers une session valablement ouverte.

Pour cela le serveur envoie le texte reprenant les données de la transaction à valider avec un indicateur de demande de validation destiné à l'extension de confiance. Au vu de cet indicateur, l'extension de confiance ouvre à nouveau un popup mais il n'est pas utile de recommencer tout le processus d'authentification.

L'extension de confiance affiche dans le popup le texte des données de la transaction à valider et demande à l'utilisateur de valider la transaction en saisissant de nouveau son PW.

L'extension de confiance a gardé en mémoire les données ayant servi lors du processus d'authentification et en particulier les valeurs de ID, de s et de MKl mais pas le PW trop sensible. Cela lui permet de calculer le vérificateur auquel correspond le couple ID / PW (à partir de ID, de s et de PW) .

A partir de là, l'extension de confiance calcule SEl comme étant le hash de v, de MKl et du hash du texte des données de la transaction à valider. La donnée SEl est alors retournée au serveur.

Le serveur calcule de façon indépendante SE2 de la même façon. La transaction sera considérée comme validée si SEl == SE2. Cela démontre en effet sans risque de divulgation de secrets que : le texte validé est le même que le texte à valider, le PW saisi est le bon.

A noter qu'il est important de faire intervenir v car sinon le serveur ne pourrait pas vérifier que le PW nouvellement

saisi est le bon. A noter aussi que c'est l'utilisation de MKl qui empêche la divulgation de secrets (PW ou v) .

Extension avec authentification à deux facteurs

En dépit de toutes les précautions prises, on ne peut jamais tout à fait exclure la compromission du PW, en particulier par compromission de l'extension de confiance ou tout simplement par négligence de l'utilisateur.

Le PW constitue un premier facteur d' authentification et l'idée de cette variante est d'y adjoindre un second facteur d' authentification.

Nous avons énoncé que nous cherchons des solutions d' authentification qui ne nécessitent l'utilisation d'aucun matériel additionnel au poste utilisateur de base. II n'est donc pas possible d'utiliser comme second facteur "quelque chose que possède l'utilisateur" puisqu'il s'agirait justement de quelque chose de matériel comme par exemple une carte à puce + lecteur ou une clé USB ou une "calculette" capable de générer des mots de passe dynamiques ou des réponses à challenge.

On songe donc à utiliser une « caractéristique propre à l'utilisateur », donc un facteur biométrique.

Mais pour pouvoir capter cette caractéristique, il faut en général un périphérique adapté à cet effet, ce qu'on a exclu du champ de la présente solution.

Pourtant il reste bien une caractéristique propre à chaque utilisateur et qui ne nécessite aucun périphérique autre que ceux dont est doté tout poste utilisateur : la façon de saisir un texte sur un clavier d'ordinateur. L'idée est ainsi dans cette variante de compléter

1' authentification par PW par un procédé biométrique de cette nature et pourquoi pas par le procédé "Psylock" développé par IBI, Institute for Bank Innovation, et par l'Université de Regensburg, également en Allemagne.

On rappelle que ce procédé suppose que l'utilisateur se soit enregistré au préalable en saisissant typiquement une page et demi de texte, de façon à déterminer son profil de frappe clavier. Ce profil serait évidemment conservé par le serveur avec les autres données d'authentification (ou sur un serveur dédié à cet effet) .

Lors d'une authentification, l'utilisateur est appelé à saisir un texte plus court, de l'ordre d'une ou de deux lignes de textes, ce qui suffit alors à déterminer si on est ou non en présence de l'utilisateur enregistré.

L'intérêt de ce procédé est que sa mise en œuvre ne risque pas de divulguer de secrets et si on a choisi un texte variable, on peut aussi empêcher la réutilisation des données issues d'une authentification réussie. En revanche, la fiabilité n'est peut-être pas suffisante pour authentifier un utilisateur au moyen de ce seul facteur biométrique.

D'où la complémentarité toute naturelle, d'une part, avec la solution de base relative à l' authentification de l'utilisateur et, d'autre part, avec l'extension relative à la validation de transactions en ligne. Le recours à ce second facteur d'authentification pourra être soit systématique soit modulé selon une certaine fréquence ou selon l'enjeu.

Ainsi, l'invention concerne un procédé d'authentification d'un utilisateur par un serveur, accédé par un réseau informatique, notamment le réseau Internet ; ce procédé comprend : une première étape de reconnaissance, par l'utilisateur, du serveur désiré, et - une seconde étape d'authentification de l'utilisateur par le serveur, le procédé, qui fait intervenir un mot de passe fourni par l'utilisateur, étant tel que l'utilisateur ne soit pas contraint à utiliser un dispositif particulier autre qu'un terminal de connexion au réseau informatique,

• la première étape comportant :

- l'accès au serveur par une adresse URL selon le protocole HTTPS avec établissement d'une session SSL ou TLS,

- l'émission par le serveur d'une requête demandant à l'utilisateur de s'authentifier,

- l'activation par l'utilisateur, après réception de cette requête, d'une application de confiance constituant une extension de son navigateur,

- l'affichage, par l'application de confiance, d'une fenêtre destinée à gérer le processus d'authentification,

- la demande à l'utilisateur, par l'application de confiance via la fenêtre, de saisir le nom de domaine du serveur auquel il désire se connecter, les contrôles effectués par l'application de confiance sont les suivants :

- existence d'une session SSL ou TLS avec le serveur,

- correspondance du certificat du serveur accédé avec le nom de domaine saisi, - validité du certificat, le certificat n'étant considéré comme valide que s'il a été émis par une autorité de certification reconnue et que s'il est ni expiré, ni révoqué, de sorte que l'utilisateur a pu vérifier qu'il est connecté au serveur souhaité,

• la seconde étape du procédé comportant :

- la demande, par l'application, de la saisie par l'utilisateur de son identifiant auprès du serveur,

- la saisie du mot de passe par l'utilisateur, cette saisie étant de préférence protégée contre l'espionnage local, l'application de confiance étant telle qu'elle ne communique directement le mot de passe ni au navigateur, ni au serveur, l'application de confiance et le serveur mettant en œuvre une authentification à divulgation nulle telle, d'une

part, qu'un secret dynamique est partagé entre l'application de confiance et le serveur et que, d'autre part, l'authentification de l'utilisateur par le serveur est réalisée au moyen de ce secret partagé ; de sorte que l'authentification de l'utilisateur par le serveur est réalisée en minimisant les risques de compromission du mot de passe de l'utilisateur.

Dans une réalisation, entre la saisie de l'identifiant et la saisie du mot de passe, un message d'accueil est fourni par le serveur contenant une information non publique liée à la relation entre l'utilisateur et le serveur, de sorte à confirmer à l'utilisateur qu'il est en relation avec le serveur désiré.

Dans une réalisation pour laquelle pour se prémunir contre une usurpation de session préalablement ouverte et pour laquelle session, l'utilisateur s'est préalablement authentifié, le procédé fait appel au secret partagé entre l'application de confiance et le serveur pour calculer et ajouter un sceau aux données transmises par le navigateur vers le serveur, le serveur rejetant les données dépourvues de sceau ou avec un sceau incorrect .

Dans une réalisation, pour valider une transaction au cours d'une session préalablement ouverte :

- le serveur présente les données de la transaction à l'utilisateur via l'application de confiance, - l'application de confiance recueille le consentement de l'utilisateur en lui demandant de saisir de nouveau son mot de passe, ce dernier étant de préférence protégé contre l'espionnage local de saisie,

- l'application de confiance transmet un sceau calculé à partir des données de la transaction, du mot de passe nouvellement saisi et du secret partagé, le serveur vérifiant le sceau de façon à rejeter la transaction en l'absence de sceau ou avec un sceau incorrect.

Dans une réalisation, on renforce l'authentification par mot de passe, par une authentification avec un second

facteur de type biométrique, ce second facteur d'authentification consistant à reconnaître l'utilisateur par son comportement lors de la saisie d'un texte communiqué par le serveur via l'application de confiance, de sorte que la seconde authentification n' exige pas de périphérique additionnel à connecter au poste de l'utilisateur.