Brevet FR3041195A1 — publié le 20170317

Description Domaine technique La présente invention se rapporte à un dispositif permettant d'accéder à un service en ligne au moyen de pseudonymes et d'attributs contenus dans des jetons de sécurité. Le procédé concerne particulièrement l'accès à un serveur via un réseau, par exemple via le réseau Internet, par une entité informatique appelée "application 10 cliente", qui peut représenter une personne physique ou une personne morale, dans le paradigme "client-serveur". Technique antérieure 15 Généralement, l'accès d'un client à un serveur est conditionné par la présentation de certains "attributs" de l'utilisateur qui, à défaut de son identité complète, révèlent certaines données personnelles de cette personne. A titre d'exemple, il y a des situations où il est souhaitable de pouvoir démontrer que l'on est majeur (plus de 18 ans), sans pour autant devoir révéler sa date de naissance, son nom 20 ou son prénom. L'accès à un serveur au moyen de la présentation d'attributs est parfois connu sous l'acronyme anglais ABC: "Attribute Based Credentials". En matière de sécurité, on a longtemps considéré qu'il n'y avait que deux sortes de personnes: les personnes utilisatrices d'un système situées à l'intérieur de ce système et les attaquants situés à l'extérieur de ce système. Si cette vision a été 25 utile et reste toujours utile, elle n'est pas suffisante. De nombreux systèmes ont été décrits dans la littérature et certains sont en cours d'expérimentation avec le concours financier de la Commission Européenne. Ces systèmes font l'hypothèse que les utilisateurs sont toujours "honnêtes". Hélas, cette hypothèse ne résiste pas dans la vie courante. 30 En effet, il faut aussi considérer des personnes utilisatrices d'un système situées "à l'intérieur de ce système" qui accepteraient de collaborer ensemble durant quelques instants afin que l'une des personnes qui serait en mesure de démontrer à un serveur une qualité qu'elle possède (par exemple qu'elle est majeure) puisse 3041195 2 transférer cette qualité à une autre personne qui ne la possède pas (par exemple parce qu'elle est mineure) afin que cette autre personne soit alors en mesure de démontrer à un serveur une qualité qu'elle ne possède pas. Quelle que soit la sophistication des algorithmes cryptographiques mis en oeuvre, 5 il est strictement impossible avec une solution ne mettant en oeuvre que du logiciel d'empêcher le transfert d'une qualité d'une personne qui la possède au profit d'une personne qui ne la possède pas. D'où la nécessité de mettre en oeuvre un composant matériel, en la circonstance un microcircuit sécurisé, aussi connu sous l'appellation "élément sécurisé" (en anglais "secure element"), tel qu'une carte à microcircuit ou un module de sécurité. Certains systèmes qui ont été décrits dans la littérature et qui sont en cours d'expérimentation permettent de mettre en oeuvre un microcircuit. Cependant la manière dont ce microcircuit sécurisé est mis en oeuvre ne permet pas d'empêcher le transfert d'une qualité (c'est à dire d'un attribut) depuis la 15 personne qui la possède vers une personne qui ne la possède pas. Parmi différentes solutions proposées, on connait le projet ABC4Trust qui fédère deux solutions: la solution "U Prove" de Microsoft et la solution "Identity Mixer" (IdeMix) d'IBM Zürich. Même avec la mise en oeuvre d'un microcircuit sécurisé, du moins telle que décrite dans la documentation accessible au public en mai 2015, 20 aucune de ces deux solutions ne permet pas d'empêcher le transfert d'une qualité depuis la personne qui la possède vers une personne qui ne la possède pas. Par ailleurs, le groupe de travail 16 (WG 16) du TC 224 du Comité Européen de Normalisation (CEN) a élaboré en avril 2015 un document de 372 pages découpé en 5 parties qui est intitulé : "Application Interface for secure elements used as 25 Qualified electronic Signature (Seal-) Creation Devices". Ce document qui décrit la mise en oeuvre de "secure elements" décrit des protocoles de sécurité - et non des interfaces applicatives comme son titre l'identique à tort - et différents services de sécurité n'ayant aucun rapport avec son titre. Le document comporte cinq parties. 30 La partie 4, intitulée : "Privacy specific Protocols" permet, après 28 échanges, de supporter un mécanisme d'authentification par pseudonymes appelé "Restricted identification", qui est décrit dans la section 3.3. Elle permet aussi de transférer des attributs, après un total de 45 échanges. 3041195 3 Ce mécanisme outre sa lourdeur et sa complexité nécessite la mise en oeuvre d'un architecture spécifique qui nécessite de déployer au niveau des serveurs des certificats vérifiables par des cartes à microcircuit (appelé CV certificates pour "Card Verifiable certificate") en sus des certificats X.509 qui servent à établir des 5 liaisons du type HTTPS. Le principe de base retenu est d'effectuer tous les échanges sensibles avec la carte à microcircuit au moyen de canaux sécurisés (secure channels) ce qui ne permet pas de modifier les échanges sans que cela ne soit détecté; mais ce qui ne permet pas à l'utilisateur de voir le contenu des échanges effectués par sa carte avec le monde extérieur. L'un des principes de 10 base du respect de la vie privée dès la conception ("privacy by design" en anglais) n'est dès lors pas respecté: l'utilisateur n'a pas la possibilité de donner son accord pour autoriser le transfert de chaque attribut: il doit faire confiance aux droits qui sont contenus dans un "CV certificate" et ne peut les modifier. Les droits sont fixes ce qui est contraire aux principes de base du respect de la vie privée dès la conception d'autant qu'ils sont définis par une autorité que l'utilisateur ne connait pas. Le contenu d'un CV certificate est très difficile à interpréter car il contient un champ spécifique appelé CHAT (Certificate Holder Authorization Template) qui contient un identifiant d'objet et une suite de bits qui est fonction de cet identifiant. La manière dont cette carte à microcircuit est mise en oeuvre permet cependant d'empêcher le transfert d'une qualité depuis la personne qui la possède vers une personne qui ne la possède pas au prix du déploiement d'une architecture très lourde et de protocoles très complexes. Des précisions complémentaires ont été apportées lors d'un exposé effectué à l'occasion de l'atelier de sécurité tenu par l'ETSI à Sophia Antipolis le 24 juin 2015 sous le titre : "elD and the principle of privacy by design". La présentation est accessible sur le site de l'ETSI à l'adresse suivante : http://docbox.etsi.org/Workshop/2015/201506_SECURITYWEEK/ eIDAS_THREAD/S03_elD/DPSECURITYCONSULTING_PINKAS.pdf Résumé de l'invention L'invention a pour but de proposer un procédé plus simple permettant de sécuriser l'accès à un serveur sans qu'aucun attribut personnel certifié ne puisse être 3041195 4 transféré depuis une personne qui le possède vers une personne qui ne le possède pas. L'invention permet le déploiement de solutions du type "Attribute Based Credentials" (ABC) qui étaient en cours d'étude au sein du comité ISO SC 27 WG 5, en septembre 2015. 5 Ainsi, dans le cadre de cette invention, on doit impérativement utiliser un microcircuit sécurisé, tel que celui que l'on peut trouver dans une "carte à microcircuit" ("smart card" en anglais). Un tel microcircuit sécurisé devra être mis en oeuvre ou bien par une personne physique, ou bien par une personne morale ou bien par une entité informatique appelée "application cliente" ("Client 10 Application" en anglais, abréviation CA), dans le paradigme "client-serveur". Cette "application cliente" peut aussi être une applet de confiance fonctionnant dans un navigateur, par exemple une applet Java. Le terme "microcircuit sécurisé" sera utilisé ci-après par commodité pour désigner tout composant physique sécurisé capable de résister à des attaques physiques 15 et logiques et à même d'exécuter un ensemble de fonctions mettant en oeuvre à la fois des données internes protégées et des données externes fournies par l'environnement du microcircuit selon des exigences précises. Ce terme recouvre aussi les composants du type TPM (Trusted Platform Module) que l'on trouve dans certains ordinateurs professionnels et UICC (Universal Integrated Circuit 20 Card) normalisé par le 3GPP (3rd Generation Mobile System) et l'ETSI (European Telecommunications Standards Institute). Le dernier terme "à la mode" en anglais est maintenant "secure element". Sa traduction française "élément sécurisé" est cependant encore peu utilisée. 25 L'invention s'appuie sur les concepts définis dans les spécifications techniques de l'Alliance FIDO (Fast Identity On line) qui sont disponibles à l'adresse suivante: https://fidoalliance.org/specifications/download Plus exactement sur les protocoles décrits dans le cadre d'authentification universel (Universal Authentication Framework - UAF). Les protocoles décrits 30 dans cette spécification permettent une authentification à l'aide de pseudonymes en utilisant un pseudonyme différent pour chaque serveur. Seulement, les protocoles décrits dans les documents de FIDO ne prévoient pas et ne permettent pas la présentation d'attributs certifiés. 3041195 5 L'invention permet d'étendre l'architecture de FIDO et les protocoles de FIDO pour permettre le transfert d'attributs certifiés vers un serveur tout en respectant le principe du respect de la vie privée dès la conception ("privacy by design" en anglais). 5 Plusieurs modes d'exécution de l'invention seront décrits ci-après, à titre d'exemples non limitatifs, en référence aux dessins annexés dans lesquels : - la Figure 1 illustre schématiquement l'architecture FIDO d'origine, - la Figure 2 illustre schématiquement l'architecture FIDO complétée 10 selon l'invention, et - la Figure 3 illustre les données essentielles contenues dans un microcircuit sécurisé selon l'invention. L'invention est un procédé permettant, à partir d'une application cliente (10), 15 d'accéder à un serveur en ligne (11) ("Service Provider" en anglais, abréviation SP) au moyen d'un microcircuit sécurisé (12), d'un pseudonyme et d'un jeton de sécurité contenant des attributs, ledit jeton ayant été obtenu auprès d'un serveur producteur de jetons (13), abréviation SPJ, caractérisé par le fait que l'application cliente (10) est dans l'impossibilité de pouvoir octroyer le bénéfice dudit jeton de 20 sécurité à une autre application cliente, et que le procédé comprend les étapes suivantes: - la mise à disposition des utilisateurs par des fabricants de microcircuits de microcircuits sécurisés aux caractéristiques particulières, - la création d'un compte sur un serveur cible au moyen d'un pseudonyme 25 et d'un tel microcircuit sécurisé, la création d'un compte sur un serveur producteur de jetons au moyen d'un pseudonyme et d'un tel microcircuit sécurisé, la demande d'un jeton de sécurité auprès d'un serveur producteur de jetons au moyen d'un pseudonyme et d'un tel microcircuit sécurisé, 30 la génération d'un jeton de sécurité par le serveur producteur de jetons, - l'acceptation du jeton de sécurité par le serveur cible. 304 1 1 9 5 6 L'invention est caractérisée par le fait que chaque microcircuit sécurisé objet du procédé est livré par son fournisseur avec : d'une part, une Information Publique (14) (abréviation IP) contenue dans le microcircuit sécurisé permettant de savoir ou de déduire que l'octroi de 5 ladite information publique a été conditionné par le respect des exigences de sécurité et de fonctionnalités applicables au microcircuit sécurisé et décrites dans le cadre de ladite invention, et d'autre part, une clé privée (15) (abréviation CP) associée qui sera utilisée impérativement pour effectuer certaines opérations précises, de manière 10 telle que les signatures numériques effectués en utilisant ladite clé privée soient vérifiables à partir de ladite information publique, et où l'Information Publique (14) contient au moins une information permettant de savoir, par le biais d'un contact à un serveur, si une donnée publique spécifique au microcircuit sécurisé est toujours valide (fonctionnement en liste blanche) ou 15 bien a été invalidée (fonctionnement en liste noire). Selon une réalisation préférée, chaque microcircuit sécurisé (12) est livré par son fournisseur avec : un certificat de clé publique, et, une clé privée associée, où la clé privée et la clé publique constituent une 20 paire unique, et où le certificat de clé publique qui constitue l'Information Publique (14) contient au moins une information permettant de savoir, par le biais d'un contact à un serveur, si une donnée publique spécifique au microcircuit sécurisé est toujours valide (fonctionnement en liste blanche) ou bien a été invalidée (fonctionnement 25 en liste noire). Selon une autre réalisation, chaque microcircuit sécurisé (12) est livré par son fournisseur avec : une Information Publique (14) contenant une donnée publique propre au microcircuit sécurisé, un identifiant du fournisseur de microcircuits, ainsi 30 qu'une clé publique commune à un ensemble de microcircuits produits par ledit fournisseur de microcircuits, et 3041195 7 une Clé Privée (15) propre au microcircuit, calculée par le ledit fournisseur de microcircuits à partir d'une clé privée unique gardée secrète par ledit fournisseur de microcircuits, et où l'Information Publique (14) contient au moins une information permettant 5 de savoir, par le biais d'un contact à un serveur, si une donnée publique spécifique au microcircuit sécurisé est toujours valide (fonctionnement en liste blanche) ou bien a été invalidée (fonctionnement en liste noire). L'invention est caractérisée en ce que le microcircuit sécurisé (12) génère à la demande de l'application cliente les données permettant de mettre en oeuvre 10 la création d'un compte sur un fournisseur de service donné ou sur un serveur producteur de jetons donné au moyen d'un pseudonyme, la demande de l'application cliente étant accompagnée au minimum du paramètre suivant: - un identifiant IdS du serveur objet de la demande, tandis qu'en retour, et si l'identifiant procuré par l'application cliente n'est pas déjà 15 présent dans le microcircuit sécurisé, ledit microcircuit : - génère un pseudonyme Ps, qui est une valeur aléatoire de taille suffisante vis à vis du nombre d'utilisateurs potentiellement authentifiables sur le serveur pour que la probabilité qu'il puisse exister une collision entre pseudonymes soit quasiment nulle, et 20 génère une bi-clé (i.e. une paire de clés, c'est à dire une clé privée et une clé publique), puis, après l'accord de l'utilisateur légitime du microcircuit sécurisé (12), fournit des donnés permettant l'authentification vis à vis du serveur cible en signant numériquement à l'aide de la clé privée générée ci-dessus au minimum les 25 données suivantes: (a) le pseudonyme généré par le microcircuit sécurisé pour ce serveur, (b) la valeur de la clé publique générée le microcircuit sécurisé pour ce serveur, et mémorise dans une entrée (16) du microcircuit sécurisé les informations 30 suivantes: - l'identifiant du serveur IdS (17), - le pseudonyme généré Ps (18) de manière aléatoire pour ce serveur, 304 1 1 9 5 8 - la clé privée Cp (19) correspondant à la bi-clé générée précédemment par le microcircuit sécurisé (12) pour ce serveur, et est aussi en mesure de mémoriser, associée à chaque entrée, de manière non restrictive, ni exhaustive d'autres informations (20) telles que : 5 - une date de création de ladite entrée (si celle-ci est fournie par l'application cliente), - une date de dernière utilisation de ladite entrée (si celle-ci est fournie par l'application cliente). 10 L'invention est caractérisée en ce que le microcircuit sécurisé (12) fournit à la demande de l'application cliente (10) les données permettant de mettre en oeuvre la création d'un compte sur un serveur producteur de jetons donné au moyen d'un pseudonyme (18), tout en apportant simultanément au serveur la preuve qu'un microcircuit sécurisé (12) conforme aux exigences décrites dans le cadre de ladite 15 invention est utilisé, la demande de l'application cliente étant accompagnée au minimum du paramètre suivant: - un identifiant du serveur producteur de jetons objet de la demande, tandis qu'en retour, et si l'identifiant procuré par l'application cliente n'est pas déjà présent dans le microcircuit sécurisé, ledit microcircuit : 20 - génère un pseudonyme (18), qui est une valeur aléatoire de taille suffisante vis à vis du nombre d'utilisateurs potentiellement authentifiables sur le serveur pour que la probabilité qu'il puisse exister une collision entre pseudonymes soit quasiment nulle, et - génère une bi-clé (i.e. une paire de clés: l'une privée et l'autre publique), 25 puis, après l'accord de l'utilisateur légitime du microcircuit sécurisé, fournit des donnés permettant l'authentification vis à vis du serveur cible en fournissant et en signant numériquement à l'aide de la clé privée (19) générée ci-dessus au minimum les données suivantes: (a) le pseudonyme (18) généré par le microcircuit sécurisé (12) pour 30 ce serveur producteur de jetons, (b) la valeur de la clé publique générée le microcircuit sécurisé pour ce serveur producteur de jetons, et en plaçant cette signature numérique dans un champ (c), 3041195 9 et de surcroit en signant numériquement à l'aide de la clé privé propre au microcircuit sécurisé (15) : - la signature numérique précédente présente dans le champ (c) ou bien les données (a) et (b), ainsi que 5 l'information publique (14) propre au microcircuit sécurisé, qui est placée dans un champ (d), et place cette seconde signature numérique dans un champ (e), et mémorise dans une entrée (16) les informations suivantes: un identifiant du serveur producteur de jetons (17), 10 - le pseudonyme (18) généré de manière aléatoire pour ce serveur producteur de jetons, - la clé privée (19) correspondant à la bi-clé générée précédemment par le microcircuit sécurisé pour ce serveur producteur de jetons, et optionnellement, un indicateur précisant que l'entrée a été créée selon 15 cette procédure n° 2 dans la mesure où l'application appelante ne désire pas mémoriser cet indicateur, et est aussi en mesure de mémoriser, associée à chaque entrée, de manière non restrictive, ni exhaustive : une date de création de ladite entrée 20 (si celle-ci est fournie par l'application cliente), une date de dernière utilisation de ladite entrée (si celle-ci est fournie par l'application cliente), étant entendu que ladite procédure n° 2 ne doit en aucun cas être utilisée par l'application cliente vis à vis d'un fournisseur de service (11). 25 L'invention est caractérisée par le fait qu'une demande de jeton de sécurité adressée au microcircuit sécurisé (12) par l'application appelante (10) à l'intention d'un serveur producteur de jetons effectuée selon la procédure n° 3 décrite ci-dessous, ne peut être générée par le microcircuit sécurisé (12) qu'à partir du 30 moment où il existe au moins déjà deux entrées (16) dans le microcircuit sécurisé, la première désignant un serveur cible, c'est à dire le serveur pour lequel le jeton est destiné, la seconde désignant un serveur producteur de jetons dont l'entrée 3041195 10 a été créée selon la procédure n° 2, et dans ce cas, l'application cliente (10) doit fournir au microcircuit sécurisé les éléments suivants: (a) un défi ou un nombre unique, afin de pouvoir détecter des cas de rejeu, 5 (b) les types d'attributs et/ou les valeurs d'attributs que l'application cliente souhaite voir incorporés dans le jeton de sécurité, (c) une période de validité des attributs (pour un jeton multi sessions) ou un champ vide ou absent (pour un jeton mono session), (d) une suite d'octets représentative du serveur cible, 10 (e) un pointeur relatif à une entrée située dans le microcircuit sécurisé désignant le désignant le serveur cible, (f) un pointeur relatif à une entrée située dans le microcircuit sécurisé désignant le serveur producteur de jetons, tandis qu'en retour, le microcircuit sécurisé, après l'accord de l'utilisateur légitime 15 du microcircuit sécurisé, produit un message formaté qui comporte : (a) le défi ou le nombre unique, (b) les attributs demandés par l'utilisateur, (c) une période de validité des attributs (pour un jeton multi sessions) ou un champ vide ou absent (pour un jeton mono session), 20 (d) la suite d'octets représentative du serveur cible, (e) le pseudonyme contenu dans l'entrée pointée par le paramètre (e) de la commande, (f) le pseudonyme contenu dans l'entrée pointée par le paramètre (f) de la commande, 25 (g) une signature numérique appliquée sur l'ensemble des données précédentes, au moyen de la clé privée relative au serveur producteur de jetons. L'invention est caractérisée par le fait qu'une demande de jeton de sécurité 30 adressée au microcircuit sécurisé (12) par l'application appelante (10) à l'intention d'un serveur producteur de jetons (13), effectuée selon la procédure n° 4 décrite ci-dessous, ne peut être générée par le microcircuit sécurisé (12) qu'à partir du moment où il existe au moins déjà deux entrées (16) dans le microcircuit sécurisé, 3041195 11 la première désignant un serveur cible, c'est à dire le serveur pour lequel le jeton est destiné, la seconde désignant un serveur producteur de jetons dont l'entrée n'a pas été créée selon la procédure n° 2, et dans ce cas, l'application cliente (10) doit fournir au microcircuit sécurisé les éléments suivants: 5 (a) un défi ou un nombre unique, afin de pouvoir détecter des cas de rejeu, (b) les types d'attributs et/ou les valeurs d'attributs que l'application cliente souhaite voir incorporés dans le jeton de sécurité, (c) une période de validité des attributs (pour un jeton multi sessions) 10 ou un champ vide ou absent (pour un jeton mono session), (d) une suite d'octets représentative du serveur cible, (e) un pointeur relatif à une entrée située dans le microcircuit sécurisé désignant le serveur cible, (f) un pointeur relatif à une entrée située dans le microcircuit sécurisé 15 désignant le serveur producteur de jetons, tandis qu'en retour, le microcircuit sécurisé (12), après l'accord de l'utilisateur légitime du microcircuit sécurisé, produit un message formaté qui comporte : (a) le défi ou le nombre unique, (b) les attributs demandés par l'utilisateur, 20 (c) une période de validité des attributs (pour un jeton multi sessions) ou un champ vide ou absent (pour un jeton mono session), (d) la suite d'octets représentative du serveur cible, (e) le pseudonyme contenu dans l'entrée pointée par le paramètre (e) de la commande, 25 (f) le pseudonyme contenu dans l'entrée pointée par le paramètre (f) de la commande, (g) une signature numérique appliquée sur l'ensemble des données précédentes, au moyen de la clé privée relative au serveur producteur de jetons, 30 (h) l'information publique propre au microcircuit sécurisé, (i) une signature numérique appliquée sur l'ensemble des données précédentes, au moyen de la clé privée propre au microcircuit sécurisé. 3041195 12 L'invention est caractérisée par le fait que le microcircuit sécurisé (12) formate chaque champ de ses réponses signées de manière non ambigüe et que les données utilisées pour réaliser ce formatage font elles-mêmes parties des 5 données signées de sorte qu'aucune opération ne peut, d'un point de vue fonctionnel, être confondue avec une autre opération et qu'en conséquence chacune d'entre elles peut être identifiée de manière non ambigüe et que les valeurs utilisées pour cette identification font partie des données signées, et que si des opérations supplémentaires devaient être mises en oeuvre par le 10 microcircuit sécurisé, en aucun cas une réponse à l'une quelconque de ces opérations supplémentaires, à partir du moment où elle est signée, ne devra pouvoir être confondue avec une autre réponse signée et tout particulièrement avec les réponses signées du microcircuit sécurisé suite à des demandes de jeton telles qu'effectuées au moyen des procédures n° 3 et n° 4. 15 L'invention est caractérisée par le fait qu'un jeton de sécurité émis par un serveur producteur de jetons (13) suite à une demande signée en provenance d'un microcircuit sécurisé (12) comporte, pour désigner le propriétaire du jeton, un champ contenant le pseudonyme d'un propriétaire déjà connu du serveur cible et que, du fait du processus menant à son incorporation dans le jeton, ce 20 pseudonyme ne peut avoir été généré que par un microcircuit sécurisé (12) au moyen d'un générateur pseudo aléatoire et qu'en conséquence sa valeur ne pourra avoir été librement choisie par quiconque. L'invention est caractérisée par le fait qu'un jeton de sécurité émis par un serveur 25 producteur de jetons (13), suite à une demande signée en provenance d'un microcircuit sécurisé (12), comporte pour désigner le serveur cible auquel le jeton est destiné, une suite d'octets qui n'est pas interprétable par le serveur producteur de jetons (13), car cette suite d'octets est d'abord localement calculée par l'application cliente (10) en utilisant une fonction de hachage et deux paramètres 30 en entrée: une valeur de salage ("salt value" en anglais) et un identifiant du serveur cible, puis communiquée au serveur producteur de jetons en tant que paramètre de la demande afin d'être incorporée dans le jeton et en conséquence lorsque l'application cliente communique au serveur cible concomitamment avec 3041195 13 le jeton, cet identifiant et cette valeur de salage, ce dernier peut, grâce à ces deux valeurs, se reconnaitre puis combiner ces deux valeurs à l'aide de la fonction de hachage pour retrouver la suite d'octets représentative présente dans le jeton de telle sorte que le serveur cible peut vérifier que le jeton de sécurité lui est 5 effectivement destiné. L'invention est caractérisée en ce que l'accord de l'utilisateur légitime du microcircuit sécurisé est obtenu: (a) soit par la présentation d'un code PIN (Personal Identification 10 Number) par le propriétaire légitime du microcircuit sécurisé qui est nécessaire pour autoriser certaines opérations liées à l'identification ou à l'authentification; ce code PIN étant appelé en la circonstance un "eID-PIN", (b) soit par la comparaison par le microcircuit sécurisé d'une donnée 15 biométrique propre à l'utilisateur légitime du microcircuit sécurisé qui est nécessaire pour autoriser certaines opérations liées à l'authentification, (c) soit par une combinatoire d'un elD-PIN et d'une donnée biométrique propre à l'utilisateur légitime du microcircuit sécurisé. 20 L'invention est caractérisée par le fait que le microcircuit sécurisé utilisé dans le cadre du procédé doit avoir les propriétés habituelles d'un "module de sécurité" ("security module" en anglais) ou d'un élément sécurisé ("secure element" en anglais) au sens des règles de l'art, et en particulier, une résistance aux attaques 25 physiques externes, une résistance aux attaques cryptographiques différentielles, l'impossibilité de pouvoir dupliquer le contenu du microcircuit sécurisé si celui-ci ne l'autorise pas, et de surcroit, doit contenir les données décrites précédemment, doit supporter la procédure n°1, doit supporter la procédure n° 3 s'il supporte la procédure n° 2, doit supporter la procédure n° 4 s'il supporte pas la procédure n° 2 30 et doit être conforme aux exigences spécifiées dans le paragraphe précédent. 3041195 14 L'invention est caractérisée en ce qu'un serveur producteur de jetons (13) n'acceptera d'émettre un jeton de sécurité suite à une demande de jeton pour un utilisateur identifié sous un pseudonyme donné que s'il est en mesure de vérifier que: 5 (1) il ne s'agit pas du rejeu d'une demande de jeton, soit en contrôlant que le défi correspond bien à celui qui a été envoyé, soit en contrôlant que le nombre unique se trouve dans la fourchette de temps autorisé et que ce nombre unique ne figure pas déjà parmi les nombres uniques mémorisés durant cette fourchette de temps, 10 (2) le pseudonyme désignant le serveur producteur de jetons dans la demande de jeton lui est connu, (3) le compte attaché à ce pseudonyme n'est ni temporairement, ni définitivement invalidé, (4) la demande de jeton est effectivement signée par la clé privée 15 associée au compte, (5) l'information publique correspondant à la clé privée du microcircuit sécurisé qui a été mise en oeuvre lors de l'ouverture du compte ou bien au plus tard lors de la demande du jeton est toujours valide ou bien n'est ni expirée, ni révoquée, 20 (6) l'information publique a bien été émise par une autorité de confiance qui ne délivre une telle information qu'après s'être assuré que le microcircuit sécurisé répond à un cahier des charges précis lui permettant de savoir que toutes les exigences de sécurité applicables au microcircuit sécurisé sont respectées. 25 L'invention est caractérisée par le fait qu'un serveur cible n'acceptera d'associer, après les vérifications d'usage, à un compte ouvert sous un pseudonyme les attributs contenus dans un jeton de sécurité, que si un compte a déjà été ouvert sur ce serveur sous le pseudonyme contenu dans le champ ad-hoc du jeton de 30 sécurité, que si ce compte n'est ni temporairement, ni définitivement invalidé, que si la date à laquelle le jeton a été émis est voisine du temps présent ou bien si une période de validité est indiquée dans le jeton, si le temps présent est inclus dans cette période de validité, que si le serveur cible se reconnait en tant que 3041195 15 destinataire du jeton et que si le jeton de sécurité a été signé par un serveur producteur de jetons connu du serveur cible pour effectuer l'ensemble des vérifications prescrites au paragraphe précédent. 5 Comme illustré à la Figure 1, l'architecture de FIDO comprend une application cliente (10) et un fournisseur de service (11). Un compte doit être systématiquement créé sur le serveur du fournisseur de service, préalablement à tout accès. Alors que FIDO autorise plusieurs variantes et n'impose en rien l'usage de 10 microcircuits, l'invention impose l'usage de microcircuits et en particulier des deux exigences suivantes : a) le pseudonyme utilisé sur un fournisseur de service (11) ne peut être que généré par un microcircuit sécurisé (12) respectant l'ensemble des critères définis dans le procédé, et 15 b) la bi-clé d'authentification associée à ce pseudonyme pour ce fournisseur de service (11) ne peut être que générée par un microcircuit sécurisé (12) respectant l'ensemble des critères définis dans le procédé. De la sorte, ni l'utilisateur, ni le fournisseur de service (11) n'ont la possibilité de choisir le pseudonyme qui va être utilisé sur un fournisseur de service (11), 20 ni d'avoir la connaissance de la clé privée associée à ce pseudonyme et à ce fournisseur de service (11), car cette dernière réside exclusivement dans le microcircuit sécurisé (12). Si l'utilisateur a l'usage de la clé privée, il n'a pas la connaissance de la valeur de la clé privée. Comme illustré à la Figure 2, dans une structure selon l'invention, l'architecture 25 initiale de FIDO est étendue en ajoutant deux composants : 1) un fournisseur d'attributs (21) ("Attribute Provider" en anglais), et 2) un fournisseur d'identité (22) ("Identity Provider" en anglais). On utilisera le terme "serveur producteur de jetons" (13) pour désigner soit un fournisseur d'identité (22), soit un fournisseur d'attributs (21). 30 Dans l'exemple illustré, il n'est représenté qu'un seul fournisseur d'identité, qu'un seul fournisseur d'attributs et qu'un seul fournisseur de service. Cependant, pour une même application cliente, il pourra y avoir plusieurs serveurs pour chaque type. 304 1 1 9 5 16 Un fournisseur d'identité (22), tout comme un fournisseur d'attributs (21), est en mesure d'émettre des jetons de sécurité ("security tokens" en anglais). Un jeton de sécurité est un train de bits ou d'octets qui est numériquement signé par un fournisseur d'identité (22) ou par un fournisseur d'attributs (21) et qui contient 5 notamment un ou plusieurs attributs relatifs à une personne (ou à une entité). On dit alors que ces attributs sont "certifiés" par le fournisseur d'identité (22) ou par le fournisseur d'attributs (21). La différence entre un fournisseur d'identité (22) et un fournisseur d'attributs (21) dépend essentiellement de la nature des attributs qui sont délivrés. 10 Un fournisseur d'identité (22) délivre principalement des attributs du type: nom, prénom, date de naissance, lieu de naissance, toutes ces informations ayant été généralement collectées et vérifiées soit à partir de documents d'identité nationaux sous forme papier, soit à partir de documents d'identité nationaux sous forme électronique. 15 Un fournisseur d'attributs (21) peut délivrer tout type d'attribut, à savoir des attributs d'identité et/ou des attributs, par exemple du type: "Membre du club de golf de Saint-Nom-la-Bretèche" ou bien "Diplômé d'un DEA de Physique de l'Université Paris VI; Option "Théorie des jeux", mais aussi des attributs du type nom, prénom, date de naissance, lieu de naissance, lieu de 20 résidence, etc.. Un fournisseur d'attributs (21) pourra, dans certains cas, exiger la présentation d'un jeton de sécurité émis par un fournisseur d'identité (22) avant d'accepter d'émettre un jeton de sécurité. La Figure 1 indique un dialogue D1 (23) entre l'application cliente (10) 25 et le fournisseur de service (11), La Figure 2 mentionne trois types de dialogues: - un dialogue D1 (23) entre l'application cliente (10) et le fournisseur de service 11, un dialogue D2 (24) entre l'application cliente (10) 30 et le fournisseur d'attributs (21), et un dialogue D3 (25) entre l'application cliente (10) et le fournisseur d'identité (22), 3041195 17 Selon les trois cas (A, B et C) décrits ci-dessous, deux ou trois dialogues sont mis en oeuvre. Cas A. L'application cliente (10) contacte directement le fournisseur d'attributs (21) au moyen du dialogue D2 (24) afin d'obtenir un jeton de sécurité, puis contacte le 5 fournisseur de service (11) au moyen du dialogue D1 (23) afin de le lui transmettre. Cas B. L'application cliente (10) contacte directement le fournisseur d'identité (22) au moyen du dialogue D3 (25) afin d'obtenir un jeton de sécurité, puis contacte le fournisseur de service (11) au moyen du dialogue D1 (23) afin de le lui 10 transmettre. Cas C. L'application cliente 10) contacte d'abord le fournisseur d'identité (22) au moyen du dialogue D3 (25) afin d'obtenir un jeton de sécurité, puis contacte le fournisseur d'attributs (21) au moyen du dialogue D2 (24) afin de le lui transmettre, reçoit en retour un autre jeton de sécurité et contacte enfin le fournisseur de 15 service (11) au moyen du dialogue D1 (23) afin de lui transmettre le second jeton de sécurité. La suite du document utilisera l'expression "serveur cible" pour désigner un serveur auquel un jeton est destiné. Un serveur cible sera habituellement un fournisseur de service (10) , mais pourra aussi être un fournisseur d'attributs (21) 20 lorsqu'un jeton de sécurité en provenance d'un fournisseur d'identité lui sera présenté. Dans l'exemple illustré, les échanges pour ces trois dialogues seront de préférence effectués en mode HTTPS (ou équivalent) afin de que le contenu des échanges ne soit pas compréhensible au monde extérieur et que toute 25 modification ou rejeu d'un échange puisse être détecté. Avant de pouvoir demander un jeton à un serveur producteur de jetons, l'application cliente (10) doit préalablement créer un compte sur ce serveur producteur de jetons à l'aide du microcircuit sécurisé (12). Avant de pouvoir présenter un jeton à un serveur cible, l'application cliente (10) 30 doit préalablement créer un compte sur le serveur cible à l'aide du microcircuit sécurisé (12). La création de ces comptes devra de préférence être effectuée au travers d'une liaison en mode HTTPS (ou équivalent) afin que l'application cliente située sur 304 1 1 9 5 18 le poste de travail de l'utilisateur puisse avoir l'assurance d'être en liaison avec le "bon serveur". L'application cliente (10) peut alors s'adresser à un serveur producteur de jetons afin d'obtenir un jeton de sécurité (13) qui va contenir un ou plusieurs attributs et 5 qui sera ensuite présenté à un serveur cible. Selon les attributs contenus dans le jeton, l'accès sera ensuite autorisé ou non par le serveur cible. L'invention impose la Règle 1 suivante aux serveurs producteurs de jetons : un serveur producteur de jetons (13) n'acceptera d'émettre un jeton de sécurité à un utilisateur que s'il est en mesure d'obtenir l'assurance que le jeton de sécurité qui 10 est demandé l'a été suite à la demande d'un utilisateur qui utilise un microcircuit sécurisé (12) qui possède des caractéristiques qui font l'objet du procédé. L'invention impose la Règle 2 suivante aux serveurs cibles : un serveur cible n'acceptera un jeton de sécurité de la part d'un serveur producteur de jetons (13) que s'il est en mesure d'obtenir l'assurance que le jeton de sécurité qui a été 15 généré par ce serveur producteur de jetons (13) ne l'a été que suite à la demande d'un utilisateur qui utilise un microcircuit sécurisé (12) qui possède toutes les caractéristiques qui font l'objet du procédé. Dans les exemples illustrés par les Figures 2 et 3, le dispositif est une carte à microcircuit ICC ("Integrated Circuit Card" en anglais). La création d'un compte 20 sur un serveur producteur de jetons (13) étant un préalable, il suffit de prouver une fois et une seule fois auprès d'un tel serveur qu'un microcircuit sécurisé qui possède toutes les caractéristiques qui font l'objet du procédé est mis en oeuvre par l'utilisateur connu du serveur producteur de jetons (13) sous un pseudonyme donné. De manière optimum, la démonstration de la mise en oeuvre d'un 25 microcircuit sécurisé possédant toutes les caractéristiques requises par le procédé sera ainsi effectuée lors de la création du compte sur le serveur producteur de jetons (13). Cependant, cela peut aussi être fait lors de la première demande de jeton de sécurité, ou encore, lors de chaque demande de jeton de sécurité (ce qui serait alors non optimum, mais techniquement possible). 30 Ainsi, aucun jeton de sécurité ne sera délivré par un serveur producteur de jetons (13), si l'utilisateur n'est pas en mesure de démontrer lors de la création du compte, ou à défaut lors de lors de la première demande de jeton ou encore à défaut lors de chaque demande de jeton qu'il utilise un dispositif physique qui 3041195 19 possède d'une part toutes les caractéristiques générales d'un microcircuit sécurisé, en particulier : résistance aux attaques physiques externes, résistance aux attaques cryptographiques différentielles, impossibilité de dupliquer le contenu d'un microcircuit si le microcircuit n'autorise pas l'accès à certains contenus; et 5 d'autre part des caractéristiques particulières complémentaires, indispensables au bon fonctionnement du procédé. Celles-ci seront détaillées ci-après. Le fait que l'utilisateur utilise un microcircuit sécurisé donné (par exemple, identifiable par un numéro de série) devra être démontré à un serveur producteur de jetons (13), mais surtout pas à un fournisseur de service (11). 10 En effet, si une telle démonstration était faite, elle pourrait révéler un identifiant spécifique au microcircuit sécurisé, ce qui pourrait permettre aux fournisseurs de service d'établir des liens entre leurs utilisateurs, ce qui est contraire à l'un des principes du respect de la vie privée. Le fournisseur de service (11) obtiendra de son côté une assurance indirecte du 15 fait que l'utilisateur qui utilise effectivement un microcircuit sécurisé qui possède toutes les caractéristiques qui font l'objet du procédé. En effet, le fournisseur de service (11) n'accordera sa confiance qu'aux serveurs producteurs de jetons (13) qui lui garantissent effectuer cette vérification. Chaque microcircuit (12) sécurisé doit comporter : 20 - une information publique (14) , permettant de vérifier les données signées avec la clé privée propre à ce microcircuit, et - une clé privée (15) qui lui est propre. Cela est illustré sur la Figure 3. L'information publique permet de savoir directement ou indirectement que son 25 octroi a été conditionné par l'assurance que le microcircuit sécurisé (12) répond aux exigences imposées au microcircuit du fait du procédé, par exemple, en émettant un certificat de clé publique sous une Politique de Certification (PC) donnée. Un microcircuit sécurisé (12) conforme aux exigences du procédé devra de 30 préférence être certifié par un organisme indépendant en fonction d'un cahier d'exigences établi sous la forme d'un Profil de Protection (PP) et avec un niveau d'assurance "élevé", par exemple "EAL4+". Le résultat de la certification pourra être remis au fabriquant du microcircuit qui pourra alors s'en prévaloir. 3041195 20 Chaque fabriquant de microcircuit produisant des microcircuits sécurisés conformes aux exigences du procédé devra s'assurer que l'Information Publique (14) contenue dans le microcircuit sécurisé (12) contient au moins une information permettant de savoir, par le biais d'un contact à un serveur, si une donnée 5 publique spécifique au microcircuit sécurisé est toujours valide ou bien a été invalidée. Lors de l'ouverture d'un compte sur un fournisseur de service (11) ou sur un serveur producteur de jetons (13), le microcircuit sécurisé (12) doit être en mesure de générer deux données et de les associer à un identifiant de serveur IdS (17), 10 comme illustré sur la Figure 3 : - un pseudonyme Ps (18), qui est une valeur aléatoire de taille suffisante pour éviter toute collision entre pseudonymes sur le serveur en question et qui doit impérativement être généré par le microcircuit, et , - une bi-clé (i.e. une paire de clés: i.e. une clé privée Cp (19) et une clé 15 publique) qui doit impérativement être générée par le microcircuit. Dès lors que l'utilisateur souhaite disposer de plus d'un compte sur le même serveur, un index peut être ajouté. Les éléments ci-dessus sont alors mis en oeuvre pour réaliser une authentification et une fois celle-ci réussie, le microcircuit mémorise de manière permanente au 20 niveau d'une "entrée" (16), au minimum, les trois informations suivantes: - un identifiant du serveur distant IdS (17), le pseudonyme Ps (18) généré de manière aléatoire pour ce serveur distant, - la clé privée Cp (19) correspondant à la bi-clé générée précédemment pour 25 ce serveur distant par le microcircuit. D'autres informations (20) peuvent être ajoutées. En particulier, afin de mieux gérer l'obsolescence et la suppression des entrées qui ne sont plus utilisées, chaque entrée pourra en outre comporter : - la date de création de l'entrée, et/ou 30 - la date de la dernière utilisation de l'entrée. Afin d'optimiser le fonctionnement, l'application cliente (10) peut demander que la clé privée (15) propre au microcircuit sécurisé (12) ainsi que l'information publique (14) permettant de vérifier les données signées avec la clé privée (15) propre à ce 304 1 1 9 5 21 microcircuit sécurisé (12) soit mise en oeuvre lors de l'authentification. Si cela est le cas, cette particularité peut être mémorisée par le microcircuit sécurisé (12) afin que l'application cliente (10) puisse en tenir compte et d'éviter de refaire cette même demande lors d'une autre authentification. 5 Naturellement, l'application cliente dispose d'une commande permettant, après l'accord de l'utilisateur, la suppression d'une ou plusieurs entrées (16). Afin d'optimiser les gestion des entrées (16), l'application cliente pourra aussi avoir un intérêt à fournir au microcircuit un indicateur complémentaire lui permettant de faire la différence entre une entrée relative à un fournisseur de service (11) et une 10 entrée relative à un serveur producteur de jetons (13). Si cela est le cas, l'indicateur sera mémorisé par le microcircuit sécurisé (12) dans l'entrée (16) en tant que donnée complémentaire (20) en question. On va maintenant examiner la structure d'un jeton de sécurité. Selon le procédé objet de l'invention, un jeton de sécurité émis par un serveur 15 producteur de jetons et destiné à un serveur cible comportera au minimum les informations suivantes : (a) le bénéficiaire du jeton, sous la forme d'un pseudonyme de l'utilisateur tel qu'il est connu du serveur cible, (b) un ou plusieurs attributs de l'utilisateur, 20 (c) un identifiant non ambigu du serveur producteur de jetons, par exemple, un certificat du type X.509, (d) pour un jeton multi sessions, une période de validité du jeton de sécurité éventuellement associée à un champ permettant de vérifier l'état de révocation de ce jeton ; ou, pour un jeton mono 25 session, le temps où le jeton a été émis, usuellement un temps UTC (Universal Coordinated Time), (e) un numéro d'identification unique du jeton attribué par le serveur producteur de jetons, (f) le serveur cible auquel le jeton est destiné, sous la forme d'une 30 suite d'octets ne permettant qu'au serveur cible de se reconnaitre, (g) une signature numérique des valeurs précédentes à l'aide de la clé privée du serveur producteur de jetons. 3041195 22 Le champ (a) permet au serveur cible de savoir au bénéfice duquel pseudonyme le jeton a été généré. Si le pseudonyme n'est pas reconnu, le jeton de sécurité doit être rejeté par le serveur cible. Le champ (b) permet au serveur cible de connaitre les attributs certifiés tels 5 qu'émis par un serveur d'identité (22) ou par un serveur d'attributs (21). Le champ (c) permet de s'assurer de l'identité du signataire du jeton de sécurité. Le champ (d) permet de délivrer des jetons de sécurité mono session ou multi sessions. Ainsi : - Pour un jeton de sécurité mono session, les attributs présents dans le jeton 10 ne seront conservés par le fournisseur de service (11) que durant une seule ouverture de session. Toute session a une durée limitée, avec un délai de fin de session ("time-out") en cas d'inactivité prolongée. - Pour un jeton de sécurité multi sessions, les attributs présents dans le jeton seront conservés par le fournisseur de service (11) durant une période de 15 validité définie dans le jeton. Si cette période de validité est considérée comme étant "assez longue" par le serveur d'identité (22) ou par le serveur d'attributs (21), ce dernier pourra mettre en oeuvre un mécanisme de révocation qui permettra de révoquer tous les attributs contenus dans le jeton. 20 Le champ (e) permet d'identifier le numéro de jeton de sécurité dans le but de le révoquer, par exemple, à l'aide d'un mécanisme du type CRL (Certificate Revocation List) ou du type OCSP (On-line Certificate Status Protocol). Le champ (e) permet aussi d'identifier de manière unique, en particulier à des fins d'audit, un jeton émis un serveur producteur de jetons. 25 Le champ (f) permet de cibler le jeton de sécurité pour un serveur cible donné, sans pour autant permettre l'identification de ce serveur par le serveur producteur de jetons. Pour ce faire, avant de demander un jeton à un serveur producteur de jetons, l'utilisateur va cacher l'identifiant du serveur cible de la manière suivante. Il combine au moyen d'un fonction de compression non inversible, parfois appelée 30 "fonction de hachage", l'identifiant du serveur cible avec une valeur aléatoire, appelée "valeur de salage" (sait value). Le résultat du calcul est placé dans le champ (f) intitulé "suite d'octets représentative du serveur cible ". 3041195 23 L'identifiant d'un serveur cible comportant une sémantique n'est donc jamais présent dans le jeton de sécurité et l'identifiant ou l'identité du serveur cible reste ainsi totalement inconnu du serveur producteur du jeton. En particulier, l'identifiant ou l'identité d'un serveur d'attributs (21) reste totalement inconnu d'un serveur 5 d'identité (22). Ceci constitue une caractéristique avantageuse du procédé. Il est cependant nécessaire que le serveur cible puisse savoir que le jeton de sécurité lui est bien destiné. Pour cela, l'application cliente communique au serveur cible la valeur de salage tandis qu'une règle fixe est définie pour transformer l'adresse du serveur cible en identifiant de serveur cible. Ainsi, le 10 serveur cible connaissant à la fois la valeur de salage et son propre identifiant est en mesure de vérifier que la valeur contenue dans le champ (f) est bien celle qu'il aura recalculée localement. Si cela n'était pas le cas, le jeton devra être refusé. Pour la création d'un compte sur un serveur producteur de jetons, l'utilisateur transmet au microcircuit: 15 - un identifiant du serveur producteur de jetons. En retour, le microcircuit produit un message formaté qui comporte : (a) le pseudonyme généré par le microcircuit pour ce serveur, (b) la valeur de la clé publique générée par le microcircuit pour ce serveur, 20 (c) une signature numérique sur les trois données précédentes, calculée au moyen de la clé privée générée par le microcircuit pour ce serveur, (d) une information publique, telle un certificat de clé publique, par exemple du type X.509, permettant de vérifier les données 25 signées avec la clé privée propre à ce microcircuit, et (e) une signature numérique sur l'ensemble des données précédentes au moyen de la clé privée propre au microcircuit. Nota 1: le champ (d) pourrait aussi faire partie des données signées par la clé 30 privée générée par le microcircuit pour ce serveur, mais pour des raisons strictement de sécurité cela n'est pas indispensable. Nota 2: une signature numérique est calculée généralement à l'aide d'une clé privée sur une valeur de hachage calculée à l'aide d'un algorithme de 3041195 24 compression non inversible (one way hash function, en anglais) complétée le cas échéant par des bits de remplissage (padding bits, en anglais). Le champ (c) permet de prouver la possession de la clé publique contenue dans le champ (b). 5 Le champ (e) permet au serveur producteur de jetons de s'assurer à l'aide du champ (d) que les données reçues proviennent bien d'un microcircuit conforme aux exigences du procédé et que c'est bien ce certificat qui appartient au microcircuit. Une fois ces vérifications effectuées, le serveur producteur de jetons crée un compte associé au pseudonyme et à la clé publique qui ont été générés 10 par le microcircuit. Nota 3: Les champs (d) et (e) peuvent être en outre considérés comme étant une protection contre des ouvertures de comptes intempestives, car seul un détenteur de microcircuit conforme aux exigences du procédé sera en mesure d'ouvrir un compte sur un serveur producteur de jetons. 15 Si la réponse du serveur producteur de jetons à la demande de création du compte est positive, alors l'utilisateur doit confirmer qu'il est d'accord pour créer une nouvelle entrée dans son microcircuit en présentant un elD-PIN. Dans le cas contraire, les données qui étaient temporairement stockées dans la mémoire du microcircuit seraient effacées. 20 Pour la création d'un compte sur un fournisseur de service (11), l'utilisateur transmet au microcircuit: - l'identifiant du fournisseur de service (11). En retour, le microcircuit produit un message formaté qui comporte : (a) le pseudonyme généré par le microcircuit pour ce serveur, 25 (b) la valeur de la clé publique générée par le microcircuit pour ce serveur, (c) une signature numérique sur les trois données précédentes générée au moyen de la clé privée associée à ce serveur. On observera que les paramètres (d) et (e) qui étaient présents auparavant pour la création d'un compte sur un serveur producteur de jetons, ne figurent pas dans 30 la liste ci-dessus. Cela est à bon escient. En effet, s'ils étaient présents, cela permettrait aux serveurs fournisseurs de service (11) d'établir des liens entre leurs comptes respectifs. 3041195 25 Si la réponse d'un fournisseur de service (11) à la demande de création du compte est positive, alors l'utilisateur devra confirmer qu'il est d'accord pour créer une nouvelle entrée dans son microcircuit, par exemple en présentant un elD-PIN. Un elD-PIN (electronic Identification - Personal Identification Number) est un PIN 5 (Personal Identification Number) spécifique aux fonctions d'identité électronique doit être mis en oeuvre. Il est connu du possesseur légitime du microcircuit et doit être présenté au microcircuit pour permettre l'exécution de certaines fonctions ou commandes du microcircuit liées à l'authentification. En effet, il peut exister un autre PIN sur un même microcircuit pour permettre l'exécution de certaines 10 fonctions ou commandes circuit liées à la signature électronique. Si l'elD-PIN a déjà été présenté, et qu'il n'est pas souhaitable pour des raisons ergonomiques de demander à l'utilisateur de fournir "n fois" son elD-PIN dans un court laps de temps, l'application cliente pourra demander la confirmation au moyen d'une interaction homme-machine et présenter l'elD-PIN au microcircuit de manière 15 transparente pour l'utilisateur. L'homme de l'art aura très certainement remarqué l'absence de l'utilisation de mécanisme permettant de détecter le rejeu ("replay" en anglais) de la demande de création de compte. En la circonstance, pour une demande de création de compte, l'usage d'un tel mécanisme n'est pas nécessaire, car un pseudonyme 20 (qu'il ait été ou non généré par un microcircuit) sera refusé si un compte a déjà été ouvert avec succès sous ce pseudonyme sur le serveur. Cependant et habituellement, dans tout échange de données du type requête/réponse entre un client et un serveur, il est nécessaire de mettre en place un mécanisme permettant de détecter le rejeu ("replay" en anglais) d'une requête 25 ou d'une réponse. Deux techniques existent pour effectuer une telle protection : l'usage de défis ("challenges" en anglais) ou l'usage de nombres uniques ("unique numbers" en anglais). L'usage des défis nécessite un minimum de quatre échanges, tandis que l'usage des nombres uniques ne nécessite que deux échanges, avec en contrepartie 30 l'usage d'horloges faiblement synchronisées vis à vis du Temps Coordonné Universel (UTC): à titre d'exemple, de l'ordre d'une dizaine de minutes. Cela est facile à obtenir avec la technologie actuelle. Des détails sont disponibles dans le standard ISO/IEC 10181-2:1996. Information technology -- Open Systems 3041195 26 Interconnection -- Security frameworks for open systems: Authentication framework. Cependant, pour des opérations qui concernent des comptes déjà ouverts un tel mécanisme de détection de rejeu est nécessaire. Les opérations qui sont décrites 5 ci-après permettent d'utiliser aussi bien de la technique des défis que de la technique des nombres uniques. Dans le premier cas, le défi reçu lors du second échange est incorporé dans les données véhiculées lors du troisième échange, tandis que dans le second cas, le nombre unique est directement incorporé dans les données véhiculées lors du premier échange. Le défi ou le nombre unique doit 10 ainsi toujours être transmis par l'application cliente au microcircuit. Pour l'authentification auprès d'un serveur à l'aide d'un pseudonyme, l'utilisateur transmet au microcircuit les éléments suivants: (a) un défi ou un nombre unique, selon la technique de rejeu choisie, (b) l'identifiant du serveur distant. 15 En retour, le microcircuit produit un message formaté qui comporte : (a) le défi ou le nombre unique, (b) le pseudonyme de l'utilisateur pour cette entrée, (c) une signature numérique appliquée sur les deux données ci-dessus en utilisant la clé privée associée à cette entrée. 20 Remarque: dans le cas de l'authentification auprès d'un producteur de jetons, la durée de vie du certificat du microcircuit peut conduire à ajouter deux éléments protocolaires complémentaires, dans la mesure où : (i) le certificat du microcircuit est renouvelable, et (ii) un tel renouvellement n'entraînerait pas une durée de validité du 25 certificat supérieure à la durée de vie du microcircuit lui-même. Les deux éléments protocolaires complémentaires sont alors les suivants: (d) le nouveau certificat, par exemple du type X.509, comportant la clé publique propre au microcircuit, et (e) une signature numérique sur l'ensemble des données précédentes au 30 moyen de la clé privée propre au microcircuit. L'utilisateur aura ensuite deux possibilités: - envoyer directement ses messages au travers du protocole HTTPS (ou à défaut HTTP), ou bien 3041195 27 permettre l'authentification de ses messages en les faisant signer par le microcircuit au moyen de la clé privée associée à ce serveur et ce, que le protocole utilisé soit le protocole HTTP ou bien le protocole HTTPS. Le choix sera à effectuer par l'utilisateur en fonction du volume des données à 5 échanger et/ou de l'importance de la sémantique de ces données. Pour l'authentification de messages auprès d'un serveur à l'aide d'un pseudonyme, l'utilisateur transmet au microcircuit les éléments suivants: (a) un défi ou un nombre unique, selon la technique de rejeu choisie, (b) l'identifiant du serveur distant, 10 (c) le contenu du message qui doit faire l'objet de l'authentification. En retour, le microcircuit produit un message formaté qui comporte : (a) le défi ou le nombre unique, (b) le pseudonyme de l'utilisateur pour cette entrée, (c) le contenu du message qui fait l'objet de l'authentification 15 (data origin authentication), (d) une signature numérique appliquée sur les trois données précédentes en utilisant la clé privée associée à cette entrée. Nota 4: Alors que le protocole HTTPS assure à la fois l'intégrité et la confidentialité des données véhiculées entre un client et un serveur, le 20 message transmis permet d'authentifier l'origine du message et du fait que ce message a bien transité par le microcircuit de l'utilisateur titulaire du pseudonyme. Pour permettre la génération du message formaté par le microcircuit, l'utilisateur devra indiquer au microcircuit qu'il est d'accord pour s'authentifier, par exemple, 25 en présentant un elD-PIN. Il est maintenant utile de décrire la manière de faire générer une demande de jeton par un microcircuit afin que la demande de génération produite par le microcircuit puisse ensuite être transmise par l'application cliente à un serveur producteur de jetons. 30 Pour la génération d'une demande jeton adressée au microcircuit sécurisé, l'utilisateur transmet au microcircuit sécurisé les éléments suivants: 3041195 28 (a) un défi ou un nombre unique, (b) les types d'attributs et/ou les types et valeurs d'attributs que l'application cliente souhaite voir incorporés dans le jeton de sécurité, 5 (c) une période de validité des attributs (pour un jeton multi sessions) ou un champ vide ou absent (pour un jeton mono session), (d) une suite d'octets représentative du serveur cible, (e) un pointeur relatif à une entrée située dans le microcircuit désignant le serveur cible, 10 (f) un pointeur relatif à une entrée située dans le microcircuit désignant le serveur producteur de jetons. Le champ (a) assure une protection contre le rejeu. Il est à noter que cette protection vient en complément de celle offerte par le protocole HTTPS, si celui-ci est mis en oeuvre. 15 Le champ (b) permet à l'application cliente A, suite à un dialogue avec l'utilisateur, de ne demander que les attributs que l'utilisateur souhaite voir incorporés dans le jeton. Il s'agit de la combinatoire de deux principes liés au respect de la vie privée ("privacy" en anglais) connus sous les noms de "minimisation des données" ("data minimization" en anglais) et "consentement de l'utilisateur" ("user consent" en 20 anglais). Le champ (c) permet de délivrer des jetons de sécurité mono session ou multi sessions. Le champ (d) est "copié et collé" dans le jeton de sécurité par le serveur producteur de jetons. 25 Le champ (e) est primordial car il permet de sélectionner le pseudonyme de l'utilisateur qui sera incorporé dans le jeton de sécurité. Il est particulièrement important de remarquer que ce pseudonyme doit déjà être présent dans le microcircuit sécurisé et qu'il a donc nécessairement été généré par le microcircuit sécurisé et qu'en conséquence cela ne pourra être aucun cas le pseudonyme 30 utilisé par une autre personne avec qui le demandeur du jeton serait de connivence. C'est cette caractéristique fondamentale qui permet d'empêcher la transmission d'un attribut appartenant à une personne (ou à une entité) au profit d'une ou plusieurs autres personnes (ou entités), même si ces personnes (ou 3041195 29 entités) sont de connivence. Le champ (f) a deux usages: (i) il permet d'indiquer le pseudonyme de l'utilisateur tel qu'il est déjà connu du serveur producteur de jetons et qui sera contenu dans la 5 demande du jeton de sécurité qui va être générée par le microcircuit, et (ii) il permet de sélectionner la clé privée associée au serveur producteur de jetons et qui sera utilisée par le microcircuit pour signer la demande de jeton. En retour, le microcircuit sécurisé produit un message formaté qui comporte : 10 (a) le défi ou le nombre unique, (b) les attributs demandés par l'utilisateur, (c) une période de validité des attributs (pour un jeton multi sessions) ou un champ vide ou absent (pour un jeton mono session), (d) la suite d'octets représentative du serveur cible, 15 (e) le pseudonyme utilisé par l'utilisateur sur le serveur cible, (f) le pseudonyme utilisé par l'utilisateur sur le serveur producteur de jeton à qui le jeton de sécurité va être demandé, (g) une signature numérique appliquée sur l'ensemble des données précédentes, au moyen de la clé privée relative au serveur 20 producteur de jetons. En vérifiant le champ (a), le serveur producteur de jetons peut s'assurer que la commande reçue n'est pas le rejeu d'une commande envoyée auparavant. En utilisant le champ (b), le serveur pourra incorporer les attributs demandés, bien évidemment dans la mesure où l'utilisateur les possède effectivement. L'utilisateur 25 a la possibilité de demander chaque attribut soit en indiquant seulement son type, soit en indiquant à la fois son type et une valeur. En utilisant le champ (c), le serveur pourra générer un jeton multi sessions ou un jeton mono session, dans la mesure où il supporte les deux types de jetons. La valeur contenue dans le champ (d) est recopiée à l'aveugle à partir du champ 30 (d) de la commande. Ce même champ sera par la suite recopiée à l'aveugle dans le champ (f) du jeton de sécurité par le serveur producteur de jetons. De la sorte, un serveur producteur de jetons ne peut pas identifier les serveurs consommateurs du jeton, par le simple examen des commandes reçues. 3041195 30 La valeur contenue dans le champ (e) est le pseudonyme qui provient de la valeur contenue dans le microcircuit sécurisé dans l'entrée pointée dans le champ (e) de la commande. Le champ (f) permettra au serveur producteur de jetons de sélectionner la clé 5 publique appropriée afin de lui permettre de vérifier la signature numérique contenue dans le champ (g). Avant l'émission d'un jeton de sécurité, le serveur producteur de jetons doit vérifier que le certificat du microcircuit sécurisé attaché au compte n'est pas révoqué. Si ce certificat a été révoqué, alors le jeton demandé ne doit pas être émis. 10 Il est essentiel que le champ (e) ci-dessus provienne effectivement du microcircuit sécurisé et non d'une donnée extérieure, sans quoi il serait possible de modifier à sa guise le bénéficiaire du jeton. Hors, il existe une fonction permettant d'assurer l'intégrité et l'authentification de données externes (non encore décrite à ce stade de l'exposé). Il faut donc s'assurer que cette dernière fonction ne pourra jamais 15 être utilisée pour mimer une demande de jeton signée. Il existe plusieurs manières d'assurer l'impossibilité de faire une telle mascarade. Par exemple, en imposant l'ordre dans lequel les différents paramètres doivent être inclus dans la réponse ainsi qu'une codage pour chaque paramètre, par exemple du type TLV (Type, Longueur, Valeur) ou en utilisant des balises du type 20 XML. L'avantage d'un codage TLV, tel que le BER (Basic Encoding Rules) ou le DER (Distinguished Encoding Rules) de l'ASN.1, est sa compacité. Une autre façon de faire, est d'insérer systématiquement en tête du message (ou en queue du message) un code différent permettant de faire la différence entre une réponse à une commande de demande de jeton de sécurité et toute 25 réponse à une autre commande, en particulier, une commande permettant d'assurer l'intégrité et l'authentification de données externes. A partir du moment où le codage des champs ou bien les données supplémentaires font partie des données qui entrent dans le calcul de la signature numérique, alors il est possible de discriminer entre les différents types de messages. 30 Si un utilisateur souhaite présenter à un serveur cible un jeton de sécurité qu'il a obtenu auprès d'un serveur producteur de jetons, deux variantes sont possibles, en particulier: 3041195 31 (a) le jeton de sécurité peut être transmis après l'authentification de l'utilisateur au moyen de son pseudonyme; la liaison entre le message et le jeton étant alors réalisée grâce à l'usage du protocole HTTPS, 5 (b) le jeton de sécurité peut faire partie du contenu d'un message faisant l'objet d'une authentification ("data origin authentication", en anglais); la liaison entre le message et le jeton étant alors réalisée qu'il y ait ou non la mise en oeuvre du protocole HTTPS. Bien sûr, l'invention n'est pas limitée aux modes de réalisation préférés qui 10 viennent d'être décrits, mais au contraire l'invention est définie par les revendications qui suivent. Il apparaîtra en effet à l'homme de l'art que diverses modifications peuvent être apportées aux modes de réalisation du procédé décrit ci-dessus, à la lumière de l'enseignement qui vient de lui être divulgué. 15 Description des modes de réalisation Le microcircuit sécurisé sera réalisé au moyen d'un unique composant électronique ou bien au moyen de plusieurs composants électroniques encapsulés 20 dans un autre composant ou encore au moyen de plusieurs composants électroniques protégés par une enceinte sécurisée, généralement appelée "enceinte cryptographique", l'une ou l'autre de ces réalisations disposant des protections telles que décrites dans l'invention, tandis que ledit "microcircuit sécurisé" s'interfacera avec son environnement extérieur, soit au moyen d'une 25 interface avec contacts, soit au moyen d'une interface sans contact. Brève description des dessins La Figure 1 illustre schématiquement l'architecture FIDO d'origine. 30 La Figure 2 illustre schématiquement l'architecture FIDO complétée selon l'invention. La Figure 3 illustre les données essentielles contenues dans un microcircuit sécurisé selon l'invention. 3041195 32 Liste des abréviations utilisées ASN.1 : Abstract Syntax Notation One. BER : Basic Encoding Rules. 5 CEN : Comité Européen de Normalisation. CHAT : Certificate Holder Authorization Template, ("Gabarit d'autorisation pour un porteur de certificat" en français). CRL : Certificate Revocation List ("Liste de Révocation de Certificats" (LRC) en français). 10 CV certificate : Card Verifiable certificate ("Certificat vérifiable par une carte" en français). DER : Distinguished Encoding Rules. EAL4 : Evaluation Assurance Level 4 ("Evaluation d'assurance de niveau 4" en français). 15 elD-PIN: electronic Identification - Personal Identification Number ("nombre d'identification personnel pour l'identification électronique" en français). ETSI : European Telecommunications Standardization Institute ("Institut Européen de Normalisation des Télécommunications" 20 en français). FIDO : Fast Identity On line. ICC: Integrated Circuit Card ("carte à microcircuit " en français). HTTP : HyperText Transfer Protocol, ("Protocole de Transfert Hypertexte" en français). 25 HTTPS : HyperText Transfer Protocol Secure, ("Protocole de Transfert Hypertexte Sécurisé" en français). OCSP: "One-line Certificate Status Protocol". PC : Politique de Certification ("Certification Policy" en anglais). PIN : Personal Identification Number 30 ("Nombre d'Identification Personnel" en français). PP : Profil de Protection ("Protection Profile" en anglais). TLV : Type, Longueur, Valeur ("Type, Length, Value" en anglais). TPM : Trusted Platform Module. 3041195 33 UAF : Universal Authentication Framework ("Cadre d'Authentification Universel" en français). UTC : Universal Coordinated Time ("Temps Coordonné Universel" en français). XML : Extensible Markup Language. 5 X.509 : Recommandation de l'ITU-T X.509 : Open Systems Interconnection The Directory : Public-key and attribute certificate frameworks. Liste des documents cités 10 Application Interface for secure elements used as Qualified electronic Signature (Seal-) Creation Devices". Documents de travail du CEN TC 224 WG 17: " Draft EN 419 212-1 à draft EN 419 212-5", uniquement disponibles aux membres du CEN TC 224 WG 17 au moment du dépôt du document. 15 ASN.1: Abstract Syntax Notation One. Recommandations ITU-T X.680 à X.683 (les documents ISO/IEC ont pour références 8824-1 à 8824-4). Les encodages BER, CER et DER sont spécifiés par la recommandation X.690. - ISO/IEC 10181-2:1996. Information technology -- Open Systems Interconnection -- Security frameworks for open systems: Authentication 20 framework. "elD and the principle of privacy by design". Présentation effectuée le 24 juin 2015, accessible à l'adresse suivante : http://docbox.etsi.org/Workshop/2015/201506_SECURITYWEEK/ eIDAS_THREAD/S03_elD/DPSECURITYCONSULTING_PINKAS.pdf 25 Spécifications techniques de l'Alliance FIDO (Fast Identity On line), accessibles à l'adresse suivante: https://fidoalliance.org/specifications/download - Universal Authentication Framework - UAF. FIDO Alliance, accessible à l'adresse suivante: 30 https://fidoalliance.org/specifications/download - Recommandation de l'ITU-T X.509. Information technology Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks. REVENDICATIONS1. Procédé permettant, à partir d'une application cliente, d'accéder à un serveur cible en ligne au moyen d'un microcircuit sécurisé, d'un pseudonyme 5 et d'un jeton de sécurité contenant des attributs, ledit jeton ayant été obtenu auprès d'un serveur producteur de jetons, qui peut être soit un fournisseur d'attributs, soit un fournisseur d'identité, caractérisé par le fait que l'application cliente est dans l'impossibilité de pouvoir octroyer le bénéfice dudit jeton à une autre application cliente, et que le procédé comprend les étapes suivantes: 10 la création d'un compte sur un serveur cible ou sur un serveur producteur de jeton au moyen d'un pseudonyme et d'une demande générés par un microcircuit sécurisé qui fournit, à la demande de l'application cliente, l'ensemble des données permettant la création du compte, la création d'un compte sur un serveur producteur de jetons au moyen 15 d'un pseudonyme et d'une demande générés par microcircuit sécurisé qui fournit, à la demande de l'application cliente, l'ensemble des données permettant la création du compte au moyen d'un pseudonyme et qui permet de démontrer qu'un microcircuit sécurisé fabriqué par un fournisseur de microcircuits selon un cahier des charges précis est 20 effectivement mis en oeuvre pour réaliser cette opération, la demande d'un jeton de sécurité auprès d'un serveur producteur de jetons étant précisé que les données essentielles pour effectuer cette demande doivent être générées par le microcircuit sécurisé, la génération d'un jeton de sécurité suite à une demande de jeton signée 25 en provenance d'un microcircuit sécurisé, comportant deux champs caractéristiques, si, et seulement si, au plus tard au moment de la demande de jeton, le serveur producteur de jetons a obtenu l'assurance que la demande de jeton provenait bien d'un microcircuit sécurisé fabriqué par un fournisseur de microcircuits selon des 30 caractéristiques précises, l'acceptation du jeton de sécurité par le serveur cible, si le serveur cible se reconnait en tant que serveur cible du jeton, si le jeton est reconnu comme étant valide, si un compte a été préalablement ouvert sur le 3041195 35 serveur cible sous le pseudonyme contenu dans le jeton de sécurité et si le jeton de sécurité a été signé par un serveur producteur de jetons connu du serveur cible pour avoir obtenu l'assurance que la demande de jeton provenait bien d'un microcircuit fabriqué par un fournisseur de microcircuits selon des caractéristiques précises. Revendication 2. Procédé selon la revendication 1 caractérisé par le fait que chaque microcircuit sécurisé est livré par son fournisseur avec : d'une part, une Information Publique contenue dans le microcircuit sécurisé permettant de savoir ou de déduire que l'octroi de ladite information publique a été conditionné par le respect des exigences de sécurité et de fonctionnalités applicables au microcircuit sécurisé et décrites dans le cadre de ladite invention, et d'autre part, une clé privée associée qui sera utilisée impérativement pour effectuer certaines opérations précises, de manière telle que les signatures numériques effectués en utilisant ladite clé privée soient vérifiables à partir de ladite information publique, et où l'Information Publique contient au moins une information permettant de savoir, par le biais d'un contact à un serveur, si une donnée publique spécifique 20 au microcircuit sécurisé est toujours valide (fonctionnement en liste blanche) ou bien a été invalidée (fonctionnement en liste noire). Revendication 3. Selon une réalisation préférée de la revendication 2 chaque microcircuit sécurisé est livré par son fournisseur avec : 25 un certificat de clé publique, et une clé privée associée, où la clé privée et la clé publique constituent une paire de clés asymétriques unique, et où le certificat de clé publique contient au moins une information permettant de savoir, par le biais d'un contact à un serveur, si une donnée publique spécifique au 30 microcircuit sécurisé est toujours valide (fonctionnement en liste blanche) ou bien a été invalidée (fonctionnement en liste noire). 3041195 36 Revendication 4. Selon une autre réalisation préférée de la revendication 2, chaque microcircuit sécurisé est livré par son fournisseur avec : une Information Publique contenant, en particulier, une donnée publique propre au microcircuit sécurisé, un identifiant du fournisseur de 5 microcircuits, ainsi qu'une clé publique commune à un ensemble de microcircuits produits par ledit fournisseur de microcircuits, et une clé privée propre au microcircuit, calculée par le ledit fournisseur de microcircuits à partir d'une clé privée unique gardée secrète par le ledit fournisseur de microcircuits, 10 et où l'Information Publique contient au moins une information permettant de savoir, par le biais d'un contact à un serveur, si une donnée publique spécifique au microcircuit sécurisé est toujours valide ou bien a été invalidée. Revendication 5. Procédé selon les revendications 1 et 2 caractérisé en ce que 15 le microcircuit sécurisé, selon la procédure n° 1 décrite ci-dessous, génère à la demande de l'application cliente les données permettant de mettre en oeuvre la création d'un compte sur un fournisseur de service donné ou sur un serveur producteur de jetons donné au moyen d'un pseudonyme, la demande de l'application cliente étant accompagnée au minimum du paramètre suivant: - un identifiant du serveur objet de la demande, tandis qu'en retour, et si l'identifiant procuré par l'application cliente n'est pas déjà présent dans le microcircuit sécurisé, ledit microcircuit : génère un pseudonyme, qui est une valeur aléatoire de taille suffisante vis à vis du nombre d'utilisateurs potentiellement authentifiables sur le serveur pour que la probabilité qu'il puisse exister une collision entre pseudonymes soit quasiment nulle, et génère une bi-clé (i.e. une paire de clés, c'est à dire une clé privée et une clé publique), puis, après l'accord de l'utilisateur légitime du microcircuit sécurisé, fournit des 30 donnés permettant l'authentification vis à vis du serveur cible en signant numériquement à l'aide de la clé privée générée ci-dessus au minimum les données suivantes: 3041195 37 (a) le pseudonyme généré par le microcircuit sécurisé pour ce serveur, (b) la valeur de la clé publique générée le microcircuit sécurisé pour ce serveur, et mémorise dans une entrée les informations suivantes: 5 - l'identifiant du serveur, - le pseudonyme généré de manière aléatoire pour ce serveur, - la clé privée correspondant à la bi-clé générée précédemment par le microcircuit sécurisé pour ce serveur, et est aussi en mesure de mémoriser, associée à chaque entrée, de manière 10 non restrictive, ni exhaustive : - une date de création de ladite entrée (si celle-ci est fournie par l'application cliente), - une date de dernière utilisation de ladite entrée (si celle-ci est fournie par l'application cliente). 15 Revendication 6. Procédé selon les revendications 1 et 2 caractérisé en ce que le microcircuit sécurisé, selon la procédure n° 2 décrite ci-dessous, fournit à la demande de l'application cliente les données permettant de mettre en oeuvre la création d'un compte sur un serveur producteur de jetons donné au moyen d'un 20 pseudonyme, tout en apportant simultanément au serveur la preuve qu'un microcircuit sécurisé conforme aux exigences décrites dans le cadre de ladite invention est utilisé, la demande de l'application cliente étant accompagnée au minimum du paramètre suivant: - un identifiant du serveur producteur de jetons objet de la demande, 25 tandis qu'en retour, et si l'identifiant procuré par l'application cliente n'est pas déjà présent dans le microcircuit sécurisé, ledit microcircuit : - génère un pseudonyme, qui est une valeur aléatoire de taille suffisante vis à vis du nombre d'utilisateurs potentiellement authentifiables sur le serveur pour que la probabilité qu'il puisse exister une collision entre pseudonymes soit quasiment nulle, et - génère une bi-clé (i.e. une paire de clés: l'une privée et l'autre publique), puis, après l'accord de l'utilisateur légitime du microcircuit sécurisé, fournit des donnés permettant l'authentification vis à vis du serveur cible en 3041195 38 fournissant et en signant numériquement à l'aide de la clé privée générée ci-dessus au minimum les données suivantes: (a) le pseudonyme généré par le microcircuit sécurisé pour ce serveur producteur de jetons, 5 (b) la valeur de la clé publique générée le microcircuit sécurisé pour ce serveur producteur de jetons, et en plaçant cette signature numérique dans un champ (c), et de surcroit en signant numériquement à l'aide de la clé privé propre au microcircuit sécurisé : 10 - la signature numérique précédente présente dans le champ (c) ou bien les données (a) et (b), ainsi que - l'information publique propre au microcircuit sécurisé, qui est placée dans un champ (d), et place cette seconde signature numérique dans un champ (e), 15 et mémorise dans une entrée les informations suivantes: - l'identifiant du serveur producteur de jetons, - le pseudonyme généré de manière aléatoire pour ce serveur producteur de jetons, - la clé privée correspondant à la bi-clé générée précédemment 20 par le microcircuit sécurisé pour ce serveur producteur de jetons, et, optionnellement, un indicateur précisant que l'entrée a été créée selon cette procédure n° 2 dans la mesure où l'application appelante ne désire pas mémoriser cet indicateur, et est aussi en mesure de mémoriser, associée à chaque entrée, de manière non restrictive, ni exhaustive : 25 - une date de création de ladite entrée (si celle-ci est fournie par l'application cliente), - une date de dernière utilisation de ladite entrée (si celle-ci est fournie par l'application cliente), étant entendu que ladite procédure n° 2 ne doit en aucun cas être utilisée par 30 l'application cliente vis à vis d'un fournisseur de service. 3041195 39 Revendication 7. Procédé selon les revendications 1, 2, 5 et 6 caractérisé par le fait qu'une demande de jeton de sécurité adressée au microcircuit sécurisé par l'application appelante à l'intention d'un serveur producteur de jetons effectuée selon la procédure n° 3 décrite ci-dessous, ne peut être générée par le microcircuit 5 sécurisé qu'à partir du moment où il existe au moins déjà deux entrées dans le microcircuit sécurisé, la première désignant un serveur cible, c'est à dire le serveur pour lequel le jeton est destiné, la seconde désignant un serveur producteur de jetons dont l'entrée a été créée selon la procédure n° 2, et dans ce cas, l'application cliente doit fournir au microcircuit sécurisé les éléments suivants: 10 (a) un défi ou un nombre unique, afin de pouvoir détecter des cas de rejeu, (b) les types d'attributs et/ou les valeurs d'attributs que l'application cliente souhaite voir incorporés dans le jeton de sécurité, (c) une période de validité des attributs (pour un jeton multi sessions) ou un champ vide ou absent (pour un jeton mono session), 15 (d) une suite d'octets représentative du serveur cible, (e) un pointeur relatif à une entrée située dans le microcircuit sécurisé désignant le désignant le serveur cible, (f) un pointeur relatif à une entrée située dans le microcircuit sécurisé désignant le serveur producteur de jetons, 20 tandis qu'en retour, le microcircuit sécurisé, après l'accord de l'utilisateur légitime du microcircuit sécurisé, produit un message formaté qui comporte : (a) le défi ou le nombre unique, (b) les attributs demandés par l'utilisateur, (c) une période de validité des attributs (pour un jeton multi sessions) 25 ou un champ vide ou absent (pour un jeton mono session), (d) la suite d'octets représentative du serveur cible, (e) le pseudonyme contenu dans l'entrée pointée par le paramètre (e) de la commande, (f) le pseudonyme contenu dans l'entrée pointée par le paramètre (f) 30 de la commande, (g) une signature numérique appliquée sur l'ensemble des données précédentes, au moyen de la clé privée relative au serveur producteur 3041195 40 de jeton. Revendication 8. Procédé selon les revendications 1, 2, 5 et 6 caractérisé par le fait qu'une demande de jeton de sécurité adressée au microcircuit sécurisé par 5 l'application appelante à l'intention d'un serveur producteur de jetons, effectuée selon la procédure n° 4 décrite ci-dessous, ne peut être générée par le microcircuit sécurisé qu'à partir du moment où il existe au moins déjà deux entrées dans le microcircuit sécurisé, la première désignant un serveur cible, c'est à dire le serveur pour lequel le jeton est destiné, la seconde désignant un serveur producteur de 10 jetons dont l'entrée n'a pas été créée selon la procédure n° 2, et dans ce cas, l'application cliente doit fournir au microcircuit sécurisé les éléments suivants: (a) un défi ou un nombre unique, afin de pouvoir détecter des cas de rejeu, (b) les types d'attributs et/ou les valeurs d'attributs que l'application cliente souhaite voir incorporés dans le jeton de sécurité, 15 (c) une période de validité des attributs (pour un jeton multi sessions) ou un champ vide ou absent (pour un jeton mono session), (d) une suite d'octets représentative du serveur cible, (e) un pointeur relatif à une entrée située dans le microcircuit sécurisé désignant le serveur cible, 20 (f) un pointeur relatif à une entrée située dans le microcircuit sécurisé désignant le serveur producteur de jetons, tandis qu'en retour, le microcircuit sécurisé, après l'accord de l'utilisateur légitime du microcircuit sécurisé, produit un message formaté qui comporte : (a) le défi ou le nombre unique, 25 (b) les attributs demandés par l'utilisateur, (c) une période de validité des attributs (pour un jeton multi sessions) ou un champ vide ou absent (pour un jeton mono session), (d) la suite d'octets représentative du serveur cible, (e) le pseudonyme contenu dans l'entrée pointée par le paramètre (e) 30 de la commande, (f) le pseudonyme contenu dans l'entrée pointée par le paramètre (f) de la commande, (g) une signature numérique appliquée sur l'ensemble des données 3041195 41 précédentes, au moyen de la clé privée relative au serveur producteur de jetons, (h) l'information publique propre au microcircuit sécurisé, (i) une signature numérique appliquée sur l'ensemble des données 5 précédentes, au moyen de la clé privée propre au microcircuit sécurisé. Revendication 9. Procédé selon les revendications 5, 6, 7 et 8 caractérisé par le fait que le microcircuit sécurisé formate chaque champ de ses réponses signées de manière non ambigüe et que les données utilisées pour réaliser ce formatage 10 font elles-mêmes parties des données signées de sorte qu'aucune opération ne peut, d'un point de vue fonctionnel, être confondue avec une autre opération et qu'en conséquence chacune d'entre elles peut être identifiée de manière non ambigüe et que les valeurs utilisées pour cette identification font partie des données signées, 15 et que si des opérations supplémentaires aux opérations décrites dans ces revendications devaient être mises en oeuvre par le microcircuit sécurisé, en aucun cas une réponse à l'une quelconque de ces opérations supplémentaires, à partir du moment où elle est signée, ne devra pouvoir être confondue avec une autre réponse signée et tout particulièrement avec les réponses signées du 20 microcircuit sécurisé suite à des demandes de jeton telles qu'effectuées au moyen des procédures n° 3 et n° 4, respectivement décrites dans les revendications 7 et 8. Revendication 10. Procédé selon les revendications 1 et 7 ou 8 caractérisé par 25 le fait qu'un jeton de sécurité émis par un serveur producteur de jetons suite à une demande signée en provenance d'un microcircuit sécurisé comporte, pour désigner le propriétaire du jeton, un champ contenant le pseudonyme d'un propriétaire déjà connu du serveur cible et que, du fait du processus menant à son incorporation dans le jeton, ce pseudonyme ne peut avoir été généré que par un 30 microcircuit sécurisé au moyen d'un générateur pseudo aléatoire et qu'en conséquence sa valeur ne pourra avoir été librement choisie par quiconque. 3041195 42 Revendication 11. Procédé selon les revendications 1 et 7 ou 8 caractérisé par le fait qu'un jeton de sécurité émis par un serveur producteur de jetons, suite à une demande signée en provenance d'un microcircuit sécurisé, comporte pour désigner le serveur cible auquel le jeton est destiné, une suite d'octets qui n'est 5 pas interprétable par le serveur producteur de jetons, car cette suite d'octets est d'abord localement calculée par l'application cliente en utilisant une fonction de hachage et deux paramètres en entrée: une valeur de salage et un identifiant du serveur cible, puis communiquée au serveur producteur de jetons en tant que paramètre de la demande afin d'être incorporée dans le jeton et en conséquence 10 lorsque l'application cliente communique au serveur cible concomitamment avec le jeton, cet identifiant et cette valeur de salage, ce dernier peut, grâce à ces deux valeurs, se reconnaitre puis combiner ces deux valeurs à l'aide de la fonction de hachage pour retrouver la suite d'octets représentative présente dans le jeton de telle sorte que le serveur cible peut vérifier que le jeton de sécurité lui est 15 effectivement destiné. Revendication 12. Procédé selon les revendications 5, 6, 7 et 8 caractérisé en ce que l'accord de l'utilisateur légitime du microcircuit sécurisé mentionné dans les revendications susvisées est obtenu: 20 (a) soit par la présentation d'un code PIN (Personal Identification Number) ou d'un code d'activation par le propriétaire légitime du microcircuit sécurisé qui est nécessaire pour autoriser certaines opérations liées à l'authentification; ce code PIN étant appelé en la circonstance un "eID-PIN", 25 (b) soit par la comparaison par le microcircuit sécurisé d'une donnée biométrique propre à l'utilisateur légitime du microcircuit sécurisé qui est nécessaire pour autoriser certaines opérations liées à l'authentification, (c) soit par une combinatoire d'un elD-PIN et d'une donnée biométrique propre à l'utilisateur légitime du microcircuit sécurisé. 30 Revendication 13. Procédé selon les revendications 1, 2, 5, 6, 7, 8 et 12 caractérisé par le fait que le microcircuit sécurisé utilisé dans le cadre du procédé doit avoir les propriétés habituelles d'un "module de sécurité" ("security module" 3041195 43 en anglais) ou d'un élément sécurisé ("secure element" en anglais) au sens des règles de l'art, et en particulier, une résistance aux attaques physiques externes, une résistance aux attaques cryptographiques différentielles, l'impossibilité de pouvoir dupliquer le contenu du microcircuit sécurisé si celui-ci ne l'autorise pas, 5 et de surcroit, doit contenir les données décrites dans la revendication 2, doit supporter la procédure n° 1, doit supporter la procédure n° 3 s'il supporte la procédure n° 2, doit supporter la procédure n° 4 s'il supporte pas la procédure n° 2 et doit être conforme aux exigences spécifiées dans la revendication 12. 10 Revendication 14. Procédé selon les revendications 1 et 7 ou 8, et 13 caractérisé en ce qu'un serveur producteur de jetons n'accepte d'émettre un jeton de sécurité suite à une demande de jeton pour un utilisateur identifié sous un pseudonyme donné que s'il est en mesure de vérifier que: (1) il ne s'agit pas du rejeu d'une demande de jeton, soit en contrôlant que 15 le défi correspond bien à celui qui a été envoyé, soit en contrôlant que le nombre unique se trouve dans la fourchette de temps autorisé et que ce nombre unique ne figure pas déjà parmi les nombres uniques mémorisés durant cette fourchette de temps, (2) le pseudonyme désignant le serveur producteur de jetons dans 20 la demande de jeton lui est connu, (3) le compte attaché à ce pseudonyme n'est ni temporairement, ni définitivement invalidé, (4) la demande de jeton est effectivement signée par la clé privée associée au compte, 25 (5) l'information publique correspondant à la clé privée du microcircuit sécurisé qui a été mise en oeuvre lors de l'ouverture du compte ou bien au plus tard lors de la demande du jeton est toujours valide ou bien n'est ni expirée, ni révoquée, (6) l'information publique a bien été émise par une autorité de confiance 30 qui ne délivre une telle information qu'après s'être assuré que le microcircuit sécurisé répond à un cahier des charges précis lui permettant de savoir que toutes les exigences de sécurité applicables au microcircuit 3041195 44 sécurisé et qui sont décrites à la revendication 13 sont respectées. Revendication 15. Procédé selon les revendications 1, 5, 10, 11 et 14 caractérisé par le fait qu'un serveur cible n'acceptera d'associer, après les vérifications 5 d'usage, à un compte ouvert sous un pseudonyme les attributs contenus dans un jeton de sécurité, que : (1) si un compte a déjà été ouvert sur ce serveur sous le pseudonyme contenu dans le champ ad-hoc du jeton de sécurité, et (2) si ce compte n'est ni temporairement, ni définitivement invalidé, et 10 (3) si la date à laquelle le jeton a été émis est voisine du temps présent ou bien si une période de validité est indiquée dans le jeton, si le temps présent est inclus dans cette période de validité, et (4) si le serveur cible se reconnait en tant que destinataire du jeton, et (5) si le jeton de sécurité a été signé par un serveur producteur de jetons 15 connu du serveur cible pour effectuer l'ensemble des vérifications prescrites à la revendication 14.