Récemment, nous avons obtenu que l’article ‘Fondations des signatures anonymes : Formal Definitions, Simplified Requirements, and a Construction Based on General Assumptions’ accepté dans FC’24 - l’édition 2024 de la conférence sur la cryptographie financière. Cet article présente les signatures anonymes universelles (UAS).
Nous sommes très enthousiastes à ce sujet car, en plus de faire le lien entre plusieurs sous-domaines dans le domaine de l’authentification anonyme, l’UAS ouvre la voie à ce que nous pensons être (une partie de) l’avenir de Identité auto-souveraine et quelque chose que nous pousserons certainement à intégrer dans le Atala offre.
Mais cette introduction est suffisante. De quoi s’agit-il ?
Un peu d’histoire
En 1985, David Chaum a pensé pour la première fois à un justificatif cryptographique que les gens pourraient utiliser sans divulguer leur identité, tout en donnant aux fournisseurs de services l’assurance qu’ils parlent à une personne légitime. De nombreuses variantes ont été proposées, généralement en s’appuyant sur le concept d’attributs attestés, que les détenteurs de titres peuvent choisir de révéler ou non. C’est ce que l’on appelle les systèmes de certificats anonymes (AC).
En 1991, Chaum et van Heyst ont proposé des signatures de groupe (GS), qui permettent aux membres d’un groupe détenant un certificat d’adhésion de faire quelque chose de similaire aux CA. Ces certificats d’appartenance n’ont généralement pas d’attributs, mais les signatures produites par les schémas GS peuvent être traitées par une entité de confiance, qui peut extraire l’identifiant du signataire, par ailleurs anonyme.
Les systèmes AC et GS reposent tous deux sur des autorités qui délivrent les références nécessaires à l’authentification ou à la signature. Cette entité a été supprimée en 2001, lorsque Rivest, Shamir et Tauman ont imaginé les systèmes de signature en anneau (RS), qui peuvent être considérés comme une sorte de signature de groupe qui ne peut pas être désanonymisée et qui ne nécessite pas d’émetteurs.
Ainsi, en à peine 16 ans, la communauté cryptographique s’est retrouvée avec trois méthodes différentes mais similaires pour permettre aux utilisateurs de s’authentifier de manière anonyme. Depuis 2001, de nombreuses autres variantes ont été proposées, trouvant parfois des points intermédiaires. Il s’agit notamment des systèmes RS qui permettent de lier des signatures, ou des signatures de groupe dans lesquelles seuls les utilisateurs peuvent lier leurs propres signatures).
Quelle est la solution apportée par la SAU ?
En fait, les schémas AC, GS et RS (et leurs nombreuses variantes) n’ont pas seulement des points communs. Leurs raisons d’être sont étroitement liées. Permettre aux utilisateurs de s’authentifier de manière anonyme, tout en laissant aux fournisseurs de services un certain contrôle sur les informations qu’ils peuvent extraire. D’un point de vue théorique, cela se traduit par le fait que les modèles de sécurité se ressemblent beaucoup. Par exemple, il faut toujours penser aux propriétés d’anonymat, qui capturent ce qui peut être appris à partir d’une signature. Et aux propriétés d’infalsifiabilité, qui ont des variantes de traçabilité et de non-fraçabilité, indiquant précisément quel type d’assurance d’infalsifiabilité les vérificateurs (fournisseurs de services) et les utilisateurs peuvent attendre, respectivement. Il existe également des moyens de construire ces systèmes à partir d’éléments de base très similaires.
Cependant, pour une raison quelconque, jusqu’à présent, AC, GS, RS et d’autres ont été étudiés indépendamment. En outre, même si dans une branche concrète, comme la GS, il existe des modèles de sécurité de référence comme la ligne de travail “Foundations of Group Signatures”, ce n’est pas toujours le cas. Même s’il existe des modèles de référence, ces modèles de sécurité sont généralement liés à un compromis concret entre vie privée et utilité.
Un exemple pratique
Supposons que vous disposiez d’un système de CA qui vous permet de divulguer sélectivement des attributs arbitraires au moment de la présentation de la carte d’identité. Mais ensuite, vous voulez le réutiliser dans un scénario où vous avez également besoin de lier les présentations du même utilisateur (peut-être que vous voulez récompenser cet utilisateur avec quelques points de fidélité, ou peut-être que cet utilisateur vous spamme et que vous voulez le bloquer !) En bref, vous voulez ajouter une certaine forme d’auditabilité. Ce changement a priori simple nécessite un nouveau modèle de sécurité! Bien sûr, si vous savez comment le faire, vous pouvez étendre le précédent et, si vous avez de la chance, la construction que vous aviez auparavant peut également être mise à jour facilement. Mais si vous avez déjà mis en œuvre ce genre de choses, vous savez déjà que c’est généralement trop espérer.
Un modèle dynamique pour les compromis entre vie privée et utilité dans l’authentification anonyme
Exiger un modèle de sécurité pour chaque compromis concret entre vie privée et utilité n’est évidemment pas idéal. Et c’est précisément ce que nous voulions corriger, car ce type d’exigences proches mais différentes est assez courant dans la pratique. Ce que nous avons donc fait, c’est proposer un modèle de sécurité générique qui peut être modifié ici et là, de manière à ce que vous puissiez l’adapter aux besoins de votre cas d’utilisation - en termes de compromis vie privée/utilité. En regardant de plus près, il y a trois points sur lesquels on peut vouloir adapter ce type de schémas d’authentification anonyme :
- Au moment de la délivrance : lorsqu’un utilisateur demande un titre, il peut lui être demandé de fournir des titres d’approbation précédemment obtenus qui satisfont à la propriété A ou B - ou il peut même ne pas avoir à fournir de titre du tout !
- Au moment de la signature : lorsqu’un utilisateur souhaite produire une signature anonyme (ou présenter sa carte d’identité), le vérificateur peut avoir besoin d’apprendre que les attributs de la carte d’identité répondent à certains critères.
- Au moment de l’audit : les auditeurs peuvent exiger que certaines informations puissent être extraites après la création de la signature. Il se peut aussi qu’il n’y ait pas d’auditeurs du tout !
Nous capturons ces différents compromis par le biais de “paramètres fonctionnels” (les programmeurs peuvent les considérer comme des fonctions abstraites) à ces trois points, qui sont intégrés dans un cadre de sécurité qui suit fondamentalement le modèle d’anonymat et d’infalsifiabilité mentionné plus haut. Le plus important pour les ingénieurs est que, étant donné une construction dont la sécurité est prouvée dans notre modèle, ils n’auraient qu’à spécifier les fonctions concrètes nécessaires à chaque étape - émission, signature et audit -, et c’est tout ! La sécurité découle de la sécurité de la construction principale.
Quel est le rapport avec GS, AC ou RS ?
C’est une bonne question ! Nous voulions être certains que le modèle général que nous revendiquons est réellement général. Comment avons-nous procédé ? Nous avons prouvé qu’en donnant des fonctions concrètes au moment de l’émission, de la signature et de l’audit, notre construction générique peut se comporter comme un schéma GS, AC ou RS. Plus précisément, nous prouvons qu’une telle variante de notre construction est un schéma GS, AC ou RS sécurisé, en vertu de leurs modèles de sécurité bien connus.)
Bien entendu, les documents étant finis, nous prouvons uniquement que les GS, AC et RS de base peuvent être construits à partir d’une construction générique de la SAU. Nous esquissons également des preuves pour des variantes plus avancées, telles que GS avec ouverture dépendante du message, Signatures privées multimodales, et Accréditations anonymes révocables. Il est facile d’imaginer de nombreuses autres variantes. Les références anonymes avec des capacités d’audit étendues, par exemple, ou même des systèmes de signature anonymes avec un compromis vie privée/utilité qui n’a pas encore été pris en compte dans l’espace universitaire.
Quelle est (ou peut être) la prochaine étape ?
La première chose que vous avez peut-être remarquée, c’est qu’il s’agit d’un travail assez théorique. Si tout semble parfait sur le papier, les problèmes peuvent apparaître lors du codage. Une préoccupation légitime est de savoir quelle pénalité est payée en termes d’efficacité pour avoir une construction qui peut être adaptée pour convenir à de nombreux cas d’utilisation différents. Il s’agit d’une préoccupation tout à fait raisonnable. Après tout, les systèmes conçus dans un seul but tendent à être plus efficaces. Pour mieux évaluer cette question, nous travaillons sur un prototype. Dans un premier temps, nous souhaitons disposer d’une bibliothèque capable d’abstraire les détails internes et de permettre aux développeurs de se concentrer sur la mise en œuvre des paramètres fonctionnels concrets qui les intéressent. Ensuite, nous testerons l’efficacité du résultat à partir de notre construction générique (pour l’instant uniquement). Cela sera probablement suffisant pour certaines applications, mais pas pour toutes.
L’article donne une construction générique basée sur BBS+, le cryptage et les preuves ZK génériques (non interactives). Cela conviendra certainement si nous voulons obtenir des revendications de type divulgation sélective, mais cela ne conviendra probablement pas si nous voulons prouver des prédicats plus expressifs, par exemple. L’étape suivante consiste donc à réfléchir à d’autres constructions génériques mieux adaptées à des exigences plus expressives.
D’un point de vue théorique, nous avons également de nombreuses idées pour l’avenir. Permettre aux émetteurs et aux auditeurs de changer de fonction, par exemple. Actuellement, si plusieurs émetteurs ou auditeurs peuvent coexister, chacun d’entre eux s’engage à remplir une fonction. Adapter le modèle à un environnement entièrement dynamique, et bien d’autres choses encore.
Comment prévoyons-nous d’intégrer l’UAS dans Atala ?
Comme indiqué, nous travaillons sur une implémentation basée sur notre construction générique de BBS+, le cryptage (ElGamal), et les preuves ZK (protocoles Sigma de base). Ce sera notre point de départ, nous permettant de tester cette nouvelle technologie dans la pile SSI fournie par Atala. En intégrant l’UAS dans la pile SSI d’Atala (Open Enterprise Agent stack), nous serons en mesure de tirer parti de tous les outils inclus par Atala et de commencer à tester le comportement de l’UAS dans des environnements prêts pour la production (avec des agents, des nœuds, des protocoles de communication, etc. spécifiques à SSI), et de l’adapter aux besoins du marché et des équipes d’ingénieurs.
Gardez un œil sur les prochaines mises à jour !