Brevet FR3041195A1 (20170317)
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\n<CLM>\1\tProcé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\n<CLM>\1\tSelon 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\n<CLM>\1\tSelon 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\n<CLM>\1\tProcé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\n<CLM>\1\tProcé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\n<CLM>\1\tProcé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\n<CLM>\1\tProcé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\n<CLM>\1\tProcé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\n<CLM>\1\tRevendication\n<CLM>\1\tProcé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\n<CLM>\1\tProcé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\n<CLM>\1\tProcé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\n<CLM>\1\tProcé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\n<CLM>\1\t10 Revendication\n<CLM>\1\tProcé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\n<CLM>\1\tProcé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.