EP4792477A1 - Procédés et dispositifs permettant de contrôler l'accès d'un utilisateur à un service en certifiant et en assurant la confidentialité des attributs de cet utilisateur - Google Patents

Abstract

Un fournisseur d'identité (D-FI) génère une accréditation vérifiable anonyme (τ) portant sur des attributs d'un utilisateur (D-USR), en utilisant une clé privée (sk _i ). L'utilisateur rafraîchit cette accréditation (τ) et envoie l'accréditation rafraîchie à un fournisseur de service (D-FS) dans une présentation vérifiable (VP) en accompagnement d'attributs demandés par le fournisseur de service (D-FS). Le fournisseur de service (D-FS) signe la présentation vérifiable (VP) avec une clé privée de groupe (sk _RP ) pour obtenir une signature de groupe (σ _RP ) et demande de façon anonyme au fournisseur d'identité de valider l'accréditation (τ') de ladite présentation vérifiable (VP) et de ladite signature de groupe (σ _RP ). Le fournisseur de service (D-FS) vérifie la validité des attributs demandés et attend une preuve (Π_OK) de la validité de l'accréditation (τ') pour autoriser l'accès de l'utilisateur (D-USR) audit service.

Description

Description Procédés et dispositifs permettant de contrôler l’accès d’un utilisateur à un service en certifiant et en assurant la confidentialité des attributs de cet utilisateur Technique antérieure L’invention se situe dans le domaine de la gestion de l’identité numérique. Plus précisément, l’invention porte sur un procédé de gestion de l’identité numérique qui préserve la vie privée des utilisateurs. De nombreux fournisseurs de services, en ligne ou dans une relation en face à face avec l’utilisateur, requièrent la mise à disposition d’éléments d’identité de l’utilisateur, plus généralement de façon à délivrer leur service. Traditionnellement, dans un monde non-numérique, cet apport d’éléments d’identité est réalisé à l’aide de titres (physiques) émis par des autorités officielles (cartes d’identité, permis de conduire, etc.) et de justificatifs émis par des tiers certificateurs reconnus (facture d’électricité, facture télécom, certificat médical, etc.). Le développement des services accessibles via internet nécessite la mise en œuvre d’outils dédiés permettant la numérisation des éléments présents sur les supports précités, éventuellement de façon structurée et autorisant leur partage avec le fournisseur de services, après consentement de l’utilisateur. Les grands prescripteurs sur Internet ont jusqu’alors structuré le domaine de la gestion de l’identité numérique dans le sens de leur modèle d’affaires. Ils ont, par exemple, au travers du protocole OIDC (OpenID Connect), élaboré une offre qui centralise les éléments d’identité de l’utilisateur et, sous son contrôle, après identification / authentification et consentement de l’utilisateur, autorise, l’accès du service à tout ou partie des éléments d’identité de l’utilisateur. Un des principaux problèmes de ce type d’architecture, connue sous le nom d’Identité fédérée, réside dans le fait que le fournisseur d’identité connait, à chaque fois qu’un utilisateur consomme un des services, quand l’opération se déroule et quels sont les éléments d’identité que l’utilisateur partage avec le fournisseur de services auquel il accède. Le fournisseur d’identité est ainsi en mesure de compiler l’historique des activités d’accès et des éléments d’identité de l’utilisateur requis par les divers services qu’il a visités. Ces données lui permettent alors de bâtir un profil de consommation de services de l’utilisateur auprès des fournisseurs de services et d’en disposer à des fins souvent commerciales. L'identité auto-souveraine (SSI, Self Sovereign Identity) est une autre approche de l'identité numérique, qui donne aux utilisateurs le contrôle total de leurs éléments d’identité : ils peuvent les présenter à l’accès à un service soit pour prouver qui ils sont ou une de leurs qualités. Seuls, le fournisseur de services et l’utilisateur interagissent lors de la phase de partage d’éléments d’identité. De façon à générer la confiance entre l’utilisateur et le service, l’utilisateur présente des éléments d’identité qui ont été certifiés par un tiers (le fournisseur d’identité) en qui le fournisseur de services a confiance. Dans cette logique, l’utilisateur détient des éléments d’identité le concernant, qui ont été délivrés et certifiés par une ou des entités de confiance, maîtrise leur diffusion auprès du fournisseur de services (après consentement) et protège sa vie privée vis-à-vis du fournisseur d’identité en l’excluant de la relation qu’il a avec le fournisseur de services. L’utilisation de méthodes cryptographiques telles que les « preuves à divulgation nulle de connaissance » (Zero-Knowledge Proof ou ZKP en anglais) permettrait en outre à un utilisateur de protéger également sa vie privée vis-à-vis du fournisseur de services : grâce à ces mécanismes, il pourrait ainsi choisir de ne révéler au fournisseur de services qu’une partie de ses éléments d’identité, tout en prouvant que ces derniers sont certifiés, voire le convaincre qu’ils vérifient certaines propriétés toujours sans les révéler (par exemple prouver qu’« il est majeur » sans qu’il soit nécessaire qu’il révèle sa date de naissance). Toutefois, cet anonymat rend difficile le suivi et l’analyse de l’usage de tels titres d’identité dématérialisés : en effet les fournisseurs d’identité ignorent totalement comment les certificats qu’ils délivrent sont utilisés. La divulgation ci-après propose un mécanisme permettant notamment d’assurer un suivi des usages de titres d’identités dématérialisés qui ne présente pas les inconvénients précités. Objet et résumé de l’invention D’une façon générale, la présente divulgation concerne trois entités : (1) un fournisseur de service qui souhaite vérifier certains attributs d’un utilisateur avant de délivrer le service et avoir la certitude que ses attributs sont certifiés ; (2) un fournisseur d’identité capable de certifier les attributs d’un utilisateur et qui souhaite une visibilité sur l’usage des accréditations qu’il délivre ; (3) un utilisateur qui souhaite préserver une confidentialité sur les services auxquels ils accède. La présente divulgation propose un mécanisme notamment dans lequel le fournisseur d’identité certifie des attributs de l’utilisateur, l’utilisateur ne révèle au fournisseur de service que les attributs nécessaires pour accéder au service, le fournisseur de service peut demander au fournisseur d’identité de lui apporter la preuve de la certification de ces attributs, le fournisseur d’identité ne pouvant déterminer ni le fournisseur de service lui demandant cette preuve, ni l’utilisateur concerné. Ainsi, et selon un premier aspect, la présente divulgation concerne un procédé de gestion d’au moins une accréditation vérifiable anonyme, ce procédé pouvant être mis en œuvre par un fournisseur d’identité et comportant les étapes suivantes : - authentification d’un utilisateur ; - obtention d’au moins un attribut de l’utilisateur ; - génération d’une accréditation vérifiable anonyme portant au moins sur le dit au moins un attribut de l’utilisateur, ladite accréditation étant une signature aveugle calculée en utilisant une clé privée du fournisseur d’identité ; et - envoi de ladite accréditation audit utilisateur. Corrélativement, la présente divulgation concerne aussi un dispositif de gestion d’au moins une accréditation vérifiable anonyme, ce dispositif comportant: - un module d’authentification d’un utilisateur ; - un module d’obtention d’au moins un attribut de l’utilisateur ; - un module de génération d’une accréditation vérifiable anonyme portant au moins sur le dit au moins un attribut de l’utilisateur, ladite accréditation étant une signature aveugle calculée en utilisant une clé privée du fournisseur d’identité ; - un module d’envoi de ladite accréditation audit utilisateur. Ainsi, et d’une façon générale, le fournisseur d’identité peut générer, après avoir authentifié un utilisateur, une accréditation, autrement dit certifier ou attester que des attributs de cet utilisateur sont valides. Ces attributs peuvent être des attributs publics, par exemple régaliens (nom, prénom, date de naissance, adresse, …). Dans un mode particulier de réalisation, l’utilisateur peut aussi souhaiter que l’accréditation porte sur un attribut secret, par exemple une clé secrète de l’utilisateur. Auquel cas, l’utilisateur ne fournit pas l’attribut secret en tant que tel mais un engagement (ou mise en gage) sur cet attribut secret. Les schémas de mise en gage sont des mécanismes connus de la personne du métier de la cryptographie et seront rappelés ci- après. On rappelle que les accréditations sont des attestions personnelles permettant à un utilisateur de convaincre un tiers qu’il possède une autorisation ou une qualification particulière. Elles sont propres à un individu et générées par une entité de confiance, via l’utilisation de signatures numériques. Cependant, les mécanismes standards de signature numérique nécessitent de révéler l’intégralité des données certifiées, même pour prouver l’authenticité d’une partie seulement d’entre elles, et permettent de tracer les utilisateurs. Dans la présente divulgation, on utilise un mécanisme d’accréditation anonyme tel qu’introduit par Chaum (David Chaum: Showing Credentials Without Identification: SIgnatures Transferred Between Unconditionally Unlinkable Pseudonyms. EUROCRYPT 1985: 241-244 ). Un tel système permet à un utilisateur de prouver que ses attributs (nom, prénom, date de naissance, adresse, genre, etc.) ont été certifiés, sans révéler d’information superflue. De façon très avantageuse, il faut noter que le fournisseur d’identité génère l’accréditation en utilisant une signature aveugle calculée avec sa clé privée de sorte que seul ce fournisseur d’identité sera en mesure de vérifier sa validité. Dans un mode particulier de réalisation, la signature aveugle est un code d’authentification de message avec une structure de groupe, connu de la personne du métier sous le nom de MAC algébrique. On rappelle qu’un MAC est une primitive cryptographique qui permet d’authentifier des messages mais où une unique clé secrète sert à la fois à sa génération et à sa vérification. Cette primitive diffère donc de la signature numérique qui, elle, peut être vérifiée par tous, grâce à une clé publique. Dans un mode particulier de réalisation, la présente divulgation utilise plus précisément, le schéma d’accréditations anonymes avec vérification par clé proposé par Barki et al. dans le document Amira Barki, Solenn Brunet, Nicolas Desmoulins, Jacques Traoré: Improved Algebraic MACs and Practical Keyed-Verification Anonymous Credentials. SAC 2016: 360-38. ^{Celui-ci s’appuie sur le schéma de MACs algébriques, noté MAC} _{BBS+, introduit par les mêmes} auteurs dans le même document. Ce schéma est particulièrement avantageux dans le cadre de la présente divulgation, car l’utilisation successive d’une même accréditation ne peut être détectée, ce qui évite tout risque de traçage. Il permet aussi de certifier certains attributs sans les révéler, ce schéma de signature permettant de signer des messages mis en gage et d’autre part de prouver efficacement la connaissance d’une signature sans la révéler. La présente divulgation pourrait toutefois s’appuyer sur d’autres systèmes d’accréditations anonymes avec vérification par clé, tels que celui proposé par Melissa Chase, Sarah Meiklejohn, Greg Zaverucha: Algebraic MACs and Keyed-Verification Anonymous Credentials. CCS 2014: 1205-1216 ou sur celui introduit plus récemment par Camenisch et al (Jan Camenisch, Manu Drijvers, Petr Dzurenda, Jan Hajny: Fast Keyed- Verification Anonymous Credentials on Standard Smart Cards. SEC 2019: 286-298). Dans un mode particulier de réalisation, le procédé de gestion comporte en outre un calcul d’une preuve de la validité de l’accréditation vérifiable et l’envoi de ladite preuve à l’utilisateur. Cette preuve permet de convaincre l’utilisateur de la validité de l’accréditation. Dans un mode particulier de réalisation, la preuve est une preuve à vérificateur désigné, de sorte que seul l’utilisateur peut être convaincu de la validité de l’accréditation. Le mécanisme de preuve à divulgation nulle de connaissance est un mécanisme connu de la personne du métier de la cryptographie et est rappelé ci-après. Comme mentionné précédemment, seul le fournisseur d’identité est capable de vérifier la validité d’une accréditation. Cette demande de vérification peut notamment être effectuée à la demande d’un fournisseur de service qui souhaite vérifier que les attributs que lui présente un utilisateur sont certifiés. Ainsi, dans un mode particulier de réalisation, le procédé de gestion comporte en outre les étapes de : - réception anonyme, en provenance d’un fournisseur de service, d’une présentation vérifiable comportant une accréditation vérifiable anonyme portant sur au moins un des attributs d’un utilisateur et d’une signature de groupe de cette présentation ; - vérification de validité de ladite signature de groupe ; - vérification de la validité de l’accréditation vérifiable anonyme en utilisant ladite clé privée du fournisseur d’identité, et en cas de succès, génération d’une preuve de la validité de ladite accréditation ; - envoi de ladite preuve de la validité de l’accréditation vérifiable anonyme au fournisseur de service uniquement si ladite signature de groupe a été déterminée valide. De façon très avantageuse, grâce à l’utilisation d’une signature de groupe, le fournisseur d’identité n’est pas en mesure d’identifier le fournisseur de service à l’origine de la demande de vérification, mais juste de s’assurer que ce fournisseur de service appartient à un groupe de fournisseurs de service autorisés. Ce mécanisme permet au fournisseur d’identité de contrôler l’usage qui est fait des accréditations qu’il produit. Le mécanisme de signature de groupe est un mécanisme connu de la personne du métier de la cryptographie et est rappelé ci-après. Dans un mode particulier de réalisation, l’accréditation vérifiable anonyme comprise dans la présentation vérifiable n’est pas identique à celle générée par le fournisseur d’identité mais un rafraîchi de celle-ci. Ce rafraîchi porte sur les mêmes attributs (secrets ou publics) mais ne permet pas de faire un rapprochement avec l’accréditation générée. Ainsi, le fournisseur d’identité ne peut pas identifier l’utilisateur pour lequel le fournisseur de service demande à vérifier les attributs. Dans un mode particulier du procédé de gestion, la présentation vérifiable comporte en outre une preuve à divulgation nulle de connaissance démontrant que l’utilisateur sait révéler une mise en gage sur ledit au moins un attribut et que l’accréditation anonyme vérifiable est valide sur ledit au moins un attribut mis en gage, ledit procédé comportant : - une étape de vérification de la validité de ladite preuve ; - ladite preuve de la validité de l’accréditation vérifiable anonyme étant envoyée au fournisseur de service uniquement si ladite preuve à divulgation nulle de connaissance a été déterminée valide. Ce mode de réalisation est particulièrement avantageux car il empêche l’utilisateur de donner son accréditation à un tiers. Selon un deuxième aspect, la présente divulgation concerne également un procédé de demande d’accès, mis en œuvre par un dispositif d’un utilisateur, pour demander accès à un service fourni par un fournisseur de service, ledit procédé comportant les étapes suivantes : - authentification de l’utilisateur auprès d’un dispositif de gestion d’au moins une accréditation vérifiable anonyme; - envoi d’au moins un attribut de l’utilisateur audit dispositif de gestion ; - obtention d’une accréditation vérifiable anonyme portant sur le dit au moins un attribut de l’utilisateur, ladite accréditation étant une signature aveugle calculée en utilisant une clé privée dudit dispositif de gestion ; - calcul d’une accréditation vérifiable anonyme rafraîchie à partir de ladite accréditation ; - envoi, audit fournisseur de service, d’une présentation vérifiable comportant au moins ladite accréditation rafraîchie et des informations permettant au fournisseur de service d’obtenir au moins un attribut dudit utilisateur demandé par ledit fournisseur de service. Corrélativement la présente divulgation concerne aussi un dispositif de demande d’accès à un service fourni par un fournisseur de service, ledit dispositif comportant: - un module d’authentification d’un utilisateur auprès d’un dispositif de gestion d’au moins une accréditation vérifiable anonyme; - un module d’envoi d’au moins un attribut de l’utilisateur audit dispositif de gestion ; - un module d’obtention d’une accréditation vérifiable anonyme portant sur le dit au moins un attribut de l’utilisateur, ladite accréditation étant une signature aveugle calculée en utilisant une clé privée dudit dispositif de gestion ; - un module de calcul d’une accréditation vérifiable anonyme rafraîchie à partir de ladite accréditation ; - un module d’envoi, audit fournisseur de service, d’une présentation vérifiable comportant au moins ladite accréditation rafraîchie et des informations permettant au fournisseur de service d’obtenir au moins un attribut dudit utilisateur demandé par ledit fournisseur de service. Ainsi, une fois que l’utilisateur a obtenu une accréditation sur ses attributs, il peut générer une présentation vérifiable comportant une ou plusieurs accréditations selon les attributs demandés par le fournisseur de service. De façon très avantageuse, en utilisant dans cette présentation vérifiable un rafraîchi de la signature reçue du fournisseur de service, l’utilisateur s’assure que le fournisseur de service qui attestera de la validité de ces attributs ne sera pas en mesure de l’identifier. Dans un mode de réalisation du procédé de demande d’accès, la présentation vérifiable comporte une mise en gage sur l’ensemble des attributs de l’utilisateur, lesdites informations comportant des données d’ouverture permettant de n’ouvrir que ledit au moins un attribut demandé par ledit fournisseur de service. Selon un troisième aspect, la présente divulgation concerne un procédé de contrôle d’accès à un service par un utilisateur, ledit procédé étant mis en œuvre par un fournisseur de service et comportant les étapes suivantes : - obtention d’une présentation vérifiable comportant une accréditation vérifiable anonyme portant sur des attributs de l’utilisateur ; - obtention d’informations permettant au fournisseur de service d’obtenir au moins un desdits attributs et vérification dudit au moins un attribut ; - signature de ladite présentation vérifiable avec une clé privée de groupe pour obtenir une signature de groupe ; - envoi anonyme, à un dispositif configuré pour valider ladite accréditation, de ladite présentation vérifiable et de ladite signature de groupe ; - un résultat positif d’une vérification dudit au moins un attribut et l’obtention d’une preuve de la validité de ladite accréditation étant des conditions nécessaires pour autoriser l’accès de l’utilisateur audit service. Corrélativement, la présente divulgation concerne un dispositif de contrôle d’accès à un service par un utilisateur, ledit dispositif comportant: - un module d’obtention d’une présentation vérifiable comportant une accréditation vérifiable anonyme portant sur des attributs de l’utilisateur ; - un module d’obtention d’informations permettant au fournisseur de service d’obtenir au moins un desdits attributs ; - un module de vérification dudit au moins un attribut ; - un module de signature de ladite présentation vérifiable avec une clé privée de groupe pour obtenir une signature de groupe ; - un module d’envoi, de manière anonyme, à un dispositif configuré pour valider ladite accréditation, de ladite présentation vérifiable et de ladite signature de groupe ; - un module configuré pour autoriser l’accès de l’utilisateur audit service au moins si une vérification dudit au moins un attribut est positive et si une preuve de la validité de ladite accréditation est obtenue. Dans un mode de réalisation du procédé de contrôle d’accès, la présentation vérifiable comporte en outre une preuve à divulgation nulle de connaissance démontrant que l’utilisateur sait révéler une mise en gage sur lesdits attributs et que l’accréditation anonyme vérifiable est valide sur l’ensemble des attributs mis en gage, ledit procédé comportant : - une étape de vérification de la validité de ladite preuve ; - un résultat positif de ladite vérification étant une condition nécessaire pour autoriser l’accès de l’utilisateur audit service. La présente divulgation propose ainsi une nouvelle architecture hybride pour l’identité numérique entre celles de l’identité fédérée et celle de l’identité décentralisée introduites en préambule : tout comme pour l’identité décentralisée, l’utilisateur conservera la maitrise totale de ses éléments d’identité, en revanche, et à l’instar de l’identité fédérée, le fournisseur de service devra déléguer la vérification de la validité d’une présentation vérifiable aux fournisseurs d’identité ayant émis le ou les accréditations anonymes utilisées dans cette présentation puisque seul le fournisseur d’identité ayant émis une accréditation sera en mesure de vérifier les présentations vérifiables s’appuyant sur cette accréditation. En revanche les présentations vérifiables sont complètement anonymes pour les fournisseurs d’identité, si bien qu’ils ne seront pas en mesure d’établir les profils de consommation de services des utilisateurs. Par ailleurs, les requêtes de vérification de présentation vérifiables sont signées anonymement par les fournisseurs de service. Les fournisseurs d’identité ne peuvent identifier ni les fournisseurs de service à l’origine de ces requêtes de vérification ni l’utilisateur à l’origine des présentations vérifiables. L’invention vise aussi un programme d’ordinateur comportant des instructions pour exécuter les étapes du procédé de gestion d’au moins une accréditation vérifiable anonyme lorsque ledit programme est exécuté par un ordinateur. L’invention vise aussi un programme d’ordinateur comportant des instructions pour exécuter les étapes du procédé de demande d’accès à un service lorsque ledit programme est exécuté par un ordinateur. L’invention vise aussi un programme d’ordinateur comportant des instructions pour exécuter les étapes du procédé de contrôle d’accès à un service lorsque ledit programme est exécuté par un ordinateur. Ces programmes peuvent utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. L'invention vise aussi un support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, une mémoire non volatile de type flash ou encore un moyen d'enregistrement magnétique, par exemple un disque dur. D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. Brève description des dessins : D’autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent des exemples de réalisation dépourvus de tout caractère limitatif. Sur les figures : La figure 1 représente un système comportant un dispositif de gestion d’au moins une accréditation vérifiable anonyme, un dispositif de demande d’accès à un service et un dispositif de contrôle d’accès à un service conformes à des modes de réalisation particuliers de la présente divulgation ; La figure 2 représente sous forme d’ordinogrammes des étapes d’un procédé de gestion d’au moins une accréditation vérifiable anonyme et d’un procédé de demande d’accès à un service conformes à des modes de réalisation particuliers de la présente divulgation ; La figure 3 représente sous forme d’ordinogrammes des étapes d’un procédé de gestion d’au moins une accréditation vérifiable anonyme, d’un procédé de demande d’accès à un service et d’un procédé de contrôle d’accès à un service conformes à des modes de réalisation particuliers de la présente divulgation ; La figure 4 représente l’architecture matérielle des dispositifs de la figure 1 dans un mode de réalisation particulier de la présente divulgation. De façon préliminaire, nous rappelons des outils cryptographiques utilisés dans la présente divulgation. Les schémas de mise en gage La mise en gage d’une valeur est un procédé cryptographique permettant à un émetteur de s’engager sur une valeur auprès d’un destinataire sans la dévoiler de prime abord et de telle sorte que cet engagement ne soit plus modifiable a posteriori. Cette valeur peut être, si nécessaire, dévoilée par la suite par l'émetteur. Ainsi, le destinataire a l’assurance qu’une fois l’engagement publié, l'émetteur ne peut plus changer d’avis sur la valeur contenue dans cet engagement. Dans la présente divulgation, on utilise par exemple un schéma de mise en gage basé sur une fonction de hachage H. On rappelle qu'une telle fonction est résistante aux collisions : en d'autres termes, il doit être difficile en pratique de trouver deux messages m et m′ tels ^{que H(m) = H(m′). Une telle fonction doit être également difficile à inverser : un condensé} _{C étant donné, il doit être difficile en pratique de trouver un message m tel que C = H(m).} Pour s'engager auprès du destinataire sur une valeur a priori secrète x, l’émetteur choisit un aléa r et calcule l'engagement C = H(x||r) qu'il envoie au destinataire. Ce faisant, l’émetteur ne peut plus modifier x car, dans le cas contraire, cela voudrait dire qu’il aurait pu trouver une autre valeur ^^^^′ ≠ ^^^^ (ainsi qu'un autre aléa r′) telle que C = H(x′||r′), ce qui contredirait l'hypothèse selon laquelle la fonction H est résistante aux collisions. A^{u besoin, l’émetteur peut révéler la paire (x, r) pour permettre à un tiers de vérifier que} _{C = H(x|| r).} Dans un mode particulier de réalisation, la présente divulgation peut utiliser le schéma de mise en gage proposé par Pedersen en 1992 (Torben P. Pedersen. Non-interactive and information-theoretic secure verifiable secret sharing. In Joan Feigenbaum, editor, CRYPTO’91, volume 576 of LNCS, pages 129–140. Springer, Heidelberg, August 1992), qui a la particularité de produire des engagements parfaitement non distinguables (perfectly hiding en anglais). Preuves à divulgation nulle de connaissance On rappelle qu’une preuve de connaissance dite à divulgation nulle de connaissance (Zero-Knowledge Proof ou ZKP en anglais), permet à un vérifieur de se convaincre qu’un certain prouveur connaît bien un secret S satisfaisant un prédicat P donné, la preuve ne révélant au vérifieur aucune information sur le secret S en question hormis le fait que celui- ci vérifie bien le prédicat P donné. Par la suite, pour représenter les preuves à divulgation ^{nulle de connaissance, nous utiliserons parfois la notation usuelle} _{PoK{α,β, … : prédicat sur α,β, … }.} Dans certains modes de réalisation, la présente invention utilise en outre le mécanisme de preuve à vérificateur désigné notamment décrit dans (Markus Jakobsson, Kazue Sako, Russell Impagliazzo: Designated Verifier Proofs and Their Applications. EUROCRYPT 1996: 143-154). Signatures de groupes et signatures anonymes Dans cette divulgation, les fournisseurs de service signent toutes leurs requêtes à destination des fournisseurs d’identité, sans dévoiler leur identité. A cet effet, la présente divulgation propose par exemple d’utiliser un schéma de signatures anonymes (variante d’un schéma de signature de groupe), de tels schémas permettant à un demandeur de prouver son appartenance à un groupe (ici à un groupe de fournisseurs de service) sans révéler son identité exacte. En particulier, les signatures de groupe ont la particularité d'être anonymes (on ne peut identifier le signataire) et non traçables (on ne peut pas déterminer si deux signatures ont été émises par la même personne ou par deux personnes distinctes). La validité d'une signature de groupe peut être vérifiée par quiconque grâce à une clé publique caractérisant le groupe (appelée "clé publique de groupe"). Pour faire partie du groupe, un demandeur doit s'enregistrer auprès d'un gestionnaire de groupe. Lors de cette phase d'enregistrement, le futur membre obtient, de manière aveugle, une clé privée de groupe qui va lui permettre de signer des messages au nom du groupe. « De manière aveugle » signifie dans ce contexte que le gestionnaire de groupe ne connaît pas la clé privée obtenue par le demandeur. De façon connue, seule une autorité de confiance (qu’on appelle autorité de révocation ou simplement RA) a le pouvoir de révoquer l'anonymat d'une signature de groupe, grâce à une trappe (une clé privée) qu'elle seule possède. En pratique, cette trappe est partagée entre plusieurs autorités de confiance (appelées généralement autorités de révocation) et il est nécessaire qu'elles coopèrent toutes pour lever l'anonymat d'une signature. Le membre du groupe se voit ainsi protéger contre des levées d'anonymat abusives. Dans un tel schéma, le gestionnaire de groupe ( ^^^^ ^^^^) dispose d’une paire de clés, privée et publique (notée ( ^^^^ ^^^^ _{^^^^ ^^^^} , ^^^^ ^^^^ _{^^^^ ^^^^})) et d’un algorithme de signature numérique. Lors de la phase d’enregistrement, le membre du groupe (noté ^^^^) reçoit du gestionnaire de groupe ^^^^ ^^^^ une signature ^^^^ sur une clé publique PK généré pour l’occasion (dont lui seul connait la clé privée associée SK : ^^^^ = ^^^^ ^^^^ ^^^^ ^^^^ _{^^^^ ^^^^ ^^^^ ^^^^}( ^^^^ ^^^^) . La clé publique de groupe est ^^^^ ^^^^ _{^^^^ ^^^^} . tandis que la clé privée de l’utilisateur est SK et son certificat de membre est ( ^^^^ ^^^^, ^^^^). Pour prouver à un fournisseur de services ou à tout autre tiers qu’il fait bien partie du groupe géré par ^^^^ ^^^^ , l’utilisateur ^^^^ chiffre sa clé publique PK en utilisant la clé publique ^^^^ ^^^^ _{^^^^ ^^^^} de l’autorité de révocation RA ( ^^^^₁ = ^^^^ _{^^^^ ^^^^ ^^^^ ^^^^}( ^^^^ ^^^^) ), puis chiffre ^^^^ ( ^^^^₂ = ^^^^ _{^^^^ ^^^^ ^^^^ ^^^^}( ^^^^) ) toujours avec la clé publique ^^^^ ^^^^ _{^^^^ ^^^^}. L’utilisateur génère une preuve ^^^^ à divulgation nulle de connaissance démontrant qu’il connait d’une part le texte clair de ^^^^₁ (c’est-à-dire ^^^^ ^^^^) mais également la clé privée correspondant à ce texte clair (c’est-à-dire ^^^^ ^^^^) et d’autre part que le texte clair de ^^^^₂ (c’est-à-dire ^^^^) est bien une signature de ^^^^ ^^^^ sur le texte clair de ^^^^₁ (c’est- à-dire PK). La signature de groupe est constituée de ( ^^^^₁, ^^^^₂, ^^^^). Dans un mode particulier de réalisation, l’algorithme de signature de groupe de Delerablée-Pointcheval peut être utilisé (Cécile Delerablée, David Pointcheval : Dynamic Fully Anonymous Short Group Signatures. VIETCRYPT 2006: 193-210). Pour cet algorithme, l’autorité de révocation dispose d’une paire de clés de l’algorithme de chiffrement d’El-Gamal (El Gamal, T.: A public key cryptosystem and a signature scheme based on discrete logarithms. In: Blakely, G.R., Chaum, D. (eds.) CRYPTO 1984. LNCS, vol. 196, pp. 10–18. Springer, Heidelberg (1985)). Tout autre schéma de signature de groupe peut toutefois être mis en œuvre dans cette divulgation. Description de modes de réalisation Nous allons maintenant décrire un exemple de mise en œuvre de la présente divulgation dans lequel un fournisseur d’identité (D-FI) génère une accréditation vérifiable anonyme ⁽ ^^^^⁾ portant sur des attributs ( ^^^^₀, ^^^^₁, … , ^^^^ _^^^^) d’un utilisateur (D-USR), en utilisant sa clé privée ( ^^^^ ^^^^ _^^^^). Dans cet exemple, l’utilisateur rafraîchit cette accréditation ( ^^^^) et envoie l’accréditation rafraichie à un fournisseur de service (D-FS) dans une présentation vérifiable (VP) en accompagnement d’attributs demandés par le fournisseur de service (D-FS). Dans cet exemple, le fournisseur de service (D-FS) signe la présentation vérifiable (VP) avec une clé privée de groupe ( ^^^^ ^^^^ _{^^^^ ^^^^}) pour obtenir une signature de groupe ( ^^^^ _{^^^^ ^^^^}) et demande de façon anonyme au fournisseur d’identité de valider l’accréditation ( ^^^^′) de ladite présentation vérifiable (VP) et de ladite signature de groupe ( ^^^^ _{^^^^ ^^^^}). Dans cet exemple le fournisseur de service (D-FS) vérifie la validité des attributs demandés et attend une preuve (Π _{^^^^ ^^^^}) de la validité de l’accréditation ( ^^^^′) pour autoriser l’accès de l’utilisateur (D-USR) audit service. Plus particulièrement : La figure 1 représente un système SYS comportant un dispositif D-FI de gestion d’accréditation anonyme mis en œuvre par un fournisseur d’identité FI, un dispositif D-FS de contrôle d’accès à un service mis en œuvre par un fournisseur de service FS et un dispositif D-USR mis en œuvre par un utilisateur USR pour demander l’accès audit service. Pour simplifier la description, le dispositif D-FI de gestion d’accréditation anonyme sera parfois appelé « dispositif D-FI du fournisseur d’identité FI ». De même, le dispositif D-FS de contrôle d’accès à un service sera parfois appelé « dispositif D-FS de fourniture de service ». De même, le dispositif D-USR de demande d’accès à un service sera parfois appelé « dispositif utilisateur D-USR ». De même, au lieu de dire « dispositif D-X » on pourra dire simplement « X ». Autrement dit, le fournisseur de service FS peut désigner le dispositif de D-FS, le fournisseur d’identité FI peut désigner le dispositif D-FI de gestion d’accréditation anonyme et l’utilisateur USR peut désigner le dispositif D-USR de demande d’accès à un service. Le dispositif D-FI de gestion d’accréditation anonyme possède une paire de clés publique et privée ( ^^^^ ^^^^ _^^^^ , ^^^^ ^^^^ _^^^^). Dans le mode de réalisation décrit ici, le fournisseur de service FS fait partie d’un groupe de fournisseurs de services, chaque membre du groupe possédant une clé privée d’un schéma de signature de groupe. Nous désignerons par ^^^^ ^^^^ _{^^^^ ^^^^} la clé privée du fournisseur de service FS et par ^^^^ ^^^^ _{^^^^ ^^^^} la clé publique du groupe de fournisseurs de services. L^{e dispositif de l’utilisateur D-USR possède une paire de clés publique et privée} _{( ^^^^ ^^^^ ^^^^, ^^^^ ^^^^ ^^^^) pour permettre son authentification auprès du fournisseur d’identité FI. Dans le} mode de réalisation décrit ici, ces clés ( ^^^^ ^^^^ _^^^^, ^^^^ ^^^^ _^^^^) sont stockées dans un élément sécurisé SE. Le dispositif D-FI de gestion d’accréditation anonyme est configuré pour, après avoir authentifié un utilisateur USR, émettre une accréditation vérifiable anonyme ^^^^ portant sur au moins un des attributs ^^^^ _^^^^ de cet utilisateur, par exemple des attributs secrets et/ou attributs publics, par exemple des éléments d’identité de cet utilisateur. Pour simplifier la description, l’« accréditation vérifiable anonyme ^^^^ » sera parfois simplement appelée « accréditation ^^^^ ». Conformément à cette divulgation, pour émettre une accréditation ^^^^, le fournisseur d’identité FI utilise une signature cryptographique calculée à partir de sa clé privée ^^^^ ^^^^ _^^^^ (clé secrète). Ainsi, seule la clé privée ^^^^ ^^^^ _^^^^ du fournisseur d’identité FI peut permettre de confirmer la validité de l’accréditation ^^^^ ou de tout autre élément impliquant cette accréditation ^^^^. En effet, conformément à cette divulgation, le fournisseur d’identité FI est le seul à pouvoir garantir à un tiers la validité d’un élément dont il a effectivement vérifié la validité, en produisant une preuve à divulgation nulle de connaissance Π _{^^^^ ^^^^} de la validité de cet élément. On notera en particulier que la clé publique ^^^^ ^^^^ _^^^^ du fournisseur d’identité FI ne permet pas de vérifier la validité d’une accréditation ^^^^ produite pas le fournisseur d’identité FI. Dans le mode particulier de réalisation décrit ici, la signature à clé secrète utilisée par le fournisseur d’identité FI pour émettre une accréditation anonyme vérifiable ^^^^ est un code d’authentification de message avec une structure de groupe, connu de l’homme du métier sous le nom de schéma de MAC algébrique. La paire de clés ( ^^^^ ^^^^ _^^^^ , ^^^^ ^^^^ _^^^^) du fournisseur d’identité FI est donc conforme à un tel schéma. Dans un mode particulier de réalisation, on utilise l’algorithme de signature MAC_BBS+ déjà présenté. Dans le mode de réalisation décrit ici, le dispositif D-USR de l’utilisateur comporte un module M-AUTH d’authentification de l’utilisateur auprès du dispositif D-FI de gestion d’au moins une accréditation vérifiable anonyme. Dans le mode de réalisation décrit, le dispositif D-USR de l’utilisateur USR comporte un module cryptographique WAL, par exemple un portefeuille d’identité électronique configuré pour stocker au moins une accréditation vérifiable anonyme ^^^^ délivrée par un fournisseur d’identité FI et pour générer une présentation vérifiable VP à présenter au fournisseur de service FS pour accéder à un service tout en protégeant la confidentialité de ses attributs. La présentation vérifiable VP comporte une accréditation ^^^^′ calculée par l’utilisateur en rafraîchissant l’accréditation ^^^^. Dans certains modes de réalisation, une présentation vérifiable VP comporte plusieurs accréditations ^^^^′, chacune calculée en rafraîchissant une accréditation ^^^^. On supposera par la suite que la présentation vérifiable VP ne comporte qu’une seule accréditation ^^^^′. La clé publique ^^^^ ^^^^ _^^^^ du fournisseur d’identité FI peut être utilisée par le fournisseur de service FS pour identifier le fournisseur d’identité FI capable d’apporter la preuve de la validité de cette accréditation. Lorsque le fournisseur de service FS sollicite le fournisseur d’identité FI pour qu’il valide une accréditation, il le fait de façon anonyme en signant la présentation vérifiable VP au moyen d’une signature de groupe. Au moins certains des attributs de l’utilisateur peuvent être demandés par le fournisseur de service FS pour autoriser l’utilisateur USR à accéder à un service. Ceux-ci ne sont jamais dévoilés au fournisseur d’identité. Dans le mode de réalisation décrit ici, le porte-monnaie électronique WAL du dispositif utilisateur D-USR est configuré pour rafraîchir une accréditation et générer la présentation vérifiable VP avec cette accréditation rafraîchie. Dans le mode de réalisation décrit ici, le dispositif D-USR comporte un module de communication COM3. Ce module peut être utilisé pour envoyer des attributs ^^^^₁, … , ^^^^ _^^^^ de l’utilisateur au dispositif D-FI, recevoir une accréditation vérifiable anonyme ^^^^ portant sur ces attributs, envoyer à un fournisseur de service : -la présentation vérifiable VP générée par le module WAL ; et - des informations permettant au fournisseur de service d’obtenir au moins un attribut de l’utilisateur requis pour accéder au service. Dans le mode de réalisation décrit ici, le dispositif D-FI de gestion d’au moins une accréditation vérifiable anonyme comporte un module de communication COM1. Ce module peut notamment être utilisé par le dispositif D-FI pour obtenir les attributs ^^^^₀, ^^^^₁ … , ^^^^ _^^^^ de l’utilisateur, lui envoyer une accréditation ^^^^, envoyer des preuves, recevoir une présentation vérifiable. Dans le mode de réalisation décrit ici, le dispositif D-FI de gestion d’au moins une accréditation vérifiable anonyme comporte un module cryptographique M-CRY1. Ce module peut notamment être utilisé pour authentifier un utilisateur, générer et vérifier la validité d’une accréditation vérifiable anonyme ^^^^ portant sur des attributs et sous la forme d’une signature aveugle en utilisant la clé privée ^^^^ ^^^^ _^^^^, calculer des preuves, vérifier des signatures, notamment des signatures de groupe. Dans le mode de réalisation décrit ici, le dispositif D-FS de contrôle d’accès à un service par un utilisateur comporte un module M-LS pour déterminer quels attributs d’un utilisateur doivent être vérifiés avant de l’autoriser à accéder à un service, vérifier si des attributs obtenus satisfont effectivement la logique du service et le cas échéant pour autoriser l’accès au service après avoir vérifié au moins une preuve de la validité d’une accréditation de la certification de ces attributs. Dans le mode de réalisation décrit ici, le dispositif D-FS comporte un module de communication COM2. Ce module peut notamment être utilisé par le dispositif pour demander des attributs à l’utilisateur, obtenir ces attributs ou des informations lui permettant d’obtenir ces attributs, obtenir une présentation vérifiable comportant une accréditation vérifiable anonyme portant sur des attributs d’un utilisateur, envoyer cette accréditation et une signature de la présentation à un fournisseur d’identité, obtenir une preuve de la validité ou de la non-validité de cette accréditation. Dans le mode de réalisation décrit ici, le dispositif D-FS comporte un module cryptographique M-CRY2 configuré notamment pour signer ladite présentation vérifiable avec une clé privée de groupe pour obtenir une signature de groupe et pour vérifier la validité d’une preuve. Les figures 2 et 3 représentent sous forme d’ordinogramme les principales étapes d’un procédé de gestion d’au moins une accréditation vérifiable anonyme mis en œuvre par le fournisseur d’identité FI, les principales étapes d’un procédé de demande d’accès à un service mis en œuvre par l’utilisateur USR et les principales étapes d’un procédé de contrôle d’accès mis en œuvre par le fournisseur de service FS. Dans cet exemple, l’utilisateur USR utilise son dispositif D-USR pour demander au dispositif D-FI d’un fournisseur d’identité FI de lui fournir une accréditation vérifiable ^^^^ portant sur un attribut secret ^^^^₀ et sur ^^^^ attributs publics ^^^^₁, … , ^^^^ _^^^^. Ces attributs publics peuvent être des attributs régaliens (nom, prénom, date de naissance, …) ou non. Au cours d’une étape U2, le dispositif de l’utilisateur D-USR génère une valeur aléatoire ^^^^₀. Cette valeur ^^^^₀ est destinée à rester secrète ; elle peut être utilisée par l’utilisateur USR pour prouver que l’accréditation vérifiable ^^^^ qu’il recevra du fournisseur d’identité FI est effectivement sa propriété. Au cours d’une étape U4, l’utilisateur USR utilise sa paire de clés ( ^^^^ ^^^^ _^^^^, ^^^^ ^^^^ _^^^^) pour s’authentifier auprès du fournisseur d’identité FI. Dans le mode de réalisation décrit ici, si le fournisseur d’identité FI n’authentifie pas l’utilisateur USR, le résultat d’un test I4 est négatif et le procédé s’arrête. Si l’authentification réussit, au cours d’une étape U5, le dispositif D-USR de l’utilisateur USR calcule une mise en gage (ou engagement) ^^^^ ^^^^ ^^^^ sur la valeur secrète a₀. Cet engagement ^^^^ ^^^^ ^^^^ constitue un attribut secret, car l’utilisateur ne souhaite pas révéler ^^^^₀. Dans le mode de réalisation décrit ici, la mise en gage ^^^^ ^^^^ ^^^^ est générée avec le schéma de mise en gage de Pedersen. Pour plus de renseignement sur ce schéma, l’homme du métier peut se reporter au document Torben P. Pedersen : Non-interactive and information- theoretic secure verifiable secret sharing. In Joan Feigenbaum, editor, CRYPTO’91, volume 576 of LNCS, pages 129–140. Springer, Heidelberg, August 1992. Au cours d’une étape U6, l’utilisateur USR transmet au fournisseur d’identité FI les attributs ^^^^ ^^^^ ^^^^, ^^^^₁, … , ^^^^ _^^^^ pour lesquels il souhaite obtenir une accréditation vérifiable ^^^^. Au cours d’une étape I8, le dispositif D-FI du fournisseur d’identité FI calcule une signature ^^^^ sur les attributs ^^^^ ^^^^ ^^^^, ^^^^₁, … , ^^^^ _^^^^ en utilisant sa clé privée ^^^^ ^^^^ _^^^^. Conformément à la présente divulgation, cette signature ^^^^ est une signature aveugle. On rappelle qu’une signature aveugle est un mécanisme de sécurité utilisé en cryptographie pour permettre à une partie de signer un message sans avoir connaissance du contenu de ce message de sorte à ce que la confidentialité du message soit préservée. Dans un tel mécanisme, la partie qui souhaite obtenir une signature aveugle combine le message à signer avec un facteur d’aveuglement généré aléatoirement et envoie le résultat de cette combinaison au signataire. Le signataire signe le message sans prendre connaissance de son contenu réel, et envoie la signature résultante au demandeur. Le demandeur peut utiliser le facteur d'aveuglement pour "désaveugler" la signature, c'est-à-dire pour annuler l'effet du facteur d'aveuglement et obtenir la signature du message d'origine. Dans le mode de réalisation décrit ici, la signature aveugle ^^^^ est calculée en utilisant la primitive de schéma de MAC algébrique. Dans l’exemple de réalisation décrit ici, la signature ^^^^ est en deux parties ^^^^ = ( ^^^^₁, ^^^^₂), où ^^^^₂ = ^^^^ ^{^^^^ ^^^^} 1 ^{^^^^}. Cette signature constitue une accréditation vérifiable au sens de la présente divulgation. Au cours d’une étape I10, le fournisseur d’identité FI calcule une preuve Π_I destinée à convaincre l’utilisateur USR de la validité de l’accréditation ^^^^. Dans le mode de réalisation décrit ici, il ne souhaite convaincre que l’utilisateur USR et il utilise à cet effet un mécanisme de preuve à vérificateur désigné connu de la personne de l’art de la cryptographie. Au cours d’une étape I12, le fournisseur d’identité FI retourne l’accréditation ^^^^ et la preuve Π_I à l’utilisateur USR. Au cours d’une étape U14, le dispositif D-USR de l’utilisateur désaveugle la signature ^^^^ et obtient une signature également notée ^^^^ pour plus de simplicité. Cette signature désaveuglée du message constitué de l’engagement ^^^^ ^^^^ ^^^^ sur l’attribut secret ^^^^₀ et des attributs publics ^^^^₁, … , ^^^^ _^^^^ de cet utilisateur constitue une accréditation vérifiable anonyme qui ne peut être vérifiée qu’en utilisant la clé secrète ^^^^ ^^^^ _^^^^ du fournisseur d’identité FI. Dans le mode décrit ici, elle est stockée dans le portefeuille WAL. La figure 3 représente les étapes mises en œuvre par les différents intervenants (utilisateur, fournisseur de service, fournisseur d’identité) lorsque l’utilisateur USR souhaite accéder au service proposé par le fournisseur de service FS. Conformément à la présente divulgation, l’utilisateur USR utilise à cet effet une présentation vérifiable (en anglais « verifiable presentation ») VP générée à partir d’une ou plusieurs accréditations ^^^^ délivrées par au moins un fournisseur d’identité FI. Par souci de simplicité, on suppose que la présentation vérifiable VP ne comporte qu’une accréditation vérifiable ^^^^. On rappelle que dans cet exemple cette accréditation vérifiable ^^^^ porte sur un engagement ^^^^ ^^^^ ^^^^ sur un attribut secret ^^^^₀. Nous désignerons par ^^^^, la liste des indices des attributs { ^^^^ _^^^^} _{^^^^∈ ^^^^} réclamés par le _{fournisseur de service FS et dans cet exemple ^^^^ =} ^{ _{1, 2} ^} _. Au cours d’une étape U20, l’utilisateur USR se connecte de façon anonyme auprès du fournisseur de service FS. Au cours d’une étape S22, le fournisseur de service demande à l’utilisateur USR une liste ^^^^ d’attributs qu’il a besoin de vérifier pour lui donner accès à son service. Dans un mode préféré de réalisation, cette demande est authentifiée, autrement dit signée par le fournisseur de service FS. Au cours d’une étape U24, l’utilisateur calcule une mise en gage ^^^^ sur l’ensemble de ses attributs publics certifiés ^^^^₁, … , ^^^^ _^^^^. Par souci de simplification, nous supposerons qu’il calcule ^{en fait ^^^^ mises en gage, une mise en gage par attribut public : ^^^^ = ( ^^^^1, ^^^^2, … , ^^^^ ^^^^) où ^^^^ ^^^^ ( ^^^^ ∈} _{{1,2, … , ^^^^}) désigne une mise en gage sur l’attribut ^^^^ ^^^^.} Conformément à la présente divulgation, le fournisseur de service FS demandera au fournisseur d’identité FI de lui apporter la preuve qu’il a bien certifié les attributs de l’utilisateur. Le fournisseur d’identité FI devrait donc vérifier, avec sa clé privée ^^^^ ^^^^ _^^^^, l’accréditation ^^^^ produite à l’étape I8. Mais comme le fournisseur d’identité FI ne doit pas pouvoir faire le rapprochement avec l’utilisateur USR qui lui a communiqué ses attributs (étape U4) pour le calcul de cette accréditation (étape I8), l’utilisateur USR calcule à l’étape U26, une accréditation vérifiable anonyme rafraichie ^^^^′ à partir de l’accréditation ^^^^ obtenue à l’étape U14. Ainsi, la nouvelle accréditation vérifiable ^^^^′ = porte toujours sur l’attribut secret ^^^^₀ et sur les attributs publics … , ^^^^ _^^^^ mais elle ne peut être rapprochée, notamment par le fournisseur d’identité FI, de l’accréditation ^^^^ produite par le fournisseur d’identité FI à l’étape I8. Dans le mode de réalisation décrit ici, au cours d’une étape U27, l’utilisateur USR génère une preuve ^^^^ _^^^^ à divulgation nulle de connaissance démontrant qu’il sait révéler les ^^^^ mises en gage ^^^^ _^^^^ et que l’accréditation anonyme vérifiable ^^^^′ est valide sur l’ensemble des valeurs ^^^^₀, ^^^^₁, ^^^^₂, … , ^^^^ _^^^^ mises en gage. Au cours d’une étape U28, l’utilisateur USR génère une présentation vérifiable VP comportant au moins une accréditation vérifiable ^^^^′. Dans le mode de réalisation décrit, la présentation vérifiable VP comporte la clé publique ^^^^ ^^^^ _^^^^ du fournisseur d’identité FI, l’accréditation vérifiable ^^^^′ , les mises en gage ^^^^ _^^^^ et la preuve ^^^^ _^^^^ à divulgation nulle de connaissance : ^^^^ ^^^^ = ( ^^^^ ^^^^ _^^^^ , ^^^^′,{ ^^^^ _^^^^} ^{^} ^_^ ^{^} ^_^ ^{^} =^{^} 1 , ^^^^ _^^^^). Comme mentionné précédemment, le fournisseur de service FS a besoin de vérifier les attributs publics ^^^^₁ ^^^^ ^^^^ ^^^^₂ ({ ^^^^ _^^^^} _{^^^^∈ ^^^^}) demandés et l’utilisateur doit donc lui fournir des informations pour les obtenir. Dans le mode de réalisation décrit ici, ces informations comportent les données nécessaires pour révéler les mises en gage ^^^^ _^^^^, uniquement pour ^^^^ ∈ ^^^^. Ces données sont ci-après appelées données d’ouverture et notées ^^^^ ^^^^ ^^^^ ^^^^( ^^^^ _^^^^) _{^^^^∈ ^^^^}. Lorsqu’on utilise un schéma de mise en gage basé sur une fonction de hachage la mise en gage peut être du type ^^^^ _^^^^) où ^^^^ _^^^^ est un aléa. Dans cet exemple ^^^^ _^^^^ et ^^^^ _^^^^ constituent les données d’ouverture ^^^^ ^^^^ ^^^^ ^^^^( ^^^^ _^^^^) _{^^^^∈ ^^^^}. Au cours d’une étape U30, l’utilisateur fournit la présentation vérifiable VP et les données d’ouverture ^^^^ ^^^^ ^^^^ ^^^^( ^^^^ _^^^^) _{^^^^∈ ^^^^} au fournisseur de service FS. Au cours d’une étape S32, le fournisseur de service FS vérifie que les données d’ouverture ^^^^ ^^^^ ^^^^ ^^^^( ^^^^ _^^^^) _{^^^^∈ ^^^^} permettent effectivement de révéler les attributs ^^^^₁ ^^^^ ^^^^ ^^^^₂ et que les attributs ^^^^₁ ^^^^ ^^^^ ^^^^₂ de l’utilisateur sont conformes aux conditions d’accès à son service. Si ce n’est pas le cas, dans le mode de réalisation décrit ici, le fournisseur de service FS refuse l’accès au service au cours d’une étape S34. Dans le mode de réalisation décrit ici, si les attributs ^^^^₁ ^^^^ ^^^^ ^^^^₂ de l’utilisateur sont conformes aux conditions d’accès à son service, le fournisseur de service vérifie, au cours d’une étape S36, la validité de la preuve ^^^^ _^^^^ à divulgation nulle de connaissance. Cette étape peut ne pas être effectuée, en particulier si le fournisseur d’identité FI est configuré pour effectuer cette vérification (voir étape I44 ci-après). Elle permet néanmoins au fournisseur de service de vérifier que la présentation vérifiable VP a bien été émise par l’utilisateur USR, et que celui-ci n’a pas réutilisé une présentation vérifiable d’un tiers qu’il aurait pu recopier frauduleusement. Dans le mode de réalisation décrit ici, si le fournisseur de service FS détermine que la preuve ^^^^ _^^^^ est invalide, il refuse l’accès au service au cours de l’étape S34. Avant de permettre l’accès au service à l’utilisateur USR, le fournisseur de service doit s’assurer que les attributs ^^^^₁ ^^^^ ^^^^ ^^^^₂ de l’utilisateur ont bien été certifiés. Conformément à la présente divulgation, seul le fournisseur d’identité lui-même peut apporter la preuve de cette certification. Au cours d’une étape S38, le fournisseur de service signe anonymement la présentation vérifiable ^^^^ ^^^^ avec sa clé privée de groupe ^^^^ ^^^^ _{^^^^ ^^^^}. En notant ^^^^ _{^^^^ ^^^^} cette signature, et en reprenant les notations présentées en préambule de _{la présente divulgation : ^^^^ ^^^^ ^^^^ = ^^^^ ^^^^ ^^^^ ^^^^ ^^^^ ^^^^ ^^^^ ^^^^} ⁽ _{^^^^ ^^^^} ⁾ _. Au cours d’une étape S40, le fournisseur de service FS transmet ensuite anonymement la présentation vérifiable ^^^^ ^^^^ et la signature de groupe ^^^^ _{^^^^ ^^^^} au fournisseur d’identité FI identifié dans cet exemple grâce à sa clé publique ^^^^ ^^^^ _^^^^. Il ne transmet pas les données d’ouverture ^^^^ ^^^^ ^^^^ ^^^^( ^^^^ _^^^^) _{^^^^∈ ^^^^} car elles permettraient au fournisseur d’identité d’identifier le fournisseur de service FS ainsi que l’utilisateur USR. Au cours d’une étape I42, le fournisseur d’identité FI vérifie la signature de groupe ^^^^ _{^^^^ ^^^^}. Cette opération lui permet de vérifier que le fournisseur de service FS fait partie des fournisseurs de service autorisés à le solliciter mais ne dévoile pas son identité. Dans certains modes de réalisation de la présente divulgation, si le fournisseur d’identité FI authentifie le fournisseur de service FS comme autorisé, il vérifie la validité de la preuve ^^^^ _^^^^ au cours d’une étape I44. Cette vérification peut ne pas être effectuée, notamment lorsque la preuve ^^^^ _^^^^ a été vérifiée par le fournisseur de service à l’étape S36. Elle permet cependant avantageusement au fournisseur d’identité de vérifier que la présentation vérifiable VP n’a pas été générée frauduleusement par le fournisseur de service lui-même. Dans un mode particulier de réalisation, le fournisseur d’identité FI vérifie systématiquement la validité de la preuve. Dans le mode de réalisation décrit ici, si le fournisseur d’identité FI échoue à valider la signature de groupe ^^^^ _{^^^^ ^^^^} (étape I42) ou la preuve ^^^^ _^^^^ (étape I44), il envoie au fournisseur de service FS, au cours d’une étape I46, un message lui indiquant que les vérifications demandées à l’étape S40 ont échoué. Dans le mode de réalisation décrit ici, le fournisseur de service FS refuse l’accès au service au cours de l’étape S34. Si ces deux vérifications sont concluantes, le fournisseur d’identité FI vérifie la validité de l’accréditation vérifiable anonyme ^^^^′ rafraîchie au cours d’une étape I48. Il utilise à cet effet ^{sa clé privée} On rappelle que dans cet exemple ^^^^′ est une clé en deux parties de la forme ^^^^′ = ( ^^^^′₁, ^^^^′₂) et cette vérification consiste à vérifier que Si la vérification de l’accréditation vérifiable rafraîchie échoue, le fournisseur d’identité génère (étape I50) une preuve Π _{^^^^ ^^^^} démontrant que l’accréditation vérifiable ^^^^′ est invalide. Π _{^^^^ ^^^^}= PoΚ( ^^^^ ∶ ^^^^ ^^^^ _^^^^ = ^^^^( ^^^^)⋀ ^^^^₂ ^′ ≠ ^^^^′₁ ^{^^^^}). Le fournisseur d’identité FI envoie cette preuve Π _{^^^^ ^^^^} au fournisseur de service FS (étape I52) et le fournisseur de service FS refuse l’accès au service au cours de l’étape S34. Au contraire, si l’accréditation vérifiable rafraîchie est vérifiée, le fournisseur d’identité génère (étape I54) une preuve Π _{^^^^ ^^^^} démontrant que l’accréditation vérifiable ^^^^′ a bien été validée avec sa clé secrète Π_NG= PoΚ( ^^^^ ∶ ^^^^ ^^^^ _^^^^ = ^^^^( ^^^^)⋀ ^^^^₂ ^′ = ^^^^′₁ ^{^^^^}) . Le fournisseur d’identité FI envoie cette preuve Π _{^^^^ ^^^^} au fournisseur de service FS (étape I56) et le fournisseur de service FS permet à l’utilisateur USR d’accéder au service au cours d’une étape S58. Chacun des dispositifs D-USR, D-FI et D-FS décrits précédemment peut être mis en œuvre par un ordinateur ORD dont l’architecture matérielle est représentée à la figure 4. Cet ordinateur ORD comporte notamment un processeur 10, une mémoire vive 11, une mémoire morte 12 et des moyens de communication 13. La mémoire morte 12 constitue un support d’enregistrement au sens de l’invention. Elle comporte un programme d’ordinateur PG-X conforme à l’invention. Pour le dispositif D-USR, ce programme d’ordinateur PG-X est un programme PG-USR comportant des instructions pour exécuter les étapes d’un procédé de demande d’accès à un service tel que décrit précédemment en référence aux figures 2 et 3. Le programme PG-USR définit notamment les modules M-AUTH d’authentification, d’obtention WAL d’une accréditation anonyme, de calcul WAL d’une accréditation rafraîchie, et de communication COM-3 du dispositif D-USR. Pour le dispositif D-FI, ce programme d’ordinateur PG-X est un programme PG-FI comportant des instructions pour exécuter les étapes d’un procédé de gestion d’au moins une accréditation vérifiable anonyme tel que décrit précédemment en référence aux figures 2 et 3. Le programme PG-FI définit notamment le module M-CRY1 d’authentification et de génération d’une accréditation vérifiable anonyme, et le module COM1 du dispositif D-FI. Pour le dispositif D-FS, ce programme d’ordinateur PG-X est un programme PG-FS comportant des instructions pour exécuter les étapes d’un procédé de contrôle d’accès à un service tel que décrit précédemment en référence aux figures 2 et 3. Le programme PG-FS définit notamment le module M-CRY2 de signature, le module ML-S de vérification des attributs et le module COM2 de communication du dispositif D-FS.

