Récemment, nous avons reçu l’article « Fondements des signatures anonymes : définitions formelles, exigences simplifiées et construction basée sur des hypothèses générales » 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 vraiment enthousiasmés car, en plus de relier plusieurs sous-domaines du domaine de l’authentification anonyme, l’UAS ouvre la voie à ce que nous pensons être (une partie de) l’avenir de l’identité auto-souveraine et quelque chose que nous allons certainement promouvoir pour l’intégration au sein du Offrande Atala .
Mais assez d’introduction. Qu’est-ce que l’UAS ?
Un peu d’histoire
En 1985, David Chaum a imaginé pour la première fois un identifiant cryptographique que les gens pourraient utiliser sans divulguer leur identité, tout en donnant aux prestataires de services l’assurance qu’ils parlent à une personne légitime. De nombreuses variantes ont été proposées, exploitant généralement le concept d’attributs attestés – que les titulaires de titres d’identité peuvent choisir de révéler ou non. C’est ce qu’on appelle les systèmes d’informations d’identification anonymes (AC).
En 1991, Chaum et van Heyst ont proposé les signatures de groupe (GS), qui permettent aux membres d’un groupe titulaires d’un titre de membre de faire quelque chose de similaire aux AC. Ces informations d’identification d’adhésion n’ont généralement pas d’attributs, mais les signatures produites par les systèmes GS peuvent être traitées par une entité de confiance, qui peut extraire l’identifiant du signataire autrement anonyme.
Les systèmes AC et GS s’appuient sur les autorités délivrant les informations d’identification nécessaires pour s’authentifier ou signer. Une telle entité a été supprimée en 2001, lorsque Rivest, Shamir et Tauman ont imaginé les systèmes Ring Signature (RS), qui peuvent être considérés comme une sorte de signature de groupe qui ne peut pas être désanonymisée et ne nécessite pas d’émetteurs.
Ainsi, en à peine 16 ans, la communauté cryptographique s’est retrouvée face à trois manières différentes mais similaires de permettre aux utilisateurs de s’authentifier de manière anonyme. Et depuis 2001, de nombreuses autres variantes ont été proposées, trouvant parfois des points intermédiaires. Ceux-ci incluent des schémas RS qui permettent de lier des signatures ou des signatures de groupe dans lesquelles seuls les utilisateurs peuvent lier leurs propres signatures).
Que résout l’UAS ?
En fait, ce n’est pas seulement que les schémas AC, GS et RS (et leurs nombreuses variantes) ont 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 une certaine sorte de contrôle sur les informations qu’ils peuvent extraire. D’un point de vue théorique, cela se reflète dans le fait que les modèles de sécurité se ressemblent généralement beaucoup. Par exemple, il faut toujours penser aux propriétés d’anonymat, qui capturent ce que l’on peut apprendre d’une signature. Et sur les propriétés d’infalsification, qui ont des variantes de traçabilité et de non-frameabilité, indiquant précisément à quel type d’assurance d’infalsification les vérificateurs (prestataires de services) et les utilisateurs peuvent s’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 autres ont été étudiés indépendamment. De plus, même si dans certaines branches concrètes, comme 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’ils disposent de modèles de référence, ces modèles de sécurité sont généralement liés à un compromis concret entre confidentialité et utilité .
Un exemple pratique
Disons que vous disposez d’un schéma AC qui vous permet de divulguer de manière sélective des attributs arbitraires au moment de la présentation des informations d’identification. Mais ensuite, vous souhaitez le réutiliser dans un scénario où vous devez également lier des présentations du même utilisateur (peut-être souhaitez-vous récompenser cet utilisateur avec des points de fidélité, ou peut-être que cet utilisateur vous envoie du spam et que vous souhaitez le bloquer !) . En bref, vous souhaitez ajouter un certain type d’auditabilité. Ce changement a priori simple nécessite un nouveau modèle de sécurité ! Bien sûr, si vous savez comment faire, vous pouvez étendre la précédente 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 confidentialité et utilité dans l’authentification anonyme
Exiger un seul modèle de sécurité par compromis concret entre confidentialité 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 sont assez courantes dans la pratique. Nous avons donc mis au point l’UAS, un modèle de sécurité générique qui peut être modifié ici et là, afin que vous puissiez l’adapter aux besoins de votre cas d’utilisation – en termes de compromis requis entre confidentialité et utilité. . De manière un peu plus détaillée, en y regardant de plus près, il y a trois points sur lesquels on peut vouloir adapter ce type de schémas d’authentification anonymes :
- Au moment de l’émission : lorsqu’un utilisateur demande un identifiant, il peut lui être demandé de fournir des identifiants d’approbation précédemment obtenus qui répondent à la propriété A ou B - ou il peut même ne pas être obligé de fournir un identifiant du tout !
- Au moment de la signature : lorsqu’un utilisateur souhaite produire une signature anonyme (ou présenter son identifiant), le vérificateur peut exiger d’apprendre que les attributs du identifiant 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 également qu’il n’y ait aucun auditeur !
Nous capturons ces différents compromis via des « espaces réservés 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 essentiellement le modèle d’anonymat-infalsifiable mentionné ci-dessus. Le plus important pour les ingénieurs est que, étant donné une construction prouvée sécurisée dans notre modèle, il leur suffirait de préciser 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 ?
Bonne question ! Nous voulions être certains que notre modèle général revendiqué est réellement général. Alors, comment avons-nous fait ? Eh bien, 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 sécurisé GS, AC ou RS, selon leurs modèles de sécurité bien connus).
Bien sûr, les articles sont limités, nous prouvons donc seulement que les GS, AC et RS de base peuvent être construits à partir d’une construction générique d’UAS. 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 informations d’identification anonymes révocables . Il est facile d’imaginer bien d’autres variantes. Des informations d’identification anonymes avec des capacités d’audit étendues, par exemple, ou même des systèmes de signature anonymes avec un compromis entre confidentialité et utilité qui n’a pas encore été envisagé 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. Bien que tout semble parfait sur le papier, des 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 à de nombreux cas d’utilisation différents. C’est une préoccupation très raisonnable. Après tout, les programmes conçus dans un seul but ont tendance à être plus efficaces. Pour mieux évaluer cela, nous travaillons sur un prototype. Dans un premier temps, nous souhaitons disposer d’une bibliothèque capable d’extraire les détails internes et de permettre aux développeurs de se concentrer sur la mise en œuvre des espaces réservés fonctionnels concrets qui les intéressent. Ensuite, testez l’efficacité du résultat, à partir de notre (actuellement uniquement) construction générique. . Ce 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 des preuves ZK génériques (non interactives). Cela conviendra très certainement si nous voulons obtenir des allégations de type divulgation sélective, mais cela ne conviendra probablement pas si nous voulons prouver des prédicats plus expressifs, par exemple. La prochaine étape consiste donc à réfléchir à des constructions génériques alternatives, mieux adaptées à des exigences plus expressives.
Aussi, d’un point de vue théorique, nous avons de nombreuses idées pour l’avenir. Permettre aux émetteurs et aux auditeurs de modifier leurs fonctions, par exemple. Aujourd’hui, si plusieurs émetteurs ou auditeurs peuvent coexister, chacun d’eux s’engage sur une fonction. Ou adaptez le modèle au cadre entièrement dynamique, et bien d’autres encore.
Comment prévoyons-nous d’intégrer les UAS dans Atala ?
Comme indiqué, nous travaillons sur une implémentation basée sur notre construction générique à partir des preuves BBS+, de chiffrement (ElGamal) et ZK (protocoles Sigma de base). Ce sera notre point de départ, nous permettant de tester cette nouvelle technologie dans la stack SSI fournie par Atala. En intégrant l’UAS dans la pile Open Enterprise Agent d’Atala, nous serons en mesure d’exploiter 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 spécifiques à SSI, etc.), et également l’adapter au marché et aux besoins des équipes d’ingénierie.
Gardez un œil sur les mises à jour à venir !