Brevet FR3070516A1 — publié le 20190301

Procédé d'authentification d'un utilisateur auprès d'un serveur d'authentification Domaine technique de l'invention L'invention a pour objet un procédé d'authentification d'un utilisateur auprès d'un serveur d'authentification. Le domaine de l'invention est celui de l'authentification. Plus précisément le domaine de l'invention de l'authentification pour les applications ou les portails d'applications web. Ces applications et portails nécessitent des mécanismes d'authentification à la fois robustes et simple à utiliser pour convenir à différentes population d'utilisateurs. Ces populations sont soit les employés des entreprises soit leurs clients. Certaines opérations, au travers de ces applications, nécessitent un haut niveau d'authentification, comme par exemple les applications permettant des transactions bancaires. Les mécanismes d'authentification doivent être suffisamment robustes pour certifier que l'utilisateur authentifié n'est pas une identité usurpée. Les mécanismes d'authentification doivent être suffisamment simples à utiliser pour ne pas dérouter les utilisateurs. Etat de la technique antérieur Les mécanismes classiques d'authentification reposent sur des identifiants « login » et des mots de passe. La faiblesse de l'utilisation des mots de passe n'est plus à démontrer. Des nouveaux mécanismes d'authentification de type multi-facteurs sont utilisés pour renforcer les mécanismes d'authentification classiques. Le principe des authentifications multi-facteurs reposent sur le principe « ce que je connais ET ce que je possède ». L'objet possédé permet de rajouter un facteur d'authentification, par exemple une clé USB contenant un secret ou un mécanisme de chiffrement par clé privé, une clé ou une application générant des mots de passe non réutilisable (One Time Password ou mot de passe OTP) synchronisés avec un serveur, etc. D'autres principes multi-facteurs, utilisent le téléphone mobile de l'utilisateur, pour recevoir, un code d'authentification, par mail, par SMS ou par notification push,... L'utilisation du téléphone mobile offre plusieurs avantages : - L'utilisateur garde son téléphone avec lui en permanence : Il est plus facile d'oublier ou de perdre une clé USB que son téléphone. 2 - Les téléphones sont toujours chargés (les tokens matériels posent des problèmes de changement de pile) - Les téléphones possèdent suffisamment de puissance de traitement pour réaliser des opérations de chiffrement complexes. 5 - Les téléphones ont accès aux réseaux 3G ou wifi, et à Internet Cependant, les envois de SMS ne sont pas considérés sécurisés car ils passent par l'infrastructure des opérateurs téléphoniques. De même, les envois de mail posent des problèmes de délais d'acheminement, et ne peuvent pas être utilisés pour protéger l'accès à une messagerie mail. 10 Encore, les mécanismes d'envois des notifications dépendent des infrastructures des constructeurs des téléphones mobiles. Ces infrastructures proposent leurs propres mécanismes de sécurisation des communications et d'identifications des téléphones, mais l'ensemble des données transite par une infrastructure tierce non-maitrisée. Ces infrastructures de notification, même si elles proposent un coût réduit, voire nul, 15 et des mécanismes de transfert de données entre les serveurs et les téléphones, ne sont utilisable comme mécanisme d'authentification qu'en mettant en oeuvre des mécanismes de sécurisation indépendants. Les mécanismes d'authentification par notifications utilisent les infrastructures de notification tierce de la façon suivante : 20 - En envoyant dans la charge de la notification, un mot de passe à usage unique d'authentification, comme dans les mécanismes par SMS ; - Ou en envoyant dans la charge de la notification, des jeux de jetons chiffrés, que seul le téléphone enrôlé peut déchiffrer ; - Ou en envoyant dans la notification, l'URL du serveur demandant 25 l'authentification et qui sert de point d'accès pour récupérer les données de l'OTP d'authentification ; - Et en demandant à l'utilisateur d'approuver la notification et donc l'authentification par validation d'un formulaire présentant les données de la demande d'authentification 30 - Et en se connectant au point d'accès du serveur émetteur de la demande, pour renvoyer la réponse à la demande d'authentification sous la forme d'un OTP sur-chiffré ou déchiffré avec les secrets connus du téléphone enrôlé. 3 Les problèmes techniques des méthodes précédentes sont liés à la difficulté de construire un principe d'authentification, indépendant de l'infrastructure de notification, des failles de sécurité inhérentes aux téléphones eux-mêmes, et en la sécurisation des communications entre les nombreux serveurs demandant des authentifications et 5 les téléphones. L'infrastructure de notification ne peut pas être considérées comme sure car elle dépend d'un tiers. Les identifications des téléphones dans les infrastructures de notification peuvent varier en fonction de paramètres non maitrisés. 10 Les infrastructures de notifications ne sont pas nécessairement homogènes entre les différents fournisseurs. Leurs caractéristiques peuvent aussi changer dans le temps ; renouvellement des clés d'accès pour les serveurs d'authentifications, évolution des protocoles. Lors de l'évolution technique de l'infrastructure de notification, ou de l'évolution 15 technique de l'application qui reçoit les notifications, les clés d'API utilisées ou les identifications peuvent changer à l'initiative du fournisseur de l'infrastructure de notification. Si les clés d'API sont utilisée par plusieurs serveurs de plusieurs clients, il est nécessaire de redéployer une nouvelle version contenant les nouvelles clés d'API. Ces clés d'API doivent être conservée de manière sécurisée car elles sont liées à zo l'application mobile recevant les notifications, la perte de ses clés peut entrainer la mise en péril des mécanismes d'authentification de l'ensemble des utilisateurs de l'application mobile et de tous les clients du service. Les téléphones ne sont pas considérés comme sûrs car ils peuvent être volés ou utilisés au détriment de l'utilisateur légitime. 25 Les applications mobiles sont faiblement sécurisées ; par l'utilisation des certificats systèmes qui peuvent être corrompus, par copie des données ou clonage de l'application sur un autre téléphone, ... L'infrastructure de communication entre les téléphones et les serveurs d'authentification n'est pas considérée comme sure car elle peut passer par des 30 connexions 3G ou wifi non maitrisées. De plus les connexions directes entre les téléphones mobiles et les serveurs d'authentification internes au réseau de l'entreprise, sont souvent impossibles ou source de faille dans le réseau de l'entreprise. 4 Des services mutualisés dédiés à l'authentification des utilisateurs grâce à leur téléphone mobile existent. Ils sont utilisables grâce à des APIs (WebService ou REST) ou des protocoles de fédération d'identités comme OpenIDConnect ou SAML. Mais ces services doivent connaitre l'identité des utilisateurs et doivent gérer et stocker les 5 secrets échangés avec les téléphones. Les utilisateurs sont donc déclarés et connus d'un service externe à l'entreprise. Ces services posent donc un problème de confidentialités et de responsabilité dans la gestion des utilisateurs. On peut par exemple citer MobileConnect qui est géré par les opérateurs téléphoniques. L'opérateur de ce service connait les utilisateurs nominativement, possède une grande 10 quantité de méta-data sur lui, ainsi que l'intégralité de son historique d'authentification. Les problèmes techniques que l'on cherche à résoudre sont donc: - Authentifier un utilisateur grâce à son téléphone mobile en lui envoyant une notification ne nécessitant qu'une interaction très simple mais sécurisée pour valider l'authentification ; 15 - Utiliser les mécanismes d'envois de notifications des fournisseurs de téléphones de manière sécurisée ; - Fournir un mécanisme qui s'affranchit des contraintes réseau et sécurité des entreprises, en utilisant que des connexions sortantes ; - Fournir un service mutualisé pour plusieurs clients, tout en garantissant que les 20 authentifications des utilisateurs de chaque client sont traitées de façon cloisonnée. Une parfaite étanchéité est requise entre les données d'authentification de chaque client, les clés d'enrôlements des téléphones des utilisateurs ne sont pas partagées entre les clients ; - Fournir un service mutualisé d'authentification qui ne possède aucune 25 information sur les utilisateurs qui l'utilisent. La gestion de l'utilisateur et des clés associées à son téléphone est maitrisée par l'entreprise cliente du service ; - Transmettre depuis un serveur d'authentification qui peut être interne au réseau de l'entreprise, un OTP que seul le téléphone mobile destinataire peut déchiffrer ; 30 - Transmettre depuis le téléphone mobile de l'utilisateur, l'OTP déchiffré servant de preuve d'identité, au serveur d'authentification qui peut être interne au réseau de l'entreprise ; 5 - Recevoir sur le serveur d'authentification de l'entreprise, la preuve de l'authentification de l'utilisateur ; Exposé de l'invention 5 L'invention résout ces problèmes en mettant en oeuvre un serveur mandataire d'authentification qui ordonnance les communications entre un calculateur, un serveur d'authentification et un serveur de notification. Les communications entre les différents appareils sont sécurisées par l'utilisation de techniques de chiffrements, par exemple SSL, TLS, ou un équivalent. 10 L'invention a donc pour objet un procédé d'authentification d'un utilisateur auprès d'un serveur d'authentification, caractérisé en ce que le serveur d'authentification comporte : Une zone mémoire pour stocker un enregistrement associant : 15 o Un identifiant de l'utilisateur sur le serveur d'authentification ; o Un identifiant de l'utilisateur sur un serveur mandataire d'authentification; o Une clé publique d'une bi-clé; le procédé permettant d'authentifier l'utilisateur ayant à sa disposition un calculateur comprenant : 20 Une zone mémoire pour stocker la clé privée de la bi-clé ; Une zone mémoire pour stocker un identifiant de l'utilisateur sur un serveur de notifications ; Une zone mémoire pour stocker un identifiant de l'utilisateur sur le serveur mandataire d'authentification ; 25 l'authentification se faisant par l'intermédiaire du serveur mandataire d'authentification comprenant : Une zone mémoire pour stocker un enregistrement associant : o L'identifiant de l'utilisateur sur le serveur mandataire d'authentification ; o L'identifiant de l'utilisateur sur le serveur de notification 30 le procédé comportant les étapes suivantes : Production, par le serveur d'authentification, d'un message de mise à l'épreuve comportant : o Un aléa chiffré avec la clé publique o L'identifiant de l'utilisateur sur le serveur mandataire d'authentification 6 Emission du message de mise à l'épreuve, par le serveur d'authentification, vers le serveur de notification, le serveur d'authentification reçoit en réponse un jeton de mise à l'épreuve ; Production, par le serveur mandataire d'authentification à la réception d'un 5 message de mise à l'épreuve : o D'un jeton de mise à l'épreuve associé au message de mise à l'épreuve ; o D'un message de notification comportant : - L'identifiant de l'utilisateur sur le serveur de notification ; - Un jeton de notification, produit par le serveur mandataire 10 d'authentification, le jeton de notification étant associé, sur le serveur mandataire d'authentification au message de mise à l'épreuve ; Emission du message de notification, par le serveur mandataire d'authentification, vers le serveur de notification ; 15 Acheminement du message de notification par le serveur de notification ; Production par le calculateur, à la réception du message de notification d'un message de prise en charge de l'épreuve, le message de prise en charge de l'épreuve comportant : o L'identifiant de l'utilisateur sur le serveur mandataire d'authentification ; 20 o L'identifiant de l'utilisateur sur le serveur de notification ; o Le jeton de de notification ; Emission par le calculateur du message de prise en charge de l'épreuve vers le serveur mandataire d'authentification ; Production par le serveur mandataire d'authentification, à la réception du 25 message de prise en charge de l'épreuve, d'un message épreuve comportant : o L'aléa chiffré retrouvé grâce au contenu du message de prise en charge de l'épreuve ; Emission par le serveur mandataire d'authentification du message épreuve vers le calculateur ; 30 Production par le calculateur, à la réception du message épreuve, d'un message réponse comportant : o Le résultat du déchiffrement de l'aléa chiffré par l'utilisation de la clé privé ; 7 Emission par le calculateur du message réponse vers le serveur mandataire d'authentification ; Association par le serveur mandataire d'authentification, à la réception du message de réponse, du résultat du déchiffrement et du jeton de mise 5 l'épreuve ; Interrogation par le serveur d'authentification du serveur mandataire d'authentification pour obtenir le contenu du message de réponse associé au jeton de mise à l'épreuve ; Comparaison par le serveur d'authentification du contenu du message de 10 réponse avec l'aléa produit pour déterminer le résultat de l'authentification. Avantageusement l'invention peut aussi être combinée avec les caractéristiques suivantes la bi-clé, l'identifiant d'utilisateur sur le serveur mandataire, l'identifiant d'utilisateur sur le serveur de notification sont produits lors d'un enrôlement du 15 calculateur, ledit enrôlement se déroulant comme suit, l'utilisateur ayant à sa disposition le calculateur et un terminal sécurisé connecté au serveur d'authentification : L'utilisateur s'enregistre, avec le calculateur, sur le serveur de notification et obtient l'identifiant utilisateur sur le serveur de notification ; 20 L'utilisateur utilise le terminal sécurisé pour s'authentifier et émettre un message de demande d'enrôlement vers le serveur d'authentification ; Production, par le serveur d'authentification à la réception d'un message de demande d'enrôlement des éléments suivants : o Une bi-clé associée à l'utilisateur ; 25 o Un message de démarrage d'enrôlement émis vers le serveur mandataire d'authentification ; Mise en oeuvre, par le serveur mandataire d'authentification à la réception d'un message de démarrage d'enrôlement, des actions suivantes : o Création d'un enregistrement associant : 30 - Un identifiant d'utilisateur sur le serveur mandataire ; - Un jeton d'enrôlement ; o Production d'un message d'enrôlement démarré comportant : - L'identifiant d'utilisateur sur le serveur mandataire ; - Le jeton d'enrôlement ; 8 o Emission du message d'enrôlement démarré en réponse au message de démarrage d'enrôlement ; Mise en oeuvre, par le serveur d'authentification à la réception (3080) d'un message de démarrage d'enrôlement, des actions suivantes : 5 o Production d'un message d'acceptation d'enrôlement comportant : - Au moins la clé privée de la bi-clé ; - Le jeton d'enrôlement ; o Emission du message d'acceptation d'enrôlement en réponse au message de demande d'enrôlement ; 10 Mise en oeuvre, par le terminal sécurisé à la réception d'un message d'acceptation d'enrôlement : o Affichage, sur un écran du terminal sécurisé du contenu du message reçu ; Acquisition, par le calculateur, de données affichées sur l'écran du terminal 15 sécurisé ; Mise en oeuvre, par le calculateur suite à l'acquisition des données, des actions suivantes : o Création d'un enregistrement associant : - Au moins la clé privée de la bi-clé 20 - L'identifiant de l'utilisateur sur le serveur de notification o Production d'un message de finalisation d'enrôlement comportant - Le jeton d'enrôlement ; - L'identifiant sur le serveur de notification ; o Emission du message de finalisation d'enrôlement vers le serveur 25 mandataire d'authentification ; Mise en oeuvre, par le serveur mandataire suite à la réception d'un message de finalisation d'enrôlement des actions suivantes : o Si un enregistrement correspond au jeton d'enrôlement du message de finalisation alors : 30 - Association de l'identifiant sur le serveur de notification avec l'enregistrement correspondant ; - Production d'un message d'enrôlement finalisé comportant : - L'identifiant sur le serveur mandataire d'authentification de l'enregistrement correspondant ; 9 - Emission du message d'enrôlement finalisé en réponse au message de finalisation d'enregistrement ; - Emission d'un message de confirmation d'enrôlement vers le serveur d'authentification ; 5 - Effacement du jeton d'enrôlement ; Mise en oeuvre, par le calculateur à la réception d'un message d'enrôlement finalisé des actions suivantes : o Association à l'enregistrement correspondant au message de finalisation d'enregistrement de l'identifiant sur le serveur mandataire. 10 Avantageusement l'invention peut aussi être combinée avec les caractéristiques suivantes : l'accès à des zones mémoire du calculateur est verrouillé par un mécanisme de sécurité local au calculateur. 15 L'invention sera mieux comprise à la lecture de la description qui suit et à l'examen des figures qui l'accompagnent. Ces figures sont présentées à titre d'exemple nullement limitatif. Sur des figures différentes, des références identiques font références à des éléments identiques. Ce peut être le même élément ou des éléments ayant les mêmes fonctions. 20 Brève description des figures Les figures montrent : - La figure 1, une illustration de moyens permettant la mise en oeuvre de l'invention ; 25 - La figure 2, une illustration essentiellement chronologique d'étapes du procédé d'authentification, les étapes étant représentées réparties par acteurs ; - La figure 3, une illustration essentiellement chronologique d'étape d'un procédé d'enrôlement pour la mise en oeuvre d'une authentification selon l'invention, les étapes étant représentées réparties par acteurs ; 30 Pour la désignation des acteurs on utilise la convention suivante : - C : calculateur ; - N : serveur de notification ; - TS : terminal sécurisé ; - A : serveur d'authentification ; 10 - MA : serveur mandataire d'authentification. Description détaillée d'un mode de réalisation La figure 1 montre un calculateur 100. La figure 1 montre que le calculateur 100 5 comporte : - Un microprocesseur 110 ; - Des moyens 120 de stockage. par exemple un disque dur, une carte mémoire, un composant intégré, ou une partie d'un composant intégré dédié au stockage de donnée ; 10 - Une interface 130 de communication ; - Des moyens 140 d'interface homme machine, par exemple un écran tactile. Ces moyens 140 d'interface homme machine peuvent aussi comporter une caméra. Le calculateur est par exemple un téléphone mobile intelligent. Dans la pratique un calculateur est tout dispositif apte à mettre en oeuvre une application utilisant un 15 service de notification. Un service de notification est, par exemple, Firebase Cloud Messaging (anciennement Google Cloud Messaging), Apple Push Notification Service, ou SignalR. Fonctionnellement l'utilisation d'un service de notification permet au calculateur de recevoir des messages en mode « push ». Le microprocesseur 110 du calculateur, les moyens 120 de stockage du calculateur, 20 l'interface 130 de communication du calculateur et les moyens 140 d'interface homme machine du calculateur sont interconnectés par un bus 150. D'une manière générale les moyens de stockage peuvent être locaux ou accessibles à distance. La figure 1 montre un serveur 200 de notifications. Un serveur de notification permet 25 la mise en oeuvre d'un service de notification du type de ceux déjà cités. Dans la pratique un service de notifications est mis en oeuvre par une architecture plus complexe, mais elle reste assimilable à un serveur. D'une manière classique un serveur de notifications connait des utilisateurs qu'il identifie par un identifiant d'utilisateur sur le serveur de notifications. Un serveur de 30 notification reçoit des messages comportant au moins un identifiant de destinataire et un contenu. Le serveur de notifications pousse les messages qu'il reçoit vers les destinataires identifiés. Classiquement un message géré par un serveur de notification comporte aussi un identifiant d'émetteur ce qui permet aux destinataires identifiés des messages de traiter les messages. 11 La figure 1 un montre que le serveur 200 de notifications comporte : - Un microprocesseur 210; - Des moyens 220 de stockage ; - Une interface 230 de communication ; 5 Le microprocesseur 210 du serveur 200 de notification, les moyens 220 de stockage du serveur 200 de notification, l'interface 230 de communication du serveur 200 de notification sont interconnectés par un bus 250. La figure 1 montre un serveur 300 mandataire d'authentification. Le serveur 300 mandataire permet une isolation forte d'un serveur 400 d'authentification d'une 10 organisation. Grace au serveur 300 mandataire d'authentification n'est pas connecté directement à un réseau publique et donc ne peut pas être facilement attaqué. La figure 1 montre que le serveur 300 mandataire d'authentification comporte : - Un microprocesseur 310; - Des moyens 320 de stockage ; 15 - Une première interface 330 de communication ; - Une deuxième interface 340 de communication ; Le microprocesseur 310 du serveur 300 mandataire d'authentification, les moyens 220 de stockage du serveur 300 mandataire d'authentification, la première interface 330 de communication du serveur 300 mandataire d'authentification et la deuxième zo interface 340 de communication du serveur 300 mandataire d'authentification sont interconnectés par un bus 350. La figure 1 montre un serveur 400 d'authentification. La figure 1 montre que le serveur 400 d'authentification comporte : - Un microprocesseur 410; 25 - Des moyens 420 de stockage ; - Une interface 430 de communication ; Le microprocesseur 410 du serveur 400 d'authentification, les moyens 420 de stockage du serveur 400 d'authentification et l'interface 430 de communication du serveur 400 d'authentification sont interconnectés par un bus 450. 30 La figure 1 montre que l'interface de communication du calculateur 100, l'interface de communication du serveur 200 de notification et la première interface de communication du serveur 300 mandataire d'authentification sont connecté à un premier réseau 500. Dans l'invention le premier réseau 500 est un réseau publique, ou réseau ouvert, par exemple le réseau internet. 12 La figure 1 montre que la deuxième interface de communication du serveur 300 mandataire et l'interface de communication du serveur 400 d'authentification sont connecté à un deuxième réseau 510. Le deuxième réseau 510 est un réseau privé par opposition au premier réseau 500 publique. 5 La figure 1 montre que les moyens de stockage du serveur d'authentification comportent plusieurs zones. En particulier, pour l'invention, les moyens 420 de stockage du serveur d'authentification comportent : - Une zone non représenté pour enregistrer des codes instructions pour la mise en oeuvre du procédé selon l'invention ; 10 - Une zone 420.1 base de données utilisateur. Cette base de données utilisateurs est configurée pour permettre de stocker des enregistrements utilisateur du serveur d'authentification. Un enregistrement utilisateur du serveur d'authentification comporte une pluralité de champs dont au moins : o Un champ 420.1.1 identifiant utilisateur sur le serveur d'authentification ; 15 o Un champ 420.1.2 Identifiant utilisateur sur le serveur mandataire d'authentification et o Un champ 420.1.3 certificat comportant une bi-clé. Un enregistrement est une association de champs. Dans cette description on emploie le terme base de données au sens large. Il peut 20 s'agir d'un ou plusieurs fichiers plats de type fichier CSV, d'un ou plusieurs fichiers hiérarchiques de type XML ou JSON, d'un système de base de données relationnel de type SQL ou d'un système de base de données NoSQL. Cette énumération n'est pas exhaustive. La figure 1 montre que les moyens de stockage du calculateur comportent plusieurs 25 zones. En particulier, pour l'invention, les moyens 120 de stockage du calculateur 100 comportent : - Une zone non représentée pour enregistrer des codes instructions pour la mise en oeuvre du procédé selon l'invention ; - Une zone 120.1 mémoire pour enregistrer une clé privée d'une bi-clé ; 30 - Une zone 120.2 mémoire pour enregistrer un identifiant d'utilisateur sur le serveur 200 de notification ; - Une zone 120.3 mémoire pour enregistrer un identifiant de l'utilisateur sur le serveur 300 mandataire d'authentification ; 13 - Une zone 120.4 mémoire pour enregistrer une adresse du serveur mandataire d'authentification. Dans une mise en oeuvre de l'invention dans laquelle un utilisateur du calculateur 100 aurait besoin de plusieurs identités. La zone mémoire pour enregistrer une clé privée 5 d'une bi-clé, la zone mémoire pour enregistrer un identifiant d'utilisateur sur le serveur 200 de notification et la zone mémoire pour enregistrer un identifiant de l'utilisateur sur le serveur 300 mandataire d'authentification sont associées dans un enregistrement d'identification. Dans ce cas le calculateur est configuré pour pouvoir enregistrer plusieurs enregistrements d'identification. 113 La figure 1 montre que les moyens de stockage du serveur mandataire d'authentification comportent plusieurs zones. En particulier, pour l'invention, les moyens de stockage serveur mandataire d'authentification comportent : - Une zone non représentée pour enregistrer des codes instructions pour la mise en oeuvre du procédé selon l'invention ; 15 - Une zone 320.1 base de données utilisateurs. Cette base de données utilisateurs est configurée pour permettre de stocker des enregistrements utilisateur du serveur mandataire d'authentification. Un enregistrement utilisateur du serveur mandataire d'authentification comporte une pluralité de champs dont au moins : 20 o Un champ 320.1.1 identifiant de l'utilisateur sur le serveur mandataire d'authentification ; o Un champ 320.1.2 identifiant l'utilisateur sur le serveur de notification. Lorsque l'on prête une action à un dispositif celle-ci est en fait effectuée par un microprocesseur du dispositif commandé par des codes instructions enregistrés dans 25 une mémoire du dispositif. Si l'on prête une action à une application, celle-ci est en fait effectuée par un microprocesseur du dispositif dans une mémoire duquel des codes instructions correspondant à l'application sont enregistrés. Lorsqu'un dispositif, ou une application, émet un message, ce message est émis via une interface de communication dudit dispositif ou de la dite application. Dans ces cas, un dispositif est 30 réel ou virtuel. Dans la pratique un message comporte au moins des données permettant d'identifier émetteur et destinataire. La figure 2 illustre des étapes du procédé selon l'invention pour une authentification forte d'un utilisateur. Dans l'invention l'authentification forte se fait par l'obtention de la preuve de possession et de maîtrise du calculateur précédemment décrit. 14 La figure 2 montre une étape 2000 préliminaire dans laquelle le serveur d'authentification reçoit un message de demande d'authentification forte d'un utilisateur. Un tel message comporte au moins : - Un code instruction ; 5 - Une donnée d'identification de l'utilisateur à authentifier. Le code instruction permet au serveur d'authentification de déterminer quel traitement appliquer au message reçu. Ce code est facultatif s'il peut être déduit du contexte de réception. Le contexte de réception est, par exemple, le canal par lequel a été reçu le message, ce canal étant dédié à la réception de tel message. Un autre exemple de lo contexte peut aussi être, le rang du message dans une séquence de message. Par la suite il n'est plus préciser que les messages comportent un code instruction correspondant à leur nom. Il est implicite qu'il est utilisé un mécanisme permettant au destinataire du message de déterminer la nature du message. Une donnée d'identification du l'utilisateur à authentifier est une données qui permet 15 au serveur d'authentification de retrouver dans la base de données utilisateurs du serveur d'authentification l'enregistrement qui correspond à l'utilisateur à authentifier. Une telle donnée d'identification est donc soit directement un identifiant utilisateur sur le serveur d'authentification, soit une donnée associée à un identifiant utilisateur sur le serveur d'authentification. Une telle donnée est, par exemple, un email par exemple : 20 REVENDICATIONS1. Procédé d'authentification d'un utilisateur auprès d'un serveur (400) d'authentification, caractérisé en ce que le serveur d'authentification comporte : Une zone mémoire pour stocker un enregistrement associant : o Un identifiant (420.1) de l'utilisateur sur le serveur d'authentification ; o Un identifiant (420.2) de l'utilisateur sur un serveur mandataire d'authentification; o Une clé publique d'une bi-clé (420.3); le procédé permettant d'authentifier l'utilisateur ayant à sa disposition un calculateur (100) comprenant : Une zone (120.1) mémoire pour stocker la clé privée de la bi-clé ; Une zone (120.2) mémoire pour stocker un identifiant de l'utilisateur sur un serveur (200) de notifications ; Une zone mémoire (120.3) pour stocker un identifiant de l'utilisateur sur le serveur mandataire d'authentification ; l'authentification se faisant par l'intermédiaire du serveur (300) mandataire d'authentification comprenant : Une zone (320.1) mémoire pour stocker un enregistrement associant : o L'identifiant (320.1.1) de l'utilisateur sur le serveur mandataire d'authentification ; o L'identifiant (320.1.2) de l'utilisateur sur le serveur de notification le procédé comportant les étapes suivantes : Production (2000), par le serveur d'authentification, d'un message de mise à l'épreuve comportant : o Un aléa chiffré avec la clé publique o L'identifiant de l'utilisateur sur le serveur mandataire d'authentification Emission (2010) du message de mise à l'épreuve, par le serveur d'authentification, vers le serveur de notification, le serveur d'authentification reçoit en réponse un jeton de mise à l'épreuve ; Production (2030 - 2040), par le serveur mandataire d'authentification à la réception (2020) d'un message de mise à l'épreuve : o (2030) D'un jeton de mise à l'épreuve associé au message de mise à l'épreuve ; 24 o (2040) D'un message de notification comportant : - L'identifiant de l'utilisateur sur le serveur de notification ; - Un jeton de notification, produit par le serveur mandataire d'authentification, le jeton de notification étant associé, sur le 5 serveur mandataire d'authentification au message de mise à l'épreuve ; Emission (2050) du message de notification, par le serveur mandataire d'authentification, vers le serveur de notification ; Acheminement (2060) du message de notification par le serveur de lo notification ; Production (2080) par le calculateur, à la réception (2070) du message de notification d'un message de prise en charge de l'épreuve, le message de prise en charge de l'épreuve comportant : o L'identifiant de l'utilisateur sur le serveur mandataire d'authentification ; 15 o L'identifiant de l'utilisateur sur le serveur de notification ; o Le jeton de de notification ; Emission (2090) par le calculateur du message de prise en charge de l'épreuve vers le serveur mandataire d'authentification ; Production (2110) par le serveur mandataire d'authentification, à la réception 20 (2100) du message de prise en charge de l'épreuve, d'un message épreuve comportant : o L'aléa chiffré retrouvé grâce au contenu du message de prise en charge de l'épreuve ; Emission (2120) par le serveur mandataire d'authentification du message 25 épreuve vers le calculateur ; Production (2140) par le calculateur, à la réception (2130) du message épreuve, d'un message réponse comportant : o Le résultat du déchiffrement de l'aléa chiffré par l'utilisation de la clé privé ; 30 Emission (2150) par le calculateur du message réponse vers le serveur mandataire d'authentification ; Association (2170) par le serveur mandataire d'authentification, à la réception (2160) du message de réponse, du résultat du déchiffrement et du jeton de mise l'épreuve ; 25 Interrogation (2035) par le serveur d'authentification du serveur mandataire d'authentification pour obtenir le contenu du message de réponse associé au jeton de mise à l'épreuve ; Comparaison (2200) par le serveur d'authentification du contenu du message 5 de réponse avec l'aléa produit pour déterminer le résultat de l'authentification. 2. Procédé d'authentification selon la revendication 1, caractérisé en ce que la bi-clé, l'identifiant d'utilisateur sur le serveur mandataire, l'identifiant d'utilisateur sur le 10 serveur de notification sont produits lors d'un enrôlement du calculateur, ledit enrôlement se déroulant comme suit, l'utilisateur ayant à sa disposition le calculateur et un terminal sécurisé connecté au serveur d'authentification : L'utilisateur s'enregistre (3000), avec le calculateur, sur le serveur de notification et obtient l'identifiant utilisateur sur le serveur de notification ; 15 L'utilisateur utilise (3010) le terminal sécurisé pour s'authentifier et émettre un message de demande d'enrôlement vers le serveur d'authentification ; Production (3030), par le serveur d'authentification à la réception (3020) d'un message de demande d'enrôlement des éléments suivants : o Une bi-clé associée à l'utilisateur ; 20 o Un message de démarrage d'enrôlement émis vers le serveur mandataire d'authentification ; Mise en oeuvre, par le serveur mandataire d'authentification à la réception (3040) d'un message de démarrage d'enrôlement, des actions suivantes : o Création (3050) d'un enregistrement associant : 25 - Un identifiant d'utilisateur sur le serveur mandataire ; - Un jeton d'enrôlement ; o Production (3060) d'un message d'enrôlement démarré comportant : - L'identifiant d'utilisateur sur le serveur mandataire ; - Le jeton d'enrôlement ; 30 o Emission (3070) du message d'enrôlement démarré en réponse au message de démarrage d'enrôlement ; Mise en oeuvre, par le serveur d'authentification à la réception (3080) d'un message de démarrage d'enrôlement, des actions suivantes : 26 o Production (3090) d'un message d'acceptation d'enrôlement comportant : - Au moins la clé privée de la bi-clé ; - Le jeton d'enrôlement ; 5 o Emission (3100) du message d'acceptation d'enrôlement en réponse au message de demande d'enrôlement ; Mise en oeuvre, par le terminal sécurisé à la réception (3110) d'un message d'acceptation d'enrôlement : o Affichage (3120), sur un écran du terminal sécurisé du contenu du 10 message reçu ; Acquisition (3130), par le calculateur, de données affichées sur l'écran du terminal sécurisé ; Mise en oeuvre, par le calculateur suite à l'acquisition (3130) des données, des actions suivantes : 15 o Création (3140) d'un enregistrement associant : - Au moins la clé privée de la bi-clé - L'identifiant de l'utilisateur sur le serveur de notification o Production (3150) d'un message de finalisation d'enrôlement comportant - Le jeton d'enrôlement ; 20 - L'identifiant sur le serveur de notification ; o Emission (3160) du message de finalisation d'enrôlement vers le serveur mandataire d'authentification ; Mise en oeuvre, par le serveur mandataire suite à la réception (3170) d'un message de finalisation d'enrôlement des actions suivantes : 25 o Si (3180) un enregistrement correspond au jeton d'enrôlement du message de finalisation alors (3190) : - Association (3200) de l'identifiant sur le serveur de notification avec l'enregistrement correspondant ; - Production (3210) d'un message d'enrôlement finalisé 30 comportant : - L'identifiant sur le serveur mandataire d'authentification de l'enregistrement correspondant ; - Emission (3220) du message d'enrôlement finalisé en réponse au message de finalisation d'enregistrement ; 27 - Emission (3230) d'un message de confirmation d'enrôlement vers le serveur d'authentification ; - Effacement du jeton d'enrôlement ; Mise en oeuvre, par le calculateur à la réception (3250) d'un message 5 d'enrôlement finalisé des actions suivantes : o Association (3270) à l'enregistrement correspondant au message de finalisation d'enregistrement de l'identifiant sur le serveur mandataire. 3. Procédé d'authentification selon l'une des revendications précédentes caractérisé 10 en ce que l'accès à des zones mémoire du calculateur est verrouillé par un mécanisme de sécurité local au calculateur.