Brevet FR3159868A1 — publié le 20250905

Un dispositif de gestion d’accréditations (D-FI) génère une accréditation vérifiable anonyme portant sur des attributs d’un utilisateur (D-USR), dont un identifiant de cette accréditation. Il gère également une liste de ces identifiants et un accumulateur cryptographique dans lequel les identifiants valides sont accumulés. Il calcule un témoin représentatif de l’appartenance de l’identifiant d’une accréditation à cette une liste et une preuve associée à ce témoin . L’utilisateur peut calculer une preuve de non révocation de l’identifiant de son accréditation vérifiable anonyme et utiliser ses attributs certifiés pour exercer un droit, par exemple accéder à un service sous réserve de la vérification de cette preuve et de la validité de l’accréditation. Fig. 1 Procédés et dispositifs de gestion de la révocation d’accréditations cryptographiques 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. Par exemple, 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.). En particulier, il est connu un mécanisme dans lequel une autorité délivre des accréditations cryptographiques pour certifier des attributs de ses utilisateurs, un fournisseur de service étant en mesure d’obtenir une preuve de la validité d’une telle accréditation avant de délivrer l’accès à son service. Traditionnellement, des systèmes de révocation sont associés à des schémas d’authentification. Par exemple, dans une infrastructure à clés publiques, des certificats avec une durée de validité limitée doivent être renouvelés régulièrement. Dans certaines circonstances, l’entité détentrice d’un certificat peut être amenée à évoluer quant aux informations présentes dans son certificat ou à être exclue de l’infrastructure. Le certificat qu’elle détient doit être exclu des certificats considérés comme valides. La RFC 5280 définit différentes méthodes de révocation (https://www.rfc-editor.org/rfc/pdfrfc/rfc5280.txt.pdf). OAuth 2.0 (https://www.rfc-editor.org/rfc/rfc6749) est un système d’autorisation à l’accès synchrone au sens où l’utilisateur obtient un jeton d’un système central, jeton qui lui permet d’accéder à une ressource. La révocation est décrite dans la rfc7009 (https://www.rfc-editor.org/rfc/rfc7009). Le fournisseur de service gestionnaire de la ressource peut systématiquement interroger le système central pour s’assurer de la validité du jeton. Dans un tel système, les jetons peuvent être révoqués conséquemment à l’expiration de leur date de validité, à la déclaration par le fournisseur de service ou l’utilisateur auprès d’un point de terminaison dédié sur le système central, voire par le système central lui-même sur des critères propres (sécuritaires ou liés à la gestion du système). Souvent, dans ce type d’architecture, le système stocke les jetons valides qu’il a émis dans sa base de données, un processus d’effacement s’activant à l’expiration de leur date de validité ou sur une action volontaire de suppression. Dans d’autres systèmes plus asynchrones, le fournisseur de service peut être amené à gérer une liste noire comprenant l’ensemble de jetons révoqués, ou une liste blanche comprenant l’ensemble des jetons valides, ces deux listes étant alimentées par le système central. Enfin, dans des systèmes où l’équipement de l’utilisateur est maîtrisé par le système central, la suppression du jeton peut être réalisée sur l’équipement de l’utilisateur par le système central. Les preuves de non révocation de jetons de l’état actuel de la technique, soit n’offrent aucun anonymat à l’utilisateur, soit un anonymat calculatoire qui pourrait être levé par des attaquants disposant d’ordinateurs quantiques puissants, soit sont trop coûteuses pour être générées par des dispositifs (tels que des cartes à puce) disposant d’une puissance de calculs limitée voire impliquent des opérations non supportées par ces dispositifs (couplages bilinéaires par exemple). La présente divulgation vise à améliorer ces mécanismes de révocation et en particulier, dans au moins certains modes de réalisation, à offrir une solution cryptographique à la fois anonyme (les preuves de non révocation de jetons ne révèlent aucune information sur le propriétaire du jeton), n’impliquant que des opérations mathématiques classiques et résistante à des attaques par des ordinateurs quantiques ou plus généralement disposant d’une puissance de calcul non bornée. Objet et résumé de l’invention 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, le procédé étant mis en œuvre par un dispositif de gestion d’accréditations et comportant les étapes suivantes : - génération d’une accréditation vérifiable anonyme portant sur une pluralité d’attributs dont l’un est un identifiant de cette accréditation; - mise à jour d’une liste d’identifiants d’accréditation accumulés dans un accumulateur cryptographique par ajout ou retrait dudit identifiant ( )et de la valeur de l’accumulateur, ladite liste étant : (i) soit une liste blanche comportant des identifiants valides ; (ii) soit liste noire comportant des identifiants non valides ; - calcul d’un témoin représentatif de : (i) l’appartenance dudit identifiant à une liste blanche ; ou (ii) de la non-appartenance dudit identifiant à une liste noire et (iii) d’une preuve associée audit témoin; - envoi à un utilisateur : (i) de ladite accréditation vérifiable anonyme (ii) d’une preuve de la validité de ladite accréditation vérifiable anonyme; (iii) dudit identifiant de ladite accréditation vérifiable anonyme ; et (iv) dudit témoin et de la preuve associée audit témoin. Corrélativement, la divulgation concerne un dispositif de gestion d’accréditations comportant: - un module de génération d’une accréditation vérifiable anonyme portant sur une pluralité d’attributs dont l’un est un identifiant de cette accréditation; - un module de mise à jour d’une liste d’identifiants d’accréditation accumulés dans un accumulateur cryptographique par ajout ou retrait dudit identifiant et de la valeur de l’accumulateur, ladite liste étant: (i) soit une liste blanche comportant des identifiants valides ; (ii) soit une liste noire comportant des identifiants non valides ; - un module de calcul d’un témoin représentatif de : (i) l’appartenance dudit identifiant à une liste blanche ; ou (ii) de la non-appartenance dudit identifiant à une liste noire et (iii) d’une preuve associée audit témoin; - un module d’envoi à un utilisateur : (i) de ladite accréditation vérifiable anonyme (ii) d’une preuve de la validité de ladite accréditation vérifiable anonyme; (iii) dudit identifiant de ladite accréditation vérifiable anonyme ; (iv) dudit témoin et de la preuve associée audit témoin. Ainsi, et d’une façon générale, le dispositif de génération d’accréditations peut, préférentiellement après avoir authentifié un utilisateur, générer 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, un desdits attributs est un engagement portant sur un attribut secret de l’utilisateur, 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. De façon très avantageuse, la présente divulgation propose de gérer la liste des identifiants d’accréditations valides ou révoqués par des accumulateurs cryptographiques. La liste des identifiants valides ou révoqués est ainsi une liste compressée dont la taille n’est pas fonction du nombre d’identifiants qu’elle représente. Dans un mode de réalisation de la présente divulgation, pour générer la liste compressée des identifiants révoqués (respectivement non-révoqués), on utilise l’accumulateur universel dynamique proposé par la référence [1] avec les adaptations présentées ci-après pour qu’il puisse être supporté par des dispositifs contraints comme des éléments sécurisés (en anglais secure elements SE) qui n’implantent pas certaines opérations mathématiques comme les couplages utilisés classiquement par ce type d’accumulateurs). [1] : Giuseppe Vitto, Alex Biryukov : Dynamic Universal Accumulator with Batch Update over Bilinear Groups. CT-RSA 2022: 395-426. Dans un mode particulier de réalisation: (i) la valeur de l’accumulateur après ajout d’une valeur (ou ) à une liste noire ou blanche est calculée par ; - le témoin d’appartenance dudit identifiant à ladite liste blanche est calculé par , - la preuve associée à ce témoin est =PoK - la valeur de l’accumulateur après retrait d’une valeur (ou ) à une liste noire est blanche est calculée par ; - le témoin de non-appartenance dudit identifiant à ladite liste noire est calculé par , - la preuve associée à ce témoin est =PoK où : - sont des générateurs publics dudit accumulateur ; - est un entier appartenant à {1, 2,…, p-1}, la clé privée du dispositif de gestion d’accréditations pour la gestion de l’accumulateur est égale à - , - la clé publique pour la gestion de l’accumulateur est - = = - est la valeur de l’accumulateur avant ladite mise à jour ; - où est un polynôme défini par , étant une liste de valeurs secrètes utilisée pour initialiser l’accumulateur et l'ensemble des éléments accumulés dans l’accumulateur V à l'exclusion des éléments d'initialisation - est une valeur initiale de l’accumulateur : Dans un mode particulier de réalisation de la présente divulgation, l’accréditation vérifiable anonyme est une signature aveugle calculée en utilisant une clé privée dudit dispositif de gestion d’accréditations. 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 peut utiliser 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 gestionnaire d’accréditation génère l’accréditation en utilisant une signature aveugle calculée avec sa clé privée de sorte que tout fournisseur de service puisse vérifier sa validité en utilisant la clé publique du gestionnaire d’accréditation. 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. à la section 4.3 du 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 permet au gestionnaire d’accréditation de générer des accréditations anonymes que tout fournisseur de service peut vérifier en utilisant la clé publique du gestionnaire.. 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. 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. Dans un mode particulier de réalisation de la présente divulgation, ladite accréditation vérifiable anonyme est un couple calculé selon le protocole BBS+ défini par des paramètres publics avec où : - désigne un environnement bilinéaire pour lequel le problème q SDH est difficile ; - p est un entier premier qui désigne l’ordre des groupes cycliques , et - désignent n+3 générateurs de choisis aléatoirement, chaque étant associé à un type d’attribut spécifique ; - sont les générateurs publics dudit accumulateur ; - désigne un générateur de , et dans lequel : , où , ,…, sont des valeurs aléatoires choisies par ledit dispositif de gestion d’accréditations. Selon un deuxième aspect, la divulgation concerne un procédé mis en œuvre par un dispositif d’un utilisateur, ce procédé comportant les étapes suivantes : - réception , en provenance d’un dispositif de gestion d’accréditations : (i) d’au moins une accréditation vérifiable anonyme portant sur une pluralité d’attributs dont l’un est un identifiant de cette accréditation; (ii) d’une preuve de la validité de ladite accréditation vérifiable anonyme; (iii) de l’identifiant de ladite accréditation vérifiable anonyme ; (iv) d’un témoin de l’appartenance dudit identifiant à une liste blanche d’identifiants valides ou de la non-appartenance dudit identifiant à une liste noire d’identifiants non valides, ladite liste blanche ou noire étant une liste d’éléments accumulés dans un accumulateur cryptographique ; (v) d’une preuve associée audit témoin; - obtention d’une preuve de non révocation de l’identifiant de ladite accréditation vérifiable anonyme d’intérêt constituée par : (i) une preuve que ledit identifiant de ladite accréditation vérifiable anonyme d’intérêt appartient à ladite liste blanche ou par (ii) une preuve que ledit identifiant de ladite accréditation vérifiable anonyme d’intérêt n’appartient pas à ladite liste noire ; - utilisation d’au moins un desdits attributs pour exercer un droit de l’utilisateur au moins sous condition de l’obtention d’une preuve de la validité de ladite accréditation et de la non-révocation dudit identifiant. Corrélativement, la divulgation concerne un dispositif comportant : - un module de réception , en provenance d’un dispositif de gestion d’accréditations : (i) d’au moins une accréditation vérifiable anonyme portant sur une pluralité d’attributs dont l’un est un identifiant de cette accréditation; (ii) d’une preuve de la validité de ladite accréditation vérifiable anonyme; (iii) de l’identifiant de ladite accréditation vérifiable anonyme ; (iv) d’un témoin de l’appartenance dudit identifiant à une liste blanche d’identifiants valides ou de la non-appartenance dudit identifiant à une liste noire d’identifiants non valides, ladite liste blanche ou noire étant une liste d’éléments accumulés dans un accumulateur cryptographique ; (v) d’une preuve associée audit témoin; - un module d’obtention d’une preuve de non révocation de l’identifiant de ladite accréditation vérifiable anonyme d’intérêt constituée par : (i) une preuve que ledit identifiant de ladite accréditation vérifiable anonyme d’intérêt appartient à ladite liste blanche ou par (ii) une preuve que ledit identifiant de ladite accréditation vérifiable anonyme d’intérêt n’appartient pas à ladite liste noire ; - un module d’utilisation d’au moins un desdits attributs pour exercer un droit de l’utilisateur au moins sous condition de l’obtention d’une preuve de la validité de ladite accréditation et de la non-révocation dudit identifiant. Dans un mode particulier de réalisation, ce procédé est un procédé pour demander l’accès à un service dans lequel ladite au moins une accréditation vérifiable anonyme porte sur une pluralité d’attributs de l’utilisateur, ledit procédé comportant en outre les étapes suivantes; - sélection d’au moins une dite accréditation vérifiable anonyme dite « d’intérêt » portant sur au moins un attribut d’intérêt pour un fournisseur dudit service ; - envoi, audit fournisseur de service : (i) d’une présentation vérifiable comportant au moins une accréditation rafraîchie obtenue à partir de ladite accréditation vérifiable anonyme d’intérêt permettant au fournisseur de service d’obtenir ledit au moins un attribut d’intérêt (ii) ladite preuve de non révocation de l’identifiant de ladite accréditation vérifiable anonyme d’intérêt. Dans un mode particulier de réalisation : (i) la preuve que ledit identifiant de ladite accréditation vérifiable anonyme d’intérêt appartient à ladite liste blanche est du type , , avec : où (notons que cette valeur ne doit pas être confondue avec la valeur de l’équation (EQ) présentée ultérieurement). Posons = et = On a donc = (ii) la preuve que ledit identifiant de ladite accréditation vérifiable anonyme d’intérêt n’appartient à ladite liste noire est du type , , avec : où = où : - sont des générateurs publics dudit accumulateur ; - est un entier appartenant à {1, 2,…, p-1}, la clé privée du dispositif de gestion d’accréditations pour la gestion de l’accumulateur étant égale à - , - la clé publique pour la gestion de l’accumulateur est =( , ) - = = - est la valeur de l’accumulateur avant ladite mise à jour ; - où est un polynôme défini par , étant une liste de valeurs secrètes utilisée pour initialiser l’accumulateur - est une valeur initiale de l’accumulateur : - = . Pour vérifier la validité de , on doit s’assurer que l’égalité suivante est satisfaite et d’autre part que est valide. L’algorithme de vérification de cette ZKP ( ) étant relativement classique pour l’homme de l’art, nous ne le détaillerons pas dans ce document. Pour plus de renseignements ; l’homme du métier peut se reporter au document David Chaum, Torben P. Pedersen: Wallet Databases with Observers. CRYPTO 1992: 89-105 Si est valide alors, on démontre aisément que l’on connaît nécessairement et tels que et donc que, sous l’hypothèse q-SDH, est bien accumulé dans . Par ailleurs et de façon très avantageuse, on démontre mathématiquement que la preuve ainsi définie ne révèle aucune information sur la valeur (par exemple sur l’identifiant de l’accréditation de l’utilisateur, y compris pour un utilisateur disposant d’une puissance de calcul non bornée et donc a fortiori pour un attaquant disposant d’un ordinateur quantique). Soit , le témoin d’appartenance de l’identifiant ( ) de l’accréditation d’un utilisateur (différent de l’utilisateur ayant généré la preuve ), à la liste des identifiants valides. On a bien entendu . Nous allons d’une part démontrer que l’utilisateur aurait tout aussi bien pu générer la même preuve (i.e. en produisant exactement les même valeurs et ) et d’autre part que personne, y compris un attaquant disposant d’une puissance de calcul non-bornée, n’est en mesure de savoir qui de ou de a généré la preuve : , . Comme est un élément d’un groupe cyclique d’ordre et que est différent de 1 (l’élément neutre de ce groupe), cela implique qu’il existe un entier tel que . On a donc et donc que . Ceci implique, en réutilisant les notations ci-dessus, que . On vient donc de montrer que aurait également pu produire les valeurs et . Etant donné que la preuve , qui est rappelons-le classique pour l’homme de l’art, est prouvée statistiquement ZK, elle ne révèle donc aucune information, y compris face à un attaquant disposant d’une puissance de calcul non-bornée, sur la paire secrète ( ) utilisée pour produire la preuve . Par conséquent, un attaquant, y compris disposant d’une puissance de calcul non-bornée, n’a aucune possibilité de déterminer qui de ou de a généré la preuve : , . Cela conclut donc la démonstration que garantit bien une confidentialité éternelle (en anglais Everlasting Privacy). De façon similaire, pour vérifier la validité de , on doit d’une part s’assurer que l’égalité suivante est satisfaite et d’autre part que est valide. L’algorithme de vérification de cette ZKP ( étant relativement classique pour l’homme de l’art (voir par exemple [2] et [3]), nous ne le détaillerons pas dans ce document. [2] : David Chaum, Torben P. Pedersen:bWallet Databases with Observers. CRYPTO 1992: 89-105 [3] : Stefan Brands: Rapid Demonstration of Linear Relations Connected by Boolean Operators. EUROCRYPT 1997: 318-333 Si est valide alors, on démontre aisément que l’utilisateur connaît nécessairement des valeurs , et telles que et donc que, sous l’hypothèse q-SDH, n’est pas accumulé dans . Il est entendu que l’utilisateur devra, en plus de sa VP, également transférer cette preuve de connaissance au fournisseur de service afin de le convaincre que la VP contient bien un VC non révoqué. La confidentialité éternelle procurée par se démontre de la même façon que dans le cas précédent avec Il faut noter que les preuves à divulgation nulle de connaissance ZKP proposées dans l’état de l’art pour ou , soit n’offrent aucun anonymat à l’utilisateur, soit un anonymat calculatoire (qui pourrait être levé par des attaquants disposant d’ordinateurs quantiques puissants), soit sont trop coûteuses pour être générées par des dispositifs (tels que des cartes à puce) disposant d’une puissance de calculs limitée voire impliquent des opérations non supportées par ces dispositifs (couplages bilinéaires par exemple). Les preuves ou en revanche dans cette divulgation ne révèlent aucune information sur l’utilisateur qui la présente (y compris pour un attaquant disposant d’une puissance de calcul non bornée) et n'impliquent que des opérations mathématiques classiques (addition de points ou multiplications scalaires sur courbes elliptiques) et sont suffisamment efficaces pour être exécutées par des cartes à puce. Selon un troisième aspect, la 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 d’intérêt portant sur des attributs d’intérêt de l’utilisateur et d’une preuve de non révocation d’un identifiant de ladite accréditation vérifiable anonyme d’intérêt; - vérification dudit au moins un attribut d’intérêt ; - vérification de la validité de ladite preuve de non révocation ; - vérification de ladite accréditation vérifiable anonyme d’intérêt comprise dans ladite présentation vérifiable, - 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 et de la non-révocation dudit identifiant étant des conditions nécessaires pour autoriser l’accès de l’utilisateur audit service. Corrélativement, la 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 d’intérêt portant sur des attributs d’intérêt de l’utilisateur et d’une preuve de non révocation d’un identifiant de ladite accréditation vérifiable anonyme d’intérêt; - un module de vérification dudit au moins un attribut d’intérêt ; - un module de vérification de la validité de ladite preuve de non révocation ; - un module de vérification de ladite accréditation vérifiable anonyme d’intérêt comprise dans ladite présentation vérifiable, - 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 et de la non-révocation dudit identifiant étant des conditions nécessaires pour autoriser l’accès de l’utilisateur audit service. Ainsi, dans au moins un mode de réalisation, l’ensemble des mécanismes cryptographiques mis en œuvre par l‘invention permettent de constituer une liste compressée des identifiants d’accréditation révoqués, et de prouver que l’identifiant d’une accréditation détenue par l’utilisateur n’est pas présent dans cette liste. Cette preuve à divulgation nulle de connaissance, ne révèle aucune information, sur l’identifiant utilisé par l’utilisateur. En d’autres termes, même un attaquant disposant d’un ordinateur quantique ou d’une puissance de calcul non bornée, ne sera en mesure d’identifier l’utilisateur à l’origine de cette ZKP. Typiquement, si pour accéder à un service, l’utilisateur doit présenter au fournisseur de service une preuve de majorité valide (i.e. non révoquée) délivré par un fournisseur d’identité accrédité, cet utilisateur aura la garantie que personne ne pourra savoir que par le passé il accédait à ce service. L’utilisateur voit donc sa vie privée protégée de manière maximale avec une confidentialité illimitée (en anglais, ce type de protection est connue sous le nom d’Everlasting Privacy). La divulgation vise aussi un programme d’ordinateur comportant des instructions pour exécuter les étapes d’un procédé tel que décrit ci-dessus lorsque ledit programme est exécuté par un ordinateur. Ce programme peut 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. La divulgation 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 la divulgation 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. 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 : FIG. 1 La FIG. 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 ; FIG. 2 La FIG. 2 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 ; FIG. 3 La FIG. 3 représente l’architecture matérielle des dispositifs de la FIG. 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. 1. 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 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) et calculatoirement résistants aux collisions. Présentation du schéma de mise en gage de Pedersen Dans un schéma de mise en gage de Pedersen on considère un groupe cyclique d’ordre premier et et deux générateurs quelconques de . On suppose que le logarithme discret de en base est inconnu. Pour une opération de « mise en gage » dans laquelle un émetteur s’engage sur un message auprès d’un destinataire, l’émetteur choisit une valeur aléatoire , calcule et l’envoie au destinataire. Pour une opération « d’ouverture », l’émetteur envoie au destinataire le message et la valeur aléatoire afin que ce dernier vérifie l’égalité : . Le procédé ci-dessus peut être facilement généralisé par la mise en gage de plusieurs messages par exemple messages ( . Soient un groupe cyclique d’ordre premier et générateurs quelconques de : et . Pour s’engager sur des messages de son choix, l’émetteur choisit une valeur aléatoire et calcule et l’envoie au destinataire. Pour l’opération d’ouverture, l’émetteur envoie au destinataire les messages et la valeur aléatoire afin que ce dernier vérifie l’égalité : . 2. 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 satisfaisant un prédicat donné, la preuve ne révélant au vérifieur aucune information sur le secret en question hormis le fait que celui-ci vérifie bien le prédicat donné. Par la suite, pour représenter les preuves à divulgation nulle de connaissance, nous utiliserons parfois la notation usuelle . 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). 3. Signatures de groupes et signatures anonymes Dans un mode particulier de réalisation, certains dispositifs peuvent 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. 4. Accumulateur cryptographique 4.1 Principe On rappelle qu’un accumulateur cryptographique permet d'agréger plusieurs valeurs différentes d'un ensemble fini en un condensé de longueur fixe (typiquement 256 bits) appelé valeur de l'accumulateur. Contrairement aux fonctions de hachage, les accumulateurs cryptographiques fournissent différentes méthodes permettant de vérifier facilement si un élément est accumulé (respectivement non accumulé) dans une valeur d'accumulateur donnée via des témoins d'appartenance (respectivement de non-appartenance). En d’autres termes, étant donné un témoin d'appartenance pour un élément accumulé et la valeur actuelle de l'accumulateur , il est possible de vérifier efficacement que l'élément fait bien partie de la liste des éléments accumulés. Les accumulateurs cryptographiques qui ne prennent en charge que les témoins d'appartenance sont appelés accumulateurs positifs, ceux qui ne prennent en charge que les témoins de non-appartenance sont appelés accumulateurs négatifs, tandis que ceux qui prennent en charge les deux sont appelés accumulateurs universels. Une exigence commune aux accumulateurs cryptographiques est la possibilité de modifier l'ensemble des éléments accumulés, ce qui permet les mises à jour de l'accumulateur. Dans le mode de réalisation décrit ici, une entité gestionnaire de l’accumulateur cryptographique définit les paramètres publics de cet accumulateur cryptographique : , où : - e : un couplage bilinéaire défini de vers un ensemble où , et désignent des groupes cycliques d’ordre , étant un nombre premier. Pour simplification, on suppose que la loi de groupe dans et est la multiplication ; - désignent deux générateurs de choisis aléatoirement, de sorte que le logarithme discret d’un de ces générateurs est inconnu par rapport à un autre de ces générateurs ; et - désigne un générateur de choisi aléatoirement Dans la suite, tous les calculs portant sur les exposants seront effectués modulo . 4.2 Générations des clés : Dans un mode de réalisation de la présente divulgation, le gestionnaire de l’accumulateur cryptographique génère aléatoirement un entier appartenant à {1, 2,…, p-1} et calcule ainsi que . La clé privée du gestionnaire de l’accumulateur cryptographique peut être choisie égale à et sa clé publique peut être constituée de la paire . Comme de façon connue par l’homme du métier de la cryptographie, la valeur de l’accumulateur évolue en fonction des valeurs qui pourront y être ajoutées ou retirées. On note la valeur de l’accumulateur à un instant donné et la liste des valeurs accumulées dans l’accumulateur . 4.3 Initialisation de l’accumulateur Dans un mode de réalisation de la présente divulgation, le gestionnaire de l’accumulateur génère un certain nombre de valeurs aléatoires qui doivent rester secrètes. On note cette liste de valeurs secrètes et par la valeur initiale de l’accumulateur : . 4.4 Etat de l’accumulateur L’état de l’accumulateur à un instant donné est caractérisé par une paire ( , ) où ∈ est la valeur de l'accumulateur et où désigne l'ensemble des éléments accumulés dans , à l'exclusion des éléments d'initialisation : . 4. 5 Mise à jour de l’accumulateur Dans un mode de réalisation de la présente divulgation, pour ajouter un élément à l’accumulateur dans l’état courant ( ’, ), le gestionnaire de l’accumulateur effectue le calcul suivant : . Le nouvel état de l’accumulateur devient ( , ) où = . Dans un mode de réalisation de la présente divulgation, pour retirer un élément de l’accumulateur dans l’état courant ( , ), le gestionnaire de l’accumulateur effectue le calcul suivant : . Le nouvel état de l’accumulateur devient ( , ) où = . 4. 6 Calcul d’un témoin d’appartenance Soit ( , ) l’état courant de l’accumulateur et une valeur appartenant à et accumulée dans , on note le certificat ou témoin d’appartenance de à la liste et relatif à la valeur courante de l’accumulateur. Ce témoin d’appartenance peut être généré par le gestionnaire de l’accumulateur et utilisé par l’utilisateur pour prouver, en utilisant une preuve de connaissance à divulgation nulle de connaissance, que la valeur appartient bien à et est donc accumulée dans . Dans un mode de réalisation de la présente divulgation, le témoin de l’appartenance de à la liste est calculé de la manière suivante par le gestionnaire de l’accumulateur : . Dans un mode de réalisation de la divulgation, le gestionnaire de l’accumulateur génère une preuve à divulgation nulle de connaissance, notée prouvant la validité de ce témoin ou d’appartenance à l’accumulateur . On peut remarquer que . Désignons par = = . Le témoin d’appartenance est donc valide si le logarithme discret de dans la base est égal au logarithme discret de dans la base : =PoK . Comme seul le gestionnaire de l’accumulateur connaît , lui seul est en mesure de générer cette preuve. Dans un mode particulier de réalisation, le gestionnaire de l’accumulateur peut transmettre le témoin d’appartenance (ou ) et la preuve à un utilisateur qui pourra vérifier la validité de . Son témoin ne sera valide que si la preuve l’est également. 4. 7 Calcul d’un témoin de non appartenance Soit ( , ) l’état courant de l’accumulateur et une valeur n’appartenant pas à et donc non accumulée dans . Dans un mode de réalisation, on désigne par , le polynôme . On note . Si on désigne par le certificat ou témoin de non-appartenance de à la liste et relatif à la valeur courante de l’accumulateur. Ce témoin de non-appartenance peut être généré par le gestionnaire de l’accumulateur et utilisé par un utilisateur pour prouver en utilisant une preuve de connaissance à divulgation nulle de connaissance, que cette valeur n’appartient pas à et n’est donc pas accumulée dans . Dans un mode de réalisation de la présente divulgation, le témoin de la non-appartenance de à la liste est calculé de la manière suivante, par exemple par le gestionnaire de l’accumulateur : . Dans un mode de réalisation de la divulgation, le gestionnaire de l’accumulateur génère une preuve à divulgation nulle de connaissance, notée prouvant la validité de ce témoin de non-appartenance à l’accumulateur . On peut remarquer que . Désignons par = = . Le témoin sera donc valide si le logarithme discret de dans la base est égal au logarithme discret de dans la base : =PoK . Comme seul le gestionnaire de l’accumulateur connaît , lui seul est donc en mesure de générer cette preuve. Le gestionnaire de l’accumulateur peut transmettre le témoin (ou ) et ainsi que la preuve à l’utilisateur. Après réception de et de , l’utilisateur peut vérifier la validité de . Son témoin ne sera valide que si la preuve l’est également et que . Il est remarquable de noter que les preuves et peuvent être vérifiées par des dispositifs contraints tels que des éléments sécurisés, car elle n’implique que des opérations dans le groupe (qui sont supportées par ces dispositifs) contrairement aux preuves proposées par l’état de l’art qui nécessitent des calculs de couplages (en anglais pairings) non supportées par de tels dispositifs. 4. 8 Mise à jour d’un témoin d’appartenance ou de non appartenance Dans le mode de réalisation décrit ici, le témoin d’appartenance ou de non-appartenance d’un utilisateur doit être mis à jour à chaque modification de la liste. Le témoin peut être mis à jour par le gestionnaire de l’accumulateur ; l’utilisateur peut alors l’obtenir auprès du gestionnaire. En variante, l’utilisateur peut lui-même, c’est-à-dire sans faire appel au gestionnaire de l’accumulateur, mettre à jour son témoin d’appartenance (respectivement de non-appartenance) dans le cas où une nouvelle valeur serait ajoutée ou retirée de l’accumulateur. On supposera dans les paragraphes ci-dessous qu’un utilisateur a déjà reçu un témoin d’appartenance ou de non appartenance pour une valeur , et on note ( , ) l’état courant de cet accumulateur. 4.8.1 Mise à jour d’un témoin d’appartenance par ajout d’une valeur : On suppose qu’une valeur est ajouté à l’accumulateur qui passe donc de l’état ( , ) au nouvel état ( , ) où L’utilisateur peut mettre à jour son témoin d’appartenance en effectuant le calcul suivant : où désigne la valeur courante du témoin d’appartenance de l’utilisateur et la valeur de l’utilisateur. 4.8.2 Mise à jour d’un témoin d’appartenance par retrait d’une valeur : On suppose qu’une valeur est retirée de l’accumulateur qui passe donc de l’état ( , ) au nouvel état ( , ) où L’utilisateur peut mettre à jour son témoin d’appartenance en effectuant le calcul suivant : où désigne la valeur courante du témoin d’appartenance de l’utilisateur et la valeur pour laquelle cet accumulateur a été créé. 4.8.3 Mise à jour d’un témoin de non-appartenance par ajout d’une valeur : On suppose qu’une valeur est ajoutée à l’accumulateur qui passe donc de l’état ( , ) au nouvel état ( , ) où L’utilisateur peut mettre à jour son témoin d’appartenance en effectuant le calcul suivant : où désigne la valeur courante du témoin de non-appartenance de l’utilisateur et la valeur pour laquelle cet accumulateur a été créé et . 4.8.4 Mise à jour d’un témoin de non-appartenance par retrait d’une valeur : On suppose qu’une valeur est retirée de l’accumulateur qui passe donc de l’état ( , ) au nouvel état ( , ) où L’utilisateur peut mettre à jour son témoin d’appartenance en effectuant le calcul suivant : où désigne la valeur courante du témoin de non-appartenance de l’utilisateur et la valeur pour laquelle cet accumulateur a été créé et . Premier exemple de mise en œuvre de la divulgation Dans un premier exemple de mise en œuvre de la divulgation, on considère un fournisseur d’identité, un fournisseur de service et un utilisateur. Fournisseur d’identité Dans au moins un mode de réalisation, un fournisseur d’identité est une entité dont un rôle consiste à émettre des accréditations vérifiables anonymes (en anglais Verifiable Credential VC) aux utilisateurs, portant sur leurs éléments d’identité, après les avoir authentifiés. Ces derniers pourront les présenter à l’accès à un service soit pour prouver qui ils sont ou une ou plusieurs de leurs qualités. Dans un mode particulier de réalisation de cette divulgation, le fournisseur d’identité peut utiliser le protocole BBS+ pour certifier les attributs des utilisateurs. Dans un mode particulier de réalisation, le fournisseur d’identité gère également une liste compressée des accréditations vérifiables anonymes VC révoquées (ou une liste des accréditations non révoquées) au travers d’un accumulateur cryptographique. Dans un mode particulier de réalisation, le fournisseur d’identité peut fournir aux utilisateurs, consécutivement à la remise de leur accréditation anonyme vérifiable VC, leurs témoins d’appartenance (respectivement de non-appartenance) à la liste compressée des accréditations vérifiables valides (respectivement révoquées). Fournisseur de service Dans un mode de réalisation, un fournisseur de service délivre un service aux utilisateurs après s’être assuré que ces derniers remplissent effectivement les conditions d’accès à ce service. Par exemple, pour l’accès à un site de contenus pour adultes, le fournisseur de service a l’obligation légale de s’assurer que l’utilisateur est majeur. L’utilisateur doit donc fournir une preuve attestant de sa majorité au travers d’une présentation vérifiable (en anglais Verifiable Presentation VP) générée à partir d’une accréditation vérifiable anonyme, certifiant son âge, émise par un fournisseur d’identité en qui le fournisseur de service fait confiance. Dans un mode de réalisation de la présente divulgation, le fournisseur de services doit vérifier que la présentation vérifiable VP qui lui a été présentée a bien été générée à partir d’une accréditation vérifiable anonyme VC valide, c’est-à-dire non révoquée. Utilisateurs Dans un mode de réalisation de la présente divulgation, les utilisateurs disposent d’une ou plusieurs accréditations vérifiables anonymes et de leurs témoins d’appartenance (respectivement de non-appartenance) respectifs à la liste compressée des accréditations valides (respectivement à la liste compressée des accréditations révoquées), leur permettant de prouver leur identité ou qualités (majorité, séniorité, qualifications, etc.) auprès d’un fournisseur de service, afin d’accéder au service proposé par ce fournisseur. Dans un mode de réalisation, les utilisateurs disposent d’un portefeuille d’identité numérique (ID Wallet en anglais) leur permettant de stocker et gérer leurs différentes accréditations vérifiables anonymes et de générer les présentations vérifiables VP pour l’accès aux services des fournisseurs de services. Les clés privées et secrets des utilisateurs utilisés notamment par les utilisateurs pour prouver que les accréditations vérifiables anonymes VC qu’ils présentent leur appartiennent sont préférentiellement stockés dans des dispositifs sécurisés tels que des éléments sécurisés (en anglais Secure Element), des modules matériels de sécurité (en anglais Hardware Security Module HSM) ou dans des environnements d’exécution de confiance (Trusted execution environment TEE). 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 VC portant sur des attributs secrets et sur des attributs publics d’un utilisateur D-USR, en utilisant sa clé privée Dans cet exemple, lorsque le fournisseur d’identité produit une accréditation pour un utilisateur, il insère l’identifiant (par exemple un numéro de série) de cet accréditation parmi les attributs publics précités. Dans cet exemple, le fournisseur d’identité gère également une liste blanche comportant les identifiants des accréditations valides ou une liste noire comportant les identifiants des accréditations non valides ou révoquées. Il gère en outre un accumulateur cryptographique dans lequel les identifiants de la liste blanche ou de la liste noire sont accumulés. Le fournisseur d’identité fournit à l’utilisateur son accréditation anonyme , un témoin de l’appartenance de l’identifiant de son accréditation à la liste blanche ou un témoin de la non-appartenance de cet identifiant à la liste noire et une preuve associée à ce témoin. 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 d’intérêt demandés par le fournisseur de service D-FS. Dans le mode de réalisation décrit ici, l’utilisateur envoie également au fournisseur de service une preuve de non-révocation de l’identifiant de son accréditation. Dans cet exemple, le fournisseur de service vérifie la preuve de non-révocation de l’identifiant de l’accréditation de l’utilisateur, signe la présentation vérifiable VP avec une clé privée de groupe et valide l’accréditation de la présentation vérifiable VP en utilisant la clé publique du fournisseur d’identité. 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 audit service. La FIG. 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. La FIG. 2 représente les principales étapes d’un procédé de gestion d’au moins une accréditation vérifiable anonyme, les principales étapes d’un procédé de demande d’accès à un service et les principales étapes d’un procédé de contrôle d’accès à ce service. Dans le mode de réalisation décrit ici, au cours d’une étape non représentée, le fournisseur d’identité D-FI définit les paramètres publics d’un système de signature de type BBS+. Dans le mode de réalisation décrit ici : où désigne un environnement bilinéaire, pour lequel nous ferons l’hypothèse que le problème q-SDH est difficile. est un nombre premier qui désigne l’ordre des groupes cycliques , et le nombre d’attributs à certifier. Dans un mode particulier de réalisation, les attributs sont des attributs régaliens et est un numéro de série de l’accréditation anonyme VC. désignent +3 générateurs de choisis aléatoirement (de telle sorte que personne ne connaisse le logarithme discret d’un de ces générateurs par rapport à un autre de ces générateurs). Chaque est associé à un type d’attribut spécifique (par exemple sera associé à l’attribut « nom », à l’attribut « prénom », à l’attribut « âge », à l’attribut « genre », etc.). Cela nous permettra de différencier les attributs et d’éviter toute ambiguïté. correspondent aux générateurs publics de l’accumulateur géré par le fournisseur d’identité D-FI désignent générateurs additionnels de choisis aléatoirement (de telle sorte que personne ne connaisse le logarithme discret d’un de ces générateurs par rapport à un autre de ces générateurs). Chaque sera associé à un attribut secret (additionnel à ) de l’utilisateur. Le nombre exact d’attributs secrets additionnels dépend du cas d’usage. désigne un générateur de . Dans la suite, tous les calculs portant sur les exposants seront effectués modulo (mod ). Nous désignerons par où désignera une fonction de hachage cryptographiquement sûre (par exemple SHA-256). Générations des clés : Dans le mode de réalisation décrit ici, le fournisseur d’identité D-FI génère aléatoirement un entier appartenant à {1, 2,…, } et calcule . Sa clé privée sera et sa clé publique. Dans le mode de réalisation décrit ici, le fournisseur d’identité FI fait également office de gestionnaire d’un accumulateur cryptographique et génère les paramètres publics de cet accumulateur dont le rôle sera d’accumuler des identifiants des accréditations vérifiables anonymes révoquées dans le cas de la gestion d’une liste noire, ou de numéros de série valides s’il s’agit d’une liste blanche. Pour ce faire, il génère aléatoirement un entier appartenant à {1, 2,…, p} et calcule ainsi que . Nous supposerons également que chaque utilisateur U dispose également d’une paire de clés, privée et publique ( , ) certifiée par une autorité de certification. Le dispositif D-USR de l’utilisateur connaît les paramètres publics du système BBS+ et la clé publique du fournisseur d’identité D-FI 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 ici, le dispositif D-USR comporte un module de communication COM3. Ce module peut être utilisé pour envoyer un engagement portant sur des attributs secrets de l’utilisateur au dispositif D-FI et recevoir une accréditation vérifiable anonyme portant sur ces attributs et sur des attributs publics de l’utilisateur. 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. Le module cryptographique WAL peut notamment également stocker un témoin de l’appartenance de l’identifiant de cette accréditation à une liste blanche d’identifiants valides ou un témoin de la non-appartenance de cet identifiant à une liste noire d’identifiants non valides. La module cryptographique WAL est par exemple configuré pour obtenir une preuve de non révocation de cet identifiant . Dans le mode de réalisation décrit ici, le module de communication COM3 du dispositif D-USR peut être utilisé pour envoyer cette preuve à un fournisseur de service D-FS. Dans le mode de réalisation décrit ici, le dispositif D-USR comporte un module MUT configuré pour utiliser au moins un des attributs certifiés de l’utilisateur pour accéder à un service du fournisseur de service D-FS. Dans le mode de réalisation décrit ici, le dispositif D-FI de gestion d’accréditations anonyme comporte un module de communication COM1. Ce module peut notamment être utilisé par le dispositif D-FI pour obtenir l’engagement sur les attributs secrets de l’utilisateur, lui envoyer une accréditation VC, 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’accréditations 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. Le module cryptographique M-CRY1 peut aussi être configuré pour gérer une liste blanche ou noire d’identifiants d’accréditations et pour calculer un témoin de l’appartenance de l’identifiant d’une accréditation à une liste blanche d’identifiants valides ou un témoin de la non-appartenance de cet identifiant à une liste noire d’identifiants non valides. 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 VP comportant une accréditation vérifiable anonyme portant sur des attributs d’un utilisateur, une preuve de non révocation d’un identifiant 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 vérifier la validité de la preuve , et pour signer la présentation vérifiable VP avec une clé privée de groupe. Le module COM2 du dispositif D-FS peut être utilisé pour envoyer à un dispositif de gestion d’accréditations une demande de vérification d’une accréditation vérifiable anonyme La FIG. 2 représente 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 un utilisateur USR et les principales étapes d’un procédé de contrôle d’accès mis en œuvre par un fournisseur de service FS. Dans cet exemple, on suppose que l’utilisateur USR dispose de attributs secrets . Dans cet exemple, l’utilisateur USR utilise un dispositif D-USR pour demander au dispositif D-FI d’un fournisseur d’identité FI de lui fournir une accréditation vérifiable anonyme portant sur les attributs secrets et sur attributs publics . Dans l’exemple décrit ici, les attributs publics comprennent attributs régaliens et un attribut correspondant à un identifiant, par exemple un numéro de série, de l’accréditation anonyme vérifiable . Dans le mode de réalisation décrit ici, le fournisseur de service FI gère un accumulateur cryptographique. Il met à cet effet en œuvre les procédures présentées précédemment dans la section « 4. Accumulateur cryptographique ». On note la liste des éléments accumulés dans cet accumulateur cryptographique et la valeur courante de cet accumulateur 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 l’ensemble de ses valeur secrètes et une preuve qu’il sait ouvrir cet engagement. , où Dans le mode de réalisation dans lequel l’utilisateur souhaiterait que l’accréditation anonyme vérifiable ne porte que sur 1 attribut secret, on aurait : 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 sa clé publique , l’engagement et la preuve . Le fournisseur de service FI vérifie la validité de la preuve au cours d’une étape U7. Dans le mode de réalisation décrit ici, si la preuve n’est pas valide, le procédé d’émission d’une accréditation anonyme vérifiable s’arrête. Au cours d’une étape I8, le fournisseur de service FI détermine un identifiant de l’accréditation vérifiable anonyme qu’il va générer pour l’utilisateur USR. Au cours d’une étape I10, le fournisseur de service met à jour l’accumulateur cryptographique. Cette opération comporte notamment la mise à jour la liste des éléments accumulés soit l’ajout de l’identifiant (noté parfois dans le document) à la liste si cette liste est une liste blanche comportant des identifiants valides, soit le retrait de l’identifiant de cette liste si cette liste est une liste noire comportant des identifiants non valides. Cette opération comporte également la mise à jour de la valeur de l’accumulateur. Un exemple de mise en œuvre de ces opérations a été présenté au chapitre « 4. 5 Mise à jour de l’accumulateur ». Au cours d’une étape I12, le fournisseur de service calcule un témoin qui représente : (i) le fait que l’identifiant de l’accréditation anonyme vérifiable appartient à la liste des éléments accumulés si cette liste est une liste blanche. Dans ce cas, le témoin peut-être calculé par la formule présentée à la section « 4. 6 Calcul d’un témoin d’appartenance » ; ou (ii) le fait que l’identifiant de l’accréditation anonyme vérifiable n’appartient pas à la liste des éléments accumulés si cette liste est une liste noire. Dans ce cas, le témoin peut-être calculé par la formule présentée à la section « 4. 7 Calcul d’un témoin de non appartenance ». Au cours de cette même étape I12, le fournisseur de service calcule une preuve associée au témoin . Dans le mode de réalisation décrit ici, et comme décrit précédemment aux sections « 4. 6 Calcul d’un témoin d’appartenance » et « 4. 7 Calcul d’un témoin de non appartenance » : (i) lorsque le témoin est un témoin d’appartenance de l’identifiant à une liste blanche de la forme , la preuve associée à ce témoin peut être : =PoK et (ii) lorsque le témoin est un témoin de non appartenance de l’identifiant à une liste noire, de la forme , la preuve associée à ce témoin peut être : est =PoK . Dans le mode de réalisation décrit ici, le fournisseur d’identité FI génère l’accréditation vérifiable anonyme au cours d’une étape I14. Dans le mode de réalisation décrit ici, cette accréditation vérifiable anonyme porte sur l’engagement calculé à partir des attributs secrets de l’utilisateur et sur attributs publics comportant attributs régaliens et l’identifiant (ou ) de l’accréditation vérifiable anonyme Dans le mode de réalisation décrit ici, cette signature est une signature aveugle calculée en utilisant une clé privée de l’entité FI de gestion de droits. 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, cette signature est calculée en utilisant le protocole BBS+. Pour plus de renseignements sur ce standard, l’homme du métier peut se reporter au standard lui-même (https://identity.foundation/bbs-signature/draft-irtf-cfrg-bbs-signatures.html) ou au document « Barki, A., Brunet, S., Desmoulins, N., and J. Traore, "Improved Algebraic MACs and Practical Keyed-Verification Anonymous Credentials", In International Conference on Selected Areas in Cryptography, 1016, . Dans le mode de réalisation décrit ici, l’accréditation vérifiable anonyme est un couple calculé selon le protocole BBS+ défini par des paramètres publics avec où : - désigne un environnement bilinéaire pour lequel le problème q-SDH est difficile ;= - p est un entier premier qui désigne l’ordre des groupes cycliques , et - désignent n+3 générateurs de choisis aléatoirement, chaque étant associé à un type d’attribut spécifique ; - sont les générateurs publics dudit accumulateur ; - désigne un générateur de , et dans lequel : (EQ), où , ,…, sont des valeurs aléatoires choisies par ladite entité de gestion de droits. Dans le mode de réalisation dans lequel l’utilisateur souhaiterait que l’accréditation anonyme vérifiable ne porte que sur 1 attribut secret, on aurait : , où et représente la valeur mise en gage dans Com. Dans le mode de réalisation décrit ici, au cours d’une étape I16, le fournisseur d’identité FI calcule une preuve de la validité de l’accréditation vérifiable anonyme . L’homme du métier comprend en effet que implique que : (i) où et que (ii) En notant le fournisseur d’identité peut calculer une preuve à divulgation de connaissance, par exemple à la Schnorr démontrant que a bien été calculé correctement, en d’autres termes que le logarithme discret de dans la base est égal au logarithme discret de dans la base . Pour plus de renseignements sue les preuves à la Schnorr, l’homme du métier peut se reporter au document Claus-Peter Schnorr: Efficient Identification and Signatures for Smart Cards. CRYPTO 1989: 239-252. Au cours d’une étape I18, le fournisseur d’identité FI envoi à l’utilisateur : (i) l’accréditation vérifiable anonyme (ii) la preuve de la validité de cette accréditation ; (iii) l’identifiant de cette accréditation vérifiable anonyme ; (iv) le témoin d’appartenance ou de non appartenance de cet identifiant à une liste et la preuve associée à ce témoin. Dans le mode de réalisation décrit ici, le fournisseur d’identité envoie également, dans le même message, les valeurs aléatoires , ,…, . Ces éléments sont reçus par le l’utilisateur USR au cours de la même étape. Au cours d’une étape U20, le dispositif D-USR de l’utilisateur : - calcule et et - désaveugle l’accréditation vérifiable anonyme et obtient une l’accréditation vérifiable anonyme également notée pour plus de simplicité. Au cours d’une étape U22, il vérifie la validité de la signature en vérifiant la preuve et la preuve associée au témoin d’appartenance (preuve ) ou au témoin de non appartenance (preuve ). Cette signature désaveuglée du message constituée de l’engagement sur les attributs secrets ( , des attributs publics de cet utilisateur et de l’identifiant = de l’accréditation vérifiable anonyme peut être vérifiée soit via une ZKP générée par le fournisseur d’identité FI soit plus directement en utilisant sa clé publique. Dans le mode décrit ici, elle est stockée dans le portefeuille WAL. Nous allons maintenant décrire les principale étapes mises en œuvre par les différents intervenants (utilisateur, fournisseur de service, fournisseur d’identité) lorsque l’utilisateur USR souhaite accéder à un service proposé par le fournisseur de service FS. Au cours d’une étape U22, l’utilisateur USR se connecte de façon anonyme auprès du fournisseur de service FS. Dans l’exemple de réalisation décrit ici, nous supposerons que le fournisseur de service FS demande, au cours d’une étape S24 des attributs à l’utilisateur USR (appelés attributs d’intérêt) qu’il souhaite vérifier avant de permettre à l’utilisateur USR d’accéder à 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. Nous désignerons par , la liste des indices des attributs d’intérêt réclamés par le fournisseur de service FS et dans cet exemple . Au cours d’une étape U26, l’utilisateur USR sélectionne parmi les accréditations vérifiables anonymes reçues du fournisseur d’identité FI, une ou plusieurs accréditations vérifiables anonymes d’intérêt portant les attributs d’intérêts du fournisseur de service FS. Par souci de simplification, nous considérons qu’une seule accréditation porte sur l’ensemble des attributs d’intérêt. Dans le mode de réalisation décrit ici, l’utilisateur USR génère une présentation vérifiable VP (en anglais « verifiable presentation ») à partir de cette accréditation d’intérêt . Dans le mode de réalisation décrit ici, l’utilisateur USR 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 : où ( désigne une mise en gage sur l’attribut . Dans le mode de réalisation décrit ici, 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 d’intérêt produite à l’étape I14. Dans le mode de réalisation décrit ici, on ne souhaite pas que le fournisseur d’identité FI puisse faire le rapprochement avec l’utilisateur USR qui lui a communiqué ses attributs secrets (étape U6) pour le calcul de cette accréditation, l’utilisateur USR calcule une accréditation vérifiable anonyme rafraichie à partir de l’accréditation d’intérêt . Cette nouvelle accréditation vérifiable rafraîchie porte toujours sur les attributs secrets , les attributs publics de cet utilisateur et sur l’identifiant de l’accréditation d’intérêt 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 I14. Dans le mode de réalisation décrit ici, 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 l’accréditation vérifiable rafraîchie . 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 : , , ). Comme mentionné précédemment, dans le mode de réalisation décrit ici, le fournisseur de service FS a besoin de vérifier les attributs publics d’intérêt 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 calcule une preuve de non révocation de l’identifiant de l’accréditation vérifiable anonyme d’intérêt . Dans le mode de réalisation décrit ici, cette preuve est constituée par : - une preuve que l’identifiant appartient à la liste blanche d’identifiants valides ou par - une preuve que cet identifiant n’appartient pas à la liste noire d’identifiants non valides. Exemple de génération de la preuve Cette preuve permet à l’utilisateur USR de prouver que l’identifiant est valide. On rappelle que dans le cas d’une liste blanche, le témoin d’appartenance à la liste des identifiants valides est du type , et on note ( , ) l’état courant de l’accumulateur. Dans le mode de réalisation décrit ici, l’utilisateur calcule dans un premier temps un rafraîchi de son témoin d’appartenance . Pour ce faire, il choisit et calcule . Posons On a = et donc = . Ce qui implique que = Posons = et = On a donc . L’utilisateur USR génère ensuite une preuve à divulgation nulle de connaissance: = . Dans ce mode particulier de réalisation, l'utilisateur USR prouve également dans sa présentation vérifiable que l’identifiant utilisé pour la preuve de non-revocation est bien le même que celui normalement présent dans son accréditation anonyme . Par exemple, l’utilisateur USR génère une preuve_ZK que l’identifiant dans la représentation de Â dans les bases V et est le même que celui de la mise en gage . Pour cette preuve ZK, l’homme du métier peut se reporter au document David Chaum, Torben P. Pedersen: Wallet Databases with Observers. CRYPTO 1992: 89-105. Nous supposerons implicitement que cette preuve est intégrée dans la preuve décrite plus haut. Dans le mode de réalisation décrit ici, la preuve finale est constituée des données suivantes : , . Exemple de génération de la preuve Cette preuve permet à l’utilisateur USR de prouver que l’identifiant de son accréditation anonyme vérifiable n’est pas révoqué.. On rappelle que dans le cas d’une liste noire , le témoin de non appartenance à la liste identifiants non valides est du type , et on note ( , ) l’état courant de l’accumulateur. Dans le mode de réalisation décrit ici, l’utilisateur calcule dans un premier temps un rafraîchi de son témoin de non-appartenance . Pour ce faire, il choisit et calcule . Posons On a = avec et donc = . Ce qui implique que = Posons = et = et On a donc . L’utilisateur USR génère ensuite une preuve à divulgation nulle de connaissance: = . Dans ce mode particulier de réalisation, l'utilisateur USR prouve également dans sa présentation vérifiable que l’identifiant utilisé pour la preuve de non-revocation est bien le même que celui normalement présent dans son accréditation anonyme . Par exemple, l’utilisateur USR génère une preuve_ZK que l’identifiant dans la représentation de Â dans les bases V et est le même que celui de la mise en gage . Pour cette preuve ZK, l’homme du métier peut se reporter au document David Chaum, Torben P. Pedersen: Wallet Databases with Observers. CRYPTO 1992: 89-105. Nous supposerons implicitement que cette preuve est intégrée dans la preuve décrite plus haut. Dans le mode de réalisation décrit ici, la preuve finale est constituée des données suivantes : , . Au cours d’une étape U32, l’utilisateur envoie au fournisseur de service FS : (i) la présentation vérifiable VP comportant l’accréditation vérifiable anonyme rafraîchie obtenue à partir de l’accréditation vérifiable anonyme d’intérêt (ii) la preuve de non révocation de l’identifiant de l’accréditation vérifiable anonyme d’intérêt constituée par la preuve que l’identifiant appartient à la liste blanche des identifiants valides ou par la preuve que cet identifiant n’appartient pas à la liste noire des identifiants non valides (révoqués). Dans le mode de réalisation décrit ici, l’utilisateur envoie également les données d’ouverture au fournisseur de service FS. Au cours d’une étape S34, le fournisseur de service FS vérifie que les données d’ouverture permettent effectivement de révéler les attributs d’intérêt de l’utilisateur et que ces attributs 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 S40. 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, 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. 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 d’une étape S36, le fournisseur de service vérifie la preuve de non révocation, c’est-à-dire la validité de ou de Pour vérifier la validité de , le fournisseur de service devra d’une part s’assurer que l’égalité suivante est satisfaite et d’autre part que est valide. Pour vérifier la validité de , le fournisseur de service devra d’une part s’assurer que l’égalité suivante est satisfaite et d’autre part que est valide. L’algorithme de vérification des preuves et étant relativement classique pour l’homme de l’art, ils ne seront pas décrits ici. Dans le mode de réalisation décrit ici, avant de permettre l’accès au service à l’utilisateur USR, le fournisseur de service FS doit s’assurer que les attributs d’intérêt de l’utilisateur ont bien été certifiés. Dans le mode de réalisation décrit ici, le fournisseur de service FS vérifie la validité de ces attributs en utilisant clé publique d fournisseur d’identité FI. Dans le mode de réalisation décrit ici, le fournisseur de service FS offre son service à l’utilisateur, seulement si : - les attributs d’intérêt de l’utilisateur ; - la preuve de la validité de l’accréditation ; - la preuve de la non-révocation de l’identifiant de cette accréditation ont été obtenues. 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 FIG. 3 . 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 la divulgation. Elle comporte un programme d’ordinateur PG-X conforme à la divulgation. 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 à la FIG. 2 . Le programme PG-USR définit notamment le modules M-AUTH d’authentification, le module cryptographique WAL et le module 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 à la FIG. 2 . 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 à la FIG. 2 . Le programme PG-FS définit notamment le module cryptographique M-CRY2 et le module COM2 de communication du dispositif D-FS. Autre exemple de mise en œuvre de la divulgation Dans le premier exemple détaillé ci-dessus, les attributs publics certifiés de l’utilisateur sont utilisés pour accéder à un service. La présente divulgation ne se limite pas à ce mode de réalisation de la divulgation. Par exemple, le dispositif de gestion d’accréditations peut générer une accréditation comportant : - un attribut nécessaire pour exercer un droit (code d’accès pour un droit d’accès, numéro de carte bancaire pour un droit de paiement, …) ; et - un identifiant de cette accréditation . Le dispositif de gestion d’accréditations peut gérer une liste blanche d’identifiants d’accréditations valides ou une liste noire d’identifiants d’accréditations révoquées (non valides) et calculer un témoin d’appartenance ou de non-appartenance d’un identifiant d’accréditation à une telle liste. Le dispositif de gestion d’accréditations peut ainsi fournir à un utilisateur une accréditation portant notamment sur un attribut nécessaire à l’exercice d’un droit et le témoin d’appartenance ou de non-appartenance de l’identifiant de cette accréditation à une liste blanche d’identifiants valides ou noire d’identifiants révoqués. Le dispositif de l’utilisateur peut être configuré pour obtenir une preuve de non-révocation de cet identifiant et pour fournir cette preuve, en plus de l’accréditation portant sur l’attribut nécessaire à l’exercice du droit à une entité auprès de laquelle l’utilisateur souhaite exercer son droit (marchand pour un paiement avec le numéro de carte bancaire, portail d’accès pour un droit d’accès avec le code d’accès …). Procédé de gestion d’au moins une accréditation vérifiable anonyme , le procédé étant mis en œuvre par un dispositif (D-FI) de gestion d’accréditations et comportant les étapes suivantes : - génération (I14) d’une accréditation vérifiable anonyme portant sur une pluralité d’attributs dont l’un est un identifiant de cette accréditation ; - mise à jour (I10) d’une liste d’identifiants d’accréditation accumulés dans un accumulateur cryptographique par ajout ou retrait dudit identifiant ( ) et de la valeur de l’accumulateur, ladite liste étant : (i) soit une liste blanche comportant des identifiants valides ; (ii) soit une liste noire comportant des identifiants non valides ; - calcul (I12) d’un témoin représentatif de : (i) l’appartenance dudit identifiant à une liste blanche ; ou (ii) de la non-appartenance dudit identifiant à une liste noire et (iii) d’une preuve associée audit témoin ; - envoi (I18) à un utilisateur : (i) de ladite accréditation vérifiable anonyme (ii) d’une preuve de la validité de ladite accréditation vérifiable anonyme ; (iii) dudit identifiant de ladite accréditation vérifiable anonyme ; (iv) dudit témoin et de la preuve associée audit témoin. Procédé de gestion d’au moins une accréditation vérifiable anonyme , selon la revendication 1 dans lequel un desdits attributs est un engagement portant sur un attribut secret de l’utilisateur. Procédé de gestion d’au moins une accréditation vérifiable anonyme selon la revendication 1 ou 2 dans lequel : (i) lorsque ladite liste est une liste blanche : - la valeur de l’accumulateur après mise à jour est calculée par ; - le témoin d’appartenance dudit identifiant à ladite liste blanche est calculé par , - la preuve associée à ce témoin est =PoK et (ii) lorsque ladite liste est une liste noire: - la valeur de l’accumulateur après mise à jour est calculée par ; - le témoin de non-appartenance dudit identifiant à ladite liste noire est calculé par , - la preuve associée à ce témoin est =PoK où : - sont des générateurs publics dudit accumulateur ; - est un entier appartenant à {1, 2,…, p-1}, la clé privée du dispositif (D-FI) de gestion d’accréditations (D-FI) pour la gestion de l’accumulateur est égale à - , - la clé publique pour la gestion de l’accumulateur est = ( , ) - = = - est la valeur de l’accumulateur avant ladite mise à jour ; - où est un polynôme défini par , étant une liste de valeurs secrètes utilisée pour initialiser l’accumulateur - est une valeur initiale de l’accumulateur : Procédé mis en œuvre par un dispositif d’un utilisateur (D-USR), ce procédé comportant les étapes suivantes : - réception (I18) , en provenance d’un dispositif (D-FI) de gestion d’accréditations : (i) d’au moins une accréditation vérifiable anonyme portant sur une pluralité d’attributs dont l’un est un identifiant de cette accréditation ; (ii) d’une preuve de la validité de ladite accréditation vérifiable anonyme ; (iii) de l’identifiant de ladite accréditation vérifiable anonyme ; (iv) d’un témoin de l’appartenance dudit identifiant à une liste blanche d’identifiants valides ou de la non-appartenance dudit identifiant à une liste noire d’identifiants non valides, ladite liste blanche ou noire étant une liste d’éléments accumulés dans un accumulateur cryptographique ; (v) d’une preuve associée audit témoin ; - obtention (U30) d’une preuve de non révocation de l’identifiant de ladite accréditation vérifiable anonyme d’intérêt constituée par : (i) une preuve que ledit identifiant de ladite accréditation vérifiable anonyme d’intérêt appartient à ladite liste blanche ou par (ii) une preuve que ledit identifiant de ladite accréditation vérifiable anonyme d’intérêt n’appartient pas à ladite liste noire ; - utilisation d’au moins un desdits attributs pour exercer un droit de l’utilisateur (USR) au moins sous condition de l’obtention d’une preuve de la validité de ladite accréditation et de la non-révocation dudit identifiant . Procédé selon la revendication 4 pour demander l’accès à un service dans lequel ladite au moins une accréditation vérifiable anonyme porte sur une pluralité d’attributs ( de l’utilisateur (USR), ledit procédé comportant en outre les étapes suivantes; - sélection (U26) parmi ladite au moins une accréditation vérifiables anonyme d’une accréditation vérifiable anonyme d’intérêt portant sur au moins un attribut d’intérêt pour un fournisseur dudit service ; - envoi (U32), audit fournisseur de service (FS) : (i) d’une présentation vérifiable (VP) comportant au moins une accréditation rafraîchie obtenue à partir de ladite accréditation vérifiable anonyme d’intérêt permettant au fournisseur de service d’obtenir ledit au moins un attribut d’intérêt (ii) ladite preuve de non révocation de l’identifiant de ladite accréditation vérifiable anonyme d’intérêt . Procédé de demande d’accès à un service selon la revendication 5 dans lequel : (i) la preuve que ledit identifiant de ladite accréditation vérifiable anonyme d’intérêt appartient à ladite liste blanche est du type , , avec : où = = (ii) la preuve que ledit identifiant de ladite accréditation vérifiable anonyme d’intérêt n’appartient à ladite liste noire est du type , , avec : où = où : - sont des générateurs publics dudit accumulateur ; - est un entier appartenant à {1, 2,…, p-1}, la clé privée du dispositif (D-FI) de gestion d’accréditations pour la gestion de l’accumulateur étant égale à - , - la clé publique pour la gestion de l’accumulateur est = ( , ) - = = - est la valeur de l’accumulateur avant ladite mise à jour ; - où est un polynôme défini par , étant une liste de valeurs secrètes utilisée pour initialiser l’accumulateur - est une valeur initiale de l’accumulateur : Procédé de contrôle d’accès à un service par un utilisateur (USR), ledit procédé étant mis en œuvre par un fournisseur de service (D-FS) et comportant les étapes suivantes : - obtention (U32) d’une présentation vérifiable (VP) comportant une accréditation vérifiable anonyme d’intérêt portant sur des attributs d’intérêt de l’utilisateur et d’une preuve de non révocation d’un identifiant de ladite accréditation vérifiable anonyme d’intérêt ; - vérification (S34) dudit au moins un attribut d’intérêt ; - vérification (S36) de la validité de ladite preuve de non révocation ; - envoi (S38) à un dispositif de gestion d’accréditations (D-FI) d’une demande de vérification de ladite accréditation vérifiable anonyme d’intérêt comprise dans ladite présentation vérifiable (VP), - un résultat positif d’une vérification (S40) dudit au moins un attribut et l’obtention d’une preuve de la validité de ladite accréditation et de la non-révocation dudit identifiant étant des conditions nécessaires pour autoriser (S58) l’accès de l’utilisateur (USR) audit service. Procédé selon l’une quelconque des revendications 1 à 7 dans lequel ladite accréditation vérifiable anonyme est une signature aveugle calculée en utilisant une clé privée dudit dispositif (D-FI) de gestion d’accréditations. Procédé selon la revendication 8 dans lequel ladite accréditation vérifiable anonyme est un couple calculé selon le protocole BBS+ défini par des paramètres publics avec où : - désigne un environnement bilinéaire pour lequel le problème q SDH est difficile ; - p est un entier premier qui désigne l’ordre des groupes cycliques , et - désignent n+3 générateurs de choisis aléatoirement, chaque étant associé à un type d’attribut spécifique ; - sont les générateurs publics dudit accumulateur ; - désigne un générateur de , et dans lequel : , où , ,…, sont des valeurs aléatoires choisies par ledit dispositif (D-FI) de gestion d’accréditations. Dispositif (D-FI) de gestion d’accréditations comportant: - un module (M-CRY1) de génération (I14) d’une accréditation vérifiable anonyme portant sur une pluralité d’attributs dont l’un est un identifiant de cette accréditation ; - un module (M-CRY1) de mise à jour (I10) d’une liste d’identifiants d’accréditation accumulés dans un accumulateur cryptographique par ajout ou retrait dudit identifiant et de la valeur de l’accumulateur, ladite liste étant: (i) soit une liste blanche comportant des identifiants valides ; (ii) soit une liste noire comportant des identifiants non valides ; - un module (M-CRY1) de calcul (I12) d’un témoin représentatif de : (i) l’appartenance dudit identifiant à une liste blanche ; ou (ii) de la non-appartenance dudit identifiant à une liste noire et (iii) d’une preuve associée audit témoin ; - un module (COM1) d’envoi (I18) à un utilisateur : (i) de ladite accréditation vérifiable anonyme (ii) d’une preuve de la validité de ladite accréditation vérifiable anonyme ; (iii) dudit identifiant de ladite accréditation vérifiable anonyme ; (iv) dudit témoin et de la preuve associée audit témoin. Dispositif (D-USR) comportant : - un module (COM3) de réception (I18) , en provenance d’un dispositif (D-FI) de gestion d’accréditations : (i) d’au moins une accréditation vérifiable anonyme portant sur une pluralité d’attributs dont l’un est un identifiant de cette accréditation ; (ii) d’une preuve de la validité de ladite accréditation vérifiable anonyme ; (iii) de l’identifiant de ladite accréditation vérifiable anonyme ; (iv) d’un témoin de l’appartenance dudit identifiant à une liste blanche d’identifiants valides ou de la non-appartenance dudit identifiant à une liste noire d’identifiants non valides, ladite liste blanche ou noire étant une liste d’éléments accumulés dans un accumulateur cryptographique ; (v) d’une preuve associée audit témoin ; - un module (WAL) d’obtention (U30) d’une preuve de non révocation de l’identifiant de ladite accréditation vérifiable anonyme d’intérêt constituée par : (i) une preuve que ledit identifiant de ladite accréditation vérifiable anonyme d’intérêt appartient à ladite liste blanche ou par (ii) une preuve que ledit identifiant de ladite accréditation vérifiable anonyme d’intérêt n’appartient pas à ladite liste noire ; - un module (MUT) d’utilisation d’au moins un desdits attributs pour exercer un droit de l’utilisateur (USR) au moins sous condition de l’obtention d’une preuve de la validité de ladite accréditation et de la non-révocation dudit identifiant . Dispositif (D-FS) de contrôle d’accès à un service par un utilisateur (USR), ledit dispositif comportant: - un module (COM2) d’obtention d’une présentation vérifiable (VP) comportant une accréditation vérifiable anonyme d’intérêt portant sur des attributs d’intérêt de l’utilisateur et d’une preuve de non révocation d’un identifiant de ladite accréditation vérifiable anonyme d’intérêt ; - un module (M-CRY2) de vérification (S34) dudit au moins un attribut d’intérêt ; - un module (M-CRY2) de vérification (S36) de la validité de ladite preuve de non révocation ; - un module (COM2) d’envoi (S38) à un dispositif de gestion d’accréditations (D-FI) d’une demande de vérification de ladite accréditation vérifiable anonyme d’intérêt comprise dans ladite présentation vérifiable (VP), - un résultat positif d’une vérification (S40) dudit au moins un attribut et l’obtention d’une preuve de la validité de ladite accréditation et de la non-révocation dudit identifiant étant des conditions nécessaires pour autoriser (S58) l’accès de l’utilisateur (USR) audit service. 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é selon l’une quelconque des revendications 1 à 9. Support d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur (PG-USR, PG-FS, PG-FI) selon la revendication 13.