Claims

REVENDICATIONS [Revendication 1] Procédé de gestion d’au moins une accréditation vérifiable anonyme comportant les étapes suivantes : - authentification (U4) d’un utilisateur (D-USR) ; - obtention (U6) d’au moins un attribut ( ^^^^ ^^^^ ^^^^, ^^^^₁, … , ^^^^ _^^^^) de l’utilisateur ; - génération (I8) d’une accréditation vérifiable anonyme ( ^^^^) portant au moins sur le dit au moins un attribut ( ^^^^ ^^^^ ^^^^, ^^^^₁, … , ^^^^ _^^^^) de l’utilisateur, ladite accréditation ( ^^^^) étant un code de type MAC algébrique calculé en utilisant une clé privée ( ^^^^ ^^^^ _^^^^) d’un fournisseur d’identité; - calcul (I10) d’une preuve (Π_I) de la validité de l’accréditation vérifiable ( ^^^^) et - envoi (I12) de ladite preuve (Π_I) et de ladite accréditation ( ^^^^) audit utilisateur. [Revendication 2] Procédé de gestion selon la revendication 1 dans lequel au moins un desdits attributs ( ^^^^ ^^^^ ^^^^) est un engagement sur un attribut secret ( ^^^^ _^^^^) de l’utilisateur. [Revendication 3] Procédé de gestion selon la revendication 1 ou 2 comportant en outre les étapes de : - réception anonyme (S40), en provenance d’un fournisseur de service (FS), d’une présentation vérifiable (VP) comportant une accréditation vérifiable anonyme ( ^^^^′) portant sur au moins un des attributs ( ^^^^ ^^^^ ^^^^, ^^^^₁, … , ^^^^ _^^^^) d’un utilisateur (D-USR) et d’une signature de groupe ( ^^^^ _{^^^^ ^^^^}) de cette présentation (VP) ; - vérification (I42) de la validité de ladite signature de groupe ( ^^^^ _{^^^^ ^^^^}) ; - vérification (I48) de la validité de l’accréditation vérifiable anonyme ( ^^^^′) en utilisant ladite ^{clé privée ( ^^^^ ^^^^ ^^^^) du fournisseur d’identité, et en cas de succès, génération d’une preuve} _{(Π ^^^^ ^^^^) de la validité de ladite accréditation ( ^^^^′) ;} - envoi (I56) de ladite preuve (Π _{^^^^ ^^^^}) de la validité de l’accréditation vérifiable anonyme ( ^^^^′) au fournisseur de service (FS) uniquement si ladite signature de groupe ( ^^^^ _{^^^^ ^^^^}) a été déterminée (I42) valide. [Revendication 4] Procédé de gestion selon la revendication 3 dans lequel ladite présentation vérifiable (VP) comporte en outre une preuve ( ^^^^ _^^^^) à divulgation nulle de connaissance démontrant que l’utilisateur (D-USR) sait révéler une mise en gage ( ^^^^ _^^^^) sur ledit au moins un attribut ( ^^^^ ^^^^ ^^^^, ^^^^₁, … , ^^^^ _^^^^) et que l’accréditation anonyme vérifiable ( ^^^^′) est valide sur ledit au moins un attribut ( ^^^^ ^^^^ ^^^^, ^^^^₁, ^^^^₂, … , ^^^^ _^^^^) mis en gage, ledit procédé comportant : - une étape (I44) de vérification de la validité de ladite preuve ( ^^^^ _^^^^) ; - ladite preuve (Π _{^^^^ ^^^^}) de la validité de l’accréditation vérifiable anonyme ( ^^^^′) étant envoyée au fournisseur de service (FS) uniquement si ladite preuve ( ^^^^ _^^^^) à divulgation nulle de connaissance a été déterminée (I44) valide. [Revendication 5] Procédé de demande d’accès, mis en œuvre par un dispositif (D-USR) d’un utilisateur, pour demander accès à un service fourni par un fournisseur de service (FS), ledit procédé comportant les étapes suivantes : - authentification (U4) de l’utilisateur (D-USR) auprès d’un dispositif (D-FI) de gestion d’au moins une accréditation vérifiable anonyme; - envoi (U6) d’au moins un attribut ( ^^^^₁, … , ^^^^ _^^^^) de l’utilisateur audit dispositif de gestion (D- FI) ; - obtention (I12, U14) d’une accréditation vérifiable anonyme ( ^^^^) portant sur le dit au moins un attribut ( ^^^^ ^^^^ ^^^^, ^^^^₁, … , ^^^^ _^^^^) de l’utilisateur et d’une preuve (Π_I) de la validité de l’accréditation vérifiable ( ^^^^), ladite accréditation ( ^^^^) étant un code de type MAC algébrique calculé en utilisant une clé privée ( ^^^^ ^^^^ _^^^^) dudit dispositif de gestion (D-FI) ; - calcul (U26) d’une accréditation vérifiable anonyme rafraîchie ( ^^^^′) à partir de ladite accréditation ( ^^^^) ; - envoi (U30), audit fournisseur de service (FS), d’une présentation vérifiable (VP) ^{comportant au moins ladite accréditation rafraîchie ( ^^^^′) et des informations ({ ^^^^ ^^^^ ^^^^} ^^^^=1 ,} _{Open( ^^^^i)i∈ ^^^^) permettant au fournisseur de service d’obtenir au moins un attribut ({ai}i∈ ^^^^) )} dudit utilisateur demandé par ledit fournisseur de service (FS). [Revendication 6] Procédé de demande d’accès selon la revendication 5, dans lequel la présentation vérifiable (VP) comporte une mise en gage ( ^^^^ _^^^^) sur l’ensemble des attributs de l’utilisateur, lesdites informations comportant des données d’ouverture ( ^^^^ ^^^^ ^^^^ ^^^^( ^^^^ _^^^^) _{^^^^∈ ^^^^}) permettant de n’ouvrir que ledit au moins un attribut ({ ^^^^ _^^^^} _{^^^^∈ ^^^^}) demandé par ledit fournisseur de service (FS). [Revendication 7] Procédé de contrôle d’accès à un service par un utilisateur (D-USR), ledit procédé étant mis en œuvre par un fournisseur de service (D-FS) et comportant les étapes suivantes : - obtention (U30) d’une présentation vérifiable (VP) comportant une accréditation vérifiable anonyme ( ^^^^′) portant sur des attributs ( ^^^^ ^^^^ ^^^^, ^^^^₁, … , de l’utilisateur, ladite accréditation vérifiable anonyme ( ^^^^′) étant un code de type MAC algébrique calculé en utilisant une clé privée ( ^^^^ ^^^^ _^^^^) dudit fournisseur d’identité ; - obtention (U30) d’informations ({ ^^^^ _^^^^} ^{^} ^_^ ^{^} ^_^ ^{^} =^{^} 1 , ^^^^ ^^^^ ^^^^ ^^^^( ^^^^ _^^^^) _{^^^^∈ ^^^^}) permettant au fournisseur de service d’obtenir au moins un desdits attributs ({ ^^^^ _^^^^} _{^^^^∈ ^^^^}) et vérification (S32) dudit au moins un attribut ({ ^^^^ _^^^^} _{^^^^∈ ^^^^}) ; - signature (S38) de ladite présentation vérifiable (VP) avec une clé privée de groupe ( ^^^^ ^^^^ _{^^^^ ^^^^}) pour obtenir une signature de groupe ( ^^^^ _{^^^^ ^^^^}) ; - envoi anonyme (S40), à un dispositif (D-FI) configuré pour valider ladite accréditation ( ^^^^′), de ladite présentation vérifiable (VP) et de ladite signature de groupe ( ^^^^ _{^^^^ ^^^^}) ; - un résultat positif d’une vérification (S32) dudit au moins un attribut (^{ ^^^^ _^^^^ ^} _{^^^^∈ ^^^^}) et l’obtention d’une preuve (Π _{^^^^ ^^^^}) de la validité de ladite accréditation ( ^^^^′) étant des conditions nécessaires pour autoriser (S58) l’accès de l’utilisateur (USR) audit service. [Revendication 8] Procédé de contrôle d’accès selon la revendication 7 dans lequel ladite présentation vérifiable (VP) comporte en outre une preuve ( ^^^^ _^^^^) à divulgation nulle de connaissance démontrant que l’utilisateur (D-USR) sait révéler une mise en gage ( ^^^^ _^^^^) sur lesdits attributs ( ^^^^₀, ^^^^₁, … , ^^^^ _^^^^) et que l’accréditation anonyme vérifiable ( ^^^^′) est valide sur l’ensemble des attributs ( ^^^^₀, ^^^^₁, ^^^^₂, … , ^^^^ _^^^^) mis en gage, ledit procédé comportant : - une étape (S36) de vérification de la validité de ladite preuve ( ^^^^ _^^^^) ; - un résultat positif de ladite vérification (S36) étant une condition nécessaire pour autoriser (S58) l’accès de l’utilisateur (USR) audit service. [Revendication 9] Dispositif (D-FI) de gestion d’au moins une accréditation vérifiable anonyme, ce dispositif comportant: - un module (M-CRY1) d’authentification (U4) d’un utilisateur (D-USR) ; ^{- un module (COM1) d’obtention (U6) d’au moins un attribut ( ^^^^ ^^^^ ^^^^, ^^^^} _{1, … , ^^^^ ^^^^) de l’utilisateur ;} - un module (M-CRY1) de génération (I8) d’une accréditation vérifiable anonyme ( ^^^^) portant ^{au moins sur le dit au moins un attribut ( ^^^^ ^^^^ ^^^^, ^^^^1, … , ^^^^ ^^^^) de l’utilisateur, ladite accréditation} _{( ^^^^) étant un code de type MAC algébrique calculé en utilisant une clé privée ( ^^^^ ^^^^ ^^^^) du} fournisseur d’identité ; ^{- un module (M-CRY1) de calcul d’une preuve (Π} _I ^{) de la validité de l’accréditation vérifiable} _{( ^^^^) et} - un module (COM1) d’envoi (I12) de ladite preuve (Π_I) et de ladite accréditation ( ^^^^) audit utilisateur. [Revendication 10] Dispositif (D-USR) de demande d’accès à un service fourni par un fournisseur de service (FS), ledit dispositif comportant: - un module (M-AUTH) d’authentification (U4) d’un utilisateur (D-USR) auprès d’un dispositif (D-FI) de gestion d’au moins une accréditation vérifiable anonyme; - un module (COM3) d’envoi (U6) d’au moins un attribut ( ^^^^₁, … , de l’utilisateur audit dispositif de gestion (D-FI) ; - un module (WAL) d’obtention (I12, U14) d’une accréditation vérifiable anonyme ( ^^^^) portant sur le dit au moins un attribut ( ^^^^ ^^^^ ^^^^, ^^^^₁, … , ^^^^ _^^^^) de l’utilisateur et d’une preuve (Π_I) de la validité de l’accréditation vérifiable ( ^^^^), ladite accréditation ( ^^^^) étant un code de type MAC algébrique calculé en utilisant une clé privée ( ^^^^ ^^^^ _^^^^) dudit dispositif de gestion (D-FI) ; - un module (WAL) de calcul (U26) d’une accréditation vérifiable anonyme rafraîchie ( ^^^^′) à partir de ladite accréditation ( ^^^^) ; - un module d’envoi (COM3), audit fournisseur de service (FS), d’une présentation vérifiable ^{(VP) comportant au moins ladite accréditation rafraîchie ( ^^^^′) et des informations ({ ^^^^ ^^^^ ^^^^} ^^^^=1 ,} _{Open( ^^^^i)i∈ ^^^^) permettant au fournisseur de service d’obtenir au moins un attribut ({ai}i∈ ^^^^) )} dudit utilisateur demandé par ledit fournisseur de service (FS). [Revendication 11] Dispositif (D-FS) de contrôle d’accès à un service par un utilisateur (D- USR), ledit dispositif comportant: - un module (COM2) d’obtention (U30) d’une présentation vérifiable (VP) comportant une accréditation vérifiable anonyme ( ^^^^′) portant sur des attributs ( ^^^^ ^^^^ ^^^^, ^^^^₁, … , ^^^^ _^^^^) de l’utilisateur, ladite accréditation vérifiable anonyme ( ^^^^′) étant un code de type MAC algébrique calculé en utilisant une clé privée ( ^^^^ ^^^^ _^^^^) dudit fournisseur d’identité ; - un module (COM2) d’obtention (U30) d’informations ({ ^^^^ _^^^^} ^{^} ^_^ ^{^} ^_^ ^{^} =^{^} 1 , ^^^^ ^^^^ ^^^^ ^^^^( ^^^^ _^^^^) _{^^^^∈ ^^^^}) permettant au fournisseur de service d’obtenir au moins un desdits attributs (^{ ^^^^ _^^^^ ^} _{^^^^∈ ^^^^}) ; - un module (M-LS) de vérification (S32) dudit au moins un attribut (^{ ^^^^ _^^^^ ^} _{^^^^∈ ^^^^}) ; - un module (M-CRY2) de signature (S38) de ladite présentation vérifiable (VP) avec une clé privée de groupe ( ^^^^ ^^^^ _{^^^^ ^^^^}) pour obtenir une signature de groupe ( ^^^^ _{^^^^ ^^^^}) ; - un module (COM2) d’envoi, de manière anonyme (S40), à un dispositif (D-FI) configuré pour valider ladite accréditation ( ^^^^′), de ladite présentation vérifiable (VP) et de ladite signature de groupe ( ^^^^ _{^^^^ ^^^^}) ; - un module (COM2) configuré pour autoriser (S58) l’accès de l’utilisateur (USR) audit service au moins si une vérification (S32) dudit au moins un attribut (^{ ^^^^ _^^^^ ^} _{^^^^∈ ^^^^}) est positive et si une preuve (Π _{^^^^ ^^^^}) de la validité de ladite accréditation ( ^^^^′) est obtenue. [Revendication 12] Programme d'ordinateur (PG-USR, PG-FS, PG-FI) comprenant des instructions qui, lorsque le programme est exécuté par un ordinateur, conduisent celui-ci à mettre en œuvre : - un procédé de gestion d’au moins une accréditation vérifiable anonyme selon l’une quelconque des revendications 1 à 4 ; ou - un procédé de demande d’accès à un service selon la revendication 5 ou 6 ; ou - un procédé de contrôle d’accès à un service selon la revendication 7 ou 8. [Revendication 13] Support d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur (PG) selon la revendication 12.